MIP4 D. Premec Internet Draft D. Damic Expires: December 2006 Siemens Mobile June 19, 2006 Mobility Management for IPv6 Hosts using Proxy Mobile IPv4 draft-premec-mip4-ip6-proxy-mip4-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 19, 2006. Abstract The IPv6-based end-user device is commonly not able to utilize the advantages introduced by the mobile IP protocols. However, this specification describes how an end-user device supporting only IPv6 protocol stack may be provided with a mobility service by the mobile IPv4-based access network. The unaltered end-user device relies on the functionalities of the two network-side entities, the Home Agent Premec, Damic Expires Dec 19, 2006 [Page 1] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 and the new Proxy Mobile Node, acting on its behalf and providing the IP layer mobility management. Conventions used in this document Mobile station (MS) Mobile station is an IPv6 host that can change its point of attachment to the network. An MS does not implement the Mobile IPv6 protocol nor is it a dual stack host. Proxy Mobile Node (PMN) Proxy mobile node is a function implemented by the access network. Proxy mobile node performs mobile IPv4 signaling and traffic tunneling on behalf of a MS. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [Bra1997]. Table of Contents 1. Introduction...................................................3 1.1. Motivation................................................3 1.2. Goals.....................................................3 1.3. Overview of the Solution..................................4 1.4. Advantages................................................4 2. Operation......................................................5 2.1. Initial Network Entry.....................................5 2.2. Movement to a new PMN.....................................9 2.3. Address Lifetime.........................................10 3. Home Agent Considerations.....................................11 4. Proxy Mobile Node Considerations..............................12 5. Mobile Station Considerations.................................13 6. Foreign Agent Considerations..................................13 7. Security Considerations.......................................14 8. IANA Considerations...........................................14 9. Acknowledgments...............................................14 10. References...................................................14 10.1. Normative References....................................14 10.2. Informative References..................................15 Author's Addresses...............................................16 Intellectual Property Statement..................................16 Premec, Damic Expires Dec 19, 2006 [Page 2] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 Disclaimer of Validity...........................................17 Copyright Statement..............................................17 Acknowledgment...................................................17 1. Introduction This specification describes how an end-user device supporting only IPv6 protocol stack may be provided with a mobility service by the mobile IPv4-based access network. The mobility management is handled completely by the network without any involvement of the end-user device. 1.1. Motivation The operators of IPv4 networks are facing the problem of the shortage of the IPv4 address space. One possibility to cope with this problem is the introduction of NATs, but this approach is not ideal and has its own set of issues. For example, some applications exchange the IP addresses in the application layer payload. These addresses go unnoticed by the NAT and are not rewritten, with the consequence that the application fails. Such problems may be addressed by the introduction of application layer gateways at the cost of additional complexity. In this perspective, the deployment of IPv6, with its huge address space, seems very appealing. There is also a constant growth in the number of mobile devices causing additional pressure on the already exhausted IPv4 address space. These devices expect to be able to access the network from anywhere, anytime and to provide the always-on experience. Those end- user devices also require some form of mobility management. However, most commercial operating systems available today don't provide any form of mobility support at the IP layer. Mobile IPv4 [Per2002] as a mobility management protocol is slowly gaining momentum and operators are implementing networks based on it - there is already a significant infrastructure in the deployment supporting the mobile IPv4. 1.2. Goals Goals of this specification are summarized below: o To provide a network based mobility solution for IPv6 hosts o IPv6 hosts doesn't implement whether IPv4 stack nor mobile IPv6 Premec, Damic Expires Dec 19, 2006 [Page 3] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 o Mobility management is based on mobile IPv4 o Mobility management is handled completely within the network, without the involvement of the hosts o IPv6 service for the hosts is provided exclusively by the home network. Access network doesn't need to support IPv6 at all. 1.3. Overview of the Solution When the access network detects an attachment of a new IPv6 device, the PMN (Proxy Mobile Node) will register the device with the HA using its own IPv4 care-of address. The IPv6 traffic of the MS will consequently be tunneled between the PMN and the HA in the IPv4 tunnel. Tunnel end points are PMN itself and the HA. IPv6 MS---IPv6----PMN------over-----------HA---IPv6 network IPv4 Figure 1 Deployment example The PMN is not processing IPv6 packets in any way besides tunneling them between the HA and the MS. Thus, from the perspective of the MS, the complete access network looks like a bridge, i.e. it appears to be a single link layer connecting the MS with its HA. The MS can not tell that it is not attached to its home link - in other words, it believes to be attached directly to the HA. When the MS moves to the new PMN, the new PMN will register its care- of address with the HA, thus redirecting the MS traffic to itself. 1.4. Advantages Advantages of the proposed solution are combination of advantages listed in [Tsi2006] and [Leu2006]. They are briefly summarized below: o Mobility support for unmodified IPv6 hosts Premec, Damic Expires Dec 19, 2006 [Page 4] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 o Leverage the existing mobile IPv4 network infrastructure, allowing the MIPv4-based access network to provide mobility service to IPv6 hosts o Mobility management is handled completely within the network, without the involvement of the hosts o Reduced radio link consumption: no MIP signaling over the air and no tunnel overhead over the air o Network uses just a single mobility protocol to support both IPv4 and IPv6 hosts (protection of investment and reduction of operating costs) 2. Operation We assume a mobile IPv4-based access network. This access network is connected to the router on the home network acting as a MIPv4 HA. The HA is a dual stack node and is also acting as a default router on its IPv6 link. We introduce a new entity which is executing mobile IPv4 procedures on behalf of the mobile node. We call this new entity a Proxy Mobile Node (PMN). The PMN resides in the access network and is located on the traffic path to the MS. The PMN is assumed to have direct link layer connectivity (from the perspective of the IP layer) with the MS. When the MS attaches to the network, in the course of link establishment it will be authenticated. During the authentication process, the access network will learn the NAI of the MS, and the NAI must be made available to the PMN. All these actions happen at the link layer, before any IP layer connectivity. 2.1. Initial Network Entry After the authentication and after the link layer connectivity is successfully established, the MS, being an IPv6 host, will send a Neighbor solicitation message on a newly established link to configure its link local address. The following figure illustrates the procedure in more detail: Premec, Damic Expires Dec 19, 2006 [Page 5] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 MS PMN HA home link | link up | | | 1) <----------------> | | | | | | | NS(LLA) | | | 2) +--------------->| | | | | | | | | | | 3) | *** acq. CoA | | | | | | | | RegReq | | 4) | +----------------------> | | | | | | | RegResp | | 5) | <----------------------| | | | | | | | IP4[RA(home prefix)] | | 6) | <----------------------| | | | | | 7) | RA(home prefix)| | | <----------------+ | | | | | | 8) | | IP4[NS(LLA)] | | | +----------------------> | | | | proxy | 9) | | *** DAD | | | | | | | | | | | | | | | | | | | | | | | | | Figure 2 Initial network entry 1. In this step the link is established and the MS is authenticated. The PMN SHALL learn the NAI of the MS in this step. 2. The MS sends the Neighbor solicitation to configure its link local address. Premec, Damic Expires Dec 19, 2006 [Page 6] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 3. When the Neighbor solicitation arrives at PMN, the PMN MAY detect that this is an IPv6 packet. This MAY trigger the PMN to register with the HA. First, the PMN MUST acquire the IPv4 address which it will use as a care-of address for the MS. How exactly the PMN acquires the IPv4 care-of address is not defined in this specification, but typically the PMN may request the address from the DHCPv4 server, or it can maintain its own address pool. 4. The PMN SHALL generate the MIPv4 Registration request using the CoA obtained in step 3 and NAI [Cal2002a] learned during the authentication. Further, the Registration request SHALL contain an IPv6 tunneling mode extension requesting the IPv6 operation mode, as defined in [Tsi2006]. The Registration request MAY also contain an IPv6 prefix extension [Tsi2006]. 5. The HA SHALL create the binding between the MS, identified by its NAI, and the CoA received in the Registration request. The HA SHALL include the IPv6 code extension [Tsi2006] as a confirmation that it supports tunneling of IPv6 traffic over MIPv4 tunnel. The code filed in the extension SHALL be set to 1 indicating that the traffic will be tunneled to the IPv4 CoA. When the PMN receives the Registration reply, it creates a binding between the newly established tunnel and the L2 link associated with the MS. 6. Immediately after sending the Registration reply, the HA SHOULD send the Router advertisement over the newly established MIPv4 tunnel. The Router advertisement is encapsulated and sent to the PMN. The inner header destination address is set to all-nodes-on- the-link address and the Router advertisement message contains the home link prefix in the prefix information option. The Router advertisement also controls which kind of address configuration the MS may use: stateless or stateful. 7. The PMN SHALL decapsulate and deliver any packets it receives via the MIPv4 tunnel directly to the MS. In this step we see the delivery of the Router advertisement sent by the HA. 8. After the MIPv4 tunnel is established, the PMN SHALL start delivering the uplink traffic to the HA. Here the Neighbor solicitation from step 2, which was delayed until the MIPv4 tunnel was set up, is tunneled to the HA. Premec, Damic Expires Dec 19, 2006 [Page 7] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 9. The arrival of a Neighbor solicitation message verifying the tentative address SHALL trigger the HA to perform proxy DAD on behalf of the MS [Joh2004]. Having successfully performed proxy DAD, the HA SHALL deliver any traffic on the home link destined to this address via the MIPv4 tunnel to the current location of the MS. Every time the MS configures an additional IPv6 address, the HA SHALL perform proxy DAD for this additional address and bind it to the MIPv4 tunnel associated with the MS. If the PMN is aware that the MS is an IPv6-only host, then the PMN MAY initiate the setup of the MIPv4 tunnel immediately after the link layer connection is successfully established. In other words, the step 1 in the figure above may be followed by the step 3. This has the advantage that the MIPv4 tunnel is setup in advance, before any IPv6 traffic arrives at the PMN. The benefit is that the delay caused by the tunnel setup is minimized. This is especially important because the tunnel setup delay may influence the DAD process. It is apparent from the discussion above that the IPv6 traffic is tunneled between the PMN and the HA. Thus the whole access network appears to the MS as a single link connected directly to its HA. The MS is effectively deceived into believing that it is attached to its home link. The MS MAY use either stateful or stateless methods to configure its home address. This specification doesn't mandate or prefer one method over another and is compatible with both methods. Important point is that whenever the MS configures an additional address, the HA SHALL perform the proxy DAD for it and add it to its binding cache. Premec, Damic Expires Dec 19, 2006 [Page 8] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 2.2. Movement to a new PMN The following figure describes the sequence of events when the MS moves to a new link which is associated with the new PMN. MS nPMN oPMN HA home link | link up | context tx. | | | 1) <------------>|<-------------->| | | | | | | | | | | | | 2) | *** acq. CoA | | | | | | | | | | RegReq | | | 3) | +------------------------------> | | | | | | | | RegResp | | | 4) | <------------------------------| | | | | | | | | | RegRev | | 5) | | <-------------+ | | | | | | | | | RegRevAck | | 6) | | +-------------> | | | | | | | | | | | | | | | | Figure 3 Movement to a new PMN 1. In this step the MS changed its point of attachment to the network. The new link layer connection with the new PMN (nPMN) is established. It is assumed that during the link layer handover the old PMN (oPMN) transfers the MS related context to the new PMN. The context SHALL include at least the NAI and the current sequence number used in MIPv4 Registration request messages. It MAY also include any packets still buffered/arriving at the oPMN. The protocol for exchanging context between PMNs is out of scope of this specification 2. - 4. These steps are the same as steps 3-5 in the section 2.1. Premec, Damic Expires Dec 19, 2006 [Page 9] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 5. When the HA receives a Registration request for a MS for which it already has a binding cache entry, the HA SHOULD send the Registration Revoke message to the previous mobility agent, i.e. to the oPMN. This will expedite the release of resources at the oPMN. The oPMN can safely remove all its resource associated with the PMN since it now knows that it will not receive any further traffic from the HA for this MS. The HA will perform steps 4. and 5. simultaneously. 6. The oPMN acknowledges to the HA the release of the MS related resources. From the message flow above, it is obvious that the MS itself is not involved in the handover at all. In fact, from the perspective of the MS nothing changed, the illusion that it is connected to its home link is still being maintained by the network despite the fact that the MS actually changed its point of attachment. 2.3. Address Lifetime Lifetime of the IPv6 address assigned to the MS and the binding lifetime held in the HA's MIPv4 context are not directly related to each other. PMN SHALL refresh the mobility binding before it expires. If the mobility binding ever expires, for whatever reason, both PMN and the HA SHALL release all resources related to that mobility binding. In case when the binding lifetime expires at the HA, the HA MAY send the Registration Revocation to the PMN, to insure that the PMN will also release its resources and that the state in both the HA and the PMN is in sync. The MS is expected to take care of the lifetime of its IPv6 address. The HA SHALL be aware of the lifetimes of the IPv6 addresses assigned to the MS. If the MS is allowed to autoconfigure [Tho1998] its IPv6 address, then the MIPv4 binding lifetime SHALL be limited by the HA to be no more than the (remaining) lifetime of the prefix used for IPv6 address autoconfiguration. The HA MAY act as the DHCPv6 relay agent in order to learn the lifetimes of IPv6 addresses assigned by means of DHCPv6. If the IPv6 address of the MS ever expires, the HA SHALL stop defending it on the home link and SHALL remove it from its binding cache entry. Premec, Damic Expires Dec 19, 2006 [Page 10] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 3. Home Agent Considerations The home agent MUST support Mobile IPv4 protocol [Per2002] and the following extensions defined in [Tsi2006]: IPv6 tunneling mode extension, IPv6 code extension and IPv6 prefix extension. Home agent is a dual stack router supporting also IPv6. The home agent MUST be configured with at least one 64-bit prefix which will serve as the home link prefix. On the interface(es) advertising the home link prefix, the HA provides the services of a default IPv6 router on the link. It also has the role of an IPv6 home agent [Joh2004]: it MUST defend home address of the MS while it is away from home, it MUST intercept its traffic and it MUST tunnel it via the MIPv4 tunnel to the current location of the MS. When the HA tunnels the packet to the PMN, the destination address of the outer header is the registered IPv4 care-of address and the source address is the HA's IPv4 address. The inner packet is the unmodified IPv6 datagram as captured on the home link. The HA MUST provide the Mobile IPv4 service [Per2002] on at least one interface which is connected to the IPv4 network. 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. If the MS is allowed to autoconfigure its home address, then the HA SHALL perform the proxy DAD for the home address of the MS immediately after the DAD process for the link local address of the MS is successfully over. The home address to be defended is formulated by the HA using the home link prefix and the interface identifier part of the LLA. This is because the IPv6 host is not required to verify additionally configured addresses if they are based on the same interface identifier used by the one of the already verified addresses. The HA MAY, at its own discretion, disallow the MS from configuring and using a particular IPv6 address. When the HA receives the Neighbor solicitation message verifying the tentative address, it MAY Premec, Damic Expires Dec 19, 2006 [Page 11] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 reply to the MS with a Neighbor advertisement packet pretending that the address being verified is already in use on the home link. This will effectively block the MS from using the tentative address. When the HA receives the packet via the MIPv4 tunnel, it MAY check that the source IPv6 address of the inner packet is a legitimate address that the MS is allowed to use. If this is not the case, the HA SHALL discard the packet and SHALL terminate the mobility session by sending the Registration revocation to the PMN. The HA SHALL clear the on-link determination bit in prefix information, thus preventing the MS to attempt the direct communication with the correspondent nodes having the same prefix. The HA SHALL be aware of the address lifetime of the home address assigned to the MS. If the address lifetime expires, the HA SHALL remove the expired address from its binding cache entry. 4. Proxy Mobile Node Considerations When the PMN detects an IPv6-only MS on the link, the PMN SHALL register the MS with the HA by sending the MIPv4 Registration request message. The Registration request message shall contain the NAI of the MS and the IPv6 tunneling mode extension as defined in [Cal2002b]. 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 PMN SHALL decapsulate the packets received from the HA and SHALL deliver the inner IPv6 packets to the MS. The PMN SHALL generate the appropriate link layer header and prepend it to the IPv6 packets delivered to the MS. The PMN SHALL encapsulate the IPv6 packets received from the MS and SHALL send them to the HA via the established MIPv4 tunnel. The source address of the outer header is the registered IPv4 care-of address and the destination address is the HA's IPv4 address. The inner packet is the unmodified IPv6 datagram as received from the MS. For the MS traffic, the PMN is acting as a link layer bridge. In particular, the PMN SHALL never decrease the hop limit field in the IPv6 header nor will it change any other field in the IPv6 header. Premec, Damic Expires Dec 19, 2006 [Page 12] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 The PMN SHALL intercept Router advertisements sent by the HA and inspect them before relaying them to the MS. If the Router advertisement contains the source link layer address option, the PMN SHALL use the advertised link layer address as the source address when constructing the link layer header, provided that the underlying link layer technology makes use of such an address. The intercepted source LLA MAY be transferred during the handover to the new PMN as part of the MS context, and the new PMN SHOULD use the transferred link layer address when constructing the link layer header. The PMN SHALL protect all MIPv4 signaling messages with the MN-HA authentication extension. 5. Mobile Station Considerations Mobile station is a plain IPv6 host, and it does not have a Mobile IP stack. There are no additional requirements on the mobile station. 6. Foreign Agent Considerations Solution described in this document supports the use of unmodified foreign agents. To the FA, the PMN will appear as regular mobile node. However, the use of FA will add an additional layer of encapsulation. If the PMN chooses to register with the FA, the PMN will provide its IPv4 address as a care-of address and SHALL request the dynamic assignment of its home address by setting the home address field in Registration request to all zeros. The home address will be assigned by the HA in the Registration response message. The home address may be allocated from private address space and the FA may also implement the support for overlapping address spaces as described in [Leu2006]. When the PMN has an uplink packet to send, it will first encapsulate it using the assigned IPv4 home address as the source address and the HA's IPv4 address as the destination address. Then it will deliver the encapsulated packet to the FA using either direct or encapsulated delivery style [Mon2001]. Before sending the packet to the HA, the FA will encapsulate the packet once again, using its CoA as a source address and HoA address as a destination address. Premec, Damic Expires Dec 19, 2006 [Page 13] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 Advantage of using the non-collocated CoA mode is that the number of publicly routable IPv4 addresses is minimized: only one is needed per FA instead of one per PMN. The disadvantage is that the FA will add another layer of encapsulation when tunneling back to the HA. This adds additional processing overhead and diminishes the MTU size. 7. Security Considerations The security considerations mentioned in [Leu2006] also apply to this specification. According to this specification, IPv6 Neighbor discovery messages are tunneled between the MS and the HA. A number of security concerns and threats related to neighbor discovery protocol are listed in the security considerations section of [Nar1998] and in the [Nik2004]. A misbehaving MS can launch exactly the same attacks as the malicious IPv6 host physically attached to its home link (wire), but not more. In the view of the author, this specification does not introduce any new threats related to ND. 8. IANA Considerations There are no IANA issues in this document. 9. Acknowledgments This specification is based on the discussions and work in the WiMAX Forum as well as the drafts [Cal2002b], [Leu2006] and [Tsi2006]. 10. References 10.1. Normative References [Ark2005] Arkko, J., Kempf, J., Zill, B., Nikander, P. "Secure Neighbor Discovery (SEND)", RFC 3971, March 2005. [Bra1997] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Premec, Damic Expires Dec 19, 2006 [Page 14] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 [Cal2002a]Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [Joh2004] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004 [Mon2001] Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [Nar1998] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [Nik2004] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [Per2002] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [Tho1998] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998 10.2. Informative References [Cal2002b]Calhoun, P., Engelstad P., Hiller, T., and McCann P., "IPv6 over Mobile IPv4", draft-mccann-mobileip-ipv6mipv4-03.txt, October 2002. [Leu2006] Leung, K., Dommety, G., Yegani, P., "Mobility Management using Proxy Mobile IPv4", draft-leung-mip4-proxy-mode- 00.txt, February 2006. [Tsi2006] Tsirtsis, G., Soliman, H. and Park, V., "Dual Stack Mobile IPv4", draft-tsirtsis-v4v6-mipv4-01.txt, April 2006. Premec, Damic Expires Dec 19, 2006 [Page 15] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 Author's Addresses Domagoj Premec Siemens Mobile Heinzelova 70a 10010 Zagreb Croatia Phone: +385.1.610 5293 Email: domagoj.premec@siemens.com Damjan Damic Siemens Mobile Heinzelova 70a 10010 Zagreb Croatia Phone: +385.1.633 1337 Email: damjan.damic@siemens.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Premec, Damic Expires Dec 19, 2006 [Page 16] Internet-Draft IPv6 over Proxy MIPv4 Jun 2006 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Premec, Damic Expires Dec 19, 2006 [Page 17]