idnits 2.17.1 draft-ietf-netlmm-pmip6-ipv4-support-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1373. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1397. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (May 22, 2008) is 5818 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NAT' is mentioned on line 160, but not defined == Missing Reference: 'TLV-header' is mentioned on line 1144, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-nemo-v4traversal-05 -- Possible downref: Normative reference to a draft: ref. 'ID-DSMIP6' == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-16 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group R. Wakikawa (Editor) 3 Internet-Draft Keio University 4 Intended status: Standards Track S. Gundavelli 5 Expires: November 23, 2008 Cisco 6 May 22, 2008 8 IPv4 Support for Proxy Mobile IPv6 9 draft-ietf-netlmm-pmip6-ipv4-support-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 23, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document specifies extensions to Proxy Mobile IPv6 protocol for 43 supporting IPv4 protocol. The scope of this IPv4 support includes 44 the support for the mobile node's IPv4 home address mobility and for 45 allowing the mobility entities in the Proxy Mobile IPv6 domain to 46 exchange signaling messages over an IPv4 transport. 48 Table of Contents 50 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1. Stated Assumptions . . . . . . . . . . . . . . . . . . . . 5 53 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 7 54 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 55 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 57 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 8 58 3.1. IPv4 Home Address Assignment . . . . . . . . . . . . . . . 8 59 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 11 60 3.2.1. Extensions to Binding Update List Entry . . . . . . . 11 61 3.2.2. Signaling Considerations . . . . . . . . . . . . . . . 11 62 3.3. Local Mobility Anchor Considerations . . . . . . . . . . . 15 63 3.3.1. Extensions to Binding Cache Entry . . . . . . . . . . 15 64 3.3.2. Signaling Considerations . . . . . . . . . . . . . . . 16 65 3.3.3. Routing Considerations . . . . . . . . . . . . . . . . 18 66 3.4. Mobility Options . . . . . . . . . . . . . . . . . . . . . 19 67 3.4.1. IPv4 Default Router Address Option . . . . . . . . . . 19 69 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 20 70 4.1. NAT Support . . . . . . . . . . . . . . . . . . . . . . . 21 71 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 22 72 4.2.1. Extensions to Binding Update List Entry . . . . . . . 22 73 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 22 74 4.3. Local Mobility Anchor Considerations . . . . . . . . . . . 25 75 4.3.1. Extensions to Binding Cache Entry . . . . . . . . . . 25 76 4.3.2. Signaling Considerations . . . . . . . . . . . . . . . 25 77 4.4. Tunnel Management . . . . . . . . . . . . . . . . . . . . 28 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 83 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 32 90 Appendix A. DHCP usages for IPv4 home address assignment . . . . 33 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 93 Intellectual Property and Copyright Statements . . . . . . . . . . 35 95 1. Overview 97 The transition from IPv4 to IPv6 is a long process and during this 98 period of transition, both the protocols will be enabled over the 99 same network infrastructure. Thus, it is reasonable to assume that a 100 mobile node in a Proxy Mobile IPv6 domain may operate in an IPv4-only 101 IPv6-only or in dual-stack mode and additionally the network between 102 the mobile access gateway and a local mobility anchor may be an IPv4 103 or an IPv6 network. It is also reasonable to expect the same 104 mobility infrastructure in a Proxy Mobile IPv6 domain to provide 105 mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode 106 and when the network between the local mobility anchor and the mobile 107 access gateway is an IPv4 or an IPv6 network. The motivation and 108 scope of IPv4 support in Mobile IPv6 is summarized in [RFC-4977] and 109 all those requirements apply to Proxy Mobile IPv6 protocol as well. 111 The Proxy Mobile IPv6 protocol[ID-PMIP6] specifies a mechanism for 112 providing IPv6 home address mobility support to a mobile node in a 113 Proxy Mobile IPv6 domain and when there is an IPv6 transport network 114 separating the entities involved in the mobility management. The 115 extensions defined in this document are for extending IPv4 support to 116 the Proxy Mobile IPv6 protocol [ID-PMIP6]. 118 The scope of IPv4 support in Proxy Mobile IPv6 includes the support 119 for the following two features: 121 o IPv4 Home Address Mobility Support: A mobile node that has an IPv4 122 stack enabled will be able to obtain an IPv4 address and be able 123 to use that address from any of the access networks in that Proxy 124 Mobile IPv6 domain. The mobile node is not required to be 125 allocated or assigned an IPv6 address for enabling IPv4 home 126 address support. 128 o IPv4 Transport Network Support: The mobility entities in the Proxy 129 Mobile IPv6 domain will be able to exchange Proxy Mobile IPv6 130 signaling messages over an IPv4 transport and further the local 131 mobility anchor or the mobile access gateway may be using IPv4 132 private addresses and with NAT [RFC-3022] translation devices 133 separating them. 135 The DSMIPv6 specification [ID-DSMIP6], defines IPv4 home address 136 mobility and IPv4 transport support to the Mobile IPv6 protocol [RFC- 137 3775]. The solution specified in this document leverages some of the 138 options related to IPv4 support and some processing logic for 139 extending IPv4 support to Proxy Mobile IPv6 protocol. These two 140 features, the IPv4 Home Address Mobility support and IPv4 transport 141 support features, are independent of each other and deployments can 142 choose to enable any one or both of these features. 144 Figure 1 illustrates a Proxy Mobile IPv6 domain supporting IPv4 home 145 address mobility and IPv4 transport support features. The mobile 146 nodes MN1, MN2 and MN3 can be operating in IPv4-only, IPv6-only or 147 dual-stack mode, and the transport network between the local mobility 148 anchor and the mobile access gateway may be an IPv6 network or an 149 IPv4 network. Further, when the transport network is IPv4, either 150 the local mobility anchor or the mobile access gateway, or both can 151 be behind a NAT [RFC-3022] translation device and configured with an 152 IPv4 private address. 154 +----+ +----+ 155 |LMA1| |LMA2| 156 +----+ +----+ 157 IPv4-LMAA1 -> | | <-- LMAA2 158 | | 159 \\ //\\ 160 [NAT] // \\ 161 \\ // \\ 162 +---\\------------- //------\\----+ 163 ( \\ IPv4/IPv6 // \\ ) 164 ( \\ Network // \\ ) 165 +------\\--------//------------\\-+ 166 \\ // \\ 167 \\ // \\ 168 \\ // \\ 169 IPv4-Proxy-CoA1--> | | <-- Proxy-CoA2 170 +----+ +----+ 171 |MAG1|-----{MN2} |MAG2| 172 +----+ | +----+ 173 (IPv6 MN-HoA1) | | | <-- (IPv6 MN-HoA2) 174 (IPv4-MN-HoA1) --> | (IPv4-MN-HoA2) | <-- (IPv4-MN-HoA3) 175 {MN1} {MN3} 177 Figure 1: IPv4 support for Proxy Mobile IPv6 179 1.1. Stated Assumptions 181 o This specification requires that the local mobility anchor and the 182 mobile access gateway are both IPv6 capable and IPv6 enabled. 183 Irrespective of the type of transport network (IPv4 or IPv6) 184 separating these two entities (i.e., if the entities are reachable 185 using an IPv4 or IPv6 transport address), the mobility signaling 186 is always based on Proxy Mobile IPv6. 188 o For supporting IPv4/IPv6 home address mobility, the transport 189 network between the local mobility anchor and the mobile access 190 gateway can be an IPv6 network or an IPv4 network. However, for 191 supporting IPv4 transport network feature, as implied, IPv4 192 transport network is required. 194 o The mobile node can be operating in IPv4-only, IPv6-only or in 195 dual mode. If enabled, the mobile node should be able to obtain 196 IPv4-only, IPv6-only or both IPv4 and IPv6 address(es) on its 197 interface. However, the respective protocol(s) support must be 198 enabled on the access link between the mobile node and the mobile 199 access gateway. 201 o There can be support for multiple IPv4 home network prefixes for 202 the mobile node's attached interface. The mobile node should be 203 able to obtain one or more IPv4 addresses from one or all of its 204 IPv4 home network prefixes. Based on the type of link, it may be 205 able to acquire its IPv4 address configuration using DHCP, IPCP, 206 IKEv2 or through other standard address configuration mechanisms. 208 o The mobile node's IPv4 home network prefix is a shared prefix 209 (unlike its IPv6 home network prefix, which is a shared prefix). 210 There can be more than one mobile node sharing address(es) from 211 the same IPv4 home network prefix. 213 o The mobile access gateway is always the IPv4 default-router for 214 the mobile node on its access link. It will always be able to 215 receive traffic sent to the mobile node's IPv4 default-router 216 address. 218 2. Conventions & Terminology 220 2.1. Conventions 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in RFC 2119 [RFC-2119]. 226 2.2. Terminology 228 All the mobility related terms used in this document are to be 229 interpreted as defined in Mobile IPv6 specification [RFC-3775] and 230 Proxy Mobile IPv6 specification [ID-PMIP6]. In addition the document 231 introduces the following terms. 233 IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) 235 The IPv4 address that is configured on the interface of the mobile 236 access gateway and is the transport endpoint of the tunnel between 237 a local mobility anchor and a mobile access gateway. This address 238 will be used as the source address for the signaling messages sent 239 by the mobile access gateway to the local mobility anchor and will 240 be the registered Care-of address in the mobile node's Binding 241 Cache entry. However, when the configured address is a private 242 IPv4 address and with a NAT device in the path to the local 243 mobility anchor, the care-of address as seen by the local mobility 244 anchor will be the address allocated by the NAT device for that 245 flow. 247 IPv4 Local Mobility Anchor Address (IPv4-LMAA) 249 The IPv4 address that is configured on the interface of a local 250 mobility anchor and is the transport endpoint of the tunnel 251 between the local mobility anchor and the mobile access gateway. 252 This is the address to where the mobile access gateway sends the 253 Proxy Binding Update messages when using IPv4 transport. If the 254 local mobility anchor is configured to be behind a NAT device, 255 this address will not be directly configured on the local mobility 256 anchor, but a corresponding mapped private address will be 257 configured on the local mobility anchor. 259 Mobile Node's IPv4 Home Network Prefix (IPv4-MN-HNP) 261 This is the IPv4 prefix from which the mobile node obtains its 262 home address(es). This IPv4 home network prefix is topologically 263 anchored at the mobile node's local mobility anchor. The mobile 264 node configures its interface with address(es) from this prefix. 266 3. IPv4 Home Address Mobility Support 268 An IPv4 enabled mobile node when it attaches to the Proxy Mobile IPv6 269 domain, the network will ensure the mobile node will be able to 270 obtain an IPv4 address (IPv4-MN-HoA) from its home network prefix for 271 the interface attached to the access network in that Proxy Mobile 272 IPv6 domain. Using the extensions defined in this specification, the 273 mobile access gateway on the access network will exchange the 274 signaling messages with the mobile node's local mobility anchor and 275 will setup the required routing state for that home address. 277 If the mobile node connects to the Proxy Mobile IPv6 domain, through 278 multiple interfaces and simultaneously through different access 279 networks, each of the connected interfaces will obtain an address 280 from a unique IPv4 home network prefix. In such configuration, there 281 will be multiple Binding Cache entries on the local mobility anchor 282 for that mobile node and with one entry for each connected interface, 283 as specified in Section 5.4 [ID-PMIP6]. 285 The support for IPv4 addressing is orthogonal to the IPv6 addressing 286 support. Unlike as specified in [ID-DSMIP6], the mobile node is not 287 required to have an IPv6 home address for obtaining IPv4 home address 288 mobility. A mobile node attached to an access link in a Proxy Mobile 289 IPv6 domain will be able to obtain just an IPv4 address configuration 290 or both IPv4 and IPv6 address configurations on the connected 291 interface. The mobile nodes' policy profile will determine if the 292 mobile node is entitled for both the protocols or a single protocol 293 and based on what is enabled, only those protocols will be enabled on 294 the access link. Further, when the mobile node after obtaining the 295 IPv4 or IPv4/IPv6 address configuration on the access link, performs 296 an inter-technology handoff, the network will ensure the mobile node 297 will be able to use the same IPv4/IPv6 address configuration on the 298 new interface. [RYUJI The IPv4 home address MUST be the global IPv4 299 address. A private IPv4 address assignment as an IPv4 home address 300 is prohibited. There is no gurantee to assign the IPv4 private home 301 address which is different from the private address configured at a 302 mobile access gateway.] 304 3.1. IPv4 Home Address Assignment 306 A mobile node on attaching to an access link connected to a mobile 307 access gateway, and if the network allows the mobile node for IPv4 308 home address mobility service, the mobile node using any of the IPv4 309 address configuration procedures, such as DHCP [RFC-2131], IPCP or 310 IKEv2 that are supported on that access link, will be able to obtain 311 required information for its IPv4 home address configuration. The 312 required information includes the IPv4 home address, the IPv4 home 313 network prefix, IPv4 home network prefix length and the IPv4 default 314 router address. 316 When a mobile node is configured with a static IPv4 home address, the 317 IPv4 home address information SHOULD be stored in the mobile node's 318 policy profile. The mobile access gateway where the mobile node 319 attached obtains the static IPv4 home address from the policy 320 profile. The mobile access gateway MUST use either the obtained IPv4 321 home address or the obtained IPv4 home subnet address to initialize 322 the IPv4 Home Address and Pref fields in the IPv4 Home Address option 323 [ID-DSMIP6]. This option is carried by a proxy binding update 324 described in [ID-PMIP6]. 326 On the other hand, if DHCP is used for the IPv4 home address 327 allocation as specified in [RFC-2131], a DHCP server and/or a DHCP 328 relay agent on the link will ensure the mobile node is assigned an 329 IPv4 address from its home network subnet. All the IPv4 home 330 addresses assigned to mobile nodes must be reachable via local 331 mobility anchor so that local mobility anchor intercepts packets 332 meant for an IPv4 home address and tunnels them to the mobile node 333 via corresponding mobile access gateway. There are several 334 configurations where the DHCP entities are located in a Proxy Mobile 335 IPv6 domain. This document recommends following two configurations. 336 The other configurations are explained in Appendix A. 338 1. DHCP server is co-located with each mobile access gateway 340 2. DHCP server is co-located with a local mobility anchor and a DHCP 341 relay is co-located with each mobile access gateway 343 Figure 2 shows the operational sequence of the home address 344 assignment when a DHCP server is co-located with each mobile access 345 gateway. In this scenario, a DHCP server which is also a mobile 346 access gateway interacts with a DHCP client on a mobile node. All 347 mobile access gateways SHOULD support minimal functionality of a DHCP 348 server in order to send DHCP offer and acknowledgment messages to the 349 mobile node in reply to the DHCP discovery and request messages. 350 While the mobile access gateway is seen as a DHCP server from a 351 mobile node, it actually obtains the IPv4 home address for each 352 mobile node from the local mobility anchor during proxy binding 353 procedure (set 0.0.0.0 in the the IPv4 Home Address field of the IPv4 354 home address option as described in [ID-DSMIP6]). After MAG 355 receiving the assigned IPv4 address from LMA, it assigns the address 356 to the requesting mobile node. Note that the mobile access gateway 357 MUST return its own IP address in the 'server identifier' option when 358 sending DHCP messages to the mobile node. Thus, whenever the mobile 359 node changes the attached mobile access gateway, this server 360 identifier must be updated. The detail can be found in 361 Section 3.2.2. The second scenario does not have this server 362 identifier change when a mobile node changes its mobile access 363 gateway. Any information carried in DHCP options such as addresses 364 of domain name server, time server, lpr server, etc. MUST be 365 configured in all the DHCP server located at mobile access gateways 366 if necessary. 368 MN MAG(DHCP-S) LMA 369 |------>| | 1. DHCP discovery 370 | |------->| 2. Proxy Binding Update * 371 | |<-------| 3. Proxy Binding Acknowledgement (IPv4HoA) 372 | |========| 4. Tunnel/Route Setup* 373 |<------| | 5. DHCP offer (IPv4 HoA) 374 |------>| | 6. DHCP request (IPv4 HoA) 375 |<------| | 7. DHCP acknowledgement 376 | | | 377 * DHCP discovery (no.1) and PBU (no.2) are operated in parallel. 378 * Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7) 379 are processed in parallel. 381 Figure 2: An example when LMA assigns an IPv4 home address 383 In the second scenario, a DHCP relay is co-located at each mobile 384 access gateway and a DHCP server is co-located at a local mobility 385 anchor. A mobile access gateway sends a proxy binding update and 386 retrieves an IPv4 home address for the mobile node from the local 387 mobility anchor as described in the first scenario. When the mobile 388 access gateway relays DHCP messages to the DHCP server, it includes 389 the assigned IPv4 home address information in the DHCP messages as a 390 hint. The DHCP server SHOULD assign the address stored in the hint 391 to the mobile node. Figure 3 are the sequence of IPv4 home address 392 assignment using DHCP Relay. The DHCP discovery message is sent by a 393 mobile node at any time, but the DHCP relay SHOULD NOT relay the DHCP 394 discovery message before it learns the IPv4 home address hint during 395 the proxy binding registration. As shown in Figure 3, the DHCP 396 messages MAY be sent across an administrative boundaries. The 397 operators MUST ensure to secure these messages. More remarks can be 398 found in Section 6. The DHCP server identifier remains the same all 399 the time, because the server is uniquely located at the local 400 mobility anchor. 402 MN MAG(DHCP-R) LMA(DHCP-S) 403 | |------->| 1. Proxy Binding Update * 404 | |<-------| 2. Proxy Binding Acknowledgement (IPv4HoA) 405 | |========| 3. Tunnel/Route Setup* 406 |------>|------->| 4. DHCP discovery (IPv4HoA) via DHCP-R 407 |<------|<-------| 5. DHCP offer (IPv4 HoA) via DHCP-R 408 |------>|------->| 6. DHCP request (IPv4 HoA) via DHCP-R 409 |<------|<-------| 7. DHCP acknowledgement via DHCP-R 410 | | | 411 * Tunnel/Route setup(no.3) and DHCP offer/request/ack(no.4-7) 412 are processed in parallel. 414 Figure 3: The use of DHCP relay 416 3.2. Mobile Access Gateway Considerations 418 3.2.1. Extensions to Binding Update List Entry 420 For supporting this feature, the conceptual Binding Update List entry 421 data structure needs to be extended with the following additional 422 fields. 424 o The IPv4 home address of the attached mobile node. This is 425 acquired from the mobile node's local mobility anchor through the 426 received Proxy Binding Acknowledgment message. The IPv4 home 427 address parameter also includes the corresponding subnet mask. 429 o The IPv4 default-router address of the mobile node. This is 430 acquired from the mobile node's local mobility anchor through the 431 received Proxy Binding Acknowledgment messages. 433 3.2.2. Signaling Considerations 435 All the considerations from Section 6.9 of [ID-PMIP6] apply here. 436 However, the following additional considerations MUST be applied. 438 Mobile Node Attachment and Initial Binding Registration: 440 o After detecting a new mobile node on its access link, the mobile 441 access gateway must identify the mobile node and acquire its MN- 442 Identifier. If it determines that the IPv4 home address mobility 443 service needs to be offered to the mobile node [RYUJI by checking 444 the policy profile], it MUST send a Proxy Binding Update message 445 for the IPv4 home address to the local mobility anchor. The 446 message MUST include the IPv4 Home Address option, defined in 447 section 3.1.1 of [ID-DSMIP6]. The mobile access gateway MAY also 448 include the IPv6 Home Network Prefix option in the same message 449 for requesting IPv6 home address support in addition to IPv4 home 450 address support for the mobile node. [RYUJI The mobile access 451 gateway contain either an IPv4 Home Address Option or a Home 452 Network Prefix option, or both, depending on the mobile node's 453 type.] 455 o If the mobile access gateway learns the mobile node's IPv4 home 456 network prefix or the IPv4 home address either from its policy 457 store or from the DHCP messages exchanged between the mobile node 458 and the DHCP server, the mobile access gateway can specify the 459 same in the IPv4 Home Address option for requesting the local 460 mobility anchor to allocate that address or to allocate an address 461 from the specified home network prefix. If the specified value is 462 0.0.0.0, then the local mobility anchor will consider this as a 463 request for dynamic address allocation. 465 o The mobile access gateway on the access link where mobile node is 466 attached, will register this address with the local mobility 467 anchor using the IPv4 Home Address option, defined in Section 468 3.1.1 of [ID-DSMIP6]. The IPv4 Home Address option is sent with a 469 proxy binding update message. The format of the proxy binding 470 update is slightly different from the one of [ID-DSMIP6]. In [ID- 471 DSMIP6], the source address of IPv6 header must be a home address 472 of the mobile terminal. However, since Proxy Mobile IPv6 supports 473 also IPv4-only nodes, IPv6 home address is not always available on 474 the terminal. In addition to this, the originator of this proxy 475 binding update is not the mobile terminal, but the mobile access 476 gateway. The mobile access gateway cannot send the proxy binding 477 update with the mobile node's home address because of security 478 reasons (IPsec and ingress filtering). Therefore, in this 479 specification, the mobile access gateway's care-of address (Proxy- 480 CoA) is used in the IPv6 source address field. 482 o The proxy binding update MUST be protected by IPsec ESP. 484 Receiving Binding Acknowledgement Message: 486 o If the received Proxy Binding Acknowledgement message has neither 487 an IPv4 Address Acknowledgement option or a Home Network Prefix 488 option present, the mobile access gateway MUST ignore the Proxy 489 Binding Acknowledgement and MUST NOT enable routing for the mobile 490 node's IPv4 Home Address or IPv6 home address traffic. However, 491 if there is an IPv4 Home Address Acknowledgment option present in 492 the reply, the option MUST be processed as per the rules specified 493 in Dual Stack Mobile IPv6 specification [ID-DSMIP6]. 495 o If the received Proxy Binding Acknowledgement message has the 496 Status field value in the IPv4 Address Acknowledgement Option set 497 to a value that indicates that the request was rejected by the 498 local mobility anchor, the mobile access gateway MUST NOT enable 499 IPv4 support for the mobile node. However, if there is an IPv6 500 Home Network Prefix option in the Proxy Binding Acknowledgement 501 message and the Status field in the message is set to a value 0 502 (Proxy Binding Update accepted), the mobile access gateway MUST 503 enable IPv6 support for the mobile node. 505 o If the received Proxy Binding Acknowledgement message has the 506 Status field value set to 0 (Proxy Binding Update accepted), the 507 mobile access gateway MUST update a Binding Update List entry and 508 must setup a tunnel to the local mobility anchor and must also add 509 a default route over the tunnel for all the mobile node's IPv4 510 traffic. The encapsulation mode for the bi-directional tunnel set 511 to IPv4-In-IPv6 mode. The considerations from Section 6.10 [ID- 512 PMIP6] apply. 514 Extending Binding Lifetime: 516 o For extending the binding lifetime of a currently registered 517 mobile node , the mobile access gateway MUST send a Proxy Binding 518 Update message to the local mobility anchor with a non zero 519 lifetime value. The message MUST contain the IPv4 Home Address 520 option with the value set to the currently registered IPv4 home 521 address value. Additionally, if there is a registered IPv6 home 522 network prefix for the mobile node for the connected interface on 523 that access link, both the options, Home Network Prefix option and 524 the IPv4 Home Address option MUST be present and with the values 525 set to the respective registered values. 527 Mobile Node Detachment and Binding De-Registration: 529 o As specified in Section 6.9.1 [ID-PMIP6], at any point in time, 530 when the mobile access gateway detects that the mobile node has 531 moved away from its access link, it SHOULD send a Proxy Binding 532 Update message to the local mobility anchor with the lifetime 533 value set to zero. The message MUST contain the IPv4 Home Address 534 option with the value set to the currently registered IPv4 home 535 address value. Additionally, if there is a registered IPv6 home 536 network prefix for the mobile node for the connected interface on 537 that access link, both the options, Home Network Prefix option and 538 the IPv4 Home Address option MUST be present and with the values 539 set to the respective registered values. 541 Constructing the Proxy Binding Update Message: 543 The mobile access gateway when sending the Proxy Binding Update 544 request to the local mobility anchor for requesting IPv4 home address 545 mobility support MUST construct the message with the following 546 considerations. 548 o The message MUST be constructed as specified in Section 6.9 of 549 [ID-PMIP6]. However, when sending the messages over IPv4 550 transport, additional considerations from Section 4.0 MUST be 551 applied. 553 o The IPv4 Home Address option [ID-DSMIP6] MUST be present. The 554 address value MAY be set 0.0.0.0 or to a specific value. 556 DHCP Messages from the mobile node: 558 The operations of DHCP are almost same for both scenarios listed in 559 Section 3.1. There is one special operation for address renewing 560 operation when a mobile access gateway is the DHCP server. 562 o When a mobile node attached to an access link and attempts to 563 obtain an IPv4 address configuration, using DHCP or other 564 procedures, it will get an IPv4 address as an IPv4 home address 565 from its home subnet as discussed in Section 3.1. The mobile 566 access gateway on the access link where mobile node is attached, 567 will register the IPv4 home address with the local mobility anchor 568 using the IPv4 Home Address option, defined in Section 3.1.1 of 569 [ID-DSMIP6]. The IPv4 Home Address option is sent with a proxy 570 binding update. 572 o When a mobile node attempts to obtain an IPv4 home address by 573 using DHCP, the mobile access gateway SHOULD complete the proxy 574 binding registration before starting any DHCP operation. This is 575 necessary for the mobile access gateway to obtain all the 576 information required for DHCP operation from the local mobility 577 anchor. 579 o The mobile access gateway SHOULD send a proxy binding update with 580 0.0.0.0 in the the IPv4 Home Address field of the IPv4 home 581 address option [ID-DSMIP6] and retrieve the assigned IPv4 home 582 address from the local mobility anchor. The IPv4 home address 583 assigned by the local mobility anchor is offered to the mobile 584 node by DHCP. 586 o When a mobile node changes its attached mobile access gateway, the 587 new mobile access gateway MUST sends a proxy binding update with 588 the IPv4 home address option. If the new mobile access gateway 589 know the assigned IPv4 home address, for example by context 590 transfer mechanism or policy profile, it SHOULD include the 591 address in the IPv4 Home Address field. Otherwise, it uses 592 0.0.0.0 and obtains the assigned IPv4 home address of the mobile 593 node from the local mobility anchor, again. 595 o Except for the mobile node's bootstrap, DHCP runs independently to 596 the proxy binding registration, for instance, for renewing the 597 assigned IPv4 home address. It is not necessary to run DHCP 598 whenever a mobile node changes its attached mobile access gateway. 599 A DHCP client renew the address according to the address lifetime, 600 etc. However, whenever a mobile node renews the IPv4 home address 601 by DHCP (DHCP RENEWING STATE [RFC-2131]), the mobile access 602 gateway SHOULD send a proxy binding update to the local mobility 603 anchor regardless of the mobile node's assigned address changes. 605 o When a mobile node gets IPv4 home address from Local Mobility 606 Anchor through DHCP interaction with mobile access gateway that 607 supports DHCP server functionality, the DHCP client in the mobile 608 node recognizes mobile access gateway's IP address as DHCP 609 server's IP address. Thus, the DHCP client unicasts DHCP renew to 610 the mobile access gateway, when the DHCP client goes into the DHCP 611 RENEWING state [RFC-2131]. However, when the mobile node 612 handovers to a new mobile access gateway, the mobile node does not 613 know the link change and the DHCP client would unicast DHCP 614 request to the previous mobile access gateway whose IP address was 615 acquired from DHCP offer. The DHCP client in the mobile node 616 needs to reconfigure its local configuration parameters. The 617 mobile access gateway SHOULD discard any DHCP request message that 618 does not belong to the mobile access gateway itself, so that the 619 mobile node should go into the DHCP REBINDING state and broadcast 620 DHCP discovery message without server identifier. 622 3.3. Local Mobility Anchor Considerations 624 3.3.1. Extensions to Binding Cache Entry 626 For supporting this feature, the conceptual Binding Cache entry data 627 structure needs to be extended with the following additional 628 parameter, as specified in [ID-DSMIP6] specification and is presented 629 here for convenience. 631 o The IPv4 home address of the registered mobile node. The IPv4 632 home address value may have been statically configured in the 633 mobile node's policy profile, it MAY have been assigned by a DHCP 634 server, or it MAY have been dynamically allocated by the local 635 mobility anchor. 637 3.3.2. Signaling Considerations 639 All the considerations explained in Section 5.3 [ID-PMIP6] apply 640 here. For supporting IPv4 home address mobility feature, the 641 following additional considerations MUST be applied. 643 Processing Binding Registrations: 645 o If there is an IPv4 Home Address option present in the request, 646 but if there is no Home Network Prefix option present in the 647 request, the local mobility anchor MUST NOT reject the request as 648 specified in [ID-PMIP6]. At least one of these two options MUST 649 be present. However, if both the options are not present, the 650 local mobility anchor MUST reject the request and send a Proxy 651 Binding Acknowledgement message with Status field set to 652 MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home 653 network prefix option). 655 o The local mobility anchor MUST use the identifier from the Mobile 656 Node Identifier Option [RFC-4283] present in the Proxy Binding 657 Update request and MUST apply multihoming considerations specified 658 in Section 5.4 [ID-PMIP6] and from this section for performing the 659 Binding Cache entry existence test. 661 o If there is no existing Binding Cache entry that matches the 662 request, the local mobility anchor MUST consider this request as 663 an initial binding registration request. If the entry exists, the 664 local mobility anchor MUST consider this request as a binding re- 665 registration request. 667 o The proxy care-of address MUST be retrieved from the source 668 address field of the proxy binding update message. 670 o If the IPv4 Home Address option present in the Proxy Binding 671 Update request has the value of 0.0.0.0, the local mobility anchor 672 MUST allocate an IPv4 home address for the mobile node and send a 673 Proxy Binding Acknowledgement message and including the IPv4 674 Address Acknowledgement option, defined in Section 3.2.1 of [ID- 675 DSMIP6], containing the allocated address value. The specific 676 details on how the local mobility anchor allocates the home 677 address is outside the scope of this document. The local mobility 678 anchor MUST ensure the allocated prefix is not in use by any other 679 mobile node. 681 o If the local mobility anchor is unable to allocate an IPv4 home 682 address for the mobile node, it MUST reject the request and send a 683 Proxy Binding Acknowledgement message with Status field set to 130 684 (Insufficient resources). 686 o Upon accepting the request, the local mobility anchor MUST create 687 a Binding Cache entry for the mobile node. It must set the fields 688 in the Binding Cache entry to the accepted values for that 689 binding. It MUST also establish a bi-directional tunnel to the 690 mobile access gateway, as described in [RFC-2473]. Considerations 691 from Section 5.6 [ID-PMIP6] MUST be applied. The local mobility 692 anchor MUST add an IPv4 host route for that allocated IPv4 home 693 address over the tunnel to the mobile access gateway. 695 Multihoming Considerations: 697 o The multihoming considerations specified in Section 5.4 [ID-PMIP6] 698 allows the local mobility anchor to perform the Binding Cache 699 entry existence test for identifying the mobility session, by 700 using the mobile node identifier, interface identifier and the 701 Home Network Prefix values. When using an IPv4 home address 702 value, instead of the IPv6 home network prefix for matching the 703 Binding Cache entry, all those considerations equally apply for 704 the IPv4 home address as well. 706 o If there is an Home Network Prefix option present in the Proxy 707 Binding Update request and with a NON_ZERO value, the local 708 mobility anchor MUST use this parameter in combination with the 709 mobile node identifier and interface identifier for matching the 710 Binding Cache entry, just as specified in Section 5.4 [ID-PMIP6]. 711 For all other cases, the local mobility anchor MUST use the IPv4 712 home address parameter in combination with the mobile node 713 identifier and interface identifier for matching the Binding Cache 714 entry, as specified in Section 5.4 [ID-PMIP6]. 716 Constructing the Proxy Binding Acknowledgement Message: 718 o The local mobility anchor when sending the Proxy Binding 719 Acknowledgement message to the mobile access gateway MUST 720 construct the message as specified in Proxy Mobile IPv6 base 721 specification [ID-PMIP6]. However, the following considerations 722 MUST be applied. 724 o The IPv4 Address Acknowledgement option MUST be present in the 725 Proxy Binding Acknowledgement message. 727 1. If the Status field is set to a value greater than or equal to 728 128, i.e., if the binding request is rejected, then the IPv4 729 home address value in the IPv4 Address Acknowledgement option 730 MUST be set to ALL_ZERO value. 732 2. For all other cases, the IPv4 home address value in the IPv4 733 Address Acknowledgement option MUST be set to the allocated 734 IPv4 home address value for that mobility session. 736 3.3.3. Routing Considerations 738 Forwarding Considerations for the mobile node's IPv4 home address 739 traffic. 741 Intercepting Packets Sent to the Mobile Node's IPv4 home network: 743 o When the local mobility anchor is serving a mobile node, it MUST 744 be able to receive packets that are sent to the mobile node's IPv4 745 network. In order for it to receive those packets, it MUST 746 advertise a connected route in to the Routing Infrastructure for 747 the mobile node's IPv4 home network prefix or for an aggregated 748 prefix with a larger scope. This essentially enables IPv4 routers 749 in that network to detect the local mobility anchor as the last- 750 hop router for that IPv4 prefix. 752 Forwarding Packets to the Mobile Node: 754 o On receiving a packet from a correspondent node with the 755 destination address matching a mobile node's IPv4 home address, 756 the local mobility anchor MUST forward the packet through the bi- 757 directional tunnel setup for that mobile node. The format of the 758 tunneled packet is shown below. 760 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 761 IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ 762 Upper layer protocols /* Packet Content*/ 764 Figure 4: Tunneled Packets from LMA to MAG 766 Forwarding Packets Sent by the Mobile Node: 768 o All the reverse tunneled packets that the local mobility anchor 769 receives from the mobile access gateway, after removing the tunnel 770 header MUST be routed to the destination specified in the inner 771 IPv4 packet header. These routed packets will have the source 772 address field set to the mobile node's IPv4 home address. 774 3.4. Mobility Options 776 For supporting IPv4 home address mobility feature, this specification 777 defines the following new option. 779 3.4.1. IPv4 Default Router Address Option 781 A new option, IPv4 Default Router Address Option is defined for using 782 it in the Proxy Binding Acknowledgment message sent by the local 783 mobility anchor to the mobile access gateway. This option can be 784 used for sending the mobile node's IPv4 default router address. 786 The IPv4 Default Router Address option has an alignment requirement 787 of 4n. Its format is as follows: 789 0 1 2 3 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Type | Length | Reserved (R) | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | IPv4 Default Router Address | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 Type 798 800 Length 802 8-bit unsigned integer indicating the length of the option in 803 octets, excluding the type and length fields. This field MUST 804 be set to 6. 806 Reserved (R) 808 This 8-bit field is unused for now. The value MUST be 809 initialized to 0 by the sender and MUST be ignored by the 810 receiver. 812 IPv4 Default Router Address 814 A four-byte field containing the mobile node's default router 815 address. 817 Figure 5: IPv4 Default Router Address Option 819 4. IPv4 Transport Support 821 The Proxy Mobile IPv6 specification [ID-PMIP6] requires the network 822 between the local mobility anchor and the mobile access gateway to be 823 an IPv6 network and the signaling messages exchanged between the 824 local mobility anchor and the mobile access gateway to be over an 825 IPv6 transport. The extensions defined in this section allow the 826 exchange of signaling messages over an IPv4 transport when the local 827 mobility anchor and the mobile access gateway are separated by an 828 IPv4 network and are reachable using an IPv4 address. 830 IPv4-Proxy-CoA IPv4-LMAA 831 | + - - - - - - + | 832 +--+ +---+ / \ +---+ +--+ 833 |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| 834 +--+ +---+ \ / +---+ +--+ 835 + - - - - - - + 837 Figure 6: IPv4 Transport Network 839 When the network between the local mobility anchor and the mobile 840 access gateway is an IPv4 network, i.e., when both these mobility 841 entities are configured and reachable using an IPv4 address, the 842 mobile access gateway serving a mobile node can potentially register 843 its IPv4 address with the local mobility anchor, as the care-of 844 address in the mobile node's Binding Cache entry and can negotiate 845 and IPv4 transport tunnel for tunneling the mobile node's data 846 traffic. 848 The Dual Stack Mobile IPv6 specification [ID-DSMIP6] defines protocol 849 extensions to Mobile IPv6 protocol for allowing a mobile node to roam 850 into an IPv4 network and registers an IPv4 care-of address with the 851 home agent. The same mechanism is leveraged for extending IPv4 852 transport support to Proxy Mobile IPv6 protocol. The mobility 853 options for requesting IPv4 transport support, the processing logic 854 and the on-path NAT detection logic is just as described in [ID- 855 DSMIP6]. The following are the key properties of this feature. 857 o The local mobility anchor and the mobile access gateway are both 858 configured and reachable using an IPv4 address. 860 o The configured address on the mobile access gateway can be an IPv4 861 private address and when it is behind a NAT translation device and 862 the mechanism specified in Dual Stack Mobile IPv6 specification 863 [ID-DSMIP6] is again leveraged for NAT detection and traversal. 865 o The Proxy Mobile IPv6 signaling messages exchanged between the 866 local mobility anchor and the mobile access gateway for 867 negotiating the IPv4 transport will be encapsulated and carried as 868 IPv4 packets. However, these signaling messages are fundamentally 869 IPv6 messages with the mobility header and the semantics as 870 specified in base Proxy Mobile IPv6 specification [ID-PMIP6], but 871 carried as payload in IPv4 packets. Additionally, the mobility 872 options defined in Dual Stack Mobile IPv6 specification [ID- 873 DSMIP6] are used for negotiating IPv4 transport support and with a 874 specific encapsulation mode. 876 o The IPv4 tunnel established between the local mobility anchor and 877 the mobile access gateway (with any of the supported encapsulation 878 modes over IPv4 transport) is used for carrying the mobile node's 879 IPv4 and IPv6 traffic. The mobile node can be an IPv6, IPv4 or a 880 dual IPv4/IPv6 node and the IPv4 transport support specified in 881 this section is agnostic to the type of address mobility enabled 882 for the mobile node. 884 4.1. NAT Support 886 When the transport network between the local mobility anchor and the 887 mobile access gateway is an IPv4 network, the mobile access gateway 888 MUST send Proxy Binding Update message encapsulated in the IPv4-UDP 889 packet. On receiving this Proxy Binding Update packet encapsulated 890 in an IPv4-UDP packet, the local mobility anchor if it detects a NAT 891 on the path, will send the Proxy Binding Acknowledgment message with 892 the NAT Detection Option. The presence of this option in the Proxy 893 Binding Acknowledgment is an indication to the mobile access gateway 894 about the presence of NAT in the path. On detecting the NAT in the 895 path, both the local mobility anchor and the mobile access gateway 896 MUST set the encapsulation mode of the tunnel to IPv4-UDP-based 897 encapsulation. The specific details around the NAT detection and the 898 related logic is described in in DSMIPv6 specification [ID-DSMIP6]. 900 There are discussions on how to incorporate the NAT detection 901 mechanism of IKE with DSMIPv6 in the MEXT Working Groups. This 902 documentation will follow the conclusion of their discussions. 904 [RYUJI Private addresses MUST NOT be configured at both mobile access 905 gateways and a local mobility anchor in the same Proxy Mobile IPv6 906 domain. At least one of Proxy Mobile IPv6's tunnel end points MUST 907 have a global address. Otherwise, the packets might not be exchanged 908 in the tunnel due to NAT.] 910 [RYUJI When a mobile access gateway is configured with an IPv4 911 private address, it MUST NOT operate the local routing (described in 912 Section 6.10.3 of [ID-PMIP6]) for packets destined to an IPv4 address 913 assigned to a correspondent node. The address translation MUST 914 happen before the packets are arrived at the correspondent node. To 915 ensure this, the packets MUST be sent to the local mobility anchor 916 and routed back to the correspondent node.] 918 4.2. Mobile Access Gateway Considerations 920 4.2.1. Extensions to Binding Update List Entry 922 For supporting this feature, the conceptual Binding Update List entry 923 data structure needs to be extended with the following additional 924 parameters, as specified in [ID-DSMIP6] specification and is reviewed 925 here for convenience. 927 o The IPv4 address registered with the local mobility anchor as the 928 mobile node's care-of address. 930 4.2.2. Signaling Considerations 932 All the considerations as explained in Section 6.11 of the base Proxy 933 Mobile IPv6 specification apply here. 935 Network Configurations for IPv4 Transport Signaling Support: 937 o If IPv4 transport support is enabled in order to place a mobile 938 access gateway at IPv4 only network, the mobile access gateway 939 MUST have an IPv4 address at the visiting network. In addition to 940 that, the mobile access gateway MUST obtain an IPv6 address 941 configured for the Proxy Mobile IPv6 operation. Even if the 942 mobile access gateway does not have connectivity to the IPv6 943 network, it MUST configure with an IPv6 address for sending the 944 proxy binding registration to the local mobility anchor. 946 Processing Binding Registrations: 948 o As explained in the DSMIPv6 specification, the mobile access 949 gateway can encapsulate a Proxy Binding Update message and carry 950 it in IPv4 and UDP packet. The processing logic for handling the 951 NAT detection at the mobile node is applicable to the mobile 952 access gateway as described in Section 4.1. 954 o An example of proxy binding update sent by mobile access gateway 955 is shown in Figure 7. The source address of the inner IPv6 header 956 MUST set to the IPv6 address assigned to the mobile access gateway 957 and the destination address MUST be the local mobility anchor's 958 IPv6 address (LMAA). This is slightly different from [ID-DSMIP6] 959 . The reason is already mentioned in Section 3.2.2. 961 o The source address of the outer packet MUST be the IPv4-Proxy-CoA 962 and the destination MUST be the local mobility anchor's IPv4 963 address (IPv4-LMAA). 965 o The IPv4-Proxy-CoA MUST be set in the IPv4 Care-of Address option 966 defined in section 3.1.2 of [ID-DSMIP6]. 968 o For the NAT handling, the UDP-based encapsulation MUST be always 969 used for the proxy binding update. The UDP port number is defined 970 in [ID-DSMIP6]. 972 o If the mobile access gateway requested to use the TLV header for 973 the UDP encapsulation, it MUST insert a TLV header after the UDP 974 header and MUST set T flag in the proxy binding update message. 975 The format of the TLV header is defined in section 4.1 of [ID- 976 DSMIP6]. 978 o The proxy binding update MUST be protected by IPsec ESP. The 979 security association for IPv4 addresses of the mobile access 980 gateway and local mobility anchor are pre-established. 982 Constructing the Proxy Binding Update Message: 984 o For requesting IPv4 transport support, the mobile access gateway 985 when sending the Proxy Binding Update request to the local 986 mobility anchor from an IPv4 networks MUST construct the message 987 as specified below. 989 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 990 UDP header 991 IPv6 header (src=Proxy-CoA, dst=LMAA) 992 Mobility header 993 -BU (P flag is set. F/T flags are optional) 994 Mobility Options 995 - The IPv4 Care-of Address option(Mandatory) 996 - 997 - All the options as required by [ID-PMIP6] 998 - or as required by any extension documents 999 - 1001 Figure 7: Proxy Binding Update Message Format for IPv4 Transport 1002 Support 1004 o 1006 o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The 1007 address value MUST be set to mobile access gateway's IPv4 address. 1009 o All the other fields and the options MUST be constructed, as 1010 specified in [ID-PMIP6]. 1012 Receiving Binding Registration Reply: 1014 o After receiving a Proxy Binding Acknowledgment message 1015 encapsulated in an IPv4 packet, the mobile access gateway MUST 1016 verify the Proxy Binding Acknowledgment according to the Section 1017 4.3 of Dual Stack Mobile IPv6 specification [ID-DSMIP6]. 1019 o If the Status field indicates Success, the mobile access gateway 1020 MUST setup a tunnel to the local mobility anchor and add a default 1021 route over the tunnel for all the mobile node's traffic. 1023 o If the NAT is available and the NAT detection option is presented 1024 in the Proxy Binding Acknowledgment, the mobile access gateway 1025 MUST use the UDP tunnel to traverse the NAT for mobile node's 1026 traffic and MUST send a proxy binding update every refresh time 1027 specified in the NAT detection option. The detailed operation can 1028 be found in Dual Stack Mobile IPv6 specification [ID-DSMIP6]. 1030 o If the Status field in the proxy binding acknowledgment indicates 1031 the rejection of the binding registration, the mobile access 1032 gateway MUST NOT enable IPv4 transport for the mobile node's 1033 traffic. 1035 Forwarding Packets to Local Mobility Anchor 1037 o On receiving any packets from the mobile node's IPv6 home address 1038 and/or IPv4 home address, the mobile access gateway tunnels the 1039 packets to local mobility anchor as shown in Figure 8. If the 1040 mobile access gateway and the local mobility anchor agreed to use 1041 the TLV header for the UDP tunnel during the binding registration, 1042 the TLV header MUST be presented after the UDP header as shown in 1043 Figure 9. 1045 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1046 [UDP header] /*Only if NAT is detected*/ 1047 union { /*following either v6 or v4 header */ 1048 IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN) 1049 IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN) 1050 } 1051 Upper layer protocols /*TCP,UDP,SCTP*/ 1053 Figure 8: Tunneled Packets from MAG to LMA 1055 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1056 UDP header 1057 TLV header 1058 union { 1059 IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN) 1060 IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN) 1061 IPsec 1062 GRE 1063 } 1064 Upper layer protocols /*TCP,UDP,SCTP*/ 1066 Figure 9: Tunneled Packets from MAG to LMA using the TLV header 1068 4.3. Local Mobility Anchor Considerations 1070 4.3.1. Extensions to Binding Cache Entry 1072 For supporting this feature, the conceptual Binding Cache entry data 1073 structure needs to be extended with the following additional 1074 parameter as specified in [ID-DSMIP6] specification and are reviewed 1075 here for convenience. 1077 o The IPv4 Care-of address of the attached mobile node. In this 1078 specification, it can be translated to IPv4 Care-of address of the 1079 mobile access gateway to which a mobile node is attached. 1081 4.3.2. Signaling Considerations 1083 When a mobile node is attached to a mobile access gateway that is 1084 reachable only through an IPv4 transport network, the local mobility 1085 anchor must establish an IPv4 tunnel for routing the mobile node's 1086 IPv4 and IPv6 home address traffic. The DSMIPv6 specification 1087 provides the semantics on how the IPv4 tunnel needs to be negotiated 1088 and the detection logic of the NAT devices. This specification 1089 leverages the NAT Detection Option, defined in the Dual Stack Mobile 1090 IPv6 specification for the use in Binding Acknowledgment message and 1091 extends it to Proxy Binding Acknowledgment messages. The operational 1092 steps are defined below. 1094 Processing Binding Registrations: 1096 o After accepting the registration from the mobile access gateway 1097 locating at the IPv4 only network, the local mobility anchor MUST 1098 setup a tunnel to the mobile access gateway. The tunnel is 1099 established between the v4-LMAA and the IPv4-Proxy-CoA of the 1100 mobile access gateway. 1102 o If the NAT is available, the local mobility anchor MUST use UDP 1103 encapsulation for the tunnel. 1105 o If the T flag is set in the proxy binding update message and the 1106 TLV header is presented, the specified tunnel type must be used. 1108 o The local mobility anchor also setup a host routes for the IPv4 1109 home address and the IPv6 home address of the mobile node over the 1110 tunnel to the mobile access gateway. Any traffic that the local 1111 mobility anchor receives from a correspondent node will be 1112 tunneled to the mobile access gateway over the bi-directional 1113 tunnel and then routed accordingly after removing the tunnel 1114 headers. The encapsulation modes for the bi-directional tunnel 1115 are as specified in Section 5.3 of Proxy Mobile IPv6 specification 1116 [ID-PMIP6] and as in this specification. 1118 o Upon receiving a Proxy Binding Update message encapsulated in an 1119 IPv4 packet, the local mobility anchor MUST send the Proxy Binding 1120 Acknowledgment to the mobile access gateway's IPv4-Proxy-CoA by 1121 using IPv4 encapsulation. 1123 o If the NAT is detected, the NAT detection option MUST be used in 1124 the Proxy Binding Acknowledgment. How to detect NAT is described 1125 in Section 4.1 of [ID-DSMIP6] and Section 4.1. 1127 Constructing the Proxy Binding Acknowledgement Message: 1129 o The proxy binding acknowledgment MUST be protected by IPsec ESP. 1130 The security association for IPv4 addresses of the mobile access 1131 gateway and local mobility anchor are pre-established. 1133 o For the IPv4 transport support, no special mobility options are 1134 required. Only when NAT is detected, the NAT detection option 1135 MUST be present. The local mobility anchor MUST construct the 1136 proxy binding Acknowledgement as specified in [ID-PMIP6]. 1138 o An example of proxy binding acknowledgment sent by local mobility 1139 anchor is shown below. The same illustration for Mobile IPv6 can 1140 be found in Section 4.1 of [ID-DSMIP6]. 1142 IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) 1143 UDP header 1144 [TLV-header] /* optional, if T flag is set */ 1145 IPv6 header (src=LMAA, dst=Proxy-CoA) 1146 Mobility header 1147 -BA /* P flag/T flag(option) */ 1148 Mobility Options 1149 - Home Network Prefix Option 1150 - IPv4 Address Acknowledgement option 1151 - Timestamp option (optional) 1152 - Mobile Node Identifier Option 1153 - Access Technology Type option (Mandatory) 1154 - Mobile Node Interface Identifier option 1155 (Optional) 1157 - NAT Detection Option (Optional) 1159 Figure 10: Proxy Binding Acknowledgment in IPv4 network 1161 Forwarding Packets to Mobile Access Gateway 1163 o When sending any packets meant to a mobile node's IPv4 home 1164 address or IPv6 home address, the local mobility anchor tunnels 1165 the packet to mobile access gateway as shown in Figure 11. 1167 IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) 1168 [UDP header] /*Only if NAT is detected*/ 1169 union { /*following either v6 or v4 header */ 1170 IPv4 header (src=IPv4-CN, dst=IPv4-HoA) 1171 IPv6 header (src=IPv6-CN, dst=IPv6-HoA) 1172 } 1173 Upper layer protocols /*TCP,UDP,SCTP*/ 1175 Figure 11: Tunneled Packets from LMA to MAG 1177 o If the mobile access gateway and the local mobility anchor agreed 1178 to use the TLV header for the UDP tunnel during the binding 1179 registration, the TLV header MUST be presented after the UDP 1180 header as shown in Figure 12. 1182 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1183 UDP header 1184 TLV header 1185 union { 1186 IPv4 header (src=IPv4-CN, dst=IPv4-HoA) 1187 IPv6 header (src=IPv6-CN, dst=IPv6-HoA) 1188 IPsec 1189 GRE 1190 } 1191 Upper layer protocols /*TCP,UDP,SCTP*/ 1193 Figure 12: Tunneled Packets from LMA to MAG using the TLV header 1195 4.4. Tunnel Management 1197 As specified in the Proxy Mobile IPv6 specification, the bi- 1198 directional tunnel between the local mobility anchor and the mobile 1199 access gateway, is a shared tunnel and all the considerations from 1200 Section 6.6 of Proxy Mobile IPv6 [ID-PMIP6] apply for IPv4 transport 1201 as well. 1203 5. IANA Considerations 1205 This document does not require IANA Action. 1207 6. Security Considerations 1209 The security mechanisms specified for Proxy Mobile IPv6 protocol are 1210 used when using the extensions defined in this document. 1212 When supporting IPv4 address assignment from a DHCP server, all the 1213 IPv4 home addresses managed in the DHCP server must be reachable via 1214 local mobility anchor so that local mobility anchor intercepts 1215 packets meant for an IPv4 home address and tunnels them to the mobile 1216 node via corresponding mobile access gateway. Moreover, all the DHCP 1217 messages between a DHCP relay and the DHCP server SHOULD be securely 1218 exchanged. 1220 After receiving a Proxy Binding Update message with an IPv4 Home 1221 Address Option, the local mobility anchor MUST be able to verify that 1222 the mobile node is authorized to use that address before setting up 1223 forwarding for that host route. 1225 When supporting dynamic IPv4 address assignment by DHCP and also from 1226 local mobility anchor, it should be ensured both the entities are 1227 configured with different address pools, so as to avoid both entities 1228 do not allocate the same address to different mobile nodes. 1230 This specification describes the use of IPv4 transport network 1231 between the local mobility anchor and the mobile access gateway. All 1232 the signaling messages exchanged between the mobile access gateway 1233 and the local mobility anchor over the IPv4 transport MUST be 1234 protected using IPsec, just as the messages must be protected when 1235 using IPv6 transport and as specified in the Section 4.0, of the 1236 Proxy Mobile IPv6 specification [ID-PMIP6]. 1238 7. Contributors 1240 This document reflects discussions and contributions from several 1241 people (in alphabetical order): 1243 Kuntal Chowdhury 1245 kchowdhury@starentnetworks.com 1247 Vijay Devarapalli 1249 vijay.devarapalli@azairenet.com 1251 Sangjin Jeong 1253 sjjeong@etri.re.kr 1255 Basavaraj Patil 1257 basavaraj.patil@nsn.com 1259 Myungki Shin 1261 myungki.shin@gmail.com 1263 8. Acknowledgments 1265 The IPv4 support for Proxy Mobile IPv6 was initially covered in the 1266 internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. This document 1267 leverages lot of text from that document. We would like to thank all 1268 the authors of the document and acknowledge that initial work. 1270 9. References 1272 9.1. Normative References 1274 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1275 Requirement Levels", BCP 14, RFC 2119, March 1997. 1277 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1278 2131, March 1997. 1280 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1281 IPv6 Specification", RFC 2473, December 1998. 1283 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1284 IPv6", RFC 3775, June 2004. 1286 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1287 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 1288 November 2005. 1290 [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack 1291 Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-05.txt 1292 ,July 2007. 1294 [ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6", 1295 draft-ietf-netlmm-proxymip6-16.txt, November 2007. 1297 9.2. Informative References 1299 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1300 2131, March 1997. 1302 [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1303 Address Translator (Traditional NAT)", RFC 3022, January 2001. 1305 [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack 1306 Mobility", RFC 4977, August 2007. 1308 Appendix A. DHCP usages for IPv4 home address assignment 1310 There are several other configurations of DHCP entities [RFC-2131] in 1311 a Proxy Mobile IPv6 domain other than the two configurations listed 1312 in Section 3.1. Although this specification recommends the two 1313 configurations described in Section 3.1, operators should select the 1314 best configuration according to their deployments scenario. The 1315 mobile node behavior for all scenarios does not change. We do not 1316 have major interoperability concerns between multiple scenarios. A 1317 mobile access gateway and local mobility anchor make sure that which 1318 scenario is used in the same Proxy Mobile IPv6 domain based on 1319 deployment requirements. The optional DHCP configurations for IPv4 1320 home address assignment are described below. 1322 o DHCP relay is co-located with each mobile access gateway and DHCP 1323 server is solely located in the Proxy Mobile IPv6 domain. 1325 o DHCP relay is co-located with both each mobile access gateway and 1326 a local mobility anchor. DHCP server is solely located behind the 1327 local mobility anchor in the Proxy Mobile IPv6 domain. 1329 The operations are same as described in Section 3.1. Before relaying 1330 any DHCP messages, a mobile access gateway　SHOULD complete the 1331 proxy binding registration so that it learns the assigned address to 1332 provide the IPv4 home address hint to the DHCP server. However, when 1333 DHCP relays are located at both a mobile access gateway and a local 1334 mobility anchor, the DHCP relay at the local mobility anchor can 1335 simply insert the address hint retrieved from its local address 1336 management pool in the DHCP messages. Thus, the IPv4 home address 1337 option [ID-DSMIP6] can be omitted from the Proxy Binding Update and 1338 Acknowledgement messages. 1340 Authors' Addresses 1342 Ryuji Wakikawa 1343 Keio University 1344 Department of Environmental Information, Keio University. 1345 5322 Endo 1346 Fujisawa, Kanagawa 252-8520 1347 Japan 1349 Email: ryuji@sfc.wide.ad.jp 1351 Sri Gundavelli 1352 Cisco 1353 170 West Tasman Drive 1354 San Jose, CA 95134 1355 USA 1357 Email: sgundave@cisco.com 1359 Full Copyright Statement 1361 Copyright (C) The IETF Trust (2008). 1363 This document is subject to the rights, licenses and restrictions 1364 contained in BCP 78, and except as set forth therein, the authors 1365 retain all their rights. 1367 This document and the information contained herein are provided on an 1368 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1369 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1370 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1371 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1372 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1373 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1375 Intellectual Property 1377 The IETF takes no position regarding the validity or scope of any 1378 Intellectual Property Rights or other rights that might be claimed to 1379 pertain to the implementation or use of the technology described in 1380 this document or the extent to which any license under such rights 1381 might or might not be available; nor does it represent that it has 1382 made any independent effort to identify any such rights. Information 1383 on the procedures with respect to rights in RFC documents can be 1384 found in BCP 78 and BCP 79. 1386 Copies of IPR disclosures made to the IETF Secretariat and any 1387 assurances of licenses to be made available, or the result of an 1388 attempt made to obtain a general license or permission for the use of 1389 such proprietary rights by implementers or users of this 1390 specification can be obtained from the IETF on-line IPR repository at 1391 http://www.ietf.org/ipr. 1393 The IETF invites any interested party to bring to its attention any 1394 copyrights, patents or patent applications, or other proprietary 1395 rights that may cover technology that may be required to implement 1396 this standard. Please address the information to the IETF at 1397 ietf-ipr@ietf.org. 1399 Acknowledgment 1401 Funding for the RFC Editor function is provided by the IETF 1402 Administrative Support Activity (IASA).