NETLMM Working Group D.Premec Internet Draft Nokia Siemens Networks Intended status: Informational T.Savolainen Expires: October 2008 Nokia April 26, 2008 Inter-technology handover in netlmm domain draft-premec-netlmm-intertech-handover-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 October 26, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Premec Expires October 26, 2008 [Page 1] Internet-Draft PMIP6 inter-tech handover April 2008 Abstract Proxy Mobile IPv6 specification [Gun2008] describes a network based mobility management protocol which provides IP mobility service to a host in a way which is transparent to the host itself. This document analyses the scenario in which the MN equipped with multiple network interfaces roams in a netlmm domain consisting of several access networks. If the MN wants to preserve IP session continuity across different network interfaces as it moves from one access network to another it needs to be enhanced with a new, netlmm-specific functionality. 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....................................................3 3. Problem statement..............................................4 4. Possible solutions.............................................9 4.1. netlmm service availability...............................9 4.2. MN's enhancements for netlmmm ............................9 4.3. Movement of IP sessions across interfaces................11 5. Router Solicitation message extension.........................12 6. Mobile Node Operation.........................................13 7. Mobile Access Gateway Operation...............................14 8. LMA operation.................................................14 9. Other Considerations..........................................15 9.1. Support for IPv4.........................................15 9.1.1. Overlapping private address spaces..................15 9.1.2. IPv4 address configuration and indication of PMIP support....................................................15 9.2. MTU size.................................................16 9.3. Zero physical interfaces available.......................16 10. Security Considerations......................................17 11. IANA Considerations..........................................17 12. Acknowledgments..............................................17 13. References...................................................17 Premec Expires October 26, 2008 [Page 2] Internet-Draft PMIP6 inter-tech handover April 2008 13.1. Normative References....................................17 13.2. Informative References..................................18 Author's Addresses...............................................18 Intellectual Property Statement..................................19 Disclaimer of Validity...........................................19 1. Introduction NETLMM working group develops a network based mobility management protocol called Proxy Mobile IPv6 [Gun2008]. The goal of the Proxy Mobile IPv6 protocol is to provide IP mobility service to hosts which are not Mobile IP capable. One of the key objectives of the netlmm protocol is that network based IP mobility service is provided in a manner that is transparent to the hosts. According to base PMIP6 specification, an unmodified host can roam within a netlmm domain and retain its IP address and IP session continuity as it moves within the PMIP6 domain. This document presents a scenario where the host with multiple network interfaces attaches to the netlmm domain consisting of multiple access networks. If the host wants to retain IP session continuity as it handoffs from one access network to another, we show that the host has to be enhanced with netlmm specific capabilities. Section 3 presents a detailed discussion of the scenario and the related issues. Section 4 analyses possible solutions. Section 5 shows changes for Router Solicitation message. Section 6, 7 and 8 describe operational changes to Mobile Node, Mobile Access Gateway, and Local Mobility Anchor. Section 9 lists other considerations and future research needs identified this far. 2. Terminology General mobility related terminology is defined in [RFC3775]. Additional PMIP6 specific terminology can be found in [Gun2008]. netlmm domain Network providing the network based IP mobility service as defined in [Gun2008]. PMIP6 Proxy Mobile IPv6 protocol specified in [Gun2008]. Premec Expires October 26, 2008 [Page 3] Internet-Draft PMIP6 inter-tech handover April 2008 3. Problem statement According to the base PMIP6 specification [Gun2008], a netlmm domain is defined as a network which provides network based IP mobility service by deploying the PMIP6 protocol and where the security association between MAGs and LMAs can be set up. Such broad definition allows a netlmm domain to consist of several access networks of different types. A host attaching to such netlmm domain may have multiple network interface cards (WiFi, 3G, WiMAX, etc.), one for each different radio access technology. The basic premise of the netlmm protocol is that the host roaming in a netlmm domain is provided with IP session continuity in a manner transparent to the host. However, this is not true any more if the host is equipped with multiple network interface cards and if the netlmm domain comprises several access networks of different technology types. This network configuration is illustrated by the following figure: +--------+ | HA/LMA | +--------+ / \ / \ / \ / \ / \ --------------/-----+ +-\-------------- / ) ( \ RAN1 +------+ ) ( +------+ RAN2 | MAG1 | ) ( | MAG2 | +------+ ) ( +------+ \ ) ( / ---------------\----+ +----/----------- \ / \ / \ / \ / | | +-|---|-+ |IF1 IF2| | MN | +-------+ Figure 1 netlmm domain with multiple access networks Premec Expires October 26, 2008 [Page 4] Internet-Draft PMIP6 inter-tech handover April 2008 In such scenario the host can handoff between the adjacent MAGs located at the boundaries of different access networks. The scenario analyzed here assumes that the host does not want to use both interfaces simultaneously for independent IP sessions. Instead the host wants to move its existing IP sessions from one interface to another at time of its choosing. We assume that the host first attaches to the netlmm domain via the MAG1 located in the access network RAN1. As the host moves, it may come into an area covered by the access network RAN2 and may decide to attach to it. However, the attach decision does not necessarily imply immediate interest of moving existing IP sessions from RAN1 to RAN2. The attachment may be done only as an initial preparation for faster future movement of IP sessions. The decision to switch IP sessions to RAN2 is an implementation dependent and may be based on the number of different reasons like for example deteriorating radio signal quality from RAN1 or various policy reasons like price, quality of service, available bandwidth, etc. The following figure shows in more detail how the attachment procedure to RAN2 will happen. Unmodified host is assumed and the goal is to preserve host's IP session continuity. Premec Expires October 26, 2008 [Page 5] Internet-Draft PMIP6 inter-tech handover April 2008 MN MAG1 MAG2 LMA IF1 IF2 | | | | | 1) |<-----L2 link------>|<==========PMIP tunnel===========>| | | | | | | | | | | 2) | |<---------L2 link---------------->| | | | | | PBU | 3) | | | |--------------->| | | | | | | | | | PBAck | 4) | | | |<---------------| | | | | | 5) | | | |<==PMIP tunnel=>| | | | | | | | RS | | | 6) | |--------------------------------->| | | | | | | | | MLD(JOIN) | | | 7) | |--------------------------------->| | | | | | | | | DAD(LLA) | | | 8) | |--------------------------------->| | | | | | | | | RA(HNP) | | | 9) | |<---------------------------------| | | | | | | | | DAD(HNP) | | | 10) | |--------------------------------->| | | | | | | | | | | | | | | | | Figure 2 Multihomed MN moving between different RANs 1. This step shows the MN is connected to MAG1 and there is a PMIP6 tunnel between MAG1 and the LMA 2. MN attaches to MAG2 through its second interface. Depending on the access technology used in RAN2, it is possible that MN configures different Interface Identifier for the second interface than what is used in the first interface. Premec Expires October 26, 2008 [Page 6] Internet-Draft PMIP6 inter-tech handover April 2008 3. Triggered by the link establishment event the MAG2 sends the PBU to the LMA. MAG2 indicates the access technology type in the PBU and sets handoff indicator to the "handoff state unknown". The legacy MN attaching to MAG2 will not be able to provide any hint as to how the handoff indicator should be set. 4. LMA detects an existing binding of the MN. The binding contains an access technology type that is different from the one received in the PBU message. If the LMA wants to give MN a chance to move its existing IP sessions to a new interface, it must send to the MAG2 the existing HNP from the MN's binding cache entry. If LMA returns a different HNP, the MN will have to configure an address that is different from the address configured on its interface to MAG1, and will thus not be able to move its IP sessions from one interface to another. For detailed description of rules how the LMA selects a prefix consult [Gun2008] section 5.4. 5. This step shows the MAG2 to LMA tunnel is established. The LMA no longer retains the tunnel to MAG1. 6. Triggered by the step 2, the MN sends a Router Solicitation message. 7. Triggered by the step 2, the MN sends the MLD report message to join the solicited node multicast group. 8. Triggered by the step 2, the MN autoconfigures a link-local address and starts a DAD process. 9. Triggered by the step 4, MAG2 advertises the HNP to the MN. 10.MN autoconfigures the address based on the HNP received in the RA message and the Interface Identifier selected for the interface. Although the advertised prefix is the same on both interfaces, the address autoconfigured by host on the interface facing the MAG2 is either truly different, or considered logically different by the host software, from the address configured on its interface connected to MAG1. This is to comply with the basic rules of IP networking: an IP address can not be assigned to more then one interface. Some existing host implementations are less strict and actually allow configuration of the same IP address to multiple interfaces, but in that case consider IP addresses being overlapping and logically different from each other, and thus do not allow movement of sessions from one interface to another. The host starts a DAD procedure for its newly configured address. Premec Expires October 26, 2008 [Page 7] Internet-Draft PMIP6 inter-tech handover April 2008 The precondition for the host to move IP sessions from one interface to another is that it is able to configure the same IP address for both interfaces and it considers the same IP address in multiple interfaces actually being logically the same address (host supports multihoming on different access technologies with single IP address). The above steps show that unmodified legacy host will not be able to move its IP sessions even if the same prefix is available in both access networks. In fact, there is a serious flaw resulting from the above message sequence. The host still has connectivity to MAG1 and may still send packets via the interface connected to MAG1. MAG1 will tunnel the packets to the LMA, but the LMA will drop them as in its binding cache entry the authorized tunnel source is now MAG2. Any packets the MN transmits over MAG1 will be dropped by the network and no indication will be sent to the MN. Because of this the baseline document does not allow the LMA to return the same HNP to a new MAG in a different access network unless the LMA is sure that the MN intends to perform handover across interfaces. LMA relies on the handoff indication to know that the MN is capable of moving its IP session across interfaces. In case that the access technology type in the PBU message is different from the one saved in the binding cache entry, LMA will know that the MN attached to MAG2 over a different interface. In this case the LMA may return the same HNP in the PBAck message only if the handoff indicator in the PBU message indicates handoff between two different interfaces. It is the responsibility of the MAG to provide the correct handoff indication, but how does the MAG know? This document recommends that the MAG must get this indication from the MN itself. Consequently, the MN that wants to retain its IP address as it moves from one access network to another in a netlmm domain must be enhanced with netlmm specific functionality, and in particular it must be able to do the following: o detect that it is located in a netlmm domain o indicate to the MAG its support for moving of IP sessions across interfaces o support moving of IP session across interfaces Premec Expires October 26, 2008 [Page 8] Internet-Draft PMIP6 inter-tech handover April 2008 4. Possible solutions This subsection introduces several different mechanisms that, when put to work together, address the issue of moving the IP sessions across interfaces. 4.1. netlmm service availability The network can indicate to the MN that it is providing the netlmm service in any of the following ways: o Extension of Router Advertisement message Router Advertisement message can be extended to carry the information about the availability of the netlmm service. This is described in more detail in [Dam2008]. Advantage of such IP-layer based mechanism is that it is available irrespective of link-layer technology and requires no support or modification of the underlying link-layer(s). o Extensions of the link-layer A link-layer technology used in a netlmm domain could be extended to carry the indication of the availability of the netlmm service. This approach enables the MN to learn the network's netlmm capability during the link setup phase. On the other side, it requires changes to the underlying link-layer technologies and is based on a tight coupling between the IP and the link layer. o Advertising the same prefix in different access networks If the MN receives Router Advertisement messages over different interfaces carrying the same prefix, it may take this as an indication of the netlmm service availability in the network. This is an implicit indication and is error prone because such solution can not differentiate between the netlmm domain and multi-link subnets [RFC4903]. Advantage is that it does not require any changes to the messages. This document recommends the mechanism based on the extension of Router Advertisement message. This mechanism provides an explicit indication, it is backwards compatible with legacy hosts and it is independent of the link-layer technology. 4.2. MN's enhancements for netlmmm When the MN roaming in a netlmm domain decides to move its IP sessions from one access network to another, it needs a mechanism by Premec Expires October 26, 2008 [Page 9] Internet-Draft PMIP6 inter-tech handover April 2008 which it can inform the network about its intention to move its IP sessions across interfaces. The MAG uses this indication from the MN to fill in the Handoff Indicator option in the PBU message. o Extension of Router Solicitation message A Router Solicitation message can be extended with a new flag indicating that the MN wants to move its IP session across interfaces. Usage of Router Solicitation message requires that MAG waits for a Router Solicitation message from the MN before it can send a PBU message to the LMA with the correct handoff indicator. This is different from the baseline spec [Gun2008] where it is assumed that the sending of PBU message is triggered by the link establishment event. o Extensions of the link-layer The underlying link-layer can be extended to carry the indication of the MN's netlmm capability to the MAG. This solution introduces tight coupling between the IP layer and the link-layer and requires changes to link layer technologies used with the PMIP6 protocol. o Same interface identifier across access networks This approach is suggested in the [Lag2008]. The idea is that the MN will use the same interface identifier in both access networks if it wants to move its IP session across interfaces. A MAG in a new access network is assumed to acquire the MN's interface identifier during the link establishment phase through link specific mechanisms. A MAG is also assumed to obtain an interface identifier that the MN was using at a previous MAG and the access technology type through context transfer between MAGs or some other unspecified mechanisms. If access technology type is different and the interface identifier is the same in both access networks than the new MAG should take that as an indication of the MN's capability and intention to move its IP sessions across interfaces. In this case the MAG would always set the handoff indicator in the PBU message to the value "2: Handoff between two different interfaces of the mobile node". This solution is partly based on a link-layer as the MAG learns the MN's interface identifier during the link layer establishment. Note that there are link layers which do not allow for MAC address negotiation and where the MAC address assigned to the device is authenticated by the certificate and thus can not be changed. One example of such link layer is IEEE 802.16 defined in [IEEE802.16] and [IEEE802.16e]. This document recommends the mechanism based on the extension of Router Solicitation message. This mechanism provides an explicit Premec Expires October 26, 2008 [Page 10] Internet-Draft PMIP6 inter-tech handover April 2008 indication, it is backwards compatible with legacy hosts, it is independent of the link-layer technology, it allows arbitrarily long temporal separation of access network attachment and session movement, and does not require any changes to the already deployed equipment. 4.3. Movement of IP sessions across interfaces Some aspects of the procedure described here are internal to the MN and as such they are implementation dependent and may be implemented differently than shown here. The MN initiates the PMIP6 handover across interfaces by sending a Router Solicitation message with a flag indicating that it wants to move its IP sessions across interfaces. The target access network to which the IP sessions will be moved is the access network where the Router Solicitation message was sent. The MAG SHOULD respond with the Router Advertisement message containing netlmm specific extensions as described in [Dam2008]. The MN SHOULD detect that it is in a netlmm domain by looking for a N flag in a Flags Expansion option in a Router Advertisement message. If during the initial network attachment the MN detects that it is attaching to a netlmm domain, it SHOULD instantiate a virtual interface and associate it with a physical interface used to attach to the network. The address configured using the HNP from the Router Advertisement message SHOULD NOT be assigned to the physical interface used to attach to the netlmm domain. Instead, it SHOULD be assigned to the virtual interface. Any packets that the MN sends over this virtual interface SHOULD be delivered to the network over the associated physical interface. Any packets the MN receives over the physical interface SHOULD be delivered to the IP layer over the associated virtual interface. When the MN attaches to the netlmm domain over its second interface, it SHOULD send a Router Solicitation message over this interface. The Router Solicitation message SHOULD include the indication that the MN wants to move its IP sessions across interfaces, but if MN wants to postpone movement of its IP sessions, it MAY leave this indication out from initial Router Solicitation. If the Router Advertisement message indicates that the network supports netlmm service and the HNP advertised in the Router Advertisement message is the same as the MN is using on its virtual interface, the MN SHOULD associate its virtual interface with the newly configured physical interface. The switch of the virtual interface's association to the newly configured physical interface accomplishes the movement of IP sessions from one access network to another, preserving the IP sessions. Premec Expires October 26, 2008 [Page 11] Internet-Draft PMIP6 inter-tech handover April 2008 After associating the virtual interface with the newly configured physical interface, the MN MAY bring down the physical interface previously associated with the virtual interface. The MN may decide to remain attached at a link layer to both access networks. In such case the MN can move its IP sessions back and forth between the access networks without first performing a network entry in the target access network. In order to initiate the switch of its IP sessions to another access network, the MN SHALL send a Router Solicitation message in the target access network and the flag requesting the movement of IP sessions in the Router Solicitation message SHALL be set. 5. Router Solicitation message extension A new 'P' flag is added to the Router Solicitation message specified in [RFC4861] indicating that the host supports netlmm specific enhancement specified in this document. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Figure 3. P flag in the Router Solicitation ICMP Fields: Type 133 Code 0 Checksum The ICMP checksum. See [RFC4443] C flag C bit is introduced in [Dam2008]. If it is set, it indicates that the MN is capable of performing its own mobility management. Premec Expires October 26, 2008 [Page 12] Internet-Draft PMIP6 inter-tech handover April 2008 P flag If this bit is set, it indicates that the MN supports the netlmm specific enhancements specified in this document. In particular, by setting this bit the sending node indicates that it is both capable and willing of moving its IP session across interfaces. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. The MN implementing the P flag SHOULD support the N flag in a Router Advertisement message as defined in [Dam2008]. Access routers and MAGs not supporting the P bit will ignore it as specified in [RFC4861]. Hence there are no backward compatibility issues. 6. Mobile Node Operation When the mobile node wants to move its IP sessions from one interface to another one, the mobile node SHALL send the Router Solicitation message in the target access network with the P flag set. If the Router Advertisement message received in response does not contain the same HNP that the MN is already using for its IP sessions in the current access network, then the target access network does not support handovers across interfaces and the MN SHALL not move its IP sessions to a target interface. The P flag in a Router Advertisement message triggers the mobile node to move its IP sessions from the previous access network to interface attached to the target access network. Unless the MN wants to initiate the PMIP6 handover it SHALL NOT set the P flag in a Router Solicitation message. If the MN already initiated the PMIP6 handover and the MN receives a Router Advertisement message in a previous access network revoking the HNP (prefix lifetime set to 0), the MN SHOULD NOT immediately invalidate the addresses configured with the HNP. Instead, the MN SHALL wait for a Router Advertisement from a target access network. This situation is similar to what is described in chapter 9.3. If the Router Advertisement from a target network contains the HNP with a non-zero lifetime, the MN SHALL continue to use the addresses based on HNP in the target access network. Premec Expires October 26, 2008 [Page 13] Internet-Draft PMIP6 inter-tech handover April 2008 7. Mobile Access Gateway Operation When the mobile node attaches to a MAG, the MAG SHALL delay the sending of an initial PBU message until it receives a Router Solicitation message from the mobile node. If the P flag in the received Router Solicitation message is not set, the MAG SHALL send the PBU message as per [Gun2008]. When MAG receives a Router Solicitation message with a P flag set, the MAG SHALL send a PBU message to the LMA setting the Handoff indicator option to the value "2: Handoff between two different interfaces of the mobile node". In all other cases the MAG SHALL set the Handoff Indicator option as described in the [Gun2008]. 8. LMA operation When the LMA receives a PBU message with a handoff option indicating handover across interface, the LMA SHALL send a Binding Revocation message to the previous MAG. 9. Other Considerations 9.1. Support for IPv4 The current version of this document is focused on IPv6 only and the considerations for IPv4-enabled hosts are not in the scope. Future versions of the document should be enhanced to include support for IPv4. 9.1.1. Overlapping private address spaces IPv4 hosts with multiple simultaneously used network interfaces have had to be able to function even in situations where host has same private IP address allocated for two or more network interfaces. This has been implemented, for example, by binding applications to interface, rather than to IPv4 address. Hosts of this kind are not able to move IP sessions from one interface to another, even if they are able to configure same IPv4 address to multiple interfaces. Premec Expires October 26, 2008 [Page 14] Internet-Draft PMIP6 inter-tech handover April 2008 Furthermore, due to overlapping address spaces, private IPv4 address cannot be used to determine whether network is providing network based mobility. Network based mobility should utilize public IPv4 addresses, or there should be indication that informs host of possibility to move IP sessions even when private IP address spaces are used. Nevertheless, hosts have to be modified to allow IP session movement from one network interface to another. 9.1.2. IPv4 address configuration and indication of PMIP support IPv6 addresses are always configured after link establishment, which enables rather dynamic features as described in this document. However, especially in cellular networks IPv4 addresses are often configured during the link layer establishment procedures only, e.g. with IPCP. In these kinds of networks host cannot utilize IP-layer technologies to indicate support for network based mobility, before IPv4 address allocation takes place in the network. Thus in these kinds of networks host effectively cannot open second network interface before it is actually willing to move, as just opening of a RAN2 network interface can trigger MAG2 to update bindings in LMA, and as not all of the current unmodified host implementations are able to be able to move IP sessions from one interface to another, ongoing IP sessions in RAN1 would be immediately disconnected. In those network access technologies where IPv4 address is assigned after link establishment, e.g. with DHCP, similar solutions as with IPv6 may be possible (IPv4 Router Solicitation/Advertisement, or DHCP-based). In technologies where IPv4 address is allocated right at the link setup, link layer extensions seem to be inevitable. Question: if a host asks during RAN2 link layer setup to be given the same address it has in the RAN1, would that help MAG2 to determine host is interested to move its sessions? 9.2. MTU size Different physical interfaces can have different MTU size. Changes in the MTU size MAY affect the existing IP sessions. When the MN moves its IP sessions to another access network, it SHOULD expect that the link MTU size has changed. Likewise, the MN SHOULD assume that the path MTU changes whenever the access network is changed. If the MN assigns the addresses based on the HNP to a virtual interface, it SHOULD set the MTU size of the virtual interface to the Premec Expires October 26, 2008 [Page 15] Internet-Draft PMIP6 inter-tech handover April 2008 link MTU of the physical interface associated with the virtual interface. When a physical interface associated with a virtual interface is changed, the MTU of the virtual interface must also be updated to the MTU of the new physical interface. 9.3. Zero physical interfaces available It may happen that the multi-interface MN looses its connection with the current access network before it is able to establish a connection with a target access network. We call this situation "zero physical interfaces". Such situation is transient in nature. When the MN roaming in a netlmm domain looses its connection with the current access network (link-down event), it SHOULD NOT immediately invalidate the addresses based on the HNP and tear down the virtual interface. Instead, the MN SHOULD perform a network scan over all physical interfaces looking for a suitable network to attach to. If it finds alternative access network, it should attach to it and use the mechanism described in this document to handoff its IP sessions from previous access network. If the MN is not able to configure the same HNP in a new access network, then the MN SHALL release all addresses based on HNP and all related IP sessions. 10. Security Considerations tbd 11. IANA Considerations The following Extension Types MUST be assigned by IANA: 'P' flag in the Router Solicitation message. 12. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Premec Expires October 26, 2008 [Page 16] Internet-Draft PMIP6 inter-tech handover April 2008 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [Gun2008] Gundavelli, S., Ed., "Proxy Mobile IPv6", April 2008, draft-ietf-netlmm-proxymip6-12.txt [Dam2008] Damic, D., et al., "Proxy Mobile IPv6 indication and discovery", February 2008, draft-damic-netlmm-pmip6-ind- discover 13.2. Informative References [RFC4443] Conta, A., Deering, S., Gupta, M., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007. [Lag2008] Laganier, J., Narayanan, S., McCann, P., "Interface between a Proxy MIPv6 Mobility Access Gateway and a Mobile Node", February 2008, draft-ietf-netlmm-mn-ar-if-03 [IEEE802.16] IEEE Std 802.16-2004, "IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", October 2004. [IEEE802.16e] IEEE802.16e-2005, "IEEE Standard for Local and metropolitan area networks, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", 2005. Premec Expires October 26, 2008 [Page 17] Internet-Draft PMIP6 inter-tech handover April 2008 Author's Addresses Domagoj Premec Nokia Siemens Networks Heinzelova 70a 10000 Zagreb Croatia Email: domagoj.premec.ext@nsn.com Teemu Savolainen Nokia Sinitaival 5 FI-33720 Tampere Finland Email: teemu.savolainen@nokia.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 Expires October 26, 2008 [Page 18] Internet-Draft PMIP6 inter-tech handover April 2008 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. 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 October 26, 2008 [Page 19]