draft-ietf-mip6-bootstrapping-integrated-dhc-06.txt   rfc6611.txt 
Network Working Group K. Chowdhury, Editor Internet Engineering Task Force (IETF) K. Chowdhury, Ed.
Internet-Draft Starent Networks Request for Comments: 6611 Radio Mobile Access, Inc.
Intended status: Standards Track A. Yegin Category: Standards Track A. Yegin
Expires: October 22, 2008 Samsung AIT ISSN: 2070-1721 Samsung
April 20, 2008 May 2012
MIP6-bootstrapping for the Integrated Scenario
draft-ietf-mip6-bootstrapping-integrated-06.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 October 22, 2008. Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario
Abstract Abstract
Mobile IPv6 bootstrapping can be categorized into two primary Mobile IPv6 bootstrapping can be categorized into two primary
scenarios, the split scenario and the integrated scenario. In the scenarios: the split scenario and the integrated scenario. In the
split scenario, the mobile node's mobility service is authorized by a split scenario, the mobile node's mobility service is authorized by a
different service authorizer than the network access authorizer. In different service authorizer than the network access authorizer. In
the integrated scenario, the mobile node's mobility service is the integrated scenario, the mobile node's mobility service is
authorized by the same service authorizer as the network access authorized by the same service authorizer as the network access
service authorizer. This document defines a method for home agent service authorizer. This document defines a method for home agent
information discovery for the integrated scenario. information discovery for the integrated scenario.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6611.
Copyright Notice
Copyright (c) 2012 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
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 1. Introduction and Scope ..........................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................3
3. Assumptions & Conformance . . . . . . . . . . . . . . . . . . 5 3. Assumptions and Conformance .....................................4
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Solution Overview ...............................................5
4.1. Logical View of the Integrated Scenario . . . . . . . . . 6 4.1. Logical View of the Integrated Scenario ....................5
4.2. Bootstrapping Message Sequence . . . . . . . . . . . . . . 7 4.2. Bootstrapping Message Sequence .............................6
4.2.1. Home Agent allocation in the MSP . . . . . . . . . . . 8 4.2.1. Home Agent Allocation in the MSP ....................7
4.2.2. Home Agent allocation in the ASP . . . . . . . . . . . 9 4.2.2. Home Agent Allocation in the ASP ....................9
4.3. Bootstrapping Message Sequence: Fallback case . . . . . . 10 4.3. Bootstrapping Message Sequence: Fallback Case .............10
4.4. HoA and IKEv2 SA Bootstrapping in the Integrated 4.4. HoA and IKEv2 SA Bootstrapping in the Integrated
Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 11 Scenario ..................................................10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations ........................................10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements ...............................................11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. Contributors ...................................................11
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References .....................................................11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References ......................................11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References ....................................12
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction and Scope 1. Introduction and Scope
The Mobile IPv6 protocol [RFC3775] requires the mobile node to have The Mobile IPv6 protocol [RFC6275] requires the mobile node to have
information of its Home Address, the home agent address and the the following information:
cryptographic materials for establishing an IPsec security
association with the home agent prior to initiating the registration o the Home Address (HoA),
process. The mechanism via which the mobile node obtains these
information is called Mobile IPv6 bootstrapping. In order to allow a o the home agent address, and
flexible deployment model for Mobile IPv6, it is desirable to define
a bootstrapping mechanism for the mobile node to acquire these o the cryptographic materials for establishing an IPsec security
parameters dynamically. [RFC4640] describes the problem statement association with the home agent.
for Mobile IPv6 bootstrapping. It also defines the bootstrapping
scenarios based on the relationship between the entity that The cryptographic materials need to be established prior to
authenticates and authorizes the mobile node for network access initiating the registration process. The mechanism via which the
(i.e., the Access Service Authorizer) and the entity that mobile node obtains this information is called "Mobile IPv6
authenticates and authorizes the mobile node for mobility service bootstrapping". In order to allow a flexible deployment model for
(i.e., the Mobility Service Authorizer). The scenario in which the Mobile IPv6, it is desirable to define a bootstrapping mechanism for
Access Service Authorizer is not the Mobility Service Authorizer is the mobile node to acquire these parameters dynamically. [RFC4640]
called the "Split" scenario. The bootstrapping solution for the describes the problem statement for Mobile IPv6 bootstrapping. It
split scenario is defined in [RFC5026]. The scenario in which the also defines the bootstrapping scenarios based on the relationship
Access Service Authorizer is also the Mobility Service Authorizer is between the entity that authenticates and authorizes the mobile node
called the "Integrated" scenario. This document defines a for network access (i.e., the Access Service Authorizer, ASA) and the
bootstrapping solution for the Integrated scenario. entity that authenticates and authorizes the mobile node for mobility
service (i.e., the Mobility Service Authorizer, MSA). The scenario
in which the Access Service Authorizer is not the Mobility Service
Authorizer is called the "split" scenario. The bootstrapping
solution for the split scenario is defined in [RFC5026]. The
scenario in which the Access Service Authorizer is also the Mobility
Service Authorizer is called the "integrated" scenario. This
document defines a bootstrapping solution for the integrated
scenario.
[RFC5026] identifies four different components of the bootstrapping [RFC5026] identifies four different components of the bootstrapping
problem: home agent address discovery, HoA assignment, IPsec Security problem: home agent address discovery, HoA assignment, IPsec Security
Association [RFC4301] setup, and Authentication and Authorization Association [RFC4301] setup, and Authentication and Authorization
with the MSA. This document defines a mechanism for home agent with the MSA. This document defines a mechanism for home agent
address discovery. The other components of bootstrapping are as per address discovery. The other components of bootstrapping are as per
[RFC5026]. [RFC5026].
In the integrated scenario, the bootstrapping of the home agent In the integrated scenario, the bootstrapping of the home agent
information can be achieved via DHCPv6. This document defines the information can be achieved via DHCPv6. This document defines the
MIPv6 bootstrapping procedures for the integrated scenario. It MIPv6 bootstrapping procedures for the integrated scenario. It
enables Home Agent assignment in the integrated scenario by utilizing enables home agent assignment in the integrated scenario by utilizing
DHCP and AAA protocols. The specification utilizes DHCP and AAA DHCP and Authentication, Authorization, and Accounting (AAA)
options and AVPs that are defined in [HIOPT], [MIP6-Dime], and protocols. The specification utilizes DHCP and AAA options and
[MIP6-RADIUS]. This document specifies the interworking among MN, attribute-value pairs (AVPs) that are defined in [RFC6610] and
NAS, DHCP, and AAA entities for the bootstrapping procedure in the [RFC5447]. This document specifies the interworking among Mobile
integrated scenario. Node (MN), Network Access Server (NAS), DHCP, and AAA entities for
the bootstrapping procedure in the integrated scenario.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in [RFC2119].
General mobility terminology can be found in [RFC3753]. The General mobility terminology can be found in [RFC3753]. The
following additional terms, as defined in [RFC4640], are used in this following additional terms, as defined in [RFC4640], are used in this
document: document:
Access Service Authorizer (ASA): A network operator that Access Service Authorizer (ASA): A network operator that
authenticates a mobile node and establishes the mobile node's authenticates a mobile node and establishes the mobile node's
authorization to receive Internet service. authorization to receive Internet service.
Access Service Provider (ASP): A network operator that provides Access Service Provider (ASP): A network operator that provides
direct IP packet forwarding to and from the mobile node. direct IP packet forwarding to and from the mobile node.
Mobility Service Authorizer (MSA): A service provider that authorizes Mobility Service Authorizer (MSA): A service provider that authorizes
Mobile IPv6 service. Mobile IPv6 service.
Mobility Service Provider (MSP): A service provider that provides Mobility Service Provider (MSP): A service provider that provides
Mobile IPv6 service. A MSP is called home MSP when MSP == MSA. In Mobile IPv6 service. An MSP is called a "home MSP" when MSP == MSA.
this document the term MSP means a Mobility Service Provider that has In this document, the term MSP means a Mobility Service Provider that
roaming relationship with the MSA but it is not the MSA. has a roaming relationship with the MSA but it is not the MSA.
Split scenario: A scenario where the mobility service and the network Split Scenario: A scenario where the mobility service and the network
access service are authorized by different entities. access service are authorized by different entities.
Integrated Scenario: A scenario where the mobility service and the Integrated Scenario: A scenario where the mobility service and the
network access service are authorized by the same entity. network access service are authorized by the same entity.
3. Assumptions & Conformance 3. Assumptions and Conformance
The following assumptions are made in this document: The following assumptions are made in this document:
a. MSA == ASA. (a) MSA == ASA.
b. MSA and MSP roaming relationship is assumed but not required. (b) MSA and MSP have a roaming relationship.
c. DHCP relay and NAS are co-located or there is a mechanism to (c) DHCP relay and NAS are either co-located or there is a mechanism
transfer received AAA information from the NAS to the DHCP relay. to transfer received AAA information from the NAS to the DHCP
relay.
Note: If assignment of a home agent in the home MSP is not required Note: If assignment of a home agent in the home MSP is not
by a deployment, co-location of the NAS and the DHCP relay functions required by a deployment, co-location of the NAS and the DHCP
or a mechanism to transfer received AAA information from the NAS to relay functions or a mechanism to transfer received AAA
the DHCP relay won't be necessary. In such a case, only the information from the NAS to the DHCP relay won't be
implementation of the options and procedures defined in [HIOPT] necessary. In such a case, only the implementation of the
should suffice. options and procedures defined in [RFC6610] should suffice.
d. The NAS shall support MIPv6 specific AAA attributes as specified (d) The NAS shall support MIPv6-specific AAA attributes as specified
in [MIP6-RADIUS] and [MIP6-Dime]. in [RFC5447].
e. The AAAH used for network access authentication (ASA) has access (e) The AAA server in the home domain (AAAH) used for network access
to the same database as the AAAH used for the mobility service authentication (ASA) has access to the same database as the AAAH
authentication (MSA). used for the mobility service authentication (MSA).
If home agent assignment only in the ASP is required by the If home agent assignment is required only in the ASP by the
deployment, a minimal implementation of this specification MAY only deployment, a minimal implementation of this specification MAY only
support the delivery of information from the DHCP server to the DHCP support the delivery of information from the DHCP server to the DHCP
client through [HIOPT]. However, if home agent assignment in the MSP client through [RFC6610]. However, if home agent assignment in the
is required by the deployment, an implementation conforming to this MSP is required by the deployment, an implementation conforming to
specification SHALL be able to transfer received information (from this specification SHALL be able to transfer the information received
the AAA server) from the NAS to the DHCP relay function. This can be from the AAA server to the NAS, and from the NAS to the DHCP relay
achieved either by co-locating the NAS and the DHCP relay functions function. This can be achieved either by co-locating the NAS and the
or via an interface between these functions. The detail of this DHCP relay functions or via an interface between these functions.
interface is out of scope of this specification. The details of this interface are out of the scope of this
specification.
4. Solution Overview 4. Solution Overview
4.1. Logical View of the Integrated Scenario 4.1. Logical View of the Integrated Scenario
In the integrated scenario, the mobile node utilizes the network In the integrated scenario, the mobile node utilizes the network
access authentication process to bootstrap Mobile IPv6. It is access authentication process to bootstrap Mobile IPv6. It is
assumed that the access service authorizer is mobility service aware. assumed that the access service authorizer is mobility service aware.
This allows for Mobile IPv6 bootstrapping at the time of access This allows for Mobile IPv6 bootstrapping at the time of access
authentication and authorization. Also, the mechanism defined in authentication and authorization. Also, the mechanism defined in
this document requires the NAS to support Mobile IPv6 specific AAA this document requires the NAS to support MIP6-specific AAA
attributes and a co-located DHCP relay agent. attributes and a co-located DHCP relay agent.
The following diagram shows the network elements and layout in the Figure 1 shows the AAA infrastructure with a AAA client (NAS), a AAA
integrated scenario: proxy in the visited network (AAAV), and a AAA server in the home
network (AAAH).
| |
ASP(/MSP) | ASA/MSA(/MSP) ASP(/MSP) | ASA/MSA(/MSP)
| |
| |
+-------+ | +-------+ +-------+ | +-------+
| | | | | | | | | |
|AAAV |-----------|--------|AAAH | |AAAV |-----------|--------|AAAH |
| | | | | | | | | |
+-------+ | +-------+ +-------+ | +-------+
skipping to change at page 6, line 45 skipping to change at page 6, line 30
| MN |------|DHCP |----|Server| | | MN |------|DHCP |----|Server| |
+----+ |Relay| | | | +----+ |Relay| | | |
+-----+ +------+ | +-----+ +------+ |
| |
| |
+--------+ | +--------+ +--------+ | +--------+
| HA | | | HA | | HA | | | HA |
| in ASP | | |in MSP | | in ASP | | |in MSP |
+--------+ | +--------+ +--------+ | +--------+
Figure 1. Integrated Scenario, Network Diagram with DHCP Server Figure 1: Integrated Scenario, Network Diagram with DHCP Server
Figure 1 shows the AAA infrastructure with an AAA client (NAS), an The user's home network authorizes the mobile node for network access
AAA proxy in the visited network and an AAA server in the home and mobility services. Note that usage of a home agent with the
network. The user's home network authorizes the mobile node for mobile node might be selected in the access service provider's
network access and also for mobility services. Note that a home network or alternatively in the mobility service provider's network.
agent for usage with the mobile node might be selected in the access
service provider's network or alternatively in the mobility service
provider's network.
The mobile node interacts with the DHCP Server via the Relay Agent The MSP may be co-located with the ASP, or the ASA/MSA, or
independent of the two.
The mobile node interacts with the DHCP server via the relay agent
after the network access authentication as part of the mobile node after the network access authentication as part of the mobile node
configuration procedure. configuration procedure.
4.2. Bootstrapping Message Sequence 4.2. Bootstrapping Message Sequence
In this case, the mobile node is able to acquire the home agent In this case, the mobile node is able to acquire the home agent
address via a DHCPv6 query. The message flows for home agent address via a DHCPv6 query. In the integrated scenario, the ASA and
allocation in the ASP and the MSP are illustrated below. In the the MSA are the same; it can be safely assumed that the AAAH used for
integrated scenario, the ASA and the MSA are the same, it can be network access authentication (ASA) has access to the same database
safely assumed that the AAAH used for network access authentication as the AAAH used for the mobility service authentication (MSA).
(ASA) has access to the same database as the AAAH used for the Hence, the same AAAH can authorize the mobile node for network access
mobility service authentication (MSA). Hence, the same AAAH can and mobility service at the same time. When the MN performs Mobile
authorize the mobile node for network access and mobility service at IPv6 registration, the AAAH ensures that the MN is accessing the
the same time. When the MN performs Mobile IPv6 registration, the assigned home agent for that MSP.
AAAH ensures that the MN is accessing the assigned Home Agent for
that MSP.
Figure 2 shows the message sequence for home agent allocation in both Figure 2 shows the message sequence for home agent allocation in both
scenarios -- HA in the MSP, and HA in the ASP. scenarios -- HA in the ASP (which is co-located with the MSP), or HA
in an MSP that is separate from ASP and possibly from the ASA/MSA as
well.
| |
--------------ASP------>|<--ASA+MSA-- --------------ASP------>|<--ASA+MSA--
| |
+----+ +------+ +-------+ +-----+ +----+ +------+ +-------+ +-----+
| | | | | | | | | | | | | | | |
| MN/| |NAS/ | | DHCP | |AAAH | | MN/| |NAS/ | | DHCP | |AAAH |
|User| |DHCP | | Server| | | |User| |DHCP | | Server| | |
| | |relay | | | | | | | |relay | | | | |
+----+ +------+ +-------+ +-----+ +----+ +------+ +-------+ +-----+
skipping to change at page 8, line 32 skipping to change at page 7, line 40
| | 3 | | | | 3 | |
| |------------>| | | |------------>| |
| | | | | | | |
| | 4 | | | | 4 | |
| |<------------| | | |<------------| |
| | | | | | | |
| 5 | | | | 5 | | |
|<--------------| | | |<--------------| | |
| | | | | | | |
Figure 2. Message sequence for Home Agent allocation Figure 2: Message Sequence for Home Agent Allocation
4.2.1. Home Agent allocation in the MSP 4.2.1. Home Agent Allocation in the MSP
This section describes a scenario where the home agent is allocated This section describes a scenario where the home agent is allocated
in the mobile node's MSP network(s). In order to provide the mobile in the mobile node's MSP network(s) that is (are) not co-located with
node with information about the assigned home agent, the AAAH conveys the ASP. In order to provide the mobile node with information about
the assigned home agent's information to the NAS via an AAA protocol, the assigned home agent, the AAAH conveys the assigned home agent's
e.g., [MIP6-RADIUS] or [MIP6-Dime]. information to the NAS via a AAA protocol, e.g., [RFC5447].
Figure 2 shows the message sequence for home agent allocation. In Figure 2 shows the message sequence for home agent allocation. In
the scenario with HA in the MSP, the following details apply. the scenario with HA in the MSP, the following details apply.
(1) The mobile node executes the network access authentication (1) The mobile node executes the network access authentication
procedure (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS. procedure (e.g., IEEE 802.11i/802.1X), and it interacts with the
The NAS is in the ASP and it interacts with the AAAH, which is in the NAS. The NAS is in the ASP, and it interacts with the AAAH,
ASA/MSA, to authenticate the mobile node. In the process of which is in the ASA/MSA, to authenticate the mobile node. In
authorizing the mobile node, the AAAH verifies in the AAA profile the process of authorizing the mobile node, the AAAH verifies in
that the mobile node is allowed to use the Mobile IPv6 service. The the AAA profile that the mobile node is allowed to use the
AAAH assigns a home agent in the home MSP and it assigns one or more Mobile IPv6 service. The AAAH assigns a home agent in the home
home agent(s) in other authorized MSPs and returns this information MSP, and it assigns one or more home agents in other authorized
to the NAS. The NAS may keep the received information for a MSPs and returns this information to the NAS. The NAS may keep
configurable duration or it may keep the information for as long as the received information for a configurable duration, or it may
the MN is connected to the NAS. keep the information for as long as the MN is connected to the
NAS.
(2) The mobile node sends a DHCPv6 Information Request message (2) The mobile node sends a DHCPv6 Information-request message
[RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast
In this message, the mobile node (DHCP client) SHALL include the address. In this message, the mobile node (DHCP client) SHALL
Option Code for the Home Network Identifier Option [HIOPT] in the include the following:
OPTION_ORO, and a Home Network Identifier Option with id-type set to
1 and the Home Network Identifier field set to the network realm of
the home MSP [HIOPT]. The mobile node SHALL also include the
OPTION_CLIENTID to identify itself to the DHCP server.
(3) The Relay Agent intercepts the Information Request from the * the Option Code for the Visited Home Network Information
mobile node and forwards it to the DHCP server. The Relay Agent also option [RFC6610] in the OPTION_ORO.
includes the received home agent information from the AAAH in the
OPTION_MIP6-RELAY-Option [HIOPT]. If a NAS implementation does not
store the received information as long as the MN's session remains in
the ASP, and if the MN delays sending a DHCP request, the NAS/DHCP
relay does not include the OPTION_MIP6-RELAY-Option in the Relay
Forward message.
(4) The DHCP server identifies the client by looking at the DUID for * Client Home Network ID FQDN option identifying the MSP.
the client in the OPTION_CLIENTID. The DHCP server also determines
that the mobile node is requesting home agent information in the MSP
by looking at the Home Network Identifier Option (id-type 1). The
DHCP server determines that the home agent is allocated by the AAAH
by looking at the MIP6 home agent sub-option in the OPTION_MIP6-
RELAY-Option. The DHCP server extracts the allocated home agent
information from the OPTION_MIP6-RELAY-Option and includes it in the
Home Network Information Option [HIOPT] in the Reply Message. If the
requested information is not available in the DHCP server, it follows
the behavior described in [HIOPT].
(5) The Relay Agent relays the Reply Message from the DHCP server to * the OPTION_CLIENTID to identify itself to the DHCP server
the mobile node. At this point, the mobile node has the home agent
information that it requested.
4.2.2. Home Agent allocation in the ASP (3) The relay agent intercepts the Information Request from the
mobile node and forwards it to the DHCP server. The relay agent
also includes the received home agent information from the AAAH
in the Relay-Supplied Options option [RFC6610]. If a NAS
implementation does not store the received information as long
as the MN's session remains in the ASP, and if the MN delays
sending a DHCP request, the NAS/DHCP relay does not include the
Relay-Supplied Options option in the Relay Forward message.
This section describes a scenario where the mobile node requests for (4) The DHCP server:
home agent allocation in the ASP by setting the id-type field to zero
in the Home Network Identifier Option [HIOPT] in the DHCPv6 request * identifies the client by looking at the DHCP Unique
Identifier (DUID) for the client in the OPTION_CLIENTID.
* determines that the mobile node is requesting home agent
information in the MSP by looking at the Home Network ID FQDN
option.
* determines that the home agent is allocated by the AAAH by
looking at the Relay-Supplied Options option.
* extracts the allocated home agent information from the Relay-
Supplied Options option and includes it in the Identified
Home Network Information option [RFC6610] in the Reply
Message. If the requested information is not available in
the DHCP server, it follows the behavior described in
[RFC6610].
(5) The relay agent relays the Reply Message from the DHCP server to
the mobile node. At this point, the mobile node has the home
agent information that it requested.
4.2.2. Home Agent Allocation in the ASP
This section describes a scenario where the mobile node requests home
agent allocation in the ASP by setting the id-type field to zero in
the Home Network Identifier Option [RFC6610] in the DHCPv6 request
message. In this scenario, the ASP becomes the MSP for the duration message. In this scenario, the ASP becomes the MSP for the duration
of the network access authentication session. of the network access authentication session.
Figure 2 shows the message sequence for home agent allocation. In Figure 2 shows the message sequence for home agent allocation. In
the scenario with HA in the ASP, the following details apply. the scenario with HA in the ASP, the following details apply.
(1) The mobile node executes the network access authentication (1) The mobile node executes the network access authentication
procedure (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS. procedure (e.g., IEEE 802.11i/802.1X) and interacts with the
The NAS is in the ASP and it interacts with the AAAH, which is in the NAS. The NAS is in the ASP, and it interacts with the AAAH,
ASA/MSA, to authenticate the mobile node. In the process of which is in the ASA/MSA, to authenticate the mobile node. In
authorizing the mobile node, the AAAH verifies in the AAA profile the process of authorizing the mobile node, the AAAH verifies in
that the mobile node is allowed to use the Mobile IPv6 services. The the AAA profile that the mobile node is allowed to use the
AAAH assigns a home agent in the home MSP and it assigns one or more Mobile IPv6 services. The AAAH assigns a home agent in the home
home agent(s) in other authorized MSPs and returns this information MSP, and it assigns one or more home agents in other authorized
to the NAS. Note that the AAAH is not aware of the fact that the MSPs and returns this information to the NAS. Note that the
mobile node prefers a home agent allocation in the ASP. Therefore AAAH is not aware of the fact that the mobile node prefers a
the assigned home agent may not be used by the mobile node. This home agent allocation in the ASP. Therefore, the assigned home
leaves the location of the mobility anchor point decision to the agent may not be used by the mobile node. This leaves the
mobile node. location of the mobility anchor point decision to the mobile
node.
(2) The mobile node sends a DHCPv6 Information Request message (2) The mobile node sends a DHCPv6 Information Request message
[RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address. [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast
In this message, the mobile node (DHCP client) SHALL include the address. In this message, the mobile node (DHCP client) SHALL
Option Code for the Home Network Identifier Option [HIOPT] in the include the following:
OPTION_ORO, and a Home Network Identifier Option with id-type set to
0. The mobile node SHALL also include the OPTION_CLIENTID to
identify itself to the DHCP server.
(3) The Relay Agent intercepts the Information Request from the * the Option Code for the Home Network Identifier Option
mobile node and forwards it to the DHCP server. The Relay Agent [RFC6610] in the OPTION_ORO.
(which is the NAS) also includes the received AAA AVP from the AAAH
in the OPTION_MIP6-RELAY-Option [HIOPT].
(4) The DHCP server identifies the client by looking at the DUID for * the OPTION_CLIENTID to identify itself to the DHCP server.
the client in the OPTION_CLIENTID. The DHCP server also determines
that the mobile node is requesting home agent information in the ASP
by looking at the Home Network Identifier Option (id-type 0). If
configured to do so, the DHCP server allocates a home agent from its
configured list of home agents and includes it in the Home Network
Information Option [HIOPT] in the Reply Message. Note that in this
case, the DHCP server does not use the received information in the
OPTION_MIP6-RELAY-Option.
(5) The Relay Agent relays the Reply Message from the DHCP server to (3) The relay agent (which is the NAS) intercepts the Information
the mobile node. At this point, the mobile node has the home agent Request from the mobile node and forwards it to the DHCP server.
information that it requested. The relay agent also includes the received AAA AVP from the AAAH
in the Relay-Supplied Options option [RFC6610].
4.3. Bootstrapping Message Sequence: Fallback case (4) The DHCP server identifies the client by looking at the DUID for
the client in the OPTION_CLIENTID. The DHCP server also
determines that the mobile node is requesting home agent
information in the ASP by looking at the Visited Home Network
Information option. If configured to do so, the DHCP server
allocates a home agent from its configured list of home agents
and includes it in the Visited Home Network Information Option
[RFC6610] in the Reply Message. Note that in this case, the
DHCP server does not use the received information in the Relay-
Supplied Options option.
(5) The relay agent relays the Reply Message from the DHCP server to
the mobile node. At this point, the mobile node has the home
agent information that it requested.
4.3. Bootstrapping Message Sequence: Fallback Case
In the fallback case, the mobile node is not able to acquire the home In the fallback case, the mobile node is not able to acquire the home
agent information via DHCPv6. The mobile node MAY perform DNS agent information via DHCPv6. The mobile node MAY perform DNS
queries to discover the home agent address as defined in [RFC5026]. queries to discover the home agent address as defined in [RFC5026].
To perform DNS-based home agent discovery, the mobile node needs to
To perform DNS based home agent discovery, the mobile node needs to
know the DNS server address. The details of how the MN is configured know the DNS server address. The details of how the MN is configured
with the DNS server address is outside the scope of this document. with the DNS server address are outside the scope of this document.
4.4. HoA and IKEv2 SA Bootstrapping in the Integrated Scenario 4.4. HoA and IKEv2 SA Bootstrapping in the Integrated Scenario
In the integrated scenario, the HoA, IPsec Security Association In the integrated scenario, the HoA, IPsec Security Association
setup, and Authentication and Authorization with the MSA are setup, and Authentication and Authorization with the MSA are
bootstrapped via the same mechanism as described in the bootstrapping bootstrapped via the same mechanism as described in the bootstrapping
solution for the split scenario [RFC5026]. solution for the split scenario [RFC5026].
5. Security Considerations 5. Security Considerations
The transport of the assigned home agent information via the AAA The transport of the assigned home agent information via the AAA
infrastructure (i.e., from the AAA server to the AAA client) to the infrastructure (i.e., from the AAA server to the AAA client) to the
NAS may only be integrity protected as per standard RADIUS and NAS may only be integrity protected as per standard Diameter or other
Diameter security mechanisms. No additional security considerations AAA protocol security mechanisms. No additional security
are imposed by the usage of this document. The security mechanisms considerations are imposed by the usage of this document. The
provided by [RFC2865] and [RFC3588] are applicable for this purpose. security mechanisms provided by [RFC3588] are applicable for this
This document does not introduce any new security issues to Mobile purpose. This document does not introduce any new security issues to
IPv6. Mobile IPv6.
6. IANA Considerations
None
7. Acknowledgements 6. Acknowledgements
The authors would like to thank Kilian Weniger, Vidya Narayanan, and The authors would like to thank Kilian Weniger, Vidya Narayanan, and
George Tsirtsis for their review and comments. Thanks to Alfred George Tsirtsis for their review and comments. Thanks to Alfred
Hoenes for thorough review and valuable suggestions to improve the Hoenes for thorough review and valuable suggestions to improve the
readability of the document. readability of the document.
8. Contributors 7. Contributors
This contribution is a joint effort of the bootstrapping solution This contribution is a joint effort of the bootstrapping solution
design team of the MEXT WG. The contributors include Gerardo design team of the MEXT WG. The contributors include Jari Arkko,
Giaretta, Basavaraj Patil, Alpesh Patel, Jari Arkko, James Kempf, Julien Bournelle, Kuntal Chowdhury, Vijay Devarapalli, Gopal Dommety,
Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal Gerardo Giaretta, Junghoon Jee, James Kempf, Alpesh Patel, Basavaraj
Chowdhury, Julien Bournelle, and Hannes Tschofenig. Patil, Hannes Tschofenig, and Alper Yegin.
The design team members can be reached at:
Gerardo Giaretta gerardog@qualcomm.com
Basavaraj Patil basavaraj.patil@nsn.com
Alpesh Patel alpesh@cisco.com
Jari Arkko jari.arkko@kolumbus.fi
James Kempf kempf@docomolabs-usa.com
Gopal Dommety gdommety@cisco.com
Alper Yegin a.yegin@partner.samsung.com
Junghoon Jee jhjee@etri.re.kr
Vijay Devarapalli Vijay.Devarapalli@AzaireNet.com
Kuntal Chowdhury kchowdhury@starentnetworks.com
Julien Bournelle julien.bournelle@orange-ftgroup.com
Hannes Tschofenig hannes.tschofenig@nsn.com
9. References
9.1. Normative References The design team members can be reached at the following email
addresses:
[HIOPT] Hee Jang et. al., A., "DHCP Option for Home Agent Jari Arkko jari.arkko@kolumbus.fi
Discovery in MIPv6.", draft-ietf-mip6-hiopt-15.txt (work Julien Bournelle julien.bournelle@orange-ftgroup.com
in progress), April 2008. Kuntal Chowdhury kc@radiomobiles.com
Vijay Devarapalli Vijay.Devarapalli@AzaireNet.com
Gopal Dommety dommety@yahoo.com
Gerardo Giaretta gerardog@qualcomm.com
Junghoon Jee jhjee@etri.re.kr
James Kempf kempf@docomolabs-usa.com
Alpesh Patel alpesh@cisco.com
Basavaraj Patil basavaraj.patil@nsn.com
Hannes Tschofenig hannes.tschofenig@nsn.com
Alper Yegin alper.yegin@yegin.org
[MIP6-Dime] 8. References
Korhonen et. al., J., "Diameter Mobile IPv6: NAS - HAAA
Support.", draft-ietf-dime-mip6-integrated-04.txt (work in
progress), May 2007.
[MIP6-RADIUS] 8.1. Normative References
Lior et. al., A., "RADIUS Mobile IPv6 Support.",
draft-ietf-mip6-radius-03.txt (work in progress),
November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
Bootstrapping in Split Scenario", RFC 5026, October 2007. Bootstrapping in Split Scenario", RFC 5026, October 2007.
9.2. Informative References [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
and K. Chowdhury, "Diameter Mobile IPv6: Support for
Network Access Server to Diameter Server Interaction",
RFC 5447, February 2009.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T.
Lemon, "DHCP Option for Home Agent Discovery in Mobile
IPv6 (MIPv6)", RFC 6610, May 2012.
8.2. Informative References
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for
bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
September 2006. September 2006.
Authors' Addresses Authors' Addresses
Kuntal Chowdhury Kuntal Chowdhury (editor)
Starent Networks Radio Mobile Access, Inc.
30 International Place 100 Ames Pond Dr.
Tewksbury, MA 01876 Tewksbury MA 01876
US
Email: kchowdhury@starentnetworks.com EMail: kc@radiomobiles.com
Alper Yegin Alper Yegin
Samsung AIT Samsung
Istanbul, Istanbul
Turkey Turkey
Email: a.yegin@partner.samsung.com EMail: alper.yegin@yegin.org
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.
 End of changes. 59 change blocks. 
295 lines changed or deleted 309 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/