Network Working Group B. Sarikaya Internet-Draft Huawei USA Intended status: Best Current Practice D. Luedtke Expires: February 22, 2016 Unaffiliated August 21, 2015 Guidelines for New Router Advertisement Options draft-sarikaya-6man-ra-guidelines-01 Abstract This document defines simple rules to follow when defining new router advertisement options. 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 http://datatracker.ietf.org/drafts/current/. 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, 2016. 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. Sarikaya & Luedtke Expires February 22, 2016 [Page 1] Internet-Draft RA Option Guidelines August 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Configuration using Router Advertisements . . . . . . . . . . 3 4. Provisioning Domains . . . . . . . . . . . . . . . . . . . . 3 5. Considerations on the Options . . . . . . . . . . . . . . . . 4 5.1. Classification of Options . . . . . . . . . . . . . . . . 4 5.2. Considerations on Singleton Options . . . . . . . . . . . 5 5.3. Considerations on Combined Options . . . . . . . . . . . 5 5.4. Considerations on Expanding Options . . . . . . . . . . . 5 5.5. Considerations on Field Sizes . . . . . . . . . . . . . . 5 5.6. Considerations on Field Values . . . . . . . . . . . . . 6 5.7. Considerations on Packet Size . . . . . . . . . . . . . . 6 5.8. RAs Spanning Over Multiple Packets . . . . . . . . . . . 7 6. Recommended Sections . . . . . . . . . . . . . . . . . . . . 7 6.1. Section on Host Configuration . . . . . . . . . . . . . . 7 6.2. Section on Router Configuration . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Router Advertisement messages as defined by the Neighbor Discovery Protocol (NDP) [RFC4861] are sent by routers to hosts on the link. Router Advertisement messages are an important tool in IPv6. Many key protocols are defined around Router Advertisement messages. Neighbor Discovery Protocol is used by IPv6 hosts to discover the presence of other hosts and key information about neighbor hosts such as their link layer address [RFC4861]. Another important functionality is Stateless Address Autoconfiguration (SLAAC) as defined by [RFC4862]. Yet another, perhaps more important functionality of Router Advertisement messages is route configuration. [RFC4191] defines Prefix List and Default Router List or Routing Table structures that the hosts maintain. Maintenance of routing table is becoming more and more important because the hosts in the Internet are mostly multiple interfaced and they use strong end host model [RFC1122], [RFC6250]. Sarikaya & Luedtke Expires February 22, 2016 [Page 2] Internet-Draft RA Option Guidelines August 2015 [RFC7227] defines the guidelines to follow when creating new DHCP options. Similar to DHCP, router advertisement messages carry options and the need to define new options arises every now and then. This document intends to fill the gap in providing some guidelines to Router Advertisement option developers. 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 [RFC2119]. 3. Configuration using Router Advertisements Routers advertise their presence in conjunction with various link and Internet parameters either periodically, or in response to a Router Solicitation message. Router Advertisement messages carry options containing parameters such as Prefix Information, Recursive DNS Servers and Link MTU. Unlike DHCPv6, the operation is stateless. A host cannot request specific or further options from a router, neither by name nor by any other identifier. Note that the PvD Identity option defined in [I-D.ietf-mif-mpvd-ndp-support] is an exception to this, see Section 4. However, the overall operation of solicitation and advertising a router is still stateless. Router Advertisement options are sent to all hosts on a link. The parameters are the same for all hosts on link. This may be only one host on point-to-point links. Router Advertisement options are commonly used to distribute a. on-link specific parameters, such as network layer parameters or route prefixes, and b. related configuration parameters, such as DNS configuration (cp. [RFC6106]). 4. Provisioning Domains Provisioning domains provide a good abstraction for network configuration data which is discussed in this section. Consistent set of network configuration information is called provisioning domain (PvD) [I-D.ietf-mif-mpvd-arch]. The hosts may be connected to one or more provisioning domains. In case of multi- prefix multihoming, more than one provisioning domain is present on a single link. In case of multi-prefix multiple interface environments, elements of the same domain may be present on multiple Sarikaya & Luedtke Expires February 22, 2016 [Page 3] Internet-Draft RA Option Guidelines August 2015 links. So PvD identity is important by the host to know the identity of the provisioning domain that is associated with the configuration information. Provisioning domains give rise to a new set of hosts called PvD aware hosts. PvD aware hosts support association of configuration information into PvDs and use these PvDs to serve requests for network connections. Routers may advertise configuration information related to provisioning domains. PvDs can be constructed from Router Advertisement options. PvDs constructed based on such information are called explicit PvDs. Two router advertisement options are defined for this purpose: PvD identity and PvD container [I-D.ietf-mif-mpvd-ndp-support] options. PvD identity explicitly indicates the identity of the provisioning domain, such as Network Access Identity (NAI) realm like example.com that is associated with the configuration information encapsulated by the PVD container option [I-D.ietf-mif-mpvd-id]. PvD content may be encapsulated in a separate RA option called PvD Container Option. All router advertisement options that make up the configuration data are placed in the container option of an explicit PvD. PvD Identity option may be sent alone by the router without PvD container option to inform the existence of a provisioning domain. PvD Identity option can also be sent by the hosts in Router Solicitation (RS) messages to solicit configuration data from this specific provisioning domain. 5. Considerations on the Options 5.1. Classification of Options Router Advertisement options can be classified as follows: a. Singleton options providing parameters related to all or no prefixes or routes, and b. Combined options providing parameters related to one or more specific prefixes or routes, and c. Options expanding the capacity of a field of an existing option. Being aware of the classification of the proposed option is essential for a consistent definition and implementation. Sarikaya & Luedtke Expires February 22, 2016 [Page 4] Internet-Draft RA Option Guidelines August 2015 5.2. Considerations on Singleton Options Implementers MUST be able to decide which prefixes or routes a singleton option applies to. If there is considerable amount of difficulty to decide on the prefixes, the new document should clarify it in the text. If it cannot be clearly explained then the right approach is to make the association explicit by using combined options, see Section 5.3. Examples of such options are given in [RFC6106] and [I-D.ietf-mif-mpvd-ndp-support]. 5.3. Considerations on Combined Options Stacking more than one data results in combined options. Care should be taken in using combined options. Data that are associated with each other should be combined together. Otherwise it should be preferred to declare them as singleton options. In combined options each piece of data is defined as fields of the option. When defining a new option, the most important question to answer is what will be the host's behavior when it receives the option. If this question cannot be answered without associating the option's data with another option's data then such an option is a good candidate for combining. It should be noted that combined options are typically used in defining data that are associated with route prefixes. 5.4. Considerations on Expanding Options An option expanding the capacity of an existing option's field inherits the class of its parent option. An option expanding the capacity of a Router Advertisement field MUST always be a singleton option. An example is given in [RFC5175]. 5.5. Considerations on Field Sizes Fields in RA options can have a fixed or a variable length. The size of a fixed length field SHOULD be chosen so that the field fits into a standard type, such as uint8_t, uint16_t, uint32_t, and uint64_t. Documents defining smaller fields that can be considered as flags, i.e. fields of one or two bits, SHOULD make use of the Flags Expansion option as defined in [RFC5175]. Fields containing prefixes or addresses or lists of such MUST be sized using a multiple of 16 octets. For example, such a field Sarikaya & Luedtke Expires February 22, 2016 [Page 5] Internet-Draft RA Option Guidelines August 2015 SHOULD NOT be specified of length smaller than sizeof(struct in6_addr). Otherwise implementations may be forced to fill the field using inet_pton() or define it to be of variable length, which is strongly discouraged. 5.6. Considerations on Field Values Documents proposing options including a lifetime field SHOULD use unsigned integers and MAY use units of seconds. A lifetime of zero SHOULD indicate that the option is no longer valid. The latter is important when it is required to invalidate the option. Options in need of a special value for infinity SHOULD use the lifetime field's maximum value (e.g. 65535 in case of 16-bit unsigned integer). Any other non-zero value MAY be defining the option's lifetime in seconds. The starting octet for IPv6 addresses or prefixes or lists of such SHOULD be a multiple of 8. In cases where this is not feasible, the starting octet SHOULD be a multiple of 4. Options containing domain names or lists of such, SHOULD encode the data using the technique described in Section 3.1 of [RFC1035]. By this technique, each domain name is represented as a sequence of labels ending in a zero octet, defined as domain name representation. For more than one domain name, the corresponding domain name representations are concatenated as they are. Note that for the simple decoding, the domain names MUST NOT be encoded in a compressed form, as described in Section 4.1.4 of [RFC1035]. Remaining octets other than the encoding parts of the domain name representations MUST be padded with zeros. 5.7. Considerations on Packet Size When defining new options, sometimes the maximum transmission unit size issues need to be considered. In this case, a rough worst case calculation should be undertaken. We present such a calculation below. Neighbor Discovery Protocol messages SHOULD NOT be subject to fragmentation. Therefore, a Router Advertisement option's overall length is bounded by the following upper limit: Sarikaya & Luedtke Expires February 22, 2016 [Page 6] Internet-Draft RA Option Guidelines August 2015 IPv6 Minimum MTU 1280 [octets] - IPv6 header length 40 [octets] - RA header length 16 [octets] - Expanded Flags option length 8 [octets] ---------------------------------------------- 1216 [octets] ============= A Router Advertisement option's overall length MUST NOT exceed 1216 octets. Documents proposing large or variable length options SHOULD include an analysis clearly indicating that the size is not exceeded. 5.8. RAs Spanning Over Multiple Packets Due to many and/or large options, a Router Advertisement may not fit into a single packet, such RAs are called RAs spanning over multiple packets. In this case the router sends multiple Router Advertisement messages with identical ICMPv6 header, filling each of the messages with different options. Note that, if used, the Flags Expansion option as defined in [RFC5175] is present in all Router Advertisement messages with identical ICMPv6 header. 6. Recommended Sections Router advertisement messages are sent from the router to the hosts. A new document MUST include a section for each of these entities. In other sections the need for the new option(s) are explained. Usually each option is detailed in separate sections. 6.1. Section on Host Configuration This section defines the host behavior related to the option(s) defined. It should be specified under which conditions the option(s) defined can be ignored. In case the host should not ignore the option(s) defined, this section should explain what should the host do, where the information is stored and how the networking behavior of the host will change after receiving the option(s). Host behavior should be detailed based on the field values defined in the new option(s). Each new field may carry different values that require attention by the host. These should be clearly explained. Sarikaya & Luedtke Expires February 22, 2016 [Page 7] Internet-Draft RA Option Guidelines August 2015 6.2. Section on Router Configuration This section defines the router behavior related to the option(s) defined. This includes a description of required behavior of the router in sending this option(s) to the hosts. It should also include what the routers should avoid, i.e. the behavior that is not allowed. Router behavior should be detailed based on the fields defined in the new option(s). Each new field should be covered in detail. 7. Security Considerations This document shares the security issues of Neighbor Discovery Protocol that are documented in the "Security Considerations" section of [RFC4861]. 8. IANA Considerations None. 9. Acknowledgements TBD. 10. References 10.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, . Sarikaya & Luedtke Expires February 22, 2016 [Page 8] Internet-Draft RA Option Guidelines August 2015 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC5175] Haberman, B., Ed. and R. Hinden, "IPv6 Router Advertisement Flags Option", RFC 5175, DOI 10.17487/RFC5175, March 2008, . [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, DOI 10.17487/RFC6106, November 2010, . [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, DOI 10.17487/RFC6250, May 2011, . [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, . 10.2. Informative References [I-D.ietf-mif-mpvd-arch] Anipko, D., "Multiple Provisioning Domain Architecture", draft-ietf-mif-mpvd-arch-11 (work in progress), March 2015. [I-D.ietf-mif-mpvd-id] Krishnan, S., Korhonen, J., Bhandari, S., and S. Gundavelli, "Identification of provisioning domains", draft-ietf-mif-mpvd-id-01 (work in progress), February 2015. [I-D.ietf-mif-mpvd-ndp-support] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-01 (work in progress), February 2015. Sarikaya & Luedtke Expires February 22, 2016 [Page 9] Internet-Draft RA Option Guidelines August 2015 Authors' Addresses Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 175 Plano, TX 75024 Email: sarikaya@ieee.org Dan Luedtke Unaffiliated Munich, Bavaria DE Email: mail@danrl.de URI: https://www.danrl.de Sarikaya & Luedtke Expires February 22, 2016 [Page 10]