idnits 2.17.1 draft-ietf-netlmm-pmip6-ipv4-support-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 23, 2009) is 5482 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-09) exists of draft-ietf-netlmm-grekey-option-06 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group R. Wakikawa 3 Internet-Draft Toyota ITC 4 Intended status: Standards Track S. Gundavelli 5 Expires: October 25, 2009 Cisco 6 April 23, 2009 8 IPv4 Support for Proxy Mobile IPv6 9 draft-ietf-netlmm-pmip6-ipv4-support-12.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 25, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies extensions to Proxy Mobile IPv6 protocol for 48 adding IPv4 protocol support. The scope of IPv4 protocol support is 49 two-fold: 1) enable IPv4 home address mobility support to the mobile 50 node. 2) allowing the mobility entities in the Proxy Mobile IPv6 51 domain to exchange signaling messages over an IPv4 transport network. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 6 57 1.2. Relevance to Dual-Stack Mobile IPv6 . . . . . . . . . . . 7 59 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 9 60 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 9 61 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 63 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 11 64 3.1. Local Mobility Anchor Considerations . . . . . . . . . . . 12 65 3.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 12 66 3.1.2. Signaling Considerations . . . . . . . . . . . . . . . 12 67 3.1.3. Routing Considerations for the Local Mobility 68 Anchor . . . . . . . . . . . . . . . . . . . . . . . . 18 69 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 19 70 3.2.1. Extensions to Binding Update List Entry . . . . . . . 19 71 3.2.2. Extensions to Mobile Node's Policy Profile . . . . . . 19 72 3.2.3. Signaling Considerations . . . . . . . . . . . . . . . 19 73 3.2.4. Routing Considerations for the Mobile Access 74 Gateway . . . . . . . . . . . . . . . . . . . . . . . 23 75 3.3. Mobility Options and Status Codes . . . . . . . . . . . . 24 76 3.3.1. IPv4 Default-Router Address Option . . . . . . . . . . 24 77 3.3.2. IPv4 DHCP Support Mode . . . . . . . . . . . . . . . . 25 78 3.3.3. Status Codes . . . . . . . . . . . . . . . . . . . . . 26 79 3.4. Supporting DHCP-Based Address Configuration . . . . . . . 26 80 3.4.1. DHCP Server co-located with the Mobile Access 81 Gateway . . . . . . . . . . . . . . . . . . . . . . . 28 82 3.4.2. DHCP Relay Agent co-located with the Mobile Access 83 Gateway . . . . . . . . . . . . . . . . . . . . . . . 30 84 3.4.3. Common DHCP Considerations . . . . . . . . . . . . . . 32 86 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 34 87 4.1. Local Mobility Anchor Considerations . . . . . . . . . . . 35 88 4.1.1. Extensions to Binding Cache Entry . . . . . . . . . . 35 89 4.1.2. Extensions to Mobile Node's Policy Profile . . . . . . 36 90 4.1.3. Signaling Considerations . . . . . . . . . . . . . . . 36 91 4.1.4. Routing Considerations . . . . . . . . . . . . . . . . 39 92 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 40 93 4.2.1. Extensions to Binding Update List Entry . . . . . . . 40 94 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 41 96 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 44 97 5.1. Local Mobility Anchor - Configuration Variables . . . . . 44 98 5.2. Mobile Access Gateway - Configuration Variables . . . . . 44 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 47 103 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 105 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 108 10.1. Normative References . . . . . . . . . . . . . . . . . . . 48 109 10.2. Informative References . . . . . . . . . . . . . . . . . . 49 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 113 1. Overview 115 The transition from IPv4 to IPv6 is a long process and during this 116 period of transition, both the protocols will be enabled over the 117 same network infrastructure. Thus, it is reasonable to assume that a 118 mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only 119 IPv6-only or in dual-stack mode and additionally the network between 120 the mobile access gateway and a local mobility anchor may be an IPv4 121 or an IPv6 network. It is also reasonable to expect the same 122 mobility infrastructure in the Proxy Mobile IPv6 domain to provide 123 mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode 124 and when the network between the local mobility anchor and the mobile 125 access gateway is an IPv4 or an IPv6 network. The motivation and 126 scope of IPv4 support in Mobile IPv6 is summarized in [RFC-4977] and 127 all those requirements apply to Proxy Mobile IPv6 protocol as well. 129 The Proxy Mobile IPv6 protocol [RFC-5213] specifies a mechanism for 130 providing IPv6 home address mobility support to a mobile node in a 131 Proxy Mobile IPv6 domain. The protocol requires IPv6 transport 132 network between the mobility entities. The extensions defined in 133 this document extends IPv4 support to the Proxy Mobile IPv6 protocol 134 [RFC-5213]. 136 The scope of IPv4 support in Proxy Mobile IPv6 includes the support 137 for the following two features: 139 o IPv4 Home Address Mobility Support: A mobile node that has an IPv4 140 stack enabled will be able to obtain an IPv4 address and be able 141 to use that address from any of the access networks in that Proxy 142 Mobile IPv6 domain. The mobile node is not required to be 143 allocated or assigned an IPv6 address for enabling IPv4 home 144 address support. 146 o IPv4 Transport Network Support: The mobility entities in the Proxy 147 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 148 signaling messages over an IPv4 transport and furthermore the 149 mobile access gateway may be using an IPv4 private address and 150 with NAT [RFC-3022] translation devices on the path to the local 151 mobility anchor. 153 These two features, the IPv4 Home Address Mobility support and the 154 IPv4 transport support features, are independent of each other and 155 deployments may choose to enable any one or both of these features as 156 required. 158 +----+ +----+ 159 |LMA1| |LMA2| 160 +----+ +----+ 161 IPv4-LMAA1 -> | | <-- LMAA2 162 | | 163 \\ //\\ 164 (NAT) // \\ 165 \\ // \\ 166 +---\\------------- //------\\----+ 167 ( \\ IPv4/IPv6 // \\ ) 168 ( \\ Network // \\ ) 169 +------\\--------//------------\\-+ 170 \\ // \\ 171 \\ // \\ 172 \\ // \\ 173 IPv4-Proxy-CoA1--> | | <-- Proxy-CoA2 174 +----+ +----+ 175 |MAG1|-----{MN2} |MAG2| 176 +----+ | +----+ 177 (IPv6 MN-HoA1) | | | <-- (IPv6 MN-HoA2) 178 (IPv4-MN-HoA1) --> | (IPv4-MN-HoA2) | <-- (IPv4-MN-HoA3) 179 {MN1} {MN3} 181 Figure 1: IPv4 support for Proxy Mobile IPv6 183 1.1. Stated Assumptions 185 The following are the configuration requirements from the mobility 186 entities in the Proxy Mobile IPv6 domain for supporting the 187 extensions defined in this document. 189 o The local mobility anchor and the mobile access gateway are both 190 IPv4 and IPv6 enabled. Irrespective of the type of transport 191 network (IPv4 or IPv6) separating these two entities, the mobility 192 signaling is always based on Proxy Mobile IPv6 [RFC-5213]. 194 o The local mobility anchor and the mobile access gateway MUST be 195 configured with IPv6 globally unique addresses, even when they are 196 in IPv4-only network. These addresses can be of the type Unique 197 Local IPv6 Unicast Address [RFC-4193], IPv6 Global Unicast Address 198 [RFC-3587] or IPv4-mapped IPv6 address [RFC-4291]. When using 199 IPv4 transport, it is not required that there is IPv6 routing 200 enabled between the local mobility anchor and the mobile access 201 gateway. However, they must be able to receive any IPv6 packets 202 sent to the configured IPv6 addresses, after removing the outer 203 IPv4 encapsulation header. 205 o The mobile node can be operating in IPv4-only, IPv6-only or in 206 dual mode. Based on what is enabled for a mobile node, it should 207 be able to obtain IPv4-only, IPv6-only or both IPv4 and IPv6 208 address(es) for its interface and furthermore achieve mobility 209 support for those addresses. 211 o For enabling IPv4 home address mobility support to a mobile node, 212 it is not required that the IPv6 home address mobility support 213 needs to enabled. However, the respective protocol(s) support, 214 such as IPv4 or IPv6 packet forwarding, must be enabled on the 215 access link between the mobile node and the mobile access gateway. 217 o The mobile node can obtain an IPv4 address for its attached 218 interface. Based on the type of link, it may be able to acquire 219 its IPv4 address configuration using standard IPv4 address 220 configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332], 221 IKEv2 [RFC-4306] or static address configuration. 223 o The mobile node's IPv4 home subnet is typically a shared address 224 space. It is not for the exclusive use of any one mobile node. 225 There can be multiple mobile nodes that are assigned IPv4 226 addresses from the same subnet. 228 o The mobile access gateway is the IPv4 default-router for the 229 mobile node on its access link. It will be in the forwarding path 230 for the mobile node's data traffic. Additionally, as specified in 231 section 6.9.3 of [RFC-5213], all the mobile access gateways in the 232 Proxy Mobile IPv6 domain MUST use the same link-layer address on 233 any of the access links wherever the mobile node attaches. 235 1.2. Relevance to Dual-Stack Mobile IPv6 237 IPv4 support for Mobile IPv6 is specified in Dual-Stack Mobile IPv6 238 specification [ID-DSMIP6]. This document to most part leverages the 239 approaches, messaging options and processing logic defined in that 240 document for extending IPv4 support to Proxy Mobile IPv6, except with 241 deviation in some aspects for obvious reasons of supporting a 242 network-based mobility model. Following are some of the related 243 considerations. 245 o The messaging options, IPv4 Home Address, IPv4 Address 246 Acknowledgement, IPv4 Care-of Address option defined in [ID- 247 DSMIP6] for use in Binding Update and Binding Acknowledgement 248 messages are used by this specification to be carried in Proxy 249 Binding Update and Proxy Binding Acknowledgement messages. 251 o The extensions needed to the conceptual data structures, Binding 252 Cache entry and Binding Update List entry, for storing the state 253 related to the IPv4 support defined in [ID-DSMIP6], will all be 254 needed and relevant for this document. 256 o The NAT traversal logic specified in [ID-DSMIP6] for detecting the 257 on-path NAT devices is valid for this specification as well. 259 o The tunneling considerations specified in [ID-DSMIP6] for 260 supporting IPv4 transport is relevant for this document as well. 262 If a given home agent [RFC-3775] implementation has support for both 263 Dual-stack Mobile IPv6 [ID-DSMIP6] and local mobility anchor function 264 [RFC-5213], when extending IPv4 support as specified in this document 265 the above common functions and the related considerations have to be 266 reused for Proxy Mobile IPv6 signaling flows. 268 2. Conventions & Terminology 270 2.1. Conventions 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 273 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 274 document are to be interpreted as described in RFC 2119 [RFC-2119]. 276 2.2. Terminology 278 All the mobility related terms used in this document are to be 279 interpreted as defined in the Mobile IPv6 specification [RFC-3775] 280 and Proxy Mobile IPv6 specification [RFC-5213]. In addition this 281 document introduces the following terms. 283 IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) 285 The IPv4 address that is configured on the egress-interface of the 286 mobile access gateway. When using IPv4 transport, this address 287 will be the registered care-of address in the mobile node's 288 Binding Cache entry and will also be the transport-endpoint of the 289 tunnel between the local mobility anchor and a mobile access 290 gateway. However, if the configured address is a private IPv4 291 address and with a NAT device in the path to the local mobility 292 anchor, the care-of address as seen by the local mobility anchor 293 will be the address allocated by the NAT device for that flow. 295 IPv4 Local Mobility Anchor Address (IPv4-LMAA) 297 The IPv4 address that is configured on the egress-interface of the 298 local mobility anchor. When using IPv4 transport, the mobile 299 access gateway sends the Proxy Binding Update messages to this 300 address and will be the transport-endpoint of the tunnel between 301 the local mobility anchor and the mobile access gateway. 303 Mobile Node's IPv4 Home Address (IPv4-MN-HoA) 305 The IPv4 home address assigned to the mobile node's attached 306 interface. This address is topologically anchored at the local 307 mobility anchor. The mobile node configures this address on its 308 attached interface. If the mobile node connects to the Proxy 309 Mobile IPv6 domain via multiple interfaces each of the interfaces 310 are assigned a unique IPv4 address. All the IPv6 home network 311 prefixes and the IPv4 home address assigned to a given interface 312 of a mobile node will be managed under one mobility session. 314 Selective De-registration 315 It is a procedure for partial de-registration of all the addresses 316 that belong to one address family, i.e., de-registration of either 317 IPv4 home address, or all of the IPv6 home network prefixes. 319 Encapsulation Modes 321 This document uses the following terms when referring to the 322 different encapsulation modes. 324 IPv4-or-IPv6-over-IPv6 326 IPv4 or IPv6 packet carried as a payload of an IPv6 packet 328 IPv4-or-IPv6-over-IPv4 330 IPv4 or IPv6 packet carried as a payload of an IPv4 packet 332 IPv4-or-IPv6-over-IPv4-UDP 334 IPv4 or IPv6 packet carried as a payload in an UDP header of an 335 IPv4 packet 337 IPv4-or-IPv6-over-IPv4-UDP-TLV 339 IPv4 packet carried as a payload in an IPv4 packet with UDP and 340 TLV headers 342 3. IPv4 Home Address Mobility Support 344 The IPv4 home address mobility support essentially enables a mobile 345 node in a Proxy Mobile IPv6 domain to obtain IPv4 home address 346 configuration for its attached interface and be able to retain that 347 address configuration even after changing its point of attachment in 348 that Proxy Mobile IPv6 domain. This section describes the protocol 349 operation and the required extensions to Proxy Mobile IPv6 protocol 350 for extending IPv4 home address mobility support. 352 When an IPv4-enabled or a dual-stack enabled mobile node attaches to 353 the Proxy Mobile IPv6 domain, the mobile access gateway on the access 354 link where the mobile node is attached will identify the mobile node 355 and will initiate the Proxy Mobile IPv6 signaling with the mobile 356 node's local mobility anchor. The mobile access gateway will follow 357 the signaling considerations specified in Section 3.2 for requesting 358 IPv4 home address mobility support. Upon the completion of the 359 signaling, the local mobility anchor and the mobile access gateway 360 will establish the required routing states for allowing the mobile 361 node to use its IPv4 home address from its current point of 362 attachment. 364 The mobile node on the access link using any of the standard IPv4 365 address configuration mechanisms supported on that access link, such 366 as IPCP [RFC-1332], IKEv2 [RFC-4306] or DHCP [RFC-2131], will be able 367 to obtain an IPv4 home address (IPv4-MN-HoA) for its attached 368 interface. Although the address configuration mechanisms for 369 delivering the address configuration to the mobile node is 370 independent of the Proxy Mobile IPv6 protocol operation, however 371 there needs to be some interactions between these two protocol flows. 372 Section 3.4 identifies these interactions for supporting DHCP based 373 address configuration. 375 The support for IPv4 home address mobility is not dependent on the 376 IPv6 home address mobility support. It is not required that the IPv6 377 home address mobility support needs to be enabled for providing IPv4 378 home address mobility support. A mobile node will be able to obtain 379 IPv4-only, IPv6-only or dual IPv4/IPv6 address configuration for its 380 attached interface. The mobile node's policy profile will determine 381 if the mobile node is entitled for both the protocol versions or a 382 single protocol version. Based on the policy, only those protocols 383 will be enabled on the access link. Furthermore, if the mobile node 384 after obtaining the address configuration on its interface performs 385 an handoff, either by changing its point of attachment over the same 386 interface or to a different interface, the network will ensure the 387 mobile node will be able to use the same IPv4 address configuration 388 after the handoff. 390 Additionally, If the mobile node connects to the Proxy Mobile IPv6 391 domain, through multiple interfaces and simultaneously through 392 different access networks, each of the connected interfaces will 393 obtain an IPv4 home address from different subnets. In such 394 scenario, there will be multiple Binding Cache entries for the mobile 395 node on the local mobility anchor. All the address (IPv4/IPv6) 396 assigned to a given interface will be managed as part of one mobility 397 session, as specified in Section 5.4 of [RFC-5213]. 399 3.1. Local Mobility Anchor Considerations 401 3.1.1. Extensions to Binding Cache Entry 403 To support this feature, the conceptual Binding Cache entry data 404 structure maintained by the local mobility anchor needs to include 405 the following parameters. 407 o The IPv4 home address assigned to the mobile node's interface and 408 registered by the mobile access gateway. The IPv4 home address 409 entry also includes the corresponding subnet mask. It is to be 410 noted that this parameter is defined in the [ID-DSMIP6] and is 411 presented here for completeness. 413 o The IPv4 default-router address assigned to the mobile node. 415 3.1.2. Signaling Considerations 417 3.1.2.1. Processing Proxy Binding Updates 419 The processing rules specified in Section 5.3 of [RFC-5213] are 420 applied for processing the received Proxy Binding Update message. 421 However, if the received Proxy Binding Update message has an IPv4 422 Home Address option [ID-DSMIP6], the following considerations MUST be 423 applied additionally. 425 o If there is an IPv4 Home Address option [ID-DSMIP6] present in the 426 received Proxy Binding Update message, but if there is no Home 427 Network Prefix option [RFC-5213] present in the request, the local 428 mobility anchor MUST NOT reject the request as specified in 429 Section 5.3.1 of [RFC-5213]. At least one instance of any of 430 these two options MUST be present. If there is not a single 431 instance of any of these two options present in the request, the 432 local mobility anchor MUST reject the request and send a Proxy 433 Binding Acknowledgement message with Status field set to 434 MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home 435 network prefix option) [RFC-5213]. 437 o If there is at least one instance of Home Network Prefix option 438 [RFC-5213] present in the received Proxy Binding Update message, 439 but either if it is known from the mobile node's policy profile 440 that the mobile node is not authorized for IPv6 service or if IPv6 441 routing not enabled in the home network, the local mobility anchor 442 MUST reject the request and send a Proxy Binding Acknowledgement 443 message with the Status field set to 444 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX (mobile node not 445 authorized for the requesting IPv6 home network prefix). 447 o If there are more than one instance of the IPv4 Home Address 448 option present in the request, then the local mobility anchor MUST 449 reject the request and send a Proxy Binding Acknowledgement 450 message with the Status field set to 451 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED (multiple IPv4 452 home address assignment not supported). 454 o If the prefix request(P) flag in the IPv4 Home Address option is 455 set to a value of 1, then the local mobility anchor MUST reject 456 the request and send a Proxy Binding Acknowledgement message with 457 the Status field set to IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED (IPv4 458 prefix assignment not supported). 460 o For associating the received Proxy Binding Update message to an 461 existing mobility session, the local mobility anchor MUST perform 462 the Binding Cache entry existence test by applying the following 463 considerations. 465 * If there is at least one instance of the Home Network Prefix 466 option [RFC-5213] with a NON_ZERO prefix value, or, if there is 467 an IPv4 Home Address option [ID-DSMIP6] with the IPv4 address 468 in the option set to ALL_ZERO, considerations from Section 469 5.4.1 of [RFC-5213] MUST be applied. 471 * If there is an IPv4 Home Address option [ID-DSMIP6] present in 472 the request with the IPv4 address value in the option set to a 473 NON_ZERO value, considerations from Section 3.1.2.7 MUST be 474 applied. 476 o If there is no existing Binding Cache entry that can be associated 477 with the request, the local mobility anchor MUST consider this 478 request as an initial binding registration request and 479 considerations from Section 3.1.2.2 MUST be applied. 480 Additionally, if there are one or more Home Network Prefix options 481 [RFC-5213] present in the request, considerations from Section 482 5.3.2 of [RFC-5213] MUST also be applied. 484 o If there exists a Binding Cache entry that can be associated with 485 the request, the local mobility anchor MUST apply considerations 486 from Section 5.3.1 of [RFC-5213], (point 13), to determine if the 487 request is re-registration or a de-registration request and the 488 respective considerations from the below sections MUST be applied. 490 o If there exists a Binding Cache entry that can be associated with 491 the request and if it is determined that the request is a re- 492 registration request and with the request to extend IPv4 home 493 address mobility support to the existing IPv6-only mobility 494 session, considerations from Section 3.1.2.2 MUST be applied with 495 respect to IPv4 support. 497 3.1.2.2. Initial Binding Registration (New Mobility Session) 499 o If there is an IPv4 Home Address option [ID-DSMIP6] present in the 500 Proxy Binding Update message with the IPv4 address value in the 501 option set to ALL_ZERO, the local mobility anchor MUST allocate an 502 IPv4 home address to the mobile node and associate it with the new 503 mobility session created for that mobile node. 505 o If there is an IPv4 Home Address option [ID-DSMIP6] with the IPv4 506 address in the option set to a NON_ZERO value, the local mobility 507 anchor before accepting the request MUST ensure the address is 508 topologically anchored on the local mobility anchor and 509 furthermore the mobile node is authorized to use that address. If 510 the mobile node is not authorized for that specific address, the 511 local mobility anchor MUST reject the request and send a Proxy 512 Binding Acknowledgement message with the Status field set to 513 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized 514 for the requesting IPv4 address). It MUST also include the IPv4 515 Address Acknowledgement option [ID-DSMIP6] in the reply with the 516 status field value in the option set to 129 (Administratively 517 prohibited). 519 o If the local mobility anchor is unable to allocate an IPv4 address 520 due to lack of resources, it MUST reject the request and send a 521 Proxy Binding Acknowledgement message with Status field set to 130 522 (Insufficient resources). It MUST also include the IPv4 Address 523 Acknowledgement option [ID-DSMIP6] in the reply with the status 524 field value in the option set to 128 (Failure, reason 525 unspecified). 527 o Upon accepting the request, the local mobility anchor MUST create 528 a Binding Cache entry for this mobility session. However, if the 529 request also contains one or more Home Network Prefix options [ID- 530 DSMIP6], there should still be only one Binding Cache entry that 531 should be created for this mobility session. The created Binding 532 Cache entry MUST be used for managing both IPv4 and IPv6 home 533 address bindings. The fields in the Binding Cache entry MUST be 534 updated with the accepted values for that session. 536 o The local mobility anchor MUST establish a bi-directional tunnel 537 to the mobile access gateway and with the encapsulation mode set 538 to the negotiated mode for carrying the IPv4 payload traffic. 539 When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6- 540 over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 541 packet). When using IPv4 transport, the encapsulation mode is as 542 specified in Section 4.0. 544 o The local mobility anchor MUST create an IPv4 host route (or a 545 platform specific equivalent function that sets up the forwarding) 546 for tunneling the packets received for the mobile node's home 547 address associated with this mobility session. 549 o The local mobility anchor MUST send the Proxy Binding 550 Acknowledgement message with the Status field set to 0 (Proxy 551 Binding Update Accepted). The message MUST be constructed as 552 specified in Section 3.1.2.6. 554 3.1.2.3. Binding Lifetime Extension (No handoff) 556 All the considerations from Section 5.3.3 of [RFC-5213] MUST be 557 applied. 559 3.1.2.4. Binding Lifetime Extension (After handoff) 561 o If there is no Home Network Prefix option(s) [RFC-5213] present in 562 the request, but if the Binding Cache entry associated with this 563 request has IPv6 home network prefix(es), the local mobility 564 anchor MUST consider this as a request to extend lifetime only for 565 the IPv4 home address and not for the IPv6 home network 566 prefix(es). Hence, the local mobility anchor SHOULD release all 567 the IPv6 home network prefix(es) assigned to that mobile node and 568 for that specific attached interface. Similar considerations 569 apply for the case where there is no IPv4 Home Address option [ID- 570 DSMIP6] present in the request, but if the Binding Cache entry 571 associated with that request has both IPv4 home address and IPv6 572 home network prefix(es). 574 o The local mobility anchor MUST remove the previously created IPv4 575 host route (or the forwarding state) and the dynamically created 576 bi-directional tunnel for carrying the IPv4 payload traffic (if 577 there are no other mobile nodes for which the tunnel is being 578 used). This will remove the routing state towards the mobile 579 access gateway where the mobile node was anchored prior to the 580 handoff. 582 o The local mobility anchor MUST create a bi-directional tunnel to 583 the mobile access gateway that sent the request (if there is no 584 existing bi-directional tunnel) and with the encapsulation mode 585 set to the negotiated mode for carrying the IPv4 payload traffic. 586 An IPv4 host route for tunneling the packets received for the 587 mobile node's IPv4 home address MUST also be added. 589 o The required forwarding state identified in Section 5.3.6 of [RFC- 590 5213] is for IPv6 payload traffic. Those considerations apply for 591 IPv4 payload traffic as well. However, if IPv4 transport is in 592 use, considerations from Section 4.0 MUST be applied. 594 3.1.2.5. Binding De-Registration 596 All the considerations from Section 5.3.5 of [RFC-5213] MUST be 597 applied. Additionally, for removing the IPv4 state as part of the 598 Binding Cache entry deletion, the IPv4 host route and the dynamically 599 created bi-directional tunnel for carrying the IPv4 payload traffic 600 (if there are no other mobile nodes for which the tunnel is being 601 used) MUST be removed. However, if the request is for a selective 602 de-registration (IPv4 home address only, or all the IPv6 home network 603 prefixes), the Binding Cache entry MUST NOT be deleted, only the 604 respective states with respect to those addresses MUST be deleted. 606 3.1.2.6. Constructing the Proxy Binding Acknowledgement Message 608 The local mobility anchor when sending the Proxy Binding 609 Acknowledgement message to the mobile access gateway MUST construct 610 the message as specified in Section 5.3.6 of [RFC-5213]. 611 Additionally, the following considerations MUST be applied. 613 o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to 614 include at least one instance of Home Network Prefix option [RFC- 615 5213] in the Proxy Binding Acknowledgement message that it sends 616 to the mobile access gateway. However, if the received Proxy 617 Binding Update message has only the IPv4 Home Address option [ID- 618 DSMIP6] and did not contain the Home Network Prefix option(s), 619 then the local mobility anchor MUST NOT include any Home Network 620 Prefix option(s) in the reply. However, there MUST be at least 621 one instance of either the Home Network Prefix option [RFC-5213] 622 or the IPv4 Address Acknowledgement option [ID-DSMIP6] present in 623 the Proxy Binding Acknowledgement message. 625 o The IPv4 Address Acknowledgement option [ID-DSMIP6] MUST be 626 present in the Proxy Binding Acknowledgement message. 628 1. If the Status field is set to a value greater than or equal to 629 128, i.e., if the Proxy Binding Update is rejected, then there 630 MUST be an IPv4 Address Acknowledgement option [ID-DSMIP6] 631 corresponding to the IPv4 Home Address option [ID-DSMIP6] 632 present in the request and with the IPv4 address value and the 633 prefix length fields in the option set to the corresponding 634 values in the request. The status field value in the option 635 must be set to the specific error code. 637 2. For all other cases, there MUST be an IPv4 Address 638 Acknowledgement option for carrying the IPv4 home address 639 assigned for that mobility session and with the value in the 640 option set to the allocated IPv4 address. The prefix length 641 in the option MUST be set to the prefix length of the 642 allocated address. The status field value in the option must 643 be set to 0 (Success). 645 o The IPv4 Default-Router Address option MUST be present, if the 646 Status field value in the Proxy Binding Acknowledgement message is 647 set to 0 (Proxy Binding Update Accepted). Otherwise, the option 648 MUST NOT be present. If the option is present, the default-router 649 address in the option MUST be set to the mobile node's default- 650 router address. 652 3.1.2.7. Binding Cache Entry Lookup Considerations 654 The Binding Cache entry lookup considerations specified in section 655 5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213] 656 as the key parameter for identifying the Binding Cache entry. 657 However, when there is not a single Home Network Prefix option with 658 NON_ZERO value present in the request, but if there an IPv4 Home 659 Address option with a NON_ZERO value present in the request, the 660 following considerations MUST be applied. 662 o The search rules specified in section 5.4.1.1 of [RFC-5213], which 663 primarily uses IPv6 home network prefix set as the search key, are 664 equally valid when using a single IPv4 home address as the key. 665 When applying those considerations, instead of the IPv6 home 666 network prefix(es), the IPv4 home address from the IPv4 Home 667 Address option present in the request MUST be used as the search 668 key. 670 o These rules specified in section 5.4.1.1 of [RFC-5213], assume the 671 presence of one or more IPv6 home network prefixes in the received 672 request and also in the Binding Cache entry. But, when using the 673 IPv4 home address as the search key, these considerations MUST 674 always assume just one single IPv4 home address, both in the 675 request and also in the Binding Cache entry. 677 3.1.3. Routing Considerations for the Local Mobility Anchor 679 Intercepting Packets Sent to the Mobile Node's IPv4 home address: 681 o When the local mobility anchor is serving a mobile node, it MUST 682 be able to receive packets that are sent to the mobile node's IPv4 683 home address. In order for it to receive those packets, it MUST 684 advertise a connected route in to the Routing Infrastructure for 685 the mobile node's IPv4 home address or for its home subnet. This 686 essentially enables IPv4 routers in that network to detect the 687 local mobility anchor as the last-hop router for that subnet. 689 Forwarding Packets to the Mobile Node: 691 o On receiving a packet from a correspondent node with the 692 destination address matching the mobile node's IPv4 home address, 693 the local mobility anchor MUST forward the packet through the bi- 694 directional tunnel setup for that mobile node. 696 o The format of the tunneled packet when payload protection is not 697 enabled: 699 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 700 IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ 701 Upper layer protocols /* Packet Content*/ 703 Figure 2: Tunneled Packets from LMA to MAG 705 Forwarding Packets Sent by the Mobile Node: 707 o All the reverse tunneled packets that the local mobility anchor 708 receives from the mobile access gateway, after removing the tunnel 709 header MUST be routed to the destination specified in the inner 710 IPv4 packet header. These routed packets will have the source 711 address field set to the mobile node's IPv4 home address. 713 3.2. Mobile Access Gateway Considerations 715 3.2.1. Extensions to Binding Update List Entry 717 To support the IPv4 home address mobility feature, the conceptual 718 Binding Update List entry data structure needs to be extended with 719 the following additional fields. 721 o The IPv4 home address assigned to the mobile node's attached 722 interface. This IPv4 home address may have been statically 723 configured in the mobile node's policy profile, or, may have been 724 dynamically allocated by the local mobility anchor. The IPv4 home 725 address entry also includes the corresponding subnet mask. 727 o The IPv4 default-router address of the mobile node. This is 728 acquired from the mobile node's local mobility anchor through the 729 received Proxy Binding Acknowledgment message. 731 3.2.2. Extensions to Mobile Node's Policy Profile 733 To support the IPv4 Home Address Mobility Support feature the mobile 734 node's policy profile, specified in Section 6.2 of [RFC-5213] MUST be 735 extended with the following additional fields. 737 Extensions to the mandatory section of the policy profile: 739 o This field identifies all the IP protocol versions for which the 740 home address mobility support needs to be extended to the mobile 741 node. The supported modes are IPv4-only, IPv6-only and dual IPv4/ 742 IPv6. 744 Extensions to the optional section of the policy profile: 746 o The IPv4 home address assigned to the mobile node's attached 747 interface. The specific details on how the network maintains the 748 association between the address and the attached interface is 749 outside the scope of this document. This address field also 750 includes the corresponding subnet mask. 752 3.2.3. Signaling Considerations 753 3.2.3.1. Mobile Node Attachment and Initial Binding Registration 755 After detecting a new mobile node on its access link, the mobile 756 access gateway on the access link MUST determine if IPv4 home address 757 mobility support needs to be enabled for that mobile node. The 758 mobile node's policy profile identifies the supported modes (IPv4- 759 only, IPv6-only or dual IPv4/IPv6) for that mobile node for which the 760 mobile service needs to be enabled. Based on those policy 761 considerations and from other triggers such as from the network, if 762 it is determined that IPv4 home address mobility support needs to be 763 enabled for the mobile node, considerations from section 6.9.1.1 of 764 [RFC-5213] MUST be applied with the following exceptions. 766 o The IPv4 Home Address option [ID-DSMIP6] MUST be present in the 767 Proxy Binding Update message. 769 * If the mobile access gateway learns the mobile node's IPv4 home 770 address either from its policy profile, or from other means, 771 the mobile access gateway MAY ask the local mobility anchor to 772 allocate that specific address by including exactly one 773 instance of the IPv4 Home Address option [ID-DSMIP6] with the 774 IPv4 home address and the prefix length fields in the option 775 set to that specific address and its prefix length. 776 Furthermore, the (P) flag in the option MUST be set to 0. 778 * The mobile access gateway MAY also ask the local mobility 779 anchor for dynamic IPv4 home address allocation. It can 780 include exactly one instance of the IPv4 Home Address option 781 with the IPv4 home address and the prefix length fields in the 782 option set to ALL_ZERO value. Furthermore, the (P) flag in the 783 option MUST be set to 0. This essentially serves as a request 784 to the local mobility anchor for the IPv4 home address 785 allocation. 787 o The Proxy Binding Update message MUST be constructed as specified 788 in Section 6.9.1.5 of [RFC-5213]. However, the Home Network 789 Prefix option(s) [RFC-5213] MUST be present in the Proxy Binding 790 Update only if IPv6 home address mobility support also needs to be 791 enabled for the mobile node. Otherwise, the Home Network Prefix 792 option(s) MUST NOT be present. 794 o When using IPv4 transport for carrying the signaling messages, the 795 related considerations from section 4.0 MUST be applied 796 additionally. 798 3.2.3.2. Receiving Proxy Binding Acknowledgement 800 All the considerations from section 6.9.1.2 of [RFC-5213] MUST be 801 applied with the following exceptions. 803 o If the received Proxy Binding Acknowledgement message has the 804 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 805 mobile node is not authorized for IPv4 home address), the mobile 806 access gateway SHOULD NOT send a Proxy Binding Update message 807 including the IPv4 Home Address option [ID-DSMIP6] till an 808 administrative action is taken. 810 o If the received Proxy Binding Acknowledgement message has the 811 Status field value set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS(The 812 mobile node is not authorized for the requesting IPv4 home 813 address), the mobile access gateway SHOULD NOT request for the 814 same address again, but MAY request the local mobility anchor to 815 do the assignment of address by including exactly one instance of 816 IPv4 Home Address option [ID-DSMIP6] with the IPv4 home address 817 and the prefix length fields in the option set to ALL_ZERO value. 819 o If there is no IPv4 Address Acknowledgement option [ID-DSMIP6] 820 present in the received Proxy Binding Acknowledgement message, the 821 mobile access gateway MUST NOT enable IPv4 support for the mobile 822 node and the rest of the considerations from this section can be 823 skipped. 825 o If the received Proxy Binding Acknowledgement message has the 826 Status field value in the IPv4 Address Acknowledgement Option [ID- 827 DSMIP6] set to a value that indicates that the request was 828 rejected by the local mobility anchor, the mobile access gateway 829 MUST NOT enable forwarding for that specific IPv4 home address. 831 o If the received Proxy Binding Acknowledgement message has the 832 Status field value set to 0 (Proxy Binding Update accepted), the 833 mobile access gateway MUST update a Binding Update List entry for 834 that mobile node. The entry MUST be updated with the assigned 835 IPv4 home address and other accepted registration values. 837 o If the received Proxy Binding Acknowledgement message has the 838 Status field value set to 0 (Proxy Binding Update accepted) and 839 has the IPv4 Address Acknowledgement Option [ID-DSMIP6] set to a 840 value that indicates that the request was accepted by the local 841 mobility anchor, the mobile access gateway MUST establish a bi- 842 directional tunnel to the local mobility anchor (if there is no 843 existing bi-directional tunnel to that local mobility anchor) and 844 with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or 845 IPv6 packet carried as a payload of an IPv6 packet). 847 Considerations from Section 5.6.1 of [RFC-5213] MUST be applied 848 for managing the dynamically created bi-directional tunnel. 849 However, when using IPv4 transport, the encapsulation mode MUST be 850 set to the negotiated encapsulation mode, as specified in Section 851 4 of this specification. 853 o The mobile access gateway MUST set up the route for forwarding the 854 IPv4 packets received from the mobile node (using its IPv4 home 855 address) through the bi-directional tunnel set up for that mobile 856 node. 858 o The default-router address MUST be obtained from the IPv4 Default- 859 Router Address option present in the received Proxy Binding 860 Acknowledgement message. The mobile access gateway MAY configure 861 this address on its interface and respond to any ARP requests sent 862 by the mobile node for resolving the hardware address of the 863 default-router. It MAY also use this address as the source 864 address for any datagrams sent to the mobile node and originated 865 by the mobile access gateway itself. It MAY also use this address 866 in the DHCP Router option [RFC-2132] in the DHCP messages. 868 o If there is an IPv4 DHCP Support Mode option present in the 869 received Proxy Binding Acknowledgement message and if the (S) flag 870 in the option is set to a value of 1, then the mobile access 871 gateway MUST function as a DHCP server for the mobile node. If 872 either the (S) flag in the option is set to a value of 0, or if 873 the option is not present in the request, then the mobile access 874 gateway MUST function as a DHCP Relay for the mobile node. 876 3.2.3.3. Binding Re-Registration and De-Registrations 878 When sending a Proxy Binding Update either for extending the lifetime 879 of a mobility session or for de-registering the mobility session, the 880 respective considerations from [RFC-5213] MUST be applied. 881 Furthermore, the following additional considerations MUST also be 882 applied. 884 o If there is an IPv4 home address assigned to the mobility session, 885 then there MUST be exactly one instance of the IPv4 Home Address 886 option [ID-DSMIP6] present in the Proxy Binding Update message. 887 The IPv4 home address and the prefix length fields in the option 888 MUST be set to that specific address and its corresponding subnet- 889 mask length. The (P) flag in the option MUST be set to 0. 891 o If there was no IPv4 home address requested in the initial Proxy 892 Binding Update message, but if it is determined that the IPv4 home 893 address MUST be requested subsequently, then there MUST be exactly 894 one instance of the IPv4 Home Address option [ID-DSMIP6] present 895 in the Proxy Binding Update message. The IPv4 home address in the 896 option MUST be set to either ALL_ZERO or to a specific address 897 that is being requested. 899 o For performing selective de-registration of IPv4 home address but 900 still retaining the mobility session with all the IPv6 home 901 network prefixes, the Proxy Binding Update message with the 902 lifetime value of 0 MUST NOT include any IPv6 Home Network Prefix 903 options(s) [RFC-5213]. It MUST include exactly one instance of 904 the IPv4 Home Address option [ID-DSMIP6] with the IPv4 home 905 address and the prefix length fields in the option set to the IPv4 906 home address that is being de-registered. Similarly for selective 907 de-registration of all the IPv6 home network prefixes, the Proxy 908 Binding Update message MUST NOT include the IPv4 Home address 909 option, it MUST include a Home Network Prefix option for each of 910 the assigned home network prefixes assigned for that mobility 911 session and with the prefix value in the option set to that 912 respective prefix value. 914 o The Home Network Prefix option(s) [RFC-5213] MUST NOT be present 915 if the same option(s) was not present in the initial Proxy Binding 916 Update message. Otherwise considerations from [RFC-5213] with 917 respect to this option MUST be applied. 919 o If at any point the mobile access gateway fails to extend the 920 binding lifetime with the local mobility anchor for the mobile 921 node's IPv4 address, it MUST remove any forwarding state set up 922 for the mobile node's IPv4 home address. 924 3.2.4. Routing Considerations for the Mobile Access Gateway 926 o On receiving a packet from the bi-directional tunnel established 927 with the mobile node's local mobility anchor, the mobile access 928 gateway MUST remove the outer header before forwarding the packet 929 to the mobile node. 931 o Considerations from Section 6.10.3 of [RFC-5213] MUST be applied 932 with respect the local routing and on the use of 933 EnableMAGLocalRouting flag. 935 o On receiving a packet from a mobile node connected to its access 936 link, the packet MUST be forwarded to the local mobility anchor 937 through the bi-directional tunnel established with the local 938 mobility anchor. The encapsulation considerations specified in 939 section 3.1.3 MUST be applied. However, before forwarding the 940 packet, the mobile access gateway MUST ensure the source address 941 in the received packet is the address allocated for that mobile 942 node and that there is an active binding on the local mobility 943 anchor for that mobile node. 945 3.3. Mobility Options and Status Codes 947 To support the IPv4 home address mobility feature, this specification 948 defines the following new options and Status Codes. 950 3.3.1. IPv4 Default-Router Address Option 952 A new option, IPv4 Default-Router Address Option is defined for using 953 it in the Proxy Binding Acknowledgment message [RFC-5213] sent by the 954 local mobility anchor to the mobile access gateway. This option can 955 be used for sending the mobile node's IPv4 default-router address. 957 The IPv4 Default-Router Address option has an alignment requirement 958 of 4n. Its format is as follows: 960 0 1 2 3 961 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 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Type | Length | Reserved (R) | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | IPv4 Default-Router Address | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 Figure 3: IPv4 Default-Router Address Option 970 Type 972 IANA 974 Length 976 8-bit unsigned integer indicating the length of the option in 977 octets, excluding the type and length fields. This field MUST 978 be set to 6. 980 Reserved (R) 982 This 8-bit field is unused for now. The value MUST be 983 initialized to 0 by the sender and MUST be ignored by the 984 receiver. 986 IPv4 Default-Router Address 988 A four-byte field containing the mobile node's default router 989 address. 991 3.3.2. IPv4 DHCP Support Mode 993 A new option, IPv4 DHCP Support Mode Option is defined for using it 994 in the Proxy Binding Acknowledgment message [RFC-5213] sent by the 995 local mobility anchor to the mobile access gateway. This option can 996 be used for notifying the mobile access gateway, if it should 997 function as a DHCP Server or a DHCP Relay for the attached mobile 998 node. 1000 The IPv4 DHCP Support Mode option has no alignment requirement. Its 1001 format is as follows: 1003 0 1 2 3 1004 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 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Type | Length | Reserved (R) |S| 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 Figure 4: IPv4 DHCP Support Mode Option 1011 Type 1013 IANA 1015 Length 1017 8-bit unsigned integer indicating the length of the option in 1018 octets, excluding the type and length fields. This field MUST 1019 be set to 2. 1021 Reserved (R) 1023 This 15-bit field is unused for now. The value MUST be 1024 initialized to 0 by the sender and MUST be ignored by the 1025 receiver. 1027 DHCP Support Mode (S) 1028 A 1-bit field that specifies the DHCP support mode. This flag 1029 indicates if the mobile access gateway should function as a 1030 DHCP Server or a DHCP Relay for the attached mobile node. The 1031 flag value of (0) indicates the mobile access gateway should 1032 act as a DHCP Relay and the flag value of (1) indicates it 1033 should act as a DHCP Server. 1035 3.3.3. Status Codes 1037 This document defines the following new Status values for use in the 1038 Proxy Binding Acknowledgement message [RFC-5213]. These values are 1039 to be allocated from the same numbering space, as defined in Section 1040 6.1.8 of [RFC-3775]. 1042 NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS: IANA 1044 Mobile node not authorized for the requesting IPv4 home address 1046 NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX: IANA 1048 Mobile node not authorized for the requesting IPv6 home network 1049 prefix(es). 1051 MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED 1053 Multiple IPv4 home address assignment not supported 1055 IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED 1057 IPv4 prefix assignment not supported 1059 3.4. Supporting DHCP-Based Address Configuration 1061 This section explains how DHCP-based address configuration support 1062 can be enabled for a mobile node in a Proxy Mobile IPv6 domain. It 1063 explains the protocol operation, supported DHCP server deployment 1064 configurations and the protocol interactions between DHCP agents and 1065 mobility entities in each of the supported configurations. 1067 This specification supports the following two DHCP deployment 1068 configurations. 1070 o DHCP relay agent co-located with the mobile access gateway. 1072 o DHCP server co-located in the mobile access gateway. 1074 The following are the configuration requirements: 1076 o The DHCP server or the DHCP relay agent configured on the mobile 1077 access gateway is required to have an IPv4 address for exchanging 1078 the DHCP messages with the mobile node. This address can be 1079 either the IPv4 Proxy Care-of Address or the mobile node's 1080 default-router address provided by the local mobility anchor. 1081 Optionally, all the DHCP servers co-located with the mobile access 1082 gateways in the Proxy Mobile IPv6 domain can be configured with a 1083 fixed IPv4 address. This fixed address can be potentially an IPv4 1084 private address [RFC-1918] that can be used for the DHCP protocol 1085 communication on any of the access links. This address will be 1086 used as the server identifier in the DHCP messages. 1088 o A DHCP server identifies the DHCP client and its interface for 1089 which the address is assigned from the client identifier and the 1090 client hardware address (chaddr) [RFC-2131] fields respectively. 1091 A mobile node in a Proxy Mobile IPv6 domain, can attach to the 1092 network through multiple interfaces and additionally may perform 1093 handoffs between its interfaces. Following are the related 1094 considerations: 1096 * If the mobile node attaches to the Proxy Mobile IPv6 domain 1097 through multiple interfaces, the DHCP server will uniquely 1098 identify each of those interfaces from the client hardware 1099 address and will perform address assignment. As the mobile 1100 node changes its point of attachment in the network and 1101 performs an handoff to a different mobile access gateway, using 1102 the same interface, the DHCP server will always be able to 1103 identify the binding using the presented client hardware 1104 address. The client hardware address and client identifier 1105 will remain as the primary keys for each binding, just as how 1106 they are unique in a Binding Cache entry. 1108 * However, if the mobile node is capable of performing handoff 1109 between interfaces, as per [RFC-5213], the client hardware 1110 address in such scenarios needs to be an identifier that is not 1111 tied to any of those interfaces. The identifier must be a 1112 stable identifier which remains the same through out the mobile 1113 node's attachment in that Proxy Mobile IPv6 domain. This 1114 identifier must remain fixed for a given binding. This 1115 identifier in some implementations can be the identifier 1116 associated to a virtual interface, that is abstracting the 1117 physical interfaces. 1119 o All the DHCP servers co-located with the mobile access gateways in 1120 a Proxy Mobile IPv6 domain can be configured with the same set of 1121 DHCP option values (Ex: DNS Server, SIP Server ..etc.) to ensure 1122 the mobile node receives the same configuration values on any of 1123 the access links in that Proxy Mobile IPv6 domain. 1125 3.4.1. DHCP Server co-located with the Mobile Access Gateway 1127 This section explains the operational sequence of home address 1128 assignment operation when the DHCP server is co-located with the 1129 mobile access gateway. 1131 MN MAG(DHCP-S) LMA 1132 |------>| | 1. DHCPDISCOVER 1133 | |------->| 2. Proxy Binding Update 1134 | |<-------| 3. Proxy Binding Acknowledgement (IPv4 HoA) 1135 | |========| 4. Tunnel/Route Setup 1136 |<------| | 5. DHCPOFFER (IPv4 HoA) 1137 |------>| | 6. DHCPREQUEST (IPv4 HoA) 1138 |<------| | 7. DHCPACK 1139 | | | 1140 * DHCPDISCOVER (Step-1) and Proxy Mobile IPv6 signaling 1141 * (Step-2 to Step-4) may happen in parallel and in no specific order 1142 * Tunnel/Route setup(Step-4) and the subsequent steps will happen in 1143 * in the specified order. 1145 Figure 5: Overview of DHCP Server located at Mobile Access Gateway 1147 Initial IPv4 Home Address Assignment: 1149 o When the mobile node sends a DHCPDISCOVER message [RFC-2131], the 1150 DHCP server co-located with the mobile access gateway will trigger 1151 the mobile access gateway to complete the Proxy Mobile IPv6 1152 signaling. This is the required interaction between these two 1153 protocols. If the mobile access gateway is unable to complete the 1154 Proxy Mobile IPv6 signaling, or, if the local mobility anchor does 1155 not assign an IPv4 address for the mobile node, the mobile access 1156 gateway MUST NOT enable IPv4 support for the mobile node on that 1157 access link. The trigger for initiating Proxy Mobile IPv6 1158 signaling can also be delivered to the mobile access gateway as 1159 part of a context transfer from the previous mobile access 1160 gateway, or delivered from the other network elements in the radio 1161 network, the details of which are outside the scope of this 1162 document. 1164 o After a successful completion of the Proxy Mobile IPv6 signaling 1165 and upon acquiring the mobile node's IPv4 home address from the 1166 local mobility anchor, the DHCP server on the mobile access 1167 gateway will send a DHCPOFFER message [RFC-2131] to the mobile 1168 node. The offered address will be the mobile node's IPv4 home 1169 address, assigned by the local mobility anchor. The server 1170 address, 'siaddr' field of the DHCPOFFER message, will be set to 1171 the mobile node's default-router address. The DHCPOFFER message 1172 will be sent to the mobile node just as specified in [RFC-2131]. 1174 o If the mobile node sends the DHCPREQUEST message, the DHCP server 1175 will send DHCPACK message, as per [RFC-2131]. 1177 IPv4 Home Address Renewal with the DHCP server (No Handoff): 1179 o Any time the mobile node goes into the DHCP RENEWING state [RFC- 1180 2131], it simply unicasts the DHCPREQUEST message including the 1181 assigned IPv4 home address in the 'requested IP address' option. 1182 The DHCPREQUEST is sent to the address specified in 'server 1183 identifier' field of the previously received DHCPOFFER and DHCPACK 1184 messages. 1186 o The DHCP server will send a DHCPACK to the mobile node to 1187 acknowledge the assignment of the committed IPv4 address. 1189 IPv4 Home Address Renewal with a different DHCP server (After 1190 Handoff): 1192 When the mobile node goes into the DHCP RENEWING state [RFC-2131], it 1193 directly unicasts the DHCPREQUEST message to the DHCP server that 1194 currently provided the DHCP lease. However, if the mobile node 1195 changed its point of attachment and is attached to a new mobile 1196 access gateway, it is required that the mobile node updates the DHCP 1197 server address and uses the address of the DHCP server that is co- 1198 located with the new mobile access gateway. The following approach 1199 can be adopted to ensure the mobile node uses the DHCP server on the 1200 attached link. 1202 The use of fixed DHCP server address on all DHCP servers 1203 MN oMAG(DHCP-S) nMAG(DHCP-S) 1204 | : | 1205 RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) 1206 BOUND<-------------| 2. DHCPACK or DHCPNACK 1207 | : | 1208 Figure 6: Address renewal with a different DHCP server 1210 o If a fixed address such as the IPv4 default-router address of the 1211 mobile node is used as the DHCP server Id on any of the links in 1212 that Proxy Mobile IPv6 domain, the DHCPREQUEST message sent by the 1213 mobile node for renewing the address will be received by the new 1214 mobile access gateway on the attached link. The mobile access 1215 gateway after completing the Proxy Mobile IPv6 signaling and upon 1216 acquiring the IPv4 home address of the mobile node will return the 1217 address in the DHCPACK message. However, if the mobile access 1218 gateway is unable to complete the Proxy Mobile IPv6 signaling or 1219 is unable to acquire the same IPv4 address as requested by the 1220 mobile node, it will send a DHCPNACK message [RFC-2131] to the 1221 mobile node, as shown in Figure 6-1). 1223 3.4.2. DHCP Relay Agent co-located with the Mobile Access Gateway 1225 A DHCP relay agent is co-located with each mobile access gateway. A 1226 DHCP server is located somewhere in the Proxy Mobile IPv6 domain 1227 (e.g., is co-located with the local mobility anchor). Figure 7 shows 1228 the sequence of IPv4 home address assignment using DHCP Relay. 1230 MN MAG(DHCP-R) LMA DHCP-S 1231 | |------->| | 1. Proxy Binding Update * 1232 | |<-------| | 2. Proxy Binding Acknowledgement (IPv4HoA) 1233 | |========| | 3. Tunnel/Route Setup* 1234 |------>|-------------->| 4. DHCPDISCOVER (IPv4HoA) via DHCP-R 1235 |<------|<--------------| 5. DHCPOFFER (IPv4 HoA) via DHCP-R 1236 |------>|-------------->| 6. DHCPREQUEST (IPv4 HoA) via DHCP-R 1237 |<------|<--------------| 7. DHCPACK via DHCP-R 1238 | | | 1239 * The Proxy Mobile IPv6 signaling (Step-1 to Step-2) and the 1240 DHCPDISCOVER phase (Step-4) may occur in any order. However, 1241 the DHCPOFFER (Step-5) and the following steps will occur in 1242 the specified order and after the Tunnel/Route Setup (Step-3). 1244 Figure 7: Overview of the DHCP relay located at mobile access gateway 1246 Initial IPv4 Home Address Assignment: 1248 o When the mobile access gateway receives a DHCPDISCOVER message 1249 from a mobile node, it can check if there is already an assigned 1250 IPv4 home address for the mobile node, from the local mobility 1251 anchor. If there is no assigned IPv4 home address assigned for 1252 that mobile node, the mobile access gateway has to complete the 1253 Proxy Mobile IPv6 signaling with the local mobility anchor by 1254 sending a Proxy Binding Update message. It is to be noted that 1255 the mobile node needs to be identified by the MN-Identifier, as 1256 specified in Section 6.6 of [RFC-5213]. 1258 o If the Proxy Binding Update message is rejected by the local 1259 mobility anchor for any reason, the mobile access gateway will 1260 discard the DHCPDISCOVER messages from the mobile node. 1262 o If the Proxy Binding Update message is accepted by the local 1263 mobility anchor and if there is an assigned IPv4 home address for 1264 the mobile node, the DHCP messages will be forwarded to the DHCP 1265 server. 1267 o The DHCP relay agent on the mobile access gateway will add the 1268 DHCP relay agent information option [RFC-3046] to the DHCPDISCOVER 1269 message. The assigned IPv4 home address will be included in the 1270 Agent Remote ID Sub-option of the DHCP relay agent information 1271 option. This sub-option is used as a hint for requesting the DHCP 1272 server to allocate that specific IPv4 address. 1274 o On receiving a DHCPOFFER message from the DHCP server, the mobile 1275 access gateway will ensure the assigned address is currently 1276 assigned by the local mobility anchor to that mobile node. If 1277 this address is different from what is assigned to the mobile 1278 node, then the mobile access gateway will drop the DHCPOFFER 1279 message and an administrative error message will be logged. 1281 o When the DHCP messages are sent over administrative boundaries, 1282 the operators needs to ensure these messages are secured. All the 1283 DHCP messages relayed by the mobile access gateway can be tunneled 1284 to the local mobility anchor if needed. Alternatively, if the 1285 network in the Proxy Mobile IPv6 domain is secure enough, the 1286 mobile access gateway can just relay the DHCP messages to the 1287 server. To achieve this, all the mobile access gateways needs to 1288 have a route towards the DHCP server. 1290 IPv4 Home Address Renewal to the same DHCP server: (No Handover) 1292 o When the DHCP client goes into the DHCP RENEW STATE [RFC-2131], it 1293 directly unicasts DHCPREQUEST messages to the DHCP server. The 1294 DHCP relay agent may not detect any changes in the DHCP state. 1295 For example, if the mobile node releases the IPv4 address, the 1296 relay agent would not be aware of it. The following describes 1297 additional mechanisms for the mobile access gateway to detect any 1298 changes in the DHCP state. 1300 * The DHCP relay agent can intercept all IPv4 DHCP packets 1301 destined to the set of addresses used within the Proxy Mobile 1302 IPv6 domain as DHCP addresses. Since the link between a mobile 1303 node and a mobile access gateway is the point-to-point link, 1304 the mobile access gateway will be in path for all the messages. 1306 * The DHCP relay agent can use the DHCP Server Identifier 1307 Override Sub-option [RFC-5107] to be in path for all the DHCP 1308 message flows. The DHCP client uses the DHCP server address 1309 which is overridden by the DHCP relay agent address as a 1310 destination address of DHCPREQUEST. The DHCP Server Identifier 1311 Override Sub-option is recommended only when the fixed DHCP 1312 relay address is configured on all the mobile access gateways. 1313 Otherwise, the DHCP relay agent address is changed when the 1314 mobile node changes the attached mobile access gateway. 1316 o However, if the DHCP server is co-located with the local mobility 1317 anchor, then the DHCP relay agent is not required to intercept the 1318 unicast DHCP messages between the mobile node and the DHCP server. 1319 This is because the local mobility anchor will ensure that the 1320 DHCP state is consistent with the PMIPv6 binding that exists for 1321 the IPv4 address. 1323 o Once the mobile access gateway intercepts the DHCP message from 1324 the mobile node to the DHCP server, it can verify if the mobile 1325 node is negotiating the same IPv4 address that the local mobility 1326 anchor allocated for that mobile node. If the address in the 1327 DHCPREQUEST message does not match with the IPv4 address allocated 1328 for the mobile node, then the mobile access gateway SHOULD 1329 silently drop the DHCP message. 1331 o Any time the mobile access gateway detects that the mobile node 1332 has released its IPv4 address, it can send a Proxy Binding Update 1333 to the local mobility anchor and de-register the IPv4 mobility 1334 session. 1336 3.4.3. Common DHCP Considerations 1338 The following handoff considerations are common to both the supported 1339 configuration modes, specified in Section 3.4.1 and Section 3.4.2. 1341 o When the mobile node performs an handoff from one mobile access 1342 gateway to the another, the mobile access gateway on the new link 1343 will initiate the Proxy Mobile IPv6 signaling with the local 1344 mobility anchor. On completing the Proxy Mobile IPv6 signaling, 1345 the mobile access gateway has the proper IPv4 address state that 1346 the local mobility anchor has allocated for the mobile node and 1347 which can be used for supporting DHCP based address configuration 1348 on that link. 1350 o If the mobile node is DNAv4 [RFC-4436] capable and if it performs 1351 DNAv4 procedures after a handoff, it would always detect the same 1352 default-router on any of the access links in that Proxy Mobile 1353 IPv6 domain, as the mobile access gateway configures a fixed link- 1354 layer address on all the access links, as per the base Proxy 1355 Mobile IPv6 specification [RFC-5213]. The mobile node will not 1356 perform any DHCP operation specifically due to this handoff. 1358 o If the mobile node is not DNAv4 [RFC-4436] capable, after handoff 1359 it will enter INIT-REBOOT state [RFC-2131] and will send a 1360 DHCPREQUEST message. The mobile node in both the configuration 1361 modes, specified in Section 3.4.1 and Section 3.4.2, will obtain 1362 the same address configuration as before, as the link change will 1363 not be transparent to the mobile node in that Proxy Mobile IPv6 1364 domain. 1366 o The mobile node may release its IPv4 home address at any time by 1367 sending the DHCPRELEASE message [RFC-2131]. When the mobile 1368 access gateway detects the DHCPRELEASE message sent by the mobile 1369 node, it should consider this as a trigger for de-registering the 1370 mobile node's IPv4 home address. It will apply the considerations 1371 specified in section 3.2.3.3 for performing the de-registration 1372 procedure. However, this operation should not release any IPv6 1373 home network prefix(es) assigned to the mobile node. 1375 4. IPv4 Transport Support 1377 The Proxy Mobile IPv6 specification [RFC-5213] requires the signaling 1378 messages exchanged between the local mobility anchor and the mobile 1379 access gateway to be over an IPv6 transport. The extensions defined 1380 in this section allow the exchange of signaling messages over an IPv4 1381 transport when the local mobility anchor and the mobile access 1382 gateway are separated by an IPv4 network and are reachable using only 1383 IPv4 addresses. 1385 IPv4-Proxy-CoA IPv4-LMAA 1386 | + - - - - - - + | 1387 +--+ +---+ / \ +---+ +--+ 1388 |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| 1389 +--+ +---+ \ / +---+ +--+ 1390 + - - - - - - + 1392 Figure 8: IPv4 Transport Network 1394 When the local mobility anchor and the mobile access gateway are 1395 configured and reachable using only IPv4 addresses, the mobile access 1396 gateway serving a mobile node can potentially send the signaling 1397 messages over IPv4 transport and register its IPv4 address as the 1398 care-of address in the mobile node's Binding Cache entry. An IPv4 1399 tunnel (with any of the supported encapsulation modes) can be used 1400 for tunneling the mobile node's data traffic. The following are the 1401 key aspects of this feature. 1403 o The local mobility anchor and the mobile access gateway are both 1404 configured and reachable using an IPv4 address. Additionally, 1405 both entities are also IPv6 enabled and have configured IPv6 1406 addresses on their interfaces, as specified in [RFC-5213], but are 1407 reachable only over an IPv4 transport. 1409 o The mobile access gateway can be potentially in a private IPv4 1410 network behind a NAT [RFC-3022] device, with a private IPv4 1411 address configured on its egress interface. But, the local 1412 mobility anchor must not be behind a NAT and must be using a 1413 globally routable IPv4 address. However, both the local mobility 1414 anchor and the mobile access gateway can be in the same private 1415 IPv4 routing domain, i.e., when both are configured with private 1416 IPv4 addresses and with no need for NAT translation between them. 1418 o The IPv6 address configuration requirement on the mobile access 1419 gateway does not imply there needs to be IPv6 routing enabled 1420 between the local mobility anchor and the mobile access gateway. 1421 It just requires each of the mobile access gateways and local 1422 mobility anchors in a Proxy Mobile IPv6 domain to be configured 1423 with a globally unique IPv6 address. 1425 o The Proxy Mobile IPv6 signaling messages exchanged between the 1426 local mobility anchor and the mobile access gateway for 1427 negotiating the IPv4 transport will be encapsulated and carried as 1428 IPv4 packets. However, these signaling messages are fundamentally 1429 IPv6 messages using the mobility header and the related semantics 1430 as specified in base Proxy Mobile IPv6 specification [RFC-5213], 1431 but carried as a payload in an IPv4 packet. The supported 1432 encapsulation modes for the signaling messages are either native 1433 IPv4 or IPv4 with UDP header. 1435 o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and 1436 the IPv4 transport support specified in this section is agnostic 1437 to the type of address mobility enabled for that mobile node. 1439 o The IPv4 tunnel established between the local mobility anchor and 1440 the mobile access gateway (with any of the supported encapsulation 1441 modes over IPv4 transport) will be used for carrying the mobile 1442 node's IPv4 and IPv6 traffic. The following are the outer headers 1443 based on the negotiated encapsulation mode. 1445 * IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet). 1446 If payload protection using IPsec is enabled for the tunneled 1447 traffic, the ESP header follows the outer tunnel header. 1449 * IPv4-UDP (Payload packet carried in an IPv4 packet with UDP 1450 header). If payload protection using IPsec is enabled for the 1451 tunneled traffic, the ESP header follows the outer tunnel 1452 header, as specified in [RFC-3948]. 1454 * IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP 1455 and TLV header). Refer to [ID-GREKEY-NEGO]. If payload 1456 protection using IPsec is enabled for the tunneled traffic, the 1457 ESP header follows the outer tunnel header. 1459 4.1. Local Mobility Anchor Considerations 1461 4.1.1. Extensions to Binding Cache Entry 1463 To support this feature, the conceptual Binding Cache entry data 1464 structure maintained by the local mobility anchor [RFC-5213] MUST be 1465 extended with the following additional parameters. It is to be noted 1466 that all of these parameters are specified in [ID-DSMIP6] and also 1467 required here in the present usage context, and are presented here 1468 only for completeness. 1470 o The IPv4 Proxy Care-of Address configured on the mobile access 1471 gateway that sent the Proxy Binding Update message. This address 1472 can be obtained from the IPv4 Care-of Address option [ID-DSMIP6], 1473 present in the received Proxy Binding Update message. However, if 1474 the received Proxy Binding Update message is not sent as an IPv4 1475 packet, i.e., when using IPv6 transport, this field in the Binding 1476 Cache entry MUST be set to ALL_ZERO value. 1478 o The IPv4 NAT translated address of the mobile access gateway. If 1479 the mobile access gateway is not behind a NAT [RFC-3022], this 1480 address will be the same as the address configured on the egress 1481 interface of the mobile access gateway. This address can be 1482 obtained from the IPv4 header of the received Proxy Binding Update 1483 message. However, if the received Proxy Binding Update message is 1484 not sent as an IPv4 packet, this field in the Binding Cache entry 1485 MUST be set to ALL_ZERO value. 1487 o The source UDP port, if the Proxy Binding Update was received in 1488 an IPv4 packet with UDP header. 1490 o The destination UDP port, if the Proxy Binding Update was received 1491 in an IPv4 packet with UDP header. 1493 4.1.2. Extensions to Mobile Node's Policy Profile 1495 To support the IPv4 Transport Support feature the mobile node's 1496 policy profile, specified in Section 6.2 of [RFC-5213] MUST be 1497 extended with the following additional fields. These are mandatory 1498 fields of the policy profile required for supporting this feature. 1500 o The IPv4 address of the local mobility anchor (IPv4-LMAA). 1502 4.1.3. Signaling Considerations 1504 This section provides the rules for processing the Proxy Mobile IPv6 1505 signaling messages received over IPv4 transport. 1507 4.1.3.1. Processing Proxy Binding Updates 1509 o If the received Proxy Binding Update message was sent encapsulated 1510 in IPv4 or IPv4-UDP header, the message MUST be authenticated 1511 after removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1512 Considerations from Section 4 of [RFC-5213] MUST be applied for 1513 authenticating and authorizing the request. 1515 o All the considerations from Section 5.3.1 of [RFC-5213] MUST be 1516 applied on the encapsulated Proxy Binding Update message, after 1517 removing the outer encapsulation (IPv4 or IPv4-UDP) header. 1519 o If there is an IPv4 Care-of Address option [ID-DSMIP6] present in 1520 the request and if the outer encapsulation header is IPv4-UDP, 1521 then the NAT presence detection procedure specified in Section 1522 4.1.3.3 MUST be used for detecting the NAT in the path. 1524 o Upon accepting the request, the local mobility anchor MUST set up 1525 an IPv4 bi-directional tunnel to the mobile access gateway. The 1526 tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA. 1527 The encapsulation mode MUST be determined from the below 1528 considerations. 1530 * If the received Proxy Binding Update message was sent with IPv4 1531 encapsulated header, then the encapsulation mode for the bi- 1532 directional tunnel MUST be set to IPv4. Otherwise, the 1533 following considerations apply. 1535 * If NAT is not detected on the path and if the (F) flag in the 1536 received Proxy Binding Update message is set to the value of 1, 1537 but if the configuration flag, 1538 AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of 1539 0, then the local mobility anchor MUST reject the request with 1540 the Status field value set to 129 (Administratively 1541 prohibited). 1543 * If the (T) flag [ID-GREKEY-NEGO] in the Proxy Binding Update 1544 message is set to value of 1, then the encapsulation mode MUST 1545 be set to IPv4-or-IPv6-over-IPv4-UDP-TLV. 1547 * If NAT is detected on the path, or if the (F) flag in the 1548 received Proxy Binding Update message is set to the value of 1, 1549 then the encapsulation mode MUST be set to IPv4-or-IPv6-over- 1550 IPv4-UDP. Otherwise the encapsulation mode MUST be set to 1551 IPv4-or-IPv6-over-IPv4. 1553 o The local mobility anchor MUST send the Proxy Binding 1554 Acknowledgement message with the Status field value set to 0 1555 (Proxy Binding Update Accepted). The message MUST be constructed 1556 as specified in Section 4.1.3.2. 1558 4.1.3.2. Constructing the Proxy Binding Acknowledgement Message 1560 The local mobility anchor when sending the Proxy Binding 1561 Acknowledgement message to the mobile access gateway MUST construct 1562 the message as specified in Section 5.3.6 of [RFC-5213]. However, if 1563 the received Proxy Binding Update message was encapsulated in an IPv4 1564 packet or as a payload in the UDP header of an IPv4 packet, the 1565 following additional considerations MUST be applied. 1567 o The Proxy Binding Acknowledgement message MUST be encapsulated in 1568 an IPv4 packet. However, if the received Proxy Binding Update 1569 message was sent encapsulated in the UDP header of an IPv4 packet, 1570 then the Proxy Binding Acknowledgement message MUST be 1571 encapsulated in the UDP header of an IPv4 packet. 1573 o The source address in the IPv4 header of the message MUST be set 1574 to the destination IPv4 address of the received request. 1576 o If the mobile access gateway and the local mobility anchor are 1577 using globally routable IPv4 addresses and if there is a security 1578 association that is based of IPv4 addresses, then the encapsulated 1579 IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement) 1580 MUST be protected using IPsec ESP [RFC-4301] mode. There is no 1581 need to apply IPsec ESP header to the IPv6 packet. In all other 1582 cases, the Proxy Binding Acknowledgement message MUST be protected 1583 using IPsec prior to the IPv4 or IPv4-UDP encapsulation. 1585 o The NAT Detection option [ID-DSMIP6] MUST be present only if there 1586 is an IPv4 Care-of Address option [ID-DSMIP6] present in the 1587 received Proxy Binding Update message and if the NAT detection 1588 procedure resulted in detecting a NAT on path. However, if the 1589 received Proxy Binding Update message was not sent encapsulated in 1590 IPv4 UDP header, then the option MUST NOT be present. 1591 Furthermore, in all other cases, the option MUST NOT be present. 1593 o The IPv4 DHCP Support Mode option MAY be present. If this option 1594 is not present, the mobile access gateway will enable the default 1595 behavior and function as a DHCP Relay for the mobile node. 1597 o The format of the Proxy Binding Acknowledgement message 1598 encapsulated in an IPv4 packet and protected using IPv6 security 1599 association. The UDP header MUST be present only if the received 1600 Proxy Binding Update message was sent with IPv4-UDP encapsulation 1601 header. 1603 IPv4 header (src=IPv4-LMAA, dst=pbu_src_address) 1604 UDP header (sport=DSMIP_PORT, dport= pbu_sport) /*Optional*/ 1605 /* IPv6 PBA Packet protected with ESP header */ 1607 Figure 9: Proxy Binding Acknowledgment (PBA) Message encapsulated 1608 in IPv4 header 1610 4.1.3.3. NAT Presence Detection 1612 When the transport network between the local mobility anchor and the 1613 mobile access gateway is an IPv4 network and if the received Proxy 1614 Binding Update message was sent encapsulated in IPv4 UDP header, the 1615 local mobility anchor performs the NAT Presence Detection as 1616 specified below. 1618 On receiving the Proxy Binding Update message encapsulated in an IPv4 1619 UDP packet, the local mobility anchor, if it detects a NAT on the 1620 path, will send the Proxy Binding Acknowledgment message with the NAT 1621 Detection Option. The presence of this option in the Proxy Binding 1622 Acknowledgment is an indication to the mobile access gateway about 1623 the presence of NAT in the path. On detecting any NAT in the path, 1624 both the local mobility anchor and the mobile access gateway will set 1625 the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation. 1626 The specific details around the NAT detection and the related logic 1627 are described in DSMIPv6 specification [ID-DSMIP6]. 1629 However, if the value of the configuration variable, 1630 UseIPv4UDPEncapForSignalingMessages, is set to a value of 0, the 1631 mobile access gateway will not use IPv4 UDP encapsulation for Proxy 1632 Binding Update messages and hence the local mobility anchor will not 1633 perform this NAT Presence Detection procedure on these messages that 1634 are not sent in IPv4 UDP packet. 1636 4.1.4. Routing Considerations 1638 4.1.4.1. Forwarding Considerations 1640 Forwarding Packets to the Mobile Node: 1642 o On receiving an IPv4 or an IPv6 packet from a correspondent node 1643 with the destination address matching any of the mobile node's 1644 IPv4 or IPv6 home addresses, the local mobility anchor MUST 1645 forward the packet through the bi-directional tunnel set up for 1646 that mobile node. 1648 o The format of the tunneled packet is shown below. 1650 IPv4 Header (src= IPv4-LMAA, dst= IPv4-Proxy-CoA)] /* Tunnel Header */ 1651 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1652 [TLV Header] /* If TLV negotiated */ 1653 /* IPv6 or IPv4 Payload Packet */ 1654 IPv6 header (src= CN, dst= MN-HOA) 1655 OR 1656 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1658 Figure 10: Tunneled IPv4 Packet from LMA to MAG 1660 o Forwarding Packets Sent by the Mobile Node: 1662 * All the reverse tunneled packets (IPv4 and IPv6) that the local 1663 mobility anchor receives from the mobile access gateway, after 1664 removing the tunnel header (i.e., the outer IPv4 header along 1665 with the UDP and TLV header, if negotiated) MUST be routed to 1666 the destination specified in the inner packet header. These 1667 routed packets will have the source address field set to the 1668 mobile node's home address. 1670 4.1.4.2. ECN Considerations 1672 The ECN considerations specified in Section 5.6.3 of [RFC-5213] apply 1673 for the IPv4 transport tunnels as well. The mobility agents at the 1674 tunnel entry and exit points MUST handle ECN information as specified 1675 in that document. 1677 4.1.4.3. Bi-Directional Tunnel Management 1679 The Tunnel Management considerations specified in section 5.6.1 of 1680 [RFC-5213] apply for the IPv4 transport tunnels as well, with just 1681 one difference that the encapsulation mode is different. 1683 4.2. Mobile Access Gateway Considerations 1685 4.2.1. Extensions to Binding Update List Entry 1687 To support the IPv4 Transport Support feature, the conceptual Binding 1688 Update List entry data structure maintained by the mobile access 1689 gateway [RFC-5213] MUST be extended with the following additional 1690 parameters. 1692 o The IPv4 address of the local mobility anchor. This address can 1693 be obtained from the mobile node's policy profile. 1695 4.2.2. Signaling Considerations 1697 The mobile access gateway when sending a Proxy Binding Update message 1698 to the local mobility anchor MUST construct the message as specified 1699 in Section 6.9.1.5 of [RFC-5213]. However, if the mobile access 1700 gateway is in an IPv4-only access network, the following additional 1701 considerations MUST be applied. 1703 o The Proxy Binding Update message MUST be encapsulated in an IPv4 1704 packet. However, if the value of the configuration variable, 1705 UseIPv4UDPEncapForSignalingMessages, is set to 1, then the Proxy 1706 Binding Update message MUST be encapsulated in an UDP header of an 1707 IPv4 packet. 1709 o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The 1710 IPv4 address in the option MUST be set to the mobile access 1711 gateway's IPv4-Proxy-CoA. 1713 o The packet MUST be constructed as specified in Section 4.2.3. 1715 o Just as specified in [RFC-5213], when sending a Proxy Binding 1716 message for extending the lifetime of a currently existing 1717 mobility session or for de-registering the mobility session, the 1718 Proxy Binding Update message MUST be constructed just as the 1719 initial request. 1721 Receiving Proxy Binding Acknowledgement 1723 o If the received Proxy Binding Acknowledgement message is 1724 encapsulated in IPv4 or IPv4 UDP packet, the message MUST be 1725 authenticated after removing the outer IPv4 or IPv4-UDP header. 1726 Considerations from Section 4 of [RFC-5213] MUST be applied for 1727 authenticating and authorizing the message. 1729 o All the considerations from Section 6.9.1.2 of [RFC-5213] MUST be 1730 applied on the encapsulated Proxy Binding Acknowledgement message, 1731 after removing the outer IPv4 UDP header. 1733 o If the Status field indicates Success, the mobile access gateway 1734 MUST setup a bi-directional tunnel to the local mobility anchor. 1736 o Upon accepting the request, the mobile access gateway MUST set up 1737 an IPv4 bi-directional tunnel to the local mobility anchor. The 1738 tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA. 1739 The encapsulation mode MUST be determined from the below 1740 considerations. 1742 * The encapsulation mode for the bi-directional tunnel MUST be 1743 set to IPv4. However, if the value of the configuration 1744 variable, UseIPv4UDPEncapForSignalingMessages, is set to 1, 1745 then the following considerations MUST be applied. 1747 * If there is a NAT Detection option [ID-DSMIP6] in the received 1748 Proxy Binding Acknowledgement message and if the value of the 1749 configuration flag, UseIPv4UDPEncapForSignalingMessages, is set 1750 to value of 1, then the encapsulation mode for the tunnel MUST 1751 be set to IPv4-UDP. Otherwise the encapsulation mode MUST be 1752 set to IPv4. 1754 * If the (T) flag in the Proxy Binding Acknowledgement message is 1755 set to value of 1, then the encapsulation mode MUST be set to 1756 IPv4-UDP-TLV. 1758 4.2.2.1. Constructing the Proxy Binding Update Message 1760 o The source address in the IPv4 header MUST be set to IPv4-Proxy- 1761 CoA of the mobile access gateway and the destination address MUST 1762 be set to the local mobility anchor's IPv4-LMAA. 1764 o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The 1765 address MUST be set to the mobile access gateway's IPv4-Proxy-CoA. 1767 o If the configuration variable ForceIPv4UDPEncapsulationSupport is 1768 set to value of 1, then the (F) flag in the Proxy Binding Update 1769 message MUST be set to value of 1. 1771 o The Proxy Binding Update message MUST be protected using IPsec ESP 1772 [RFC-4301], as specified in [RFC-5213]. The protection MUST be 1773 applied on the IPv6 packet of the Proxy Binding Update message, 1774 prior to the IPv4 encapsulation. 1776 o The format of the Proxy Binding Update message encapsulated in an 1777 IPv4 or IPv4-UDP packet with no IPsec protection: 1779 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1780 UDP header (sport=ANY, dport= DSMIP_PORT) /*Optional*/ 1781 /* IPv6 PBU Packet protected with ESP header */ 1783 Figure 11: Proxy Binding Update (PBU) message encapsulated in IPv4 1784 UDP header 1786 4.2.2.2. Forwarding Considerations 1788 Forwarding Packets Sent by the Mobile Node: 1790 o On receiving an IPv4 or an IPv6 packet from the mobile node to any 1791 destination, the mobile access gateway MUST tunnel the packet to 1792 the local mobility anchor. The format of the tunneled packet is 1793 shown below. However, considerations from Section 6.10.3 of [RFC- 1794 5213] MUST be applied with respect the local routing and on the 1795 use of EnableMAGLocalRouting flag. 1797 IPv4 Header (src= IPv4-Proxy-CoA, dst= IPv4-LMAA)] /* Tunnel Header */ 1798 [UDP Header (src port=DSMIPv6, dst port=Z] /* If UDP encap nego */ 1799 [TLV Header] /* If TLV negotiated */ 1800 /* IPv6 or IPv4 Payload Packet */ 1801 IPv6 header (src= CN, dst= MN-HOA) 1802 OR 1803 IPv4 header (src= CN, dst= IPv4 MN-HoA) 1805 Figure 12: Tunneled IPv4 Packet from LMA to MAG 1807 o Forwarding Packets received from the bi-directional tunnel: 1809 o On receiving a packet from the bi-directional tunnel established 1810 with the mobile node's local mobility anchor, the mobile access 1811 gateway MUST remove the outer header before forwarding the packet 1812 to the mobile node. 1814 5. Protocol Configuration Variables 1816 5.1. Local Mobility Anchor - Configuration Variables 1818 The local mobility anchor MUST allow the following variables to be 1819 configured by the system management. The configured values for these 1820 protocol variables MUST survive server reboots and service restarts. 1822 AcceptForcedIPv4UDPEncapsulationRequest 1824 This flag indicates whether or not the local mobility anchor 1825 should accept IPv4 UDP encapsulation request for the mobile node's 1826 data traffic, even if there is no NAT detected in the path. 1828 The default value for this flag is set to value of 0, indicating 1829 that the local mobility anchor MUST NOT accept IPv4 UDP 1830 encapsulation request when NAT is not detected in the path. 1832 When the value for this flag is set to value of 1, the local 1833 mobility anchor MUST accept IPv4 UDP encapsulation request even 1834 when NAT is not detected in the path. 1836 5.2. Mobile Access Gateway - Configuration Variables 1838 The mobile access gateway MUST allow the following variables to be 1839 configured by the system management. The configured values for these 1840 protocol variables MUST survive server reboots and service restarts. 1842 UseIPv4UDPEncapForSignalingMessages 1844 This flag indicates whether or not the mobile access gateway 1845 should use IPv4-UDP encapsulation mode for the signaling messages. 1847 The default value for this flag is set to value of 0, indicating 1848 that the mobile access gateway MUST NOT use IPv4-UDP encapsulation 1849 mode, but MUST use native IPv4 encapsulation mode for sending the 1850 Proxy Mobile IPv6 signaling messages. 1852 When the value for this flag is set to value of 1, the mobile 1853 access gateway MUST use IPv4-UDP encapsulation mode for sending 1854 the Proxy Mobile IPv6 signaling messages. 1856 ForceIPv4UDPEncapsulationSupport 1857 This flag indicates whether or not the mobile access gateway 1858 should request the mobile node's local mobility anchor for forcing 1859 IPv4 UDP encapsulation support for the mobile node's data traffic, 1860 even when NAT is not detected in the path. 1862 The default value for this flag is set to value of 0, indicating 1863 that the mobile access gateway MUST NOT request the mobile node's 1864 local mobility anchor for forcing IPv4 UDP encapsulation support 1865 even when NAT is not detected in path. 1867 When the value for this flag is set to value of 1, the mobile 1868 access gateway MUST force the mobile node's local mobility anchor 1869 for IPv4 UDP encapsulation support. 1871 This flag is applicable only when the flag 1872 UseIPv4UDPEncapForSignalingMessages is set to a value of 1. 1874 6. IANA Considerations 1876 This document defines a new Mobility Header option, IPv4 Default 1877 Router Address option. This option is described in Section 3.3.1. 1878 The Type value for this option needs to be assigned from the same 1879 number space as allocated for the other mobility options, as defined 1880 in [RFC-3775]. 1882 This document also defines new status values, used in Proxy Binding 1883 Acknowledgement message, as described in Section 3.3.2. These values 1884 are to be assigned from the same number space as allocated for other 1885 Status codes [RFC-3775]. Each of these allocated values have to be 1886 greater than 128. 1888 7. Security Considerations 1890 All the security considerations from the base Proxy Mobile IPv6 [RFC- 1891 5213], Mobile IPv6 [RFC-3775], and Dual-Stack Mobile IPv6 [ID-DSMIP6] 1892 apply when using the extensions defined in this document. 1893 Additionally, the following security considerations need to be 1894 applied. 1896 This document defines news mobility options for supporting the IPv4 1897 Home Address assignment and IPv4 Transport Support features. These 1898 options are to be carried in Proxy Binding Update and Proxy Binding 1899 Acknowledgement messages. The required security mechanisms specified 1900 in the base Proxy Mobile IPv6 protocol for protecting these signaling 1901 messages are sufficient when carrying these mobility options. 1903 This specification describes the use of IPv4 transport for exchanging 1904 the signaling messages between the local mobility anchor and the 1905 mobile access gateway. These signaling messages are fundamentally 1906 IPv6 messages, but encapsulated in an IPv4 header and routed as IPv4 1907 packets. The encapsulated inner IPv6 message is still protected 1908 using IPsec, using the established security association and this 1909 offers the same level of security as when the messages are routed 1910 natively as IPv6 packets. The use of outer IPv4 header does not 1911 introduce any new security vulnerabilities. 1913 8. Contributors 1915 This document reflects discussions and contributions from several 1916 people (in alphabetical order): 1918 Kuntal Chowdhury 1920 kchowdhury@starentnetworks.com 1922 Vijay Devarapalli 1924 vijay.devarapalli@azairenet.com 1926 Sangjin Jeong 1928 sjjeong@etri.re.kr 1930 Basavaraj Patil 1932 basavaraj.patil@nsn.com 1934 Myungki Shin 1936 myungki.shin@gmail.com 1938 9. Acknowledgments 1940 The IPv4 support for Proxy Mobile IPv6 was initially covered in the 1941 internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. We would like 1942 to thank all the authors of the document and acknowledge that initial 1943 work. 1945 Thanks to Alper Yegin, Behcet Sarikaya, Bernard Aboba, Charles 1946 Perkins, Damic Damjan, Jari Arkko, Joel Hortelius, Jonne Soinnen, 1947 Julien Laganier, Mohana Jeyatharan, Niklas Nuemann, Premec Domagoj, 1948 Ralph Droms, Sammy Touati, Vidya Narayanan, Yingzhe Wu and Zu Qiang 1949 for their helpful review of this document. 1951 10. References 1953 10.1. Normative References 1955 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1956 Requirement Levels", BCP 14, RFC 2119, March 1997. 1958 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1959 2131, March 1997. 1961 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1962 IPv6", RFC 3775, June 2004. 1964 [RFC-4193] Hinden, R. and Haberman, B., "Unique Local IPv6 Unicast 1965 Addresses", RFC-4193, October 2005. 1967 [RFC-4291] Hinden, R. and Deering, S., "IP Version 6 Addressing 1968 Architecture", RFC-4291, February 2006. 1970 [RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213, 1971 November 2007. 1973 [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack 1974 Hosts and Routers (DSMIPv6)", 1975 draft-ietf-mext-nemo-v4traversal-10.txt, April 2009. 1977 [ID-GREKEY-NEGO] Muhanna, A., Khalil, M., Gundavelli, S., Leung, K., 1978 "GRE Key Option for Proxy Mobile IPv6", 1979 draft-ietf-netlmm-grekey-option-06.txt, February 2009. 1981 10.2. Informative References 1983 [RFC-1332] G. McGregor, "The PPP Internet Protocol Control Protocol 1984 (IPCP)", RFC 1332, May 1992. 1986 [RFC-1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1987 and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1988 1918, February 1996. 1990 [RFC-2132] Alexander, S. & Droms, R., "DHCP Options and BOOTP Vendor 1991 Extensions", RFC 2132, March 1997. 1993 [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1994 Address Translator (Traditional NAT)", RFC 3022, January 2001. 1996 [RFC-3046] M. Patrick, "DHCP Relay Agent Information Option", January 1997 2001. 1999 [RFC-3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 2000 Unicast Address Format", RFC 3587, August 2003. 2002 [RFC-3948] Huttunen, A. et al, "UDP Encapsulation of IPsec ESP 2003 Packets", RFC 3948, January 2005. 2005 [RFC-4301] Kent, S. and K. Seo, "Security Architecture for the 2006 Internet Protocol", RFC 4301, December 2005. 2008 [RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 2009 4306, December 2005. 2011 [RFC-4436] Aboba, B., Carlson, J. and S.Cheshire, "Detecting Network 2012 Attachment in IPv4", RFC 4436, March 2006. 2014 [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack 2015 Mobility", RFC 4977, August 2007. 2017 [RFC-5107] R. Johnson and J. Jumarasamy and K. Kinnear and M. Stapp, 2018 "DHCP Server Identifier Override Suboption", RFC 5107, February 2008. 2020 Authors' Addresses 2022 Ryuji Wakikawa 2023 Toyota ITC / Keio University 2024 6-6-20 Akasaka, Minato-ku 2025 Tokyo 107-0052 2026 Japan 2028 Phone: +81-3-5561-8276 2029 Fax: +81-3-5561-8292 2030 Email: ryuji@jp.toyota-itc.com 2032 Sri Gundavelli 2033 Cisco 2034 170 West Tasman Drive 2035 San Jose, CA 95134 2036 USA 2038 Email: sgundave@cisco.com