Network Working Group K. Chowdhury
Internet-Draft Starent Networks
Expires: March 12, 2007 A. Singh
Motorola
September 8, 2006
Network Based Layer 3 Connectivity and Mobility Management for IPv6
draft-chowdhury-netmip6-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 March 12, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The layer 3 connection and mobility management is essential in
providing seamless access to services and enhanced user experience in
a mobile and nomadic envoirnment. This document defines a mechanism
via which service providers can deploy a managed layer 3 connectivity
and mobility management scheme that is entirely based on the
capabilities in the Network.
Chowdhury & Singh Expires March 12, 2007 [Page 1]
Internet-Draft September 2006
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3
2. Terminology & Definitions . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Network Connection Setup for IPv6 . . . . . . . . . . . . 4
3.2 Network Connection Setup for IPv4 . . . . . . . . . . . . 6
3.3 Inter AR Handoff . . . . . . . . . . . . . . . . . . . . . 8
4. ICMPv6 Enhancements for Inter AR Interaction . . . . . . . . . 10
4.1 HO Request Message . . . . . . . . . . . . . . . . . . . . 10
4.2 HO Response Message . . . . . . . . . . . . . . . . . . . 12
5. HMIPv6 Considerations . . . . . . . . . . . . . . . . . . . . 14
5.1 Network Based HMIPv6 Operation . . . . . . . . . . . . . . 14
5.2 Net-HMIPv6 and MIPv6 Interaction . . . . . . . . . . . . . 15
6. Node Requirements . . . . . . . . . . . . . . . . . . . . . . 15
6.1 Mobile Node Requirements . . . . . . . . . . . . . . . . . 15
6.2 Access Router/NetMIPv6 Client Requirements . . . . . . . . 15
6.3 Home Agent Requirements . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 19
Chowdhury & Singh Expires March 12, 2007 [Page 2]
Internet-Draft September 2006
1. Introduction and Scope
Network based L3 mobility management allows any mobile node to
connect to a mobile wireless network and maintain it's L3
connectivity while crossing link boundaries. This type of mobility
management solution does not necessarily require any Mobile IPv6
implementation in the mobile node. Rather, the L3 mobility is
handled entirely in the network via a Mobile IPv6 function in a
network node such as an Access Router (AR).
In a typical mobile wireless network the inter base station handoffs
(often called L2 handoffs) are handled by local mobility management
protocols. There are various flavors of such protocols deployed
today. When the mobile node incurs handoff to a base station that is
attached to an Access Router in a different link than the current
one, the L3 mobility management procedure is invoked by the mobile
node to re-register the new Care-of Address with the Home Agent.
However, if the mobile node does not have Mobile IPv6 implementation
it's L3 will break and the session will terminate abnormally. If the
mobile node has Mobile IPv6 implementation, there are solutions to
handle inter AR handoffs via techniques like Fast MIPv6 [RFC4068].
The solution offers early establishment of the link with the new AR
albeit requiring number of messages exchanged over the air and still
requiring the mobile node to re-register with the Home Agent even if
the mobile user is in the middle of a real time conversation. The
requirement of additional messaging over the air to manage handoff
that can be easily managed by the network nodes is a problem that
this document addresses.
There are other reasons why network based IPv6 mobility makes perfect
sense. For example, the network operators are deploying more than
one access technology for the wireless data users. These wireless
technologies are being developed in different standerdization
organizations such as 3GPP2, WiMAX forum, 3GPP etc. The standards
developed by these organizations do impose some level of requirements
on the MN's. However it becomes impractical to assume uniform
capabilities acorss MNs of different access technologies. Ideally
the operator's core IP network should be able handle any type of MN
regardless of Mobile IPv6 capabiliy and use of client based Mobile
IPv6 in the MN. For this reason, Mobile IPv6 is being considered for
deployment in various standerdazation organisations.
The solution provided in this document allows any mobile node to
connect to the network and be mobile without Mobile IPv6 in the
mobile node and without losing its L3 connectivity or having to
perform additional signaling to maintain L3 connectivity during
handoffs.
Chowdhury & Singh Expires March 12, 2007 [Page 3]
Internet-Draft September 2006
2. Terminology & Definitions
The keywords "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].
The definitions of some new terms that are used in this document:
SAR: Serving Access Router
TAR: Target Access Router
3. Solution Overview
The solution has two aspects. The first aspect deals with the
network connection setup. The second aspect deals with the L3
mobility management.
3.1 Network Connection Setup for IPv6
The mobile node connects to the mobile wireless network via any
access technology e.g. CDMA, GPRS, 802.11, 802.16e etc. After
establishing L2 connection with the network, the mobile node
initiates L3 establishment by requesting an IPv6 address from the
network. There are various ways the mobile node can request for an
IPv6 address e.g. IPv6CP [RFC2472], IPv6 stateless address autoconf
[RFC2462], and DHCPv6 [RFC3315].
The following message sequence diagram shows the network connectivity
procedure.
Chowdhury & Singh Expires March 12, 2007 [Page 4]
Internet-Draft September 2006
+----+ +-------+ +-------+ +-----+
| | | AR/ | | | | |
| MN | | MIPv6 | | AAA | | HA |
| | | Client| | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1a | 1b | |
|<------------->|<----------->| |
| | | |
| 2 | | |
|-------------->| | |
| | 3 | |
| |----------------------->|
| | | |
| | 4 | |
| |<-----------------------|
| 5 | | |
|<--------------| | |
| | | |
| 6 | | |
|<------------->|<===========>|<========>|
| | | |
Figure 1. Network Connection Setup for IPv6 with MIPv6 Function in
the AR.
Description of the steps:
1a. MN and the NAS performs L2 establishment with the base station
(not shown) and performs access authentication/authorization. During
this phase, the MN may run CHAP or PAP if PPP is used or EAP over foo
if PPP is not used. The AR acts as the NAS in this phase.
1b. The NAS exchanges AAA messages with the AAA infrastructure to
perform authentication and authorization of the MN. As part of this
step, the AAA server may download some information about the MN (e.g.
user's profile, handset type, assigned home agent address, and other
capabilities of the MN) if needed.
2. The MN sends an IPv6CP config request to the NAS/AR in case of
PPP to configure the IID. Subsequently, the MN sends an Router
Solicitation to request an IPv6 address prefix. If DHCPv6 is used,
the DHCPv6 client in the MN sends a DHCP SOLICIT or REQUEST message.
It is assumed in this document that the AR has a DHCPv6 proxy/server
function.
Chowdhury & Singh Expires March 12, 2007 [Page 5]
Internet-Draft September 2006
3. Triggered by step 2 the MIPv6 Client in the AR (Net-MIPv6) sends
a Mobile IPv6 Binding Update (BU) to the Home Agent. The Home
Agent's address if either received at step 1b from the Home AAA or it
is provisioned in a out of band way at the AR. The BU contains the
Care-of Address (CoA) of the AR. The HoA field is set to ALL-ZERO-
ONES-ADDRESS if not already assigned by the AAA at step 1b. It is
assumed that the AR and the HA either has an IPsec SA setup to
protect the BU and the AR and the HA uses auth protocol [RFC4285]
based security. These security aspects are to be defined in more
details either in the current document or in some other document.
4. The home agent registers the MN's session and assigns an HoA.
The home agent returns the HoA in the BA.
5. The AR/NAS sends an RA with IPv6 address prefix with the prefix
of the HoA to the MN. If DHCPv6 was used at step 2, the AR/
DHCP-proxy/server sends back a DHCP Reply with the IPv6 address set
to the received HoA.
6. At this step, the MN's IPv6 stack is ready to receive or send
IPv6 packets. If DHCPv6 is used, the regular DHCPv6 messages are
exchanged and the MN's IPv6 stack is configured with the assigned
IPv6 address.
3.2 Network Connection Setup for IPv4
The network based connectivity and mobility management protocol
defined in this document can be used to support IPv4 MNs as well.
The mobile node connects to the mobile wireless network via any
access technology e.g. CDMA, GPRS, 802.11, 802.16e etc. After
establishing L2 connection with the network, the mobile node
initiates L3 establishment by requesting an IPv4 address from the
network. There are various ways the mobile node can request an IPv4
address e.g. IPCP [RFC1332], or DHCP [RFC2132].
The following message sequence diagram shows the network connectivity
procedure.
Chowdhury & Singh Expires March 12, 2007 [Page 6]
Internet-Draft September 2006
+----+ +-------+ +-------+ +-----+
| | | AR/ | | | | |
| MN | | MIPv6 | | AAA | | HA |
| | | Client| | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1a | 1b | |
|<------------->|<----------->| |
| | | |
| 2 | | |
|-------------->| | |
| | 3 | |
| |----------------------->|
| | | |
| | 4 | |
| |<-----------------------|
| 5 | | |
|<--------------| | |
| | | |
| 6 | | |
|<------------->|<===========>|<========>|
| | | |
Figure 1. Network Connection Setup for IPv4 with MIPv6 Function in
the AR.
Description of the steps:
1a. MN and the NAS performs L2 establishment with the base station
(not shown) and performs access authentication/authorization. During
this phase, the MN may run CHAP or PAP if PPP is used or EAP over foo
if PPP is not used. The AR acts as the NAS in this phase.
1b. The NAS exchanges AAA messages with the AAA infrastructure to
perform authentication and authorization of the MN. As part of this
step, the AAA server may download some information about the MN (e.g.
user's profile, handset type, assigned home agent address, and other
capabilities of the MN) if needed.
2. The MN sends an IPCP config request to the NAS/AR in case of PPP
to configure the IPv4 address. If DHCP is used, the DHCP client in
the MN sends a DHCP DISCOVER message. It is assumed in this document
that the AR has a DHCP proxy/server function.
3. Triggered by step 2 the MIPv6 Client in the AR (Net-MIPv6) sends
Chowdhury & Singh Expires March 12, 2007 [Page 7]
Internet-Draft September 2006
a Mobile IPv6 Binding Update (BU) to the Home Agent. The Home
Agent's address if either received at step 1b from the Home AAA or it
is provisioned in a out of band way at the AR. The BU contains the
Care-of Address (CoA) of the AR. The HoA field is set to ALL-ZERO-
ONES-ADDRESS. The BU contains the IPv4 home address option [DSMIPv6]
with IPv4 home address field set to 0.0.0.0 and P-bit not set. It is
assumed that the AR and the HA either has an IPsec SA setup to
protect the BU and the AR and the HA uses auth protocol [RFC4285]
based security. These security aspects are to be defined in more
details either in the current document or in some other document.
4. The home agent registers the MN's session and assigns an IPv4
HoA. The home agent returns the IPv4 HoA in IPv4 home address option
in the BA.
5. The AR/NAS sends an IPCP configure-NACK with IPv4 address to the
MN. If DHCP was used at step 2, the AR/DHCP-proxy/server sends back
a DHCP OFFER with the IPv4 address set to the received IPv4 HoA.
6. At this step, the MN's IPv4 stack is ready to receive or send
IPv4 packets. If DHCP is used, the regular DHCP messages are
exchanged and the MN's IPv4 stack is configured with the assigned
IPv4 address.
3.3 Inter AR Handoff
After connecting to the access network, the MN may incur inter AR
handoff due to mobility. This poses the challenge of keeping the L3
connection for the MN intact due to possible change in the link.
The following message sequence diagram shows how the network
connectivity can be maintained across an inter AR handoff.
Chowdhury & Singh Expires March 12, 2007 [Page 8]
Internet-Draft September 2006
+----+ +-------+ +-------+ +-----+
| | | | | | | |
| MN | | SAR | | TAR | | HA |
| | | | | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| 1 | | |
|<------------->|<======================>|
| | | |
| | 2.HO trigger |
| | arrives |
| | | |
| | 3 | |
| |<------------| |
| | | |
| | 4 | |
| |------------>| |
| | | |
| | | 5 |
| | |--------->|
| | | |
| | | 6 |
| | |<---------|
| | | |
| | | Bi-cast(optional)
MN connects 7.HO occurs | |
L2 at | | |
new BS | | |
| | 8 | |
| X------------------------X
| | | |
| | | |
| | 9 | |
|<--------------------------->|<========>|
| | | |
Figure 1. Inter AR Mobility Management with MIPv6 Client in the AR.
Description of the steps:
1. MN is connected at the Serving AR (SAR) and it is sending/
receiving data via SAR. The HA has a tunnel established with the
SAR.
2. The MN moves into an area of a target Base Station (not shown in
Chowdhury & Singh Expires March 12, 2007 [Page 9]
Internet-Draft September 2006
the figure) that is connected to a target AR (TAR). The target BS
sends a HO indication message (out of scope of this document) to the
target AR. This message contains the address of the SAR and the MN
identifier (NAI) among other parameters.
3. Based on the trigger at step 2, the TAR sends a HO Request
message to the SAR to fetch the relevant context for the MN. The
ICMPv6 HO Request message is defined in the following section of
this document. Note that the TAR and the SAR share a security
association. The HO Request message can be protected with an IPsec
authentication header using the security association between the ARs.
4. Upon receiving the HO Request message the SAR validates it by
checking it's security association with the TAR. if the validation
succeeds, the SAR sends all the state information (context) for the
identified MN to the TAR in a ICMPv6 HO Response message.
5. The Mobile IPv6 Client in the TAR sends a Binding Update to the
HA with its' CoA (CoA of the TAR) and sets the HoA to the HoA of the
MN which is received as part of the state information at step 4.
6. Upon receiving the BU from the TAR, the HA updates it's BCE with
the new CoA and an HoA to the MN and returns the HoA in an RRP.
Since the binding/tunnel with the SAR is still not torn down, the HA
has an option of bi-casting to both SAR and TAR at this time.
7. At this time, the MN connects L2 with the target BS. The target
BS (not shown in the figure for brevity) informs the TAR that the MN
has connected to the target system. The Serving BS also detects that
the handoff (L2 torn down with the MN) and it informs the SAR about
this event.
8. Upon receiving the HO event from the Serving BS, the SAR tears
down the tunnel with the HA.
9. The MN continues to receive service (i.e. send/receive data) with
the same IPv6 address which is the HoA. The MN is agnostic to the L3
mobility procedures in the network.
4. ICMPv6 Enhancements for Inter AR Interaction
The format of the inter AR messages are defined here:
4.1 HO Request Message
The HO Request message is an inter AR message used for HO
notification and request for context transfer. The message is
formatted as follows:
Chowdhury & Singh Expires March 12, 2007 [Page 10]
Internet-Draft September 2006
IP Fields:
Source Address
The IPv6 address of the TAR.
Destination Address
The IPv6 address of the SAR.
Hop Limit
255, refer to [RFC2461].
Authentication Header
The authentication header SHOULD be used, ref [RFC2402].
The ICMPv6 message has the following fields as shown below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |C|H| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options.....
+-------------------------------
Type
A 8-bit field indicating the type of the message. To be assigned
by IANA.
Code
TBD, to be assigned by IANA.
Checksum
An 16-bit Checksum of the ICMPv6 message.
Chowdhury & Singh Expires March 12, 2007 [Page 11]
Internet-Draft September 2006
Identifier
An 16-bit string that the sender uses to match the corresponding
response from the receiver.
C-bit
If set, the sender is requesting context transfer for the
identified MN.
H-bit
By setting this bit the sender informs the receiver that the
reason for this message is a handoff by the identified MN.
Options
This message can carry several options to help identify the proper
context in the receiver. The options MUST be encoded as defined
in [RFC2461].
An option carrying MN's identity (e.g. NAI) MUST be included in
this message.
4.2 HO Response Message
The HO Response message is an inter AR message that is used to
respond to an HO Request message. The message is formatted as
follows:
IP Fields:
Source Address
The IPv6 address of the SAR.
Destination Address
The IPv6 address of the TAR.
Hop Limit
255, refer to [RFC2461].
Chowdhury & Singh Expires March 12, 2007 [Page 12]
Internet-Draft September 2006
Authentication Header
The authentication header SHOULD be used, ref [RFC2402].
The ICMPv6 message has the following fields as shown below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A 8-bit field indicating the type of the message. To be assigned
by IANA.
Code
TBD, to be assigned by IANA.
Checksum
An 16-bit Checksum of the ICMPv6 message.
Identifier
An 16-bit string that is copied from the corresponding field in
the HO Request message.
Status Code
The 8-bit Status Code is used by the sender of this message to
convey the status of the corresponding request. The following
values are defined at this time:
0: Success.
1: Failure, Poorly Formatted Request.
2: Failure, Authentication failed.
Chowdhury & Singh Expires March 12, 2007 [Page 13]
Internet-Draft September 2006
3: Failure, Unable to locate Context.
4: Failure, Administratively Prohibited.
All other values are reserved.
5. HMIPv6 Considerations
HMIPv6 [RFC4140] is a MIPv6 (experimental) extension to support
localized mobility management. The base HMIPv6 protocol supports
mobile controlled mobility management and hence requires MN to be
aware of the MN's local CoA, Regional CoA and HoA. The MN manages
localized mobility management (e.g., mobility inside a MAP domain) by
updating binding between LCoA and RCoA while it moves inside the
coverage area of the MAP (Mobility Anchor Point, ref: RFC4140)
domain. It performs Global Mobility Management (e.g., inter-MAP
mobility) by updating binding between RCoA and HA to Home Agent and
CN while it moves from one MAP domain to other. The use of vanilla
HMIPv6 enables mobile controlled localized mobility management, but
does not enable network controlled mobility management required by
some deployments.
5.1 Network Based HMIPv6 Operation
In some special deployment scenarios localized mobility management
may be desired. In this document, we are proposing a network
controlled mobility management scheme that is based on modified
HMIPv6 protocol, Net-HMIPv6. The Net-HMIPv6 protocol re-uses HMIPv6
signaling and HMIPv6 MAP function to enable network controlled
localized mobility management. The Net-HMIPv6 protocol introduces a
network based MIPv6 Client (NetMIPv6) that is responsible for sending
binding updates on behalf of a MN to the MAP. The NetMIPv6 Client
performs mobility management signaling on behalf of a MN as long as
the MN moves inside the coverage area of a given MAP domain. The
NetMIPv6 Client uses link layer specific mechanism to detect movement
of a mobile node from one AR to other AR inside a MAP domain. To
manage intra-MAP mobility on behalf of MN, the NetMIpv6 Client keeps
updating the MAP about the mapping between LCoA and RCoA every time
the MN changes its point of attachment from one AR to another inside
the same MAP domain. The MIPv6 protocol can be used along with Net-
HMIPv6 to provide global mobility management when a MN moves from one
MAP to other. The NetMIPv6 Client also acquires local care of
address every time a mobile moves from one MAP domain to another.
The LCoA is derived using TAR prefix information and RCoA is derived
using MAP prefix information. The Net-HMIPv6 solution uses trust
model between the NetMIPv6 Client and the MAP in place of end-to-end
security model of HMIPv6 as end-to-end security may be difficult to
Chowdhury & Singh Expires March 12, 2007 [Page 14]
Internet-Draft September 2006
achieve in this mode of operation. The subsequent revisions of this
document will investigate further the end-to-end security model if
any that can be used to along with Net-HMIPv6 based solution.
5.2 Net-HMIPv6 and MIPv6 Interaction
The Net-HMIPv6 is able to inter-work with vanilla Mobile Node based
MIPv6 protocol (C-MIPv6) [RFC3775]. The C-MIPv6 protocol is used to
manage Mobility when a MN moves from one AR to other within a given
MAP. To avoid the MN to initiate C-MIPv6 as long it moves from SAR
to TAR inside a given MAP domain, the proposed Net-HMIPv6 solution
requires that ARs belonging to a given MAP domain to advertise prefix
associated with the MAP instead of its own prefix. This is required
to prohibit the C-MIPv6 stack in the MN to initiate mobility
management signaing over the air when it moves from one AR to another
inside a given mobility domain. The advertisement of MAP prefix to
the MN ensures that the MN only detects prefix change when it moves
away from one MAP to other. If the Client does not have a C-MIPv6
implementation mobility management is entirely performed by the
network nodes as described in section 3 of this document, this
requirement on the ARs does not apply.
6. Node Requirements
This section describes the requirements for each of the nodes
involved.
6.1 Mobile Node Requirements
This solution does not impose any new requirement on the MN. Any MN
with an IPv6 stack and DHCPv6 or IPv6CP implementations should work.
6.2 Access Router/NetMIPv6 Client Requirements
the NetMIPv6 Client shall perform the mobility binding creation,
modification and deletion functions on behalf of the MN. The
NetMIPv6 Client shall support Mobile IPv6 protocol as defined in RFC
3775, and RFC 4285. The user identifier e.g. NAI of the user can be
extracted from lower layer protocols, e.g. PPP and MUST be included
in client identifier option as defiend in [RFC4283]. The NetMIPv6
client SHALL maintain and update the mobility binding for the MN as
long as the MN has an IP session with the AR. The NetMIPv6 client
MAY support the IPv4 Home Address Option as defined in [DSMIPv6].
The NetMIPv6 client MAY support the HMIPv6 extentions [RFC4140].
In order to support inter AR HO, the AR SHOULD support HO Request and
HO Response messages defined in this document.
Chowdhury & Singh Expires March 12, 2007 [Page 15]
Internet-Draft September 2006
6.3 Home Agent Requirements
The HA MUST support the basic Mobile IPv6 operational requirments as
defined in RFC 3775, and RFC 4285. The HA shall also support client
identifier option as defined in [RFC4283]. The HA MAY support HMIPv6
extenstions. The HA SHOULD support the IPv4 Home Address option as
defined in [DSMIPv6].
7. Security Considerations
The HO Request and the HO Response messages SHOULD be protected via
IPsec AH. In the absence of such security, the context information
of the MN's ongoing session at the SAR may be compromised when sent
to a rogue AR.
At the time of L2 establishment, the SAR may receive security keying
information for the MN from the Home AAA server that can be used to
secure the subsequent BU. The HA should be able to retrieve the
corresponding security keying material from the Home AAA server to
process the BU and send the BA.
Alternatively, if individual security keying material per MN are not
available at the AR and the HA, the AR and the HA SHOULD secure the
BU/BA by a common security association that they share.
The support for Route Optimization and the associated security
mechanism to protect the return routability signaling is outside the
scope of this document. The mechanism proposed in this document
allows dynamic HA assignment. Hence the possibility of a inefficient
transport due to reverse tunnel can be significantly mitigated.
HMIPv6 supports end-to-end security. However, use of Net-HMIPv6
based approach would require trust between NetMIPv6 Client in the AR
and the MAP. Also, it is to be noted that security of HMIPv6 is
closely tied to RCoA allocation, hence RCoA need to be allocated in
such a way that uniqueness of RCoA allocation is guaranteed otherwise
existing HMIPv6 security would break.
8. IANA Considerations
The following ICMPv6 messages need IANA assignment:
HO Request:
Type: TBD-1.
Code: TBD-2.
Chowdhury & Singh Expires March 12, 2007 [Page 16]
Internet-Draft September 2006
HO Response:
Type: TBD-3.
Code: TBD-4.
9. Acknowledgements
TBD.
10. Normative References
[DSMIPv6] Soliman et. al., H., "Mobile IPv6 support for dual stack
Hosts and Routers",
draft-ietf-mip6-nemo-v4traversal-02.txt (work in
progress), June 2006.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
Chowdhury & Singh Expires March 12, 2007 [Page 17]
Internet-Draft September 2006
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Authentication Protocol for Mobile IPv6",
RFC 4285, January 2006.
Authors' Addresses
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Phone: +1 214-550-1416
Email: kchowdhury@starentnetworks.com
Ajoy Singh
Motorola
1421 West Shure Dr.
Arlington Heights, IL 60004
US
Phone: +1 847-632-6941
Email: asingh1@email.mot.com
Chowdhury & Singh Expires March 12, 2007 [Page 18]
Internet-Draft September 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Chowdhury & Singh Expires March 12, 2007 [Page 19]