idnits 2.17.1 draft-ietf-netext-pd-pmip-09.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 date (June 18, 2013) is 3958 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) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG X. Zhou 3 Internet-Draft ZTE Corporation 4 Intended status: Standards Track J. Korhonen 5 Expires: December 20, 2013 Renesas Mobile 6 C. Williams 7 Consultant 8 S. Gundavelli 9 Cisco 10 CJ. Bernardos 11 UC3M 12 June 18, 2013 14 Prefix Delegation Support for Proxy Mobile IPv6 15 draft-ietf-netext-pd-pmip-09 17 Abstract 19 This specification defines extensions to Proxy Mobile IPv6 protocol 20 for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain 21 delegated IP prefixes for its attached mobile networks. The mobility 22 entities in the network will provide network-based mobility 23 management support for those delegated IP prefixes just as how IP 24 mobility support is provided for the mobile node's home address. 25 Even as the mobile router performs a handoff and changes its network 26 point of attachment, mobility support is ensured for all the 27 delegated IP prefixes and for all the IP nodes in the mobile network 28 that use IP address configuration from those delegated IP prefixes. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 20, 2013. 47 Copyright Notice 48 Copyright (c) 2013 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 Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Convention and Terminology . . . . . . . . . . . . . . . . . . 5 65 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 7 67 3.2. Deployment Models . . . . . . . . . . . . . . . . . . . . 7 68 3.2.1. Delegating Router Co-located with Mobile Access 69 Gateway . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.2.2. Delegating Router Co-located with Local Mobility 71 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.2.3. Static Configuration of Delegated Mobile Network 73 Prefixes . . . . . . . . . . . . . . . . . . . . . . . 9 74 4. Message formats . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.1. Delegated Mobile Network Prefix Option . . . . . . . . . . 11 76 4.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 12 77 5. Operational Details . . . . . . . . . . . . . . . . . . . . . 13 78 5.1. MAG Considerations . . . . . . . . . . . . . . . . . . . . 13 79 5.1.1. Extension to Binding Update List Entry Data 80 Structure . . . . . . . . . . . . . . . . . . . . . . 13 81 5.1.2. Signaling Considerations . . . . . . . . . . . . . . . 13 82 5.1.3. Packet Forwarding . . . . . . . . . . . . . . . . . . 18 83 5.2. LMA Considerations . . . . . . . . . . . . . . . . . . . . 18 84 5.2.1. Extensions to Binding Cache Entry Data Structure . . . 18 85 5.2.2. Signaling Considerations . . . . . . . . . . . . . . . 18 86 5.2.3. Packet Forwarding . . . . . . . . . . . . . . . . . . 20 87 5.3. Security Policy Database (SPD) Example Entries . . . . . . 21 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 96 1. Introduction 98 Proxy Mobile IPv6 [RFC5213] enables network-based mobility management 99 support for an IP host without requiring its participation in any IP 100 mobility signaling. The mobility elements in the network allow an IP 101 host to obtain an IPv4 address and/or a set of IPv6 addresses and be 102 able to obtain IP mobility support for those IP address(es) within 103 the Proxy Mobile IPv6 domain. In this context, the mobility 104 management support that is enabled is for an individual IP host, 105 which is the mobile node. The IPv4 home address, or the IPv6 home 106 network prefixes are logically bound to the link shared between the 107 mobile access gateway and the mobile node and only the mobile node 108 can use those IP address(es) by configuring them on the interface 109 attached to that link. Currently, there is no mobility support for 110 the mobile networks attached to a mobile router in a Proxy Mobile 111 IPv6 domain. 113 This specification defines extensions to the Proxy Mobile IPv6 114 protocol for allowing mobility support to the mobile networks 115 attached to a mobile router. The mobile router can request the 116 mobility entities in the Proxy Mobile IPv6 domain for one or more 117 delegated IP prefixes using DHCP Prefix Delegation extensions 118 [RFC3633], or through other mechanisms outside the scope of this 119 document. The mobility entities in the network will provide network- 120 based mobility management support for those delegated prefixes just 121 as how mobility is supported for an home address. The delegated 122 prefixes are hosted in the mobile network attached to the mobile 123 router. IP mobility is ensured for all the IP nodes in the mobile 124 network, even as the mobile router performs a handoff by changing its 125 point of network attachment within the Proxy Mobile IPv6 domain. The 126 local mobility anchor in the Proxy Mobile IPv6 domain will not track 127 the individual IP sessions for all the IP nodes in the mobile 128 network, it only tracks a single mobile router session that is 129 hosting the mobile network and associates the delegated IP prefixes 130 with that session. 132 _----_ 133 +-------+ _( )_ 134 | |---( Internet ) 135 | LMA | (_ _) 136 | | '----' 137 +-------+ 138 | 139 === === === 140 == Proxy == 141 == Mobile IPv6 == 142 == Domain == 143 === === === 144 ___________|___________ 145 | | 146 +-------+ +-------+ 147 | MAG | | MAG | 148 +-------+ +-------+ 149 . 150 . 151 - - - - - - - - 152 | +------+ | 153 | | MR | | 154 | +------+ | 155 | | | 156 | ------- | 157 | | | | 158 | LFN LFN | 159 - - - - - - - - 161 Figure 1: Mobile Router in Proxy Mobile IPv6 Domain 163 Within the context of this document, the definition of a mobile 164 router extends that of a mobile node definition from [RFC5213], by 165 adding routing capability for routing IP packets between its egress 166 interface (interface used for attachment to the mobile access 167 gateway) and any of its ingress interfaces (interface used for 168 attachment to the mobile network). The network of nodes part of the 169 mobile network are referred to as locally fixed nodes (LFN) and they 170 all move with the mobile router as a single cluster. As the mobile 171 router moves, the LFNs are not aware of the mobility of the MR to a 172 new MAG. Figure 1 illustrates a mobile router in a Proxy Mobile IPv6 173 domain. 175 The rest of the document identifies the protocol extensions and the 176 operational details of the local mobility anchor and mobile access 177 gateway for supporting this specification. 179 2. Convention and Terminology 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 All the mobility related terms used in this document are to be 186 interpreted as defined in Proxy Mobile IPv6 specifications [RFC5213] 187 and [RFC5844]. All the DHCP related terms are to be interpreted as 188 defined in DHCPv6-PD for NEMO [RFC6276], DHCPv6-PD [RFC3633] and 189 Subnet Allocation Option for DHCPv4 [RFC6656]. This document also 190 provides a context-specific explanation to the following terms used 191 in this document. 193 Mobile Router (MR) 195 The term mobile router is used to refer to an IP router whose 196 mobility is managed by the network while being attached to a Proxy 197 Mobile IPv6 domain. The mobile router is a mobile node as defined 198 in [RFC5213], but with additional capabilities for supporting an 199 attached mobile network. The mobility entities in the Proxy 200 Mobile IPv6 domain provide mobility for the IPv4/IPv6 address(es) 201 assigned to the mobile node's egress link and also mobility 202 support to the network prefixes hosted in the network attached to 203 the mobile router. 205 Mobile Network 207 It is an IP network attached to a mobile router. There can be 208 many IP nodes in this IP network. The mobile router is a gateway 209 for these IP nodes for reaching other IP networks or the Internet. 210 The mobile router and the attached IP networks move as a single 211 cluster. 213 Delegated Mobile Network Prefix (DMNP) 215 The Delegated Mobile Network Prefix is an IPv4/IPv6 prefix 216 delegated to a mobile router and is hosted in the mobile network. 217 The IP nodes in the mobile network will be able to obtain IP 218 address configuration from the delegated mobile network prefix and 219 will have IP mobility support for that address configuration. The 220 DMNP is topologically anchored on the local mobility anchor and 221 the mobility elements in the Proxy Mobile IPv6 domain provide IP 222 mobility support for the prefix, by forwarding the mobile network 223 traffic to the mobile router. 225 Locally Fixed Node (LFN) 226 A Locally Fixed Node is an IP node in the mobile network. As the 227 mobile router performs a handoff and changes its network point of 228 attachement, the locally fixed node moves along with the mobile 229 router. 231 3. Solution Overview 233 This section provides an overview of the operation of this 234 specification, as well as lists the stated assumptions. This 235 specification references three different deployment scenarios and 236 explains the protocol operation. 238 3.1. Stated Assumptions 240 o The mobile router is a mobile node as defined in [RFC5213], but 241 with additional capabilities for routing IP packets between its 242 egress interface (interface used for attachment to the mobile 243 access gateway) and any of its ingress interfaces (interface used 244 for attachment to the mobile network). 246 o The specification assumes that a mobile router is an IPv4 and/or 247 IPv6 router without any capability for mobility management. 249 o The mobile router can obtain the delegated IP prefix(es) for its 250 attached mobile networks using DHCPv6, or using mechanisms outside 251 of this document (Example: Static Configuration, or access 252 technology specific mechanisms). This document makes no 253 assumption on the support of any one specific approach. However, 254 it explains the protocol operation using DHCPv6-based prefix 255 delegation as specified in [RFC3633] and with the use of Prefix 256 Exclude Option for DHCPv6-PD as described in [RFC6603]. It 257 defines an interworking between the mobility entities and the 258 DHCPv6 functional elements in a non-normative way. 260 o The mobile router obtains the IP address configuration for its 261 egress roaming interface as specified in [RFC5213] and [RFC5844]. 262 The mobile router along with its mobile networks will be able to 263 perform handoff and change its point of attachment in the network 264 and will be able to retain IP mobility support. 266 3.2. Deployment Models 268 This section explains the protocol operation for supporting prefix 269 delegation support in Proxy Mobile IPv6 for the following three 270 deployment_models. The high-level message call flows between the 271 mobile router, mobile access gateway and the local mobility anchor 272 are presented. 274 3.2.1. Delegating Router Co-located with Mobile Access Gateway 276 o The delegating router (DR) function, as specified in [RFC3633], is 277 co-located with the mobile access gateway. 279 o The requesting router (RR) function, as specified in [RFC3633], is 280 enabled on the mobile router. 282 +-----+ +-----+ +-----+ 283 | MR | | MAG | | LMA | 284 |(RR) | | (DR)| | | 285 +-----+ +-----+ +-----+ 286 1) |-- MN Attach -----| | 287 | |--------- PBU ----------->| 288 | | | 289 | |<-------- PBA ------------| 290 | | | 291 | |o========================o| 292 2) | | PMIPv6 tunnel | 293 | |o========================o| 294 3) |-- Solicit for -->| | 295 | delegated prefix | | 296 4) | |----------PBU------------>| 297 | | | 298 5) | |<---------PBA (DMNP)------| 299 | | | 300 - -<---+ | 301 6) |<- Advertise -----| | | 302 | | | | 303 7) |-- Request ------>| Optional | 304 | | | | 305 - -<---+ | 306 8) |<-- Reply (DMNP) -| | 307 | | | 308 | | | 310 Figure 2: Delegating Router Co-located with Mobile Access Gateway 312 3.2.2. Delegating Router Co-located with Local Mobility Anchor 314 o The delegating router (DR) function, as specified in [RFC3633], is 315 co-located with the local mobility anchor. 317 o A DHCPv6 Relay Agent (DRA) function, as specified in [RFC3315], is 318 co-located on the mobile access gateway. 320 o The requesting router (RR) function, as specified in [RFC3633], is 321 enabled on the mobile router. 323 +-----+ +-----+ +-----+ 324 | MR | | MAG | | LMA | 325 |(RR) | |(DRA)| |(DR) | 326 +-----+ +-----+ +-----+ 327 1) |-- MN Attach -----| | 328 | |--------- PBU ----------->| 329 | | | 330 | |<-------- PBA ------------| 331 | | | 332 | |o========================o| 333 2) | | PMIPv6 tunnel | 334 | |o========================o| 335 3) |-- Solicit for -->| | 336 | delegated prefix | | 337 4) | |--- Solicit ------------->| 338 - - - <---+ 339 5) | |<-- Advertise ------------| | 340 | | | | 341 6) |<- Advertise -----| | | 342 | | | Optional 343 7) |-- Request ------>| | | 344 | | | | 345 8) | |--- Request ------------->| | 346 - - - <---+ 347 9) | |<-- Reply (DMNP) ---------| 348 | | | 349 10) | |----------PBU (DNMP)----->| 350 | | | 351 11) | |<---------PBA (DMNP)------| 352 | | | 353 12) |<-- Reply (DMNP) -| | 354 | | | 356 Figure 3: Delegating Router Co-located with Local Mobility Anchor 358 3.2.3. Static Configuration of Delegated Mobile Network Prefixes 360 o The delegated mobile network prefixes of the mobile router are 361 statically configured in the mobile node's policy profile 362 [RFC5213]. 364 o The delegated mobile network prefixes are statically configured in 365 the mobile network attached to the mobile router. The mobile 366 router is the default-router for the mobile networks. 368 o The mobile access gateway obtains statically configured mobile 369 network prefixes from the policy profile and registers them with 370 the local mobility anchor using the extensions specified in this 371 document. There is no explicit trigger from the mobile router 372 from registering, or de-registering those prefixes. As long as 373 there is a mobility session for the mobile router's home address, 374 the local mobility anchor enables mobility support for the mobile 375 network prefixes. 377 +-----+ +-----+ +-----+ 378 | MR | | MAG | | LMA | 379 | | | | | | 380 +-----+ +-----+ +-----+ 381 1) |-- MN Attach -----| | 382 2) | - (Policy Profile) | 383 | | | 384 3) | |--------- PBU (DMNP) ---->| 385 | | | 386 4) | |<-------- PBA (DMNP) -----| 387 | | | 388 | |o========================o| 389 5) | | PMIPv6 tunnel | 390 | |o========================o| 391 | | | 393 Figure 4: Static Configuration of Delegated Mobile Network Prefixes 395 4. Message formats 397 This section defines extensions to Proxy Mobile IPv6 [RFC5213] 398 protocol messages. 400 4.1. Delegated Mobile Network Prefix Option 402 A new mobility header option, Delegated Mobile Network Prefix option 403 is defined for use with Proxy Binding Update and Proxy Binding 404 Acknowledgment messages exchanged between a local mobility anchor and 405 a mobile access gateway. This option is used for exchanging the 406 mobile router's IPv4/IPv6 delegated mobile network prefix. There can 407 be multiple instances of the Delegated Mobile Network Prefix option 408 present in a message. 410 The Delegated Mobile Network Prefix option has an alignment 411 requirement of 8n+2. Its format is as follows: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length |V| Reserved | Prefix Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | | 419 + + 420 | | 421 . . 422 + IPv4 or IPv6 Delegated Mobile Network Prefix + 423 | (DMNP) | 424 + + 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Type 430 : To be assigned by IANA. 432 Length 434 8-bit unsigned integer indicating the length of the option in 435 octets, excluding the type and length fields. 437 IPv4 Prefix (V) 439 If the IPv4 Prefix (V) flag is set to a value of (1), then it 440 indicates that the prefix that is included in the DMNP field is an 441 IPv4 prefix. If the IPv4 Prefix (V) flag is set to a value of 442 (0), then it indicates that the prefix that is included in the 443 DMNP field is an IPv6 prefix. 445 Reserved 447 This field is unused for now. The value MUST be initialized to 0 448 by the sender and MUST be ignored by the receiver. 450 Prefix Length 452 8-bit unsigned integer indicating the prefix length of the prefix 453 contained in the option. 455 Delegated Mobile Network Prefix 457 Contains a mobile router's 4-byte IPv4 or a 16-byte IPv6 Delegated 458 Mobile Network Prefix. 460 4.2. Status Codes 462 This document defines the following new status code values for use in 463 the Proxy Binding Acknowledgement message. These values have been 464 allocated from the same number space as defined in Section 6.1.8 of 465 [RFC6275]. 467 NOT_AUTHORIZED_FOR_DELEGATED_MNP: 469 Not Authorized for delegated mobile network prefix 471 REQUESTED_DMNP_IN_USE: 473 Requested delegated mobile network prefix is in use 475 5. Operational Details 477 5.1. MAG Considerations 479 5.1.1. Extension to Binding Update List Entry Data Structure 481 In order to support this specification, the conceptual Binding Update 482 List Entry (BULE) data structure [RFC5213] needs to be extended to 483 include delegated mobile network prefix (DMNP) list. Each entry in 484 the list is used for storing an IPv4/IPv6 mobile network prefix 485 delegated to the mobile router. 487 5.1.2. Signaling Considerations 489 o The mobile node's policy profile defined in [RFC5213] is extended 490 to include a parameter which indicates Delegated Prefix support. 491 During the mobile router's initial attachment procedure, the 492 mobile access gateway obtains the mobile router's policy profile, 493 as per the procedures defined in [RFC5213]. If the policy profile 494 indicates that the mobile router is authorized for Delegated 495 Prefix support, then the following considerations apply. 497 o For requesting the local mobility anchor to allocate delegated 498 mobile network prefix(es) for the mobile router, the mobile access 499 gateway MUST include one or more Delegated Mobile Network Prefix 500 (DMNP) options in the Proxy Binding Update message. 502 * There MUST be exactly one instance of the Delegated Mobile 503 Network Prefix option with ALL_ZERO value and with the (V) flag 504 set to a value of (0). This serves as a request to the local 505 mobility anchor to allocate a set of delegated IPv6 mobile 506 network prefixes. 508 * There MUST be exactly one instance of the Delegated Mobile 509 Network Prefix option with ALL_ZERO value and with the (V) flag 510 set to a value of (1). This serves as a request to the local 511 mobility anchor to allocate a set of delegated IPv4 mobile 512 network prefixes. 514 * There MUST be exactly one instance of the Delegated Mobile 515 Network Prefix option with NON_ZERO prefix value for each of 516 the mobile network prefixes that the mobile access gateway is 517 requesting the local mobility anchor to allocate. The prefix 518 value in the option is the prefix that is either statically 519 configured for that mobile router in the mobile node's policy 520 profile, or obtained via interactions with the DHCP PD 521 functions. This serves as a request to the local mobility 522 anchor to allocate the requested IPv4/IPv6 prefix. 524 o If the received Proxy Binding Acknowledgement message has the 525 status field value set to NOT_AUTHORIZED_FOR_DELEGATED_MNP (Not 526 Authorized for delegated mobile network prefix), the mobile access 527 gateway MUST NOT enable mobility support for any of the prefixes 528 in the mobile network and prefix delegation support has to be 529 disabled. 531 o If the received Proxy Binding Acknowledgement message has the 532 status field value set to REQUESTED_DMNP_IN_USE (Requested 533 delegated mobile network prefix is in use), the mobile access 534 gateway MUST NOT enable mobility support for the requested 535 prefixes. The mobile access gateway MAY choose to send Proxy 536 Binding Acknowledgement message requesting the local mobility 537 anchor to perform the prefix assignment. 539 o If the received Proxy Binding Acknowledgement message has the 540 status field value set to 0 (Proxy Binding Update accepted), the 541 mobile access gateway has to apply the following considerations. 543 * The delegated mobile network prefix (DMNP) list in the mobile 544 router's Binding Update List entry has to be updated with the 545 allocated prefix(es). However, if the received message was in 546 response to a de-registration request with a lifetime value of 547 (0), then the delegated mobile network prefix list has to be 548 removed along with the Binding Update List entry. 550 * The mobile access gateway has to set up a policy-based route 551 for forwarding the IP packets received from the mobile network 552 (with the source IP address from any of the delegated IPv4/IPv6 553 mobile network prefixes) through the bidirectional tunnel set 554 up for that mobile router. However, if the received message 555 was in response to a de-registration request with a lifetime 556 value of (0), then the created forwarding state has to be 557 removed. 559 5.1.2.1. DHCP - MAG Interactions 561 This section describes the interactions between the DHCP and PMIPv6 562 logical entities running on the mobile access gateway. This section 563 is applicable only for deployments that use DHCPv6-based prefix 564 delegation. As described next, these interactions vary slightly 565 depending on the considered deployment model at the mobile access 566 gateway (described in Section 3.2). 568 The mobile router, acting as a "Requesting Router" as described in 569 [RFC3633], sends a SOLICIT message including one or more IA_PD 570 option(s) to the Delegating Router/DHCPv6 Relay Agent collocated on 571 the mobile access gateway. This message provides the needed trigger 572 for the mobile access gateway for requesting the local mobility 573 anchor to enable delegated mobile network prefix support for that 574 mobility session. 576 o Delegating router co-located with mobile access gateway 578 * The mobile access gateway applies the considerations in 579 Section 5.1.2 for requesting the local mobility anchor to 580 enable delegated prefix support. For example, if the mobile 581 router is soliciting an IPv4 prefix, the mobile access gateway 582 includes in the Proxy Binding Update signaling a Delegated 583 Mobile Network Prefix option with ALL_ZERO value and with the 584 (V) flag set to a value of (1). 586 * The mobile access gateway, upon successfully completing the 587 Proxy Binding Update signaling with the local mobility anchor 588 (following the considerations described in Section 5.1.2), adds 589 the delegated mobile network prefixes to the binding update 590 list. Then, the mobile access gateway provides the obtained 591 prefixes to the DHCPv6 Delegating Router for prefix assignment. 592 The way in which the mobile access gateway provides the DHCPv6 593 Delegating Router with this information is beyond the scope of 594 this document. 596 + In case the Proxy Binding Update signaling with the local 597 mobility anchor is not completed successfully, for example 598 because the local mobility anchor is not authorized for 599 delegated mobile network prefix or the requested prefix is 600 in use, the DHCPv6 Delegating Router will send a Reply 601 message to the Requesting Router containing the IA_PD with 602 the lifetimes of the prefixes in the IA_PD set to zero. 604 * The standard DHCPv6 considerations will be applied with respect 605 to the interactions between the Delegating Router and the 606 Requesting Router. The Delegating Router is provided with the 607 delegated prefix(es), which can then be then advertised in the 608 mobile network, and therefore used by the locally fixed nodes 609 to auto configure IP addresses allowing to gain access to the 610 Internet. 612 * Any time, the Requesting Router releases the delegated 613 prefixes, the Delegating Router removes the assigned prefixes. 614 To do so, the mobile access gateway will send an Updated Proxy 615 Binding Update following the considerations described in 616 Section 5.1.2 for deregistering those prefixes. The way in 617 which the DHCPv6 Delegating Router triggers the mobile access 618 gateway in order to deregister the prefixes is beyond the scope 619 of this document. 621 * In case the mobile router performs a handover and attaches to a 622 different mobile access gateway, the following cases are 623 possible: 625 + The new mobile access gateway does not support the 626 delegation of mobile network prefixes described in this 627 specification. In this case, forwarding of the previously 628 delegated mobile network prefixes is no longer performed. 630 + The new mobile access gateway supports the delegation of 631 mobile network prefixes described in this specification. 632 There are two possible cases upon the reception of the 633 SOLICIT message by the Delegating Router. If the MAG 634 already knows the delegated mobile network prefixes, it 635 conveys them in a DMNP option included in the Proxy Binding 636 Update sent to the local mobility anchor, which then 637 authorizes them based on: a) the content of the associated 638 binding cache entry (if exists), b) the user profile (if the 639 allocation is static), or, c) checking that the delegated 640 mobile network prefixes are not already allocated. On the 641 other hand, if the mobile access gateway is not aware of the 642 delegated mobile network prefixes, it will include 0.0.0.0 / 643 ::0 in a DMNP option included in the Proxy Binding Update 644 sent to the LMA, which will provide the right prefixes back 645 in the Proxy Binding Acknowledgemente based on a) the 646 content of the associated binding cache entry (if exits), b) 647 the profile (if static allocation is used), or c) dynamic 648 assignment. 650 o Delegating router co-located with local mobility anchor 652 * A DHCPv6 Relay Agent function running on the mobile access 653 gateway will forward the DHCP messages to the local mobility 654 anchor which has the co-located Delegating Router function. 655 The Requesting Router and the Delegating Router complete the 656 DHCP messages related to prefix delegation. 658 * During the DHCPv6 exchange, the standard DHCPv6 considerations 659 apply with respect to the interactions between the Delegating 660 Router, DHCPv6 Relay Agent and the Requesting Router. 662 * The mobile access gateway learns from the co-located DHCPv6 663 Relay Agent the prefixes allocated by the Delegating Router. 664 The way in which the mobile access gateway learns obtains this 665 information from the DHCPv6 Relay Agent is beyond the scope of 666 this document. 668 * The mobile access gateway will apply the considerations in 669 Section 5.1.2 for requesting the local mobility anchor to 670 enable delegated prefix support. The mobile access gateway 671 will include exactly one instance of the Delegated Mobile 672 Network Prefix option with NON_ZERO prefix value for each of 673 the mobile network prefixes that the mobile access gateway is 674 requesting the local mobility anchor to allocate. The prefix 675 value(s) in the option will be the prefix(es) obtained via DHCP 676 prefix delegation. 678 * The mobile access gateway, upon successfully completing the 679 Proxy Binding Update signaling with the local mobility anchor, 680 will provide the obtained prefixes to the DHCPv6 Relay Agent 681 for prefix assignment. The Delegating Router is provided with 682 the delegated prefix(es) completing the standard DHCPv6 683 signaling. These prefixes can then be then advertised in the 684 mobile network, and therefore used by the locally fixed nodes 685 to auto configure IP addresses allowing to gain access to the 686 Internet. 688 + In case the Proxy Binding Update signalling with the local 689 mobility anchor is not completed successfully, for example 690 because the local mobility anchor is not authorized for 691 delegated mobile network prefix, the requeted prefix is in 692 use, or the delegated prefix(es) do not match the ones 693 allocated by DHCP prefix delegation, the DHCPv6 Relay Agent 694 MAY send a Reply message to the Requesting Router containing 695 the IA_PD with the lifetimes of the prefixes in the IA_PD 696 set to zero. 698 * In case the mobile router performs a handover and attaches to a 699 different mobile access gateway, the following cases are 700 possible: 702 + The new mobile access gateway does not support the 703 delegation of mobile network prefixes described in this 704 specification. In this case, forwarding of the previously 705 delegated mobile network prefixes is no longer performed. 707 + The new mobile access gateway supports the delegation of 708 mobile network prefixes described in this specification. 709 There are two possible cases upon the reception of the 710 SOLICIT message by the DHCPv6 Relay Agent. If the MAG 711 already knows the delegated mobile network prefixes, it 712 conveys them in a DMNP option included in the Proxy Binding 713 Update sent to the local mobility anchor, which then 714 authorizes them based on: a) the content of the associated 715 binding cache entry (if exists), b) the user profile (if the 716 allocation is static), or, c) checking that the delegated 717 mobile network prefixes are not already allocated. On the 718 other hand, if the mobile access gateway is not aware of the 719 delegated mobile network prefixes, it will include 0.0.0.0 / 720 ::0 in a DMNP option included in the Proxy Binding Update 721 sent to the LMA, which will provide the right prefixes back 722 in the Proxy Binding Acknowledgemente based on a) the 723 content of the associated binding cache entry (if exits), b) 724 the profile (if static allocation is used), or c) dynamic 725 assignment. 727 5.1.3. Packet Forwarding 729 o On receiving an IP packet from a mobile router, the mobile access 730 gateway before tunneling the packet to the local mobility anchor 731 MUST ensure that there is an established binding for the mobile 732 router and the source IP address of the packet is a prefix 733 delegated to that mobile router. If the source address of the 734 received IP packet is not part of the delegated mobile network 735 prefix, then the mobile access gateway MUST NOT tunnel the packet 736 to the local mobility anchor. 738 o On receiving an IP packet from the bi-directional tunnel 739 established with the local mobility anchor, the mobile access 740 gateway MUST first decapsulate the packet (removing the outer 741 header) and then use the destination address of the (inner) packet 742 to forward it on the interface through which the mobile router is 743 reachable. 745 o The above forwarding considerations are not applicable to the IP 746 traffic sent/received to/from the mobile router's home address 747 (IPv4 HOA/HNP). For the mobile router's home address traffic, 748 forwarding considerations from [RFC5213] and [RFC5844] continue to 749 apply. 751 5.2. LMA Considerations 753 5.2.1. Extensions to Binding Cache Entry Data Structure 755 In order to support this specification, the conceptual Binding Cache 756 Entry (BCE) data structure [RFC5213] needs to be extended to include 757 the delegated mobile network prefix (DMNP) list. Each entry in the 758 list represents a delegated mobile network prefix. 760 5.2.2. Signaling Considerations 761 o If the Proxy Binding Update message does not include any Delegated 762 Mobile Network Prefix option(s) (Section 4.1), then the local 763 mobility anchor MUST NOT enable Delegated Prefix support for the 764 mobility session, and the Proxy Binding Acknowledgment message 765 that is sent in response MUST NOT contain any Delegated Mobile 766 Network Prefix option(s). 768 o If the Proxy Binding Update message includes one or more Delegated 769 Mobile Network Prefix options, but either the local mobility 770 anchor is not configured to support Delegated Prefix support, then 771 the local mobility anchor will ignore the option(s) and process 772 the rest of the option as specified in [RFC5213]. This would have 773 no effect on the operation of the rest of the protocol. The Proxy 774 Binding Acknowledgement message that is sent in response will not 775 include any Delegated Mobile Network Prefix option(s). 777 o If the Proxy Binding Update message has the Delegated Mobile 778 Network Prefix option(s) and if the local mobility anchor is 779 configured for Delegated Prefix support, then the local mobility 780 anchor MUST enable Delegated Mobile Network Prefix option for that 781 mobility session. The Proxy Binding Acknowledgement message that 782 is sent in response MUST include the Delegated Mobile Network 783 Prefix option(s). The following considerations apply. 785 * If there is at least one instance of the Delegated Mobile 786 Network Prefix option with a ALL_ZERO [RFC5213] prefix value, 787 then this serves as a request for the local mobility anchor to 788 perform the assignment of one or more delegated mobile network 789 prefixes. 791 + A Delegated Mobile Network option with ALL_ZERO value and 792 with the (V) flag set to a value of (0), is a request for 793 the local mobility anchor to allocate one or more IPv6 794 prefixes. 796 + A Delegated Mobile Network option with ALL_ZERO value and 797 with the (V) flag set to a value of (1), is a request for 798 the local mobility anchor to allocate one or more IPv4 799 prefixes. 801 + Inclusion of multiple instances of Delegated Mobile Network 802 options with ALL_ZERO value, one with the (V) flag set to a 803 value of (1), and another instance with the (V) flag set to 804 a value of (0) is a request to allocate both IPv4 and IPv6 805 prefixes. 807 * If there are no instances of the Delegated Mobile Network 808 Prefix option present in the request with ALL_ZERO value, but 809 has a specific prefix value, then this serves as a request for 810 the local mobility anchor to perform the allocation of the 811 requested prefix(es). 813 + If any one of the requested prefixes are assigned to some 814 other mobility node, or not from an authorized pool that the 815 local mobility can allocate for that mobility session, then 816 the Proxy Binding Update MUST be rejected by sending a Proxy 817 Binding Acknowledgement message with Status field set to 818 REQUESTED_DMNP_IN_USE (Requested delegated mobile network 819 prefix is in use). 821 o Upon accepting the Proxy Binding Update, the local mobility anchor 822 MUST send a Proxy Binding Acknowledgement message with the Status 823 field set to 0 (Proxy Binding Update accepted). 825 * The message MUST include one instance of the Delegated Mobile 826 Network Prefix option for each of the allocated IPv4/IPv6 827 delegated mobile network prefixes. 829 * The delegated mobile network prefix (DMNP) list in the mobile 830 router's Binding Cache entry has to be updated with the 831 allocated prefix(es). However, if the request is a de- 832 registration request with a lifetime value of (0), the 833 delegated mobile network prefix list has to be removed along 834 with the Binding Cache entry. 836 * A route (or a platform-specific equivalent function that sets 837 up the forwarding) for each of the allocated prefixes over the 838 tunnel has to be added. However, if the request is a de- 839 registration request, with a lifetime value of (0), all the 840 IPv4/IPv6 delegated prefix routes created for that session have 841 to be removed. 843 5.2.3. Packet Forwarding 845 o The local mobility anchor MUST advertise a connected route into 846 the Routing Infrastructure for the IP prefixes delegated to all of 847 the mobile routers that it is serving. This step essentially 848 enables the local mobility anchor to be a routing anchor for those 849 IP prefixes and be able to intercept IP packets sent to those 850 mobile networks. 852 o On receiving a packet from a correspondent node with the 853 destination address matching any of the mobile router's delegated 854 mobile network prefixes, the local mobility anchor MUST forward 855 the packet through the bi-directional tunnel set up with the 856 mobile access gateway where the mobile router is attached. 858 o On receiving an IP packet from the bi-directional tunnel 859 established with the mobile access gateway, the local mobility 860 anchor MUST first decapsulate the packet (removing the outer 861 header) and then use the destination address of the (inner) packet 862 for forwarding decision. The local mobility anchor MUST ensure 863 that there is an established binding for the mobile router and the 864 source IP address of the packet is a prefix delegated to a mobile 865 router reachable over that bi-directional tunnel. 867 o The above forwarding considerations are not applicable to the IP 868 traffic sent/received to/from the mobile router's home address 869 (IPv4 HOA/HNP). For the mobile router's home address traffic, 870 forwarding considerations from [RFC5213] and [RFC5844] continue to 871 apply. 873 5.3. Security Policy Database (SPD) Example Entries 875 The use of DHCPv6, as described in this document, requires message 876 integrity protection and source authentication. The IPsec security 877 mechanism used by Proxy Mobile IPv6 [RFC5213] for securing the 878 signaling messages between the mobile access gateway and the local 879 mobility anchor can be used for securing the DHCP signaling between 880 the mobile access gateway and the local mobility anchor. 882 The Security Policy Database (SPD) and Security Association Database 883 (SAD) entries necessary to protect the DHCP signaling is specified 884 below. The format of these entries is based on [RFC4877] 885 conventions. The SPD and SAD entries are only example 886 configurations. A particular implementation of mobile access gateway 887 and local mobility anchor implementation can configure different SPD 888 and SAD entries as long as they provide the required security for 889 protecting DHCP signaling messages. 891 For the examples described in this document, a mobile access gateway 892 with address "mag_address_1", and a local mobility anchor with 893 address "lma_address_1" are assumed. 895 mobile access gateway SPD-S: 896 - IF local_address = mag_address_1 & 897 remote_address = lma_address_1 & proto = UDP & 898 local_port = any & remote_port = DHCP 899 Then use SA1 (OUT) and SA2 (IN) 901 mobile access gateway SAD: 902 - SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT): 903 local_address = mag_address_1 & 904 remote_address = lma_address_1 & 905 proto = UDP & remote_port = DHCP 906 - SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT): 907 local_address = lma_address_1 & 908 remote_address = mag_address_1 & 909 proto = UDP & local_port = DHCP 911 local mobility anchor SPD-S: 912 - IF local_address = lma_address_1 & 913 remote_address = mag_address_1 & proto = UDP & 914 local_port = DHCP & remote_port = any 915 Then use SA2 (OUT) and SA1 (IN) 917 local mobility anchor SAD: 918 - SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT): 919 local_address = lma_address_1 & 920 remote_address = mag_address_1 & 921 proto = UDP & local_port = DHCP 922 - SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT): 923 local_address = mag_address_1 & 924 remote_address = lma_address_1 & 925 proto = UDP & remote_port = DHCP 927 6. Security Considerations 929 The Delegated Mobile Network Prefix Option defined in this 930 specification is for use in Proxy Binding Update and Proxy Binding 931 Acknowledgement messages. This option is carried like any other 932 mobility header option as specified in [RFC5213]. Therefore, it 933 inherits from [RFC5213] its security guidelines and does not require 934 any additional security considerations. 936 The use of DHCPv6 in this specification is as defined in DHCPv6 base 937 specification [RFC3315] and DHCPv6 Prefix Delegation specifications 938 [RFC3633]. The security considerations specified in those 939 specifications apply to this specification. 941 If IPsec is used, the IPsec security association that is used for 942 protecting the Proxy Binding Update and Proxy Binding 943 Acknowledgement, also needs to be used for protecting the DHCPv6 944 signaling between the mobile access gateway and the local mobility 945 anchor. Considerations specified in Section 5.3 identify the 946 extensions to security policy entries [RFC4301] 948 7. IANA Considerations 950 This document requires the following IANA actions. 952 o Action-1: This specification defines a new Mobility Header option, 953 Delegated Mobile Network Prefix option. This mobility option is 954 described in Section 4.1. The type value for this 955 message needs to be allocated from the Mobility Header Types 956 registry at http://www.iana.org/assignments/mobility-parameters. 957 RFC Editor: Please replace in Section 4.1 with the 958 assigned value, and update this section accordingly. 960 o Action-2: This document also defines two new status code values 961 for use in the Proxy Binding Acknowledgement message, as described 962 in Section 4.2. These status codes are, 963 NOT_AUTHORIZED_FOR_DELEGATED_MNP (Not Authorized for delegated 964 mobile network prefix) with a status code value of , and 965 REQUESTED_DMNP_IN_USE (Requested delegated mobile network prefix 966 is in use) with a status code value of . These values 967 have to be assigned from the same number space as allocated for 968 other status codes [RFC6275] and update this section accordingly. 970 8. Acknowledgments 972 The authors would like to Acknowledge Ryuji Wakikawa, Alexandru 973 Petrescu, Behcet Sarikaya, Seil Jeon and Basavaraj Patil for all the 974 discussions and reviews of this draft. 976 The work of Carlos J. Bernardos has also been partially supported by 977 the European Community's Seventh Framework Programme (FP7-ICT-2009-5) 978 under grant agreement n. 258053 (MEDIEVAL project) and by the 979 Ministry of Science and Innovation of Spain under the QUARTET project 980 (TIN2009-13992-C02-01). 982 9. References 984 9.1. Normative References 986 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 987 Requirement Levels", BCP 14, RFC 2119, March 1997. 989 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 990 and M. Carney, "Dynamic Host Configuration Protocol for 991 IPv6 (DHCPv6)", RFC 3315, July 2003. 993 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 994 Host Configuration Protocol (DHCP) version 6", RFC 3633, 995 December 2003. 997 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 998 Internet Protocol", RFC 4301, December 2005. 1000 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1001 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1002 April 2007. 1004 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1005 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1007 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1008 Mobile IPv6", RFC 5844, May 2010. 1010 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1011 in IPv6", RFC 6275, July 2011. 1013 [RFC6276] Droms, R., Thubert, P., Dupont, F., Haddad, W., and C. 1014 Bernardos, "DHCPv6 Prefix Delegation for Network Mobility 1015 (NEMO)", RFC 6276, July 2011. 1017 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1018 "Prefix Exclude Option for DHCPv6-based Prefix 1019 Delegation", RFC 6603, May 2012. 1021 9.2. Informative References 1023 [RFC6656] Johnson, R., Kinnear, K., and M. Stapp, "Description of 1024 Cisco Systems' Subnet Allocation Option for DHCPv4", 1025 RFC 6656, July 2012. 1027 Authors' Addresses 1029 Xingyue Zhou 1030 ZTE Corporation 1031 No.50 Software Avenue, Yuhuatai District 1032 Nanjing 1033 China 1035 Phone: +86-25-8801-4634 1036 Email: zhou.xingyue@zte.com.cn 1038 Jouni Korhonen 1039 Renesas Mobile 1040 Porkkalankatu 24 1041 Helsinki FIN-00180 1042 Finland 1044 Email: jouni.nospam@gmail.com 1046 Carl Williams 1047 Consultant 1048 San Jose, CA 1049 USA 1051 Email: carlw@mcsr-labs.org 1053 Sri Gundavelli 1054 Cisco 1055 170 West Tasman Drive 1056 San Jose, CA 95134 1057 USA 1059 Email: sgundave@cisco.com 1061 Carlos J. Bernardos 1062 Universidad Carlos III de Madrid 1063 Av. Universidad, 30 1064 Leganes, Madrid 28911 1065 Spain 1067 Phone: +34 91624 6236 1068 Email: cjbc@it.uc3m.es 1069 URI: http://www.it.uc3m.es/cjbc/