idnits 2.17.00 (12 Aug 2021) /tmp/idnits10309/draft-premec-mip4-ip6-proxy-mip4-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 15. -- Found old boilerplate from RFC 3978, Section 5.3 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 672. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 656. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 662. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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: When the MS configures an additional IPv6 address, in order to verify its uniqueness it starts the DAD process by sending a Neighbor solicitation message to the solicited node multicast group. When the HA receives such a packet via the MIPv4 tunnel, it MUST not deliver it to the home link. Instead, the HA MUST perform proxy DAD on the home link for the address being verified. If the DAD is successful, the HA SHALL add the verified address to the binding cache entry for the MS and SHALL treat the newly configured IPv6 address as an additional home address of the MS. If the DAD process fails, the HA SHALL relay the received Neighbor advertisement to the MS via the MIPv4 tunnel. == 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 'SHALL not' in this paragraph: If there is no IPv6 code extension [Tsi2006] in the Registration response message or if the code value in the IPv6 code extension doesn't equal 1, the PMN SHALL not provide the MS with mobility service. -- 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 (June 19, 2006) is 5814 days in the past. Is this intentional? 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: 'Cal2002a' is mentioned on line 265, but not defined == Missing Reference: 'Cal2002b' is mentioned on line 572, but not defined == Unused Reference: 'Ark2005' is defined on line 578, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. 'Joh2004') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2461 (ref. 'Nar1998') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 3756 (ref. 'Nik2004') ** Obsolete normative reference: RFC 3344 (ref. 'Per2002') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 2462 (ref. 'Tho1998') (Obsoleted by RFC 4862) == Outdated reference: draft-leung-mip4-proxy-mode has been published as RFC 5563 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIP4 D. Premec 2 Internet Draft D. Damic 3 Expires: December 2006 Siemens Mobile 4 June 19, 2006 6 Mobility Management for IPv6 Hosts using Proxy Mobile IPv4 7 draft-premec-mip4-ip6-proxy-mip4-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 This document may only be posted in an Internet-Draft. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on December 19, 2006. 37 Abstract 39 The IPv6-based end-user device is commonly not able to utilize the 40 advantages introduced by the mobile IP protocols. However, this 41 specification describes how an end-user device supporting only IPv6 42 protocol stack may be provided with a mobility service by the mobile 43 IPv4-based access network. The unaltered end-user device relies on 44 the functionalities of the two network-side entities, the Home Agent 45 and the new Proxy Mobile Node, acting on its behalf and providing the 46 IP layer mobility management. 48 Conventions used in this document 50 Mobile station (MS) 52 Mobile station is an IPv6 host that can change its point of 53 attachment to the network. An MS does not implement the Mobile 54 IPv6 protocol nor is it a dual stack host. 56 Proxy Mobile Node (PMN) 58 Proxy mobile node is a function implemented by the access network. 59 Proxy mobile node performs mobile IPv4 signaling and traffic 60 tunneling on behalf of a MS. 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC-2119 [Bra1997]. 66 Table of Contents 68 1. Introduction...................................................3 69 1.1. Motivation................................................3 70 1.2. Goals.....................................................3 71 1.3. Overview of the Solution..................................4 72 1.4. Advantages................................................4 73 2. Operation......................................................5 74 2.1. Initial Network Entry.....................................5 75 2.2. Movement to a new PMN.....................................9 76 2.3. Address Lifetime.........................................10 77 3. Home Agent Considerations.....................................11 78 4. Proxy Mobile Node Considerations..............................12 79 5. Mobile Station Considerations.................................13 80 6. Foreign Agent Considerations..................................13 81 7. Security Considerations.......................................14 82 8. IANA Considerations...........................................14 83 9. Acknowledgments...............................................14 84 10. References...................................................14 85 10.1. Normative References....................................14 86 10.2. Informative References..................................15 87 Author's Addresses...............................................16 88 Intellectual Property Statement..................................16 89 Disclaimer of Validity...........................................17 90 Copyright Statement..............................................17 91 Acknowledgment...................................................17 93 1. Introduction 95 This specification describes how an end-user device supporting only 96 IPv6 protocol stack may be provided with a mobility service by the 97 mobile IPv4-based access network. The mobility management is handled 98 completely by the network without any involvement of the end-user 99 device. 101 1.1. Motivation 103 The operators of IPv4 networks are facing the problem of the shortage 104 of the IPv4 address space. One possibility to cope with this problem 105 is the introduction of NATs, but this approach is not ideal and has 106 its own set of issues. For example, some applications exchange the IP 107 addresses in the application layer payload. These addresses go 108 unnoticed by the NAT and are not rewritten, with the consequence that 109 the application fails. Such problems may be addressed by the 110 introduction of application layer gateways at the cost of additional 111 complexity. In this perspective, the deployment of IPv6, with its 112 huge address space, seems very appealing. 114 There is also a constant growth in the number of mobile devices 115 causing additional pressure on the already exhausted IPv4 address 116 space. These devices expect to be able to access the network from 117 anywhere, anytime and to provide the always-on experience. Those end- 118 user devices also require some form of mobility management. However, 119 most commercial operating systems available today don't provide any 120 form of mobility support at the IP layer. 122 Mobile IPv4 [Per2002] as a mobility management protocol is slowly 123 gaining momentum and operators are implementing networks based on it 124 - there is already a significant infrastructure in the deployment 125 supporting the mobile IPv4. 127 1.2. Goals 129 Goals of this specification are summarized below: 131 o To provide a network based mobility solution for IPv6 hosts 133 o IPv6 hosts doesn't implement whether IPv4 stack nor mobile IPv6 134 o Mobility management is based on mobile IPv4 136 o Mobility management is handled completely within the network, 137 without the involvement of the hosts 139 o IPv6 service for the hosts is provided exclusively by the home 140 network. Access network doesn't need to support IPv6 at all. 142 1.3. Overview of the Solution 144 When the access network detects an attachment of a new IPv6 device, 145 the PMN (Proxy Mobile Node) will register the device with the HA 146 using its own IPv4 care-of address. The IPv6 traffic of the MS will 147 consequently be tunneled between the PMN and the HA in the IPv4 148 tunnel. Tunnel end points are PMN itself and the HA. 150 IPv6 151 MS---IPv6----PMN------over-----------HA---IPv6 network 152 IPv4 154 Figure 1 Deployment example 156 The PMN is not processing IPv6 packets in any way besides tunneling 157 them between the HA and the MS. Thus, from the perspective of the MS, 158 the complete access network looks like a bridge, i.e. it appears to 159 be a single link layer connecting the MS with its HA. The MS can not 160 tell that it is not attached to its home link - in other words, it 161 believes to be attached directly to the HA. 163 When the MS moves to the new PMN, the new PMN will register its care- 164 of address with the HA, thus redirecting the MS traffic to itself. 166 1.4. Advantages 168 Advantages of the proposed solution are combination of advantages 169 listed in [Tsi2006] and [Leu2006]. They are briefly summarized below: 171 o Mobility support for unmodified IPv6 hosts 172 o Leverage the existing mobile IPv4 network infrastructure, allowing 173 the MIPv4-based access network to provide mobility service to IPv6 174 hosts 176 o Mobility management is handled completely within the network, 177 without the involvement of the hosts 179 o Reduced radio link consumption: no MIP signaling over the air and 180 no tunnel overhead over the air 182 o Network uses just a single mobility protocol to support both IPv4 183 and IPv6 hosts (protection of investment and reduction of 184 operating costs) 186 2. Operation 188 We assume a mobile IPv4-based access network. This access network is 189 connected to the router on the home network acting as a MIPv4 HA. The 190 HA is a dual stack node and is also acting as a default router on its 191 IPv6 link. 193 We introduce a new entity which is executing mobile IPv4 procedures 194 on behalf of the mobile node. We call this new entity a Proxy Mobile 195 Node (PMN). The PMN resides in the access network and is located on 196 the traffic path to the MS. 198 The PMN is assumed to have direct link layer connectivity (from the 199 perspective of the IP layer) with the MS. When the MS attaches to the 200 network, in the course of link establishment it will be 201 authenticated. During the authentication process, the access network 202 will learn the NAI of the MS, and the NAI must be made available to 203 the PMN. All these actions happen at the link layer, before any IP 204 layer connectivity. 206 2.1. Initial Network Entry 208 After the authentication and after the link layer connectivity is 209 successfully established, the MS, being an IPv6 host, will send a 210 Neighbor solicitation message on a newly established link to 211 configure its link local address. The following figure illustrates 212 the procedure in more detail: 214 MS PMN HA home 215 link 216 | link up | | | 217 1) <----------------> | | 218 | | | | 219 | NS(LLA) | | | 220 2) +--------------->| | | 221 | | | | 222 | | | | 223 3) | *** acq. CoA | | 224 | | | | 225 | | RegReq | | 226 4) | +----------------------> | 227 | | | | 228 | | RegResp | | 229 5) | <----------------------| | 230 | | | | 231 | | IP4[RA(home prefix)] | | 232 6) | <----------------------| | 233 | | | | 234 7) | RA(home prefix)| | | 235 <----------------+ | | 236 | | | | 237 8) | | IP4[NS(LLA)] | | 238 | +----------------------> | 239 | | | proxy | 240 9) | | *** DAD | 241 | | | | 242 | | | | 243 | | | | 244 | | | | 245 | | | | 246 | | | | 248 Figure 2 Initial network entry 250 1. In this step the link is established and the MS is authenticated. 251 The PMN SHALL learn the NAI of the MS in this step. 253 2. The MS sends the Neighbor solicitation to configure its link local 254 address. 256 3. When the Neighbor solicitation arrives at PMN, the PMN MAY detect 257 that this is an IPv6 packet. This MAY trigger the PMN to register 258 with the HA. First, the PMN MUST acquire the IPv4 address which it 259 will use as a care-of address for the MS. How exactly the PMN 260 acquires the IPv4 care-of address is not defined in this 261 specification, but typically the PMN may request the address from 262 the DHCPv4 server, or it can maintain its own address pool. 264 4. The PMN SHALL generate the MIPv4 Registration request using the 265 CoA obtained in step 3 and NAI [Cal2002a] learned during the 266 authentication. Further, the Registration request SHALL contain an 267 IPv6 tunneling mode extension requesting the IPv6 operation mode, 268 as defined in [Tsi2006]. The Registration request MAY also contain 269 an IPv6 prefix extension [Tsi2006]. 271 5. The HA SHALL create the binding between the MS, identified by its 272 NAI, and the CoA received in the Registration request. The HA 273 SHALL include the IPv6 code extension [Tsi2006] as a confirmation 274 that it supports tunneling of IPv6 traffic over MIPv4 tunnel. The 275 code filed in the extension SHALL be set to 1 indicating that the 276 traffic will be tunneled to the IPv4 CoA. When the PMN receives 277 the Registration reply, it creates a binding between the newly 278 established tunnel and the L2 link associated with the MS. 280 6. Immediately after sending the Registration reply, the HA SHOULD 281 send the Router advertisement over the newly established MIPv4 282 tunnel. The Router advertisement is encapsulated and sent to the 283 PMN. The inner header destination address is set to all-nodes-on- 284 the-link address and the Router advertisement message contains the 285 home link prefix in the prefix information option. The Router 286 advertisement also controls which kind of address configuration 287 the MS may use: stateless or stateful. 289 7. The PMN SHALL decapsulate and deliver any packets it receives via 290 the MIPv4 tunnel directly to the MS. In this step we see the 291 delivery of the Router advertisement sent by the HA. 293 8. After the MIPv4 tunnel is established, the PMN SHALL start 294 delivering the uplink traffic to the HA. Here the Neighbor 295 solicitation from step 2, which was delayed until the MIPv4 tunnel 296 was set up, is tunneled to the HA. 298 9. The arrival of a Neighbor solicitation message verifying the 299 tentative address SHALL trigger the HA to perform proxy DAD on 300 behalf of the MS [Joh2004]. Having successfully performed proxy 301 DAD, the HA SHALL deliver any traffic on the home link destined to 302 this address via the MIPv4 tunnel to the current location of the 303 MS. Every time the MS configures an additional IPv6 address, the 304 HA SHALL perform proxy DAD for this additional address and bind it 305 to the MIPv4 tunnel associated with the MS. 307 If the PMN is aware that the MS is an IPv6-only host, then the PMN 308 MAY initiate the setup of the MIPv4 tunnel immediately after the link 309 layer connection is successfully established. In other words, the 310 step 1 in the figure above may be followed by the step 3. This has 311 the advantage that the MIPv4 tunnel is setup in advance, before any 312 IPv6 traffic arrives at the PMN. The benefit is that the delay caused 313 by the tunnel setup is minimized. This is especially important 314 because the tunnel setup delay may influence the DAD process. 316 It is apparent from the discussion above that the IPv6 traffic is 317 tunneled between the PMN and the HA. Thus the whole access network 318 appears to the MS as a single link connected directly to its HA. The 319 MS is effectively deceived into believing that it is attached to its 320 home link. 322 The MS MAY use either stateful or stateless methods to configure its 323 home address. This specification doesn't mandate or prefer one method 324 over another and is compatible with both methods. Important point is 325 that whenever the MS configures an additional address, the HA SHALL 326 perform the proxy DAD for it and add it to its binding cache. 328 2.2. Movement to a new PMN 330 The following figure describes the sequence of events when the MS 331 moves to a new link which is associated with the new PMN. 333 MS nPMN oPMN HA home 334 link 335 | link up | context tx. | | | 336 1) <------------>|<-------------->| | | 337 | | | | | 338 | | | | | 339 2) | *** acq. CoA | | | 340 | | | | | 341 | | RegReq | | | 342 3) | +------------------------------> | 343 | | | | | 344 | | RegResp | | | 345 4) | <------------------------------| | 346 | | | | | 347 | | | RegRev | | 348 5) | | <-------------+ | 349 | | | | | 350 | | | RegRevAck | | 351 6) | | +-------------> | 352 | | | | | 353 | | | | | 354 | | | | | 356 Figure 3 Movement to a new PMN 358 1. In this step the MS changed its point of attachment to the 359 network. The new link layer connection with the new PMN (nPMN) is 360 established. It is assumed that during the link layer handover the 361 old PMN (oPMN) transfers the MS related context to the new PMN. 362 The context SHALL include at least the NAI and the current 363 sequence number used in MIPv4 Registration request messages. It 364 MAY also include any packets still buffered/arriving at the oPMN. 365 The protocol for exchanging context between PMNs is out of scope 366 of this specification 368 2. - 4. These steps are the same as steps 3-5 in the section 2.1. 370 5. When the HA receives a Registration request for a MS for which it 371 already has a binding cache entry, the HA SHOULD send the 372 Registration Revoke message to the previous mobility agent, i.e. 373 to the oPMN. This will expedite the release of resources at the 374 oPMN. The oPMN can safely remove all its resource associated with 375 the PMN since it now knows that it will not receive any further 376 traffic from the HA for this MS. The HA will perform steps 4. and 377 5. simultaneously. 379 6. The oPMN acknowledges to the HA the release of the MS related 380 resources. 382 From the message flow above, it is obvious that the MS itself is not 383 involved in the handover at all. In fact, from the perspective of the 384 MS nothing changed, the illusion that it is connected to its home 385 link is still being maintained by the network despite the fact that 386 the MS actually changed its point of attachment. 388 2.3. Address Lifetime 390 Lifetime of the IPv6 address assigned to the MS and the binding 391 lifetime held in the HA's MIPv4 context are not directly related to 392 each other. PMN SHALL refresh the mobility binding before it expires. 393 If the mobility binding ever expires, for whatever reason, both PMN 394 and the HA SHALL release all resources related to that mobility 395 binding. In case when the binding lifetime expires at the HA, the HA 396 MAY send the Registration Revocation to the PMN, to insure that the 397 PMN will also release its resources and that the state in both the HA 398 and the PMN is in sync. 400 The MS is expected to take care of the lifetime of its IPv6 address. 401 The HA SHALL be aware of the lifetimes of the IPv6 addresses assigned 402 to the MS. If the MS is allowed to autoconfigure [Tho1998] its IPv6 403 address, then the MIPv4 binding lifetime SHALL be limited by the HA 404 to be no more than the (remaining) lifetime of the prefix used for 405 IPv6 address autoconfiguration. The HA MAY act as the DHCPv6 relay 406 agent in order to learn the lifetimes of IPv6 addresses assigned by 407 means of DHCPv6. If the IPv6 address of the MS ever expires, the HA 408 SHALL stop defending it on the home link and SHALL remove it from its 409 binding cache entry. 411 3. Home Agent Considerations 413 The home agent MUST support Mobile IPv4 protocol [Per2002] and the 414 following extensions defined in [Tsi2006]: IPv6 tunneling mode 415 extension, IPv6 code extension and IPv6 prefix extension. 417 Home agent is a dual stack router supporting also IPv6. The home 418 agent MUST be configured with at least one 64-bit prefix which will 419 serve as the home link prefix. On the interface(es) advertising the 420 home link prefix, the HA provides the services of a default IPv6 421 router on the link. It also has the role of an IPv6 home agent 422 [Joh2004]: it MUST defend home address of the MS while it is away 423 from home, it MUST intercept its traffic and it MUST tunnel it via 424 the MIPv4 tunnel to the current location of the MS. When the HA 425 tunnels the packet to the PMN, the destination address of the outer 426 header is the registered IPv4 care-of address and the source address 427 is the HA's IPv4 address. The inner packet is the unmodified IPv6 428 datagram as captured on the home link. 430 The HA MUST provide the Mobile IPv4 service [Per2002] on at least one 431 interface which is connected to the IPv4 network. 433 When the MS configures an additional IPv6 address, in order to verify 434 its uniqueness it starts the DAD process by sending a Neighbor 435 solicitation message to the solicited node multicast group. When the 436 HA receives such a packet via the MIPv4 tunnel, it MUST not deliver 437 it to the home link. Instead, the HA MUST perform proxy DAD on the 438 home link for the address being verified. If the DAD is successful, 439 the HA SHALL add the verified address to the binding cache entry for 440 the MS and SHALL treat the newly configured IPv6 address as an 441 additional home address of the MS. If the DAD process fails, the HA 442 SHALL relay the received Neighbor advertisement to the MS via the 443 MIPv4 tunnel. 445 If the MS is allowed to autoconfigure its home address, then the HA 446 SHALL perform the proxy DAD for the home address of the MS 447 immediately after the DAD process for the link local address of the 448 MS is successfully over. The home address to be defended is 449 formulated by the HA using the home link prefix and the interface 450 identifier part of the LLA. This is because the IPv6 host is not 451 required to verify additionally configured addresses if they are 452 based on the same interface identifier used by the one of the already 453 verified addresses. 455 The HA MAY, at its own discretion, disallow the MS from configuring 456 and using a particular IPv6 address. When the HA receives the 457 Neighbor solicitation message verifying the tentative address, it MAY 458 reply to the MS with a Neighbor advertisement packet pretending that 459 the address being verified is already in use on the home link. This 460 will effectively block the MS from using the tentative address. 462 When the HA receives the packet via the MIPv4 tunnel, it MAY check 463 that the source IPv6 address of the inner packet is a legitimate 464 address that the MS is allowed to use. If this is not the case, the 465 HA SHALL discard the packet and SHALL terminate the mobility session 466 by sending the Registration revocation to the PMN. 468 The HA SHALL clear the on-link determination bit in prefix 469 information, thus preventing the MS to attempt the direct 470 communication with the correspondent nodes having the same prefix. 472 The HA SHALL be aware of the address lifetime of the home address 473 assigned to the MS. If the address lifetime expires, the HA SHALL 474 remove the expired address from its binding cache entry. 476 4. Proxy Mobile Node Considerations 478 When the PMN detects an IPv6-only MS on the link, the PMN SHALL 479 register the MS with the HA by sending the MIPv4 Registration request 480 message. The Registration request message shall contain the NAI of 481 the MS and the IPv6 tunneling mode extension as defined in 482 [Cal2002b]. 484 If there is no IPv6 code extension [Tsi2006] in the Registration 485 response message or if the code value in the IPv6 code extension 486 doesn't equal 1, the PMN SHALL not provide the MS with mobility 487 service. 489 The PMN SHALL decapsulate the packets received from the HA and SHALL 490 deliver the inner IPv6 packets to the MS. The PMN SHALL generate the 491 appropriate link layer header and prepend it to the IPv6 packets 492 delivered to the MS. 494 The PMN SHALL encapsulate the IPv6 packets received from the MS and 495 SHALL send them to the HA via the established MIPv4 tunnel. The 496 source address of the outer header is the registered IPv4 care-of 497 address and the destination address is the HA's IPv4 address. The 498 inner packet is the unmodified IPv6 datagram as received from the MS. 500 For the MS traffic, the PMN is acting as a link layer bridge. In 501 particular, the PMN SHALL never decrease the hop limit field in the 502 IPv6 header nor will it change any other field in the IPv6 header. 504 The PMN SHALL intercept Router advertisements sent by the HA and 505 inspect them before relaying them to the MS. If the Router 506 advertisement contains the source link layer address option, the PMN 507 SHALL use the advertised link layer address as the source address 508 when constructing the link layer header, provided that the underlying 509 link layer technology makes use of such an address. The intercepted 510 source LLA MAY be transferred during the handover to the new PMN as 511 part of the MS context, and the new PMN SHOULD use the transferred 512 link layer address when constructing the link layer header. 514 The PMN SHALL protect all MIPv4 signaling messages with the MN-HA 515 authentication extension. 517 5. Mobile Station Considerations 519 Mobile station is a plain IPv6 host, and it does not have a Mobile IP 520 stack. There are no additional requirements on the mobile station. 522 6. Foreign Agent Considerations 524 Solution described in this document supports the use of unmodified 525 foreign agents. To the FA, the PMN will appear as regular mobile 526 node. However, the use of FA will add an additional layer of 527 encapsulation. 529 If the PMN chooses to register with the FA, the PMN will provide its 530 IPv4 address as a care-of address and SHALL request the dynamic 531 assignment of its home address by setting the home address field in 532 Registration request to all zeros. The home address will be assigned 533 by the HA in the Registration response message. The home address may 534 be allocated from private address space and the FA may also implement 535 the support for overlapping address spaces as described in [Leu2006]. 537 When the PMN has an uplink packet to send, it will first encapsulate 538 it using the assigned IPv4 home address as the source address and the 539 HA's IPv4 address as the destination address. Then it will deliver 540 the encapsulated packet to the FA using either direct or encapsulated 541 delivery style [Mon2001]. Before sending the packet to the HA, the FA 542 will encapsulate the packet once again, using its CoA as a source 543 address and HoA address as a destination address. 545 Advantage of using the non-collocated CoA mode is that the number of 546 publicly routable IPv4 addresses is minimized: only one is needed per 547 FA instead of one per PMN. The disadvantage is that the FA will add 548 another layer of encapsulation when tunneling back to the HA. This 549 adds additional processing overhead and diminishes the MTU size. 551 7. Security Considerations 553 The security considerations mentioned in [Leu2006] also apply to this 554 specification. 556 According to this specification, IPv6 Neighbor discovery messages are 557 tunneled between the MS and the HA. A number of security concerns and 558 threats related to neighbor discovery protocol are listed in the 559 security considerations section of [Nar1998] and in the [Nik2004]. A 560 misbehaving MS can launch exactly the same attacks as the malicious 561 IPv6 host physically attached to its home link (wire), but not more. 562 In the view of the author, this specification does not introduce any 563 new threats related to ND. 565 8. IANA Considerations 567 There are no IANA issues in this document. 569 9. Acknowledgments 571 This specification is based on the discussions and work in the WiMAX 572 Forum as well as the drafts [Cal2002b], [Leu2006] and [Tsi2006]. 574 10. References 576 10.1. Normative References 578 [Ark2005] Arkko, J., Kempf, J., Zill, B., Nikander, P. "Secure 579 Neighbor Discovery (SEND)", RFC 3971, March 2005. 581 [Bra1997] Bradner, S., "Key words for use in RFCs to Indicate 582 Requirement Levels", BCP 14, RFC 2119, March 1997. 584 [Cal2002a]Calhoun, P. and C. Perkins, "Mobile IP Network Access 585 Identifier Extension for IPv4", RFC 2794, March 2000. 587 [Joh2004] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 588 IPv6", RFC 3775, June 2004 590 [Mon2001] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", 591 RFC 3024, January 2001. 593 [Nar1998] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 594 Discovery for IP Version 6 (IPv6)", RFC 2461, December 595 1998. 597 [Nik2004] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 598 Discovery (ND) Trust Models and Threats", RFC 3756, May 599 2004. 601 [Per2002] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 602 August 2002. 604 [Tho1998] S. Thomson, T. Narten, "IPv6 Stateless Address 605 Autoconfiguration", RFC 2462, December 1998 607 10.2. Informative References 609 [Cal2002b]Calhoun, P., Engelstad P., Hiller, T., and McCann P., "IPv6 610 over Mobile IPv4", draft-mccann-mobileip-ipv6mipv4-03.txt, 611 October 2002. 613 [Leu2006] Leung, K., Dommety, G., Yegani, P., "Mobility Management 614 using Proxy Mobile IPv4", draft-leung-mip4-proxy-mode- 615 00.txt, February 2006. 617 [Tsi2006] Tsirtsis, G., Soliman, H. and Park, V., "Dual Stack Mobile 618 IPv4", draft-tsirtsis-v4v6-mipv4-01.txt, April 2006. 620 Author's Addresses 622 Domagoj Premec 623 Siemens Mobile 624 Heinzelova 70a 625 10010 Zagreb 626 Croatia 628 Phone: +385.1.610 5293 629 Email: domagoj.premec@siemens.com 631 Damjan Damic 632 Siemens Mobile 633 Heinzelova 70a 634 10010 Zagreb 635 Croatia 637 Phone: +385.1.633 1337 638 Email: damjan.damic@siemens.com 640 Intellectual Property Statement 642 The IETF takes no position regarding the validity or scope of any 643 Intellectual Property Rights or other rights that might be claimed to 644 pertain to the implementation or use of the technology described in 645 this document or the extent to which any license under such rights 646 might or might not be available; nor does it represent that it has 647 made any independent effort to identify any such rights. Information 648 on the procedures with respect to rights in RFC documents can be 649 found in BCP 78 and BCP 79. 651 Copies of IPR disclosures made to the IETF Secretariat and any 652 assurances of licenses to be made available, or the result of an 653 attempt made to obtain a general license or permission for the use of 654 such proprietary rights by implementers or users of this 655 specification can be obtained from the IETF on-line IPR repository at 656 http://www.ietf.org/ipr. 658 The IETF invites any interested party to bring to its attention any 659 copyrights, patents or patent applications, or other proprietary 660 rights that may cover technology that may be required to implement 661 this standard. Please address the information to the IETF at 662 ietf-ipr@ietf.org. 664 Disclaimer of Validity 666 This document and the information contained herein are provided on an 667 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 668 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 669 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 670 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 671 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 672 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 674 Copyright Statement 676 Copyright (C) The Internet Society (2006). 678 This document is subject to the rights, licenses and restrictions 679 contained in BCP 78, and except as set forth therein, the authors 680 retain all their rights. 682 Acknowledgment 684 Funding for the RFC Editor function is currently provided by the 685 Internet Society.