idnits 2.17.1 draft-ietf-netlmm-pmip6-ipv4-support-15.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 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 (August 23, 2009) is 5354 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) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: February 24, 2010 Cisco 6 August 23, 2009 8 IPv4 Support for Proxy Mobile IPv6 9 draft-ietf-netlmm-pmip6-ipv4-support-15.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 February 24, 2010. 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies extensions to Proxy Mobile IPv6 protocol for 48 adding IPv4 protocol support. The scope of IPv4 protocol support is 49 two-fold: 1) enable IPv4 home address mobility support to the mobile 50 node. 2) allowing the mobility entities in the Proxy Mobile IPv6 51 domain to exchange signaling messages over an IPv4 transport network. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 5 57 1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 17 69 3.1.4. ECN & Payload Fragmentation Considerations . . . . . . 17 70 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 18 71 3.2.1. Extensions to Binding Update List Entry . . . . . . . 18 72 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18 73 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19 74 3.2.4. Routing Considerations for the Mobile Access 75 Gateway . . . . . . . . . . . . . . . . . . . . . . . 22 76 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23 77 3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23 78 3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 24 79 3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 25 80 3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 26 81 3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 27 82 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 28 83 3.4.1. DHCP Server co-located with the Mobile Access 84 Gateway . . . . . . . . . . . . . . . . . . . . . . . 29 85 3.4.2. DHCP Relay Agent co-located with the Mobile Access 86 Gateway . . . . . . . . . . . . . . . . . . . . . . . 32 87 3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 34 89 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 37 90 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 38 91 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 38 92 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 39 93 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 39 94 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 42 95 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 43 96 4.2.1. Extensions to Binding Update List Entry . . . . . . . 43 97 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 44 98 4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 46 99 4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 46 100 4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 50 102 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 53 103 5.1. Local Mobility Anchor - Configuration Variables . . . . . 53 104 5.2. Mobile Access Gateway - Configuration Variables . . . . . 53 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 57 110 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 58 112 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 114 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 115 10.1. Normative References . . . . . . . . . . . . . . . . . . . 59 116 10.2. Informative References . . . . . . . . . . . . . . . . . . 59 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 120 1. Overview 122 The transition from IPv4 to IPv6 is a long process and during this 123 period of transition, both the protocols will be enabled over the 124 same network infrastructure. Thus, it is reasonable to assume that a 125 mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only 126 IPv6-only or in dual-stack mode and additionally the network between 127 the mobile access gateway and a local mobility anchor may be an IPv4 128 or an IPv6 network. It is also reasonable to expect the same 129 mobility infrastructure in the Proxy Mobile IPv6 domain to provide 130 mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode 131 and whether the transport network is IPv4 or IPv6 network. The 132 motivation and scope of IPv4 support in Mobile IPv6 is summarized in 133 [RFC-4977] and all those requirements apply to Proxy Mobile IPv6 134 protocol as well. 136 The Proxy Mobile IPv6 protocol [RFC-5213] specifies a mechanism for 137 providing IPv6 home address mobility support to a mobile node in a 138 Proxy Mobile IPv6 domain. The protocol requires IPv6 transport 139 network between the mobility entities. The extensions defined in 140 this document extends IPv4 support to the Proxy Mobile IPv6 protocol 141 [RFC-5213]. 143 The scope of IPv4 support in Proxy Mobile IPv6 includes the support 144 for the following two features: 146 o IPv4 Home Address Mobility Support: A mobile node that has an IPv4 147 stack enabled will be able to obtain an IPv4 address and be able 148 to use that address from any of the access networks in that Proxy 149 Mobile IPv6 domain. The mobile node is not required to be 150 allocated or assigned an IPv6 address to enable IPv4 home address 151 support. 153 o IPv4 Transport Network Support: The mobility entities in the Proxy 154 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 155 signaling messages over an IPv4 transport and furthermore the 156 mobile access gateway may be using an IPv4 private address and 157 with NAT [RFC-3022] translation devices on the path to the local 158 mobility anchor. 160 These two features, the IPv4 Home Address Mobility support and the 161 IPv4 transport support features, are independent of each other and 162 deployments may choose to enable any one or both of these features as 163 required. 165 Figure-1 shows a typical Proxy Mobile IPv6 domain with IPv4 transport 166 network and with IPv4 enabled mobile nodes. The terms used in this 167 illustration are explained in the Terminology section. 169 +----+ +----+ 170 |LMA1| |LMA2| 171 +----+ +----+ 172 IPv4-LMAA -> | | <-- LMAA 173 | | 174 \\ //\\ 175 (NAT) // \\ 176 \\ // \\ 177 +---\\------------- //------\\----+ 178 ( \\ IPv4/IPv6 // \\ ) 179 ( \\ Network // \\ ) 180 +------\\--------//------------\\-+ 181 \\ // \\ 182 \\ // \\ 183 \\ // \\ 184 IPv4-Proxy-CoA --> | | <-- Proxy-CoA 185 +----+ +----+ 186 |MAG1|-----{MN2} |MAG2| 187 +----+ | +----+ 188 (MN-HoA) | | | <-- (MN-HoA) 189 (IPv4-MN-HoA) --> | (IPv4-MN-HoA) | <-- (IPv4-MN-HoA) 190 {MN1} {MN3} 192 Figure 1: IPv4 support for Proxy Mobile IPv6 194 1.1. Stated Assumptions 196 The following are the system and configuration requirements from the 197 mobility entities in the Proxy Mobile IPv6 domain for supporting the 198 extensions defined in this document. 200 o Both the mobility entities, the local mobility anchor and the 201 mobile access gateway are dual stack (IPv4/IPv6) enabled. 202 Irrespective of the type of transport network (IPv4 or IPv6) 203 separating these two entities, the mobility signaling is always 204 based on Proxy Mobile IPv6 [RFC-5213]. 206 o The local mobility anchor and the mobile access gateway MUST be 207 configured with IPv6 globally unique addresses, even when they are 208 in IPv4-only network. These addresses can be of the type Unique 209 Local IPv6 Unicast Address [RFC-4193], IPv6 Global Unicast Address 210 [RFC-3587] or IPv4-mapped IPv6 address [RFC-4291]. When using 211 IPv4 transport, it is not required that there is IPv6 routing 212 enabled between the local mobility anchor and the mobile access 213 gateway. However, they must be able to receive any IPv6 packets 214 sent to the configured IPv6 addresses, after removing the outer 215 IPv4 encapsulation header. 217 o The mobile node can be operating in IPv4-only, IPv6-only or in 218 dual mode. Based on what is enabled for a mobile node, it should 219 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 220 address(es) for its interface and furthermore achieve mobility 221 support for those addresses. 223 o For enabling IPv4 home address mobility support to a mobile node, 224 it is not required that the IPv6 home address mobility support 225 needs to enabled. However, the respective protocol(s) support, 226 such as IPv4 or IPv6 packet forwarding, must be enabled on the 227 access link between the mobile node and the mobile access gateway. 229 o The mobile node can obtain an IPv4 address for its attached 230 interface. Based on the type of link, it may be able to acquire 231 its IPv4 address configuration using standard IPv4 address 232 configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332], 233 IKEv2 [RFC-4306] or static address configuration. 235 o The mobile node's IPv4 home subnet is typically a shared address 236 space. It is not for the exclusive use of any one mobile node. 237 There can be multiple mobile nodes that are assigned IPv4 238 addresses from the same subnet. 240 o The mobile access gateway is the IPv4 default router for the 241 mobile node on its access link. It will be in the forwarding path 242 for the mobile node's data traffic. Additionally, as specified in 243 section 6.9.3 of [RFC-5213], all the mobile access gateways in the 244 Proxy Mobile IPv6 domain MUST use the same link-layer address on 245 any of the access links wherever the mobile node attaches. 247 1.2. Relevance to Dual-Stack Mobile IPv6 249 IPv4 support for Mobile IPv6 is specified in Dual-Stack Mobile IPv6 250 specification [RFC-5555]. This document to most part leverages the 251 approaches, messaging options and processing logic defined in that 252 document for extending IPv4 support to Proxy Mobile IPv6, except with 253 deviation in some aspects for obvious reasons of supporting a 254 network-based mobility model. Following are some of the related 255 considerations. 257 o The messaging option, IPv4 Care-of Address option defined in [RFC- 258 5555] for use in Binding Update and Binding Acknowledgement 259 messages are used by this specification to be carried in Proxy 260 Binding Update and Proxy Binding Acknowledgement messages. 262 o The extensions needed to the conceptual data structures, Binding 263 Cache entry and Binding Update List entry, for storing the state 264 related to the IPv4 support defined in [RFC-5555], will all be 265 needed and relevant for this document. 267 o The NAT traversal logic specified in [RFC-5555] for detecting the 268 on-path NAT devices is valid for this specification as well. 270 o The tunneling considerations specified in [RFC-5555] for 271 supporting IPv4 transport is relevant for this document as well. 273 If a given home agent [RFC-3775] implementation has support for both 274 Dual-stack Mobile IPv6 [RFC-5555] and local mobility anchor function 275 [RFC-5213], when extending IPv4 support as specified in this document 276 the above common functions and the related considerations have to be 277 reused for Proxy Mobile IPv6 signaling flows. 279 2. Conventions & Terminology 281 2.1. Conventions 283 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 284 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 285 document are to be interpreted as described in RFC 2119 [RFC-2119]. 287 2.2. Terminology 289 All the mobility related terms used in this document are to be 290 interpreted as defined in the Mobile IPv6 specification [RFC-3775] 291 and Proxy Mobile IPv6 specification [RFC-5213]. In addition this 292 document introduces the following terms. 294 IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) 296 The IPv4 address that is configured on the egress-interface of the 297 mobile access gateway. When using IPv4 transport, this address 298 will be the registered care-of address in the mobile node's 299 Binding Cache entry and will also be the transport-endpoint of the 300 tunnel between the local mobility anchor and a mobile access 301 gateway. However, if the configured address is a private IPv4 302 address and with a NAT device in the path to the local mobility 303 anchor, the care-of address as seen by the local mobility anchor 304 will be the address allocated by the NAT device for that flow. 306 IPv4 Local Mobility Anchor Address (IPv4-LMAA) 308 The IPv4 address that is configured on the egress-interface of the 309 local mobility anchor. When using IPv4 transport, the mobile 310 access gateway sends the Proxy Binding Update messages to this 311 address and will be the transport-endpoint of the tunnel between 312 the local mobility anchor and the mobile access gateway. 314 Mobile Node's IPv4 Home Address (IPv4-MN-HoA) 316 The IPv4 home address assigned to the mobile node's attached 317 interface. This address is topologically anchored at the local 318 mobility anchor. The mobile node configures this address on its 319 attached interface. If the mobile node connects to the Proxy 320 Mobile IPv6 domain via multiple interfaces each of the interfaces 321 are assigned a unique IPv4 address. All the IPv6 home network 322 prefixes and the IPv4 home address assigned to a given interface 323 of a mobile node will be managed under one mobility session. 325 Selective De-registration 326 A procedure for partial de-registration of all the addresses that 327 belong to one address family, i.e., de-registration of either IPv4 328 home address, or all of the IPv6 home network prefixes. 330 Encapsulation Modes 332 This document uses the following terms when referring to the 333 different encapsulation modes. 335 IPv4-or-IPv6-over-IPv6 337 IPv4 or IPv6 packet carried as a payload of an IPv6 packet 339 IPv4-or-IPv6-over-IPv4 341 IPv4 or IPv6 packet carried as a payload of an IPv4 packet 343 IPv4-or-IPv6-over-IPv4-UDP 345 IPv4 or IPv6 packet carried as a payload in an IPv4 packet with 346 a UDP header 348 IPv4-or-IPv6-over-IPv4-UDP-TLV 350 IPv4 packet carried as a payload in an IPv4 packet with UDP and 351 TLV headers 353 3. IPv4 Home Address Mobility Support 355 The IPv4 home address mobility support essentially enables a mobile 356 node in a Proxy Mobile IPv6 domain to obtain IPv4 home address 357 configuration for its attached interface and be able to retain that 358 address configuration even after changing its point of attachment in 359 that Proxy Mobile IPv6 domain. This section describes the protocol 360 operation and the required extensions to Proxy Mobile IPv6 protocol 361 for extending IPv4 home address mobility support. 363 When an IPv4-enabled or a dual-stack enabled mobile node attaches to 364 the Proxy Mobile IPv6 domain, the mobile access gateway on the access 365 link where the mobile node is attached will identify the mobile node 366 and will initiate the Proxy Mobile IPv6 signaling with the mobile 367 node's local mobility anchor. The mobile access gateway will follow 368 the signaling considerations specified in Section 3.2 for requesting 369 IPv4 home address mobility support. Upon the completion of the 370 signaling, the local mobility anchor and the mobile access gateway 371 will establish the required routing states for allowing the mobile 372 node to use its IPv4 home address from its current point of 373 attachment. 375 The mobile node on the access link using any of the standard IPv4 376 address configuration mechanisms supported on that access link, such 377 as IPCP [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], will be able 378 to obtain an IPv4 home address (IPv4-MN-HoA) for its attached 379 interface. Although the address configuration mechanisms for 380 delivering the address configuration to the mobile node is 381 independent of the Proxy Mobile IPv6 protocol operation, however 382 there needs to be some interactions between these two protocol flows. 383 Section 3.4 identifies these interactions for supporting DHCP based 384 address configuration. 386 The support for IPv4 home address mobility is not dependent on the 387 IPv6 home address mobility support. It is not required that the IPv6 388 home address mobility support needs to be enabled for providing IPv4 389 home address mobility support. A mobile node will be able to obtain 390 IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its 391 attached interface. The mobile node's policy profile will determine 392 if the mobile node is entitled for both the protocol versions or a 393 single protocol version. Based on the policy, only those protocols 394 will be enabled on the access link. Furthermore, if the mobile node 395 after obtaining the address configuration on its interface performs 396 an handoff, either by changing its point of attachment over the same 397 interface or to a different interface, the network will ensure the 398 mobile node will be able to use the same IPv4 address configuration 399 after the handoff. 401 Additionally, If the mobile node connects to the Proxy Mobile IPv6 402 domain, through multiple interfaces and simultaneously through 403 different access networks, each of the connected interfaces will 404 obtain an IPv4 home address from different subnets. In such 405 scenario, there will be multiple Binding Cache entries for the mobile 406 node on the local mobility anchor. All the address (IPv4/IPv6) 407 assigned to a given interface will be managed as part of one mobility 408 session, as specified in Section 5.4 of [RFC-5213]. 410 3.1. Local Mobility Anchor Considerations 412 3.1.1. Extensions to Binding Cache Entry 414 To support this feature, the conceptual Binding Cache entry data 415 structure maintained by the local mobility anchor needs to include 416 the following parameters. 418 o The IPv4 home address assigned to the mobile node's interface and 419 registered by the mobile access gateway. The IPv4 home address 420 entry also includes the corresponding subnet mask. It is to be 421 noted that this parameter is defined in the [RFC-5555] and is 422 presented here for completeness. 424 o The IPv4 default router address assigned to the mobile node. 426 3.1.2. Signaling Considerations 428 3.1.2.1. Processing Proxy Binding Updates 430 The processing rules specified in Section 5.3 of [RFC-5213] are 431 applied for processing the received Proxy Binding Update message. 432 However, if the received Proxy Binding Update message has an IPv4 433 Home Address Request option, the following considerations MUST be 434 applied additionally. 436 o If there is an IPv4 Home Address Request option present in the 437 received Proxy Binding Update message, but if there is no Home 438 Network Prefix option [RFC-5213] present in the request, the local 439 mobility anchor MUST NOT reject the request as specified in 440 Section 5.3.1 of [RFC-5213]. At least one instance of any of 441 these two options, either the IPv4 Home Address Request option or 442 the Home Network Prefix option, MUST be present. If there is not 443 a single instance of any of these two options present in the 444 request, the local mobility anchor MUST reject the request and 445 send a Proxy Binding Acknowledgement message with Status field set 446 to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home 447 network prefix option) [RFC-5213]. 449 o If there is at least one instance of Home Network Prefix option 450 [RFC-5213] present in the received Proxy Binding Update message, 451 but either if it is known from the mobile node's policy profile 452 that the mobile node is not authorized for IPv6 service or if IPv6 453 routing not enabled in the home network, the local mobility anchor 454 MUST reject the request and send a Proxy Binding Acknowledgement 455 message with the Status field set to 456 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX (mobile node not 457 authorized for the requesting IPv6 home network prefix). 459 o If there are more than one instance of the IPv4 Home Address 460 Request option present in the request, then the local mobility 461 anchor MUST reject the request and send a Proxy Binding 462 Acknowledgement message with the Status field set to 463 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 464 home address assignment not supported). 466 o For associating the received Proxy Binding Update message to an 467 existing mobility session, the local mobility anchor MUST perform 468 the Binding Cache entry existence test by applying the following 469 considerations. 471 * If there is at least one instance of the Home Network Prefix 472 option [RFC-5213] with a NON_ZERO prefix value, or, if there is 473 an IPv4 Home Address Request option with the IPv4 address in 474 the option set to ALL_ZERO, considerations from Section 5.4.1 475 of [RFC-5213] MUST be applied. 477 * If there is an IPv4 Home Address Request option present in the 478 request with the IPv4 address value in the option set to a 479 NON_ZERO value, considerations from Section 3.1.2.7 MUST be 480 applied. 482 o If there is no existing Binding Cache entry that can be associated 483 with the request, the local mobility anchor MUST consider this 484 request as an initial binding registration request and 485 considerations from Section 3.1.2.2 MUST be applied. 486 Additionally, if there are one or more Home Network Prefix options 487 [RFC-5213] present in the request, considerations from Section 488 5.3.2 of [RFC-5213] MUST also be applied. 490 o If there exists a Binding Cache entry that can be associated with 491 the request, the local mobility anchor MUST apply considerations 492 from Section 5.3.1 of [RFC-5213], (point 13), to determine if the 493 request is re-registration or a de-registration request. If the 494 request is a re-registration request, considerations from Section 495 3.1.2.3 MUST be applied and if it is a de-registration request, 496 considerations from Section 3.1.2.4 MUST be applied. 498 o If there exists a Binding Cache entry that can be associated with 499 the request and if it is determined that the request is a re- 500 registration request for extending IPv4 home address mobility 501 support to the existing IPv6-only mobility session, considerations 502 from Section 3.1.2.2 MUST be applied with respect to IPv4 support. 504 3.1.2.2. Initial Binding Registration (New Mobility Session) 506 o If there is an IPv4 Home Address Request option present in the 507 Proxy Binding Update message with the IPv4 address value in the 508 option set to ALL_ZERO, the local mobility anchor MUST allocate an 509 IPv4 home address to the mobile node and associate it with the new 510 mobility session created for that mobile node. 512 o If there is an IPv4 Home Address Request option with the IPv4 513 address in the option set to a NON_ZERO value, the local mobility 514 anchor before accepting the request MUST ensure the address is 515 topologically anchored on the local mobility anchor and 516 furthermore the mobile node is authorized to use that address. If 517 the mobile node is not authorized for that specific address, the 518 local mobility anchor MUST reject the request and send a Proxy 519 Binding Acknowledgement message with the Status field set to 520 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized 521 for the requesting IPv4 address). It MUST also include the IPv4 522 Home Address Reply option in the reply with the status field value 523 in the option set to 129 (Administratively prohibited). 525 o If the local mobility anchor is unable to allocate an IPv4 address 526 due to lack of resources, it MUST reject the request and send a 527 Proxy Binding Acknowledgement message with Status field set to 130 528 (Insufficient resources). It MUST also include the IPv4 Home 529 Address Reply option in the reply with the status field value in 530 the option set to 128 (Failure, reason unspecified). 532 o Upon accepting the request, the local mobility anchor MUST create 533 a Binding Cache entry for this mobility session. However, if the 534 request also contains one or more Home Network Prefix options 535 [RFC-5213], there should still be only one Binding Cache entry 536 that should be created for this mobility session. The created 537 Binding Cache entry MUST be used for managing both IPv4 and IPv6 538 home address bindings. The fields in the Binding Cache entry MUST 539 be updated with the accepted values for that session. 541 o The local mobility anchor MUST establish a bi-directional tunnel 542 to the mobile access gateway and with the encapsulation mode set 543 to the negotiated mode for carrying the IPv4 payload traffic. 544 When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6- 545 over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 546 packet). When using IPv4 transport, the encapsulation mode is as 547 specified in Section 4.0. 549 o The local mobility anchor MUST create an IPv4 host route (or a 550 platform specific equivalent function that sets up the forwarding) 551 for tunneling the packets received for the mobile node's home 552 address associated with this mobility session. 554 o The local mobility anchor MUST send the Proxy Binding 555 Acknowledgement message with the Status field set to 0 (Proxy 556 Binding Update Accepted). The message MUST be constructed as 557 specified in Section 3.1.2.6. 559 3.1.2.3. Binding Lifetime Extension (No handoff) 561 All the considerations from Section 5.3.3 of [RFC-5213] MUST be 562 applied. 564 3.1.2.4. Binding Lifetime Extension (After handoff) 566 o If there is no Home Network Prefix option(s) [RFC-5213] present in 567 the request, but if the Binding Cache entry associated with this 568 request has IPv6 home network prefix(es), the local mobility 569 anchor MUST consider this as a request to extend lifetime only for 570 the IPv4 home address and not for the IPv6 home network 571 prefix(es). Hence, the local mobility anchor SHOULD release all 572 the IPv6 home network prefix(es) assigned to that mobile node and 573 for that specific attached interface. Similar considerations 574 apply for the case where there is no IPv4 Home Address Request 575 option present in the request, but if the Binding Cache entry 576 associated with that request has both IPv4 home address and IPv6 577 home network prefix(es). 579 o The local mobility anchor MUST remove the previously created IPv4 580 host route (or the forwarding state) and the dynamically created 581 bi-directional tunnel for carrying the IPv4 payload traffic (if 582 there are no other mobile nodes for which the tunnel is being 583 used). This will remove the routing state towards the mobile 584 access gateway where the mobile node was anchored prior to the 585 handoff. 587 o The local mobility anchor MUST create a bi-directional tunnel to 588 the mobile access gateway that sent the request (if there is no 589 existing bi-directional tunnel) and with the encapsulation mode 590 set to the negotiated mode for carrying the IPv4 payload traffic. 591 An IPv4 host route for tunneling the packets received for the 592 mobile node's IPv4 home address MUST also be added. 594 o The required forwarding state identified in Section 5.3.6 of [RFC- 595 5213] is for IPv6 payload traffic. Those considerations apply for 596 IPv4 payload traffic as well. However, if IPv4 transport is in 597 use, considerations from Section 4.0 MUST be applied. 599 3.1.2.5. Binding De-Registration 601 All the considerations from Section 5.3.5 of [RFC-5213] MUST be 602 applied. Additionally, for removing the IPv4 state as part of the 603 Binding Cache entry deletion, the IPv4 host route and the dynamically 604 created bi-directional tunnel for carrying the IPv4 payload traffic 605 (if there are no other mobile nodes for which the tunnel is being 606 used) MUST be removed. However, if the request is for a selective 607 de-registration (IPv4 home address only, or all the IPv6 home network 608 prefixes), the Binding Cache entry MUST NOT be deleted, only the 609 respective states with respect to those addresses MUST be deleted. 611 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 613 The local mobility anchor when sending the Proxy Binding 614 Acknowledgement message to the mobile access gateway MUST construct 615 the message as specified in Section 5.3.6 of [RFC-5213]. 616 Additionally, the following considerations MUST be applied. 618 o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to 619 include at least one instance of Home Network Prefix option [RFC- 620 5213] in the Proxy Binding Acknowledgement message that it sends 621 to the mobile access gateway. However, if the received Proxy 622 Binding Update message has only the IPv4 Home Address Request 623 option and did not contain the Home Network Prefix option(s), then 624 the local mobility anchor MUST NOT include any Home Network Prefix 625 option(s) in the reply. However, there MUST be at least one 626 instance of either the Home Network Prefix option [RFC-5213] or 627 the IPv4 Home Address Reply option present in the Proxy Binding 628 Acknowledgement message. 630 o The IPv4 Home Address Reply option MUST be present in the Proxy 631 Binding Acknowledgement message. 633 1. If the Status field is set to a value greater than or equal to 634 (128), i.e., if the Proxy Binding Update is rejected, then 635 there MUST be an IPv4 Home Address Reply option corresponding 636 to the IPv4 Home Address Request option present in the request 637 and with the IPv4 address value and the prefix length fields 638 in the option set to the corresponding values in the request. 639 The status field value in the option must be set to the 640 specific error code. 642 2. For all other cases, there MUST be an IPv4 Home Address Reply 643 option for carrying the IPv4 home address assigned for that 644 mobility session and with the value in the option set to the 645 allocated IPv4 address. The prefix length in the option MUST 646 be set to the prefix length of the allocated address. The 647 status field value in the option must be set to 0 (Success). 649 o The IPv4 Default-Router Address option MUST be present, if the 650 Status field value in the Proxy Binding Acknowledgement message is 651 set to 0 (Proxy Binding Update Accepted). Otherwise, the option 652 MUST NOT be present. If the option is present, the default router 653 address in the option MUST be set to the mobile node's default 654 router address. 656 3.1.2.7. Binding Cache Entry Lookup Considerations 658 The Binding Cache entry lookup considerations specified in section 659 5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213] 660 as the key parameter for identifying the Binding Cache entry. 661 However, when there are no Home Network Prefix options with a 662 NON_ZERO value present in the request a single Home Network Prefix 663 option with NON_ZERO value present in the request, but if there an 664 IPv4 Home Address option with a NON_ZERO value present in the 665 request, the following considerations MUST be applied. 667 o The search rules specified in section 5.4.1.1 of [RFC-5213], which 668 primarily uses IPv6 home network prefix set as the search key, are 669 equally valid when using a single IPv4 home address as the key. 670 When applying those considerations, instead of the IPv6 home 671 network prefix(es), the IPv4 home address from the IPv4 Home 672 Address option present in the request MUST be used as the search 673 key. 675 o These rules specified in section 5.4.1.1 of [RFC-5213], assume the 676 presence of one or more IPv6 home network prefixes in the received 677 request and also in the Binding Cache entry. But, when using the 678 IPv4 home address as the search key, these considerations MUST 679 always assume just one single IPv4 home address, both in the 680 request and also in the Binding Cache entry. 682 3.1.3. Routing Considerations for the Local Mobility Anchor 684 Intercepting Packets Sent to the Mobile Node's IPv4 home address: 686 o When the local mobility anchor is serving a mobile node, it MUST 687 advertise a connected route in to the Routing Infrastructure for 688 the mobile node's IPv4 home address or for its home subnet, in 689 order to receive packets that are sent to the mobile node's IPv4 690 home address. This essentially enables IPv4 routers in that 691 network to detect the local mobility anchor as the last-hop router 692 for that subnet. 694 Forwarding Packets to the Mobile Node: 696 o On receiving a packet from a correspondent node with the 697 destination address matching the mobile node's IPv4 home address, 698 the local mobility anchor MUST forward the packet through the bi- 699 directional tunnel setup for that mobile node. 701 o The format of the tunneled packet when payload protection is not 702 enabled: 704 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 705 IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ 706 Upper layer protocols /* Packet Content*/ 708 Figure 2: Tunneled Packets from LMA to MAG 710 Forwarding Packets Sent by the Mobile Node: 712 o All the reverse tunneled packets that the local mobility anchor 713 receives from the mobile access gateway, after removing the tunnel 714 header MUST be routed to the destination specified in the inner 715 IPv4 packet header. These routed packets will have the source 716 address field set to the mobile node's IPv4 home address. 718 3.1.4. ECN & Payload Fragmentation Considerations 720 The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply 721 for the IPv4 payload packets as well. The mobility agents at the 722 tunnel entry and exit points MUST handle ECN information as specified 723 in that document. 725 The mobility agents at the tunnel entry and exit points MUST apply 726 the IP packet fragmentation considerations as specified in section 7 727 of [RFC-2473] and additionally they MUST apply the considerations 728 related to tunnel error processing and reporting as specified in 729 section 8 of [RFC-2473]. 731 3.2. Mobile Access Gateway Considerations 733 3.2.1. Extensions to Binding Update List Entry 735 To support the IPv4 home address mobility feature, the conceptual 736 Binding Update List entry data structure needs to be extended with 737 the following additional fields. 739 o The IPv4 home address assigned to the mobile node's attached 740 interface. This IPv4 home address may have been statically 741 configured in the mobile node's policy profile, or, may have been 742 dynamically allocated by the local mobility anchor. The IPv4 home 743 address entry also includes the corresponding subnet mask. 745 o The IPv4 default router address of the mobile node. This is 746 acquired from the mobile node's local mobility anchor through the 747 received Proxy Binding Acknowledgment message. 749 3.2.2. Extensions to Mobile Node's Policy Profile 751 To support the IPv4 Home Address Mobility Support feature the mobile 752 node's policy profile, specified in Section 6.2 of [RFC-5213] MUST be 753 extended with the following additional fields. 755 Extensions to the mandatory section of the policy profile: 757 o This field identifies all the IP protocol versions for which the 758 home address mobility support needs to be extended to the mobile 759 node. The supported modes are IPv4-only, IPv6-only and dual IPv4/ 760 IPv6. 762 Extensions to the optional section of the policy profile: 764 o The IPv4 home address assigned to the mobile node's attached 765 interface. The specific details on how the network maintains the 766 association between the address and the attached interface is 767 outside the scope of this document. This address field also 768 includes the corresponding subnet mask. 770 3.2.3. Signaling Considerations 772 3.2.3.1. Mobile Node Attachment and Initial Binding Registration 774 After detecting a new mobile node on its access link, the mobile 775 access gateway on the access link MUST determine if IPv4 home address 776 mobility support needs to be enabled for that mobile node. The 777 mobile node's policy profile identifies the supported modes (IPv4- 778 only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the 779 mobile service needs to be enabled. Based on those policy 780 considerations and from other triggers such as from the network, if 781 it is determined that IPv4 home address mobility support needs to be 782 enabled for the mobile node, considerations from section 6.9.1.1 of 783 [RFC-5213] MUST be applied with the following exceptions. 785 o The IPv4 Home Address Request option MUST be present in the Proxy 786 Binding Update message. 788 * If the mobile access gateway learns the mobile node's IPv4 home 789 address either from its policy profile, or from other means, 790 the mobile access gateway MAY ask the local mobility anchor to 791 allocate that specific address by including exactly one 792 instance of the IPv4 Home Address Request option with the IPv4 793 home address and the prefix length fields in the option set to 794 that specific address and its prefix length. 796 * The mobile access gateway MAY also ask the local mobility 797 anchor for dynamic IPv4 home address allocation. It can 798 include exactly one instance of the IPv4 Home Address option 799 with the IPv4 home address and the prefix length fields in the 800 option set to ALL_ZERO value. Furthermore, the (P) flag in the 801 option MUST be set to 0. This essentially serves as a request 802 to the local mobility anchor for the IPv4 home address 803 allocation. 805 o The Proxy Binding Update message MUST be constructed as specified 806 in Section 6.9.1.5 of [RFC-5213]. However, the Home Network 807 Prefix option(s) [RFC-5213] MUST be present in the Proxy Binding 808 Update only if IPv6 home address mobility support also needs to be 809 enabled for the mobile node. Otherwise, the Home Network Prefix 810 option(s) MUST NOT be present. 812 o When using IPv4 transport for carrying the signaling messages, the 813 related considerations from section 4.0 MUST be applied 814 additionally. 816 3.2.3.2. Receiving Proxy Binding Acknowledgement 818 All the considerations from section 6.9.1.2 of [RFC-5213] MUST be 819 applied with the following exceptions. 821 o If the received Proxy Binding Acknowledgement message has the 822 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 823 mobile node is not authorized for IPv4 home address), the mobile 824 access gateway SHOULD NOT send a Proxy Binding Update message 825 including the IPv4 Home Address Request option till an 826 administrative action is taken. 828 o If the received Proxy Binding Acknowledgement message has the 829 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 830 mobile node is not authorized for the requesting IPv4 home 831 address), the mobile access gateway SHOULD NOT request for the 832 same address again, but MAY request the local mobility anchor to 833 do the assignment of address by including exactly one instance of 834 IPv4 Home Address Request option with the IPv4 home address and 835 the prefix length fields in the option set to ALL_ZERO value. 837 o If there is no IPv4 Home Address Reply option present in the 838 received Proxy Binding Acknowledgement message, the mobile access 839 gateway MUST NOT enable IPv4 support for the mobile node and the 840 rest of the considerations from this section can be skipped. 842 o If the received Proxy Binding Acknowledgement message has the 843 Status field value in the IPv4 Home Address Reply option set to a 844 value that indicates that the request was rejected by the local 845 mobility anchor, the mobile access gateway MUST NOT enable 846 forwarding for that specific IPv4 home address. 848 o If the received Proxy Binding Acknowledgement message has the 849 Status field value set to 0 (Proxy Binding Update accepted), the 850 mobile access gateway MUST update a Binding Update List entry for 851 that mobile node. The entry MUST be updated with the assigned 852 IPv4 home address and other accepted registration values. 854 o If the received Proxy Binding Acknowledgement message has the 855 Status field value set to 0 (Proxy Binding Update accepted) and 856 has the IPv4 Home Address Reply option set to a value that 857 indicates that the request was accepted by the local mobility 858 anchor, the mobile access gateway MUST establish a bi-directional 859 tunnel to the local mobility anchor (if there is no existing bi- 860 directional tunnel to that local mobility anchor) and with the 861 encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6 862 packet carried as a payload of an IPv6 packet). Considerations 863 from Section 5.6.1 of [RFC-5213] MUST be applied for managing the 864 dynamically created bi-directional tunnel. However, when using 865 IPv4 transport, the encapsulation mode MUST be set to the 866 negotiated encapsulation mode, as specified in Section 4 of this 867 specification. 869 o The mobile access gateway MUST set up the route for forwarding the 870 IPv4 packets received from the mobile node (using its IPv4 home 871 address) through the bi-directional tunnel set up for that mobile 872 node. 874 o The default router address MUST be obtained from the IPv4 Default- 875 Router Address option present in the received Proxy Binding 876 Acknowledgement message. The mobile access gateway MAY configure 877 this address on its interface and respond to any ARP requests sent 878 by the mobile node for resolving the hardware address of the 879 default router. It MAY also use this address as the source 880 address for any datagrams sent to the mobile node and originated 881 by the mobile access gateway itself. It MAY also use this address 882 in the DHCP Router option [RFC-2132] in the DHCP messages. 884 o If there is an IPv4 DHCP Support Mode option present in the 885 received Proxy Binding Acknowledgement message and if the (S) flag 886 in the option is set to a value of (1), then the mobile access 887 gateway MUST function as a DHCP server for the mobile node. If 888 either the (S) flag in the option is set to a value of (0), or if 889 the option is not present in the request, then the mobile access 890 gateway MUST function as a DHCP Relay for the mobile node. 892 3.2.3.3. Binding Re-Registration and De-Registrations 894 When sending a Proxy Binding Update either for extending the lifetime 895 of a mobility session or for de-registering the mobility session, the 896 respective considerations from [RFC-5213] MUST be applied. 897 Furthermore, the following additional considerations MUST also be 898 applied. 900 o If there is an IPv4 home address assigned to the mobility session, 901 then there MUST be exactly one instance of the IPv4 Home Address 902 Request option present in the Proxy Binding Update message. The 903 IPv4 home address and the prefix length fields in the option MUST 904 be set to that specific address and its corresponding subnet-mask 905 length. 907 o If there was no IPv4 home address requested in the initial Proxy 908 Binding Update message, but if it is determined that the IPv4 home 909 address MUST be requested subsequently, then there MUST be exactly 910 one instance of the IPv4 Home Address Request option present in 911 the Proxy Binding Update message. The IPv4 home address in the 912 option MUST be set to either ALL_ZERO or to a specific address 913 that is being requested. 915 o For performing selective de-registration of IPv4 home address but 916 still retaining the mobility session with all the IPv6 home 917 network prefixes, the Proxy Binding Update message with the 918 lifetime value of (0) MUST NOT include any IPv6 Home Network 919 Prefix options(s) [RFC-5213]. It MUST include exactly one 920 instance of the IPv4 Home Address Request option with the IPv4 921 home address and the prefix length fields in the option set to the 922 IPv4 home address that is being de-registered. Similarly for 923 selective de-registration of all the IPv6 home network prefixes, 924 the Proxy Binding Update message MUST NOT include the IPv4 Home 925 address option, it MUST include a Home Network Prefix option for 926 each of the assigned home network prefixes assigned for that 927 mobility session and with the prefix value in the option set to 928 that respective prefix value. 930 o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present 931 if the same option(s) was not present in the initial Proxy Binding 932 Update message. Otherwise considerations from [RFC-5213] with 933 respect to this option MUST be applied. 935 o If at any point the mobile access gateway fails to extend the 936 binding lifetime with the local mobility anchor for the mobile 937 node's IPv4 address, it MUST remove any forwarding state set up 938 for the mobile node's IPv4 home address. 940 3.2.4. Routing Considerations for the Mobile Access Gateway 942 o On receiving a packet from the bi-directional tunnel established 943 with the mobile node's local mobility anchor, the mobile access 944 gateway MUST remove the outer header before forwarding the packet 945 to the mobile node. 947 o Considerations from Section 6.10.3 of [RFC-5213] MUST be applied 948 with respect the local routing and on the use of 949 EnableMAGLocalRouting flag. 951 o On receiving a packet from a mobile node connected to its access 952 link, the packet MUST be forwarded to the local mobility anchor 953 through the bi-directional tunnel established with the local 954 mobility anchor. The encapsulation considerations specified in 955 section 3.1.3 MUST be applied. However, before forwarding the 956 packet, the mobile access gateway MUST ensure the source address 957 in the received packet is the address allocated for that mobile 958 node and that there is an active binding on the local mobility 959 anchor for that mobile node. 961 o The mobile access gateway MAY use proxy ARP [RFC-925] to reply to 962 ARP Requests that it receives from the mobile node seeking address 963 resolutions for the destinations on the mobile node's home subnet. 964 When receiving an ARP Request, the local mobility anchor can 965 examine the target IP address of the Request, and if this IP 966 address matches the mobile node's IPv4 home subnet, it MAY 967 transmit a Proxy ARP Reply. 969 3.3. Mobility Options and Status Codes 971 To support the IPv4 home address mobility feature, this specification 972 defines the following new options and Status Codes. 974 3.3.1. IPv4 Home Address Request Option 976 A new option, IPv4 Home Address Request Option is defined for use 977 with the Proxy Binding Update message sent by the mobile access 978 gateway to the local mobility anchor. This option is used for 979 requesting IPv4 home address assignment for the mobile node. 981 The IPv4 Home Address Request option has an alignment requirement of 982 4n. Its format is as follows: 984 0 1 2 3 985 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 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Type | Length |Prefix-len | Reserved | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | IPv4 home address | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 Figure 3: IPv4 Home Address Request Option 994 Type 996 IANA 998 Length 1000 8-bit unsigned integer indicating the length of the option in 1001 octets, excluding the type and length fields. This field MUST 1002 be set to (6). 1004 Prefix-len 1006 This 6-bit unsigned integer indicating the prefix length of the 1007 IPv4 home address contained in the option. 1009 Reserved 1011 This 10-bit field is unused for now. The value MUST be 1012 initialized to (0) by the sender and MUST be ignored by the 1013 receiver. 1015 IPv4 home address 1017 This four-byte field containing the IPv4 home address that is 1018 being requested. The value of 0.0.0.0 is used for requesting 1019 the local mobility anchor to perform the address allocation. 1021 3.3.2. IPv4 Home Address Reply Option 1023 A new option, IPv4 Home Address Reply Option is defined for using it 1024 in the Proxy Binding Acknowledgment message sent by the local 1025 mobility anchor to the mobile access gateway. This option can be 1026 used for sending the assigned mobile node's IPv4 home address. 1028 The IPv4 Home Address Reply option has an alignment requirement of 1029 4n. Its format is as follows: 1031 0 1 2 3 1032 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 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | Type | Length | Status |Pref-len |Res| 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | IPv4 home address | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 Figure 4: IPv4 Home Address Reply Option 1041 Type 1043 IANA 1045 Length 1046 8-bit unsigned integer indicating the length of the option in 1047 octets, excluding the type and length fields. This field MUST 1048 be set to (6). 1050 Status 1052 Indicates success or failure for the IPv4 home address 1053 assignment. Values from 0 to 127 indicate success. Higher 1054 values indicate failure. The following status values are 1055 currently allocated by this document: 1057 0 Success 1059 128 Failure, reason unspecified 1061 129 Administratively prohibited 1063 130 Incorrect IPv4 home address 1065 131 Invalid IPv4 address 1067 132 Dynamic IPv4 home address assignment not available 1069 Prefix-len 1071 This 6-bit unsigned integer is used for carrying the prefix 1072 length of the mobile node's IPv4 home network corresponding the 1073 IPv4 home address contained in the option. 1075 Reserved (Res) 1077 This 2-bit field is unused for now. The value MUST be 1078 initialized to (0) by the sender and MUST be ignored by the 1079 receiver. 1081 IPv4 home address 1083 This four-byte field is used for carrying the IPv4 home address 1084 assigned to the mobile node. 1086 3.3.3. IPv4 Default-Router Address Option 1088 A new option, IPv4 Default-Router Address Option is defined for using 1089 it in the Proxy Binding Acknowledgment message sent by the local 1090 mobility anchor to the mobile access gateway. This option can be 1091 used for sending the mobile node's IPv4 default router address. 1093 The IPv4 Default-Router Address option has an alignment requirement 1094 of 4n. Its format is as follows: 1096 0 1 2 3 1097 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 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Type | Length | Reserved (R) | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | IPv4 Default-Router Address | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 Figure 5: IPv4 Default-Router Address Option 1106 Type 1108 IANA 1110 Length 1112 8-bit unsigned integer indicating the length of the option in 1113 octets, excluding the type and length fields. This field MUST 1114 be set to (6). 1116 Reserved (R) 1118 This 16-bit field is unused for now. The value MUST be 1119 initialized to (0) by the sender and MUST be ignored by the 1120 receiver. 1122 IPv4 Default-Router Address 1124 A four-byte field containing the mobile node's default router 1125 address. 1127 3.3.4. IPv4 DHCP Support Mode 1129 A new option, IPv4 DHCP Support Mode Option is defined for using it 1130 in the Proxy Binding Acknowledgment message sent by the local 1131 mobility anchor to the mobile access gateway. This option can be 1132 used for notifying the mobile access gateway, if it should function 1133 as a DHCP Server or a DHCP Relay for the attached mobile node. 1135 The IPv4 DHCP Support Mode option has no alignment requirement. Its 1136 format is as follows: 1138 0 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Type | Length | Reserved (R) |S| 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 Figure 6: IPv4 DHCP Support Mode Option 1146 Type 1148 IANA 1150 Length 1152 8-bit unsigned integer indicating the length of the option in 1153 octets, excluding the type and length fields. This field MUST 1154 be set to 2. 1156 Reserved (R) 1158 This 15-bit field is unused for now. The value MUST be 1159 initialized to (0) by the sender and MUST be ignored by the 1160 receiver. 1162 DHCP Support Mode (S) 1164 A 1-bit field that specifies the DHCP support mode. This flag 1165 indicates if the mobile access gateway should function as a 1166 DHCP Server or a DHCP Relay for the attached mobile node. The 1167 flag value of (0) indicates the mobile access gateway should 1168 act as a DHCP Relay and the flag value of (1) indicates it 1169 should act as a DHCP Server. 1171 3.3.5. Status Codes 1173 This document defines the following new Status values for use in the 1174 Proxy Binding Acknowledgement message. These values are to be 1175 allocated from the same numbering space, as defined in Section 6.1.8 1176 of [RFC-3775]. 1178 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 1180 Mobile node not authorized for the requesting IPv4 home address 1182 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA 1183 Mobile node not authorized for the requesting IPv6 home network 1184 prefix(es). 1186 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED 1188 Multiple IPv4 home address assignment not supported 1190 3.4. Supporting DHCP-Based Address Configuration 1192 This section explains how DHCP-based address configuration support 1193 can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It 1194 explains the protocol operation, supported DHCP server deployment 1195 configurations and the protocol interactions between DHCP agents and 1196 mobility entities in each of the supported configurations. 1198 This specification supports the following two DHCP deployment 1199 configurations. 1201 o DHCP relay agent co-located with the mobile access gateway. 1203 o DHCP server co-located in the mobile access gateway. 1205 The following are the configuration requirements: 1207 o The DHCP server or the DHCP relay agent configured on the mobile 1208 access gateway is required to have an IPv4 address for exchanging 1209 the DHCP messages with the mobile node. This address is the 1210 mobile node's default router address provided by the local 1211 mobility anchor. Optionally, all the DHCP servers co-located with 1212 the mobile access gateways in the Proxy Mobile IPv6 domain can be 1213 configured with a fixed IPv4 address. This fixed address can be 1214 potentially an IPv4 private address [RFC-1918] that can be used 1215 for the DHCP protocol communication on any of the access links. 1216 This address will be used as the server identifier in the DHCP 1217 messages. 1219 o A DHCP server identifies a DHCP client from the client identifier, 1220 if present, or from the client hardware address (chaddr), as 1221 specified in [RFC-2131]. It uses this identity for identifying 1222 the client and its interface for which the address is assigned. A 1223 mobile node in a Proxy Mobile IPv6 domain, can attach to the 1224 network through multiple interfaces and can obtain address 1225 configuration for each of its interfaces. Additionally, it may 1226 perform handoffs between its interfaces. Following are the 1227 related considerations with respect to the identification 1228 presented to the DHCP server. 1230 * If the mobile node attaches to the Proxy Mobile IPv6 domain 1231 through multiple interfaces, the DHCP server will uniquely 1232 identify each of those interfaces and will perform address 1233 assignment. The DHCP server will identify the client as 1234 specified in [RFC-2131]. If the client identifier is present, 1235 that will be used for identifying the mobile node, otherwise 1236 the client hardware address will be used. Anytime the mobile 1237 node changes its point of attachment in the network and 1238 performs an handoff to a different mobile access gateway, using 1239 the same interface, the DHCP server will always be able to 1240 identify the binding using the presented identifier, the client 1241 identifier or the hardware address. The client identifier or 1242 the hardware address will remain as the primary key for each 1243 binding, just as how they are unique in a Binding Cache entry. 1245 * However, if the mobile node is capable of performing handoff 1246 between interfaces, as per [RFC-5213], the client identifier in 1247 such scenarios needs to be an identifier that is not tied to 1248 any of those interfaces. The identifier must be a stable 1249 identifier which remains the same through out the mobile node's 1250 attachment in that Proxy Mobile IPv6 domain. This identifier 1251 must remain fixed for a given binding. This identifier in some 1252 implementations can be the identifier associated to a virtual 1253 interface, that is abstracting the physical interfaces. 1255 o All the DHCP servers co-located with the mobile access gateways in 1256 a Proxy Mobile IPv6 domain can be configured with the same set of 1257 DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure 1258 the mobile node receives the same configuration values on any of 1259 the access links in that Proxy Mobile IPv6 domain. 1261 3.4.1. DHCP Server co-located with the Mobile Access Gateway 1263 This section explains the operational sequence of home address 1264 assignment operation when the DHCP server is co-located with the 1265 mobile access gateway. 1267 MN MAG(DHCP-S) LMA 1268 |------>| | 1. DHCPDISCOVER 1269 | |------->| 2. Proxy Binding Update 1270 | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) 1271 | |========| 4. Tunnel/Route Setup 1272 |<------| | 5. DHCPOFFER (IPv4 HoA) 1273 |------>| | 6. DHCPREQUEST (IPv4 HoA) 1274 |<------| | 7. DHCPACK 1275 | | | 1276 * It is possible the MAG may have already completed the Proxy Mobile 1277 IPv6 signaling with the LMA for requesting both IPv6 home network 1278 prefix(es) and IPv4 home address assignment prior to step-1. In 1279 such event, the Proxy Mobile IPv6 signaling steps (step-2 to 1280 step-4) above are not relevant. 1281 * It is possible the MAG may have initially completed the Proxy 1282 Mobile IPv6 signaling prior to Step-1, but only for requesting 1283 IPv6 home network prefix(es) and may later request IPv4 home 1284 address assignment after detecting the DHCP triggers from the 1285 mobile node as shown above. 1286 * The MAG may choose to ignore the DHCPDISCOVER messages till the 1287 Proxy Mobile IPv6 signaling is successfully completed, or it may 1288 choose to send a delayed response for reducing the additional 1289 delay waiting for a new DHCPDISCOVER message from the mobile node. 1291 Figure 7: Overview of DHCP Server located at Mobile Access Gateway 1293 Initial IPv4 Home Address Assignment: 1295 o For acquiring the mobile node's IPv4 home address from the local 1296 mobility anchor, the mobile access gateway will initiate Proxy 1297 Mobile IPv6 signaling with the local mobility anchor. 1299 o After the successful completion of the Proxy Mobile IPv6 signaling 1300 and upon acquiring the mobile node's IPv4 home address from the 1301 local mobility anchor, the DHCP server on the mobile access 1302 gateway will send a DHCPOFFER message [RFC-2131] to the mobile 1303 node. The offered address will be the mobile node's IPv4 home 1304 address, assigned by the local mobility anchor. The DHCPOFFER 1305 message will also have the subnet mask option [RFC-2132] and 1306 router option [RFC-2132], with the values in those options set to 1307 the mobile node's IPv4 home subnet mask and default router address 1308 respectively. Additionally, the Server Identifier option will be 1309 included and with the value in the option set to the default 1310 router address. 1312 o If the mobile node sends the DHCPREQUEST message, the DHCP server 1313 will send DHCPACK message, as per [RFC-2131]. 1315 IPv4 Home Address Renewal with the DHCP server (No Handoff): 1317 o Any time the mobile node goes into the DHCP RENEWING state [RFC- 1318 2131], it simply unicasts the DHCPREQUEST message including the 1319 assigned IPv4 home address in the 'requested IP address' option. 1320 The DHCPREQUEST is sent to the address specified in 'server 1321 identifier' field of the previously received DHCPOFFER and DHCPACK 1322 messages. 1324 o The DHCP server will send a DHCPACK to the mobile node to 1325 acknowledge the assignment of the committed IPv4 address. 1327 IPv4 Home Address Renewal with the DHCP server (After Handoff): 1329 When the mobile node goes into the DHCP RENEWING state [RFC-2131], it 1330 directly unicasts the DHCPREQUEST message to the DHCP server that 1331 currently provided the DHCP lease. However, if the mobile node 1332 changed its point of attachment and is attached to a new mobile 1333 access gateway, it is required that the mobile node updates the DHCP 1334 server address and uses the address of the DHCP server that is co- 1335 located with the new mobile access gateway. The following approach 1336 can be adopted to ensure the mobile node uses the DHCP server on the 1337 attached link. 1339 MN oMAG(DHCP-S) nMAG(DHCP-S) 1340 | : | 1341 RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) 1342 BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK 1343 | : | 1344 * The use of a fixed DHCP server address on all DHCP servers 1346 Figure 8: Address renewal with the DHCP server 1348 o If a fixed address such as the IPv4 default router address of the 1349 mobile node is used as the DHCP server Id on any of the links in 1350 that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the 1351 mobile node for renewing the address will be received by the new 1352 mobile access gateway on the attached link. The mobile access 1353 gateway after completing the Proxy Mobile IPv6 signaling and upon 1354 acquiring the IPv4 home address of the mobile node will return the 1355 address in the DHCPACK message. However, if the mobile access 1356 gateway is unable to complete the Proxy Mobile IPv6 signaling or 1357 is unable to acquire the same IPv4 address as requested by the 1358 mobile node, it will send a DHCPNACK message [RFC-2131] to the 1359 mobile node, as shown in Figure 8-1). 1361 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway 1363 A DHCP relay agent is co-located with each mobile access gateway. A 1364 DHCP server is located somewhere in the Proxy Mobile IPv6 domain 1365 (e.g., is co-located with the local mobility anchor). Figure 9 shows 1366 the sequence of IPv4 home address assignment using DHCP Relay. 1368 MN MAG(DHCP-R) LMA DHCP-S 1369 | |------->| | 1. Proxy Binding Update * 1370 | |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA) 1371 | |========| | 3. Tunnel/Route Setup* 1372 |------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R 1373 |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R 1374 |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R 1375 |<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R 1376 | | | 1377 * The Proxy Mobile IPv6 signaling (starting at Step-1) and the 1378 DHCP address configuration (starting at Step-4) may start in any 1379 order. However, the DHCPOFFER (Step-5) and the immediate steps 1380 following it will occur in the specified order and only after the 1381 Tunnel/Route Setup (Step-3). 1382 * It is possible the MAG may have initially completed the Proxy 1383 Mobile IPv6 signaling with the LMA only for requesting IPv6 home 1384 network prefix(es) and may later request IPv4 home address 1385 assignment after detecting the DHCP triggers from the mobile node 1386 (after Step-4). 1387 * The MAG may choose to ignore the DHCPDISCOVER messages till the 1388 Proxy Mobile IPv6 signaling is successfully completed, or it may 1389 choose to send a delayed response for reducing the additional 1390 delay waiting for a new DHCPDISCOVER message from the mobile node. 1392 Figure 9: Overview of the DHCP relay located at mobile access gateway 1394 Initial IPv4 Home Address Assignment: 1396 o For acquiring the mobile node's IPv4 home address from the local 1397 mobility anchor, the mobile access gateway will initiate Proxy 1398 Mobile IPv6 signaling with the local mobility anchor. 1400 o After the successful completion of the Proxy Mobile IPv6 signaling 1401 and upon acquiring the mobile node's IPv4 home address from the 1402 local mobility anchor, the mobile access gateway will enable 1403 forwarding for all the DHCP messages between the mobile node and 1404 the DHCP server. 1406 o The DHCP relay agent on the mobile access gateway will add the 1407 DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER 1408 message. The assigned IPv4 home address will be included in the 1409 Agent Remote ID Sub-option of the DHCP relay agent information 1410 option. This sub-option is used as a hint for requesting the DHCP 1411 server to allocate that specific IPv4 address. 1413 o On receiving a DHCPOFFER message from the DHCP server, the mobile 1414 access gateway will ensure the assigned address is currently 1415 assigned by the local mobility anchor to that mobile node. If 1416 this address is different from what is assigned to the mobile 1417 node, then the mobile access gateway will drop the DHCPOFFER 1418 message and an administrative error message will be logged. 1420 o When the DHCP messages are sent over administrative boundaries, 1421 the operators needs to ensure these messages are secured. All the 1422 DHCP messages relayed by the mobile access gateway can be tunneled 1423 to the local mobility anchor if needed. Alternatively, if the 1424 network in the Proxy Mobile IPv6 domain is secure enough, the 1425 mobile access gateway can just relay the DHCP messages to the 1426 server. To achieve this, all the mobile access gateways needs to 1427 have a route towards the DHCP server. 1429 IPv4 Home Address Renewal to the same DHCP server: (No Handoff) 1431 o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it 1432 directly unicasts DHCPREQUEST messages to the DHCP server. The 1433 DHCP relay agent may not detect any changes in the DHCP state. 1434 For example, if the mobile node releases the IPv4 address, the 1435 relay agent would not be aware of it. The following describes 1436 additional mechanisms for the mobile access gateway to detect any 1437 changes in the DHCP state. 1439 * The DHCP relay agent can intercept all IPv4 DHCP packets 1440 destined to the set of addresses used within the Proxy Mobile 1441 IPv6 domain as DHCP addresses. Since the link between a mobile 1442 node and a mobile access gateway is the point-to-point link, 1443 the mobile access gateway will be in path for all the messages. 1445 * The DHCP relay agent can use the DHCP Server Identifier 1446 Override Sub-option [RFC-5107] to be in path for all the DHCP 1447 message flows. The DHCP client uses the DHCP server address 1448 which is overridden by the DHCP relay agent address as a 1449 destination address of DHCPREQUEST. The DHCP Server Identifier 1450 Override Sub-option is recommended only when the fixed DHCP 1451 relay address is configured on all the mobile access gateways. 1452 Otherwise, the DHCP relay agent address is changed when the 1453 mobile node changes the attached mobile access gateway. 1455 o However, if the DHCP server is co-located with the local mobility 1456 anchor, then the DHCP relay agent is not required to intercept the 1457 unicast DHCP messages between the mobile node and the DHCP server. 1458 This is because the local mobility anchor will ensure that the 1459 DHCP state is consistent with the PMIPv6 binding that exists for 1460 the IPv4 address. 1462 o Once the mobile access gateway intercepts the DHCP message from 1463 the mobile node to the DHCP server, it can verify if the mobile 1464 node is negotiating the same IPv4 address that the local mobility 1465 anchor allocated for that mobile node. If the address in the 1466 DHCPREQUEST message does not match with the IPv4 address allocated 1467 for the mobile node, then the mobile access gateway SHOULD 1468 silently drop the DHCP message. 1470 o Any time the mobile access gateway detects that the mobile node 1471 has released its IPv4 address, it can send a Proxy Binding Update 1472 to the local mobility anchor and de-register the IPv4 mobility 1473 session. 1475 3.4.3. Common DHCP Considerations 1477 The following DHCP related considerations are common to both the 1478 supported configuration modes, specified in Section 3.4.1 and Section 1479 3.4.2. 1481 o When a mobile node sends a DHCPDISCOVER message [RFC-2131], the 1482 DHCP server or the relay agent co-located with the mobile access 1483 gateway will trigger the mobile access gateway to complete the 1484 Proxy Mobile IPv6 signaling. This is the required interaction 1485 between these two protocols. The mobile access gateway on 1486 receiving this trigger will check if there is already an assigned 1487 IPv4 home address for the mobile node, from the local mobility 1488 anchor. If there is no assigned IPv4 home address assigned for 1489 that mobile node, the mobile access gateway will complete the 1490 Proxy Mobile IPv6 signaling with the local mobility anchor by 1491 sending a Proxy Binding Update message. 1493 o The mobile node needs to be identified by the MN-Identifier, as 1494 specified in Section 6.6 of [RFC-5213]. This identity should be 1495 associated to the DHCP messages sent by the mobile node. 1497 o The mobile access gateway will drop all the DHCPDISCOVER messages 1498 till it completes the Proxy Mobile IPv6 signaling. If the mobile 1499 access gateway is unable to complete the Proxy Mobile IPv6 1500 signaling, or, if the local mobility anchor does not assign an 1501 IPv4 address for the mobile node, the mobile access gateway MUST 1502 NOT enable IPv4 home address mobility support for the mobile node 1503 on that access link. 1505 o The trigger for initiating Proxy Mobile IPv6 signaling can also be 1506 delivered to the mobile access gateway as part of a context 1507 transfer from the previous mobile access gateway, or delivered 1508 from the other network elements in the radio network, the details 1509 of which are outside the scope of this document. 1511 o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST 1512 include the Subnet Mask option [RFC-2132] and the Router option 1513 [RFC-2132]. The values in the Subnet Mask option and Router 1514 option MUST be set to the mobile node's IPv4 home subnet mask and 1515 its default router address respectively. 1517 o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST 1518 include the Interface MTU option [RFC-2132]. The DHCP servers in 1519 the Proxy Mobile IPv6 domain MUST be configured to include the 1520 Interface MTU option. The MTU value SHOULD reflect the tunnel MTU 1521 for the bi-directional tunnel between the mobile access gateway 1522 and the local mobility anchor. 1524 o The DHCP lease length allocated to the mobile node's IPv4 home 1525 address may be different from the binding lifetime at the local 1526 mobility anchor for that mobile node's session. It is not 1527 possible to keep these lifetimes synchronized and so its not 1528 required that the configured lifetimes should be kept same in both 1529 DHCP and Proxy Mobile IPv6. 1531 o When the mobile node performs an handoff from one mobile access 1532 gateway to another, the mobile access gateway on the new link will 1533 initiate the Proxy Mobile IPv6 signaling with the local mobility 1534 anchor. On completing the Proxy Mobile IPv6 signaling, the mobile 1535 access gateway has the proper IPv4 address state that the local 1536 mobility anchor has allocated for the mobile node and which can be 1537 used for supporting DHCP based address configuration on that link. 1539 o Any time the mobile node detects a link change event due to 1540 handoff, or due to other reasons such as re-establishment of the 1541 link-layer, the following are the mobile node's considerations 1542 with respect to the DHCP protocol. 1544 * If the mobile node is DNAv4 [RFC-4436] capable and if it 1545 performs DNAv4 procedures after receiving a link change event, 1546 it would always detect the same default router on any of the 1547 access links in that Proxy Mobile IPv6 domain, as the mobile 1548 access gateway configures a fixed link-layer address on all the 1549 access links, as per the base Proxy Mobile IPv6 specification 1550 [RFC-5213]. The mobile node will not perform any DHCP 1551 operation specifically due to this event. 1553 * If the mobile node is not DNAv4 [RFC-4436] capable, after 1554 receiving the link change event it will enter INIT-REBOOT state 1555 [RFC-2131] and will send a DHCPREQUEST message as specified in 1556 Section 3.7 of [RFC-2131]. The mobile node will obtain the 1557 same address configuration as before, as the link change does 1558 not result in any change at the network layer. 1560 o The mobile node may release its IPv4 home address at any time by 1561 sending the DHCPRELEASE message [RFC-2131]. When the mobile 1562 access gateway detects the DHCPRELEASE message sent by the mobile 1563 node, it should consider this as a trigger for de-registering the 1564 mobile node's IPv4 home address. It will apply the considerations 1565 specified in section 3.2.3.3 for performing the de-registration 1566 procedure. However, this operation MUST NOT release any IPv6 home 1567 network prefix(es) assigned to the mobile node. 1569 4. IPv4 Transport Support 1571 The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling 1572 messages exchanged between the local mobility anchor and the mobile 1573 access gateway to be over an IPv6 transport. The extensions defined 1574 in this section allow the exchange of signaling messages over an IPv4 1575 transport when the local mobility anchor and the mobile access 1576 gateway are separated by an IPv4 network and are reachable using only 1577 IPv4 addresses. 1579 IPv4-Proxy-CoA IPv4-LMAA 1580 | + - - - - - - + | 1581 +--+ +---+ / \ +---+ +--+ 1582 |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| 1583 +--+ +---+ \ / +---+ +--+ 1584 + - - - - - - + 1586 Figure 10: IPv4 Transport Network 1588 When the local mobility anchor and the mobile access gateway are 1589 configured and reachable using only IPv4 addresses, the mobile access 1590 gateway serving a mobile node can potentially send the signaling 1591 messages over IPv4 transport and register its IPv4 address as the 1592 care-of address in the mobile node's Binding Cache entry. An IPv4 1593 tunnel (with any of the supported encapsulation modes) can be used 1594 for tunneling the mobile node's data traffic. The following are the 1595 key aspects of this feature. 1597 o The local mobility anchor and the mobile access gateway are both 1598 configured and reachable using an IPv4 address. Additionally, 1599 both entities are also IPv6 enabled and have configured IPv6 1600 addresses on their interfaces, as specified in [RFC-5213], but are 1601 reachable only over an IPv4 transport network. 1603 o The mobile access gateway can be potentially in a private IPv4 1604 network behind a NAT [RFC-3022] device, with a private IPv4 1605 address configured on its egress interface. But, the local 1606 mobility anchor must not be behind a NAT and must be using a 1607 globally routable IPv4 address. However, both the local mobility 1608 anchor and the mobile access gateway can be in the same private 1609 IPv4 routing domain, i.e., when both are configured with private 1610 IPv4 addresses and with no need for NAT translation between them. 1612 o The IPv6 address configuration requirement on the mobile access 1613 gateway does not imply there needs to be IPv6 routing enabled 1614 between the local mobility anchor and the mobile access gateway. 1615 It just requires each of the mobile access gateways and local 1616 mobility anchors in a Proxy Mobile IPv6 domain to be configured 1617 with a globally unique IPv6 address. 1619 o The Proxy Mobile IPv6 signaling messages exchanged between the 1620 local mobility anchor and the mobile access gateway for 1621 negotiating the IPv4 transport will be encapsulated and carried as 1622 IPv4 packets. However, these signaling messages are fundamentally 1623 IPv6 messages using the mobility header and the related semantics 1624 as specified in base Proxy Mobile IPv6 specification [RFC-5213], 1625 but carried as a payload in an IPv4 packet. The supported 1626 encapsulation modes for the signaling messages are either native 1627 IPv4 or IPv4 with UDP header. 1629 o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and 1630 the IPv4 transport support specified in this section is agnostic 1631 to the type of address mobility enabled for that mobile node. 1633 o The IPv4 tunnel established between the local mobility anchor and 1634 the mobile access gateway (with any of the supported encapsulation 1635 modes over IPv4 transport) will be used for carrying the mobile 1636 node's IPv4 and IPv6 traffic. The following are the outer headers 1637 based on the negotiated encapsulation mode. 1639 * IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet). 1640 If payload protection using IPsec is enabled for the tunneled 1641 traffic, the ESP header follows the outer tunnel header. 1643 * IPv4-UDP (Payload packet carried in an IPv4 packet with UDP 1644 header). If payload protection using IPsec is enabled for the 1645 tunneled traffic, the ESP header follows the outer tunnel 1646 header, as explained in Section 4.3. 1648 * IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP 1649 and TLV header). Refer to [ID-GREKEY-NEGO]. If payload 1650 protection using IPsec is enabled for the tunneled traffic, the 1651 ESP header follows the outer tunnel header, as explained in 1652 Section 4.3. 1654 4.1. Local Mobility Anchor Considerations 1656 4.1.1. Extensions to Binding Cache Entry 1658 To support this feature, the conceptual Binding Cache entry data 1659 structure maintained by the local mobility anchor [RFC-5213] MUST be 1660 extended with the following additional parameters. It is to be noted 1661 that all of these parameters are specified in [RFC-5555] and also 1662 required here in the present usage context, and are presented here 1663 only for completeness. 1665 o The IPv4 Proxy Care-of Address configured on the mobile access 1666 gateway that sent the Proxy Binding Update message. This address 1667 can be obtained from the IPv4 Care-of Address option [RFC-5555], 1668 present in the received Proxy Binding Update message. However, if 1669 the received Proxy Binding Update message is not sent as an IPv4 1670 packet, i.e., when using IPv6 transport, this field in the Binding 1671 Cache entry MUST be set to ALL_ZERO value. 1673 o The IPv4 NAT translated address of the mobile access gateway. If 1674 the mobile access gateway is not behind a NAT [RFC-3022], this 1675 address will be the same as the address configured on the egress 1676 interface of the mobile access gateway. This address can be 1677 obtained from the IPv4 header of the received Proxy Binding Update 1678 message. However, if the received Proxy Binding Update message is 1679 not sent as an IPv4 packet, this field in the Binding Cache entry 1680 MUST be set to ALL_ZERO value. 1682 o The source UDP port, if the Proxy Binding Update was received in 1683 an IPv4 packet with UDP header. 1685 o The destination UDP port, if the Proxy Binding Update was received 1686 in an IPv4 packet with UDP header. 1688 4.1.2. Extensions to Mobile Node's Policy Profile 1690 To support the IPv4 Transport Support feature the mobile node's 1691 policy profile, specified in Section 6.2 of [RFC-5213] MUST be 1692 extended with the following additional fields. These are mandatory 1693 fields of the policy profile required for supporting this feature. 1695 o The IPv4 address of the local mobility anchor (IPv4-LMAA). 1697 4.1.3. Signaling Considerations 1699 This section provides the rules for processing the Proxy Mobile IPv6 1700 signaling messages received over IPv4 transport. 1702 4.1.3.1. Processing Proxy Binding Updates 1704 o If the received Proxy Binding Update message was sent encapsulated 1705 in an IPv4 or IPv4-UDP packet, the message MUST be authenticated 1706 after removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1707 Considerations from Section 4 of [RFC-5213] MUST be applied for 1708 authenticating and authorizing the request. 1710 o All the considerations from Section 5.3.1 of [RFC-5213] MUST be 1711 applied on the encapsulated Proxy Binding Update message, after 1712 removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1714 o If there is an IPv4 Care-of Address option [RFC-5555] present in 1715 the request and if the outer encapsulation header is IPv4-UDP, 1716 then the NAT presence detection procedure specified in Section 1717 4.1.3.3 MUST be used for detecting the NAT in the path. 1719 o Upon accepting the request, the local mobility anchor MUST set up 1720 an IPv4 bi-directional tunnel to the mobile access gateway. The 1721 tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. 1722 The encapsulation mode MUST be determined by applying the 1723 following considerations: 1725 * If the received Proxy Binding Update message was sent with IPv4 1726 encapsulated header, then the encapsulation mode for the bi- 1727 directional tunnel MUST be set to IPv4. Otherwise, the 1728 following considerations apply. 1730 * If NAT is not detected on the path and if the (F) flag in the 1731 received Proxy Binding Update message is set to the value of 1732 (1), but if the configuration flag, 1733 AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of 1734 (0), then the local mobility anchor MUST reject the request 1735 with the Status field value set to 129 (Administratively 1736 prohibited). 1738 * If the (T) flag [ID-GREKEY-NEGO] in the Proxy Binding Update 1739 message is set to value of (1), then the encapsulation mode 1740 MUST be set to IPv4-or-IPv6-over-IPv4-UDP-TLV. 1742 * If NAT is detected on the path, or if the (F) flag in the 1743 received Proxy Binding Update message is set to the value of 1744 (1), then the encapsulation mode MUST be set to IPv4-or-IPv6- 1745 over-IPv4-UDP. Otherwise the encapsulation mode MUST be set to 1746 IPv4-or-IPv6-over-IPv4. 1748 o The local mobility anchor MUST send the Proxy Binding 1749 Acknowledgement message with the Status field value set to (0) 1750 (Proxy Binding Update Accepted). The message MUST be constructed 1751 as specified in Section 4.1.3.2. 1753 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 1755 The local mobility anchor when sending the Proxy Binding 1756 Acknowledgement message to the mobile access gateway MUST construct 1757 the message as specified in Section 5.3.6 of [RFC-5213]. However, if 1758 the received Proxy Binding Update message was encapsulated in an IPv4 1759 packet or as a payload in the UDP header of an IPv4 packet, the 1760 following additional considerations MUST be applied. 1762 o The Proxy Binding Acknowledgement message MUST be encapsulated in 1763 an IPv4 packet. However, if the received Proxy Binding Update 1764 message was sent encapsulated in an IPv4-UDP packet, then the 1765 Proxy Binding Acknowledgement message MUST be encapsulated in the 1766 UDP header of an IPv4 packet. 1768 o The source address in the IPv4 header of the message MUST be set 1769 to the destination IPv4 address of the received request. 1771 o If the mobile access gateway and the local mobility anchor are 1772 using globally routable IPv4 addresses and if there is a security 1773 association that is based on IPv4 addresses, then the encapsulated 1774 IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement) 1775 MUST be protected using IPsec ESP [RFC-4301] mode. There is no 1776 need to apply IPsec ESP header to the IPv6 packet. In all other 1777 cases, the Proxy Binding Acknowledgement message MUST be protected 1778 using IPsec prior to the IPv4 or IPv4-UDP encapsulation. 1780 o The NAT Detection option [RFC-5555] MUST be present only if there 1781 is an IPv4 Care-of Address option [RFC-5555] present in the 1782 received Proxy Binding Update message and if the NAT detection 1783 procedure resulted in detecting a NAT on path. However, if the 1784 received Proxy Binding Update message was not sent encapsulated in 1785 IPv4 UDP header, then the option MUST NOT be present. 1786 Furthermore, in all other cases, the option MUST NOT be present. 1788 o The IPv4 DHCP Support Mode option MAY be present. If this option 1789 is not present, the mobile access gateway will enable the default 1790 behavior and function as a DHCP Relay for the mobile node. 1792 o Figure 9 shows the format of the Proxy Binding Acknowledgement 1793 message encapsulated in an IPv4 packet and protected using IPv6 1794 security association. The UDP header MUST be present only if the 1795 received Proxy Binding Update message was sent encapsulated in an 1796 IPv4-UDP packet. 1798 IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) 1799 UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/ 1800 /* IPv6 PBA Packet protected with ESP header */ 1802 Figure 11: Proxy Binding Acknowledgment (PBA) Message encapsulated 1803 in IPv4 header 1805 4.1.3.3. NAT Presence Detection 1807 When the transport network between the local mobility anchor and the 1808 mobile access gateway is an IPv4 network and if the received Proxy 1809 Binding Update message was sent encapsulated in IPv4 UDP header, the 1810 local mobility anchor performs the NAT Presence Detection as 1811 specified below. 1813 On receiving the Proxy Binding Update message encapsulated in an IPv4 1814 UDP packet, the local mobility anchor, if it detects a NAT on the 1815 path, will send the Proxy Binding Acknowledgment message with the NAT 1816 Detection Option. The presence of this option in the Proxy Binding 1817 Acknowledgment is an indication to the mobile access gateway about 1818 the presence of NAT in the path. On detecting any NAT in the path, 1819 both the local mobility anchor and the mobile access gateway will set 1820 the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation. 1821 The specific details around the NAT detection and the related logic 1822 are described in DSMIPv6 specification [RFC-5555]. 1824 However, if the value of the configuration variable, 1825 UseIPv4UDPEncapForSignalingMessages, is set to a value of (0), the 1826 mobile access gateway will not use IPv4 UDP encapsulation for Proxy 1827 Binding Update messages and hence the local mobility anchor will not 1828 perform this NAT Presence Detection procedure on these messages that 1829 are not sent in IPv4 UDP packet. 1831 4.1.4. Routing Considerations 1833 4.1.4.1. Forwarding Considerations 1835 Forwarding Packets to the Mobile Node: 1837 o On receiving an IPv4 or an IPv6 packet from a correspondent node 1838 with the destination address matching any of the mobile node's 1839 IPv4 or IPv6 home addresses, the local mobility anchor MUST 1840 forward the packet through the bi-directional tunnel set up for 1841 that mobile node. 1843 o The format of the tunneled packet is shown below. 1845 IPv4 Header (src= IPv4-LMAA, dst= IPv4-Proxy-CoA)] /* Tunnel Header */ 1846 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1847 [TLV Header] /* If TLV negotiated */ 1848 /* IPv6 or IPv4 Payload Packet */ 1849 IPv6 header (src= CN, dst= MN-HOA) 1850 OR 1851 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1853 Figure 12: Tunneled IPv4 Packet from LMA to MAG 1855 o Forwarding Packets Sent by the Mobile Node: 1857 * All the reverse tunneled packets (IPv4 and IPv6) that the local 1858 mobility anchor receives from the mobile access gateway, after 1859 removing the tunnel header (i.e., the outer IPv4 header along 1860 with the UDP and TLV header, if negotiated) MUST be routed to 1861 the destination specified in the inner packet header. These 1862 routed packets will have the source address field set to the 1863 mobile node's home address. 1865 4.1.4.2. ECN & Payload Fragmentation Considerations 1867 The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply 1868 for the IPv4 transport tunnels as well. The mobility agents at the 1869 tunnel entry and exit points MUST handle ECN information as specified 1870 in that document. 1872 The mobility agents at the tunnel entry and exit points MUST apply 1873 the IP packet fragmentation considerations as specified in [RFC- 1874 4213]. Additionally they MUST also apply the considerations related 1875 to tunnel error processing and reporting as specified in the same 1876 specification. 1878 4.1.4.3. Bi-Directional Tunnel Management 1880 The Tunnel Management considerations specified in section 5.6.1 of 1881 [RFC-5213] apply for the IPv4 transport tunnels as well, with just 1882 one difference that the encapsulation mode is different. 1884 4.2. Mobile Access Gateway Considerations 1886 4.2.1. Extensions to Binding Update List Entry 1888 To support the IPv4 Transport Support feature, the conceptual Binding 1889 Update List entry data structure maintained by the mobile access 1890 gateway [RFC-5213] MUST be extended with the following additional 1891 parameters. 1893 o The IPv4 address of the local mobility anchor. This address can 1894 be obtained from the mobile node's policy profile. 1896 4.2.2. Signaling Considerations 1898 The mobile access gateway when sending a Proxy Binding Update message 1899 to the local mobility anchor MUST construct the message as specified 1900 in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access 1901 gateway is in an IPv4-only access network, the following additional 1902 considerations MUST be applied. 1904 o The Proxy Binding Update message MUST be encapsulated in an IPv4 1905 packet. However, if the value of the configuration variable, 1906 UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy 1907 Binding Update message MUST be encapsulated in an UDP header of an 1908 IPv4 packet. 1910 o The IPv4 Care-of Address option [RFC-5555] MUST be present. The 1911 IPv4 address in the option MUST be set to the mobile access 1912 gateway's IPv4-Proxy-CoA. 1914 o The packet MUST be constructed as specified in Section 4.2.2.1. 1916 o Just as specified in [RFC-5213], when sending a Proxy Binding 1917 message for extending the lifetime of a currently existing 1918 mobility session or for de-registering the mobility session, the 1919 Proxy Binding Update message MUST be constructed just as the 1920 initial request. 1922 Receiving Proxy Binding Acknowledgement 1924 o If the received Proxy Binding Acknowledgement message is 1925 encapsulated in IPv4 or IPv4 UDP packet, the message MUST be 1926 authenticated after removing the outer IPv4 or IPv4-UDP header. 1927 Considerations from Section 4 of [RFC-5213] MUST be applied for 1928 authenticating and authorizing the message. 1930 o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be 1931 applied on the encapsulated Proxy Binding Acknowledgement message, 1932 after removing the outer IPv4 UDP header. 1934 o If the Status field indicates Success, the mobile access gateway 1935 MUST setup a bi-directional tunnel to the local mobility anchor. 1937 o Upon accepting the request, the mobile access gateway MUST set up 1938 an IPv4 bi-directional tunnel to the local mobility anchor. The 1939 tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA. 1940 The encapsulation mode MUST be determined from the below 1941 considerations. 1943 o The encapsulation mode for the bi-directional tunnel MUST be set 1944 to IPv4. However, if the value of the configuration variable, 1945 UseIPv4UDPEncapForSignalingMessages, is set to (1), then the 1946 following considerations MUST be applied. 1948 * If there is a NAT Detection option [RFC-5555] in the received 1949 Proxy Binding Acknowledgement message and if the value of the 1950 configuration flag, UseIPv4UDPEncapForSignalingMessages, is set 1951 to value of (1), then the encapsulation mode for the tunnel 1952 MUST be set to IPv4-UDP. Otherwise the encapsulation mode MUST 1953 be set to IPv4. 1955 * If the (T) flag in the Proxy Binding Acknowledgement message is 1956 set to value of (1), then the encapsulation mode MUST be set to 1957 IPv4-UDP-TLV. 1959 4.2.2.1. Constructing the Proxy Binding Update Message 1961 o The source address in the IPv4 header MUST be set to IPv4-Proxy- 1962 CoA of the mobile access gateway and the destination address MUST 1963 be set to the local mobility anchor's IPv4-LMAA. 1965 o The IPv4 Care-of Address option [RFC-5555] MUST be present. The 1966 address MUST be set to the mobile access gateway's IPv4-Proxy-CoA. 1968 o If the configuration variable ForceIPv4UDPEncapsulationSupport is 1969 set to value of (1), then the (F) flag in the Proxy Binding Update 1970 message MUST be set to value of (1). 1972 o The Proxy Binding Update message MUST be protected using IPsec ESP 1973 [RFC-4301], as specified in [RFC-5213]. The protection MUST be 1974 applied on the IPv6 packet of the Proxy Binding Update message, 1975 prior to the IPv4 encapsulation. 1977 o The format of the Proxy Binding Update message encapsulated in an 1978 IPv4 or IPv4-UDP packet with no IPsec protection: 1980 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1981 UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/ 1982 /* IPv6 PBU Packet protected with ESP header */ 1984 Figure 13: Proxy Binding Update (PBU) message encapsulated in IPv4 1985 UDP header 1987 4.2.2.2. Forwarding Considerations 1989 Forwarding Packets Sent by the Mobile Node: 1991 o On receiving an IPv4 or an IPv6 packet from the mobile node to any 1992 destination, the mobile access gateway MUST tunnel the packet to 1993 the local mobility anchor. The format of the tunneled packet is 1994 shown below. However, considerations from Section 6.10.3 of [RFC- 1995 5213] MUST be applied with respect the local routing and on the 1996 use of EnableMAGLocalRouting flag. 1998 IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */ 1999 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 2000 [TLV Header] /* If TLV negotiated */ 2001 /* IPv6 or IPv4 Payload Packet */ 2002 IPv6 header (src= CN, dst= MN-HOA) 2003 OR 2004 IPv4 header (src= CN, dst= IPv4 MN-HoA) 2006 Figure 14 2008 o Forwarding Packets received from the bi-directional tunnel: 2010 o On receiving a packet from the bi-directional tunnel established 2011 with the mobile node's local mobility anchor, the mobile access 2012 gateway MUST remove the outer header before forwarding the packet 2013 to the mobile node. 2015 4.3. IPsec Considerations 2017 4.3.1. PBU and PBA 2019 The following section describes how IPsec is used for protecting the 2020 signaling messages and data packets between the local mobility anchor 2021 and mobile access gateway when using IPv4 transport. 2023 The following are the SPD example entries to protect PBU and PBA on 2024 the local mobility anchor and mobile access gateway. 2026 MAG SPD-S: 2027 - IF local_address = Proxy-CoA_1 & 2028 remote_address = LMAA_1 & proto = MH & 2029 local_mh_type = PBU & remote_mh_type = PBAck 2030 Then use SA ESP transport mode 2032 LMA SPD-S: 2033 - IF local_address = LMAA_1 & 2034 remote_address = Proxy-CoA_1 & proto = MH & 2035 local_mh_type = PBAck & remote_mh_type = PBU 2036 Then use SA ESP transport mode 2038 Figure 15 and Figure 16 show how PBU and PBA are sent and processed 2039 at the local mobility anchor and at the mobile access gateway. IPsec 2040 ESP is always applied before the PBU or the PBA is encapsulated in 2041 the outer IPv4 header. 2043 | PBU on wire : PBU internal processing 2044 \|/ \:/ 2046 MAG's PMIP Module 2047 : 2048 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2049 : Mobility header 2050 : PBU (p flag) 2051 : Home Network Prefix option 2052 : IPv4 Home Address Request option 2053 : IPv4 Care-of Address option 2054 : 2055 \:/ 2056 MAG's IPsec module 2057 : 2058 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2059 : ESP header in transport mode 2060 : Mobility header 2061 : PBU (p flag) 2062 : Home Network Prefix option 2063 : IPv4 Home Address Request option 2064 : IPv4 Care-of Address option 2065 : 2066 : * After adding the ESP header, the PBU is returned to the PMIP 2067 : module and is encapsulated into the UDP and IPv4 headers. 2068 : This requires a Proxy Mobile IPv6 specific IPsec implementation, 2069 : which knows that the packet needs to be passed back to the PMIP 2070 : module, instead of sending it out via the normal forwarding 2071 \:/ 2072 MAG 2073 | IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 2074 | UDP header (sport=Z, dport=DSMIPv6) 2075 | IPv6 header (src=Proxy-CoA, dst=LMAA) 2076 | ESP header in transport mode 2077 | Mobility header 2078 | PBU (p flag) 2079 | Home Network Prefix option 2080 | IPv4 Home Address Request option 2081 | IPv4 Care-of Address option 2082 \|/ 2083 LMA (received at DSMIPv6 port) 2084 : 2085 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2086 : ESP header in transport mode 2087 : Mobility header 2088 : PBU (p flag) 2089 : Home Network Prefix option 2090 : IPv4 Home Address Request option 2091 : IPv4 Care-of Address option 2092 : 2093 : *In addition, IPv4-Proxy-CoA and the sport (Z) needs to 2094 : be passed along with the packet to ensure correct processing. 2095 \:/ 2096 LMA's IPsec module 2097 : 2098 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2099 : Mobility header 2100 : PBU (p flag) 2101 : Home Network Prefix option 2102 : IPv4 Home Address Request option 2103 : IPv4 Care-of Address option 2104 : 2105 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2106 : be passed with the packet to ensure correct processing. 2107 \:/ 2108 LMA's PMIP module 2110 Figure 15: Proxy Binding Update 2112 | PBA on wire : PBA internal processing 2113 \|/ \:/ 2115 LMA's PMIP module 2116 : 2117 : IPv6 header (src=LMAA, dst=Proxy-CoA) 2118 : Mobility header 2119 : PBA (p flag) 2120 : Home Network Prefix option 2121 : IPv4 Home Address Reply option 2122 : IPv4 Care-of Address option 2123 \:/ 2124 LMA's IPsec module 2125 : 2126 : IPv6 header (src=LMAA, dst=Proxy-CoA) 2127 : ESP header in transport mode 2128 : Mobility header 2129 : PBA (p flag) 2130 : Home Network Prefix option 2131 : IPv4 Home Address Reply option 2132 : IPv4 Care-of Address option 2133 : 2134 : * After adding the ESP header, the PBA is returned to the PMIP 2135 : module and is encapsulated into the UDP and IPv4 headers. 2136 : This requires a Proxy Mobile IPv6 specific IPsec implementation, 2137 : which knows that the packet needs to be passed back to the PMIP 2138 : module, instead of sending it out via normal forwarding 2139 \:/ 2140 LMA 2141 | IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) 2142 | UDP header (sport=DSMIPv6, dport=Z) 2143 | IPv6 header (src=LMAA, dst=Proxy-CoA) 2144 | ESP header in transport mode 2145 | Mobility header 2146 | PBA (p flag) 2147 | Home Network Prefix option 2148 | IPv4 Home Address Reply option 2149 | IPv4 Care-of Address option 2150 \|/ 2151 MAG (received at DSMIPv6 listening port) 2152 : 2153 : IPv6 header (src=LMAA, dst=Proxy-CoA) 2154 : ESP header in transport mode 2155 : Mobility header 2156 : PBA (p flag) 2157 : Home Network Prefix option 2158 : IPv4 Home Address Reply option 2159 : IPv4 Care-of Address option 2160 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2161 : be passed with the packet to ensure correct processing. 2162 \:/ 2163 MAG's IPsec module 2164 : 2165 : IPv6 header (src=LMAA, dst=Proxy-CoA) 2166 : Mobility header 2167 : PBA (p flag) 2168 : Home Network Prefix option 2169 : IPv4 Home Address Reply option 2170 : IPv4 Care-of Address option 2171 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2172 : be passed with the packet to ensure correct processing. 2173 \:/ 2174 MAG's PMIP module 2176 Figure 16: Proxy Binding Acknowledgement 2178 4.3.2. Payload Packet 2180 The following are the SPD example entries to protect payload packets 2181 on the local mobility anchor and mobile access gateway. Note that 2182 the example SPDs protect all payload packets sent to and from mobile 2183 nodes. If an operator needs to apply a different security mechanism 2184 per mobile node, they need to create a SPD and a SA entry per mobile 2185 node. 2187 MAG SPD-S: 2188 - IF interface = IPv6 tunnel to LMAA_1 & 2189 local_address != Proxy-CoA_1 & 2190 remote_address != LMAA_1 & proto=any 2191 Then use SA ESP tunnel mode 2193 LMA SPD-S: 2194 - IF interface = IPv6 tunnel to Proxy-CoA_1 & 2195 local_address != LMAA_1 & 2196 remote_address != Proxy-CoA_1 & proto=any 2197 Then use SA ESP tunnel mode 2199 When a payload packet is protected by IPsec, MAG and LMA SHOULD 2200 always use the tunnel IPv6 header to let the payload packet be IPsec 2201 protected in the ESP tunnel mode. If IPsec is not applied to payload 2202 packets, this additional tunnel IPv6 header SHOULD be omitted and an 2203 IPv4 header SHOULD be used to encapsulate the data packet as shown in 2204 Figure 14 . 2206 | Packet on wire : Packet internal processing 2208 \|/ \:/ 2210 MN 2211 | IPv4/v6 header (src= MN-HoA, dst= CN) 2212 | Payload 2213 \|/ 2214 MAG's PMIP Module 2215 :3 2216 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2217 : IPv4/v6 header (src= MN-HoA, dst= CN) 2218 : Payload 2219 : 2220 \:/ 2221 MAG's IPsec module 2222 : 2223 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2224 : ESP header in tunnel mode 2225 : IPv4/v6 header (src= MN-HoA, dst= CN) 2226 : Payload 2227 : 2228 : * After the ESP header installation, the payload packet is returned 2229 : to the PMIP module and is encapsulated for the tunnel between MAG 2230 : and LMA. If necessary, the UDP and TLV headers are added to the 2231 : payload packet. 2232 : This requires a Proxy Mobile IPv6 specific IPsec implementation, 2233 : which knows that the packet needs to be passed back to the PMIP 2234 : module, instead of sending it out via normal forwarding 2235 \:/ 2236 MAG 2237 | 2238 | IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 2239 | UDP header (sport=Z, dport=DSMIPv6) /* If UDP encap nego */ 2240 | TLV Header /* If TLV negotiated */ 2241 | IPv6 header (src=Proxy-CoA, dst=LMAA) 2242 | ESP header in tunnel mode 2243 : IPv4/v6 header (src= MN-HoA, dst= CN) 2244 | Payload 2245 \|/ 2246 LMA (received at DSMIPv6 port) 2247 : 2248 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2249 : ESP header in tunnel mode 2250 : IPv4/v6 header (src= MN-HoA, dst= CN) 2251 : Payload 2252 : 2253 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2254 : be passed with the packet to ensure correct processing. 2255 \:/ 2256 LMA's IPsec module 2257 : 2258 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2259 : IPv4/v6 header (src= MN-HoA, dst= CN) 2260 : Payload 2261 : 2262 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2263 : be passed with the packet to ensure correct processing. 2264 \:/ 2265 LMA forwarding engine 2267 Figure 17: IPsec Protected Payload Packet 2269 5. Protocol Configuration Variables 2271 5.1. Local Mobility Anchor - Configuration Variables 2273 The local mobility anchor MUST allow the following variables to be 2274 configured by the system management. The configured values for these 2275 protocol variables MUST survive server reboots and service restarts. 2277 AcceptForcedIPv4UDPEncapsulationRequest 2279 This flag indicates whether or not the local mobility anchor 2280 should accept IPv4 UDP encapsulation request for the mobile node's 2281 data traffic, even if there is no NAT detected in the path. 2283 The default value for this flag is set to (0), indicating that the 2284 local mobility anchor MUST NOT accept IPv4 UDP encapsulation 2285 request when NAT is not detected in the path. 2287 When the value for this flag is set to (1), the local mobility 2288 anchor MUST accept IPv4 UDP encapsulation request even when NAT is 2289 not detected in the path. 2291 5.2. Mobile Access Gateway - Configuration Variables 2293 The mobile access gateway MUST allow the following variables to be 2294 configured by the system management. The configured values for these 2295 protocol variables MUST survive server reboots and service restarts. 2297 UseIPv4UDPEncapForSignalingMessages 2299 This flag indicates whether or not the mobile access gateway 2300 should use IPv4-UDP encapsulation mode for the signaling messages. 2302 The default value for this flag is set to (0), indicating that the 2303 mobile access gateway MUST NOT use IPv4-UDP encapsulation mode, 2304 but MUST use native IPv4 encapsulation mode for sending the Proxy 2305 Mobile IPv6 signaling messages. 2307 When the value for this flag is set to (1), the mobile access 2308 gateway MUST use IPv4-UDP encapsulation mode for sending the Proxy 2309 Mobile IPv6 signaling messages. 2311 ForceIPv4UDPEncapsulationSupport 2312 This flag indicates whether or not the mobile access gateway 2313 should request the mobile node's local mobility anchor for forcing 2314 IPv4 UDP encapsulation support for the mobile node's data traffic, 2315 even when NAT is not detected in the path. 2317 The default value for this flag is set to (0), indicating that the 2318 mobile access gateway MUST NOT request the mobile node's local 2319 mobility anchor for forcing IPv4 UDP encapsulation support even 2320 when NAT is not detected in path. 2322 When the value for this flag is set to (1), the mobile access 2323 gateway MUST force the mobile node's local mobility anchor for 2324 IPv4 UDP encapsulation support. 2326 This flag is applicable only when the flag 2327 UseIPv4UDPEncapForSignalingMessages is set to a value of (1). 2329 6. IANA Considerations 2331 This document defines two new Mobility Header options, IPv4 Home 2332 Address Request option, IPv4 Home Address Reply option, IPv4 Default 2333 Router Address option and IPv4 DHCP Support Mode option. These 2334 options are described in Sections 3.3.1, 3.3.2, 3.3.3 and 3.3.4 2335 respectively. The Type value for these options needs to be assigned 2336 from the same number space as allocated for the other mobility 2337 options, as defined in [RFC-3775]. 2339 The IPv4 Home Address Reply option, described in Section 3.3.2 of 2340 this document, introduces a new number space, IPv4 Home Address Reply 2341 Status Codes. This document currently reserves the following values. 2342 Approval of any new status code values are to be made through IANA 2343 Expert Review. 2345 o 0 Success 2347 o 128 Failure, reason unspecified 2349 o 129 Administratively prohibited 2351 o 130 Incorrect IPv4 home address 2353 o 131 Invalid IPv4 address 2355 o 132 Dynamic IPv4 home address assignment not available 2357 The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this 2358 document, introduces a new number space, IPv4 DHCP Support Mode 2359 Flags. This document reserves the value 0x1 for the (S) flag. 2360 Approval of this flag values are to be made through IANA Expert 2361 Review. 2363 This document also defines new status values, used in Proxy Binding 2364 Acknowledgement message, as described in Section 3.3.5. These values 2365 are to be assigned from the same number space as allocated for other 2366 Status codes [RFC-3775]. Each of these allocated values have to be 2367 greater than 128. 2369 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 2371 Mobile node not authorized for the requesting IPv4 home address 2373 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA 2375 Mobile node not authorized for the requesting IPv6 home network 2376 prefix(es). 2378 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED 2380 Multiple IPv4 home address assignment not supported 2382 7. Security Considerations 2384 All the security considerations from the base Proxy Mobile IPv6 [RFC- 2385 5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6 [RFC-5555] 2386 apply when using the extensions defined in this document. 2387 Additionally, the following security considerations need to be 2388 applied. 2390 This document defines new mobility options for supporting the IPv4 2391 Home Address assignment and IPv4 Transport Support features. These 2392 options are to be carried in Proxy Binding Update and Proxy Binding 2393 Acknowledgement messages. The required security mechanisms specified 2394 in the base Proxy Mobile IPv6 protocol for protecting these signaling 2395 messages are sufficient when carrying these mobility options. 2397 This specification describes the use of IPv4 transport for exchanging 2398 the signaling messages between the local mobility anchor and the 2399 mobile access gateway. These signaling messages are fundamentally 2400 IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4 2401 packets. The encapsulated inner IPv6 message is still protected 2402 using IPsec, using the established security association and this 2403 offers the same level of security as when the messages are routed 2404 natively as IPv6 packets. The use of outer IPv4 header does not 2405 introduce any new security vulnerabilities. 2407 8. Contributors 2409 This document reflects discussions and contributions from several 2410 people (in alphabetical order): 2412 Kuntal Chowdhury 2414 kchowdhury@starentnetworks.com 2416 Vijay Devarapalli 2418 vijay.devarapalli@azairenet.com 2420 Sangjin Jeong 2422 sjjeong@etri.re.kr 2424 Basavaraj Patil 2426 basavaraj.patil@nsn.com 2428 Myungki Shin 2430 myungki.shin@gmail.com 2432 9. Acknowledgments 2434 The IPv4 support for Proxy Mobile IPv6 was initially covered in the 2435 internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like 2436 to thank all the authors of the document and acknowledge that initial 2437 work. 2439 Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles 2440 Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen, 2441 Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen, 2442 Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe 2443 Wu and Zu Qiang for their helpful review of this document. 2445 Also, we would like to thank Spencer Dawkins, Tim Polk and Menachem 2446 Dodge and Adrian Farrel for their reviews of this document as part of 2447 the IESG review process. 2449 10. References 2450 10.1. Normative References 2452 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 2453 Requirement Levels", BCP 14, RFC 2119, March 1997. 2455 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2456 2131, March 1997. 2458 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 2459 IPv6", RFC 3775, June 2004. 2461 [RFC-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast 2462 Addresses", RFC-4193, October 2005. 2464 [RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing 2465 Architecture", RFC-4291, February 2006. 2467 [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, 2468 November 2007. 2470 [RFC-5555] Soliman, H. et al, "Mobile IPv6 support for dual stack 2471 Hosts and Routers (DSMIPv6)", RFC-5555, June 2009. 2473 10.2. Informative References 2475 [RFC-925] Postel, J., "Multi-LAN Address Resolution", RFC 925, 2476 October 1984. 2478 [RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol 2479 (IPCP)", RFC 1332, May 1992. 2481 [RFC-1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2482 and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 2483 1918, February 1996. 2485 [RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor 2486 Extensions", RFC 2132, March 1997. 2488 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2489 IPv6 Specification", RFC 2473, December 1998. 2491 [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2492 Address Translator (Traditional NAT)", RFC 3022, January 2001. 2494 [RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January 2495 2001. 2497 [RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 2498 Unicast Address Format", RFC 3587, August 2003. 2500 [RFC-4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms 2501 for IPv6 Hosts and Routers", RFC 4213, October 2005. 2503 [RFC-4301] Kent, S. and K. Seo, "Security Architecture for the 2504 Internet Protocol", RFC 4301, December 2005. 2506 [RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 2507 4306, December 2005. 2509 [RFC-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network 2510 Attachment in IPv4", RFC 4436, March 2006. 2512 [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack 2513 Mobility", RFC 4977, August 2007. 2515 [RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp, 2516 "DHCP Server Identifier Override Suboption", RFC 5107, February 2008. 2518 [ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K., 2519 "GRE Key Option for Proxy Mobile IPv6", 2520 draft-ietf-netlmm-grekey-option-09.txt, May 2009. 2522 Authors' Addresses 2524 Ryuji Wakikawa 2525 TOYOTA InfoTechnology Center, U.S.A., Inc. 2526 465 Bernardo Avenue 2527 Mountain View, CA 94043 2528 USA 2530 Email: ryuji@us.toyota-itc.com 2532 Sri Gundavelli 2533 Cisco 2534 170 West Tasman Drive 2535 San Jose, CA 95134 2536 USA 2538 Email: sgundave@cisco.com