idnits 2.17.1 draft-ietf-netlmm-pmip6-ipv4-support-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1910. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1921. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1928. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1934. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: All the considerations from Section 5.3.5 of [RFC-5213] MUST be applied. Additionally, for removing the IPv4 state as part of the Binding Cache entry deletion, the IPv4 host route and the dynamically created bi-directional tunnel for carrying the IPv4 payload traffic (if there are no other mobile nodes for which the tunnel is being used) MUST be removed. However, if the request is for a selective de-registration (IPv4 home address only, or all the IPv6 home network prefixes), the Binding Cache entry MUST not be deleted, only the respective states with respect to those addresses MUST be deleted. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The default value for this flag is set to value of 0, indicating that the local mobility anchor MUST not accept IPv4 UDP encapsulation request when NAT is not detected in the path. -- 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 (November 27, 2008) is 5629 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) == Missing Reference: 'NAT' is mentioned on line 158, but not defined == Missing Reference: 'RFC-1332' is mentioned on line 321, but not defined == Missing Reference: 'RFC-4306' is mentioned on line 321, but not defined ** Obsolete undefined reference: RFC 4306 (Obsoleted by RFC 5996) == Missing Reference: 'RFC-3046' is mentioned on line 1187, but not defined == Missing Reference: 'RFC-3948' is mentioned on line 1335, but not defined == Missing Reference: 'RFC-4301' is mentioned on line 1653, but not defined == Missing Reference: 'RFC3775' is mentioned on line 1768, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Unused Reference: 'RFC-2473' is defined on line 1840, but no explicit reference was found in the text == Unused Reference: 'RFC-3011' is defined on line 1858, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-06 Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 8 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: May 31, 2009 Cisco 6 November 27, 2008 8 IPv4 Support for Proxy Mobile IPv6 9 draft-ietf-netlmm-pmip6-ipv4-support-06.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 31, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document specifies extensions to Proxy Mobile IPv6 protocol for 43 adding IPv4 protocol support. The scope of IPv4 protocol support is 44 two-fold: 1) enable IPv4 home address mobility support to the mobile 45 node. 2) allowing the mobility entities in the Proxy Mobile IPv6 46 domain to exchange signaling messages over an IPv4 transport network. 48 Table of Contents 50 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 6 53 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8 54 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 55 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 57 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 58 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 59 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11 60 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11 61 3.1.3. Routing Considerations for the Local Mobility 62 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 16 63 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 17 64 3.2.1. Extensions to Binding Update List Entry . . . . . . . 17 65 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 17 66 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 18 67 3.2.4. Routing Considerations for the Mobile Access 68 Gateway . . . . . . . . . . . . . . . . . . . . . . . 21 69 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 22 70 3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 22 71 3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 23 72 3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 24 73 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 24 74 3.4.1. DHCP Server co-located with the Mobile Access 75 Gateway . . . . . . . . . . . . . . . . . . . . . . . 25 76 3.4.2. DHCP Relay Agent co-located with the Mobile Access 77 Gateway . . . . . . . . . . . . . . . . . . . . . . . 28 79 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 32 80 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 33 81 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 33 82 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 34 83 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 34 84 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 37 85 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 38 86 4.2.1. Extensions to Binding Update List Entry . . . . . . . 38 87 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 38 89 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 42 90 5.1. Local Mobility Anchor - Configuration Variables . . . . . 42 91 5.2. Mobile Access Gateway - Configuration Variables . . . . . 42 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 45 96 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 101 10.1. Normative References . . . . . . . . . . . . . . . . . . . 46 102 10.2. Informative References . . . . . . . . . . . . . . . . . . 47 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 105 Intellectual Property and Copyright Statements . . . . . . . . . . 49 107 1. Overview 109 The transition from IPv4 to IPv6 is a long process and during this 110 period of transition, both the protocols will be enabled over the 111 same network infrastructure. Thus, it is reasonable to assume that a 112 mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only 113 IPv6-only or in dual-stack mode and additionally the network between 114 the mobile access gateway and a local mobility anchor may be an IPv4 115 or an IPv6 network. It is also reasonable to expect the same 116 mobility infrastructure in the Proxy Mobile IPv6 domain to provide 117 mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode 118 and when the network between the local mobility anchor and the mobile 119 access gateway is an IPv4 or an IPv6 network. The motivation and 120 scope of IPv4 support in Mobile IPv6 is summarized in [RFC-4977] and 121 all those requirements apply to Proxy Mobile IPv6 protocol as well. 123 The Proxy Mobile IPv6 protocol [RFC-5213] specifies a mechanism for 124 providing IPv6 home address mobility support to a mobile node in a 125 Proxy Mobile IPv6 domain. The protocol requires IPv6 transport 126 network between the mobility entities. The extensions defined in 127 this document extends IPv4 support to the Proxy Mobile IPv6 protocol 128 [RFC-5213]. 130 The scope of IPv4 support in Proxy Mobile IPv6 includes the support 131 for the following two features: 133 o IPv4 Home Address Mobility Support: A mobile node that has an IPv4 134 stack enabled will be able to obtain an IPv4 address and be able 135 to use that address from any of the access networks in that Proxy 136 Mobile IPv6 domain. The mobile node is not required to be 137 allocated or assigned an IPv6 address for enabling IPv4 home 138 address support. 140 o IPv4 Transport Network Support: The mobility entities in the Proxy 141 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 142 signaling messages over an IPv4 transport and furthermore the 143 mobile access gateway may be using an IPv4 private address and 144 with NAT [RFC-3022] translation devices on the path to the local 145 mobility anchor. 147 These two features, the IPv4 Home Address Mobility support and the 148 IPv4 transport support features, are independent of each other and 149 deployments may choose to enable any one or both of these features as 150 required. 152 +----+ +----+ 153 |LMA1| |LMA2| 154 +----+ +----+ 155 IPv4-LMAA1 -> | | <-- LMAA2 156 | | 157 \\ //\\ 158 [NAT] // \\ 159 \\ // \\ 160 +---\\------------- //------\\----+ 161 ( \\ IPv4/IPv6 // \\ ) 162 ( \\ Network // \\ ) 163 +------\\--------//------------\\-+ 164 \\ // \\ 165 \\ // \\ 166 \\ // \\ 167 IPv4-Proxy-CoA1--> | | <-- Proxy-CoA2 168 +----+ +----+ 169 |MAG1|-----{MN2} |MAG2| 170 +----+ | +----+ 171 (IPv6 MN-HoA1) | | | <-- (IPv6 MN-HoA2) 172 (IPv4-MN-HoA1) --> | (IPv4-MN-HoA2) | <-- (IPv4-MN-HoA3) 173 {MN1} {MN3} 175 Figure 1: IPv4 support for Proxy Mobile IPv6 177 1.1. Stated Assumptions 179 The following are the configuration requirements from the mobility 180 entities in the Proxy Mobile IPv6 domain for supporting the 181 extensions defined in this document. 183 o The local mobility anchor and the mobile access gateway are both 184 IPv4 and IPv6 enabled. Irrespective of the type of transport 185 network (IPv4 or IPv6) separating these two entities, the mobility 186 signaling is always based on Proxy Mobile IPv6 [RFC-5213]. 188 o The local mobility anchor and the mobile access gateway MUST be 189 configured with IPv6 global addresses, even when they are in IPv4- 190 only network. When using IPv4 transport, it is not required that 191 there is IPv6 routing enabled between the local mobility anchor 192 and the mobile access gateway. However, there must be IPv6 193 routing enabled for the configured address locally within the 194 host. 196 o The mobile node can be operating in IPv4-only, IPv6-only or in 197 dual mode. Based on what is enabled for a mobile node, it should 198 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 199 address(es) for its interface and furthermore achieve mobility 200 support for those addresses. 202 o For enabling IPv4 home address mobility support to a mobile node, 203 it is not required that the IPv6 home address mobility support 204 needs to enabled. However, the respective protocol(s) support, 205 such as IPv4 or IPv6 packet forwarding, must be enabled on the 206 access link between the mobile node and the mobile access gateway. 208 o The mobile node can obtain an IPv4 address for its attached 209 interface. Based on the type of link, it may be able to acquire 210 its IPv4 address configuration using standard IPv4 address 211 configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332], 212 IKEv2 [RFC-4306] or static address configuration. 214 o The mobile node's IPv4 home subnet is typically a shared address 215 space. It is not for the exclusive use of any one mobile node. 216 There can be multiple mobile nodes that are assigned IPv4 217 addresses from the same subnet. 219 o The mobile access gateway is the IPv4 default-router for the 220 mobile node on its access link. It will be in the forwarding path 221 for the mobile node's data traffic. 223 2. Conventions & Terminology 225 2.1. Conventions 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 229 document are to be interpreted as described in RFC 2119 [RFC-2119]. 231 2.2. Terminology 233 All the mobility related terms used in this document are to be 234 interpreted as defined in the Mobile IPv6 specification [RFC-3775] 235 and Proxy Mobile IPv6 specification [RFC-5213]. In addition this 236 document introduces the following terms. 238 IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) 240 The IPv4 address that is configured on the egress-interface of the 241 mobile access gateway. When using IPv4 transport, this address 242 will be the registered care-of address in the mobile node's 243 Binding Cache entry and will also be the transport-endpoint of the 244 tunnel between the local mobility anchor and a mobile access 245 gateway. However, if the configured address is a private IPv4 246 address and with a NAT device in the path to the local mobility 247 anchor, the care-of address as seen by the local mobility anchor 248 will be the address allocated by the NAT device for that flow. 250 IPv4 Local Mobility Anchor Address (IPv4-LMAA) 252 The IPv4 address that is configured on the egress-interface of the 253 local mobility anchor. When using IPv4 transport, the mobile 254 access gateway sends the Proxy Binding Update messages to this 255 address and will be the transport-endpoint of the tunnel between 256 the local mobility anchor and the mobile access gateway. 258 Mobile Node's IPv4 Home Address (IPv4-MN-HoA) 260 This is the IPv4 home address assigned to the mobile node's 261 attached interface. This address is topologically anchored at the 262 local mobility anchor. The mobile node configures this address on 263 its attached interface. If the mobile node connects to the Proxy 264 Mobile IPv6 domain via multiple interfaces each of the interfaces 265 are assigned a unique IPv4 address. All the IPv6 home network 266 prefixes and the IPv4 home address assigned to a given interface 267 of a mobile node will be managed under one mobility session. 269 Selective De-registration 270 It is a procedure for partial de-registration of all the addresses 271 that belong to one address family, i.e., de-registration of either 272 IPv4 home address, or all of the IPv6 home network prefixes. 274 Encapsulation Modes 276 This document uses the following terms when referring to the 277 different encapsulation modes. 279 IPv4-over-IPv6 281 IPv4 packet carried as a payload of an IPv6 packet 283 IPv4-over-IPv4 285 IPv4 packet carried as a payload of an IPv4 packet 287 IPv4-over-IPv4-UDP 289 IPv4 packet carried as a payload in an UDP header of an IPv4 290 packet 292 IPv4-over-IPv4-UDP-TLV 294 IPv4 packet carried as a payload in an IPv4 packet with UDP and 295 TLV headers 297 3. IPv4 Home Address Mobility Support 299 The IPv4 home address mobility support essentially enables a mobile 300 node in a Proxy Mobile IPv6 domain to obtain IPv4 home address 301 configuration for its attached interface and be able to retain that 302 address configuration even after changing its point of attachment in 303 that Proxy Mobile IPv6 domain. This section describes the protocol 304 operation and the required extensions to Proxy Mobile IPv6 protocol 305 for extending IPv4 home address mobility support. 307 When an IPv4-enabled or a dual-stack enabled mobile node attaches to 308 the Proxy Mobile IPv6 domain, the mobile access gateway on the access 309 link where the mobile node is attached will identify the mobile node 310 and will initiate the Proxy Mobile IPv6 signaling with the mobile 311 node's local mobility anchor. The mobile access gateway will follow 312 the signaling considerations specified in Section 3.2 for requesting 313 IPv4 home address mobility support. Upon the completion of the 314 signaling, the local mobility anchor and the mobile access gateway 315 will establish the required routing states for allowing the mobile 316 node to use its IPv4 home address from its current point of 317 attachment. 319 The mobile node on the access link using any of the standard IPv4 320 address configuration mechanisms supported on that access link, such 321 as IPCP [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], will be able 322 to obtain an IPv4 home address (IPv4-MN-HoA) for its attached 323 interface. Although the address configuration mechanisms for 324 delivering the address configuration to the mobile node is 325 independent of the Proxy Mobile IPv6 protocol operation, however 326 there needs to be some interactions between these two protocol flows. 327 Section 3.4 identifies these interactions for supporting DHCP based 328 address configuration. 330 The support for IPv4 home address mobility is not dependent on the 331 IPv6 home address mobility support. It is not required that the IPv6 332 home address mobility support needs to be enabled for providing IPv4 333 home address mobility support. A mobile node will be able to obtain 334 IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its 335 attached interface. The mobile node's policy profile will determine 336 if the mobile node is entitled for both the protocol versions or a 337 single protocol version. Based on the policy, only those protocols 338 will be enabled on the access link. Furthermore, if the mobile node 339 after obtaining the address configuration on its interface performs 340 an handoff, either by changing its point of attachment over the same 341 interface or to a different interface, the network will ensure the 342 mobile node will be able to use the same IPv4 address configuration 343 after the handoff. 345 Additionally, If the mobile node connects to the Proxy Mobile IPv6 346 domain, through multiple interfaces and simultaneously through 347 different access networks, each of the connected interfaces will 348 obtain an IPv4 home address from different subnets. In such 349 scenario, there will be multiple Binding Cache entries for the mobile 350 node on the local mobility anchor. All the address (IPv4/IPv6) 351 assigned to a given interface will be managed as part of one mobility 352 session, as specified in Section 5.4 of [RFC-5213]. 354 3.1. Local Mobility Anchor Considerations 356 3.1.1. Extensions to Binding Cache Entry 358 To support this feature, the conceptual Binding Cache entry data 359 structure maintained by the local mobility anchor needs to be 360 extended with the following additional parameters. 362 o The IPv4 home address assigned to the mobile node's interface and 363 registered by the mobile access gateway. The IPv4 home address 364 entry also includes the corresponding subnet mask. 366 o The IPv4 default-router address assigned to the mobile node. 368 3.1.2. Signaling Considerations 370 3.1.2.1. Processing Proxy Binding Updates 372 The processing rules specified in Section 5.3 of [RFC-5213] are 373 applied for processing the received Proxy Binding Update message. 374 However, if the received Proxy Binding Update message has an IPv4 375 Home Address option [ID-DSMIP6], the following considerations MUST be 376 applied additionally. 378 o If there is an IPv4 Home Address option [ID-DSMIP6] present in the 379 received Proxy Binding Update message, but if there is no Home 380 Network Prefix option [RFC-5213] present in the request, the local 381 mobility anchor MUST NOT reject the request as specified in 382 Section 5.3.1 of [RFC-5213]. At least one instance of any of 383 these two options MUST be present. If there is not a single 384 instance of any of these two options present in the request, the 385 local mobility anchor MUST reject the request and send a Proxy 386 Binding Acknowledgement message with Status field set to 387 MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home 388 network prefix option) [RFC-5213]. 390 o If there is at least one instance of Home Network Prefix option 391 [RFC-5213] present in the received Proxy Binding Update message, 392 but either if the mobile node is not IPv6 enabled, or if IPv6 393 routing not enabled in the home network, the local mobility anchor 394 SHOULD reject the request and send a Proxy Binding Acknowledgement 395 message with the Status field set to 396 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX (mobile node not 397 authorized for the requesting IPv6 home network prefix). 399 o For associating the received Proxy Binding Update message to an 400 existing mobility session, the local mobility anchor MUST perform 401 the Binding Cache entry existence test by applying the following 402 considerations. 404 * If there is at least one instance of the Home Network Prefix 405 option [RFC-5213] with a NON_ZERO prefix value, or, if there is 406 an IPv4 Home Address option [ID-DSMIP6] with the IPv4 address 407 in the option set to ALL_ZERO, considerations from Section 408 5.4.1 of [RFC-5213] MUST be applied. 410 * If there is an IPv4 Home Address option [ID-DSMIP6] present in 411 the request with the IPv4 address value in the option set to a 412 NON_ZERO value, considerations from Section 3.1.2.7 MUST be 413 applied. 415 o If there is no existing Binding Cache entry that can be associated 416 with the request, the local mobility anchor MUST consider this 417 request as an initial binding registration request and 418 considerations from Section 3.1.2.2 MUST be applied. 419 Additionally, if there are one or more Home Network Prefix options 420 [RFC-5213] present in the request, considerations from Section 421 5.3.2 of [RFC-5213] MUST also be applied. 423 o If there exists a Binding Cache entry that can be associated with 424 the request, the local mobility anchor MUST apply considerations 425 from Section 5.3.1 of [RFC-5213], (point 13), to determine if the 426 request is re-registration or a de-registration request and the 427 respective considerations from the below sections MUST be applied. 429 o If there exists a Binding Cache entry that can be associated with 430 the request and if it is determined that the request is a re- 431 registration request and with the request to extend IPv4 home 432 address mobility support to the existing IPv6-only mobility 433 session, considerations from Section 3.1.2.2 MUST be applied with 434 respect to IPv4 support. 436 3.1.2.2. Initial Binding Registration (New Mobility Session) 438 o If there is an IPv4 Home Address option [ID-DSMIP6] present in the 439 Proxy Binding Update message with the IPv4 address value in the 440 option set to ALL_ZERO, the local mobility anchor MUST allocate an 441 IPv4 home address to the mobile node and associate it with the new 442 mobility session created for that mobile node. 444 o If there is an IPv4 Home Address option [ID-DSMIP6] with the IPv4 445 address in the option set to a NON_ZERO value, the local mobility 446 anchor before accepting the request MUST ensure the address is 447 topologically anchored on the local mobility anchor and 448 furthermore the mobile node is authorized to use that address. If 449 the mobile node is not authorized for that specific address, the 450 local mobility anchor MUST reject the request and send a Proxy 451 Binding Acknowledgement message with the Status field set to 452 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized 453 for the requesting IPv4 address). It MUST also include the IPv4 454 Address Acknowledgement option [ID-DSMIP6] in the reply with the 455 status field value in the option set to 129 (Administratively 456 prohibited). 458 o If the local mobility anchor is unable to allocate an IPv4 address 459 due to lack of resources, it MUST reject the request and send a 460 Proxy Binding Acknowledgement message with Status field set to 130 461 (Insufficient resources). It MUST also include the IPv4 Address 462 Acknowledgement option [ID-DSMIP6] in the reply with the status 463 field value in the option set to 128 (Failure, reason 464 unspecified). 466 o Upon accepting the request, the local mobility anchor MUST create 467 a Binding Cache entry for this mobility session. However, if the 468 request also contains one or more Home Network Prefix options [ID- 469 DSMIP6], there should still be only one Binding Cache entry that 470 should be created for this mobility session. The created Binding 471 Cache entry MUST be used for managing both IPv4 and IPv6 home 472 address bindings. The fields in the Binding Cache entry MUST be 473 updated with the accepted values for that session. 475 o The local mobility anchor MUST establish a bi-directional tunnel 476 to the mobile access gateway and with the encapsulation mode set 477 to the negotiated mode for carrying the IPv4 payload traffic. 478 When using IPv6 transport, the encapsulation mode is IPv4-over- 479 IPv6 (IPv4 packet carried as a payload of an IPv6 packet). When 480 using IPv4 transport, the encapsulation mode is as specified in 481 Section 4.0. 483 o The local mobility anchor MUST create an IPv4 host route (or a 484 platform specific equivalent function that sets up the forwarding) 485 for tunneling the packets received for the mobile node's home 486 address associated with this mobility session. 488 o The local mobility anchor MUST send the Proxy Binding 489 Acknowledgement message with the Status field set to 0 (Proxy 490 Binding Update Accepted). The message MUST be constructed as 491 specified in Section 3.1.2.6. 493 3.1.2.3. Binding Lifetime Extension (No handoff) 495 All the considerations from Section 5.3.3 of [RFC-5213] MUST be 496 applied. 498 3.1.2.4. Binding Lifetime Extension (After handoff) 500 o If there is no Home Network Prefix option(s) [RFC-5213] present in 501 the request, but if the Binding Cache entry associated with this 502 request has IPv6 home network prefix(es), the local mobility 503 anchor MUST consider this as a request to extend lifetime only for 504 the IPv4 home address and not for the IPv6 home network 505 prefix(es). Hence, the local mobility anchor SHOULD release all 506 the IPv6 home network prefix(es) assigned to that mobile node and 507 for that specific attached interface. Similar considerations 508 apply for the case where there is no IPv4 Home Address option [ID- 509 DSMIP6] present in the request, but if the Binding Cache entry 510 associated with that request has both IPv4 home address and IPv6 511 home network prefix(es). 513 o The local mobility anchor MUST remove the previously created IPv4 514 host route (or the forwarding state) and the dynamically created 515 bi-directional tunnel for carrying the IPv4 payload traffic (if 516 there are no other mobile nodes for which the tunnel is being 517 used). This will remove the routing state towards the mobile 518 access gateway where the mobile node was anchored prior to the 519 handoff. 521 o The local mobility anchor MUST create a bi-directional tunnel to 522 the mobile access gateway that sent the request (if there is no 523 existing bi-directional tunnel) and with the encapsulation mode 524 set to the negotiated mode for carrying the IPv4 payload traffic. 525 An IPv4 host route for tunneling the packets received for the 526 mobile node's IPv4 home address MUST also be added. 528 o The required forwarding state identified in Section 5.3.6 of [RFC- 529 5213] is for IPv6 payload traffic. Those considerations apply for 530 IPv4 payload traffic as well. However, if IPv4 transport is in 531 use, considerations from Section 4.0 MUST be applied. 533 3.1.2.5. Binding De-Registration 535 All the considerations from Section 5.3.5 of [RFC-5213] MUST be 536 applied. Additionally, for removing the IPv4 state as part of the 537 Binding Cache entry deletion, the IPv4 host route and the dynamically 538 created bi-directional tunnel for carrying the IPv4 payload traffic 539 (if there are no other mobile nodes for which the tunnel is being 540 used) MUST be removed. However, if the request is for a selective 541 de-registration (IPv4 home address only, or all the IPv6 home network 542 prefixes), the Binding Cache entry MUST not be deleted, only the 543 respective states with respect to those addresses MUST be deleted. 545 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 547 The local mobility anchor when sending the Proxy Binding 548 Acknowledgement message to the mobile access gateway MUST construct 549 the message as specified in Section 5.3.6 of [RFC-5213]. 550 Additionally, the following considerations MUST be applied. 552 o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to 553 include at least one instance of Home Network Prefix option [RFC- 554 5213] in the Proxy Binding Acknowledgement message that it sends 555 to the mobile access gateway. However, if the received Proxy 556 Binding Update message has only the IPv4 Home Address option [ID- 557 DSMIP6] and did not contain the Home Network Prefix option(s), 558 then the local mobility anchor MUST NOT include any Home Network 559 Prefix option(s) in the reply. However, there MUST be at least 560 one instance of either the Home Network Prefix option [RFC-5213] 561 or the IPv4 Address Acknowledgement option [ID-DSMIP6] present in 562 the Proxy Binding Acknowledgement message. 564 o The IPv4 Address Acknowledgement option [ID-DSMIP6] MUST be 565 present in the Proxy Binding Acknowledgement message. 567 1. If the Status field is set to a value greater than or equal to 568 128, i.e., if the Proxy Binding Update is rejected, then there 569 MUST be an IPv4 Address Acknowledgement option [ID-DSMIP6] 570 corresponding to the IPv4 Home Address option [ID-DSMIP6] 571 present in the request and with the IPv4 address value and the 572 prefix length fields in the option set to the corresponding 573 values in the request. The status field value in the option 574 must be set to the specific error code. 576 2. For all other cases, there MUST be an IPv4 Address 577 Acknowledgement option for carrying the IPv4 home address 578 assigned for that mobility session and with the value in the 579 option set to the allocated IPv4 address. The prefix length 580 in the option MUST be set to the prefix length of the 581 allocated address. The status field value in the option must 582 be set to 0 (Success). 584 o The IPv4 Default-Router Address option MUST be present, if the 585 Status field value in the Proxy Binding Acknowledgement message is 586 set to 0 (Proxy Binding Update Accepted). Otherwise, the option 587 MUST NOT be present. If the option is present, the default-router 588 address in the option MUST be set to the mobile node's default- 589 router address. 591 3.1.2.7. Binding Cache Entry Lookup Considerations 593 The Binding Cache entry lookup considerations specified in Section 594 5.4.1.1 of [RFC-5213] requires the Home Network Prefix [RFC-5213] as 595 the key parameter for identifying the Binding Cache entry. When 596 using an IPv4 address with a NON_ZERO value, the exact same 597 considerations specified in Section 5.4.1.1 of [RFC-5213] MUST be 598 applied, with the exception of using an IPv4 home address in place of 599 an IPv6 home network prefix. 601 3.1.3. Routing Considerations for the Local Mobility Anchor 603 Intercepting Packets Sent to the Mobile Node's IPv4 home address: 605 o When the local mobility anchor is serving a mobile node, it MUST 606 be able to receive packets that are sent to the mobile node's IPv4 607 home address. In order for it to receive those packets, it MUST 608 advertise a connected route in to the Routing Infrastructure for 609 the mobile node's IPv4 home address or for its home subnet. This 610 essentially enables IPv4 routers in that network to detect the 611 local mobility anchor as the last-hop router for that subnet. 613 Forwarding Packets to the Mobile Node: 615 o On receiving a packet from a correspondent node with the 616 destination address matching the mobile node's IPv4 home address, 617 the local mobility anchor MUST forward the packet through the bi- 618 directional tunnel setup for that mobile node. 620 o The format of the tunneled packet when payload protection is not 621 enabled: 623 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 624 IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ 625 Upper layer protocols /* Packet Content*/ 627 Figure 2: Tunneled Packets from LMA to MAG 629 Forwarding Packets Sent by the Mobile Node: 631 o All the reverse tunneled packets that the local mobility anchor 632 receives from the mobile access gateway, after removing the tunnel 633 header MUST be routed to the destination specified in the inner 634 IPv4 packet header. These routed packets will have the source 635 address field set to the mobile node's IPv4 home address. 637 3.2. Mobile Access Gateway Considerations 639 3.2.1. Extensions to Binding Update List Entry 641 To support the IPv4 home address mobility feature, the conceptual 642 Binding Update List entry data structure needs to be extended with 643 the following additional fields. 645 o The IPv4 home address assigned to the mobile node's attached 646 interface. This IPv4 home address may have been statically 647 configured in the mobile node's policy profile, or, may have been 648 dynamically allocated by the local mobility anchor. The IPv4 home 649 address entry also includes the corresponding subnet mask. 651 o The IPv4 default-router address of the mobile node. This is 652 acquired from the mobile node's local mobility anchor through the 653 received Proxy Binding Acknowledgment message. 655 3.2.2. Extensions to Mobile Node's Policy Profile 657 To support the IPv4 Home Address Mobility Support feature the mobile 658 node's policy profile, specified in Section 6.2 of [RFC-5213] MUST be 659 extended with the following additional fields. 661 Extensions to the mandatory section of the policy profile: 663 o This field identifies all the IP protocol versions for which the 664 home address mobility support needs to be extended to the mobile 665 node. The supported modes are IPv4-only, IPv6-only and dual IPv4/ 666 IPv6. 668 Extensions to the optional section of the policy profile: 670 o The IPv4 home address assigned to the mobile node's attached 671 interface. The specific details on how the network maintains the 672 association between the address and the attached interface is 673 outside the scope of this document. This address field also 674 includes the corresponding subnet mask. 676 3.2.3. Signaling Considerations 678 3.2.3.1. Mobile Node Attachment and Initial Binding Registration 680 After detecting a new mobile node on its access link, the mobile 681 access gateway on the access link MUST determine if IPv4 home address 682 mobility support needs to be enabled for that mobile node. The 683 mobile node's policy profile identifies the supported modes (IPv4- 684 only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the 685 mobile service needs to be enabled. Based on those policy 686 considerations and from other triggers such as from the network, if 687 it is determined that IPv4 home address mobility support needs to be 688 enabled for the mobile node, considerations from section 6.9.1.1 of 689 [RFC-5213] MUST be applied with the following exceptions. 691 o The IPv4 Home Address option [ID-DSMIP6] MUST be present in the 692 Proxy Binding Update message. 694 * If the mobile access gateway learns the mobile node's IPv4 home 695 address either from its policy profile, or from other means, 696 the mobile access gateway MAY ask the local mobility anchor to 697 allocate that specific address by including exactly one 698 instance of the IPv4 Home Address option [ID-DSMIP6] with the 699 IPv4 home address and the prefix length fields in the option 700 set to that specific address and its prefix length. 701 Furthermore, the (P) flag in the option MUST be set to 0. 703 * The mobile access gateway MAY also ask the local mobility 704 anchor for dynamic IPv4 home address allocation. It can 705 include exactly one instance of the IPv4 Home Address option 706 with the IPv4 home address and the prefix length fields in the 707 option set to ALL_ZERO value. Furthermore, the (P) flag in the 708 option MUST be set to 0. This essentially serves as a request 709 to the local mobility anchor for the IPv4 home address 710 allocation. 712 o The Proxy Binding Update message MUST be constructed as specified 713 in Section 6.9.1.5 of [RFC-5213]. However, the Home Network 714 Prefix option(s) [RFC-5213] MUST be present in the Proxy Binding 715 Update only if IPv6 home address mobility support also needs to be 716 enabled for the mobile node. Otherwise, the Home Network Prefix 717 option(s) MUST NOT be present. 719 o When using IPv4 transport for carrying the signaling messages, the 720 related considerations from section 4.0 MUST be applied 721 additionally. 723 3.2.3.2. Receiving Proxy Binding Acknowledgement 725 All the considerations from section 6.9.1.2 of [RFC-5213] MUST be 726 applied with the following exceptions. 728 o If the received Proxy Binding Acknowledgement message has the 729 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 730 mobile node is not authorized for IPv4 home address), the mobile 731 access gateway SHOULD NOT send a Proxy Binding Update message 732 including the IPv4 Home Address option [ID-DSMIP6] till an 733 administrative action is taken. 735 o If the received Proxy Binding Acknowledgement message has the 736 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 737 mobile node is not authorized for the requesting IPv4 home 738 address), the mobile access gateway SHOULD NOT request for the 739 same address again, but MAY request the local mobility anchor to 740 do the assignment of address by including exactly one instance of 741 IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address 742 and the prefix length fields in the option set to ALL_ZERO value. 744 o If there is no IPv4 Address Acknowledgement option [ID-DSMIP6] 745 present in the received Proxy Binding Acknowledgement message, the 746 mobile access gateway MUST NOT enable IPv4 support for the mobile 747 node and the rest of the considerations from this section can be 748 skipped. 750 o If the received Proxy Binding Acknowledgement message has the 751 Status field value in the IPv4 Address Acknowledgement Option [ID- 752 DSMIP6] set to a value that indicates that the request was 753 rejected by the local mobility anchor, the mobile access gateway 754 MUST NOT enable forwarding for that specific IPv4 home address. 756 o If the received Proxy Binding Acknowledgement message has the 757 Status field value set to 0 (Proxy Binding Update accepted), the 758 mobile access gateway MUST update a Binding Update List entry for 759 that mobile node. The entry MUST be updated with the assigned 760 IPv4 home address and other accepted registration values. 762 o If the received Proxy Binding Acknowledgement message has the 763 Status field value set to 0 (Proxy Binding Update accepted) and 764 has the IPv4 Address Acknowledgement Option [ID-DSMIP6] set to a 765 value that indicates that the request was accepted by the local 766 mobility anchor, the mobile access gateway MUST establish a bi- 767 directional tunnel to the local mobility anchor (if there is no 768 existing bi-directional tunnel to that local mobility anchor) and 769 with the encapsulation mode set to IPv4-over-IPv6 (IPv4 packet 770 carried as a payload of an IPv6 packet). Considerations from 771 Section 5.6.1 of [RFC-5213] MUST be applied for managing the 772 dynamically created bi-directional tunnel. However, when using 773 IPv4 transport, the encapsulation mode MUST be set to the 774 negotiated encapsulation mode, as specified in Section 4 of this 775 specification. 777 o The mobile access gateway MUST set up the route for forwarding the 778 IPv4 packets received from the mobile node (using its IPv4 home 779 address) through the bi-directional tunnel set up for that mobile 780 node. 782 o If there is an IPv4 Default-Router Address option present in the 783 received Proxy Binding Acknowledgement message, the mobile access 784 gateway MAY configure this address on its interface and respond to 785 any ARP requests sent by the mobile node for resolving the 786 hardware address of the default-router. It MAY also use this 787 address as the source address for any datagrams sent to the mobile 788 node and originated by the mobile access gateway itself. It MAY 789 also use this address in the DHCP Router option [RFC-2132] in the 790 DHCP messages. 792 o If there is an IPv4 DHCP Support Mode option present in the 793 received Proxy Binding Acknowledgement message and if the (S) flag 794 in the option is set to a value of 1, then the mobile access 795 gateway MUST function as a DHCP server for the mobile node. If 796 either the (S) flag in the option is set to a value of 0, or if 797 the option is not present in the request, then the mobile access 798 gateway MUST function as a DHCP Relay for the mobile node. 800 3.2.3.3. Binding Re-Registration and De-Registrations 802 When sending a Proxy Binding Update either for extending the lifetime 803 of a mobility session or for de-registering the mobility session, the 804 respective considerations from [RFC-5213] MUST be applied. 805 Furthermore, the following additional considerations MUST also be 806 applied. 808 o If there is an IPv4 home address assigned to the mobility session, 809 then there MUST be exactly one instance of the IPv4 Home Address 810 option [ID-DSMIP6] present in the Proxy Binding Update message. 811 The IPv4 home address and the prefix length fields in the option 812 MUST be set to that specific address and its corresponding subnet- 813 mask length. The (P) flag in the option MUST be set to 0. 815 o If there was no IPv4 home address requested in the initial Proxy 816 Binding Update message, but if it is determined that the IPv4 home 817 address MUST be requested subsequently, then there MUST be exactly 818 one instance of the IPv4 Home Address option [ID-DSMIP6] present 819 in the Proxy Binding Update message. The IPv4 home address in the 820 option MUST be set to either ALL_ZERO or to a specific address 821 that is being requested. 823 o For performing selective de-registration of IPv4 home address but 824 still retaining the mobility session with all the IPv6 home 825 network prefixes, the Proxy Binding Update message with the 826 lifetime value of 0 MUST NOT include any IPv6 Home Network Prefix 827 options(s) [RFC-5213]. It MUST include exactly one instance of 828 the IPv4 Home Address option [ID-DSMIP6] with the IPv4 home 829 address and the prefix length fields in the option set to the IPv4 830 home address that is being de-registered. Similarly for selective 831 de-registration of all the IPv6 home network prefixes, the Proxy 832 Binding Update message MUST NOT include the IPv4 Home address 833 option, it MUST include a Home Network Prefix option for each of 834 the assigned home network prefixes assigned for that mobility 835 session and with the prefix value in the option set to that 836 respective prefix value. 838 o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present 839 if the same option(s) was not present in the initial Proxy Binding 840 Update message. Otherwise considerations from [RFC-5213] with 841 respect to this option MUST be applied. 843 3.2.4. Routing Considerations for the Mobile Access Gateway 845 o On receiving a packet from the bi-directional tunnel established 846 with the mobile node's local mobility anchor, the mobile access 847 gateway MUST remove the outer header before forwarding the packet 848 to the mobile node. 850 o Considerations from Section 6.10.3 of [RFC-5213] MUST be applied 851 with respect the local routing and on the use of 852 EnableMAGLocalRouting flag. 854 o On receiving a packet from a mobile node connected to its access 855 link, the packet MUST be forwarded to the local mobility anchor 856 through the bi-directional tunnel established with the local 857 mobility anchor. The encapsulation considerations specified in 858 section 3.1.3 MUST be applied. However, before forwarding the 859 packet, the mobile access gateway MUST ensure the source address 860 in the received packet is the address allocated for that mobile 861 node and that there is an active binding on the local mobility 862 anchor for that mobile node. 864 3.3. Mobility Options and Status Codes 866 To support the IPv4 home address mobility feature, this specification 867 defines the following new options and Status Codes. 869 3.3.1. IPv4 Default-Router Address Option 871 A new option, IPv4 Default-Router Address Option is defined for using 872 it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the 873 local mobility anchor to the mobile access gateway. This option can 874 be used for sending the mobile node's IPv4 default-router address. 876 The IPv4 Default-Router Address option has an alignment requirement 877 of 4n. Its format is as follows: 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Type | Length | Reserved (R) | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | IPv4 Default-Router Address | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Figure 3: IPv4 Default-Router Address Option 889 Type 891 IANA 893 Length 895 8-bit unsigned integer indicating the length of the option in 896 octets, excluding the type and length fields. This field MUST 897 be set to 6. 899 Reserved (R) 901 This 8-bit field is unused for now. The value MUST be 902 initialized to 0 by the sender and MUST be ignored by the 903 receiver. 905 IPv4 Default-Router Address 907 A four-byte field containing the mobile node's default router 908 address. 910 3.3.2. IPv4 DHCP Support Mode 912 A new option, IPv4 DHCP Support Mode Option is defined for using it 913 in the Proxy Binding Acknowledgment message [RFC-5213] sent by the 914 local mobility anchor to the mobile access gateway. This option can 915 be used for notifying the mobile access gateway, if it should 916 function as a DHCP Server or a DHCP Relay for the attached mobile 917 node. 919 The IPv4 DHCP Support Mode option has no alignment requirement. Its 920 format is as follows: 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | Type | Length | Reserved (R) |S| 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 Figure 4: IPv4 DHCP Support Mode Option 930 Type 932 IANA 934 Length 936 8-bit unsigned integer indicating the length of the option in 937 octets, excluding the type and length fields. This field MUST 938 be set to 2. 940 Reserved (R) 941 This 15-bit field is unused for now. The value MUST be 942 initialized to 0 by the sender and MUST be ignored by the 943 receiver. 945 DHCP Support Mode (S) 947 A 1-bit field that specifies the DHCP support mode. This flag 948 indicates if the mobile access gateway should function as a 949 DHCP Server or a DHCP Relay for the attached mobile node. The 950 flag value of (0) indicates the mobile access gateway should 951 act as a DHCP Relay and the flag value of (1) indicates it 952 should act as a DHCP Server. 954 3.3.3. Status Codes 956 This document defines the following new Status values for use in the 957 Proxy Binding Acknowledgement message [RFC-5213]. These values are 958 to be allocated from the same numbering space, as defined in Section 959 6.1.8 of [RFC-3775]. 961 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 963 Mobile node not authorized for the requesting IPv4 home address 965 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA 967 Mobile node not authorized for the requesting IPv6 home network 968 prefix(es). 970 3.4. Supporting DHCP-Based Address Configuration 972 This section explains how DHCP-based address configuration support 973 can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It 974 explains the protocol operation, supported DHCP server deployment 975 configurations and the protocol interactions between DHCP agents and 976 mobility entities in each of the supported configurations. 978 This specification supports the following two DHCP deployment 979 configurations. 981 o DHCP relay agent co-located with the mobile access gateway. 983 o DHCP server co-located in the mobile access gateway. 985 The following are the configuration requirements: 987 o The DHCP server or the DHCP relay agent configured on the mobile 988 access gateway is required to have an IPv4 address for exchanging 989 the DHCP messages with the mobile node. This address can be 990 either the IPv4 Proxy Care-of Address or the mobile node's 991 default-router address provided by the local mobility anchor. 992 Optionally, all the DHCP servers co-located with the mobile access 993 gateways in the Proxy Mobile IPv6 domain can be configured with a 994 fixed IPv4 address. This fixed address can be potentially an IPv4 995 link-local address [RFC-3927] that can be used for the DHCP 996 protocol communication on any of the access links. This address 997 will be used as the server identifier in the DHCP messages. 999 o The DHCP server identifies the DHCP client either from the client 1000 identifier or the client hardware address (chaddr) [RFC-2131]. A 1001 mobile node in a Proxy Mobile IPv6 domain may present any of these 1002 identifiers to the DHCP server as long as the identifier remains 1003 the same through out the mobile node's attachment in that Proxy 1004 Mobile IPv6 domain. If the client hardware address is used as the 1005 identifier and if the mobile node performs an handoff between two 1006 interfaces, this hardware identifier will change and the DHCP 1007 server will not be able to identify the mobile node. Thus, it is 1008 recommended that the DHCP client in a multihomed mobile node is 1009 configured to use a stable client identifier that does not change 1010 during the active life of its DHCP session. 1012 o All the DHCP servers co-located with the mobile access gateways in 1013 a Proxy Mobile IPv6 domain can be configured with the same set of 1014 DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure 1015 the mobile node receives the same configuration values on any of 1016 the access links in that Proxy Mobile IPv6 domain. 1018 3.4.1. DHCP Server co-located with the Mobile Access Gateway 1020 This section explains the operational sequence of home address 1021 assignment operation when the DHCP server is co-located with the 1022 mobile access gateway. 1024 MN MAG(DHCP-S) LMA 1025 |------>| | 1. DHCPDISCOVER 1026 | |------->| 2. Proxy Binding Update 1027 | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) 1028 | |========| 4. Tunnel/Route Setup 1029 |<------| | 5. DHCPOFFER (IPv4 HoA) 1030 |------>| | 6. DHCPREQUEST (IPv4 HoA) 1031 |<------| | 7. DHCPACK 1032 | | | 1033 * DHCPDISCOVER (Step-1) and Proxy Mobile IPv6 signaling 1034 * (Step-2 to Step-4) may happen in parallel and in no specific order 1035 * Tunnel/Route setup(Step-4) and the subsequent steps will happen in 1036 * in the specified order. 1038 Figure 5: Overview of DHCP Server located at Mobile Access Gateway 1040 Initial IPv4 Home Address Assignment: 1042 o When the mobile node sends a DHCPDISCOVER message [RFC-2131], the 1043 DHCP server co-located with the mobile access gateway will trigger 1044 the mobile access gateway to complete the Proxy Mobile IPv6 1045 signaling. This is the required interaction between these two 1046 protocols. If the mobile access gateway is unable to complete the 1047 Proxy Mobile IPv6 signaling, or, if the local mobility anchor does 1048 not assign an IPv4 address for the mobile node, the mobile access 1049 gateway MUST NOT enable IPv4 support for the mobile node on that 1050 access link. 1052 o After a successful completion of the Proxy Mobile IPv6 signaling 1053 and upon acquiring the mobile node's IPv4 home address from the 1054 local mobility anchor, the DHCP server on the mobile access 1055 gateway will send a DHCPOFFER message [RFC-2131] to the mobile 1056 node. The offered address will be the mobile node's IPv4 home 1057 address, assigned by the local mobility anchor. The server 1058 address, 'siaddr' field of the DHCPOFFER message, will be set to 1059 the mobile node's default-router address. The DHCPOFFER message 1060 will be unicasted to the mobile node. 1062 o If the mobile node sends the DHCPREQUEST message, the DHCP server 1063 will send DHCPACK message, as per [RFC-2131]. 1065 IPv4 Home Address Renewal with the DHCP server (No Handoff): 1067 o Any time the mobile node goes into the DHCP RENEWING state [RFC- 1068 2131], it simply unicasts the DHCPREQUEST message including the 1069 assigned IPv4 home address in the 'requested IP address' option. 1070 The DHCPREQUEST is sent to the address specified in 'server 1071 identifier' field of the previously received DHCPOFFER and DHCPACK 1072 messages. 1074 o The DHCP server will send a DHCPACK to the mobile node to 1075 acknowledge the assignment of the committed IPv4 address. 1077 IPv4 Home Address Renewal with a different DHCP server (After 1078 Handoff): 1080 When the mobile node goes into the DHCP RENEWING state [RFC-2131], it 1081 directly unicasts the DHCPREQUEST message to the DHCP server that 1082 currently provided the DHCP lease. However, if the mobile node 1083 changed its point of attachment and is attached to a new mobile 1084 access gateway, it is required that the mobile node updates the DHCP 1085 server address and uses the address of the DHCP server that is co- 1086 located with the new mobile access gateway. Any of the following 1087 approaches can be adopted to ensure the mobile node uses the DHCP 1088 server on the attached link. 1090 1. The use of fixed DHCP server address on all DHCP servers 1091 MN oMAG(DHCP-S) nMAG(DHCP-S) 1092 | : | 1093 RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) 1094 BOUND<-------------| 2. DHCPACK or DHCPNACK 1095 | : | 1097 2. The use of FORCERENEW message to notify the address change 1098 MN prev-MAG (DHCP-S) new-MAG (DHCP-S) 1099 | : | 1100 RENEW------------->| 1. DHCPREQUEST*a (IPv4 HoA) 1101 |<---------------| 2. FORCERENEW 1102 |--------------->| 3. DHCPREQUEST*b (IPv4 HoA) 1103 BOUND<-------------| 4. DHCPACK or DHCPNACK 1104 | : | 1105 *a DHCPREQUEST sent to oMAG 1106 *b DHCPREQUEST sent to nMAG 1108 Figure 6: Address renewal with a different DHCP server 1110 o If a fixed address such as the IPv4 default-router address of the 1111 mobile node is used as the DHCP server Id on any of the links in 1112 that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the 1113 mobile node for renewing the address will be received by the new 1114 mobile access gateway on the attached link. The mobile access 1115 gateway after completing the Proxy Mobile IPv6 signaling and upon 1116 acquiring the IPv4 home address of the mobile node will return the 1117 address in the DHCPACK message. However, if the mobile access 1118 gateway is unable to complete the Proxy Mobile IPv6 signaling or 1119 is unable to acquire the same IPv4 address as requested by the 1120 mobile node, it will send a DHCPNACK message [RFC-2131] to the 1121 mobile node, as shown in Figure 6-1). 1123 o If the mobile access gateway on the access link receives any DHCP 1124 messages from the mobile node unicasted to a server address that 1125 is not locally configured, the mobile access gateway can unicast 1126 FORCERENEW message [RFC-3203] to the mobile node as shown in 1127 Figure 6-2). This will force the mobile node to update the DHCP 1128 server address with the address of the mobile access gateway on 1129 the new link. However, if the FORCERENEW message [RFC-3203] is 1130 also not supported by the DHCP server on the mobile access 1131 gateway, then that DHCPREQUEST message can be ignored. This will 1132 force the mobile node to enter the DHCP REBINDING state [RFC-2131] 1133 and start the DHCPDISCOVER phase again. 1135 Additional Operation: 1137 o If at any point the mobile access gateway fails to extend the 1138 binding lifetime with the local mobility anchor for the mobile 1139 node's IPv4 address, it can send the unicast FORCERENEW message 1140 [RFC-3203] to the mobile node to force it to change its DHCP state 1141 to the RENEW state. Furthermore, it MUST remove forwarding for 1142 the mobile node's IPv4 home address. 1144 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway 1146 A DHCP relay agent is co-located with each mobile access gateway. A 1147 DHCP server is located somewhere in the Proxy Mobile IPv6 domain 1148 (e.g., is co-located with the local mobility anchor). Figure 7 shows 1149 the sequence of IPv4 home address assignment using DHCP Relay. 1151 MN MAG(DHCP-R) LMA DHCP-S 1152 | |------->| | 1. Proxy Binding Update * 1153 | |<-------| | 2. Proxy Binding Acknowledgement (IPv4HoA) 1154 | |========| | 3. Tunnel/Route Setup* 1155 |------>|-------------->| 4. DHCPDISCOVER (IPv4HoA) via DHCP-R 1156 |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R 1157 |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R 1158 |<------|<--------------| 7. DHCPACK via DHCP-R 1159 | | | 1160 * The Proxy Mobile IPv6 signaling (Step-1 to Step-2) and the 1161 DHCPDISCOVER phase (Step-4) may occur in any order. However, 1162 the DHCPOFFER (Step-5) and the following steps will occur in 1163 the specified order and after the Tunnel/Route Setup (Step-3). 1165 Figure 7: Overview of the DHCP relay located at mobile access gateway 1167 Initial IPv4 Home Address Assignment: 1169 o When the mobile access gateway receives a DHCPDISCOVER message 1170 from a mobile node, it can check if there is already an assigned 1171 IPv4 home address for the mobile node from the local mobility 1172 anchor. If there is no assigned IPv4 home address assigned for 1173 that mobile node, the mobile access gateway has to complete the 1174 Proxy Mobile IPv6 signaling with the local mobility anchor by 1175 sending a Proxy Binding Update message. 1177 o If the Proxy Binding Update message is rejected by the local 1178 mobility anchor for any reason, the local mobility anchor will 1179 discard the DHCPDISCOVER messages from the mobile node. 1181 o If the Proxy Binding Update message is accepted by the local 1182 mobility anchor and if there is an assigned IPv4 home address for 1183 the mobile node, the DHCP messages will be forwarded to the DHCP 1184 server. 1186 o The DHCP relay agent on the mobile access gateway will add the 1187 DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER 1188 message. The assigned IPv4 home address will be included in the 1189 Agent Remote ID Sub-option of the DHCP relay agent information 1190 option. This sub-option is used as a hint for requesting the DHCP 1191 server to allocate that specific IPv4 address. 1193 o On receiving a DHCPOFFER message from the DHCP server, the mobile 1194 access gateway will ensure the assigned address is the address 1195 that is currently assigned to the mobile node by the local 1196 mobility anchor. If this address is different from what is 1197 assigned to the mobile node, then the mobile access gateway will 1198 drop the DHCPOFFER message and an administrative error message can 1199 be logged. 1201 o When the DHCP messages are sent over administrative boundaries, 1202 the operators needs to ensure these messages are secured. All the 1203 DHCP messages relayed by the mobile access gateway can be tunneled 1204 to the local mobility anchor if needed. Alternatively, if the 1205 network in the Proxy Mobile IPv6 domain is secure enough, the 1206 mobile access gateway can just relay the DHCP messages to the 1207 server. To achieve this, all the mobile access gateways needs to 1208 have route towards the DHCP server. 1210 IPv4 Home Address Renewal to the same DHCP server: (No Handover) 1212 o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it 1213 directly unicasts DHCPREQUEST message to the DHCP server. The 1214 DHCP relay agent may not detect these unicasted DHCPREQUEST 1215 messages for renewing the address. Thus, one of following 1216 operations is required. 1218 * The DHCP relay agent can intercept all the DHCP packets 1219 regardless of the destination address. Since the link between 1220 a mobile node and a mobile access gateway is the point-to-point 1221 link, the mobile access gateway will be in path for all the 1222 messages. 1224 * The DHCP relay agent can use the DHCP Server Identifier 1225 Override Sub-option [RFC-5107] to be in path for all the DHCP 1226 message flows. The DHCP client uses the DHCP server address 1227 which is overridden by the DHCP relay agent address as a 1228 destination address of DHCPREQUEST. The DHCP Server Identifier 1229 Override Sub-option is recommended only when the fixed DHCP 1230 relay address is configured on all the mobile access gateways. 1231 Otherwise, the DHCP relay agent address is changed when the 1232 mobile node changes the attached mobile access gateway. 1234 o The DHCP Relay agent on detecting the DHCPREQUEST message from the 1235 mobile node, will verify if the address in the DHCPREQUEST message 1236 is the address assigned by the local mobility anchor for that 1237 mobile node. If the requesting IPv4 home address is not 1238 registered to the local mobility anchor, the mobile access gateway 1239 will drop the packet. Once the address verification is 1240 successfully completed, the DHCP relay agent will forward the 1241 DHCPREQUEST message to the DHCP server. 1243 IPv4 Address Release Triggers from the mobile node: 1245 o The mobile node may release its IPv4 home address at any time by 1246 sending the DHCPRELEASE message [RFC-2131]. When the mobile 1247 access gateway detects the DHCPRELEASE message sent by the mobile 1248 node and for releasing its assigned IPv4 home address, the mobile 1249 access gateway should consider this as a trigger for de- 1250 registering the mobile node's IPv4 home address. It MUST apply 1251 the considerations specified in section 3.2.3.3 for performing the 1252 de-registration procedure. However, this operation should not 1253 release any IPv6 home network prefix(es) assigned to the mobile 1254 node. 1256 Additional Operations: 1258 o If at any point the mobile access gateway fails to extend the 1259 binding lifetime with the local mobility anchor for the mobile 1260 node's IPv4 address, it can send the unicast FORCERENEW message 1261 [RFC-3203] to the mobile node to force it to change its DHCP state 1262 to RENEW state. Furthermore, it MUST remove forwarding for the 1263 mobile node IPv4 home address. 1265 4. IPv4 Transport Support 1267 The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling 1268 messages exchanged between the local mobility anchor and the mobile 1269 access gateway to be over an IPv6 transport. The extensions defined 1270 in this section allow the exchange of signaling messages over an IPv4 1271 transport when the local mobility anchor and the mobile access 1272 gateway are separated by an IPv4 network and are reachable using only 1273 IPv4 addresses. 1275 IPv4-Proxy-CoA IPv4-LMAA 1276 | + - - - - - - + | 1277 +--+ +---+ / \ +---+ +--+ 1278 |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| 1279 +--+ +---+ \ / +---+ +--+ 1280 + - - - - - - + 1282 Figure 8: IPv4 Transport Network 1284 When the local mobility anchor and the mobile access gateway are 1285 configured and reachable using only IPv4 addresses, the mobile access 1286 gateway serving a mobile node can potentially send the signaling 1287 messages over IPv4 transport and register its IPv4 address as the 1288 care-of address in the mobile node's Binding Cache entry. An IPv4 1289 tunnel (with any of the supported encapsulation modes) can be used 1290 for tunneling the mobile node's data traffic. The following are the 1291 key aspects of this feature. 1293 o The local mobility anchor and the mobile access gateway are both 1294 configured and reachable using an IPv4 address. Additionally, 1295 both entities are also IPv6 enabled and have configured IPv6 1296 addresses on their interfaces, as specified in [RFC-5213], but are 1297 reachable only over an IPv4 transport. 1299 o The mobile access gateway can be potentially in a private IPv4 1300 network behind a NAT [RFC-3022] device, with a private IPv4 1301 address configured on its egress interface. However, the local 1302 mobility anchor must not be behind a NAT and must be using a 1303 globally routable IPv4 address. 1305 o The Proxy Mobile IPv6 signaling messages exchanged between the 1306 local mobility anchor and the mobile access gateway for 1307 negotiating the IPv4 transport will be encapsulated and carried as 1308 IPv4 packets. However, these signaling messages are fundamentally 1309 IPv6 messages using the mobility header and the related semantics 1310 as specified in base Proxy Mobile IPv6 specification [RFC-5213], 1311 but carried as a payload in an IPv4 packet. The supported 1312 encapsulation modes for the signaling messages are either native 1313 IPv4 or IPv4 with UDP header. 1315 o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and 1316 the IPv4 transport support specified in this section is agnostic 1317 to the type of address mobility enabled for that mobile node. 1319 o The IPv4 tunnel established between the local mobility anchor and 1320 the mobile access gateway (with any of the supported encapsulation 1321 modes over IPv4 transport) will be used for carrying the mobile 1322 node's IPv4 and IPv6 traffic. The supported encapsulation modes 1323 for carrying mobile node's IPv4 or IPv6 packets when using IPv4 1324 transport are as shown below. 1326 * IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet) 1328 * IPv4-UDP (Payload packet carried in an IPv4 packet with UDP 1329 header). 1331 * IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP 1332 and TLV header). Refer to [ID-DSMIP6]. 1334 * IPv4-UDP-ESP (Payload packet carried in an IPv4 packet with UDP 1335 and ESP headers). Refer to [RFC-3948]. 1337 4.1. Local Mobility Anchor Considerations 1339 4.1.1. Extensions to Binding Cache Entry 1341 To support this feature, the conceptual Binding Cache entry data 1342 structure maintained by the local mobility anchor [RFC-5213] MUST be 1343 extended with the following additional parameters. 1345 o The IPv4 address of the mobile access gateway. This is the 1346 address configured on the egress interface of the mobile access 1347 gateway that sent the Proxy Binding Update message. This address 1348 can be obtained from the IPv4 Care-of Address option [ID-DSMIP6], 1349 present in the received Proxy Binding Update message. If the 1350 option was not present in the request, this field MUST be set to 1351 the source address of the IPv4 header of the received Proxy 1352 Binding Update message. However, if the received Proxy Binding 1353 Update message is not sent as an IPv4 packet, this field MUST be 1354 set to ALL_ZERO value. 1356 o The IPv4 NAT translated address of the mobile access gateway. If 1357 the mobile access gateway is not behind a NAT [RFC-3022], this 1358 address will be the same as the address configured on the egress 1359 interface of the mobile access gateway. This address can be 1360 obtained from the IPv4 header of the received Proxy Binding Update 1361 message. However, if the received Proxy Binding Update message is 1362 not sent as an IPv4 packet, this field MUST be set to ALL_ZERO 1363 value. 1365 4.1.2. Extensions to Mobile Node's Policy Profile 1367 To support the IPv4 Transport Support feature the mobile node's 1368 policy profile, specified in Section 6.2 of [RFC-5213] MUST be 1369 extended with the following additional fields. These are mandatory 1370 fields of the policy profile required for supporting this feature. 1372 o The IPv4 address of the local mobility anchor (IPv4-LMAA). 1374 4.1.3. Signaling Considerations 1376 This section provides the rules for processing the Proxy Mobile IPv6 1377 signaling messages received over IPv4 transport. 1379 4.1.3.1. Processing Proxy Binding Updates 1381 o If the received Proxy Binding Update message was sent encapsulated 1382 in IPv4 or IPv4-UDP header, the message MUST be authenticated 1383 after removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1384 Considerations from Section 4 of [RFC-5213] MUST be applied for 1385 authenticating and authorizing the request. 1387 o All the considerations from Section 5.3.1 of [RFC-5213] MUST be 1388 applied on the encapsulated Proxy Binding Update message, after 1389 removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1391 o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in 1392 the request and if the outer encapsulation header is IPv4-UDP, 1393 then the NAT presence detection procedure specified in Section 1394 4.1.3.3 MUST be used for detecting the NAT in the path. 1396 o Upon accepting the request, the local mobility anchor MUST set up 1397 an IPv4 bi-directional tunnel to the mobile access gateway. The 1398 tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. 1399 The encapsulation mode MUST be determined from the below 1400 considerations. 1402 * If the received Proxy Binding Update message was sent with IPv4 1403 encapsulated header, then the encapsulation mode for the bi- 1404 directional tunnel MUST be set to IPv4. Otherwise, the 1405 following considerations apply. 1407 * If NAT is detected on the path, or if the (F) flag in the 1408 received Proxy Binding Update message is set to the value of 1, 1409 then the encapsulation mode MUST be set to IPv4-UDP. Otherwise 1410 the encapsulation mode MUST be set to IPv4. 1412 * If NAT is not detected on the path and if the (F) flag in the 1413 received Proxy Binding Update message is set to the value of 1, 1414 but if the configuration flag, 1415 AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of 1416 0, then the local mobility anchor MUST reject the request with 1417 the Status field value set to 129 (Administratively 1418 prohibited). 1420 * If the (T) flag [ID-DSMIP6] in the Proxy Binding Update message 1421 is set to value of 1, then the encapsulation mode MUST be set 1422 to IPv4-UDP-TLV. 1424 o The local mobility anchor MUST send the Proxy Binding 1425 Acknowledgement message with the Status field value set to 0 1426 (Proxy Binding Update Accepted). The message MUST be constructed 1427 as specified in Section 4.1.3.2. 1429 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 1431 The local mobility anchor when sending the Proxy Binding 1432 Acknowledgement message to the mobile access gateway MUST construct 1433 the message as specified in Section 5.3.6 of [RFC-5213]. However, if 1434 the received Proxy Binding Update message was encapsulated in an IPv4 1435 packet or as a payload in the UDP header of an IPv4 packet, the 1436 following additional considerations MUST be applied. 1438 o The Proxy Binding Acknowledgement message MUST be encapsulated in 1439 an IPv4 packet. However, if the received Proxy Binding Update 1440 message was sent encapsulated in the UDP header of an IPv4 packet, 1441 then the Proxy Binding Acknowledgement message MUST be 1442 encapsulated in the UDP header of an IPv4 packet. 1444 o The source address in the IPv4 header of the message MUST be set 1445 to the destination IPv4 address of the received request. 1447 o If the mobile access gateway and the local mobility anchor are 1448 using globally routable IPv4 addresses and if there is a security 1449 associated that is based of IPv4 addresses, then the encapsulated 1450 IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement) 1451 MUST be protected using IPsec ESP [RFC-4301] mode. There is no 1452 need to apply IPsec ESP header to the IPv6 packet. In all other 1453 cases, the Proxy Binding Acknowledgement message MUST be protected 1454 using IPsec prior to the IPv4 or IPv4-UDP encapsulation. 1456 o The NAT Detection option [ID-DSMIP6] MUST be present only if there 1457 is an IPv4 Care-of Address option [ID-DSMIP6] present in the 1458 received Proxy Binding Update message and if the NAT detection 1459 procedure resulted in detecting a NAT on path. However, if the 1460 received Proxy Binding Update message was not sent encapsulated in 1461 IPv4 UDP header, then the option MUST NOT be present. 1462 Furthermore, in all other cases, the option MUST NOT be present. 1464 o The IPv4 DHCP Support Mode option MAY be present. If this option 1465 is not present, the mobile access gateway will enable the default 1466 behavior and function as a DHCP Relay for the mobile node. 1468 o The format of the Proxy Binding Acknowledgement message 1469 encapsulated in an IPv4 packet and protected using IPv6 security 1470 association. The UDP header MUST be present only if the received 1471 Proxy Binding Update message was sent with IPv4-UDP encapsulation 1472 header. 1474 IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) 1475 UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/ 1476 /* IPv6 PBA Packet protected with ESP header */ 1478 Figure 9: Proxy Binding Acknowledgment (PBA) Message encapsulated 1479 in IPv4 header 1481 4.1.3.3. NAT Presence Detection 1483 When the transport network between the local mobility anchor and the 1484 mobile access gateway is an IPv4 network and if the received Proxy 1485 Binding Update message was sent encapsulated in IPv4 UDP header, the 1486 local mobility anchor performs the NAT Presence Detection as 1487 specified below. 1489 On receiving the Proxy Binding Update message encapsulated in an IPv4 1490 UDP packet, the local mobility anchor, if it detects a NAT on the 1491 path, will send the Proxy Binding Acknowledgment message with the NAT 1492 Detection Option. The presence of this option in the Proxy Binding 1493 Acknowledgment is an indication to the mobile access gateway about 1494 the presence of NAT in the path. On detecting any NAT in the path, 1495 both the local mobility anchor and the mobile access gateway will set 1496 the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation. 1497 The specific details around the NAT detection and the related logic 1498 are described in DSMIPv6 specification [ID-DSMIP6]. 1500 However, if the value of the configuration variable, 1501 UseIPv4UDPEncapForSignalingMessages, is set to a value of 0, the 1502 mobile access gateway will not use IPv4 UDP encapsulation for Proxy 1503 Binding Update messages and hence the local mobility anchor will not 1504 perform this NAT Presence Detection procedure on these messages that 1505 are not sent in IPv4 UDP packet. 1507 4.1.4. Routing Considerations 1509 4.1.4.1. Forwarding Considerations 1511 Forwarding Packets to the Mobile Node: 1513 o On receiving an IPv4 or an IPv6 packet from a correspondent node 1514 with the destination address matching any of the mobile node's 1515 IPv4 or IPv6 home addresses, the local mobility anchor MUST 1516 forward the packet through the bi-directional tunnel set up for 1517 that mobile node. 1519 o The format of the tunneled packet is shown below. 1521 IPv4 Header (src= IPv4-LMAA, dst= IPv4-Proxy-CoA)] /* Tunnel Header */ 1522 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1523 [TLV Header] /* If TLV negotiated */ 1524 /* IPv6 or IPv4 Payload Packet */ 1525 IPv6 header (src= CN, dst= MN-HOA) 1526 OR 1527 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1529 Figure 10: Tunneled IPv4 Packet from LMA to MAG 1531 o Forwarding Packets Sent by the Mobile Node: 1533 * All the reverse tunneled packets (IPv4 and IPv6) that the local 1534 mobility anchor receives from the mobile access gateway, after 1535 removing the tunnel header (i.e., the outer IPv4 header along 1536 with the UDP and TLV header, if negotiated) MUST be routed to 1537 the destination specified in the inner packet header. These 1538 routed packets will have the source address field set to the 1539 mobile node's home address. 1541 4.1.4.2. ECN Considerations 1543 The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply 1544 for the IPv4 transport tunnels as well. The mobility agents at the 1545 tunnel entry and exit points MUST handle ECN information as specified 1546 in that document. 1548 4.1.4.3. Bi-Directional Tunnel Management 1550 The Tunnel Management considerations specified in section 5.6.1 of 1551 [RFC-5213] apply for the IPv4 transport tunnels as well, with just 1552 one difference that the encapsulation mode is different. 1554 4.2. Mobile Access Gateway Considerations 1556 4.2.1. Extensions to Binding Update List Entry 1558 To support the IPv4 Transport Support feature, the conceptual Binding 1559 Update List entry data structure maintained by the mobile access 1560 gateway [RFC-5213] MUST be extended with the following additional 1561 parameters. 1563 o The IPv4 address of the local mobility anchor. This address can 1564 be obtained from the mobile node's policy profile. 1566 o The IPv4 address of the mobile access gateway. This is the 1567 address configured on the egress interface of the mobile access 1568 gateway and is registered with the mobile node's local mobility 1569 anchor as the IPv4 Proxy-CoA. However, if the mobile access 1570 gateway is in a private IPv4 network and behind a NAT, the address 1571 that is registered with the mobile node's local mobility anchor is 1572 the NAT translated public IPv4 address. 1574 4.2.2. Signaling Considerations 1576 The mobile access gateway when sending a Proxy Binding Update message 1577 to the local mobility anchor MUST construct the message as specified 1578 in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access 1579 gateway is in an IPv4-only access network, the following additional 1580 considerations MUST be applied. 1582 o The Proxy Binding Update message MUST be encapsulated in an IPv4 1583 packet. However, if the value of the configuration variable, 1584 UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy 1585 Binding Update message MUST be encapsulated in an UDP header of an 1586 IPv4 packet. 1588 o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The 1589 IPv4 address in the option MUST be set to the mobile access 1590 gateway's IPv4-Proxy-CoA. 1592 o The packet MUST be constructed as specified in Section 4.2.3. 1594 o When sending a Proxy Binding message for extending the lifetime of 1595 a currently existing mobility session or for de-registering the 1596 mobility session, the Proxy Binding Update message MUST be 1597 constructed as the initial request. 1599 Receiving Proxy Binding Acknowledgement 1601 o If the received Proxy Binding Acknowledgement message is 1602 encapsulated in IPv4 or IPv4 UDP packet, the message MUST be 1603 authenticated after removing the outer IPv4 or IPv4-UDP header. 1604 Considerations from Section 4 of [RFC-5213] MUST be applied for 1605 authenticating and authorizing the message. 1607 o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be 1608 applied on the encapsulated Proxy Binding Acknowledgement message, 1609 after removing the outer IPv4 UDP header. 1611 o If the Status field indicates Success, the mobile access gateway 1612 MUST setup a bi-directional tunnel to the local mobility anchor. 1614 o Upon accepting the request, the mobile access gateway MUST set up 1615 an IPv4 bi-directional tunnel to the local mobility anchor. The 1616 tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA. 1617 The encapsulation mode MUST be determined from the below 1618 considerations. 1620 * The encapsulation mode for the bi-directional tunnel MUST be 1621 set to IPv4. However, if the value of the configuration 1622 variable, UseIPv4UDPEncapForSignalingMessages, is set to 1, 1623 then the following considerations MUST be applied. 1625 * If there is a NAT Detection option [ID-DSMIP6] in the received 1626 Proxy Binding Acknowledgement message and if the value of the 1627 configuration flag, UseIPv4UDPEncapForSignalingMessages, is set 1628 to value of 1, then the encapsulation mode for the tunnel MUST 1629 be set to IPv4-UDP. Otherwise the encapsulation mode MUST be 1630 set to IPv4. 1632 * If the (T) flag in the Proxy Binding Acknowledgement message is 1633 set to value of 1, then the encapsulation mode MUST be set to 1634 IPv4-UDP-TLV. 1636 4.2.2.1. Constructing the Proxy Binding Update Message 1638 o The source address in the IPv4 header MUST be set to IPv4-Proxy- 1639 CoA of the mobile access gateway and the destination address MUST 1640 be set to the local mobility anchor's IPv4-LMAA. 1642 o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The 1643 address MUST be set to the mobile access gateway's IPv4-Proxy-CoA. 1645 o If the configuration variable ForceIPv4UDPEncapsulationSupport is 1646 set to value of 1, then the (F) flag in the Proxy Binding Update 1647 message MUST be set to value of 1. 1649 o If the mobile access gateway and the local mobility anchor are 1650 using globally routable IPv4 addresses and if there is a security 1651 associated that is based of IPv4 addresses, then the encapsulated 1652 IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement 1653 message) MUST be protected using IPsec ESP [RFC-4301] mode and 1654 additionally there is no need to apply ESP header on the IPv6 1655 packet. In all other cases, the Proxy Binding Update message MUST 1656 be protected on the IPv6 packet of the Proxy Binding Update 1657 message, prior to the IPv4 encapsulation. 1659 o The format of the Proxy Binding Update message encapsulated in an 1660 IPv4 or IPv4-UDP packet with no IPsec protection: 1662 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1663 UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/ 1664 /* IPv6 PBU Packet protected with ESP header */ 1666 Figure 11: Proxy Binding Update (PBU) message encapsulated in IPv4 1667 UDP header 1669 4.2.2.2. Forwarding Considerations 1671 Forwarding Packets Sent by the Mobile Node: 1673 o On receiving an IPv4 or an IPv6 packet from the mobile node to any 1674 destination, the mobile access gateway MUST tunnel the packet to 1675 the local mobility anchor. The format of the tunneled packet is 1676 shown below. However, considerations from Section 6.10.3 of [RFC- 1677 5213] MUST be applied with respect the local routing and on the 1678 use of EnableMAGLocalRouting flag. 1680 IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */ 1681 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1682 [TLV Header] /* If TLV negotiated */ 1683 /* IPv6 or IPv4 Payload Packet */ 1684 IPv6 header (src= CN, dst= MN-HOA) 1685 OR 1686 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1688 Figure 12: Tunneled IPv4 Packet from LMA to MAG 1690 o Forwarding Packets received from the bi-directional tunnel: 1692 o On receiving a packet from the bi-directional tunnel established 1693 with the mobile node's local mobility anchor, the mobile access 1694 gateway MUST remove the outer header before forwarding the packet 1695 to the mobile node. 1697 5. Protocol Configuration Variables 1699 5.1. Local Mobility Anchor - Configuration Variables 1701 The local mobility anchor MUST allow the following variables to be 1702 configured by the system management. The configured values for these 1703 protocol variables MUST survive server reboots and service restarts. 1705 AcceptForcedIPv4UDPEncapsulationRequest 1707 This flag indicates whether or not the local mobility anchor 1708 should accept IPv4 UDP encapsulation request for the mobile node's 1709 data traffic, even if there is no NAT detected in the path. 1711 The default value for this flag is set to value of 0, indicating 1712 that the local mobility anchor MUST not accept IPv4 UDP 1713 encapsulation request when NAT is not detected in the path. 1715 When the value for this flag is set to value of 1, the local 1716 mobility anchor MUST accept IPv4 UDP encapsulation request even 1717 when NAT is not detected in the path. 1719 5.2. Mobile Access Gateway - Configuration Variables 1721 The mobile access gateway MUST allow the following variables to be 1722 configured by the system management. The configured values for these 1723 protocol variables MUST survive server reboots and service restarts. 1725 UseIPv4UDPEncapForSignalingMessages 1727 This flag indicates whether or not the mobile access gateway 1728 should use IPv4-UDP encapsulation mode for the signaling messages. 1730 The default value for this flag is set to value of 0, indicating 1731 that the mobile access gateway MUST NOT use IPv4-UDP encapsulation 1732 mode, but MUST use native IPv4 encapsulation mode for sending the 1733 Proxy Mobile IPv6 signaling messages. 1735 When the value for this flag is set to value of 1, the mobile 1736 access gateway MUST use IPv4-UDP encapsulation mode for sending 1737 the Proxy Mobile IPv6 signaling messages. 1739 ForceIPv4UDPEncapsulationSupport 1740 This flag indicates whether or not the mobile access gateway 1741 should request the mobile node's local mobility anchor for forcing 1742 IPv4 UDP encapsulation support for the mobile node's data traffic, 1743 even when NAT is not detected in the path. 1745 The default value for this flag is set to value of 0, indicating 1746 that the mobile access gateway MUST NOT request the mobile node's 1747 local mobility anchor for forcing IPv4 UDP encapsulation support 1748 even when NAT is not detected in path. 1750 When the value for this flag is set to value of 1, the mobile 1751 access gateway MUST force the mobile node's local mobility anchor 1752 for IPv4 UDP encapsulation support. 1754 This flag is applicable only when the flag 1755 UseIPv4UDPEncapForSignalingMessages is set to a value of 1. 1757 6. IANA Considerations 1759 This document defines a new Mobility Header option, IPv4 Default 1760 Router Address option. This option is described in Section 3.3.1. 1761 The Type value for this option needs to be assigned from the same 1762 numbering space as allocated for the other mobility options, as 1763 defined in [RFC-3775]. 1765 This document also defines new Binding Acknowledgement status values, 1766 as described in Section 3.3.2. The status values MUST be assigned 1767 from the same number space used for Binding Acknowledgement status 1768 values, as defined in [RFC3775]. The allocated values for each of 1769 these status values must be greater than 128. 1771 7. Security Considerations 1773 All the security considerations from the base Proxy Mobile IPv6 1774 protocol [RFC-5213] apply when using the extensions defined in this 1775 document. Additionally, the following security considerations need 1776 to be applied. 1778 This document defines news mobility options for supporting the IPv4 1779 Home Address assignment and IPv4 Transport Support features. It also 1780 uses some of the mobility options from DSMIPv6 specification [ID- 1781 DSMIP6]. These options are to be carried in Proxy Binding Update and 1782 Proxy Binding Acknowledgement messages. The required security 1783 mechanisms specified in the base Proxy Mobile IPv6 protocol for 1784 protecting these signaling messages are sufficient when carrying 1785 these mobility options. 1787 This specification describes the use of IPv4 transport for exchanging 1788 the signaling messages between the local mobility anchor and the 1789 mobile access gateway. These messages are protected using IPsec 1790 using the security associations established using the IPv4 transport 1791 addresses and offer the same security as when the messages are 1792 protected when using IPv6 transport. 1794 8. Contributors 1796 This document reflects discussions and contributions from several 1797 people (in alphabetical order): 1799 Kuntal Chowdhury 1801 kchowdhury@starentnetworks.com 1803 Vijay Devarapalli 1805 vijay.devarapalli@azairenet.com 1807 Sangjin Jeong 1809 sjjeong@etri.re.kr 1811 Basavaraj Patil 1813 basavaraj.patil@nsn.com 1815 Myungki Shin 1817 myungki.shin@gmail.com 1819 9. Acknowledgments 1821 The IPv4 support for Proxy Mobile IPv6 was initially covered in the 1822 internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like 1823 to thank all the authors of the document and acknowledge that initial 1824 work. 1826 Thanks to Behcet Sarikaya, Charles Perkins, Jonne Soinnen, Julien 1827 Laganier, Mohana Jeyatharan, Niklas Nuemann, Premec Domagoj, Sammy 1828 Touati and Zu Qiang for their helpful review of this document. 1830 10. References 1832 10.1. Normative References 1834 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1835 Requirement Levels", BCP 14, RFC 2119, March 1997. 1837 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1838 2131, March 1997. 1840 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1841 IPv6 Specification", RFC 2473, December 1998. 1843 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1844 IPv6", RFC 3775, June 2004. 1846 [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, 1847 November 2007. 1849 [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack 1850 Hosts and Routers (DSMIPv6)", 1851 draft-ietf-mext-nemo-v4traversal-06.txt, November 2008. 1853 10.2. Informative References 1855 [RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor 1856 Extensions", RFC 2132, March 1997. 1858 [RFC-3011] G. Waters, "The IPv4 Subnet Selection Option for DHCP", 1859 RFC 3011, November 2000. 1861 [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1862 Address Translator (Traditional NAT)", RFC 3022, January 2001. 1864 [RFC-3203] Y. T'Joens and C. Hublet and P. De Schrijver, "DHCP 1865 reconfigure extension", RFC 3203, December 2001. 1867 [RFC-3927] Cheshire, S. et al, "Dynamic Configuration of IPv4 Link- 1868 Local Addresses", RFC 3927, May 2005. 1870 [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack 1871 Mobility", RFC 4977, August 2007. 1873 [RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp, 1874 "DHCP Server Identifier Override Suboption", RFC 5107, February 2008. 1876 Authors' Addresses 1878 Ryuji Wakikawa 1879 Toyota ITC / Keio University 1880 6-6-20 Akasaka, Minato-ku 1881 Tokyo 107-0052 1882 Japan 1884 Phone: +81-3-5561-8276 1885 Fax: +81-3-5561-8292 1886 Email: ryuji@jp.toyota-itc.com 1888 Sri Gundavelli 1889 Cisco 1890 170 West Tasman Drive 1891 San Jose, CA 95134 1892 USA 1894 Email: sgundave@cisco.com 1896 Full Copyright Statement 1898 Copyright (C) The IETF Trust (2008). 1900 This document is subject to the rights, licenses and restrictions 1901 contained in BCP 78, and except as set forth therein, the authors 1902 retain all their rights. 1904 This document and the information contained herein are provided on an 1905 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1906 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1907 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1908 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1909 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1910 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1912 Intellectual Property 1914 The IETF takes no position regarding the validity or scope of any 1915 Intellectual Property Rights or other rights that might be claimed to 1916 pertain to the implementation or use of the technology described in 1917 this document or the extent to which any license under such rights 1918 might or might not be available; nor does it represent that it has 1919 made any independent effort to identify any such rights. Information 1920 on the procedures with respect to rights in RFC documents can be 1921 found in BCP 78 and BCP 79. 1923 Copies of IPR disclosures made to the IETF Secretariat and any 1924 assurances of licenses to be made available, or the result of an 1925 attempt made to obtain a general license or permission for the use of 1926 such proprietary rights by implementers or users of this 1927 specification can be obtained from the IETF on-line IPR repository at 1928 http://www.ietf.org/ipr. 1930 The IETF invites any interested party to bring to its attention any 1931 copyrights, patents or patent applications, or other proprietary 1932 rights that may cover technology that may be required to implement 1933 this standard. Please address the information to the IETF at 1934 ietf-ipr@ietf.org. 1936 Acknowledgment 1938 Funding for the RFC Editor function is provided by the IETF 1939 Administrative Support Activity (IASA).