idnits 2.17.1 draft-ietf-netlmm-pmip6-ipv4-support-05.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 1826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1844. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1850. 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-only or IPv6-only addresses), the Binding Cache entry MUST not be deleted, only the respective states with respect those addresses MUST be deleted. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 23, 2008) is 5694 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 159, but not defined == Missing Reference: 'RFC-4306' is mentioned on line 309, but not defined ** Obsolete undefined reference: RFC 4306 (Obsoleted by RFC 5996) == Missing Reference: 'RFC-1332' is mentioned on line 309, but not defined == Missing Reference: 'RFC-3046' is mentioned on line 1086, but not defined == Missing Reference: 'RFC-3948' is mentioned on line 1226, but not defined == Missing Reference: 'RFC-4301' is mentioned on line 1540, but not defined == Missing Reference: 'RFC3775' is mentioned on line 1684, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Unused Reference: 'RFC-2473' is defined on line 1756, but no explicit reference was found in the text == Unused Reference: 'RFC-3011' is defined on line 1774, 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-05 Summary: 4 errors (**), 0 flaws (~~), 13 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: March 27, 2009 Cisco 6 September 23, 2008 8 IPv4 Support for Proxy Mobile IPv6 9 draft-ietf-netlmm-pmip6-ipv4-support-05.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 March 27, 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) extending IPv4 home address mobility support to the 45 mobile node. 2) allowing the mobility entities in the Proxy Mobile 46 IPv6 domain to exchange signaling messages over an IPv4 transport 47 network. 49 Table of Contents 51 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 6 54 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 8 55 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 56 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 58 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 10 59 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 11 60 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 11 61 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 11 62 3.1.3. Routing Considerations for the Local Mobility 63 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 15 64 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 16 65 3.2.1. Extensions to Binding Update List Entry . . . . . . . 16 66 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 17 67 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 17 68 3.2.4. Routing Considerations for the Mobile Access 69 Gateway . . . . . . . . . . . . . . . . . . . . . . . 20 70 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 21 71 3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 21 72 3.3.2. Status Codes . . . . . . . . . . . . . . . . . . . . . 22 73 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 22 74 3.4.1. DHCP Server co-located with the Mobile Access 75 Gateway . . . . . . . . . . . . . . . . . . . . . . . 23 76 3.4.2. DHCP Relay Agent co-located with the Mobile Access 77 Gateway . . . . . . . . . . . . . . . . . . . . . . . 26 79 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 30 80 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 31 81 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 31 82 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 32 83 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 32 84 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 35 85 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 36 86 4.2.1. Extensions to Binding Update List Entry . . . . . . . 36 87 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 36 89 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 40 90 5.1. Local Mobility Anchor - Configuration Variables . . . . . 40 91 5.2. Mobile Access Gateway - Configuration Variables . . . . . 40 92 5.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 41 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 97 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 44 99 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 102 10.1. Normative References . . . . . . . . . . . . . . . . . . . 44 103 10.2. Informative References . . . . . . . . . . . . . . . . . . 45 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 106 Intellectual Property and Copyright Statements . . . . . . . . . . 47 108 1. Overview 110 The transition from IPv4 to IPv6 is a long process and during this 111 period of transition, both the protocols will be enabled over the 112 same network infrastructure. Thus, it is reasonable to assume that a 113 mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only 114 IPv6-only or in dual-stack mode and additionally the network between 115 the mobile access gateway and a local mobility anchor may be an IPv4 116 or an IPv6 network. It is also reasonable to expect the same 117 mobility infrastructure in the Proxy Mobile IPv6 domain to provide 118 mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode 119 and when the network between the local mobility anchor and the mobile 120 access gateway is an IPv4 or an IPv6 network. The motivation and 121 scope of IPv4 support in Mobile IPv6 is summarized in [RFC-4977] and 122 all those requirements apply to Proxy Mobile IPv6 protocol as well. 124 The Proxy Mobile IPv6 protocol [RFC-5213] specifies a mechanism for 125 providing IPv6 home address mobility support to a mobile node in a 126 Proxy Mobile IPv6 domain. The protocol requires IPv6 transport 127 network between the mobility entities. The extensions defined in 128 this document extends IPv4 support to the Proxy Mobile IPv6 protocol 129 [RFC-5213]. 131 The scope of IPv4 support in Proxy Mobile IPv6 includes the support 132 for the following two features: 134 o IPv4 Home Address Mobility Support: A mobile node that has an IPv4 135 stack enabled will be able to obtain an IPv4 address and be able 136 to use that address from any of the access networks in that Proxy 137 Mobile IPv6 domain. The mobile node is not required to be 138 allocated or assigned an IPv6 address for enabling IPv4 home 139 address support. 141 o IPv4 Transport Network Support: The mobility entities in the Proxy 142 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 143 signaling messages over an IPv4 transport and furthermore the 144 mobile access gateway may be using an IPv4 private address and 145 with NAT [RFC-3022] translation devices on the path to the local 146 mobility anchor. 148 These two features, the IPv4 Home Address Mobility support and the 149 IPv4 transport support features, are independent of each other and 150 deployments may choose to enable any one or both of these features as 151 required. 153 +----+ +----+ 154 |LMA1| |LMA2| 155 +----+ +----+ 156 IPv4-LMAA1 -> | | <-- LMAA2 157 | | 158 \\ //\\ 159 [NAT] // \\ 160 \\ // \\ 161 +---\\------------- //------\\----+ 162 ( \\ IPv4/IPv6 // \\ ) 163 ( \\ Network // \\ ) 164 +------\\--------//------------\\-+ 165 \\ // \\ 166 \\ // \\ 167 \\ // \\ 168 IPv4-Proxy-CoA1--> | | <-- Proxy-CoA2 169 +----+ +----+ 170 |MAG1|-----{MN2} |MAG2| 171 +----+ | +----+ 172 (IPv6 MN-HoA1) | | | <-- (IPv6 MN-HoA2) 173 (IPv4-MN-HoA1) --> | (IPv4-MN-HoA2) | <-- (IPv4-MN-HoA3) 174 {MN1} {MN3} 176 Figure 1: IPv4 support for Proxy Mobile IPv6 178 1.1. Stated Assumptions 180 The following are the configuration requirements from the mobility 181 entities in the Proxy Mobile IPv6 domain for supporting the 182 extensions defined in this document. 184 o The local mobility anchor and the mobile access gateway are both 185 IPv4 and IPv6 enabled. Irrespective of the type of transport 186 network (IPv4 or IPv6) separating these two entities, the mobility 187 signaling is always based on Proxy Mobile IPv6 [RFC-5213]. 189 o The mobile node can be operating in IPv4-only, IPv6-only or in 190 dual mode. Based on what is enabled for a mobile node, it should 191 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 192 address(es) for its interface and furthermore achieve mobility 193 support for those addresses. 195 o For enabling IPv4 home address mobility support to a mobile node, 196 it is not required that the IPv6 home address mobility support 197 needs to enabled. However, the respective protocol(s) support 198 must be enabled on the access link between the mobile node and the 199 mobile access gateway. 201 o The mobile node can obtain an IPv4 address for its attached 202 interface. Based on the type of link, it may be able to acquire 203 its IPv4 address configuration using DHCP [RFC-2131], IPCP [RFC- 204 1332], IKEv2 [RFC-4306], static configuration or through other 205 standard IPv4 address configuration mechanisms. 207 o The mobile node's IPv4 home subnet is typically a shared address 208 space. It is not for the exclusive use of any one mobile node. 209 There can be more than one mobile node sharing different addresses 210 from the same IPv4 subnet. 212 o The mobile access gateway is the IPv4 default-router for the 213 mobile node on its access link. It will be in the forwarding path 214 for the mobile node's data traffic. 216 2. Conventions & Terminology 218 2.1. Conventions 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in RFC 2119 [RFC-2119]. 224 2.2. Terminology 226 All the mobility related terms used in this document are to be 227 interpreted as defined in the Mobile IPv6 specification [RFC-3775] 228 and Proxy Mobile IPv6 specification [RFC-5213]. In addition this 229 document introduces the following terms. 231 IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) 233 The IPv4 address that is configured on the egress-interface of the 234 mobile access gateway. When using IPv4 transport, this address 235 will be the registered care-of address in the mobile node's 236 Binding Cache entry and will also be the transport-endpoint of the 237 tunnel between the local mobility anchor and a mobile access 238 gateway. However, if the configured address is a private IPv4 239 address and with a NAT device in the path to the local mobility 240 anchor, the care-of address as seen by the local mobility anchor 241 will be the address allocated by the NAT device for that flow. 243 IPv4 Local Mobility Anchor Address (IPv4-LMAA) 245 The IPv4 address that is configured on the egress-interface of the 246 local mobility anchor. When using IPv4 transport, the mobile 247 access gateway sends the Proxy Binding Update messages to this 248 address and will be the transport-endpoint of the tunnel between 249 the local mobility anchor and the mobile access gateway. 251 Mobile Node's IPv4 Home Address (IPv4-MN-HoA) 253 This is the IPv4 home address assigned to the mobile node's 254 attached interface. This address is topologically anchored at the 255 local mobility anchor. The mobile node configures this address on 256 its attached interface. Further, if the mobile node connects to 257 the Proxy Mobile IPv6 domain through multiple interfaces and for 258 simultaneous access, each of the attached interface will be 259 assigned a unique IPv4 home address. All the IPv6 home network 260 prefixes and the IPv4 home address assigned to a given interface 261 of a mobile node will be managed under one mobility session. 263 Encapsulation Modes 265 This document uses the following terms when referring to the 266 different encapsulation modes. 268 IPv4-over-IPv6 270 IPv4 packet carried as a payload of an IPv6 packet 272 IPv4-over-IPv4 274 IPv4 packet carried as a payload of an IPv4 packet 276 IPv4-over-IPv4-UDP 278 IPv4 packet carried as a payload in an UDP header of an IPv4 279 packet 281 IPv4-over-IPv4-UDP-TLV 283 IPv4 packet carried as a payload in an IPv4 packet with UDP and 284 TLV headers 286 3. IPv4 Home Address Mobility Support 288 The IPv4 home address mobility support essentially enables a mobile 289 node in a Proxy Mobile IPv6 domain to obtain IPv4 home address 290 configuration for its attached interface and be able to retain that 291 address configuration even after changing its point of attachment in 292 that Proxy Mobile IPv6 domain. This section describes the protocol 293 operation and the required extensions to Proxy Mobile IPv6 protocol 294 for extending IPv4 home address mobility support. 296 When an IPv4-enabled or a dual-stack enabled mobile node attaches to 297 the Proxy Mobile IPv6 domain, the mobile access gateway on the access 298 link where the mobile node is attached will identify the mobile node 299 and will initiate the Proxy Mobile IPv6 signaling with the mobile 300 node's local mobility anchor. The mobile access gateway will follow 301 the signaling considerations specified in Section 3.2 for requesting 302 IPv4 home address mobility support. Upon the completion of the 303 signaling, the local mobility anchor and the mobile access gateway 304 will have the required routing states for allowing the mobile node to 305 use its IPv4 home address from its current point of attachment. 307 The mobile node on the access link using any of the standard IPv4 308 address configuration mechanisms supported on that access link, such 309 as IPCP [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], will be able 310 to obtain an IPv4 home address (IPv4-MN-HoA) for its attached 311 interface. Although the address configuration mechanisms for 312 delivering the address configuration to the mobile node is 313 independent of the Proxy Mobile IPv6 protocol operation, however 314 there needs to be some interactions between these two protocol flows. 315 Section 3.4 identifies these interactions for supporting DHCP based 316 address configuration. 318 The support for IPv4 home address mobility is not dependent on the 319 IPv6 home address mobility support. It is not required that the IPv6 320 home address mobility support needs to be enabled for providing IPv4 321 home address mobility support. A mobile node will be able to obtain 322 IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its 323 attached interface. The mobile node's policy profile will determine 324 if the mobile node is entitled for both the protocol versions or a 325 single protocol version. Based on the policy, only those protocols 326 will be enabled on the access link. Furthermore, if the mobile node 327 after obtaining the address configuration on its interface performs 328 an handoff, either by changing its point of attachment over the same 329 interface or to a different interface, the network will ensure the 330 mobile node will be able to use the same IPv4 address configuration 331 after the handoff. 333 Additionally, If the mobile node connects to the Proxy Mobile IPv6 334 domain, through multiple interfaces and simultaneously through 335 different access networks, each of the connected interfaces will 336 obtain an IPv4 home address from different subnets. In such 337 scenario, there will be multiple Binding Cache entries for the mobile 338 node on the local mobility anchor. All the address (IPv4/IPv6) 339 assigned to a given interface will be managed as part of one mobility 340 session, as specified in Section 5.4 of [RFC-5213]. 342 3.1. Local Mobility Anchor Considerations 344 3.1.1. Extensions to Binding Cache Entry 346 To support this feature, the conceptual Binding Cache entry data 347 structure maintained by the local mobility anchor needs to be 348 extended with the following additional parameters. 350 o The IPv4 home address assigned to the mobile node's interface and 351 registered by the mobile access gateway. The IPv4 home address 352 entry also includes the corresponding subnet mask. 354 o The IPv4 default-router address assigned to the mobile node. 356 3.1.2. Signaling Considerations 358 3.1.2.1. Processing Proxy Binding Updates 360 The processing rules specified in Section 5.3 of [RFC-5213] are 361 applied for processing the received Proxy Binding Update message. 362 However, if the received Proxy Binding Update message has an IPv4 363 Home Address option [ID-DSMIP6], the following considerations MUST be 364 applied additionally. 366 o If there is an IPv4 Home Address option [ID-DSMIP6] present in the 367 received Proxy Binding Update message, but if there is no Home 368 Network Prefix option [RFC-5213] present in the request, the local 369 mobility anchor MUST NOT reject the request as specified in 370 Section 5.3.1 of [RFC-5213]. At least one instance of any of 371 these two options MUST be present. If there is not a single 372 instance of any of these two options present in the request, the 373 local mobility anchor MUST reject the request and send a Proxy 374 Binding Acknowledgement message with Status field set to 375 MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home 376 network prefix option) [RFC-5213]. 378 o For associating the received Proxy Binding Update message to an 379 existing mobility session, the local mobility anchor MUST perform 380 the Binding Cache entry existence test by applying the following 381 considerations. 383 * If there is at least one instance of the Home Network Prefix 384 option [RFC-5213] with a NON_ZERO prefix value, or, if there is 385 an IPv4 Home Address option [ID-DSMIP6] with the IPv4 address 386 in the option set to ALL_ZERO, considerations from Section 387 5.4.1 of [RFC-5213] MUST be applied. 389 * If there is an IPv4 Home Address option [ID-DSMIP6] present in 390 the request with the IPv4 address value in the option set to a 391 NON_ZERO value, considerations from Section 3.1.2.7 MUST be 392 applied. 394 o If there is no existing Binding Cache entry that can be associated 395 with the request, the local mobility anchor MUST consider this 396 request as an initial binding registration request and 397 considerations from Section 3.1.2.2 MUST be applied. 398 Additionally, if there are one or more Home Network Prefix options 399 [RFC-5213] present in the request, considerations from Section 400 5.3.2 of [RFC-5213] MUST also be applied. 402 o If there exists a Binding Cache entry that can be associated with 403 the request, the local mobility anchor MUST apply considerations 404 from Section 5.3.1 of [RFC-5213], (point 13), to determine if the 405 request is re-registration or a de-registration request and the 406 respective considerations from the below sections MUST be applied. 408 o If there exists a Binding Cache entry that can be associated with 409 the request and if it is determined that the request is a re- 410 registration request and with the request to extend IPv4 home 411 address mobility support to the existing IPv6-only mobility 412 session, considerations from Section 3.1.2.2 MUST be applied with 413 respect to IPv4 support. 415 3.1.2.2. Initial Binding Registration (New Mobility Session) 417 o If there is an IPv4 Home Address option [ID-DSMIP6] present in the 418 Proxy Binding Update message with the IPv4 address value in the 419 option set to ALL_ZERO, the local mobility anchor MUST allocate an 420 IPv4 home address to the mobile node and associate it with the new 421 mobility session created for that mobile node. 423 o If there is an IPv4 Home Address option [ID-DSMIP6] with the IPv4 424 address in the option set to a NON_ZERO value, the local mobility 425 anchor before accepting the request MUST ensure the address is 426 owned by the local mobility anchor and furthermore the mobile node 427 is authorized to use that address. If the mobile node is not 428 authorized for that specific address, the local mobility anchor 429 MUST reject the request and send a Proxy Binding Acknowledgement 430 message with the Status field set to 431 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized 432 for the requesting IPv4 address). It MUST also include the IPv4 433 Address Acknowledgement option [ID-DSMIP6] in the reply with the 434 status field value in the option set to 129 (Administratively 435 prohibited). 437 o If the local mobility anchor is unable to allocate an IPv4 address 438 due to lack of resources, it MUST reject the request and send a 439 Proxy Binding Acknowledgement message with Status field set to 130 440 (Insufficient resources). It MUST also include the IPv4 Address 441 Acknowledgement option [ID-DSMIP6] in the reply with the status 442 field value in the option set to 128 (Failure, reason 443 unspecified). 445 o Upon accepting the request, the local mobility anchor MUST create 446 a Binding Cache entry for this mobility session. However, if the 447 request also contains one or more Home Network Prefix options [ID- 448 DSMIP6], there should still be only one Binding Cache entry that 449 should be created for this mobility session. The created Binding 450 Cache entry MUST be used for managing both IPv4 and IPv6 home 451 address bindings. The fields in the Binding Cache entry MUST be 452 updated with the accepted values for that session. 454 o The local mobility anchor MUST establish a bi-directional tunnel 455 to the mobile access gateway and with the encapsulation mode set 456 to the negotiated mode for carrying the IPv4 payload traffic. 457 When using IPv6 transport, the encapsulation mode is IPv4-over- 458 IPv6 (IPv4 packet carried as a payload of an IPv6 packet). When 459 using IPv4 transport, the encapsulation mode is as specified in 460 Section 4.0. 462 o The local mobility anchor MUST create an IPv4 host route for 463 tunneling the packets received for the mobile node's home address 464 associated with this mobility session. 466 o The local mobility anchor MUST send the Proxy Binding 467 Acknowledgement message with the Status field set to 0 (Proxy 468 Binding Update Accepted). The message MUST be constructed as 469 specified in Section 3.1.2.6. 471 3.1.2.3. Binding Lifetime Extension (No handoff) 473 All the considerations from Section 5.3.3 of [RFC-5213] MUST be 474 applied. 476 3.1.2.4. Binding Lifetime Extension (After handoff) 478 o The local mobility anchor MUST remove the previously created IPv4 479 host route and the dynamically created bi-directional tunnel for 480 carrying the IPv4 payload traffic (if there are no other mobile 481 nodes for which the tunnel is being used). This will remove the 482 routing state towards the mobile access gateway where the mobile 483 node was anchored prior to the handoff. 485 o The local mobility anchor MUST create a bi-directional tunnel to 486 the mobile access gateway that sent the request (if there is no 487 existing bi-directional tunnel) and with the encapsulation mode 488 set to the negotiated mode for carrying the IPv4 payload traffic. 489 An IPv4 host route for tunneling the packets received for the 490 mobile node's IPv4 home address MUST also be added. 492 o The required forwarding state identified in Section 5.3.6 of [RFC- 493 5213] is for IPv6 payload traffic. Those considerations apply for 494 IPv4 payload traffic as well. However, if IPv4 transport is in 495 use, considerations from Section 4.0 MUST be applied. 497 3.1.2.5. Binding De-Registration 499 All the considerations from Section 5.3.5 of [RFC-5213] MUST be 500 applied. Additionally, for removing the IPv4 state as part of the 501 Binding Cache entry deletion, the IPv4 host route and the dynamically 502 created bi-directional tunnel for carrying the IPv4 payload traffic 503 (if there are no other mobile nodes for which the tunnel is being 504 used) MUST be removed. However, if the request is for a selective 505 de-registration (IPv4-only or IPv6-only addresses), the Binding Cache 506 entry MUST not be deleted, only the respective states with respect 507 those addresses MUST be deleted. 509 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 511 The local mobility anchor when sending the Proxy Binding 512 Acknowledgement message to the mobile access gateway MUST construct 513 the message as specified in Section 5.3.6 of [RFC-5213]. 514 Additionally, the following considerations MUST be applied. 516 o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to 517 include at least one instance of Home Network Prefix option [RFC- 518 5213] in the Proxy Binding Acknowledgement message that it sends 519 to the mobile access gateway. However, if the received Proxy 520 Binding Update message has only the IPv4 Home Address option [ID- 521 DSMIP6] and did not contain the Home Network Prefix option(s), 522 then the local mobility anchor MUST NOT include any Home Network 523 Prefix option(s) in the reply. 525 o The IPv4 Address Acknowledgement option [ID-DSMIP6] MUST be 526 present in the Proxy Binding Acknowledgement message. 528 1. If the Status field is set to a value greater than or equal to 529 128, i.e., if the Proxy Binding Update is rejected, then there 530 MUST be an IPv4 Address Acknowledgement option [ID-DSMIP6] 531 corresponding to the IPv4 Home Address option [ID-DSMIP6] 532 present in the request and with the IPv4 address value and the 533 prefix length fields in the option set to the corresponding 534 values in the request. The status field value in the option 535 must be set to the specific error code. 537 2. For all other cases, there MUST be an IPv4 Address 538 Acknowledgement option for carrying the IPv4 home address 539 assigned for that mobility session and with the value in the 540 option set to the allocated IPv4 address. The prefix length 541 in the option MUST be set to the prefix length of the 542 allocated address. The status field value in the option must 543 be set to 0 (Success). 545 o The IPv4 Default-Router Address option MUST be present, if the 546 Status field value in the Proxy Binding Acknowledgement message is 547 set to 0 (Proxy Binding Update Accepted). Otherwise, the option 548 MUST NOT be present. If the option is present, the default-router 549 address in the option MUST be set to the mobile node's default- 550 router address. 552 3.1.2.7. Binding Cache Entry Lookup Considerations 554 The Binding Cache entry lookup considerations specified in Section 555 5.4.1.1 of [RFC-5213] requires the Home Network Prefix [RFC-5213] as 556 the key parameter for identifying the Binding Cache entry. When 557 using an IPv4 address with a NON_ZERO value, the exact same 558 considerations specified in Section 5.4.1.1 of [RFC-5213] MUST be 559 applied, with the exception of using an IPv4 home address in place of 560 an IPv6 home network prefix. 562 3.1.3. Routing Considerations for the Local Mobility Anchor 564 Intercepting Packets Sent to the Mobile Node's IPv4 home address: 566 o When the local mobility anchor is serving a mobile node, it MUST 567 be able to receive packets that are sent to the mobile node's IPv4 568 home address. In order for it to receive those packets, it MUST 569 advertise a connected route in to the Routing Infrastructure for 570 the mobile node's IPv4 home address or for its home subnet. This 571 essentially enables IPv4 routers in that network to detect the 572 local mobility anchor as the last-hop router for that subnet. 574 Forwarding Packets to the Mobile Node: 576 o On receiving a packet from a correspondent node with the 577 destination address matching the mobile node's IPv4 home address, 578 the local mobility anchor MUST forward the packet through the bi- 579 directional tunnel setup for that mobile node. 581 o The format of the tunneled packet when payload protection is not 582 enabled: 584 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 585 IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ 586 Upper layer protocols /* Packet Content*/ 588 Figure 2: Tunneled Packets from LMA to MAG 590 Forwarding Packets Sent by the Mobile Node: 592 o All the reverse tunneled packets that the local mobility anchor 593 receives from the mobile access gateway, after removing the tunnel 594 header MUST be routed to the destination specified in the inner 595 IPv4 packet header. These routed packets will have the source 596 address field set to the mobile node's IPv4 home address. 598 3.2. Mobile Access Gateway Considerations 600 3.2.1. Extensions to Binding Update List Entry 602 To support the IPv4 home address mobility feature, the conceptual 603 Binding Update List entry data structure needs to be extended with 604 the following additional fields. 606 o The IPv4 home address assigned to the mobile node's attached 607 interface. This IPv4 home address may have been statically 608 configured in the mobile node's policy profile, or, may have been 609 dynamically allocated by the local mobility anchor. The IPv4 home 610 address entry also includes the corresponding subnet mask. 612 o The IPv4 default-router address of the mobile node. This is 613 acquired from the mobile node's local mobility anchor through the 614 received Proxy Binding Acknowledgment message. 616 3.2.2. Extensions to Mobile Node's Policy Profile 618 To support the IPv4 Home Address Mobility Support feature the mobile 619 node's policy profile, specified in Section 6.2 of [RFC-5213] MUST be 620 extended with the following additional fields. 622 Extensions to the mandatory section of the policy profile: 624 o This field identifies all the IP protocol versions for which the 625 home address mobility support needs to be extended to the mobile 626 node. The supported modes are IPv4-only, IPv6-only and dual IPv4/ 627 IPv6. 629 Extensions to the optional section of the policy profile: 631 o The IPv4 home address assigned to the mobile node's attached 632 interface. The specific details on how the network maintains the 633 association between the address and the attached interface is 634 outside the scope of this document. This address field also 635 includes the corresponding subnet mask. 637 3.2.3. Signaling Considerations 639 3.2.3.1. Mobile Node Attachment and Initial Binding Registration 641 After detecting a new mobile node on its access link, the mobile 642 access gateway on the access link MUST determine if IPv4 home address 643 mobility support needs to be enabled for that mobile node. The 644 mobile node's policy profile identifies the supported modes (IPv4- 645 only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the 646 mobile service needs to be enabled. Based on those policy 647 considerations and from other triggers such as from the network, if 648 it is determined that IPv4 home address mobility support needs to be 649 enabled for the mobile node, considerations from section 6.9.1.1 of 650 [RFC-5213] MUST be applied with the following exceptions. 652 o The IPv4 Home Address option [ID-DSMIP6] MUST be present in the 653 Proxy Binding Update message. 655 * If the mobile access gateway learns the mobile node's IPv4 home 656 address either from its policy profile, or from other means, 657 the mobile access gateway MAY ask the local mobility anchor to 658 allocate that specific address by including exactly one 659 instance of the IPv4 Home Address option [ID-DSMIP6] with the 660 IPv4 home address and the prefix length fields in the option 661 set to that specific address and its prefix length. 662 Furthermore, the (P) flag in the option MUST be set to 0. 664 * The mobile access gateway MAY also ask the local mobility 665 anchor for dynamic IPv4 home address allocation. It can 666 include exactly one instance of the IPv4 Home Address option 667 with the IPv4 home address and the prefix length fields in the 668 option set to ALL_ZERO value. Furthermore, the (P) flag in the 669 option MUST be set to 0. This essentially serves as a request 670 to the local mobility anchor for the IPv4 home address 671 allocation. 673 o The Proxy Binding Update message MUST be constructed as specified 674 in Section 6.9.1.5 of [RFC-5213]. However, the Home Network 675 Prefix option(s) [RFC-5213] MUST be present in the Proxy Binding 676 Update only if IPv6 home address mobility support also needs to be 677 enabled for the mobile node. Otherwise, the Home Network Prefix 678 option(s) MUST NOT be present. 680 o When using IPv4 transport for carrying the signaling messages, the 681 related considerations from section 4.0 MUST be applied 682 additionally. 684 3.2.3.2. Receiving Proxy Binding Acknowledgement 686 All the considerations from section 6.9.1.2 of [RFC-5213] MUST be 687 applied with the following exceptions. 689 o If the received Proxy Binding Acknowledgement message has the 690 Status field value set to 691 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS_SUPPORT (The mobile node is 692 not authorized for IPv4 home address support), the mobile access 693 gateway SHOULD NOT send a Proxy Binding Update message including 694 the IPv4 Home Address option [ID-DSMIP6] till an administrative 695 action is taken. 697 o If the received Proxy Binding Acknowledgement message has the 698 Status field value set to NOT_AUTHORIZED_FOR_REQ_IPV4_HOME_ADDRESS 699 (The mobile node is not authorized for the requesting IPv4 home 700 address), the mobile access gateway SHOULD NOT request for the 701 same address again, but MAY request the local mobility anchor to 702 do the assignment of address by including exactly one instance if 703 IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address 704 and the prefix length fields in the option set to ALL_ZERO value. 706 o If there is no IPv4 Address Acknowledgement option [ID-DSMIP6] 707 present in the received Proxy Binding Acknowledgement message, the 708 mobile access gateway MUST NOT enable IPv4 support for the mobile 709 node and the rest of the considerations from this section can be 710 skipped. 712 o If the received Proxy Binding Acknowledgement message has the 713 Status field value in the IPv4 Address Acknowledgement Option [ID- 714 DSMIP6] set to a value that indicates that the request was 715 rejected by the local mobility anchor, the mobile access gateway 716 MUST NOT enable forwarding for that specific IPv4 home address. 718 o If the received Proxy Binding Acknowledgement message has the 719 Status field value set to 0 (Proxy Binding Update accepted), the 720 mobile access gateway MUST update a Binding Update List entry for 721 that mobile node. The entry MUST be updated with the assigned 722 IPv4 home address and other accepted registration values. 724 o If the received Proxy Binding Acknowledgement message has the 725 Status field value set to 0 (Proxy Binding Update accepted) and 726 has the IPv4 Address Acknowledgement Option [ID-DSMIP6] set to a 727 value that indicates that the request was accepted by the local 728 mobility anchor, the mobile access gateway MUST establish a bi- 729 directional tunnel to the local mobility anchor (if there is no 730 existing bi-directional tunnel to that local mobility anchor) and 731 with the encapsulation mode set to IPv4-over-IPv6 (IPv4 packet 732 carried as a payload of an IPv6 packet). Considerations from 733 Section 5.6.1 of [RFC-5213] MUST be applied for managing the 734 dynamically created bi-directional tunnel. However, when using 735 IPv4 transport, the encapsulation mode MUST be set to the 736 negotiated encapsulation mode, as specified in Section 4 of this 737 specification. 739 o The mobile access gateway MUST set up the route for forwarding the 740 IPv4 packets received from the mobile node (using its IPv4 home 741 address) through the bi-directional tunnel set up for that mobile 742 node. 744 o If there is an IPv4 Default-Router Address option present in the 745 received Proxy Binding Acknowledgement message, the mobile access 746 gateway MAY configure this address on its interface and respond to 747 any ARP requests sent by the mobile node for resolving the 748 hardware address of the default-router. 750 3.2.3.3. Binding Re-Registration and De-Registrations 752 When sending a Proxy Binding Update either for extending the lifetime 753 of a mobility session or for de-registering the mobility session, the 754 respective considerations from [RFC-5213] MUST be applied. 755 Furthermore, the following additional considerations MUST also be 756 applied. 758 o If there is an IPv4 home address assigned to the mobility session, 759 then there MUST be exactly one instance of the IPv4 Home Address 760 option [ID-DSMIP6] present in the Proxy Binding Update message. 761 The IPv4 home address and the prefix length fields in the option 762 MUST be set to that specific address and its corresponding subnet- 763 mask length. The (P) flag in the option MUST be set to 0. 765 o If there was no IPv4 home address requested in the initial Proxy 766 Binding Update message, but if it is determined that the IPv4 home 767 address MUST be requested subsequently, then there MUST be exactly 768 one instance of the IPv4 Home Address option [ID-DSMIP6] present 769 in the Proxy Binding Update message. The IPv4 home address in the 770 option MUST be set to either ALL_ZERO or to a specific address 771 that is being requested. 773 o For performing selective de-registration of the IPv4-only home 774 address, but still retaining the mobility session with all the 775 IPv6 home network prefixes, the Proxy Binding Update message with 776 the lifetime value of 0 MUST NOT include any IPv6 Home Network 777 Prefix options(s) [RFC-5213]. It MUST include exactly one 778 instance of the IPv4 Home Address option [ID-DSMIP6] with the IPv4 779 home address and the prefix length fields in the option set to the 780 IPv4 home address that is being deregistered. 782 o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present 783 if the same option(s) was not present in the initial Proxy Binding 784 Update message. Otherwise considerations from [RFC-5213] with 785 respect to this option MUST be applied. 787 3.2.4. Routing Considerations for the Mobile Access Gateway 789 o On receiving a packet from the bi-directional tunnel established 790 with the mobile node's local mobility anchor, the mobile access 791 gateway MUST remove the outer header before forwarding the packet 792 to the mobile node. 794 o Considerations from Section 6.10.3 of [RFC-5213] MUST be applied 795 with respect the local routing and on the use of 796 EnableMAGLocalRouting flag. 798 o On receiving a packet from a mobile node connected to its access 799 link, the packet MUST be forwarded to the local mobility anchor 800 through the bi-directional tunnel established with the local 801 mobility anchor. The encapsulation considerations specified in 802 section 3.1.3 MUST be applied. 804 3.3. Mobility Options and Status Codes 806 To support the IPv4 home address mobility feature, this specification 807 defines the following new options and Status Codes. 809 3.3.1. IPv4 Default-Router Address Option 811 A new option, IPv4 Default-Router Address Option is defined for using 812 it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the 813 local mobility anchor to the mobile access gateway. This option can 814 be used for sending the mobile node's IPv4 default-router address. 816 The IPv4 Default-Router Address option has an alignment requirement 817 of 4n. Its format is as follows: 819 0 1 2 3 820 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 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Type | Length | Reserved (R) | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | IPv4 Default-Router Address | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 Figure 3: IPv4 Default-Router Address Option 829 Type 831 IANA 833 Length 835 8-bit unsigned integer indicating the length of the option in 836 octets, excluding the type and length fields. This field MUST 837 be set to 6. 839 Reserved (R) 841 This 8-bit field is unused for now. The value MUST be 842 initialized to 0 by the sender and MUST be ignored by the 843 receiver. 845 IPv4 Default-Router Address 847 A four-byte field containing the mobile node's default router 848 address. 850 3.3.2. Status Codes 852 This document defines the following new Status values for use in the 853 Proxy Binding Acknowledgement message [RFC-5213]. These values are 854 to be allocated from the same numbering space, as defined in Section 855 6.1.8 of [RFC-3775]. 857 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 859 Mobile node not authorized for the requesting IPv4 home address 861 3.4. Supporting DHCP-Based Address Configuration 863 This section explains how DHCP-based address configuration support 864 can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It 865 explains the protocol operation, supported DHCP server deployment 866 configurations and the protocol interactions between DHCP agents and 867 mobility entities in each of the supported configurations. 869 This specification supports the following two DHCP deployment 870 configurations. 872 o DHCP relay agent co-located with the mobile access gateway. 874 o DHCP server co-located in the mobile access gateway. 876 The following are the configuration requirements: 878 o The DHCP server or the DHCP relay agent configured on the mobile 879 access gateway is required to have an IPv4 address for exchanging 880 the DHCP messages with the mobile node. This address can be 881 either the IPv4 Proxy Care-of Address or the mobile node's 882 default-router address provided by the local mobility anchor. 884 Optionally, all the DHCP servers co-located with the mobile access 885 gateways in the Proxy Mobile IPv6 domain can be configured with a 886 fixed IPv4 address. This fixed address can be potentially an IPv4 887 link-local address [RFC-3927] that can be used for the DHCP 888 protocol communication on any of the access links. This address 889 will be used as the server identifier in the DHCP messages. 891 o The DHCP server identifies the DHCP client either from the client 892 identifier or the client hardware address (chaddr) [RFC-2131]. A 893 mobile node in a Proxy Mobile IPv6 domain may present any of these 894 identifiers to the DHCP server as long as the identifier remains 895 the same through out the mobile node's attachment in that Proxy 896 Mobile IPv6 domain. If the client hardware address is used as the 897 identifier and if the mobile node performs an handoff between two 898 interfaces, this hardware identifier will change and the DHCP 899 server will not be able to identify the mobile node. Thus, it is 900 recommended that the DHCP client in a multihomed mobile node is 901 configured to use a stable client identifier that does not change 902 during the active life of its DHCP session. 904 o All the DHCP servers co-located with the mobile access gateways in 905 a Proxy Mobile IPv6 domain can be configured with the same set of 906 DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure 907 the mobile node receives the same configuration values on any of 908 the access links in that Proxy Mobile IPv6 domain. 910 3.4.1. DHCP Server co-located with the Mobile Access Gateway 912 This section explains the operational sequence of home address 913 assignment operation when the DHCP server is co-located with the 914 mobile access gateway. 916 MN MAG(DHCP-S) LMA 917 |------>| | 1. DHCPDISCOVER 918 | |------->| 2. Proxy Binding Update 919 | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) 920 | |========| 4. Tunnel/Route Setup 921 |<------| | 5. DHCPOFFER (IPv4 HoA) 922 |------>| | 6. DHCPREQUEST (IPv4 HoA) 923 |<------| | 7. DHCPACK 924 | | | 925 * DHCPDISCOVER (Step-1) and Proxy Mobile IPv6 signaling 926 * (Step-2 to Step-4) may happen in parallel and in no specific order 927 * Tunnel/Route setup(Step-4) and the subsequent steps will happen in 928 * in the specified order. 930 Figure 4: Overview of DHCP Server located at Mobile Access Gateway 932 Initial IPv4 Home Address Assignment: 934 o When a mobile node attached to an access link sends a DHCPDISCOVER 935 message [RFC-2131], the DHCP server co-located with the mobile 936 access gateway will trigger the mobile access gateway to complete 937 the Proxy Mobile IPv6 signaling. This is the required interaction 938 between these two protocols. If the mobile access gateway is 939 unable to complete the Proxy Mobile IPv6 signaling, or, if the 940 local mobility anchor does not assign an IPv4 address for the 941 mobile node, the mobile access gateway MUST NOT enable IPv4 942 support for the mobile node on that access link. 944 o After a successful completion of the Proxy Mobile IPv6 signaling 945 and acquiring the mobile node's IPv4 home address assigned by the 946 local mobility anchor, the DHCP server on the mobile access 947 gateway will send a DHCPOFFER message [RFC-2131] to the mobile 948 node. The offered address will the mobile node's IPv4 home 949 address, assigned by the local mobility anchor. The server 950 address, 'siaddr' field of the DHCPOFFER message, will be set to 951 the mobile node's default-router address, or, to the address set 952 in the FixedDHCPServerId configuration variable. The DHCPOFFER 953 message will be unicasted to the mobile node. 955 o If the mobile node sends the DHCPREQUEST message, the DHCP server 956 will send DHCPACK message, as per [RFC-2131]. 958 IPv4 Home Address Renewal with the DHCP server (No Handoff): 960 o Any time the DHCP client goes into the DHCP RENEWING state [RFC- 961 2131], it simply unicasts the DHCPREQUEST message including the 962 assigned IPv4 home address in the 'requested IP address' option. 963 The DHCPREQUEST is sent to the address specified in 'server 964 identifier' field of the previously received DHCPOFFER and DHCPACK 965 messages. 967 o The DHCP server will send a DHCPACK to the mobile node to 968 acknowledge the assignment of the committed IPv4 address. 970 IPv4 Home Address Renewal with a different DHCP server (After 971 Handoff): 973 When the DHCP client goes into the DHCP RENEWING state [RFC-2131], it 974 directly unicasts the DHCPREQUEST message to the DHCP server that 975 currently provided the DHCP lease. However, if the mobile node 976 changed its point of attachment and is attached to a new mobile 977 access gateway, it is required that the mobile node updates the DHCP 978 server address and uses the address of the DHCP server that is on co- 979 located on the new mobile access gateway. Any of the following 980 approaches can be adopted for forcing the DHCP server address change. 982 1. The use of fixed DHCP server address on all DHCP servers 983 MN oMAG(DHCP-S) nMAG(DHCP-S) 984 | : | 985 RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) 986 BOUND<-------------| 2. DHCPACK or DHCPNACK 987 | : | 989 2. The use of FORCERENEW message to notify the address change 990 MN prev-MAG (DHCP-S) new-MAG (DHCP-S) 991 | : | 992 RENEW------------->| 1. DHCPREQUEST*a (IPv4 HoA) 993 |<---------------| 2. FORCERENEW 994 |--------------->| 3. DHCPREQUEST*b (IPv4 HoA) 995 BOUND<-------------| 4. DHCPACK or DHCPNACK 996 | : | 997 *a DHCPREQUEST sent to oMAG 998 *b DHCPREQUEST sent to nMAG 1000 3. The use of different address on different DHCP servers 1001 MN prev-MAG (DHCP-S) new-MAG (DHCP-S) 1002 | : | 1003 RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) 1004 | : | (discarding & timeout) 1005 REBINDING--------->| 2. DHCPDISCOVER 1006 |<---------------| 3. DHCPOFFER (IPv4 HoA) 1007 |--------------->| 4. DHCPREQUEST(IPv4 HoA) 1008 BOUND<-------------| 5. DHCPACK (IPv4 HoA) 1009 | : | 1011 Figure 5: Address renewal with a different DHCP server 1013 o If a fixed DHCP server address is used by all the mobile access 1014 gateways in the Proxy Mobile IPv6 domain, the DHCPREQUEST message 1015 sent by the mobile node for renewing the address will be received 1016 by the new mobile access gateway on the attached link. The mobile 1017 access gateway after completing the Proxy Mobile IPv6 signaling 1018 and upon acquiring the IPv4 home address of the mobile node will 1019 return the address in the DHCPACK message. However, if the mobile 1020 access gateway is unable to complete the Proxy Mobile IPv6 1021 signaling or is unable to acquire the same IPv4 address as 1022 requested by the mobile node, it will send a DHCPNACK message 1023 [RFC-2131] to the mobile node, as shown in Figure 5-1). 1025 o If the mobile access gateway on the access link receives any DHCP 1026 messages from the mobile node unicasted to a server address that 1027 is not locally configured, the mobile access gateway can unicast 1028 FORCERENEW message [RFC-3203] to the mobile node as shown in 1029 Figure 5-2). This will force the mobile node to update the DHCP 1030 server address with the address of the mobile access gateway on 1031 the new link. 1033 o If a fixed IPv4 address is not used by all the DHCP servers in the 1034 Proxy Mobile IPv6 domain and if the FORCERENEW message [RFC-3203] 1035 is also not supported by the DHCP server on the mobile access 1036 gateway, then that DHCPREQUEST message should be ignored. This 1037 will force the mobile node to enter the DHCP REBINDING state [RFC- 1038 2131] and start the DHCPDISCOVER phase, as shown in Figure 5-3). 1040 Additional Operation: 1042 o If at any point the mobile access gateway fails to extend the 1043 binding lifetime with the local mobility anchor, it MUST send an 1044 unsolicited DHCPNAK message [RFC-2131] to the mobile node. 1046 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway 1048 A DHCP relay is co-located with each mobile access gateway. A DHCP 1049 server is located somewhere in the Proxy Mobile IPv6 domain (e.g., is 1050 co-located with the local mobility anchor). Figure 6 shows the 1051 sequence of IPv4 home address assignment using DHCP Relay. 1053 MN MAG(DHCP-R) LMA DHCP-S 1054 | |------->| | 1. Proxy Binding Update * 1055 | |<-------| | 2. Proxy Binding Acknowledgement (IPv4HoA) 1056 | |========| | 3. Tunnel/Route Setup* 1057 |------>|-------------->| 4. DHCPDISCOVER (IPv4HoA) via DHCP-R 1058 |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R 1059 |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R 1060 |<------|<--------------| 7. DHCPACK via DHCP-R 1061 | | | 1062 * The Proxy Mobile IPv6 signaling (Step-1 to Step-2) and the 1063 DHCPDISCOVER phase (Step-4) may occur in any order. However, 1064 the DHCPOFFER (Step-5) and the following steps will occur in 1065 the specified order and after the Tunnel/Route Setup (Step-3). 1067 Figure 6: Overview of the DHCP relay located at mobile access gateway 1069 Initial IPv4 Home Address Assignment: 1071 o When the mobile access gateway receives a DHCPDISCOVER message 1072 from a mobile node, it MUST check whether it has already obtained 1073 the IPv4 home address for the mobile node from the local mobility 1074 anchor. 1076 o If the IPv4 home address is not yet assigned by the local mobility 1077 anchor, the mobile access gateway MUST send a Proxy Binding Update 1078 for that. 1080 o If the IPv4 home address is not assigned to the mobile node by the 1081 local mobility anchor due to administrative policy or resource 1082 limitation, it MUST discard the DHCPDISCOVER messages from the 1083 mobile node. 1085 o Otherwise, it MUST add the DHCP relay agent information option 1086 [RFC-3046] to the DHCPDISCOVER message. The assigned IPv4 home 1087 address (32-bit full address) is included in the Agent Remote ID 1088 Sub-option of the DHCP relay agent information option. This sub- 1089 option is used as a hint of address assignment of the DHCP server. 1091 o When the mobile access gateway receives the DHCPOFFER from the 1092 DHCP server, it MUST verify whether the DHCP server offers the 1093 correct IPv4 home address which is indicated in the Agent Remote 1094 ID Sub-option of the DHCPDISOCVERY. If the DHCP server offers the 1095 different address from the expected address, the mobile access 1096 gateway MUST drop the DHCPOFFER. 1098 o After the successful relaying the DHCPOFFER, the mobile access 1099 gateway acts as a regular DHCP relay agent as [RFC-2131]. 1101 o As shown in Figure 6, the DHCP messages MAY be sent across an 1102 administrative boundaries. The operators MUST ensure to secure 1103 these messages. All the DHCP messages relayed by the mobile 1104 access gateway can be tunneled over the local mobility anchor if 1105 needed. Alternatively, if the networks in the Proxy Mobile IPv6 1106 domain are secured enough, the mobile access gateway just relays 1107 the DHCP messages to the server without the tunnel. For doing 1108 this, all the mobile access gateway MUST have the route toward the 1109 DHCP server. More remarks can be found in Section 7. 1111 IPv4 Home Address Renewal to the same DHCP server: (No Handover) 1113 o When the DHCP client goes into the DHCP-RENEWING-STATE [RFC-2131], 1114 it directly unicasts DHCPREQUEST message to the DHCP server. The 1115 DHCP relay agent cannot receive the DHCPREQUEST for renewing 1116 addresses. Thus, one of following operations is required. 1118 * The DHCP relay agent SHOULD intercept all the DHCP packets 1119 regardless of the destination address. Since the link between 1120 a mobile node and a mobile access gateway is the point-to-point 1121 link, it is possible to check the DHCP packets at the interface 1122 by enabling the promiscuous mode. 1124 * The cost of monitoring packets is not negligible. Therefore, 1125 The DHCP relay agent MAY use the DHCP Server Identifier 1126 Override Sub-option [RFC-5107] to intercept DHCPREQUESTs for 1127 the address renewal. The DHCP client uses the DHCP server 1128 address which is overridden by the DHCP relay agent address as 1129 a destination address of DHCPREQUEST. The DHCP Server 1130 Identifier Override Sub-option is recommended only when the 1131 Virtual DHCP address is configured on all the mobile access 1132 gateways. Otherwise, the DHCP relay agent address is changed 1133 when the mobile node changes the attached mobile access 1134 gateway. As a result, the DHCP relay agent MUST monitor DHCP 1135 packets by force as described above. 1137 o Once the DHCP relay agent intercepts the DHCPREQUEST from the 1138 mobile node, it MUST verify the requesting IPv4 home address 1139 stored in the DHCPREQUEST message. The verification is operated 1140 by checking it with the binding update list for the mobile node. 1141 If the requesting IPv4 home address is not registered to the local 1142 mobility anchor, the mobile access gateway MUST NOT relay the 1143 DHCPREQUEST and MUST discard it. 1145 o If the address verification is successfully completed, the DHCP 1146 relay agent SHOULD forward the DHCPREQUEST to the DHCP server. 1148 Additional Operations: 1150 o If the mobile access gateway sends Proxy Binding Update for the 1151 IPv4 home address and receives the unsuccessful Proxy Binding 1152 Acknowledgement (as indicated by the error codes), it MUST send 1153 unsolicited DHCPNACK for the invalid IPv4 home address to the 1154 mobile node. 1156 4. IPv4 Transport Support 1158 The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling 1159 messages exchanged between the local mobility anchor and the mobile 1160 access gateway to be over an IPv6 transport. The extensions defined 1161 in this section allow the exchange of signaling messages over an IPv4 1162 transport when the local mobility anchor and the mobile access 1163 gateway are separated by an IPv4 network and are reachable using only 1164 IPv4 addresses. 1166 IPv4-Proxy-CoA IPv4-LMAA 1167 | + - - - - - - + | 1168 +--+ +---+ / \ +---+ +--+ 1169 |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| 1170 +--+ +---+ \ / +---+ +--+ 1171 + - - - - - - + 1173 Figure 7: IPv4 Transport Network 1175 When the local mobility anchor and the mobile access gateway are 1176 configured and reachable using only IPv4 addresses, the mobile access 1177 gateway serving a mobile node can potentially send the signaling 1178 messages over IPv4 transport and register its IPv4 address as the 1179 care-of address in the mobile node's Binding Cache entry. An IPv4 1180 tunnel (with any of the supported encapsulation modes) can be used 1181 for tunneling the mobile node's data traffic. The following are the 1182 key aspects of this feature. 1184 o The local mobility anchor and the mobile access gateway are both 1185 configured and reachable using an IPv4 address. Additionally, 1186 both entities are also IPv6 enabled and have configured IPv6 1187 addresses on their interfaces, as specified in [RFC-5213], but are 1188 reachable only over an IPv4 transport. 1190 o The mobile access gateway can be potentially in a private IPv4 1191 network behind a NAT [RFC-3022] device, with a private IPv4 1192 address configured on its egress interface. However, the local 1193 mobility anchor must not be behind a NAT and must be using a 1194 globally routable IPv4 address. 1196 o The Proxy Mobile IPv6 signaling messages exchanged between the 1197 local mobility anchor and the mobile access gateway for 1198 negotiating the IPv4 transport will be encapsulated and carried as 1199 IPv4 packets. However, these signaling messages are fundamentally 1200 IPv6 messages using the mobility header and the related semantics 1201 as specified in base Proxy Mobile IPv6 specification [RFC-5213], 1202 but carried as a payload in an IPv4 packet. The supported 1203 encapsulation modes for the signaling messages are either native 1204 IPv4 or IPv4 with UDP header. 1206 o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and 1207 the IPv4 transport support specified in this section is agnostic 1208 to the type of address mobility enabled for that mobile node. 1210 o The IPv4 tunnel established between the local mobility anchor and 1211 the mobile access gateway (with any of the supported encapsulation 1212 modes over IPv4 transport) will be used for carrying the mobile 1213 node's IPv4 and IPv6 traffic. The supported encapsulation modes 1214 for carrying mobile node's IPv4 or IPv6 packets when using IPv4 1215 transport are as shown below. 1217 * IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet) 1219 * IPv4-UDP (Payload packet carried in an IPv4 packet with UDP 1220 header). 1222 * IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP 1223 and TLV header). Refer to [ID-DSMIP6]. 1225 * IPv4-UDP-ESP (Payload packet carried in an IPv4 packet with UDP 1226 and ESP headers). Refer to [RFC-3948]. 1228 4.1. Local Mobility Anchor Considerations 1230 4.1.1. Extensions to Binding Cache Entry 1232 To support this feature, the conceptual Binding Cache entry data 1233 structure maintained by the local mobility anchor [RFC-5213] MUST be 1234 extended with the following additional parameters. 1236 o The IPv4 address of the mobile access gateway. This is the 1237 address configured on the egress interface of the mobile access 1238 gateway that sent the Proxy Binding Update message. This address 1239 can be obtained from the IPv4 Care-of Address option [ID-DSMIP6], 1240 present in the received Proxy Binding Update message. If the 1241 option was not present in the request, this field MUST be set to 1242 the source address of the IPv4 header of the received Proxy 1243 Binding Update message. However, if the received Proxy Binding 1244 Update message is not sent as an IPv4 packet, this field MUST be 1245 set to ALL_ZERO value. 1247 o The IPv4 NAT translated address of the mobile access gateway. If 1248 the mobile access gateway is not behind a NAT [RFC-3022], this 1249 address will be the same as the address configured on the egress 1250 interface of the mobile access gateway. This address can be 1251 obtained from the IPv4 header of the received Proxy Binding Update 1252 message. However, if the received Proxy Binding Update message is 1253 not sent as an IPv4 packet, this field MUST be set to ALL_ZERO 1254 value. 1256 4.1.2. Extensions to Mobile Node's Policy Profile 1258 To support the IPv4 Transport Support feature the mobile node's 1259 policy profile, specified in Section 6.2 of [RFC-5213] MUST be 1260 extended with the following additional fields. This are mandatory 1261 fields of the policy profile required for supporting this feature. 1263 o A flag indicating whether or not IPv4 transport should be used. 1264 The value of this flag can vary at different mobile access 1265 gateways. The specific details on how this flag is maintained on 1266 a per mobile access gateway basis is outside the scope of this 1267 document. 1269 o The IPv4 address of the local mobility anchor (IPv4-LMAA). 1271 4.1.3. Signaling Considerations 1273 This section provides the rules for processing the Proxy Mobile IPv6 1274 signaling messages received over IPv4 transport. 1276 4.1.3.1. Processing Proxy Binding Updates 1278 o If the received Proxy Binding Update message (encapsulated in IPv4 1279 or IPv4-UDP header) is protected using IPsec ESP header, then the 1280 message MUST be authenticated as described in Section 4 of [RFC- 1281 5213]. However, if the IPv4 packet is not protected using IPsec 1282 ESP header, then the message MUST be authenticated after removing 1283 the outer encapsulation (IPv4 or IPv4-UDP) header. 1285 o All the considerations from Section 5.3.1 of [RFC-5213] MUST be 1286 applied on the encapsulated Proxy Binding Update message, after 1287 removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1289 o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in 1290 the request and if the outer encapsulation header is IPv4-UDP, 1291 then the NAT presence detection procedure specified in Section 1292 4.1.3.3 MUST be used for detecting the NAT in the path. 1294 o Upon accepting the request, the local mobility anchor MUST set up 1295 an IPv4 bi-directional tunnel to the mobile access gateway. The 1296 tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. 1298 The encapsulation mode MUST be determined from the below 1299 considerations. 1301 * If the received Proxy Binding Update message was sent with IPv4 1302 encapsulated header, then the encapsulation mode for the bi- 1303 directional tunnel MUST be set to IPv4. Otherwise, the 1304 following considerations apply. 1306 * If a NAT is detected on the path, or if the (F) flag in the 1307 received Proxy Binding Update message is set to the value of 1, 1308 then the encapsulation mode MUST be set to IPv4-UDP. Otherwise 1309 the encapsulation mode MUST be set to IPv4. 1311 * If the (T) flag in the Proxy Binding Update message is set to 1312 value of 1, then the encapsulation mode MUST be set to IPv4- 1313 UDP-TLV. 1315 o The local mobility anchor MUST send the Proxy Binding 1316 Acknowledgement message with the Status field value set to 0 1317 (Proxy Binding Update Accepted). The message MUST be constructed 1318 as specified in Section 4.1.3.2. 1320 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 1322 The local mobility anchor when sending the Proxy Binding 1323 Acknowledgement message to the mobile access gateway MUST construct 1324 the message as specified in Section 5.3.6 of [RFC-5213]. However, if 1325 the received Proxy Binding Update message was encapsulated in an IPv4 1326 packet or as a payload in the UDP header of an IPv4 packet, the 1327 following additional considerations MUST be applied. 1329 o The Proxy Binding Acknowledgement message MUST be encapsulated in 1330 an IPv4 packet. However, if the received Proxy Binding Update 1331 message was encapsulated in the UDP header of an IPv4 packet, then 1332 the message MUST be encapsulated in the UDP header of an IPv4 1333 packet. 1335 o The source address in the IPv4 header of the message MUST be set 1336 to the destination IPv4 address of the received request. 1338 o If the mobile access gateway and the local mobility anchor are 1339 using globally routable IPv4 addresses and if there is a security 1340 associated that is based of IPv4 addresses, then the encapsulated 1341 IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement) 1342 MUST be protected using IPsec ESP [RFC-4301] mode. There is no 1343 need to apply IPsec ESP header to the IPv6 packet. In all other 1344 cases, the Proxy Binding Acknowledgement message MUST be protected 1345 using IPsec prior to the IPv4 or IPv4-UDP encapsulation. 1347 o The NAT Detection option [ID-DSMIP6] MUST be present only if there 1348 is a IPv4 Care-of Address option [ID-DSMIP6] present in the 1349 received Proxy Binding Update and if the NAT detection procedure 1350 resulted in detecting a NAT on path. In all other cases, the 1351 option MUST NOT be present. 1353 o The format of the Proxy Binding Acknowledgement message 1354 encapsulated in an IPv4 packet and protected using IPv6 security 1355 association. The UDP header MUST be present only if the received 1356 Proxy Binding Update message was sent with IPv4-UDP encapsulation 1357 header. 1359 IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) 1360 UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/ 1361 /* IPv6 PBA Packet protected with ESP header */ 1363 Figure 8: Proxy Binding Acknowledgment (PBA) Message encapsulated 1364 in IPv4 header 1366 o The format of the Proxy Binding Acknowledgement message 1367 encapsulated in an IPv4 packet and protected using IPv4 security 1368 association. 1370 IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) 1371 ESP Header 1372 UDP header (sport=DSMIP_PORT, dport= pbu_sport) /* Optional */ 1373 /* IPv6 PBA Packet protected with no ESP header */ 1375 Figure 9: Proxy Binding Acknowledgment (PBA)Message encapsulated 1376 in IPv4 ESP header 1378 4.1.3.3. NAT Presence Detection 1380 When the transport network between the local mobility anchor and the 1381 mobile access gateway is an IPv4 network, the mobile access gateway 1382 will send the Proxy Binding Update messages encapsulated in the IPv4- 1383 UDP packet. On receiving this Proxy Binding Update packet 1384 encapsulated in an IPv4-UDP packet, the local mobility anchor if it 1385 detects a NAT on the path, will send the Proxy Binding Acknowledgment 1386 message with the NAT Detection Option. The presence of this option 1387 in the Proxy Binding Acknowledgment is an indication to the mobile 1388 access gateway about the presence of NAT in the path. On detecting 1389 any NAT in the path, both the local mobility anchor and the mobile 1390 access gateway MUST set the encapsulation mode of the tunnel to IPv4- 1391 UDP-based encapsulation. The specific details around the NAT 1392 detection and the related logic are described in DSMIPv6 1393 specification [ID-DSMIP6]. 1395 4.1.4. Routing Considerations 1397 4.1.4.1. Forwarding Considerations 1399 Forwarding Packets to the Mobile Node: 1401 o On receiving an IPv4 or an IPv6 packet from a correspondent node 1402 with the destination address matching any of the mobile node's 1403 IPv4 or IPv6 home addresses, the local mobility anchor MUST 1404 forward the packet through the bi-directional tunnel set up for 1405 that mobile node. 1407 o The format of the tunneled packet is shown below. 1409 IPv4 Header (src= IPv4-LMAA, dst= IPv4-Proxy-CoA)] /* Tunnel Header */ 1410 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1411 [TLV Header] /* If TLV negotiated */ 1412 /* IPv6 or IPv4 Payload Packet */ 1413 IPv6 header (src= CN, dst= MN-HOA) 1414 OR 1415 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1417 Figure 10: Tunneled IPv4 Packet from LMA to MAG 1419 o Forwarding Packets Sent by the Mobile Node: 1421 * All the reverse tunneled packets (IPv4 and IPv6) that the local 1422 mobility anchor receives from the mobile access gateway, after 1423 removing the tunnel header (i.e., the outer IPv4 header along 1424 with the UDP and TLV header, if negotiated) MUST be routed to 1425 the destination specified in the inner packet header. These 1426 routed packets will have the source address field set to the 1427 mobile node's home address. 1429 4.1.4.2. ECN Considerations 1431 The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply 1432 for the IPv4 transport tunnels as well. The mobility agents at the 1433 tunnel entry and exit points MUST handle ECN information as specified 1434 in that document. 1436 4.1.4.3. Bi-Directional Tunnel Management 1438 The Tunnel Management considerations specified in section 5.6.1 of 1439 [RFC-5213] apply for the IPv4 transport tunnels as well, with just 1440 one difference that the encapsulation mode is different. 1442 4.2. Mobile Access Gateway Considerations 1444 4.2.1. Extensions to Binding Update List Entry 1446 To support the IPv4 Transport Support feature, the conceptual Binding 1447 Update List entry data structure maintained by the mobile access 1448 gateway [RFC-5213] MUST be extended with the following additional 1449 parameters. 1451 o The IPv4 address of the local mobility anchor. This address can 1452 be obtained from the mobile node's policy profile. 1454 o The IPv4 address of the mobile access gateway. This is the 1455 address configured on the egress interface of the mobile access 1456 gateway and is registered with the mobile node's local mobility 1457 anchor as the IPv4 Proxy-CoA. However, if the mobile access 1458 gateway is in a private IPv4 network and behind a NAT, the address 1459 that is registered with the mobile node's local mobility anchor is 1460 the NAT translated public IPv4 address. 1462 4.2.2. Signaling Considerations 1464 The mobile access gateway when sending a Proxy Binding Update message 1465 to the local mobility anchor MUST construct the message as specified 1466 in Section 6.9.1.5. However, if the mobile access gateway is in an 1467 IPv4-only access network, the following additional considerations 1468 MUST be applied. 1470 o The Proxy Binding Update message MUST be encapsulated in an IPv4 1471 packet. However, if the value of the configuration variable, 1472 UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy 1473 Binding Update message MUST be encapsulated in an UDP header of an 1474 IPv4 packet. 1476 o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The 1477 IPv4 address in the option MUST be set to the mobile access 1478 gateway's IPv4-Proxy-CoA. 1480 o The packet MUST be constructed as specified in Section 4.2.3. 1482 o When sending a Proxy Binding message for extending the lifetime of 1483 a currently existing mobility session or for de-registering the 1484 mobility session, the Proxy Binding Update message MUST be 1485 constructed as the initial request. 1487 Receiving Proxy Binding Acknowledgement 1489 o If the received Proxy Binding Acknowledgement message 1490 (encapsulated in IPv4 or IPv4 UDP packet) is protected using IPsec 1491 ESP header, then the message MUST be authenticated as described in 1492 Section 4 of [RFC-5213]. However, if the IPv4 packet is not 1493 protected using IPsec ESP header, then the message MUST be 1494 authenticated after removing the outer IPv4 or IPv4-UDP header. 1496 o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be 1497 applied on the encapsulated Proxy Binding Acknowledgement message, 1498 after removing the outer IPv4 UDP header. 1500 o If the Status field indicates Success, the mobile access gateway 1501 MUST setup a bi-directional tunnel to the local mobility anchor. 1503 o Upon accepting the request, the local mobility anchor MUST set up 1504 an IPv4 bi-directional tunnel to the mobile access gateway. The 1505 tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. 1506 The encapsulation mode MUST be determined from the below 1507 considerations. 1509 * The encapsulation mode for the bi-directional tunnel MUST be 1510 set to IPv4. However, if the value of the configuration 1511 variable, UseIPv4UDPEncapForSignalingMessages, is set to 1, 1512 then the following considerations MUST be applied. 1514 * If there is a NAT Detection option [ID-DSMIP6] in the received 1515 Proxy Binding Acknowledgement message, then the encapsulation 1516 mode for the tunnel MUST be set to IPv4-UDP. Otherwise the 1517 encapsulation mode MUST be set to IPv4. 1519 * If the (T) flag in the Proxy Binding Acknowledgement message is 1520 set to value of 1, then the encapsulation mode MUST be set to 1521 IPv4-UDP-TLV. 1523 4.2.2.1. Constructing the Proxy Binding Update Message 1525 o The source address in the IPv4 header MUST be set to IPv4-Proxy- 1526 CoA of the mobile access gateway and the destination address MUST 1527 be set to the local mobility anchor's IPv4-LMAA. 1529 o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The 1530 address MUST be set to the mobile access gateway's IPv4-Proxy-CoA. 1532 o If the configuration variable ForceIPv4UDPEncapsulationSupport is 1533 set to value of 1, then the (F) flag in the Proxy Binding Update 1534 message MUST be set to value of 1. 1536 o If the mobile access gateway and the local mobility anchor are 1537 using globally routable IPv4 addresses and if there is a security 1538 associated that is based of IPv4 addresses, then the encapsulated 1539 IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement 1540 message) MUST be protected using IPsec ESP [RFC-4301] mode and 1541 additionally there is no need to apply ESP header on the IPv6 1542 packet. In all other cases, the Proxy Binding Update message MUST 1543 be protected on the IPv6 packet of the Proxy Binding Update 1544 message, prior to the IPv4 encapsulation. 1546 o The format of the Proxy Binding Update message encapsulated in an 1547 IPv4 or IPv4-UDP packet with no IPsec protection: 1549 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1550 UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/ 1551 /* IPv6 PBU Packet protected with ESP header */ 1553 Figure 11: Proxy Binding Update (PBU) message encapsulated in IPv4 1554 UDP header 1556 o The format of the Proxy Binding Update message encapsulated in an 1557 IPv4 UDP packet and with IPsec protection on the encapsulated 1558 packet: 1560 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1561 ESP Header 1562 UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/ 1563 /* IPv6 PBU Packet protected with no ESP header */ 1565 Figure 12: Proxy Binding Update (PBU) message encapsulated in IPv4 1566 ESP header 1568 4.2.2.2. Forwarding Considerations 1570 Forwarding Packets Sent by the Mobile Node: 1572 o On receiving an IPv4 or an IPv6 packet from the mobile node to any 1573 destination, the mobile access gateway MUST tunnel the packet to 1574 the local mobility anchor. The format of the tunneled packet is 1575 shown below. However, considerations from Section 6.10.3 of [RFC- 1576 5213] MUST be applied with respect the local routing and on the 1577 use of EnableMAGLocalRouting flag. 1579 IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */ 1580 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1581 [TLV Header] /* If TLV negotiated */ 1582 /* IPv6 or IPv4 Payload Packet */ 1583 IPv6 header (src= CN, dst= MN-HOA) 1584 OR 1585 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1587 Figure 13: Tunneled IPv4 Packet from LMA to MAG 1589 o Forwarding Packets received from the bi-directional tunnel: 1591 o On receiving a packet from the bi-directional tunnel established 1592 with the mobile node's local mobility anchor, the mobile access 1593 gateway MUST remove the outer header before forwarding the packet 1594 to the mobile node. 1596 5. Protocol Configuration Variables 1598 5.1. Local Mobility Anchor - Configuration Variables 1600 The local mobility anchor MUST allow the following variables to be 1601 configured by the system management. The configured values for these 1602 protocol variables MUST survive server reboots and service restarts. 1604 AcceptIPv4UDPEncapsulationRequest 1606 This flag indicates whether or not the local mobility anchor 1607 should accept IPv4 UDP encapsulation support for the mobile node's 1608 data traffic, if there is NAT detected in the path. 1610 The default value for this flag is set to value of 1, indicating 1611 that the local mobility anchor MUST enable IPv4 UDP encapsulation 1612 support on detecting NAT in the path. 1614 When the value for this flag is set to value of 0, the local 1615 mobility anchor MUST NOT enable IPv4 UDP encapsulation support. 1617 5.2. Mobile Access Gateway - Configuration Variables 1619 The mobile access gateway MUST allow the following variables to be 1620 configured by the system management. The configured values for these 1621 protocol variables MUST survive server reboots and service restarts. 1623 UseIPv4UDPEncapForSignalingMessages 1625 This flag indicates whether or not the mobile access gateway 1626 should use IPv4-UDP encapsulation mode for the signaling messages. 1628 The default value for this flag is set to value of 0, indicating 1629 that the mobile access gateway MUST NOT use IPv4-UDP encapsulation 1630 mode, but MUST use native IPv4 encapsulation mode for sending the 1631 Proxy Mobile IPv6 signaling messages. 1633 When the value for this flag is set to value of 1, the mobile 1634 access gateway MUST use IPv4-UDP encapsulation mode for sending 1635 the Proxy Mobile IPv6 signaling messages. 1637 ForceIPv4UDPEncapsulationSupport 1638 This flag indicates whether or not the mobile access gateway 1639 should request the mobile node's local mobility anchor for forcing 1640 IPv4 UDP encapsulation support for the mobile node's data traffic, 1641 even when NAT is not detected in the path. 1643 The default value for this flag is set to value of 0, indicating 1644 that the mobile access gateway MUST NOT request the mobile node's 1645 local mobility anchor for forcing IPv4 UDP encapsulation support 1646 even when NAT is not detected in path. 1648 When the value for this flag is set to value of 1, the mobile 1649 access gateway MUST force the mobile node's local mobility anchor 1650 for IPv4 UDP encapsulation support. 1652 This flag is applicable only when the flag 1653 UseIPv4UDPEncapForSignalingMessages is set to a value of 1. 1655 5.3. Proxy Mobile IPv6 Domain - Configuration Variables 1657 All the mobile entities (local mobility anchors and mobile access 1658 gateways) in a Proxy Mobile IPv6 domain MUST allow the following 1659 variables to be configured by the system management. The configured 1660 values for these protocol variables MUST survive server reboots and 1661 service restarts. These variables MUST be globally fixed for a given 1662 Proxy Mobile IPv6 domain resulting in the same values being enforced 1663 on all the mobility entities in that domain. 1665 FixedDHCPServerId 1667 This variable indicates the DHCP server id that all the DHCP 1668 servers co-located with the mobile access gateways SHOULD 1669 configure in that Proxy Mobile IPv6 domain. If this variable is 1670 initialized to ALL_ZERO value, it implies the use of fixed address 1671 is not enabled for that Proxy Mobile IPv6 domain. 1673 6. IANA Considerations 1675 This document defines a new Mobility Header option, IPv4 Default 1676 Router Address option. This option is described in Section 3.3.1. 1677 The Type value for this option needs to be assigned from the same 1678 numbering space as allocated for the other mobility options, as 1679 defined in [RFC-3775]. 1681 This document also defines new Binding Acknowledgement status values, 1682 as described in Section 3.3.2. The status values MUST be assigned 1683 from the same number space used for Binding Acknowledgement status 1684 values, as defined in [RFC3775]. The allocated values for each of 1685 these status values must be greater than 128. 1687 7. Security Considerations 1689 All the security considerations from the base Proxy Mobile IPv6 1690 protocol [RFC-5213] apply when using the extensions defined in this 1691 document. Additionally, the following security considerations need 1692 to be applied. 1694 This document defines news mobility options for supporting the IPv4 1695 Home Address assignment and IPv4 Transport Support features. It also 1696 uses some of the mobility options from DSMIPv6 specification [ID- 1697 DSMIP6]. These options are to be carried in Proxy Binding Update and 1698 Proxy Binding Acknowledgement messages. The required security 1699 mechanisms specified in the base Proxy Mobile IPv6 protocol for 1700 protecting these signaling messages are sufficient when carrying 1701 these mobility options. 1703 This specification describes the use of IPv4 transport for exchanging 1704 the signaling messages between the local mobility anchor and the 1705 mobile access gateway. These messages are protected using IPsec 1706 using the security associations established using the IPv4 transport 1707 addresses and offer the same security as when the messages are 1708 protected when using IPv6 transport. 1710 8. Contributors 1712 This document reflects discussions and contributions from several 1713 people (in alphabetical order): 1715 Kuntal Chowdhury 1717 kchowdhury@starentnetworks.com 1719 Vijay Devarapalli 1721 vijay.devarapalli@azairenet.com 1723 Sangjin Jeong 1725 sjjeong@etri.re.kr 1727 Basavaraj Patil 1729 basavaraj.patil@nsn.com 1731 Myungki Shin 1733 myungki.shin@gmail.com 1735 9. Acknowledgments 1737 The IPv4 support for Proxy Mobile IPv6 was initially covered in the 1738 internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like 1739 to thank all the authors of the document and acknowledge that initial 1740 work. 1742 Thanks to Charles Perkins, Jonne Soinnen, Julien Laganier, Mohana 1743 Jeyatharan, Niklas Nuemann, Premec Domagoj, Sammy Touati and Zu Qiang 1744 for their helpful review of this document. 1746 10. References 1748 10.1. Normative References 1750 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1751 Requirement Levels", BCP 14, RFC 2119, March 1997. 1753 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1754 2131, March 1997. 1756 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1757 IPv6 Specification", RFC 2473, December 1998. 1759 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1760 IPv6", RFC 3775, June 2004. 1762 [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, 1763 November 2007. 1765 [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack 1766 Hosts and Routers (DSMIPv6)", 1767 draft-ietf-mext-nemo-v4traversal-05.txt, July 2008. 1769 10.2. Informative References 1771 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1772 2131, March 1997. 1774 [RFC-3011] G. Waters, "The IPv4 Subnet Selection Option for DHCP", 1775 RFC 3011, November 2000. 1777 [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1778 Address Translator (Traditional NAT)", RFC 3022, January 2001. 1780 [RFC-3203] Y. T'Joens and C. Hublet and P. De Schrijver, "DHCP 1781 reconfigure extension", RFC 3203, December 2001. 1783 [RFC-3927] Cheshire, S. et al, "Dynamic Configuration of IPv4 Link- 1784 Local Addresses", RFC 3927, May 2005. 1786 [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack 1787 Mobility", RFC 4977, August 2007. 1789 [RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp, 1790 "DHCP Server Identifier Override Suboption", RFC 5107, February 2008. 1792 Authors' Addresses 1794 Ryuji Wakikawa 1795 Toyota ITC / Keio University 1796 6-6-20 Akasaka, Minato-ku 1797 Tokyo 107-0052 1798 Japan 1800 Phone: +81-3-5561-8276 1801 Fax: +81-3-5561-8292 1802 Email: ryuji@jp.toyota-itc.com 1804 Sri Gundavelli 1805 Cisco 1806 170 West Tasman Drive 1807 San Jose, CA 95134 1808 USA 1810 Email: sgundave@cisco.com 1812 Full Copyright Statement 1814 Copyright (C) The IETF Trust (2008). 1816 This document is subject to the rights, licenses and restrictions 1817 contained in BCP 78, and except as set forth therein, the authors 1818 retain all their rights. 1820 This document and the information contained herein are provided on an 1821 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1822 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1823 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1824 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1825 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1826 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1828 Intellectual Property 1830 The IETF takes no position regarding the validity or scope of any 1831 Intellectual Property Rights or other rights that might be claimed to 1832 pertain to the implementation or use of the technology described in 1833 this document or the extent to which any license under such rights 1834 might or might not be available; nor does it represent that it has 1835 made any independent effort to identify any such rights. Information 1836 on the procedures with respect to rights in RFC documents can be 1837 found in BCP 78 and BCP 79. 1839 Copies of IPR disclosures made to the IETF Secretariat and any 1840 assurances of licenses to be made available, or the result of an 1841 attempt made to obtain a general license or permission for the use of 1842 such proprietary rights by implementers or users of this 1843 specification can be obtained from the IETF on-line IPR repository at 1844 http://www.ietf.org/ipr. 1846 The IETF invites any interested party to bring to its attention any 1847 copyrights, patents or patent applications, or other proprietary 1848 rights that may cover technology that may be required to implement 1849 this standard. Please address the information to the IETF at 1850 ietf-ipr@ietf.org. 1852 Acknowledgment 1854 Funding for the RFC Editor function is provided by the IETF 1855 Administrative Support Activity (IASA).