idnits 2.17.1 draft-ietf-netlmm-pmip6-ipv4-support-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 12, 2010) is 5159 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: August 16, 2010 Cisco 6 February 12, 2010 8 IPv4 Support for Proxy Mobile IPv6 9 draft-ietf-netlmm-pmip6-ipv4-support-18.txt 11 Abstract 13 This document specifies extensions to Proxy Mobile IPv6 protocol for 14 adding IPv4 protocol support. The scope of IPv4 protocol support is 15 two-fold: 1) enable IPv4 home address mobility support to the mobile 16 node. 2) allow the mobility entities in the Proxy Mobile IPv6 domain 17 to exchange signaling messages over an IPv4 transport network. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 16, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 5 61 1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 6 63 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8 64 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 65 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 67 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 68 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 69 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11 70 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11 71 3.1.3. Routing Considerations for the Local Mobility 72 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 17 73 3.1.4. ECN & Payload Fragmentation Considerations . . . . . . 17 74 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 18 75 3.2.1. Extensions to Binding Update List Entry . . . . . . . 18 76 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 18 77 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19 78 3.2.4. Routing Considerations for the Mobile Access 79 Gateway . . . . . . . . . . . . . . . . . . . . . . . 22 80 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 23 81 3.3.1. IPv4 Home Address Request Option . . . . . . . . . . . 23 82 3.3.2. IPv4 Home Address Reply Option . . . . . . . . . . . . 24 83 3.3.3. IPv4 Default-Router Address Option . . . . . . . . . . 26 84 3.3.4. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 27 85 3.3.5. Status Codes . . . . . . . . . . . . . . . . . . . . . 28 86 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 29 87 3.4.1. DHCP Server co-located with the Mobile Access 88 Gateway . . . . . . . . . . . . . . . . . . . . . . . 30 89 3.4.2. DHCP Relay Agent co-located with the Mobile Access 90 Gateway . . . . . . . . . . . . . . . . . . . . . . . 33 91 3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 35 93 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 38 94 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 39 95 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 39 96 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 40 97 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 40 98 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 41 99 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 43 100 4.2.1. Extensions to Binding Update List Entry . . . . . . . 43 101 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 43 102 4.3. IPsec Considerations . . . . . . . . . . . . . . . . . . . 45 103 4.3.1. PBU and PBA . . . . . . . . . . . . . . . . . . . . . 45 104 4.3.2. Payload Packet . . . . . . . . . . . . . . . . . . . . 46 106 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 47 107 5.1. Local Mobility Anchor - Configuration Variables . . . . . 47 108 5.2. Mobile Access Gateway - Configuration Variables . . . . . 47 110 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 112 7. Security Considerations . . . . . . . . . . . . . . . . . . . 50 114 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51 116 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 118 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 119 10.1. Normative References . . . . . . . . . . . . . . . . . . . 52 120 10.2. Informative References . . . . . . . . . . . . . . . . . . 52 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53 124 1. Overview 126 The transition from IPv4 to IPv6 is a long process and during this 127 period of transition, both the protocols will be enabled over the 128 same network infrastructure. Thus, it is reasonable to assume that a 129 mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only 130 IPv6-only or in dual-stack mode and additionally the network between 131 the mobile access gateway and a local mobility anchor may be an IPv4 132 or an IPv6 network. It is also reasonable to expect the same 133 mobility infrastructure in the Proxy Mobile IPv6 domain to provide 134 mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode 135 and whether the transport network is IPv4 or IPv6 network. The 136 motivation and scope of IPv4 support in Mobile IPv6 is summarized in 137 [RFC4977] and all those requirements apply to Proxy Mobile IPv6 138 protocol as well. 140 The Proxy Mobile IPv6 protocol [RFC5213] specifies a mechanism for 141 providing IPv6 home address mobility support to a mobile node in a 142 Proxy Mobile IPv6 domain. The protocol requires IPv6 transport 143 network between the mobility entities. The extensions defined in 144 this document extends IPv4 support to the Proxy Mobile IPv6 protocol 145 [RFC5213]. 147 The scope of IPv4 support in Proxy Mobile IPv6 includes the support 148 for the following two features: 150 o IPv4 Home Address Mobility Support: A mobile node which is dual- 151 stack or IPv4-only enabled will be able to obtain an IPv4 address 152 and be able to use that address from any of the access networks in 153 that Proxy Mobile IPv6 domain. The mobile node is not required to 154 be allocated or assigned an IPv6 address to enable IPv4 home 155 address support. 157 o IPv4 Transport Network Support: The mobility entities in the Proxy 158 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 159 signaling messages over an IPv4 transport. 161 These two features, the IPv4 Home Address Mobility support and the 162 IPv4 transport support features, are independent of each other and 163 deployments may choose to enable any one or both of these features as 164 required. 166 Figure 1 shows a typical Proxy Mobile IPv6 domain with IPv4 transport 167 network and with IPv4 enabled mobile nodes. The terms used in this 168 illustration are explained in the Terminology section. 170 +----+ +----+ 171 |LMA1| |LMA2| 172 +----+ +----+ 173 IPv4-LMAA -> | IPv4-LMAA-> | <-- LMAA 174 | | 175 \\ //\\ 176 \\ // \\ 177 \\ // \\ 178 +---\\------------- //------\\----+ 179 ( \\ IPv4/IPv6 // \\ ) 180 ( \\ Network // \\ ) 181 +------\\--------//------------\\-+ 182 \\ // \\ 183 \\ // \\ 184 \\ // \\ 185 IPv4-Proxy-CoA --> | | <-- Proxy-CoA 186 +----+ +----+ 187 |MAG1|-----{MN2} |MAG2| 188 +----+ | +----+ 189 (MN-HoA) | | | <-- (MN-HoA) 190 (IPv4-MN-HoA) --> | (IPv4-MN-HoA) | <-- (IPv4-MN-HoA) 191 {MN1} {MN3} 193 Figure 1: IPv4 support for Proxy Mobile IPv6 195 1.1. Stated Assumptions 197 The following are the system and configuration requirements from the 198 mobility entities in the Proxy Mobile IPv6 domain for supporting the 199 extensions defined in this document. 201 o Both the mobility entities, the local mobility anchor and the 202 mobile access gateway are dual stack (IPv4/IPv6) enabled. 203 Irrespective of the type of transport network (IPv4 or IPv6) 204 separating these two entities, the mobility signaling is always 205 based on Proxy Mobile IPv6 [RFC5213]. 207 o A deployment where a mobile access gateway uses an IPv4 private 208 address with NAT [RFC3022] translation devices in path to a local 209 mobility anchor is not supported by this specification. 211 o The mobile node can be operating in IPv4-only, IPv6-only or in 212 dual mode. Based on what is enabled for a mobile node, it should 213 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 214 address(es) for its interface and furthermore achieve mobility 215 support for those addresses. 217 o For enabling IPv4 home address mobility support to a mobile node, 218 it is not required that the IPv6 home address mobility support 219 needs to enabled. However, the respective protocol(s) support, 220 such as IPv4 or IPv6 packet forwarding, must be enabled on the 221 access link between the mobile node and the mobile access gateway. 223 o The mobile node can obtain an IPv4 address for its attached 224 interface. Based on the type of link, it may be able to acquire 225 its IPv4 address configuration using standard IPv4 address 226 configuration mechanisms such as DHCP [RFC2131], IPCP [RFC1332], 227 IKEv2 [RFC4306] or static address configuration. However, the 228 details on how IPCP or IKEv2 can be used for address delivery is 229 outside the scope of this document. 231 o The mobile node's IPv4 home subnet is typically a shared address 232 space. It is not for the exclusive use of any one mobile node. 233 There can be multiple mobile nodes that are assigned IPv4 234 addresses from the same subnet. 236 o The mobile access gateway is the IPv4 default router for the 237 mobile node on its access link. It will be in the forwarding path 238 for the mobile node's data traffic. Additionally, as specified in 239 section 6.9.3 of [RFC5213], all the mobile access gateways in the 240 Proxy Mobile IPv6 domain MUST use the same link-layer address on 241 any of the access links wherever the mobile node attaches. 243 1.2. Relevance to Dual-Stack Mobile IPv6 245 IPv4 support for Mobile IPv6 is specified in Dual-Stack Mobile IPv6 246 specification [RFC5555]. This document leverages some of the 247 approaches, messaging options and processing logic defined in that 248 document for extending IPv4 support to Proxy Mobile IPv6, except with 249 deviation in some aspects for obvious reasons of supporting a 250 network-based mobility model. Following are some of the related 251 considerations. 253 o The Binding Update flag 'F' and the NAT Detection Option defined 254 in Sections 3.1.3 and 3.2.2 of [RFC5555] are used by this 255 specification in Proxy Binding Update and Proxy Binding 256 Acknowledgement messages. Their sole purpose is to allow forcing 257 of UDP encapsulation between a mobile access gateway and a local 258 mobility anchor in situations similar to those discussed in 259 Sections 4.1 and 4.4.1 of [RFC5555]. 261 o The extensions needed to the conceptual data structures, Binding 262 Cache entry and Binding Update List entry, for storing the state 263 related to the IPv4 support defined in [RFC5555], will all be 264 needed and relevant for this document. 266 o In Mobile IPv6 [RFC3775] and in Dual-Stack Mobile IPv6 [RFC5555], 267 IPsec security associations (SAs) are specific to a single mobile 268 node; they use the identifier visible to upper-layer protocols 269 (HoA/IPv4-HoA) as traffic selector; and the IKE/IPsec SAs need to 270 be updated when the mobile node moves. 272 In Proxy Mobile IPv6 (both [RFC5213] and this document), the IPsec 273 SAs are specific to mobile access gateway (and used for 274 potentially large number of mobile nodes); they use the locators 275 used for routing (Proxy-CoA/IPv4-Proxy-CoA) as traffic selector; 276 and they are not updated when the mobile node moves. 278 This means the IPsec processing for Mobile IPv6 and Proxy Mobile 279 IPv6 (whether IPv6 only or dual-stack) is very different. 281 o The tunneling considerations specified in [RFC5555] for supporting 282 IPv4 transport is relevant for this document as well. 284 2. Conventions & Terminology 286 2.1. Conventions 288 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 289 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 290 document are to be interpreted as described in RFC 2119 [RFC2119]. 292 2.2. Terminology 294 All the mobility related terms used in this document are to be 295 interpreted as defined in the Mobile IPv6 specification [RFC3775] and 296 Proxy Mobile IPv6 specification [RFC5213]. In addition this document 297 introduces the following terms. 299 IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) 301 The IPv4 address that is configured on the egress-interface of the 302 mobile access gateway. When using IPv4 transport, this address 303 will be the registered care-of address in the mobile node's 304 Binding Cache entry and will also be the transport-endpoint of the 305 tunnel between the local mobility anchor and a mobile access 306 gateway. 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 329 A procedure for partial de-registration of all the addresses that 330 belong to one address family, i.e. de-registration of either the 331 IPv4 home address, or one or more of the assigned IPv6 home 332 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 IPv4-or-IPv6-over-IPv4-GRE 359 IPv4 packet carried as a payload in an IPv4 packet with GRE 360 header (but no UDP or TLV header) 362 3. IPv4 Home Address Mobility Support 364 The IPv4 home address mobility support essentially enables a mobile 365 node in a Proxy Mobile IPv6 domain to obtain IPv4 home address 366 configuration for its attached interfaces and be able to retain that 367 address configuration even after performing an handoff anywhere 368 within that Proxy Mobile IPv6 domain. This section describes the 369 protocol operation and the required extensions to Proxy Mobile IPv6 370 protocol for extending IPv4 home address mobility support. 372 When an IPv4-enabled or a dual-stack enabled mobile node attaches to 373 the Proxy Mobile IPv6 domain, the mobile access gateway on the access 374 link where the mobile node is attached will identify the mobile node 375 and will initiate the Proxy Mobile IPv6 signaling with the mobile 376 node's local mobility anchor. The mobile access gateway will follow 377 the signaling considerations specified in Section 3.2 for requesting 378 IPv4 home address mobility support. Upon the completion of the 379 signaling, the local mobility anchor and the mobile access gateway 380 will establish the required routing states for allowing the mobile 381 node to use its IPv4 home address from its current point of 382 attachment. 384 The mobile node on the access link using any of the standard IPv4 385 address configuration mechanisms supported on that access link, such 386 as IPCP [RFC1332], IKEv2 [RFC4306] or DHCP [RFC2131], will be able to 387 obtain an IPv4 home address (IPv4-MN-HoA) for its attached interface. 388 Although the address configuration mechanisms for delivering the 389 address configuration to the mobile node is independent of the Proxy 390 Mobile IPv6 protocol operation, however there needs to be some 391 interactions between these two protocol flows. Section 3.4 392 identifies these interactions for supporting DHCP based address 393 configuration. 395 The support for IPv4 home address mobility is not dependent on the 396 IPv6 home address mobility support. It is not required that the IPv6 397 home address mobility support needs to be enabled for providing IPv4 398 home address mobility support. A mobile node will be able to obtain 399 IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its 400 attached interface. The mobile node's policy profile will determine 401 if the mobile node is entitled for both the protocol versions or a 402 single protocol version. Based on the policy, only those protocols 403 will be enabled on the access link. Furthermore, if the mobile node 404 after obtaining the address configuration on its interface performs 405 an handoff, either by changing its point of attachment over the same 406 interface or to a different interface, the network will ensure the 407 mobile node will be able to use the same IPv4 address configuration 408 after the handoff. 410 Additionally, If the mobile node connects to the Proxy Mobile IPv6 411 domain, through multiple interfaces and simultaneously through 412 different access networks, each of the connected interfaces will 413 obtain an IPv4 home address from different subnets. In such 414 scenario, there will be multiple Binding Cache entries for the mobile 415 node on the local mobility anchor. All the address (IPv4/IPv6) 416 assigned to a given interface will be managed as part of one mobility 417 session, as specified in Section 5.4 of [RFC5213]. 419 3.1. Local Mobility Anchor Considerations 421 3.1.1. Extensions to Binding Cache Entry 423 To support this feature, the conceptual Binding Cache entry data 424 structure maintained by the local mobility anchor needs to include 425 the following parameters. 427 o The IPv4 home address assigned to the mobile node's interface and 428 registered by the mobile access gateway. The IPv4 home address 429 entry also includes the corresponding subnet mask. It is to be 430 noted that this parameter is defined in the [RFC5555] and is 431 presented here for completeness. 433 o The IPv4 default router address assigned to the mobile node. 435 3.1.2. Signaling Considerations 437 3.1.2.1. Processing Proxy Binding Updates 439 The processing rules specified in Section 5.3 of [RFC5213] are 440 applied for processing the received Proxy Binding Update message. 441 However, if the received Proxy Binding Update message has an IPv4 442 Home Address Request option, the following considerations MUST be 443 applied additionally. 445 o If there is an IPv4 Home Address Request option present in the 446 received Proxy Binding Update message, but no Home Network Prefix 447 option [RFC5213] present in the received Proxy Binding Update 448 message, the local mobility anchor MUST NOT reject the request as 449 specified in Section 5.3.1 of [RFC5213]. At least one instance of 450 any of these two options, either the IPv4 Home Address Request 451 option or the Home Network Prefix option, MUST be present. If 452 there is not a single instance of any of these two options present 453 in the request, the local mobility anchor MUST reject the request 454 and send a Proxy Binding Acknowledgement message with Status field 455 set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's 456 home network prefix option) [RFC5213]. 458 o If there is at least one instance of Home Network Prefix option 459 [RFC5213] present in the received Proxy Binding Update message, 460 but it is known from the mobile node's policy profile that the 461 mobile node is not authorized for IPv6 service, or IPv6 routing in 462 not enabled in the home network, the local mobility anchor MUST 463 reject the request and send a Proxy Binding Acknowledgement 464 message with the Status field set to 465 NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not 466 authorized for IPv6 mobility service). 468 o If there is an IPv4 Home Address Request option present in the 469 received Proxy Binding Update message, but it is known from the 470 mobile node's policy profile that the mobile node is not 471 authorized for IPv4 service, or if IPv4 routing not enabled in the 472 home network, the local mobility anchor MUST reject the request 473 and send a Proxy Binding Acknowledgement message with the Status 474 field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (mobile node 475 not authorized for IPv4 mobility service). 477 o If there are more than one instance of the IPv4 Home Address 478 Request option present in the request, then the local mobility 479 anchor MUST reject the request and send a Proxy Binding 480 Acknowledgement message with the Status field set to 481 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 482 home address assignment not supported). 484 o For associating the received Proxy Binding Update message to an 485 existing mobility session, the local mobility anchor MUST perform 486 the Binding Cache entry existence test by applying the following 487 considerations. 489 * If there is at least one instance of the Home Network Prefix 490 option [RFC5213] with a NON_ZERO prefix value, or, if there is 491 an IPv4 Home Address Request option with the IPv4 address in 492 the option set to ALL_ZERO, considerations from Section 5.4.1 493 of [RFC5213] MUST be applied. 495 * If there is an IPv4 Home Address Request option present in the 496 request with the IPv4 address value in the option set to a 497 NON_ZERO value, considerations from Section 3.1.2.7 MUST be 498 applied. 500 o If there is no existing Binding Cache entry that can be associated 501 with the request, the local mobility anchor MUST consider this 502 request as an initial binding registration request and 503 considerations from Section 3.1.2.2 MUST be applied. 504 Additionally, if there are one or more Home Network Prefix options 505 [RFC5213] present in the request, considerations from Section 506 5.3.2 of [RFC5213] MUST also be applied. 508 o If there exists a Binding Cache entry that can be associated with 509 the request, the local mobility anchor MUST apply considerations 510 from Section 5.3.1 of [RFC5213], (point 13), to determine if the 511 request is re-registration or a de-registration request. If the 512 request is a re-registration request, considerations from Section 513 3.1.2.3 MUST be applied and if it is a de-registration request, 514 considerations from Section 3.1.2.5 MUST be applied. 516 o If there exists a Binding Cache entry that can be associated with 517 the request and if it is determined that the request is a re- 518 registration request for extending IPv4 home address mobility 519 support to the existing IPv6-only mobility session, considerations 520 from Section 3.1.2.2 MUST be applied with respect to IPv4 support. 522 3.1.2.2. Initial Binding Registration (New Mobility Session) 524 o If there is an IPv4 Home Address Request option present in the 525 Proxy Binding Update message with the IPv4 address value in the 526 option set to ALL_ZERO, the local mobility anchor MUST allocate an 527 IPv4 home address to the mobile node and associate it with the new 528 mobility session created for that mobile node. 530 o If there is an IPv4 Home Address Request option with the IPv4 531 address in the option set to a NON_ZERO value, the local mobility 532 anchor before accepting the request MUST ensure the address is 533 topologically anchored on the local mobility anchor and 534 furthermore the mobile node is authorized to use that address. If 535 the mobile node is not authorized for that specific address, the 536 local mobility anchor MUST reject the request and send a Proxy 537 Binding Acknowledgement message with the Status field set to 538 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized 539 for the requesting IPv4 address). It MUST also include the IPv4 540 Home Address Reply option in the reply with the status field value 541 in the option set to 129 (Administratively prohibited). 543 o If the local mobility anchor is unable to allocate an IPv4 address 544 due to lack of resources, it MUST reject the request and send a 545 Proxy Binding Acknowledgement message with Status field set to 130 546 (Insufficient resources). It MUST also include the IPv4 Home 547 Address Reply option in the reply with the status field value in 548 the option set to 128 (Failure, reason unspecified). 550 o Upon accepting the request, the local mobility anchor MUST create 551 a Binding Cache entry for this mobility session. However, if the 552 request also contains one or more Home Network Prefix options 553 [RFC5213], there should still be only one Binding Cache entry that 554 should be created for this mobility session. The created Binding 555 Cache entry MUST be used for managing both IPv4 and IPv6 home 556 address bindings. The fields in the Binding Cache entry MUST be 557 updated with the accepted values for that session. 559 o The local mobility anchor MUST establish a bi-directional tunnel 560 to the mobile access gateway with the encapsulation mode set to 561 the negotiated mode for carrying the IPv4 payload traffic. When 562 using IPv6 transport, the encapsulation mode is IPv4-or-IPv6-over- 563 IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 packet). 564 When using IPv4 transport, the encapsulation mode is as specified 565 in Section 4. 567 o The local mobility anchor MUST create an IPv4 host route (or a 568 platform specific equivalent function that sets up the forwarding) 569 for tunneling the packets received for the mobile node's home 570 address associated with this mobility session. 572 o The local mobility anchor MUST send the Proxy Binding 573 Acknowledgement message with the Status field set to 0 (Proxy 574 Binding Update Accepted). The message MUST be constructed as 575 specified in Section 3.1.2.6. 577 3.1.2.3. Binding Lifetime Extension (No handoff) 579 All the considerations from Section 5.3.3 of [RFC5213] MUST be 580 applied. 582 3.1.2.4. Binding Lifetime Extension (After handoff) 584 o If there is no Home Network Prefix option(s) [RFC5213] present in 585 the request, but if the Binding Cache entry associated with this 586 request has IPv6 home network prefix(es), the local mobility 587 anchor MUST consider this as a request to extend lifetime only for 588 the IPv4 home address and not for the IPv6 home network 589 prefix(es). Hence, the local mobility anchor SHOULD release all 590 the IPv6 home network prefix(es) assigned to that mobile node and 591 for that specific attached interface. Similar considerations 592 apply for the case where there is no IPv4 Home Address Request 593 option present in the request, but if the Binding Cache entry 594 associated with that request has both IPv4 home address and IPv6 595 home network prefix(es). 597 o The local mobility anchor MUST remove the previously created IPv4 598 host route (or the forwarding state) and the dynamically created 599 bi-directional tunnel for carrying the IPv4 payload traffic (if 600 there are no other mobile nodes for which the tunnel is being 601 used). This will remove the routing state towards the mobile 602 access gateway where the mobile node was anchored prior to the 603 handoff. 605 o The local mobility anchor MUST create a bi-directional tunnel to 606 the mobile access gateway that sent the request (if there is no 607 existing bi-directional tunnel) and with the encapsulation mode 608 set to the negotiated mode for carrying the IPv4 payload traffic. 609 An IPv4 host route for tunneling the packets received for the 610 mobile node's IPv4 home address MUST also be added. 612 o The required forwarding state identified in Section 5.3.6 of 613 [RFC5213] is for IPv6 payload traffic. Those considerations apply 614 for IPv4 payload traffic as well. However, if IPv4 transport is 615 in use, considerations from Section 4 MUST be applied. 617 3.1.2.5. Binding De-Registration 619 All the considerations from Section 5.3.5 of [RFC5213] MUST be 620 applied. Additionally, for removing the IPv4 state as part of the 621 Binding Cache entry deletion, the IPv4 host route and the dynamically 622 created bi-directional tunnel for carrying the IPv4 payload traffic 623 (if there are no other mobile nodes for which the tunnel is being 624 used) MUST be removed. However, if the request is for a selective 625 de-registration (IPv4 home address only, or all the IPv6 home network 626 prefixes), the Binding Cache entry MUST NOT be deleted, only the 627 respective states with respect to those addresses MUST be deleted. 629 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 631 The local mobility anchor when sending the Proxy Binding 632 Acknowledgement message to the mobile access gateway MUST construct 633 the message as specified in Section 5.3.6 of [RFC5213]. 634 Additionally, the following considerations MUST be applied. 636 o Section 5.3.6 of [RFC5213] requires the local mobility anchor to 637 include at least one instance of Home Network Prefix option 638 [RFC5213] in the Proxy Binding Acknowledgement message that it 639 sends to the mobile access gateway. However, if the received 640 Proxy Binding Update message has only the IPv4 Home Address 641 Request option and did not contain the Home Network Prefix 642 option(s), then the local mobility anchor MUST NOT include any 643 Home Network Prefix option(s) in the reply. However, there MUST 644 be at least one instance of either the Home Network Prefix option 645 [RFC5213] or the IPv4 Home Address Reply option present in the 646 Proxy Binding Acknowledgement message. 648 o The IPv4 Home Address Reply option MUST be present in the Proxy 649 Binding Acknowledgement message. 651 1. If the Status field is set to a value greater than or equal to 652 (128), i.e., if the Proxy Binding Update is rejected, then 653 there MUST be an IPv4 Home Address Reply option corresponding 654 to the IPv4 Home Address Request option present in the request 655 and with the IPv4 address value and the prefix length fields 656 in the option set to the corresponding values in the request. 657 The status field value in the option must be set to the 658 specific error code. 660 2. For all other cases, there MUST be an IPv4 Home Address Reply 661 option for carrying the IPv4 home address assigned for that 662 mobility session and with the value in the option set to the 663 allocated IPv4 address. The prefix length in the option MUST 664 be set to the prefix length of the allocated address. The 665 status field value in the option must be set to 0 (Success). 667 o The IPv4 Default-Router Address option MUST be present, if the 668 Status field value in the Proxy Binding Acknowledgement message is 669 set to 0 (Proxy Binding Update Accepted). Otherwise, the option 670 MUST NOT be present. If the option is present, the default router 671 address in the option MUST be set to the mobile node's default 672 router address. 674 3.1.2.7. Binding Cache Entry Lookup Considerations 676 The Binding Cache entry lookup considerations specified in section 677 5.4.1.1 of [RFC5213] uses the Home Network Prefix option [RFC5213] as 678 the key parameter for identifying the Binding Cache entry. However, 679 when there is not a single Home Network Prefix option with a NON_ZERO 680 value present in the request, but if there is an IPv4 Home Address 681 option with a NON_ZERO value present in the request, then the 682 following considerations MUST be applied. 684 o The search rules specified in section 5.4.1.1 of [RFC5213], which 685 primarily uses IPv6 home network prefix set as the search key, are 686 equally valid when using a single IPv4 home address as the key. 687 When applying those considerations, instead of the IPv6 home 688 network prefix(es), the IPv4 home address from the IPv4 Home 689 Address option present in the request MUST be used as the search 690 key. 692 o The rules specified in section 5.4.1.1 of [RFC5213], assume the 693 presence of one or more IPv6 home network prefixes in the received 694 request and also in the Binding Cache entry. But, when using the 695 IPv4 home address as the search key, these considerations MUST 696 always assume just one single IPv4 home address, both in the 697 request and also in the Binding Cache entry. 699 3.1.3. Routing Considerations for the Local Mobility Anchor 701 Intercepting Packets Sent to the Mobile Node's IPv4 home address: 703 o When the local mobility anchor is serving a mobile node, it MUST 704 advertise a connected route into the Routing Infrastructure for 705 the mobile node's IPv4 home address or for its home subnet, in 706 order to receive packets that are sent to the mobile node's IPv4 707 home address. This essentially enables IPv4 routers in that 708 network to detect the local mobility anchor as the last-hop router 709 for that subnet. 711 Forwarding Packets to the Mobile Node: 713 o On receiving a packet from a correspondent node with the 714 destination address matching the mobile node's IPv4 home address, 715 the local mobility anchor MUST forward the packet through the bi- 716 directional tunnel setup for that mobile node. 718 o The format of the tunneled packet when payload protection is not 719 enabled: 721 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 722 IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ 723 Upper layer protocols /* Packet Content*/ 725 Figure 2: Tunneled Packets from LMA to MAG 727 Forwarding Packets Sent by the Mobile Node: 729 o All the reverse tunneled packets that the local mobility anchor 730 receives from the mobile access gateway, after removing the tunnel 731 header MUST be routed to the destination specified in the inner 732 IPv4 packet header. These routed packets will have the source 733 address field set to the mobile node's IPv4 home address. 735 3.1.4. ECN & Payload Fragmentation Considerations 737 The ECN considerations specified in Section 5.6.3 of [RFC5213] apply 738 for the IPv4 payload packets as well. The mobility agents at the 739 tunnel entry and exit points MUST handle ECN information as specified 740 in that document. 742 The mobility agents at the tunnel entry and exit points MUST apply 743 the IP packet fragmentation considerations as specified in section 7 744 of [RFC2473] and additionally they MUST apply the considerations 745 related to tunnel error processing and reporting as specified in 746 section 8 of [RFC2473]. 748 3.2. Mobile Access Gateway Considerations 750 3.2.1. Extensions to Binding Update List Entry 752 To support the IPv4 home address mobility feature, the conceptual 753 Binding Update List entry data structure needs to be extended with 754 the following additional fields. 756 o The IPv4 home address assigned to the mobile node's attached 757 interface. This IPv4 home address may have been statically 758 configured in the mobile node's policy profile, or, may have been 759 dynamically allocated by the local mobility anchor. The IPv4 home 760 address entry also includes the corresponding subnet mask. 762 o The IPv4 default router address of the mobile node. This is 763 acquired from the mobile node's local mobility anchor through the 764 received Proxy Binding Acknowledgment message. 766 3.2.2. Extensions to Mobile Node's Policy Profile 768 To support the IPv4 Home Address Mobility Support feature the mobile 769 node's policy profile, specified in Section 6.2 of [RFC5213] MUST be 770 extended with the following additional fields. 772 Extensions to the mandatory section of the policy profile: 774 o This field identifies all the IP protocol versions for which the 775 home address mobility support needs to be extended to the mobile 776 node. The supported modes are IPv4-only, IPv6-only and dual IPv4/ 777 IPv6. 779 Extensions to the optional section of the policy profile: 781 o The IPv4 home address assigned to the mobile node's attached 782 interface. The specific details on how the network maintains the 783 association between the address and the attached interface is 784 outside the scope of this document. This address field also 785 includes the corresponding subnet mask. 787 3.2.3. Signaling Considerations 789 3.2.3.1. Mobile Node Attachment and Initial Binding Registration 791 After detecting a new mobile node on its access link, the mobile 792 access gateway on the access link MUST determine if IPv4 home address 793 mobility support needs to be enabled for that mobile node. The 794 mobile node's policy profile identifies the supported modes (IPv4- 795 only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the 796 mobile service needs to be enabled. Based on those policy 797 considerations and from other triggers such as from the network, if 798 it is determined that IPv4 home address mobility support needs to be 799 enabled for the mobile node, considerations from section 6.9.1.1 of 800 [RFC5213] MUST be applied with the following exceptions. 802 o The IPv4 Home Address Request option MUST be present in the Proxy 803 Binding Update message. 805 * If the mobile access gateway learns the mobile node's IPv4 home 806 address either from its policy profile, or from other means, 807 the mobile access gateway MAY ask the local mobility anchor to 808 allocate that specific address by including exactly one 809 instance of the IPv4 Home Address Request option with the IPv4 810 home address and the prefix length fields in the option set to 811 that specific address and its prefix length. 813 * The mobile access gateway MAY also ask the local mobility 814 anchor for dynamic IPv4 home address allocation. It can 815 include exactly one instance of the IPv4 Home Address option 816 with the IPv4 home address and the prefix length fields in the 817 option set to ALL_ZERO value. Furthermore, the (P) flag in the 818 option MUST be set to 0. This serves as a request to the local 819 mobility anchor for the IPv4 home address allocation. 821 o The Proxy Binding Update message MUST be constructed as specified 822 in Section 6.9.1.5 of [RFC5213]. However, the Home Network Prefix 823 option(s) [RFC5213] MUST be present in the Proxy Binding Update 824 only if IPv6 home address mobility support also needs to be 825 enabled for the mobile node. Otherwise, the Home Network Prefix 826 option(s) MUST NOT be present. 828 o When using IPv4 transport for carrying the signaling messages, the 829 related considerations from section 4 MUST be applied 830 additionally. 832 3.2.3.2. Receiving Proxy Binding Acknowledgement 834 All the considerations from section 6.9.1.2 of [RFC5213] MUST be 835 applied with the following exceptions. 837 o If the received Proxy Binding Acknowledgement message has the 838 Status field value set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE 839 (The mobile node is not authorized for IPv4 mobility service), the 840 mobile access gateway SHOULD NOT send a Proxy Binding Update 841 message including a IPv4 Home Address Request option till an 842 administrative action is taken. 844 o If the received Proxy Binding Acknowledgement message has the 845 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 846 mobile node is not authorized for the requesting IPv4 home 847 address), the mobile access gateway SHOULD NOT request for the 848 same IPv4 address again, but MAY request the local mobility anchor 849 to perform the address assignment by including exactly one 850 instance of IPv4 Home Address Request option with the IPv4 home 851 address and the prefix length fields in the option set to ALL_ZERO 852 value. 854 o If the received Proxy Binding Acknowledgement message has the 855 Status field value set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE 856 (The mobile node is not authorized for IPv6 mobility service), the 857 mobile access gateway SHOULD NOT send a Proxy Binding Update 858 message including any Home Network Prefix option(s) till an 859 administrative action is taken. 861 o If there is no IPv4 Home Address Reply option present in the 862 received Proxy Binding Acknowledgement message, the mobile access 863 gateway MUST NOT enable IPv4 support for the mobile node and the 864 rest of the considerations from this section can be skipped. 866 o If the received Proxy Binding Acknowledgement message has the 867 Status field value in the IPv4 Home Address Reply option set to a 868 value that indicates that the request was rejected by the local 869 mobility anchor, the mobile access gateway MUST NOT enable 870 forwarding for that specific IPv4 home address. 872 o If the received Proxy Binding Acknowledgement message has the 873 Status field value set to 0 (Proxy Binding Update accepted), the 874 mobile access gateway MUST update a Binding Update List entry for 875 that mobile node. The entry MUST be updated with the assigned 876 IPv4 home address and other accepted registration values. 878 o If the received Proxy Binding Acknowledgement message has the 879 Status field value set to 0 (Proxy Binding Update accepted) and 880 has the IPv4 Home Address Reply option set to a value that 881 indicates that the request was accepted by the local mobility 882 anchor, the mobile access gateway MUST establish a bi-directional 883 tunnel to the local mobility anchor (if there is no existing bi- 884 directional tunnel to that local mobility anchor) and with the 885 encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6 886 packet carried as a payload of an IPv6 packet). Considerations 887 from Section 5.6.1 of [RFC5213] MUST be applied for managing the 888 dynamically created bi-directional tunnel. However, when using 889 IPv4 transport, the encapsulation mode MUST be set to the 890 negotiated encapsulation mode, as specified in Section 4 of this 891 specification. 893 o The mobile access gateway MUST set up the route for forwarding the 894 IPv4 packets received from the mobile node (using its IPv4 home 895 address) through the bi-directional tunnel set up for that mobile 896 node. 898 o The default router address MUST be obtained from the IPv4 Default- 899 Router Address option present in the received Proxy Binding 900 Acknowledgement message. The mobile access gateway SHOULD 901 configure this address on its interface and respond to any ARP 902 requests sent by the mobile node for resolving the hardware 903 address of the default router. However, since the link between 904 the mobile access gateway and the mobile node is a point-to-point 905 link, implementations will be able receive any packets sent to the 906 default router address without having to explicitly configure the 907 default router address on its interface. The mobile access 908 gateway MAY also use the default router address as the source 909 address for any datagrams sent to the mobile node and originated 910 by the mobile access gateway itself. It MUST also use this 911 address in the DHCP Router option [RFC2132] in the DHCP messages. 913 o If there is an IPv4 DHCP Support Mode option present in the 914 received Proxy Binding Acknowledgement message and if the (S) flag 915 in the option is set to a value of (1), then the mobile access 916 gateway MUST function as a DHCP server for the mobile node. If 917 either the (S) flag in the option is set to a value of (0), or if 918 the option is not present in the request, then the mobile access 919 gateway MUST function as a DHCP Relay for the mobile node. 921 3.2.3.3. Binding Re-Registration and De-Registrations 923 When sending a Proxy Binding Update either for extending the lifetime 924 of a mobility session or for de-registering the mobility session, the 925 respective considerations from [RFC5213] MUST be applied. 926 Furthermore, the following additional considerations MUST also be 927 applied. 929 o If there is an IPv4 home address assigned to the mobility session, 930 then there MUST be exactly one instance of the IPv4 Home Address 931 Request option present in the Proxy Binding Update message. The 932 IPv4 home address and the prefix length fields in the option MUST 933 be set to that specific address and its corresponding subnet-mask 934 length. 936 o If there was no IPv4 home address requested in the initial Proxy 937 Binding Update message, but if it is determined that the IPv4 home 938 address MUST be requested subsequently, then there MUST be exactly 939 one instance of the IPv4 Home Address Request option present in 940 the Proxy Binding Update message. The IPv4 home address in the 941 option MUST be set to either ALL_ZERO or to a specific address 942 that is being requested. 944 o For performing selective de-registration of IPv4 home address but 945 still retaining the mobility session with all the IPv6 home 946 network prefixes, the Proxy Binding Update message with the 947 lifetime value of (0) MUST NOT include any IPv6 Home Network 948 Prefix options(s) [RFC5213]. It MUST include exactly one instance 949 of the IPv4 Home Address Request option with the IPv4 home address 950 and the prefix length fields in the option set to the IPv4 home 951 address that is being de-registered. Similarly for selective de- 952 registration of all the IPv6 home network prefixes, the Proxy 953 Binding Update message MUST NOT include the IPv4 Home address 954 option, it MUST include a Home Network Prefix option for each of 955 the assigned home network prefixes assigned for that mobility 956 session and with the prefix value in the option set to that 957 respective prefix value. 959 o The Home Network Prefix option(s) [RFC5213] MUST NOT be present if 960 the same option(s) was not present in the initial Proxy Binding 961 Update message. Otherwise considerations from [RFC5213] with 962 respect to this option MUST be applied. 964 o If at any point the mobile access gateway fails to extend the 965 binding lifetime with the local mobility anchor for the mobile 966 node's IPv4 address, it MUST remove any forwarding state set up 967 for the mobile node's IPv4 home address. 969 3.2.4. Routing Considerations for the Mobile Access Gateway 971 o On receiving a packet from the bi-directional tunnel established 972 with the mobile node's local mobility anchor, the mobile access 973 gateway MUST remove the outer header before forwarding the packet 974 to the mobile node. 976 o On receiving a packet from a mobile node connected to its access 977 link, the packet MUST be forwarded to the local mobility anchor 978 through the bi-directional tunnel established with the local 979 mobility anchor. However, when EnableMAGLocalRouting flag is set, 980 considerations from Section 6.10.3 of [RFC5213] MUST be applied 981 with respect to local routing. 983 o When forwarding the packet through the bi-directional tunnel, the 984 encapsulation considerations specified in section 3.1.3 MUST be 985 applied. However, before forwarding the packet, the mobile access 986 gateway MUST ensure the source address in the received packet is 987 the address allocated for that mobile node and that there is an 988 active binding on the local mobility anchor for that mobile node. 990 o The mobile access gateway SHOULD use Proxy ARP [RFC0925] to reply 991 to ARP Requests that it receives from the mobile node seeking 992 address resolutions for the destinations on the mobile node's home 993 subnet. When receiving an ARP Request, the mobile access gateway 994 SHOULD examine the target IP address of the Request, and if this 995 IP address matches the mobile node's IPv4 home subnet, it SHOULD 996 transmit a Proxy ARP Reply. However, on certain types of links, 997 the mobile node does not use ARP for address resolutions, instead 998 it forwards all the packets to the mobile access gateway. On such 999 types of links, the mobile access gateway is not required to 1000 support Proxy ARP function. At the same time, implementations not 1001 supporting the Proxy ARP function on links where the mobile node 1002 uses ARP for seeking address resolutions for the destinations on 1003 the mobile node's home subnet will result in communication 1004 failure. 1006 3.3. Mobility Options and Status Codes 1008 To support the IPv4 home address mobility feature, this specification 1009 defines the following new options and Status Codes. 1011 3.3.1. IPv4 Home Address Request Option 1013 A new option, IPv4 Home Address Request Option is defined for use 1014 with the Proxy Binding Update message sent by the mobile access 1015 gateway to the local mobility anchor. This option is used for 1016 requesting IPv4 home address assignment for the mobile node. 1018 The IPv4 Home Address Request option has an alignment requirement of 1019 4n. Its format is as follows: 1021 0 1 2 3 1022 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 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Type | Length |Prefix-len | Reserved | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | IPv4 home address | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 Figure 3: IPv4 Home Address Request Option 1031 Type 1033 IANA 1035 Length 1037 8-bit unsigned integer indicating the length of the option in 1038 octets, excluding the type and length fields. This field MUST 1039 be set to (6). 1041 Prefix-len 1043 This 6-bit unsigned integer indicating the prefix length of the 1044 IPv4 home address contained in the option. 1046 Reserved 1048 This 10-bit field is unused for now. The value MUST be 1049 initialized to (0) by the sender and MUST be ignored by the 1050 receiver. 1052 IPv4 home address 1054 This four-byte field containing the IPv4 home address that is 1055 being requested. The value of 0.0.0.0 is used for requesting 1056 the local mobility anchor to perform the address allocation. 1058 3.3.2. IPv4 Home Address Reply Option 1060 A new option, IPv4 Home Address Reply Option is defined for using it 1061 in the Proxy Binding Acknowledgment message sent by the local 1062 mobility anchor to the mobile access gateway. This option can be 1063 used for sending the assigned mobile node's IPv4 home address. 1065 The IPv4 Home Address Reply option has an alignment requirement of 1066 4n. Its format is as follows: 1068 0 1 2 3 1069 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 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Type | Length | Status |Pref-len |Res| 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | IPv4 home address | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 Figure 4: IPv4 Home Address Reply Option 1078 Type 1080 IANA 1082 Length 1084 8-bit unsigned integer indicating the length of the option in 1085 octets, excluding the type and length fields. This field MUST 1086 be set to (6). 1088 Status 1090 Indicates success or failure for the IPv4 home address 1091 assignment. Values from 0 to 127 indicate success. Higher 1092 values (128 to 255) indicate failure. The following status 1093 values are currently allocated by this document: 1095 0 Success 1097 128 Failure, reason unspecified 1099 129 Administratively prohibited 1101 130 Incorrect IPv4 home address 1103 131 Invalid IPv4 address 1104 132 Dynamic IPv4 home address assignment not available 1106 Prefix-len 1108 This 6-bit unsigned integer is used for carrying the prefix 1109 length of the mobile node's IPv4 home network corresponding the 1110 IPv4 home address contained in the option. 1112 Reserved (Res) 1114 This 2-bit field is unused for now. The value MUST be 1115 initialized to (0) by the sender and MUST be ignored by the 1116 receiver. 1118 IPv4 home address 1120 This four-byte field is used for carrying the IPv4 home address 1121 assigned to the mobile node. 1123 3.3.3. IPv4 Default-Router Address Option 1125 A new option, IPv4 Default-Router Address Option is defined for using 1126 it in the Proxy Binding Acknowledgment message sent by the local 1127 mobility anchor to the mobile access gateway. This option can be 1128 used for sending the mobile node's IPv4 default router address. 1130 The IPv4 Default-Router Address option has an alignment requirement 1131 of 4n. Its format is as follows: 1133 0 1 2 3 1134 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 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Type | Length | Reserved (R) | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | IPv4 Default-Router Address | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 Figure 5: IPv4 Default-Router Address Option 1143 Type 1144 IANA 1146 Length 1148 8-bit unsigned integer indicating the length of the option in 1149 octets, excluding the type and length fields. This field MUST 1150 be set to (6). 1152 Reserved (R) 1154 This 16-bit field is unused for now. The value MUST be 1155 initialized to (0) by the sender and MUST be ignored by the 1156 receiver. 1158 IPv4 Default-Router Address 1160 A four-byte field containing the mobile node's default router 1161 address. 1163 3.3.4. IPv4 DHCP Support Mode 1165 A new option, IPv4 DHCP Support Mode Option is defined for using it 1166 in the Proxy Binding Acknowledgment message sent by the local 1167 mobility anchor to the mobile access gateway. This option can be 1168 used for notifying the mobile access gateway, if it should function 1169 as a DHCP Server or a DHCP Relay for the attached mobile node. 1171 The IPv4 DHCP Support Mode option has no alignment requirement. Its 1172 format is as follows: 1174 0 1 2 3 1175 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 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Type | Length | Reserved (R) |S| 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 Figure 6: IPv4 DHCP Support Mode Option 1182 Type 1184 IANA 1186 Length 1188 8-bit unsigned integer indicating the length of the option in 1189 octets, excluding the type and length fields. This field MUST 1190 be set to 2. 1192 Reserved (R) 1194 This 15-bit field is unused for now. The value MUST be 1195 initialized to (0) by the sender and MUST be ignored by the 1196 receiver. 1198 DHCP Support Mode (S) 1200 A 1-bit field that specifies the DHCP support mode. This flag 1201 indicates if the mobile access gateway should function as a 1202 DHCP Server or a DHCP Relay for the attached mobile node. The 1203 flag value of (0) indicates the mobile access gateway should 1204 act as a DHCP Relay and the flag value of (1) indicates it 1205 should act as a DHCP Server. 1207 3.3.5. Status Codes 1209 This document defines the following new Status values for use in the 1210 Proxy Binding Acknowledgement message. These values are to be 1211 allocated from the same numbering space, as defined in Section 6.1.8 1212 of [RFC3775]. 1214 NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: IANA 1216 Mobile node not authorized for IPv4 mobility service. 1218 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 1220 Mobile node not authorized for the requesting IPv4 home address 1222 NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: IANA 1224 Mobile node not authorized for IPv6 mobility service. 1226 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: IANA 1228 Multiple IPv4 home address assignment not supported 1230 3.4. Supporting DHCP-Based Address Configuration 1232 This section explains how DHCP-based address configuration support 1233 can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It 1234 explains the protocol operation, supported DHCP server deployment 1235 configurations and the protocol interactions between DHCP agents and 1236 mobility entities in each of the supported configurations. 1238 This specification supports the following two DHCP deployment 1239 configurations. 1241 o DHCP relay agent co-located with the mobile access gateway. 1243 o DHCP server co-located in the mobile access gateway. 1245 The following are the configuration requirements: 1247 o The DHCP server or the DHCP relay agent configured on the mobile 1248 access gateway is required to have an IPv4 address for exchanging 1249 the DHCP messages with the mobile node. This address is the 1250 mobile node's default router address provided by the local 1251 mobility anchor. Optionally, all the DHCP servers co-located with 1252 the mobile access gateways in the Proxy Mobile IPv6 domain can be 1253 configured with a fixed IPv4 address. This fixed address can be 1254 potentially an IPv4 private address [RFC1918] that can be used for 1255 the DHCP protocol communication on any of the access links. This 1256 address will be used as the server identifier in the DHCP 1257 messages. 1259 o A DHCP server identifies a DHCP interface from the contents of the 1260 DHCP "Client-identifier" option [RFC2132], if present, or from the 1261 client hardware address (chaddr), as specified in [RFC2131]. Note 1262 that the name "Client-identifier" is a misnomer as it actually 1263 identifies an interface and not the client. The DHCP server uses 1264 this identity to identify the interface for which the address is 1265 assigned. A mobile node in a Proxy Mobile IPv6 domain, can attach 1266 to the network through multiple interfaces and can obtain address 1267 configuration for each of its interfaces. Additionally, it may 1268 perform handoffs between its interfaces. Following are the 1269 related considerations with respect to the identification 1270 presented to the DHCP server. 1272 * If the mobile node attaches to the Proxy Mobile IPv6 domain 1273 through multiple physical interfaces, the DHCP server will 1274 uniquely identify each of those interfaces and will perform 1275 address assignment. The DHCP server will identify the 1276 interface as specified in RFC 2131. The mobile node SHOULD 1277 generate and use the "Client-identifier" for each physical 1278 interface according to [RFC4361]. Any time the mobile node 1279 performs an handoff of a physical interface to a different 1280 mobile access gateway, using the same interface, the DHCP 1281 server will always be able to identify the binding using the 1282 presented identifier. The presented identifier (either the 1283 "Client-identifier" or the hardware address) will remain as the 1284 primary key for each binding, just as how they are unique in a 1285 Binding Cache entry. 1287 * If the mobile node is capable of performing handoff between 1288 interfaces, as per [RFC5213], a "Client-identifier" value MUST 1289 be used for the attachment point that is not tied to any of the 1290 physical interfaces. The identifier MUST be generated 1291 according to [RFC4361], which guarantees that the identifier is 1292 stable and unique across all "Client-identifier" values in use 1293 in the Proxy Mobile IPv6 domain. 1295 o All the DHCP servers co-located with the mobile access gateways in 1296 a Proxy Mobile IPv6 domain can be configured with the same set of 1297 DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure 1298 the mobile node receives the same configuration values on any of 1299 the access links in that Proxy Mobile IPv6 domain. 1301 3.4.1. DHCP Server co-located with the Mobile Access Gateway 1303 This section explains the operational sequence of home address 1304 assignment operation when the DHCP server is co-located with the 1305 mobile access gateway. 1307 MN MAG(DHCP-S) LMA 1308 |------>| | 1. DHCPDISCOVER 1309 | |------->| 2. Proxy Binding Update 1310 | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) 1311 | |========| 4. Tunnel/Route Setup 1312 |<------| | 5. DHCPOFFER (IPv4 HoA) 1313 |------>| | 6. DHCPREQUEST (IPv4 HoA) 1314 |<------| | 7. DHCPACK 1315 | | | 1316 * It is possible the MAG may have already completed the Proxy Mobile 1317 IPv6 signaling with the LMA for requesting both IPv6 home network 1318 prefix(es) and IPv4 home address assignment prior to step-1. In 1319 such event, the Proxy Mobile IPv6 signaling steps (step-2 to 1320 step-4) above are not relevant. 1321 * It is possible the MAG may have initially completed the Proxy 1322 Mobile IPv6 signaling prior to Step-1, but only for requesting 1323 IPv6 home network prefix(es) and may later request IPv4 home 1324 address assignment after detecting the DHCP triggers from the 1325 mobile node as shown above. 1326 * The MAG may choose to ignore the DHCPDISCOVER messages till the 1327 Proxy Mobile IPv6 signaling is successfully completed, or it may 1328 choose to send a delayed response for reducing the additional 1329 delay waiting for a new DHCPDISCOVER message from the mobile node. 1331 Figure 7: Overview of DHCP Server located at Mobile Access Gateway 1333 Initial IPv4 Home Address Assignment: 1335 o For acquiring the mobile node's IPv4 home address from the local 1336 mobility anchor, the mobile access gateway will initiate Proxy 1337 Mobile IPv6 signaling with the local mobility anchor. 1339 o After the successful completion of the Proxy Mobile IPv6 signaling 1340 and upon acquiring the mobile node's IPv4 home address from the 1341 local mobility anchor, the DHCP server on the mobile access 1342 gateway will send a DHCPOFFER message [RFC2131] to the mobile 1343 node. The offered address will be the mobile node's IPv4 home 1344 address, assigned by the local mobility anchor. The DHCPOFFER 1345 message will also have the subnet mask option [RFC2132] and router 1346 option [RFC2132], with the values in those options set to the 1347 mobile node's IPv4 home subnet mask and default router address 1348 respectively. Additionally, the Server Identifier option will be 1349 included and with the value in the option set to the default 1350 router address. 1352 o If the mobile node sends the DHCPREQUEST message, the DHCP server 1353 will send DHCPACK message, as per [RFC2131]. 1355 IPv4 Home Address Renewal with the DHCP server (No Handoff): 1357 o Any time the mobile node goes into the DHCP RENEWING state 1358 [RFC2131], it simply unicasts the DHCPREQUEST message including 1359 the assigned IPv4 home address in the 'requested IP address' 1360 option. The DHCPREQUEST is sent to the address specified in 1361 Server Identifier option of the previously received DHCPOFFER and 1362 DHCPACK messages. 1364 o The DHCP server will send a DHCPACK to the mobile node to 1365 acknowledge the assignment of the committed IPv4 address. 1367 IPv4 Home Address Renewal with the DHCP server (After Handoff): 1369 When the mobile node goes into the DHCP RENEWING state [RFC2131], it 1370 directly unicasts the DHCPREQUEST message to the DHCP server that 1371 currently provided the DHCP lease. However, if the mobile node 1372 changed its point of attachment and is attached to a new mobile 1373 access gateway, it is required that the mobile node updates the DHCP 1374 server address and uses the address of the DHCP server that is co- 1375 located with the new mobile access gateway. The following approach 1376 can be adopted to ensure the mobile node uses the DHCP server on the 1377 attached link. 1379 MN oMAG(DHCP-S) nMAG(DHCP-S) 1380 | : | 1381 RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) 1382 BOUND<-------------| 2. DHCPACK (IPv4 HoA) or DHCPNACK 1383 | : | 1384 * The use of a fixed DHCP server address on all DHCP servers 1386 Figure 8: Address renewal with the DHCP server 1388 o The use of a stable address, either the IPv4 default router 1389 address of the mobile node, or a fixed IPv4 address common in that 1390 Proxy Mobile IPv6 domain, as the DHCP server Id will ensure the 1391 DHCPREQUEST message sent by the mobile node for renewing the 1392 address will be received by the new mobile access gateway on the 1393 attached link. 1395 o The mobile access gateway after completing the Proxy Mobile IPv6 1396 signaling and upon acquiring the IPv4 home address of the mobile 1397 node will return the address in the DHCPACK message. However, if 1398 the mobile access gateway is unable to complete the Proxy Mobile 1399 IPv6 signaling or is unable to acquire the same IPv4 address as 1400 requested by the mobile node, it will send a DHCPNACK message 1401 [RFC2131] to the mobile node, as shown in Figure 8. 1403 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway 1405 A DHCP relay agent is co-located with each mobile access gateway. A 1406 DHCP server is located somewhere in the Proxy Mobile IPv6 domain 1407 (e.g., is co-located with the local mobility anchor). Figure 9 shows 1408 the sequence of IPv4 home address assignment using DHCP Relay. 1410 MN MAG(DHCP-R) LMA DHCP-S 1411 | |------->| | 1. Proxy Binding Update * 1412 | |<-------| | 2. Proxy Binding Acknowledgement (IPv4 HoA) 1413 | |========| | 3. Tunnel/Route Setup* 1414 |------>|-------------->| 4. DHCPDISCOVER (IPv4 HoA) via DHCP-R 1415 |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R 1416 |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R 1417 |<------|<--------------| 7. DHCPACK (IPv4 HoA) via DHCP-R 1418 | | | 1419 * The Proxy Mobile IPv6 signaling (starting at Step-1) and the 1420 DHCP address configuration (starting at Step-4) may start in any 1421 order. However, the DHCPOFFER (Step-5) and the immediate steps 1422 following it will occur in the specified order and only after the 1423 Tunnel/Route Setup (Step-3). 1424 * It is possible the MAG may have initially completed the Proxy 1425 Mobile IPv6 signaling with the LMA only for requesting IPv6 home 1426 network prefix(es) and may later request IPv4 home address 1427 assignment after detecting the DHCP triggers from the mobile node 1428 (after Step-4). 1429 * The MAG may choose to ignore the DHCPDISCOVER messages till the 1430 Proxy Mobile IPv6 signaling is successfully completed, or it may 1431 choose to send a delayed response for reducing the additional 1432 delay waiting for a new DHCPDISCOVER message from the mobile node. 1434 Figure 9: Overview of the DHCP relay located at mobile access gateway 1436 Initial IPv4 Home Address Assignment: 1438 o For acquiring the mobile node's IPv4 home address from the local 1439 mobility anchor, the mobile access gateway will initiate Proxy 1440 Mobile IPv6 signaling with the local mobility anchor. 1442 o After the successful completion of the Proxy Mobile IPv6 signaling 1443 and upon acquiring the mobile node's IPv4 home address from the 1444 local mobility anchor, the mobile access gateway will enable 1445 forwarding for all the DHCP messages between the mobile node and 1446 the DHCP server. 1448 o The DHCP relay agent on the mobile access gateway will add the 1449 DHCP relay agent information option [RFC3046] to the DHCPDISCOVER 1450 message. The assigned IPv4 home address will be included in the 1451 Agent Remote ID Sub-option of the DHCP relay agent information 1452 option. This sub-option is used as a hint for requesting the DHCP 1453 server to allocate that specific IPv4 address. 1455 o On receiving a DHCPOFFER message from the DHCP server, the mobile 1456 access gateway will ensure the assigned address is currently 1457 assigned by the local mobility anchor to that mobile node. If 1458 this address is different from what is assigned to the mobile 1459 node, then the mobile access gateway will drop the DHCPOFFER 1460 message and an administrative error message will be logged. 1462 o When the DHCP messages are sent over administrative boundaries, 1463 the operators needs to ensure these messages are secured. All the 1464 DHCP messages relayed by the mobile access gateway can be tunneled 1465 to the local mobility anchor if needed. Alternatively, if the 1466 network in the Proxy Mobile IPv6 domain is secure enough, the 1467 mobile access gateway can just relay the DHCP messages to the 1468 server. To achieve this, all the mobile access gateways needs to 1469 have a route towards the DHCP server. 1471 IPv4 Home Address Renewal to the same DHCP server: (No Handoff) 1473 o When the DHCP client goes into the DHCP RENEW STATE [RFC2131], it 1474 directly unicasts DHCPREQUEST messages to the DHCP server. The 1475 DHCP relay agent may not detect any changes in the DHCP state. 1476 For example, if the mobile node releases the IPv4 address, the 1477 relay agent would not be aware of it. The following describes 1478 additional mechanisms for the mobile access gateway to detect any 1479 changes in the DHCP state. 1481 * The DHCP relay agent can intercept all IPv4 DHCP packets 1482 destined to the set of addresses used within the Proxy Mobile 1483 IPv6 domain as DHCP addresses. Since the link between a mobile 1484 node and a mobile access gateway is the point-to-point link, 1485 the mobile access gateway will be in path for all the messages. 1487 * The DHCP relay agent can use the DHCP Server Identifier 1488 Override Sub-option [RFC5107] to be in path for all the DHCP 1489 message flows. The DHCP client uses the DHCP server address 1490 which is overridden by the DHCP relay agent address as a 1491 destination address of DHCPREQUEST. The DHCP Server Identifier 1492 Override Sub-option is recommended only when the fixed DHCP 1493 relay address is configured on all the mobile access gateways. 1494 Otherwise, the DHCP relay agent address is changed when the 1495 mobile node changes the attached mobile access gateway. 1497 o However, if the DHCP server is co-located with the local mobility 1498 anchor, then the DHCP relay agent is not required to intercept the 1499 unicast DHCP messages between the mobile node and the DHCP server. 1500 This is because the local mobility anchor will ensure that the 1501 DHCP state is consistent with the PMIPv6 binding that exists for 1502 the IPv4 address. 1504 o Once the mobile access gateway intercepts the DHCP message from 1505 the mobile node to the DHCP server, it can verify if the mobile 1506 node is negotiating the same IPv4 address that the local mobility 1507 anchor allocated for that mobile node. If the address in the 1508 DHCPREQUEST message does not match with the IPv4 address allocated 1509 for the mobile node, then the mobile access gateway SHOULD drop 1510 the DHCP message and an administrative error message can be 1511 logged. 1513 o Any time the mobile access gateway detects that the mobile node 1514 has released its IPv4 address, it can send a Proxy Binding Update 1515 to the local mobility anchor and de-register the IPv4 mobility 1516 session. 1518 3.4.3. Common DHCP Considerations 1520 The following DHCP related considerations are common to both the 1521 supported configuration modes, specified in Section 3.4.1 and Section 1522 3.4.2. 1524 o When a mobile node sends a DHCPDISCOVER message [RFC2131], the 1525 DHCP server or the relay agent co-located with the mobile access 1526 gateway will trigger the mobile access gateway to complete the 1527 Proxy Mobile IPv6 signaling. This is the required interaction 1528 between these two protocols. The mobile access gateway on 1529 receiving this trigger will check if there is already an assigned 1530 IPv4 home address for the mobile node, from the local mobility 1531 anchor. If there is no assigned IPv4 home address assigned for 1532 that mobile node, the mobile access gateway will complete the 1533 Proxy Mobile IPv6 signaling with the local mobility anchor by 1534 sending a Proxy Binding Update message. 1536 o The mobile node needs to be identified by the MN-Identifier, as 1537 specified in Section 6.6 of [RFC5213]. This identity should be 1538 associated to the DHCP messages sent by the mobile node. 1540 o The mobile access gateway will drop all the DHCPDISCOVER messages 1541 till it completes the Proxy Mobile IPv6 signaling. If the mobile 1542 access gateway is unable to complete the Proxy Mobile IPv6 1543 signaling, or, if the local mobility anchor does not assign an 1544 IPv4 address for the mobile node, the mobile access gateway MUST 1545 NOT enable IPv4 home address mobility support for the mobile node 1546 on that access link. 1548 o The trigger for initiating Proxy Mobile IPv6 signaling can also be 1549 delivered to the mobile access gateway as part of a context 1550 transfer from the previous mobile access gateway, or delivered 1551 from the other network elements in the radio network, the details 1552 of which are outside the scope of this document. 1554 o The DHCPOFFER message [RFC2131] sent to the mobile node MUST 1555 include the Subnet Mask option [RFC2132] and the Router option 1556 [RFC2132]. The values in the Subnet Mask option and Router option 1557 MUST be set to the mobile node's IPv4 home subnet mask and its 1558 default router address respectively. 1560 o The DHCPOFFER message [RFC2131] sent to the mobile node MUST 1561 include the Interface MTU option [RFC2132]. The DHCP servers in 1562 the Proxy Mobile IPv6 domain MUST be configured to include the 1563 Interface MTU option. The MTU value SHOULD reflect the tunnel MTU 1564 for the bi-directional tunnel between the mobile access gateway 1565 and the local mobility anchor. 1567 o The DHCP lease length allocated to the mobile node's IPv4 home 1568 address may be different from the binding lifetime at the local 1569 mobility anchor for that mobile node's session. It is not 1570 possible to keep these lifetimes synchronized and so its not 1571 required that the configured lifetimes should be kept same in both 1572 DHCP and Proxy Mobile IPv6. 1574 o When the mobile node performs an handoff from one mobile access 1575 gateway to another, the mobile access gateway on the new link will 1576 initiate the Proxy Mobile IPv6 signaling with the local mobility 1577 anchor. On completing the Proxy Mobile IPv6 signaling, the mobile 1578 access gateway has the proper IPv4 address state that the local 1579 mobility anchor has allocated for the mobile node and which can be 1580 used for supporting DHCP based address configuration on that link. 1582 o Any time the mobile node detects a link change event due to 1583 handoff, or due to other reasons such as re-establishment of the 1584 link-layer, the following are the mobile node's considerations 1585 with respect to the DHCP protocol. 1587 * If the mobile node is DNAv4 [RFC4436] capable and if it 1588 performs DNAv4 procedures after receiving a link change event, 1589 it would always detect the same default router on any of the 1590 access links in that Proxy Mobile IPv6 domain, as the mobile 1591 access gateway configures a fixed link-layer address on all the 1592 access links, as per the base Proxy Mobile IPv6 specification 1593 [RFC5213]. The mobile node will not perform any DHCP operation 1594 specifically due to this event. 1596 * If the mobile node is not DNAv4 [RFC4436] capable, after 1597 receiving the link change event it will enter INIT-REBOOT state 1598 [RFC2131] and will send a DHCPREQUEST message as specified in 1599 Section 3.7 of [RFC2131]. The mobile node will obtain the same 1600 address configuration as before, as the link change does not 1601 result in any change at the network layer. 1603 o The mobile node may release its IPv4 home address at any time by 1604 sending the DHCPRELEASE message [RFC2131]. When the mobile access 1605 gateway detects the DHCPRELEASE message sent by the mobile node, 1606 it should consider this as a trigger for de-registering the mobile 1607 node's IPv4 home address. It will apply the considerations 1608 specified in section 3.2.3.3 for performing the de-registration 1609 procedure. However, this operation MUST NOT release any IPv6 home 1610 network prefix(es) assigned to the mobile node. 1612 4. IPv4 Transport Support 1614 The Proxy Mobile IPv6 specification [RFC5213] requires the signaling 1615 messages exchanged between the local mobility anchor and the mobile 1616 access gateway to be over an IPv6 transport. However, in some cases 1617 the local mobility anchor and the mobile access gateway are separated 1618 by an IPv4 network. 1620 The normal Proxy Mobile IPv6 specification [RFC5213] can be run over 1621 an IPv4 transport without any modifications by using a transition 1622 technology that allows IPv6 hosts to communicate over IPv4 networks. 1623 For example, the MAG and the LMA could have a simple configured IPv6- 1624 over-IPv4 tunnel. Instead of configured tunnels, various mechanisms 1625 for automatic tunneling could be used, too. To these tunnels, Proxy 1626 Mobile IPv6 would look just like any other application traffic 1627 running over IPv6. 1629 However, treating Proxy Mobile IPv6 just like any other IPv6 traffic 1630 would mean an extra layer of encapsulation for the mobile node's 1631 tunneled data traffic, adding 40 octets of overhead for each packet. 1632 The extensions defined in this section allow the MAG and the LMA to 1633 communicate over an IPv4 network without this overhead. 1635 IPv4-Proxy-CoA IPv4-LMAA 1636 | + - - - - - - + | 1637 +--+ +---+ / \ +---+ +--+ 1638 |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| 1639 +--+ +---+ \ / +---+ +--+ 1640 + - - - - - - + 1642 Figure 10: IPv4 Transport Network 1644 When the local mobility anchor and the mobile access gateway are 1645 configured and reachable using only IPv4 addresses, the mobile access 1646 gateway serving a mobile node can potentially send the signaling 1647 messages over IPv4 transport and register its IPv4 address as the 1648 care-of address in the mobile node's Binding Cache entry. An IPv4 1649 tunnel (with any of the supported encapsulation modes) can be used 1650 for tunneling the mobile node's data traffic. The following are the 1651 key aspects of this feature. 1653 o The local mobility anchor and the mobile access gateway are both 1654 configured and reachable using an IPv4 address of the same scope. 1656 o The IPv4 addresses used can be private IPv4 addresses, but it is 1657 assumed that there is no NAT between the LMA and the MAG. 1659 However, it is possible to use UDP encapsulation if other types of 1660 middleboxes are present. 1662 o The Mobility Header [RFC3775] is carried inside an IPv4 packet and 1663 UDP header, using an UDP port number for Proxy Mobile IPv6 1664 signalling over IPv4. 1666 o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and 1667 the IPv4 transport support specified in this section is agnostic 1668 to the type of address mobility enabled for that mobile node. 1670 o The mobile node's data traffic will be tunneled between the local 1671 mobility anchor and the mobile access gateway. There are several 1672 encapsulation modes available: 1674 * IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet). 1675 If payload protection using IPsec is enabled for the tunneled 1676 traffic, the ESP header follows the outer tunnel header. 1678 * IPv4-UDP (Payload packet carried in an IPv4 packet with UDP 1679 header, using a UDP port number for Proxy Mobile IPv6 data; 1680 this is different port than is used for signalling). If 1681 payload protection using IPsec is enabled, the ESP header 1682 follows the outer IPv4 header, as explained in Section 4.3. 1684 * IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP 1685 and TLV header) and IPv4-GRE (Payload packet carried in an IPv4 1686 packet with GRE header). Refer to 1687 [I-D.ietf-netlmm-grekey-option]. If payload protection using 1688 IPsec is enabled, the ESP header follows the outer IPv4 header, 1689 as explained in Section 4.3. 1691 4.1. Local Mobility Anchor Considerations 1693 4.1.1. Extensions to Binding Cache Entry 1695 To support this feature, the conceptual Binding Cache entry data 1696 structure maintained by the local mobility anchor [RFC5213] MUST be 1697 extended with the following additional parameters. It is to be noted 1698 that all of these parameters are specified in [RFC5555] and also 1699 required here in the present usage context, and are presented here 1700 only for completeness. 1702 o The IPv4 Proxy Care-of Address configured on the mobile access 1703 gateway that sent the Proxy Binding Update message. The address 1704 MUST be the same as the source address of the received IPv4 packet 1705 that contains the Proxy Binding Update message. However, if the 1706 received Proxy Binding Update message is not sent as an IPv4 1707 packet, i.e., when using IPv6 transport, this field in the Binding 1708 Cache entry MUST be set to ALL_ZERO value. 1710 4.1.2. Extensions to Mobile Node's Policy Profile 1712 To support the IPv4 Transport Support feature the mobile node's 1713 policy profile, specified in Section 6.2 of [RFC5213] MUST be 1714 extended with the following additional fields. These are mandatory 1715 fields of the policy profile required for supporting this feature. 1717 o The IPv4 address of the local mobility anchor (IPv4-LMAA). 1719 4.1.3. Signaling Considerations 1721 This section provides the rules for processing the Proxy Mobile IPv6 1722 signaling messages received over IPv4 transport. 1724 4.1.3.1. Processing Proxy Binding Updates 1726 o If the Proxy Binding Update message is protected with IPsec ESP, 1727 IPsec processing happens before the packet is passed to Proxy 1728 Mobile IPv6. 1730 o All the considerations from Section 5.3.1 of [RFC5213] except step 1731 1 (about IPsec) MUST be applied on the encapsulated Proxy Binding 1732 Update message. Note that the Checksum field in Mobility Header 1733 MUST be ignored. 1735 o Upon accepting the request, the local mobility anchor MUST set up 1736 an IPv4 bi-directional tunnel to the mobile access gateway. The 1737 tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. 1738 The encapsulation mode MUST be determined by applying the 1739 following considerations: 1741 * If the (F) flag in the received Proxy Binding Update message is 1742 set to the value of (1), but if the configuration flag, 1743 AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of 1744 (0), then the local mobility anchor MUST reject the request 1745 with the Status field value set to 129 (Administratively 1746 prohibited). 1748 * If the (T) flag is set to (1), or GRE Key option is included, 1749 see [I-D.ietf-netlmm-grekey-option]. 1751 * If the (F) flag in the received Proxy Binding Update message is 1752 set to the value of (1), then the encapsulation mode MUST be 1753 set to IPv4-UDP. Otherwise the encapsulation mode MUST be set 1754 to IPv4. 1756 o The local mobility anchor MUST send the Proxy Binding 1757 Acknowledgement message with the Status field value set to (0) 1758 (Proxy Binding Update Accepted). The message MUST be constructed 1759 as specified in Section 4.1.3.2. 1761 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 1763 The local mobility anchor when sending the Proxy Binding 1764 Acknowledgement message to the mobile access gateway MUST construct 1765 the message as specified in Section 5.3.6 of [RFC5213]. However, if 1766 the Proxy Binding Update message was received over IPv4, the 1767 following additional considerations MUST be applied. 1769 o The IPv6 Header is removed, and the Mobility Header containing the 1770 Proxy Binding Acknowledgement is encapsulated in UDP (with source 1771 port set to TBD1 and destination port set to the source port of 1772 received Proxy Binding Update message). The Mobility Header 1773 Checksum field MUST be set to zero (and UDP checksum MUST be used 1774 instead). 1776 o The source address in the IPv4 header of the message MUST be set 1777 to the destination IPv4 address of the received request. 1779 o If IPsec ESP is used to protect signalling, the packet is 1780 processed using transport mode ESP as described in Section 4.3. 1782 o Figure 11 shows the format of the Proxy Binding Acknowledgement 1783 message sent over IPv4 and protected using ESP. 1785 IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) 1786 ESP header (in transport mode) 1787 UDP header (sport=TBD1, dport=TBD1) 1788 Mobility Header (PBA) 1790 Figure 11: Proxy Binding Acknowledgment (PBA) Message sent over 1791 IPv4 1793 4.1.4. Routing Considerations 1795 4.1.4.1. Forwarding Considerations 1797 Forwarding Packets to the Mobile Node: 1799 o On receiving an IPv4 or an IPv6 packet from a correspondent node 1800 with the destination address matching any of the mobile node's 1801 IPv4 or IPv6 home addresses, the local mobility anchor MUST 1802 forward the packet through the bi-directional tunnel set up for 1803 that mobile node. 1805 o The format of the tunneled packet is shown below. The IPv4-UDP- 1806 TLV and IPv4-GRE encapsulation modes are described in 1807 [I-D.ietf-netlmm-grekey-option]. 1809 IPv4 Header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)] /* Tunnel Header */ 1810 [UDP Header (src port=TBD2, dst port=TBD2] /* If UDP encap nego */ 1811 /* IPv6 or IPv4 Payload Packet */ 1812 IPv6 header (src=CN, dst=MN-HOA) 1813 OR 1814 IPv4 header (src=CN, dst=IPv4-MN-HoA) 1816 Figure 12: Tunneled IPv4 Packet from LMA to MAG (IPv4 or IPv4-UDP 1817 encapsulation mode) 1819 o Forwarding Packets Sent by the Mobile Node: 1821 * All the reverse tunneled packets (IPv4 and IPv6) that the local 1822 mobility anchor receives from the mobile access gateway, after 1823 removing the tunnel header (i.e., the outer IPv4 header along 1824 with the UDP and TLV header, if negotiated) MUST be routed to 1825 the destination specified in the inner packet header. These 1826 routed packets will have the source address field set to the 1827 mobile node's home address. 1829 4.1.4.2. ECN & Payload Fragmentation Considerations 1831 The ECN considerations specified in Section 5.6.3 of [RFC5213] apply 1832 for the IPv4 transport tunnels as well. The mobility agents at the 1833 tunnel entry and exit points MUST handle ECN information as specified 1834 in that document. 1836 The mobility agents at the tunnel entry and exit points MUST apply 1837 the IP packet fragmentation considerations as specified in [RFC4213]. 1838 Additionally they MUST also apply the considerations related to 1839 tunnel error processing and reporting as specified in the same 1840 specification. 1842 4.1.4.3. Bi-Directional Tunnel Management 1844 The Tunnel Management considerations specified in section 5.6.1 of 1845 [RFC5213] apply for the IPv4 transport tunnels as well, with just one 1846 difference that the encapsulation mode is different. 1848 4.2. Mobile Access Gateway Considerations 1850 4.2.1. Extensions to Binding Update List Entry 1852 To support the IPv4 Transport Support feature, the conceptual Binding 1853 Update List entry data structure maintained by the mobile access 1854 gateway [RFC5213] MUST be extended with the following additional 1855 parameters. 1857 o The IPv4 address of the local mobility anchor. This address can 1858 be obtained from the mobile node's policy profile. 1860 4.2.2. Signaling Considerations 1862 The mobile access gateway when sending a Proxy Binding Update message 1863 to the local mobility anchor MUST construct the message as specified 1864 in Section 6.9.1.5 of [RFC5213]. However, if the mobile access 1865 gateway is in an IPv4-only access network, the following additional 1866 considerations MUST be applied. 1868 o The Proxy Binding Update message MUST be sent over IPv4 as 1869 desribed in Section 4.2.2.1. 1871 o Just as specified in [RFC5213], when sending a Proxy Binding 1872 Update message for extending the lifetime of a currently existing 1873 mobility session or for de-registering the mobility session, the 1874 Proxy Binding Update message MUST be constructed just as the 1875 initial request. 1877 Receiving Proxy Binding Acknowledgement 1879 o If the received Proxy Binding Acknowledgement message is protected 1880 with IPsec ESP, IPsec processing happens before the packet is 1881 passed to Proxy Mobile IPv6. Considerations from Section 4 of 1882 [RFC5213] MUST be applied for authenticating and authorizing the 1883 message. 1885 o All the considerations from Section 6.9.1.2 of [RFC5213] MUST be 1886 applied on the encapsulated Proxy Binding Acknowledgement message. 1887 Note that the Checksum field in Mobility Header MUST be ignored. 1889 o If the Status field indicates Success, the mobile access gateway 1890 MUST setup a bi-directional tunnel to the local mobility anchor. 1892 o Upon accepting the request, the mobile access gateway MUST set up 1893 an IPv4 bi-directional tunnel to the local mobility anchor. The 1894 tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA. 1896 The encapsulation mode MUST be determined from the below 1897 considerations: 1899 * If the (T) flag is set to (1), or GRE Key option is included, 1900 see [I-D.ietf-netlmm-grekey-option]. 1902 * If there is a NAT Detection option [RFC5555] in the received 1903 Proxy Binding Acknowledgement message, and the (F) flag is set 1904 to value of (1), the encapsulation mode for the tunnel MUST be 1905 set to IPv4-UDP. Otherwise the encapsulation mode MUST be set 1906 to IPv4. 1908 4.2.2.1. Constructing the Proxy Binding Update Message 1910 o The IPv6 Header is removed, and the Mobility Header containing the 1911 Proxy Binding update message is encapsulated in UDP (with the 1912 destination port set to TBD1). The Mobility Header Checksum field 1913 MUST be set to zero (and UDP checksum MUST be used instead). 1915 o The source address in the IPv4 header MUST be set to IPv4-Proxy- 1916 CoA of the mobile access gateway and the destination address MUST 1917 be set to the local mobility anchor's IPv4-LMAA. 1919 o If the configuration variable ForceIPv4UDPEncapsulationSupport is 1920 set to value of (1), then the (F) flag in the Proxy Binding Update 1921 message MUST be set to value of (1). 1923 o If IPsec ESP is used to protect signalling, the packet is 1924 processed using transport mode ESP as described in Section 4.3. 1926 o Figure 13 shows the format of the Proxy Binding Update message 1927 sent over IPv4 and protected using ESP. 1929 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1930 ESP header (in transport mode) 1931 UDP header (sport=TBD1, dport=TBD1) 1932 Mobility Header (PBU) 1934 Figure 13: Proxy Binding Update (PBU) message sent over IPv4 1936 4.2.2.2. Forwarding Considerations 1938 Forwarding Packets Sent by the Mobile Node: 1940 o On receiving an IPv4 or an IPv6 packet from the mobile node to any 1941 destination, the mobile access gateway MUST tunnel the packet to 1942 the local mobility anchor. The format of the tunneled packet is 1943 shown below. The IPv4-UDP-TLV and IPv4-GRE encapsulation modes 1944 are described in [I-D.ietf-netlmm-grekey-option]. However, 1945 considerations from Section 6.10.3 of [RFC5213] MUST be applied 1946 with respect the local routing and on the use of 1947 EnableMAGLocalRouting flag. 1949 IPv4 Header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)] /* Tunnel Header */ 1950 [UDP Header (src port=TBD2, dst port=TBD2] /* If UDP encap nego */ 1951 /* IPv6 or IPv4 Payload Packet */ 1952 IPv6 header (src=MN-HOA, dst=CN) 1953 OR 1954 IPv4 header (src=MN-HOA, dst=CN) 1956 Figure 14: Tunneled IPv4 Packet from MAG to LMA (IPv4 or IPv4-UDP 1957 encapsulation mode) 1959 Forwarding Packets received from the bi-directional tunnel: 1961 o On receiving a packet from the bi-directional tunnel established 1962 with the mobile node's local mobility anchor, the mobile access 1963 gateway MUST remove the outer header before forwarding the packet 1964 to the mobile node. 1966 4.3. IPsec Considerations 1968 4.3.1. PBU and PBA 1970 The following section describes how IPsec is used for protecting the 1971 signaling messages and data packets between the local mobility anchor 1972 and mobile access gateway when using IPv4 transport. 1974 The following are the SPD example entries to protect PBU and PBA on 1975 the local mobility anchor and mobile access gateway. 1977 MAG SPD-S: 1978 - IF local_address = IPv4-Proxy-CoA_1 & 1979 remote_address = IPv4-LMAA_1 & proto = UDP & 1980 remote_port = TBD1 1981 Then use SA ESP transport mode 1983 LMA SPD-S: 1984 - IF local_address = IPv4-LMAA_1 & 1985 remote_address = IPv4-Proxy-CoA_1 & proto = UDP & 1986 local_port = TBD1 1987 Then use SA ESP transport mode 1989 4.3.2. Payload Packet 1991 The following are the SPD example entries to protect payload packets 1992 on the local mobility anchor and mobile access gateway. Note that 1993 the example SPDs protect all payload packets sent to and from mobile 1994 nodes. If an operator needs to apply a different security mechanism 1995 per mobile node, they need to create a SPD and a SA entry per mobile 1996 node. 1998 MAG SPD-S: 1999 - IF interface = tunnel to LMAA_1 & 2000 local_address != Proxy-CoA_1 & 2001 remote_address != LMAA_1 & proto=any 2002 Then use SA ESP tunnel mode 2004 LMA SPD-S: 2005 - IF interface = tunnel to Proxy-CoA_1 & 2006 local_address != LMAA_1 & 2007 remote_address != Proxy-CoA_1 & proto=any 2008 Then use SA ESP tunnel mode 2010 When payload packets are protected by IPsec, payload packets matching 2011 to the SPDs are passed to the IPsec module and encapsulated using the 2012 tunnel mode ESP. The tunnel mode ESP encapsulated payload packets 2013 are then directly sent to the peer mobile access gateway or local 2014 mobility anchor. If IPsec is not applied to payload packets, then 2015 they are encapsulated as shown in Figures 12 and 14. 2017 5. Protocol Configuration Variables 2019 5.1. Local Mobility Anchor - Configuration Variables 2021 The local mobility anchor MUST allow the following variables to be 2022 configured by the system management. The configured values for these 2023 protocol variables MUST survive server reboots and service restarts. 2025 AcceptForcedIPv4UDPEncapsulationRequest 2027 This flag indicates whether or not the local mobility anchor 2028 should accept IPv4 UDP encapsulation request for the mobile node's 2029 data traffic. The default value for this flag is set to (0), 2030 indicating that plain IPv4 encapsulation (without UDP) is used for 2031 data traffic. 2033 5.2. Mobile Access Gateway - Configuration Variables 2035 The mobile access gateway MUST allow the following variables to be 2036 configured by the system management. The configured values for these 2037 protocol variables MUST survive server reboots and service restarts. 2039 ForceIPv4UDPEncapsulationSupport 2041 This flag indicates whether or not the mobile access gateway 2042 should request the mobile node's local mobility anchor to use 2043 IPv4-UDP encapsulation mode for the mobile node's data traffic. 2044 The default value for this flag is set to (0), indicating that 2045 plain IPv4 encapsulation (without UDP) is used for data traffic. 2047 6. IANA Considerations 2049 This document defines four new Mobility Header options, IPv4 Home 2050 Address Request option, IPv4 Home Address Reply option, IPv4 Default 2051 Router Address option and IPv4 DHCP Support Mode option. These 2052 options are described in Sections 3.3.1, 3.3.2, 3.3.3 and 3.3.4 2053 respectively. The Type value for these options needs to be assigned 2054 from the same number space as allocated for the other mobility 2055 options, as defined in [RFC3775]. 2057 The IPv4 Home Address Reply option, described in Section 3.3.2 of 2058 this document, introduces a new number space, IPv4 Home Address Reply 2059 Status Codes. This document currently reserves the following values. 2060 Approval of any new status code values are to be made through IANA 2061 Expert Review. 2063 o 0 Success 2065 o 128 Failure, reason unspecified 2067 o 129 Administratively prohibited 2069 o 130 Incorrect IPv4 home address 2071 o 131 Invalid IPv4 address 2073 o 132 Dynamic IPv4 home address assignment not available 2075 The IPv4 DHCP Support Mode option, described in Section 3.3.4 of this 2076 document, introduces a new number space, IPv4 DHCP Support Mode 2077 Flags. This document reserves the value 0x1 for the (S) flag. 2078 Approval of this flag values are to be made through IANA Expert 2079 Review. At this point of time there are no thoughts on what the new 2080 flag allocations can be for and hence this document is leaving this 2081 to the discretion of the expert review. 2083 This document also defines new status values, used in Proxy Binding 2084 Acknowledgement message, as described in Section 3.3.5. These values 2085 are to be assigned from the same number space as allocated for other 2086 Status codes [RFC3775]. Each of these allocated values have to be 2087 greater than 128. 2089 NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE: IANA 2091 Mobile node not authorized for IPv4 mobility service. 2093 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 2095 Mobile node not authorized for the requesting IPv4 home address 2097 NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE: IANA 2099 Mobile node not authorized for IPv6 mobility service. 2101 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED: IANA 2103 Multiple IPv4 home address assignment not supported 2105 IANA is requested to assign two UDP port numbers, TBD1 and TBD2, for 2106 "pmip6-cntl" and "pmip6-data", respectively. 2108 7. Security Considerations 2110 All the security considerations from the base Proxy Mobile IPv6 2111 [RFC5213], Mobile IPv6 [RFC3775], and Dual-Stack Mobile IPv6 2112 [RFC5555] apply when using the extensions defined in this document. 2113 Additionally, the following security considerations need to be 2114 applied. 2116 This document defines new mobility options for supporting the IPv4 2117 Home Address assignment and IPv4 Transport Support features. These 2118 options are to be carried in Proxy Binding Update and Proxy Binding 2119 Acknowledgement messages. The required security mechanisms specified 2120 in the base Proxy Mobile IPv6 protocol for protecting these signaling 2121 messages are sufficient when carrying these mobility options. 2123 This specification describes the use of IPv4 transport for exchanging 2124 the signaling messages between the local mobility anchor and the 2125 mobile access gateway. These can be protected using IPsec as 2126 described in Section 4.3. 2128 8. Contributors 2130 This document reflects discussions and contributions from several 2131 people (in alphabetical order): 2133 Kuntal Chowdhury 2135 kchowdhury@starentnetworks.com 2137 Vijay Devarapalli 2139 vijay.devarapalli@azairenet.com 2141 Sangjin Jeong 2143 sjjeong@etri.re.kr 2145 Basavaraj Patil 2147 basavaraj.patil@nokia.com 2149 Myungki Shin 2151 myungki.shin@gmail.com 2153 9. Acknowledgments 2155 The IPv4 support for Proxy Mobile IPv6 was initially covered in the 2156 internet-draft [draft-sgundave-mip6-proxymip6-02.txt"/>. We would 2157 like to thank all the authors of the document and acknowledge that 2158 initial work. 2160 Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles 2161 Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen, 2162 Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Pasi Eronen, 2163 Premec Domagoj, Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe 2164 Wu and Zu Qiang for their helpful review of this document. 2166 Also, we would like to thank Spencer Dawkins, Tim Polk and Menachem 2167 Dodge, Adrian Farrel and Pekka Savola for their reviews of this 2168 document as part of the IESG review process. Finally, special thanks 2169 to Jouni Korohonen for his support in addressing the IPsec issues. 2171 10. References 2172 10.1. Normative References 2174 [I-D.ietf-netlmm-grekey-option] 2175 Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 2176 "GRE Key Option for Proxy Mobile IPv6", 2177 draft-ietf-netlmm-grekey-option-09 (work in progress), 2178 May 2009. 2180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2181 Requirement Levels", BCP 14, RFC 2119, March 1997. 2183 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2184 RFC 2131, March 1997. 2186 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 2187 Extensions", RFC 2132, March 1997. 2189 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2190 IPv6 Specification", RFC 2473, December 1998. 2192 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 2193 RFC 3046, January 2001. 2195 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 2196 in IPv6", RFC 3775, June 2004. 2198 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2199 for IPv6 Hosts and Routers", RFC 4213, October 2005. 2201 [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client 2202 Identifiers for Dynamic Host Configuration Protocol 2203 Version Four (DHCPv4)", RFC 4361, February 2006. 2205 [RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, 2206 "DHCP Server Identifier Override Suboption", RFC 5107, 2207 February 2008. 2209 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 2210 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 2212 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 2213 Routers", RFC 5555, June 2009. 2215 10.2. Informative References 2217 [RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, 2218 October 1984. 2220 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 2221 (IPCP)", RFC 1332, May 1992. 2223 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2224 E. Lear, "Address Allocation for Private Internets", 2225 BCP 5, RFC 1918, February 1996. 2227 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2228 Address Translator (Traditional NAT)", RFC 3022, 2229 January 2001. 2231 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2232 RFC 4306, December 2005. 2234 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 2235 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 2237 [RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual 2238 Stack Mobility", RFC 4977, August 2007. 2240 Authors' Addresses 2242 Ryuji Wakikawa 2243 TOYOTA InfoTechnology Center, U.S.A., Inc. 2244 465 Bernardo Avenue 2245 Mountain View, CA 94043 2246 USA 2248 Email: ryuji@us.toyota-itc.com 2250 Sri Gundavelli 2251 Cisco 2252 170 West Tasman Drive 2253 San Jose, CA 95134 2254 USA 2256 Email: sgundave@cisco.com