idnits 2.17.1 draft-ietf-mext-nemo-pd-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5160 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-agentopt-delegate-04 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Extensions for IPv6 R. Droms 3 (MEXT) P. Thubert 4 Internet-Draft Cisco 5 Intended status: Standards Track F. Dupont 6 Expires: September 9, 2010 ISC 7 W. Haddad 8 Ericsson 9 CJ. Bernardos 10 UC3M 11 March 8, 2010 13 DHCPv6 Prefix Delegation for NEMO 14 draft-ietf-mext-nemo-pd-04 16 Abstract 18 One aspect of network mobility support is the assignment of a prefix 19 or prefixes to a Mobile Router (MR) for use on the links in the 20 Mobile Network. DHCPv6 prefix delegation can be used for this 21 configuration task. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 9, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Application of DHCPv6 prefix delegation to mobile networks 66 for delegation of home prefixes . . . . . . . . . . . . . . . 4 67 3.1. When the MR uses DHCPv6 . . . . . . . . . . . . . . . . . 5 68 3.2. Use of MR-HA tunnel for DHCPv6 messages . . . . . . . . . 6 69 3.3. DHCPv6 Relay Agent for transmission of DHCPv6 messages . . 7 70 3.3.1. Relay agent configuration . . . . . . . . . . . . . . 8 71 3.3.2. Transmission of DHCPv6 messages . . . . . . . . . . . 9 72 3.3.3. Receipt of DHCPv6 messages . . . . . . . . . . . . . . 9 73 3.4. Exchanging DHCPv6 messages when MR is at home . . . . . . 9 74 3.5. Selecting an HA that provides DHCPv6PD . . . . . . . . . . 10 75 3.6. Minimizing DHCPv6PD messages . . . . . . . . . . . . . . . 10 76 3.7. Location of DHCPv6PD Delegating Router function . . . . . 10 77 3.8. Other DHCPv6 functions . . . . . . . . . . . . . . . . . . 12 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 81 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 7.1. Revision -00 . . . . . . . . . . . . . . . . . . . . . . . 14 83 7.2. Revision -01 . . . . . . . . . . . . . . . . . . . . . . . 14 84 7.3. Revision -02 . . . . . . . . . . . . . . . . . . . . . . . 15 85 7.4. Revision -04 . . . . . . . . . . . . . . . . . . . . . . . 15 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 91 1. Introduction 93 One aspect of network mobility support is the assignment of a prefix 94 or prefixes to a Mobile Router for use on the links in the Mobile 95 Network. DHCPv6 prefix delegation [RFC3633] (DHCPv6PD) can be used 96 for this configuration task. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC2119 [RFC2119]. 104 The following terms used in this document are defined in the IPv6 105 Addressing Architecture document [RFC4291]: 107 link-local unicast address 109 link-local scope multicast address 111 The following terms used in this document are defined in the mobile 112 IPv6 specification [RFC3775]: 114 home agent (HA) 116 home link 118 The following terms used in this document are defined in the Mobile 119 Network terminology document [RFC4885]: 121 Mobile Router (MR) 123 Mobile Network (NEMO) 125 Mobile Network Prefix (MNP) 127 The following terms used in this document are defined in the DHCPv6 128 [RFC3315] and DHCPv6 prefix delegation [RFC3633] specifications: 130 delegating router (DR; acts as a DHCPv6 server) 132 requesting router (RR; acts as a DHCPv6 client) 134 DHCPv6 relay agent (DRA) 136 The following acronym is used in this document: 138 DHCPv6PD: DHCPv6 prefix delegation 140 3. Application of DHCPv6 prefix delegation to mobile networks for 141 delegation of home prefixes 143 The NEMO Basic protocol [RFC3963] extends the mobile IPv6 protocol 144 [RFC3775] to enable network mobility. In this extension, an MR uses 145 the mobile IPv6 protocol to establish and maintain a session with its 146 HA, and uses bidirectional tunneling between the MR and HA to provide 147 a path through which nodes attached to links in the Mobile Network 148 can maintain connectivity with nodes not in the Mobile Network. 150 The requirements for NEMO [RFC4885] include the ability of the MR to 151 receive delegated prefixes that can then be assigned to links in the 152 Mobile Network. DHCPv6PD can be used to meet this requirement for 153 prefix delegation. 155 To use DHCPv6PD for Mobile Networks, the HA assumes the role of 156 either the DR or a DHCPv6 relay agent and the MR assumes the role of 157 the RR. Throughout the remainder of this document, the HA will be 158 assumed to be acting as a DHCPv6PD DR or relay agent and the MR will 159 be assumed to be acting as a RR. 161 If the HA is acting as relay agent, some other device acts as the DR. 162 For example, the server providing DHCPv6 service in the home network 163 might also provide NEMO DHCPv6PD service. Or, a home network with 164 several HAs might configure one of those HAs as a DHCPv6PD server 165 while the other HAs act as relay agents. 167 The HA and MR exchange DHCPv6PD protocol messages through the tunnel 168 connecting them (as specified in RFC3775). The tunnel acts as the 169 link labeled "DSL to subscriber premises" in figure 1 of the DHCPv6PD 170 specification. See Figure 1 for different possible deployment 171 topologies. 173 ---- /-----------\ ---- 174 | MR |-----| Internet |-----| HA | 175 |(RR)| \-----------/ |(DR)| 176 ---- ---- 178 ---- /-----------\ ----- ------ 179 | MR |-----| Internet |-----| HA |-----|DHCPv6| 180 |(RR)| \-----------/ |(DRA)| |Server| 181 ---- ----- ------ 183 ----- /-----------\ ----- 184 | MR |----| Internet |-----| HA | 185 |(RR) | \-----------/ |(DR) | 186 |(DRA)| ----- 187 ----- 189 Figure 1: Different topologies of the application of DHCPv6PD to NEMO 190 for delegation of MNPs 192 The DHCPv6PD server is provisioned with prefixes to be assigned using 193 any of the prefix assignment mechanisms described in the DHCPv6PD 194 specifications. Other updates to the HA data structures required as 195 a side effect of prefix delegation are specified by the particular 196 network mobility protocol. For example, in the case of Basic Network 197 Mobility Support [RFC3963], the HA would add an entry in its binding 198 cache registering the delegated prefix to the MR to which the prefix 199 was delegated. 201 3.1. When the MR uses DHCPv6 203 The MR initiates a DHCPv6 message exchange for prefix delegation 204 whenever it establishes an MR-HA tunnel to its HA. If the MR does 205 not have any active delegated prefixes (with unexpired leases), the 206 MR initiates a DHCPv6 message exchange with a DHCPv6 Solicit message 207 as described in section 17 of RFC 3315 and section 12.1 of RFC 3633. 208 Once the MR has been delegated a set of prefixes from the HA, the MR 209 sends a new Binding Update including the delegated prefixes, carried 210 in Mobile Network Prefix options (see Figure 2). Note that this 211 requires a minor modification to the NEMO Basic Support protocol as 212 described in RFC 3963. RFC 3963 does not assume the MR can change 213 from implicit to explicit BU signaling mode, while this specification 214 requires the MR to first perform a MIPv6 registration to the HA 215 providing DHCPv6PD services (via implicit signaling, no MNP carried 216 in the BU), then obtain a set of delegated prefixes via DHCPv6PD, and 217 then send a new BU to the Home Agent, now carrying the delegated 218 prefixes as Mobile Network Prefixes (explicit signaling mode). 220 In case the MR has one or more active delegated prefixes, the MR 221 initiates a DHCPv6 message exchange with a DHCPv6 Rebind message as 222 described in section 18.1.2 of RFC 3315 and section 12.1 of RFC 3633. 223 In this case, only one BU signaling sequence is required. 225 MR HA 226 (RR) (DR) 227 | Binding Update | 228 |------------------------>| 229 | (HoA, CoA) | 230 | | 231 | Binding Ack | 232 |<------------------------| 233 | | 234 | DHCPv6 Solicit | 235 |--=====================->| 236 | | 237 | DHCPv6 Advertise | 238 |<-=====================--| 239 | | 240 | DHCPv6 Request | 241 |--=====================->| 242 | | 243 | DHCPv6 Reply | 244 |<-=====================--| 245 | (Mobile Network Prefix) | 246 | | 247 | Binding Update | 248 |------------------------>| 249 | (HoA, CoA, MNP) | 250 | | 251 | Binding Ack | 252 |<------------------------| 253 | | 255 Figure 2: Signaling sequence for the case the HA acts as DHCPv6PD 256 Delegating Router 258 3.2. Use of MR-HA tunnel for DHCPv6 messages 260 The DHCPv6 specification requires the use of link-local unicast and 261 link-local scope multicast addresses in DHCPv6 messages (except in 262 certain cases as defined in section 22.12 of the DHCPv6 263 specification). Section 10.4.2 of the mobile IPv6 specification 264 describes forwarding of intercepted packets, and the third paragraph 265 of that section begins: 267 However, packets addressed to the mobile node's link-local address 268 MUST NOT be tunneled to the mobile node. 270 The DHCPv6 messages exchanged between the HA and the MR originate 271 only with the HA and the MR, and therefore are not "intercepted 272 packets" (i.e. the sender of the packets is a third node on the home 273 link) and may be sent between the HA and the MR through the tunnel. 275 Even though the MR-HA tunnel is a point to point connection, the MR 276 SHOULD use multicast DHCPv6 messages as described in RFC 3315 over 277 that tunnel. 279 3.3. DHCPv6 Relay Agent for transmission of DHCPv6 messages 281 A DHPCv6 relay agent function [RFC3315] can be used as an alternative 282 to multicast DHCPv6 messages over the tunnel between the MR and the 283 HA. In this configuration, the relay agent function is co-located in 284 the MR with the DHCPv6 client function (see Figure 3. Rather than 285 using multicast to send DHCPv6 messages through the tunnel to the 286 DHCPv6 server, the DHCPv6 client in the MR hands any outbound DHCPv6 287 messages to the co-located relay agent. Responses from the DHCPv6 288 server are delivered to the relay agent function in the MR, which 289 extracts the encapsulated message and delivers it to the DHCPv6 290 client in the MR. 292 MR 293 (RR) HA 294 (DRA) (DR) 295 | Binding Update | 296 |------------------------>| 297 | (HoA, CoA) | 298 | | 299 | Binding Ack | 300 |<------------------------| 301 -- | | 302 / \ | | 303 \ *| | 304 DHCPv6 -- >| DHCPv6 Solicit | 305 Solicit |--=====================->| 306 | | 307 | DHCPv6 Advertise | 308 -- |<-=====================--| 309 / \ | | 310 \ *| DHCPv6 Request | 311 DHCPv6 -- >|--=====================->| 312 Request | | 313 | DHCPv6 Reply | 314 |<-=====================--| 315 | (Mobile Network Prefix) | 316 | | 317 | Binding Update | 318 |------------------------>| 319 | (HoA, CoA, MNP) | 320 | | 321 | Binding Ack | 322 |<------------------------| 323 | | 325 Figure 3: Signaling sequence for the case a DHCPv6 relay agent is co- 326 located in the MR 328 3.3.1. Relay agent configuration 330 The use of the relay agent function in the MR allows the MR to 331 unicast DHCPv6 messages to the DHCPv6 server. The relay agent must 332 be configured with the address of the DHCPv6 server or another DHCPv6 333 relay agent that will forward message on to a DHCPv6 server. For the 334 purposes of NEMO, the relay agent assumes that the HA for the MR 335 hosts the next hop in the path the to the DHCPv6 server: either the 336 DHCPv6 server or a relay agent that will forward message to the 337 DHCPv6 server. Therefore, if the MR acts as a DHCPv6 relay agent, 338 the MR MUST configure the DHCPv6 relay agent to forward DHCPv6 339 messages to the HA. 341 3.3.2. Transmission of DHCPv6 messages 343 In this configuration, i.e., a DHCPv6 relay agent is used and co- 344 located in the MR, when the DHCPv6 client in the MR sends a message, 345 it hands the message to the DHCPv6 relay agent in the MR. The way in 346 which the message is passed to the DHCP relay agent is beyond the 347 scope of this document. The relay agent encapsulates the message 348 from the client according to RFC 3315 in a Relay-forward message and 349 sends the resulting DHCPv6 message to the HA. The relay agent sets 350 the fields in the Relay-forward message as follows: 352 msg-type RELAY-FORW 354 hop-count 1 356 link-address A non-link-local address from the MR interface (e.g., 357 home address or, in case the HoA belongs to the MNP, 358 the address of the MR's egress interface of the MR 359 when attached to the Home Link) of the tunnel between 360 the HA and MR 362 peer-address A non-link-local address from the MR interface (e.g., 363 home address or, in case the HoA belongs to the MNP, 364 the address of the MR's egress interface of the MR 365 when attached to the Home Link) of the tunnel between 366 the HA and MR 368 options MUST include a "Relay Message option" [RFC3315]; MAY 369 include other options added by the relay agent. 371 3.3.3. Receipt of DHCPv6 messages 373 In this configuration, messages from the DHCPv6 server will be 374 returned to the DHCPv6 relay agent, with the message for the DHCPv6 375 client encapsulated in the Relay Message option [RFC3315] in a Relay- 376 reply message. The relay agent function extracts the message for the 377 client from the Relay Message option and hands the message to the 378 DHCPv6 client in the MR. The way in which, the message is passed to 379 the client is beyond the scope of this document. 381 3.4. Exchanging DHCPv6 messages when MR is at home 383 When the MR is on its home link, the HA uses the home link to 384 exchange DHCPv6PD messages with the MR. It is the responsibility of 385 the implementation to determine when the MR is on its home link and 386 to avoid use of any existing tunnel. 388 3.5. Selecting an HA that provides DHCPv6PD 390 Not all nodes that are willing to act as an HA are required to 391 provide DHCPv6PD. Therefore, when selecting an HA, an MR that 392 requires DHCPv6PD service must identify an HA that will provide the 393 service. The MR can determine if an HA provides DHCPv6PD by 394 initiating a DHCPv6 message exchange in which the MR requests 395 delegated prefix(es). If the HA does not respond or responds but 396 does not delegate any prefix(es) in its response, the MR assumes that 397 the HA does not provide DHCPv6PD service. The MR continues to query 398 all candidate HAs until it finds an HA that provides DHCPv6PD. Note 399 that in this particular case, the MR has also to setup a tunnel with 400 each HA (this requires the MR to perform an MIPv6 registration) it 401 queries. 403 Querying an HA to determine if it provides DHCPv6PD requires a small 404 modification to the operation of DHCPv6 as described in RFC 3315. 405 Under normal circumstances, a host will continue to send DHCPv6 406 Solicit messages until it receives a response (see Section 17 of RFC 407 3315). However, an HA may choose not to respond to the Solicit 408 messages from the MR because the HA does not provide DHCPv6. 409 Therefore, when querying an HA to determine if the HA provides 410 DHCPv6PD service, the MR MUST discontinue sending Solicit messages to 411 the HA after sending 6 Solicit messages, and conclude that the HA 412 will not provide DHCPv6PD service. Sending 6 queries provides enough 413 reliability for scenarios in which the wireless connectivity is lost 414 for a short period after sending the first BU message. 416 It is recommended that the MR uses a sequential probing of the HAs 417 for DHCPv6PD service. 419 3.6. Minimizing DHCPv6PD messages 421 DHCPv6PD in a Mobile Network can be combined with the Rapid Commit 422 option [RFC3315] to provide DHCPv6 prefix delegation with a two 423 message exchange between the mobile node and the DHCPv6PD DR. 425 3.7. Location of DHCPv6PD Delegating Router function 427 Support of DHCPv6PD for a Mobile Network is optional. 429 The use of a DHCPv6 relay agent in DHCPv6PD may require "a protocol 430 or other out-of-band communication to add routing information for 431 delegated prefixes into the provider edge router" (section 14 of RFC 432 3633). If the DHCPv6PD DR function is implemented in the HA for the 433 MR, no relay agent function is required. 435 It may be desirable to use a single DR to manage RRs in a network 436 with multiple HAs. In this scenario, the HAs will act as DHCP relay 437 agents, forwarding messages between the RRs and the DR. 439 The use of the DHCPv6 relay agent function with DHCPv6PD requires 440 that there be some mechanism through which routing information for 441 the delegated prefixes can be added to the appropriate routing 442 infrastructure. If the HA is acting as a DHCPv6 relay agent, the HA 443 SHOULD add a route to the delegated prefix and advertise that route 444 after receiving a binding update for the prefix from the RR 445 [RFC3963]. Note that such binding update is received after the first 446 binding update message which is sent by the MR in order to set-up the 447 bidirectional tunnel (see Figure 4). 449 MR HA DHCPv6 450 (RR) (DRA) Server 451 | Binding Update | | 452 |------------------------>| | 453 | (HoA, CoA) | | 454 | | | 455 | Binding Ack | | 456 |<------------------------| | 457 | | | 458 | DHCPv6 Solicit | DHCPv6 Solicit | 459 |--=====================->|------------------------>| 460 | | | 461 | DHCPv6 Advertise | DHCPv6 Advertise | 462 |<-=====================--|<------------------------| 463 | | | 464 | DHCPv6 Request | DHCPv6 Request | 465 |--=====================->|------------------------>| 466 | | | 467 | DHCPv6 Reply | DHCPv6 Reply | 468 |<-=====================--|<------------------------| 469 | (Mobile Network Prefix) | (Mobile Network Prefix) | 470 | | | 471 | Binding Update | | 472 |------------------------>| | 473 | (HoA, CoA, MNP) | ( HA starts ) | 474 | | ( advertising ) | 475 | Binding Ack | ( routes to ) | 476 |<------------------------| ( the MNP ) | 477 | | | 479 Figure 4: Signaling sequence for the case the HA acts as DHCPv6 relay 480 agent 482 In particular, if the MR uses NEMO explicit mode, then it must add 483 the delegated prefix to the prefix list in the Binding Update 484 messages. If the binding cache is cleared before the prefix valid 485 lifetime, the MR might bind that prefix again using explicit mode, 486 till the lifetime expires. 488 In implicit mode, the HA must save the delegated prefix with the 489 binding cache entry (BCE) of the Mobile Router. When the BCE is 490 cleared, the HA loses the information about the delegated prefix. 491 Because the MR will use DHCPv6 when it reestablishes its tunnel to 492 the HA (see Section 3.1), the HA will be able to add the delegated 493 prefix back to the BCE. 495 At the time this document was written, one way in which a DR can 496 explicitly notify a relay agent about delegated prefixes, is to use 497 the "DHCP Relay Agent Assignment Notification Option" 498 [I-D.ietf-dhc-dhcpv6-agentopt-delegate]. 500 Another alternative, if the RR is part of the same administrative 501 domain as the home network to which it is attached through the HA, 502 and the RR can be trusted, the RR can use a routing protocol like 503 OSPF to advertise any delegated prefixes. 505 NEMO explicit mode is recommended to take advantage of the function 506 already defined for NEMO. 508 3.8. Other DHCPv6 functions 510 The DHCPv6 messages exchanged between the MR and the HA may also be 511 used for other DHCPv6 functions in addition to DHCPv6PD. For 512 example, the HA may assign global addresses to the MR and may pass 513 other configuration information such as a list of available DNS 514 recursive name servers [RFC3646] to the MR using the same DHCPv6 515 messages as used for DHCPV6PD. 517 The HA may act as a DHCPv6 relay agent for MHs while it acts as a DR 518 for MRs. 520 4. Security Considerations 522 This document describes the use of DHCPv6 for prefix delegation in 523 Mobile Networks. It does not introduce any additional security 524 considerations for DHCPv6 beyond those described in the "Security 525 Considerations" section of the DHCPv6 base specification [RFC3315] 526 and the "Security Considerations" of the DHCPv6 Prefix Delegation 527 specification [RFC3633]. 529 The use of DHCPv6, as described in this document, requires only 530 message integrity protection, which can be provided by the mobile 531 network infrastructure between the MR and the HA. 533 If the network infrastructure connecting the various communicating 534 nodes does not provide message integrity and source authentication 535 for the DHCPv6PD messages, HAs and MRs SHOULD use DHCPv6 536 authentication as described in section "Authentication of DHCP 537 messages" of the DHCPv6 specification [RFC3315], to guard against 538 attacks mounted through prefix delegation. 540 If the HA and DHCPv6 PD functions are not provided by the same 541 physical node, the HA will act as a DHCPv6 relay agent between the MR 542 and the DHCPv6 server. In this scenario, the mobile network 543 infrastructure will only protect the DHCPv6 traffic between the RR 544 (MR) and the relay agent (HA). The following text, based on Section 545 21.1 of RFC 3315, describes how appropriate security can be provided 546 between a DHCPv6 relay agent and server. 548 DHCPv6 relay agents and servers MAY use IPsec mechanisms for IPv6 549 [RFC4301] to exchange messages securely. DHCPv6 relay agents and 550 servers that support secure relay agent to server or relay agent 551 to relay agent communication use IPsec under the following 552 conditions: 554 Selectors DHCPv6 relay agents are manually configured with 555 the addresses of the DHCPv6 server to which DHCPv6 556 messages are to be forwarded. Each DHCPv6 server 557 that will be using IPsec for securing DHCPv6 558 messages must also be configured with a list of 559 the DHCPv6 relay agents to which messages will be 560 returned. The selectors for the DHCPv6 relay 561 agents and servers will be the pairs of addresses 562 defining DHCPv6 relay agents and servers that 563 exchange DHCP messages on the DHCPv6 UDP ports 546 564 and 547. 566 Mode DHCPv6 relay agents and servers use transport mode 567 and ESP. The information in DHCPv6 messages is 568 not generally considered confidential, so 569 encryption need not be used (i.e., NULL encryption 570 can be used). 572 Key management If the HA providing the DHCPv6 relay agent 573 function and the DHCPv6 servers are both 574 administered by the same organization, public key 575 schemes are not necessary. Because the relay 576 agents and servers must be manually configured, 577 manually configured key management may suffice, 578 but does not provide defense against replayed 579 messages. Accordingly, IKE with preshared secrets 580 SHOULD be supported. 582 Security policy DHCPv6 messages between relay agents and servers 583 should only be accepted from DHCPv6 peers as 584 identified in the local configuration. 586 Authentication Shared keys, indexed to the source IP address of 587 the received DHCPv6 message, are adequate in this 588 application. 590 5. IANA Considerations 592 This document describes the use of DHCPv6 for prefix delegation in 593 Mobile Networks. It does not introduce any additional IANA 594 considerations. 596 6. Acknowledgments 598 The authors would like to thank people who have given valuable 599 comments on the mailing list. Specific suggestions from Ryuji 600 Wakikawa, George Tsirtsis, Alexandru Petrescu, Vijay Devarapalli and 601 Marcelo Bagnulo were incorporated into this document. 603 7. Change Log 605 This section MUST be removed before this document is published as an 606 RFC. 608 7.1. Revision -00 610 This document is based on draft-ietf-nemo-dhcpv6-pd-03 and includes 611 the use of the DHCPv6 relay agent in the MR, as described in 612 Section 3.3, from draft-dupont-mext-dhcrelay-00. 614 7.2. Revision -01 616 Added detail in Section 4, "Security Considerations", describing 617 protection required for DHCPv6 and a mechanism for protecting traffic 618 between the DHCPv6 relay agent and server. 620 Corrected minor typos. 622 7.3. Revision -02 624 Removed text describing extensions to DHAAD for discovery of HA that 625 will provide PD. 627 Added Section 3.5, "Selecting an HA that provides DHCPv6PD," which 628 describes how an MR can discover DHCPv6PD service through polling of 629 multiple HAs. 631 Added text to Section 4, "Security Considerations", giving detail 632 about the use of IPsec. 634 7.4. Revision -04 636 Added some figures to better explaining considered topologies and 637 message exchanges. Credits to Alex Petrescu. 639 Added some text to clarify that two BUs are required, one to set up 640 the tunnel to the HA so the DHCPv6 signaling can be sent, and one to 641 register the delegated prefixes as MNPs at the HA. This updates RFC 642 3963 behavior (note added). 644 Text added to address some comments received on the MEXT mailing list 646 Corrected minor typos. 648 Enlisted Carlos J. Bernardos as co-author 650 8. References 652 8.1. Normative References 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, March 1997. 657 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 658 and M. Carney, "Dynamic Host Configuration Protocol for 659 IPv6 (DHCPv6)", RFC 3315, July 2003. 661 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 662 Host Configuration Protocol (DHCP) version 6", RFC 3633, 663 December 2003. 665 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 666 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 667 December 2003. 669 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 670 in IPv6", RFC 3775, June 2004. 672 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 673 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 674 RFC 3963, January 2005. 676 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 677 Architecture", RFC 4291, February 2006. 679 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 680 Internet Protocol", RFC 4301, December 2005. 682 8.2. Informative References 684 [I-D.ietf-dhc-dhcpv6-agentopt-delegate] 685 Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent 686 Assignment Notification (RAAN) Option", 687 draft-ietf-dhc-dhcpv6-agentopt-delegate-04 (work in 688 progress), July 2009. 690 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 691 Terminology", RFC 4885, July 2007. 693 Authors' Addresses 695 Ralph Droms 696 Cisco 697 1414 Massachusetts Avenue 698 Boxborough, MA 01719 699 USA 701 Phone: +1 978.936.1674 702 Email: rdroms@cisco.com 704 Pascal Thubert 705 Cisco 706 Village d'Entreprises Green Side 707 400, Avenue Roumanille 708 Biot - Sophia Antipolis 06410 709 FRANCE 711 Email: pthubert@cisco.com 712 Francis Dupont 713 ISC 715 Email: Francis.Dupont@fdupont.fr 717 Wassim Haddad 718 Ericsson 719 6210 Spine Road 720 Boulder, CO 80301 721 USA 723 Phone: +1 303.473.6963 724 Email: Wassim.Haddad@ericsson.com 726 Carlos J. Bernardos 727 Universidad Carlos III de Madrid 728 Av. Universidad, 30 729 Leganes, Madrid 28911 730 Spain 732 Phone: +34 91624 6236 733 Email: cjbc@it.uc3m.es 734 URI: http://www.it.uc3m.es/cjbc/