idnits 2.17.1 draft-ietf-mext-nemo-pd-07.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 : ---------------------------------------------------------------------------- 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 (December 20, 2010) is 4875 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) == Outdated reference: A later version (-13) exists of draft-ietf-mext-rfc3775bis-10 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 2 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: June 23, 2011 ISC 7 W. Haddad 8 Ericsson 9 CJ. Bernardos 10 UC3M 11 December 20, 2010 13 DHCPv6 Prefix Delegation for NEMO 14 draft-ietf-mext-nemo-pd-07 16 Abstract 18 One aspect of network mobility support is the assignment of a prefix 19 or prefixes to a mobile router for use on the links in the mobile 20 network. This document specifies how DHCPv6 prefix delegation can be 21 used for this configuration task. The mobile router plays the role 22 of requesting router, while the home agent assumes the role of 23 delegating router. When the mobile router is outside its home 24 network, the mobile router also assumes the role of DHCPv6 relay 25 agent, co-located with the requesting router function. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 23, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. DHCPv6 Prefix Delegation of Mobile Network Prefixes . . . . . 4 64 3.1. Exchanging DHCPv6 messages when the mobile router is 65 not at home . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1.1. Relay agent configuration . . . . . . . . . . . . . . 7 67 3.1.2. Transmission of DHCPv6 messages . . . . . . . . . . . 8 68 3.1.3. Receipt of DHCPv6 messages . . . . . . . . . . . . . . 8 69 3.2. Exchanging DHCPv6 messages when the mobile router is 70 at home . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.3. Selecting a home agent that provides DHCPv6PD . . . . . . 9 72 3.4. Minimizing DHCPv6PD messages . . . . . . . . . . . . . . . 10 73 3.5. Other DHCPv6 functions . . . . . . . . . . . . . . . . . . 10 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 77 7. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7.1. Revision -00 . . . . . . . . . . . . . . . . . . . . . . . 12 79 7.2. Revision -01 . . . . . . . . . . . . . . . . . . . . . . . 12 80 7.3. Revision -02 . . . . . . . . . . . . . . . . . . . . . . . 13 81 7.4. Revision -04 . . . . . . . . . . . . . . . . . . . . . . . 13 82 7.5. Revision -05 . . . . . . . . . . . . . . . . . . . . . . . 13 83 7.6. Revision -06 . . . . . . . . . . . . . . . . . . . . . . . 14 84 7.7. Revision -07 . . . . . . . . . . . . . . . . . . . . . . . 14 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 One aspect of network mobility support is the assignment of a prefix 93 or prefixes to a Mobile Router for use on the links in the NEMO. 94 DHCPv6 prefix delegation (DHCPv6PD) [RFC3633] can be used for this 95 configuration task. 97 The model of operation of DHCPv6PD for prefix delegation is as 98 follows [RFC3633]. A delegating router is provided IPv6 prefixes to 99 be delegated to requesting routers. A requesting router requests 100 prefix(es) from the delegating router. The delegating router chooses 101 prefix(es) for delegation, and responds with prefix(es) to the 102 requesting router. The requesting router is then responsible for the 103 delegated prefix(es). Note that DHCPv6 options for prefix delegation 104 defined in [RFC3633] have been defined for general use across 105 routers, and not only for mobile routers running the NEMO Basic 106 Support protocol [RFC3963]. 108 To use DHCPv6PD as prefix assignment mechanism in mobile networks, 109 when the mobile router is located at home the home agent assumes the 110 role of the delegating router and the mobile router assumes the role 111 of the requesting router. However, when the mobile router is away 112 from home, in addition to the roles when the mobile router is located 113 at home, the mobile router also assumes the role of a DHCPv6 relay 114 agent co-located with the requesting router function. 116 The DHCPv6PD server running at the home agent is provisioned with 117 prefixes to be assigned using any of the prefix assignment mechanisms 118 described in the DHCPv6PD specification [RFC3633]. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC2119 [RFC2119]. 126 The following terms used in this document are defined in the IPv6 127 Addressing Architecture document [RFC4291]: 129 Link-Local Unicast address 131 Link-Local Scope Multicast address 133 The following terms used in this document are defined in the Mobile 134 IPv6 specification [I-D.ietf-mext-rfc3775bis]: 136 Home Agent (HA) 138 Home Link 140 Home Address (HoA) 142 Care-of Address (CoA) 144 Binding Update (BU) 146 Binding Acknowledgement (BA) 148 The following terms used in this document are defined in the Mobile 149 Network terminology document [RFC4885]: 151 Mobile Router (MR) 153 Mobile Network (NEMO) 155 Mobile Network Prefix (MNP) 157 The following terms used in this document are defined in the DHCPv6 158 [RFC3315] and DHCPv6 prefix delegation [RFC3633] specifications: 160 Delegating Router (DR; acts as a DHCPv6 server) 162 Requesting Router (RR; acts as a DHCPv6 client) 164 DHCPv6 Relay Agent (DRA) 166 The following acronym is used in this document: 168 DHCPv6PD: DHCPv6 Prefix Delegation 170 3. DHCPv6 Prefix Delegation of Mobile Network Prefixes 172 The NEMO Basic Support protocol [RFC3963] extends the Mobile IPv6 173 protocol [I-D.ietf-mext-rfc3775bis] to enable network mobility. With 174 the NEMO Basic Support protocol a mobile router uses Mobile IPv6 to 175 establish and maintain a session with its home agent, and uses 176 bidirectional tunneling between the mobile router and the home agent 177 to provide a path through which nodes attached to links in the mobile 178 network can maintain connectivity with nodes not in the NEMO. 180 The requirements for Network Mobility [RFC4885] include the ability 181 of the mobile router to receive delegated prefixes that can then be 182 assigned to links in the mobile network. DHCPv6PD can be used to 183 meet this requirement for prefix delegation. 185 To use DHCPv6PD for mobile networks, when the mobile router is 186 located at home the home agent assumes the role of the delegating 187 router and the mobile router assumes the role of the requesting 188 router. However, when the mobile router is away from home, in 189 addition to the roles when the mobile router is located at home, the 190 mobile router also assumes the role of a DHCPv6 relay agent co- 191 located with the requesting router function. 193 When the mobile router is not at home, the home agent and the mobile 194 router exchange DHCPv6PD protocol messages as specified in 195 [I-D.ietf-mext-rfc3775bis]. This means that the messages sent by the 196 mobile router MUST include the Home Address destination option and 197 messages sent by the home agent MUST make use of a Routing Header 198 type 2. See Figure 1 for the deployment topologies when the MR is at 199 home and when it is visiting a foreign network. 201 ------ ------ 202 | MR |----------------| HA | 203 |(RR)| (home network) |(DR)| 204 ------ ------ 206 ------- /-----------\ ------ 207 | MR |----| Internet |-----| HA | 208 |(RR) | \-----------/ |(DR)| 209 |(DRA)| ------ 210 ------- 211 (visited network) 213 Figure 1: Deployment topologies of the use of DHCPv6PD for delegation 214 of Mobile Network Prefixes 216 The DHCPv6PD server is provisioned with prefixes to be assigned using 217 any of the prefix assignment mechanisms described in the DHCPv6PD 218 specifications. Other updates to the home agent data structures 219 required as a side effect of prefix delegation are specified by the 220 particular network mobility protocol. For example, in the case of 221 NEMO Basic Network Mobility Support [RFC3963], the HA would add an 222 entry in its binding cache registering the delegated prefix to the 223 mobile router to which the prefix was delegated. 225 3.1. Exchanging DHCPv6 messages when the mobile router is not at home 227 The case when the mobile router is away from home is described in 228 this section. Section 3.2 describes the protocol operation for the 229 case when the mobile router is attached to its home link. 231 The mobile router MUST register at the home agent (i.e., by sending a 232 Binding Update to the home agent) before initiating a DHCPv6 message 233 exchange for prefix delegation. The mobile router MUST use implicit 234 BU signaling, since the mobile router may not have yet requested any 235 prefixes. 237 If the mobile router does not have any active delegated prefixes 238 (with unexpired leases), the mobile router MUST initiate a DHCPv6 239 message exchange with a DHCPv6 Solicit message as described in 240 section 17 of [RFC3315] and section 11.1 of [RFC3633]. The 241 delegating router at the home agent responds with an Advertise 242 message. Then, the mobile router MUST request a set of prefixes by 243 sending a Request message. The delegating router includes the 244 delegated prefixes in a Reply message. Note that in this case, the 245 mobile router has previously sent a Binding Update to the home agent 246 without knowing yet the set of prefixes that it can use as mobile 247 network prefixes. The home agent, upon reception of the implicit 248 Binding Update from the mobile router, MUST select (in case this was 249 not pre-configured already) the prefixes that would then be delegated 250 to the mobile router via DHCPv6PD. The home agent, once the DHCPv6 251 signaling has been completed, MUST add an entry in its binding cache 252 including the delegated prefixes. 254 In case the mobile router has one or more active delegated prefixes 255 -- as for example if the mobile router reboots or the mobile network 256 prefix(es) currently used by the mobile router is about to expire -- 257 the mobile router MUST initiate a DHCPv6 message exchange with a 258 DHCPv6 Rebind message as described in section 18.1.2 of [RFC3315] and 259 section 12.1 of [RFC3633]. 261 A DHPCv6 relay agent function [RFC3315] MUST be used at the mobile 262 router. This relay agent function is co-located in the mobile router 263 with the DHCPv6 client function (see Figure 2). The DHCPv6 signaling 264 between the mobile router and the home agent is exchanged between the 265 DHCPv6 relay agent in the mobile router and the DHCPv6 server on the 266 home agent. DHCPv6 messages from the mobile router to the home agent 267 are unicast packets sent from the unicast home address of the mobile 268 router to the global unicast address of the home agent, and therefore 269 the Home Address destination option MUST be used. DHCPv6 replies 270 from the home agent to the mobile router MUST be sent using the 271 Routing Header type 2, as specified in [I-D.ietf-mext-rfc3775bis]. 272 The DHCPv6 client in the mobile router MUST hand any outbound DHCPv6 273 messages to the co-located relay agent. Responses from the DHCPv6 274 server are delivered to the relay agent function in the mobile 275 router, which MUST extract the encapsulated message and deliver it to 276 the DHCPv6 client in the mobile router. 278 ----------------------------- -------- 279 | MR | | HA | 280 | (RR) (DRA) | | (DR) | 281 ---------------------------- -------- 282 | | Binding Update | 283 | |------------------------>| 284 | | (HoA, CoA) | 285 | | | 286 | | Binding Ack | 287 | |<------------------------| 288 | | | 289 | DHCPv6 Solicit | DHCPv6 Solicit | 290 |..................>|--=====================->| 291 | | | 292 | DHCPv6 Advertise | DHCPv6 Advertise | 293 |<..................|<-=====================--| 294 | | | 295 | DHCPv6 Request | DHCPv6 Request | 296 |..................>|--=====================->| 297 | | | 298 | DHCPv6 Reply | DHCPv6 Reply | 299 |<..................|<-=====================--| 300 | | (Mobile Network Prefix) | 301 | | | 303 Figure 2: Signaling sequence when the mobile router is not at home 305 Note that a mobile router using DHCPv6PD to obtain the set of 306 prefixes to be used as mobile network prefixes cannot derive its home 307 address from one of its mobile network prefix(es) (as the mobile 308 router does not know them before registering to the home agent). 309 Therefore, the mobile router MUST assign its home address from the 310 prefix on its Home Link. 312 3.1.1. Relay agent configuration 314 The use of the relay agent function in the mobile router allows the 315 mobile router to unicast DHCPv6 messages to the DHCPv6 server. The 316 relay agent MUST be configured with the address of the DHCPv6 server. 317 For the purposes of this specification, the relay agent assumes that 318 the home agent for the mobile router hosts the DHCPv6 server. 319 Therefore, the mobile router MUST configure the DHCPv6 relay agent to 320 forward DHCPv6 messages to the home agent. 322 The DHCPv6 specification supports in certain scenarios the use of 323 unicast between the client and the server. However its use presents 324 some difficulties, as the client has to first receive a Server 325 Unicast option (section 22.12 of [RFC3315]) from the server, which 326 means that a Solicit/Advertise message exchange is required in 327 advance. That signaling exchange would require the presence of a 328 relay agent on the mobile router, and therefore little gain would be 329 achieved in this case from the use of the Server Unicast option. 331 3.1.2. Transmission of DHCPv6 messages 333 When the DHCPv6 client in the mobile router sends a message, it MUST 334 hand the message to the DHCPv6 relay agent in the mobile router. The 335 way in which the message is passed to the DHCP relay agent is beyond 336 the scope of this document. The relay agent encapsulates the message 337 from the client according to [RFC3315] in a Relay-forward message and 338 sends the resulting DHCPv6 message to the home agent. The relay 339 agent sets the fields in the Relay-forward message as follows: 341 msg-type RELAY-FORW 343 hop-count 1 345 link-address The home address of the mobile router 347 peer-address The home address of the mobile router 349 options MUST include a "Relay Message option" [RFC3315]; MAY 350 include other options added by the relay agent. 352 3.1.3. Receipt of DHCPv6 messages 354 Messages from the DHCPv6 server will be returned to the DHCPv6 relay 355 agent, with the message for the DHCPv6 client encapsulated in the 356 Relay Message option [RFC3315] in a Relay-reply message. The relay 357 agent function MUST extract the message for the client from the Relay 358 Message option and hand the message to the DHCPv6 client in the 359 mobile router. The way in which the message is passed to the client 360 is beyond the scope of this document. 362 3.2. Exchanging DHCPv6 messages when the mobile router is at home 364 When the mobile router is on its home link, the home agent MUST use 365 the home link to exchange DHCPv6PD messages with the mobile router 366 (Figure 3). In this case, the DHCPv6 co-located relay function MUST 367 be disabled. It is the responsibility of the implementation to 368 determine when the mobile router is on its home link. The Home Link 369 Detection mechanism is described in the section 11.5.2 of 370 [I-D.ietf-mext-rfc3775bis]. 372 -------- -------- 373 | MR | | HA | 374 | (RR) | | (DR) | 375 -------- -------- 376 | | 377 | DHCPv6 Solicit | 378 |------------------------>| 379 | | 380 | DHCPv6 Advertise | 381 |<------------------------| 382 | | 383 | DHCPv6 Request | 384 |------------------------>| 385 | | 386 | DHCPv6 Reply | 387 |<------------------------| 388 | (Mobile Network Prefix) | 389 | | 391 Figure 3: Signaling sequence for the case the home agent is at home 393 3.3. Selecting a home agent that provides DHCPv6PD 395 Not all nodes that are willing to act as a home agent are required to 396 provide DHCPv6PD. Therefore, when selecting a home agent, a mobile 397 router that requires DHCPv6PD service MUST identify a home agent that 398 will provide the service. The mobile router can determine if a home 399 agent provides DHCPv6PD by initiating a DHCPv6 message exchange 400 (i.e., sending a Solicit message) in which the mobile router requests 401 delegated prefix(es). If the home agent does not respond or responds 402 but does not delegate any prefix(es) in its response, the mobile 403 router assumes that the home agent does not provide DHCPv6PD service. 404 The mobile router continues to query all candidate home agents until 405 it finds one that provides DHCPv6PD. Note that in this particular 406 case and if the mobile router is away from home, the mobile router 407 has to have already performed a Mobile IPv6 registration with the 408 home agent it queries. 410 Querying a home agent to determine if it provides DHCPv6PD requires 411 different operational variables than those recommended by the DHCPv6 412 specification. [RFC3315] recommends that under normal circumstances, 413 a host will continue to send DHCPv6 Solicit messages until it 414 receives a response (see Section 17 of [RFC3315]), i.e., the Maximum 415 Retransmission Duration (MRD) and Maximum Retransmission Count (MRC) 416 are both set to zero. However, a home agent may not respond to the 417 Solicit messages from the mobile router because the home agent does 418 not support DHCPv6 prefix delegation. Therefore, when querying a 419 home agent to determine if the home agent provides DHCPv6PD service, 420 it is RECOMMENDED that MRD and MRC be set to non-zero values so that 421 the mobile router discontinues sending Solicit messages to the home 422 agent after sending 6 Solicit messages, and conclude that the home 423 agent will not provide DHCPv6PD service. Sending 6 queries provides 424 enough reliability for scenarios in which the wireless connectivity 425 is lost for a short period after sending the first Binding Update 426 message. 428 It is RECOMMENDED that the mobile router uses a sequential probing of 429 the home agents for DHCPv6PD service. 431 3.4. Minimizing DHCPv6PD messages 433 The use DHCPv6PD in a mobile network can be combined with the Rapid 434 Commit option [RFC3315] to provide DHCPv6 prefix delegation with a 435 two message exchange between the mobile router and the DHCPv6PD 436 delegating router. 438 3.5. Other DHCPv6 functions 440 The DHCPv6 messages exchanged between the mobile router and the home 441 agent MAY also be used for other DHCPv6 functions in addition to 442 DHCPv6PD. For example, the home agent MAY assign global addresses to 443 the mobile router and MAY pass other configuration information such 444 as a list of available DNS recursive name servers [RFC3646] to the 445 mobile router using the same DHCPv6 messages as used for DHCPv6PD. 447 The home agent MAY act as a DHCPv6 relay agent for mobile nodes while 448 it acts as a delegating router for mobile routers. 450 4. Security Considerations 452 This document describes the use of DHCPv6 for prefix delegation in 453 mobile networks. In addition to the security considerations for 454 DHCPv6 described in the "Security Considerations" section of the 455 DHCPv6 base specification [RFC3315] and the "Security Considerations" 456 of the DHCPv6 Prefix Delegation specification [RFC3633], there are 457 two aspects that need to be considered. 459 First, the NEMO Basic Support specification requires the home agent 460 to prevent a mobile router from claiming mobile network prefixes 461 belonging to another mobile router. Upon reception of an implicit 462 Binding Update from a mobile router, the home agent MUST only add 463 prefixes into the mobile router's Binding Cache Entry if the mobile 464 router has a valid DHCPv6 Prefix Delegation lease for said prefixes. 465 If the mobile router does not have a valid DHCPv6 Prefix Delegation 466 lease, the home agent MUST NOT add any prefixes into the mobile 467 router's Binding Cache Entry. Upon the mobile router obtaining a 468 valid DHCPv6 Prefix Delegation lease for a given set of prefixes, the 469 home agent MUST add these prefixes to the mobile router's Binding 470 Cache Entry. This avoids the home agent forwarding traffic addressed 471 to prefixes that have not been yet delegated to the mobile router. 473 The use of DHCPv6, as described in this document, requires message 474 integrity protection and source authentication. When the mobile 475 router is at home, normal DHCPv6 operation is used between the mobile 476 router and the home agent and therefore this specification does not 477 add any new security issue. While the mobile router is away from 478 home, the IPsec security mechanism mandated by Mobile IPv6 [RFC3776] 479 MUST be used to secure the DHCPv6 signaling. In the following, we 480 describe the Security Policy Database (SPD) and Security Association 481 Database (SAD) entries necessary to protect the DHCPv6 signaling. We 482 use the same format used by [RFC4877]. The SPD and SAD entries are 483 only example configurations. A particular mobile router 484 implementation and a home agent implementation could configure 485 different SPD and SAD entries as long as they provide the required 486 security of the DHCPv6 signaling messages. 488 For the examples described in this document, a mobile router with 489 home address "home_address_1", and a home agent with address 490 "home_agent_1" are assumed. If the home address of the mobile router 491 changes, the SPD and SAD entries need to be re-created or updated for 492 the new home address. 494 mobile router SPD-S: 495 - IF local_address = home_address_1 & 496 remote_address = home_agent_1 & proto = UDP & 497 local_port = any & remote_port = DHCP 498 Then use SA1 (OUT) and SA2 (IN) 500 mobile router SAD: 501 - SA1(OUT, spi_a, home_agent_1, ESP, TRANSPORT): 502 local_address = home_address_1 & 503 remote_address = home_agent_1 & 504 proto = UDP & remote_port = DHCP 505 - SA2(IN, spi_b, home_address_1, ESP, TRANSPORT): 506 local_address = home_agent_1 & 507 remote_address = home_address_1 & 508 proto = UDP & local_port = DHCP 510 home agent SPD-S: 511 - IF local_address = home_agent_1 & 512 remote_address = homa_address_1 & proto = UDP & 513 local_port = DHCP & remote_port = any 514 Then use SA2 (OUT) and SA1 (IN) 516 home agent SAD: 517 - SA2(OUT, spi_b, home_address_1, ESP, TRANSPORT): 518 local_address = home_agent_1 & 519 remote_address = home_address_1 & 520 proto = UDP & local_port = DHCP 521 - SA1(IN, spi_a, home_agent_1, ESP, TRANSPORT): 522 local_address = home_address_1 & 523 remote_address = home_agent_1 & 524 proto = UDP & remote_port = DHCP 526 5. IANA Considerations 528 This document describes the use of DHCPv6 for prefix delegation in 529 mobile networks. It does not introduce any additional IANA 530 considerations. 532 6. Acknowledgments 534 The authors would like to thank people who have given valuable 535 comments on the mailing list. Specific suggestions from Ryuji 536 Wakikawa, George Tsirtsis, Alexandru Petrescu, Vijay Devarapalli and 537 Marcelo Bagnulo were incorporated into this document. 539 The authors would like to thank Julien Laganier, Michaela Vanderveen 540 and Jean-Michel Combes for their review of previous versions of this 541 document. 543 7. Change Log 545 This section MUST be removed before this document is published as an 546 RFC. 548 7.1. Revision -00 550 This document is based on draft-ietf-nemo-dhcpv6-pd-03 and includes 551 the use of the DHCPv6 relay agent in the MR from 552 draft-dupont-mext-dhcrelay-00. 554 7.2. Revision -01 556 Added detail in Section 4, "Security Considerations", describing 557 protection required for DHCPv6 and a mechanism for protecting traffic 558 between the DHCPv6 relay agent and server. 560 Corrected minor typos. 562 7.3. Revision -02 564 Removed text describing extensions to DHAAD for discovery of HA that 565 will provide PD. 567 Added Section 3.3, "Selecting an HA that provides DHCPv6PD," which 568 describes how an MR can discover DHCPv6PD service through polling of 569 multiple HAs. 571 Added text to Section 4, "Security Considerations", giving detail 572 about the use of IPsec. 574 7.4. Revision -04 576 Added some figures to better explaining considered topologies and 577 message exchanges. Credits to Alex Petrescu. 579 Added some text to clarify that two BUs are required, one to set up 580 the tunnel to the HA so the DHCPv6 signaling can be sent, and one to 581 register the delegated prefixes as MNPs at the HA. This updates RFC 582 3963 behavior (note added). 584 Text added to address some comments received on the MEXT mailing list 586 Corrected minor typos. 588 Enlisted Carlos J. Bernardos as co-author 590 7.5. Revision -05 592 Only implicit BU mode supported. 594 Only DHCPv6 relay agent in the MR co-located with the DHCPv6 client 595 function is supported as mode of operation when the MR is away from 596 home. 598 Security considerations include now the issue of the HA enforcing 599 that the MR registers the prefixes that were delegated to it via 600 DHCPv6PD. 602 Since [I-D.ietf-mext-rfc3775bis] specifies that MR and HA operate in 603 RO mode when sending traffic between them, the term tunnel has been 604 removed. 606 Some typos detected and corrected. 608 7.6. Revision -06 610 Some nits fixed. 612 7.7. Revision -07 614 Fixes and clarifying text as suggested during IESG review. 616 8. References 618 8.1. Normative References 620 [I-D.ietf-mext-rfc3775bis] 621 Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 622 in IPv6", draft-ietf-mext-rfc3775bis-10 (work in 623 progress), October 2010. 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, March 1997. 628 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 629 and M. Carney, "Dynamic Host Configuration Protocol for 630 IPv6 (DHCPv6)", RFC 3315, July 2003. 632 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 633 Host Configuration Protocol (DHCP) version 6", RFC 3633, 634 December 2003. 636 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 637 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 638 December 2003. 640 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 641 Protect Mobile IPv6 Signaling Between Mobile Nodes and 642 Home Agents", RFC 3776, June 2004. 644 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 645 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 646 RFC 3963, January 2005. 648 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 649 Architecture", RFC 4291, February 2006. 651 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 652 IKEv2 and the Revised IPsec Architecture", RFC 4877, 653 April 2007. 655 8.2. Informative References 657 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 658 Terminology", RFC 4885, July 2007. 660 Authors' Addresses 662 Ralph Droms 663 Cisco 664 1414 Massachusetts Avenue 665 Boxborough, MA 01719 666 USA 668 Phone: +1 978.936.1674 669 Email: rdroms@cisco.com 671 Pascal Thubert 672 Cisco 673 Village d'Entreprises Green Side 674 400, Avenue Roumanille 675 Biot - Sophia Antipolis 06410 676 FRANCE 678 Email: pthubert@cisco.com 680 Francis Dupont 681 ISC 683 Email: Francis.Dupont@fdupont.fr 685 Wassim Haddad 686 Ericsson 687 6210 Spine Road 688 Boulder, CO 80301 689 USA 691 Phone: +1 303.473.6963 692 Email: Wassim.Haddad@ericsson.com 693 Carlos J. Bernardos 694 Universidad Carlos III de Madrid 695 Av. Universidad, 30 696 Leganes, Madrid 28911 697 Spain 699 Phone: +34 91624 6236 700 Email: cjbc@it.uc3m.es 701 URI: http://www.it.uc3m.es/cjbc/