idnits 2.17.1 draft-ietf-netlmm-pmip6-ipv4-support-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (January 18, 2009) is 5577 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-07 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group R. Wakikawa 3 Internet-Draft Toyota ITC 4 Intended status: Standards Track S. Gundavelli 5 Expires: July 22, 2009 Cisco 6 January 18, 2009 8 IPv4 Support for Proxy Mobile IPv6 9 draft-ietf-netlmm-pmip6-ipv4-support-08.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 22, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document specifies extensions to Proxy Mobile IPv6 protocol for 49 adding IPv4 protocol support. The scope of IPv4 protocol support is 50 two-fold: 1) enable IPv4 home address mobility support to the mobile 51 node. 2) allowing the mobility entities in the Proxy Mobile IPv6 52 domain to exchange signaling messages over an IPv4 transport network. 54 Table of Contents 56 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 6 59 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8 60 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 61 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 63 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 64 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 65 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11 66 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11 67 3.1.3. Routing Considerations for the Local Mobility 68 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 16 69 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17 70 3.2.1. Extensions to Binding Update List Entry . . . . . . . 17 71 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18 72 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 18 73 3.2.4. Routing Considerations for the Mobile Access 74 Gateway . . . . . . . . . . . . . . . . . . . . . . . 22 75 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22 76 3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 22 77 3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 23 78 3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 24 79 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 25 80 3.4.1. DHCP Server co-located with the Mobile Access 81 Gateway . . . . . . . . . . . . . . . . . . . . . . . 26 82 3.4.2. DHCP Relay Agent co-located with the Mobile Access 83 Gateway . . . . . . . . . . . . . . . . . . . . . . . 29 85 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 32 86 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 33 87 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 33 88 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 34 89 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 34 90 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 37 91 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 38 92 4.2.1. Extensions to Binding Update List Entry . . . . . . . 38 93 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 38 95 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 42 96 5.1. Local Mobility Anchor - Configuration Variables . . . . . 42 97 5.2. Mobile Access Gateway - Configuration Variables . . . . . 42 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 102 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 104 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 107 10.1. Normative References . . . . . . . . . . . . . . . . . . . 46 108 10.2. Informative References . . . . . . . . . . . . . . . . . . 47 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 112 1. Overview 114 The transition from IPv4 to IPv6 is a long process and during this 115 period of transition, both the protocols will be enabled over the 116 same network infrastructure. Thus, it is reasonable to assume that a 117 mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only 118 IPv6-only or in dual-stack mode and additionally the network between 119 the mobile access gateway and a local mobility anchor may be an IPv4 120 or an IPv6 network. It is also reasonable to expect the same 121 mobility infrastructure in the Proxy Mobile IPv6 domain to provide 122 mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode 123 and when the network between the local mobility anchor and the mobile 124 access gateway is an IPv4 or an IPv6 network. The motivation and 125 scope of IPv4 support in Mobile IPv6 is summarized in [RFC-4977] and 126 all those requirements apply to Proxy Mobile IPv6 protocol as well. 128 The Proxy Mobile IPv6 protocol [RFC-5213] specifies a mechanism for 129 providing IPv6 home address mobility support to a mobile node in a 130 Proxy Mobile IPv6 domain. The protocol requires IPv6 transport 131 network between the mobility entities. The extensions defined in 132 this document extends IPv4 support to the Proxy Mobile IPv6 protocol 133 [RFC-5213]. 135 The scope of IPv4 support in Proxy Mobile IPv6 includes the support 136 for the following two features: 138 o IPv4 Home Address Mobility Support: A mobile node that has an IPv4 139 stack enabled will be able to obtain an IPv4 address and be able 140 to use that address from any of the access networks in that Proxy 141 Mobile IPv6 domain. The mobile node is not required to be 142 allocated or assigned an IPv6 address for enabling IPv4 home 143 address support. 145 o IPv4 Transport Network Support: The mobility entities in the Proxy 146 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 147 signaling messages over an IPv4 transport and furthermore the 148 mobile access gateway may be using an IPv4 private address and 149 with NAT [RFC-3022] translation devices on the path to the local 150 mobility anchor. 152 These two features, the IPv4 Home Address Mobility support and the 153 IPv4 transport support features, are independent of each other and 154 deployments may choose to enable any one or both of these features as 155 required. 157 +----+ +----+ 158 |LMA1| |LMA2| 159 +----+ +----+ 160 IPv4-LMAA1 -> | | <-- LMAA2 161 | | 162 \\ //\\ 163 (NAT) // \\ 164 \\ // \\ 165 +---\\------------- //------\\----+ 166 ( \\ IPv4/IPv6 // \\ ) 167 ( \\ Network // \\ ) 168 +------\\--------//------------\\-+ 169 \\ // \\ 170 \\ // \\ 171 \\ // \\ 172 IPv4-Proxy-CoA1--> | | <-- Proxy-CoA2 173 +----+ +----+ 174 |MAG1|-----{MN2} |MAG2| 175 +----+ | +----+ 176 (IPv6 MN-HoA1) | | | <-- (IPv6 MN-HoA2) 177 (IPv4-MN-HoA1) --> | (IPv4-MN-HoA2) | <-- (IPv4-MN-HoA3) 178 {MN1} {MN3} 180 Figure 1: IPv4 support for Proxy Mobile IPv6 182 1.1. Stated Assumptions 184 The following are the configuration requirements from the mobility 185 entities in the Proxy Mobile IPv6 domain for supporting the 186 extensions defined in this document. 188 o The local mobility anchor and the mobile access gateway are both 189 IPv4 and IPv6 enabled. Irrespective of the type of transport 190 network (IPv4 or IPv6) separating these two entities, the mobility 191 signaling is always based on Proxy Mobile IPv6 [RFC-5213]. 193 o The local mobility anchor and the mobile access gateway MUST be 194 configured with IPv6 globally unique addresses, even when they are 195 in IPv4-only network. These addresses can be of the type Unique 196 Local IPv6 Unicast Address [RFC-4193], IPv6 Global Unicast Address 197 [RFC-3587] or IPv4-mapped IPv6 address [RFC-4291]. When using 198 IPv4 transport, it is not required that there is IPv6 routing 199 enabled between the local mobility anchor and the mobile access 200 gateway. However, they must be able to receive any IPv6 packets 201 sent to the configured IPv6 addresses, after removing the outer 202 IPv4 encapsulation header. 204 o The mobile node can be operating in IPv4-only, IPv6-only or in 205 dual mode. Based on what is enabled for a mobile node, it should 206 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 207 address(es) for its interface and furthermore achieve mobility 208 support for those addresses. 210 o For enabling IPv4 home address mobility support to a mobile node, 211 it is not required that the IPv6 home address mobility support 212 needs to enabled. However, the respective protocol(s) support, 213 such as IPv4 or IPv6 packet forwarding, must be enabled on the 214 access link between the mobile node and the mobile access gateway. 216 o The mobile node can obtain an IPv4 address for its attached 217 interface. Based on the type of link, it may be able to acquire 218 its IPv4 address configuration using standard IPv4 address 219 configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332], 220 IKEv2 [RFC-4306] or static address configuration. 222 o The mobile node's IPv4 home subnet is typically a shared address 223 space. It is not for the exclusive use of any one mobile node. 224 There can be multiple mobile nodes that are assigned IPv4 225 addresses from the same subnet. 227 o The mobile access gateway is the IPv4 default-router for the 228 mobile node on its access link. It will be in the forwarding path 229 for the mobile node's data traffic. 231 2. Conventions & Terminology 233 2.1. Conventions 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 237 document are to be interpreted as described in RFC 2119 [RFC-2119]. 239 2.2. Terminology 241 All the mobility related terms used in this document are to be 242 interpreted as defined in the Mobile IPv6 specification [RFC-3775] 243 and Proxy Mobile IPv6 specification [RFC-5213]. In addition this 244 document introduces the following terms. 246 IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) 248 The IPv4 address that is configured on the egress-interface of the 249 mobile access gateway. When using IPv4 transport, this address 250 will be the registered care-of address in the mobile node's 251 Binding Cache entry and will also be the transport-endpoint of the 252 tunnel between the local mobility anchor and a mobile access 253 gateway. However, if the configured address is a private IPv4 254 address and with a NAT device in the path to the local mobility 255 anchor, the care-of address as seen by the local mobility anchor 256 will be the address allocated by the NAT device for that flow. 258 IPv4 Local Mobility Anchor Address (IPv4-LMAA) 260 The IPv4 address that is configured on the egress-interface of the 261 local mobility anchor. When using IPv4 transport, the mobile 262 access gateway sends the Proxy Binding Update messages to this 263 address and will be the transport-endpoint of the tunnel between 264 the local mobility anchor and the mobile access gateway. 266 Mobile Node's IPv4 Home Address (IPv4-MN-HoA) 268 This is the IPv4 home address assigned to the mobile node's 269 attached interface. This address is topologically anchored at the 270 local mobility anchor. The mobile node configures this address on 271 its attached interface. If the mobile node connects to the Proxy 272 Mobile IPv6 domain via multiple interfaces each of the interfaces 273 are assigned a unique IPv4 address. All the IPv6 home network 274 prefixes and the IPv4 home address assigned to a given interface 275 of a mobile node will be managed under one mobility session. 277 Selective De-registration 278 It is a procedure for partial de-registration of all the addresses 279 that belong to one address family, i.e., de-registration of either 280 IPv4 home address, or all of the IPv6 home network prefixes. 282 Encapsulation Modes 284 This document uses the following terms when referring to the 285 different encapsulation modes. 287 IPv4-over-IPv6 289 IPv4 packet carried as a payload of an IPv6 packet 291 IPv4-over-IPv4 293 IPv4 packet carried as a payload of an IPv4 packet 295 IPv4-over-IPv4-UDP 297 IPv4 packet carried as a payload in an UDP header of an IPv4 298 packet 300 IPv4-over-IPv4-UDP-TLV 302 IPv4 packet carried as a payload in an IPv4 packet with UDP and 303 TLV headers 305 3. IPv4 Home Address Mobility Support 307 The IPv4 home address mobility support essentially enables a mobile 308 node in a Proxy Mobile IPv6 domain to obtain IPv4 home address 309 configuration for its attached interface and be able to retain that 310 address configuration even after changing its point of attachment in 311 that Proxy Mobile IPv6 domain. This section describes the protocol 312 operation and the required extensions to Proxy Mobile IPv6 protocol 313 for extending IPv4 home address mobility support. 315 When an IPv4-enabled or a dual-stack enabled mobile node attaches to 316 the Proxy Mobile IPv6 domain, the mobile access gateway on the access 317 link where the mobile node is attached will identify the mobile node 318 and will initiate the Proxy Mobile IPv6 signaling with the mobile 319 node's local mobility anchor. The mobile access gateway will follow 320 the signaling considerations specified in Section 3.2 for requesting 321 IPv4 home address mobility support. Upon the completion of the 322 signaling, the local mobility anchor and the mobile access gateway 323 will establish the required routing states for allowing the mobile 324 node to use its IPv4 home address from its current point of 325 attachment. 327 The mobile node on the access link using any of the standard IPv4 328 address configuration mechanisms supported on that access link, such 329 as IPCP [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], will be able 330 to obtain an IPv4 home address (IPv4-MN-HoA) for its attached 331 interface. Although the address configuration mechanisms for 332 delivering the address configuration to the mobile node is 333 independent of the Proxy Mobile IPv6 protocol operation, however 334 there needs to be some interactions between these two protocol flows. 335 Section 3.4 identifies these interactions for supporting DHCP based 336 address configuration. 338 The support for IPv4 home address mobility is not dependent on the 339 IPv6 home address mobility support. It is not required that the IPv6 340 home address mobility support needs to be enabled for providing IPv4 341 home address mobility support. A mobile node will be able to obtain 342 IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its 343 attached interface. The mobile node's policy profile will determine 344 if the mobile node is entitled for both the protocol versions or a 345 single protocol version. Based on the policy, only those protocols 346 will be enabled on the access link. Furthermore, if the mobile node 347 after obtaining the address configuration on its interface performs 348 an handoff, either by changing its point of attachment over the same 349 interface or to a different interface, the network will ensure the 350 mobile node will be able to use the same IPv4 address configuration 351 after the handoff. 353 Additionally, If the mobile node connects to the Proxy Mobile IPv6 354 domain, through multiple interfaces and simultaneously through 355 different access networks, each of the connected interfaces will 356 obtain an IPv4 home address from different subnets. In such 357 scenario, there will be multiple Binding Cache entries for the mobile 358 node on the local mobility anchor. All the address (IPv4/IPv6) 359 assigned to a given interface will be managed as part of one mobility 360 session, as specified in Section 5.4 of [RFC-5213]. 362 3.1. Local Mobility Anchor Considerations 364 3.1.1. Extensions to Binding Cache Entry 366 To support this feature, the conceptual Binding Cache entry data 367 structure maintained by the local mobility anchor needs to be 368 extended with the following additional parameters. 370 o The IPv4 home address assigned to the mobile node's interface and 371 registered by the mobile access gateway. The IPv4 home address 372 entry also includes the corresponding subnet mask. 374 o The IPv4 default-router address assigned to the mobile node. 376 3.1.2. Signaling Considerations 378 3.1.2.1. Processing Proxy Binding Updates 380 The processing rules specified in Section 5.3 of [RFC-5213] are 381 applied for processing the received Proxy Binding Update message. 382 However, if the received Proxy Binding Update message has an IPv4 383 Home Address option [ID-DSMIP6], the following considerations MUST be 384 applied additionally. 386 o If there is an IPv4 Home Address option [ID-DSMIP6] present in the 387 received Proxy Binding Update message, but if there is no Home 388 Network Prefix option [RFC-5213] present in the request, the local 389 mobility anchor MUST NOT reject the request as specified in 390 Section 5.3.1 of [RFC-5213]. At least one instance of any of 391 these two options MUST be present. If there is not a single 392 instance of any of these two options present in the request, the 393 local mobility anchor MUST reject the request and send a Proxy 394 Binding Acknowledgement message with Status field set to 395 MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home 396 network prefix option) [RFC-5213]. 398 o If there is at least one instance of Home Network Prefix option 399 [RFC-5213] present in the received Proxy Binding Update message, 400 but either if the mobile node is not IPv6 enabled, or if IPv6 401 routing not enabled in the home network, the local mobility anchor 402 MUST reject the request and send a Proxy Binding Acknowledgement 403 message with the Status field set to 404 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX (mobile node not 405 authorized for the requesting IPv6 home network prefix). 407 o If there are more than one instance of the IPv4 Home Address 408 option present in the request, then the local mobility anchor MUST 409 reject the request and send a Proxy Binding Acknowledgement 410 message with the Status field set to 411 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 412 home address assignment not supported). 414 o If the prefix request(P) flag in the IPv4 Home Address option is 415 set to a value of 1, then the local mobility anchor MUST reject 416 the request and send a Proxy Binding Acknowledgement message with 417 the Status field set to IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED (IPv4 418 prefix assignment not supported). 420 o For associating the received Proxy Binding Update message to an 421 existing mobility session, the local mobility anchor MUST perform 422 the Binding Cache entry existence test by applying the following 423 considerations. 425 * If there is at least one instance of the Home Network Prefix 426 option [RFC-5213] with a NON_ZERO prefix value, or, if there is 427 an IPv4 Home Address option [ID-DSMIP6] with the IPv4 address 428 in the option set to ALL_ZERO, considerations from Section 429 5.4.1 of [RFC-5213] MUST be applied. 431 * If there is an IPv4 Home Address option [ID-DSMIP6] present in 432 the request with the IPv4 address value in the option set to a 433 NON_ZERO value, considerations from Section 3.1.2.7 MUST be 434 applied. 436 o If there is no existing Binding Cache entry that can be associated 437 with the request, the local mobility anchor MUST consider this 438 request as an initial binding registration request and 439 considerations from Section 3.1.2.2 MUST be applied. 440 Additionally, if there are one or more Home Network Prefix options 441 [RFC-5213] present in the request, considerations from Section 442 5.3.2 of [RFC-5213] MUST also be applied. 444 o If there exists a Binding Cache entry that can be associated with 445 the request, the local mobility anchor MUST apply considerations 446 from Section 5.3.1 of [RFC-5213], (point 13), to determine if the 447 request is re-registration or a de-registration request and the 448 respective considerations from the below sections MUST be applied. 450 o If there exists a Binding Cache entry that can be associated with 451 the request and if it is determined that the request is a re- 452 registration request and with the request to extend IPv4 home 453 address mobility support to the existing IPv6-only mobility 454 session, considerations from Section 3.1.2.2 MUST be applied with 455 respect to IPv4 support. 457 3.1.2.2. Initial Binding Registration (New Mobility Session) 459 o If there is an IPv4 Home Address option [ID-DSMIP6] present in the 460 Proxy Binding Update message with the IPv4 address value in the 461 option set to ALL_ZERO, the local mobility anchor MUST allocate an 462 IPv4 home address to the mobile node and associate it with the new 463 mobility session created for that mobile node. 465 o If there is an IPv4 Home Address option [ID-DSMIP6] with the IPv4 466 address in the option set to a NON_ZERO value, the local mobility 467 anchor before accepting the request MUST ensure the address is 468 topologically anchored on the local mobility anchor and 469 furthermore the mobile node is authorized to use that address. If 470 the mobile node is not authorized for that specific address, the 471 local mobility anchor MUST reject the request and send a Proxy 472 Binding Acknowledgement message with the Status field set to 473 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized 474 for the requesting IPv4 address). It MUST also include the IPv4 475 Address Acknowledgement option [ID-DSMIP6] in the reply with the 476 status field value in the option set to 129 (Administratively 477 prohibited). 479 o If the local mobility anchor is unable to allocate an IPv4 address 480 due to lack of resources, it MUST reject the request and send a 481 Proxy Binding Acknowledgement message with Status field set to 130 482 (Insufficient resources). It MUST also include the IPv4 Address 483 Acknowledgement option [ID-DSMIP6] in the reply with the status 484 field value in the option set to 128 (Failure, reason 485 unspecified). 487 o Upon accepting the request, the local mobility anchor MUST create 488 a Binding Cache entry for this mobility session. However, if the 489 request also contains one or more Home Network Prefix options [ID- 490 DSMIP6], there should still be only one Binding Cache entry that 491 should be created for this mobility session. The created Binding 492 Cache entry MUST be used for managing both IPv4 and IPv6 home 493 address bindings. The fields in the Binding Cache entry MUST be 494 updated with the accepted values for that session. 496 o The local mobility anchor MUST establish a bi-directional tunnel 497 to the mobile access gateway and with the encapsulation mode set 498 to the negotiated mode for carrying the IPv4 payload traffic. 499 When using IPv6 transport, the encapsulation mode is IPv4-over- 500 IPv6 (IPv4 packet carried as a payload of an IPv6 packet). When 501 using IPv4 transport, the encapsulation mode is as specified in 502 Section 4.0. 504 o The local mobility anchor MUST create an IPv4 host route (or a 505 platform specific equivalent function that sets up the forwarding) 506 for tunneling the packets received for the mobile node's home 507 address associated with this mobility session. 509 o The local mobility anchor MUST send the Proxy Binding 510 Acknowledgement message with the Status field set to 0 (Proxy 511 Binding Update Accepted). The message MUST be constructed as 512 specified in Section 3.1.2.6. 514 3.1.2.3. Binding Lifetime Extension (No handoff) 516 All the considerations from Section 5.3.3 of [RFC-5213] MUST be 517 applied. 519 3.1.2.4. Binding Lifetime Extension (After handoff) 521 o If there is no Home Network Prefix option(s) [RFC-5213] present in 522 the request, but if the Binding Cache entry associated with this 523 request has IPv6 home network prefix(es), the local mobility 524 anchor MUST consider this as a request to extend lifetime only for 525 the IPv4 home address and not for the IPv6 home network 526 prefix(es). Hence, the local mobility anchor SHOULD release all 527 the IPv6 home network prefix(es) assigned to that mobile node and 528 for that specific attached interface. Similar considerations 529 apply for the case where there is no IPv4 Home Address option [ID- 530 DSMIP6] present in the request, but if the Binding Cache entry 531 associated with that request has both IPv4 home address and IPv6 532 home network prefix(es). 534 o The local mobility anchor MUST remove the previously created IPv4 535 host route (or the forwarding state) and the dynamically created 536 bi-directional tunnel for carrying the IPv4 payload traffic (if 537 there are no other mobile nodes for which the tunnel is being 538 used). This will remove the routing state towards the mobile 539 access gateway where the mobile node was anchored prior to the 540 handoff. 542 o The local mobility anchor MUST create a bi-directional tunnel to 543 the mobile access gateway that sent the request (if there is no 544 existing bi-directional tunnel) and with the encapsulation mode 545 set to the negotiated mode for carrying the IPv4 payload traffic. 546 An IPv4 host route for tunneling the packets received for the 547 mobile node's IPv4 home address MUST also be added. 549 o The required forwarding state identified in Section 5.3.6 of [RFC- 550 5213] is for IPv6 payload traffic. Those considerations apply for 551 IPv4 payload traffic as well. However, if IPv4 transport is in 552 use, considerations from Section 4.0 MUST be applied. 554 3.1.2.5. Binding De-Registration 556 All the considerations from Section 5.3.5 of [RFC-5213] MUST be 557 applied. Additionally, for removing the IPv4 state as part of the 558 Binding Cache entry deletion, the IPv4 host route and the dynamically 559 created bi-directional tunnel for carrying the IPv4 payload traffic 560 (if there are no other mobile nodes for which the tunnel is being 561 used) MUST be removed. However, if the request is for a selective 562 de-registration (IPv4 home address only, or all the IPv6 home network 563 prefixes), the Binding Cache entry MUST NOT be deleted, only the 564 respective states with respect to those addresses MUST be deleted. 566 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 568 The local mobility anchor when sending the Proxy Binding 569 Acknowledgement message to the mobile access gateway MUST construct 570 the message as specified in Section 5.3.6 of [RFC-5213]. 571 Additionally, the following considerations MUST be applied. 573 o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to 574 include at least one instance of Home Network Prefix option [RFC- 575 5213] in the Proxy Binding Acknowledgement message that it sends 576 to the mobile access gateway. However, if the received Proxy 577 Binding Update message has only the IPv4 Home Address option [ID- 578 DSMIP6] and did not contain the Home Network Prefix option(s), 579 then the local mobility anchor MUST NOT include any Home Network 580 Prefix option(s) in the reply. However, there MUST be at least 581 one instance of either the Home Network Prefix option [RFC-5213] 582 or the IPv4 Address Acknowledgement option [ID-DSMIP6] present in 583 the Proxy Binding Acknowledgement message. 585 o The IPv4 Address Acknowledgement option [ID-DSMIP6] MUST be 586 present in the Proxy Binding Acknowledgement message. 588 1. If the Status field is set to a value greater than or equal to 589 128, i.e., if the Proxy Binding Update is rejected, then there 590 MUST be an IPv4 Address Acknowledgement option [ID-DSMIP6] 591 corresponding to the IPv4 Home Address option [ID-DSMIP6] 592 present in the request and with the IPv4 address value and the 593 prefix length fields in the option set to the corresponding 594 values in the request. The status field value in the option 595 must be set to the specific error code. 597 2. For all other cases, there MUST be an IPv4 Address 598 Acknowledgement option for carrying the IPv4 home address 599 assigned for that mobility session and with the value in the 600 option set to the allocated IPv4 address. The prefix length 601 in the option MUST be set to the prefix length of the 602 allocated address. The status field value in the option must 603 be set to 0 (Success). 605 o The IPv4 Default-Router Address option MUST be present, if the 606 Status field value in the Proxy Binding Acknowledgement message is 607 set to 0 (Proxy Binding Update Accepted). Otherwise, the option 608 MUST NOT be present. If the option is present, the default-router 609 address in the option MUST be set to the mobile node's default- 610 router address. 612 3.1.2.7. Binding Cache Entry Lookup Considerations 614 The Binding Cache entry lookup considerations specified in Section 615 5.4.1.1 of [RFC-5213] requires the Home Network Prefix [RFC-5213] as 616 the key parameter for identifying the Binding Cache entry. When 617 using an IPv4 address with a NON_ZERO value, the exact same 618 considerations specified in Section 5.4.1.1 of [RFC-5213] MUST be 619 applied, with the exception of using an IPv4 home address in place of 620 an IPv6 home network prefix. 622 3.1.3. Routing Considerations for the Local Mobility Anchor 624 Intercepting Packets Sent to the Mobile Node's IPv4 home address: 626 o When the local mobility anchor is serving a mobile node, it MUST 627 be able to receive packets that are sent to the mobile node's IPv4 628 home address. In order for it to receive those packets, it MUST 629 advertise a connected route in to the Routing Infrastructure for 630 the mobile node's IPv4 home address or for its home subnet. This 631 essentially enables IPv4 routers in that network to detect the 632 local mobility anchor as the last-hop router for that subnet. 634 Forwarding Packets to the Mobile Node: 636 o On receiving a packet from a correspondent node with the 637 destination address matching the mobile node's IPv4 home address, 638 the local mobility anchor MUST forward the packet through the bi- 639 directional tunnel setup for that mobile node. 641 o The format of the tunneled packet when payload protection is not 642 enabled: 644 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 645 IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ 646 Upper layer protocols /* Packet Content*/ 648 Figure 2: Tunneled Packets from LMA to MAG 650 Forwarding Packets Sent by the Mobile Node: 652 o All the reverse tunneled packets that the local mobility anchor 653 receives from the mobile access gateway, after removing the tunnel 654 header MUST be routed to the destination specified in the inner 655 IPv4 packet header. These routed packets will have the source 656 address field set to the mobile node's IPv4 home address. 658 3.2. Mobile Access Gateway Considerations 660 3.2.1. Extensions to Binding Update List Entry 662 To support the IPv4 home address mobility feature, the conceptual 663 Binding Update List entry data structure needs to be extended with 664 the following additional fields. 666 o The IPv4 home address assigned to the mobile node's attached 667 interface. This IPv4 home address may have been statically 668 configured in the mobile node's policy profile, or, may have been 669 dynamically allocated by the local mobility anchor. The IPv4 home 670 address entry also includes the corresponding subnet mask. 672 o The IPv4 default-router address of the mobile node. This is 673 acquired from the mobile node's local mobility anchor through the 674 received Proxy Binding Acknowledgment message. 676 3.2.2. Extensions to Mobile Node's Policy Profile 678 To support the IPv4 Home Address Mobility Support feature the mobile 679 node's policy profile, specified in Section 6.2 of [RFC-5213] MUST be 680 extended with the following additional fields. 682 Extensions to the mandatory section of the policy profile: 684 o This field identifies all the IP protocol versions for which the 685 home address mobility support needs to be extended to the mobile 686 node. The supported modes are IPv4-only, IPv6-only and dual IPv4/ 687 IPv6. 689 Extensions to the optional section of the policy profile: 691 o The IPv4 home address assigned to the mobile node's attached 692 interface. The specific details on how the network maintains the 693 association between the address and the attached interface is 694 outside the scope of this document. This address field also 695 includes the corresponding subnet mask. 697 3.2.3. Signaling Considerations 699 3.2.3.1. Mobile Node Attachment and Initial Binding Registration 701 After detecting a new mobile node on its access link, the mobile 702 access gateway on the access link MUST determine if IPv4 home address 703 mobility support needs to be enabled for that mobile node. The 704 mobile node's policy profile identifies the supported modes (IPv4- 705 only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the 706 mobile service needs to be enabled. Based on those policy 707 considerations and from other triggers such as from the network, if 708 it is determined that IPv4 home address mobility support needs to be 709 enabled for the mobile node, considerations from section 6.9.1.1 of 710 [RFC-5213] MUST be applied with the following exceptions. 712 o The IPv4 Home Address option [ID-DSMIP6] MUST be present in the 713 Proxy Binding Update message. 715 * If the mobile access gateway learns the mobile node's IPv4 home 716 address either from its policy profile, or from other means, 717 the mobile access gateway MAY ask the local mobility anchor to 718 allocate that specific address by including exactly one 719 instance of the IPv4 Home Address option [ID-DSMIP6] with the 720 IPv4 home address and the prefix length fields in the option 721 set to that specific address and its prefix length. 722 Furthermore, the (P) flag in the option MUST be set to 0. 724 * The mobile access gateway MAY also ask the local mobility 725 anchor for dynamic IPv4 home address allocation. It can 726 include exactly one instance of the IPv4 Home Address option 727 with the IPv4 home address and the prefix length fields in the 728 option set to ALL_ZERO value. Furthermore, the (P) flag in the 729 option MUST be set to 0. This essentially serves as a request 730 to the local mobility anchor for the IPv4 home address 731 allocation. 733 o The Proxy Binding Update message MUST be constructed as specified 734 in Section 6.9.1.5 of [RFC-5213]. However, the Home Network 735 Prefix option(s) [RFC-5213] MUST be present in the Proxy Binding 736 Update only if IPv6 home address mobility support also needs to be 737 enabled for the mobile node. Otherwise, the Home Network Prefix 738 option(s) MUST NOT be present. 740 o When using IPv4 transport for carrying the signaling messages, the 741 related considerations from section 4.0 MUST be applied 742 additionally. 744 3.2.3.2. Receiving Proxy Binding Acknowledgement 746 All the considerations from section 6.9.1.2 of [RFC-5213] MUST be 747 applied with the following exceptions. 749 o If the received Proxy Binding Acknowledgement message has the 750 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 751 mobile node is not authorized for IPv4 home address), the mobile 752 access gateway SHOULD NOT send a Proxy Binding Update message 753 including the IPv4 Home Address option [ID-DSMIP6] till an 754 administrative action is taken. 756 o If the received Proxy Binding Acknowledgement message has the 757 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 758 mobile node is not authorized for the requesting IPv4 home 759 address), the mobile access gateway SHOULD NOT request for the 760 same address again, but MAY request the local mobility anchor to 761 do the assignment of address by including exactly one instance of 762 IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address 763 and the prefix length fields in the option set to ALL_ZERO value. 765 o If there is no IPv4 Address Acknowledgement option [ID-DSMIP6] 766 present in the received Proxy Binding Acknowledgement message, the 767 mobile access gateway MUST NOT enable IPv4 support for the mobile 768 node and the rest of the considerations from this section can be 769 skipped. 771 o If the received Proxy Binding Acknowledgement message has the 772 Status field value in the IPv4 Address Acknowledgement Option [ID- 773 DSMIP6] set to a value that indicates that the request was 774 rejected by the local mobility anchor, the mobile access gateway 775 MUST NOT enable forwarding for that specific IPv4 home address. 777 o If the received Proxy Binding Acknowledgement message has the 778 Status field value set to 0 (Proxy Binding Update accepted), the 779 mobile access gateway MUST update a Binding Update List entry for 780 that mobile node. The entry MUST be updated with the assigned 781 IPv4 home address and other accepted registration values. 783 o If the received Proxy Binding Acknowledgement message has the 784 Status field value set to 0 (Proxy Binding Update accepted) and 785 has the IPv4 Address Acknowledgement Option [ID-DSMIP6] set to a 786 value that indicates that the request was accepted by the local 787 mobility anchor, the mobile access gateway MUST establish a bi- 788 directional tunnel to the local mobility anchor (if there is no 789 existing bi-directional tunnel to that local mobility anchor) and 790 with the encapsulation mode set to IPv4-over-IPv6 (IPv4 packet 791 carried as a payload of an IPv6 packet). Considerations from 792 Section 5.6.1 of [RFC-5213] MUST be applied for managing the 793 dynamically created bi-directional tunnel. However, when using 794 IPv4 transport, the encapsulation mode MUST be set to the 795 negotiated encapsulation mode, as specified in Section 4 of this 796 specification. 798 o The mobile access gateway MUST set up the route for forwarding the 799 IPv4 packets received from the mobile node (using its IPv4 home 800 address) through the bi-directional tunnel set up for that mobile 801 node. 803 o If there is an IPv4 Default-Router Address option present in the 804 received Proxy Binding Acknowledgement message, the mobile access 805 gateway MAY configure this address on its interface and respond to 806 any ARP requests sent by the mobile node for resolving the 807 hardware address of the default-router. It MAY also use this 808 address as the source address for any datagrams sent to the mobile 809 node and originated by the mobile access gateway itself. It MAY 810 also use this address in the DHCP Router option [RFC-2132] in the 811 DHCP messages. 813 o If there is an IPv4 DHCP Support Mode option present in the 814 received Proxy Binding Acknowledgement message and if the (S) flag 815 in the option is set to a value of 1, then the mobile access 816 gateway MUST function as a DHCP server for the mobile node. If 817 either the (S) flag in the option is set to a value of 0, or if 818 the option is not present in the request, then the mobile access 819 gateway MUST function as a DHCP Relay for the mobile node. 821 3.2.3.3. Binding Re-Registration and De-Registrations 823 When sending a Proxy Binding Update either for extending the lifetime 824 of a mobility session or for de-registering the mobility session, the 825 respective considerations from [RFC-5213] MUST be applied. 826 Furthermore, the following additional considerations MUST also be 827 applied. 829 o If there is an IPv4 home address assigned to the mobility session, 830 then there MUST be exactly one instance of the IPv4 Home Address 831 option [ID-DSMIP6] present in the Proxy Binding Update message. 832 The IPv4 home address and the prefix length fields in the option 833 MUST be set to that specific address and its corresponding subnet- 834 mask length. The (P) flag in the option MUST be set to 0. 836 o If there was no IPv4 home address requested in the initial Proxy 837 Binding Update message, but if it is determined that the IPv4 home 838 address MUST be requested subsequently, then there MUST be exactly 839 one instance of the IPv4 Home Address option [ID-DSMIP6] present 840 in the Proxy Binding Update message. The IPv4 home address in the 841 option MUST be set to either ALL_ZERO or to a specific address 842 that is being requested. 844 o For performing selective de-registration of IPv4 home address but 845 still retaining the mobility session with all the IPv6 home 846 network prefixes, the Proxy Binding Update message with the 847 lifetime value of 0 MUST NOT include any IPv6 Home Network Prefix 848 options(s) [RFC-5213]. It MUST include exactly one instance of 849 the IPv4 Home Address option [ID-DSMIP6] with the IPv4 home 850 address and the prefix length fields in the option set to the IPv4 851 home address that is being de-registered. Similarly for selective 852 de-registration of all the IPv6 home network prefixes, the Proxy 853 Binding Update message MUST NOT include the IPv4 Home address 854 option, it MUST include a Home Network Prefix option for each of 855 the assigned home network prefixes assigned for that mobility 856 session and with the prefix value in the option set to that 857 respective prefix value. 859 o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present 860 if the same option(s) was not present in the initial Proxy Binding 861 Update message. Otherwise considerations from [RFC-5213] with 862 respect to this option MUST be applied. 864 3.2.4. Routing Considerations for the Mobile Access Gateway 866 o On receiving a packet from the bi-directional tunnel established 867 with the mobile node's local mobility anchor, the mobile access 868 gateway MUST remove the outer header before forwarding the packet 869 to the mobile node. 871 o Considerations from Section 6.10.3 of [RFC-5213] MUST be applied 872 with respect the local routing and on the use of 873 EnableMAGLocalRouting flag. 875 o On receiving a packet from a mobile node connected to its access 876 link, the packet MUST be forwarded to the local mobility anchor 877 through the bi-directional tunnel established with the local 878 mobility anchor. The encapsulation considerations specified in 879 section 3.1.3 MUST be applied. However, before forwarding the 880 packet, the mobile access gateway MUST ensure the source address 881 in the received packet is the address allocated for that mobile 882 node and that there is an active binding on the local mobility 883 anchor for that mobile node. 885 3.3. Mobility Options and Status Codes 887 To support the IPv4 home address mobility feature, this specification 888 defines the following new options and Status Codes. 890 3.3.1. IPv4 Default-Router Address Option 892 A new option, IPv4 Default-Router Address Option is defined for using 893 it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the 894 local mobility anchor to the mobile access gateway. This option can 895 be used for sending the mobile node's IPv4 default-router address. 897 The IPv4 Default-Router Address option has an alignment requirement 898 of 4n. Its format is as follows: 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Type | Length | Reserved (R) | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | IPv4 Default-Router Address | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 Figure 3: IPv4 Default-Router Address Option 909 Type 911 IANA 913 Length 915 8-bit unsigned integer indicating the length of the option in 916 octets, excluding the type and length fields. This field MUST 917 be set to 6. 919 Reserved (R) 921 This 8-bit field is unused for now. The value MUST be 922 initialized to 0 by the sender and MUST be ignored by the 923 receiver. 925 IPv4 Default-Router Address 927 A four-byte field containing the mobile node's default router 928 address. 930 3.3.2. IPv4 DHCP Support Mode 932 A new option, IPv4 DHCP Support Mode Option is defined for using it 933 in the Proxy Binding Acknowledgment message [RFC-5213] sent by the 934 local mobility anchor to the mobile access gateway. This option can 935 be used for notifying the mobile access gateway, if it should 936 function as a DHCP Server or a DHCP Relay for the attached mobile 937 node. 939 The IPv4 DHCP Support Mode option has no alignment requirement. Its 940 format is as follows: 942 0 1 2 3 943 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 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | Type | Length | Reserved (R) |S| 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 Figure 4: IPv4 DHCP Support Mode Option 950 Type 952 IANA 954 Length 956 8-bit unsigned integer indicating the length of the option in 957 octets, excluding the type and length fields. This field MUST 958 be set to 2. 960 Reserved (R) 962 This 15-bit field is unused for now. The value MUST be 963 initialized to 0 by the sender and MUST be ignored by the 964 receiver. 966 DHCP Support Mode (S) 968 A 1-bit field that specifies the DHCP support mode. This flag 969 indicates if the mobile access gateway should function as a 970 DHCP Server or a DHCP Relay for the attached mobile node. The 971 flag value of (0) indicates the mobile access gateway should 972 act as a DHCP Relay and the flag value of (1) indicates it 973 should act as a DHCP Server. 975 3.3.3. Status Codes 977 This document defines the following new Status values for use in the 978 Proxy Binding Acknowledgement message [RFC-5213]. These values are 979 to be allocated from the same numbering space, as defined in Section 980 6.1.8 of [RFC-3775]. 982 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 984 Mobile node not authorized for the requesting IPv4 home address 986 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA 988 Mobile node not authorized for the requesting IPv6 home network 989 prefix(es). 991 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED 993 Multiple IPv4 home address assignment not supported 995 IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED 996 IPv4 prefix assignment not supported 998 3.4. Supporting DHCP-Based Address Configuration 1000 This section explains how DHCP-based address configuration support 1001 can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It 1002 explains the protocol operation, supported DHCP server deployment 1003 configurations and the protocol interactions between DHCP agents and 1004 mobility entities in each of the supported configurations. 1006 This specification supports the following two DHCP deployment 1007 configurations. 1009 o DHCP relay agent co-located with the mobile access gateway. 1011 o DHCP server co-located in the mobile access gateway. 1013 The following are the configuration requirements: 1015 o The DHCP server or the DHCP relay agent configured on the mobile 1016 access gateway is required to have an IPv4 address for exchanging 1017 the DHCP messages with the mobile node. This address can be 1018 either the IPv4 Proxy Care-of Address or the mobile node's 1019 default-router address provided by the local mobility anchor. 1020 Optionally, all the DHCP servers co-located with the mobile access 1021 gateways in the Proxy Mobile IPv6 domain can be configured with a 1022 fixed IPv4 address. This fixed address can be potentially an IPv4 1023 link-local address [RFC-3927] that can be used for the DHCP 1024 protocol communication on any of the access links. This address 1025 will be used as the server identifier in the DHCP messages. 1027 o The DHCP server identifies the DHCP client either from the client 1028 identifier or the client hardware address (chaddr) [RFC-2131]. A 1029 mobile node in a Proxy Mobile IPv6 domain may present any of these 1030 identifiers to the DHCP server as long as the identifier remains 1031 the same through out the mobile node's attachment in that Proxy 1032 Mobile IPv6 domain. If the client hardware address is used as the 1033 identifier and if the mobile node performs an handoff between two 1034 interfaces, this hardware identifier will change and the DHCP 1035 server will not be able to identify the mobile node. Thus, it is 1036 recommended that the DHCP client on the mobile node, which 1037 performs mobility session handoff across interfaces in a Proxy 1038 Mobile IPv6 domain, is configured to use a stable client 1039 identifier that does not change during the active life of its DHCP 1040 session. 1042 o All the DHCP servers co-located with the mobile access gateways in 1043 a Proxy Mobile IPv6 domain can be configured with the same set of 1044 DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure 1045 the mobile node receives the same configuration values on any of 1046 the access links in that Proxy Mobile IPv6 domain. 1048 3.4.1. DHCP Server co-located with the Mobile Access Gateway 1050 This section explains the operational sequence of home address 1051 assignment operation when the DHCP server is co-located with the 1052 mobile access gateway. 1054 MN MAG(DHCP-S) LMA 1055 |------>| | 1. DHCPDISCOVER 1056 | |------->| 2. Proxy Binding Update 1057 | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) 1058 | |========| 4. Tunnel/Route Setup 1059 |<------| | 5. DHCPOFFER (IPv4 HoA) 1060 |------>| | 6. DHCPREQUEST (IPv4 HoA) 1061 |<------| | 7. DHCPACK 1062 | | | 1063 * DHCPDISCOVER (Step-1) and Proxy Mobile IPv6 signaling 1064 * (Step-2 to Step-4) may happen in parallel and in no specific order 1065 * Tunnel/Route setup(Step-4) and the subsequent steps will happen in 1066 * in the specified order. 1068 Figure 5: Overview of DHCP Server located at Mobile Access Gateway 1070 Initial IPv4 Home Address Assignment: 1072 o When the mobile node sends a DHCPDISCOVER message [RFC-2131], the 1073 DHCP server co-located with the mobile access gateway will trigger 1074 the mobile access gateway to complete the Proxy Mobile IPv6 1075 signaling. This is the required interaction between these two 1076 protocols. If the mobile access gateway is unable to complete the 1077 Proxy Mobile IPv6 signaling, or, if the local mobility anchor does 1078 not assign an IPv4 address for the mobile node, the mobile access 1079 gateway MUST NOT enable IPv4 support for the mobile node on that 1080 access link. 1082 o After a successful completion of the Proxy Mobile IPv6 signaling 1083 and upon acquiring the mobile node's IPv4 home address from the 1084 local mobility anchor, the DHCP server on the mobile access 1085 gateway will send a DHCPOFFER message [RFC-2131] to the mobile 1086 node. The offered address will be the mobile node's IPv4 home 1087 address, assigned by the local mobility anchor. The server 1088 address, 'siaddr' field of the DHCPOFFER message, will be set to 1089 the mobile node's default-router address. The DHCPOFFER message 1090 will be unicasted to the mobile node. 1092 o If the mobile node sends the DHCPREQUEST message, the DHCP server 1093 will send DHCPACK message, as per [RFC-2131]. 1095 IPv4 Home Address Renewal with the DHCP server (No Handoff): 1097 o Any time the mobile node goes into the DHCP RENEWING state [RFC- 1098 2131], it simply unicasts the DHCPREQUEST message including the 1099 assigned IPv4 home address in the 'requested IP address' option. 1100 The DHCPREQUEST is sent to the address specified in 'server 1101 identifier' field of the previously received DHCPOFFER and DHCPACK 1102 messages. 1104 o The DHCP server will send a DHCPACK to the mobile node to 1105 acknowledge the assignment of the committed IPv4 address. 1107 IPv4 Home Address Renewal with a different DHCP server (After 1108 Handoff): 1110 When the mobile node goes into the DHCP RENEWING state [RFC-2131], it 1111 directly unicasts the DHCPREQUEST message to the DHCP server that 1112 currently provided the DHCP lease. However, if the mobile node 1113 changed its point of attachment and is attached to a new mobile 1114 access gateway, it is required that the mobile node updates the DHCP 1115 server address and uses the address of the DHCP server that is co- 1116 located with the new mobile access gateway. Any of the following 1117 approaches can be adopted to ensure the mobile node uses the DHCP 1118 server on the attached link. 1120 1. The use of fixed DHCP server address on all DHCP servers 1121 MN oMAG(DHCP-S) nMAG(DHCP-S) 1122 | : | 1123 RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) 1124 BOUND<-------------| 2. DHCPACK or DHCPNACK 1125 | : | 1127 2. The use of FORCERENEW message to notify the address change 1128 MN prev-MAG (DHCP-S) new-MAG (DHCP-S) 1129 | : | 1130 RENEW------------->| 1. DHCPREQUEST*a (IPv4 HoA) 1131 |<---------------| 2. FORCERENEW 1132 |--------------->| 3. DHCPREQUEST*b (IPv4 HoA) 1133 BOUND<-------------| 4. DHCPACK or DHCPNACK 1134 | : | 1135 *a DHCPREQUEST sent to oMAG 1136 *b DHCPREQUEST sent to nMAG 1138 Figure 6: Address renewal with a different DHCP server 1140 o If a fixed address such as the IPv4 default-router address of the 1141 mobile node is used as the DHCP server Id on any of the links in 1142 that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the 1143 mobile node for renewing the address will be received by the new 1144 mobile access gateway on the attached link. The mobile access 1145 gateway after completing the Proxy Mobile IPv6 signaling and upon 1146 acquiring the IPv4 home address of the mobile node will return the 1147 address in the DHCPACK message. However, if the mobile access 1148 gateway is unable to complete the Proxy Mobile IPv6 signaling or 1149 is unable to acquire the same IPv4 address as requested by the 1150 mobile node, it will send a DHCPNACK message [RFC-2131] to the 1151 mobile node, as shown in Figure 6-1). 1153 o If the mobile access gateway on the access link receives any DHCP 1154 messages from the mobile node unicasted to a server address that 1155 is not locally configured, the mobile access gateway can unicast 1156 FORCERENEW message [RFC-3203] to the mobile node as shown in 1157 Figure 6-2). This will force the mobile node to update the DHCP 1158 server address with the address of the mobile access gateway on 1159 the new link. However, if the FORCERENEW message [RFC-3203] is 1160 also not supported by the DHCP server on the mobile access 1161 gateway, then that DHCPREQUEST message can be ignored. This will 1162 force the mobile node to enter the DHCP REBINDING state [RFC-2131] 1163 and start the DHCPDISCOVER phase again. 1165 Additional Operation: 1167 o If at any point the mobile access gateway fails to extend the 1168 binding lifetime with the local mobility anchor for the mobile 1169 node's IPv4 address, it can send the unicast FORCERENEW message 1170 [RFC-3203] to the mobile node to force it to change its DHCP state 1171 to the RENEW state. Furthermore, it MUST remove forwarding for 1172 the mobile node's IPv4 home address. 1174 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway 1176 A DHCP relay agent is co-located with each mobile access gateway. A 1177 DHCP server is located somewhere in the Proxy Mobile IPv6 domain 1178 (e.g., is co-located with the local mobility anchor). Figure 7 shows 1179 the sequence of IPv4 home address assignment using DHCP Relay. 1181 MN MAG(DHCP-R) LMA DHCP-S 1182 | |------->| | 1. Proxy Binding Update * 1183 | |<-------| | 2. Proxy Binding Acknowledgement (IPv4HoA) 1184 | |========| | 3. Tunnel/Route Setup* 1185 |------>|-------------->| 4. DHCPDISCOVER (IPv4HoA) via DHCP-R 1186 |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R 1187 |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R 1188 |<------|<--------------| 7. DHCPACK via DHCP-R 1189 | | | 1190 * The Proxy Mobile IPv6 signaling (Step-1 to Step-2) and the 1191 DHCPDISCOVER phase (Step-4) may occur in any order. However, 1192 the DHCPOFFER (Step-5) and the following steps will occur in 1193 the specified order and after the Tunnel/Route Setup (Step-3). 1195 Figure 7: Overview of the DHCP relay located at mobile access gateway 1197 Initial IPv4 Home Address Assignment: 1199 o When the mobile access gateway receives a DHCPDISCOVER message 1200 from a mobile node, it can check if there is already an assigned 1201 IPv4 home address for the mobile node from the local mobility 1202 anchor. If there is no assigned IPv4 home address assigned for 1203 that mobile node, the mobile access gateway has to complete the 1204 Proxy Mobile IPv6 signaling with the local mobility anchor by 1205 sending a Proxy Binding Update message. 1207 o If the Proxy Binding Update message is rejected by the local 1208 mobility anchor for any reason, the local mobility anchor will 1209 discard the DHCPDISCOVER messages from the mobile node. 1211 o If the Proxy Binding Update message is accepted by the local 1212 mobility anchor and if there is an assigned IPv4 home address for 1213 the mobile node, the DHCP messages will be forwarded to the DHCP 1214 server. 1216 o The DHCP relay agent on the mobile access gateway will add the 1217 DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER 1218 message. The assigned IPv4 home address will be included in the 1219 Agent Remote ID Sub-option of the DHCP relay agent information 1220 option. This sub-option is used as a hint for requesting the DHCP 1221 server to allocate that specific IPv4 address. 1223 o On receiving a DHCPOFFER message from the DHCP server, the mobile 1224 access gateway will ensure the assigned address is currently 1225 assigned by the local mobility anchor to that mobile node. If 1226 this address is different from what is assigned to the mobile 1227 node, then the mobile access gateway will drop the DHCPOFFER 1228 message and an administrative error message will be logged. 1229 However, the mobile access gateway is not required to perform this 1230 check, if the DHCP server is co-located with the local mobility 1231 anchor, as that check will be performed by the local mobility 1232 anchor in such scenario. The mobile access gateway can determine 1233 the co-location of the DHCP server and the local mobility anchor 1234 by comparing the source address of the DHCPOFFER message with the 1235 address of the mobile node's local mobility anchor. 1237 o When the DHCP messages are sent over administrative boundaries, 1238 the operators needs to ensure these messages are secured. All the 1239 DHCP messages relayed by the mobile access gateway can be tunneled 1240 to the local mobility anchor if needed. Alternatively, if the 1241 network in the Proxy Mobile IPv6 domain is secure enough, the 1242 mobile access gateway can just relay the DHCP messages to the 1243 server. To achieve this, all the mobile access gateways needs to 1244 have route towards the DHCP server. 1246 IPv4 Home Address Renewal to the same DHCP server: (No Handover) 1248 o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it 1249 directly unicasts DHCPREQUEST message to the DHCP server. The 1250 DHCP relay agent may not detect these unicasted DHCPREQUEST 1251 messages for renewing the address. Thus, any of the following 1252 approaches can be adopted. 1254 * The DHCP relay agent can intercept all the DHCP packets 1255 regardless of the destination address. Since the link between 1256 a mobile node and a mobile access gateway is the point-to-point 1257 link, the mobile access gateway will be in path for all the 1258 messages. 1260 * The DHCP relay agent can use the DHCP Server Identifier 1261 Override Sub-option [RFC-5107] to be in path for all the DHCP 1262 message flows. The DHCP client uses the DHCP server address 1263 which is overridden by the DHCP relay agent address as a 1264 destination address of DHCPREQUEST. The DHCP Server Identifier 1265 Override Sub-option is recommended only when the fixed DHCP 1266 relay address is configured on all the mobile access gateways. 1267 Otherwise, the DHCP relay agent address is changed when the 1268 mobile node changes the attached mobile access gateway. 1270 o The DHCP Relay agent on detecting the DHCPREQUEST message from the 1271 mobile node, will verify if the address in the DHCPREQUEST message 1272 is the address assigned by the local mobility anchor for that 1273 mobile node. If the requesting IPv4 home address is not 1274 registered to the local mobility anchor, the mobile access gateway 1275 will drop the packet. Once the address verification is 1276 successfully completed, the DHCP relay agent will forward the 1277 DHCPREQUEST message to the DHCP server. 1279 IPv4 Address Release Triggers from the mobile node: 1281 o The mobile node may release its IPv4 home address at any time by 1282 sending the DHCPRELEASE message [RFC-2131]. When the mobile 1283 access gateway detects the DHCPRELEASE message sent by the mobile 1284 node and for releasing its assigned IPv4 home address, the mobile 1285 access gateway should consider this as a trigger for de- 1286 registering the mobile node's IPv4 home address. It MUST apply 1287 the considerations specified in section 3.2.3.3 for performing the 1288 de-registration procedure. However, this operation should not 1289 release any IPv6 home network prefix(es) assigned to the mobile 1290 node. 1292 Additional Operations: 1294 o If at any point the mobile access gateway fails to extend the 1295 binding lifetime with the local mobility anchor for the mobile 1296 node's IPv4 address, it can send the unicast FORCERENEW message 1297 [RFC-3203] to the mobile node to force it to change its DHCP state 1298 to RENEW state. Furthermore, it MUST remove forwarding for the 1299 mobile node IPv4 home address. 1301 4. IPv4 Transport Support 1303 The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling 1304 messages exchanged between the local mobility anchor and the mobile 1305 access gateway to be over an IPv6 transport. The extensions defined 1306 in this section allow the exchange of signaling messages over an IPv4 1307 transport when the local mobility anchor and the mobile access 1308 gateway are separated by an IPv4 network and are reachable using only 1309 IPv4 addresses. 1311 IPv4-Proxy-CoA IPv4-LMAA 1312 | + - - - - - - + | 1313 +--+ +---+ / \ +---+ +--+ 1314 |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| 1315 +--+ +---+ \ / +---+ +--+ 1316 + - - - - - - + 1318 Figure 8: IPv4 Transport Network 1320 When the local mobility anchor and the mobile access gateway are 1321 configured and reachable using only IPv4 addresses, the mobile access 1322 gateway serving a mobile node can potentially send the signaling 1323 messages over IPv4 transport and register its IPv4 address as the 1324 care-of address in the mobile node's Binding Cache entry. An IPv4 1325 tunnel (with any of the supported encapsulation modes) can be used 1326 for tunneling the mobile node's data traffic. The following are the 1327 key aspects of this feature. 1329 o The local mobility anchor and the mobile access gateway are both 1330 configured and reachable using an IPv4 address. Additionally, 1331 both entities are also IPv6 enabled and have configured IPv6 1332 addresses on their interfaces, as specified in [RFC-5213], but are 1333 reachable only over an IPv4 transport. 1335 o The mobile access gateway can be potentially in a private IPv4 1336 network behind a NAT [RFC-3022] device, with a private IPv4 1337 address configured on its egress interface. But, the local 1338 mobility anchor must not be behind a NAT and must be using a 1339 globally routable IPv4 address. However, both the local mobility 1340 anchor and the mobile access gateway can be in the same private 1341 IPv4 routing domain, i.e., when both are configured with private 1342 IPv4 addresses and with no need for NAT translation between them. 1344 o The IPv6 address configuration requirement on the mobile access 1345 gateway does not imply there needs to be IPv6 routing enabled 1346 between the local mobility anchor and the mobile access gateway. 1347 It just requires each of the mobile access gateways and local 1348 mobility anchors in a Proxy Mobile IPv6 domain to be configured 1349 with a globally unique IPv6 address. 1351 o The Proxy Mobile IPv6 signaling messages exchanged between the 1352 local mobility anchor and the mobile access gateway for 1353 negotiating the IPv4 transport will be encapsulated and carried as 1354 IPv4 packets. However, these signaling messages are fundamentally 1355 IPv6 messages using the mobility header and the related semantics 1356 as specified in base Proxy Mobile IPv6 specification [RFC-5213], 1357 but carried as a payload in an IPv4 packet. The supported 1358 encapsulation modes for the signaling messages are either native 1359 IPv4 or IPv4 with UDP header. 1361 o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and 1362 the IPv4 transport support specified in this section is agnostic 1363 to the type of address mobility enabled for that mobile node. 1365 o The IPv4 tunnel established between the local mobility anchor and 1366 the mobile access gateway (with any of the supported encapsulation 1367 modes over IPv4 transport) will be used for carrying the mobile 1368 node's IPv4 and IPv6 traffic. The supported encapsulation modes 1369 for carrying mobile node's IPv4 or IPv6 packets when using IPv4 1370 transport are as shown below. 1372 * IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet) 1374 * IPv4-UDP (Payload packet carried in an IPv4 packet with UDP 1375 header). 1377 * IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP 1378 and TLV header). Refer to [ID-DSMIP6]. 1380 * IPv4-UDP-ESP (Payload packet carried in an IPv4 packet with UDP 1381 and ESP headers). Refer to [RFC-3948]. 1383 4.1. Local Mobility Anchor Considerations 1385 4.1.1. Extensions to Binding Cache Entry 1387 To support this feature, the conceptual Binding Cache entry data 1388 structure maintained by the local mobility anchor [RFC-5213] MUST be 1389 extended with the following additional parameters. 1391 o This is the IPv4 Proxy Care-of Address configured on the mobile 1392 access gateway that sent the Proxy Binding Update message. This 1393 address can be obtained from the IPv4 Care-of Address option [ID- 1394 DSMIP6], present in the received Proxy Binding Update message. 1395 However, if the received Proxy Binding Update message is not sent 1396 as an IPv4 packet, i.e., when using IPv6 transport, this field 1397 MUST be set to ALL_ZERO value. 1399 o The IPv4 NAT translated address of the mobile access gateway. If 1400 the mobile access gateway is not behind a NAT [RFC-3022], this 1401 address will be the same as the address configured on the egress 1402 interface of the mobile access gateway. This address can be 1403 obtained from the IPv4 header of the received Proxy Binding Update 1404 message. However, if the received Proxy Binding Update message is 1405 not sent as an IPv4 packet, this field MUST be set to ALL_ZERO 1406 value. 1408 4.1.2. Extensions to Mobile Node's Policy Profile 1410 To support the IPv4 Transport Support feature the mobile node's 1411 policy profile, specified in Section 6.2 of [RFC-5213] MUST be 1412 extended with the following additional fields. These are mandatory 1413 fields of the policy profile required for supporting this feature. 1415 o The IPv4 address of the local mobility anchor (IPv4-LMAA). 1417 4.1.3. Signaling Considerations 1419 This section provides the rules for processing the Proxy Mobile IPv6 1420 signaling messages received over IPv4 transport. 1422 4.1.3.1. Processing Proxy Binding Updates 1424 o If the received Proxy Binding Update message was sent encapsulated 1425 in IPv4 or IPv4-UDP header, the message MUST be authenticated 1426 after removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1427 Considerations from Section 4 of [RFC-5213] MUST be applied for 1428 authenticating and authorizing the request. 1430 o All the considerations from Section 5.3.1 of [RFC-5213] MUST be 1431 applied on the encapsulated Proxy Binding Update message, after 1432 removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1434 o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in 1435 the request and if the outer encapsulation header is IPv4-UDP, 1436 then the NAT presence detection procedure specified in Section 1437 4.1.3.3 MUST be used for detecting the NAT in the path. 1439 o Upon accepting the request, the local mobility anchor MUST set up 1440 an IPv4 bi-directional tunnel to the mobile access gateway. The 1441 tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. 1443 The encapsulation mode MUST be determined from the below 1444 considerations. 1446 * If the received Proxy Binding Update message was sent with IPv4 1447 encapsulated header, then the encapsulation mode for the bi- 1448 directional tunnel MUST be set to IPv4. Otherwise, the 1449 following considerations apply. 1451 * If NAT is detected on the path, or if the (F) flag in the 1452 received Proxy Binding Update message is set to the value of 1, 1453 then the encapsulation mode MUST be set to IPv4-UDP. Otherwise 1454 the encapsulation mode MUST be set to IPv4. 1456 * If NAT is not detected on the path and if the (F) flag in the 1457 received Proxy Binding Update message is set to the value of 1, 1458 but if the configuration flag, 1459 AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of 1460 0, then the local mobility anchor MUST reject the request with 1461 the Status field value set to 129 (Administratively 1462 prohibited). 1464 * If the (T) flag [ID-DSMIP6] in the Proxy Binding Update message 1465 is set to value of 1, then the encapsulation mode MUST be set 1466 to IPv4-UDP-TLV. 1468 o The local mobility anchor MUST send the Proxy Binding 1469 Acknowledgement message with the Status field value set to 0 1470 (Proxy Binding Update Accepted). The message MUST be constructed 1471 as specified in Section 4.1.3.2. 1473 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 1475 The local mobility anchor when sending the Proxy Binding 1476 Acknowledgement message to the mobile access gateway MUST construct 1477 the message as specified in Section 5.3.6 of [RFC-5213]. However, if 1478 the received Proxy Binding Update message was encapsulated in an IPv4 1479 packet or as a payload in the UDP header of an IPv4 packet, the 1480 following additional considerations MUST be applied. 1482 o The Proxy Binding Acknowledgement message MUST be encapsulated in 1483 an IPv4 packet. However, if the received Proxy Binding Update 1484 message was sent encapsulated in the UDP header of an IPv4 packet, 1485 then the Proxy Binding Acknowledgement message MUST be 1486 encapsulated in the UDP header of an IPv4 packet. 1488 o The source address in the IPv4 header of the message MUST be set 1489 to the destination IPv4 address of the received request. 1491 o If the mobile access gateway and the local mobility anchor are 1492 using globally routable IPv4 addresses and if there is a security 1493 association that is based of IPv4 addresses, then the encapsulated 1494 IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement) 1495 MUST be protected using IPsec ESP [RFC-4301] mode. There is no 1496 need to apply IPsec ESP header to the IPv6 packet. In all other 1497 cases, the Proxy Binding Acknowledgement message MUST be protected 1498 using IPsec prior to the IPv4 or IPv4-UDP encapsulation. 1500 o The NAT Detection option [ID-DSMIP6] MUST be present only if there 1501 is an IPv4 Care-of Address option [ID-DSMIP6] present in the 1502 received Proxy Binding Update message and if the NAT detection 1503 procedure resulted in detecting a NAT on path. However, if the 1504 received Proxy Binding Update message was not sent encapsulated in 1505 IPv4 UDP header, then the option MUST NOT be present. 1506 Furthermore, in all other cases, the option MUST NOT be present. 1508 o The IPv4 DHCP Support Mode option MAY be present. If this option 1509 is not present, the mobile access gateway will enable the default 1510 behavior and function as a DHCP Relay for the mobile node. 1512 o The format of the Proxy Binding Acknowledgement message 1513 encapsulated in an IPv4 packet and protected using IPv6 security 1514 association. The UDP header MUST be present only if the received 1515 Proxy Binding Update message was sent with IPv4-UDP encapsulation 1516 header. 1518 IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) 1519 UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/ 1520 /* IPv6 PBA Packet protected with ESP header */ 1522 Figure 9: Proxy Binding Acknowledgment (PBA) Message encapsulated 1523 in IPv4 header 1525 4.1.3.3. NAT Presence Detection 1527 When the transport network between the local mobility anchor and the 1528 mobile access gateway is an IPv4 network and if the received Proxy 1529 Binding Update message was sent encapsulated in IPv4 UDP header, the 1530 local mobility anchor performs the NAT Presence Detection as 1531 specified below. 1533 On receiving the Proxy Binding Update message encapsulated in an IPv4 1534 UDP packet, the local mobility anchor, if it detects a NAT on the 1535 path, will send the Proxy Binding Acknowledgment message with the NAT 1536 Detection Option. The presence of this option in the Proxy Binding 1537 Acknowledgment is an indication to the mobile access gateway about 1538 the presence of NAT in the path. On detecting any NAT in the path, 1539 both the local mobility anchor and the mobile access gateway will set 1540 the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation. 1541 The specific details around the NAT detection and the related logic 1542 are described in DSMIPv6 specification [ID-DSMIP6]. 1544 However, if the value of the configuration variable, 1545 UseIPv4UDPEncapForSignalingMessages, is set to a value of 0, the 1546 mobile access gateway will not use IPv4 UDP encapsulation for Proxy 1547 Binding Update messages and hence the local mobility anchor will not 1548 perform this NAT Presence Detection procedure on these messages that 1549 are not sent in IPv4 UDP packet. 1551 4.1.4. Routing Considerations 1553 4.1.4.1. Forwarding Considerations 1555 Forwarding Packets to the Mobile Node: 1557 o On receiving an IPv4 or an IPv6 packet from a correspondent node 1558 with the destination address matching any of the mobile node's 1559 IPv4 or IPv6 home addresses, the local mobility anchor MUST 1560 forward the packet through the bi-directional tunnel set up for 1561 that mobile node. 1563 o The format of the tunneled packet is shown below. 1565 IPv4 Header (src= IPv4-LMAA, dst= IPv4-Proxy-CoA)] /* Tunnel Header */ 1566 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1567 [TLV Header] /* If TLV negotiated */ 1568 /* IPv6 or IPv4 Payload Packet */ 1569 IPv6 header (src= CN, dst= MN-HOA) 1570 OR 1571 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1573 Figure 10: Tunneled IPv4 Packet from LMA to MAG 1575 o Forwarding Packets Sent by the Mobile Node: 1577 * All the reverse tunneled packets (IPv4 and IPv6) that the local 1578 mobility anchor receives from the mobile access gateway, after 1579 removing the tunnel header (i.e., the outer IPv4 header along 1580 with the UDP and TLV header, if negotiated) MUST be routed to 1581 the destination specified in the inner packet header. These 1582 routed packets will have the source address field set to the 1583 mobile node's home address. 1585 4.1.4.2. ECN Considerations 1587 The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply 1588 for the IPv4 transport tunnels as well. The mobility agents at the 1589 tunnel entry and exit points MUST handle ECN information as specified 1590 in that document. 1592 4.1.4.3. Bi-Directional Tunnel Management 1594 The Tunnel Management considerations specified in section 5.6.1 of 1595 [RFC-5213] apply for the IPv4 transport tunnels as well, with just 1596 one difference that the encapsulation mode is different. 1598 4.2. Mobile Access Gateway Considerations 1600 4.2.1. Extensions to Binding Update List Entry 1602 To support the IPv4 Transport Support feature, the conceptual Binding 1603 Update List entry data structure maintained by the mobile access 1604 gateway [RFC-5213] MUST be extended with the following additional 1605 parameters. 1607 o The IPv4 address of the local mobility anchor. This address can 1608 be obtained from the mobile node's policy profile. 1610 o The IPv4 address of the mobile access gateway. This is the 1611 address configured on the egress interface of the mobile access 1612 gateway and is registered with the mobile node's local mobility 1613 anchor as the IPv4 Proxy-CoA. However, if the mobile access 1614 gateway is in a private IPv4 network and behind a NAT, the address 1615 that is registered with the mobile node's local mobility anchor is 1616 the NAT translated public IPv4 address. 1618 4.2.2. Signaling Considerations 1620 The mobile access gateway when sending a Proxy Binding Update message 1621 to the local mobility anchor MUST construct the message as specified 1622 in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access 1623 gateway is in an IPv4-only access network, the following additional 1624 considerations MUST be applied. 1626 o The Proxy Binding Update message MUST be encapsulated in an IPv4 1627 packet. However, if the value of the configuration variable, 1628 UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy 1629 Binding Update message MUST be encapsulated in an UDP header of an 1630 IPv4 packet. 1632 o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The 1633 IPv4 address in the option MUST be set to the mobile access 1634 gateway's IPv4-Proxy-CoA. 1636 o The packet MUST be constructed as specified in Section 4.2.3. 1638 o When sending a Proxy Binding message for extending the lifetime of 1639 a currently existing mobility session or for de-registering the 1640 mobility session, the Proxy Binding Update message MUST be 1641 constructed as the initial request. 1643 Receiving Proxy Binding Acknowledgement 1645 o If the received Proxy Binding Acknowledgement message is 1646 encapsulated in IPv4 or IPv4 UDP packet, the message MUST be 1647 authenticated after removing the outer IPv4 or IPv4-UDP header. 1648 Considerations from Section 4 of [RFC-5213] MUST be applied for 1649 authenticating and authorizing the message. 1651 o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be 1652 applied on the encapsulated Proxy Binding Acknowledgement message, 1653 after removing the outer IPv4 UDP header. 1655 o If the Status field indicates Success, the mobile access gateway 1656 MUST setup a bi-directional tunnel to the local mobility anchor. 1658 o Upon accepting the request, the mobile access gateway MUST set up 1659 an IPv4 bi-directional tunnel to the local mobility anchor. The 1660 tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA. 1661 The encapsulation mode MUST be determined from the below 1662 considerations. 1664 * The encapsulation mode for the bi-directional tunnel MUST be 1665 set to IPv4. However, if the value of the configuration 1666 variable, UseIPv4UDPEncapForSignalingMessages, is set to 1, 1667 then the following considerations MUST be applied. 1669 * If there is a NAT Detection option [ID-DSMIP6] in the received 1670 Proxy Binding Acknowledgement message and if the value of the 1671 configuration flag, UseIPv4UDPEncapForSignalingMessages, is set 1672 to value of 1, then the encapsulation mode for the tunnel MUST 1673 be set to IPv4-UDP. Otherwise the encapsulation mode MUST be 1674 set to IPv4. 1676 * If the (T) flag in the Proxy Binding Acknowledgement message is 1677 set to value of 1, then the encapsulation mode MUST be set to 1678 IPv4-UDP-TLV. 1680 4.2.2.1. Constructing the Proxy Binding Update Message 1682 o The source address in the IPv4 header MUST be set to IPv4-Proxy- 1683 CoA of the mobile access gateway and the destination address MUST 1684 be set to the local mobility anchor's IPv4-LMAA. 1686 o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The 1687 address MUST be set to the mobile access gateway's IPv4-Proxy-CoA. 1689 o If the configuration variable ForceIPv4UDPEncapsulationSupport is 1690 set to value of 1, then the (F) flag in the Proxy Binding Update 1691 message MUST be set to value of 1. 1693 o If the mobile access gateway and the local mobility anchor are 1694 using globally routable IPv4 addresses and if there is a security 1695 associated that is based of IPv4 addresses, then the encapsulated 1696 IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement 1697 message) MUST be protected using IPsec ESP [RFC-4301] mode and 1698 additionally there is no need to apply ESP header on the IPv6 1699 packet. In all other cases, the Proxy Binding Update message MUST 1700 be protected on the IPv6 packet of the Proxy Binding Update 1701 message, prior to the IPv4 encapsulation. 1703 o The format of the Proxy Binding Update message encapsulated in an 1704 IPv4 or IPv4-UDP packet with no IPsec protection: 1706 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1707 UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/ 1708 /* IPv6 PBU Packet protected with ESP header */ 1710 Figure 11: Proxy Binding Update (PBU) message encapsulated in IPv4 1711 UDP header 1713 4.2.2.2. Forwarding Considerations 1715 Forwarding Packets Sent by the Mobile Node: 1717 o On receiving an IPv4 or an IPv6 packet from the mobile node to any 1718 destination, the mobile access gateway MUST tunnel the packet to 1719 the local mobility anchor. The format of the tunneled packet is 1720 shown below. However, considerations from Section 6.10.3 of [RFC- 1721 5213] MUST be applied with respect the local routing and on the 1722 use of EnableMAGLocalRouting flag. 1724 IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */ 1725 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1726 [TLV Header] /* If TLV negotiated */ 1727 /* IPv6 or IPv4 Payload Packet */ 1728 IPv6 header (src= CN, dst= MN-HOA) 1729 OR 1730 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1732 Figure 12: Tunneled IPv4 Packet from LMA to MAG 1734 o Forwarding Packets received from the bi-directional tunnel: 1736 o On receiving a packet from the bi-directional tunnel established 1737 with the mobile node's local mobility anchor, the mobile access 1738 gateway MUST remove the outer header before forwarding the packet 1739 to the mobile node. 1741 5. Protocol Configuration Variables 1743 5.1. Local Mobility Anchor - Configuration Variables 1745 The local mobility anchor MUST allow the following variables to be 1746 configured by the system management. The configured values for these 1747 protocol variables MUST survive server reboots and service restarts. 1749 AcceptForcedIPv4UDPEncapsulationRequest 1751 This flag indicates whether or not the local mobility anchor 1752 should accept IPv4 UDP encapsulation request for the mobile node's 1753 data traffic, even if there is no NAT detected in the path. 1755 The default value for this flag is set to value of 0, indicating 1756 that the local mobility anchor MUST NOT accept IPv4 UDP 1757 encapsulation request when NAT is not detected in the path. 1759 When the value for this flag is set to value of 1, the local 1760 mobility anchor MUST accept IPv4 UDP encapsulation request even 1761 when NAT is not detected in the path. 1763 5.2. Mobile Access Gateway - Configuration Variables 1765 The mobile access gateway MUST allow the following variables to be 1766 configured by the system management. The configured values for these 1767 protocol variables MUST survive server reboots and service restarts. 1769 UseIPv4UDPEncapForSignalingMessages 1771 This flag indicates whether or not the mobile access gateway 1772 should use IPv4-UDP encapsulation mode for the signaling messages. 1774 The default value for this flag is set to value of 0, indicating 1775 that the mobile access gateway MUST NOT use IPv4-UDP encapsulation 1776 mode, but MUST use native IPv4 encapsulation mode for sending the 1777 Proxy Mobile IPv6 signaling messages. 1779 When the value for this flag is set to value of 1, the mobile 1780 access gateway MUST use IPv4-UDP encapsulation mode for sending 1781 the Proxy Mobile IPv6 signaling messages. 1783 ForceIPv4UDPEncapsulationSupport 1784 This flag indicates whether or not the mobile access gateway 1785 should request the mobile node's local mobility anchor for forcing 1786 IPv4 UDP encapsulation support for the mobile node's data traffic, 1787 even when NAT is not detected in the path. 1789 The default value for this flag is set to value of 0, indicating 1790 that the mobile access gateway MUST NOT request the mobile node's 1791 local mobility anchor for forcing IPv4 UDP encapsulation support 1792 even when NAT is not detected in path. 1794 When the value for this flag is set to value of 1, the mobile 1795 access gateway MUST force the mobile node's local mobility anchor 1796 for IPv4 UDP encapsulation support. 1798 This flag is applicable only when the flag 1799 UseIPv4UDPEncapForSignalingMessages is set to a value of 1. 1801 6. IANA Considerations 1803 This document defines a new Mobility Header option, IPv4 Default 1804 Router Address option. This option is described in Section 3.3.1. 1805 The Type value for this option needs to be assigned from the same 1806 numbering space as allocated for the other mobility options, as 1807 defined in [RFC-3775]. 1809 This document also defines new Binding Acknowledgement status values, 1810 as described in Section 3.3.2. The status values MUST be assigned 1811 from the same number space used for Binding Acknowledgement status 1812 values, as defined in [RFC-3775]. The allocated values for each of 1813 these status values must be greater than 128. 1815 7. Security Considerations 1817 All the security considerations from the base Proxy Mobile IPv6 1818 protocol [RFC-5213] apply when using the extensions defined in this 1819 document. Additionally, the following security considerations need 1820 to be applied. 1822 This document defines news mobility options for supporting the IPv4 1823 Home Address assignment and IPv4 Transport Support features. It also 1824 uses some of the mobility options from DSMIPv6 specification [ID- 1825 DSMIP6]. These options are to be carried in Proxy Binding Update and 1826 Proxy Binding Acknowledgement messages. The required security 1827 mechanisms specified in the base Proxy Mobile IPv6 protocol for 1828 protecting these signaling messages are sufficient when carrying 1829 these mobility options. 1831 This specification describes the use of IPv4 transport for exchanging 1832 the signaling messages between the local mobility anchor and the 1833 mobile access gateway. These signaling messages are fundamentally 1834 IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4 1835 packets. The encapsulated inner IPv6 message is still protected 1836 using IPsec, using the established security association and this 1837 offers the same level of security as when the messages are routed 1838 natively as IPv6 packets. The use of outer IPv4 header does not 1839 introduce any new security vulnerabilities. 1841 8. Contributors 1843 This document reflects discussions and contributions from several 1844 people (in alphabetical order): 1846 Kuntal Chowdhury 1848 kchowdhury@starentnetworks.com 1850 Vijay Devarapalli 1852 vijay.devarapalli@azairenet.com 1854 Sangjin Jeong 1856 sjjeong@etri.re.kr 1858 Basavaraj Patil 1860 basavaraj.patil@nsn.com 1862 Myungki Shin 1864 myungki.shin@gmail.com 1866 9. Acknowledgments 1868 The IPv4 support for Proxy Mobile IPv6 was initially covered in the 1869 internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like 1870 to thank all the authors of the document and acknowledge that initial 1871 work. 1873 Thanks to Alper Yegin, Behcet Sarikaya, Charles Perkins, Damic 1874 Damjan, Joel Hortelius, Jonne Soinnen, Julien Laganier, Mohana 1875 Jeyatharan, Niklas Nuemann, Premec Domagoj, Sammy Touati, Vidya 1876 Narayanan, Yingzhe Wu and Zu Qiang for their helpful review of this 1877 document. 1879 10. References 1881 10.1. Normative References 1883 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1884 Requirement Levels", BCP 14, RFC 2119, March 1997. 1886 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1887 2131, March 1997. 1889 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1890 IPv6", RFC 3775, June 2004. 1892 [RFC-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast 1893 Addresses", RFC-4193, October 2005. 1895 [RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing 1896 Architecture", RFC-4291, February 2006. 1898 [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, 1899 November 2007. 1901 [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack 1902 Hosts and Routers (DSMIPv6)", 1903 draft-ietf-mext-nemo-v4traversal-07.txt, December 2008. 1905 10.2. Informative References 1907 [RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol 1908 (IPCP)", RFC 1332, May 1992. 1910 [RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor 1911 Extensions", RFC 2132, March 1997. 1913 [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1914 Address Translator (Traditional NAT)", RFC 3022, January 2001. 1916 [RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January 1917 2001. 1919 [RFC-3203] Y. T'Joens and C. Hublet and P. De Schrijver, "DHCP 1920 reconfigure extension", RFC 3203, December 2001. 1922 [RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 1923 Unicast Address Format", RFC 3587, August 2003. 1925 [RFC-3927] Cheshire, S. et al, "Dynamic Configuration of IPv4 Link- 1926 Local Addresses", RFC 3927, May 2005. 1928 [RFC-3948] Huttunen, A. et al, "UDP Encapsulation of IPsec ESP 1929 Packets", RFC 3948, January 2005. 1931 [RFC-4301] Kent, S. and K. Seo, "Security Architecture for the 1932 Internet Protocol", RFC 4301, December 2005. 1934 [RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 1935 4306, December 2005. 1937 [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack 1938 Mobility", RFC 4977, August 2007. 1940 [RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp, 1941 "DHCP Server Identifier Override Suboption", RFC 5107, February 2008. 1943 Authors' Addresses 1945 Ryuji Wakikawa 1946 Toyota ITC / Keio University 1947 6-6-20 Akasaka, Minato-ku 1948 Tokyo 107-0052 1949 Japan 1951 Phone: +81-3-5561-8276 1952 Fax: +81-3-5561-8292 1953 Email: ryuji@jp.toyota-itc.com 1955 Sri Gundavelli 1956 Cisco 1957 170 West Tasman Drive 1958 San Jose, CA 95134 1959 USA 1961 Email: sgundave@cisco.com