idnits 2.17.1 draft-ietf-netlmm-pmip6-ipv4-support-00.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 853. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 877. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ID-DSMIP6], [ID-PMIP6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o If the Status field in the IPv4 Address Acknowledgment Option indicates the rejection of the IPv4 home address mobility service, the mobile access gateway MUST not enable IPv4 routing for the mobile node's IPv4 traffic. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o If the Status field in the proxy binding acknowledgment indicates the rejection of the binding registration, the mobile access gateway MUST not enable IPv4 transport for the mobile node's traffic. -- 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 2007) is 6162 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 164, but not defined == Missing Reference: 'MN1' is mentioned on line 172, but not defined == Missing Reference: 'MN3' is mentioned on line 172, but not defined == Missing Reference: 'DSMIP6' is mentioned on line 325, but not defined == Missing Reference: 'ID-DSMIP' is mentioned on line 368, but not defined == Unused Reference: 'RFC-1332' is defined on line 749, but no explicit reference was found in the text == Unused Reference: 'RFC-1661' is defined on line 752, but no explicit reference was found in the text == Unused Reference: 'RFC-2131' is defined on line 758, but no explicit reference was found in the text == Unused Reference: 'RFC-2473' is defined on line 761, but no explicit reference was found in the text == Unused Reference: 'RFC-3776' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'RFC-4830' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'RFC-4831' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'RFC-4832' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'ID-MIP6-IKEV2' is defined on line 786, but no explicit reference was found in the text == Unused Reference: 'RFC-2460' is defined on line 795, but no explicit reference was found in the text == Unused Reference: 'RFC-2461' is defined on line 798, but no explicit reference was found in the text == Unused Reference: 'RFC-2462' is defined on line 801, but no explicit reference was found in the text == Unused Reference: 'RFC-3315' is defined on line 804, but no explicit reference was found in the text == Unused Reference: 'RFC-4301' is defined on line 808, but no explicit reference was found in the text == Unused Reference: 'RFC-4303' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'RFC-4306' is defined on line 814, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4830 ** Downref: Normative reference to an Informational RFC: RFC 4831 ** Downref: Normative reference to an Informational RFC: RFC 4832 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-nemo-v4traversal-03 -- Possible downref: Normative reference to a draft: ref. 'ID-DSMIP6' -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 6 errors (**), 0 flaws (~~), 25 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group R. Wakikawa 3 Internet-Draft Keio University 4 Intended status: Standards Track S. Gundavelli 5 Expires: November 2, 2007 Cisco 6 May 2007 8 IPv4 Support for Proxy Mobile IPv6 9 draft-ietf-netlmm-pmip6-ipv4-support-00.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 2, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document specifies extensions to the Proxy Mobile IPv6 protocol 43 [ID-PMIP6] for supporting IPv4. The scope of the IPv4 support in 44 Proxy Mobile IPv6 includes the support for the mobile node's IPv4 45 home address mobility and for supporting the scenario where the local 46 mobility anchor and the mobile access gateway are separated by an 47 IPv4 transport network. The solution primarily leverages the 48 extensions defined in Dual Stack Mobile IPv6 specification [ID- 49 DSMIP6] for achieving this. 51 Table of Contents 53 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 6 56 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 57 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. IPv4 Home Address Mobility Support . . . . . . . . . . . . . . 7 60 3.1. IPv4 Home Address Assignment . . . . . . . . . . . . . . . 7 61 3.2. Extensions to Conceptual Data Structure . . . . . . . . . 9 62 3.3. Mobility Options . . . . . . . . . . . . . . . . . . . . . 9 63 3.4. Mobile Access Gateway Operation . . . . . . . . . . . . . 10 64 3.5. Local Mobility Anchor Operation . . . . . . . . . . . . . 11 66 4. IPv4 Transport Support . . . . . . . . . . . . . . . . . . . . 13 67 4.1. Mobility Options . . . . . . . . . . . . . . . . . . . . . 13 68 4.2. Extensions to Conceptual Data Structure . . . . . . . . . 13 69 4.3. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 14 70 4.4. Mobile Access Gateway Operation . . . . . . . . . . . . . 14 71 4.5. Local Mobility Anchor Operation . . . . . . . . . . . . . 16 72 4.6. Tunnel Management . . . . . . . . . . . . . . . . . . . . 18 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 78 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 87 Intellectual Property and Copyright Statements . . . . . . . . . . 25 89 1. Overview 91 The transition from IPv4 to IPv6 is a long process and during this 92 period of transition, both the protocols will be enabled over the 93 same infrastructure. Thus, it is reasonable to assume that the 94 mobile node, mobile access gateway and the local mobility anchor are 95 both IPv4 and IPv6 enabled and further it is also reasonable to 96 expect the same mobility infrastructure to provide both IPv4 and IPv6 97 address mobility for a mobile node. The motivation and scope of IPv4 98 support in Mobile IPv6 is summraized in [ID-DSMIP6-PS]. 100 The Proxy Mobile IPv6 base specification [ID-PMIP6] defines a 101 network-based mobility management protocol. The protocol specifies a 102 solution for providing IPv6 home address mobility for a mobile node 103 and over an IPv6 transport network separating the entities involved 104 in the mobility management. The extensions defined in this document 105 are for extending IPv4 support to the Proxy Mobile IPv6 protocol [ID- 106 PMIP6]. 108 The scope of these efforts include the support for the following: 110 o IPv4 Home Address Mobility: A mobile node operating in IPv4-only 111 mode or in a dual-stack mode should be able to obtain an IPv4 home 112 address and roam anywhere in that Proxy Mobile IPv6 domain. 114 o IPv4 Transport Network Support: The transport network between the 115 local mobility anchor and the mobile access gateway is an IPv4 116 network and further the local mobility anchor or the mobile access 117 gateway may be using IPv4 private addresses and with NAT 118 translation devices on the path 120 The DSMIP6 specification [ID-DSMIP6], extends IPv4 home address 121 mobility and IPv4 transport network support to the Mobile IPv6 122 protocol [RFC-3775]. The solution specified in this document 123 leverages the DSMIP6 work and extends the IPv4 feature to the Proxy 124 Mobile IPv6 protocol. The protocol semantics, processing logic and 125 mobility header options, such as IPv4 home address option, IPv4 126 address acknowledgment option and NAT detection option, defined in 127 the DSMIP6 specification, are all applied for Proxy Mobile IPv6 128 protocol. As specified in DSMIPv6, these two features, IPv4 Home 129 Address Mobility support and IPv4 transport support, are independent 130 of each other and implementors may choose to implement any one or 131 both of these features. Since this specification also inherits Proxy 132 Mobile IPv6 [ID-PMIP6], only point to point link is assumed between a 133 mobile node and a mobile access gateway. 135 This specification assumes that the local mobility anchor and the 136 mobile access gateway are both IPv6 capabled and IPv6 enabled, 137 irrespective of the type of transport network (IPv4 or IPv6), 138 connecting these two entities. The signaling protocol is 139 fundamentally based on Mobile IPv6 in this document. 141 Figure 1 illustrates a Proxy Mobile IPv6 domain supporting IPv4 home 142 address mobility and IPv4 transport network features. The mobile 143 nodes MN1, MN2 and MN3 can be operating in IPv4-only, IPv6-only or 144 dual-stack mode, and the transport network between the local mobility 145 anchor and the mobile access gateway may be an IPv6 network or an 146 IPv4 network. Further, when the transport network is IPv4, either 147 the local mobility anchor or the mobile access gateway, or both can 148 be behind a NAT translation device and configured with an IPv4 149 private address. 151 +----+ +----+ 152 |LMA1| |LMA2| 153 +----+ +----+ 154 IPv4-LMAA1 -> | | <-- IPv4-LMAA2 155 | | 156 \\ //\\ 157 [NAT] // \\ 158 \\ // \\ 159 +---\\------------- //------\\----+ 160 ( \\ IPv4/IPv6 // \\ ) 161 ( \\ Network // \\ ) 162 +------\\--------//------------\\-+ 163 \\ // \\ 164 \\ // [NAT] 165 \\ // \\ 166 IPv4-Proxy-CoA1--> | | <-- IPv4-Proxy-CoA2 167 +----+ +----+ 168 |MAG1|-----[MN2] |MAG2| 169 +----+ | +----+ 170 | | | 171 IPv4-MN-HoA1 --> | IPv4-MN-HoA2 | <-- IPv4-MN-HoA3 172 [MN1] [MN3] 174 Figure 1: IPv4 support for Proxy Mobile IPv6 176 2. Conventions & Terminology 178 2.1. Conventions 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted as described in [RFC-2119]. 184 2.2. Terminology 186 All the mobility related terms used in this document are to be 187 interpreted as defined in Mobile IPv6 specification [RFC-3775], 188 DSMIP6 specification [ID-DSMIP6] and Proxy Mobile IPv6 specification 189 [ID-PMIP6]. In addition the document introduces the following terms. 191 IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) 193 The IPv4 Care-of Address that is configured on the interface of 194 the mobile access gateway and is the transport endpoint of the 195 tunnel between a local mobility anchor and a mobile access 196 gateway. However, when the configured address is a private IPv4 197 address and with a NAT device in the path to the local mobility 198 anchor, the care-of address as seen by the local mobility anchor 199 will be the address allocated by the NAT device for the mobility 200 session. 202 IPv4 Local Mobility Anchor Address (IPv4-LMAA) 204 The global IPv4 address that is typically configured on the 205 interface of a local mobility anchor and is the transport endpoint 206 of the tunnel between a local mobility anchor and a mobile access 207 gateway. This is the address to where a mobile access gateway 208 sends proxy binding update messages. If a local mobility anchor 209 is configured behind NAT, IPv4-LMAA is the IPv6 global address of 210 the NAT box. According to Section 2.1 of [ID-DSMIP6], two options 211 are introduced for the case of the home agent being behind the NAT 212 box. When we interpret this two options for Proxy Mobile IPv6, it 213 goes following. 1) configure a public IPv4 address for each local 214 mobility anchor on the NAT box. 2) configure one public address 215 and make the local mobility anchors share the public address. 217 3. IPv4 Home Address Mobility Support 219 Using the extensions defined in this specification, a mobile node 220 operating in an IPv4-only or dual-stack mode will be able to obtain 221 an IPv4 address (IPv4-MN-HoA) and will be able to roam in that Proxy 222 Mobile IPv6 domain using that address. Although IPv6 home address is 223 always required in [ID-DSMIP6], this specification does not mandate 224 IPv6 home address unless a mobile node wants the IPv6 home address. 225 The network will provide mobility to that mobile node in that entire 226 domain. And further, the network will ensure that the mobile node 227 will always be able to obtain the same IPv4 address, as it moves 228 between access links and as long as the mobile node is in the scope 229 of that Proxy Mobile IPv6 domain. 231 3.1. IPv4 Home Address Assignment 233 A mobile node on attaching to an access link connected to a mobile 234 access gateway, and if the network allows the mobile node for IPv4 235 home address mobility service, the mobile node using any of the IPv4 236 address configuration procedures, such as DHCP, IPCP or IKEv2 that 237 are supported on that access link, will be able to obtain its IPv4 238 home address configuration. In addition to this, other address 239 configuration mechanisms including static configuration methods 240 specific to the access link may also be in place. The IPv4 home 241 address configuration includes the IPv4 home address, the IPv4 home 242 network prefix and IPv4 home network prefix length. In this 243 specification, we support following static and dynamic assignment 244 schemes. 246 o Static IPv4 Home Address Assignment: When a mobile node is 247 configured with a static IPv4 home address, the IPv4 home address 248 information MUST be stored in the mobile node's policy profile. 249 The mobile access gateway where the mobile node attached obtains 250 the static IPv4 home address from the policy profile. The mobile 251 access gateway MUST set the known IPv4 home prefix to the IPv4 252 Home Address field and the Pref field of the IPv4 home address 253 option [ID-DSMIP6]. This option is carried by a proxy binding 254 update described in [ID-PMIP6]. 256 o Dynamic IPv4 Home Address Assignment from Local Mobility Anchor: 257 If a local mobility anchor manages the IPv4 home address 258 allocation, a mobile access gateway requests dynamic IPv4 home 259 address allocation to the local mobility anchor as described in 260 [ID-DSMIP6]. The mobile access gateway SHOULD support minimal 261 functionality of DHCP server in order to send DHCP offer and and 262 acknowledgment messages to the mobile node in reply to the DHCP 263 discovery and request messages. The mobile access gateway is seen 264 as DHCP server from a mobile node, but it actually obtains the 265 IPv4 home address for each mobile node from the local mobility 266 anchor during proxy binding procedure. Figure 2 shows the 267 operational sequence of the home address mobility support< in this 268 case. If IPCP is used for address assignment, DHCP events in 269 Figure 2 are replaced by PPP events. 271 MN MAG LMA 272 |------>| | 1. DHCP discovery 273 | |------->| 2. Proxy Binding Update 274 | |<-------| 3. Proxy Binding Acknowledgement (IPv4HoA) 275 | |========| 4. Tunnel/Route Setup* 276 |<------| | 5. DHCP offer (IPv4 HoA) 277 |------>| | 6. DHCP request (IPv4 HoA) 278 |<------| | 7. DHCP acknowledgement 279 | | | 280 * Tunnel/Route setup(no.4) and DHCP offer/request/ack(no.5-7) 281 are processed in parallel. 283 Figure 2: An example when LMA assigns an IPv4 home address 285 o Dynamic IPv4 Home Address Assignment from DHCP Server: If DHCP is 286 used for the IPv4 home address allocation, a mobile access gateway 287 or specifically a DHCP relay agent on the link will ensure the 288 mobile node is assigned an address from its home network prefix, 289 by marking the DHCP request with the mobile node's IPv4 home 290 network prefix hint. A DHCP relay and a mobile access gateway can 291 be co-located. The mobile access gateway learns the IPv4 home 292 address from the DHCP reply and sends that information to the 293 mobile node by DHCP offer message. Meanwhile, it notifies the 294 assigned IPv4 home address by an IPv4 home address option in a 295 proxy binding update to the local mobility anchor. In this case, 296 the local mobility anchor does not allocate any address, but only 297 deals with route setup and tunnel setup for the requested home 298 address. Note that all the IPv4 home addresses managed in the 299 DHCP server must be reachable via local mobility anchor so that 300 local mobility anchor intercepts packets meant for an IPv4 home 301 address and tunnels them to the mobile node via corresponding 302 mobile access gateway. More remarks can be found in Section 6. 303 Figure 3 are the sequence of the home address mobility support. 305 MN MAG(DHCPR) DHCPS LMA 306 |------>|------->| | 1. DHCP discovery and Relay 307 | |<-------| | 2. DHCP offer (IPv4 HoA) 308 | |--------------->| 3. Proxy Binding Update 309 | |<---------------| 4. Proxy Binding Acknowledgement 310 | |================| 5. Tunnel/Route Setup 311 |<------| | | 6. DHCP offer (IPv4 HoA) Relay 312 |------>|------->| | 7. DHCP request (IPv4 HoA) and Relay 313 |<------|<-------| | 8. DHCP acknowledgement and Relay 314 | | | | 316 DHCPS: DHCP Server 317 DHCPR: DHCP Relay 318 * Tunnel setup(no.5) and DHCP offer/request/ack(no.6-8) 319 are processed in parallel. 321 Figure 3: An example when DHCP Server assigns an IPv4 home address 323 3.2. Extensions to Conceptual Data Structure 325 There are certain extensions defined in DSMIP specification [DSMIP6] 326 for supporting IPv4 home address mobility support. A mobile node can 327 obtain only IPv4 home address by this specification, while DSMIP 328 requires IPv6 home address for IPv4 home address support. Thus, a 329 mobile access gateway and a local mobility agent MUST create a 330 binding update list and a binding cache only for IPv4 home address 331 assigned to a mobile node. 333 3.3. Mobility Options 335 For supporting the IPv4 home address mobility, the following options 336 are required from the DSMIPv6 specification [ID-DSMIP6]. 338 o IPv4 Home Address Option defined in section 3.1.1 of [ID-DSMIP6]. 339 This option MUST be present in the Proxy Binding Update message 340 sent by the mobile access gateway to the local mobility anchor, 341 when requesting IPv4 home address support. 343 o IPv4 Address Acknowledgment Option defined in section 3.2.1 of 344 [ID-DSMIP6]. This option MUST be present in the Proxy Binding 345 Acknowledgment, if the local mobility anchor accepts IPv4 home 346 address support. 348 3.4. Mobile Access Gateway Operation 350 o All the considerations as explained in Section 6.11 of the base 351 Proxy Mobile IPv6 specification apply here. 353 o When a mobile node attached to an access link and attempts to 354 obtain an IPv4 address configuration, using DHCP or other 355 procedures, it will get an IPv4 address as a IPv4 home address 356 from its home network prefix as discussed in Section 3.1. The 357 mobile access gateway on the access link where mobile node is 358 attached, will register this address with the local mobility 359 anchor using the IPv4 Home Address option, defined in Section 360 3.1.1 of [ID-DSMIP6]. The IPv4 Home Address option is sent with a 361 proxy binding update as shown in Figure 4. The proxy binding 362 update MUST be protected by IPsec ESP. How to build the IPv4 home 363 address option is varied as follows: 365 * If a mobile access gateway needs to request dynamic IPv4 home 366 address allocation to the local mobility anchor, it MUST set 367 0.0.0.0 in the the IPv4 Home Address field of the IPv4 home 368 address option as described in [ID-DSMIP] and send this option 369 by the proxy binding update. 371 * If a mobile access gateway knows the IPv4 home prefix (or home 372 address) for the mobile node from static mobile node's policy 373 profile or DHCP server, it MUST set the known IPv4 home prefix 374 to the IPv4 Home Address field and the Pref field of the IPv4 375 home address option. This option is carried by a proxy binding 376 update described in Proxy Mobile IPv6 specification [ID-PMIP6]. 378 IPv6 header (src=PCoA, dst=LMAA) 379 Mobility header 380 -BU /*P flag is set*/ 381 Mobility Options 382 -HNP* /*IPv6 home address*/ 383 -TSO* 384 -IPv4-HAO 386 *HNP: Home Network Prefix Option 387 *TSO: Time Stamp Option 389 Figure 4: Proxy Binding Update for IPv4 Home Address Support 391 o A proxy binding acknowledgment will be returned by the local 392 mobility anchor. In the proxy binding acknowledgment, an IPv4 393 address acknowledgment option MUST be presented in reply to the 394 IPv4 home address option. The processing of this IPv4 home 395 acknowledgment option is found in DSMIP6 specification [ID- 396 DSMIP6]. 398 o After receiving a Proxy Binding Acknowledgment message with the 399 IPv4 Address Acknowledgment Option and if the status code in the 400 Binding Acknowledgment and Status field in the IPv4 Address 401 Acknowledgment values are set to Success, the mobile access 402 gateway MUST setup a tunnel to the local mobility anchor and must 403 also add a default route over the tunnel for all the mobile node's 404 IPv4 traffic. The encapsulation modes for the bi-directional 405 tunnel may be as specified in Section 5.3 of Proxy Mobile IPv6 406 specification [ID-PMIP6] and as in this specification. 408 o If the Status field in the IPv4 Address Acknowledgment Option 409 indicates the rejection of the IPv4 home address mobility service, 410 the mobile access gateway MUST not enable IPv4 routing for the 411 mobile node's IPv4 traffic. 413 3.5. Local Mobility Anchor Operation 415 o Upon receiving a Proxy Binding Update message with the IPv4 Home 416 Address Option, defined in Section 3.1.1 of DSMIP6 specification 417 [ID-DSMIP6], the local mobility anchor, if it determines that the 418 mobile node is configured for IPv4 home address mobility service, 419 the local mobility anchor MUST send the Proxy Binding 420 Acknowledgment message with the IPv4 Address Acknowledgment 421 Option, defined in Section 3.2.1 of DSMIP6 specification. How to 422 process the IPv4 home address option and how to return the IPv4 423 address acknowledgment are described in [ID-DSMIP6]. 425 IPv6 header (src=PCoA, dst=LMAA) 426 Mobility header 427 -BA /*P flag is set*/ 428 Mobility Options 429 -HNP* /*IPv6 home address*/ 430 -TSO* 431 -IPv4-ACK 432 -IPv4-DRA 433 *HNP: Home Network Prefix Option 434 *TSO: Time Stamp Option 436 Figure 5: Proxy Binding Acknowledgement for IPv4 Home Address 437 Support 439 o After accepting the registration for the mobile node's IPv4 home 440 address, the local mobility anchor will add an IPv4 host route 441 over the tunnel to the mobile access gateway. Any IPv4 packets 442 that the local mobility anchor receives from a correspondent node 443 will be tunneled to the mobile access gateway over the bi- 444 directional tunnel, and then routed accordingly after removing the 445 tunnel header. The encapsulation modes for the bi-directional 446 tunnel may be as specified in Section 5.3 of Proxy Mobile IPv6 447 specification [ID-PMIP6] and as in this specification. 449 4. IPv4 Transport Support 451 As per the Proxy Mobile IPv6 specification [ID-PMIP6], the transport 452 network between the local mobility anchor and the mobile access 453 gateway is an IPv6 network. This specification defines extensions 454 for supporting the scenario where the local mobility anchor and the 455 mobile access gateway may be separated by an IPv4 transport network 456 and further these entities may be configured with IPv4 private 457 addresses and with NAT translation devices in the path. 459 When the network between the local mobility anchor and the mobile 460 access gateway is an IPv4 network, the mobile access gateway can 461 potentially register an IPv4 address with the local mobility anchor, 462 as the care-of address in the mobile node's binding cache entry and 463 thus creating an IPv4 tunnel for carrying all the mobile node's 464 traffic. 466 The DSMIPv6 specification [ID-DSMIP6] defines a solution for allowing 467 a mobile node to roam over an IPv4 network and the same solution can 468 be extended to Proxy Mobile IPv6. As explained in Section 4.1, of 469 the DSMIPv6 specification, a mobile access gateway can encapsulate a 470 Proxy Binding Update IPv6 message in an IPv4-UDP packet and route it 471 to the local mobility anchor. The processing logic and the on path 472 NAT detection logic is just as described in Section 4.3. The 473 signaling messages will always be IPv6 messages encapsulated in an 474 IPv4 packet and carried as an IPv4 packet. The data traffic to and 475 from the mobile node will also be encapsulated and carried as IPv4 476 packets. This specification does not cover the dynamic discovery of 477 the IPv4 address of the local mobility anchor (IPv4-LMAA) and thus it 478 is assumed that the mobile access gateway can learn this address from 479 the mobile node's policy profile or it can obtain this information 480 through other techniques that are beyond the scope of this document. 482 4.1. Mobility Options 484 For supporting IPv4 transport support, the following options are 485 required from the DSMIP6 specification [ID-DSMIP6]. 487 o NAT detection Option, defined in section 3.2.2 of the DSMIP 488 specification [ID-DSMIP6]. This option MUST be present in the 489 Proxy Binding Acknowledgment when the local mobility anchor 490 detects NAT in the path between mobile access gateway and itself. 492 4.2. Extensions to Conceptual Data Structure 494 There are certain extensions defined in DSMIP6 specification [ID- 495 DSMIP6] for supporting this feature. 497 4.3. NAT Detection 499 The NAT detection logic in Proxy Mobile IPv6 is just as specified in 500 DSMIP6 specification. 502 When the transport network between the local mobility anchor and the 503 mobile access gateway is an IPv4 network, the mobile access gateway 504 must send Proxy Binding Update message encapsulated in an IPv4-UDP 505 packet. On receiving this Proxy Binding Update packet encapsulated 506 in an IPv4-UDP packet, the local mobility anchor if it detects a NAT 507 on the path, will send the Proxy Binding Acknowledgment message with 508 the NAT Detection Option. The presence of this option in the Proxy 509 Binding Acknowledgment is an indication to the mobile access gateway 510 about the presence of NAT in the path. On detecting the NAT in the 511 path, both the local mobility anchor and the mobile access gateway 512 will set the encapsulation mode of the tunnel to IPv4-UDP. The 513 specific details around the NAT detection and the related logic is 514 described in in Dual Stack for Mobile IPv6 specification [ID-DSMIP6]. 516 4.4. Mobile Access Gateway Operation 518 o All the considerations as explained in Section 6.11 of the base 519 Proxy Mobile IPv6 specification apply here. 521 o If IPv4 transport support is enabled in order to place a mobile 522 access gateway at IPv4 only network, the mobile access gateway 523 MUST have an IPv4 address at the visiting network. In addition to 524 that, the mobile access gateway MUST also obtain IPv6 address 525 configured for the Proxy Mobile IPv6 operation. Even if the 526 mobile access gateway does not have connectivity to the IPv6 527 network, it MUST configure with an IPv6 address for sending the 528 proxy binding registration to the local mobility anchor. 530 o As explained in Section 4.1, of the DSMIPv6 specification, the 531 mobile access gateway can encapsulate a Proxy Binding Update 532 message and carry it in IPv4 and UDP packet. The processing logic 533 for handling the NAT detection at the mobile node is applicable to 534 the mobile access gateway as described in Section 4.3. An example 535 of proxy binding update sent by mobile access gateway is shown in 536 Figure 6. Note that the source address of the inner IPv6 header 537 MUST set to the IPv6 address assigned to the mobile access gateway 538 and the destination address MUST be the local mobility anchor's 539 IPv6 address (LMAA). The source address of the outer packet MUST 540 be the IPv4-proxy-CoA and the destination MUST be the local 541 mobility anchor's IPv4 address (IPv4-LMAA). For the NAT handling, 542 UDP header MUST be always used for the proxy binding update. The 543 UDP port number is defined in [ID-DSMIP6]. The proxy binding 544 update MUST be protected by IPsec ESP. The security association 545 for IPv4 addresses of the mobile access gateway and local mobility 546 anchor are pre-established. 548 IPv4 header (src=IPv4-proxy-CoA, dst=IPv4-LMAA) 549 UDP header 550 IPv6 header (src=v6MAG*, dst=LMAA) 551 Mobility header 552 -BU /*P flag is set*/ 553 Mobility Options 554 -HNP* /*IPv6 home address*/ 555 -TSO* 556 -IPv4-HAO /*if IPv4 HoA is required*/ 558 *HNP: Home Network Prefix Option 559 *TSO: Time Stamp Option 560 *v6MAG: IPv6 address assigned to the mobile access gateway. 562 Figure 6: Proxy Binding Update from mobile access gateway in IPv4 563 network 565 o After receiving a Proxy Binding Acknowledgment message 566 encapsulated in an IPv4 packet, the mobile access gateway MUST 567 verify the Proxy Binding Acknowledgment according to the Section 568 4.3 of DSMIP6 specification [ID-DSMIP6]. 570 o If the Status field indicates Success, the mobile access gateway 571 MUST setup a tunnel to the local mobility anchor and add a default 572 route over the tunnel for all the mobile node's IPv6 traffic. If 573 the NAT is available and the NAT detection option is presented in 574 the Proxy Binding Acknowledgment, the mobile access gateway MUST 575 use UDP tunnel to traverse the NAT and MUST send a proxy binding 576 update every refresh time specified in the NAT detection option. 577 The detailed operation can be found in DSMIP6 specification [ID- 578 DSMIP6]. 580 o If the Status field in the proxy binding acknowledgment indicates 581 the rejection of the binding registration, the mobile access 582 gateway MUST not enable IPv4 transport for the mobile node's 583 traffic. 585 o On receiving any packets from the mobile node's IPv6 home address 586 and/or IPv4 home address, the mobile access gateway tunnels the 587 packets to local mobility anchor as shown in Figure 7 588 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 589 UDP header /*Only if NAT is detected*/ 590 union { /*following either v6 or v4 header */ 591 IPv4 header (src=MN's IPv4-HoA, dst=IPv4 CN) 592 IPv6 header (src=MN's IPv6-HoA, dst=IPv6 CN) 593 } 594 Upper layer protocols /*TCP,UDP,SCTP*/ 596 Figure 7: Tunneled Packets from MAG to LMA 598 4.5. Local Mobility Anchor Operation 600 When a mobile node is attached to a mobile access gateway that is 601 reachable only through an IPv4 transport network, the local mobility 602 anchor must establish an IPv4 tunnel for routing the mobile node's 603 IPv4 and IPv6 home address traffic. The DSMIPv6 specification 604 provides the semantics on how the IPv4 tunnel needs to be negotiated 605 and the detection logic of the NAT devices. This specification 606 leverages the NAT Detection Option, defined in the DSMIP6 607 specification for the use in Binding Acknowledgment message and 608 extends it to Proxy Binding Acknowledgment messages. The operational 609 steps are defined below. 611 o Upon receiving a Proxy Binding Update message encapsulated in an 612 IPv4 packet, the local mobility anchor MUST send the Proxy Binding 613 Acknowledgment to the mobile access gateway's IPv4-Proxy-CoA by 614 using IPv4 encapsulation. If the NAT is detected, the NAT 615 detection option MUST be used in the Proxy Binding Acknowledgment. 616 How to detect NAT is described in Section 4.1 of [ID-DSMIP6] and 617 Section 4.3. 619 o An example of proxy binding acknowledgment sent by local mobility 620 anchor is shown below. The same illustration for Mobile IPv6 can 621 be found in Section 4.1 of [ID-DSMIP6]. The proxy binding 622 acknowledgment MUST be protected by IPsec ESP. The security 623 association for IPv4 addresses of the mobile access gateway and 624 local mobility anchor are pre-established. 626 IPv4 header (src=IPv4-LMAA, dst=IPv4-proxy-CoA) 627 UDP header /*Only if NAT is detected*/ 628 IPv6 header (src=LMAA, dst=v6MAG) 629 Mobility header 630 -BA /*P flag is set */ 631 Mobility Options 632 -HNP* /* IPv6-MN-HoA */ 633 -TSO* 634 -IPv4-ACK /* Only if IPv4 HoA is required */ 635 -NAT-DET /* Only if NAT is detected */ 637 *HNP: Home Network Prefix Option 638 *TSO: Time Stamp Option 639 *v6MAG: IPv6 address assigned to the mobile access gateway. 641 Figure 8: Proxy Binding Acknowledgment in IPv4 network 643 o After accepting the registration from the mobile access gateway 644 locating at the IPv4 only network, the local mobility anchor MUST 645 setup a tunnel to the mobile access gateway. The tunnel is 646 established between the v4-LMAA and the IPv4-Proxy-CoA of the 647 mobile access gateway. If the NAT is available and the NAT 648 detection option is included in the Proxy Binding Acknowledgment, 649 the local mobility anchor MUST use UDP encapsulation for the 650 tunnel. The local mobility anchor also setup a host routes for 651 the IPv4 home address and the IPv6 home address of the mobile node 652 over the tunnel to the mobile access gateway. Any traffic that 653 the local mobility anchor receives from a correspondent node will 654 be tunneled to the mobile access gateway over the bi-directional 655 tunnel and then routed accordingly after removing the tunnel 656 headers. The encapsulation modes for the bi-directional tunnel 657 may be as specified in Section 5.3 of Proxy Mobile IPv6 658 specification [ID-PMIP6] and as in this specification. 660 o When sending any packets meant to a mobile node's IPv4 home 661 address or IPv6 home address, the local mobility anchor tunnels 662 the packet to mobile access gateway as shown in Figure 9 664 IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) 665 UDP header /*Only if NAT is detected*/ 666 union { /*following either v6 or v4 header */ 667 IPv4 header (src=IPv4-CN, dst=IPv4-HoA) 668 IPv6 header (src=IPv6-CN, dst=IPv6-HoA) 669 } 670 Upper layer protocols /*TCP,UDP,SCTP*/ 672 Figure 9: Tunneled Packets from LMA to MAG 674 4.6. Tunnel Management 676 As specified in the Proxy Mobile IPv6 specification, the bi- 677 directional tunnel between the local mobility anchor and the mobile 678 access gateway, is a shared tunnel and all the considerations from 679 Section 6.6 of Proxy Mobile IPv6 [ID-PMIP6] apply for IPv4 transport 680 as well. 682 5. IANA Considerations 684 This document does not define any new messages. The UDP port number 685 for proxy binding update and acknowledgment will be defined in [ID- 686 DSMIP6]. 688 6. Security Considerations 690 This specification describes the use of IPv4 transport network 691 between the local mobility anchor and the mobile access gateway. All 692 the signaling messages exchanged between the mobile access gateway 693 and the local mobility anchor over the IPv4 transport MUST be 694 protected using IPsec, just as the messages must be protected when 695 using IPv6 transport and as specified in the Section 4.0, of the 696 Proxy Mobile IPv6 specification [ID-PMIP6]. 698 When supporting IPv4 address assignment from a DHCP server, the local 699 mobility anchor MUST be the prefix owner and the topological anchor 700 point for the address pools that are configured on the DHCP server 701 for allocation for the mobile nodes. 703 After receiving a Proxy Binding Update message with an IPv4 Home 704 Address Option, the local mobility anchor MUST be able to verify that 705 the mobile node is authorized to use that address before setting up 706 forwarding for that host route. 708 When supporting dynamic IPv4 address assignment by DHCP and also from 709 local mobility anchor, it should be ensured both the entities are 710 configured with different address pools, so as to avoid both entities 711 do not allocate the same address to different mobile nodes. 713 7. Contributors 715 This document reflects discussions and contributions from several 716 people (in alphabetical order): 718 Kuntal Chowdhury 720 kchowdhury@starentnetworks.com 722 Vijay Devarapalli 724 vijay.devarapalli@azairenet.com 726 Sangjin Jeong 728 sjjeong@gmail.com 730 Basavaraj Patil 732 basavaraj.patil@nsn.com 734 Myungki Shin 736 myungki.shin@gmail.com 738 8. Acknowledgments 740 The IPv4 support for Proxy Mobile IPv6 was initially covered in the 741 internet-draft [draft-sgundave-mip6-proxymip6-02.txt]. This document 742 leverages lot of text from that document. We would like to thank all 743 the authors of the document and acknowledge that initial work. 745 9. References 747 9.1. Normative References 749 [RFC-1332] McGregor, G., "The PPP Internet Protocol Control Protocol 750 (IPCP)", RFC 1332, May 1992. 752 [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 753 51, RFC 1661, July 1994. 755 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 756 Requirement Levels", BCP 14, RFC 2119, March 1997. 758 [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 759 2131, March 1997. 761 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 762 IPv6 Specification", RFC 2473, December 1998. 764 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 765 IPv6", RFC 3775, June 2004. 767 [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 768 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", 769 RFC 3776, June 2004. 771 [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 772 G., Liebsch, M., "Problem Statement for Network-based Localized 773 Mobility Management", September 2006. 775 [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 776 G., Liebsch, M., "Goals for Network-based Localized Mobility 777 Management", October 2006. 779 [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based 780 Localized Mobility Management", September 2006. 782 [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack 783 Hosts and Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-03.txt 784 ,October 2006. 786 [ID-MIP6-IKEV2] Devarapalli, V. and Dupont, F., "Mobile IPv6 787 Operation with IKEv2 and the revised IPsec Architecture", 788 draft-ietf-mip6-ikev2-ipsec-08.txt, December 2006. 790 [ID-PMIP6] Gundavelli, S., et.al, "Proxy Mobile IPv6", 791 draft-sgundave-mip6-proxymip6-02.txt, March 2007. 793 9.2. Informative References 795 [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 796 (IPv6) Specification", RFC 2460, December 1998. 798 [RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 799 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 801 [RFC-2462] Thompson, S., Narten, T., "IPv6 Stateless Address 802 Autoconfiguration", RFC 2462, December 1998. 804 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 805 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 806 RFC 3315, July 2003. 808 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 809 Internet Protocol", RFC 4301, December 2005. 811 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 812 4303, December 2005. 814 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 815 Protocol", RFC 4306, December 2005. 817 [ID-DSMIP6-PS] Tsirtsis, G., et.al, "Problem Statement: Dual Stack 818 Mobility", draft-ietf-mip6-dsmip-problem-03.txt, January 2007. 820 Authors' Addresses 822 Ryuji Wakikawa 823 Keio University 824 Department of Environmental Information, Keio University. 825 5322 Endo 826 Fujisawa, Kanagawa 252-8520 827 Japan 829 Email: ryuji@sfc.wide.ad.jp 831 Sri Gundavelli 832 Cisco 833 170 West Tasman Drive 834 San Jose, CA 95134 835 USA 837 Email: sgundave@cisco.com 839 Full Copyright Statement 841 Copyright (C) The IETF Trust (2007). 843 This document is subject to the rights, licenses and restrictions 844 contained in BCP 78, and except as set forth therein, the authors 845 retain all their rights. 847 This document and the information contained herein are provided on an 848 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 849 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 850 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 851 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 852 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 853 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 855 Intellectual Property 857 The IETF takes no position regarding the validity or scope of any 858 Intellectual Property Rights or other rights that might be claimed to 859 pertain to the implementation or use of the technology described in 860 this document or the extent to which any license under such rights 861 might or might not be available; nor does it represent that it has 862 made any independent effort to identify any such rights. Information 863 on the procedures with respect to rights in RFC documents can be 864 found in BCP 78 and BCP 79. 866 Copies of IPR disclosures made to the IETF Secretariat and any 867 assurances of licenses to be made available, or the result of an 868 attempt made to obtain a general license or permission for the use of 869 such proprietary rights by implementers or users of this 870 specification can be obtained from the IETF on-line IPR repository at 871 http://www.ietf.org/ipr. 873 The IETF invites any interested party to bring to its attention any 874 copyrights, patents or patent applications, or other proprietary 875 rights that may cover technology that may be required to implement 876 this standard. Please address the information to the IETF at 877 ietf-ipr@ietf.org. 879 Acknowledgment 881 Funding for the RFC Editor function is provided by the IETF 882 Administrative Support Activity (IASA).