Internet DRAFT - draft-sarikaya-mext-multicastdmm
draft-sarikaya-mext-multicastdmm
Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Standards Track October 26, 2011
Expires: April 28, 2012
Distributed Mobility Management Protocol with Multicast Support
draft-sarikaya-mext-multicastdmm-04.txt
Abstract
As networks are moving towards flat architectures, a distributed
approach is needed to Mobile IPv6. This document defines a
distributed mobility management protocol with multicast support.
Protocol is based on Mobile IPv6 and its extensions for multiple care
of address registration, flow mobility and dual stack mobile IPv6
with minimum extensions. Control and data plane separation is
achieved by separating Home Agent functionalities into the control
and data planes.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 28, 2012.
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Sarikaya Expires April 28, 2012 [Page 1]
Internet-Draft DMM with Multicast October 2011
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Multicast State Mobility Option . . . . . . . . . . . . . 6
5. Correspondent Node Operation . . . . . . . . . . . . . . . . . 9
6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 9
7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 10
7.1. Multiple Interface Operation . . . . . . . . . . . . . . . 11
8. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Control and Data Plane Separation . . . . . . . . . . . . . . 13
10. Authentication for Distributed Mobility Management . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . . 15
14.2. Informative references . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Sarikaya Expires April 28, 2012 [Page 2]
Internet-Draft DMM with Multicast October 2011
1. Introduction
Mobile IPv6 defines client based mobility support to the mobile nodes
and is defined in [RFC6275]. There are several extensions to Mobile
IPv6 such as multiple Care-of Address registration for multi-homed
mobile nodes [RFC5648], flow mobility [RFC6089] and Dual Stack Mobile
IPv6 [RFC5555]. Mobile IPv6 is based on a centralized mobility
anchoring architecture.
Centralized mobility anchoring has several drawbacks such as single
point of failure, routing in a non optimal route, overloading of the
centralized data anchor point due to the data traffic increase, low
scalability of the centralized route and context management
[I-D.liu-mext-distributed-mobile-ip].
In this document, we define a client based distributed mobility
management protocol. The protocol assumes a flat network
architecture as shown in Figure 1
[I-D.liu-mext-distributed-mobile-ip]. Access router on each link
mobile node visits is expected to have the home agent capabilities.
Unlike in Mobile IPv6, mobile node at a given time may be registered
with more than one home agent and may be receiving data tunneled from
these home agents. Mobile IPv6 used in such a flat architecture
removes the need for route optimization which has many flaws such as
revealing the mobile nodes location to the outside
[I-D.liu-mext-distributed-mobile-ip].
Control and data plane separation is stated as a requirement for the
distributed mobility management. Mobile IPv6 control plane is used
for registration and handover signaling and for establishing security
association, e.g. IPSec SAs. Data plane is used for data transfer
from the corresponding nodes (CN) to MN and from MN to CNs.
Typically control plane traffic is much ligther than the data plane
traffic and thus the control plane can be centralized while
distributing the data plane. This separation however requires new
signaling between the control and data plane functional entities
[I-D.yokota-dmm-scenario].
Client based distributed mobility management protocol is designed
based on Mobile IPv6 protocols and its many extensions with a minimum
amount of extensions.
Due to the popularity of mobile nodes with multiple interfaces client
based distributed mobility management protocol must support multi-
homed mobile nodes. In this document, this is achieved by way of
using [RFC5648]. Flow mobility among the interfaces need to be
supported and this is accomplished using [RFC6089]. Mobile nodes in
IPv4 only networks also need to be supported and this is done using
Sarikaya Expires April 28, 2012 [Page 3]
Internet-Draft DMM with Multicast October 2011
[RFC5555].
Access to a content delivery network (CDN) is done using
multicasting. Mobile node operation for multicasting is needed for a
client based distributed mobility management protocol. The current
trend is that service providers tend to relieve the core network
traffic by placing the content closer to the users in the access
network in the form of cache or local CDN servers. Multicast support
in the client based distributed mobility management protocol is
designed to facilitate local access to the multicast groups.
+---+ +---+ +---+
|CN1| |CN2| |CN3|
+---+ +---+ +--,+
_.---------+----------. \
,----'' | `---'-.
,-' | \ `-.
,' | ' `.
( IP Network| \
`. | ' ,'
`-. ; ,\'
;-----. ; _.----' '
,' `---------+----------'' |
/ | '
+---'---+ +---:---+ +-------+
| AR1 | | AR2 |------------| AR3 |
| HA | | HA |------------|HA |
+-------+ +-------+ +-------+
\\ \
\\ '
+-----+ +--\--+
| MN | ----move-------> | MN |
+-----+ +-----+
Figure 1: Architecture of Distributed Mobile IPv6 Protocol
2. Terminology
This document uses the terminology defined in [RFC6275].
3. Overview
This section presents an overview of the protocol.
Home agent capable access routers (AR) send router advertisements
Sarikaya Expires April 28, 2012 [Page 4]
Internet-Draft DMM with Multicast October 2011
(RA) with Home Agent Information Option. Mobile node caches the home
agent address when it receives such an RA. Cache entries expire
after a timeout period. Only the first entry from MN's home link
does not expire.
Mobile node uses a home agent after it moves to another link and if
it still has ongoing communication with a correspondent node. MN
gets a new Care-of Address (CoA) on the new link and MN sends a
Binding Update message to the HA on the previous link to register CoA
with HA. Binding Acknowledgement received from HA completes the
registration. MN starts to receive the packets over HA-MN link from
CN and MN starts to reverse tunnel packets to the CN.
At each link, mobile node goes through bootstrapping if the router
advertisement from the access router does not contain Home Agent
Information Option. Using [RFC5026] MN either does DNS lookup by
home agent name or by service name. MN gets the local domain name
during link establishment. This constitutes dynamic assignment of
the home agent and [RFC5026] allows such a dynamic assignment as
mentioned in Section 5.1.1.
Alternatively, MN can use stateless DHCP for Home Info discovery as
in [I-D.ietf-mip6-hiopt]. Dynamic home agent address assignment
using DHCP is allowed as mentioned in Section 1.
After the bootstrapping, MN gets a new Care-of Address. MN uses this
new address as its new Home Address and registers it in the DNS. HA
can register MN's address in the DNS if MN sets DNS Update Mobility
Option defined in [RFC5026] and sends it in the binding update to HA.
MN sets R bit to zero. The procedure for sending a dynamic DNS
update message is specified in [RFC2136]. AAA server could also
register MN's new address in the DNS. MN also removes DNS entries
with MN's Home Addresses that are no longer used. MN sends BU with
DNS Update Mobility Option. MN sets the R flag in the option and
sets its old address as the FQDN in the option.
MN uses Cryptographically Generated Addresses if the link is a public
multi-access link. Wireless LAN links especially in public hotspots
are examples of such links.
Mobile nodes join multicast groups by sending join messages (MLD
Report) to the the MLD Querier currently available on the link. MLD
Querier after successfully joining the group receives multicast data
packets addressed to the group and delivers them to the mobile node.
The delivery could be made using Layer 2 means avoiding IPv6 packet
duplication. Mobile node multicast state (created by MLD/IGMP joins)
is associated with the air interface of the mobile node.
Sarikaya Expires April 28, 2012 [Page 5]
Internet-Draft DMM with Multicast October 2011
When the mobile node moves to a new link and creates a binding with
the home agent in the previous link, MN sets Multicast State mobility
option with all ongoing multicast group subscriptions of the mobile
node. The home agent as MLD Querier adds multicast state into the
binding cache entry for this mobile node and starts tunneling
multicast data to MN as in [RFC6275]. If there are more than one
mobile nodes that are members of the same multicast group then the
data packets are duplicated. Downstream multicast state for each
mobile node points to MN-HA tunnel interface at the home agent.
Similarly at the mobile node, multicast state for these groups do no
longer point to the air interface but to the tunnel interface that
the mobile node has established with the home agent.
4. Option Format
4.1. Multicast State Mobility Option
The multicast state mobility option is a new mobility option and it
is included in the binding update and acknowledgement messages.
Mobile node places its MLD multicast listener state in this option
before sending BU message. The receiver, the home agent uses this
option to establish the multicast state for this mobile node as MLD
Querier and starts serving the mobile node over the tunnel.
Sarikaya Expires April 28, 2012 [Page 6]
Internet-Draft DMM with Multicast October 2011
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 143 | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Nr of Mcast Address Records (M)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [1] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [2] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
. . .
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Multicast Address Record [M] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Multicast State Mobility Option
Option Type
TBA1 for MULTICAST-STATE-TYPE
Option Length
8-bit unsigned integer indicating the length of the option
excluding the type and length fields.
Multicast State Option Fields
Defined in [RFC3810].
Multicast address record has the following fields and each field is
as defined in [RFC3810].
Sarikaya Expires April 28, 2012 [Page 7]
Internet-Draft DMM with Multicast October 2011
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Type | Aux Data Len | Number of Sources (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Multicast Address *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
* *
| |
* Source Address [1] *
| |
* *
| |
+- -+
| |
* *
| |
* Source Address [2] *
| |
* *
| |
+- -+
. . .
. . .
. . .
+- -+
| |
* *
| |
* Source Address [N] *
| |
* *
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Auxiliary Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sarikaya Expires April 28, 2012 [Page 8]
Internet-Draft DMM with Multicast October 2011
5. Correspondent Node Operation
This protocol removes the need for route optimization. Corresponding
nodes receive regular IPv6 data packets sent by the mobile nodes and
reverse tunneled from the home agent. Also corresponding nodes do
not need to be involved in any route optimization message exchanges
nor maintaining state, i.e. binding cache.
Correspondent nodes when communicating with the same mobile node may
only receive regular IPv6 data packets with no mobility headers. In
some cases these packets are directly sent by the mobile node, i.e.
when the mobile node is not using its home agent and in some other
cases, i.e. when the mobile node starts using a home agent, coming
via the home agent.
6. Home Agent Operation
Home agent provides mobility support to the mobile nodes as defined
in [RFC6275].
Home agent receiving the DNS Update mobility option MUST process the
option as described in Section 6 of [RFC5026]. The dynamic DNS
update SHOULD be performed in a secure way. After the DNS update,
the home agent MUST send a Binding Acknowledgement message to the
Mobile Node, including the DNS Update mobility option with the
correct value in the Status field.
Home agent receiving the DNS Update mobility option with R-flag set
the Home Agent MUST remove the DNS entry and MUST send Binding
Acknowledgement message to the Mobile Node, including the DNS Update
mobility option with the correct value in the Status field. Home
agent MUST remove the DNS entry upon receiving a deregistration BU
from the mobile node. Home agent MAY use the binding cache entry
expiration as a trigger to remove the DNS entry.
In this specification route optimization is DISABLED. This means
that Home Test Init, Care-of Test Init, Home Test, Care-of Test
messages defined in [RFC6275] are not used in this specification.
Home agent MUST support MLD as MLD Querier for the mobile node.
Multicast state for the mobile node is usually established when
mobile node was on the link and the state in Multicast State mobility
option normally must match this state and the multicast state sent by
the mobile node becomes the multicast state of the mobile node when
communicating over MN-HA tunnel. In this specification, home agent
does not receive multicast join messages tunneled to the home agent.
Home agent gets this information from the multicast state mobility
Sarikaya Expires April 28, 2012 [Page 9]
Internet-Draft DMM with Multicast October 2011
option in the binding update message. After receiving this message
home agent makes sure that the mobile node has already subscribed to
each group from MLD Querier protocol state. Home agent changes IPv6
source address field in each source record in the set of records to
the Care-of Address of the mobile node as taken from the binding
update message. A binding cache entry MUST exist for each such
Care-of Address.
Home agent sends all multicast group management messages such as MLD
Report messages to the Care-of Address over the tunnel due to the
binding cache entry. Multicast data packets addressed to the groups
the mobile node is subscribed, i.e. Multicast Address is in
Multicast Address Record field of the multicast state the mobile node
sends, MUST be tunneled to the mobile node.
Home agent MUST support multiple Care-of address registration
[RFC5648] and flow mobility for multi homed mobile nodes [RFC6089].
Home agent MUST maintain several flow bindings for a given home
address and to direct packets to different care-of addresses
according to flow bindings. Home agent MUST keep a flow binding list
which is associated with the mobile node with an entry for each flow
that is registered.
Dual stack home agent MUST support Dual Stack Mobile IPv6 protocol
defined in [RFC5555]. When home agent receives Binding Update
message with IPv4 CoA option and IPv4 Home Address option home agent
sets a home address and/or prefix, creates a binding cache entry for
this mobile node and then sends back a binding acknowledgement
message with IPv4 Address Acknowledgement option which includes an
IPv4 home address.
7. Mobile Node Operation
Mobile nodes keep a cache of home agent addresses. This cache is
called Binding Update List in [RFC6275] and is used for route
optimization. In this specification, home agent cache or binding
update list is used to keep track of the home agents with which the
mobile node is currently registered and not for route optimization.
Mobile node sends periodic binding update messages to each home agent
in the home agent cache if the sessions initiated when mobile node
was on home agent's link. This keeps the HA-MN tunnel active.
Mobile node MAY send a deregistration BU when the sessions initiated
with the home agent are no longer active.
If mobile node receives a router advertisement with Home Agent
Information option it adds an entry to the home agent cache. Mobile
Sarikaya Expires April 28, 2012 [Page 10]
Internet-Draft DMM with Multicast October 2011
node does not establish a binding with a home agent until it moves to
a new link and still has active sessions initiated when on link. On
the new link, if a binding update message is not sent the cache entry
for this home agent is removed.
On a new link, mobile node does a DNS lookup for a Home Agent address
if it is configured with a DNS server address. If the Mobile Node is
configured with the Fully Qualified Domain Name of the Home Agent it
does DNS lookup by home agent name. Otherwise mobile node does DNS
lookup by service name and constructs a request with QNAME set to
"_mip6._ipv6.example.com" and QTYPE to SRV.
On a new link, mobile node does home agent address discovery using
stateless DHCP if configured. Mobile node as DHCP Client exchanges
home network information with DHCP server. Mobile node sends
Information-request message including the Home Network Information
option. Mobile node indicates its preference about the requested
home network with the Id-type in the Home Network Information option.
Mobile node MUST set the Id-type to 2 to indicate that the mobile
node has no preferred home network. Such a value is needed for
bootstrapping on any link. DHCP server returns the Reply message
including a Home Network Information option which contains home agent
address and home network prefix.
In the registration binding update message mobile node MUST set DNS
Update mobility option so that home agent does DNS update on its
behalf. Mobile node does not set the flag R in the option. Mobile
node sets the MN identity field in DNS Update option with its FQDN
and sets its Home Address in the Home Address Option. DNS update is
made based on these values.
Mobile node starts to use a home agent after it moves to a new link
and if it still has ongoing communication with a correspondent node.
MN registers its care-of address with the home agent. MN changes its
communication with the corresponding node: MN starts to receive the
packets over HA-MN link from CN and MN starts to reverse tunnel
packets to the CN. To the corresponding nodes this change is
invisible except for some additional delays the tirangular route may
introduce.
7.1. Multiple Interface Operation
When a new interface becomes active such as Wi-Fi the mobile node
forms an address and starts using that interface for communication on
that link. No home agent is involved. When the mobile node starts
to use a home agent any new communication on the new interface MUST
use the registered home address. Mobile node MUST register its
care-of address with this home agent as described in [RFC5648]. In
Sarikaya Expires April 28, 2012 [Page 11]
Internet-Draft DMM with Multicast October 2011
the Binding Update message, Binding Identifier Mobility option
defined in MUST be used. Mobile node MUST assign a BID for this
Care-of Address which is unique. Mobile node also MUST assign a BID-
PRI for this BID with lower value indicating a higher priority. If
the registration is successful mobile node receives a binding
acknowledgement with Status set to zero in the Binding Identifier
Mobility option.
Multiple Care-of address registration allows flow mobility between
interfaces of a mobile node. Mobile node can then move flows by
sending BU with flow identification mobility option.
Multiple interfaces and possible use of multiple home address
registered with the home agents makes it important for the mobile
node to select the correct source address in sending packets.
8. IPv4 Support
Dual stack home agent MUST support IGMP for multicasting. Home agent
is IGMP Querier for the mobile node. Mobile nodes or IGMP listeners
could be supported over tunnel interface. Reception state for the
mobile node is initialized to the value received in the multicast
state mobility option received in the registration binding update.
For IGMP, the type value is 0x22 containing the same fields as in
Figure 2 also as defined in [RFC3376] Section 4.2.
In IPv4 only foreign networks mobile node gets an IPv4 care-of
address. It registers this address with a dual stack home agent only
after moving to a new link and with open sessions with the
correspondent nodes. Mobile node includes IPv4 CoA option and IPv4
Home Address option in the binding update message when registering
and gets an IPv4 Home Address assigned. Mobile node does a DNS
update registering its IPv4 home address on the DNS.
In IPv4 only foreign networks mobile node does stateless DHCP in
order to receive the home network information. Mobile node MUST use
Home Network Information DHCPv4 option defined in
[I-D.xia-mext-hioptv4].
Sarikaya Expires April 28, 2012 [Page 12]
Internet-Draft DMM with Multicast October 2011
9. Control and Data Plane Separation
------------+----------.
/ Binding Cache and \
| Security Associations |
\ /
-------------------------
,-' | `-.
+---'----+ +---:----+ +--------+
| HA | | HA | | HA |
| Data | | Data | | Control|
| Plane | | Plane | | Plane |
|Function| |Function| |Function|
+--------+ +--------+ +--------+
/ \\ \
/ \\ '
+-----+ +--\--+
| MN |---move----> | MN |
+-----+ +-----+
Figure 3: Architecture of Control and Data Planes
Control and data plane separation can be achieved by dividing HA into
two functional entities: control plane functional entity and data
plane functional entity as shown in Figure 3. These functional
entities can be hosted on different physical entities. These two
entities must share a common database. The database contains the
binding cache and the security association information such as IPSec
keys.
MN first communicates with the control plane function to establish
security association. Address configuration and binding registration
follows. Next MN receives/sends data packets using the data plane
function closest to the link MN is attached.
When MN moves MN does handover signaling with the control plane
function which updates the binding cache based on this move. Control
plane function informs the new data plane function of this binding
cache update and then this MN starts to receive and send data to the
new data plane function. MN MUST keep HA control plane function
address in cache so that it can conduct handover signaling with it.
When MN boots, it goes through authentication and security
association establishment. Next MN sends a binding update. MN does
these steps with HA control plane function. MN sends Binding Update
message to HA control plane function and receives a Binding
Acknowledgement message and in this message MN MUST receive HA data
plane function address.
Sarikaya Expires April 28, 2012 [Page 13]
Internet-Draft DMM with Multicast October 2011
HA data plane function address can be provided by HA control plane
function to MN in Alternate Care-of Address option of BA message
[RFC6275]. HA control plane function may also use
[I-D.perkins-mext-hatunaddr] and provide the address in Alternate
Home Agent Tunnel Address option.
Control and data plane separation does not require protocol
extensions except the sharing of binding cache and security
associations database. How this sharing can be accomplished is left
out of scope with this specification.
10. Authentication for Distributed Mobility Management
Currently, MN and HA create security associations (SA) based on the
home address using IKEv2 as the key exchange protocol. When MN moves
SAs are reestablished when MN gets a new care-of address. After SA
is established, MN and HA use Encapsulating Security Payload (ESP)
encapsulation for Binding Updates and Binding Acknowledgements
[RFC4877].
IKEv2 enables the use of EAP authentication and provides EAP
transport between MN as the peer and HA as the authenticator. EAP
authentication is done using one of the EAP methods such as EAP-AKA
[RFC4187].
MN is authorized as a valid user using EAP authentication. IKEv2
public key signature authentication with certificates is used to
authenticate the home agent and derive keys to be used in exchanging
BU/BA securely. MN can use the same identity, e.g. MN-NAI during
both EAP and IKEv2 authentication.
On the other hand MN goes through the access authentication when it
first connects to the network. A typical access authentication
protocol is AKA. MSK derived from this authentication serves as the
session key in accessing the air interface.
There is an overlap between the access and user authentications
sometimes done using the same protocol, e.g. AKA. Full EAP method
execution may take several round trips, some times five or more round
trips and slow down the user access to the Internet. This is
especially an important consideration in Distributed Mobility
Management since MN may connect to several home agents instead of
staying anchored at one home agent.
In order to reduce the number of round trips EAP authenticaton can be
combined with reauthentication. Reauthentication is EAP method
dependent. EAP-AKA reauthentication takes only one round trip
Sarikaya Expires April 28, 2012 [Page 14]
Internet-Draft DMM with Multicast October 2011
[RFC4187]. MN must go through an EAP-AKA reauthentication before
when MN was connected to the previous HA. During reauthentication
reauthentication ID is generated. MN MUST use its reauthentication
ID during IKEv2 EAP authentication with the new home agent. This
ensures that EAP-AKA authentication takes only one round trip. MN
continues to use its reauthentication ID in subsequent
reauthentication runs with the same HA.
11. Security Considerations
TBD.
12. IANA Considerations
TBD.
13. Acknowledgements
Romain Kuntz provided many comments that has lead to improvements in
this document.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
Sarikaya Expires April 28, 2012 [Page 15]
Internet-Draft DMM with Multicast October 2011
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089,
January 2011.
[I-D.ietf-mip6-hiopt]
Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP
Options for Home Information Discovery in MIPv6",
draft-ietf-mip6-hiopt-17 (work in progress), May 2008.
[I-D.xia-mext-hioptv4]
Xia, F. and B. Sarikaya, "DHCPv4 Options for Home
Information Discovery in Dual Stack MIPv6",
draft-xia-mext-hioptv4-03 (work in progress), July 2011.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
14.2. Informative references
[I-D.liu-mext-distributed-mobile-ip]
Liu, D., "Distributed Deployment of Mobile IPv6",
draft-liu-mext-distributed-mobile-ip-00 (work in
progress), March 2011.
[I-D.yokota-dmm-scenario]
Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case
scenarios for Distributed Mobility Management",
draft-yokota-dmm-scenario-00 (work in progress),
October 2010.
[I-D.perkins-mext-hatunaddr]
Perkins, C., "Alternate Tunnel Source Address for Home
Agent", draft-perkins-mext-hatunaddr-01 (work in
progress), August 2011.
Sarikaya Expires April 28, 2012 [Page 16]
Internet-Draft DMM with Multicast October 2011
Author's Address
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 175
Plano, TX 75074
Phone: +1 469 277 5839
Email: sarikaya@ieee.org
Sarikaya Expires April 28, 2012 [Page 17]
