idnits 2.17.1 draft-ietf-netlmm-pmip6-ipv4-support-14.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 (July 13, 2009) is 5393 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: January 14, 2010 Cisco 6 July 13, 2009 8 IPv4 Support for Proxy Mobile IPv6 9 draft-ietf-netlmm-pmip6-ipv4-support-14.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 January 14, 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.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17 70 3.2.1. Extensions to Binding Update List Entry . . . . . . . 18 71 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18 72 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 18 73 3.2.4. Routing Considerations for the Mobile Access 74 Gateway . . . . . . . . . . . . . . . . . . . . . . . 22 75 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23 76 3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23 77 3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 24 78 3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 25 79 3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 26 80 3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 27 81 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 28 82 3.4.1. DHCP Server co-located with the Mobile Access 83 Gateway . . . . . . . . . . . . . . . . . . . . . . . 29 84 3.4.2. DHCP Relay Agent co-located with the Mobile Access 85 Gateway . . . . . . . . . . . . . . . . . . . . . . . 32 86 3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 34 88 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 37 89 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 38 90 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 38 91 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 39 92 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 39 93 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 42 94 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 43 95 4.2.1. Extensions to Binding Update List Entry . . . . . . . 43 96 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 44 97 4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 46 99 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 50 100 5.1. Local Mobility Anchor - Configuration Variables . . . . . 50 101 5.2. Mobile Access Gateway - Configuration Variables . . . . . 50 103 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 54 107 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 55 109 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 112 10.1. Normative References . . . . . . . . . . . . . . . . . . . 56 113 10.2. Informative References . . . . . . . . . . . . . . . . . . 56 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 117 1. Overview 119 The transition from IPv4 to IPv6 is a long process and during this 120 period of transition, both the protocols will be enabled over the 121 same network infrastructure. Thus, it is reasonable to assume that a 122 mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only 123 IPv6-only or in dual-stack mode and additionally the network between 124 the mobile access gateway and a local mobility anchor may be an IPv4 125 or an IPv6 network. It is also reasonable to expect the same 126 mobility infrastructure in the Proxy Mobile IPv6 domain to provide 127 mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode 128 and whether the transport network is IPv4 or IPv6 network. The 129 motivation and scope of IPv4 support in Mobile IPv6 is summarized in 130 [RFC-4977] and all those requirements apply to Proxy Mobile IPv6 131 protocol as well. 133 The Proxy Mobile IPv6 protocol [RFC-5213] specifies a mechanism for 134 providing IPv6 home address mobility support to a mobile node in a 135 Proxy Mobile IPv6 domain. The protocol requires IPv6 transport 136 network between the mobility entities. The extensions defined in 137 this document extends IPv4 support to the Proxy Mobile IPv6 protocol 138 [RFC-5213]. 140 The scope of IPv4 support in Proxy Mobile IPv6 includes the support 141 for the following two features: 143 o IPv4 Home Address Mobility Support: A mobile node that has an IPv4 144 stack enabled will be able to obtain an IPv4 address and be able 145 to use that address from any of the access networks in that Proxy 146 Mobile IPv6 domain. The mobile node is not required to be 147 allocated or assigned an IPv6 address to enable IPv4 home address 148 support. 150 o IPv4 Transport Network Support: The mobility entities in the Proxy 151 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 152 signaling messages over an IPv4 transport and furthermore the 153 mobile access gateway may be using an IPv4 private address and 154 with NAT [RFC-3022] translation devices on the path to the local 155 mobility anchor. 157 These two features, the IPv4 Home Address Mobility support and the 158 IPv4 transport support features, are independent of each other and 159 deployments may choose to enable any one or both of these features as 160 required. 162 Figure-1 shows a typical Proxy Mobile IPv6 domain with IPv4 transport 163 network and with IPv4 enabled mobile nodes. The terms used in this 164 illustration are explained in the Terminology section. 166 +----+ +----+ 167 |LMA1| |LMA2| 168 +----+ +----+ 169 IPv4-LMAA -> | | <-- LMAA 170 | | 171 \\ //\\ 172 (NAT) // \\ 173 \\ // \\ 174 +---\\------------- //------\\----+ 175 ( \\ IPv4/IPv6 // \\ ) 176 ( \\ Network // \\ ) 177 +------\\--------//------------\\-+ 178 \\ // \\ 179 \\ // \\ 180 \\ // \\ 181 IPv4-Proxy-CoA --> | | <-- Proxy-CoA 182 +----+ +----+ 183 |MAG1|-----{MN2} |MAG2| 184 +----+ | +----+ 185 (MN-HoA) | | | <-- (MN-HoA) 186 (IPv4-MN-HoA) --> | (IPv4-MN-HoA) | <-- (IPv4-MN-HoA) 187 {MN1} {MN3} 189 Figure 1: IPv4 support for Proxy Mobile IPv6 191 1.1. Stated Assumptions 193 The following are the system and configuration requirements from the 194 mobility entities in the Proxy Mobile IPv6 domain for supporting the 195 extensions defined in this document. 197 o Both the mobility entities, the local mobility anchor and the 198 mobile access gateway are dual stack (IPv4/IPv6) enabled. 199 Irrespective of the type of transport network (IPv4 or IPv6) 200 separating these two entities, the mobility signaling is always 201 based on Proxy Mobile IPv6 [RFC-5213]. 203 o The local mobility anchor and the mobile access gateway MUST be 204 configured with IPv6 globally unique addresses, even when they are 205 in IPv4-only network. These addresses can be of the type Unique 206 Local IPv6 Unicast Address [RFC-4193], IPv6 Global Unicast Address 207 [RFC-3587] or IPv4-mapped IPv6 address [RFC-4291]. When using 208 IPv4 transport, it is not required that there is IPv6 routing 209 enabled between the local mobility anchor and the mobile access 210 gateway. However, they must be able to receive any IPv6 packets 211 sent to the configured IPv6 addresses, after removing the outer 212 IPv4 encapsulation header. 214 o The mobile node can be operating in IPv4-only, IPv6-only or in 215 dual mode. Based on what is enabled for a mobile node, it should 216 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 217 address(es) for its interface and furthermore achieve mobility 218 support for those addresses. 220 o For enabling IPv4 home address mobility support to a mobile node, 221 it is not required that the IPv6 home address mobility support 222 needs to enabled. However, the respective protocol(s) support, 223 such as IPv4 or IPv6 packet forwarding, must be enabled on the 224 access link between the mobile node and the mobile access gateway. 226 o The mobile node can obtain an IPv4 address for its attached 227 interface. Based on the type of link, it may be able to acquire 228 its IPv4 address configuration using standard IPv4 address 229 configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332], 230 IKEv2 [RFC-4306] or static address configuration. 232 o The mobile node's IPv4 home subnet is typically a shared address 233 space. It is not for the exclusive use of any one mobile node. 234 There can be multiple mobile nodes that are assigned IPv4 235 addresses from the same subnet. 237 o The mobile access gateway is the IPv4 default router for the 238 mobile node on its access link. It will be in the forwarding path 239 for the mobile node's data traffic. Additionally, as specified in 240 section 6.9.3 of [RFC-5213], all the mobile access gateways in the 241 Proxy Mobile IPv6 domain MUST use the same link-layer address on 242 any of the access links wherever the mobile node attaches. 244 1.2. Relevance to Dual-Stack Mobile IPv6 246 IPv4 support for Mobile IPv6 is specified in Dual-Stack Mobile IPv6 247 specification [RFC-5555]. This document to most part leverages the 248 approaches, messaging options and processing logic defined in that 249 document for extending IPv4 support to Proxy Mobile IPv6, except with 250 deviation in some aspects for obvious reasons of supporting a 251 network-based mobility model. Following are some of the related 252 considerations. 254 o The messaging option, IPv4 Care-of Address option defined in [RFC- 255 5555] for use in Binding Update and Binding Acknowledgement 256 messages are used by this specification to be carried in Proxy 257 Binding Update and Proxy Binding Acknowledgement messages. 259 o The extensions needed to the conceptual data structures, Binding 260 Cache entry and Binding Update List entry, for storing the state 261 related to the IPv4 support defined in [RFC-5555], will all be 262 needed and relevant for this document. 264 o The NAT traversal logic specified in [RFC-5555] for detecting the 265 on-path NAT devices is valid for this specification as well. 267 o The tunneling considerations specified in [RFC-5555] for 268 supporting IPv4 transport is relevant for this document as well. 270 If a given home agent [RFC-3775] implementation has support for both 271 Dual-stack Mobile IPv6 [RFC-5555] and local mobility anchor function 272 [RFC-5213], when extending IPv4 support as specified in this document 273 the above common functions and the related considerations have to be 274 reused for Proxy Mobile IPv6 signaling flows. 276 2. Conventions & Terminology 278 2.1. Conventions 280 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 281 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 282 document are to be interpreted as described in RFC 2119 [RFC-2119]. 284 2.2. Terminology 286 All the mobility related terms used in this document are to be 287 interpreted as defined in the Mobile IPv6 specification [RFC-3775] 288 and Proxy Mobile IPv6 specification [RFC-5213]. In addition this 289 document introduces the following terms. 291 IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) 293 The IPv4 address that is configured on the egress-interface of the 294 mobile access gateway. When using IPv4 transport, this address 295 will be the registered care-of address in the mobile node's 296 Binding Cache entry and will also be the transport-endpoint of the 297 tunnel between the local mobility anchor and a mobile access 298 gateway. However, if the configured address is a private IPv4 299 address and with a NAT device in the path to the local mobility 300 anchor, the care-of address as seen by the local mobility anchor 301 will be the address allocated by the NAT device for that flow. 303 IPv4 Local Mobility Anchor Address (IPv4-LMAA) 305 The IPv4 address that is configured on the egress-interface of the 306 local mobility anchor. When using IPv4 transport, the mobile 307 access gateway sends the Proxy Binding Update messages to this 308 address and will be the transport-endpoint of the tunnel between 309 the local mobility anchor and the mobile access gateway. 311 Mobile Node's IPv4 Home Address (IPv4-MN-HoA) 313 The IPv4 home address assigned to the mobile node's attached 314 interface. This address is topologically anchored at the local 315 mobility anchor. The mobile node configures this address on its 316 attached interface. If the mobile node connects to the Proxy 317 Mobile IPv6 domain via multiple interfaces each of the interfaces 318 are assigned a unique IPv4 address. All the IPv6 home network 319 prefixes and the IPv4 home address assigned to a given interface 320 of a mobile node will be managed under one mobility session. 322 Selective De-registration 323 A procedure for partial de-registration of all the addresses that 324 belong to one address family, i.e., de-registration of either IPv4 325 home address, or all of the IPv6 home network prefixes. 327 Encapsulation Modes 329 This document uses the following terms when referring to the 330 different encapsulation modes. 332 IPv4-or-IPv6-over-IPv6 334 IPv4 or IPv6 packet carried as a payload of an IPv6 packet 336 IPv4-or-IPv6-over-IPv4 338 IPv4 or IPv6 packet carried as a payload of an IPv4 packet 340 IPv4-or-IPv6-over-IPv4-UDP 342 IPv4 or IPv6 packet carried as a payload in an IPv4 packet with 343 a UDP header 345 IPv4-or-IPv6-over-IPv4-UDP-TLV 347 IPv4 packet carried as a payload in an IPv4 packet with UDP and 348 TLV headers 350 3. IPv4 Home Address Mobility Support 352 The IPv4 home address mobility support essentially enables a mobile 353 node in a Proxy Mobile IPv6 domain to obtain IPv4 home address 354 configuration for its attached interface and be able to retain that 355 address configuration even after changing its point of attachment in 356 that Proxy Mobile IPv6 domain. This section describes the protocol 357 operation and the required extensions to Proxy Mobile IPv6 protocol 358 for extending IPv4 home address mobility support. 360 When an IPv4-enabled or a dual-stack enabled mobile node attaches to 361 the Proxy Mobile IPv6 domain, the mobile access gateway on the access 362 link where the mobile node is attached will identify the mobile node 363 and will initiate the Proxy Mobile IPv6 signaling with the mobile 364 node's local mobility anchor. The mobile access gateway will follow 365 the signaling considerations specified in Section 3.2 for requesting 366 IPv4 home address mobility support. Upon the completion of the 367 signaling, the local mobility anchor and the mobile access gateway 368 will establish the required routing states for allowing the mobile 369 node to use its IPv4 home address from its current point of 370 attachment. 372 The mobile node on the access link using any of the standard IPv4 373 address configuration mechanisms supported on that access link, such 374 as IPCP [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], will be able 375 to obtain an IPv4 home address (IPv4-MN-HoA) for its attached 376 interface. Although the address configuration mechanisms for 377 delivering the address configuration to the mobile node is 378 independent of the Proxy Mobile IPv6 protocol operation, however 379 there needs to be some interactions between these two protocol flows. 380 Section 3.4 identifies these interactions for supporting DHCP based 381 address configuration. 383 The support for IPv4 home address mobility is not dependent on the 384 IPv6 home address mobility support. It is not required that the IPv6 385 home address mobility support needs to be enabled for providing IPv4 386 home address mobility support. A mobile node will be able to obtain 387 IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its 388 attached interface. The mobile node's policy profile will determine 389 if the mobile node is entitled for both the protocol versions or a 390 single protocol version. Based on the policy, only those protocols 391 will be enabled on the access link. Furthermore, if the mobile node 392 after obtaining the address configuration on its interface performs 393 an handoff, either by changing its point of attachment over the same 394 interface or to a different interface, the network will ensure the 395 mobile node will be able to use the same IPv4 address configuration 396 after the handoff. 398 Additionally, If the mobile node connects to the Proxy Mobile IPv6 399 domain, through multiple interfaces and simultaneously through 400 different access networks, each of the connected interfaces will 401 obtain an IPv4 home address from different subnets. In such 402 scenario, there will be multiple Binding Cache entries for the mobile 403 node on the local mobility anchor. All the address (IPv4/IPv6) 404 assigned to a given interface will be managed as part of one mobility 405 session, as specified in Section 5.4 of [RFC-5213]. 407 3.1. Local Mobility Anchor Considerations 409 3.1.1. Extensions to Binding Cache Entry 411 To support this feature, the conceptual Binding Cache entry data 412 structure maintained by the local mobility anchor needs to include 413 the following parameters. 415 o The IPv4 home address assigned to the mobile node's interface and 416 registered by the mobile access gateway. The IPv4 home address 417 entry also includes the corresponding subnet mask. It is to be 418 noted that this parameter is defined in the [RFC-5555] and is 419 presented here for completeness. 421 o The IPv4 default router address assigned to the mobile node. 423 3.1.2. Signaling Considerations 425 3.1.2.1. Processing Proxy Binding Updates 427 The processing rules specified in Section 5.3 of [RFC-5213] are 428 applied for processing the received Proxy Binding Update message. 429 However, if the received Proxy Binding Update message has an IPv4 430 Home Address Request option, the following considerations MUST be 431 applied additionally. 433 o If there is an IPv4 Home Address Request option present in the 434 received Proxy Binding Update message, but if there is no Home 435 Network Prefix option [RFC-5213] present in the request, the local 436 mobility anchor MUST NOT reject the request as specified in 437 Section 5.3.1 of [RFC-5213]. At least one instance of any of 438 these two options, either the IPv4 Home Address Request option or 439 the Home Network Prefix option, MUST be present. If there is not 440 a single instance of any of these two options present in the 441 request, the local mobility anchor MUST reject the request and 442 send a Proxy Binding Acknowledgement message with Status field set 443 to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home 444 network prefix option) [RFC-5213]. 446 o If there is at least one instance of Home Network Prefix option 447 [RFC-5213] present in the received Proxy Binding Update message, 448 but either if it is known from the mobile node's policy profile 449 that the mobile node is not authorized for IPv6 service or if IPv6 450 routing not enabled in the home network, the local mobility anchor 451 MUST reject the request and send a Proxy Binding Acknowledgement 452 message with the Status field set to 453 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX (mobile node not 454 authorized for the requesting IPv6 home network prefix). 456 o If there are more than one instance of the IPv4 Home Address 457 Request option present in the request, then the local mobility 458 anchor MUST reject the request and send a Proxy Binding 459 Acknowledgement message with the Status field set to 460 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 461 home address assignment not supported). 463 o For associating the received Proxy Binding Update message to an 464 existing mobility session, the local mobility anchor MUST perform 465 the Binding Cache entry existence test by applying the following 466 considerations. 468 * If there is at least one instance of the Home Network Prefix 469 option [RFC-5213] with a NON_ZERO prefix value, or, if there is 470 an IPv4 Home Address Request option with the IPv4 address in 471 the option set to ALL_ZERO, considerations from Section 5.4.1 472 of [RFC-5213] MUST be applied. 474 * If there is an IPv4 Home Address Request option present in the 475 request with the IPv4 address value in the option set to a 476 NON_ZERO value, considerations from Section 3.1.2.7 MUST be 477 applied. 479 o If there is no existing Binding Cache entry that can be associated 480 with the request, the local mobility anchor MUST consider this 481 request as an initial binding registration request and 482 considerations from Section 3.1.2.2 MUST be applied. 483 Additionally, if there are one or more Home Network Prefix options 484 [RFC-5213] present in the request, considerations from Section 485 5.3.2 of [RFC-5213] MUST also be applied. 487 o If there exists a Binding Cache entry that can be associated with 488 the request, the local mobility anchor MUST apply considerations 489 from Section 5.3.1 of [RFC-5213], (point 13), to determine if the 490 request is re-registration or a de-registration request. If the 491 request is a re-registration request, considerations from Section 492 3.1.2.3 MUST be applied and if it is a de-registration request, 493 considerations from Section 3.1.2.4 MUST be applied. 495 o If there exists a Binding Cache entry that can be associated with 496 the request and if it is determined that the request is a re- 497 registration request for extending IPv4 home address mobility 498 support to the existing IPv6-only mobility session, considerations 499 from Section 3.1.2.2 MUST be applied with respect to IPv4 support. 501 3.1.2.2. Initial Binding Registration (New Mobility Session) 503 o If there is an IPv4 Home Address Request option present in the 504 Proxy Binding Update message with the IPv4 address value in the 505 option set to ALL_ZERO, the local mobility anchor MUST allocate an 506 IPv4 home address to the mobile node and associate it with the new 507 mobility session created for that mobile node. 509 o If there is an IPv4 Home Address Request option with the IPv4 510 address in the option set to a NON_ZERO value, the local mobility 511 anchor before accepting the request MUST ensure the address is 512 topologically anchored on the local mobility anchor and 513 furthermore the mobile node is authorized to use that address. If 514 the mobile node is not authorized for that specific address, the 515 local mobility anchor MUST reject the request and send a Proxy 516 Binding Acknowledgement message with the Status field set to 517 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized 518 for the requesting IPv4 address). It MUST also include the IPv4 519 Home Address Reply option in the reply with the status field value 520 in the option set to 129 (Administratively prohibited). 522 o If the local mobility anchor is unable to allocate an IPv4 address 523 due to lack of resources, it MUST reject the request and send a 524 Proxy Binding Acknowledgement message with Status field set to 130 525 (Insufficient resources). It MUST also include the IPv4 Home 526 Address Reply option in the reply with the status field value in 527 the option set to 128 (Failure, reason unspecified). 529 o Upon accepting the request, the local mobility anchor MUST create 530 a Binding Cache entry for this mobility session. However, if the 531 request also contains one or more Home Network Prefix options 532 [RFC-5213], there should still be only one Binding Cache entry 533 that should be created for this mobility session. The created 534 Binding Cache entry MUST be used for managing both IPv4 and IPv6 535 home address bindings. The fields in the Binding Cache entry MUST 536 be updated with the accepted values for that session. 538 o The local mobility anchor MUST establish a bi-directional tunnel 539 to the mobile access gateway and with the encapsulation mode set 540 to the negotiated mode for carrying the IPv4 payload traffic. 541 When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6- 542 over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 543 packet). When using IPv4 transport, the encapsulation mode is as 544 specified in Section 4.0. 546 o The local mobility anchor MUST create an IPv4 host route (or a 547 platform specific equivalent function that sets up the forwarding) 548 for tunneling the packets received for the mobile node's home 549 address associated with this mobility session. 551 o The local mobility anchor MUST send the Proxy Binding 552 Acknowledgement message with the Status field set to 0 (Proxy 553 Binding Update Accepted). The message MUST be constructed as 554 specified in Section 3.1.2.6. 556 3.1.2.3. Binding Lifetime Extension (No handoff) 558 All the considerations from Section 5.3.3 of [RFC-5213] MUST be 559 applied. 561 3.1.2.4. Binding Lifetime Extension (After handoff) 563 o If there is no Home Network Prefix option(s) [RFC-5213] present in 564 the request, but if the Binding Cache entry associated with this 565 request has IPv6 home network prefix(es), the local mobility 566 anchor MUST consider this as a request to extend lifetime only for 567 the IPv4 home address and not for the IPv6 home network 568 prefix(es). Hence, the local mobility anchor SHOULD release all 569 the IPv6 home network prefix(es) assigned to that mobile node and 570 for that specific attached interface. Similar considerations 571 apply for the case where there is no IPv4 Home Address Request 572 option present in the request, but if the Binding Cache entry 573 associated with that request has both IPv4 home address and IPv6 574 home network prefix(es). 576 o The local mobility anchor MUST remove the previously created IPv4 577 host route (or the forwarding state) and the dynamically created 578 bi-directional tunnel for carrying the IPv4 payload traffic (if 579 there are no other mobile nodes for which the tunnel is being 580 used). This will remove the routing state towards the mobile 581 access gateway where the mobile node was anchored prior to the 582 handoff. 584 o The local mobility anchor MUST create a bi-directional tunnel to 585 the mobile access gateway that sent the request (if there is no 586 existing bi-directional tunnel) and with the encapsulation mode 587 set to the negotiated mode for carrying the IPv4 payload traffic. 588 An IPv4 host route for tunneling the packets received for the 589 mobile node's IPv4 home address MUST also be added. 591 o The required forwarding state identified in Section 5.3.6 of [RFC- 592 5213] is for IPv6 payload traffic. Those considerations apply for 593 IPv4 payload traffic as well. However, if IPv4 transport is in 594 use, considerations from Section 4.0 MUST be applied. 596 3.1.2.5. Binding De-Registration 598 All the considerations from Section 5.3.5 of [RFC-5213] MUST be 599 applied. Additionally, for removing the IPv4 state as part of the 600 Binding Cache entry deletion, the IPv4 host route and the dynamically 601 created bi-directional tunnel for carrying the IPv4 payload traffic 602 (if there are no other mobile nodes for which the tunnel is being 603 used) MUST be removed. However, if the request is for a selective 604 de-registration (IPv4 home address only, or all the IPv6 home network 605 prefixes), the Binding Cache entry MUST NOT be deleted, only the 606 respective states with respect to those addresses MUST be deleted. 608 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 610 The local mobility anchor when sending the Proxy Binding 611 Acknowledgement message to the mobile access gateway MUST construct 612 the message as specified in Section 5.3.6 of [RFC-5213]. 613 Additionally, the following considerations MUST be applied. 615 o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to 616 include at least one instance of Home Network Prefix option [RFC- 617 5213] in the Proxy Binding Acknowledgement message that it sends 618 to the mobile access gateway. However, if the received Proxy 619 Binding Update message has only the IPv4 Home Address Request 620 option and did not contain the Home Network Prefix option(s), then 621 the local mobility anchor MUST NOT include any Home Network Prefix 622 option(s) in the reply. However, there MUST be at least one 623 instance of either the Home Network Prefix option [RFC-5213] or 624 the IPv4 Home Address Reply option present in the Proxy Binding 625 Acknowledgement message. 627 o The IPv4 Home Address Reply option MUST be present in the Proxy 628 Binding Acknowledgement message. 630 1. If the Status field is set to a value greater than or equal to 631 (128), i.e., if the Proxy Binding Update is rejected, then 632 there MUST be an IPv4 Home Address Reply option corresponding 633 to the IPv4 Home Address Request option present in the request 634 and with the IPv4 address value and the prefix length fields 635 in the option set to the corresponding values in the request. 636 The status field value in the option must be set to the 637 specific error code. 639 2. For all other cases, there MUST be an IPv4 Home Address Reply 640 option for carrying the IPv4 home address assigned for that 641 mobility session and with the value in the option set to the 642 allocated IPv4 address. The prefix length in the option MUST 643 be set to the prefix length of the allocated address. The 644 status field value in the option must be set to 0 (Success). 646 o The IPv4 Default-Router Address option MUST be present, if the 647 Status field value in the Proxy Binding Acknowledgement message is 648 set to 0 (Proxy Binding Update Accepted). Otherwise, the option 649 MUST NOT be present. If the option is present, the default router 650 address in the option MUST be set to the mobile node's default 651 router address. 653 3.1.2.7. Binding Cache Entry Lookup Considerations 655 The Binding Cache entry lookup considerations specified in section 656 5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213] 657 as the key parameter for identifying the Binding Cache entry. 658 However, when there are no Home Network Prefix options with a 659 NON_ZERO value present in the request a single Home Network Prefix 660 option with NON_ZERO value present in the request, but if there an 661 IPv4 Home Address option with a NON_ZERO value present in the 662 request, the following considerations MUST be applied. 664 o The search rules specified in section 5.4.1.1 of [RFC-5213], which 665 primarily uses IPv6 home network prefix set as the search key, are 666 equally valid when using a single IPv4 home address as the key. 667 When applying those considerations, instead of the IPv6 home 668 network prefix(es), the IPv4 home address from the IPv4 Home 669 Address option present in the request MUST be used as the search 670 key. 672 o These rules specified in section 5.4.1.1 of [RFC-5213], assume the 673 presence of one or more IPv6 home network prefixes in the received 674 request and also in the Binding Cache entry. But, when using the 675 IPv4 home address as the search key, these considerations MUST 676 always assume just one single IPv4 home address, both in the 677 request and also in the Binding Cache entry. 679 3.1.3. Routing Considerations for the Local Mobility Anchor 681 Intercepting Packets Sent to the Mobile Node's IPv4 home address: 683 o When the local mobility anchor is serving a mobile node, it MUST 684 advertise a connected route in to the Routing Infrastructure for 685 the mobile node's IPv4 home address or for its home subnet, in 686 order to receive packets that are sent to the mobile node's IPv4 687 home address. This essentially enables IPv4 routers in that 688 network to detect the local mobility anchor as the last-hop router 689 for that subnet. 691 Forwarding Packets to the Mobile Node: 693 o On receiving a packet from a correspondent node with the 694 destination address matching the mobile node's IPv4 home address, 695 the local mobility anchor MUST forward the packet through the bi- 696 directional tunnel setup for that mobile node. 698 o The format of the tunneled packet when payload protection is not 699 enabled: 701 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 702 IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ 703 Upper layer protocols /* Packet Content*/ 705 Figure 2: Tunneled Packets from LMA to MAG 707 Forwarding Packets Sent by the Mobile Node: 709 o All the reverse tunneled packets that the local mobility anchor 710 receives from the mobile access gateway, after removing the tunnel 711 header MUST be routed to the destination specified in the inner 712 IPv4 packet header. These routed packets will have the source 713 address field set to the mobile node's IPv4 home address. 715 3.2. Mobile Access Gateway Considerations 716 3.2.1. Extensions to Binding Update List Entry 718 To support the IPv4 home address mobility feature, the conceptual 719 Binding Update List entry data structure needs to be extended with 720 the following additional fields. 722 o The IPv4 home address assigned to the mobile node's attached 723 interface. This IPv4 home address may have been statically 724 configured in the mobile node's policy profile, or, may have been 725 dynamically allocated by the local mobility anchor. The IPv4 home 726 address entry also includes the corresponding subnet mask. 728 o The IPv4 default router address of the mobile node. This is 729 acquired from the mobile node's local mobility anchor through the 730 received Proxy Binding Acknowledgment message. 732 3.2.2. Extensions to Mobile Node's Policy Profile 734 To support the IPv4 Home Address Mobility Support feature the mobile 735 node's policy profile, specified in Section 6.2 of [RFC-5213] MUST be 736 extended with the following additional fields. 738 Extensions to the mandatory section of the policy profile: 740 o This field identifies all the IP protocol versions for which the 741 home address mobility support needs to be extended to the mobile 742 node. The supported modes are IPv4-only, IPv6-only and dual IPv4/ 743 IPv6. 745 Extensions to the optional section of the policy profile: 747 o The IPv4 home address assigned to the mobile node's attached 748 interface. The specific details on how the network maintains the 749 association between the address and the attached interface is 750 outside the scope of this document. This address field also 751 includes the corresponding subnet mask. 753 3.2.3. Signaling Considerations 755 3.2.3.1. Mobile Node Attachment and Initial Binding Registration 757 After detecting a new mobile node on its access link, the mobile 758 access gateway on the access link MUST determine if IPv4 home address 759 mobility support needs to be enabled for that mobile node. The 760 mobile node's policy profile identifies the supported modes (IPv4- 761 only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the 762 mobile service needs to be enabled. Based on those policy 763 considerations and from other triggers such as from the network, if 764 it is determined that IPv4 home address mobility support needs to be 765 enabled for the mobile node, considerations from section 6.9.1.1 of 766 [RFC-5213] MUST be applied with the following exceptions. 768 o The IPv4 Home Address Request option MUST be present in the Proxy 769 Binding Update message. 771 * If the mobile access gateway learns the mobile node's IPv4 home 772 address either from its policy profile, or from other means, 773 the mobile access gateway MAY ask the local mobility anchor to 774 allocate that specific address by including exactly one 775 instance of the IPv4 Home Address Request option with the IPv4 776 home address and the prefix length fields in the option set to 777 that specific address and its prefix length. 779 * The mobile access gateway MAY also ask the local mobility 780 anchor for dynamic IPv4 home address allocation. It can 781 include exactly one instance of the IPv4 Home Address option 782 with the IPv4 home address and the prefix length fields in the 783 option set to ALL_ZERO value. Furthermore, the (P) flag in the 784 option MUST be set to 0. This essentially serves as a request 785 to the local mobility anchor for the IPv4 home address 786 allocation. 788 o The Proxy Binding Update message MUST be constructed as specified 789 in Section 6.9.1.5 of [RFC-5213]. However, the Home Network 790 Prefix option(s) [RFC-5213] MUST be present in the Proxy Binding 791 Update only if IPv6 home address mobility support also needs to be 792 enabled for the mobile node. Otherwise, the Home Network Prefix 793 option(s) MUST NOT be present. 795 o When using IPv4 transport for carrying the signaling messages, the 796 related considerations from section 4.0 MUST be applied 797 additionally. 799 3.2.3.2. Receiving Proxy Binding Acknowledgement 801 All the considerations from section 6.9.1.2 of [RFC-5213] MUST be 802 applied with the following exceptions. 804 o If the received Proxy Binding Acknowledgement message has the 805 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 806 mobile node is not authorized for IPv4 home address), the mobile 807 access gateway SHOULD NOT send a Proxy Binding Update message 808 including the IPv4 Home Address Request option till an 809 administrative action is taken. 811 o If the received Proxy Binding Acknowledgement message has the 812 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 813 mobile node is not authorized for the requesting IPv4 home 814 address), the mobile access gateway SHOULD NOT request for the 815 same address again, but MAY request the local mobility anchor to 816 do the assignment of address by including exactly one instance of 817 IPv4 Home Address Request option with the IPv4 home address and 818 the prefix length fields in the option set to ALL_ZERO value. 820 o If there is no IPv4 Home Address Reply option present in the 821 received Proxy Binding Acknowledgement message, the mobile access 822 gateway MUST NOT enable IPv4 support for the mobile node and the 823 rest of the considerations from this section can be skipped. 825 o If the received Proxy Binding Acknowledgement message has the 826 Status field value in the IPv4 Home Address Reply option set to a 827 value that indicates that the request was rejected by the local 828 mobility anchor, the mobile access gateway MUST NOT enable 829 forwarding for that specific IPv4 home address. 831 o If the received Proxy Binding Acknowledgement message has the 832 Status field value set to 0 (Proxy Binding Update accepted), the 833 mobile access gateway MUST update a Binding Update List entry for 834 that mobile node. The entry MUST be updated with the assigned 835 IPv4 home address and other accepted registration values. 837 o If the received Proxy Binding Acknowledgement message has the 838 Status field value set to 0 (Proxy Binding Update accepted) and 839 has the IPv4 Home Address Reply option set to a value that 840 indicates that the request was accepted by the local mobility 841 anchor, the mobile access gateway MUST establish a bi-directional 842 tunnel to the local mobility anchor (if there is no existing bi- 843 directional tunnel to that local mobility anchor) and with the 844 encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6 845 packet carried as a payload of an IPv6 packet). Considerations 846 from Section 5.6.1 of [RFC-5213] MUST be applied for managing the 847 dynamically created bi-directional tunnel. However, when using 848 IPv4 transport, the encapsulation mode MUST be set to the 849 negotiated encapsulation mode, as specified in Section 4 of this 850 specification. 852 o The mobile access gateway MUST set up the route for forwarding the 853 IPv4 packets received from the mobile node (using its IPv4 home 854 address) through the bi-directional tunnel set up for that mobile 855 node. 857 o The default router address MUST be obtained from the IPv4 Default- 858 Router Address option present in the received Proxy Binding 859 Acknowledgement message. The mobile access gateway MAY configure 860 this address on its interface and respond to any ARP requests sent 861 by the mobile node for resolving the hardware address of the 862 default router. It MAY also use this address as the source 863 address for any datagrams sent to the mobile node and originated 864 by the mobile access gateway itself. It MAY also use this address 865 in the DHCP Router option [RFC-2132] in the DHCP messages. 867 o If there is an IPv4 DHCP Support Mode option present in the 868 received Proxy Binding Acknowledgement message and if the (S) flag 869 in the option is set to a value of (1), then the mobile access 870 gateway MUST function as a DHCP server for the mobile node. If 871 either the (S) flag in the option is set to a value of (0), or if 872 the option is not present in the request, then the mobile access 873 gateway MUST function as a DHCP Relay for the mobile node. 875 3.2.3.3. Binding Re-Registration and De-Registrations 877 When sending a Proxy Binding Update either for extending the lifetime 878 of a mobility session or for de-registering the mobility session, the 879 respective considerations from [RFC-5213] MUST be applied. 880 Furthermore, the following additional considerations MUST also be 881 applied. 883 o If there is an IPv4 home address assigned to the mobility session, 884 then there MUST be exactly one instance of the IPv4 Home Address 885 Request option present in the Proxy Binding Update message. The 886 IPv4 home address and the prefix length fields in the option MUST 887 be set to that specific address and its corresponding subnet-mask 888 length. 890 o If there was no IPv4 home address requested in the initial Proxy 891 Binding Update message, but if it is determined that the IPv4 home 892 address MUST be requested subsequently, then there MUST be exactly 893 one instance of the IPv4 Home Address Request option present in 894 the Proxy Binding Update message. The IPv4 home address in the 895 option MUST be set to either ALL_ZERO or to a specific address 896 that is being requested. 898 o For performing selective de-registration of IPv4 home address but 899 still retaining the mobility session with all the IPv6 home 900 network prefixes, the Proxy Binding Update message with the 901 lifetime value of (0) MUST NOT include any IPv6 Home Network 902 Prefix options(s) [RFC-5213]. It MUST include exactly one 903 instance of the IPv4 Home Address Request option with the IPv4 904 home address and the prefix length fields in the option set to the 905 IPv4 home address that is being de-registered. Similarly for 906 selective de-registration of all the IPv6 home network prefixes, 907 the Proxy Binding Update message MUST NOT include the IPv4 Home 908 address option, it MUST include a Home Network Prefix option for 909 each of the assigned home network prefixes assigned for that 910 mobility session and with the prefix value in the option set to 911 that respective prefix value. 913 o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present 914 if the same option(s) was not present in the initial Proxy Binding 915 Update message. Otherwise considerations from [RFC-5213] with 916 respect to this option MUST be applied. 918 o If at any point the mobile access gateway fails to extend the 919 binding lifetime with the local mobility anchor for the mobile 920 node's IPv4 address, it MUST remove any forwarding state set up 921 for the mobile node's IPv4 home address. 923 3.2.4. Routing Considerations for the Mobile Access Gateway 925 o On receiving a packet from the bi-directional tunnel established 926 with the mobile node's local mobility anchor, the mobile access 927 gateway MUST remove the outer header before forwarding the packet 928 to the mobile node. 930 o Considerations from Section 6.10.3 of [RFC-5213] MUST be applied 931 with respect the local routing and on the use of 932 EnableMAGLocalRouting flag. 934 o On receiving a packet from a mobile node connected to its access 935 link, the packet MUST be forwarded to the local mobility anchor 936 through the bi-directional tunnel established with the local 937 mobility anchor. The encapsulation considerations specified in 938 section 3.1.3 MUST be applied. However, before forwarding the 939 packet, the mobile access gateway MUST ensure the source address 940 in the received packet is the address allocated for that mobile 941 node and that there is an active binding on the local mobility 942 anchor for that mobile node. 944 o The mobile access gateway MUST use proxy ARP [RFC-925] to reply to 945 ARP Requests that it receives from the mobile node seeking address 946 resolutions for the destinations on the mobile node's home subnet. 947 When receiving an ARP Request, the local mobility anchor MUST 948 examine the target IP address of the Request, and if this IP 949 address matches the mobile node's IPv4 home subnet, it MUST 950 transmit a Proxy ARP Reply. 952 3.3. Mobility Options and Status Codes 954 To support the IPv4 home address mobility feature, this specification 955 defines the following new options and Status Codes. 957 3.3.1. IPv4 Home Address Request Option 959 A new option, IPv4 Home Address Request Option is defined for use 960 with the Proxy Binding Update message sent by the mobile access 961 gateway to the local mobility anchor. This option is used for 962 requesting IPv4 home address assignment for the mobile node. 964 The IPv4 Home Address Request option has an alignment requirement of 965 4n. Its format is as follows: 967 0 1 2 3 968 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 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Type | Length |Prefix-len | Reserved | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | IPv4 home address | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 Figure 3: IPv4 Home Address Request Option 977 Type 979 IANA 981 Length 983 8-bit unsigned integer indicating the length of the option in 984 octets, excluding the type and length fields. This field MUST 985 be set to (6). 987 Prefix-len 989 This 6-bit unsigned integer indicating the prefix length of the 990 IPv4 home address contained in the option. 992 Reserved 993 This 10-bit field is unused for now. The value MUST be 994 initialized to (0) by the sender and MUST be ignored by the 995 receiver. 997 IPv4 home address 999 This four-byte field containing the IPv4 home address that is 1000 being requested. The value of 0.0.0.0 is used for requesting 1001 the local mobility anchor to perform the address allocation. 1003 3.3.2. IPv4 Home Address Reply Option 1005 A new option, IPv4 Home Address Reply Option is defined for using it 1006 in the Proxy Binding Acknowledgment message sent by the local 1007 mobility anchor to the mobile access gateway. This option can be 1008 used for sending the assigned mobile node's IPv4 home address. 1010 The IPv4 Home Address Reply option has an alignment requirement of 1011 4n. Its format is as follows: 1013 0 1 2 3 1014 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 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | Type | Length | Status |Pref-len |Res| 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | IPv4 home address | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 Figure 4: IPv4 Home Address Reply Option 1023 Type 1025 IANA 1027 Length 1029 8-bit unsigned integer indicating the length of the option in 1030 octets, excluding the type and length fields. This field MUST 1031 be set to (6). 1033 Status 1034 Indicates success or failure for the IPv4 home address 1035 assignment. Values from 0 to 127 indicate success. Higher 1036 values indicate failure. The following status values are 1037 currently allocated by this document: 1039 0 Success 1041 128 Failure, reason unspecified 1043 129 Administratively prohibited 1045 130 Incorrect IPv4 home address 1047 131 Invalid IPv4 address 1049 132 Dynamic IPv4 home address assignment not available 1051 Prefix-len 1053 This 6-bit unsigned integer is used for carrying the prefix 1054 length of the mobile node's IPv4 home network corresponding the 1055 IPv4 home address contained in the option. 1057 Reserved (Res) 1059 This 2-bit field is unused for now. The value MUST be 1060 initialized to (0) by the sender and MUST be ignored by the 1061 receiver. 1063 IPv4 home address 1065 This four-byte field is used for carrying the IPv4 home address 1066 assigned to the mobile node. 1068 3.3.3. IPv4 Default-Router Address Option 1070 A new option, IPv4 Default-Router Address Option is defined for using 1071 it in the Proxy Binding Acknowledgment message sent by the local 1072 mobility anchor to the mobile access gateway. This option can be 1073 used for sending the mobile node's IPv4 default router address. 1075 The IPv4 Default-Router Address option has an alignment requirement 1076 of 4n. Its format is as follows: 1078 0 1 2 3 1079 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 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Type | Length | Reserved (R) | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | IPv4 Default-Router Address | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Figure 5: IPv4 Default-Router Address Option 1088 Type 1090 IANA 1092 Length 1094 8-bit unsigned integer indicating the length of the option in 1095 octets, excluding the type and length fields. This field MUST 1096 be set to (6). 1098 Reserved (R) 1100 This 16-bit field is unused for now. The value MUST be 1101 initialized to (0) by the sender and MUST be ignored by the 1102 receiver. 1104 IPv4 Default-Router Address 1106 A four-byte field containing the mobile node's default router 1107 address. 1109 3.3.4. IPv4 DHCP Support Mode 1111 A new option, IPv4 DHCP Support Mode Option is defined for using it 1112 in the Proxy Binding Acknowledgment message sent by the local 1113 mobility anchor to the mobile access gateway. This option can be 1114 used for notifying the mobile access gateway, if it should function 1115 as a DHCP Server or a DHCP Relay for the attached mobile node. 1117 The IPv4 DHCP Support Mode option has no alignment requirement. Its 1118 format is as follows: 1120 0 1 2 3 1121 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 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 | Type | Length | Reserved (R) |S| 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 Figure 6: IPv4 DHCP Support Mode Option 1128 Type 1130 IANA 1132 Length 1134 8-bit unsigned integer indicating the length of the option in 1135 octets, excluding the type and length fields. This field MUST 1136 be set to 2. 1138 Reserved (R) 1140 This 15-bit field is unused for now. The value MUST be 1141 initialized to (0) by the sender and MUST be ignored by the 1142 receiver. 1144 DHCP Support Mode (S) 1146 A 1-bit field that specifies the DHCP support mode. This flag 1147 indicates if the mobile access gateway should function as a 1148 DHCP Server or a DHCP Relay for the attached mobile node. The 1149 flag value of (0) indicates the mobile access gateway should 1150 act as a DHCP Relay and the flag value of (1) indicates it 1151 should act as a DHCP Server. 1153 3.3.5. Status Codes 1155 This document defines the following new Status values for use in the 1156 Proxy Binding Acknowledgement message. These values are to be 1157 allocated from the same numbering space, as defined in Section 6.1.8 1158 of [RFC-3775]. 1160 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 1162 Mobile node not authorized for the requesting IPv4 home address 1164 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA 1165 Mobile node not authorized for the requesting IPv6 home network 1166 prefix(es). 1168 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED 1170 Multiple IPv4 home address assignment not supported 1172 3.4. Supporting DHCP-Based Address Configuration 1174 This section explains how DHCP-based address configuration support 1175 can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It 1176 explains the protocol operation, supported DHCP server deployment 1177 configurations and the protocol interactions between DHCP agents and 1178 mobility entities in each of the supported configurations. 1180 This specification supports the following two DHCP deployment 1181 configurations. 1183 o DHCP relay agent co-located with the mobile access gateway. 1185 o DHCP server co-located in the mobile access gateway. 1187 The following are the configuration requirements: 1189 o The DHCP server or the DHCP relay agent configured on the mobile 1190 access gateway is required to have an IPv4 address for exchanging 1191 the DHCP messages with the mobile node. This address is the 1192 mobile node's default router address provided by the local 1193 mobility anchor. Optionally, all the DHCP servers co-located with 1194 the mobile access gateways in the Proxy Mobile IPv6 domain can be 1195 configured with a fixed IPv4 address. This fixed address can be 1196 potentially an IPv4 private address [RFC-1918] that can be used 1197 for the DHCP protocol communication on any of the access links. 1198 This address will be used as the server identifier in the DHCP 1199 messages. 1201 o A DHCP server identifies a DHCP client from the client identifier, 1202 if present, or from the client hardware address (chaddr), as 1203 specified in [RFC-2131]. It uses this identity for identifying 1204 the client and its interface for which the address is assigned. A 1205 mobile node in a Proxy Mobile IPv6 domain, can attach to the 1206 network through multiple interfaces and can obtain address 1207 configuration for each of its interfaces. Additionally, it may 1208 perform handoffs between its interfaces. Following are the 1209 related considerations with respect to the identification 1210 presented to the DHCP server. 1212 * If the mobile node attaches to the Proxy Mobile IPv6 domain 1213 through multiple interfaces, the DHCP server will uniquely 1214 identify each of those interfaces from the client hardware 1215 address and will perform address assignment. As the mobile 1216 node changes its point of attachment in the network and 1217 performs an handoff to a different mobile access gateway, using 1218 the same interface, the DHCP server will always be able to 1219 identify the binding using the presented client hardware 1220 address. The client hardware address and client identifier 1221 will remain as the primary keys for each binding, just as how 1222 they are unique in a Binding Cache entry. 1224 * However, if the mobile node is capable of performing handoff 1225 between interfaces, as per [RFC-5213], the client hardware 1226 address in such scenarios needs to be an identifier that is not 1227 tied to any of those interfaces. The identifier must be a 1228 stable identifier which remains the same through out the mobile 1229 node's attachment in that Proxy Mobile IPv6 domain. This 1230 identifier must remain fixed for a given binding. This 1231 identifier in some implementations can be the identifier 1232 associated to a virtual interface, that is abstracting the 1233 physical interfaces. 1235 o All the DHCP servers co-located with the mobile access gateways in 1236 a Proxy Mobile IPv6 domain can be configured with the same set of 1237 DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure 1238 the mobile node receives the same configuration values on any of 1239 the access links in that Proxy Mobile IPv6 domain. 1241 3.4.1. DHCP Server co-located with the Mobile Access Gateway 1243 This section explains the operational sequence of home address 1244 assignment operation when the DHCP server is co-located with the 1245 mobile access gateway. 1247 MN MAG(DHCP-S) LMA 1248 |------>| | 1. DHCPDISCOVER 1249 | |------->| 2. Proxy Binding Update 1250 | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) 1251 | |========| 4. Tunnel/Route Setup 1252 |<------| | 5. DHCPOFFER (IPv4 HoA) 1253 |------>| | 6. DHCPREQUEST (IPv4 HoA) 1254 |<------| | 7. DHCPACK 1255 | | | 1256 * It is possible the MAG may have already completed the Proxy Mobile 1257 IPv6 signaling with the LMA for requesting both IPv6 home network 1258 prefix(es) and IPv4 home address assignment prior to step-1. In 1259 such event, the Proxy Mobile IPv6 signaling steps (step-2 to 1260 step-4) above are not relevant. 1261 * It is possible the MAG may have initially completed the Proxy 1262 Mobile IPv6 signaling prior to Step-1, but only for requesting 1263 IPv6 home network prefix(es) and may later request IPv4 home 1264 address assignment after detecting the DHCP triggers from the 1265 mobile node as shown above. 1267 Figure 7: Overview of DHCP Server located at Mobile Access Gateway 1269 Initial IPv4 Home Address Assignment: 1271 o For acquiring the mobile node's IPv4 home address from the local 1272 mobility anchor, the mobile access gateway will initiate Proxy 1273 Mobile IPv6 signaling with the local mobility anchor. 1275 o After the successful completion of the Proxy Mobile IPv6 signaling 1276 and upon acquiring the mobile node's IPv4 home address from the 1277 local mobility anchor, the DHCP server on the mobile access 1278 gateway will send a DHCPOFFER message [RFC-2131] to the mobile 1279 node. The offered address will be the mobile node's IPv4 home 1280 address, assigned by the local mobility anchor. The DHCPOFFER 1281 message will have the server address field (siaddr) and the 1282 default router option set to the mobile node's default router 1283 address. The DHCPOFFER message will be sent to the mobile node 1284 just as specified in [RFC-2131]. 1286 o If the mobile node sends the DHCPREQUEST message, the DHCP server 1287 will send DHCPACK message, as per [RFC-2131]. 1289 IPv4 Home Address Renewal with the DHCP server (No Handoff): 1291 o Any time the mobile node goes into the DHCP RENEWING state [RFC- 1292 2131], it simply unicasts the DHCPREQUEST message including the 1293 assigned IPv4 home address in the 'requested IP address' option. 1294 The DHCPREQUEST is sent to the address specified in 'server 1295 identifier' field of the previously received DHCPOFFER and DHCPACK 1296 messages. 1298 o The DHCP server will send a DHCPACK to the mobile node to 1299 acknowledge the assignment of the committed IPv4 address. 1301 IPv4 Home Address Renewal with the DHCP server (After Handoff): 1303 When the mobile node goes into the DHCP RENEWING state [RFC-2131], it 1304 directly unicasts the DHCPREQUEST message to the DHCP server that 1305 currently provided the DHCP lease. However, if the mobile node 1306 changed its point of attachment and is attached to a new mobile 1307 access gateway, it is required that the mobile node updates the DHCP 1308 server address and uses the address of the DHCP server that is co- 1309 located with the new mobile access gateway. The following approach 1310 can be adopted to ensure the mobile node uses the DHCP server on the 1311 attached link. 1313 MN oMAG(DHCP-S) nMAG(DHCP-S) 1314 | : | 1315 RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) 1316 BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK 1317 | : | 1318 * The use of a fixed DHCP server address on all DHCP servers 1320 Figure 8: Address renewal with the DHCP server 1322 o If a fixed address such as the IPv4 default router address of the 1323 mobile node is used as the DHCP server Id on any of the links in 1324 that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the 1325 mobile node for renewing the address will be received by the new 1326 mobile access gateway on the attached link. The mobile access 1327 gateway after completing the Proxy Mobile IPv6 signaling and upon 1328 acquiring the IPv4 home address of the mobile node will return the 1329 address in the DHCPACK message. However, if the mobile access 1330 gateway is unable to complete the Proxy Mobile IPv6 signaling or 1331 is unable to acquire the same IPv4 address as requested by the 1332 mobile node, it will send a DHCPNACK message [RFC-2131] to the 1333 mobile node, as shown in Figure 8-1). 1335 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway 1337 A DHCP relay agent is co-located with each mobile access gateway. A 1338 DHCP server is located somewhere in the Proxy Mobile IPv6 domain 1339 (e.g., is co-located with the local mobility anchor). Figure 9 shows 1340 the sequence of IPv4 home address assignment using DHCP Relay. 1342 MN MAG(DHCP-R) LMA DHCP-S 1343 | |------->| | 1. Proxy Binding Update * 1344 | |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA) 1345 | |========| | 3. Tunnel/Route Setup* 1346 |------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R 1347 |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R 1348 |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R 1349 |<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R 1350 | | | 1351 * The Proxy Mobile IPv6 signaling (starting at Step-1) and the 1352 DHCP address configuration (starting at Step-4) may start in any 1353 order. However, the DHCPOFFER (Step-5) and the immediate steps 1354 following it will occur in the specified order and only after the 1355 Tunnel/Route Setup (Step-3). 1356 * It is possible the MAG may have initially completed the Proxy 1357 Mobile IPv6 signaling with the LMA only for requesting IPv6 home 1358 network prefix(es) and may later request IPv4 home address 1359 assignment after detecting the DHCP triggers from the mobile node 1360 (after Step-4). 1362 Figure 9: Overview of the DHCP relay located at mobile access gateway 1364 Initial IPv4 Home Address Assignment: 1366 o For acquiring the mobile node's IPv4 home address from the local 1367 mobility anchor, the mobile access gateway will initiate Proxy 1368 Mobile IPv6 signaling with the local mobility anchor. 1370 o After the successful completion of the Proxy Mobile IPv6 signaling 1371 and upon acquiring the mobile node's IPv4 home address from the 1372 local mobility anchor, the mobile access gateway will enable 1373 forwarding for all the DHCP messages between the mobile node and 1374 the DHCP server. 1376 o The DHCP relay agent on the mobile access gateway will add the 1377 DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER 1378 message. The assigned IPv4 home address will be included in the 1379 Agent Remote ID Sub-option of the DHCP relay agent information 1380 option. This sub-option is used as a hint for requesting the DHCP 1381 server to allocate that specific IPv4 address. 1383 o On receiving a DHCPOFFER message from the DHCP server, the mobile 1384 access gateway will ensure the assigned address is currently 1385 assigned by the local mobility anchor to that mobile node. If 1386 this address is different from what is assigned to the mobile 1387 node, then the mobile access gateway will drop the DHCPOFFER 1388 message and an administrative error message will be logged. 1390 o When the DHCP messages are sent over administrative boundaries, 1391 the operators needs to ensure these messages are secured. All the 1392 DHCP messages relayed by the mobile access gateway can be tunneled 1393 to the local mobility anchor if needed. Alternatively, if the 1394 network in the Proxy Mobile IPv6 domain is secure enough, the 1395 mobile access gateway can just relay the DHCP messages to the 1396 server. To achieve this, all the mobile access gateways needs to 1397 have a route towards the DHCP server. 1399 IPv4 Home Address Renewal to the same DHCP server: (No Handoff) 1401 o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it 1402 directly unicasts DHCPREQUEST messages to the DHCP server. The 1403 DHCP relay agent may not detect any changes in the DHCP state. 1404 For example, if the mobile node releases the IPv4 address, the 1405 relay agent would not be aware of it. The following describes 1406 additional mechanisms for the mobile access gateway to detect any 1407 changes in the DHCP state. 1409 * The DHCP relay agent can intercept all IPv4 DHCP packets 1410 destined to the set of addresses used within the Proxy Mobile 1411 IPv6 domain as DHCP addresses. Since the link between a mobile 1412 node and a mobile access gateway is the point-to-point link, 1413 the mobile access gateway will be in path for all the messages. 1415 * The DHCP relay agent can use the DHCP Server Identifier 1416 Override Sub-option [RFC-5107] to be in path for all the DHCP 1417 message flows. The DHCP client uses the DHCP server address 1418 which is overridden by the DHCP relay agent address as a 1419 destination address of DHCPREQUEST. The DHCP Server Identifier 1420 Override Sub-option is recommended only when the fixed DHCP 1421 relay address is configured on all the mobile access gateways. 1422 Otherwise, the DHCP relay agent address is changed when the 1423 mobile node changes the attached mobile access gateway. 1425 o However, if the DHCP server is co-located with the local mobility 1426 anchor, then the DHCP relay agent is not required to intercept the 1427 unicast DHCP messages between the mobile node and the DHCP server. 1428 This is because the local mobility anchor will ensure that the 1429 DHCP state is consistent with the PMIPv6 binding that exists for 1430 the IPv4 address. 1432 o Once the mobile access gateway intercepts the DHCP message from 1433 the mobile node to the DHCP server, it can verify if the mobile 1434 node is negotiating the same IPv4 address that the local mobility 1435 anchor allocated for that mobile node. If the address in the 1436 DHCPREQUEST message does not match with the IPv4 address allocated 1437 for the mobile node, then the mobile access gateway SHOULD 1438 silently drop the DHCP message. 1440 o Any time the mobile access gateway detects that the mobile node 1441 has released its IPv4 address, it can send a Proxy Binding Update 1442 to the local mobility anchor and de-register the IPv4 mobility 1443 session. 1445 3.4.3. Common DHCP Considerations 1447 The following DHCP related considerations are common to both the 1448 supported configuration modes, specified in Section 3.4.1 and Section 1449 3.4.2. 1451 o When a mobile node sends a DHCPDISCOVER message [RFC-2131], the 1452 DHCP server or the relay agent co-located with the mobile access 1453 gateway will trigger the mobile access gateway to complete the 1454 Proxy Mobile IPv6 signaling. This is the required interaction 1455 between these two protocols. The mobile access gateway on 1456 receiving this trigger will check if there is already an assigned 1457 IPv4 home address for the mobile node, from the local mobility 1458 anchor. If there is no assigned IPv4 home address assigned for 1459 that mobile node, the mobile access gateway will complete the 1460 Proxy Mobile IPv6 signaling with the local mobility anchor by 1461 sending a Proxy Binding Update message. 1463 o The mobile node needs to be identified by the MN-Identifier, as 1464 specified in Section 6.6 of [RFC-5213]. This identity should be 1465 associated to the DHCP messages sent by the mobile node. 1467 o The mobile access gateway will drop all the DHCPDISCOVER messages 1468 till it completes the Proxy Mobile IPv6 signaling. If the mobile 1469 access gateway is unable to complete the Proxy Mobile IPv6 1470 signaling, or, if the local mobility anchor does not assign an 1471 IPv4 address for the mobile node, the mobile access gateway MUST 1472 NOT enable IPv4 home address mobility support for the mobile node 1473 on that access link. 1475 o The trigger for initiating Proxy Mobile IPv6 signaling can also be 1476 delivered to the mobile access gateway as part of a context 1477 transfer from the previous mobile access gateway, or delivered 1478 from the other network elements in the radio network, the details 1479 of which are outside the scope of this document. 1481 o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST 1482 include the Interface MTU option [RFC-2132]. The DHCP servers in 1483 the Proxy Mobile IPv6 domain MUST be configured to include the 1484 Interface MTU option. The MTU value SHOULD reflect the tunnel MTU 1485 for the bi-directional tunnel between the mobile access gateway 1486 and the local mobility anchor. 1488 o When the mobile node performs an handoff from one mobile access 1489 gateway to another, the mobile access gateway on the new link will 1490 initiate the Proxy Mobile IPv6 signaling with the local mobility 1491 anchor. On completing the Proxy Mobile IPv6 signaling, the mobile 1492 access gateway has the proper IPv4 address state that the local 1493 mobility anchor has allocated for the mobile node and which can be 1494 used for supporting DHCP based address configuration on that link. 1496 o Any time the mobile node detects a link change event due to 1497 handoff, or due to other reasons such as re-establishment of the 1498 link-layer, the following are the mobile node's considerations 1499 with respect to the DHCP protocol. 1501 * If the mobile node is DNAv4 [RFC-4436] capable and if it 1502 performs DNAv4 procedures after receiving a link change event, 1503 it would always detect the same default router on any of the 1504 access links in that Proxy Mobile IPv6 domain, as the mobile 1505 access gateway configures a fixed link-layer address on all the 1506 access links, as per the base Proxy Mobile IPv6 specification 1507 [RFC-5213]. The mobile node will not perform any DHCP 1508 operation specifically due to this event. 1510 * If the mobile node is not DNAv4 [RFC-4436] capable, after 1511 receiving the link change event it will enter INIT-REBOOT state 1512 [RFC-2131] and will send a DHCPREQUEST message as specified in 1513 Section 3.7 of [RFC-2131]. The mobile node will obtain the 1514 same address configuration as before, as the link change will 1515 not be transparent to the mobile node in that Proxy Mobile IPv6 1516 domain. 1518 o The mobile node may release its IPv4 home address at any time by 1519 sending the DHCPRELEASE message [RFC-2131]. When the mobile 1520 access gateway detects the DHCPRELEASE message sent by the mobile 1521 node, it should consider this as a trigger for de-registering the 1522 mobile node's IPv4 home address. It will apply the considerations 1523 specified in section 3.2.3.3 for performing the de-registration 1524 procedure. However, this operation MUST NOT release any IPv6 home 1525 network prefix(es) assigned to the mobile node. 1527 4. IPv4 Transport Support 1529 The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling 1530 messages exchanged between the local mobility anchor and the mobile 1531 access gateway to be over an IPv6 transport. The extensions defined 1532 in this section allow the exchange of signaling messages over an IPv4 1533 transport when the local mobility anchor and the mobile access 1534 gateway are separated by an IPv4 network and are reachable using only 1535 IPv4 addresses. 1537 IPv4-Proxy-CoA IPv4-LMAA 1538 | + - - - - - - + | 1539 +--+ +---+ / \ +---+ +--+ 1540 |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| 1541 +--+ +---+ \ / +---+ +--+ 1542 + - - - - - - + 1544 Figure 10: IPv4 Transport Network 1546 When the local mobility anchor and the mobile access gateway are 1547 configured and reachable using only IPv4 addresses, the mobile access 1548 gateway serving a mobile node can potentially send the signaling 1549 messages over IPv4 transport and register its IPv4 address as the 1550 care-of address in the mobile node's Binding Cache entry. An IPv4 1551 tunnel (with any of the supported encapsulation modes) can be used 1552 for tunneling the mobile node's data traffic. The following are the 1553 key aspects of this feature. 1555 o The local mobility anchor and the mobile access gateway are both 1556 configured and reachable using an IPv4 address. Additionally, 1557 both entities are also IPv6 enabled and have configured IPv6 1558 addresses on their interfaces, as specified in [RFC-5213], but are 1559 reachable only over an IPv4 transport network. 1561 o The mobile access gateway can be potentially in a private IPv4 1562 network behind a NAT [RFC-3022] device, with a private IPv4 1563 address configured on its egress interface. But, the local 1564 mobility anchor must not be behind a NAT and must be using a 1565 globally routable IPv4 address. However, both the local mobility 1566 anchor and the mobile access gateway can be in the same private 1567 IPv4 routing domain, i.e., when both are configured with private 1568 IPv4 addresses and with no need for NAT translation between them. 1570 o The IPv6 address configuration requirement on the mobile access 1571 gateway does not imply there needs to be IPv6 routing enabled 1572 between the local mobility anchor and the mobile access gateway. 1573 It just requires each of the mobile access gateways and local 1574 mobility anchors in a Proxy Mobile IPv6 domain to be configured 1575 with a globally unique IPv6 address. 1577 o The Proxy Mobile IPv6 signaling messages exchanged between the 1578 local mobility anchor and the mobile access gateway for 1579 negotiating the IPv4 transport will be encapsulated and carried as 1580 IPv4 packets. However, these signaling messages are fundamentally 1581 IPv6 messages using the mobility header and the related semantics 1582 as specified in base Proxy Mobile IPv6 specification [RFC-5213], 1583 but carried as a payload in an IPv4 packet. The supported 1584 encapsulation modes for the signaling messages are either native 1585 IPv4 or IPv4 with UDP header. 1587 o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and 1588 the IPv4 transport support specified in this section is agnostic 1589 to the type of address mobility enabled for that mobile node. 1591 o The IPv4 tunnel established between the local mobility anchor and 1592 the mobile access gateway (with any of the supported encapsulation 1593 modes over IPv4 transport) will be used for carrying the mobile 1594 node's IPv4 and IPv6 traffic. The following are the outer headers 1595 based on the negotiated encapsulation mode. 1597 * IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet). 1598 If payload protection using IPsec is enabled for the tunneled 1599 traffic, the ESP header follows the outer tunnel header. 1601 * IPv4-UDP (Payload packet carried in an IPv4 packet with UDP 1602 header). If payload protection using IPsec is enabled for the 1603 tunneled traffic, the ESP header follows the outer tunnel 1604 header, as specified in [RFC-3948]. 1606 * IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP 1607 and TLV header). Refer to [ID-GREKEY-NEGO]. If payload 1608 protection using IPsec is enabled for the tunneled traffic, the 1609 ESP header follows the outer tunnel header. 1611 4.1. Local Mobility Anchor Considerations 1613 4.1.1. Extensions to Binding Cache Entry 1615 To support this feature, the conceptual Binding Cache entry data 1616 structure maintained by the local mobility anchor [RFC-5213] MUST be 1617 extended with the following additional parameters. It is to be noted 1618 that all of these parameters are specified in [RFC-5555] and also 1619 required here in the present usage context, and are presented here 1620 only for completeness. 1622 o The IPv4 Proxy Care-of Address configured on the mobile access 1623 gateway that sent the Proxy Binding Update message. This address 1624 can be obtained from the IPv4 Care-of Address option [RFC-5555], 1625 present in the received Proxy Binding Update message. However, if 1626 the received Proxy Binding Update message is not sent as an IPv4 1627 packet, i.e., when using IPv6 transport, this field in the Binding 1628 Cache entry MUST be set to ALL_ZERO value. 1630 o The IPv4 NAT translated address of the mobile access gateway. If 1631 the mobile access gateway is not behind a NAT [RFC-3022], this 1632 address will be the same as the address configured on the egress 1633 interface of the mobile access gateway. This address can be 1634 obtained from the IPv4 header of the received Proxy Binding Update 1635 message. However, if the received Proxy Binding Update message is 1636 not sent as an IPv4 packet, this field in the Binding Cache entry 1637 MUST be set to ALL_ZERO value. 1639 o The source UDP port, if the Proxy Binding Update was received in 1640 an IPv4 packet with UDP header. 1642 o The destination UDP port, if the Proxy Binding Update was received 1643 in an IPv4 packet with UDP header. 1645 4.1.2. Extensions to Mobile Node's Policy Profile 1647 To support the IPv4 Transport Support feature the mobile node's 1648 policy profile, specified in Section 6.2 of [RFC-5213] MUST be 1649 extended with the following additional fields. These are mandatory 1650 fields of the policy profile required for supporting this feature. 1652 o The IPv4 address of the local mobility anchor (IPv4-LMAA). 1654 4.1.3. Signaling Considerations 1656 This section provides the rules for processing the Proxy Mobile IPv6 1657 signaling messages received over IPv4 transport. 1659 4.1.3.1. Processing Proxy Binding Updates 1661 o If the received Proxy Binding Update message was sent encapsulated 1662 in an IPv4 or IPv4-UDP packet, the message MUST be authenticated 1663 after removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1664 Considerations from Section 4 of [RFC-5213] MUST be applied for 1665 authenticating and authorizing the request. 1667 o All the considerations from Section 5.3.1 of [RFC-5213] MUST be 1668 applied on the encapsulated Proxy Binding Update message, after 1669 removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1671 o If there is an IPv4 Care-of Address option [RFC-5555] present in 1672 the request and if the outer encapsulation header is IPv4-UDP, 1673 then the NAT presence detection procedure specified in Section 1674 4.1.3.3 MUST be used for detecting the NAT in the path. 1676 o Upon accepting the request, the local mobility anchor MUST set up 1677 an IPv4 bi-directional tunnel to the mobile access gateway. The 1678 tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. 1679 The encapsulation mode MUST be determined by applying the 1680 following considerations: 1682 * If the received Proxy Binding Update message was sent with IPv4 1683 encapsulated header, then the encapsulation mode for the bi- 1684 directional tunnel MUST be set to IPv4. Otherwise, the 1685 following considerations apply. 1687 * If NAT is not detected on the path and if the (F) flag in the 1688 received Proxy Binding Update message is set to the value of 1689 (1), but if the configuration flag, 1690 AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of 1691 (0), then the local mobility anchor MUST reject the request 1692 with the Status field value set to 129 (Administratively 1693 prohibited). 1695 * If the (T) flag [ID-GREKEY-NEGO] in the Proxy Binding Update 1696 message is set to value of (1), then the encapsulation mode 1697 MUST be set to IPv4-or-IPv6-over-IPv4-UDP-TLV. 1699 * If NAT is detected on the path, or if the (F) flag in the 1700 received Proxy Binding Update message is set to the value of 1701 (1), then the encapsulation mode MUST be set to IPv4-or-IPv6- 1702 over-IPv4-UDP. Otherwise the encapsulation mode MUST be set to 1703 IPv4-or-IPv6-over-IPv4. 1705 o The local mobility anchor MUST send the Proxy Binding 1706 Acknowledgement message with the Status field value set to (0) 1707 (Proxy Binding Update Accepted). The message MUST be constructed 1708 as specified in Section 4.1.3.2. 1710 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 1712 The local mobility anchor when sending the Proxy Binding 1713 Acknowledgement message to the mobile access gateway MUST construct 1714 the message as specified in Section 5.3.6 of [RFC-5213]. However, if 1715 the received Proxy Binding Update message was encapsulated in an IPv4 1716 packet or as a payload in the UDP header of an IPv4 packet, the 1717 following additional considerations MUST be applied. 1719 o The Proxy Binding Acknowledgement message MUST be encapsulated in 1720 an IPv4 packet. However, if the received Proxy Binding Update 1721 message was sent encapsulated in an IPv4-UDP packet, then the 1722 Proxy Binding Acknowledgement message MUST be encapsulated in the 1723 UDP header of an IPv4 packet. 1725 o The source address in the IPv4 header of the message MUST be set 1726 to the destination IPv4 address of the received request. 1728 o If the mobile access gateway and the local mobility anchor are 1729 using globally routable IPv4 addresses and if there is a security 1730 association that is based on IPv4 addresses, then the encapsulated 1731 IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement) 1732 MUST be protected using IPsec ESP [RFC-4301] mode. There is no 1733 need to apply IPsec ESP header to the IPv6 packet. In all other 1734 cases, the Proxy Binding Acknowledgement message MUST be protected 1735 using IPsec prior to the IPv4 or IPv4-UDP encapsulation. 1737 o The NAT Detection option [RFC-5555] MUST be present only if there 1738 is an IPv4 Care-of Address option [RFC-5555] present in the 1739 received Proxy Binding Update message and if the NAT detection 1740 procedure resulted in detecting a NAT on path. However, if the 1741 received Proxy Binding Update message was not sent encapsulated in 1742 IPv4 UDP header, then the option MUST NOT be present. 1743 Furthermore, in all other cases, the option MUST NOT be present. 1745 o The IPv4 DHCP Support Mode option MAY be present. If this option 1746 is not present, the mobile access gateway will enable the default 1747 behavior and function as a DHCP Relay for the mobile node. 1749 o Figure 9 shows the format of the Proxy Binding Acknowledgement 1750 message encapsulated in an IPv4 packet and protected using IPv6 1751 security association. The UDP header MUST be present only if the 1752 received Proxy Binding Update message was sent encapsulated in an 1753 IPv4-UDP packet. 1755 IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) 1756 UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/ 1757 /* IPv6 PBA Packet protected with ESP header */ 1759 Figure 11: Proxy Binding Acknowledgment (PBA) Message encapsulated 1760 in IPv4 header 1762 4.1.3.3. NAT Presence Detection 1764 When the transport network between the local mobility anchor and the 1765 mobile access gateway is an IPv4 network and if the received Proxy 1766 Binding Update message was sent encapsulated in IPv4 UDP header, the 1767 local mobility anchor performs the NAT Presence Detection as 1768 specified below. 1770 On receiving the Proxy Binding Update message encapsulated in an IPv4 1771 UDP packet, the local mobility anchor, if it detects a NAT on the 1772 path, will send the Proxy Binding Acknowledgment message with the NAT 1773 Detection Option. The presence of this option in the Proxy Binding 1774 Acknowledgment is an indication to the mobile access gateway about 1775 the presence of NAT in the path. On detecting any NAT in the path, 1776 both the local mobility anchor and the mobile access gateway will set 1777 the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation. 1778 The specific details around the NAT detection and the related logic 1779 are described in DSMIPv6 specification [RFC-5555]. 1781 However, if the value of the configuration variable, 1782 UseIPv4UDPEncapForSignalingMessages, is set to a value of (0), the 1783 mobile access gateway will not use IPv4 UDP encapsulation for Proxy 1784 Binding Update messages and hence the local mobility anchor will not 1785 perform this NAT Presence Detection procedure on these messages that 1786 are not sent in IPv4 UDP packet. 1788 4.1.4. Routing Considerations 1790 4.1.4.1. Forwarding Considerations 1792 Forwarding Packets to the Mobile Node: 1794 o On receiving an IPv4 or an IPv6 packet from a correspondent node 1795 with the destination address matching any of the mobile node's 1796 IPv4 or IPv6 home addresses, the local mobility anchor MUST 1797 forward the packet through the bi-directional tunnel set up for 1798 that mobile node. 1800 o The format of the tunneled packet is shown below. 1802 IPv4 Header (src= IPv4-LMAA, dst= IPv4-Proxy-CoA)] /* Tunnel Header */ 1803 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1804 [TLV Header] /* If TLV negotiated */ 1805 /* IPv6 or IPv4 Payload Packet */ 1806 IPv6 header (src= CN, dst= MN-HOA) 1807 OR 1808 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1810 Figure 12: Tunneled IPv4 Packet from LMA to MAG 1812 o Forwarding Packets Sent by the Mobile Node: 1814 * All the reverse tunneled packets (IPv4 and IPv6) that the local 1815 mobility anchor receives from the mobile access gateway, after 1816 removing the tunnel header (i.e., the outer IPv4 header along 1817 with the UDP and TLV header, if negotiated) MUST be routed to 1818 the destination specified in the inner packet header. These 1819 routed packets will have the source address field set to the 1820 mobile node's home address. 1822 4.1.4.2. ECN Considerations 1824 The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply 1825 for the IPv4 transport tunnels as well. The mobility agents at the 1826 tunnel entry and exit points MUST handle ECN information as specified 1827 in that document. 1829 4.1.4.3. Bi-Directional Tunnel Management 1831 The Tunnel Management considerations specified in section 5.6.1 of 1832 [RFC-5213] apply for the IPv4 transport tunnels as well, with just 1833 one difference that the encapsulation mode is different. 1835 4.2. Mobile Access Gateway Considerations 1837 4.2.1. Extensions to Binding Update List Entry 1839 To support the IPv4 Transport Support feature, the conceptual Binding 1840 Update List entry data structure maintained by the mobile access 1841 gateway [RFC-5213] MUST be extended with the following additional 1842 parameters. 1844 o The IPv4 address of the local mobility anchor. This address can 1845 be obtained from the mobile node's policy profile. 1847 4.2.2. Signaling Considerations 1849 The mobile access gateway when sending a Proxy Binding Update message 1850 to the local mobility anchor MUST construct the message as specified 1851 in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access 1852 gateway is in an IPv4-only access network, the following additional 1853 considerations MUST be applied. 1855 o The Proxy Binding Update message MUST be encapsulated in an IPv4 1856 packet. However, if the value of the configuration variable, 1857 UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy 1858 Binding Update message MUST be encapsulated in an UDP header of an 1859 IPv4 packet. 1861 o The IPv4 Care-of Address option [RFC-5555] MUST be present. The 1862 IPv4 address in the option MUST be set to the mobile access 1863 gateway's IPv4-Proxy-CoA. 1865 o The packet MUST be constructed as specified in Section 4.2.2.1. 1867 o Just as specified in [RFC-5213], when sending a Proxy Binding 1868 message for extending the lifetime of a currently existing 1869 mobility session or for de-registering the mobility session, the 1870 Proxy Binding Update message MUST be constructed just as the 1871 initial request. 1873 Receiving Proxy Binding Acknowledgement 1875 o If the received Proxy Binding Acknowledgement message is 1876 encapsulated in IPv4 or IPv4 UDP packet, the message MUST be 1877 authenticated after removing the outer IPv4 or IPv4-UDP header. 1878 Considerations from Section 4 of [RFC-5213] MUST be applied for 1879 authenticating and authorizing the message. 1881 o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be 1882 applied on the encapsulated Proxy Binding Acknowledgement message, 1883 after removing the outer IPv4 UDP header. 1885 o If the Status field indicates Success, the mobile access gateway 1886 MUST setup a bi-directional tunnel to the local mobility anchor. 1888 o Upon accepting the request, the mobile access gateway MUST set up 1889 an IPv4 bi-directional tunnel to the local mobility anchor. The 1890 tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA. 1891 The encapsulation mode MUST be determined from the below 1892 considerations. 1894 o The encapsulation mode for the bi-directional tunnel MUST be set 1895 to IPv4. However, if the value of the configuration variable, 1896 UseIPv4UDPEncapForSignalingMessages, is set to (1), then the 1897 following considerations MUST be applied. 1899 * If there is a NAT Detection option [RFC-5555] in the received 1900 Proxy Binding Acknowledgement message and if the value of the 1901 configuration flag, UseIPv4UDPEncapForSignalingMessages, is set 1902 to value of (1), then the encapsulation mode for the tunnel 1903 MUST be set to IPv4-UDP. Otherwise the encapsulation mode MUST 1904 be set to IPv4. 1906 * If the (T) flag in the Proxy Binding Acknowledgement message is 1907 set to value of (1), then the encapsulation mode MUST be set to 1908 IPv4-UDP-TLV. 1910 4.2.2.1. Constructing the Proxy Binding Update Message 1912 o The source address in the IPv4 header MUST be set to IPv4-Proxy- 1913 CoA of the mobile access gateway and the destination address MUST 1914 be set to the local mobility anchor's IPv4-LMAA. 1916 o The IPv4 Care-of Address option [RFC-5555] MUST be present. The 1917 address MUST be set to the mobile access gateway's IPv4-Proxy-CoA. 1919 o If the configuration variable ForceIPv4UDPEncapsulationSupport is 1920 set to value of (1), then the (F) flag in the Proxy Binding Update 1921 message MUST be set to value of (1). 1923 o The Proxy Binding Update message MUST be protected using IPsec ESP 1924 [RFC-4301], as specified in [RFC-5213]. The protection MUST be 1925 applied on the IPv6 packet of the Proxy Binding Update message, 1926 prior to the IPv4 encapsulation. 1928 o The format of the Proxy Binding Update message encapsulated in an 1929 IPv4 or IPv4-UDP packet with no IPsec protection: 1931 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1932 UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/ 1933 /* IPv6 PBU Packet protected with ESP header */ 1935 Figure 13: Proxy Binding Update (PBU) message encapsulated in IPv4 1936 UDP header 1938 4.2.2.2. Forwarding Considerations 1940 Forwarding Packets Sent by the Mobile Node: 1942 o On receiving an IPv4 or an IPv6 packet from the mobile node to any 1943 destination, the mobile access gateway MUST tunnel the packet to 1944 the local mobility anchor. The format of the tunneled packet is 1945 shown below. However, considerations from Section 6.10.3 of [RFC- 1946 5213] MUST be applied with respect the local routing and on the 1947 use of EnableMAGLocalRouting flag. 1949 IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */ 1950 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1951 [TLV Header] /* If TLV negotiated */ 1952 /* IPv6 or IPv4 Payload Packet */ 1953 IPv6 header (src= CN, dst= MN-HOA) 1954 OR 1955 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1957 Figure 14: Tunneled IPv4 Packet from LMA to MAG 1959 o Forwarding Packets received from the bi-directional tunnel: 1961 o On receiving a packet from the bi-directional tunnel established 1962 with the mobile node's local mobility anchor, the mobile access 1963 gateway MUST remove the outer header before forwarding the packet 1964 to the mobile node. 1966 4.3. IPsec Considerations 1968 The following section describes how IPsec is used for protecting the 1969 signaling messages between the local mobility anchor and mobile 1970 access gateway when using IPv4 transport. 1972 The following are the SPD example entries to protect PBU and PBA on 1973 the local mobility anchor and mobile access gateway. 1975 MAG SPD-S: 1976 - IF local_address = Proxy-CoA_1 & 1977 remote_address = LMAA_1 & proto = MH & 1978 local_mh_type = PBU & remote_mh_type = PBAck 1979 Then use SA ESP transport mode 1981 LMA SPD-S: 1982 - IF local_address = LMAA_1 & 1983 remote_address = Proxy-CoA_1 & proto = MH & 1984 local_mh_type = PBAck & remote_mh_type = PBU 1985 Then use SA ESP transport mode 1987 Figure 15 and Figure 16 show how PBU and PBA are sent and processed 1988 at either the local mobility anchor or the mobile access gateway. 1989 IPsec ESP is always applied before PBU and PBA are encapsulated in 1990 the outer IPv4 header. 1992 | PBU on wire : PBU internal processing 1993 \|/ \:/ 1995 MAG 1996 | IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1997 | UDP header (sport=Z, dport=DSMIPv6) 1998 | IPv6 header (src=Proxy-CoA, dst=LMAA) 1999 | ESP header in transport mode 2000 | Mobility header 2001 | PBU (p flag) 2002 | Home Network Prefix option 2003 | IPv4 Home Address Request option 2004 | IPv4 Care-of Address option 2005 \|/ 2006 LMA (received at DSMIPv6 port) 2007 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2008 : ESP header in transport mode 2009 : Mobility header 2010 : PBU (p flag) 2011 : Home Network Prefix option 2012 : IPv4 Home Address Request option 2013 : IPv4 Care-of Address option 2014 : 2015 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2016 : be passed with the packet to ensure correct processing. 2017 \:/ 2018 LMA's IPsec module 2019 : 2020 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2021 : Mobility header 2022 : PBU (p flag) 2023 : Home Network Prefix option 2024 : IPv4 Home Address Request option 2025 : IPv4 Care-of Address option 2026 : 2027 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2028 : be passed with the packet to ensure correct processing. 2029 \:/ 2030 LMA's PMIP module 2032 Figure 15: Proxy Binding Update 2034 | PBA on wire : PBA internal processing 2035 \|/ \:/ 2037 LMA 2038 | IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) 2039 | UDP header (sport=DSMIPv6, dport=Z) 2040 | IPv6 header (src=LMAA, dst=Proxy-CoA) 2041 | ESP header in transport mode 2042 | Mobility header 2043 | PBA (p flag) 2044 | Home Network Prefix option 2045 | IPv4 Home Address Reply option 2046 | IPv4 Care-of Address option 2047 \|/ 2048 MAG (received at DSMIPv6 listening port) 2049 : IPv6 header (src=LMAA, dst=Proxy-CoA) 2050 : ESP header in transport mode 2051 : Mobility header 2052 : PBA (p flag) 2053 : Home Network Prefix option 2054 : IPv4 Home Address Reply option 2055 : IPv4 Care-of Address option 2056 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2057 : be passed with the packet to ensure correct processing. 2058 \:/ 2059 MAG's IPsec module 2060 : 2061 : IPv6 header (src=LMAA, dst=Proxy-CoA) 2062 : Mobility header 2063 : PBA (p flag) 2064 : Home Network Prefix option 2065 : IPv4 Home Address Reply option 2066 : IPv4 Care-of Address option 2067 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2068 : be passed with the packet to ensure correct processing. 2069 \:/ 2070 MAG's PMIP module 2072 Figure 16: Proxy Binding Acknowledgement 2074 5. Protocol Configuration Variables 2076 5.1. Local Mobility Anchor - Configuration Variables 2078 The local mobility anchor MUST allow the following variables to be 2079 configured by the system management. The configured values for these 2080 protocol variables MUST survive server reboots and service restarts. 2082 AcceptForcedIPv4UDPEncapsulationRequest 2084 This flag indicates whether or not the local mobility anchor 2085 should accept IPv4 UDP encapsulation request for the mobile node's 2086 data traffic, even if there is no NAT detected in the path. 2088 The default value for this flag is set to (0), indicating that the 2089 local mobility anchor MUST NOT accept IPv4 UDP encapsulation 2090 request when NAT is not detected in the path. 2092 When the value for this flag is set to (1), the local mobility 2093 anchor MUST accept IPv4 UDP encapsulation request even when NAT is 2094 not detected in the path. 2096 5.2. Mobile Access Gateway - Configuration Variables 2098 The mobile access gateway MUST allow the following variables to be 2099 configured by the system management. The configured values for these 2100 protocol variables MUST survive server reboots and service restarts. 2102 UseIPv4UDPEncapForSignalingMessages 2104 This flag indicates whether or not the mobile access gateway 2105 should use IPv4-UDP encapsulation mode for the signaling messages. 2107 The default value for this flag is set to (0), indicating that the 2108 mobile access gateway MUST NOT use IPv4-UDP encapsulation mode, 2109 but MUST use native IPv4 encapsulation mode for sending the Proxy 2110 Mobile IPv6 signaling messages. 2112 When the value for this flag is set to (1), the mobile access 2113 gateway MUST use IPv4-UDP encapsulation mode for sending the Proxy 2114 Mobile IPv6 signaling messages. 2116 ForceIPv4UDPEncapsulationSupport 2117 This flag indicates whether or not the mobile access gateway 2118 should request the mobile node's local mobility anchor for forcing 2119 IPv4 UDP encapsulation support for the mobile node's data traffic, 2120 even when NAT is not detected in the path. 2122 The default value for this flag is set to (0), indicating that the 2123 mobile access gateway MUST NOT request the mobile node's local 2124 mobility anchor for forcing IPv4 UDP encapsulation support even 2125 when NAT is not detected in path. 2127 When the value for this flag is set to (1), the mobile access 2128 gateway MUST force the mobile node's local mobility anchor for 2129 IPv4 UDP encapsulation support. 2131 This flag is applicable only when the flag 2132 UseIPv4UDPEncapForSignalingMessages is set to a value of (1). 2134 6. IANA Considerations 2136 This document defines two new Mobility Header options, IPv4 Home 2137 Address Request option, IPv4 Home Address Reply option, IPv4 Default 2138 Router Address option and IPv4 DHCP Support Mode option. These 2139 options are described in Sections 3.3.1, 3.3.2, 3.3.3 and 3.3.4 2140 respectively. The Type value for these options needs to be assigned 2141 from the same number space as allocated for the other mobility 2142 options, as defined in [RFC-3775]. 2144 The IPv4 Home Address Reply option, described in Section 3.3.2 of 2145 this document, introduces a new number space, IPv4 Home Address Reply 2146 Status Codes. This document currently reserves the following values. 2147 Approval of any new status code values are to be made through IANA 2148 Expert Review. 2150 o 0 Success 2152 o 128 Failure, reason unspecified 2154 o 129 Administratively prohibited 2156 o 130 Incorrect IPv4 home address 2158 o 131 Invalid IPv4 address 2160 o 132 Dynamic IPv4 home address assignment not available 2162 The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this 2163 document, introduces a new number space, IPv4 DHCP Support Mode 2164 Flags. This document reserves the value 0x1 for the (S) flag. 2165 Approval of this flag values are to be made through IANA Expert 2166 Review. 2168 This document also defines new status values, used in Proxy Binding 2169 Acknowledgement message, as described in Section 3.3.5. These values 2170 are to be assigned from the same number space as allocated for other 2171 Status codes [RFC-3775]. Each of these allocated values have to be 2172 greater than 128. 2174 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 2176 Mobile node not authorized for the requesting IPv4 home address 2178 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA 2180 Mobile node not authorized for the requesting IPv6 home network 2181 prefix(es). 2183 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED 2185 Multiple IPv4 home address assignment not supported 2187 7. Security Considerations 2189 All the security considerations from the base Proxy Mobile IPv6 [RFC- 2190 5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6 [RFC-5555] 2191 apply when using the extensions defined in this document. 2192 Additionally, the following security considerations need to be 2193 applied. 2195 This document defines new mobility options for supporting the IPv4 2196 Home Address assignment and IPv4 Transport Support features. These 2197 options are to be carried in Proxy Binding Update and Proxy Binding 2198 Acknowledgement messages. The required security mechanisms specified 2199 in the base Proxy Mobile IPv6 protocol for protecting these signaling 2200 messages are sufficient when carrying these mobility options. 2202 This specification describes the use of IPv4 transport for exchanging 2203 the signaling messages between the local mobility anchor and the 2204 mobile access gateway. These signaling messages are fundamentally 2205 IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4 2206 packets. The encapsulated inner IPv6 message is still protected 2207 using IPsec, using the established security association and this 2208 offers the same level of security as when the messages are routed 2209 natively as IPv6 packets. The use of outer IPv4 header does not 2210 introduce any new security vulnerabilities. 2212 8. Contributors 2214 This document reflects discussions and contributions from several 2215 people (in alphabetical order): 2217 Kuntal Chowdhury 2219 kchowdhury@starentnetworks.com 2221 Vijay Devarapalli 2223 vijay.devarapalli@azairenet.com 2225 Sangjin Jeong 2227 sjjeong@etri.re.kr 2229 Basavaraj Patil 2231 basavaraj.patil@nsn.com 2233 Myungki Shin 2235 myungki.shin@gmail.com 2237 9. Acknowledgments 2239 The IPv4 support for Proxy Mobile IPv6 was initially covered in the 2240 internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like 2241 to thank all the authors of the document and acknowledge that initial 2242 work. 2244 Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles 2245 Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen, 2246 Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen, 2247 Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe 2248 Wu and Zu Qiang for their helpful review of this document. 2250 Also, we would like to thank Spencer Dawkins, Tim Polk and Menachem 2251 Dodge and Adrian Farrel for their reviews of this document as part of 2252 the IESG review process. 2254 10. References 2255 10.1. Normative References 2257 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 2258 Requirement Levels", BCP 14, RFC 2119, March 1997. 2260 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2261 2131, March 1997. 2263 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 2264 IPv6", RFC 3775, June 2004. 2266 [RFC-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast 2267 Addresses", RFC-4193, October 2005. 2269 [RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing 2270 Architecture", RFC-4291, February 2006. 2272 [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, 2273 November 2007. 2275 [RFC-5555] Soliman, H. et al, "Mobile IPv6 support for dual stack 2276 Hosts and Routers (DSMIPv6)", RFC-5555, June 2009. 2278 10.2. Informative References 2280 [RFC-925] Postel, J., "Multi-LAN Address Resolution", RFC 925, 2281 October 1984. 2283 [RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol 2284 (IPCP)", RFC 1332, May 1992. 2286 [RFC-1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2287 and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 2288 1918, February 1996. 2290 [RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor 2291 Extensions", RFC 2132, March 1997. 2293 [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2294 Address Translator (Traditional NAT)", RFC 3022, January 2001. 2296 [RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January 2297 2001. 2299 [RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 2300 Unicast Address Format", RFC 3587, August 2003. 2302 [RFC-3948] Huttunen, A. et al, "UDP Encapsulation of IPsec ESP 2303 Packets", RFC 3948, January 2005. 2305 [RFC-4301] Kent, S. and K. Seo, "Security Architecture for the 2306 Internet Protocol", RFC 4301, December 2005. 2308 [RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 2309 4306, December 2005. 2311 [RFC-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network 2312 Attachment in IPv4", RFC 4436, March 2006. 2314 [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack 2315 Mobility", RFC 4977, August 2007. 2317 [RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp, 2318 "DHCP Server Identifier Override Suboption", RFC 5107, February 2008. 2320 [ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K., 2321 "GRE Key Option for Proxy Mobile IPv6", 2322 draft-ietf-netlmm-grekey-option-09.txt, May 2009. 2324 Authors' Addresses 2326 Ryuji Wakikawa 2327 TOYOTA InfoTechnology Center, U.S.A., Inc. 2328 465 Bernardo Avenue 2329 Mountain View, CA 94043 2330 USA 2332 Email: ryuji@us.toyota-itc.com 2334 Sri Gundavelli 2335 Cisco 2336 170 West Tasman Drive 2337 San Jose, CA 95134 2338 USA 2340 Email: sgundave@cisco.com