NetExt Working Group D.Premec Internet Draft Nokia Siemens Networks Intended status: Informational T.Savolainen Expires: September 2009 Nokia March 9, 2009 Inter-technology handover in PMIPv6 domain draft-premec-netlmm-intertech-handover-01.txt 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 September 9, 2009. 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. Premec Expires September 9, 2009 [Page 1] Internet-Draft PMIP6 inter-tech handover March 2009 Abstract Proxy Mobile IPv6 [RFC5213] is 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 mobile node equipped with multiple network interfaces roams in a Proxy Mobile IPv6 domain consisting of multiple access networks. If the mobile node 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, PMIPv6- 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.............................................7 4.1. PMIPv6 service availability...............................8 4.2. Handover Indication.......................................8 4.3. Movement of IP sessions across interfaces................10 5. Message Format................................................11 5.1. Router Solicitation message extension....................11 5.2. Attach Information DHCP Option...........................12 6. Mobile Node Operation.........................................13 6.1. Use of Router Solicitation mechanism.....................13 6.2. Usage of Attach Information DHCP option..................13 7. Mobile Access Gateway Operation...............................14 8. LMA operation.................................................14 9. DHCP server operation.........................................14 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 Premec Expires September 9, 2009 [Page 2] Internet-Draft PMIP6 inter-tech handover March 2009 10.3. Zero physical interfaces available......................16 11. Security Considerations......................................17 12. IANA Considerations..........................................17 13. Acknowledgments..............................................17 14. References...................................................17 14.1. Normative References....................................17 14.2. Informative References..................................17 Author's Addresses...............................................18 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 presents a scenario where the host with multiple network interfaces attaches to the PMIPv6 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 PMIPv6 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 [RFC5213]. PMIPv6 domain Network providing the network based IP mobility service as defined in [RFC5213]. PMIP6 Proxy Mobile IPv6 protocol specified in [RFC5213]. Premec Expires September 9, 2009 [Page 3] Internet-Draft PMIP6 inter-tech handover March 2009 3. Problem statement A PMIPv6 domain is defined as a network which provides network based 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 interface cards (WiFi, 3G, WiMAX, etc.), one or more for each different radio access technology. This network configuration is illustrated by the following figure: +---------+ | HA/LMA | +---------+ / \ / \ \ / \ \ ---------------/-----+ +--\----\--------------- / ) ( \ RAN1 +------+ ) ( +------+ RAN2 | MAG1 | ) ( | MAG2 | +------+ ) ( +------+ \ ) ( / ---------------\----+ +----/--------------- \ / \ / \ / \ / | | +-|---|-+ |IF1 IF2| | MN | +-------+ Figure 1 PMIPv6 domain with multiple access networks 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 RAN1 or various policy reasons like price, quality of service, available bandwidth, etc. To be able to move IP sessions across interfaces, the modifications on the host side are necessary on many if not all operating systems, and therefore the PMIPv6 service is no longer transparent to the MN. Premec Expires September 9, 2009 [Page 4] Internet-Draft PMIP6 inter-tech handover March 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 RAN1 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) | |--------------------------------->| | | | | | | | | | | | | | | | | 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 Premec Expires September 9, 2009 [Page 5] Internet-Draft PMIP6 inter-tech handover March 2009 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. 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 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. - 9. These steps 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. 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 Premec Expires September 9, 2009 [Page 6] Internet-Draft PMIP6 inter-tech handover March 2009 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. There is also a serious flaw resulting from the above message sequence. After attachment to MAG2, 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 drops 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 issue the [RFC5213] 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. 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 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 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. Premec Expires September 9, 2009 [Page 7] Internet-Draft PMIP6 inter-tech handover March 2009 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. 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 [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 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. 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 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 is independent of the link-layer technology. 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 Premec Expires September 9, 2009 [Page 8] Internet-Draft PMIP6 inter-tech handover March 2009 "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 [Pat2008] 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 can 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 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 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 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 Premec Expires September 9, 2009 [Page 9] Internet-Draft PMIP6 inter-tech handover March 2009 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]. This document recommends adopting the IP layer based mechanism, either by introducing the new DHCP option indicating the attachment type as per [Pat2008] 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 [Dam2008]. 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 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 Premec Expires September 9, 2009 [Page 10] Internet-Draft PMIP6 inter-tech handover March 2009 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 [Pat2008] 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). 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. Premec Expires September 9, 2009 [Page 11] Internet-Draft PMIP6 inter-tech handover March 2009 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. 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 [Dam2008]. Access routers and MAGs not supporting the P bit will ignore it as per [RFC4861]. Hence there are no backward compatibility issues. 5.2. Attach Information DHCP Option The Attach Information DHCP option is specified in [Pat2008]. 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 Premec Expires September 9, 2009 [Page 12] Internet-Draft PMIP6 inter-tech handover March 2009 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 [Dam2008] 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 [Dam2008] 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 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 Premec Expires September 9, 2009 [Page 13] Internet-Draft PMIP6 inter-tech handover March 2009 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. 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. Premec Expires September 9, 2009 [Page 14] Internet-Draft PMIP6 inter-tech handover March 2009 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 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. 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. 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. 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, Premec Expires September 9, 2009 [Page 15] Internet-Draft PMIP6 inter-tech handover March 2009 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. 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 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 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 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 mechanisms 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. Premec Expires September 9, 2009 [Page 16] Internet-Draft PMIP6 inter-tech handover March 2009 11. Security Considerations tbd 12. IANA Considerations The following Extension Types MUST be assigned by IANA: 'P' flag in the Router Solicitation message. 13. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 14. References 14.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. [RFC4862] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5213] Gundavelli, S., Ed., "Proxy Mobile IPv6", RFC 5213, August 2008 14.2. Informative References [Dam2008] Damic, D., et al., "Proxy Mobile IPv6 indication and discovery", March 2009, draft-damic-6man-pmip6-ind (work in progress) Premec Expires September 9, 2009 [Page 17] Internet-Draft PMIP6 inter-tech handover March 2009 [Pat2008] Patil, B., Chowdury, K., "DHCP options for Access Point Name and attach type indication", October 2008, draft- patil-dhc-apn-attachtype-options (work in progress) [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-PMIPv6-mn-ar-if (work in progress) [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. Author's Addresses Domagoj Premec Nokia Siemens Networks Heinzelova 70a 10000 Zagreb Croatia Email: domagoj.premec.ext@nsn.com Teemu Savolainen Nokia Sinitaival 5Hermiankatu 12 D FI-33720 Tampere Finland Email: teemu.savolainen@nokia.com Premec Expires September 9, 2009 [Page 18]