MEXT Working Group D.Premec Internet Draft Nokia Siemens Networks Intended status: Informational October 27, 2008 Expires: April 2009 Extended Home Link Support for DSMIPv6 draft-premec-mext-extended-home-link-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 not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 April 27, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Premec Expires April 27, 2009 [Page 1] Internet-Draft Extended DSMIP6 home link support October 2008 Abstract Mobile IPv6 Support for Dual Stack Hosts and Routers requires that the mobile node's home link provides native dual stack support. This document relaxes this requirement and specifies how a DSMIP6-enabled mobile node can, with the help of its home agent, maintain connectivity for both of its home addresses while attached to a home link that supports only single IP family. Conventions used in this document 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 [RFC2119]. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................4 3. Example deployment configurations..............................4 4. Solution Overview..............................................7 4.1. Registration process on the home link.....................7 4.2. Registration process on the PMIP6 emulated home link......9 4.3. IPv4-only home link considerations.......................12 4.3.1. IPv4 home link detection............................12 4.3.2. Configuration of the IPv4 home address..............12 5. Protocol Operation............................................13 5.1. Mobile Node Considerations...............................13 5.2. HA/LMA Considerations....................................14 5.3. MAG Considerations.......................................15 6. Security Considerations.......................................15 7. IANA Considerations...........................................15 8. Acknowledgments...............................................16 9. References....................................................16 9.1. Normative References.....................................16 9.2. Informative References...................................16 Author's Addresses...............................................17 Intellectual Property Statement..................................17 Disclaimer of Validity...........................................17 Premec Expires April 27, 2009 [Page 2] Internet-Draft Extended DSMIP6 home link support October 2008 1. Introduction Mobile IPv6 Support for Dual Stack Hosts and Routers [Sol2008] requires that the mobile node's home link provides native dual stack support. In some deployments there may be a need for IPv4-only home link. This may be motivated by the transition scenario where the network that provides service to the mobile node is already connected to the IPv6 internet but is not yet able to offer the IPv6 service on the interface facing the mobile node. This may be due to the fact that the existing link-layer equipment between the home agent and the mobile node is not able to transport IPv6 datagrams. According to the DSMIP6 specification [Sol2008] the MN would have to treat such network as a foreign IPv4-only network. As a consequence the IPv4 traffic would have to be tunneled to the HA, incurring the tunneling overhead although the MN is actually at its home link. Similar concerns are valid for the IPv6-only home link. The operator's decision to offer only IPv6 service on the home link can be a result of the shortage of the public IPv4 addresses or because the operator wants to save the additional costs of operating a dual stack network. This document relaxes the requirement that the home link must provide dual stack support and specifies how a DSMIP6-enabled mobile node operates when attached to an IPv4-only or IPv6-only home link. In particular, this document allows a mobile node to register its IPv4 home address as a care-of address for its IPv6 home address and vice versa. Thus, when the mobile node is attached to a home link that supports only single IP family, there is no tunneling overhead associated with the mobile node's traffic of that same protocol family. Mobile node is still able to get the home address of other IP family and tunnel any datagrams using this home address over the home address that is natively supported on its home link. Section 3. of this specification discusses the envisioned deployment scenarios in more detail. Overview of a solution is provided in section 4. It is described how a DSMIP6-enabled mobile node that is attached to a foreign network returns to its IPv4-only or IPv6-only home link. Section 5. provides detailed requirements for mobile node and HA/LMA. Premec Expires April 27, 2009 [Page 3] Internet-Draft Extended DSMIP6 home link support October 2008 2. Terminology General mobility related terminology is defined in [RFC3775]. DSMIP6 related terminology is described in [Sol2008]. Additional PMIP6 specific terminology can be found in [RFC5213]. DSMIP6 Dual Stack Mobile IPv6 protocol specified in [Sol2008]. netlmm domain Network providing the network based IP mobility service as defined in [RFC5213]. PMIP6 Proxy Mobile IPv6 protocol specified in [RFC5213]. 3. Example deployment configurations This section describes some example scenarios where a DSMIP6-enabled home agent (HA) does not provide dual stack connectivity on the MN's home link. In such case the MN connected to its home link can send and receive natively datagrams using its on-link home address. A DSMIP6-enabled mobile node compliant with this specification is still able to obtain the home address of the other IP family and tunnel any traffic of that protocol family via its on-link home address. In one case the link-layer connection between the MN and the HA involves additional link-layer equipment and that equipment may not support transport of IPv6 datagrams. This configuration is shown in the figure 1: Premec Expires April 27, 2009 [Page 4] Internet-Draft Extended DSMIP6 home link support October 2008 IPv4/IPv6 internet | | +---+----+ | HA | +--------+ | | IPv4 link | +--+---+ | MN | +------+ Figure 1 Home link supports only IPv4 Although the MN is attached directly to its home link, the link type used by the MN's home network does not support the transport of IPv6 datagrams. However, the home network may have connectivity to both IPv4 and IPv6 internet on its northbound interface. Since the HA is a full fledged DSMIP6 HA, it can provide IPv6 home address and IPv6 connectivity service to the MN. In this case the IPv6 home link appears as a virtual home link to the MN and the IPv6 datagrams between the MN and the HA are tunneled in IPv4. As the MN is IPv4- wise at home, there is no tunnel overhead for the IPv4 traffic. The same considerations are valid for IPv6-only home link. The figure 2 illustrates a configuration where the network uses PMIP6 [RFC5213] to emulate the MN's home link. The network consists of several access networks (AN) of different types and some of the access networks are able to carry only IPv4 or only IPv6 datagrams. Premec Expires April 27, 2009 [Page 5] Internet-Draft Extended DSMIP6 home link support October 2008 IPv4/IPv6 internet | | +--------+ | HA/LMA | +--------+ / \ / \ / \ / \ / \ --------------/-----+ +--\------------- AN1 / ) ( \ AN2 +-----+ ) ( +-----+ IPv4 & | MAG | ) ( | MAG | IPv4 IPv6 +-----+ ) ( +-----+ only \ ) ( ---------------\----+ +---------------- \ \ \ \ \ +------+ | MN | +------+ Figure 2 netlmm domain with IPv4-only access networks In the figure 2 the home network consists of the access network AN1 and the HA/LMA. Home network is fully capable dual stack network. The HA/LMA located in the core network is connected to the IPv4/IPv6 internet. The complete transport path from the MN through the access network AN1 to the HA/LMA supports native IPv6 and IPv4 connectivity. In addition to the native access network AN1, there could be several other access networks that connect to the MN's core network. Some of those additional access networks may support only IPv4 on the interface facing the MN. In addition, those access networks may be interconnected to the MN's core network by means of PMIP6 protocol [RFC5213]. In this case, PMIP6 is used to emulate the MN's home link while the MN is attached through non-native access network. In the figure 2 the access network AN2 provides only IPv4 connectivity. When the MN attaches through AN2, its only on-link address is its IPv4 home address emulated by PMIP6 and any IPv6 traffic must be tunneled by the MN to the HA/LMA via a DSMIP6 tunnel. Again, the same considerations apply for the IPv6-only home link emulated by PMIP6. Premec Expires April 27, 2009 [Page 6] Internet-Draft Extended DSMIP6 home link support October 2008 4. Solution Overview This document relaxes the requirement from the DSMIP6 specification [Sol2008] that a home link must provide dual stack connectivity and proposes additional protocol semantics allowing a mobile node attached to its home link to register its on-link home address as a care-of address for its home address of another family. As a result there is no tunnel overhead for the traffic using the MN's on-link home address and the MN is able to obtain connectivity for its home address of another family by tunneling the packets via its on-link home address. This specification does not introduce any new elements to the DSMIP6 protocol, but it defines an additional semantics for some specific combinations of the home address and care-of address options. 4.1. Registration process on the home link Assume a mobile node has been configured with the following four addresses: v6HoA mobile node's IPv6 home address v4HoA mobile node's IPv4 home address v6HA home agent's IPv6 address v4HA home agent's IPv4 address and currently is located in an IPv6 foreign network using v6CoA mobile node's IPv6 care-of address The mobile node has, using DSMIP6, already made a registration with the home agent for both of its home addresses. There are now two movements to home, namely movement to an IPv4-only home network and movement to an IPv6-only home network. In the first case, where the mobile node returns home to an IPv4-only home network, the mobile node sends the following packet: IPv4 Header (src = v4HoA, dst = v4HA) UDP Header (src = dst = DSMIP port) IPv6 Header (src = v6HoA, dst = v6HA) ESP Header Premec Expires April 27, 2009 [Page 7] Internet-Draft Extended DSMIP6 home link support October 2008 Mobility Header type = 5 (Binding Update) lifetime non-zero IPv4 Home Address option (v4HoA) IPv4 Care-of Address option (v4HoA) Although it is guaranteed no NAT box is present on the home network, standard DSMIP6 UDP header is used. Because lifetime is non-zero, the home agent will first consider this a registration, but because the IPv4 home address and the IPv4 care-of address options are identical, it knows the mobile node is at its IPv4 home. Until now the mobile node has been located at v6CoA, the home agent considers this a movement, where IPv4 traffic is now to be considered at home, whereas IPv6 traffic is to be 6in4 tunneled. The home agent sends the following response: IPv4 Header (src = v4HA, dst = v4HoA) UDP Header (src = dst = DSMIP port) IPv6 Header (src = v6HA, dst = v6HoA) ESP Header Mobility Header type = 6 (Binding Acknowledgement) lifetime non-zero IPv4 Address Acknowledgement option (v4HoA) In the second case, where the mobile node returns home to an IPv6- only home network, the mobile node sends the following packet: IPv6 Header (src = v6HoA, dst = v6HA) ESP Header Mobility Header type = 5 (Binding Update) lifetime non-zero Alternate Care-of Address option (v6HoA) IPv4 Home Address option (v4HoA) Again, because the lifetime is non-zero, the home agent will first consider this to be a new registration, but because the alternate care-of address is the same as the source address found in the IPv6 header, and no destination option is present in the packet, it knows the mobile node is at its IPv6 home. The IPv4 home address option is then used to create a 4in6 tunnel. The home agent sends the following response: IPv6 Header (src = v6HA, dst = v6HoA) ESP Header Premec Expires April 27, 2009 [Page 8] Internet-Draft Extended DSMIP6 home link support October 2008 Mobility Header type = 6 (Binding Acknowledgement) lifetime non-zero IPv4 Address Acknowledgement option (v4HoA) The packet exchanges above used for returning to an IPv4-only home link and IPv6-only home link are also used when the mobile node boots in an IPv4-only or IPv6-only network, or when makes a re-registration to extend the lifetime. They are also to be used when it is attached to the native dual home network, and discovers one of the address families no longer work. When later the mobile node discovers both address families are again available, the mobile node sends a binding update with lifetime set to zero. 4.2. Registration process on the PMIP6 emulated home link Detailed description of interworking scenarios between PMIP and Mobile IPv6, related issues and solution approaches is provided in [Gia2008]. This section analyses specific scenarios where the mobile node moves to its IPv4-only or IPv6-only home link. Of particular interest here are scenarios where the binding cache entry for IPv4 home address does not exist yet or is under the control of a MAG while the binding cache entry for the IPv6 home address is updated by the mobile node. Note that such scenarios where the IPv4 home address is under the control of a mobile node while IPv6 home address is controlled by the MAG are not considered in [Gia2008]. We start with the same set of assumptions regarding the mobile node's current location and the registration state with the home agent as in section 4.1. The difference is that the mobile node's home link is emulated by the PMIP6 protocol and the LMA is collocated with the mobile node's home agent. We assume that link between the MAG and the LMA supports IPv6 (it could be IPv4 as well, the link type between the MAG and the LMA does not affect discussion presented here). In addition, the MAG is configured with: v6PCoA proxy care-of address of the MAG Since the LMA is collocated with the home agent, we shall use the v6HA and the v4HA as the addresses of the LMA. When the mobile node attaches to the PMIP emulated IPv4-only home link, the MAG sends the following packet to the LMA: IPv6 header (src=v6PCoA, dst=v6HA) Mobility header type = 5 (Binding Update, P flag set) Premec Expires April 27, 2009 [Page 9] Internet-Draft Extended DSMIP6 home link support October 2008 lifetime non-zero Mobile Node Identifier option (MN-NAI) Handoff Indicator option = 1 (attach. over a new interface) Access Technology Type option IPv4 Home Address option (0.0.0.0) When the LMA receives the Proxy binding update message it checks if there is an active binding for the MN's IPv4 home address. If the HA/LMA has no binding for the home address requested in the PBU message, the LMA processes the PBU message as per [RFC5213]. If the binding for the IPv4 home address exists already, the HA/LMA creates a new BCE in response to the PBU and marks it as a shadow binding cache entry. The IPv4 home address in the shadow BCE is the same as the IPv4 home address in the active BCE. The LMA responds to the MAG in the same way as if it had created a regular (non-shadow) binding cache entry. As long as there is an active binding cache entry that was created by the MN, the shadow BCE remains inactive and is not used to deliver the packets to the MN. The LMA sends the following response to the MAG: IPv6 header (src=v6HA, dst=v6PCoA) Mobility header type = 6 (Binding Acknowledgement, P flag set) lifetime non-zero Mobile Node Identifier option (MN-NAI) Handoff Indicator option = 1 (attach. over a new interface) Access Technology Type option IPv4 Home Address option (v4HoA) The resulting binding cache entries at the HA/LMA looks like this: v6HoA -> v6CoA updated by the MN v4HoA -> v6CoA updated by the MN v4HoA -> v6PCoA shadow, created by the MAG After the MAG learns the MN's home address from the PBAck, it is able to offer it to the MN during the configuration of the MN's on-link address. When the MN realizes that it is on its IPv4-only home link it deregisters its v4HoA as described in the section 4.1. When the HA/LMA receives the request from the MN to deregister the IPv4 home address, it SHALL deprecate the corresponding binding cache entry and activate the shadow binding cache entry that was created by the MAG, which results in the following binding cache entries: Premec Expires April 27, 2009 [Page 10] Internet-Draft Extended DSMIP6 home link support October 2008 v6HoA -> v4HoA updated by the MN v4HoA -> v6PCoA updated by the MAG The MN's IPv4 traffic is tunneled between the MAG and the LMA in the PMIP6 tunnel. The MN's IPv6 traffic is double tunneled: first by the mobile node to its v4HoA and then via the PMIP6 tunnel to the v6HA. Note that different lifetimes may be associated with the binding cache entries holding the v6HoA and the v4HoA. Upon the MN's attachment to its IPv6-only home link, the MAG sends the following packet to the LMA: IPv6 header (src=v6PCoA, dst=v6HA) Mobility header type = 5 (Binding Update, P flag set) lifetime non-zero Home Network Prefix option (::) Mobile Node Identifier option (MN-NAI) Handoff Indicator option = 1 (attach. over a new interface) Access Technology Type option Again the LMA is not allowed to update the existing binding for the MN's v6HoA, instead it applies the same mechanism as described for the attachment to the PMIP emulated IPv4-only home link and creates a shadow binding cache entry for the MN's v6HoA. This results in the following binding cache entries: V4HoA -> v6CoA updated by the MN v6HoA -> v6CoA updated by the MN v6HoA -> v6PCoA shadow, crated by the MAG The LMA responds to the MAG with: IPv6 header (src=v6HA, dst=v6PCoA) Mobility header type = 6 (Binding Acknowledgement, P flag set) lifetime non-zero Mobile Node Identifier option (MN-NAI) Handoff Indicator option = 1 (attach. over a new interface) Access Technology Type option Home Network Prefix option (HNP) Having acquired the MN's home network prefix, the MAG advertises it to the MN. When the MN detects that it is IPv6-wise at its home link, it deregisters the binding for its IPv6 home address while at the same time registering the IPv6 home address as the care-of address Premec Expires April 27, 2009 [Page 11] Internet-Draft Extended DSMIP6 home link support October 2008 for its IPv4 home address as described in section 4.1. The LMA activates the shadow binding cache entry upon the deregistration of the IPv6 home address by the mobile node. The resulting binding cache entries look like this: V4HoA -> v6HoA updated by the MN v6HoA -> v6PCoA updated by the MAG 4.3. IPv4-only home link considerations This section discusses some additional considerations that are applicable only for the operation on the IPv4-only home link. IPv6 only home link uses the methods described in [Sol2008]. 4.3.1. IPv4 home link detection The mobile node SHALL use the home link detection methods described here only if the link to be tested is an IPv4-only link. If the link supports IPv6 the mobile node MUST use the home link detection methods described in [Sol2008]. The method by which the mobile node detects whether the link is an IPv4-only link is outside the scope of this specification. The mobile node MAY detect that it is attached to its IPv4 home link by comparing its IPv4 home address with its IPv4 on-link address. If both addresses are the same, or if they both belong to the same subnet, then the mobile node is attached to its home link. It is also possible that the IPv4 home link detection occurs as part of the registration process with the home agent. This will be the case when the mobile node sends initial Binding update message registering its current on-link address as the care-of address and at the same time asking for dynamic assignment of IPv4 home address. In this case the Binding Acknowledgment message indicating success MAY contain the IPv4 home address assignment option [Sol2008] carrying the same address as the mobile node's current on-link address, which tells the MN that it is attached to its IPv4 home link. 4.3.2. Configuration of the IPv4 home address The mobile node MAY learn its IPv4 home address in a dynamic manner either through the IKEv2 configuration payload when establishing the mobile IPv6 security associations with the HA [RFC4877] or through the IPv4 address acknowledgment option contained in a Binding Acknowledgment message [Sol2008]. The home agent MAY assign an IPv4 home address to the mobile node that is the same as the mobile node's current on-link IPv4 address. Regardless of the method how the mobile Premec Expires April 27, 2009 [Page 12] Internet-Draft Extended DSMIP6 home link support October 2008 node learned its IPv4 home address, it MUST remember the subnet mask associated with its IPv4 home. 5. Protocol Operation This specification does not make any changes to the Mobile IP message format, but it does introduce new semantics for some of the existing mobility options. In particular, this specification allows both the IPv4 care-of address option and the IPv4 home address option in the Binding update message to be set to the same value. It also allows the home agent to allocate an IPv4 home address to the mobile node that is the same as the mobile node's current care-of address. Further, a mobile node is allowed to send a Binding Update message with a non-zero lifetime where both the home address and the care-of addresses are the same, provided that such Binding update message also contains the home address of the other IP family. 5.1. Mobile Node Considerations When a DSMIP6-enabled mobile node is connected to an IPv4-only home link, it MAY register its IPv4 home address as the care-of address for its IPv6 home address by setting the IPv4 home address option and IPv4 care-of address option in the Binding Update message to the same value. When a DSMIP6-enabled mobile node is connected to an IPv6-only home link, it MAY register its IPv6 home address as the care-of address for its IPv4 home address by including the IPv4 Home address option in the Binding update message and setting the care-of address in the Binding Update message to its IPv6 home address. A mobile node MAY ask a home agent for a dynamic IPv4 home address assignment through IKEv2 configuration payload during the establishment of a mobile IPv6 security association [RFC4877]. A mobile node SHALL accept an IPv4 home address assigned by the home agent that is the same as its current on-link IPv4 address. If the mobile node's IPv4 home address is the same as its on-link address, the mobile node is IPv4-wise on its home link and it SHALL NOT maintain a Binding update list entry for its IPv4 home address. The mobile node SHALL remove the pending Binding update list entry for an IPv4 home address that was created when the Binding update message was sent if the Binding acknowledgment message indicates that the mobile node is IPv4-wise at its home link. Premec Expires April 27, 2009 [Page 13] Internet-Draft Extended DSMIP6 home link support October 2008 If the mobile node registered its IPv4 home address as a care-of address for its IPv6 home address, the mobile node SHALL maintain a Binding update list entry for the IPv6 home address containing the IPv4 home address as the care-of address. The same rule applies when the IPv6 home address is used as the care-of address for the IPv4 home address. Upon attaching to the home link, the mobile node SHALL deregister its home address that is of the same family (IPv4/IPv6) as its home link by sending the Binding update message containing the home address and care-of address set to the MN's on-link IP address. The MN MAY include the home address option of a different protocol family then its home link type in the Binding update message in which case the mobile node is at the same time registering this home address with its current on-link address. 5.2. HA/LMA Considerations If the mobile node asked the HA for a dynamic assignment of an IPv4 home address and if the HA detects that the mobile node is on its IPv4 home link, the home agent MAY select the mobile node's home address to be the same as the mobile node's on-link IPv4 address. The home agent MAY deliver the IPv4 home address to the mobile node either as part of the IKEv2 configuration payload or in the IPv4 home address acknowledgment option [Sol2008] as part of the Binding Acknowledgment message. If the mobile node's current care-of address as received in the Binding update message equals the mobile node's home address of the same protocol family, the home agent SHALL remove the binding cache entry for that home address. If the home address of another protocol family was included in the same Binding update message, the home agent SHALL update the binding cache entry for that home address as per [RFC3775] and [Sol2008]. When the mobile node registers its home address in one protocol family as a care-of address for a home address of another protocol family, the HA/LMA SHALL intercept the traffic destined to the mobile node's registered home address and tunnel it to the mobile node's home address of another protocol family. In case when there is a Proxy binding cache entry for one of the mobile node's home addresses, the traffic will be double tunneled: first to the mobile node's home address and then to the proxy care-of address of the MAG. When the LMA receives the Proxy binding update message for the MN and if there is an active binding that was created by the MN for the home address of the same address family as requested in the PBU, the Premec Expires April 27, 2009 [Page 14] Internet-Draft Extended DSMIP6 home link support October 2008 HA/LMA creates a new BCE based on the PBU and marks it as a shadow binding cache entry. The home address in the shadow BCE is the copied over from the existing BCE. The LMA responds to the MAG in the same way as if it had created a regular (non-shadow) binding cache entry. As long as there is an active binding cache entry that was created by the MN, the shadow BCE remains inactive. If the LMA doesn't receive a deregistration for a home address for which it has created a shadow binding cache entry within a reasonable amount of time, the LMA SHALL send the Binding revocation to the MAG to revoke the proxy binding for this home address. Upon completion of the Binding revocation procedure both the MAG and the LMA release their proxy bindings for the revoked home address. As a general consideration, the HA/LMA SHALL NOT delete the binding cache entry immediately upon processing of a deregistration message, instead, the HA/LMA SHALL mark the binding cache entry as deprecated and start the MinDelayBeforeBCEDelete timer as described in [RFC5213]. The HA/LMA SHALL delete the binding cache entry if no mobility message related to that binding cache entry was received before the timer expires. This consideration applies to both deregistration messages sent by the MAG as well as to deregistration messages sent by the MN. 5.3. MAG Considerations If MAG does not support IPv6 service on the interface facing the mobile node, the MAG SHALL NOT include the Home network prefix option in the Proxy Binding update message. If MAG does not support IPv4 service on the interface facing the mobile node, the MAG SHALL NOT include the IPv4 home address option in the Proxy Binding update message. 6. Security Considerations This document recommends that the same level of security is applied to the packets sent natively to/from the mobile node's on-link home address and to the packets on the virtual home link that are tunneled to the mobile node's on-link home address. TBD 7. IANA Considerations None. Premec Expires April 27, 2009 [Page 15] Internet-Draft Extended DSMIP6 home link support October 2008 8. Acknowledgments The author would like to thank Christian Kaas-Petersen for a detailed review and contributions to this document. This document was prepared using 2-Word-v2.0.template.dot. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [Sol2008] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-05.txt, July 2008. [RFC3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Ed., "Proxy Mobile IPv6", RFC 5213, August 2008 9.2. Informative References [RFC4877] Devarapalli, V., Dupont, F., "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007 [Gia2008] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", draft-giaretta-netlmm-mip- interactions-02, May 2008. Premec Expires April 27, 2009 [Page 16] Internet-Draft Extended DSMIP6 home link support October 2008 Author's Addresses Domagoj Premec Nokia Siemens Networks Heinzelova 70a 10000 Zagreb Croatia Email: domagoj.premec.ext@nsn.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. 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, THE IETF TRUST 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. Premec Expires April 27, 2009 [Page 17] Internet-Draft Extended DSMIP6 home link support October 2008 Copyright Statement Copyright (C) The IETF Trust (2008). 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 Expires April 27, 2009 [Page 18]