| Network Working Group | F. Templin, Ed. |
| Internet-Draft | Boeing Research & Technology |
| Intended status: Informational | January 29, 2018 |
| Expires: August 2, 2018 |
IPv6 Neighbor Discovery Extensions for Prefix Delegation
draft-templin-6man-dhcpv6-ndopt-03.txt
IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for nodes to discover neighbors, routers, prefixes and other services on the link. It also supports a manner of StateLess Address AutoConfiguration (SLAAC). The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specifies a service for the stateful delegation of addresses and prefixes. This document presents IPv6ND extensions for providing a unified prefix delegation service.
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 https://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 August 2, 2018.
Copyright (c) 2018 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 (https://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.
IPv6 Neighbor Discovery (IPv6ND) [RFC4861] specifies a control message set for nodes to discover neighbors, routers, prefixes and other services on the link. It also supports a manner of StateLess Address AutoConfiguration (SLAAC). The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specifies a service for the stateful delegation of addresses and prefixes [RFC3315][RFC3633]. This document presents possible methods for providing a unified prefix delegation service.
When a node first comes onto the link, it sends a Router Solicitation (RS) message to elicit a Router Advertisement (RA) message from one or more routers for the link. If the node also needs to acquire prefix delegations (and, if the 'M' bit is set in the RA message) it then sends a DHCPv6 Solicit message to elicit a Reply message from a DHCPv6 server that is authoritative for the link. This two round-trip message exchange can add delay as well as waste critical link bandwidth on low-end links (e.g., aeronautical wireless links). While it is possible to conceive of starting both round trip exchanges at the same time (i.e., under the leap-of-faith assumption that the link supports DHCPv6 before examining the 'M' bit) this would result in twice as many channel access transactions as necessary.
This document proposes methods for combining these separate operations into a single, unified exchange based on IPv6ND messaging for the purpose of prefix delegation. It notes that a prefix delegation exchange must include at a minimum:
The first method is through definition of a new IPv6ND option called the "DHCPv6 Option" that combines the IPv6ND router discovery and DHCPv6 managed prefix acquisition processes into a single message exchange. Nodes include the DHCPv6 option in RS messages to solicit an RA message with a DHCPv6 option in return. This allows the IPv6ND and DHCPv6 functions to work together to supply the client with all needed configuration information in a minimum number of messages.
The second method leverages the PIO-X proposal [I-D.pioxfolks-6man-pio-exclusive-bit] where the router sets the "X (eXclusive)" bit in an RA Prefix Information Option (PIO) to inform the node that the prefix is provided for the node's own exclusive use. This document permits nodes to include PIO-Xs in their RS messages for the purpose of requesting prefix delegations from routers.
The third method uses out-of-band messaging for the node to request a prefix delegation outside of the scope of IPv6ND messaging. The out-of-band messaging could entail some sort of network login process (e.g., through Layer-2 (L2) messaging, etc). The end result of the out-of-band messaging is that the router returns an RA message with either a PIO-X or DHCPv6 Option to the requesting node (the node having first explicitly requested the prefix delegation in the out-of-band exchange).
The following sections present considerations for nodes that employ these approaches.
The first method discussed in this document is the inclusion of DHCPv6 message options in IPv6ND RS and RA messages, as discussed in the following sections.
The DHCPv6 option is a new IPv6ND option that simply embeds a standard DHCPv6 message per section 6 of [RFC3315], beginning with the 'msg-type' followed by the 'transaction-id' and all DHCPv6 'options'. The format of the option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length | Pad | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 ND DHCPv6 Option Format
[RFC4861], 'Pad' encodes the number of trailing zero octets (between 0 - 7) that appear at the end of the option to pad to an integral number of 8-octets, 'Reserved' is included for alignment and potential future use, and the rest of the option is exactly as defined in Section 6 of [RFC3315]. The length of the full DHCPv6 message is determined by ((('Length' * 8) - 4) - 'Pad'), for a maximum message length of 2044 octets.
The 'Reserved' field MUST be set to 0 on transmission and ignored on reception. Future specifications MAY define new uses for these bits.
When a node first comes onto the link, it creates a Router Solicitation (RS) message containing a DHCPv6 option that embeds a DHCPv6 Solicit message. The Solicit may include a Rapid Commit option if a two-message exchange (i.e., instead of four) is required. The node then sends the RS message either to the unicast address of a specific router on the link, or to the All-Routers multicast address.
When a router receives an RS message with a DHCPv6 option, if it does not recognize the option and/or does not employ a DHCPv6 relay agent or server, it returns a Router Advertisement (RA) message as normal and without including a DHCPv6 option. By receiving the RA message with no DHCPv6 option, the node can determine that the router does not recognize the option and/or does not support a DHCPv6 relay/server function. In this way, no harm will have come from the node including the DHCPv6 option in the RS, and the function is fully backwards compatible.
When a router receives an RS message with a DHCPv6 option, if it recognizes the option and employs a DHCPv6 relay agent or server, it extracts the DHCPv6 message from the RS message and forwards the message to the DHCPv6 relay agent or server. When the DHCPv6 message reaches a DHCPv6 server, the server processes the DHCPv6 Solicit message and prepares either an Advertise (four message) or Reply (two message) DHCPv6 message containing any delegated addresses, prefixes and/or any other information the server is configured to send. The server then returns the Advertise/Reply message to the router.
When the router receives the DHCPv6 Advertise/Reply message, it creates a Router Advertisement (RA) message that includes any autoconfiguration information necessary for the link and also embeds the DHCPv6 message in a DHCPv6 option within the body of the RA. The router then returns the RA as a unicast message response to the node that sent the RS.
In a two message exchange, the prefix delegation is completed when the node receives the RA. In a four message exchange, the reqeusting node can Decline any prefix delegations it does not wish to accept and/or send unicast Request messages in subsequent RSes to get a delegated prefix Reply message back from the router or routers of its choosing.
At any time after the initial RS/RA exchange, the node may need to issue a DHCPv6 Renew, Release or Rebind message, e.g., to extend address/prefix lifetimes. In that case, the node prepares a DHCPv6 message option and inserts it in an RS message which it then sends via unicast to the router. The router in turn processes the message the same as for DHCPv6 Solicit/Reply.
At any time after the initial RS/RA exchange, the DHCPv6 server may need to issue a DHCPv6 Reconfigure message. In that case, when the router receives the DHCPv6 Reconfigure message it prepares a unicast RA message with a DHCPv6 option that encodes the Reconfigure and sends the RA as an unsolicited unicast message to the node.
Using the DHCPv6 Option, the message itself includes an Identity Association for Prefix Delegation (IA_PD) option to request a prefix delegation. The DHCPv6 Device Unique IDentifier (DUID) provides the the identity of the requesting node, and the DHCPv6 transacation-id provides a unique identifier for matching RS and RA messages. Finally, the message can be protected using SEcure Neighbor Discovery (SEND) [RFC3971].
The IPv6ND function and DHCPv6 function are typically implemented in separate router modules. In that case, the IPv6ND function extracts the DHCPv6 message from the option included in the RS message and wraps it in IP/UDP headers. The source address in the IP header is set to the node's link-local address, and the source port in the UDP header is set to the port number associated with the IPv6ND function. The IPv6ND function then acts as a Lightweight DHCPv6 Relay Agent (LDRA) [RFC6221] to forward the message to the DHCPv6 relay or server function on-board the router.
The forwarded DHCPv6 message then traverses any additional relays on the reverse path until it reaches the DHCPv6 server. When the DHCPv6 server processes the message, it delegates any necessary resources and sends a Reply via the same relay agent path as had occurred on the reverse path so that the Reply will eventually arrive back at the IPv6ND function. The IPv6ND function then prepares an RA message with any autoconfiguration information associated with the link, embeds the DHCPv6 message body in an IPv6ND DHCPv6 option, and returns the message via unicast to the node that sent the RS.
In a preferred implementation, however, the IPv6ND and DHCPv6 functions could be co-located in the same module on the router. In that way the two functions would be coupled as though they were in fact a single unified function without the need for any LDRA processing.
The second method discussed in this document is the inclusion of PIO-X options in IPv6ND RS messages, as discussed in the following sections.
The PIO option for solicited prefix delegation is formatted exactly as specified in [RFC4861] except including the "X" bit as defined in [I-D.pioxfolks-6man-pio-exclusive-bit]. We refer to PIO options with the "X" bit set as "PIO-X" options. The format of the option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|X| Rsrvd1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PIO-X Option Format
[RFC4861]. The "X" bit is set to 1 if the prefix is to be provided for the node's own exclusive use. If "X" is set to 0, no statement is made about the prefix's exclusivity.
When a node that wishes to request an eXclusive prefix first comes onto the link, it creates a Router Solicitation (RS) message containing a PIO-X. It sets the Prefix Length to either the length of the prefix it wishes to receive or '0' (unspecified) if it will defer to the router's preference. The node then sets the Valid and Preferred Lifetimes to either its preferred values or '0' (unspecified) if it will defer to the router's preference. The node then sets the Prefix to either the prefix it wishes to receive, or '0' (unspecified) if it will defer to the router's preference. The node then sends the RS message either to the unicast address of a specific router on the link, or to the All-Routers multicast address.
When a router receives an RS message with a PIO-X option, if it is not configured to accept PIO-Xs in RS messages it returns a Router Advertisement (RA) message as normal and without including a PIO-X. By receiving the RA message with no PIO-X, the node can determine that the router does not recognize the option and/or does not support a PIO-X prefix delegation service. In this way, no harm will have come from the node including the PIO-X in the RS, and the function is fully backwards compatible.
When a router receives an RS message with a PIO-X, if it recognizes the option and can provide prefix delegation services it examines the fields in the message and selects a prefix to delegate to the node. If the PIO-X included a non-zero Prefix, the router delegates the node's preferred prefix if possible. Otherwise, the router selects a prefix to delegate to the node with length based on the node's Prefix Length. The router sets lifetimes matching the lifetimes requested by the node if possible, or shorter lifetimes if the node's requested lifetimes are too long. The router finally prepares a PIO-X containing this information and inserts it into an RA message to send back to the source of the RS.
Using the PIO-X, the option itself requests a prefix delegation. The RS message link-layer addresss can be used as the identity of the requesting node. The RS message SHOULD include a Nonce option [RFC3971] to provide a unique identifier for matching RS and RA messages. Finally, the message can be protected using SEND the same as for the DHCPv6 option [RFC3971].
Each router can implement a prefix delegation database management service of their own choosing, but an attractive alternative would be to use the already-existing DHCPv6 service as the back-end prefix management service. In this way, all communications between the router's link to the requesting node are via PIO-X RS/RA messaging. But, when the router receives an RS message with a PIO-X it can create a syntehsized DHCPv6 Solicit message to send to the DHCPv6 server. This can be done exactly the same as for the approach discussed in Section 2.4. In this way, the node on the link over which the PIO-X is advertised only ever sees RS/RA messages on the front end, and the router gets to use the mature and widely deployed DHCPv6 service for prefix management on the back end.
The third method entails and out-of-band messaging exchange sometimes known as a "network login" procedure. During the network login, the requesting node could have a multi-message exchange with the network to set the stage for the router eventually sending an RA message as discusssed in the following sections
In the out-of-band network login, the node signs into the network using, e.g., a login/password, a security certificate, etc. The node authenticates itself to the network, and can optionally have an iterative exchange to request certain aspects of the node's desired prefix delegation. The network then signals the node's first-hop router to prepare an RA message with a PIO-X option.
When a node that wishes to request a prefix delegation first comes onto the link, it engages in a network login session using some form of out-of-band messaging such as Layer 2 (L2) messaging. The session entails a security exchange where the node authenticates itself to the network and proves its authorization to receive its desired prefix. The network then signals the router to send an RA message with a PIO-X to the node, either unsolicited or in response to the node's RS message.
Using out-of-band messaging, the node engages in a (possibly) multi-message exchange where a request for a prefix delegation is conveyed. The node's link-layer addresss can be used as the identity of the requesting node. The out-of-band exchange provides a unique per-message identifier so that the node can correlate its message requests with the responses it gets back from the network. Finally, the message exchange itself contains security parameters for authenticating the requesting node.
The network login system and routers must be tightly coupled so that the network login can securely convey the reqesting node's identity to the router.
As for the PIO-X-based prefix delegation discussed in Section 3.4, DHCPv6 can be used as the back-end service for managing the prefix delegation database.
The IANA is instructed to assign an IPv6ND option Type value TBD for the DHCPv6 option.
The IANA is instructed to create a registry for the DHCPv6 option "Reserved" field so that future uses of bits in the field can be coordinated.
Security considerations for IPv6 Neighbor Discovery [RFC4861] and DHCPv6 [RFC3315][RFC3633] apply to this document.
SEcure Neighbor Discovery (SEND) [RFC3971] can provide authentication for the combined DHCPv6/IPv6ND messages with no need for additional securing mechanisms.
.
This work was motivated by discussions on the 6man and v6ops list. Those individuals who provided encouragement and critical review are acknowledged.
The following individuals provided useful comments that improved the document: Bernie Volz.
This work is aligned with the NASA Safe Autonomous Systems Operation (SASO) program under NASA contract number NNA16BD84C.
This work is aligned with the FAA as per the SE2025 contract number DTFAWA-15-D-00030.
This work is aligned with the Boeing Information Technology (BIT) MobileNet program and the Boeing Research & Technology (BR&T) enterprise autonomy program.
| [RFC3315] | Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003. |
| [RFC3633] | Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003. |
| [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. |
| [RFC8200] | Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017. |
| [I-D.pioxfolks-6man-pio-exclusive-bit] | Kline, E. and M. Abrahamsson, "IPv6 Router Advertisement Prefix Information Option eXclusive Flag", Internet-Draft draft-pioxfolks-6man-pio-exclusive-bit-02, March 2017. |
| [RFC3971] | Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005. |
| [RFC6221] | Miles, D., Ooghe, S., Dec, W., Krishnan, S. and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011. |