idnits 2.17.1 draft-templin-6man-dhcpv6-ndopt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 143: '...'Reserved' field MUST be set to 0 on t...' RFC 2119 keyword, line 144: '...e specifications MAY define new uses f...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 05, 2018) is 2303 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8200' is defined on line 278, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational January 05, 2018 5 Expires: July 9, 2018 7 The DHCPv6 Option for IPv6 Neighbor Discovery 8 draft-templin-6man-dhcpv6-ndopt-01.txt 10 Abstract 12 IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for 13 nodes to discover neighbors, routers, prefixes and other services on 14 the link. It also supports a manner of StateLess Address 15 AutoConfiguration (SLAAC). The Dynamic Host Configuration Protocol 16 for IPv6 (DHCPv6) specifies a service for the stateful delegation of 17 addresses and prefixes. 19 Currently, at least two round-trip message exchanges are necessary in 20 order to perform the IPv6ND router discovery and DHCPv6 address/ 21 prefix delegation functions. This document presents a protocol for 22 combining these two exchanges into a single exchange by joining the 23 two services into a single unified service. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 9, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. The DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 3 61 3. DHCPv6 Option Usage . . . . . . . . . . . . . . . . . . . . . 4 62 4. Implementation Considerations . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 IPv6 Neighbor Discovery (IPv6ND) [RFC4861] specifies a control 74 message set for nodes to discover neighbors, routers, prefixes and 75 other services on the link. It also supports a manner of StateLess 76 Address AutoConfiguration (SLAAC). The Dynamic Host Configuration 77 Protocol for IPv6 (DHCPv6) specifies a service for the stateful 78 delegation of addresses and prefixes [RFC3315][RFC3633]. 80 Currently, at least two round-trip message exchanges are necessary in 81 order to perform the IPv6ND router discovery and DHCPv6 address/ 82 prefix delegation functions. This document presents a protocol for 83 combining these two exchanges into a single exchange by joining the 84 two services into a single unified service. 86 When a node first comes onto the link, it sends a Router Solicitation 87 (RS) message to elicit a Router Advertisement (RA) message from one 88 or more routers for the link. If the node also needs to acquire 89 managed addresses and prefixes (and, if the 'M' bit is set in the RA 90 message) it then sends a DHCPv6 Solicit message with Rapid Commit to 91 elicit a Reply message from a DHCPv6 server that is authoritative for 92 the link. This two round-trip message exchange can add delay as well 93 as waste critical link bandwidth on low-end links (e.g., aeronautical 94 wireless links). While it is possible to conceive of starting both 95 round trip exchanges at the same time (i.e., under the leap-of-faith 96 assumption that the link supports DHCPv6 before examining the 'M' 97 bit) this would result in twice as many channel access transactions 98 as necessary. 100 This document proposes a new IPv6 ND option called the "DHCPv6 101 Option" that combines the IPv6 ND router discovery and DHCPv6 managed 102 address/prefix acquisition processes into a single message exchange. 103 Nodes include the DHCPv6 option in RS messages to solicit an RA 104 message with a DHCPv6 option in return. This allows the IPv6 ND and 105 DHCPv6 functions to work together to supply the client with all 106 needed configuration information in a single message exchange instead 107 of multiple. 109 The following sections present considerations for nodes that employ 110 the IPv6 ND DHCPv6 option. 112 2. The DHCPv6 Option 114 The DHCPv6 option is a new IPv6 ND option that simply embeds a 115 standard DHCPv6 message per section 6 of [RFC3315], beginning with 116 the 'msg-type' followed by the 'transaction-id' and all DHCPv6 117 'options'. The format of the option is as follows: 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Type = TBD | Length | Pad | Reserved | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | msg-type | transaction-id | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | | 127 . options . 128 . (variable) . 129 | | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Figure 1: IPv6 ND DHCPv6 Option Format 134 In this format, 'Type' and 'Length' are exactly as defined in 135 Section 4.6 of [RFC4861], 'Pad' encodes the number of trailing zero 136 octets (between 0 - 7) that appear at the end of the option to pad to 137 an integral number of 8-octets, 'Reserved' is included for alignment 138 and potential future use, and the rest of the option is exactly as 139 defined in Section 6 of [RFC3315]. The length of the full DHCPv6 140 message is determined by ((('Length' * 8) - 4) - 'Pad'), for a 141 maximum message length of 2044 octets. 143 The 'Reserved' field MUST be set to 0 on transmission and ignored on 144 reception. Future specifications MAY define new uses for these bits. 146 3. DHCPv6 Option Usage 148 When a node first comes onto the link, it creates a Router 149 Solicitation (RS) message containing a DHCPv6 option that embeds a 150 DHCPv6 Solicit message with Rapid Commit. The node then sends the RS 151 message either to the unicast address of a specific router on the 152 link, or to the All-Routers multicast address. 154 When a router receives an RS message with a DHCPv6 option, if it does 155 not recognize the option and/or does not employ a DHCPv6 relay agent 156 or server, it returns a Router Advertisement (RA) message as normal 157 and without including a DHCPv6 option. By receiving the RA message 158 with no DHCPv6 option, the node can determine that the router does 159 not recognize the option and/or does not support a DHCPv6 relay/ 160 server function. In this way, no harm will have come from the node 161 including the DHCPv6 option in the RS, and the function is fully 162 backwards compatible. 164 When a router receives an RS message with a DHCPv6 option, if it 165 recognizes the option and employs a DHCPv6 relay agent or server, it 166 extracts the DHCPv6 message from the RS message and forwards the 167 message to the DHCPv6 relay agent or server. When the DHCPv6 message 168 reaches a DHCPv6 server, the server processes the DHCPv6 Solicit 169 message and prepares a DHCPv6 Reply message containing any delegated 170 addresses, prefixes and/or any other information the server is 171 configured to send. The server then returns the Reply message to the 172 router. 174 When the router receives the DHCPv6 Reply message, it creates a 175 Router Advertisement (RA) message that includes any autoconfiguration 176 information necessary for the link and also embeds the Reply message 177 in a DHCPv6 option within the body of the RA. The router then 178 returns the RA as a unicast message reply to the node that sent the 179 RS. 181 At any time after the initial RS/RA exchange, the node may need to 182 issue a DHCPv6 Renew, Release or Rebind message, e.g., to extend 183 address/prefix lifetimes. In that case, the node prepares a DHCPv6 184 message option and inserts it in an RS message which it then sends 185 via unicast to the router. The router in turn processes the message 186 the same as for DHCPv6 Solicit/Reply. 188 At any time after the initial RS/RA exchange, the DHCPv6 server may 189 need to issue a DHCPv6 Reconfigure message. In that case, when the 190 router receives the DHCPv6 Reconfigure message it prepares a unicast 191 RA message with a DHCPv6 option that encodes the Reconfigure and 192 sends the RA as an unsolicited unicast message to the node. 194 4. Implementation Considerations 196 The IPv6ND function and DHCPv6 function are typically implemented in 197 separate router modules. In that case, the IPv6 ND function extracts 198 the DHCPv6 message from the option included in the RS message and 199 wraps it in IP/UDP headers. The source address in the IP header is 200 set to the node's link-local address, and the source port in the UDP 201 header is set to the port number associated with the IPv6 ND 202 function. The IPv6 ND function then acts as a Lightweight DHCPv6 203 Relay Agent (LDRA) [RFC6221] to forward the message to the DHCPv6 204 relay or server function on-board the router. 206 The forwarded DHCPv6 message then traverses any additional relays on 207 the reverse path until it reaches the DHCPv6 server. When the DHCPv6 208 server processes the message, it delegates any necessary resources 209 and sends a Reply via the same relay agent path as had occurred on 210 the reverse path so that the Reply will eventually arrive back at the 211 IPv6 ND function. The IPv6 ND function then prepares an RA message 212 with any autoconfiguration information associated with the link, 213 embeds the DHCPv6 message body in an IPv6 ND DHCPv6 option, and 214 returns the message via unicast to the node that sent the RS. 216 In a preferred implementation, however, the IPv6ND and DHCPv6 217 functions could be co-located in the same module on the router. In 218 that way the two functions would be coupled as though they were in 219 fact a single unified function without the need for any LDRA 220 processing. 222 5. IANA Considerations 224 The IANA is instructed to assign an IPv6 ND option Type value TBD for 225 the DHCPv6 option. 227 The IANA is instructed to create a registry for the DHCPv6 option 228 "Reserved" field so that future uses of bits in the field can be 229 coordinated. 231 6. Security Considerations 233 Security considerations for IPv6 Neighbor Discovery [RFC4861] and 234 DHCPv6 [RFC3315][RFC3633] apply to this document. 236 SEcure Neighbor Discovery (SEND) [RFC3971] can provide authentication 237 for the combined DHCPv6/IPv6ND messages with no need for additional 238 securing mechanisms. 240 . 242 7. Acknowledgements 244 This work was motivated by discussions on the 6man and v6ops list. 246 The following individuals provided useful comments that improved the 247 document: Bernie Volz. 249 This work is aligned with the NASA Safe Autonomous Systems Operation 250 (SASO) program under NASA contract number NNA16BD84C. 252 This work is aligned with the FAA as per the SE2025 contract number 253 DTFAWA-15-D-00030. 255 This work is aligned with the Boeing Information Technology (BIT) 256 MobileNet program and the Boeing Research & Technology (BR&T) 257 enterprise autonomy program. 259 8. References 261 8.1. Normative References 263 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 264 C., and M. Carney, "Dynamic Host Configuration Protocol 265 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 266 2003, . 268 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 269 Host Configuration Protocol (DHCP) version 6", RFC 3633, 270 DOI 10.17487/RFC3633, December 2003, 271 . 273 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 274 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 275 DOI 10.17487/RFC4861, September 2007, 276 . 278 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 279 (IPv6) Specification", STD 86, RFC 8200, 280 DOI 10.17487/RFC8200, July 2017, 281 . 283 8.2. Informative References 285 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 286 "SEcure Neighbor Discovery (SEND)", RFC 3971, 287 DOI 10.17487/RFC3971, March 2005, 288 . 290 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 291 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 292 DOI 10.17487/RFC6221, May 2011, 293 . 295 Author's Address 297 Fred L. Templin (editor) 298 Boeing Research & Technology 299 P.O. Box 3707 300 Seattle, WA 98124 301 USA 303 Email: fltemplin@acm.org