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]
