Updates: 2460 (if approved) Expires: February 22, 2016 Juniper Networks August 21, 2015

Transcription

1 6man Internet-Draft Updates: 2460 (if approved) Intended status: Best Current Practice Expires: February 22, 2016 F. Gont UTN-FRH / SI6 Networks W. Liu Huawei Technologies R. Bonica Juniper Networks August 21, 2015 Transmission and Processing of IPv6 Options draft-gont-6man-ipv6-opt-transmit-02.txt Abstract Various IPv6 options have been standardized since the core IPv6 standard was first published. This document updates RFC 2460 to clarify how nodes should deal with such IPv6 options and with any options that are defined in the future. It complements [RFC7045], which offers a similar clarification regarding IPv6 Extension Headers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 22, 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 ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Gont, et al. Expires February 22, 2016 [Page 1]

2 Internet-Draft Transm. and Proc. of IPv6 Options August 2015 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 and Problem Statement Terminology and Conventions Used in This Document Terminology Conventions Considerations for All IPv6 Options Processing of currently-defined IPv6 Options Hop-by-Hop Options Header Destination Options Header IANA Considerations Security Considerations Acknowledgements References Normative References Informative References Authors Addresses Introduction and Problem Statement Various IPv6 options have been standardized since the core IPv6 standard [RFC2460] was first published. Except for the padding options (Pad1 and PadN), all the options that have so far been specified are meant to be employed with specific IPv6 Extension Header (EH) types. Additionally, some options have specific requirements such as, for example, only allowing a single instance of the option in the corresponding IPv6 extension header. This establishes some criteria for validating packets that employ IPv6 options. [RFC2460] specifies that IPv6 extension headers (with the exception of the Hop-by-Hop Options extension header) are not examined or processed by any node along a packet s delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. However, in practice this is not really the case: some routers, and a variety of middleboxes such as firewalls, load balancers, or packet classifiers, might inspect other parts of each packet [RFC7045]. Hence both end-nodes an intermediate nodes may end up inspecting the contents of extension headers and discard packets based on the presence of specific IPv6 options. Gont, et al. Expires February 22, 2016 [Page 2]

3 Internet-Draft Transm. and Proc. of IPv6 Options August 2015 This document clarifies the default processing of IPv6 options. In those cases in which the specifications add additional constraints/ requirements regarding IPv6 options, such additional constraints/ requirements are also taken into account. 2. Terminology and Conventions Used in This Document 2.1. Terminology In the remainder of this document, the term "forwarding node" refers to any router, firewall, load balancer, prefix translator, or any other device or middlebox that forwards IPv6 packets with or without examining the packet in any way. In this document, "standard" IPv6 options are those specified in detail by IETF Standards Actions [RFC5226]. "Experimental" options include those defined by any Experimental RFC and the option types 0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, and 0xFE, defined by [RFC3692] and [RFC4727] when used as experimental options. "Defined" options are the "standard" options plus the "experimental" ones. The terms "permit" (allow the traffic), "drop" (drop with no notification to sender), and "reject" (drop with appropriate notification to sender) are employed as defined in [RFC3871]. Throughout this document we also employ the term "discard" as a generic term to indicate the act of discarding a packet, irrespective of whether the sender is notified of such packet drops. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] Conventions This document clarifies some basic validation of IPv6 options, and specifies the default processing of them. We recommend that a configuration option is made available to govern the processing of each IPv6 option type, on a per-eh-type granularity. Such configuration options may include the following possible settings: o Permit this IPv6 Option type o Drop (and log) packets containing this IPv6 option type o Reject (and log) packets containing this IPv6 option type (where the packet drop is signaled with an ICMPv6 error message) Gont, et al. Expires February 22, 2016 [Page 3]

4 Internet-Draft Transm. and Proc. of IPv6 Options August 2015 o Rate-limit the processing of packets containing this IPv6 option type o Ignore this IPv6 option type (forwarding packets that contain them) We note that special care needs to be taken when devices log packet drops/rejects. Devices should count the number of packets dropped/ rejected, but the logging of drop/reject events should be limited so as to not overburden device resources. Finally, we note that when discarding packets, it is generally desirable that the sender be signaled of the packet drop, since this is of use for trouble-shooting purposes. However, throughout this document (when recommending that packets be discarded) we generically refer to the action as "discard" without specifying whether the sender is signaled of the packet drop. 3. Considerations for All IPv6 Options Forwarding nodes that discard packets (by default) based on the presence of IPv6 options are known to cause connectivity failures and deployment problems. Any forwarding node along an IPv6 packet s path, which forwards the packet for any reason, SHOULD do so regardless of any IPv6 Destination Options that are present, as required by [RFC2460]. Exceptionally, if a forwarding node is designed to examine IPv6 Destination Options for any reason, such as firewalling, it MUST recognise and deal appropriately with all standard IPv6 options types and SHOULD recognise and deal appropriately with all experimental IPv6 options. The list of standard and experimental option types is maintained by IANA (see [IANA-IPV6-PARAM]), and implementors are advised to check this list regularly for updates. In the case of some options meant to be included in IPv6 extension headers other than Hop-by-Hop Options, [RFC2460] requires destination hosts to discard the corresponding packet if the option is unrecognised. However, intermediate forwarding nodes SHOULD NOT do this, since doing so might cause them to inadvertently discard traffic using a recently standardised IPv6 option not yet recognised by the intermediate node. The exceptions to this rule are discussed next. If a forwarding node discards a packet containing a standard IPv6 option, it MUST be the result of a configurable policy and not just the result of a failure to recognise such an option. This means that the discard policy for each standard type of IPv6 option MUST be Gont, et al. Expires February 22, 2016 [Page 4]

5 Internet-Draft Transm. and Proc. of IPv6 Options August 2015 individually configurable. The default configuration SHOULD allow all standard IPv6 options. Experimental IPv6 options SHOULD be treated in the same way as standard IPv6 options, including an individually configurable discard policy. A node that processes the contents of an extension header MUST discard the corresponding packet if it contains any defined options that are not meant for the extension header being processed. This document requests IANA to add a new column to [IANA-IPV6-PARAM] to clearly mark the IPv6 Extension Header type(s) for which each option (defined by IETF Standards Action or IESG Approval) is valid. A node that processes the contents of an IPv6 extension header MAY discard the corresponding packet if it contains any options that have become deprecated. Whether or not such packets are dropped SHOULD be configurable, and the default setting MUST be to not drop such packets. A node that processes the contents of an extension header and encounters an undefined (unrecognised) IPv6 option MUST react to such option according to the highest-order two bits of the option type, as specified by Section 4.2 of [RFC2460]. A node that processes an IPv6 extension header MAY discard a packet containing any experimental IPv6 options. 4. Processing of currently-defined IPv6 Options The following subsections provide advice on how to process the IPv6 options that have been defined at the time of this writing, according to the rules specified in the previous sections Hop-by-Hop Options Header A node that processes the Hop-by-Hop Options extension header MUST discard the corresponding packet if it contains any options that are not valid for the Hop-by-Hop Options extension header [IANA-IPV6-PARAM]. A node that processes the Hop-by-Hop Options extension header MUST discard a packet containing multiple instances (i.e., more than one) of this option in the Hop-by-Hop Options extension header: o Type 0x05: Router Alert [RFC2711] Gont, et al. Expires February 22, 2016 [Page 5]

6 Internet-Draft Transm. and Proc. of IPv6 Options August 2015 NOTE: The rationale for discarding the packet is that [RFC2711] forbids multiple instances of this option. A node that processes the Hop-by-Hop Options extension header MUST discard a packet that carries a Fragment Header and also contains this option in the Hop-by-Hop Options extension header: o Type 0xC2: Jumbo Payload [RFC2675] NOTE: The rationale for discarding the packet is that [RFC2675] forbids the use of the Jumbo Payload Option in packets that carry a Fragment Header. A node that processes the Hop-by-Hop Options extension header MAY discard a packet containing any of the following options in that header: o Type=0x4D: Deprecated NOTE: The rationale for discarding the packet is that the aforementioned option has been deprecated. A node that processes the Hop-by-Hop Options extension header MAY discard a packet containing any of the following options in that header: o Type 0x1E: RFC3692-style Experiment [RFC4727] o Type 0x3E: RFC3692-style Experiment [RFC4727] o Type 0x5E: RFC3692-style Experiment [RFC4727] o Type 0x7E: RFC3692-style Experiment [RFC4727] o Type 0x9E: RFC3692-style Experiment [RFC4727] o Type 0xBE: RFC3692-style Experiment [RFC4727] o Type 0xDE: RFC3692-style Experiment [RFC4727] o Type 0xFE: RFC3692-style Experiment [RFC4727] NOTE: This is in line with the corresponding specification in [RFC7045] for experimental extension headers. Gont, et al. Expires February 22, 2016 [Page 6]

7 Internet-Draft Transm. and Proc. of IPv6 Options August Destination Options Header A node that processes the Destination Options header MUST discard a packet containing any options that are not valid for the Destination Options header [IANA-IPV6-PARAM]. A node that processes the Destination Options extension header MAY discard a packet containing any of the following options in that header: o Type 0x8A: Endpoint Identification [nimrod-eid] [NIMROD-DOC] o Type 0x4D: Deprecated NOTE: The rationale for discarding the packet is that the aforementioned options have been deprecated. A node that processes the Destination Options extension header MAY discard a packet containing any of the following options in that header: o Type 0x1E: RFC3692-style Experiment [RFC4727] o Type 0x3E: RFC3692-style Experiment [RFC4727] o Type 0x5E: RFC3692-style Experiment [RFC4727] o Type 0x7E: RFC3692-style Experiment [RFC4727] o Type 0x9E: RFC3692-style Experiment [RFC4727] o Type 0xBE: RFC3692-style Experiment [RFC4727] o Type 0xDE: RFC3692-style Experiment [RFC4727] o Type 0xFE: RFC3692-style Experiment [RFC4727] NOTE: This is in line with the corresponding specification in [RFC7045] for experimental extension headers. 5. IANA Considerations IANA is requested to add an extra column entitled "Extension Header Types" to the "Destination Options and Hop-by-Hop Options" registry [IANA-IPV6-PARAM], to clearly mark the IPv6 Extension Header types for which each option (defined by IETF Standards Action or IESG Approval) is valid (see the list below). This also applies to Destination Options and Hop-by-Hop Options defined in the future. Gont, et al. Expires February 22, 2016 [Page 7]

8 Internet-Draft Transm. and Proc. of IPv6 Options August 2015 What follows is the initial list of IPv6 options and the corresponding marks that indicate which Extension Header type(s) these IPv6 options are valid for: Hex Description Reference EH Valu Types e x00 Pad1 [RFC2460] DH x01 PadN [RFC2460] DH xC2 Jumbo Payload [RFC2675] H x63 RPL Option [RFC6553] H x04 Tunnel [RFC2473] D Encapsulation Limit x05 Router Alert [RFC2711] H x26 Quick-Start [RFC4782] H x07 CALIPSO [RFC5570] H x08 SMF_DPD [RFC6621] H xC9 Home Address [RFC6275] D x8A Endpoint [nimrod-eid][nimrod-doc] D Identification x8B ILNP Nonce [RFC6744] D x8C Line-Identification [RFC6788] D Option x4D Deprecated U x6D MPL Option [I-D.ietf-roll-trickle- H mcast] xEE IPv6 DFF Header [RFC6971] H x1E RFC3692-style [RFC4727] DH Experiment Gont, et al. Expires February 22, 2016 [Page 8]

9 Internet-Draft Transm. and Proc. of IPv6 Options August x3E RFC3692-style [RFC4727] DH Experiment x5E RFC3692-style [RFC4727] DH Experiment x7E RFC3692-style [RFC4727] DH Experiment x9E RFC3692-style [RFC4727] DH Experiment xBE RFC3692-style [RFC4727] DH Experiment xDE RFC3692-style [RFC4727] DH Experiment xFE RFC3692-style [RFC4727] DH Experiment Additionally, the following legend should be added to the registry: D: Destination Options Header H: Hop-by-Hop Options Header U: Unknown 6. Security Considerations Forwarding nodes that operate as firewalls MUST conform to the requirements in this document. In particular, packets containing standard IPv6 options are only to be discarded as a result of an intentionally configured policy. These requirements do not affect a firewall s ability to filter out traffic containing unwanted or suspect IPv6 options, if configured to do so. However, the changes do require firewalls to be capable of permitting any or all IPv6 options, if configured to do so. The default configurations are intended to allow normal use of any standard IPv6 option, avoiding the interoperability issues described in Section 1 and Section 3. As noted above, the default configuration might discard packets containing experimental IPv6 options. Gont, et al. Expires February 22, 2016 [Page 9]

10 Internet-Draft Transm. and Proc. of IPv6 Options August Acknowledgements This document is heavily based on [RFC7045], authored by Brian Carpenter and Sheng Jiang. The authors of this document would like to thank (in alphabetical order) Brian Carpenter, Mike Heard, and Jen Linkova, for providing valuable comments on earlier versions of this document. 8. References 8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI /RFC1034, November 1987, < [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI /RFC2119, March 1997, < [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI /RFC2205, September 1997, < [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI /RFC2460, December 1998, < [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI /RFC2473, December 1998, < [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI /RFC2675, August 1999, < [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI /RFC2710, October 1999, < [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, DOI /RFC2711, October 1999, < Gont, et al. Expires February 22, 2016 [Page 10]

11 Internet-Draft Transm. and Proc. of IPv6 Options August 2015 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI /RFC3692, January 2004, < [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI /RFC4302, December 2005, < [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI /RFC4303, December 2005, < [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)", RFC 4304, DOI /RFC4304, December 2005, < [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, DOI /RFC4727, November 2006, < [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- Start for TCP and IP", RFC 4782, DOI /RFC4782, January 2007, < [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI /RFC5095, December 2007, < [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, DOI /RFC5201, April 2008, < [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI /RFC5226, May 2008, < [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, DOI /RFC5533, June 2009, < Gont, et al. Expires February 22, 2016 [Page 11]

12 Internet-Draft Transm. and Proc. of IPv6 Options August 2015 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, DOI /RFC5570, July 2009, < [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI /RFC6275, July 2011, < [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI /RFC6398, October 2011, < [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI /RFC6550, March 2012, < [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI /RFC6553, March 2012, < [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI /RFC6554, March 2012, < [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding", RFC 6621, DOI /RFC6621, May 2012, < [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network Protocol (ILNP) Architectural Description", RFC 6740, DOI /RFC6740, November 2012, < [RFC6744] Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)", RFC 6744, DOI /RFC6744, November 2012, < Gont, et al. Expires February 22, 2016 [Page 12]

13 Internet-Draft Transm. and Proc. of IPv6 Options August 2015 [RFC6788] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. Nordmark, "The Line-Identification Option", RFC 6788, DOI /RFC6788, November 2012, < [RFC6971] Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S. Cespedes, "Depth-First Forwarding (DFF) in Unreliable Networks", RFC 6971, DOI /RFC6971, June 2013, < [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI /RFC7045, December 2013, < [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI /RFC7112, January 2014, < Informative References [Biondi2007] Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", CanSecWest 2007 Security Conference, 2007, < [I-D.ietf-roll-trickle-mcast] Hui, J. and R. Kelsey, "Multicast Protocol for Low power and Lossy Networks (MPL)", draft-ietf-roll-tricklemcast-12 (work in progress), June [I-D.ietf-v6ops-ipv6-ehs-in-real-world] Gont, F., Linkova, J., Chown, T., and S. LIU, "Observations on IPv6 EH Filtering in the Real World", draft-ietf-v6ops-ipv6-ehs-in-real-world-00 (work in progress), April [IANA-IPV6-PARAM] Internet Assigned Numbers Authority, "Internet Protocol Version 6 (IPv6) Parameters", December 2013, < ipv6-parameters.xhtml>. [NIMROD-DOC] Nimrod Documentation Page,, " jnc/nimrod/". Gont, et al. Expires February 22, 2016 [Page 13]

14 Internet-Draft Transm. and Proc. of IPv6 Options August 2015 [nimrod-eid] Lynn, C., "Endpoint Identifier Destination Option", IETF Internet Draft, draft-ietf-nimrod-eid-00.txt, November [RFC3871] Jones, G., Ed., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, DOI /RFC3871, September 2004, < [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations on Filtering of IPv4 Packets Containing IPv4 Options", BCP 186, RFC 7126, DOI /RFC7126, February 2014, < Authors Addresses Fernando Gont UTN-FRH / SI6 Networks Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: fgont@si6networks.com URI: Will(Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen P.R. China liushucheng@huawei.com Ronald P. Bonica Juniper Networks 2251 Corporate Park Drive Herndon, VA US Phone: rbonica@juniper.net Gont, et al. Expires February 22, 2016 [Page 14]

15 IPv6 maintenance Working Group (6man) Internet-Draft Updates: 6106 (if approved) Intended status: Standards Track Expires: August 30, 2015 F. Gont SI6 Networks / UTN-FRH P. Simerda W. Liu Huawei Technologies February 26, 2015 Current issues with DNS Configuration Options for SLAAC draft-gont-6man-slaac-dns-config-issues-01 Abstract RFC 6106 specifies two Neighbor Discovery options that can be included in Router Advertisement messages to convey information about DNS recursive servers and DNS Search Lists. Small lifetime values for the aforementioned options have been found to cause interoperability problems in those network scenarios in which these options are used to convey DNS-related information. This document analyzes the aforementioned problem, and formally updates RFC 6106 such that these issues are mitigated. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 30, 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 ( in effect on the date of Gont, et al. Expires August 30, 2015 [Page 1]

16 Internet-Draft SLAAC DNS Configuration Issues February 2015 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 Changing the Semantics of the Lifetime field of RDNSS and DNSSL options Changing the Default Values of the Lifetime field of RDNSS and DNSSL options Use of Router Solicitations for active Probing Sanitize the received RDNSS/DNSSL Lifetime Values Security Considerations Acknowledgements Normative References Authors Addresses Introduction RFC 6106 [RFC6106] specifies two Neighbor Discovery (ND) [RFC4861] options that can be included in Router Advertisement messages to convey information about DNS recursive servers and DNS Search Lists. Namely, the Recursive DNS Server (RDNSS) Option specifies the IPv6 addresses of recursive DNS servers, while the DNS Search List (DNSSL) Option specifies a "search list" to be used when trying to resolve a name by means of the DNS. Each of this options include a "Lifetime" field which specifies the maximum time, in seconds, during which the information included in the option can be used by the receiving system. The aforementioned "Lifetime" value is set as a function of the Neighbor Discovery parameter MaxRtrAdvInterval, which specifies the maximum time allowed between sending unsolicited multicast Router Advertisements from an interface. The recommended bounds (MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval) have been found to be too short for scenarios in which some Router Advertisement messages may be lost. In such scenarios, hosts may fail to receive unsolicited Router Advertisements and therefore fail to refresh the expiration time of the DNS-related information previously learned through the RDNSS and DNSSL options), thus eventually discarding the aforementioned DNSrelated information prematurely. Some implementations consider the lack of DNS-related information as a hard failure, thus causing configuration restart. This situation Gont, et al. Expires August 30, 2015 [Page 2]

17 Internet-Draft SLAAC DNS Configuration Issues February 2015 is exacerbated in those implementations in which IPv6 connectivity and IPv4 connectivity are bound together, and hence failure in the configuration of one of them causes the whole link to be restarted. This document formally updates RFC 6106 such that this issue is mitigated. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Changing the Semantics of the Lifetime field of RDNSS and DNSSL options The semantics of the Lifetime field of the RDNSS and DNSSL options is updated as follows: o The Lifetime field indicates the amount of time during which the aforementioned DNS-related information is expected to be stable. A node is NOT required to discard the DNS-related information once the Lifetime expires. o If the information received in a RDNSS or DNSSL option is already present in the corresponding local data structures, the corresponding Expiration time should be updated according to the value in the Lifetime field of the received option. A Lifetime of 0 causes the corresponding information to be discarded, as already specified in [RFC6106]. o If a host has already gathered a sufficient number of RDNSS addresses (or DNS search domain names), and additional data is received while the existing entries have not yet expired, the received RDNSS addresses (or DNS search domain names) SHOULD be ignored. o If a host receives new RDNSS addresses (or DNS search domain names), and some of the existing entries have expired, the newlylearned information SHOULD be used to replace the expired entries. o A host SHOULD flush configured DNS-related information when it has any reason to believe that its network connectivity has changed in some relevant way (e.g., there has been a "link change event"). When that happens, the host MAY send a Router Solicitation message to re-learn the corresponding DNS-related information. o The most-recently-updated information SHOULD have higher priority over the other DNS-related information already present on the local host. Gont, et al. Expires August 30, 2015 [Page 3]

18 Internet-Draft SLAAC DNS Configuration Issues February 2015 We note that the original motivation for enforcing a short expiration timeout value was to allow mobile nodes to prefer local RDNSSes to remote RDNSSes. However, the above rules already allow for a timely update of the corresponding DNS-related information. 3. Changing the Default Values of the Lifetime field of RDNSS and DNSSL options The default RDNSS/DNSSL "Lifetime" value in current the current router solutions vary between MaxRtrAdvInterval and 2*MaxRtrAdvInterval. This means that common packet loss rates can lead to the problem described in this document. One possible approach to mitigate this issue would be to avoid Lifetime values that are on the same order as MaxRtrAdvInterval. This solution would require, of course, changes in router software. When specifying a better default value, the following aspects should be considered: o IPv6 will be used on many links (including IEEE ) that experience packet loss. Therefore losing a few packets in a short period of time should not invalidate DNS configuration information. o Unsolicited Router Advertisements sent on Ethernet networks result in packets that employ multicast Ethernet Destination Addresses. A number of network elements (including those that perform bridging between wireless networks and wired networks) have problems with multicasted Ethernet frames, thus typically leading to packet loss of some of those frames. Therefore, SLAAC implementations should be able to cope with devices that can lose several multicast packets in a row. [RFC6106] is hereby updated as follows: The default value of AdvRDNSSLifetime and AdvDNSSLLifetime MUST be at least 10*MaxRtrAdvInterval so that the probability of hosts receiving unsolicited Router Advertisements is increased. 4. Use of Router Solicitations for active Probing According to RFC 6106, hosts MAY send Router Solicitations to avoid expiry of RDNSS and DNSSL lifetimes. This technique could be employed as a "last resort" when expiration of the RDNSS and DNSSL information is imminent. Gont, et al. Expires August 30, 2015 [Page 4]

19 Internet-Draft SLAAC DNS Configuration Issues February Sanitize the received RDNSS/DNSSL Lifetime Values A host that receives a RDNSS or DNSSL option that has a non-zero Lifetime smaller than 10*MaxRtrAdvInterval should employ 10*MaxRtrAdvInterval as the Lifetime value of the corresponding RDNSS or DNSSL option. 6. Security Considerations This document does not introduce any additional security considerations to those documented in the "Security Considerations" section of [RFC6106]. 7. Acknowledgements The authors would like to thank Erik Nordmark and Mark Smith for their valuable input on the topic covered by this document. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November Authors Addresses Fernando Gont SI6 Networks / UTN-FRH Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina Phone: fgont@si6networks.com URI: Gont, et al. Expires August 30, 2015 [Page 5]

20 Internet-Draft SLAAC DNS Configuration Issues February 2015 Pavel Simerda Phone: Will Liu Huawei Technologies Bantian, Longgang District Shenzhen P.R. China Gont, et al. Expires August 30, 2015 [Page 6]

21 IPv6 maintenance Working Group (6man) Internet-Draft Updates: 4861 (if approved) Intended status: Standards Track Expires: September 9, 2015 F. Gont SI6 Networks / UTN-FRH R. Bonica Juniper Networks W. Liu Huawei Technologies March 8, 2015 Validation of IPv6 Neighbor Discovery Options draft-ietf-6man-nd-opt-validation-00 Abstract This memo specifies validation rules for IPv6 Neighbor Discovery (ND) Options. In order to avoid pathological outcomes, IPv6 implementations validate incoming ND options using these rules. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 9, 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 ( 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 Gont, et al. Expires September 9, 2015 [Page 1]

22 Internet-Draft Validation of ND options March 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction Terminology Methodology The Source Link-Layer Address (SLLA) Option The Target Link-Layer Address (TLLA) Option The Prefix Information Option The Redirected Header Option The MTU Option The Route Information Option The Recursive DNS Server (RDNSS) Option The DNS Search List (DNSSL) Option IANA Considerations Security Considerations Acknowledgements References Normative References Informative References Appendix A. Mapping an IPv6 Address to a Local Router s Own Link-layer Address Appendix B. Mapping a Unicast IPv6 Address to A Broadcast Link- Layer Address Authors Addresses Introduction IPv6 [RFC2460] nodes use Neighbor Discovery (ND) [RFC4861] to discover their neighbors and to learn their neighbors link-layer addresses. IPv6 hosts also use ND to find neighboring routers that can forward packets on their behalf. Finally, IPv6 nodes use ND to verify neighbor reachability, and to detect link-layer address changes. ND defines the following ICMPv6 [RFC4443] messages: o Router Solicitation (RS) o Router Advertisement (RA) o Neighbor Solicitation (NS) o Neighbor Advertisement (NA) o Redirect Gont, et al. Expires September 9, 2015 [Page 2]

23 Internet-Draft Validation of ND options March 2015 ND messages can include options that convey additional information. Currently, the following ND options are specified: o Source link-layer address(slla) [RFC4861] o Target link-layer address (TLLA) [RFC4861] o Prefix information [RFC4861] o Redirected header [RFC4861] o MTU [RFC4861] o Route Information [RFC4191] o Recursive DNS Server (RDNSS) [RFC6106] o DNS Search List (DNSSL) [RFC6106] This memo specifies validation rules for the ND options mentioned above. In order to avoid pathological outcomes (such as [FreeBSD-rtsold]), IPv6 implementations validate incoming ND options using these rules. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Methodology Section 4 through Section 11 of this document define validation rules for ND options. These sections also specify actions that are to be taken when an implementation encounters an invalid option. Possible actions are: o The entire option MUST be ignored. However, the rest of the ND message MAY be processed. o The entire ND message MUST be ignored In the spirit of "being liberal in what you receive", the first action is always preferred. However, when an option length attribute is invalid, it is not possible to parse the rest of the ND message, and therefore subsequent ND options should be ignored. Gont, et al. Expires September 9, 2015 [Page 3]

24 Internet-Draft Validation of ND options March 2015 We note that an implementation SHOULD NOT assume a particular length of an option (based on the option type) when it moves to the next option (whether it handles or ignores the current option) and SHOULD always use the length field of the option. 4. The Source Link-Layer Address (SLLA) Option The SLLA Option is employed with NS, RS, and RA messages. If any other ND message contains an SLLA Option, the SLLA Option MUST be ignored. However, the rest of the ND message MAY be processed. (As per [RFC4861]). Figure 1 illustrates the SLLA Option: Type Length Link-Layer Address Figure 1: Source Link-Layer Address Option The Type field is set to 1. The Length field specifies the length of the option (including the Type and Length fields) in units of 8 octets. The Length field MUST be valid for the underlying link layer. For example, for IEEE 802 addresses the Length field MUST be 1 [RFC2464]. If an incoming ND message does not pass this validation check, the entire ND message MUST be discarded. The Link-Layer Address field specifies the link-layer address of the packet s originator. It MUST NOT be any of the following: o a broadcast address (see Appendix B for rationale) o a multicast address (see Appendix B for rationale) o an address belonging to the receiving node (see Appendix A for rationale) If an incoming ND message does not pass this validation check, the SLLA Option MUST be ignored. However, the rest of the ND message MAY be processed. An ND message that carries the SLLA Option MUST have a source address other than the unspecified address (0:0:0:0:0:0:0:0). If an incoming ND message does not pass this validation check, the SLLA Option MUST Gont, et al. Expires September 9, 2015 [Page 4]

25 Internet-Draft Validation of ND options March 2015 be ignored. However, the rest of the ND message MAY be processed. (As per [RFC4861]). 5. The Target Link-Layer Address (TLLA) Option NA and Redirect messages MAY contain a TLLA Option. If any other ND message contains an TLLA Option, the TLLA Option MUST be ignored. However, the rest of the ND message MAY be processed. (As per [RFC4861]). Figure 2 illustrates the Target link-layer address: Type Length Link-Layer Address Figure 2: Target link-layer address option format The Type field is set to 2. The Length field specifies the length of the option (including the Type and Length fields) in units of 8 octets. The Length field MUST be valid for the underlying link layer. For example, for IEEE 802 addresses the Length field MUST be 1 [RFC2464]. If an incoming ND message does not pass this validation check, the entire ND message MUST be discarded. An ND message that carries the TLLA option also includes a Target Address. The TLLA Option Link-Layer Address maps to the Target Address. The TLLA Option Link-Layer Address MUST NOT be any of the following: o a broadcast address (see Appendix B for rationale) o a multicast address (see Appendix B for rationale) o an address belonging to the receiving node (see Appendix A for rationale) If an incoming ND message does not pass this validation check, the TLLA Option MUST be ignored. However, the rest of the ND message MAY be processed. Gont, et al. Expires September 9, 2015 [Page 5]

26 Internet-Draft Validation of ND options March The Prefix Information Option The RA message MAY contain a Prefix Information Option. If any other ND message contains a Prefix Information Option, the Prefix Information Option MUST be ignored. However, the rest of the ND message MAY be processed. (As per [RFC4861]). Figure 3 illustrates the Prefix Information Option: Type Length Prefix Length L A R Reserved Valid Lifetime Preferred Lifetime Reserved Prefix Figure 3: Prefix Information option format The Type field is set to 3. The Length field MUST be set to 4. If an incoming ND message does not pass this validation check, the entire ND message MUST be discarded. As stated in [RFC4861] the Preferred Lifetime MUST be less than or equal to the Valid Lifetime. If an incoming ND message does not pass this validation check, the Prefix Information Option MUST be ignored. However, the rest of the ND message MAY be processed. The Prefix Length contains the number of leading bits in the prefix that are to be considered valid. It MUST be greater than or equal to 0, and smaller than or equal to 128. If the field does not pass this check, the Prefix Information Option MUST be ignored. However, the rest of the ND message MAY be processed. Gont, et al. Expires September 9, 2015 [Page 6]

27 Internet-Draft Validation of ND options March 2015 The Prefix field MUST NOT contain a link-local or multicast prefix. If an incoming ND message does not pass this validation check, the Prefix Information Option MUST be ignored. However, the rest of the ND message MAY be processed. 7. The Redirected Header Option The Redirect message MAY contain a Redirect Header Option. If any other ND message contains an Redirect Header Option, the Redirect Header Option MUST be ignored. However, the rest of the ND message MAY be processed. (As per [RFC4861]). Figure 4 illustrates the Redirected Header option: Type Length Reserved Reserved IP header + data The Type field is 4. Figure 4: Redirected Header Option format The Length field specifies the option size (including the Type and Length fields) in units of 8 octets. Its value MUST be greater than or equal to 6. If an incoming ND message does not pass this validation check, the entire ND message MUST be discarded. The value 6 was chosen to accommodate mandatory fields (8 octets) plus the base IPv6 header (40 octets). 8. The MTU Option The RA message MAY contain an MTU Option. If any other ND message contains an MTU Option, the MTU Option MUST be ignored. However, the rest of the ND message MAY be processed. (As per [RFC4861]). Figure 5 illustrates the MTU option: Gont, et al. Expires September 9, 2015 [Page 7]

28 Internet-Draft Validation of ND options March Type Length Reserved MTU Figure 5: MTU Option Format The Type field identifies the kind of option and is set to 5. The Length field MUST BE set to 1 by the sender. If an incoming ND message does not pass this validation check, the entire ND message MUST be discarded. The MTU field is a 32-bit unsigned integer that specifies the MTU value that should be used for this link. [RFC2460] specifies that the minimum IPv6 MTU is 1280 octets. Therefore, the MTU MUST be greater than or equal to If an incoming ND message does not pass this validation check, the MTU Option MUST be ignored. However, the rest of the ND message MAY be processed. Additionally, the advertised MTU MUST NOT exceed the maximum MTU specified for the link-type (e.g., [RFC2464] for Ethernet networks). If an incoming ND message does not pass this validation check, the MTU Option MUST be ignored. However, the rest of the ND message MAY be processed. 9. The Route Information Option The RA message MAY contain a Route Information Option. If any other ND message contains a Route Information Option, the Route Information Option MUST be ignored. However, the rest of the ND message MAY be processed. Figure 6 illustrates Route Information option: Gont, et al. Expires September 9, 2015 [Page 8]