Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational January 26, 2018
Expires: July 30, 2018
IPv6 Neighbor Discovery Extensions for Prefix Delegation
draft-templin-6man-dhcpv6-ndopt-02.txt
Abstract
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 single unified autoconfiguration service.
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 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 July 30, 2018.
Copyright Notice
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
Templin Expires July 30, 2018 [Page 1]
Internet-Draft DHCPv6 Option for IPv6 ND January 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. DHCPv6 Options in IPv6 ND Messages . . . . . . . . . . . . . 3
2.1. The DHCPv6 Option . . . . . . . . . . . . . . . . . . . . 3
2.2. DHCPv6 Option Usage . . . . . . . . . . . . . . . . . . . 4
2.3. Implementation Considerations . . . . . . . . . . . . . . 5
3. PIO Options in RS Messages . . . . . . . . . . . . . . . . . 6
3.1. The PIOX Option . . . . . . . . . . . . . . . . . . . . . 6
3.2. PIOX Option Usage . . . . . . . . . . . . . . . . . . . . 7
3.3. Implementation Considerations . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
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].
Currently, at least two round-trip message exchanges are necessary in
order to perform the IPv6ND router discovery and DHCPv6 address/
prefix delegation functions. This document presents two possible
methods for providing a single unified autoconfiguration 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
managed addresses and prefixes (and, if the 'M' bit is set in the RA
message) it then sends a DHCPv6 Solicit message with Rapid Commit 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'
Templin Expires July 30, 2018 [Page 2]
Internet-Draft DHCPv6 Option for IPv6 ND January 2018
bit) this would result in twice as many channel access transactions
as necessary.
This document proposes two methods for combining these separate
operations into a single, unified exchange. The first method is
through definition of a new IPv6 ND option called the "DHCPv6 Option"
that combines the IPv6 ND router discovery and DHCPv6 managed
address/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 IPv6 ND and
DHCPv6 functions to work together to supply the client with all
needed configuration information in a single message exchange instead
of multiple.
The second method leverages the PIOX 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 PIOs in their RS messages for the purpose of
requesting prefix delegations from routers. The PIOX proposal
sugggests an unsolicited method of providing the node with the
prefix, whereby this document suggested a solicited method.
The following sections present considerations for nodes that employ
these approaches.
2. DHCPv6 Options in IPv6 ND Messages
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.
2.1. The DHCPv6 Option
The DHCPv6 option is a new IPv6 ND 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:
Templin Expires July 30, 2018 [Page 3]
Internet-Draft DHCPv6 Option for IPv6 ND January 2018
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
In this format, 'Type' and 'Length' are exactly as defined in
Section 4.6 of [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.
2.2. DHCPv6 Option Usage
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 with Rapid Commit. 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
Templin Expires July 30, 2018 [Page 4]
Internet-Draft DHCPv6 Option for IPv6 ND January 2018
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 a DHCPv6 Reply message containing any delegated
addresses, prefixes and/or any other information the server is
configured to send. The server then returns the Reply message to the
router.
When the router receives the DHCPv6 Reply message, it creates a
Router Advertisement (RA) message that includes any autoconfiguration
information necessary for the link and also embeds the Reply message
in a DHCPv6 option within the body of the RA. The router then
returns the RA as a unicast message reply to the node that sent the
RS.
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.
2.3. Implementation Considerations
The IPv6ND function and DHCPv6 function are typically implemented in
separate router modules. In that case, the IPv6 ND 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 IPv6 ND
function. The IPv6 ND 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
IPv6 ND function. The IPv6 ND function then prepares an RA message
with any autoconfiguration information associated with the link,
embeds the DHCPv6 message body in an IPv6 ND DHCPv6 option, and
returns the message via unicast to the node that sent the RS.
Templin Expires July 30, 2018 [Page 5]
Internet-Draft DHCPv6 Option for IPv6 ND January 2018
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.
3. PIO Options in RS Messages
The second method discussed in this document is the inclusion of PIO
options in IPv6ND RS messages, as discussed in the following
sections.
3.1. The PIOX Option
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 "PIOX" 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: PIOX Option Format
In this format, all feilds are exactly as defined in Section 4.6 of
[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.
Templin Expires July 30, 2018 [Page 6]
Internet-Draft DHCPv6 Option for IPv6 ND January 2018
3.2. PIOX Option Usage
When a node that wishes to request an eXclusive prefix first comes
onto the link, it creates a Router Solicitation (RS) message
containing a PIOX. 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 PIOX option, if it is not
configured to accept PIOXs in RS messages it returns a Router
Advertisement (RA) message as normal and without including a PIOX.
By receiving the RA message with no PIOX, the node can determine that
the router does not recognize the option and/or does not support a
PIOX prefix delegation service. In this way, no harm will have come
from the node including the PIOX in the RS, and the function is fully
backwards compatible.
When a router receives an RS message with a PIOX, 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 PIOX 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 PIOX
containing this information and inserts it into an RA message to send
back to the source of the RS.
3.3. Implementation Considerations
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 PIOX RS/RA messaging.
But, when the router receives an RS message with a PIOX 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.3. In this way, the node on the link over which the PIOX
is advertised only ever sees RS/RA messages on the front end, and the
Templin Expires July 30, 2018 [Page 7]
Internet-Draft DHCPv6 Option for IPv6 ND January 2018
router gets to use the mature and widely deployed DHCPv6 service for
prefix management on the back end.
4. IANA Considerations
The IANA is instructed to assign an IPv6 ND 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.
5. Security Considerations
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.
.
6. Acknowledgements
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.
7. References
Templin Expires July 30, 2018 [Page 8]
Internet-Draft DHCPv6 Option for IPv6 ND January 2018
7.1. Normative References
[RFC3315] Droms, R., Ed., 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, <https://www.rfc-editor.org/info/rfc3315>.
[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,
<https://www.rfc-editor.org/info/rfc3633>.
[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,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
7.2. Informative References
[I-D.pioxfolks-6man-pio-exclusive-bit]
Kline, E. and M. Abrahamsson, "IPv6 Router Advertisement
Prefix Information Option eXclusive Flag", draft-
pioxfolks-6man-pio-exclusive-bit-02 (work in progress),
March 2017.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221,
DOI 10.17487/RFC6221, May 2011,
<https://www.rfc-editor.org/info/rfc6221>.
Author's Address
Templin Expires July 30, 2018 [Page 9]
Internet-Draft DHCPv6 Option for IPv6 ND January 2018
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires July 30, 2018 [Page 10]