draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt   draft-ietf-mip6-bootstrapping-integrated-dhc-02.txt 
Network Working Group K. Chowdhury, Editor Network Working Group K. Chowdhury, Editor
Internet-Draft Starent Networks Internet-Draft Starent Networks
Expires: December 11, 2006 A. Yegin Intended status: Standards Track A. Yegin
Samsung AIT Expires: August 11, 2007 Samsung AIT
June 9, 2006 February 7, 2007
MIP6-bootstrapping via DHCPv6 for the Integrated Scenario MIP6-bootstrapping for the Integrated Scenario
draft-ietf-mip6-bootstrapping-integrated-dhc-01.txt draft-ietf-mip6-bootstrapping-integrated-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 11, 2006. This Internet-Draft will expire on August 11, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Mobile IPv6 bootstrapping problem statement describes two main The Mobile IPv6 bootstrapping problem statement describes two main
scenarios. In the first scenario (i.e. the split scenario), the scenarios. In the first scenario (i.e. the split scenario), the
mobile node's mobility service is authorized by a different service mobile node's mobility service is authorized by a different service
authorizer than the basic network access authorizer. In the second authorizer than the basic network access authorizer. In the second
scenario (i.e. the integrated scenario), the mobile node's mobility scenario (i.e. the integrated scenario), the mobile node's mobility
service is authorized by the same service authorizer as the basic service is authorized by the same service authorizer as the basic
network access service authorizer. This document defines a method network access service authorizer. This document defines a method
for home agent information discovery based on DHCPv6 for the for home agent information discovery for the integrated scenario.
integrated scenario.
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Logical Diagram of the Integrated Scenario . . . . . . . . 5 3.1. Logical Diagram of the Integrated Scenario . . . . . . . . 5
3.2 Bootstrapping Message Sequence, Success Case . . . . . . . 6 3.2. Bootstrapping Message Sequence, Success Case . . . . . . . 6
3.2.1 Home Agent allocation in the MSP . . . . . . . . . . . 6 3.2.1. Home Agent allocation in the MSP . . . . . . . . . . . 6
3.2.2 Home Agent allocation in the ASP . . . . . . . . . . . 8 3.2.2. Home Agent allocation in the ASP . . . . . . . . . . . 8
3.3 Bootstrapping Message Sequence: Fallback case . . . . . . 10 3.3. Bootstrapping Message Sequence: Fallback case . . . . . . 10
3.4 HoA and IKEv2 SA Bootstrapping in the Integrated 3.4. HoA and IKEv2 SA Bootstrapping in the Integrated
Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 DHCPv6 options . . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
3.5.1 DHC Relay Agent Option to carry Mobile IPv6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
parameters . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.2 MIP6 home agent sub-option . . . . . . . . . . . . . . 11 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 Mobile Node Behavior . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7 NAS, DHCP Relay Agent Behavior . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
3.8 DHCP Server Behavior . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1 Normative References . . . . . . . . . . . . . . . . . . . 21
8.2 Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23
1. Introduction and Scope 1. Introduction and Scope
The Mobile IPv6 protocol [RFC3775] requires the mobile node to have The Mobile IPv6 protocol [RFC3775] requires the mobile node to have
knowledge of its Home Address, the home agent address and the knowledge of its Home Address, the home agent address and the
cryptographic materials for establishing an IPsec security cryptographic materials for establishing an IPsec security
association with the home agent prior to performing home association with the home agent prior to performing home
registration. The mechanism via which the mobile node obtains these registration. The mechanism via which the mobile node obtains these
information is called Mobile IPv6 bootstrapping. In order to allow a information is called Mobile IPv6 bootstrapping. In order to allow a
flexible deployment model for Mobile IPv6, it is desirable to define flexible deployment model for Mobile IPv6, it is desirable to define
a bootstrapping mechanism for the mobile node to acquire these a bootstrapping mechanism for the mobile node to acquire these
parameters dynamically. The [BOOT-PS] describes the problem parameters dynamically. The [RFC4640] describes the problem
statement for Mobile IPv6 bootstrapping. It also defines two statement for Mobile IPv6 bootstrapping. It also defines two
bootstrapping scenarios based on the relationship between the entity bootstrapping scenarios based on the relationship between the entity
that authenticates and authorizes the mobile node for network access that authenticates and authorizes the mobile node for network access
(i.e., the Access Service Authorizer) and the entity that (i.e., the Access Service Authorizer) and the entity that
authenticates and authorizes the mobile node for mobility service authenticates and authorizes the mobile node for mobility service
(i.e., the Mobility Service Authorizer). The scenario in which the (i.e., the Mobility Service Authorizer). The scenario in which the
Access Service Authorizer is not the Mobility Service Authorizer is Access Service Authorizer is not the Mobility Service Authorizer is
called the "Split" scenario. The bootstrapping solution for split called the "Split" scenario. The bootstrapping solution for split
scenario is defined in [BOOT-SPLIT]. The scenario in which the scenario is defined in [BOOT-SPLIT]. The scenario in which the
Access Service Authorizer is also the Mobility Service Authorizer is Access Service Authorizer is also the Mobility Service Authorizer is
called the "Integrated" scenario. This document defines a called the "Integrated" scenario. This document defines a
bootstrapping solution using DHCPv6 for the Integrated scenario. bootstrapping solution for the Integrated scenario.
[BOOT-SPLIT] identifies four different components of the [BOOT-SPLIT] identifies four different components of the
bootstrapping problem: home agent address discovery, HoA assignment, bootstrapping problem: home agent address discovery, HoA assignment,
IPsec Security Association setup and Authentication and Authorization IPsec Security Association 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. For the rest of components, please refer to address discovery. For the rest of components, please refer to
[BOOT-SPLIT]. [BOOT-SPLIT].
In the integrated scenario, the bootstrapping of the home agent In the integrated scenario, the bootstrapping of the home agent
information can be performed via DHCPv6. DHCPv6 is designed for information can be performed via DHCPv6. DHCPv6 is designed for
configuration management and it is being deployed by operators to configuration management and it is being deployed by operators to
handle their configuration management needs in their networks. handle their configuration management needs in their networks.
2. Terminology 2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in [RFC2119]. 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 [BOOT-PS], 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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
service. service.
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. Solution Overview 3. Solution Overview
3.1 Logical Diagram of the Integrated Scenario 3.1. Logical Diagram of the Integrated Scenario
In the integrated scenario the mobile node may use the security In the integrated scenario the mobile node utilizes network access
credentials for network access to bootstrap Mobile IPv6. As such, it authentication process to bootstrap Mobile IPv6. It is assumed that
is assumed that the access service authorizer is mobility service the access service authorizer is mobility service aware. This allows
aware. This allows for Mobile IPv6 bootstrapping at the time of for Mobile IPv6 bootstrapping at the time of access authentication
access authentication and authorization. Also, the mechanism defined and authorization. Also, the mechanism defined in this document
in this document requires the NAS to support Mobile IPv6 specific AAA requires the NAS to support Mobile IPv6 specific AAA attributes and a
attributes and a collocated DHCP relay agent. collocated DHCP relay agent.
The following diagram shows the network elements and layout in the The following diagram shows the network elements and layout in the
integrated scenario: integrated scenario:
| |
ASP(/MSP) | ASA/MSA(/MSP) ASP(/MSP) | ASA/MSA(/MSP)
| |
| |
+-------+ | +-------+ +-------+ | +-------+
| | | | | | | | | |
skipping to change at page 6, line 4 skipping to change at page 6, line 4
+----+ | | |DHCP | | +----+ | | |DHCP | |
| MN |------| NAS/|----|Server| | | MN |------| NAS/|----|Server| |
+----+ |Relay| | | | +----+ |Relay| | | |
+-----+ +------+ | +-----+ +------+ |
| |
| |
+--------+ | +--------+ +--------+ | +--------+
| HA | | | HA | | HA | | | HA |
| in ASP | | |in MSP | | in ASP | | |in MSP |
+--------+ | +--------+ +--------+ | +--------+
Integrated Scenario, Network Diagram with DHCP
Figure 1. Integrated Scenario, Network Diagram with DHCP Figure 1. Integrated Scenario, Network Diagram with DHCP
Figure 1 shows the AAA infrastructure with a AAA client (NAS), a AAA Figure 1 shows the AAA infrastructure with a AAA client (NAS), a AAA
proxy in the visited network and a AAA server in the home network. proxy in the visited network and a AAA server in the home network.
The user's home network authorizes the mobile node for network access The user's home network authorizes the mobile node for network access
and also for mobility services. Note that a home agent for usage and also for mobility services. Note that a home agent for usage
with the mobile node might be selected in the access service with the mobile node might be selected in the access service
provider's network or alternatively in the mobility service provider's network or alternatively in the mobility service
provider's network. provider's network.
The mobile node interacts with the DHCP Server via the Relay Agent The mobile node interacts with the DHCP Server via the Relay Agent
(ideally collocated with the NAS) after the network access after the network access authentication as part of the mobile node
authentication as part of the mobile node configuration procedure. configuration procedure.
3.2 Bootstrapping Message Sequence, Success Case 3.2. Bootstrapping Message Sequence, Success Case
In the success case, the mobile node is able to acquire the home In the success case, the mobile node is able to acquire the home
agent address via a DHCPv6 query. The message flows for home agent agent address via a DHCPv6 query. The message flows for home agent
allocation in the ASP and the MSP are illustrated below. Since, in allocation in the ASP and the MSP are illustrated below. Since, in
the integrated scenario, the ASA and the MSA are the same, it can be the integrated scenario, the ASA and the MSA are the same, it can be
safely assumed that the AAAH used for network access authentication safely assumed that the AAAH used for network access authentication
(ASA) has access to the same database as the AAAH used for the (ASA) has access to the same database as the AAAH used for the
mobility service authentication (MSA). Hence, the same AAAH can mobility service authentication (MSA). Hence, the same AAAH can
authorize the mobile node for network access and mobility service at authorize the mobile node for network access and mobility service at
the same time. the same time.
3.2.1 Home Agent allocation in the MSP 3.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 home MSP network. in order to provide the mobile in the mobile node's home MSP network. in order to provide the mobile
node with information about the assigned home agent the AAAH conveys node with information about the assigned home agent the AAAH conveys
the assigned home agent's information to the NAS via AAA protocol. the assigned home agent's information to the NAS via AAA protocol
[MIP6-RADIUS] or [MIP6-Dime].
| |
--------------ASP------>|<--ASA+MSA-- --------------ASP------>|<--ASA+MSA--
| |
+----+ +------+ +-------+ +-----+ +----+ +------+ +-------+ +-----+
| | | | | | | | | | | | | | | |
| MN/| |NAS/ | | DHCP | |AAAH | | MN/| |NAS/ | | DHCP | |AAAH |
|User| |DHCP | | Server| | | |User| |DHCP | | Server| | |
| | |relay | | Server| | | | | |relay | | Server| | |
+----+ +------+ +-------+ +-----+ +----+ +------+ +-------+ +-----+
skipping to change at page 7, line 32 skipping to change at page 7, line 32
| | 3 | | | | 3 | |
| |------------>| | | |------------>| |
| | | | | | | |
| | 4 | | | | 4 | |
| |<------------| | | |<------------| |
| | | | | | | |
| 5 | | | | 5 | | |
|<--------------| | | |<--------------| | |
| | | | | | | |
Home Agent in the MSP
Figure 2. The home agent allocation in the home MSP Figure 2. The home agent allocation in the home MSP
Figure 2 shows the message sequence for home agent allocation in the Figure 2 shows the message sequence for home agent allocation in the
home MSP. home MSP.
(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 thereby interacts with the procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the
NAS. The NAS is in the ASP and it interacts with the AAAH, which is NAS. The NAS is in the ASP and it interacts with the AAAH, which is
in the ASA/MSA, to authenticate the mobile node. In the process of in the ASA/MSA, to authenticate the mobile node. In the process of
authorizing the mobile node the AAAH verifies in the AAA profile that authorizing the mobile node the AAAH verifies in the AAA profile that
the mobile node is allowed to use Mobile IPv6 service. The AAAH the mobile node is allowed to use Mobile IPv6 service. The AAAH
assigns a home agent in the home MSP and returns this information to assigns a home agent in the home MSP and returns this information to
the NAS. 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 address.
In this message the mobile node (DHCP client) SHALL include the In this message the mobile node (DHCP client) SHALL include the
Option Code for Home Network Identifier Option [HAOPT] in the Option Code for Home Network Identifier Option [HIOPT] in the
OPTION_ORO, Home Network Identifier Option with id-type set to 1 and OPTION_ORO, Home Network Identifier Option with id-type set to 1 and
the Home Network Identifier field set to the network realm of the the Home Network Identifier field set to the network realm of the
home MSP [HAOPT]. The mobile node SHALL also include the home MSP [HIOPT]. The mobile node SHALL also include the
OPTION_CLIENTID to identify itself to the DHCP server. OPTION_CLIENTID to identify itself to the DHCP server.
(3) The Relay Agent intercepts the Information Request from the (3) The Relay Agent intercepts the Information Request from the
mobile node and forwards it to the DHCP server. The Relay Agent also mobile node and forwards it to the DHCP server. The Relay Agent also
includes the received home agent information from the AAAH in the includes the received home agent information from the AAAH in the
OPTION_MIP6-RELAY-Option (see section 3.5). OPTION_MIP6-RELAY-Option [HIOPT].
(4) The DHCP server identifies the client by looking at the DUID for (4) The DHCP server identifies the client by looking at the DUID for
the client in the OPTION_CLIENTID. The DHCP server also determines the client in the OPTION_CLIENTID. The DHCP server also determines
that the mobile node is requesting home agent information in the MSP that the mobile node is requesting home agent information in the MSP
by looking at the Home Network Identifier Option (id-type 1). The by looking at the Home Network Identifier Option (id-type 1). The
DHCP server determines that the home agent is allocated by the AAAH 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- by looking at the MIP6 home agent sub-option in the OPTION_MIP6-
RELAY-Option. The DHCP server extracts the allocated home agent RELAY-Option. The DHCP server extracts the allocated home agent
information from the OPTION_MIP6-RELAY-Option and includes it in the information from the OPTION_MIP6-RELAY-Option and includes it in the
Home Network Information Option [HAOPT] in the Reply Message. Home Network Information Option [HIOPT] in the Reply Message.
(5) The Relay Agent relays the Reply Message from the DHCP server to (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 the mobile node. At this point, the mobile node has the home agent
information that it requested. information that it requested.
3.2.2 Home Agent allocation in the ASP 3.2.2. Home Agent allocation in the ASP
This section describes a scenario where the mobile node requests for This section describes a scenario where the mobile node requests for
home agent allocation in the ASP by setting the id-type field to zero home agent allocation in the ASP by setting the id-type field to zero
in the Home Network Identifier Option in the DHCPv6 request message. in the Home Network Identifier Option in the DHCPv6 request message.
In this scenario, the ASP becomes the MSP for the duration of the In this scenario, the ASP becomes the MSP for the duration of the
network access authentication session. network access authentication session.
| |
--------------ASP-------->|<--ASA+MSA-- --------------ASP-------->|<--ASA+MSA--
| |
skipping to change at page 9, line 32 skipping to change at page 9, line 32
| | 3 | | | | 3 | |
| |------------->| | | |------------->| |
| | | | | | | |
| | 4 | | | | 4 | |
| |<-------------| | | |<-------------| |
| | | | | | | |
| 5 | | | | 5 | | |
|<--------------| | | |<--------------| | |
| | | | | | | |
Home Agent in the ASP
Figure 3. The home agent allocation in the ASP Figure 3. The home agent allocation in the ASP
Figure 3 shows the message sequence for home agent allocation in the Figure 3 shows the message sequence for home agent allocation in the
ASP. ASP.
(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 thereby interacts with the procedure (e.g., IEEE 802.11i/802.1X) and thereby interacts with the
NAS. The NAS is in the ASP and it interacts with the AAAH, which is NAS. The NAS is in the ASP and it interacts with the AAAH, which is
in the ASA/MSA, to authenticate the mobile node. In the process of in the ASA/MSA, to authenticate the mobile node. In the process of
authorizing the mobile node the AAAH verifies in the AAA profile that authorizing the mobile node the AAAH verifies in the AAA profile that
skipping to change at page 10, line 4 skipping to change at page 10, line 7
the mobile node is allowed to use Mobile IPv6 services. The AAAH the mobile node is allowed to use Mobile IPv6 services. The AAAH
assigns a home agent in the home MSP and returns this information to assigns a home agent in the home MSP and returns this information to
the NAS. Note that the AAAH is not aware of the fact that the mobile the NAS. Note that the AAAH is not aware of the fact that the mobile
node will rather request for a home agent allocation in the ASP. node will rather request for a home agent allocation in the ASP.
Therefore the assigned home agent may not be used by the mobile node. Therefore the assigned home agent may not be used by the mobile node.
This leaves the location of the mobility anchor point decision to the This leaves the location of the mobility anchor point decision to the
mobile node. 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 address.
In this message the mobile node (DHCP client) SHALL include the In this message the mobile node (DHCP client) SHALL include the
Option Code for Home Network Identifier Option [HAOPT] in the Option Code for Home Network Identifier Option [HIOPT] in the
OPTION_ORO, Home Network Identifier Option with id-type set to 0. OPTION_ORO, Home Network Identifier Option with id-type set to 0.
The mobile node SHALL also include the OPTION_CLIENTID to identify The mobile node SHALL also include the OPTION_CLIENTID to identify
itself to the DHCP server. itself to the DHCP server.
(3) The Relay Agent intercepts the Information Request from the (3) The Relay Agent intercepts the Information Request from the
mobile node and forwards it to the DHCP server. The Relay Agent mobile node and forwards it to the DHCP server. The Relay Agent
(which is the NAS) also includes the received AAA AVP from the AAAH (which is the NAS) also includes the received AAA AVP from the AAAH
in the OPTION_MIP6-RELAY-Option. in the OPTION_MIP6-RELAY-Option [HIOPT].
(4) The DHCP server identifies the client by looking at the DUID for (4) The DHCP server identifies the client by looking at the DUID for
the client in the OPTION_CLIENTID. The DHCP server also determines the client in the OPTION_CLIENTID. The DHCP server also determines
that the mobile node is requesting home agent information in the ASP that the mobile node is requesting home agent information in the ASP
by looking at the Home Network Identifier Option (id-type 0). If by looking at the Home Network Identifier Option (id-type 0). If
configured to do so, the DHCP server allocates an home agent from its configured to do so, the DHCP server allocates an home agent from its
configured list of home agents and includes it in the Home Network configured list of home agents and includes it in the Home Network
Information Option [HAOPT] in the Reply Message. Note that in this Information Option [HIOPT] in the Reply Message. Note that in this
case, the DHCP server does not use the received information in the case, the DHCP server does not use the received information in the
OPTION_MIP6-RELAY-Option. OPTION_MIP6-RELAY-Option.
(5) The Relay Agent relays the Reply Message from the DHCP server to (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 the mobile node. At this point, the mobile node has the home agent
information that it requested. information that it requested.
3.3 Bootstrapping Message Sequence: Fallback case 3.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 performs DNS queries agent information via DHCPv6. The mobile node MAY perform DNS
to discover the home agent address as defined in [BOOT-SPLIT]. To queries to discover the home agent address as defined in
perform DNS based home agent discovery, the mobile node needs to know [BOOT-SPLIT]. To perform DNS based home agent discovery, the mobile
the DNS server address. How the mobile node knows the DNS server node needs to know the DNS server address. How the mobile node knows
address is outside the scope of this document. the DNS server address is outside the scope of this document.
3.4 HoA and IKEv2 SA Bootstrapping in the Integrated Scenario 3.4. HoA and IKEv2 SA Bootstrapping in the Integrated Scenario
In the integrated scenario, the HoA, IPsec Security Associations In the integrated scenario, the HoA, IPsec Security Associations
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 split scenario [BOOT-SPLIT]. solution for split scenario [BOOT-SPLIT].
3.5 DHCPv6 options
The following DHCP options are used in this solution to carry the
home agent information from the DHCP relay agent to the DHCP serever:
3.5.1 DHC Relay Agent Option to carry Mobile IPv6 parameters
This option carries the RADIUS or Diameter attributes that are
received at the NAS from the AAAH. The DHCP relay agent sends this
option to the DHCP server in the Relay-Forward message.
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_MIP6-RELAY-Option | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. sub-options .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_MIP6-RELAY-Option (TBD-1 by IANA).
option-len Length of OPTION_MIP6-RELAY-Option.
sub-options A series of sub-options carrying MIP6
bootstrap information. The values are:
1 - MIP6 home agent.
other values are reserved.
3.5.2 MIP6 home agent sub-option
This sub-option carries the assigned home agent information to the
DHCP server.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-option=1 | sub-option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. assigned-MIP6-HA .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
sub-option-code MIP6 home agent (1).
option-len Length of assigned home agent field.
assigned-MIP6-HA IPv6 address or FQDN of the
assigned home agent.
The following DHCP options are used in this solution to carry the
home agent information and home agent bootstrap request information
between the mobile node and the DHCP server:
Home Network Information Option [HAOPT].
Home Network Identifier Option [HAOPT].
The following DHCP options are requried in this solution for normal
DHCP operation:
Option Request Option [RFC3315].
Client Identifier Option [RFC3315].
Relay Message Option [RFC3315].
Interface-Id Option [RFC3315].
3.6 Mobile Node Behavior
If configured to do so, the mobile node MUST first try to perform
home agent discovery using DHCPv6. In order to acquire the home
agent information, the mobile node SHALL send an Information Request
to the All_DHCP_Relay_Agents_and_Servers multicast address. In this
message the mobile node (DHCP client) SHALL include the Option Code
for Home Network Identifier Option [HAOPT] in the OPTION_ORO, Home
Network Identifier Option with id-type set to either 1 or 0. The
mobile node SHALL also include the OPTION_CLIENTID [RFC3315] to
identify itself to the DHCP server.
Upon receiving the Reply message from the DHCP server, the mobile
node SHALL check for the requested configuration options. Here are
the possible scenarios:
Home Network info
Option mobile node Action
________________________________________________________
hninfo-type 0,1,2 Use home agent address
hninfo-type 0,1 Use home agent address
hninfo-type 0 Use home agent address
hninfo-type 1,2 Use home agent address
hninfo-type 1 Use home agent address
hninfo-type 0,2 Use home agent address
hninfo-type 2 Use HA-FQDN, ref
[BOOT-SPLIT]
for DNS based
home agent discovery.
No Ref [BOOT-SPLIT]
for DNS based home
agent discovery.
The mobile node MAY request for local home agent assignment by
including the Home Network Identifier Option [HAOPT] in the
Information Request message and by setting the id-type to 0.
If the mobile node wants to discover an home agent in a particular
MSP, the mobile node SHALL request for home agent assignment in that
MSP by including the Home Network Identifier Option [HAOPT] in the
Information Request message. In this option the mobile node SHALL
set the id-type to 1 and the Home Network Identifier field to the
network realm of the MSP.
3.7 NAS, DHCP Relay Agent Behavior
The NAS and the DHCP relay agent are assumed to be collocated in this
solution. The NAS communicates with the mobile node during the
network access authentication and interacts with the AAAH (via the
AAAV) using either Diameter NASREQ [RFC4005] or RADIUS [MIP6-RADIUS]
[Editor's note: The Diameter AVPs need to be defined].
Upon receiving the MIP6 related RADIUS or Diameter attributes
returned by the AAAH, the NAS passes the information to the
collocated DHCP Relay Agent.
Upon receiving the Information Request from the mobile node, the DHCP
relay agent MUST forward the message to the DHCP server as per
[RFC3315]. The relay agent SHALL use the OPTION_CLIENTID to identify
the mobile node (user). This is required to check whether there are
some additional information for the user that need to be appended
while relaying the information request message to the DHCP server.
If the relay agent determines that the NAS has passed home agent
information for this mobile node, the relay agent MUST include the
received home agent information in the OPTION_MIP6-RELAY-Option and
include this option in the Relay-Forward message. The relay agent
MAY include the Interface-Id Option [RFC3315] in the Relay-Forward
message.
Upon receiving the Reply message from the DHCPv6 server, the relay
agent SHALL follow the guidelines defined in [RFC3315] to forward the
message to the mobile node.
3.8 DHCP Server Behavior
The DHCP server MUST follow the following logic to process
Information Request from the mobile node:
Information Request message includes:
a. OPTION_MIP6-RELAY-Option, OPTION_ORO and Home Network Identifier
Option with id-type 1 (home agent assignment request in the home
MSP), Interface-Id Option, Client Identifier Option.
The DHCP server MUST extract the assigned home agent information from
the OPTION_MIP6-RELAY-Option and include it in the Home Network
Information Option of the Reply message.
b. OPTION_MIP6-RELAY-Option, OPTION_ORO and Home Network Identifier
Option with id-type 0 (home agent assignment request in the ASP),
Interface-Id Option, Client Identifier Option.
If the DHCP server is configured with information about a local home
agent, select a home agent address or FQDN for the home agent from
locally provisioned configuration and include it in the Home Network
Information Option of the Reply message.
If the DHCP server is not configured with information about a local
home agent, but it received the assigned home agent info in the
OPTION_MIP6-RELAY-Option, then it MUST extract the assigned home
agent info from this option and MUST include it in the Home Network
Information Option of the Reply message.
If the DHCP server is not configured with information about a local
home agent, and no OPTION_MIP6-RELAY-Option is received, then it MAY
return any other option in the Reply message that is requested. In
this case no home agent is assigned to the mobile node.
In all cases, in the Reply message the DHCP server MUST return the
Interface-Id Option as received in the Information Request. The DHCP
server SHOULD use the Client Identifier Option to identify the mobile
node.
4. Security Considerations 4. 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 is subject to the standard RADIUS and Diameter security NAS is subject to the standard RADIUS and Diameter security
considerations. No new security considerations are imposed by the considerations. No new security considerations are imposed by the
usage of this document. The security mechanisms provided by usage of this document. The security mechanisms provided by
[RFC2865] and [RFC3588] are applicable and provide adequate security [RFC2865] and [RFC3588] are applicable and provide adequate security
for this purpose. for this purpose.
The communication between the NAS/DHCP relay agent to the DHCP server The communication between the NAS/DHCP relay agent to the DHCP server
must be authenticated, integrity and replay protected. Deployments must be authenticated, integrity and replay protected. Deployments
MAY either rely on lower-layer security, (i.e., physical or link MAY either rely on lower-layer security, (i.e., physical or link
layer security), or rely on security mechanisms specifically defined layer security), or rely on security mechanisms specifically defined
for DHCPv6, such as [RELAY-IPSEC] or [RFC4030]. for DHCPv6, such as [RFC4030].
The communication between the DHCP client and the DHCP server for the The communication between the DHCP client and the DHCP server for the
exchange of home agent information is security sensitive and requires exchange of home agent information is security sensitive and requires
authentication, integrity and replay protection. Either lower-layer authentication, integrity and replay protection. Either lower-layer
security (such as link layer security established as part of the security (such as link layer security established as part of the
network access authentication protocol run) or DHCP security network access authentication protocol run) or DHCP security
[RFC3118] can be used. The latter approach is only applicable in [RFC3118] can be used. The latter approach is only applicable in
non-roaming environments due to the limited applicability of the DHCP non-roaming environments due to the limited applicability of the DHCP
security mechanisms. An adversary that is able to modify home agent security mechanisms. An adversary that is able to modify home agent
information can force the mobile node to use a different home agent information can force the mobile node to use a different home agent
skipping to change at page 18, line 7 skipping to change at page 13, line 7
frequency of bootstrapping. frequency of bootstrapping.
Consequently, if a high level of location privacy is desired, a Consequently, if a high level of location privacy is desired, a
mobile node should not switch to local home agents in an eager manner mobile node should not switch to local home agents in an eager manner
or should not reveal its home address to untrusted nodes. or should not reveal its home address to untrusted nodes.
Furthermore, the disclosure of policy information that can help Furthermore, the disclosure of policy information that can help
locating the mobile node should be carefully considered. locating the mobile node should be carefully considered.
5. IANA Considerations 5. IANA Considerations
The following DHCP option code MUST be assigned by IANA: None
option-code for OPTION_MIP6-RELAY-Option: TBD-1.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Kilian Weniger for his valuable The authors would like to thank Kilian Weniger for his valuable
comment related to location privacy. comment related to location privacy.
7. 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 MIP6 WG. The contributors include Gerardo design team of the MIP6 WG. The contributors include Gerardo
skipping to change at page 21, line 7 skipping to change at page 16, line 7
Vijay Devarapalli vijayd@iprg.nokia.com Vijay Devarapalli vijayd@iprg.nokia.com
Kuntal Chowdhury kchowdhury@starentnetworks.com Kuntal Chowdhury kchowdhury@starentnetworks.com
Julien Bournelle julien.bournelle@int-evry.fr Julien Bournelle julien.bournelle@int-evry.fr
Hannes Tschofenig hannes.tschofenig@siemens.com Hannes Tschofenig hannes.tschofenig@siemens.com
8. References 8. References
8.1 Normative References 8.1. Normative References
[BOOT-PS] Patel et. al., A., "Problem Statement for bootstrapping [HIOPT] Hee Jang et. al., A., "DHCP Option for Home Agent
Mobile IPv6.", draft-ietf-mip6-bootstrap-ps-05.txt (work Discovery in MIPv6.", draft-ietf-mip6-hiopt-01.txt (work
in progress), May 2006. in progress), December 2006.
[HAOPT] Hee Jang et. al., A., "DHCP Option for Home Agent [MIP6-Dime]
Discovery in MIPv6.", draft-jang-dhc-haopt-02.txt (work in Korhonen et. al., J., "Diameter Mobile IPv6: NAS - HAAA
progress), February 2006. Support.", draft-ietf-dime-mip6-integrated-02.txt (work in
progress), January 2007.
[MIP6-RADIUS] [MIP6-RADIUS]
Chowdhury et. al., K., "RADIUS Mobile IPv6 Support.", Chowdhury et. al., K., "RADIUS Mobile IPv6 Support.",
draft-chowdhury-mip6-radius-01.txt (work in progress), draft-ietf-mip6-radius-01.txt (work in progress),
March 2006. October 2006.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[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, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
skipping to change at page 22, line 7 skipping to change at page 17, line 9
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC 4005,
August 2005. August 2005.
[RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for
the Dynamic Host Configuration Protocol (DHCP) Relay Agent the Dynamic Host Configuration Protocol (DHCP) Relay Agent
Option", RFC 4030, March 2005. Option", RFC 4030, March 2005.
8.2 Informative References [RFC4640] Patel, A. and G. Giaretta, "Problem Statement for
bootstrapping Mobile IPv6 (MIPv6)", RFC 4640,
September 2006.
8.2. Informative References
[BOOT-SPLIT] [BOOT-SPLIT]
Giaretta et. al., A., "Mobile IPv6 bootstrapping in split Giaretta et. al., A., "Mobile IPv6 bootstrapping in split
scenario.", draft-ietf-mip6-bootstrapping-split-02.txt scenario.", draft-ietf-mip6-bootstrapping-split-04.txt
(work in progress), March 2006. (work in progress), December 2006.
[RELAY-IPSEC]
Droms, R., "Authentication of DHCP Relay Agent Options
Using IPsec.", draft-ietf-dhc-relay-agent-ipsec-02.txt
(work in progress), May 2005.
Authors' Addresses Authors' Addresses
Kuntal Chowdhury Kuntal Chowdhury
Starent Networks Starent Networks
30 International Place 30 International Place
Tewksbury, MA 01876 Tewksbury, MA 01876
US US
Phone: +1 214-550-1416 Phone: +1 214-550-1416
Email: kchowdhury@starentnetworks.com Email: kchowdhury@starentnetworks.com
Alper Yegin Alper Yegin
Samsung AIT Samsung AIT
Istanbul, Istanbul,
Turkey Turkey
Phone: Phone:
Email: alper01.yegin@partner.samsung.com Email: alper01.yegin@partner.samsung.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 23, line 29 skipping to change at page 19, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 44 change blocks. 
291 lines changed or deleted 99 lines changed or added

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