idnits 2.17.1 draft-templin-6man-dhcpv6-ndopt-06.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 198: '...'Reserved' field MUST be set to 0 on t...' RFC 2119 keyword, line 199: '...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 (September 17, 2018) is 2048 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8200' is defined on line 574, 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) == Outdated reference: A later version (-05) exists of draft-templin-6man-aeroaddr-02 Summary: 3 errors (**), 0 flaws (~~), 3 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 September 17, 2018 5 Expires: March 21, 2019 7 A Unified Stateful/Stateless Autoconfiguration Service for IPv6 8 draft-templin-6man-dhcpv6-ndopt-06.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 separate stateful autoconfiguration 17 service. This document presents IPv6ND extensions for providing a 18 unified stateful/stateless autoconfiguration service. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 21, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. DHCPv6 Options in IPv6 ND Messages . . . . . . . . . . . . . 4 56 2.1. The DHCPv6 Option . . . . . . . . . . . . . . . . . . . . 4 57 2.2. DHCPv6 Option Usage . . . . . . . . . . . . . . . . . . . 5 58 2.3. Stateful Autoconfiguration Requirements . . . . . . . . . 6 59 2.4. Implementation Considerations . . . . . . . . . . . . . . 6 60 3. PIO Options in RS Messages . . . . . . . . . . . . . . . . . 7 61 3.1. The PIO-X Option . . . . . . . . . . . . . . . . . . . . 7 62 3.2. PIO-X Option Usage . . . . . . . . . . . . . . . . . . . 8 63 3.3. Stateful Autoconfiguration Requirements . . . . . . . . . 8 64 3.4. Implementation Considerations . . . . . . . . . . . . . . 8 65 4. Embedded Prefix Assertion . . . . . . . . . . . . . . . . . . 9 66 4.1. Embedded Prefix Assertion . . . . . . . . . . . . . . . . 9 67 4.2. Embedded Prefix Usage . . . . . . . . . . . . . . . . . . 9 68 4.3. Stateful Autoconfiguration Requirements . . . . . . . . . 10 69 4.4. Implementation Considerations . . . . . . . . . . . . . . 10 70 5. Out-of-Band Network Login Messaging . . . . . . . . . . . . . 10 71 5.1. Out-of-Band Network Login . . . . . . . . . . . . . . . . 10 72 5.2. Out-of-Band Network Login Usage . . . . . . . . . . . . . 11 73 5.3. Stateful Autoconfiguration Requirements . . . . . . . . . 11 74 5.4. Implementation Considerations . . . . . . . . . . . . . . 11 75 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 10.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 IPv6 Neighbor Discovery (IPv6ND) [RFC4861] specifies a control 87 message set for nodes to discover neighbors, routers, prefixes and 88 other services on the link. It also supports a manner of StateLess 89 Address AutoConfiguration (SLAAC). The Dynamic Host Configuration 90 Protocol for IPv6 (DHCPv6) specifies a separate service for 91 delegation of prefixes, addresses and any other stateful information 92 [RFC3315][RFC3633]. This document presents IPv6ND extensions for 93 providing a unified stateful/stateless autoconfiguration service. 95 If the network can provide such a unified service, complex multi- 96 message procedures can be condensed into a single and concise message 97 exchange. This would ease network management as well as simplify 98 host and router operations. It would further accommodate both SLAAC 99 and DHCPv6 in a way that combines the best aspects of both. The 100 operating model is based on harnessing the IPv6 ND Router 101 Solicitation (RS) / Router Advertisement (RA) functions to provide 102 all stateless and stateful information in a single message exchange. 104 When a node first comes onto a link, it sends an RS to elicit an RA 105 from one or more routers for the link. If the node also needs to 106 acquire stateful information it then sends a DHCPv6 Solicit message 107 to elicit a Reply message from a DHCPv6 server. This two round-trip 108 message exchange can add delay as well as waste critical link 109 bandwidth on low-end links (e.g., 6LoWPAN, satellite communications, 110 aeronautical wireless, etc.). While it is possible to conceive of 111 starting both round trip exchanges at the same time, this would still 112 result in twice as many channel access transactions as necessary. 113 Moreover, the multicast nature of these messages could disturb other 114 nodes on the link, e.g., resulting in an unnecessary wakeup from 115 sleep mode. 117 This document proposes methods for combining stateless and stateful 118 operations into a single, unified exchange based on IPv6ND messaging 119 extensions. It notes that stateful exchanges should include: 121 o an explicit request for stateful information 123 o the identity of the requesting node 125 o a transaction ID that the requesting node can use to match replies 126 with their corresponding requests 128 o any security parameters necessary for the requesting node to 129 establish its authorization to receive stateful information 131 The first method is through definition of a new IPv6ND option called 132 the "DHCPv6 Option" that combines the IPv6ND router discovery and 133 DHCPv6 stateful processes into a single message exchange. Nodes 134 include the DHCPv6 option in RS messages to solicit an RA message 135 with a DHCPv6 option in return. This allows the IPv6ND and DHCPv6 136 functions to work together to supply the client with all needed 137 configuration information in a minimum number of messages. 139 The second method leverages the PIO-X proposal 140 [I-D.pioxfolks-6man-pio-exclusive-bit] where the router sets the "X 141 (eXclusive)" bit in an RA Prefix Information Option (PIO) to inform 142 the node that the prefix is provided for the node's own exclusive 143 use. This document permits nodes to include PIO-Xs in their RS 144 messages for the purpose of soliciting stateful autoconfiguration 145 information from routers. 147 The third method entails the encoding of a prefix in the IPv6 link- 148 local source address of the RS message. If the node is pre- 149 configured with the prefix that it will solicit from the network, and 150 if the network has a way of accepting the node's prefix assertion 151 without the threat of spoofing, the network can then delegate the 152 prefix and establish the necessary routing information. 154 The fourth method uses out-of-band messaging for the node to request 155 stateful information outside of the scope of IPv6ND messaging. The 156 out-of-band messaging could entail some sort of network login process 157 (e.g., through Layer-2 (L2) messaging, etc.). 159 The following sections present considerations for nodes that employ 160 these approaches. 162 2. DHCPv6 Options in IPv6 ND Messages 164 The first method entails the inclusion of DHCPv6 messages within 165 IPv6ND RS and RA messages, as discussed in the following sections. 167 2.1. The DHCPv6 Option 169 The DHCPv6 option is a new IPv6ND option that simply embeds a 170 standard DHCPv6 message per section 6 of [RFC3315], beginning with 171 the 'msg-type' followed by the 'transaction-id' and all DHCPv6 172 'options'. The format of the option is as follows: 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Type = TBD | Length | Pad | Reserved | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | msg-type | transaction-id | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | | 182 . options . 183 . (variable) ................... 184 | . Padding (0-7) . 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 1: IPv6 ND DHCPv6 Option Format 189 In this format, 'Type' and 'Length' are exactly as defined in 190 Section 4.6 of [RFC4861], 'Pad' is a 3-bit integer that encodes the 191 padding length, 'Reserved' is included for alignment and future use, 192 and the rest of the option is formatted as specified in Section 6 of 193 [RFC3315] except with trailing null padding added as necessary for 8 194 octet alignment. The length of the full DHCPv6 message is determined 195 by ((('Length' * 8) - 4) - 'Pad'), for a maximum message length of 196 2036 octets. 198 The 'Reserved' field MUST be set to 0 on transmission and ignored on 199 reception. Future specifications MAY define new uses for these bits. 201 2.2. DHCPv6 Option Usage 203 When a node first comes onto the link, it creates an RS message 204 containing a DHCPv6 option that embeds a DHCPv6 Solicit message. The 205 Solicit may include a Rapid Commit option if a two-message exchange 206 (i.e., instead of four) is required. The node then sends the RS 207 message either to the unicast address of a specific router on the 208 link, or to the all-routers multicast address. 210 When a router receives an RS message with a DHCPv6 option, if it does 211 not recognize the option and/or does not employ a DHCPv6 relay agent 212 or server, it returns an RA message as normal with any stateless 213 configuration information and without including a DHCPv6 option. By 214 receiving the RA message with no DHCPv6 option, the node can 215 determine that the router does not recognize the option and/or does 216 not support a DHCPv6 relay/server function. In this way, no harm 217 will have come from the node including the DHCPv6 option in the RS, 218 and the function is fully backwards compatible. 220 When a router receives an RS message with a DHCPv6 option, if it 221 recognizes the option and employs a DHCPv6 relay agent or server, it 222 extracts the encapsulated DHCPv6 message and forwards it to the relay 223 agent or server. When the DHCPv6 message reaches a DHCPv6 server, 224 the server processes the DHCPv6 Solicit message and prepares either 225 an Advertise (four message) or Reply (two message) DHCPv6 message 226 containing any delegated addresses, prefixes and/or any other 227 information the server is configured to send. The server then 228 returns the Advertise/Reply message to the router. 230 When the router receives the DHCPv6 Advertise/Reply message, it 231 creates a Router Advertisement (RA) message that includes any 232 autoconfiguration information necessary for the link and also embeds 233 the DHCPv6 message in a DHCPv6 option within the body of the RA. The 234 router then returns the RA as a unicast message response to the node 235 that sent the RS. 237 In a two message exchange, the stateless/stateful exchange is 238 completed when the node receives the RA. In a four message exchange, 239 the requesting node can Decline any stateful information it does not 240 wish to accept and/or send unicast Request options in subsequent RSes 241 to get RA messages with Reply options back from the router or routers 242 of its choosing. 244 At any time after the initial RS/RA exchange, the node may need to 245 issue DHCPv6 Renew, Release or Rebind messages to manage address/ 246 prefix lifetimes. In that case, the node prepares a DHCPv6 message 247 option and inserts it in an RS message which it then sends via 248 unicast to the router. The router in turn processes the message the 249 same as for DHCPv6 Solicit/Reply. 251 At any time after the initial RS/RA exchange, the DHCPv6 server may 252 need to issue a DHCPv6 Reconfigure message. In that case, when the 253 router receives the DHCPv6 Reconfigure message it prepares a unicast 254 RA message with a DHCPv6 option that encodes the Reconfigure and 255 sends the RA as an unsolicited unicast message to the node. 257 2.3. Stateful Autoconfiguration Requirements 259 Using the DHCPv6 Option, the message itself includes sub-options to 260 request stateful information. The DHCPv6 Device Unique IDentifier 261 (DUID) provides the identity of the requesting node, and the DHCPv6 262 transaction-id provides a unique identifier for matching RS and RA 263 messages. Finally, the message can be protected using SEcure 264 Neighbor Discovery (SEND) [RFC3971]. 266 2.4. Implementation Considerations 268 The IPv6ND and DHCPv6 functions are typically implemented in separate 269 router modules. In that case, the IPv6ND function extracts the 270 DHCPv6 message from the option included in the RS message and wraps 271 it in IP/UDP headers with the same addresses and port numbers the 272 soliciting node would have used had it send an ordinary IP/UDP/DHCPv6 273 message. The IPv6ND function then acts as a Lightweight DHCPv6 Relay 274 Agent (LDRA) [RFC6221] to forward the message to the DHCPv6 relay or 275 server function on-board the router. 277 The forwarded DHCPv6 message then traverses any additional relays on 278 the reverse path until it reaches the DHCPv6 server. When the DHCPv6 279 server processes the message, it delegates any necessary resources 280 and returns a Reply via the same relay agent path as had occurred on 281 the reverse path so that the Reply will eventually arrive back at the 282 IPv6ND function. The IPv6ND function then prepares an RA message 283 with any autoconfiguration information associated with the link, 284 embeds the DHCPv6 message body in an IPv6ND DHCPv6 option, and 285 returns the message via unicast to the node that sent the RS. 287 In a preferred implementation, however, the IPv6ND and DHCPv6 288 functions could be co-located in the same module on the router. In 289 that way the two functions would be coupled as though they were in 290 fact a single unified function without the need for any LDRA 291 processing. 293 3. PIO Options in RS Messages 295 The second method entails the inclusion of Prefix Information Options 296 (PIOs) in IPv6ND RS messages, as discussed in the following sections. 298 3.1. The PIO-X Option 300 PIOs for stateful autoconfiguration are formatted exactly as 301 specified in [RFC4861] except including the "X" bit as defined in 302 [I-D.pioxfolks-6man-pio-exclusive-bit]. We refer to PIOs with the 303 "X" bit set as "PIO-X" options. The format of the option is as 304 follows: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Length | Prefix Length |L|A|R|X| Rsrvd1| 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Valid Lifetime | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Preferred Lifetime | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Reserved2 | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 + + 319 | | 320 + Prefix + 321 | | 322 + + 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 2: PIO-X Option Format 328 In this format, all fields are exactly as defined in Section 4.6 of 329 [RFC4861]. The "X" bit is set to 1 if the prefix is to be provided 330 for the node's own exclusive use. If "X" is set to 0, no statement 331 is made about the prefix's exclusivity. 333 3.2. PIO-X Option Usage 335 When a node that wishes to request an eXclusive prefix first comes 336 onto the link, it creates an RS message containing a PIO-X. It sets 337 the Prefix Length to either the length of the prefix it wishes to 338 receive or '0' (unspecified) if it will defer to the router's 339 preference. The node then sets the Valid and Preferred Lifetimes to 340 either its preferred values or '0' (unspecified) if it will defer to 341 the router's preference. The node then sets the Prefix to either the 342 prefix it wishes to receive, or '0' (unspecified) if it will defer to 343 the router's preference. The node then sends the RS message either 344 to the unicast address of a specific router on the link, or to the 345 all-routers multicast address. 347 When a router receives an RS message with a PIO-X, if it is not 348 configured to accept PIO-Xs in RS messages it returns an RA message 349 as normal and without including a PIO-X. By receiving the RA message 350 with no PIO-X, the node can determine that the router does not 351 recognize the option and/or does not support a PIO-X service. In 352 this way, no harm will have come from the node including the PIO-X in 353 the RS, and the function is fully backwards compatible. 355 When a router receives an RS message with a PIO-X, if it is 356 configured to accept the option and can provide stateful 357 autoconfiguration services it examines the fields in the message and 358 selects a prefix to delegate to the node. If the PIO-X included a 359 specific Prefix, the router delegates the node's preferred prefix if 360 possible. Otherwise, the router selects a prefix to delegate to the 361 node with length based on the node's Prefix Length. The router sets 362 lifetimes matching the lifetimes requested by the node if possible, 363 or shorter lifetimes if the node's requested lifetimes are too long. 364 The router finally prepares a PIO-X containing this information and 365 inserts it into an RA message to send back to the source of the RS. 367 3.3. Stateful Autoconfiguration Requirements 369 Using the PIO-X, the option itself requests stateful 370 autoconfiguration information. The RS message link-layer address can 371 be used as the identity of the requesting node. The RS message can 372 include a Nonce option [RFC3971] to provide a transaction identifier 373 for matching RS and RA messages. Finally, the message can be 374 protected using SEND the same as for the DHCPv6 option. 376 3.4. Implementation Considerations 378 Each router can implement a stateful database management service of 379 their own choosing, but a functional alternative would be to use the 380 standard DHCPv6 service as the back-end management service. In this 381 way, all communications between the router's link to the requesting 382 node are via PIO-X RS/RA messaging. But, when the router receives an 383 RS message with a PIO-X it can create a synthesized DHCPv6 Solicit 384 message to send to the DHCPv6 server. This can be done in the same 385 way as for the approach discussed in Section 2.4. In this way, the 386 node on the link over which the PIO-X is advertised only ever sees 387 RS/RA messages on the front end, and the router gets to use the 388 DHCPv6 service for stateful autoconfiguration management on the back 389 end. 391 Note: In its current form, the PIO-X approach supports only prefix 392 delegation and does not support other stateful configuration 393 services. 395 4. Embedded Prefix Assertion 397 The third method entails a simple RS/RA exchange with no additional 398 options where the node asserts a prefix by embedding the prefix in 399 the source address of the RS message. The following sections provide 400 further details. 402 4.1. Embedded Prefix Assertion 404 In this method, the node is pre-provisioned with the prefix it will 405 use on its downstream networks (e.g., through network management, 406 manual configuration, etc.). To invoke this method, the node 407 includes its pre-provisioned prefix in the link-local source address 408 of its RS message according to the AERO address format 409 [I-D.templin-6man-aeroaddr]. For example, if the node is pre- 410 provisioned with the prefix 2001:db8:1000:2000, it creates its IPv6 411 link-local source address as fe80::2001:db8:1000:2000. 413 4.2. Embedded Prefix Usage 415 When a node that wishes to assert a prefix first comes onto the link, 416 it statelessly configures an AERO address based on its pre- 417 provisioned prefix. The node then includes the AERO address as the 418 source address of a standard RS message. If a router that receives 419 the RS message has a way of verifying that the node is authorized to 420 receive the solicited prefix, the router injects the prefix into the 421 routing system and returns a standard RA message. When the node 422 receives the RA message, it then has assurance that the proper 423 routing state has been established. The node also examines the 424 lifetimes in the RA message as guidance for when subsequent RS/RA 425 exchanges are necessary to keep the state alive. 427 4.3. Stateful Autoconfiguration Requirements 429 Using embedded prefix assertion, the network must have some way of 430 determining the node's authority to assert its claimed prefix. This 431 could be, e.g., through examination of the link-layer source address 432 of the RS message. The network must also have some way of knowing 433 the node's claimed prefix length, as the length cannot be conveyed in 434 the RS message. If necessary, the exchange can also include some 435 form of transaction ID, e.g., by including a Nonce option in the RS. 436 Finally, the exchange can be protected using SEND the same as for the 437 previous two methods. 439 4.4. Implementation Considerations 441 This method can be conducted using standard RS/RA messages with no 442 extra options added to either message. It entails an administrative 443 assignment of the node's AERO address to the upstream interface over 444 which it will send the RS. When the router receives the standard RS 445 message, it statelessly derives the node's prefix from the AERO 446 address and injects the prefix into the routing system. The router 447 then returns a standard RA message. 449 When the router returns the RA message, if it is configured to do so 450 it can include a PIO-X option as discussed in Section 3.1. The PIO-X 451 option includes prefix lifetimes and the prefix length. This 452 "hybrid" combination of methods two and three could be useful in some 453 deployment scenarios. 455 As for the PIO-X-based autoconfiguration service discussed in 456 Section 3.4, DHCPv6 can be used as the back-end service for managing 457 the stateful autoconfiguration database. 459 5. Out-of-Band Network Login Messaging 461 The fourth method entails an out-of-band messaging exchange sometimes 462 known as a "network login" procedure. During the network login, the 463 requesting node could have an out-of-band messaging exchange with the 464 network to set the stage for the router eventually sending an RA 465 message as discussed in the following sections 467 5.1. Out-of-Band Network Login 469 In the out-of-band network login, the node signs into the network 470 using, e.g., a login/password, a security certificate, etc. The node 471 authenticates itself to the network, and can optionally have an 472 iterative exchange to request certain aspects of the node's desired 473 stateful autoconfiguration information. The first-hop router is then 474 signaled to prepare an RA message to return to the node, i.e., either 475 through some out-of-band signaling or through the node sending an RS 476 message. 478 5.2. Out-of-Band Network Login Usage 480 When a node that wishes to request stateful autoconfiguration first 481 comes onto the link, it engages in a network login session using some 482 form of out-of-band messaging such as Layer-2 (L2) messaging. The 483 session entails a security exchange where the node authenticates 484 itself to the network and proves its authorization to receive the 485 autoconfiguration information. The network then signals the router 486 to send an RA message to the node, either unsolicited or in response 487 to the node's RS message. 489 5.3. Stateful Autoconfiguration Requirements 491 Using out-of-band messaging, the node engages in an iterative 492 exchange where a request for stateful autoconfiguration information 493 is conveyed. The exchange includes an identity for the requesting 494 node and provides a unique per-message identifier so that the node 495 can correlate its message requests with the responses it gets back 496 from the network. Finally, the message exchange itself contains 497 security parameters for authenticating the requesting node. 499 5.4. Implementation Considerations 501 The network login system and routers must be tightly coupled so that 502 the network login can securely convey the requesting node's identity 503 to the router. 505 As for the PIO-X-based autoconfiguration service discussed in 506 Section 3.4, DHCPv6 can be used as the back-end service for managing 507 the stateful autoconfiguration database. 509 6. Implementation Status 511 A prototype of the approach discussed in Section 2 has been 512 implemented as extensions to the OpenVPN open source software 513 distribution. 515 7. IANA Considerations 517 The IANA is instructed to assign an IPv6ND option Type value TBD for 518 the DHCPv6 option. 520 The IANA is instructed to create a registry for the DHCPv6 option 521 "Reserved" field (with no initial assignments) so that future uses of 522 the field can be coordinated. The field is to be managed as a 523 "flags" field and not a "value" field. 525 8. Security Considerations 527 Security considerations for IPv6 Neighbor Discovery [RFC4861] and 528 DHCPv6 [RFC3315][RFC3633] apply to this document. 530 SEcure Neighbor Discovery (SEND) [RFC3971] can provide authentication 531 for RS/RA exchanges with no need for additional securing mechanisms. 533 9. Acknowledgements 535 This work was motivated by discussions on the 6man and v6ops list. 536 Those individuals who provided encouragement and critical review are 537 acknowledged. 539 The following individuals provided useful comments that improved the 540 document: Ron Bonica, Bernie Volz. 542 The following individuals developed IPv6ND and DHCPv6 extensions for 543 OpenVPN: Kyle Bae, Wayne Benson, Eric Yeh. 545 This work is aligned with the NASA Safe Autonomous Systems Operation 546 (SASO) program under NASA contract number NNA16BD84C. 548 This work is aligned with the FAA as per the SE2025 contract number 549 DTFAWA-15-D-00030. 551 This work is aligned with the Boeing Information Technology (BIT) 552 MobileNet program and the Boeing Research & Technology (BR&T) 553 enterprise autonomy program. 555 10. References 557 10.1. Normative References 559 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 560 C., and M. Carney, "Dynamic Host Configuration Protocol 561 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 562 2003, . 564 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 565 Host Configuration Protocol (DHCP) version 6", RFC 3633, 566 DOI 10.17487/RFC3633, December 2003, 567 . 569 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 570 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 571 DOI 10.17487/RFC4861, September 2007, 572 . 574 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 575 (IPv6) Specification", STD 86, RFC 8200, 576 DOI 10.17487/RFC8200, July 2017, 577 . 579 10.2. Informative References 581 [I-D.pioxfolks-6man-pio-exclusive-bit] 582 Kline, E. and M. Abrahamsson, "IPv6 Router Advertisement 583 Prefix Information Option eXclusive Flag", draft- 584 pioxfolks-6man-pio-exclusive-bit-02 (work in progress), 585 March 2017. 587 [I-D.templin-6man-aeroaddr] 588 Templin, F., "The AERO Address", draft-templin-6man- 589 aeroaddr-02 (work in progress), June 2018. 591 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 592 "SEcure Neighbor Discovery (SEND)", RFC 3971, 593 DOI 10.17487/RFC3971, March 2005, 594 . 596 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 597 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 598 DOI 10.17487/RFC6221, May 2011, 599 . 601 Author's Address 603 Fred L. Templin (editor) 604 Boeing Research & Technology 605 P.O. Box 3707 606 Seattle, WA 98124 607 USA 609 Email: fltemplin@acm.org