idnits 2.17.1 draft-ietf-netlmm-pmip6-ipv4-support-17.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 (September 12, 2009) is 5340 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: March 16, 2010 Cisco 6 September 12, 2009 8 IPv4 Support for Proxy Mobile IPv6 9 draft-ietf-netlmm-pmip6-ipv4-support-17.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 March 16, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies extensions to Proxy Mobile IPv6 protocol for 48 adding IPv4 protocol support. The scope of IPv4 protocol support is 49 two-fold: 1) enable IPv4 home address mobility support to the mobile 50 node. 2) allowing the mobility entities in the Proxy Mobile IPv6 51 domain to exchange signaling messages over an IPv4 transport network. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 5 57 1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 6 59 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8 60 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 61 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 63 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 64 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 65 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11 66 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11 67 3.1.3. Routing Considerations for the Local Mobility 68 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 17 69 3.1.4. ECN & Payload Fragmentation Considerations . . . . . . 18 70 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 18 71 3.2.1. Extensions to Binding Update List Entry . . . . . . . 18 72 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18 73 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19 74 3.2.4. Routing Considerations for the Mobile Access 75 Gateway . . . . . . . . . . . . . . . . . . . . . . . 23 76 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23 77 3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23 78 3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 25 79 3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 26 80 3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 27 81 3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 28 82 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 29 83 3.4.1. DHCP Server co-located with the Mobile Access 84 Gateway . . . . . . . . . . . . . . . . . . . . . . . 30 85 3.4.2. DHCP Relay Agent co-located with the Mobile Access 86 Gateway . . . . . . . . . . . . . . . . . . . . . . . 33 87 3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 35 89 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 38 90 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 39 91 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 39 92 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 40 93 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 40 94 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 43 95 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 44 96 4.2.1. Extensions to Binding Update List Entry . . . . . . . 44 97 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 45 98 4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 47 99 4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 47 100 4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 51 102 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 54 103 5.1. Local Mobility Anchor - Configuration Variables . . . . . 54 104 5.2. Mobile Access Gateway - Configuration Variables . . . . . 54 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 58 110 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 59 112 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 114 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 115 10.1. Normative References . . . . . . . . . . . . . . . . . . . 60 116 10.2. Informative References . . . . . . . . . . . . . . . . . . 60 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 120 1. Overview 122 The transition from IPv4 to IPv6 is a long process and during this 123 period of transition, both the protocols will be enabled over the 124 same network infrastructure. Thus, it is reasonable to assume that a 125 mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only 126 IPv6-only or in dual-stack mode and additionally the network between 127 the mobile access gateway and a local mobility anchor may be an IPv4 128 or an IPv6 network. It is also reasonable to expect the same 129 mobility infrastructure in the Proxy Mobile IPv6 domain to provide 130 mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode 131 and whether the transport network is IPv4 or IPv6 network. The 132 motivation and scope of IPv4 support in Mobile IPv6 is summarized in 133 [RFC-4977] and all those requirements apply to Proxy Mobile IPv6 134 protocol as well. 136 The Proxy Mobile IPv6 protocol [RFC-5213] specifies a mechanism for 137 providing IPv6 home address mobility support to a mobile node in a 138 Proxy Mobile IPv6 domain. The protocol requires IPv6 transport 139 network between the mobility entities. The extensions defined in 140 this document extends IPv4 support to the Proxy Mobile IPv6 protocol 141 [RFC-5213]. 143 The scope of IPv4 support in Proxy Mobile IPv6 includes the support 144 for the following two features: 146 o IPv4 Home Address Mobility Support: A mobile node that has an IPv4 147 stack enabled will be able to obtain an IPv4 address and be able 148 to use that address from any of the access networks in that Proxy 149 Mobile IPv6 domain. The mobile node is not required to be 150 allocated or assigned an IPv6 address to enable IPv4 home address 151 support. 153 o IPv4 Transport Network Support: The mobility entities in the Proxy 154 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 155 signaling messages over an IPv4 transport and furthermore the 156 mobile access gateway may be using an IPv4 private address and 157 with NAT [RFC-3022] translation devices on the path to the local 158 mobility anchor. 160 These two features, the IPv4 Home Address Mobility support and the 161 IPv4 transport support features, are independent of each other and 162 deployments may choose to enable any one or both of these features as 163 required. 165 Figure-1 shows a typical Proxy Mobile IPv6 domain with IPv4 transport 166 network and with IPv4 enabled mobile nodes. The terms used in this 167 illustration are explained in the Terminology section. 169 +----+ +----+ 170 |LMA1| |LMA2| 171 +----+ +----+ 172 IPv4-LMAA -> | IPv4-LMAA-> | <-- LMAA 173 | | 174 \\ //\\ 175 (NAT) // \\ 176 \\ // \\ 177 +---\\------------- //------\\----+ 178 ( \\ IPv4/IPv6 // \\ ) 179 ( \\ Network // \\ ) 180 +------\\--------//------------\\-+ 181 \\ // \\ 182 \\ // \\ 183 \\ // \\ 184 IPv4-Proxy-CoA --> | | <-- Proxy-CoA 185 +----+ +----+ 186 |MAG1|-----{MN2} |MAG2| 187 +----+ | +----+ 188 (MN-HoA) | | | <-- (MN-HoA) 189 (IPv4-MN-HoA) --> | (IPv4-MN-HoA) | <-- (IPv4-MN-HoA) 190 {MN1} {MN3} 192 Figure 1: IPv4 support for Proxy Mobile IPv6 194 1.1. Stated Assumptions 196 The following are the system and configuration requirements from the 197 mobility entities in the Proxy Mobile IPv6 domain for supporting the 198 extensions defined in this document. 200 o Both the mobility entities, the local mobility anchor and the 201 mobile access gateway are dual stack (IPv4/IPv6) enabled. 202 Irrespective of the type of transport network (IPv4 or IPv6) 203 separating these two entities, the mobility signaling is always 204 based on Proxy Mobile IPv6 [RFC-5213]. 206 o The local mobility anchor and the mobile access gateway MUST be 207 configured with IPv6 globally unique addresses. Or, they must be 208 at least unique within that Proxy Mobile IPv6 domain. These 209 addresses can be of the type, Unique Local IPv6 Unicast Address 210 [RFC-4193], IPv6 Global Unicast Address [RFC-3587], or IPv4-mapped 211 IPv6 address [RFC-4291]. When using IPv4 transport, it is not 212 required that there is IPv6 routing enabled between the local 213 mobility anchor and the mobile access gateway. However, they must 214 be able to receive any IPv6 packets sent to the configured IPv6 215 addresses, after removing the outer IPv4 encapsulation header. 217 o The mobile node can be operating in IPv4-only, IPv6-only or in 218 dual mode. Based on what is enabled for a mobile node, it should 219 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 220 address(es) for its interface and furthermore achieve mobility 221 support for those addresses. 223 o For enabling IPv4 home address mobility support to a mobile node, 224 it is not required that the IPv6 home address mobility support 225 needs to enabled. However, the respective protocol(s) support, 226 such as IPv4 or IPv6 packet forwarding, must be enabled on the 227 access link between the mobile node and the mobile access gateway. 229 o The mobile node can obtain an IPv4 address for its attached 230 interface. Based on the type of link, it may be able to acquire 231 its IPv4 address configuration using standard IPv4 address 232 configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332], 233 IKEv2 [RFC-4306] or static address configuration. However, the 234 details on how IPCP or IKEv2 can be used for address delivery is 235 outside the scope of this document. 237 o The mobile node's IPv4 home subnet is typically a shared address 238 space. It is not for the exclusive use of any one mobile node. 239 There can be multiple mobile nodes that are assigned IPv4 240 addresses from the same subnet. 242 o The mobile access gateway is the IPv4 default router for the 243 mobile node on its access link. It will be in the forwarding path 244 for the mobile node's data traffic. Additionally, as specified in 245 section 6.9.3 of [RFC-5213], all the mobile access gateways in the 246 Proxy Mobile IPv6 domain MUST use the same link-layer address on 247 any of the access links wherever the mobile node attaches. 249 1.2. Relevance to Dual-Stack Mobile IPv6 251 IPv4 support for Mobile IPv6 is specified in Dual-Stack Mobile IPv6 252 specification [RFC-5555]. This document to most part leverages the 253 approaches, messaging options and processing logic defined in that 254 document for extending IPv4 support to Proxy Mobile IPv6, except with 255 deviation in some aspects for obvious reasons of supporting a 256 network-based mobility model. Following are some of the related 257 considerations. 259 o The messaging option, IPv4 Care-of Address option defined in [RFC- 260 5555] for use in Binding Update and Binding Acknowledgement 261 messages are used by this specification to be carried in Proxy 262 Binding Update and Proxy Binding Acknowledgement messages. 264 o The extensions needed to the conceptual data structures, Binding 265 Cache entry and Binding Update List entry, for storing the state 266 related to the IPv4 support defined in [RFC-5555], will all be 267 needed and relevant for this document. 269 o The NAT traversal logic specified in [RFC-5555] for detecting the 270 on-path NAT devices is valid for this specification as well. 272 o The tunneling considerations specified in [RFC-5555] for 273 supporting IPv4 transport is relevant for this document as well. 275 If a given home agent [RFC-3775] implementation has support for both 276 Dual-stack Mobile IPv6 [RFC-5555] and local mobility anchor function 277 [RFC-5213], when extending IPv4 support as specified in this document 278 the above common functions and the related considerations have to be 279 reused for Proxy Mobile IPv6 signaling flows. 281 2. Conventions & Terminology 283 2.1. Conventions 285 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 286 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 287 document are to be interpreted as described in RFC 2119 [RFC-2119]. 289 2.2. Terminology 291 All the mobility related terms used in this document are to be 292 interpreted as defined in the Mobile IPv6 specification [RFC-3775] 293 and Proxy Mobile IPv6 specification [RFC-5213]. In addition this 294 document introduces the following terms. 296 IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) 298 The IPv4 address that is configured on the egress-interface of the 299 mobile access gateway. When using IPv4 transport, this address 300 will be the registered care-of address in the mobile node's 301 Binding Cache entry and will also be the transport-endpoint of the 302 tunnel between the local mobility anchor and a mobile access 303 gateway. However, if the configured address is a private IPv4 304 address and with a NAT device in the path to the local mobility 305 anchor, the care-of address as seen by the local mobility anchor 306 will be the address allocated by the NAT device for that flow. 308 IPv4 Local Mobility Anchor Address (IPv4-LMAA) 310 The IPv4 address that is configured on the egress-interface of the 311 local mobility anchor. When using IPv4 transport, the mobile 312 access gateway sends the Proxy Binding Update messages to this 313 address and will be the transport-endpoint of the tunnel between 314 the local mobility anchor and the mobile access gateway. 316 Mobile Node's IPv4 Home Address (IPv4-MN-HoA) 318 The IPv4 home address assigned to the mobile node's attached 319 interface. This address is topologically anchored at the mobile 320 node's local mobility anchor. The mobile node configures this 321 address on its attached interface. If the mobile node connects to 322 the Proxy Mobile IPv6 domain via multiple interfaces each of the 323 interfaces are assigned a unique IPv4 address. All the IPv6 home 324 network prefixes and the IPv4 home address assigned to a given 325 interface of a mobile node will be managed under one mobility 326 session. 328 Selective De-registration 330 A procedure for partial de-registration of all the addresses that 331 belong to one address family, i.e., de-registration of either IPv4 332 home address, or all of the IPv6 home network prefixes. 334 Encapsulation Modes 336 This document uses the following terms when referring to the 337 different encapsulation modes. 339 IPv4-or-IPv6-over-IPv6 341 IPv4 or IPv6 packet carried as a payload of an IPv6 packet 343 IPv4-or-IPv6-over-IPv4 345 IPv4 or IPv6 packet carried as a payload of an IPv4 packet 347 IPv4-or-IPv6-over-IPv4-UDP 349 IPv4 or IPv6 packet carried as a payload in an IPv4 packet with 350 a UDP header 352 IPv4-or-IPv6-over-IPv4-UDP-TLV 354 IPv4 packet carried as a payload in an IPv4 packet with UDP and 355 TLV headers 357 3. IPv4 Home Address Mobility Support 359 The IPv4 home address mobility support essentially enables a mobile 360 node in a Proxy Mobile IPv6 domain to obtain IPv4 home address 361 configuration for its attached interfaces and be able to retain that 362 address configuration even after performing an handoff anywhere 363 within that Proxy Mobile IPv6 domain. This section describes the 364 protocol operation and the required extensions to Proxy Mobile IPv6 365 protocol for extending IPv4 home address mobility support. 367 When an IPv4-enabled or a dual-stack enabled mobile node attaches to 368 the Proxy Mobile IPv6 domain, the mobile access gateway on the access 369 link where the mobile node is attached will identify the mobile node 370 and will initiate the Proxy Mobile IPv6 signaling with the mobile 371 node's local mobility anchor. The mobile access gateway will follow 372 the signaling considerations specified in Section 3.2 for requesting 373 IPv4 home address mobility support. Upon the completion of the 374 signaling, the local mobility anchor and the mobile access gateway 375 will establish the required routing states for allowing the mobile 376 node to use its IPv4 home address from its current point of 377 attachment. 379 The mobile node on the access link using any of the standard IPv4 380 address configuration mechanisms supported on that access link, such 381 as IPCP [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], will be able 382 to obtain an IPv4 home address (IPv4-MN-HoA) for its attached 383 interface. Although the address configuration mechanisms for 384 delivering the address configuration to the mobile node is 385 independent of the Proxy Mobile IPv6 protocol operation, however 386 there needs to be some interactions between these two protocol flows. 387 Section 3.4 identifies these interactions for supporting DHCP based 388 address configuration. 390 The support for IPv4 home address mobility is not dependent on the 391 IPv6 home address mobility support. It is not required that the IPv6 392 home address mobility support needs to be enabled for providing IPv4 393 home address mobility support. A mobile node will be able to obtain 394 IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its 395 attached interface. The mobile node's policy profile will determine 396 if the mobile node is entitled for both the protocol versions or a 397 single protocol version. Based on the policy, only those protocols 398 will be enabled on the access link. Furthermore, if the mobile node 399 after obtaining the address configuration on its interface performs 400 an handoff, either by changing its point of attachment over the same 401 interface or to a different interface, the network will ensure the 402 mobile node will be able to use the same IPv4 address configuration 403 after the handoff. 405 Additionally, If the mobile node connects to the Proxy Mobile IPv6 406 domain, through multiple interfaces and simultaneously through 407 different access networks, each of the connected interfaces will 408 obtain an IPv4 home address from different subnets. In such 409 scenario, there will be multiple Binding Cache entries for the mobile 410 node on the local mobility anchor. All the address (IPv4/IPv6) 411 assigned to a given interface will be managed as part of one mobility 412 session, as specified in Section 5.4 of [RFC-5213]. 414 3.1. Local Mobility Anchor Considerations 416 3.1.1. Extensions to Binding Cache Entry 418 To support this feature, the conceptual Binding Cache entry data 419 structure maintained by the local mobility anchor needs to include 420 the following parameters. 422 o The IPv4 home address assigned to the mobile node's interface and 423 registered by the mobile access gateway. The IPv4 home address 424 entry also includes the corresponding subnet mask. It is to be 425 noted that this parameter is defined in the [RFC-5555] and is 426 presented here for completeness. 428 o The IPv4 default router address assigned to the mobile node. 430 3.1.2. Signaling Considerations 432 3.1.2.1. Processing Proxy Binding Updates 434 The processing rules specified in Section 5.3 of [RFC-5213] are 435 applied for processing the received Proxy Binding Update message. 436 However, if the received Proxy Binding Update message has an IPv4 437 Home Address Request option, the following considerations MUST be 438 applied additionally. 440 o If there is an IPv4 Home Address Request option present in the 441 received Proxy Binding Update message, but if there is no Home 442 Network Prefix option [RFC-5213] present in the request, the local 443 mobility anchor MUST NOT reject the request as specified in 444 Section 5.3.1 of [RFC-5213]. At least one instance of any of 445 these two options, either the IPv4 Home Address Request option or 446 the Home Network Prefix option, MUST be present. If there is not 447 a single instance of any of these two options present in the 448 request, the local mobility anchor MUST reject the request and 449 send a Proxy Binding Acknowledgement message with Status field set 450 to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home 451 network prefix option) [RFC-5213]. 453 o If there is at least one instance of Home Network Prefix option 454 [RFC-5213] present in the received Proxy Binding Update message, 455 but either if it is known from the mobile node's policy profile 456 that the mobile node is not authorized for IPv6 service or if IPv6 457 routing not enabled in the home network, the local mobility anchor 458 MUST reject the request and send a Proxy Binding Acknowledgement 459 message with the Status field set to 460 NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not 461 authorized for IPv6 mobility service). 463 o If there is an IPv4 Home Address Request option present in the 464 received Proxy Binding Update message, but either if it is known 465 from the mobile node's policy profile that the mobile node is not 466 authorized for IPv4 service or if IPv4 routing not enabled in the 467 home network, the local mobility anchor MUST reject the request 468 and send a Proxy Binding Acknowledgement message with the Status 469 field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (mobile node 470 not authorized for IPv4 mobility service). 472 o If there are more than one instance of the IPv4 Home Address 473 Request option present in the request, then the local mobility 474 anchor MUST reject the request and send a Proxy Binding 475 Acknowledgement message with the Status field set to 476 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 477 home address assignment not supported). 479 o For associating the received Proxy Binding Update message to an 480 existing mobility session, the local mobility anchor MUST perform 481 the Binding Cache entry existence test by applying the following 482 considerations. 484 * If there is at least one instance of the Home Network Prefix 485 option [RFC-5213] with a NON_ZERO prefix value, or, if there is 486 an IPv4 Home Address Request option with the IPv4 address in 487 the option set to ALL_ZERO, considerations from Section 5.4.1 488 of [RFC-5213] MUST be applied. 490 * If there is an IPv4 Home Address Request option present in the 491 request with the IPv4 address value in the option set to a 492 NON_ZERO value, considerations from Section 3.1.2.7 MUST be 493 applied. 495 o If there is no existing Binding Cache entry that can be associated 496 with the request, the local mobility anchor MUST consider this 497 request as an initial binding registration request and 498 considerations from Section 3.1.2.2 MUST be applied. 500 Additionally, if there are one or more Home Network Prefix options 501 [RFC-5213] present in the request, considerations from Section 502 5.3.2 of [RFC-5213] MUST also be applied. 504 o If there exists a Binding Cache entry that can be associated with 505 the request, the local mobility anchor MUST apply considerations 506 from Section 5.3.1 of [RFC-5213], (point 13), to determine if the 507 request is re-registration or a de-registration request. If the 508 request is a re-registration request, considerations from Section 509 3.1.2.3 MUST be applied and if it is a de-registration request, 510 considerations from Section 3.1.2.5 MUST be applied. 512 o If there exists a Binding Cache entry that can be associated with 513 the request and if it is determined that the request is a re- 514 registration request for extending IPv4 home address mobility 515 support to the existing IPv6-only mobility session, considerations 516 from Section 3.1.2.2 MUST be applied with respect to IPv4 support. 518 3.1.2.2. Initial Binding Registration (New Mobility Session) 520 o If there is an IPv4 Home Address Request option present in the 521 Proxy Binding Update message with the IPv4 address value in the 522 option set to ALL_ZERO, the local mobility anchor MUST allocate an 523 IPv4 home address to the mobile node and associate it with the new 524 mobility session created for that mobile node. 526 o If there is an IPv4 Home Address Request option with the IPv4 527 address in the option set to a NON_ZERO value, the local mobility 528 anchor before accepting the request MUST ensure the address is 529 topologically anchored on the local mobility anchor and 530 furthermore the mobile node is authorized to use that address. If 531 the mobile node is not authorized for that specific address, the 532 local mobility anchor MUST reject the request and send a Proxy 533 Binding Acknowledgement message with the Status field set to 534 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized 535 for the requesting IPv4 address). It MUST also include the IPv4 536 Home Address Reply option in the reply with the status field value 537 in the option set to 129 (Administratively prohibited). 539 o If the local mobility anchor is unable to allocate an IPv4 address 540 due to lack of resources, it MUST reject the request and send a 541 Proxy Binding Acknowledgement message with Status field set to 130 542 (Insufficient resources). It MUST also include the IPv4 Home 543 Address Reply option in the reply with the status field value in 544 the option set to 128 (Failure, reason unspecified). 546 o Upon accepting the request, the local mobility anchor MUST create 547 a Binding Cache entry for this mobility session. However, if the 548 request also contains one or more Home Network Prefix options 549 [RFC-5213], there should still be only one Binding Cache entry 550 that should be created for this mobility session. The created 551 Binding Cache entry MUST be used for managing both IPv4 and IPv6 552 home address bindings. The fields in the Binding Cache entry MUST 553 be updated with the accepted values for that session. 555 o The local mobility anchor MUST establish a bi-directional tunnel 556 to the mobile access gateway and with the encapsulation mode set 557 to the negotiated mode for carrying the IPv4 payload traffic. 558 When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6- 559 over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 560 packet). When using IPv4 transport, the encapsulation mode is as 561 specified in Section 4.0. 563 o The local mobility anchor MUST create an IPv4 host route (or a 564 platform specific equivalent function that sets up the forwarding) 565 for tunneling the packets received for the mobile node's home 566 address associated with this mobility session. 568 o The local mobility anchor MUST send the Proxy Binding 569 Acknowledgement message with the Status field set to 0 (Proxy 570 Binding Update Accepted). The message MUST be constructed as 571 specified in Section 3.1.2.6. 573 3.1.2.3. Binding Lifetime Extension (No handoff) 575 All the considerations from Section 5.3.3 of [RFC-5213] MUST be 576 applied. 578 3.1.2.4. Binding Lifetime Extension (After handoff) 580 o If there is no Home Network Prefix option(s) [RFC-5213] present in 581 the request, but if the Binding Cache entry associated with this 582 request has IPv6 home network prefix(es), the local mobility 583 anchor MUST consider this as a request to extend lifetime only for 584 the IPv4 home address and not for the IPv6 home network 585 prefix(es). Hence, the local mobility anchor SHOULD release all 586 the IPv6 home network prefix(es) assigned to that mobile node and 587 for that specific attached interface. Similar considerations 588 apply for the case where there is no IPv4 Home Address Request 589 option present in the request, but if the Binding Cache entry 590 associated with that request has both IPv4 home address and IPv6 591 home network prefix(es). 593 o The local mobility anchor MUST remove the previously created IPv4 594 host route (or the forwarding state) and the dynamically created 595 bi-directional tunnel for carrying the IPv4 payload traffic (if 596 there are no other mobile nodes for which the tunnel is being 597 used). This will remove the routing state towards the mobile 598 access gateway where the mobile node was anchored prior to the 599 handoff. 601 o The local mobility anchor MUST create a bi-directional tunnel to 602 the mobile access gateway that sent the request (if there is no 603 existing bi-directional tunnel) and with the encapsulation mode 604 set to the negotiated mode for carrying the IPv4 payload traffic. 605 An IPv4 host route for tunneling the packets received for the 606 mobile node's IPv4 home address MUST also be added. 608 o The required forwarding state identified in Section 5.3.6 of [RFC- 609 5213] is for IPv6 payload traffic. Those considerations apply for 610 IPv4 payload traffic as well. However, if IPv4 transport is in 611 use, considerations from Section 4.0 MUST be applied. 613 3.1.2.5. Binding De-Registration 615 All the considerations from Section 5.3.5 of [RFC-5213] MUST be 616 applied. Additionally, for removing the IPv4 state as part of the 617 Binding Cache entry deletion, the IPv4 host route and the dynamically 618 created bi-directional tunnel for carrying the IPv4 payload traffic 619 (if there are no other mobile nodes for which the tunnel is being 620 used) MUST be removed. However, if the request is for a selective 621 de-registration (IPv4 home address only, or all the IPv6 home network 622 prefixes), the Binding Cache entry MUST NOT be deleted, only the 623 respective states with respect to those addresses MUST be deleted. 625 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 627 The local mobility anchor when sending the Proxy Binding 628 Acknowledgement message to the mobile access gateway MUST construct 629 the message as specified in Section 5.3.6 of [RFC-5213]. 630 Additionally, the following considerations MUST be applied. 632 o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to 633 include at least one instance of Home Network Prefix option [RFC- 634 5213] in the Proxy Binding Acknowledgement message that it sends 635 to the mobile access gateway. However, if the received Proxy 636 Binding Update message has only the IPv4 Home Address Request 637 option and did not contain the Home Network Prefix option(s), then 638 the local mobility anchor MUST NOT include any Home Network Prefix 639 option(s) in the reply. However, there MUST be at least one 640 instance of either the Home Network Prefix option [RFC-5213] or 641 the IPv4 Home Address Reply option present in the Proxy Binding 642 Acknowledgement message. 644 o The IPv4 Home Address Reply option MUST be present in the Proxy 645 Binding Acknowledgement message. 647 1. If the Status field is set to a value greater than or equal to 648 (128), i.e., if the Proxy Binding Update is rejected, then 649 there MUST be an IPv4 Home Address Reply option corresponding 650 to the IPv4 Home Address Request option present in the request 651 and with the IPv4 address value and the prefix length fields 652 in the option set to the corresponding values in the request. 653 The status field value in the option must be set to the 654 specific error code. 656 2. For all other cases, there MUST be an IPv4 Home Address Reply 657 option for carrying the IPv4 home address assigned for that 658 mobility session and with the value in the option set to the 659 allocated IPv4 address. The prefix length in the option MUST 660 be set to the prefix length of the allocated address. The 661 status field value in the option must be set to 0 (Success). 663 o The IPv4 Default-Router Address option MUST be present, if the 664 Status field value in the Proxy Binding Acknowledgement message is 665 set to 0 (Proxy Binding Update Accepted). Otherwise, the option 666 MUST NOT be present. If the option is present, the default router 667 address in the option MUST be set to the mobile node's default 668 router address. 670 3.1.2.7. Binding Cache Entry Lookup Considerations 672 The Binding Cache entry lookup considerations specified in section 673 5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213] 674 as the key parameter for identifying the Binding Cache entry. 675 However, when there is not a single Home Network Prefix option with a 676 NON_ZERO value present in the request, but if there is an IPv4 Home 677 Address option with a NON_ZERO value present in the request, then the 678 following considerations MUST be applied. 680 o The search rules specified in section 5.4.1.1 of [RFC-5213], which 681 primarily uses IPv6 home network prefix set as the search key, are 682 equally valid when using a single IPv4 home address as the key. 683 When applying those considerations, instead of the IPv6 home 684 network prefix(es), the IPv4 home address from the IPv4 Home 685 Address option present in the request MUST be used as the search 686 key. 688 o These rules specified in section 5.4.1.1 of [RFC-5213], assume the 689 presence of one or more IPv6 home network prefixes in the received 690 request and also in the Binding Cache entry. But, when using the 691 IPv4 home address as the search key, these considerations MUST 692 always assume just one single IPv4 home address, both in the 693 request and also in the Binding Cache entry. 695 3.1.3. Routing Considerations for the Local Mobility Anchor 697 Intercepting Packets Sent to the Mobile Node's IPv4 home address: 699 o When the local mobility anchor is serving a mobile node, it MUST 700 advertise a connected route in to the Routing Infrastructure for 701 the mobile node's IPv4 home address or for its home subnet, in 702 order to receive packets that are sent to the mobile node's IPv4 703 home address. This essentially enables IPv4 routers in that 704 network to detect the local mobility anchor as the last-hop router 705 for that subnet. 707 Forwarding Packets to the Mobile Node: 709 o On receiving a packet from a correspondent node with the 710 destination address matching the mobile node's IPv4 home address, 711 the local mobility anchor MUST forward the packet through the bi- 712 directional tunnel setup for that mobile node. 714 o The format of the tunneled packet when payload protection is not 715 enabled: 717 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 718 IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ 719 Upper layer protocols /* Packet Content*/ 721 Figure 2: Tunneled Packets from LMA to MAG 723 Forwarding Packets Sent by the Mobile Node: 725 o All the reverse tunneled packets that the local mobility anchor 726 receives from the mobile access gateway, after removing the tunnel 727 header MUST be routed to the destination specified in the inner 728 IPv4 packet header. These routed packets will have the source 729 address field set to the mobile node's IPv4 home address. 731 3.1.4. ECN & Payload Fragmentation Considerations 733 The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply 734 for the IPv4 payload packets as well. The mobility agents at the 735 tunnel entry and exit points MUST handle ECN information as specified 736 in that document. 738 The mobility agents at the tunnel entry and exit points MUST apply 739 the IP packet fragmentation considerations as specified in section 7 740 of [RFC-2473] and additionally they MUST apply the considerations 741 related to tunnel error processing and reporting as specified in 742 section 8 of [RFC-2473]. 744 3.2. Mobile Access Gateway Considerations 746 3.2.1. Extensions to Binding Update List Entry 748 To support the IPv4 home address mobility feature, the conceptual 749 Binding Update List entry data structure needs to be extended with 750 the following additional fields. 752 o The IPv4 home address assigned to the mobile node's attached 753 interface. This IPv4 home address may have been statically 754 configured in the mobile node's policy profile, or, may have been 755 dynamically allocated by the local mobility anchor. The IPv4 home 756 address entry also includes the corresponding subnet mask. 758 o The IPv4 default router address of the mobile node. This is 759 acquired from the mobile node's local mobility anchor through the 760 received Proxy Binding Acknowledgment message. 762 3.2.2. Extensions to Mobile Node's Policy Profile 764 To support the IPv4 Home Address Mobility Support feature the mobile 765 node's policy profile, specified in Section 6.2 of [RFC-5213] MUST be 766 extended with the following additional fields. 768 Extensions to the mandatory section of the policy profile: 770 o This field identifies all the IP protocol versions for which the 771 home address mobility support needs to be extended to the mobile 772 node. The supported modes are IPv4-only, IPv6-only and dual IPv4/ 773 IPv6. 775 Extensions to the optional section of the policy profile: 777 o The IPv4 home address assigned to the mobile node's attached 778 interface. The specific details on how the network maintains the 779 association between the address and the attached interface is 780 outside the scope of this document. This address field also 781 includes the corresponding subnet mask. 783 3.2.3. Signaling Considerations 785 3.2.3.1. Mobile Node Attachment and Initial Binding Registration 787 After detecting a new mobile node on its access link, the mobile 788 access gateway on the access link MUST determine if IPv4 home address 789 mobility support needs to be enabled for that mobile node. The 790 mobile node's policy profile identifies the supported modes (IPv4- 791 only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the 792 mobile service needs to be enabled. Based on those policy 793 considerations and from other triggers such as from the network, if 794 it is determined that IPv4 home address mobility support needs to be 795 enabled for the mobile node, considerations from section 6.9.1.1 of 796 [RFC-5213] MUST be applied with the following exceptions. 798 o The IPv4 Home Address Request option MUST be present in the Proxy 799 Binding Update message. 801 * If the mobile access gateway learns the mobile node's IPv4 home 802 address either from its policy profile, or from other means, 803 the mobile access gateway MAY ask the local mobility anchor to 804 allocate that specific address by including exactly one 805 instance of the IPv4 Home Address Request option with the IPv4 806 home address and the prefix length fields in the option set to 807 that specific address and its prefix length. 809 * The mobile access gateway MAY also ask the local mobility 810 anchor for dynamic IPv4 home address allocation. It can 811 include exactly one instance of the IPv4 Home Address option 812 with the IPv4 home address and the prefix length fields in the 813 option set to ALL_ZERO value. Furthermore, the (P) flag in the 814 option MUST be set to 0. This essentially serves as a request 815 to the local mobility anchor for the IPv4 home address 816 allocation. 818 o The Proxy Binding Update message MUST be constructed as specified 819 in Section 6.9.1.5 of [RFC-5213]. However, the Home Network 820 Prefix option(s) [RFC-5213] MUST be present in the Proxy Binding 821 Update only if IPv6 home address mobility support also needs to be 822 enabled for the mobile node. Otherwise, the Home Network Prefix 823 option(s) MUST NOT be present. 825 o When using IPv4 transport for carrying the signaling messages, the 826 related considerations from section 4.0 MUST be applied 827 additionally. 829 3.2.3.2. Receiving Proxy Binding Acknowledgement 831 All the considerations from section 6.9.1.2 of [RFC-5213] MUST be 832 applied with the following exceptions. 834 o If the received Proxy Binding Acknowledgement message has the 835 Status field value set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE 836 (The mobile node is not authorized for IPv4 mobility service), the 837 mobile access gateway SHOULD NOT send a Proxy Binding Update 838 message including a IPv4 Home Address Request option till an 839 administrative action is taken. 841 o If the received Proxy Binding Acknowledgement message has the 842 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 843 mobile node is not authorized for the requesting IPv4 home 844 address), the mobile access gateway SHOULD NOT request for the 845 same IPv4 address again, but MAY request the local mobility anchor 846 to perform the address assignment by including exactly one 847 instance of IPv4 Home Address Request option with the IPv4 home 848 address and the prefix length fields in the option set to ALL_ZERO 849 value. 851 o If the received Proxy Binding Acknowledgement message has the 852 Status field value set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE 853 (The mobile node is not authorized for IPv6 mobility service), the 854 mobile access gateway SHOULD NOT send a Proxy Binding Update 855 message including any Home Network Prefix option(s) till an 856 administrative action is taken. 858 o If there is no IPv4 Home Address Reply option present in the 859 received Proxy Binding Acknowledgement message, the mobile access 860 gateway MUST NOT enable IPv4 support for the mobile node and the 861 rest of the considerations from this section can be skipped. 863 o If the received Proxy Binding Acknowledgement message has the 864 Status field value in the IPv4 Home Address Reply option set to a 865 value that indicates that the request was rejected by the local 866 mobility anchor, the mobile access gateway MUST NOT enable 867 forwarding for that specific IPv4 home address. 869 o If the received Proxy Binding Acknowledgement message has the 870 Status field value set to 0 (Proxy Binding Update accepted), the 871 mobile access gateway MUST update a Binding Update List entry for 872 that mobile node. The entry MUST be updated with the assigned 873 IPv4 home address and other accepted registration values. 875 o If the received Proxy Binding Acknowledgement message has the 876 Status field value set to 0 (Proxy Binding Update accepted) and 877 has the IPv4 Home Address Reply option set to a value that 878 indicates that the request was accepted by the local mobility 879 anchor, the mobile access gateway MUST establish a bi-directional 880 tunnel to the local mobility anchor (if there is no existing bi- 881 directional tunnel to that local mobility anchor) and with the 882 encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6 883 packet carried as a payload of an IPv6 packet). Considerations 884 from Section 5.6.1 of [RFC-5213] MUST be applied for managing the 885 dynamically created bi-directional tunnel. However, when using 886 IPv4 transport, the encapsulation mode MUST be set to the 887 negotiated encapsulation mode, as specified in Section 4 of this 888 specification. 890 o The mobile access gateway MUST set up the route for forwarding the 891 IPv4 packets received from the mobile node (using its IPv4 home 892 address) through the bi-directional tunnel set up for that mobile 893 node. 895 o The default router address MUST be obtained from the IPv4 Default- 896 Router Address option present in the received Proxy Binding 897 Acknowledgement message. The mobile access gateway SHOULD 898 configure this address on its interface and respond to any ARP 899 requests sent by the mobile node for resolving the hardware 900 address of the default router. However, since the link between 901 the mobile access gateway and the mobile node is a point-to-point 902 link, implementations will be able receive any packets sent to the 903 default router address without having to explicitly configure the 904 default router address on its interface. The mobile access 905 gateway MAY also use the default router address as the source 906 address for any datagrams sent to the mobile node and originated 907 by the mobile access gateway itself. It MUST also use this 908 address in the DHCP Router option [RFC-2132] in the DHCP messages. 910 o If there is an IPv4 DHCP Support Mode option present in the 911 received Proxy Binding Acknowledgement message and if the (S) flag 912 in the option is set to a value of (1), then the mobile access 913 gateway MUST function as a DHCP server for the mobile node. If 914 either the (S) flag in the option is set to a value of (0), or if 915 the option is not present in the request, then the mobile access 916 gateway MUST function as a DHCP Relay for the mobile node. 918 3.2.3.3. Binding Re-Registration and De-Registrations 920 When sending a Proxy Binding Update either for extending the lifetime 921 of a mobility session or for de-registering the mobility session, the 922 respective considerations from [RFC-5213] MUST be applied. 923 Furthermore, the following additional considerations MUST also be 924 applied. 926 o If there is an IPv4 home address assigned to the mobility session, 927 then there MUST be exactly one instance of the IPv4 Home Address 928 Request option present in the Proxy Binding Update message. The 929 IPv4 home address and the prefix length fields in the option MUST 930 be set to that specific address and its corresponding subnet-mask 931 length. 933 o If there was no IPv4 home address requested in the initial Proxy 934 Binding Update message, but if it is determined that the IPv4 home 935 address MUST be requested subsequently, then there MUST be exactly 936 one instance of the IPv4 Home Address Request option present in 937 the Proxy Binding Update message. The IPv4 home address in the 938 option MUST be set to either ALL_ZERO or to a specific address 939 that is being requested. 941 o For performing selective de-registration of IPv4 home address but 942 still retaining the mobility session with all the IPv6 home 943 network prefixes, the Proxy Binding Update message with the 944 lifetime value of (0) MUST NOT include any IPv6 Home Network 945 Prefix options(s) [RFC-5213]. It MUST include exactly one 946 instance of the IPv4 Home Address Request option with the IPv4 947 home address and the prefix length fields in the option set to the 948 IPv4 home address that is being de-registered. Similarly for 949 selective de-registration of all the IPv6 home network prefixes, 950 the Proxy Binding Update message MUST NOT include the IPv4 Home 951 address option, it MUST include a Home Network Prefix option for 952 each of the assigned home network prefixes assigned for that 953 mobility session and with the prefix value in the option set to 954 that respective prefix value. 956 o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present 957 if the same option(s) was not present in the initial Proxy Binding 958 Update message. Otherwise considerations from [RFC-5213] with 959 respect to this option MUST be applied. 961 o If at any point the mobile access gateway fails to extend the 962 binding lifetime with the local mobility anchor for the mobile 963 node's IPv4 address, it MUST remove any forwarding state set up 964 for the mobile node's IPv4 home address. 966 3.2.4. Routing Considerations for the Mobile Access Gateway 968 o On receiving a packet from the bi-directional tunnel established 969 with the mobile node's local mobility anchor, the mobile access 970 gateway MUST remove the outer header before forwarding the packet 971 to the mobile node. 973 o On receiving a packet from a mobile node connected to its access 974 link, the packet MUST be forwarded to the local mobility anchor 975 through the bi-directional tunnel established with the local 976 mobility anchor. However, when EnableMAGLocalRouting flag is set, 977 considerations from Section 6.10.3 of [RFC-5213] MUST be applied 978 with respect to local routing. 980 o When forwarding the packet through the bi-directional tunnel, the 981 encapsulation considerations specified in section 3.1.3 MUST be 982 applied. However, before forwarding the packet, the mobile access 983 gateway MUST ensure the source address in the received packet is 984 the address allocated for that mobile node and that there is an 985 active binding on the local mobility anchor for that mobile node. 987 o The mobile access gateway SHOULD use Proxy ARP [RFC-925] to reply 988 to ARP Requests that it receives from the mobile node seeking 989 address resolutions for the destinations on the mobile node's home 990 subnet. When receiving an ARP Request, the local mobility anchor 991 SHOULD examine the target IP address of the Request, and if this 992 IP address matches the mobile node's IPv4 home subnet, it SHOULD 993 transmit a Proxy ARP Reply. However, on certain types of links, 994 the mobile node does not use ARP for address resolutions, instead 995 it forwards all the packets to the mobile access gateway. On such 996 types of links, the mobile access gateway is not required to 997 support Proxy ARP function. At the same time, implementations not 998 supporting the Proxy ARP function on links where the mobile node 999 uses ARP for seeking address resolutions for the destinations on 1000 the mobile node's home subnet will result in communication 1001 failure. 1003 3.3. Mobility Options and Status Codes 1005 To support the IPv4 home address mobility feature, this specification 1006 defines the following new options and Status Codes. 1008 3.3.1. IPv4 Home Address Request Option 1010 A new option, IPv4 Home Address Request Option is defined for use 1011 with the Proxy Binding Update message sent by the mobile access 1012 gateway to the local mobility anchor. This option is used for 1013 requesting IPv4 home address assignment for the mobile node. 1015 The IPv4 Home Address Request option has an alignment requirement of 1016 4n. Its format is as follows: 1018 0 1 2 3 1019 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 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Type | Length |Prefix-len | Reserved | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | IPv4 home address | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 Figure 3: IPv4 Home Address Request Option 1028 Type 1030 IANA 1032 Length 1034 8-bit unsigned integer indicating the length of the option in 1035 octets, excluding the type and length fields. This field MUST 1036 be set to (6). 1038 Prefix-len 1040 This 6-bit unsigned integer indicating the prefix length of the 1041 IPv4 home address contained in the option. 1043 Reserved 1045 This 10-bit field is unused for now. The value MUST be 1046 initialized to (0) by the sender and MUST be ignored by the 1047 receiver. 1049 IPv4 home address 1051 This four-byte field containing the IPv4 home address that is 1052 being requested. The value of 0.0.0.0 is used for requesting 1053 the local mobility anchor to perform the address allocation. 1055 3.3.2. IPv4 Home Address Reply Option 1057 A new option, IPv4 Home Address Reply Option is defined for using it 1058 in the Proxy Binding Acknowledgment message sent by the local 1059 mobility anchor to the mobile access gateway. This option can be 1060 used for sending the assigned mobile node's IPv4 home address. 1062 The IPv4 Home Address Reply option has an alignment requirement of 1063 4n. Its format is as follows: 1065 0 1 2 3 1066 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 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | Type | Length | Status |Pref-len |Res| 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | IPv4 home address | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 Figure 4: IPv4 Home Address Reply Option 1075 Type 1077 IANA 1079 Length 1081 8-bit unsigned integer indicating the length of the option in 1082 octets, excluding the type and length fields. This field MUST 1083 be set to (6). 1085 Status 1087 Indicates success or failure for the IPv4 home address 1088 assignment. Values from 0 to 127 indicate success. Higher 1089 values (128 to 255) indicate failure. The following status 1090 values are currently allocated by this document: 1092 0 Success 1094 128 Failure, reason unspecified 1096 129 Administratively prohibited 1097 130 Incorrect IPv4 home address 1099 131 Invalid IPv4 address 1101 132 Dynamic IPv4 home address assignment not available 1103 Prefix-len 1105 This 6-bit unsigned integer is used for carrying the prefix 1106 length of the mobile node's IPv4 home network corresponding the 1107 IPv4 home address contained in the option. 1109 Reserved (Res) 1111 This 2-bit field is unused for now. The value MUST be 1112 initialized to (0) by the sender and MUST be ignored by the 1113 receiver. 1115 IPv4 home address 1117 This four-byte field is used for carrying the IPv4 home address 1118 assigned to the mobile node. 1120 3.3.3. IPv4 Default-Router Address Option 1122 A new option, IPv4 Default-Router Address Option is defined for using 1123 it in the Proxy Binding Acknowledgment message sent by the local 1124 mobility anchor to the mobile access gateway. This option can be 1125 used for sending the mobile node's IPv4 default router address. 1127 The IPv4 Default-Router Address option has an alignment requirement 1128 of 4n. Its format is as follows: 1130 0 1 2 3 1131 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 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Type | Length | Reserved (R) | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | IPv4 Default-Router Address | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 Figure 5: IPv4 Default-Router Address Option 1140 Type 1142 IANA 1144 Length 1146 8-bit unsigned integer indicating the length of the option in 1147 octets, excluding the type and length fields. This field MUST 1148 be set to (6). 1150 Reserved (R) 1152 This 16-bit field is unused for now. The value MUST be 1153 initialized to (0) by the sender and MUST be ignored by the 1154 receiver. 1156 IPv4 Default-Router Address 1158 A four-byte field containing the mobile node's default router 1159 address. 1161 3.3.4. IPv4 DHCP Support Mode 1163 A new option, IPv4 DHCP Support Mode Option is defined for using it 1164 in the Proxy Binding Acknowledgment message sent by the local 1165 mobility anchor to the mobile access gateway. This option can be 1166 used for notifying the mobile access gateway, if it should function 1167 as a DHCP Server or a DHCP Relay for the attached mobile node. 1169 The IPv4 DHCP Support Mode option has no alignment requirement. Its 1170 format is as follows: 1172 0 1 2 3 1173 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 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | Type | Length | Reserved (R) |S| 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 Figure 6: IPv4 DHCP Support Mode Option 1180 Type 1182 IANA 1184 Length 1186 8-bit unsigned integer indicating the length of the option in 1187 octets, excluding the type and length fields. This field MUST 1188 be set to 2. 1190 Reserved (R) 1192 This 15-bit field is unused for now. The value MUST be 1193 initialized to (0) by the sender and MUST be ignored by the 1194 receiver. 1196 DHCP Support Mode (S) 1198 A 1-bit field that specifies the DHCP support mode. This flag 1199 indicates if the mobile access gateway should function as a 1200 DHCP Server or a DHCP Relay for the attached mobile node. The 1201 flag value of (0) indicates the mobile access gateway should 1202 act as a DHCP Relay and the flag value of (1) indicates it 1203 should act as a DHCP Server. 1205 3.3.5. Status Codes 1207 This document defines the following new Status values for use in the 1208 Proxy Binding Acknowledgement message. These values are to be 1209 allocated from the same numbering space, as defined in Section 6.1.8 1210 of [RFC-3775]. 1212 NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: IANA 1214 Mobile node not authorized for IPv4 mobility service. 1216 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 1218 Mobile node not authorized for the requesting IPv4 home address 1220 NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: IANA 1222 Mobile node not authorized for IPv6 mobility service. 1224 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: IANA 1226 Multiple IPv4 home address assignment not supported 1228 3.4. Supporting DHCP-Based Address Configuration 1230 This section explains how DHCP-based address configuration support 1231 can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It 1232 explains the protocol operation, supported DHCP server deployment 1233 configurations and the protocol interactions between DHCP agents and 1234 mobility entities in each of the supported configurations. 1236 This specification supports the following two DHCP deployment 1237 configurations. 1239 o DHCP relay agent co-located with the mobile access gateway. 1241 o DHCP server co-located in the mobile access gateway. 1243 The following are the configuration requirements: 1245 o The DHCP server or the DHCP relay agent configured on the mobile 1246 access gateway is required to have an IPv4 address for exchanging 1247 the DHCP messages with the mobile node. This address is the 1248 mobile node's default router address provided by the local 1249 mobility anchor. Optionally, all the DHCP servers co-located with 1250 the mobile access gateways in the Proxy Mobile IPv6 domain can be 1251 configured with a fixed IPv4 address. This fixed address can be 1252 potentially an IPv4 private address [RFC-1918] that can be used 1253 for the DHCP protocol communication on any of the access links. 1254 This address will be used as the server identifier in the DHCP 1255 messages. 1257 o A DHCP server identifies a DHCP interface from the contents of the 1258 DHCP "Client-identifier" option [RFC-2132], if present, or from 1259 the client hardware address (chaddr), as specified in [RFC-2131]. 1260 Note that the name "Client-identifier" is a misnomer as it 1261 actually identifies an interface and not the client. The DHCP 1262 server uses this identity to identify the interface for which the 1263 address is assigned. A mobile node in a Proxy Mobile IPv6 domain, 1264 can attach to the network through multiple interfaces and can 1265 obtain address configuration for each of its interfaces. 1266 Additionally, it may perform handoffs between its interfaces. 1267 Following are the related considerations with respect to the 1268 identification presented to the DHCP server. < 1270 * If the mobile node attaches to the Proxy Mobile IPv6 domain 1271 through multiple physical interfaces, the DHCP server will 1272 uniquely identify each of those interfaces and will perform 1273 address assignment. The DHCP server will identify the 1274 interface as specified in RFC 2131. The mobile node SHOULD 1275 generate and use the "Client-identifier" for each physical 1276 interface according to [RFC-4361]. Any time the mobile node 1277 performs an handoff of a physical interface to a different 1278 mobile access gateway, using the same interface, the DHCP 1279 server will always be able to identify the binding using the 1280 presented identifier. The presented identifier (either the 1281 "Client-identifier" or the hardware address) will remain as the 1282 primary key for each binding, just as how they are unique in a 1283 Binding Cache entry. 1285 * If the mobile node is capable of performing handoff between 1286 interfaces, as per [RFC-5213], a "Client-identifier" value MUST 1287 be used for the attachment point that is not tied to any of the 1288 physical interfaces. The identifier MUST be generated 1289 according to [RFC-4361], which guarantees that the identifier 1290 is stable and unique across all "Client-identifier" values in 1291 use in the Proxy Mobile IPv6 domain. 1293 o All the DHCP servers co-located with the mobile access gateways in 1294 a Proxy Mobile IPv6 domain can be configured with the same set of 1295 DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure 1296 the mobile node receives the same configuration values on any of 1297 the access links in that Proxy Mobile IPv6 domain. 1299 3.4.1. DHCP Server co-located with the Mobile Access Gateway 1301 This section explains the operational sequence of home address 1302 assignment operation when the DHCP server is co-located with the 1303 mobile access gateway. 1305 MN MAG(DHCP-S) LMA 1306 |------>| | 1. DHCPDISCOVER 1307 | |------->| 2. Proxy Binding Update 1308 | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) 1309 | |========| 4. Tunnel/Route Setup 1310 |<------| | 5. DHCPOFFER (IPv4 HoA) 1311 |------>| | 6. DHCPREQUEST (IPv4 HoA) 1312 |<------| | 7. DHCPACK 1313 | | | 1314 * It is possible the MAG may have already completed the Proxy Mobile 1315 IPv6 signaling with the LMA for requesting both IPv6 home network 1316 prefix(es) and IPv4 home address assignment prior to step-1. In 1317 such event, the Proxy Mobile IPv6 signaling steps (step-2 to 1318 step-4) above are not relevant. 1319 * It is possible the MAG may have initially completed the Proxy 1320 Mobile IPv6 signaling prior to Step-1, but only for requesting 1321 IPv6 home network prefix(es) and may later request IPv4 home 1322 address assignment after detecting the DHCP triggers from the 1323 mobile node as shown above. 1324 * The MAG may choose to ignore the DHCPDISCOVER messages till the 1325 Proxy Mobile IPv6 signaling is successfully completed, or it may 1326 choose to send a delayed response for reducing the additional 1327 delay waiting for a new DHCPDISCOVER message from the mobile node. 1329 Figure 7: Overview of DHCP Server located at Mobile Access Gateway 1331 Initial IPv4 Home Address Assignment: 1333 o For acquiring the mobile node's IPv4 home address from the local 1334 mobility anchor, the mobile access gateway will initiate Proxy 1335 Mobile IPv6 signaling with the local mobility anchor. 1337 o After the successful completion of the Proxy Mobile IPv6 signaling 1338 and upon acquiring the mobile node's IPv4 home address from the 1339 local mobility anchor, the DHCP server on the mobile access 1340 gateway will send a DHCPOFFER message [RFC-2131] to the mobile 1341 node. The offered address will be the mobile node's IPv4 home 1342 address, assigned by the local mobility anchor. The DHCPOFFER 1343 message will also have the subnet mask option [RFC-2132] and 1344 router option [RFC-2132], with the values in those options set to 1345 the mobile node's IPv4 home subnet mask and default router address 1346 respectively. Additionally, the Server Identifier option will be 1347 included and with the value in the option set to the default 1348 router address. 1350 o If the mobile node sends the DHCPREQUEST message, the DHCP server 1351 will send DHCPACK message, as per [RFC-2131]. 1353 IPv4 Home Address Renewal with the DHCP server (No Handoff): 1355 o Any time the mobile node goes into the DHCP RENEWING state [RFC- 1356 2131], it simply unicasts the DHCPREQUEST message including the 1357 assigned IPv4 home address in the 'requested IP address' option. 1358 The DHCPREQUEST is sent to the address specified in Server 1359 Identifier option of the previously received DHCPOFFER and DHCPACK 1360 messages. 1362 o The DHCP server will send a DHCPACK to the mobile node to 1363 acknowledge the assignment of the committed IPv4 address. 1365 IPv4 Home Address Renewal with the DHCP server (After Handoff): 1367 When the mobile node goes into the DHCP RENEWING state [RFC-2131], it 1368 directly unicasts the DHCPREQUEST message to the DHCP server that 1369 currently provided the DHCP lease. However, if the mobile node 1370 changed its point of attachment and is attached to a new mobile 1371 access gateway, it is required that the mobile node updates the DHCP 1372 server address and uses the address of the DHCP server that is co- 1373 located with the new mobile access gateway. The following approach 1374 can be adopted to ensure the mobile node uses the DHCP server on the 1375 attached link. 1377 MN oMAG(DHCP-S) nMAG(DHCP-S) 1378 | : | 1379 RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) 1380 BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK 1381 | : | 1382 * The use of a fixed DHCP server address on all DHCP servers 1384 Figure 8: Address renewal with the DHCP server 1386 o The use of a stable address, either the IPv4 default router 1387 address of the mobile node, or a fixed IPv4 address common in that 1388 Proxy Mobile IPv6 domain, as the DHCP server Id will ensure the 1389 DHCPREQUEST message sent by the mobile node for renewing the 1390 address will be received by the new mobile access gateway on the 1391 attached link. 1393 o The mobile access gateway after completing the Proxy Mobile IPv6 1394 signaling and upon acquiring the IPv4 home address of the mobile 1395 node will return the address in the DHCPACK message. However, if 1396 the mobile access gateway is unable to complete the Proxy Mobile 1397 IPv6 signaling or is unable to acquire the same IPv4 address as 1398 requested by the mobile node, it will send a DHCPNACK message 1399 [RFC-2131] to the mobile node, as shown in Figure 8-1). 1401 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway 1403 A DHCP relay agent is co-located with each mobile access gateway. A 1404 DHCP server is located somewhere in the Proxy Mobile IPv6 domain 1405 (e.g., is co-located with the local mobility anchor). Figure 9 shows 1406 the sequence of IPv4 home address assignment using DHCP Relay. 1408 MN MAG(DHCP-R) LMA DHCP-S 1409 | |------->| | 1. Proxy Binding Update * 1410 | |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA) 1411 | |========| | 3. Tunnel/Route Setup* 1412 |------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R 1413 |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R 1414 |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R 1415 |<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R 1416 | | | 1417 * The Proxy Mobile IPv6 signaling (starting at Step-1) and the 1418 DHCP address configuration (starting at Step-4) may start in any 1419 order. However, the DHCPOFFER (Step-5) and the immediate steps 1420 following it will occur in the specified order and only after the 1421 Tunnel/Route Setup (Step-3). 1422 * It is possible the MAG may have initially completed the Proxy 1423 Mobile IPv6 signaling with the LMA only for requesting IPv6 home 1424 network prefix(es) and may later request IPv4 home address 1425 assignment after detecting the DHCP triggers from the mobile node 1426 (after Step-4). 1427 * The MAG may choose to ignore the DHCPDISCOVER messages till the 1428 Proxy Mobile IPv6 signaling is successfully completed, or it may 1429 choose to send a delayed response for reducing the additional 1430 delay waiting for a new DHCPDISCOVER message from the mobile node. 1432 Figure 9: Overview of the DHCP relay located at mobile access gateway 1434 Initial IPv4 Home Address Assignment: 1436 o For acquiring the mobile node's IPv4 home address from the local 1437 mobility anchor, the mobile access gateway will initiate Proxy 1438 Mobile IPv6 signaling with the local mobility anchor. 1440 o After the successful completion of the Proxy Mobile IPv6 signaling 1441 and upon acquiring the mobile node's IPv4 home address from the 1442 local mobility anchor, the mobile access gateway will enable 1443 forwarding for all the DHCP messages between the mobile node and 1444 the DHCP server. 1446 o The DHCP relay agent on the mobile access gateway will add the 1447 DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER 1448 message. The assigned IPv4 home address will be included in the 1449 Agent Remote ID Sub-option of the DHCP relay agent information 1450 option. This sub-option is used as a hint for requesting the DHCP 1451 server to allocate that specific IPv4 address. 1453 o On receiving a DHCPOFFER message from the DHCP server, the mobile 1454 access gateway will ensure the assigned address is currently 1455 assigned by the local mobility anchor to that mobile node. If 1456 this address is different from what is assigned to the mobile 1457 node, then the mobile access gateway will drop the DHCPOFFER 1458 message and an administrative error message will be logged. 1460 o When the DHCP messages are sent over administrative boundaries, 1461 the operators needs to ensure these messages are secured. All the 1462 DHCP messages relayed by the mobile access gateway can be tunneled 1463 to the local mobility anchor if needed. Alternatively, if the 1464 network in the Proxy Mobile IPv6 domain is secure enough, the 1465 mobile access gateway can just relay the DHCP messages to the 1466 server. To achieve this, all the mobile access gateways needs to 1467 have a route towards the DHCP server. 1469 IPv4 Home Address Renewal to the same DHCP server: (No Handoff) 1471 o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it 1472 directly unicasts DHCPREQUEST messages to the DHCP server. The 1473 DHCP relay agent may not detect any changes in the DHCP state. 1474 For example, if the mobile node releases the IPv4 address, the 1475 relay agent would not be aware of it. The following describes 1476 additional mechanisms for the mobile access gateway to detect any 1477 changes in the DHCP state. 1479 * The DHCP relay agent can intercept all IPv4 DHCP packets 1480 destined to the set of addresses used within the Proxy Mobile 1481 IPv6 domain as DHCP addresses. Since the link between a mobile 1482 node and a mobile access gateway is the point-to-point link, 1483 the mobile access gateway will be in path for all the messages. 1485 * The DHCP relay agent can use the DHCP Server Identifier 1486 Override Sub-option [RFC-5107] to be in path for all the DHCP 1487 message flows. The DHCP client uses the DHCP server address 1488 which is overridden by the DHCP relay agent address as a 1489 destination address of DHCPREQUEST. The DHCP Server Identifier 1490 Override Sub-option is recommended only when the fixed DHCP 1491 relay address is configured on all the mobile access gateways. 1492 Otherwise, the DHCP relay agent address is changed when the 1493 mobile node changes the attached mobile access gateway. 1495 o However, if the DHCP server is co-located with the local mobility 1496 anchor, then the DHCP relay agent is not required to intercept the 1497 unicast DHCP messages between the mobile node and the DHCP server. 1498 This is because the local mobility anchor will ensure that the 1499 DHCP state is consistent with the PMIPv6 binding that exists for 1500 the IPv4 address. 1502 o Once the mobile access gateway intercepts the DHCP message from 1503 the mobile node to the DHCP server, it can verify if the mobile 1504 node is negotiating the same IPv4 address that the local mobility 1505 anchor allocated for that mobile node. If the address in the 1506 DHCPREQUEST message does not match with the IPv4 address allocated 1507 for the mobile node, then the mobile access gateway SHOULD drop 1508 the DHCP message and an administrative error message can be 1509 logged. 1511 o Any time the mobile access gateway detects that the mobile node 1512 has released its IPv4 address, it can send a Proxy Binding Update 1513 to the local mobility anchor and de-register the IPv4 mobility 1514 session. 1516 3.4.3. Common DHCP Considerations 1518 The following DHCP related considerations are common to both the 1519 supported configuration modes, specified in Section 3.4.1 and Section 1520 3.4.2. 1522 o When a mobile node sends a DHCPDISCOVER message [RFC-2131], the 1523 DHCP server or the relay agent co-located with the mobile access 1524 gateway will trigger the mobile access gateway to complete the 1525 Proxy Mobile IPv6 signaling. This is the required interaction 1526 between these two protocols. The mobile access gateway on 1527 receiving this trigger will check if there is already an assigned 1528 IPv4 home address for the mobile node, from the local mobility 1529 anchor. If there is no assigned IPv4 home address assigned for 1530 that mobile node, the mobile access gateway will complete the 1531 Proxy Mobile IPv6 signaling with the local mobility anchor by 1532 sending a Proxy Binding Update message. 1534 o The mobile node needs to be identified by the MN-Identifier, as 1535 specified in Section 6.6 of [RFC-5213]. This identity should be 1536 associated to the DHCP messages sent by the mobile node. 1538 o The mobile access gateway will drop all the DHCPDISCOVER messages 1539 till it completes the Proxy Mobile IPv6 signaling. If the mobile 1540 access gateway is unable to complete the Proxy Mobile IPv6 1541 signaling, or, if the local mobility anchor does not assign an 1542 IPv4 address for the mobile node, the mobile access gateway MUST 1543 NOT enable IPv4 home address mobility support for the mobile node 1544 on that access link. 1546 o The trigger for initiating Proxy Mobile IPv6 signaling can also be 1547 delivered to the mobile access gateway as part of a context 1548 transfer from the previous mobile access gateway, or delivered 1549 from the other network elements in the radio network, the details 1550 of which are outside the scope of this document. 1552 o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST 1553 include the Subnet Mask option [RFC-2132] and the Router option 1554 [RFC-2132]. The values in the Subnet Mask option and Router 1555 option MUST be set to the mobile node's IPv4 home subnet mask and 1556 its default router address respectively. 1558 o The DHCPOFFER message [RFC-2131] sent to the mobile node MUST 1559 include the Interface MTU option [RFC-2132]. The DHCP servers in 1560 the Proxy Mobile IPv6 domain MUST be configured to include the 1561 Interface MTU option. The MTU value SHOULD reflect the tunnel MTU 1562 for the bi-directional tunnel between the mobile access gateway 1563 and the local mobility anchor. 1565 o The DHCP lease length allocated to the mobile node's IPv4 home 1566 address may be different from the binding lifetime at the local 1567 mobility anchor for that mobile node's session. It is not 1568 possible to keep these lifetimes synchronized and so its not 1569 required that the configured lifetimes should be kept same in both 1570 DHCP and Proxy Mobile IPv6. 1572 o When the mobile node performs an handoff from one mobile access 1573 gateway to another, the mobile access gateway on the new link will 1574 initiate the Proxy Mobile IPv6 signaling with the local mobility 1575 anchor. On completing the Proxy Mobile IPv6 signaling, the mobile 1576 access gateway has the proper IPv4 address state that the local 1577 mobility anchor has allocated for the mobile node and which can be 1578 used for supporting DHCP based address configuration on that link. 1580 o Any time the mobile node detects a link change event due to 1581 handoff, or due to other reasons such as re-establishment of the 1582 link-layer, the following are the mobile node's considerations 1583 with respect to the DHCP protocol. 1585 * If the mobile node is DNAv4 [RFC-4436] capable and if it 1586 performs DNAv4 procedures after receiving a link change event, 1587 it would always detect the same default router on any of the 1588 access links in that Proxy Mobile IPv6 domain, as the mobile 1589 access gateway configures a fixed link-layer address on all the 1590 access links, as per the base Proxy Mobile IPv6 specification 1591 [RFC-5213]. The mobile node will not perform any DHCP 1592 operation specifically due to this event. 1594 * If the mobile node is not DNAv4 [RFC-4436] capable, after 1595 receiving the link change event it will enter INIT-REBOOT state 1596 [RFC-2131] and will send a DHCPREQUEST message as specified in 1597 Section 3.7 of [RFC-2131]. The mobile node will obtain the 1598 same address configuration as before, as the link change does 1599 not result in any change at the network layer. 1601 o The mobile node may release its IPv4 home address at any time by 1602 sending the DHCPRELEASE message [RFC-2131]. When the mobile 1603 access gateway detects the DHCPRELEASE message sent by the mobile 1604 node, it should consider this as a trigger for de-registering the 1605 mobile node's IPv4 home address. It will apply the considerations 1606 specified in section 3.2.3.3 for performing the de-registration 1607 procedure. However, this operation MUST NOT release any IPv6 home 1608 network prefix(es) assigned to the mobile node. 1610 4. IPv4 Transport Support 1612 The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling 1613 messages exchanged between the local mobility anchor and the mobile 1614 access gateway to be over an IPv6 transport. The extensions defined 1615 in this section allow the exchange of signaling messages over an IPv4 1616 transport when the local mobility anchor and the mobile access 1617 gateway are separated by an IPv4 network and are reachable using only 1618 IPv4 addresses. 1620 IPv4-Proxy-CoA IPv4-LMAA 1621 | + - - - - - - + | 1622 +--+ +---+ / \ +---+ +--+ 1623 |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| 1624 +--+ +---+ \ / +---+ +--+ 1625 + - - - - - - + 1627 Figure 10: IPv4 Transport Network 1629 When the local mobility anchor and the mobile access gateway are 1630 configured and reachable using only IPv4 addresses, the mobile access 1631 gateway serving a mobile node can potentially send the signaling 1632 messages over IPv4 transport and register its IPv4 address as the 1633 care-of address in the mobile node's Binding Cache entry. An IPv4 1634 tunnel (with any of the supported encapsulation modes) can be used 1635 for tunneling the mobile node's data traffic. The following are the 1636 key aspects of this feature. 1638 o The local mobility anchor and the mobile access gateway are both 1639 configured and reachable using an IPv4 address. Additionally, 1640 both entities are also IPv6 enabled and have configured IPv6 1641 addresses on their interfaces, as specified in [RFC-5213], but are 1642 reachable only over an IPv4 transport network. 1644 o The mobile access gateway can be potentially in a private IPv4 1645 network behind a NAT [RFC-3022] device, with a private IPv4 1646 address configured on its egress interface. But, the local 1647 mobility anchor must not be behind a NAT and must be using a 1648 globally routable IPv4 address. However, both the local mobility 1649 anchor and the mobile access gateway can be in the same private 1650 IPv4 routing domain, i.e., when both are configured with private 1651 IPv4 addresses and with no need for NAT translation between them. 1653 o The IPv6 address configuration requirement on the mobile access 1654 gateway does not imply there needs to be IPv6 routing enabled 1655 between the local mobility anchor and the mobile access gateway. 1656 It just requires each of the mobile access gateways and local 1657 mobility anchors in a Proxy Mobile IPv6 domain to be configured 1658 with a globally unique IPv6 address. 1660 o The Proxy Mobile IPv6 signaling messages exchanged between the 1661 local mobility anchor and the mobile access gateway for 1662 negotiating the IPv4 transport will be encapsulated and carried as 1663 IPv4 packets. However, these signaling messages are fundamentally 1664 IPv6 messages using the mobility header and the related semantics 1665 as specified in base Proxy Mobile IPv6 specification [RFC-5213], 1666 but carried as a payload in an IPv4 packet. The supported 1667 encapsulation modes for the signaling messages are either native 1668 IPv4 or IPv4 with UDP header. 1670 o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and 1671 the IPv4 transport support specified in this section is agnostic 1672 to the type of address mobility enabled for that mobile node. 1674 o The IPv4 tunnel established between the local mobility anchor and 1675 the mobile access gateway (with any of the supported encapsulation 1676 modes over IPv4 transport) will be used for carrying the mobile 1677 node's IPv4 and IPv6 traffic. The following are the outer headers 1678 based on the negotiated encapsulation mode. 1680 * IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet). 1681 If payload protection using IPsec is enabled for the tunneled 1682 traffic, the ESP header follows the outer tunnel header. 1684 * IPv4-UDP (Payload packet carried in an IPv4 packet with UDP 1685 header). If payload protection using IPsec is enabled for the 1686 tunneled traffic, the ESP header follows the outer tunnel 1687 header, as explained in Section 4.3. 1689 * IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP 1690 and TLV header). Refer to [ID-GREKEY-NEGO]. If payload 1691 protection using IPsec is enabled for the tunneled traffic, the 1692 ESP header follows the outer tunnel header, as explained in 1693 Section 4.3. 1695 4.1. Local Mobility Anchor Considerations 1697 4.1.1. Extensions to Binding Cache Entry 1699 To support this feature, the conceptual Binding Cache entry data 1700 structure maintained by the local mobility anchor [RFC-5213] MUST be 1701 extended with the following additional parameters. It is to be noted 1702 that all of these parameters are specified in [RFC-5555] and also 1703 required here in the present usage context, and are presented here 1704 only for completeness. 1706 o The IPv4 Proxy Care-of Address configured on the mobile access 1707 gateway that sent the Proxy Binding Update message. This address 1708 can be obtained from the IPv4 Care-of Address option [RFC-5555], 1709 present in the received Proxy Binding Update message. However, if 1710 the received Proxy Binding Update message is not sent as an IPv4 1711 packet, i.e., when using IPv6 transport, this field in the Binding 1712 Cache entry MUST be set to ALL_ZERO value. 1714 o The IPv4 NAT translated address of the mobile access gateway. If 1715 the mobile access gateway is not behind a NAT [RFC-3022], this 1716 address will be the same as the address configured on the egress 1717 interface of the mobile access gateway. This address can be 1718 obtained from the IPv4 header of the received Proxy Binding Update 1719 message. However, if the received Proxy Binding Update message is 1720 not sent as an IPv4 packet, this field in the Binding Cache entry 1721 MUST be set to ALL_ZERO value. 1723 o The source UDP port, if the Proxy Binding Update was received in 1724 an IPv4 packet with UDP header. 1726 o The destination UDP port, if the Proxy Binding Update was received 1727 in an IPv4 packet with UDP header. 1729 4.1.2. Extensions to Mobile Node's Policy Profile 1731 To support the IPv4 Transport Support feature the mobile node's 1732 policy profile, specified in Section 6.2 of [RFC-5213] MUST be 1733 extended with the following additional fields. These are mandatory 1734 fields of the policy profile required for supporting this feature. 1736 o The IPv4 address of the local mobility anchor (IPv4-LMAA). 1738 4.1.3. Signaling Considerations 1740 This section provides the rules for processing the Proxy Mobile IPv6 1741 signaling messages received over IPv4 transport. 1743 4.1.3.1. Processing Proxy Binding Updates 1745 o If the received Proxy Binding Update message was sent encapsulated 1746 in an IPv4 or IPv4-UDP packet, the message MUST be authenticated 1747 after removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1748 Considerations from Section 4 of [RFC-5213] MUST be applied for 1749 authenticating and authorizing the request. 1751 o All the considerations from Section 5.3.1 of [RFC-5213] MUST be 1752 applied on the encapsulated Proxy Binding Update message, after 1753 removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1755 o If there is an IPv4 Care-of Address option [RFC-5555] present in 1756 the request and if the outer encapsulation header is IPv4-UDP, 1757 then the NAT presence detection procedure specified in Section 1758 4.1.3.3 MUST be used for detecting the NAT in the path. 1760 o Upon accepting the request, the local mobility anchor MUST set up 1761 an IPv4 bi-directional tunnel to the mobile access gateway. The 1762 tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. 1763 The encapsulation mode MUST be determined by applying the 1764 following considerations: 1766 * If the received Proxy Binding Update message was sent with IPv4 1767 encapsulated header, then the encapsulation mode for the bi- 1768 directional tunnel MUST be set to IPv4. Otherwise, the 1769 following considerations apply. 1771 * If NAT is not detected on the path and if the (F) flag in the 1772 received Proxy Binding Update message is set to the value of 1773 (1), but if the configuration flag, 1774 AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of 1775 (0), then the local mobility anchor MUST reject the request 1776 with the Status field value set to 129 (Administratively 1777 prohibited). 1779 * If the (T) flag [ID-GREKEY-NEGO] in the Proxy Binding Update 1780 message is set to value of (1), then the encapsulation mode 1781 MUST be set to IPv4-or-IPv6-over-IPv4-UDP-TLV. 1783 * If NAT is detected on the path, or if the (F) flag in the 1784 received Proxy Binding Update message is set to the value of 1785 (1), then the encapsulation mode MUST be set to IPv4-or-IPv6- 1786 over-IPv4-UDP. Otherwise the encapsulation mode MUST be set to 1787 IPv4-or-IPv6-over-IPv4. 1789 o The local mobility anchor MUST send the Proxy Binding 1790 Acknowledgement message with the Status field value set to (0) 1791 (Proxy Binding Update Accepted). The message MUST be constructed 1792 as specified in Section 4.1.3.2. 1794 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 1796 The local mobility anchor when sending the Proxy Binding 1797 Acknowledgement message to the mobile access gateway MUST construct 1798 the message as specified in Section 5.3.6 of [RFC-5213]. However, if 1799 the received Proxy Binding Update message was encapsulated in an IPv4 1800 packet or as a payload in the UDP header of an IPv4 packet, the 1801 following additional considerations MUST be applied. 1803 o The Proxy Binding Acknowledgement message MUST be encapsulated in 1804 an IPv4 packet. However, if the received Proxy Binding Update 1805 message was sent encapsulated in an IPv4-UDP packet, then the 1806 Proxy Binding Acknowledgement message MUST be encapsulated in the 1807 UDP header of an IPv4 packet. 1809 o The source address in the IPv4 header of the message MUST be set 1810 to the destination IPv4 address of the received request. 1812 o If the mobile access gateway and the local mobility anchor are 1813 using globally routable IPv4 addresses and if there is a security 1814 association that is based on IPv4 addresses, then the encapsulated 1815 IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement) 1816 MUST be protected using IPsec ESP [RFC-4301] mode. There is no 1817 need to apply IPsec ESP header to the IPv6 packet. In all other 1818 cases, the Proxy Binding Acknowledgement message MUST be protected 1819 using IPsec prior to the IPv4 or IPv4-UDP encapsulation. 1821 o The NAT Detection option [RFC-5555] MUST be present only if there 1822 is an IPv4 Care-of Address option [RFC-5555] present in the 1823 received Proxy Binding Update message and if the NAT detection 1824 procedure resulted in detecting a NAT on path. However, if the 1825 received Proxy Binding Update message was not sent encapsulated in 1826 IPv4 UDP header, then the option MUST NOT be present. 1827 Furthermore, in all other cases, the option MUST NOT be present. 1829 o The IPv4 DHCP Support Mode option MAY be present. If this option 1830 is not present, the mobile access gateway will enable the default 1831 behavior and function as a DHCP Relay for the mobile node. 1833 o Figure 9 shows the format of the Proxy Binding Acknowledgement 1834 message encapsulated in an IPv4 packet and protected using IPv6 1835 security association. The UDP header MUST be present only if the 1836 received Proxy Binding Update message was sent encapsulated in an 1837 IPv4-UDP packet. 1839 IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) 1840 UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/ 1841 /* IPv6 PBA Packet protected with ESP header */ 1843 Figure 11: Proxy Binding Acknowledgment (PBA) Message encapsulated 1844 in IPv4 header 1846 4.1.3.3. NAT Presence Detection 1848 When the transport network between the local mobility anchor and the 1849 mobile access gateway is an IPv4 network and if the received Proxy 1850 Binding Update message was sent encapsulated in IPv4 UDP header, the 1851 local mobility anchor performs the NAT Presence Detection as 1852 specified below. 1854 On receiving the Proxy Binding Update message encapsulated in an IPv4 1855 UDP packet, the local mobility anchor, if it detects a NAT on the 1856 path, will send the Proxy Binding Acknowledgment message with the NAT 1857 Detection Option. The presence of this option in the Proxy Binding 1858 Acknowledgment is an indication to the mobile access gateway about 1859 the presence of NAT in the path. On detecting any NAT in the path, 1860 both the local mobility anchor and the mobile access gateway will set 1861 the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation. 1862 The specific details around the NAT detection and the related logic 1863 are described in DSMIPv6 specification [RFC-5555]. 1865 However, if the value of the configuration variable, 1866 UseIPv4UDPEncapForSignalingMessages, is set to a value of (0), the 1867 mobile access gateway will not use IPv4 UDP encapsulation for Proxy 1868 Binding Update messages and hence the local mobility anchor will not 1869 perform this NAT Presence Detection procedure on these messages that 1870 are not sent in IPv4 UDP packet. 1872 4.1.4. Routing Considerations 1874 4.1.4.1. Forwarding Considerations 1876 Forwarding Packets to the Mobile Node: 1878 o On receiving an IPv4 or an IPv6 packet from a correspondent node 1879 with the destination address matching any of the mobile node's 1880 IPv4 or IPv6 home addresses, the local mobility anchor MUST 1881 forward the packet through the bi-directional tunnel set up for 1882 that mobile node. 1884 o The format of the tunneled packet is shown below. 1886 IPv4 Header (src= IPv4-LMAA, dst= IPv4-Proxy-CoA)] /* Tunnel Header */ 1887 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1888 [TLV Header] /* If TLV negotiated */ 1889 /* IPv6 or IPv4 Payload Packet */ 1890 IPv6 header (src= CN, dst= MN-HOA) 1891 OR 1892 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1894 Figure 12: Tunneled IPv4 Packet from LMA to MAG 1896 o Forwarding Packets Sent by the Mobile Node: 1898 * All the reverse tunneled packets (IPv4 and IPv6) that the local 1899 mobility anchor receives from the mobile access gateway, after 1900 removing the tunnel header (i.e., the outer IPv4 header along 1901 with the UDP and TLV header, if negotiated) MUST be routed to 1902 the destination specified in the inner packet header. These 1903 routed packets will have the source address field set to the 1904 mobile node's home address. 1906 4.1.4.2. ECN & Payload Fragmentation Considerations 1908 The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply 1909 for the IPv4 transport tunnels as well. The mobility agents at the 1910 tunnel entry and exit points MUST handle ECN information as specified 1911 in that document. 1913 The mobility agents at the tunnel entry and exit points MUST apply 1914 the IP packet fragmentation considerations as specified in [RFC- 1915 4213]. Additionally they MUST also apply the considerations related 1916 to tunnel error processing and reporting as specified in the same 1917 specification. 1919 4.1.4.3. Bi-Directional Tunnel Management 1921 The Tunnel Management considerations specified in section 5.6.1 of 1922 [RFC-5213] apply for the IPv4 transport tunnels as well, with just 1923 one difference that the encapsulation mode is different. 1925 4.2. Mobile Access Gateway Considerations 1927 4.2.1. Extensions to Binding Update List Entry 1929 To support the IPv4 Transport Support feature, the conceptual Binding 1930 Update List entry data structure maintained by the mobile access 1931 gateway [RFC-5213] MUST be extended with the following additional 1932 parameters. 1934 o The IPv4 address of the local mobility anchor. This address can 1935 be obtained from the mobile node's policy profile. 1937 4.2.2. Signaling Considerations 1939 The mobile access gateway when sending a Proxy Binding Update message 1940 to the local mobility anchor MUST construct the message as specified 1941 in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access 1942 gateway is in an IPv4-only access network, the following additional 1943 considerations MUST be applied. 1945 o The Proxy Binding Update message MUST be encapsulated in an IPv4 1946 packet. However, if the value of the configuration variable, 1947 UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy 1948 Binding Update message MUST be encapsulated in an UDP header of an 1949 IPv4 packet. 1951 o The IPv4 Care-of Address option [RFC-5555] MUST be present. The 1952 IPv4 address in the option MUST be set to the mobile access 1953 gateway's IPv4-Proxy-CoA. 1955 o The packet MUST be constructed as specified in Section 4.2.2.1. 1957 o Just as specified in [RFC-5213], when sending a Proxy Binding 1958 message for extending the lifetime of a currently existing 1959 mobility session or for de-registering the mobility session, the 1960 Proxy Binding Update message MUST be constructed just as the 1961 initial request. 1963 Receiving Proxy Binding Acknowledgement 1965 o If the received Proxy Binding Acknowledgement message is 1966 encapsulated in IPv4 or IPv4 UDP packet, the message MUST be 1967 authenticated after removing the outer IPv4 or IPv4-UDP header. 1968 Considerations from Section 4 of [RFC-5213] MUST be applied for 1969 authenticating and authorizing the message. 1971 o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be 1972 applied on the encapsulated Proxy Binding Acknowledgement message, 1973 after removing the outer IPv4 UDP header. 1975 o If the Status field indicates Success, the mobile access gateway 1976 MUST setup a bi-directional tunnel to the local mobility anchor. 1978 o Upon accepting the request, the mobile access gateway MUST set up 1979 an IPv4 bi-directional tunnel to the local mobility anchor. The 1980 tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA. 1981 The encapsulation mode MUST be determined from the below 1982 considerations. 1984 o The encapsulation mode for the bi-directional tunnel MUST be set 1985 to IPv4. However, if the value of the configuration variable, 1986 UseIPv4UDPEncapForSignalingMessages, is set to (1), then the 1987 following considerations MUST be applied. 1989 * If there is a NAT Detection option [RFC-5555] in the received 1990 Proxy Binding Acknowledgement message and if the value of the 1991 configuration flag, UseIPv4UDPEncapForSignalingMessages, is set 1992 to value of (1), then the encapsulation mode for the tunnel 1993 MUST be set to IPv4-UDP. Otherwise the encapsulation mode MUST 1994 be set to IPv4. 1996 * If the (T) flag in the Proxy Binding Acknowledgement message is 1997 set to value of (1), then the encapsulation mode MUST be set to 1998 IPv4-UDP-TLV. 2000 4.2.2.1. Constructing the Proxy Binding Update Message 2002 o The source address in the IPv4 header MUST be set to IPv4-Proxy- 2003 CoA of the mobile access gateway and the destination address MUST 2004 be set to the local mobility anchor's IPv4-LMAA. 2006 o The IPv4 Care-of Address option [RFC-5555] MUST be present. The 2007 address MUST be set to the mobile access gateway's IPv4-Proxy-CoA. 2009 o If the configuration variable ForceIPv4UDPEncapsulationSupport is 2010 set to value of (1), then the (F) flag in the Proxy Binding Update 2011 message MUST be set to value of (1). 2013 o The Proxy Binding Update message MUST be protected using IPsec ESP 2014 [RFC-4301], as specified in [RFC-5213]. The protection MUST be 2015 applied on the IPv6 packet of the Proxy Binding Update message, 2016 prior to the IPv4 encapsulation. 2018 o The format of the Proxy Binding Update message encapsulated in an 2019 IPv4 or IPv4-UDP packet with no IPsec protection: 2021 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 2022 UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/ 2023 /* IPv6 PBU Packet protected with ESP header */ 2025 Figure 13: Proxy Binding Update (PBU) message encapsulated in IPv4 2026 UDP header 2028 4.2.2.2. Forwarding Considerations 2030 Forwarding Packets Sent by the Mobile Node: 2032 o On receiving an IPv4 or an IPv6 packet from the mobile node to any 2033 destination, the mobile access gateway MUST tunnel the packet to 2034 the local mobility anchor. The format of the tunneled packet is 2035 shown below. However, considerations from Section 6.10.3 of [RFC- 2036 5213] MUST be applied with respect the local routing and on the 2037 use of EnableMAGLocalRouting flag. 2039 IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */ 2040 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 2041 [TLV Header] /* If TLV negotiated */ 2042 /* IPv6 or IPv4 Payload Packet */ 2043 IPv6 header (src= CN, dst= MN-HOA) 2044 OR 2045 IPv4 header (src= CN, dst= IPv4 MN-HoA) 2047 Figure 14 2049 o Forwarding Packets received from the bi-directional tunnel: 2051 o On receiving a packet from the bi-directional tunnel established 2052 with the mobile node's local mobility anchor, the mobile access 2053 gateway MUST remove the outer header before forwarding the packet 2054 to the mobile node. 2056 4.3. IPsec Considerations 2058 4.3.1. PBU and PBA 2060 The following section describes how IPsec is used for protecting the 2061 signaling messages and data packets between the local mobility anchor 2062 and mobile access gateway when using IPv4 transport. 2064 The following are the SPD example entries to protect PBU and PBA on 2065 the local mobility anchor and mobile access gateway. 2067 MAG SPD-S: 2068 - IF local_address = Proxy-CoA_1 & 2069 remote_address = LMAA_1 & proto = MH & 2070 local_mh_type = PBU & remote_mh_type = PBAck 2071 Then use SA ESP transport mode 2073 LMA SPD-S: 2074 - IF local_address = LMAA_1 & 2075 remote_address = Proxy-CoA_1 & proto = MH & 2076 local_mh_type = PBAck & remote_mh_type = PBU 2077 Then use SA ESP transport mode 2079 Figure 15 and Figure 16 show how PBU and PBA are sent and processed 2080 at the local mobility anchor and at the mobile access gateway. IPsec 2081 ESP is always applied before the PBU or the PBA is encapsulated in 2082 the outer IPv4 header. 2084 | PBU on wire : PBU internal processing 2085 \|/ \:/ 2087 MAG's PMIP Module 2088 : 2089 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2090 : Mobility header 2091 : PBU (p flag) 2092 : Home Network Prefix option 2093 : IPv4 Home Address Request option 2094 : IPv4 Care-of Address option 2095 : 2096 \:/ 2097 MAG's IPsec module 2098 : 2099 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2100 : ESP header in transport mode 2101 : Mobility header 2102 : PBU (p flag) 2103 : Home Network Prefix option 2104 : IPv4 Home Address Request option 2105 : IPv4 Care-of Address option 2106 : 2107 : * After adding the ESP header, the PBU is returned to the PMIP 2108 : module and is encapsulated into the UDP and IPv4 headers. 2109 : This requires a Proxy Mobile IPv6 specific IPsec implementation, 2110 : which knows that the packet needs to be passed back to the PMIP 2111 : module, instead of sending it out via the normal forwarding 2112 \:/ 2113 MAG 2114 | IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 2115 | UDP header (sport=Z, dport=DSMIPv6) 2116 | IPv6 header (src=Proxy-CoA, dst=LMAA) 2117 | ESP header in transport mode 2118 | Mobility header 2119 | PBU (p flag) 2120 | Home Network Prefix option 2121 | IPv4 Home Address Request option 2122 | IPv4 Care-of Address option 2123 \|/ 2124 LMA (received at DSMIPv6 port) 2125 : 2126 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2127 : ESP header in transport mode 2128 : Mobility header 2129 : PBU (p flag) 2130 : Home Network Prefix option 2131 : IPv4 Home Address Request option 2132 : IPv4 Care-of Address option 2133 : 2134 : *In addition, IPv4-Proxy-CoA and the sport (Z) needs to 2135 : be passed along with the packet to ensure correct processing. 2136 \:/ 2137 LMA's IPsec module 2138 : 2139 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2140 : Mobility header 2141 : PBU (p flag) 2142 : Home Network Prefix option 2143 : IPv4 Home Address Request option 2144 : IPv4 Care-of Address option 2145 : 2146 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2147 : be passed with the packet to ensure correct processing. 2148 \:/ 2149 LMA's PMIP module 2151 Figure 15: Proxy Binding Update 2153 | PBA on wire : PBA internal processing 2154 \|/ \:/ 2156 LMA's PMIP module 2157 : 2158 : IPv6 header (src=LMAA, dst=Proxy-CoA) 2159 : Mobility header 2160 : PBA (p flag) 2161 : Home Network Prefix option 2162 : IPv4 Home Address Reply option 2163 : IPv4 Care-of Address option 2164 \:/ 2165 LMA's IPsec module 2166 : 2167 : IPv6 header (src=LMAA, dst=Proxy-CoA) 2168 : ESP header in transport mode 2169 : Mobility header 2170 : PBA (p flag) 2171 : Home Network Prefix option 2172 : IPv4 Home Address Reply option 2173 : IPv4 Care-of Address option 2174 : 2175 : * After adding the ESP header, the PBA is returned to the PMIP 2176 : module and is encapsulated into the UDP and IPv4 headers. 2177 : This requires a Proxy Mobile IPv6 specific IPsec implementation, 2178 : which knows that the packet needs to be passed back to the PMIP 2179 : module, instead of sending it out via normal forwarding 2180 \:/ 2181 LMA 2182 | IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) 2183 | UDP header (sport=DSMIPv6, dport=Z) 2184 | IPv6 header (src=LMAA, dst=Proxy-CoA) 2185 | ESP header in transport mode 2186 | Mobility header 2187 | PBA (p flag) 2188 | Home Network Prefix option 2189 | IPv4 Home Address Reply option 2190 | IPv4 Care-of Address option 2191 \|/ 2192 MAG (received at DSMIPv6 listening port) 2193 : 2194 : IPv6 header (src=LMAA, dst=Proxy-CoA) 2195 : ESP header in transport mode 2196 : Mobility header 2197 : PBA (p flag) 2198 : Home Network Prefix option 2199 : IPv4 Home Address Reply option 2200 : IPv4 Care-of Address option 2201 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2202 : be passed with the packet to ensure correct processing. 2203 \:/ 2204 MAG's IPsec module 2205 : 2206 : IPv6 header (src=LMAA, dst=Proxy-CoA) 2207 : Mobility header 2208 : PBA (p flag) 2209 : Home Network Prefix option 2210 : IPv4 Home Address Reply option 2211 : IPv4 Care-of Address option 2212 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2213 : be passed with the packet to ensure correct processing. 2214 \:/ 2215 MAG's PMIP module 2217 Figure 16: Proxy Binding Acknowledgement 2219 4.3.2. Payload Packet 2221 The following are the SPD example entries to protect payload packets 2222 on the local mobility anchor and mobile access gateway. Note that 2223 the example SPDs protect all payload packets sent to and from mobile 2224 nodes. If an operator needs to apply a different security mechanism 2225 per mobile node, they need to create a SPD and a SA entry per mobile 2226 node. 2228 MAG SPD-S: 2229 - IF interface = IPv6 tunnel to LMAA_1 & 2230 local_address != Proxy-CoA_1 & 2231 remote_address != LMAA_1 & proto=any 2232 Then use SA ESP tunnel mode 2234 LMA SPD-S: 2235 - IF interface = IPv6 tunnel to Proxy-CoA_1 & 2236 local_address != LMAA_1 & 2237 remote_address != Proxy-CoA_1 & proto=any 2238 Then use SA ESP tunnel mode 2240 When a payload packet is protected by IPsec, MAG and LMA SHOULD 2241 always use the tunnel IPv6 header to let the payload packet be IPsec 2242 protected in the ESP tunnel mode. If IPsec is not applied to payload 2243 packets, this additional tunnel IPv6 header SHOULD be omitted and an 2244 IPv4 header SHOULD be used to encapsulate the data packet as shown in 2245 Figure 14 . 2247 | Packet on wire : Packet internal processing 2249 \|/ \:/ 2251 MN 2252 | IPv4/v6 header (src= MN-HoA, dst= CN) 2253 | Payload 2254 \|/ 2255 MAG's PMIP Module 2256 :3 2257 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2258 : IPv4/v6 header (src= MN-HoA, dst= CN) 2259 : Payload 2260 : 2261 \:/ 2262 MAG's IPsec module 2263 : 2264 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2265 : ESP header in tunnel mode 2266 : IPv4/v6 header (src= MN-HoA, dst= CN) 2267 : Payload 2268 : 2269 : * After the ESP header installation, the payload packet is returned 2270 : to the PMIP module and is encapsulated for the tunnel between MAG 2271 : and LMA. If necessary, the UDP and TLV headers are added to the 2272 : payload packet. 2273 : This requires a Proxy Mobile IPv6 specific IPsec implementation, 2274 : which knows that the packet needs to be passed back to the PMIP 2275 : module, instead of sending it out via normal forwarding 2276 \:/ 2277 MAG 2278 | 2279 | IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 2280 | UDP header (sport=Z, dport=DSMIPv6) /* If UDP encap nego */ 2281 | TLV Header /* If TLV negotiated */ 2282 | IPv6 header (src=Proxy-CoA, dst=LMAA) 2283 | ESP header in tunnel mode 2284 : IPv4/v6 header (src= MN-HoA, dst= CN) 2285 | Payload 2286 \|/ 2287 LMA (received at DSMIPv6 port) 2288 : 2289 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2290 : ESP header in tunnel mode 2291 : IPv4/v6 header (src= MN-HoA, dst= CN) 2292 : Payload 2293 : 2294 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2295 : be passed with the packet to ensure correct processing. 2296 \:/ 2297 LMA's IPsec module 2298 : 2299 : IPv6 header (src=Proxy-CoA, dst=LMAA) 2300 : IPv4/v6 header (src= MN-HoA, dst= CN) 2301 : Payload 2302 : 2303 : *In addition, IPv4-Proxy-CoA and the sport (Z) need to 2304 : be passed with the packet to ensure correct processing. 2305 \:/ 2306 LMA forwarding engine 2308 Figure 17: IPsec Protected Payload Packet 2310 5. Protocol Configuration Variables 2312 5.1. Local Mobility Anchor - Configuration Variables 2314 The local mobility anchor MUST allow the following variables to be 2315 configured by the system management. The configured values for these 2316 protocol variables MUST survive server reboots and service restarts. 2318 AcceptForcedIPv4UDPEncapsulationRequest 2320 This flag indicates whether or not the local mobility anchor 2321 should accept IPv4 UDP encapsulation request for the mobile node's 2322 data traffic, even if there is no NAT detected in the path. 2324 The default value for this flag is set to (0), indicating that the 2325 local mobility anchor MUST NOT accept IPv4 UDP encapsulation 2326 request when NAT is not detected in the path. 2328 When the value for this flag is set to (1), the local mobility 2329 anchor MUST accept IPv4 UDP encapsulation request even when NAT is 2330 not detected in the path. 2332 5.2. Mobile Access Gateway - Configuration Variables 2334 The mobile access gateway MUST allow the following variables to be 2335 configured by the system management. The configured values for these 2336 protocol variables MUST survive server reboots and service restarts. 2338 UseIPv4UDPEncapForSignalingMessages 2340 This flag indicates whether or not the mobile access gateway 2341 should use IPv4-UDP encapsulation mode for the signaling messages. 2343 The default value for this flag is set to (0), indicating that the 2344 mobile access gateway MUST NOT use IPv4-UDP encapsulation mode, 2345 but MUST use native IPv4 encapsulation mode for sending the Proxy 2346 Mobile IPv6 signaling messages. 2348 When the value for this flag is set to (1), the mobile access 2349 gateway MUST use IPv4-UDP encapsulation mode for sending the Proxy 2350 Mobile IPv6 signaling messages. 2352 ForceIPv4UDPEncapsulationSupport 2353 This flag indicates whether or not the mobile access gateway 2354 should request the mobile node's local mobility anchor for forcing 2355 IPv4 UDP encapsulation support for the mobile node's data traffic, 2356 even when NAT is not detected in the path. 2358 The default value for this flag is set to (0), indicating that the 2359 mobile access gateway MUST NOT request the mobile node's local 2360 mobility anchor for forcing IPv4 UDP encapsulation support even 2361 when NAT is not detected in path. 2363 When the value for this flag is set to (1), the mobile access 2364 gateway MUST force the mobile node's local mobility anchor for 2365 IPv4 UDP encapsulation support. 2367 This flag is applicable only when the flag 2368 UseIPv4UDPEncapForSignalingMessages is set to a value of (1). 2370 6. IANA Considerations 2372 This document defines four new Mobility Header options, IPv4 Home 2373 Address Request option, IPv4 Home Address Reply option, IPv4 Default 2374 Router Address option and IPv4 DHCP Support Mode option. These 2375 options are described in Sections 3.3.1, 3.3.2, 3.3.3 and 3.3.4 2376 respectively. The Type value for these options needs to be assigned 2377 from the same number space as allocated for the other mobility 2378 options, as defined in [RFC-3775]. 2380 The IPv4 Home Address Reply option, described in Section 3.3.2 of 2381 this document, introduces a new number space, IPv4 Home Address Reply 2382 Status Codes. This document currently reserves the following values. 2383 Approval of any new status code values are to be made through IANA 2384 Expert Review. 2386 o 0 Success 2388 o 128 Failure, reason unspecified 2390 o 129 Administratively prohibited 2392 o 130 Incorrect IPv4 home address 2394 o 131 Invalid IPv4 address 2396 o 132 Dynamic IPv4 home address assignment not available 2398 The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this 2399 document, introduces a new number space, IPv4 DHCP Support Mode 2400 Flags. This document reserves the value 0x1 for the (S) flag. 2401 Approval of this flag values are to be made through IANA Expert 2402 Review. At this point of time there are no thoughts on what the new 2403 flag allocations can be for and hence this document is leaving this 2404 to the discretion of the expert review. 2406 This document also defines new status values, used in Proxy Binding 2407 Acknowledgement message, as described in Section 3.3.5. These values 2408 are to be assigned from the same number space as allocated for other 2409 Status codes [RFC-3775]. Each of these allocated values have to be 2410 greater than 128. 2412 NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: IANA 2414 Mobile node not authorized for IPv4 mobility service. 2416 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 2418 Mobile node not authorized for the requesting IPv4 home address 2420 NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: IANA 2422 Mobile node not authorized for IPv6 mobility service. 2424 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: IANA 2426 Multiple IPv4 home address assignment not supported 2428 7. Security Considerations 2430 All the security considerations from the base Proxy Mobile IPv6 [RFC- 2431 5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6 [RFC-5555] 2432 apply when using the extensions defined in this document. 2433 Additionally, the following security considerations need to be 2434 applied. 2436 This document defines new mobility options for supporting the IPv4 2437 Home Address assignment and IPv4 Transport Support features. These 2438 options are to be carried in Proxy Binding Update and Proxy Binding 2439 Acknowledgement messages. The required security mechanisms specified 2440 in the base Proxy Mobile IPv6 protocol for protecting these signaling 2441 messages are sufficient when carrying these mobility options. 2443 This specification describes the use of IPv4 transport for exchanging 2444 the signaling messages between the local mobility anchor and the 2445 mobile access gateway. These signaling messages are fundamentally 2446 IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4 2447 packets. The encapsulated inner IPv6 message is still protected 2448 using IPsec, using the established security association and this 2449 offers the same level of security as when the messages are routed 2450 natively as IPv6 packets. The use of outer IPv4 header does not 2451 introduce any new security vulnerabilities. 2453 8. Contributors 2455 This document reflects discussions and contributions from several 2456 people (in alphabetical order): 2458 Kuntal Chowdhury 2460 kchowdhury@starentnetworks.com 2462 Vijay Devarapalli 2464 vijay.devarapalli@azairenet.com 2466 Sangjin Jeong 2468 sjjeong@etri.re.kr 2470 Basavaraj Patil 2472 basavaraj.patil@nsn.com 2474 Myungki Shin 2476 myungki.shin@gmail.com 2478 9. Acknowledgments 2480 The IPv4 support for Proxy Mobile IPv6 was initially covered in the 2481 internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like 2482 to thank all the authors of the document and acknowledge that initial 2483 work. 2485 Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles 2486 Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen, 2487 Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen, 2488 Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe 2489 Wu and Zu Qiang for their helpful review of this document. 2491 Also, we would like to thank Spencer Dawkins, Tim Polk and Menachem 2492 Dodge, Adrian Farrel and Pekka Savola for their reviews of this 2493 document as part of the IESG review process. 2495 10. References 2496 10.1. Normative References 2498 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 2499 Requirement Levels", BCP 14, RFC 2119, March 1997. 2501 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2502 2131, March 1997. 2504 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2505 IPv6 Specification", RFC 2473, December 1998. 2507 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 2508 IPv6", RFC 3775, June 2004. 2510 [RFC-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast 2511 Addresses", RFC-4193, October 2005. 2513 [RFC-4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms 2514 for IPv6 Hosts and Routers", RFC 4213, October 2005. 2516 [RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing 2517 Architecture", RFC-4291, February 2006. 2519 [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, 2520 November 2007. 2522 [RFC-5555] Soliman, H. et al, "Mobile IPv6 support for dual stack 2523 Hosts and Routers (DSMIPv6)", RFC-5555, June 2009. 2525 10.2. Informative References 2527 [RFC-925] Postel, J., "Multi-LAN Address Resolution", RFC 925, 2528 October 1984. 2530 [RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol 2531 (IPCP)", RFC 1332, May 1992. 2533 [RFC-1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 2534 and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 2535 1918, February 1996. 2537 [RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor 2538 Extensions", RFC 2132, March 1997. 2540 [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2541 Address Translator (Traditional NAT)", RFC 3022, January 2001. 2543 [RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January 2544 2001. 2546 [RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 2547 Unicast Address Format", RFC 3587, August 2003. 2549 [RFC-4301] Kent, S. and K. Seo, "Security Architecture for the 2550 Internet Protocol", RFC 4301, December 2005. 2552 [RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 2553 4306, December 2005. 2555 [RFC-4361] Lemon, T. and B. Sommerfield, "Node-specific Client 2556 Identifiers for Dynamic Host Configuration Protocol Version Four 2557 (DHCPv4)", RFC 4361, February 2006. 2559 [RFC-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network 2560 Attachment in IPv4", RFC 4436, March 2006. 2562 [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack 2563 Mobility", RFC 4977, August 2007. 2565 [RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp, 2566 "DHCP Server Identifier Override Suboption", RFC 5107, February 2008. 2568 [ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K., 2569 "GRE Key Option for Proxy Mobile IPv6", 2570 draft-ietf-netlmm-grekey-option-09.txt, May 2009. 2572 Authors' Addresses 2574 Ryuji Wakikawa 2575 TOYOTA InfoTechnology Center, U.S.A., Inc. 2576 465 Bernardo Avenue 2577 Mountain View, CA 94043 2578 USA 2580 Email: ryuji@us.toyota-itc.com 2581 Sri Gundavelli 2582 Cisco 2583 170 West Tasman Drive 2584 San Jose, CA 95134 2585 USA 2587 Email: sgundave@cisco.com