One document matched: draft-savolainen-netext-intertech-handover-00.txt
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, <IEEE Std 802.16-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, <IEEE802.16e-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]
| PAFTECH AB 2003-2026 | 2026-04-24 13:22:43 |