DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
RFC 7610
| Document | Type |
RFC - Best Current Practice
(August 2015; No errata)
Also known as BCP 199
|
|
|---|---|---|---|
| Authors | Fernando Gont , Will LIU , Gunter Van de Velde | ||
| Last updated | 2015-10-14 | ||
| Replaces | draft-gont-opsec-dhcpv6-shield | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Chittimaneni Kk | ||
| Shepherd write-up | Show (last changed 2014-12-31) | ||
| IESG | IESG state | RFC 7610 (Best Current Practice) | |
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Joel Jaeggli | ||
| Send notices to | brian.e.carpenter@gmail.com | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | No IANA Actions | ||
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 7610 SI6 Networks / UTN-FRH
BCP: 199 W. Liu
Category: Best Current Practice Huawei Technologies
ISSN: 2070-1721 G. Van de Velde
Alcatel-Lucent
August 2015
DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers
Abstract
This document specifies a mechanism for protecting hosts connected to
a switched network against rogue DHCPv6 servers. It is based on
DHCPv6 packet filtering at the layer 2 device at which the packets
are received. A similar mechanism has been widely deployed in IPv4
networks ('DHCP snooping'); hence, it is desirable that similar
functionality be provided for IPv6 networks. This document specifies
a Best Current Practice for the implementation of DHCPv6-Shield.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7610.
Gont, et al. Best Current Practice [Page 1]
RFC 7610 DHCPv6-Shield August 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Terminology .....................................................3
4. DHCPv6-Shield Configuration .....................................5
5. DHCPv6-Shield Implementation Requirements .......................5
6. Security Considerations .........................................7
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
Acknowledgements ..................................................11
Authors' Addresses ................................................12
Gont, et al. Best Current Practice [Page 2]
RFC 7610 DHCPv6-Shield August 2015
1. Introduction
This document specifies DHCPv6-Shield, a mechanism for protecting
hosts connected to a switched network against rogue DHCPv6 servers
[RFC3315]. The basic concept behind DHCPv6-Shield is that a layer 2
device filters DHCPv6 messages intended for DHCPv6 clients
(henceforth, "DHCPv6-server messages"), according to a number of
different criteria. The most basic filtering criterion is that
DHCPv6-server messages are discarded by the layer 2 device unless
they are received on specific ports of the layer 2 device.
Before the DHCPv6-Shield device is deployed, the administrator
specifies the layer 2 port(s) on which DHCPv6-server messages are to
be allowed. Only those ports to which a DHCPv6 server or relay is to
be connected should be specified as such. Once deployed, the
DHCPv6-Shield device inspects received packets and allows (i.e.,
passes) DHCPv6-server messages only if they are received on layer 2
ports that have been explicitly configured for such purpose.
DHCPv6-Shield is analogous to the Router Advertisement Guard
(RA-Guard) mechanism [RFC6104] [RFC6105] [RFC7113], intended for
protection against rogue Router Advertisement [RFC4861] messages.
We note that DHCPv6-Shield mitigates only DHCPv6-based attacks
against hosts. Attack vectors based on other messages meant for
network configuration (such as ICMPv6 Router Advertisements) are not
addressed by DHCPv6-Shield itself. In a similar vein, DHCPv6-Shield
Show full document text