NetExt Working Group T. Savolainen Internet-Draft Nokia Intended status: Standards Track D. Premec Expires: January 3, 2010 (Unaffiliated) July 2, 2009 Inter-technology handover in PMIPv6 domain draft-savolainen-netext-intertech-handover-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 January 3, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract Proxy Mobile IPv6 [RFC5213] is a network based mobility management protocol which provides IP mobility service to a host in a way which Savolainen & Premec Expires January 3, 2010 [Page 1] Internet-Draft PMIP6 inter-tech handover July 2009 is transparent to the host itself. This document analyses the scenarios in which a multi-interfaced Mobile Node roams in a Proxy Mobile IPv6 domain which consists of access networks that are of different types. In order to support session continuity as the Mobile Node moves between access networks within the PMIP6 domain, the Mobile Node either needs to use host based Mobile IP or be enhanced with various capabilities described in this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Possible solutions . . . . . . . . . . . . . . . . . . . . . . 7 4.1. PMIPv6 service availability . . . . . . . . . . . . . . . 7 4.2. Handover Indication . . . . . . . . . . . . . . . . . . . 9 4.3. Movement of IP sessions across interfaces . . . . . . . . 10 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Router Solicitation message extension . . . . . . . . . . 12 5.2. Attach Information DHCP Option . . . . . . . . . . . . . . 13 6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 13 6.1. Use of Router Solicitation mechanism . . . . . . . . . . . 13 6.2. Usage of Attach Information DHCP option . . . . . . . . . 14 7. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 14 8. LMA operation . . . . . . . . . . . . . . . . . . . . . . . . 14 9. DHCP server operation . . . . . . . . . . . . . . . . . . . . 15 10. Other Considerations . . . . . . . . . . . . . . . . . . . . . 15 10.1. Support for IPv4 . . . . . . . . . . . . . . . . . . . . . 15 10.1.1. Overlapping private address spaces . . . . . . . . . 15 10.1.2. IPv4 address configuration and indication of PMIP support . . . . . . . . . . . . . . . . . . . . . . . 15 10.2. MTU size . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.3. Zero physical interfaces available . . . . . . . . . . . . 16 11. Conclusions and recommendations . . . . . . . . . . . . . . . 17 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 15.1. Normative References . . . . . . . . . . . . . . . . . . . 18 15.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Savolainen & Premec Expires January 3, 2010 [Page 2] Internet-Draft PMIP6 inter-tech handover July 2009 1. Introduction The goal of the Proxy Mobile IPv6 protocol (PMIPv6) [RFC5213] is to provide IP mobility service to hosts which are not Mobile IP capable. The key objective of the PMIPv6 protocol is that network based IP mobility service is provided in a manner that is transparent to the hosts and does not require any involvement from the host side. This document illustrates the issues that exist in the case where a multi-interfaced host attaches to a PMIP6 domain which consists of heterogeneous access networks. If the host needs to maintain IP session continuity as it moves within the scope of the PMIP6 domain and performs handovers across access networks of different access technologies, it has to be enhanced with certain PMIP6 specific capabilities. The document focuses primarily on IPv6, but certain IPv4 considerations are also included. 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, 8, and 9 describe operational changes to Mobile Node, Mobile Access Gateway, Local Mobility Anchor, and DHCP server. Section 10 lists other considerations and further work needed. Finally section 11 contains conclusions and recommendations for NetExt working group. 1.1. Requirements Language 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 [RFC2119]. 2. Terminology General mobility related terminology is defined in [RFC3775]. Additional PMIP6 specific terminology can be found in [RFC5213]. PMIPv6 domain: Network providing the network based IP mobility service as defined in [RFC5213]. PMIP6: Proxy Mobile IPv6 protocol specified in [RFC5213]. 3. Problem statement A PMIPv6 domain is defined as a network which provides network based Savolainen & Premec Expires January 3, 2010 [Page 3] Internet-Draft PMIP6 inter-tech handover July 2009 IP mobility service by deploying the PMIP6 protocol [RFC5213] and where the security association between MAGs and LMAs can be set up. Such broad definition allows a PMIPv6 domain to consist of several access networks of different types. A host attaching to such PMIPv6 domain may have multiple network interfaces (WiFi, 3G, WiMAX, etc.), one or more for each different access technology type. This network configuration is illustrated by the following figure: +---------+ | HA/LMA | +---------+ / \ / \ ---------------/---+ +---\--------------- / ) ( \ AN1 +------+ ) ( +------+ AN2 | MAG1 | ) ( | MAG2 | +------+ ) ( +------+ \ ) ( / ----------------\--+ +--/---------------- \ / \ / +-\---/-+ |IF1 IF2| | MN | +-------+ PMIPv6 domain with multiple access networks Figure 1 The host can handoff between the adjacent MAGs located at the boundaries of different access networks and it may want to move its existing IP sessions from one interface to another at time of its choosing. The decision and the trigger to move IP sessions across interfaces is implementation dependent and may be based on the number of reasons like for example deteriorating radio signal quality from AN1 or various policy reasons like price, quality of service, available bandwidth, etc. In order to enable session continuity across different interfaces of a host which is provided mobility via a PMIP6 domain, there are enhancements that are needed on the host. This is applicable in general to most operating systems. Network based mobility is no longer transparent from the MNs perspective when session continuity across acess technologies needs to be enabled. Savolainen & Premec Expires January 3, 2010 [Page 4] Internet-Draft PMIP6 inter-tech handover July 2009 In the following figure we assume that at first the host is attached to the PMIPv6 domain via the MAG1 located in the access network AN1 and then subsequently the MN attaches via the MAG2. 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) | |--------------------------------->| | | | | | | | | | | | | | | | | Multihomed MN moving between different ANs Figure 2 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 AN2, it is possible that MN Savolainen & Premec Expires January 3, 2010 [Page 5] Internet-Draft PMIP6 inter-tech handover July 2009 configures different Interface Identifier for the second interface than what is used in the first interface. 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 for the MN. The binding contains an access technology type that is different from the one received in the PBU message. The LMA returns to the MAG2 the existing Home Network Prefix (HNP) from the MN's binding cache entry. If the LMA would return a different HNP, the MN would configure an address that is different from the one assigned on its other interface and this would make it impossible to move the existing IP sessions across interfaces. 5. This step shows the MAG2 to LMA tunnel is established. Note that after processing the PBU message from MAG2 the LMA no longer retains the PMIP tunnel to the MAG1 although the MN is still attached also to MAG1. 6. MN sends Router Solicitation 7. MN sends MLD Join 8. MN sends a DAD request 9. MN receives Router Advertisement. The steps 6-9 are part of the IPv6 stack initialization when a new interface is brought up and are executed as per [RFC4862] and [RFC5213]. 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: the same 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. Savolainen & Premec Expires January 3, 2010 [Page 6] Internet-Draft PMIP6 inter-tech handover July 2009 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 on 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). This in general requires modifications on the host side as the legacy host can not be assumed to support the same IP address to be configured on different interfaces. LMA relies on the handoff indication to know that the MN is capable of moving its IP session across interfaces. If the access technology type in the PBU message is different from the one saved in the binding cache entry, LMA knows 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 I-D recommends that the MAG receive this indication from the MN itself since it is only the MN which is aware of whether it wants to relocate the sessions to the new interface or if it is establishing another session via the second interface in order to be multihomed. The network cannot interpret the MNs reason for attaching via a second interface to another MAG in the PMIP6 domain and hence it should only set the HO flag based on the MN indicating the reason for the attach. Consequently, the MN that wants to retain its IP address as it moves from one access network to another in a PMIPv6 domain must be enhanced with PMIPv6 specific functionality, and in particular it must be able to do the following: o Detect that it is attached to a PMIPv6 domain o Indicate to the MAG its support for moving of IP sessions across interfaces o Support moving of IP session across interfaces 4. Possible solutions This subsection looks at several different mechanisms that could be used to enable the movement of IP sessions across interfaces. 4.1. PMIPv6 service availability The MN that is able to move its IP sessions across interfaces should be aware if it is attached to a PMIP6 domain or not in order to be able to initialize virtual interfaces, or some other mechanisms, to Savolainen & Premec Expires January 3, 2010 [Page 7] Internet-Draft PMIP6 inter-tech handover July 2009 deal with the fact that the same prefix/address may be assigned to a different interface as a result of mobility. The MN can trigger such capability as a result of being aware about the access router being a MAG in a PMIP6 domain and the prefix being assigned to it is coming from an LMA. The network can indicate to the MN that it is providing the PMIPv6 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 PMIPv6 service. This is described in more detail in [I-D.damic-6man-pmip6-ind]. 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 A link-layer specific mechanism A link-layer technology used in a PMIPv6 domain could be extended to carry the indication of the availability of the PMIPv6 service. This approach enables the MN to learn the network's PMIPv6 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. While a link-layer specific changes can be standardized on some technologies, it is unlikely that it will be possible to define it for all technologies. 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 PMIPv6 service availability in the network. This is an implicit indication and is error prone because such solution can not differentiate between the PMIPv6 domain and multi-link subnets [RFC4903]. Advantage is that it does not require any changes to the protocol messages. This approach works only for IPv6 and in IPv4 when public IPv4 addresses are used. From the above options extensions of Router Advertisement message are considered best, as it provides an explicit indication, is backwards compatible with legacy hosts and is independent of the link-layer technology. Savolainen & Premec Expires January 3, 2010 [Page 8] Internet-Draft PMIP6 inter-tech handover July 2009 4.2. Handover Indication When the MN roaming in a PMIPv6 domain decides to move its IP sessions from one access network to another, it needs a mechanism by which it can tell the network about its intention to move its IP sessions across interfaces. The MAG uses this indication from the MN to set the Handoff Indicator option in the PBU message to the value "2: Handoff between two different interfaces of the mobile node". Following mechanisms are possible: o New DHCP option A new DHCP option may be introduced to enable the MN to provide an explicit indication to the network whether the attachment is to be regarded as a handover or as a new attachment. Such option is proposed in [I-D.patil-dhc-apn-attachtype-options] for both DHCPv4 and DHCPv6. In case of a DHCP based mechanism the MAG delays sending of the initial PBU message until it receives the DHCP message from the MN. The MAG can trigger the usage of the DHCPv6 by sending the Router Advertisement message which does not contain any prefix usable for address autoconfiguration and where the M flag is set. o Extension of the 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 behavior specified in the [RFC5213] 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 could be extended to carry the indication of the MN's PMIPv6 capability to the MAG. This solution introduces tight coupling between the IP layer and the link-layer and requires changes to all link layer technologies used with the PMIP6 protocol. o Same interface identifier across access networks This approach is suggested in the [I-D.ietf-netlmm-mn-ar-if]. The idea is that the MN uses 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 Savolainen & Premec Expires January 3, 2010 [Page 9] Internet-Draft PMIP6 inter-tech handover July 2009 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 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 dependent 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]. The interface identifier approach is further complicated if the host is simultaneously utilizing multiple IPv6 addresses configured from the same prefix. From the abovemention options this document prefers the IP layer based mechanism, either by introducing the new DHCP option indicating the attachment type as per [I-D.patil-dhc-apn-attachtype-options] or by extending the Router Solicitation message. Both mechanisms provide an explicit indication, are backwards compatible with legacy hosts, do not affect the underlying link-layer technology, allow for arbitrarily long temporal separation of access network attachment and session movement, and do not require any changes to the already deployed equipment like base stations or access points that provide the link layer connectivity in the PMIPv6 domain. It is recommended that the PMIPv6 domain uses a single mechanism for IPv6 address management of the MNs throughout the domain, either autoconfiguraton or DHCPv6. This is to avoid any problems during the handover given the fact that the MN in a PMIPv6 domain is given a unique 64-bit prefix for address autoconfiguration while on the other hand the address assigned through the DHCPv6 is a /128 address. 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. Upon MN attachment the MAG SHOULD send the Router Advertisement message containing PMIPv6 specific extensions as described in [I-D.damic-6man-pmip6-ind]. This enables the MN to detect that it is attaching to the PMIP6 domain. The MN SHOULD detect that it is in a PMIPv6 domain by looking for a N flag in a Flags Expansion option in the Router Advertisement message. If during the initial network Savolainen & Premec Expires January 3, 2010 [Page 10] Internet-Draft PMIP6 inter-tech handover July 2009 attachment the MN detects that it is attaching to a PMIPv6 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 PMIPv6 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 PMIPv6 domain over its second interface, it SHOULD indicate to the network if it intends to move its IP sessions across interfaces. The MN provides such an indication either by including the appropriate DHCP options [I-D.patil-dhc-apn-attachtype-options] or by setting a flag in the Router Solicitation message as described in this document. If MN wants to postpone movement of its IP sessions to a later point, it MAY leave out this indication at this time. If the Router Advertisement message indicates that the network supports PMIPv6 service and the HNP received from the network is the same as the one 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. 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. The MN can at any time decide to switch its IP sessions to another access network. To actually perform the switch of the IP sessions, the MN sends to the target network either the DHCP message or a Router Solicitation containing the indication of the handover. (DISCUSS: With further netext advancements, it could be possible for MN to use multiple physical interfaces in parallel. In such a case the virtual network interface may also contain the logic needed to direct individual uplink IP flows to specific physical interfaces, and collect downlink IP flows arriving from different physical interfaces). Savolainen & Premec Expires January 3, 2010 [Page 11] Internet-Draft PMIP6 inter-tech handover July 2009 5. Message Format 5.1. Router Solicitation message extension A new 'P' flag is added to the Router Solicitation message specified in [RFC4861] indicating that the host supports PMIPv6 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 ... +-+-+-+-+-+-+-+-+-+-+-+- P flag in the Router Solicitation Figure 3 ICMP Fields: Type: 133 Code: 0 Checksum: The ICMP checksum. See [RFC4443] C flag: C bit is introduced in [I-D.damic-6man-pmip6-ind]. If it is set, it indicates that the MN is capable of performing its own mobility management. P flag: If this bit is set, it indicates that the MN supports the PMIPv6 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 [I-D.damic-6man-pmip6-ind]. Access routers and MAGs not supporting the P bit will ignore it as Savolainen & Premec Expires January 3, 2010 [Page 12] Internet-Draft PMIP6 inter-tech handover July 2009 per [RFC4861]. Hence there are no backward compatibility issues. 5.2. Attach Information DHCP Option The Attach Information DHCP option is specified in [I-D.patil-dhc-apn-attachtype-options]. It enables the MN to convey to the network whether it wants to execute the handover across interfaces or establish a new session. The MN sets the Attach_Type field in the Attach Information option to the value "Handover" when it executes handover across interfaces, otherwise it sets the Attach_Type field to the value "New Service Flow". 6. Mobile Node Operation When the MN in a PMIP6 domain wants to move its IP sessions from one interface to another one, the MN MAY use either the DHCP based mechanism or the Router Solicitation mechanism to indicate the type of attachment to the network. 6.1. Use of Router Solicitation mechanism When the MN wants to execute the handover across interfaces, the MN SHALL send the Router Solicitation message in the target access network with the P flag set. Unless the MN wants to initiate the PMIP6 handover it SHALL NOT set the P flag in a Router Solicitation message. The Router Advertisement message with the N flag set [I-D.damic-6man-pmip6-ind] and advertising the MN's HNP triggers the MN to move its IP sessions from the previous access network to interface attached to the target access network. If the Router Advertisement message received in response does not contain the same HNP that the MN is already using for its IP sessions or if the N flag [I-D.damic-6man-pmip6-ind] in Router Advertisement is not set, then the target access network does not support handovers across interfaces and the MN SHALL NOT move its IP sessions to a target interface. 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 section 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 Savolainen & Premec Expires January 3, 2010 [Page 13] Internet-Draft PMIP6 inter-tech handover July 2009 on HNP in the target access network. 6.2. Usage of Attach Information DHCP option The MN MAY include the Attach Information option in the DHCP messages at the time of requesting the IP address from the target network. The Attach_Type field MUST be set to the value "Handover" in case the MN requests to move its IP sessions across interfaces, otherwise it MUST be set to the value "New Service Flow". Upon successful address configuration via DHCP and provided that the DHCP response contained the Attach_Type indicating "Handover" and the assigned address is the same as the address assigned to its other interface, the MN SHALL move its IP session from its other interface to the newly configured interface. If the DHCP messages received by the MN do not contain the Attach Information option with the Attach_Type set to "Handover" and the same IP address that the MN is already using on its other interface, then the handover across interfaces is not possible and the MN SHALL NOT move its IP sessions across interfaces. 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 either a Router Solicitation message or the DHCP message from the MN. If the P flag in the received Router Solicitation message is not set or if the Attach Information option is not included in the DHCP message, the MAG SHALL send the PBU message as per [RFC5213]. When the MAG receives a Router Solicitation message with a P flag set or a DHCP message with an Attach Information option where the Attach_Type field is set to "Handover", 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 [RFC5213]. 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. Savolainen & Premec Expires January 3, 2010 [Page 14] Internet-Draft PMIP6 inter-tech handover July 2009 9. DHCP server operation If the PMIP6 domain supports handovers across interfaces and if the MN included the Attach Information option in the request messages, then the DHCP messages sent in response SHALL include the Attach Information option. If the MN set the Attach_Type field to a value "Handover" and if the IP session handover across interfaces is authorized and allowed by the network, the DHCP response messages SHALL include the Attach Information option with the Attach_Type filed set to "Handover" and the address assigned to the MN SHALL be the same as the one that is assigned to the other interface of the MN. 10. Other Considerations 10.1. Support for IPv4 In case of IPv4 only the DHCP based mechanism for conveying the attachment type is available. 10.1.1. Overlapping private address spaces Hosts with multiple simultaneously used network interfaces have had to be able to function even in situations where host has same private IPv4 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 IP address to multiple interfaces. Furthermore, private IPv4 addresses cannot reliably be used to determine whether an access network is providing network based mobility service and whether sessions should continue after switch of access network. Network based mobility solution should utilize public IPv4 addresses, or there should be an indication that informs host of possibility to move IP sessions even when private IPv4 address spaces are used. Nevertheless, hosts have to be modified to allow IPv4 session movement from one network interface to another. 10.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. Savolainen & Premec Expires January 3, 2010 [Page 15] Internet-Draft PMIP6 inter-tech handover July 2009 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 AN2 network interface can trigger MAG2 to update bindings in LMA, and as not all of the current unmodified host implementations are able to move IP sessions from one interface to another, ongoing IP sessions in AN1 would be immediately disconnected. Access network technologies where IPv4 address is assigned after link establishment via DHCP SHOULD use the Attachment Information DHCP option for conveying the handover/new service flow indication. In technologies where IPv4 address is allocated right at the link setup, link layer extensions seem to be inevitable. 10.2. MTU size Different physical interfaces can have different MTU sizes. 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 may have 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 home network prefix to a virtual interface, it SHOULD set the MTU size of the virtual interface to the 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. 10.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 PMIPv6 domain looses its connection with the current access network (link-down event), it SHOULD NOT immediately invalidate the addresses 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 mechanisms described in this document to handoff its IP sessions from Savolainen & Premec Expires January 3, 2010 [Page 16] Internet-Draft PMIP6 inter-tech handover July 2009 previous access network. If the MN is not able to configure the same addresses in a new access network, then the MN SHALL release all related addresses and IP sessions. 11. Conclusions and recommendations It is clear that for IP session continuity during PMIP6 inter- technology handovers changes on many if not all operating systems are necessary. While there are several technical ways to accomplish that, as described earlier, all those require support from both hosts and access network elements. Enhancing the MN with functionality to achieve inter-technology handovers is almost the same as installing host based mobility support. Since host based mobility is already specified and is capable of accomplishing inter-technology handovers and flow mobility, there is no reason to reinvent the same in the case of PMIP6. Therefore we recommend to: 1. Use host based mobility solutions, such as DSMIP6 [RFC5555], for inter-technology handovers. DSMIP6 has the benefit of not requiring special support from access networks (such as WLAN hotspots), it allows overlapping IPv4 care-of addresses, and has been standardized already. 2. On access technologies where PMIP6 based handovers are absolutely required, it is best to standardize access technology specific solutions that provide intra-technology looking handovers for hosts. 3. In the case NetExt working group chooses to standardize inter- technology handovers for PMIP6, we propose doing that with changes to DHCPv4 and to DHCPv6 and/or Router Solicitation/Router Advertisements as described in this document. 12. Security Considerations tbd 13. IANA Considerations The following Extension Types MUST be assigned by IANA: 'P' flag in the Router Solicitation message. Savolainen & Premec Expires January 3, 2010 [Page 17] Internet-Draft PMIP6 inter-tech handover July 2009 14. Acknowledgements Authors would like to thank Basavaraj Patil on extensive review. This document was prepared using xml2rfc template and related web- tool. 15. References 15.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., and J. Arkko, "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. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 15.2. Informative References [I-D.damic-6man-pmip6-ind] Damic, D., "Proxy Mobile IPv6 indication and discovery", draft-damic-6man-pmip6-ind-00 (work in progress), March 2009. [I-D.ietf-netlmm-mn-ar-if] Laganier, J., Narayanan, S., and P. McCann, "Interface between a Proxy MIPv6 Mobility Access Gateway and a Mobile Node", draft-ietf-netlmm-mn-ar-if-03 (work in progress), February 2008. [I-D.patil-dhc-apn-attachtype-options] Patil, B., Chowdhury, K., and D. Premec, "DHCP options for Access Point Name and attach type indication", draft-patil-dhc-apn-attachtype-options-01 (work in progress), March 2009. [IEEE802.16] Savolainen & Premec Expires January 3, 2010 [Page 18] Internet-Draft PMIP6 inter-tech handover July 2009 IEEE, "IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", 2004, . [IEEE802.16e] IEEE, "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, . [RFC4443] Conta, A., Deering, S., and M. Gupta, "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. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. Authors' Addresses Teemu Savolainen Nokia Hermiankatu 12 D TAMPERE, FI-33720 FINLAND Email: teemu.savolainen@nokia.com Domagoj Premec (Unaffiliated) Heinzelova 70a Zagreb, 10000 Croatia Email: domagoj.premec@gmail.com Savolainen & Premec Expires January 3, 2010 [Page 19]