One document matched: draft-devarapalli-mext-mipv6-home-link-01.txt
Differences from draft-devarapalli-mext-mipv6-home-link-00.txt
Network Working Group V. Devarapalli
Internet-Draft N. Kant
Intended status: Informational H. Lim
Expires: August 27, 2008 Azaire Networks
February 24, 2008
Mobile IPv6 Home Link Operation over SDO point-to-point links
draft-devarapalli-mext-mipv6-home-link-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 August 27, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The Mobile IPv6 protocol is being adopted by various Standards
Development Organizations (SDO) for mobility across wide area
networks. Some of the architectures developed by these SDOs require
some of the access links to be home link for mobile node. The belief
is that if the mobile node thinks it is attached to the home link,
there will not be additional packet overhead due to Mobile IPv6
tunneling. Many of these links where the mobile node is supposed to
Devarapalli, et al. Expires August 27, 2008 [Page 1]
Internet-Draft MIPv6 Home Link Operation February 2008
be attached to the home link are point-to-point links. There are
some issues with making these point-to-point links appear like home
link to the mobile node. This document captures some of the issues
related to this, and analyzes possible solutions.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Issues with using Point-to-Point links as Home Links . . . . . 4
3.1. Detecting Attachment to the Home Link . . . . . . . . . . 4
3.2. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Home Address Management on the Mobile Node . . . . . . . . 5
3.4. Forwarding at the Home Agent . . . . . . . . . . . . . . . 6
3.5. Indicating Service Selection Option . . . . . . . . . . . 6
4. Solution Analysis . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Modified Binding Update Message Format . . . . . . . . . . 9
4.2. Modified Binding Acknowledgement Message Format . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Devarapalli, et al. Expires August 27, 2008 [Page 2]
Internet-Draft MIPv6 Home Link Operation February 2008
1. Introduction
The Mobile IPv6 protocol [2] is being adopted by various Standards
Development Organizations (SDOs) for mobility across wide area
cellular networks. The architectures being developed by the SDOs
involve some access links where bandwidth is considered scarce.
Therefore, the SDOs have designed the architectures so that the
Mobile IPv6 signaling and tunneling overhead can be avoided over
these access links. For various reasons, Route Optimization is not
being considered by the SDOs.
According to RFC 3775 [2], the mobile node does not have a valid
binding cache entry at the home agent and a Mobile IPv6 tunnel with
the home agent only when it is attached to the home link. Therefore
the architectures being developed by the SDOs require of the access
links to appear to the mobile node as home link so that the Mobile
IPv6 overhead can be avoided.
The access links where the mobile node is attached to the home link
is of various types. They typically tend to be point-to-point links.
The following describes examples of point-to-point links where Mobile
IPv6 home link operation is desired.
o GTP tunnels/PDP Contexts - GTP tunnels [4] between network
entities or PDP contexts between the mobile node and a network
entity are used as single hop point-to-point links between the
mobile node and the home agent. The architectures in [5] and [6]
show scenarios where the home agent is co-located with a network
entity that terminates the GTP tunnels. In these cases, the
mobile node, whenever it attaches over these access links is
attached to the home link. Note that this document uses the terms
GTP and PDP context very loosely. For more details about GTP
tunnels or PDP contexts, please see [4].
o PMIPv6 tunnels - [5] shows an architecture where the Proxy Mobile
IPv6 Local Mobility Anchor functionality [7] and Mobile IPv6 home
agent functionality are co-located. In this architecture whenever
the mobile node is attached to the access link where PMIPv6 is
used, it appears to the mobile node as if it is attached to the
home link. In this case, the concatenation of PMIPv6 tunnel
between the Mobile Access Gateway and the Local Mobility Anchor
and the point-to-point link between the mobile node and the mobile
access gateway is used as the point-to-point link between the
mobile node and the home agent.
o IPsec tunnels - [6] describes a scenario where a network entities
that terminates IPsec tunnels from the mobile node is co-located
with Mobile IPv6 home agent function. In this case, whenever the
Devarapalli, et al. Expires August 27, 2008 [Page 3]
Internet-Draft MIPv6 Home Link Operation February 2008
mobile node is attached over IPsec tunnels, it appears to the
mobile node as if it is attached to the home link. In this case,
an IPsec tunnel is used as point-to-point link between the mobile
node and the home agent.
In some of the scenarios in [5], it is possible to use concatenated
GTP and PMIPv6 tunnel or concatenated IPsec tunnel and PMIPv6 tunnel
as point-to-point links between the mobile node and the home agent.
There are also scenarios where two concatenated PMIPv6 tunnels are
used to provide a home link for the mobile node.
There are some issues with using point-to-point links based on GTP/
PMIPv6/IPsec tunnels between the mobile node and the home agent.
This document discusses some of the issues and analyzes possible
solutions.
2. Terminology
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 [1].
3. Issues with using Point-to-Point links as Home Links
The following describes some of the issues with using point-to-point
links as home links.
3.1. Detecting Attachment to the Home Link
In Mobile IPv6, a mobile node detects that it has attached to the
home link when it receives a router advertisement with the home
prefix. Some of the point-to-point links like IPsec tunnels and
PMIPv6 tunnels do not support running neighbor discovery in the
tunnels. When the home link is created by concatenating a GTP tunnel
with a PMIPv6 tunnel or an IPsec tunnel with PMIPv6 tunnels, it
becomes difficult for a router advertisement to be sent over the
concatenated tunnels.
If the mobile node is not able to use router discovery to detect
attaching to the home link, then the only possible solution would be
to configure the mobile node with the information on which links it
needs to treat as home links. This solution is not sufficient in
most cases.
Devarapalli, et al. Expires August 27, 2008 [Page 4]
Internet-Draft MIPv6 Home Link Operation February 2008
3.2. Bootstrapping
Mobile IPv6 bootstrapping [8] and [9] depends on the use of IKEv2
between the mobile node and the home agent to bootstrap the MIPv6
home address. According to RFC 3775, when the mobile node is
attached to the home link, it does not have to run IKEv1/IKEv2 with
the home agent to setup the necessary security associations. Most
often, the IKEv2 exchange is triggered by the need to send a binding
update. So if the mobile node boots up the home link, it may not be
able to use IKEv2 to bootstrap the MIPv6 home address.
The IKEv2 exchange is only used to bootstrap the MIPv6 home address.
The DS-MIPv6 [11] IPv4 home address is obtained by the mobile node
using the exchange of Binding Update and Binding Acknowledgement with
the home agent. The Mobile Network Prefixes required for mobile
router operation, as described in [10], may also obtained using the
Binding Update and Binding Acknowledgement exchange between the
mobile router and the home agent. This is specified in [12].
According to the current specifications, the mobile node (or the
mobile router) does not send a Binding Update to the home agent when
it is attached to the home link.
Since it is not typical for the mobile node to initiate an IKEv2
exchange with its home agent and not possible to send a Binding
Update from the home link, there is a need for other bootstrapping
mechanisms that would work across all point-to-point home links.
However, this would result in the mobile node using different
bootstrapping mechanisms depending on the point-to-point that appears
as the home link. The mobile node would also end with using
different bootstrapping mechanisms when attached to the home link and
when attached to the visited link. To avoid this, it would be
desirable to use the same bootstrapping mechanisms irrespective of
the point-to-point link that appears as the home link and/or the
visited link.
3.3. Home Address Management on the Mobile Node
When the mobile node boots up on the home link, it will configure the
IPv6 home address (and the IPv4 home address). The home address(es)
are configured using address configuration mechanisms specific to the
point-to-point links. The mobile node then assigns the address(es)
to the interface that corresponds to the point-to-point link. The
Mobile IPv6 stack that is running on the mobile node needs to know
that the addresses now assigned to the point-to-point links are also
the home addresses and should be assigned to the Mobile IPv6 virtual
interface when the mobile node moves away from the home and attaches
to a visited link.
Devarapalli, et al. Expires August 27, 2008 [Page 5]
Internet-Draft MIPv6 Home Link Operation February 2008
3.4. Forwarding at the Home Agent
According to RFC 3775, when the mobile node is attached to the home
link, it behaves as a regular IPv6 host and is able to send/receive
packets directly without going through the home agent. In case the
home agent needs to send any packet to the mobile node, it has a
valid neighbor cache entry for the mobile node which is then used to
forward packets to the mobile node.
When point-to-point links are used a home links, then the packets
meant for the mobile node always reach the home agent first and are
then forwarded to the mobile node. However, the home agent cannot
construct a neighbor cache entry for the mobile node, since most of
the point-to-point links mentioned in Section 1 do not support
sending neighbor solicitation and receiving neighbor advertisement
messages. The home agent would need to associate the mobile node's
home address with the point-to-point link between the mobile node and
the home agent. This would require tighter integration between the
function that terminates the point-to-point link and the home agent
function on the same network node.
In some of the configurations described in [5] and [6], it may be
possible that two different access links for a mobile node appear as
a home link. When the mobile node performs a handover between these
two interfaces, it would appear to it, that it attached to the same
home link using another interface. For this scenario to work, the
home agent would need to know that the mobile node, after a handover,
is reachable at home over a different point-to-point link. This
would again require tighter integration between the functions that
terminate the two different types of point-to-point link and the home
agent function.
3.5. Indicating Service Selection Option
A new extension, the Service Selection for Mobile IPv6, has been
specified in [13] for the mobile node to indicate to the home agent
which service it wants to access. The Service Selection option is
sent in the Binding Update. When the mobile node boots up in the
home link, it won't be able to indicate the service it wants to
access to the home agent, since the Binding Update message is not
sent from the home link.
It is possible to indicate the Service the mobile node wants to
access in the IKEv2 exchange with the home agent. The service
information is encoded in the IDr payload in the IKEv2 exchange.
However, this requires the mobile node to initiate an IKEv2 exchange
with the mobile node from the home link. According to RFC 3775, the
mobile node does not have to initiate an IKEv2 exchange when it boots
Devarapalli, et al. Expires August 27, 2008 [Page 6]
Internet-Draft MIPv6 Home Link Operation February 2008
up in the home link.
4. Solution Analysis
A straight forward solution to avoid the issues described in
Section 3 is to avoid the home link operation. The mobile node is
always attached to the visited link. The home link becomes a virtual
home link in this case. However, this solution may not be acceptable
due to resource constraints on some of the point-to-point links
mentioned in Section 1.
A possible solution would be for the mobile node to perform an IKEv2
exchange and a Binding Update/Binding Acknowledgement exchange with
the home agent even when it is attached to the home link. A new flag
'C' is used in the Binding Update and Binding Acknowledgement
messages to indicate that these messages are being sent on the home
link and are used only for bootstrapping and configuring other
information. The Home Agent does not create a binding cache entry
when it processes the Binding Update with the 'C' flag set. This
extension to Mobile IPv6, should only be used by those mobile nodes
which boot up on the home link using point-to-point links. The use
of the extensions specified in the section should be configurable on
the mobile node and the home agent.
A regular Binding Update, as defined in [2], cannot be used for
bootstrapping and obtaining configuration information when the mobile
node is on the home link. When the home agent receives a Binding
Update from a mobile node on the home link, it is treated as a de-
registration Binding Update. When the home agent receives the de-
registration Binding Update from the mobile node and it does not have
a valid binding cache entry for the mobile node, it responds with the
failed status 133 (Not home agent for this mobile node) in the
Binding Acknowledgement [2]. The DS-MIPv6 IPv4 home address and
Mobile Network prefixes will not be sent in the Binding
Acknowledgement, since the Binding Update is seen as a failed one.
This is one of the reasons why a new flag (the 'C' flag) is necessary
in the Binding Update.
Whenever the mobile node boots up on a point-to-point link, it first
configures information, including the IP address, specific to the
point-to-point link. The mobile node then initiates an IKEv2
exchange with the home agent as described in [3]. If the home agent
detects that the mobile node is sending IKEv2 messages from a point-
to-point link shared with the mobile node, it obtains the IPv6
address assigned to the mobile node for the point-to-point link, and
sends the same address in the INTERNAL_IP6_ADDRESS attribute in the
IKE_AUTH response message [3]. This indicates to the mobile node
Devarapalli, et al. Expires August 27, 2008 [Page 7]
Internet-Draft MIPv6 Home Link Operation February 2008
that the address it obtained earlier as part of point-to-point access
link setup, is now usable as the IPv6 home address also. The IKEv2
exchange also sets up the necessary security associations for
protecting the Binding Update and Binding Acknowledgement messages.
Once the IKEv2 exchange is complete, the mobile node sends a Binding
Update with the 'C' flag set to the home agent. The 'C' flag
indicates that this Binding Update is only being sent for
bootstrapping and not to create a binding cache entry. The bootstrap
information may include requests for the DS-MIPv6 IPv4 home address
[11], and the NEMO Mobile Network Prefixes [12]. The mobile node may
also indicate the service it wants to access using the service
selection option [13]. The Binding Update includes the home address
that the mobile node obtained earlier as part of the IKEv2 exchange.
When the home agent processes the Binding Update with the 'C' flag
set, it MUST treat the message as a Binding Update sent from the home
link. The home agent does not create a binding cache entry for the
mobile node. The home agent associates the point-to-point link over
which the Binding Update was received with the home address of the
mobile node. This is used to create a forwarding entry on the home
agent to forward packets meant for the mobile node's home address to
the point-to-point link shared with the mobile node. Once the
Binding Update processing is successful, the home agent responds with
a Binding Acknowledgement to the mobile node. In the Binding
Acknowledgement, the home agent indicates that it is sent from the
home link, by setting the 'C' bit. The home agent also includes
information like the IPv4 home address and the NEMO Mobile Network
Prefixes in the Binding Acknowledgement if the mobile node had
requested the same. If the IPv4 home address was sent by the home
agent, another forwarding entry is created to forward packets meant
for the IPv4 home address to the point-to-point link over which the
Binding Update was received.
When the mobile node receives a Binding Acknowledgement with the 'C'
flag set, it treats this message as a confirmation that it is
attached to the home link. The mobile node configures the IPv4 home
address as the DS-MIPv6 IPv4 home address. The mobile node obtains
other bootstrapping information it had requested for in the Binding
Update.
When the mobile node moves away its home link and attaches to the
visited link, it sends regular Mobile IPv6 Binding Updates to the
home agent.
Devarapalli, et al. Expires August 27, 2008 [Page 8]
Internet-Draft MIPv6 Home Link Operation February 2008
4.1. Modified Binding Update Message Format
The following shows the modified message format for the initial
Binding Update sent from the home link.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|C| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Link Exchange (C)
A new flag (C) that indicates that the Binding Update is sent from
the home link and is used for bootstrapping and configuration.
The rest of the fields in the Binding Update format illustrated above
are as described in [2], [10], [14] and [7].
4.2. Modified Binding Acknowledgement Message Format
The following shows the modified message format for the initial
Binding Acknowledgement sent from the home link.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|C| Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Devarapalli, et al. Expires August 27, 2008 [Page 9]
Internet-Draft MIPv6 Home Link Operation February 2008
Home Link Exchange (C)
A new flag (C) that indicates that the Binding Acknowledgement is
sent from the home link and is used for bootstrapping and
configuration.
The rest of the fields in the Binding Acknowledgement format
illustrated above are as described in [2], [10], and [7].
5. Security Considerations
This document does not introduce any new security considerations due
to the IKEv2 exchange and the Binding Update/Binding Acknowledgement
exchange between the mobile node and the home agent when the mobile
node boots up on the home link. Please see RFC 3775 [2] for security
considerations regarding the use of Mobile IPv6.
6. IANA Considerations
This document does not require any new assignments from IANA.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
7.2. Informative References
[4] 3rd Generation Partnership Project, "3GPP Technical
Specification 29.060 V8.2.0: Technical Specification Group Core
Network and Terminals; General Packet Radio Service (GPRS);
GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface
(Release 8)", December 2007.
[5] 3rd Generation Partnership Project, "3GPP Technical
Specification 23.402 V8.0.0: Technical Specification Group
Devarapalli, et al. Expires August 27, 2008 [Page 10]
Internet-Draft MIPv6 Home Link Operation February 2008
Services and System Aspects; Architecture enhancements for non-
3GPP accesses (Release 8)", December 2007.
[6] 3rd Generation Partnership Project, "3GPP Technical
Specification 23.327 V0.2.0: Technical Specification Group
Services and System Aspects; Mobility between 3GPP-Wireless
Local Area Network (WLAN) Interworking and 3GPP Systems
(Release 8)", January 2008.
[7] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-10
(work in progress), February 2008.
[8] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007.
[9] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in
progress), July 2007.
[10] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[11] Soliman, H., "Mobile IPv6 support for dual stack Hosts and
Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-06 (work
in progress), November 2007.
[12] Kniveton, T. and P. Thubert, "Mobile Network Prefix
Delegation", draft-ietf-nemo-prefix-delegation-02 (work in
progress), August 2007.
[13] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service
Selection for Mobile IPv6", draft-korhonen-mip6-service-06
(work in progress), December 2007.
[14] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
RFC 4140, August 2005.
Devarapalli, et al. Expires August 27, 2008 [Page 11]
Internet-Draft MIPv6 Home Link Operation February 2008
Authors' Addresses
Vijay Devarapalli
Azaire Networks
3121 Jay Street
Santa Clara, CA 95054
USA
Email: vijay.devarapalli@azairenet.com
Nishi Kant
Azaire Networks
3121 Jay Street
Santa Clara, CA 95054
USA
Email: nishi.kant@azairenet.com
Heeseon Lim
Azaire Networks
3121 Jay Street
Santa Clara, CA 95054
USA
Email: heeseon.lim@azairenet.com
Devarapalli, et al. Expires August 27, 2008 [Page 12]
Internet-Draft MIPv6 Home Link Operation February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Devarapalli, et al. Expires August 27, 2008 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:36 |