idnits 2.17.1 draft-templin-6man-dhcpv6-ndopt-03.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 184: '...'Reserved' field MUST be set to 0 on t...' RFC 2119 keyword, line 185: '...e specifications MAY define new uses f...' RFC 2119 keyword, line 361: '... The RS message SHOULD include a Nonc...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 29, 2018) is 2272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8200' is defined on line 488, 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 29, 2018 5 Expires: August 2, 2018 7 IPv6 Neighbor Discovery Extensions for Prefix Delegation 8 draft-templin-6man-dhcpv6-ndopt-03.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. This document presents IPv6ND extensions for 18 providing a unified prefix delegation 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 August 2, 2018. 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 . . . . . . . . . . . . . . . . . . . 4 58 2.3. Prefix Delegation Requirements . . . . . . . . . . . . . 6 59 2.4. Implementation Considerations . . . . . . . . . . . . . . 6 60 3. PIO Options in RS Messages . . . . . . . . . . . . . . . . . 6 61 3.1. The PIO-X Option . . . . . . . . . . . . . . . . . . . . 7 62 3.2. PIO-X Option Usage . . . . . . . . . . . . . . . . . . . 7 63 3.3. Prefix Delegation 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. Prefix Delegation Requirements . . . . . . . . . . . . . 9 69 4.4. Implementation Considerations . . . . . . . . . . . . . . 9 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 8.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 IPv6 Neighbor Discovery (IPv6ND) [RFC4861] specifies a control 81 message set for nodes to discover neighbors, routers, prefixes and 82 other services on the link. It also supports a manner of StateLess 83 Address AutoConfiguration (SLAAC). The Dynamic Host Configuration 84 Protocol for IPv6 (DHCPv6) specifies a service for the stateful 85 delegation of addresses and prefixes [RFC3315][RFC3633]. This 86 document presents possible methods for providing a unified prefix 87 delegation service. 89 When a node first comes onto the link, it sends a Router Solicitation 90 (RS) message to elicit a Router Advertisement (RA) message from one 91 or more routers for the link. If the node also needs to acquire 92 prefix delegations (and, if the 'M' bit is set in the RA message) it 93 then sends a DHCPv6 Solicit message to elicit a Reply message from a 94 DHCPv6 server that is authoritative for the link. This two round- 95 trip message exchange can add delay as well as waste critical link 96 bandwidth on low-end links (e.g., aeronautical wireless links). 98 While it is possible to conceive of starting both round trip 99 exchanges at the same time (i.e., under the leap-of-faith assumption 100 that the link supports DHCPv6 before examining the 'M' bit) this 101 would result in twice as many channel access transactions as 102 necessary. 104 This document proposes methods for combining these separate 105 operations into a single, unified exchange based on IPv6ND messaging 106 for the purpose of prefix delegation. It notes that a prefix 107 delegation exchange must include at a minimum: 109 o an explicit request for a prefix 111 o the identity of the requesting node 113 o a transaction ID that the requesting node can use to match replies 114 with their corresponding requests 116 o any security parameters necessary for the requesting node to 117 establish its authorization to receive a prefix 119 The first method is through definition of a new IPv6ND option called 120 the "DHCPv6 Option" that combines the IPv6ND router discovery and 121 DHCPv6 managed prefix acquisition processes into a single message 122 exchange. Nodes include the DHCPv6 option in RS messages to solicit 123 an RA message with a DHCPv6 option in return. This allows the IPv6ND 124 and DHCPv6 functions to work together to supply the client with all 125 needed configuration information in a minimum number of messages. 127 The second method leverages the PIO-X proposal 128 [I-D.pioxfolks-6man-pio-exclusive-bit] where the router sets the "X 129 (eXclusive)" bit in an RA Prefix Information Option (PIO) to inform 130 the node that the prefix is provided for the node's own exclusive 131 use. This document permits nodes to include PIO-Xs in their RS 132 messages for the purpose of requesting prefix delegations from 133 routers. 135 The third method uses out-of-band messaging for the node to request a 136 prefix delegation outside of the scope of IPv6ND messaging. The out- 137 of-band messaging could entail some sort of network login process 138 (e.g., through Layer-2 (L2) messaging, etc). The end result of the 139 out-of-band messaging is that the router returns an RA message with 140 either a PIO-X or DHCPv6 Option to the requesting node (the node 141 having first explicitly requested the prefix delegation in the out- 142 of-band exchange). 144 The following sections present considerations for nodes that employ 145 these approaches. 147 2. DHCPv6 Options in IPv6 ND Messages 149 The first method discussed in this document is the inclusion of 150 DHCPv6 message options in IPv6ND RS and RA messages, as discussed in 151 the following sections. 153 2.1. The DHCPv6 Option 155 The DHCPv6 option is a new IPv6ND option that simply embeds a 156 standard DHCPv6 message per section 6 of [RFC3315], beginning with 157 the 'msg-type' followed by the 'transaction-id' and all DHCPv6 158 'options'. The format of the option is as follows: 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Type = TBD | Length | Pad | Reserved | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | msg-type | transaction-id | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 . options . 169 . (variable) . 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Figure 1: IPv6 ND DHCPv6 Option Format 175 In this format, 'Type' and 'Length' are exactly as defined in 176 Section 4.6 of [RFC4861], 'Pad' encodes the number of trailing zero 177 octets (between 0 - 7) that appear at the end of the option to pad to 178 an integral number of 8-octets, 'Reserved' is included for alignment 179 and potential future use, and the rest of the option is exactly as 180 defined in Section 6 of [RFC3315]. The length of the full DHCPv6 181 message is determined by ((('Length' * 8) - 4) - 'Pad'), for a 182 maximum message length of 2044 octets. 184 The 'Reserved' field MUST be set to 0 on transmission and ignored on 185 reception. Future specifications MAY define new uses for these bits. 187 2.2. DHCPv6 Option Usage 189 When a node first comes onto the link, it creates a Router 190 Solicitation (RS) message containing a DHCPv6 option that embeds a 191 DHCPv6 Solicit message. The Solicit may include a Rapid Commit 192 option if a two-message exchange (i.e., instead of four) is required. 193 The node then sends the RS message either to the unicast address of a 194 specific router on the link, or to the All-Routers multicast address. 196 When a router receives an RS message with a DHCPv6 option, if it does 197 not recognize the option and/or does not employ a DHCPv6 relay agent 198 or server, it returns a Router Advertisement (RA) message as normal 199 and without including a DHCPv6 option. By receiving the RA message 200 with no DHCPv6 option, the node can determine that the router does 201 not recognize the option and/or does not support a DHCPv6 relay/ 202 server function. In this way, no harm will have come from the node 203 including the DHCPv6 option in the RS, and the function is fully 204 backwards compatible. 206 When a router receives an RS message with a DHCPv6 option, if it 207 recognizes the option and employs a DHCPv6 relay agent or server, it 208 extracts the DHCPv6 message from the RS message and forwards the 209 message to the DHCPv6 relay agent or server. When the DHCPv6 message 210 reaches a DHCPv6 server, the server processes the DHCPv6 Solicit 211 message and prepares either an Advertise (four message) or Reply (two 212 message) DHCPv6 message containing any delegated addresses, prefixes 213 and/or any other information the server is configured to send. The 214 server then returns the Advertise/Reply message to the router. 216 When the router receives the DHCPv6 Advertise/Reply message, it 217 creates a Router Advertisement (RA) message that includes any 218 autoconfiguration information necessary for the link and also embeds 219 the DHCPv6 message in a DHCPv6 option within the body of the RA. The 220 router then returns the RA as a unicast message response to the node 221 that sent the RS. 223 In a two message exchange, the prefix delegation is completed when 224 the node receives the RA. In a four message exchange, the reqeusting 225 node can Decline any prefix delegations it does not wish to accept 226 and/or send unicast Request messages in subsequent RSes to get a 227 delegated prefix Reply message back from the router or routers of its 228 choosing. 230 At any time after the initial RS/RA exchange, the node may need to 231 issue a DHCPv6 Renew, Release or Rebind message, e.g., to extend 232 address/prefix lifetimes. In that case, the node prepares a DHCPv6 233 message option and inserts it in an RS message which it then sends 234 via unicast to the router. The router in turn processes the message 235 the same as for DHCPv6 Solicit/Reply. 237 At any time after the initial RS/RA exchange, the DHCPv6 server may 238 need to issue a DHCPv6 Reconfigure message. In that case, when the 239 router receives the DHCPv6 Reconfigure message it prepares a unicast 240 RA message with a DHCPv6 option that encodes the Reconfigure and 241 sends the RA as an unsolicited unicast message to the node. 243 2.3. Prefix Delegation Requirements 245 Using the DHCPv6 Option, the message itself includes an Identity 246 Association for Prefix Delegation (IA_PD) option to request a prefix 247 delegation. The DHCPv6 Device Unique IDentifier (DUID) provides the 248 the identity of the requesting node, and the DHCPv6 transacation-id 249 provides a unique identifier for matching RS and RA messages. 250 Finally, the message can be protected using SEcure Neighbor Discovery 251 (SEND) [RFC3971]. 253 2.4. Implementation Considerations 255 The IPv6ND function and DHCPv6 function are typically implemented in 256 separate router modules. In that case, the IPv6ND function extracts 257 the DHCPv6 message from the option included in the RS message and 258 wraps it in IP/UDP headers. The source address in the IP header is 259 set to the node's link-local address, and the source port in the UDP 260 header is set to the port number associated with the IPv6ND function. 261 The IPv6ND function then acts as a Lightweight DHCPv6 Relay Agent 262 (LDRA) [RFC6221] to forward the message to the DHCPv6 relay or server 263 function on-board the router. 265 The forwarded DHCPv6 message then traverses any additional relays on 266 the reverse path until it reaches the DHCPv6 server. When the DHCPv6 267 server processes the message, it delegates any necessary resources 268 and sends a Reply via the same relay agent path as had occurred on 269 the reverse path so that the Reply will eventually arrive back at the 270 IPv6ND function. The IPv6ND function then prepares an RA message 271 with any autoconfiguration information associated with the link, 272 embeds the DHCPv6 message body in an IPv6ND DHCPv6 option, and 273 returns the message via unicast to the node that sent the RS. 275 In a preferred implementation, however, the IPv6ND and DHCPv6 276 functions could be co-located in the same module on the router. In 277 that way the two functions would be coupled as though they were in 278 fact a single unified function without the need for any LDRA 279 processing. 281 3. PIO Options in RS Messages 283 The second method discussed in this document is the inclusion of 284 PIO-X options in IPv6ND RS messages, as discussed in the following 285 sections. 287 3.1. The PIO-X Option 289 The PIO option for solicited prefix delegation is formatted exactly 290 as specified in [RFC4861] except including the "X" bit as defined in 291 [I-D.pioxfolks-6man-pio-exclusive-bit]. We refer to PIO options with 292 the "X" bit set as "PIO-X" options. The format of the option is as 293 follows: 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Type | Length | Prefix Length |L|A|R|X| Rsrvd1| 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Valid Lifetime | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Preferred Lifetime | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Reserved2 | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 + + 308 | | 309 + Prefix + 310 | | 311 + + 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 2: PIO-X Option Format 317 In this format, all feilds are exactly as defined in Section 4.6 of 318 [RFC4861]. The "X" bit is set to 1 if the prefix is to be provided 319 for the node's own exclusive use. If "X" is set to 0, no statement 320 is made about the prefix's exclusivity. 322 3.2. PIO-X Option Usage 324 When a node that wishes to request an eXclusive prefix first comes 325 onto the link, it creates a Router Solicitation (RS) message 326 containing a PIO-X. It sets the Prefix Length to either the length 327 of the prefix it wishes to receive or '0' (unspecified) if it will 328 defer to the router's preference. The node then sets the Valid and 329 Preferred Lifetimes to either its preferred values or '0' 330 (unspecified) if it will defer to the router's preference. The node 331 then sets the Prefix to either the prefix it wishes to receive, or 332 '0' (unspecified) if it will defer to the router's preference. The 333 node then sends the RS message either to the unicast address of a 334 specific router on the link, or to the All-Routers multicast address. 336 When a router receives an RS message with a PIO-X option, if it is 337 not configured to accept PIO-Xs in RS messages it returns a Router 338 Advertisement (RA) message as normal and without including a PIO-X. 339 By receiving the RA message with no PIO-X, the node can determine 340 that the router does not recognize the option and/or does not support 341 a PIO-X prefix delegation service. In this way, no harm will have 342 come from the node including the PIO-X in the RS, and the function is 343 fully backwards compatible. 345 When a router receives an RS message with a PIO-X, if it recognizes 346 the option and can provide prefix delegation services it examines the 347 fields in the message and selects a prefix to delegate to the node. 348 If the PIO-X included a non-zero Prefix, the router delegates the 349 node's preferred prefix if possible. Otherwise, the router selects a 350 prefix to delegate to the node with length based on the node's Prefix 351 Length. The router sets lifetimes matching the lifetimes requested 352 by the node if possible, or shorter lifetimes if the node's requested 353 lifetimes are too long. The router finally prepares a PIO-X 354 containing this information and inserts it into an RA message to send 355 back to the source of the RS. 357 3.3. Prefix Delegation Requirements 359 Using the PIO-X, the option itself requests a prefix delegation. The 360 RS message link-layer addresss can be used as the identity of the 361 requesting node. The RS message SHOULD include a Nonce option 362 [RFC3971] to provide a unique identifier for matching RS and RA 363 messages. Finally, the message can be protected using SEND the same 364 as for the DHCPv6 option [RFC3971]. 366 3.4. Implementation Considerations 368 Each router can implement a prefix delegation database management 369 service of their own choosing, but an attractive alternative would be 370 to use the already-existing DHCPv6 service as the back-end prefix 371 management service. In this way, all communications between the 372 router's link to the requesting node are via PIO-X RS/RA messaging. 373 But, when the router receives an RS message with a PIO-X it can 374 create a syntehsized DHCPv6 Solicit message to send to the DHCPv6 375 server. This can be done exactly the same as for the approach 376 discussed in Section 2.4. In this way, the node on the link over 377 which the PIO-X is advertised only ever sees RS/RA messages on the 378 front end, and the router gets to use the mature and widely deployed 379 DHCPv6 service for prefix management on the back end. 381 4. Out-of-Band Network Login Messaging 383 The third method entails and out-of-band messaging exchange sometimes 384 known as a "network login" procedure. During the network login, the 385 requesting node could have a multi-message exchange with the network 386 to set the stage for the router eventually sending an RA message as 387 discusssed in the following sections 389 4.1. Out-of-Band Network Login 391 In the out-of-band network login, the node signs into the network 392 using, e.g., a login/password, a security certificate, etc. The node 393 authenticates itself to the network, and can optionally have an 394 iterative exchange to request certain aspects of the node's desired 395 prefix delegation. The network then signals the node's first-hop 396 router to prepare an RA message with a PIO-X option. 398 4.2. Out-of-Band Network Login Usage 400 When a node that wishes to request a prefix delegation first comes 401 onto the link, it engages in a network login session using some form 402 of out-of-band messaging such as Layer 2 (L2) messaging. The session 403 entails a security exchange where the node authenticates itself to 404 the network and proves its authorization to receive its desired 405 prefix. The network then signals the router to send an RA message 406 with a PIO-X to the node, either unsolicited or in response to the 407 node's RS message. 409 4.3. Prefix Delegation Requirements 411 Using out-of-band messaging, the node engages in a (possibly) multi- 412 message exchange where a request for a prefix delegation is conveyed. 413 The node's link-layer addresss can be used as the identity of the 414 requesting node. The out-of-band exchange provides a unique per- 415 message identifier so that the node can correlate its message 416 requests with the responses it gets back from the network. Finally, 417 the message exchange itself contains security parameters for 418 authenticating the requesting node. 420 4.4. Implementation Considerations 422 The network login system and routers must be tightly coupled so that 423 the network login can securely convey the reqesting node's identity 424 to the router. 426 As for the PIO-X-based prefix delegation discussed in Section 3.4, 427 DHCPv6 can be used as the back-end service for managing the prefix 428 delegation database. 430 5. IANA Considerations 432 The IANA is instructed to assign an IPv6ND option Type value TBD for 433 the DHCPv6 option. 435 The IANA is instructed to create a registry for the DHCPv6 option 436 "Reserved" field so that future uses of bits in the field can be 437 coordinated. 439 6. Security Considerations 441 Security considerations for IPv6 Neighbor Discovery [RFC4861] and 442 DHCPv6 [RFC3315][RFC3633] apply to this document. 444 SEcure Neighbor Discovery (SEND) [RFC3971] can provide authentication 445 for the combined DHCPv6/IPv6ND messages with no need for additional 446 securing mechanisms. 448 . 450 7. Acknowledgements 452 This work was motivated by discussions on the 6man and v6ops list. 453 Those individuals who provided encouragement and critical review are 454 acknowledged. 456 The following individuals provided useful comments that improved the 457 document: Bernie Volz. 459 This work is aligned with the NASA Safe Autonomous Systems Operation 460 (SASO) program under NASA contract number NNA16BD84C. 462 This work is aligned with the FAA as per the SE2025 contract number 463 DTFAWA-15-D-00030. 465 This work is aligned with the Boeing Information Technology (BIT) 466 MobileNet program and the Boeing Research & Technology (BR&T) 467 enterprise autonomy program. 469 8. References 471 8.1. Normative References 473 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 474 C., and M. Carney, "Dynamic Host Configuration Protocol 475 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 476 2003, . 478 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 479 Host Configuration Protocol (DHCP) version 6", RFC 3633, 480 DOI 10.17487/RFC3633, December 2003, 481 . 483 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 484 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 485 DOI 10.17487/RFC4861, September 2007, 486 . 488 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 489 (IPv6) Specification", STD 86, RFC 8200, 490 DOI 10.17487/RFC8200, July 2017, 491 . 493 8.2. Informative References 495 [I-D.pioxfolks-6man-pio-exclusive-bit] 496 Kline, E. and M. Abrahamsson, "IPv6 Router Advertisement 497 Prefix Information Option eXclusive Flag", draft- 498 pioxfolks-6man-pio-exclusive-bit-02 (work in progress), 499 March 2017. 501 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 502 "SEcure Neighbor Discovery (SEND)", RFC 3971, 503 DOI 10.17487/RFC3971, March 2005, 504 . 506 [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. 507 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 508 DOI 10.17487/RFC6221, May 2011, 509 . 511 Author's Address 513 Fred L. Templin (editor) 514 Boeing Research & Technology 515 P.O. Box 3707 516 Seattle, WA 98124 517 USA 519 Email: fltemplin@acm.org