Internet DRAFT - draft-sarikaya-6man-ra-guidelines

draft-sarikaya-6man-ra-guidelines







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, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <http://www.rfc-editor.org/info/rfc1122>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
              November 2005, <http://www.rfc-editor.org/info/rfc4191>.





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,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

   [RFC5175]  Haberman, B., Ed. and R. Hinden, "IPv6 Router
              Advertisement Flags Option", RFC 5175,
              DOI 10.17487/RFC5175, March 2008,
              <http://www.rfc-editor.org/info/rfc5175>.

   [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,
              <http://www.rfc-editor.org/info/rfc6106>.

   [RFC6250]  Thaler, D., "Evolution of the IP Model", RFC 6250,
              DOI 10.17487/RFC6250, May 2011,
              <http://www.rfc-editor.org/info/rfc6250>.

   [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,
              <http://www.rfc-editor.org/info/rfc7227>.

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]