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-ShieldShow full document text