idnits 2.17.1 draft-templin-6man-dhcpv6-ndopt-10.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 197: '...'Reserved' field MUST be set to 0 on t...' RFC 2119 keyword, line 198: '...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 (June 30, 2020) is 1367 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8200' is defined on line 557, but no explicit reference was found in the text == Outdated reference: A later version (-99) exists of draft-templin-6man-omni-interface-26 Summary: 1 error (**), 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 June 30, 2020 5 Expires: January 1, 2021 7 A Unified Stateful/Stateless Configuration Service for IPv6 8 draft-templin-6man-dhcpv6-ndopt-10 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), while the Dynamic Host Configuration 16 Protocol for IPv6 (DHCPv6) specifies a separate stateful service. 17 This document presents IPv6ND extensions for providing a unified 18 stateful/stateless configuration 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 January 1, 2021. 37 Copyright Notice 39 Copyright (c) 2020 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 Provisioning Requirements . . . . . . . . . . . 6 59 2.4. Implementation Considerations . . . . . . . . . . . . . . 7 60 3. PIO Options in RS Messages . . . . . . . . . . . . . . . . . 7 61 3.1. The PIO Option in RS Messages . . . . . . . . . . . . . . 7 62 3.2. PIO Option Usage . . . . . . . . . . . . . . . . . . . . 7 63 3.3. Stateful Provisioning 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 Provisioning Requirements . . . . . . . . . . . 9 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 . . . . . . . . . . . . . 10 73 5.3. Stateful Provisioning Requirements . . . . . . . . . . . 11 74 5.4. Implementation Considerations . . . . . . . . . . . . . . 11 75 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 10.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 IPv6 Neighbor Discovery (IPv6ND) [RFC4861] specifies a control 88 message set for nodes to discover neighbors, routers, prefixes and 89 other services on the link. It also supports a manner of StateLess 90 Address AutoConfiguration (SLAAC). The Dynamic Host Configuration 91 Protocol for IPv6 (DHCPv6) specifies a separate service for 92 delegation of prefixes, addresses and any other stateful information 93 [RFC8415]. This document presents IPv6ND extensions for providing a 94 unified stateful/stateless configuration service. 96 If the network can provide such a unified service, multi-message 97 procedures can be condensed into a single and concise message 98 exchange. This would ease network management as well as simplify 99 host and router operations. It would further accommodate both 100 stateless and stateful services in a way that combines the best 101 aspects of both. The operating model is based on harnessing the IPv6 102 ND Router Solicitation (RS) / Router Advertisement (RA) functions to 103 provide all configuration information in a single message exchange. 105 When a node first comes onto a link, it sends an RS to elicit an RA 106 from one or more routers for the link. If the node also needs to 107 acquire stateful information it then sends a DHCPv6 Solicit message 108 to elicit a Reply message from a DHCPv6 server. This two round-trip 109 message exchange can add delay as well as waste critical link 110 bandwidth on low-end links (e.g., 6LoWPAN, satellite communications, 111 aeronautical wireless, etc.). While it is possible to start both 112 round trip exchanges at the same time, this would still result in 113 twice as many channel access transactions as necessary. Moreover, 114 the multicast nature of these messages could disturb other nodes on 115 the link, e.g., resulting in an unnecessary wakeup from sleep mode. 117 This document proposes methods for combining all stateless and 118 stateful configuration operations into a single, unified exchange 119 based on IPv6ND messaging extensions. It notes that stateful 120 exchanges should include: 122 o an explicit request for stateful information 124 o the identity of the requesting node 126 o a transaction identification that the requesting node can use to 127 match replies with their corresponding requests 129 o any security parameters necessary for the requesting node to 130 establish its authorization to receive stateful information 132 The first method is through definition of a new IPv6ND option called 133 the "DHCPv6 Option" that combines the IPv6ND router discovery and 134 DHCPv6 stateful processes into a single message exchange. Nodes 135 include the DHCPv6 option in RS messages to solicit an RA message 136 with a DHCPv6 option in return. This allows the IPv6ND and DHCPv6 137 functions to work together to supply the client with all needed 138 configuration information in a minimum number of messages. 140 The second method proposes the inclusion of Prefix Information 141 Options (PIOs) in RS messages for the purpose of soliciting stateful 142 information. [I-D.naveen-slaac-prefix-management] discusses the 143 maintenance and management functions required for supporting the 144 operation. 146 The third method entails the encoding of a prefix in the IPv6 link- 147 local source address of the RS message. If the node is pre- 148 configured with the prefix that it will solicit from the network, and 149 if the network has a way of accepting the node's prefix assertion 150 without the threat of spoofing, the network can then delegate the 151 prefix and establish the necessary routing information. 153 The fourth method uses out-of-band messaging for the node to request 154 stateful information outside of the scope of IPv6ND messaging. The 155 out-of-band messaging could entail some sort of network login process 156 (e.g., through Layer-2 (L2) messaging, etc.). 158 The following sections present considerations for nodes that employ 159 these approaches. 161 2. DHCPv6 Options in IPv6 ND Messages 163 The first method entails the inclusion of DHCPv6 messages within 164 IPv6ND RS and RA messages, as discussed in the following sections. 166 2.1. The DHCPv6 Option 168 The DHCPv6 option is a new IPv6ND option that simply embeds a 169 standard DHCPv6 message per section 6 of [RFC8415], beginning with 170 the 'msg-type' followed by the 'transaction-id' and all DHCPv6 171 'options'. The format of the option is as follows: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Type = TBD | Length | Pad | Reserved | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | msg-type | transaction-id | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | | 181 . options . 182 . (variable) ................... 183 | . Padding (0-7) . 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Figure 1: IPv6 ND DHCPv6 Option Format 188 In this format, 'Type' and 'Length' are exactly as defined in 189 Section 4.6 of [RFC4861], 'Pad' is a 3-bit integer that encodes the 190 padding length, 'Reserved' is included for alignment and future use, 191 and the rest of the option is formatted as specified in Section 6 of 192 [RFC8415] except with trailing null padding added as necessary for 8 193 octet alignment. The length of the full DHCPv6 message is determined 194 by ((('Length' * 8) - 4) - 'Pad'), for a maximum message length of 195 2036 octets. 197 The 'Reserved' field MUST be set to 0 on transmission and ignored on 198 reception. Future specifications MAY define new uses for these bits. 200 2.2. DHCPv6 Option Usage 202 When a node first comes onto the link, it creates an RS message 203 containing a DHCPv6 option that embeds a DHCPv6 Solicit message. The 204 Solicit may include a Rapid Commit option if a two-message exchange 205 (i.e., instead of four) is required. The RS message may also include 206 a Nonce option to provide an extended transaction identifier 207 [RFC3971]. The node then sends the RS message either to the unicast 208 address of a specific router on the link, or to the all-routers 209 multicast address. 211 When a router receives an RS message with a DHCPv6 option, if it does 212 not recognize the option and/or does not employ a DHCPv6 relay agent 213 or server, it returns an RA message as normal with any stateless 214 configuration information and without including a DHCPv6 option. By 215 receiving the RA message with no DHCPv6 option, the node can 216 determine that the router does not recognize the option and/or does 217 not support a DHCPv6 relay/server function. In this way, no harm 218 will have come from the node including the DHCPv6 option in the RS, 219 and the function is fully backwards compatible. 221 When a router receives an RS message with a DHCPv6 option, if it 222 recognizes the option and employs a DHCPv6 relay agent or server, it 223 extracts the encapsulated DHCPv6 message and forwards it to the relay 224 agent or server. When the DHCPv6 message reaches a DHCPv6 server, 225 the server processes the DHCPv6 Solicit message and prepares either 226 an Advertise (four message) or Reply (two message) DHCPv6 message 227 containing any delegated addresses, prefixes and/or any other 228 information the server is configured to send. The server then 229 returns the Advertise/Reply message to the router. 231 When the router receives the DHCPv6 Advertise/Reply message, it 232 creates a Router Advertisement (RA) message that includes any 233 autoconfiguration information necessary for the link and also embeds 234 the DHCPv6 message in a DHCPv6 option within the body of the RA. 235 (The RA also echos the Nonce value if a Nonce was included in the RS 236 message.) The router then returns the RA as a unicast message 237 response to the node that sent the RS. 239 In a two message exchange, the stateless/stateful exchange is 240 completed when the node receives the RA. In a four message exchange, 241 the requesting node can Decline any stateful information it does not 242 wish to accept and/or send unicast Request options in subsequent RSes 243 to get RA messages with Reply options back from the router or routers 244 of its choosing. 246 At any time after the initial RS/RA exchange, the node may need to 247 issue DHCPv6 Renew, Release or Rebind messages to manage address/ 248 prefix lifetimes. In that case, the node prepares a DHCPv6 message 249 option and inserts it in an RS message which it then sends via 250 unicast to the router. The router in turn processes the message the 251 same as for DHCPv6 Solicit/Reply. 253 At any time after the initial RS/RA exchange, the DHCPv6 server may 254 need to issue a DHCPv6 Reconfigure message. In that case, when the 255 router receives the DHCPv6 Reconfigure message it prepares a unicast 256 RA message with a DHCPv6 option that encodes the Reconfigure and 257 sends the RA as an unsolicited unicast message to the node. The node 258 then follows the DHCPv6 client procedures for processing and 259 responding to Reconfigure messages. 261 At any time after the initial RS/RA exchange, the router can initiate 262 an unsolicited RA/Reply, e.g., to cause the node to update its 263 configuration information quickly. In this method, the router sends 264 a synthesized DHCPv6 Renew or Information-request message that 265 induces the server to return a DHCPv6 Reply. The message includes 266 the same DHCPv6 transaction-id and IPv6 ND Nonce values that the 267 router had echoed in its initial Reply. The server then wraps the 268 Reply message in the body of an RA message, and sends the unsolicited 269 RA/Reply. When the node receives the unsolicited RA/Reply message, 270 it matches the transaction-id and Nonce values with the initial RA/ 271 Reply it had received from the router. If the identification 272 information matches, the node processes the message and initiates a 273 new RS/RA exchange if necessary; otherwise it drops the message. 275 2.3. Stateful Provisioning Requirements 277 Using the DHCPv6 Option, the message itself includes sub-options to 278 request stateful information. The DHCPv6 Device Unique IDentifier 279 (DUID) provides the identity of the requesting node, and the DHCPv6 280 transaction-id and IPv6 ND Nonce provide a unique identifier for 281 matching RS and RA messages. Finally, the message can be protected 282 using SEcure Neighbor Discovery (SEND) [RFC3971]. 284 2.4. Implementation Considerations 286 The IPv6ND and DHCPv6 functions are typically implemented in separate 287 router modules. In that case, the IPv6ND function extracts the 288 DHCPv6 message from the option included in the RS message and wraps 289 it in IP/UDP headers with the same addresses and port numbers the 290 soliciting node would have used had it send an ordinary IP/UDP/DHCPv6 291 message. The IPv6ND function then acts as a Lightweight DHCPv6 Relay 292 Agent (LDRA) [RFC6221] to forward the message to the DHCPv6 relay or 293 server function on-board the router. 295 The forwarded DHCPv6 message then traverses any additional relays on 296 the reverse path until it reaches the DHCPv6 server. When the DHCPv6 297 server processes the message, it delegates any necessary resources 298 and returns a Reply via the same relay agent path as had occurred on 299 the reverse path so that the Reply will eventually arrive back at the 300 IPv6ND function. The IPv6ND function then prepares an RA message 301 with any autoconfiguration information associated with the link, 302 embeds the DHCPv6 message body in an IPv6ND DHCPv6 option, and 303 returns the message via unicast to the node that sent the RS. 305 In an ideal implementation, the IPv6ND and DHCPv6 functions could be 306 co-located in the same module on the router. In that way the two 307 functions would be coupled as though they were in fact a single 308 unified function without the need for any LDRA processing. 310 3. PIO Options in RS Messages 312 The second method entails the inclusion of Prefix Information Options 313 (PIOs) in IPv6ND RS messages, as discussed in the following sections. 315 3.1. The PIO Option in RS Messages 317 This document proposes the inclusion of PIOs in RS messages to 318 solicit and maintain prefixes that are delegated in subsequent RA 319 messages. Prefix management is performed as discussed in 320 [I-D.naveen-slaac-prefix-management] (an alternate prefix management 321 proposal based on unsolicited advertisements with special flag 322 settings is found in [I-D.pioxfolks-6man-pio-exclusive-bit]). 324 3.2. PIO Option Usage 326 When a node that wishes to request a prefix delegation first comes 327 onto the link, it creates an RS message containing a PIO. It sets 328 the Prefix Length to either the length of the prefix it wishes to 329 receive or '0' (unspecified) if it will defer to the router's 330 preference. The node then sets the Valid and Preferred Lifetimes to 331 either its preferred values or '0' (unspecified) if it will defer to 332 the router's preference. The node then sets the Prefix to either the 333 prefix it wishes to receive, or '0' (unspecified) if it will defer to 334 the router's preference. The node then sends the RS message either 335 to the unicast address of a specific router on the link, or to the 336 all-routers multicast address. 338 When a router receives an RS message with a PIO, if it is not 339 configured to accept PIOs in RS messages it returns an RA message as 340 normal and without including a PIO. By receiving the RA message with 341 no PIO, the node can determine that the router does not recognize the 342 option and/or does not support an IPv6ND-based prefix delegation 343 service. In this way, no harm will have come from the node including 344 the PIO in the RS, and the function is fully backwards compatible. 346 When a router receives an RS message with a PIO, if it is configured 347 to accept the option and can provide prefix delegation services it 348 examines the fields in the message and selects a prefix to delegate 349 to the node. If the PIO included a specific Prefix, the router 350 delegates the node's preferred prefix if possible. Otherwise, the 351 router selects a prefix to delegate to the node with length based on 352 the node's Prefix Length. The router sets lifetimes matching the 353 lifetimes requested by the node if possible, or shorter lifetimes if 354 the node's requested lifetimes are too long. The router finally 355 prepares a PIO containing this information and inserts it into an RA 356 message to send back to the source of the RS. 358 3.3. Stateful Provisioning Requirements 360 Using the PIO in RS messages, the option itself requests stateful 361 information. The RS message link-layer address can be used as the 362 identity of the requesting node. The RS message includes a Nonce 363 option [RFC3971] to provide a transaction identifier for matching RS 364 and RA messages. Finally, the message can be protected using SEND 365 the same as for the DHCPv6 option. 367 3.4. Implementation Considerations 369 Each router can implement a stateful database management service of 370 their own choosing, but a functional alternative would be to use the 371 standard DHCPv6 service as the back-end management service. In this 372 way, all communications between the router's link to the requesting 373 node are via RS/RA messaging. But, when the router receives an RS 374 message with a PIO it can create a synthesized DHCPv6 Solicit message 375 to send to the DHCPv6 server. This can be done in the same way as 376 for the approach discussed in Section 2.4. In this way, the node on 377 the link over which the PIO is advertised only ever sees RS/RA 378 messages on the front end, and the router gets to use the DHCPv6 379 service for stateful configuration management on the back end. 381 4. Embedded Prefix Assertion 383 The third method entails a simple RS/RA exchange with no additional 384 options where the node asserts (or "regsiters") a prefix by embedding 385 the prefix in the source address of the RS message. The following 386 sections provide further details. 388 4.1. Embedded Prefix Assertion 390 In this method, the node is pre-provisioned with the prefix it will 391 use on its downstream networks (e.g., through network management, 392 manual configuration, etc.). To invoke this method, the node 393 includes its pre-provisioned prefix in the link-local source address 394 of its RS message according to the OMNI address format 395 [I-D.templin-6man-omni-interface]. For example, if the node is pre- 396 provisioned with the prefix 2001:db8:1000:2000::/64, it creates its 397 IPv6 link-local source address as fe80:2001:db8:1000:2000::. 399 4.2. Embedded Prefix Usage 401 When a node that wishes to assert a prefix first comes onto the link, 402 it statelessly configures an OMNI address based on its pre- 403 provisioned prefix. The node then includes the OMNI address as the 404 source address of a standard RS message. If a router that receives 405 the RS message has a way of verifying that the node is authorized to 406 receive the asserted prefix, the router injects the prefix into the 407 routing system and returns a standard RA message. When the node 408 receives the RA message, it then has assurance that the proper 409 routing state has been established. 411 The node examines the default router lifetime in the RA message as 412 guidance for when subsequent RS/RA exchanges are necessary, i.e., the 413 same as for normal IPv6ND. The node sends additional RS messages 414 before the default router lifetime expires in order to keep the 415 prefix assertion alive in the network. The RS messages may be sent 416 either to the all-routers multicast address, to the link-local subnet 417 router anycast address (i.e., fe80::) or to the unicast address(es) 418 of the router(s) discovered through means outside the scope of this 419 document. 421 4.3. Stateful Provisioning Requirements 423 Using embedded prefix assertion, the network must have some way of 424 determining the node's authority to assert its claimed prefix. This 425 could be, e.g., through examination of the link-layer source address 426 of the RS message. The network must also have some way of knowing 427 the node's claimed prefix length, as the length cannot be conveyed in 428 the RS message. If necessary, the exchange can also include some 429 form of transaction identifier, e.g., by including a Nonce option in 430 the RS. Finally, the exchange can be protected using SEND the same 431 as for the previous two methods. 433 4.4. Implementation Considerations 435 This method can be conducted using standard RS/RA messages. It 436 entails an administrative assignment of the node's OMNI address to 437 the upstream interface over which it will send the RS. When the 438 router receives the standard RS message, it statelessly derives the 439 node's prefix from the OMNI address and injects the prefix into the 440 routing system. The router then returns a standard RA message. 442 When the router returns the RA message, if it is configured to do so 443 it can include a PIO option as discussed in Section 3.1. The PIO 444 option includes prefix lifetimes and the prefix length. This 445 "hybrid" combination of methods two and three could be useful in some 446 deployment scenarios. 448 The same as for the PIO-based service discussed in Section 3.4, 449 DHCPv6 can be used as the back-end service for stateful configuration 450 management. 452 5. Out-of-Band Network Login Messaging 454 The fourth method entails an out-of-band messaging exchange through a 455 "network login" procedure. During the network login, the requesting 456 node could have an out-of-band messaging exchange with the network to 457 prepare for the router eventually sending an RA message as discussed 458 in the following sections 460 5.1. Out-of-Band Network Login 462 In the out-of-band network login, the node signs into the network 463 using, e.g., a login/password, a security certificate, etc. The node 464 authenticates itself to the network, and can optionally have an 465 iterative exchange to request certain aspects of the node's desired 466 stateful configuration information. The first-hop router is then 467 signaled to prepare an RA message to return to the node, i.e., either 468 through some out-of-band signaling or through the node sending an RS 469 message. 471 5.2. Out-of-Band Network Login Usage 473 When a node first comes onto the link, it engages in a network login 474 session using some form of out-of-band messaging such as Layer-2 (L2) 475 messaging. The session entails a security exchange where the node 476 authenticates itself to the network and proves its authorization to 477 receive the stateful configuration information. The network then 478 signals the router to send an RA message to the node, either 479 unsolicited or in response to the node's RS message. 481 5.3. Stateful Provisioning Requirements 483 Using out-of-band messaging, the node engages in an iterative 484 exchange where a request for stateful configuration information is 485 conveyed. The exchange includes an identity for the requesting node 486 and provides a unique per-message identifier so that the node can 487 correlate its message requests with the responses it gets back from 488 the network. Finally, the message exchange itself contains security 489 parameters for authenticating the requesting node. 491 5.4. Implementation Considerations 493 The network login system and routers must be tightly coupled so that 494 the network login can securely convey the requesting node's identity 495 to the router. 497 As for the PIO-based service discussed in Section 3.4, DHCPv6 can be 498 used as the back-end service for managing the stateful configuration 499 database. 501 6. Implementation Status 503 The approach discussed in Section 2 has been implemented as 504 extensions to the OpenVPN open source software distribution. The 505 implementation is available at: http://linkupnetworks.net/aero/AERO- 506 OpenVPN-2.0.tgz. 508 7. IANA Considerations 510 The IANA is instructed to assign an IPv6ND option Type value TBD for 511 the DHCPv6 option. 513 The IANA is instructed to create a registry for the DHCPv6 option 514 "Reserved" field (with no initial assignments) so that future uses of 515 the field can be coordinated. 517 8. Security Considerations 519 Security considerations for IPv6 Neighbor Discovery [RFC4861] and 520 DHCPv6 [RFC8415] apply to this document. 522 SEcure Neighbor Discovery (SEND) [RFC3971] can provide authentication 523 for IPv6 ND messages with no need for additional securing mechanisms. 525 9. Acknowledgements 527 This work was motivated by discussions on the 6man and v6ops list. 528 Those individuals who provided encouragement and critical review are 529 acknowledged. 531 The following individuals provided useful comments that improved the 532 document: Mikael Abrahamsson, Fred Baker, Ron Bonica, Yucel Guven, 533 Naveen Kottapalli, Ole Troan, Bernie Volz. 535 The following individuals developed IPv6ND and DHCPv6 extensions for 536 OpenVPN: Kyle Bae, Wayne Benson, Eric Yeh. 538 This work is aligned with the NASA Safe Autonomous Systems Operation 539 (SASO) program under NASA contract number NNA16BD84C. 541 This work is aligned with the FAA as per the SE2025 contract number 542 DTFAWA-15-D-00030. 544 This work is aligned with the Boeing Information Technology (BIT) 545 MobileNet program and the Boeing Research & Technology (BR&T) 546 enterprise autonomy program. 548 10. References 550 10.1. Normative References 552 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 553 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 554 DOI 10.17487/RFC4861, September 2007, 555 . 557 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 558 (IPv6) Specification", STD 86, RFC 8200, 559 DOI 10.17487/RFC8200, July 2017, 560 . 562 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 563 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 564 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 565 RFC 8415, DOI 10.17487/RFC8415, November 2018, 566 . 568 10.2. Informative References 570 [I-D.naveen-slaac-prefix-management] 571 Kottapalli, N., "IPv6 Stateless Prefix Management", draft- 572 naveen-slaac-prefix-management-00 (work in progress), 573 November 2018. 575 [I-D.pioxfolks-6man-pio-exclusive-bit] 576 Kline, E. and M. Abrahamsson, "IPv6 Router Advertisement 577 Prefix Information Option eXclusive Flag", draft- 578 pioxfolks-6man-pio-exclusive-bit-02 (work in progress), 579 March 2017. 581 [I-D.templin-6man-omni-interface] 582 Templin, F. and T. Whyman, "Transmission of IPv6 Packets 583 over Overlay Multilink Network (OMNI) Interfaces", draft- 584 templin-6man-omni-interface-26 (work in progress), June 585 2020. 587 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 588 "SEcure Neighbor Discovery (SEND)", RFC 3971, 589 DOI 10.17487/RFC3971, March 2005, 590 . 592 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 593 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 594 DOI 10.17487/RFC6221, May 2011, 595 . 597 Appendix A. Change Log 599 << RFC Editor - remove prior to publication >> 601 Changes from -09 to -10: 603 o Changed "AERO" reference to "OMNI" 605 o Version number and reference update. 607 Changes from -08 to -09: 609 o Changed reference and draft name for Prefix Assertion / 610 Registration 612 Changes from -07 to -08: 614 o Changed DHCPv6 reference to RFC8415 - deprecates RFC3315 and 615 RFC3633 617 o added prefix length to example in Section 4.1. 619 Changes from -06 to -07: 621 o Added "unsolicited DHCPv6 Reply" considerations 623 o Added refeence to new IPv6ND-based PD proposal. 625 o No longer associate the term "autoconfiguration" with the term 626 "stateful". 628 o Added URL for implementation. 630 Author's Address 632 Fred L. Templin (editor) 633 Boeing Research & Technology 634 P.O. Box 3707 635 Seattle, WA 98124 636 USA 638 Email: fltemplin@acm.org