idnits 2.17.1 draft-ietf-netlmm-pmip6-ipv4-support-02.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 1322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1346. 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 (November 19, 2007) is 6002 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 171, but not defined == Missing Reference: 'TLV-header' is mentioned on line 1047, 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-07 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: May 22, 2008 Cisco 6 November 19, 2007 8 IPv4 Support for Proxy Mobile IPv6 9 draft-ietf-netlmm-pmip6-ipv4-support-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 22, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 IPv4 transport. The solution 47 leverages the extensions defined in DSMIPv6 specification for 48 achieving this. 50 Table of Contents 52 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 6 55 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 7 59 3.1. IPv4 Home Address Assignment . . . . . . . . . . . . . . . 7 60 3.2. Mobile Access Gateway Considerations . . . . . . . . . . . 10 61 3.2.1. Extensions to Binding Update List Entry . . . . . . . 10 62 3.2.2. Signaling Considerations . . . . . . . . . . . . . . . 10 63 3.3. Local Mobility Anchor Considerations . . . . . . . . . . . 14 64 3.3.1. Extensions to Binding Cache Entry . . . . . . . . . . 14 65 3.3.2. Signaling Considerations . . . . . . . . . . . . . . . 15 66 3.3.3. Routing Considerations . . . . . . . . . . . . . . . . 17 68 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 19 69 4.1. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 20 70 4.2. Mobile Access Gateway Considerations . . . . . . . . . . . 20 71 4.2.1. Extensions to Binding Update List Entry . . . . . . . 20 72 4.2.2. Signaling Considerations . . . . . . . . . . . . . . . 20 73 4.3. Local Mobility Anchor Considerations . . . . . . . . . . . 24 74 4.3.1. Extensions to Binding Cache Entry . . . . . . . . . . 24 75 4.3.2. Signaling Considerations . . . . . . . . . . . . . . . 24 76 4.4. Tunnel Management . . . . . . . . . . . . . . . . . . . . 26 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 30 90 Appendix A. DHCP usages for IPv4 home address assignment . . . . 31 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 93 Intellectual Property and Copyright Statements . . . . . . . . . . 34 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 only network. It is also reasonable to expect the same mobility 104 infrastructure in a Proxy Mobile IPv6 domain to provide mobility to 105 the mobile node's operating in IPv4, IPv6 or in dual mode and when 106 the network between the local mobility anchor and the mobile access 107 gateway is an IPv4 network. The motivation and scope of IPv4 support 108 in Mobile IPv6 is summarized in [RFC-4977]. 110 The Proxy Mobile IPv6 protocol[ID-PMIP6] specifies a mechanism for 111 providing IPv6 home address mobility support to a mobile node in a 112 Proxy Mobile IPv6 domain and when there is an IPv6 transport network 113 separating the entities involved in the mobility management. The 114 extensions defined in this document are for extending IPv4 support to 115 the Proxy Mobile IPv6 protocol [ID-PMIP6]. 117 The scope of IPv4 support in Proxy Mobile IPv6 includes the support 118 for the following two features: 120 o IPv4 Home Address Mobility Support: A mobile node that has IPv4 121 stack enabled will be able to obtain an IPv4 address and be able 122 to use that address from any of the access networks in that Proxy 123 Mobile IPv6 domain. The mobile node is not required to be 124 allocated or assigned an IPv6 address for enabling IPv4 home 125 address support. 127 o IPv4 Transport Support: The mobility entities in the Proxy Mobile 128 IPv6 domain will be able to exchange Proxy Mobile IPv6 signaling 129 messages over an IPv4 transport and further the local mobility 130 anchor or the mobile access gateway may be using IPv4 private 131 addresses and with NAT [RFC-3022] translation devices separating 132 them. 134 The DSMIPv6 specification [ID-DSMIP6], defines IPv4 home address 135 mobility and IPv4 transport support to the Mobile IPv6 protocol [RFC- 136 3775]. The solution specified in this document leverages these 137 extensions for enabling IPv4 support to Proxy Mobile IPv6 protocol. 138 These two features, the IPv4 Home Address Mobility support and IPv4 139 transport support features, are independent of each other and 140 deployments can choose to enable any one or both of these features. 142 This specification requires that the local mobility anchor and the 143 mobile access gateway are both IPv6 capable and IPv6 enabled, 144 irrespective of the type of transport network (IPv4 or IPv6), 145 connecting these two entities. The signaling protocol is 146 fundamentally based on Mobile IPv6. 148 Figure 1 illustrates a Proxy Mobile IPv6 domain supporting IPv4 home 149 address mobility and IPv4 transport support features. The mobile 150 nodes MN1, MN2 and MN3 can be operating in IPv4-only, IPv6-only or 151 dual-stack mode, and the transport network between the local mobility 152 anchor and the mobile access gateway may be an IPv6 network or an 153 IPv4 network. Further, when the transport network is IPv4, either 154 the local mobility anchor or the mobile access gateway, or both can 155 be behind a NAT [RFC-3022] translation device and configured with an 156 IPv4 private address. 158 +----+ +----+ 159 |LMA1| |LMA2| 160 +----+ +----+ 161 IPv4-LMAA1 -> | | <-- IPv4-LMAA2 162 | | 163 \\ //\\ 164 [NAT] // \\ 165 \\ // \\ 166 +---\\------------- //------\\----+ 167 ( \\ IPv4/IPv6 // \\ ) 168 ( \\ Network // \\ ) 169 +------\\--------//------------\\-+ 170 \\ // \\ 171 \\ // [NAT] 172 \\ // \\ 173 IPv4-Proxy-CoA1--> | | <-- IPv4-Proxy-CoA2 174 +----+ +----+ 175 |MAG1|-----{MN2} |MAG2| 176 +----+ | +----+ 177 | | | 178 IPv4-MN-HoA1 --> | IPv4-MN-HoA2 | <-- IPv4-MN-HoA3 179 {MN1} {MN3} 181 Figure 1: IPv4 support for Proxy Mobile IPv6 183 2. Conventions & Terminology 185 2.1. Conventions 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in RFC 2119 [RFC-2119]. 191 2.2. Terminology 193 All the mobility related terms used in this document are to be 194 interpreted as defined in Mobile IPv6 specification [RFC-3775], Dual 195 Stack Mobile IPv6 specification [ID-DSMIP6] and Proxy Mobile IPv6 196 specification [ID-PMIP6]. In addition the document introduces the 197 following terms. 199 IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) 201 The IPv4 address that is configured on the interface of the mobile 202 access gateway and is the transport endpoint of the tunnel between 203 a local mobility anchor and a mobile access gateway. This address 204 will be used as the source address for the signaling messages sent 205 by the mobile access gateway to the local mobility anchor and will 206 be the registered Care-of address in the mobile node's Binding 207 Cache entry. However, when the configured address is a private 208 IPv4 address and with a NAT device in the path to the local 209 mobility anchor, the care-of address as seen by the local mobility 210 anchor will be the address allocated by the NAT device for that 211 flow. 213 IPv4 Local Mobility Anchor Address (IPv4-LMAA) 215 The IPv4 address that is configured on the interface of a local 216 mobility anchor and is the transport endpoint of the tunnel 217 between the local mobility anchor and the mobile access gateway. 218 This is the address to where the mobile access gateway sends the 219 Proxy Binding Update messages. If the local mobility anchor is 220 configured to be behind a NAT device, this address will be the 221 address allocated by the NAT device for that flow. 223 3. IPv4 Home Address Mobility Support 225 An IPv4 enabled mobile node when it attaches to the Proxy Mobile IPv6 226 domain, the network will ensure the mobile node will be able to 227 obtain an IPv4 address (IPv4-MN-HoA) from its home network prefix for 228 the interface attached to the access network in that Proxy Mobile 229 IPv6 domain. Using the extensions defined in this specification, the 230 mobile access gateway on the access network will exchange the 231 signaling messages with the mobile node's local mobility anchor and 232 will setup the required routing state for that home address. 234 If the mobile node connects to the Proxy Mobile IPv6 domain, through 235 multiple interfaces and simultaneously through different access 236 networks, each of the connected interfaces will obtain an address 237 from a unique IPv4 home network prefix. In such configuration, there 238 will be multiple Binding Cache entries on the local mobility anchor 239 for that mobile node and with one entry for each connected interface, 240 as specified in Section 5.4 [ID-PMIP6]. 242 The support for IPv4 addressing is orthogonal to the IPv6 addressing 243 support. Unlike as specified in [ID-DSMIP6], the mobile node is not 244 required to have an IPv6 home address for obtaining IPv4 home address 245 mobility. A mobile node attached to an access link in a Proxy Mobile 246 IPv6 domain will be able to obtain just an IPv4 address configuration 247 or both IPv4 and IPv6 address configurations on the connected 248 interface. The policy on the mobile access gateway will determine if 249 the mobile node is entitled for both the protocols or a single 250 protocol and based on what is enabled, only those protocols will be 251 enabled on the access link. Further, when the mobile node after 252 obtaining the IPv4 or IPv4/IPv6 address configuration on the access 253 link, performs an inter-technology handoff, the network will ensure 254 the mobile node will be able to use the same IPv4/IPv6 address 255 configuration on the new interface. 257 3.1. IPv4 Home Address Assignment 259 A mobile node on attaching to an access link connected to a mobile 260 access gateway, and if the network allows the mobile node for IPv4 261 home address mobility service, the mobile node using any of the IPv4 262 address configuration procedures, such as DHCP [RFC-2131], IPCP or 263 IKEv2 that are supported on that access link, will be able to obtain 264 required information for its IPv4 home address configuration. The 265 required information includes the IPv4 home address, the IPv4 home 266 network prefix and IPv4 home network prefix length. Any available 267 IPv4 address configuration mechanisms can be used such as static 268 configuration method specific to the access link or dynamic 269 configuration from DHCP. 271 When a mobile node is configured with a static IPv4 home address, the 272 IPv4 home address information SHOULD be stored in the mobile node's 273 policy profile. The mobile access gateway where the mobile node 274 attached obtains the static IPv4 home address from the policy 275 profile. The mobile access gateway MUST set the known IPv4 home 276 prefix to the IPv4 Home Address field and the Pref field of the IPv4 277 home address option [ID-DSMIP6]. This option is carried by a proxy 278 binding update described in [ID-PMIP6]. 280 On the other hand, if DHCP is used for the IPv4 home address 281 allocation as specified in [RFC-2131], a DHCP server and/or a DHCP 282 relay agent on the link will ensure the mobile node is assigned an 283 address from its home network prefix. There are several 284 configurations where the DHCP entities are located in a Proxy Mobile 285 IPv6 domain. This document recommends following two configurations 286 as default operations. The other configurations are explained in 287 Appendix A. 289 1. DHCP server is co-located with each mobile access gateway 291 2. DHCP server is co-located with a local mobility anchor and a DHCP 292 relay is co-located with each mobile access gateway 294 Figure 2 shows the operational sequence of the home address 295 assignment when a DHCP server is co-located with each mobile access 296 gateway. In this scenario, a DHCP server (i.e. mobile access 297 gateway) interacts with a DHCP client on a mobile node, while a local 298 mobility anchor actually provides an IPv4 Home Address dynamically to 299 a mobile node during proxy binding registration. All mobile access 300 gateways SHOULD support minimal functionality of a DHCP server in 301 order to send DHCP offer and acknowledgment messages to the mobile 302 node in reply to the DHCP discovery and request messages. The mobile 303 access gateway is seen as a DHCP server from a mobile node, but it 304 actually obtains the IPv4 home address for each mobile node from the 305 local mobility anchor during proxy binding procedure (set 0.0.0.0 in 306 the the IPv4 Home Address field of the IPv4 home address option as 307 described in [ID-DSMIP6]). The mobile access gateway MUST return its 308 own IP address in the 'server identifier' option when sending DHCP 309 offer message to the mobile node. Thus, whenever the mobile node 310 changes the attached mobile access gateway, this server identifier 311 must be updated. The detail can be found in Section 3.2.2. Any 312 information carried in DHCP options such as addresses of domain name 313 server, time server, lpr server, etc. MUST be configured in all the 314 mobile access gateway (i.e. DHCP server) if necessary. 316 MN MAG(DHCP-S) LMA 317 |------>| | 1. DHCP discovery 318 | |------->| 2. Proxy Binding Update 319 | |<-------| 3. Proxy Binding Acknowledgement (IPv4HoA) 320 | |========| 4. Tunnel/Route Setup* 321 |<------| | 5. DHCP offer (IPv4 HoA) 322 |------>| | 6. DHCP request (IPv4 HoA) 323 |<------| | 7. DHCP acknowledgement 324 | | | 325 * Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7) 326 are processed in parallel. 328 Figure 2: An example when LMA assigns an IPv4 home address 330 In the second scenario, a DHCP relay is co-located at each mobile 331 access gateway and a DHCP server is co-located at a local mobility 332 anchor. The mobile access gateway learns the IPv4 home address from 333 the DHCP reply and sends that information to the mobile node by DHCP 334 offer message. Meanwhile, it notifies the assigned IPv4 home address 335 by an IPv4 home address option in a proxy binding update to the local 336 mobility anchor. In this case, the local mobility anchor does not 337 allocate any address, but only deals with route setup and tunnel 338 setup for the requested home address. Note that all the IPv4 home 339 addresses managed in the DHCP server must be reachable via local 340 mobility anchor so that local mobility anchor intercepts packets 341 meant for an IPv4 home address and tunnels them to the mobile node 342 via corresponding mobile access gateway. In addition, the DHCP 343 messages MAY be sent across an administrative boundaries. The 344 operators MUST ensure to secure these messages. More remarks can be 345 found in Section 6. Figure 3 are the sequence of IPv4 home address 346 assignment using DHCP Relay. 348 MN MAG(DHCP-R) LMA(DHCP-S) 349 |------>|------->| 1. DHCP discovery to DHCP-S through DHCP-R 350 |<------|<-------| 2. DHCP offer (IPv4 HoA) 351 |------>|------->| 3. DHCP request (IPv4 HoA) 352 | |<-------| 4. DHCP acknowledgement 353 | |------->| 5. Proxy Binding Update 354 | |<-------| 6. Proxy Binding Acknowledgement 355 | |========| 7. Tunnel/Route Setup 356 |<------| | 8. DHCP acknowledgement 357 | | | 359 Figure 3: The use of DHCP relay 361 3.2. Mobile Access Gateway Considerations 363 3.2.1. Extensions to Binding Update List Entry 365 For supporting this feature, the conceptual Binding Update List entry 366 data structure needs to be extended with the following additional 367 parameter, as specified in [ID-DSMIP6] specification and are 368 presented here for convenience. 370 o The IPv4 home address of the attached mobile node. The IPv4 home 371 address value is acquired from the mobile node's local mobility 372 anchor through the received Proxy Binding Acknowledgment messages. 374 3.2.2. Signaling Considerations 376 All the considerations explained in Section 6.11 of the base Proxy 377 Mobile IPv6 specification apply here. For supporting IPv4 home 378 address mobility feature, the following additional considerations 379 MUST be applied. 381 Mobile Node Attachment and Initial Binding Registration: 383 o After detecting a new mobile node on its access link, the mobile 384 access gateway must identify the mobile node and acquire its MN- 385 Identifier. If it determines that the IPv4 home address mobility 386 service needs to be offered to the mobile node, it MUST send a 387 Proxy Binding Update message to the local mobility anchor. The 388 message MUST include the IPv4 Home Address option, defined in 389 section 3.1.1 of [ID-DSMIP6]. The mobile access gateway MAY also 390 include the IPv6 Home Network Prefix option in the same message 391 for requesting IPv6 home address support in addition to IPv4 home 392 address support for the mobile node. 394 o If the mobile access gateway learns the mobile node's IPv4 home 395 network prefix or the IPv4 home address either from its policy 396 store or from the DHCP messages exchanged between the mobile node 397 and the DHCP server, the mobile access gateway can specify the 398 same in the IPv4 Home Address option for requesting the local 399 mobility anchor to allocate that address or to allocate an address 400 from the specified home network prefix. If the specified value is 401 0.0.0.0, then the local mobility anchor will consider this as a 402 request for dynamic address allocation. 404 o The mobile access gateway on the access link where mobile node is 405 attached, will register this address with the local mobility 406 anchor using the IPv4 Home Address option, defined in Section 407 3.1.1 of [ID-DSMIP6]. The IPv4 Home Address option is sent with a 408 proxy binding update as shown in Figure 4. The format of the 409 proxy binding update is slightly different from the one of [ID- 410 DSMIP6]. In [ID-DSMIP6], the source address of IPv6 header must 411 be a home address of the mobile terminal. However, since Proxy 412 Mobile IPv6 supports only IPv4 capable node, IPv6 home address is 413 not always available on the terminal. In addition to this, the 414 originator of this proxy binding update is not the mobile 415 terminal, but the mobile access gateway. The mobile access 416 gateway cannot send the proxy binding update with the mobile 417 node's home address because of security reasons (IPsec and ingress 418 filtering). Therefore, in this specification, the mobile access 419 gateway's care-of address (Proxy-CoA) is used in the IPv6 source 420 address field. 422 o The proxy binding update MUST be protected by IPsec ESP. 424 Receiving Binding Registration Reply: 426 o If the received Proxy Binding Acknowledgement message has neither 427 an IPv4 Address Acknowledgement option or a Home Network Prefix 428 option present, the mobile access gateway MUST ignore the Proxy 429 Binding Acknowledgement and MUST NOT enable routing for the mobile 430 node's IPv4 Home Address or IPv6 home address traffic. However, 431 if there is an IPv4 Home Address Acknowledgment option present in 432 the reply, the option MUST be processed as per the rules specified 433 in Dual Stack Mobile IPv6 specification [ID-DSMIP6]. 435 o If the received Proxy Binding Acknowledgement message has the 436 Status field value in the IPv4 Address Acknowledgement Option set 437 to a value that indicates that the request was rejected by the 438 local mobility anchor, the mobile access gateway MUST NOT enable 439 IPv4 support for the mobile node. However, if there is an IPv6 440 Home Network Prefix option in the Proxy Binding Acknowledgement 441 message and the Status field in the message is set to a value 0 442 (Proxy Binding Update accepted), the mobile access gateway MUST 443 enable IPv6 support for the mobile node. 445 o If the received Proxy Binding Acknowledgement message has the 446 Status field value set to 0 (Proxy Binding Update accepted), the 447 mobile access gateway MUST update a Binding Update List entry and 448 must setup a tunnel to the local mobility anchor and must also add 449 a default route over the tunnel for all the mobile node's IPv4 450 traffic. The encapsulation mode for the bi-directional tunnel set 451 to IPv4-In-IPv6 mode. The considerations from Section 6.10 [ID- 452 PMIP6] apply. 454 Extending Binding Lifetime: 456 o For extending the binding lifetime of a currently registered 457 mobile node , the mobile access gateway MUST send a Proxy Binding 458 Update message to the local mobility anchor with a non zero 459 lifetime value. The message MUST contain the IPv4 Home Address 460 option with the value set to the currently registered IPv4 home 461 address value. Additionally, if there is a registered IPv6 home 462 network prefix for the mobile node for the connected interface on 463 that access link, both the options, Home Network Prefix option and 464 the IPv4 Home Address option MUST be present and with the values 465 set to the respective registered values. 467 Mobile Node Detachment and Binding De-Registration: 469 o As specified in Section 6.9.1 [ID-PMIP6], at any point in time, 470 when the mobile access gateway detects that the mobile node has 471 moved away from its access link, it SHOULD send a Proxy Binding 472 Update message to the local mobility anchor with the lifetime 473 value set to zero. The message MUST contain the IPv4 Home Address 474 option with the value set to the currently registered IPv4 home 475 address value. Additionally, if there is a registered IPv6 home 476 network prefix for the mobile node for the connected interface on 477 that access link, both the options, Home Network Prefix option and 478 the IPv4 Home Address option MUST be present and with the values 479 set to the respective registered values. 481 Constructing the Proxy Binding Update Message: 483 o The mobile access gateway when sending the Proxy Binding Update 484 request to the local mobility anchor for requesting IPv4 home 485 address mobility support MUST construct the message as specified 486 below. 488 IPv6 header (src=Proxy-CoA, dst=LMAA) 489 Mobility header 490 -BU /*P & A flags are set*/ 491 Mobility Options 492 - Timestamp Option (optional) 493 - Mobile Node Identifier option 494 - Access Technology Type option (Mandatory) 495 - Mobile Node Interface Identifier option 496 (Optional) 498 - IPv4 Home Address option (Mandatory) 500 Figure 4: Proxy Binding Update for IPv4 Home Address Support 502 o The source address field of the IPv6 header MUST be the IPv6 503 address of the mobile access gateway. 505 o The IPv4 Home Address option [ID-DSMIP6] MUST be present. The 506 address value MAY be set 0.0.0.0 or to a specific value. 508 o All the other fields and the options MUST be constructed, as 509 specified in [ID-PMIP6]. 511 DHCP Messages from the mobile node: 513 o When a mobile node attached to an access link and attempts to 514 obtain an IPv4 address configuration, using DHCP or other 515 procedures, it will get an IPv4 address as an IPv4 home address 516 from its home network prefix as discussed in Section 3.1. The 517 mobile access gateway on the access link where mobile node is 518 attached, will register this address with the local mobility 519 anchor using the IPv4 Home Address option, defined in Section 520 3.1.1 of [ID-DSMIP6]. The IPv4 Home Address option is sent with a 521 proxy binding update as shown in Figure 4 523 o When a mobile node obtains an IPv4 home address from DHCP server, 524 the mobile access gateway SHOULD record the assigned IPv4 home 525 address in the policy profile. A new mobile access gateway can 526 send a proxy binding update when a mobile node roams to the new 527 mobile access gateway. 529 o When a mobile node first attaches to a Proxy Mobile IPv6 domain, a 530 mobile access gateway triggers a proxy binding update by following 531 conditions. It is rarely happened that the DHCP procedure and 532 proxy binding procedure run at the same time except for the 533 initial attachment. 535 * When a mobile access gateway is a DHCP server, it MUST send a 536 proxy binding update right after receiving a DHCP discovery 537 message from a mobile node. By sending the proxy binding 538 update, it will learn the assigned IPv4 home address from the 539 local mobility anchor. 541 * When a DHCP relay is co-located with a mobile access gateway, 542 the mobile access gateway MUST send a proxy binding update as 543 soon as it receives a DHCP Acknowledgement message from the 544 DHCP server. During the proxy binding registration, it MUST 545 NOT relay the DHCP Acknowledgement message to the DHCP client. 546 After the proxy binding is successfully registered, the DHCP 547 relay (i.e. mobile access gateway) MUST forward the DHCP 548 Acknowledgement to the DHCP client (i.e. mobile node). Before 549 a DHCP Acknowledgement message, a DHCP client and the DHCP 550 server do not complete the negotiation of IPv4 address 551 assignment so that the mobile access gateway MAY send a 552 different IPv4 address to the local mobility anchor by a proxy 553 binding update. 555 o After the initial procedure described in above, DHCP runs 556 independently to the proxy binding registration for renewing the 557 assigned IPv4 home address. It is not necessary to run DHCP 558 whenever a mobile node changes its attached mobile access gateway. 559 A DHCP client renew the address according to the address lifetime, 560 etc. However, whenever a mobile node renews the IPv4 home address 561 by DHCP (DHCP RENEWING STATE [RFC-2131]), the mobile access 562 gateway SHOULD send a proxy binding update to the local mobility 563 anchor regardless of the mobile node's assigned address changes. 565 o When a mobile node gets IPv4 home address from Local Mobility 566 Anchor through DHCP interaction with mobile access gateway that 567 supports DHCP server functionality, the DHCP client in the mobile 568 node recognizes mobile access gateway's IP address as DHCP 569 server's IP address. Thus, the DHCP client unicasts DHCP renew to 570 the mobile access gateway, when the DHCP client goes into the DHCP 571 RENEWING state [RFC-2131]. However, when the mobile node 572 handovers to a new mobile access gateway, the mobile node does not 573 know the link change and the DHCP client would unicast DHCP 574 request to the previous mobile access gateway whose IP address was 575 acquired from DHCP offer. So, DHCP client in the mobile node 576 needs to reconfigure its local configuration parameters. 577 Therefore, mobile access gateway SHOULD discard any DHCP request 578 message that does not belong to the mobile access gateway itself, 579 so that the mobile node should go into the DHCP REBINDING state 580 and broadcast DHCP request without server identifier. 582 3.3. Local Mobility Anchor Considerations 584 3.3.1. Extensions to Binding Cache Entry 586 For supporting this feature, the conceptual Binding Cache entry data 587 structure needs to be extended with the following additional 588 parameter, as specified in [ID-DSMIP6] specification and is presented 589 here for convenience. 591 o The IPv4 home address of the registered mobile node. The IPv4 592 home address value may have been statically configured in the 593 mobile node's policy profile, it MAY have been assigned by a DHCP 594 server, or it MAY have been dynamically allocated by the local 595 mobility anchor. 597 3.3.2. Signaling Considerations 599 All the considerations explained in Section 5.3 [ID-PMIP6] apply 600 here. For supporting IPv4 home address mobility feature, the 601 following additional considerations MUST be applied. 603 Processing Binding Registrations: 605 o If there is an IPv4 Home Address option present in the request, 606 but if there is no Home Network Prefix option present in the 607 request, the local mobility anchor MUST NOT reject the request as 608 specified in [ID-PMIP6]. At least one of these two options MUST 609 be present. However, if both the options are not present, the 610 local mobility anchor MUST reject the request and send a Proxy 611 Binding Acknowledgement message with Status field set to 612 MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home 613 network prefix option). 615 o The local mobility anchor MUST use the identifier from the Mobile 616 Node Identifier Option [RFC-4283] present in the Proxy Binding 617 Update request and MUST apply multihoming considerations specified 618 in Section 5.4 [ID-PMIP6] and from this section for performing the 619 Binding Cache entry existence test. 621 o If there is no existing Binding Cache entry that matches the 622 request, the local mobility anchor MUST consider this request as 623 an initial binding registration request. If the entry exists, the 624 local mobility anchor MUST consider this request as a binding re- 625 registration request. 627 o The proxy care-of address MUST be retrieved from the source 628 address field of the proxy binding update message. 630 o If the IPv4 Home Address option present in the Proxy Binding 631 Update request has the value of 0.0.0.0, the local mobility anchor 632 MUST allocate an IPv4 home address for the mobile node and send a 633 Proxy Binding Acknowledgement message and including the IPv4 634 Address Acknowledgement option, defined in Section 3.2.1 of [ID- 635 DSMIP6], containing the allocated address value. The specific 636 details on how the local mobility anchor allocates the home 637 address is outside the scope of this document. The local mobility 638 anchor MUST ensure the allocated prefix is not in use by any other 639 mobile node. 641 o If the local mobility anchor is unable to allocate an IPv4 home 642 address for the mobile node, it MUST reject the request and send a 643 Proxy Binding Acknowledgement message with Status field set to 130 644 (Insufficient resources). 646 o Upon accepting the request, the local mobility anchor MUST create 647 a Binding Cache entry for the mobile node. It must set the fields 648 in the Binding Cache entry to the accepted values for that 649 binding. It MUST also establish a bi-directional tunnel to the 650 mobile access gateway, as described in [RFC-2473]. Considerations 651 from Section 5.6 [ID-PMIP6] MUST be applied. The local mobility 652 anchor MUST add an IPv4 host route for that allocated IPv4 home 653 address over the tunnel to the mobile access gateway. 655 Multihoming Considerations: 657 o The multihoming considerations specified in Section 5.4 [ID-PMIP6] 658 allows the local mobility anchor to perform the Binding Cache 659 entry existence test for identifying the mobility session, by 660 using the mobile node identifier, interface identifier and the 661 Home Network Prefix values. When using an IPv4 home address 662 value, instead of the IPv6 home network prefix for matching the 663 Binding Cache entry, all those considerations equally apply for 664 the IPv4 home address as well. 666 o If there is an Home Network Prefix option present in the Proxy 667 Binding Update request and with a NON_ZERO value, the local 668 mobility anchor MUST use this parameter in combination with the 669 mobile node identifier and interface identifier for matching the 670 Binding Cache entry, just as specified in Section 5.4 [ID-PMIP6]. 671 For all other cases, the local mobility anchor MUST use the IPv4 672 home address parameter in combination with the mobile node 673 identifier and interface identifier for matching the Binding Cache 674 entry, as specified in Section 5.4 [ID-PMIP6]. 676 Constructing the Proxy Binding Acknowledgement Message: 678 o The local mobility anchor when sending the Proxy Binding 679 Acknowledgement message to the mobile access gateway MUST 680 construct the message as specified below. 682 IPv6 header (src=LMAA, dst=Proxy-CoA) 683 Mobility header 684 -BA /*P flag is set*/ 685 Mobility Options 686 - Timestamp option (optional) 687 - Mobile Node Identifier Option 688 - Access Technology Type option (Mandatory) 689 - Mobile Node Interface Identifier option 690 (Optional) 692 - IPv4 Address Acknowledgement Option (Mandatory) 694 Figure 5: Proxy Binding Acknowledgement for IPv4 Home Address 695 Support 697 o The destination address field of the IPv6 header MUST be set to 698 the mobile access gateway. 700 o The IPv4 Address Acknowledgement option MUST be present in the 701 Proxy Binding Acknowledgement message. If both the IPv4 Home 702 Address option and the IPv6 Home Network Prefix option were not 703 present in the Proxy Binding Update request and if the Status 704 field value in the message is set to 705 MISSING_HOME_NETWORK_PREFIX_OPTION, the value MUST be set to 706 ALL_ZERO. For all other Status values, the IPv4 home address 707 value MUST be set to the allocated address value for that mobile 708 node. Considerations from [ID-DSMIP6] MUST be applied on 709 determining Status field value in the option. 711 o All the other fields and the options MUST be constructed, as 712 specified in [ID-PMIP6]. 714 3.3.3. Routing Considerations 716 Forwarding Considerations for the mobile node's IPv4 home address 717 traffic. 719 Intercepting Packets Sent to the Mobile Node's IPv4 home network: 721 o When the local mobility anchor is serving a mobile node, it MUST 722 be able to receive packets that are sent to the mobile node's IPv4 723 network. In order for it to receive those packets, it MUST 724 advertise a connected route in to the Routing Infrastructure for 725 the mobile node's IPv4 home network prefix or for an aggregated 726 prefix with a larger scope. This essentially enables IPv4 routers 727 in that network to detect the local mobility anchor as the last- 728 hop router for that IPv4 prefix. 730 Forwarding Packets to the Mobile Node: 732 o On receiving a packet from a correspondent node with the 733 destination address matching a mobile node's IPv4 home address, 734 the local mobility anchor MUST forward the packet through the bi- 735 directional tunnel setup for that mobile node. The format of the 736 tunneled packet is shown below. 738 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 739 IPv4 header (src= CN, dst= IPv4-MN-HOA ) /* Packet Header */ 740 Upper layer protocols /* Packet Content*/ 742 Figure 6: Tunneled Packets from LMA to MAG 744 Forwarding Packets Sent by the Mobile Node: 746 o All the reverse tunneled packets that the local mobility anchor 747 receives from the mobile access gateway, after removing the tunnel 748 header MUST be routed to the destination specified in the inner 749 IPv4 packet header. These routed packets will have the source 750 address field set to the mobile node's IPv4 home address. 752 4. IPv4 Transport Support 754 The Proxy Mobile IPv6 specification [ID-PMIP6] assumes the network 755 between the local mobility anchor and the mobile access gateway to be 756 an IPv6 network and requires the signaling messages exchanged between 757 the local mobility anchor and the mobile access gateway to be over an 758 IPv6 transport. The extensions defined in this section allow the 759 exchange of signaling messages over an IPv4 transport and when the 760 local mobility anchor and the mobile access gateway are separated by 761 an IPv4 network and potentially even configured with IPv4 private 762 addresses and with NAT translation devices in the path. 764 IPv4-Proxy-CoA IPv4-LMAA 765 | + - - - - - - + | 766 +--+ +---+ / \ +---+ +--+ 767 |MN|----------|MAG|===== IPv4 Network =====|LMA|----------|CN| 768 +--+ +---+ \ / +---+ +--+ 769 + - - - - - - + 771 Figure 7: IPv4 Transport Network 773 When the network between the local mobility anchor and the mobile 774 access gateway is an IPv4 network, the mobile access gateway can 775 potentially register an IPv4 address with the local mobility anchor, 776 as the care-of address in the mobile node's Binding Cache entry and 777 thus creating an IPv4 tunnel for carrying all the mobile node's 778 traffic. 780 The DSMIPv6 specification [ID-DSMIP6] defines a solution for allowing 781 a mobile node to roam over an IPv4 network and the same mechanism is 782 extended to Proxy Mobile IPv6. As explained in Section 4.1, of the 783 [ID-DSMIP6], a mobile access gateway MUST send a Proxy Binding Update 784 IPv6 message by IPv4 UDP-based encapsulation and route it to the 785 local mobility anchor. The processing logic and the on path NAT 786 detection logic are just as described in Section 4.1. The signaling 787 messages will always be IPv6 messages encapsulated in an IPv4 packet 788 and carried as an IPv4 packet. The data traffic to and from the 789 mobile node will also be encapsulated and carried as IPv4 packets. 790 This specification does not cover the dynamic discovery of the IPv4 791 address of the local mobility anchor (IPv4-LMAA) and thus it is 792 assumed that the mobile access gateway can learn this address from 793 the mobile node's policy profile or it can obtain this information 794 through other techniques that are beyond the scope of this document. 796 4.1. NAT Detection 798 When the transport network between the local mobility anchor and the 799 mobile access gateway is an IPv4 network, the mobile access gateway 800 MUST send Proxy Binding Update message encapsulated in the IPv4-UDP 801 packet. On receiving this Proxy Binding Update packet encapsulated 802 in an IPv4-UDP packet, the local mobility anchor if it detects a NAT 803 on the path, will send the Proxy Binding Acknowledgment message with 804 the NAT Detection Option. The presence of this option in the Proxy 805 Binding Acknowledgment is an indication to the mobile access gateway 806 about the presence of NAT in the path. On detecting the NAT in the 807 path, both the local mobility anchor and the mobile access gateway 808 MUST set the encapsulation mode of the tunnel to IPv4-UDP-based 809 encapsulation. The specific details around the NAT detection and the 810 related logic is described in in DSMIPv6 specification [ID-DSMIP6]. 812 There are discussions on how to incorporate the NAT detection 813 mechanism of IKE with DSMIPv6 in the MIP6 and the NEMO Working 814 Groups. This documentation will follow the conclusion of their 815 discussions. 817 4.2. Mobile Access Gateway Considerations 819 4.2.1. Extensions to Binding Update List Entry 821 For supporting this feature, the conceptual Binding Update List entry 822 data structure needs to be extended with the following additional 823 parameter, as specified in [ID-DSMIP6] specification and are reviewed 824 here for convenience. 826 o The IPv4 Care-of address of the attached mobile node. In this 827 specification, it can be translated to IPv4 Care-of address of the 828 mobile access gateway to which a mobile node is attached. 830 4.2.2. Signaling Considerations 832 All the considerations as explained in Section 6.11 of the base Proxy 833 Mobile IPv6 specification apply here. 835 Network Configurations for IPv4 Transport Signaling Support: 837 o If IPv4 transport support is enabled in order to place a mobile 838 access gateway at IPv4 only network, the mobile access gateway 839 MUST have an IPv4 address at the visiting network. In addition to 840 that, the mobile access gateway MUST obtain an IPv6 address 841 configured for the Proxy Mobile IPv6 operation. Even if the 842 mobile access gateway does not have connectivity to the IPv6 843 network, it MUST configure with an IPv6 address for sending the 844 proxy binding registration to the local mobility anchor. 846 Processing Binding Registrations: 848 o As explained in the DSMIPv6 specification, the mobile access 849 gateway can encapsulate a Proxy Binding Update message and carry 850 it in IPv4 and UDP packet. The processing logic for handling the 851 NAT detection at the mobile node is applicable to the mobile 852 access gateway as described in Section 4.1. 854 o An example of proxy binding update sent by mobile access gateway 855 is shown in Figure 8. The source address of the inner IPv6 header 856 MUST set to the IPv6 address assigned to the mobile access gateway 857 and the destination address MUST be the local mobility anchor's 858 IPv6 address (LMAA). This is slightly different from [ID-DSMIP6] 859 . The reason is already mentioned in Section 3.2.2. 861 o The source address of the outer packet MUST be the IPv4-Proxy-CoA 862 and the destination MUST be the local mobility anchor's IPv4 863 address (IPv4-LMAA). 865 o The IPv4-Proxy-CoA MUST be set in the IPv4 Care-of Address option 866 defined in section 3.1.2 of [ID-DSMIP6]. 868 o For the NAT handling, the UDP-based encapsulation MUST be always 869 used for the proxy binding update. The UDP port number is defined 870 in [ID-DSMIP6]. 872 o If the mobile access gateway requested to use the TLV header for 873 the UDP encapsulation, it MUST insert a TLV header after the UDP 874 header and MUST set T flag in the proxy binding update message. 875 The format of the TLV header is defined in section 4.1 of [ID- 876 DSMIP6]. 878 o The proxy binding update MUST be protected by IPsec ESP. The 879 security association for IPv4 addresses of the mobile access 880 gateway and local mobility anchor are pre-established. 882 Constructing the Proxy Binding Update Message: 884 o The mobile access gateway when sending the Proxy Binding Update 885 request to the local mobility anchor from an IPv4 networks MUST 886 construct the message as specified below. 888 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 889 UDP header 890 [TLV-header] (Optional, if T flag is set) 891 IPv6 header (src=Proxy-CoA, dst=LMAA) 892 Mobility header 893 -BU (P flag is set. F/T flags are optional) 894 Mobility Options 895 - Home Network Prefix Option 896 - IPv4 Home Address option 897 - Timestamp option (optional) 898 - Mobile Node Identifier Option 899 - Access Technology Type option (Mandatory) 900 - Mobile Node Interface Identifier option 901 (Optional) 903 - The IPv4 Care-of Address option(Mandatory) 905 Figure 8: Proxy Binding Update from mobile access gateway in IPv4 906 network 908 o The IPv4 Care-of Address option [ID-DSMIP6] MUST be present. The 909 address value MUST be set to a mobile access gateway's IPv4 910 address. 912 o All the other fields and the options MUST be constructed, as 913 specified in [ID-PMIP6]. 915 Receiving Binding Registration Reply: 917 o After receiving a Proxy Binding Acknowledgment message 918 encapsulated in an IPv4 packet, the mobile access gateway MUST 919 verify the Proxy Binding Acknowledgment according to the Section 920 4.3 of Dual Stack Mobile IPv6 specification [ID-DSMIP6]. 922 o If the Status field indicates Success, the mobile access gateway 923 MUST setup a tunnel to the local mobility anchor and add a default 924 route over the tunnel for all the mobile node's traffic. 926 o If the NAT is available and the NAT detection option is presented 927 in the Proxy Binding Acknowledgment, the mobile access gateway 928 MUST use the UDP tunnel to traverse the NAT for mobile node's 929 traffic and MUST send a proxy binding update every refresh time 930 specified in the NAT detection option. The detailed operation can 931 be found in Dual Stack Mobile IPv6 specification [ID-DSMIP6]. 933 o If the Status field in the proxy binding acknowledgment indicates 934 the rejection of the binding registration, the mobile access 935 gateway MUST NOT enable IPv4 transport for the mobile node's 936 traffic. 938 Forwarding Packets to Local Mobility Anchor 940 o On receiving any packets from the mobile node's IPv6 home address 941 and/or IPv4 home address, the mobile access gateway tunnels the 942 packets to local mobility anchor as shown in Figure 9. If the 943 mobile access gateway and the local mobility anchor agreed to use 944 the TLV header for the UDP tunnel during the binding registration, 945 the TLV header MUST be presented after the UDP header as shown in 946 Figure 10. 948 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 949 [UDP header] /*Only if NAT is detected*/ 950 union { /*following either v6 or v4 header */ 951 IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN) 952 IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN) 953 } 954 Upper layer protocols /*TCP,UDP,SCTP*/ 956 Figure 9: Tunneled Packets from MAG to LMA 958 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 959 UDP header 960 TLV header 961 union { 962 IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN) 963 IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN) 964 IPsec 965 GRE 966 } 967 Upper layer protocols /*TCP,UDP,SCTP*/ 969 Figure 10: Tunneled Packets from MAG to LMA using the TLV header 971 4.3. Local Mobility Anchor Considerations 973 4.3.1. Extensions to Binding Cache Entry 975 For supporting this feature, the conceptual Binding Cache entry data 976 structure needs to be extended with the following additional 977 parameter as specified in [ID-DSMIP6] specification and are reviewed 978 here for convenience. 980 o The IPv4 Care-of address of the attached mobile node. In this 981 specification, it can be translated to IPv4 Care-of address of the 982 mobile access gateway to which a mobile node is attached. 984 4.3.2. Signaling Considerations 986 When a mobile node is attached to a mobile access gateway that is 987 reachable only through an IPv4 transport network, the local mobility 988 anchor must establish an IPv4 tunnel for routing the mobile node's 989 IPv4 and IPv6 home address traffic. The DSMIPv6 specification 990 provides the semantics on how the IPv4 tunnel needs to be negotiated 991 and the detection logic of the NAT devices. This specification 992 leverages the NAT Detection Option, defined in the Dual Stack Mobile 993 IPv6 specification for the use in Binding Acknowledgment message and 994 extends it to Proxy Binding Acknowledgment messages. The operational 995 steps are defined below. 997 Processing Binding Registrations: 999 o After accepting the registration from the mobile access gateway 1000 locating at the IPv4 only network, the local mobility anchor MUST 1001 setup a tunnel to the mobile access gateway. The tunnel is 1002 established between the v4-LMAA and the IPv4-Proxy-CoA of the 1003 mobile access gateway. 1005 o If the NAT is available, the local mobility anchor MUST use UDP 1006 encapsulation for the tunnel. 1008 o If the T flag is set in the proxy binding update message and the 1009 TLV header is presented, the specified tunnel type must be used. 1011 o The local mobility anchor also setup a host routes for the IPv4 1012 home address and the IPv6 home address of the mobile node over the 1013 tunnel to the mobile access gateway. Any traffic that the local 1014 mobility anchor receives from a correspondent node will be 1015 tunneled to the mobile access gateway over the bi-directional 1016 tunnel and then routed accordingly after removing the tunnel 1017 headers. The encapsulation modes for the bi-directional tunnel 1018 are as specified in Section 5.3 of Proxy Mobile IPv6 specification 1019 [ID-PMIP6] and as in this specification. 1021 o Upon receiving a Proxy Binding Update message encapsulated in an 1022 IPv4 packet, the local mobility anchor MUST send the Proxy Binding 1023 Acknowledgment to the mobile access gateway's IPv4-Proxy-CoA by 1024 using IPv4 encapsulation. 1026 o If the NAT is detected, the NAT detection option MUST be used in 1027 the Proxy Binding Acknowledgment. How to detect NAT is described 1028 in Section 4.1 of [ID-DSMIP6] and Section 4.1. 1030 Constructing the Proxy Binding Acknowledgement Message: 1032 o The proxy binding acknowledgment MUST be protected by IPsec ESP. 1033 The security association for IPv4 addresses of the mobile access 1034 gateway and local mobility anchor are pre-established. 1036 o For the IPv4 transport support, no special mobility options are 1037 required. Only when NAT is detected, the NAT detection option 1038 MUST be present. The local mobility anchor MUST construct the 1039 proxy binding Acknowledgement as specified in [ID-PMIP6]. 1041 o An example of proxy binding acknowledgment sent by local mobility 1042 anchor is shown below. The same illustration for Mobile IPv6 can 1043 be found in Section 4.1 of [ID-DSMIP6]. 1045 IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) 1046 UDP header 1047 [TLV-header] /* optional, if T flag is set */ 1048 IPv6 header (src=LMAA, dst=Proxy-CoA) 1049 Mobility header 1050 -BA /* P flag/T flag(option) */ 1051 Mobility Options 1052 - Home Network Prefix Option 1053 - IPv4 Address Acknowledgement option 1054 - Timestamp option (optional) 1055 - Mobile Node Identifier Option 1056 - Access Technology Type option (Mandatory) 1057 - Mobile Node Interface Identifier option 1058 (Optional) 1060 - NAT Detection Option (Optional) 1062 Figure 11: Proxy Binding Acknowledgment in IPv4 network 1064 Forwarding Packets to Mobile Access Gateway 1066 o When sending any packets meant to a mobile node's IPv4 home 1067 address or IPv6 home address, the local mobility anchor tunnels 1068 the packet to mobile access gateway as shown in Figure 12. 1070 IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) 1071 [UDP header] /*Only if NAT is detected*/ 1072 union { /*following either v6 or v4 header */ 1073 IPv4 header (src=IPv4-CN, dst=IPv4-HoA) 1074 IPv6 header (src=IPv6-CN, dst=IPv6-HoA) 1075 } 1076 Upper layer protocols /*TCP,UDP,SCTP*/ 1078 Figure 12: Tunneled Packets from LMA to MAG 1080 o If the mobile access gateway and the local mobility anchor agreed 1081 to use the TLV header for the UDP tunnel during the binding 1082 registration, the TLV header MUST be presented after the UDP 1083 header as shown in Figure 13. 1085 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 1086 UDP header 1087 TLV header 1088 union { 1089 IPv4 header (src=IPv4-CN, dst=IPv4-HoA) 1090 IPv6 header (src=IPv6-CN, dst=IPv6-HoA) 1091 IPsec 1092 GRE 1093 } 1094 Upper layer protocols /*TCP,UDP,SCTP*/ 1096 Figure 13: Tunneled Packets from LMA to MAG using the TLV header 1098 4.4. Tunnel Management 1100 As specified in the Proxy Mobile IPv6 specification, the bi- 1101 directional tunnel between the local mobility anchor and the mobile 1102 access gateway, is a shared tunnel and all the considerations from 1103 Section 6.6 of Proxy Mobile IPv6 [ID-PMIP6] apply for IPv4 transport 1104 as well. 1106 5. IANA Considerations 1108 This document does not require IANA Action. 1110 6. Security Considerations 1112 The security mechanisms specified for Proxy Mobile IPv6 protocol are 1113 used when using the extensions defined in this document. 1115 When supporting IPv4 address assignment from a DHCP server, all the 1116 IPv4 home addresses managed in the DHCP server must be reachable via 1117 local mobility anchor so that local mobility anchor intercepts 1118 packets meant for an IPv4 home address and tunnels them to the mobile 1119 node via corresponding mobile access gateway. Moreover, all the DHCP 1120 messages between a DHCP relay and the DHCP server SHOULD be securely 1121 exchanged. 1123 After receiving a Proxy Binding Update message with an IPv4 Home 1124 Address Option, the local mobility anchor MUST be able to verify that 1125 the mobile node is authorized to use that address before setting up 1126 forwarding for that host route. 1128 When supporting dynamic IPv4 address assignment by DHCP and also from 1129 local mobility anchor, it should be ensured both the entities are 1130 configured with different address pools, so as to avoid both entities 1131 do not allocate the same address to different mobile nodes. 1133 This specification describes the use of IPv4 transport network 1134 between the local mobility anchor and the mobile access gateway. All 1135 the signaling messages exchanged between the mobile access gateway 1136 and the local mobility anchor over the IPv4 transport MUST be 1137 protected using IPsec, just as the messages must be protected when 1138 using IPv6 transport and as specified in the Section 4.0, of the 1139 Proxy Mobile IPv6 specification [ID-PMIP6]. 1141 7. Contributors 1143 This document reflects discussions and contributions from several 1144 people (in alphabetical order): 1146 Kuntal Chowdhury 1148 kchowdhury@starentnetworks.com 1150 Vijay Devarapalli 1152 vijay.devarapalli@azairenet.com 1154 Sangjin Jeong 1156 sjjeong@etri.re.kr 1158 Basavaraj Patil 1160 basavaraj.patil@nsn.com 1162 Myungki Shin 1164 myungki.shin@gmail.com 1166 8. Acknowledgments 1168 The IPv4 support for Proxy Mobile IPv6 was initially covered in the 1169 internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. This document 1170 leverages lot of text from that document. We would like to thank all 1171 the authors of the document and acknowledge that initial work. 1173 9. References 1175 9.1. Normative References 1177 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 1178 Requirement Levels", BCP 14, RFC 2119, March 1997. 1180 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1181 2131, March 1997. 1183 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1184 IPv6 Specification", RFC 2473, December 1998. 1186 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1187 IPv6", RFC 3775, June 2004. 1189 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1190 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 1191 November 2005. 1193 [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack 1194 Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-05.txt 1195 ,July 2007. 1197 [ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6", 1198 draft-ietf-netlmm-proxymip6-07.txt, November 2007. 1200 9.2. Informative References 1202 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1203 2131, March 1997. 1205 [RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1206 Address Translator (Traditional NAT)", RFC 3022, January 2001. 1208 [RFC-4977] Tsirtsis, G., Soliman, H., "Problem Statement: Dual Stack 1209 Mobility", RFC 4977, August 2007. 1211 Appendix A. DHCP usages for IPv4 home address assignment 1213 There are several other configurations of DHCP entities [RFC-2131] in 1214 a Proxy Mobile IPv6 domain other than the two configurations listed 1215 in Section 3.1. Although this specification recommends the two 1216 configurations described in Section 3.1, operators should select the 1217 best configuration according to their deployments scenario. Note 1218 that the mobile node behavior for all scenarios does not change. We 1219 do not have major interoperability concerns between multiple 1220 scenarios. A mobile access gateway and local mobility anchor make 1221 sure that which option is used in the Proxy Mobile IPv6 domain based 1222 on the deployment scenario. 1224 In the configurations described in this section, the DHCP messages 1225 MAY be sent across an administrative boundaries. The operators 1226 SHOULD consider to protect these messages crossing the administrative 1227 boundary. The optional DHCP configurations for IPv4 home address 1228 assignment are described below. 1230 o DHCP relay is located in each mobile access gateway and DHCP 1231 server is solely located in the Proxy Mobile IPv6 domain 1233 o DHCP relay is located in both each mobile access gateway and a 1234 local mobility anchor. DHCP server is solely located in the Proxy 1235 Mobile IPv6 domain 1237 In Figure 14, a DHCP relay is co-located with each mobile access 1238 gateway. The DHCP server is located independently in a Proxy Mobile 1239 IPv6 domain. Thus, the address assignment is done between the mobile 1240 access gateway and the DHCP server, but not with the local mobility 1241 anchor. A mobility anchor gateway is configured with the DHCP server 1242 address and relays the DHCP discovery message from the mobile node to 1243 the DHCP server. While the DHCP server offers the IPv4 home address 1244 to the mobile node, the mobile access gateway intercepts the DHCP 1245 offer and starts sending proxy binding update to the local mobility 1246 anchor. As soon as proxy binding registration is completed, the 1247 mobile access gateway sends the DHCP offer back to the mobile node. 1248 The mobile node will send DHCP request and wait for the DHCP 1249 Acknowledgement to/from the DHCP server through the mobility anchor 1250 gateway (i.e. DHCP relay). When multiple local mobility anchors are 1251 available in the Proxy Mobile IPv6 domain, each mobile access gateway 1252 must ensure to relay the DHCP messages to the right DHCP server. 1254 MN MAG(DHCP-R) DHCP-S LMA 1255 |------>|------->| | 1. DHCP discovery 1256 |<------|<-------| | 2. DHCP offer (IPv4 HoA) and Relay 1257 |------>|------->| | 3. DHCP request (IPv4 HoA) and Relay 1258 | |<-------| | 4. DHCP acknowledgement and Relay 1259 | |--------------->| 5. Proxy Binding Update 1260 | |<---------------| 6. Proxy Binding Acknowledgement 1261 | |================| 7. Tunnel/Route Setup 1262 |<------| | | 8. DHCP acknowledgement to client 1263 | | | | 1265 Figure 14: The use of an Independent DHCP relay 1267 Figure 15 is very similar to the Figure 14 except for the local 1268 mobility anchor being a DHCP relay. In this case, both a mobile 1269 access gateway and local mobility anchor relay the DHCP messages from 1270 and to the mobile nodes. 1272 MN MAG(DHCP-R) LMA(DHCP-R) DHCP-S 1273 |------>|------->|------>| 1. DHCP discovery and Relay 1274 |<------|<-------|<------| 2. DHCP offer (IPv4 HoA) and Relay 1275 |------>|------->|------>| 3. DHCP request (IPv4 HoA) and Relay 1276 | |<-------|<------| 4. DHCP acknowledgement and Relay 1277 | |------->| | 5. Proxy Binding Update 1278 | |<-------| | 6. Proxy Binding Acknowledgement 1279 | |========| | 7. Tunnel/Route Setup 1280 |<------| | | 8. DHCP acknowledgement to client 1281 | | | | 1282 * Tunnel setup(no.5) and DHCP offer/request/ack(no.6-8) 1283 are processed in parallel. 1285 Figure 15: The use of double DHCP relays on MAG and LMA 1287 Authors' Addresses 1289 Ryuji Wakikawa (Editor) 1290 Faculty of Environment and Information Studies, Keio University 1291 5322 Endo 1292 Fujisawa, Kanagawa 252-8520 1293 Japan 1295 Phone: +81-466-49-1100 1296 Fax: +81-466-49-1395 1297 Email: ryuji@sfc.wide.ad.jp 1298 URI: http://www.wakikawa.org/ 1300 Sri Gundavelli 1301 Cisco 1302 170 West Tasman Drive 1303 San Jose, CA 95134 1304 USA 1306 Email: sgundave@cisco.com 1308 Full Copyright Statement 1310 Copyright (C) The IETF Trust (2007). 1312 This document is subject to the rights, licenses and restrictions 1313 contained in BCP 78, and except as set forth therein, the authors 1314 retain all their rights. 1316 This document and the information contained herein are provided on an 1317 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1318 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1319 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1320 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1321 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1322 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1324 Intellectual Property 1326 The IETF takes no position regarding the validity or scope of any 1327 Intellectual Property Rights or other rights that might be claimed to 1328 pertain to the implementation or use of the technology described in 1329 this document or the extent to which any license under such rights 1330 might or might not be available; nor does it represent that it has 1331 made any independent effort to identify any such rights. Information 1332 on the procedures with respect to rights in RFC documents can be 1333 found in BCP 78 and BCP 79. 1335 Copies of IPR disclosures made to the IETF Secretariat and any 1336 assurances of licenses to be made available, or the result of an 1337 attempt made to obtain a general license or permission for the use of 1338 such proprietary rights by implementers or users of this 1339 specification can be obtained from the IETF on-line IPR repository at 1340 http://www.ietf.org/ipr. 1342 The IETF invites any interested party to bring to its attention any 1343 copyrights, patents or patent applications, or other proprietary 1344 rights that may cover technology that may be required to implement 1345 this standard. Please address the information to the IETF at 1346 ietf-ipr@ietf.org. 1348 Acknowledgment 1350 Funding for the RFC Editor function is provided by the IETF 1351 Administrative Support Activity (IASA).