idnits 2.17.1 draft-templin-6man-dhcpv6-ndopt-05.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 188: '...'Reserved' field MUST be set to 0 on t...' RFC 2119 keyword, line 189: '...e specifications MAY define new uses f...' RFC 2119 keyword, line 362: '... SHOULD include a Nonce option [RFC3971] to provide a unique...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2018) is 2111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8200' is defined on line 500, 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 July 16, 2018 5 Expires: January 17, 2019 7 A Unified Stateful/Stateless Autoconfiguration Service for IPv6 8 draft-templin-6man-dhcpv6-ndopt-05.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 January 17, 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 . . . . . . . . . . . . . . . . . . . 7 63 3.3. Stateful Autoconfiguration Requirements . . . . . . . . . 8 64 3.4. Implementation Considerations . . . . . . . . . . . . . . 8 65 4. Out-of-Band Network Login Messaging . . . . . . . . . . . . . 9 66 4.1. Out-of-Band Network Login . . . . . . . . . . . . . . . . 9 67 4.2. Out-of-Band Network Login Usage . . . . . . . . . . . . . 9 68 4.3. Stateful Autoconfiguration Requirements . . . . . . . . . 9 69 4.4. Implementation Considerations . . . . . . . . . . . . . . 10 70 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 9.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 IPv6 Neighbor Discovery (IPv6ND) [RFC4861] specifies a control 82 message set for nodes to discover neighbors, routers, prefixes and 83 other services on the link. It also supports a manner of StateLess 84 Address AutoConfiguration (SLAAC). The Dynamic Host Configuration 85 Protocol for IPv6 (DHCPv6) specifies a separate service for 86 delegation of prefixes, addresses and any other stateful information 87 [RFC3315][RFC3633]. This document presents IPv6ND extensions for 88 providing a unified stateful/stateless autoconfiguration service. 90 If the netwok can provide such a unified service, complex multi- 91 message procedures can be condensed into a single and concise message 92 exchange. This would ease network management as well as simplify 93 host and router operations. It would further accommodate both SLAAC 94 and DHCPv6 in a way that combines the best aspects of both. The 95 operating model is based on harnessing the IPv6 ND Router 96 Solicitation (RS) / Router Advertisement (RA) functions to provide 97 all stateless and stateful information in a single message exchange. 99 When a node first comes onto a link, it sends an RS to elicit an RA 100 from one or more routers for the link. If the node also needs to 101 acquire stateful information it then sends a DHCPv6 Solicit message 102 to elicit a Reply message from a DHCPv6 server. This two round-trip 103 message exchange can add delay as well as waste critical link 104 bandwidth on low-end links (e.g., 6LoWPAN, satellite communications, 105 aeronautical wireless, etc.). While it is possible to conceive of 106 starting both round trip exchanges at the same time (i.e., under a 107 leap-of-faith assumption that the link supports DHCPv6 before 108 examining the 'M' bit) this would still result in twice as many 109 channel access transactions as necessary. Moreover, the multicast 110 nature of these messages could disturb other nodes on the link, e.g., 111 resulting in an unnecessary wakeup from sleep mode. 113 This document proposes methods for combining stateless and stateful 114 operations into a single, unified exchange based on IPv6ND messaging 115 extensions. It notes that stateful exchanges must include at a 116 minimum: 118 o an explicit request for stateful information 120 o the identity of the requesting node 122 o a transaction ID that the requesting node can use to match replies 123 with their corresponding requests 125 o any security parameters necessary for the requesting node to 126 establish its authorization to receive stateful information 128 The first method is through definition of a new IPv6ND option called 129 the "DHCPv6 Option" that combines the IPv6ND router discovery and 130 DHCPv6 stateful processes into a single message exchange. Nodes 131 include the DHCPv6 option in RS messages to solicit an RA message 132 with a DHCPv6 option in return. This allows the IPv6ND and DHCPv6 133 functions to work together to supply the client with all needed 134 configuration information in a minimum number of messages. 136 The second method leverages the PIO-X proposal 137 [I-D.pioxfolks-6man-pio-exclusive-bit] where the router sets the "X 138 (eXclusive)" bit in an RA Prefix Information Option (PIO) to inform 139 the node that the prefix is provided for the node's own exclusive 140 use. This document permits nodes to include PIO-Xs in their RS 141 messages for the purpose of requesting stateful autoconfiguration 142 information from routers. 144 The third method uses out-of-band messaging for the node to request 145 stateful information outside of the scope of IPv6ND messaging. The 146 out-of-band messaging could entail some sort of network login process 147 (e.g., through Layer-2 (L2) messaging, etc). 149 The following sections present considerations for nodes that employ 150 these approaches. 152 2. DHCPv6 Options in IPv6 ND Messages 154 The first method entails the inclusion of DHCPv6 messages within 155 IPv6ND RS and RA messages, as discussed in the following sections. 157 2.1. The DHCPv6 Option 159 The DHCPv6 option is a new IPv6ND option that simply embeds a 160 standard DHCPv6 message per section 6 of [RFC3315], beginning with 161 the 'msg-type' followed by the 'transaction-id' and all DHCPv6 162 'options'. The format of the option is as follows: 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Type = TBD | Length | Pad | Reserved | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | msg-type | transaction-id | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 . options . 173 . (variable) ................... 174 | . Padding (0-7) . 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 1: IPv6 ND DHCPv6 Option Format 179 In this format, 'Type' and 'Length' are exactly as defined in 180 Section 4.6 of [RFC4861], 'Pad' is a 3-bit integer that encodes the 181 padding length, 'Reserved' is included for alignment and future use, 182 and the rest of the option is formatted as specified in Section 6 of 183 [RFC3315] except with trailing null padding added as necessary for 8 184 octet alignment. The length of the full DHCPv6 message is determined 185 by ((('Length' * 8) - 4) - 'Pad'), for a maximum message length of 186 2036 octets. 188 The 'Reserved' field MUST be set to 0 on transmission and ignored on 189 reception. Future specifications MAY define new uses for these bits. 191 2.2. DHCPv6 Option Usage 193 When a node first comes onto the link, it creates an RS message 194 containing a DHCPv6 option that embeds a DHCPv6 Solicit message. The 195 Solicit may include a Rapid Commit option if a two-message exchange 196 (i.e., instead of four) is required. The node then sends the RS 197 message either to the unicast address of a specific router on the 198 link, or to the all-routers multicast address. 200 When a router receives an RS message with a DHCPv6 option, if it does 201 not recognize the option and/or does not employ a DHCPv6 relay agent 202 or server, it returns an RA message as normal with any stateless 203 configuration information and without including a DHCPv6 option. By 204 receiving the RA message with no DHCPv6 option, the node can 205 determine that the router does not recognize the option and/or does 206 not support a DHCPv6 relay/server function. In this way, no harm 207 will have come from the node including the DHCPv6 option in the RS, 208 and the function is fully backwards compatible. 210 When a router receives an RS message with a DHCPv6 option, if it 211 recognizes the option and employs a DHCPv6 relay agent or server, it 212 extracts the encapsulated DHCPv6 message and forwards it to the relay 213 agent or server. When the DHCPv6 message reaches a DHCPv6 server, 214 the server processes the DHCPv6 Solicit message and prepares either 215 an Advertise (four message) or Reply (two message) DHCPv6 message 216 containing any delegated addresses, prefixes and/or any other 217 information the server is configured to send. The server then 218 returns the Advertise/Reply message to the router. 220 When the router receives the DHCPv6 Advertise/Reply message, it 221 creates a Router Advertisement (RA) message that includes any 222 autoconfiguration information necessary for the link and also embeds 223 the DHCPv6 message in a DHCPv6 option within the body of the RA. The 224 router then returns the RA as a unicast message response to the node 225 that sent the RS. 227 In a two message exchange, the stateless/stateful exchange is 228 completed when the node receives the RA. In a four message exchange, 229 the reqeusting node can Decline any stateful information it does not 230 wish to accept and/or send unicast Request options in subsequent RSes 231 to get RA messages with Reply options back from the router or routers 232 of its choosing. 234 At any time after the initial RS/RA exchange, the node may need to 235 issue DHCPv6 Renew, Release or Rebind messages to manage address/ 236 prefix lifetimes. In that case, the node prepares a DHCPv6 message 237 option and inserts it in an RS message which it then sends via 238 unicast to the router. The router in turn processes the message the 239 same as for DHCPv6 Solicit/Reply. 241 At any time after the initial RS/RA exchange, the DHCPv6 server may 242 need to issue a DHCPv6 Reconfigure message. In that case, when the 243 router receives the DHCPv6 Reconfigure message it prepares a unicast 244 RA message with a DHCPv6 option that encodes the Reconfigure and 245 sends the RA as an unsolicited unicast message to the node. 247 2.3. Stateful Autoconfiguration Requirements 249 Using the DHCPv6 Option, the message itself includes sub-options to 250 request stateful information. The DHCPv6 Device Unique IDentifier 251 (DUID) provides the the identity of the requesting node, and the 252 DHCPv6 transacation-id provides a unique identifier for matching RS 253 and RA messages. Finally, the message can be protected using SEcure 254 Neighbor Discovery (SEND) [RFC3971]. 256 2.4. Implementation Considerations 258 The IPv6ND and DHCPv6 functions are typically implemented in separate 259 router modules. In that case, the IPv6ND function extracts the 260 DHCPv6 message from the option included in the RS message and wraps 261 it in IP/UDP headers with the same addresses and port numbers the 262 soliciting node would have used had it send an ordinary IP/UDP/DHCPv6 263 message. The IPv6ND function then acts as a Lightweight DHCPv6 Relay 264 Agent (LDRA) [RFC6221] to forward the message to the DHCPv6 relay or 265 server function on-board the router. 267 The forwarded DHCPv6 message then traverses any additional relays on 268 the reverse path until it reaches the DHCPv6 server. When the DHCPv6 269 server processes the message, it delegates any necessary resources 270 and returns a Reply via the same relay agent path as had occurred on 271 the reverse path so that the Reply will eventually arrive back at the 272 IPv6ND function. The IPv6ND function then prepares an RA message 273 with any autoconfiguration information associated with the link, 274 embeds the DHCPv6 message body in an IPv6ND DHCPv6 option, and 275 returns the message via unicast to the node that sent the RS. 277 In a preferred implementation, however, the IPv6ND and DHCPv6 278 functions could be co-located in the same module on the router. In 279 that way the two functions would be coupled as though they were in 280 fact a single unified function without the need for any LDRA 281 processing. 283 3. PIO Options in RS Messages 285 The second method entails the inclusion of Prefix Information Options 286 (PIOs) in IPv6ND RS messages, as discussed in the following sections. 288 3.1. The PIO-X Option 290 PIOs for stateful autoconfiguration are formatted exactly as 291 specified in [RFC4861] except including the "X" bit as defined in 292 [I-D.pioxfolks-6man-pio-exclusive-bit]. We refer to PIOs with the 293 "X" bit set as "PIO-X" options. The format of the option is as 294 follows: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Length | Prefix Length |L|A|R|X| Rsrvd1| 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Valid Lifetime | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Preferred Lifetime | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Reserved2 | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 + + 309 | | 310 + Prefix + 311 | | 312 + + 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 2: PIO-X Option Format 318 In this format, all fields are exactly as defined in Section 4.6 of 319 [RFC4861]. The "X" bit is set to 1 if the prefix is to be provided 320 for the node's own exclusive use. If "X" is set to 0, no statement 321 is made about the prefix's exclusivity. 323 3.2. PIO-X Option Usage 325 When a node that wishes to request an eXclusive prefix first comes 326 onto the link, it creates an RS message containing a PIO-X. It sets 327 the Prefix Length to either the length of the prefix it wishes to 328 receive or '0' (unspecified) if it will defer to the router's 329 preference. The node then sets the Valid and Preferred Lifetimes to 330 either its preferred values or '0' (unspecified) if it will defer to 331 the router's preference. The node then sets the Prefix to either the 332 prefix it wishes to receive, or '0' (unspecified) if it will defer to 333 the router's preference. The node then sends the RS message either 334 to the unicast address of a specific router on the link, or to the 335 all-routers multicast address. 337 When a router receives an RS message with a PIO-X, if it is not 338 configured to accept PIO-Xs in RS messages it returns an RA message 339 as normal and without including a PIO-X. By receiving the RA message 340 with no PIO-X, the node can determine that the router does not 341 recognize the option and/or does not support a PIO-X service. In 342 this way, no harm will have come from the node including the PIO-X in 343 the RS, and the function is fully backwards compatible. 345 When a router receives an RS message with a PIO-X, if it recognizes 346 the option and can provide stateful autoconfiguration services it 347 examines the fields in the message and selects a prefix to delegate 348 to the node. If the PIO-X included a specific Prefix, the router 349 delegates the node's preferred prefix if possible. Otherwise, the 350 router selects a prefix to delegate to the node with length based on 351 the node's Prefix Length. The router sets lifetimes matching the 352 lifetimes requested by the node if possible, or shorter lifetimes if 353 the node's requested lifetimes are too long. The router finally 354 prepares a PIO-X containing this information and inserts it into an 355 RA message to send back to the source of the RS. 357 3.3. Stateful Autoconfiguration Requirements 359 Using the PIO-X, the option itself requests stateful 360 autoconfiguration information. The RS message link-layer addresss 361 can be used as the identity of the requesting node. The RS message 362 SHOULD include a Nonce option [RFC3971] to provide a unique 363 identifier for matching RS and RA messages. Finally, the message can 364 be protected using SEND the same as for the DHCPv6 option [RFC3971]. 366 3.4. Implementation Considerations 368 Each router can implement a stateful database management service of 369 their own choosing, but a functional alternative would be to use the 370 standard DHCPv6 service as the back-end management service. In this 371 way, all communications between the router's link to the requesting 372 node are via PIO-X RS/RA messaging. But, when the router receives an 373 RS message with a PIO-X it can create a syntehsized DHCPv6 Solicit 374 message to send to the DHCPv6 server. This can be done exactly the 375 same as for the approach discussed in Section 2.4. In this way, the 376 node on the link over which the PIO-X is advertised only ever sees 377 RS/RA messages on the front end, and the router gets to use the 378 DHCPv6 service for stateful autoconfiguration management on the back 379 end. 381 Note: In its current form, the PIO-X approach supports only prefix 382 delegation and does not support other stateful configuration 383 services. 385 4. Out-of-Band Network Login Messaging 387 The third method entails an out-of-band messaging exchange sometimes 388 known as a "network login" procedure. During the network login, the 389 requesting node could have an out-of-band messaging exchange with the 390 network to set the stage for the router eventually sending an RA 391 message as discusssed in the following sections 393 4.1. Out-of-Band Network Login 395 In the out-of-band network login, the node signs into the network 396 using, e.g., a login/password, a security certificate, etc. The node 397 authenticates itself to the network, and can optionally have an 398 iterative exchange to request certain aspects of the node's desired 399 stateful autoconfiguration information. The network then signals the 400 node's first-hop router to prepare an RA message to return to the 401 node. 403 4.2. Out-of-Band Network Login Usage 405 When a node that wishes to request stateful autoconfiguration first 406 comes onto the link, it engages in a network login session using some 407 form of out-of-band messaging such as Layer-2 (L2) messaging. The 408 session entails a security exchange where the node authenticates 409 itself to the network and proves its authorization to receive the 410 autoconfiguration information. The network then signals the router 411 to send an RA message to the node, either unsolicited or in response 412 to the node's RS message. 414 4.3. Stateful Autoconfiguration Requirements 416 Using out-of-band messaging, the node engages in an iterative 417 exchange where a request for stateful autoconfiguration information 418 is conveyed. The exchange includes an identifiy for the requesting 419 node and provides a unique per-message identifier so that the node 420 can correlate its message requests with the responses it gets back 421 from the network. Finally, the message exchange itself contains 422 security parameters for authenticating the requesting node. 424 4.4. Implementation Considerations 426 The network login system and routers must be tightly coupled so that 427 the network login can securely convey the reqesting node's identity 428 to the router. 430 As for the PIO-X-based autoconfiguration service discussed in 431 Section 3.4, DHCPv6 can be used as the back-end service for managing 432 the stateful autoconfiguration database. 434 5. Implementation Status 436 A prototype of the approach discussed in Section 2 has been 437 implemented as extensions to the OpenVPN open source software 438 distribution. 440 6. IANA Considerations 442 The IANA is instructed to assign an IPv6ND option Type value TBD for 443 the DHCPv6 option. 445 The IANA is instructed to create a registry for the DHCPv6 option 446 "Reserved" field (with no initial assignments) so that future uses of 447 the field can be coordinated. The field is to be managed as a 448 "flags" field and not a "value" field. 450 7. Security Considerations 452 Security considerations for IPv6 Neighbor Discovery [RFC4861] and 453 DHCPv6 [RFC3315][RFC3633] apply to this document. 455 SEcure Neighbor Discovery (SEND) [RFC3971] can provide authentication 456 for the combined DHCPv6/IPv6ND messages with no need for additional 457 securing mechanisms. 459 8. Acknowledgements 461 This work was motivated by discussions on the 6man and v6ops list. 462 Those individuals who provided encouragement and critical review are 463 acknowledged. 465 The following individuals provided useful comments that improved the 466 document: Ron Bonica, Bernie Volz. 468 The following individuals developed IPv6ND and DHCPv6 extensions for 469 OpenVPN: Kyle Bae, Wayne Benson, Eric Yeh. 471 This work is aligned with the NASA Safe Autonomous Systems Operation 472 (SASO) program under NASA contract number NNA16BD84C. 474 This work is aligned with the FAA as per the SE2025 contract number 475 DTFAWA-15-D-00030. 477 This work is aligned with the Boeing Information Technology (BIT) 478 MobileNet program and the Boeing Research & Technology (BR&T) 479 enterprise autonomy program. 481 9. References 483 9.1. Normative References 485 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 486 C., and M. Carney, "Dynamic Host Configuration Protocol 487 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 488 2003, . 490 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 491 Host Configuration Protocol (DHCP) version 6", RFC 3633, 492 DOI 10.17487/RFC3633, December 2003, 493 . 495 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 496 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 497 DOI 10.17487/RFC4861, September 2007, 498 . 500 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 501 (IPv6) Specification", STD 86, RFC 8200, 502 DOI 10.17487/RFC8200, July 2017, 503 . 505 9.2. Informative References 507 [I-D.pioxfolks-6man-pio-exclusive-bit] 508 Kline, E. and M. Abrahamsson, "IPv6 Router Advertisement 509 Prefix Information Option eXclusive Flag", draft- 510 pioxfolks-6man-pio-exclusive-bit-02 (work in progress), 511 March 2017. 513 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 514 "SEcure Neighbor Discovery (SEND)", RFC 3971, 515 DOI 10.17487/RFC3971, March 2005, 516 . 518 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 519 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 520 DOI 10.17487/RFC6221, May 2011, 521 . 523 Author's Address 525 Fred L. Templin (editor) 526 Boeing Research & Technology 527 P.O. Box 3707 528 Seattle, WA 98124 529 USA 531 Email: fltemplin@acm.org