< draft-ietf-mip6-bootstrapping-split-06.txt   draft-ietf-mip6-bootstrapping-split-07.txt >
MIP6 Working Group G. Giaretta, Ed. MIP6 Working Group G. Giaretta, Ed.
Internet-Draft Qualcomm Internet-Draft Qualcomm
Intended status: Standards Track J. Kempf Intended status: Standards Track J. Kempf
Expires: January 9, 2008 DoCoMo Labs USA Expires: January 23, 2008 DoCoMo Labs USA
V. Devarapalli, Ed. V. Devarapalli, Ed.
Azaire Networks Azaire Networks
July 8, 2007 July 22, 2007
Mobile IPv6 bootstrapping in split scenario Mobile IPv6 bootstrapping in split scenario
draft-ietf-mip6-bootstrapping-split-06 draft-ietf-mip6-bootstrapping-split-07
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 37 skipping to change at page 1, line 37
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 January 9, 2008. This Internet-Draft will expire on January 23, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
A Mobile IPv6 node requires a Home Agent address, a home address, and A Mobile IPv6 node requires a Home Agent address, a home address, and
IPsec security associations with its Home Agent before it can start IPsec security associations with its Home Agent before it can start
utilizing Mobile IPv6 service. RFC 3775 requires that some or all of utilizing Mobile IPv6 service. RFC 3775 requires that some or all of
skipping to change at page 2, line 21 skipping to change at page 2, line 21
scenarios are more specific realizations of the split scenario. scenarios are more specific realizations of the split scenario.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Split scenario . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Split scenario . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Components of the solution . . . . . . . . . . . . . . . . . . 7 4. Components of the solution . . . . . . . . . . . . . . . . . . 7
5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 9
5.1. Home Agent Address Discovery . . . . . . . . . . . . . . . 9 5.1. Home Agent Address Discovery . . . . . . . . . . . . . . . 9
5.1.1. DNS lookup by Home Agent Name . . . . . . . . . . . . 9 5.1.1. DNS lookup by Home Agent Name . . . . . . . . . . . . 10
5.1.2. DNS lookup by service name . . . . . . . . . . . . . . 10 5.1.2. DNS lookup by service name . . . . . . . . . . . . . . 10
5.2. IPsec Security Associations setup . . . . . . . . . . . . 11 5.2. IPsec Security Associations setup . . . . . . . . . . . . 11
5.3. Home Address assignment . . . . . . . . . . . . . . . . . 11 5.3. Home Address assignment . . . . . . . . . . . . . . . . . 11
5.3.1. Home Address assignment by the Home Agent . . . . . . 11 5.3.1. Home Address assignment by the Home Agent . . . . . . 11
5.3.2. Home Address auto-configuration by the Mobile Node . . 11 5.3.2. Home Address auto-configuration by the Mobile Node . . 12
5.4. Authorization and Authentication with MSA . . . . . . . . 13 5.4. Authorization and Authentication with MSA . . . . . . . . 14
6. Home Address registration in the DNS . . . . . . . . . . . . . 14 6. Home Address registration in the DNS . . . . . . . . . . . . . 14
7. Summary of Bootstrapping Protocol Flow . . . . . . . . . . . . 16 7. Summary of Bootstrapping Protocol Flow . . . . . . . . . . . . 16
8. Option and Attribute Format . . . . . . . . . . . . . . . . . 17 8. Option and Attribute Format . . . . . . . . . . . . . . . . . 17
8.1. DNS Update mobility option . . . . . . . . . . . . . . . . 17 8.1. DNS Update mobility option . . . . . . . . . . . . . . . . 17
8.2. MIP6_HOME_PREFIX attribute . . . . . . . . . . . . . . . . 18 8.2. MIP6_HOME_PREFIX attribute . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.1. HA Address Discovery . . . . . . . . . . . . . . . . . . . 19 9.1. HA Address Discovery . . . . . . . . . . . . . . . . . . . 20
9.2. Home Address Assignment through IKEv2 . . . . . . . . . . 21 9.2. Home Address Assignment through IKEv2 . . . . . . . . . . 22
9.3. SA Establishment Using EAP Through IKEv2 . . . . . . . . . 22 9.3. SA Establishment Using EAP Through IKEv2 . . . . . . . . . 22
9.4. Back End Security Between the HA and AAA Server . . . . . 22 9.4. Back End Security Between the HA and AAA Server . . . . . 22
9.5. Dynamic DNS Update . . . . . . . . . . . . . . . . . . . . 22 9.5. Dynamic DNS Update . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 13.1. Normative References . . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Introduction 1. Introduction
Mobile IPv6 [1] requires the Mobile Node to know its Home Agent Mobile IPv6 [1] requires the Mobile Node to know its Home Agent
Address, its own Home Address and the cryptographic materials (e.g. Address, its own Home Address and the cryptographic materials (e.g.
shared keys or certificates) needed to set up IPsec security shared keys or certificates) needed to set up IPsec security
associations with the Home Agent in order to protect Mobile IPv6 associations with the Home Agent in order to protect Mobile IPv6
signaling. This is generally referred to as the Mobile IPv6 signaling. This is generally referred to as the Mobile IPv6
bootstrapping problem [6]. bootstrapping problem [7].
Mobile IPv6 base protocol does not specify any method to Mobile IPv6 base protocol does not specify any method to
automatically acquire this information, which means that network automatically acquire this information, which means that network
administrators are normally required to manually set configuration administrators are normally required to manually set configuration
data on Mobile Nodes and HAs. However, in real deployments, manual data on Mobile Nodes and HAs. However, in real deployments, manual
configuration does not scale as the Mobile Nodes increase in number. configuration does not scale as the Mobile Nodes increase in number.
As discussed in [6], several bootstrapping scenarios can be As discussed in [7], several bootstrapping scenarios can be
identified depending on the relationship between the network operator identified depending on the relationship between the network operator
that authenticates a mobile node for granting network access service that authenticates a mobile node for granting network access service
(Access Service Authorizer, ASA) and the service provider that (Access Service Authorizer, ASA) and the service provider that
authorizes Mobile IPv6 service (Mobility Service Authorizer, MSA). authorizes Mobile IPv6 service (Mobility Service Authorizer, MSA).
This document describes a solution to the bootstrapping problem that This document describes a solution to the bootstrapping problem that
is applicable in a scenario where the MSA and the ASA are different is applicable in a scenario where the MSA and the ASA are different
entities (i.e. split scenario). entities (i.e. split 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 [2]. document are to be interpreted as described in RFC 2119 [2].
General mobility terminology can be found in [7]. The following General mobility terminology can be found in [8]. The following
additional terms are used here: additional terms are used here:
Access Service Authorizer (ASA) Access Service Authorizer (ASA)
A network operator that authenticates a mobile node and A network operator that authenticates a mobile node and
establishes the mobile node's authorization to receive Internet establishes the mobile node's authorization to receive Internet
service. service.
Access Service Provider (ASP) Access Service Provider (ASP)
skipping to change at page 4, line 23 skipping to change at page 4, line 23
prove authorization to obtain the service. prove authorization to obtain the service.
Split scenario Split scenario
A scenario where mobility service and network access service are A scenario where mobility service and network access service are
authorized by different entities. This implies that MSA is authorized by different entities. This implies that MSA is
different from ASA. different from ASA.
3. Split scenario 3. Split scenario
In the problem statement description [6] there is a clear assumption In the problem statement description [7] there is a clear assumption
that mobility service and network access service can be separate. that mobility service and network access service can be separate.
This assumption implies that mobility service and network access This assumption implies that mobility service and network access
service may be authorized by different entities. As an example, the service may be authorized by different entities. As an example, the
service model defined in [6] allows an enterprise network to deploy a service model defined in [7] allows an enterprise network to deploy a
Home Agent and offer Mobile IPv6 service to a user, even if the user Home Agent and offer Mobile IPv6 service to a user, even if the user
is accessing the Internet independent of its enterprise account is accessing the Internet independent of its enterprise account
(e.g., by using his personal WiFi hotspot account at a coffee shop). (e.g., by using his personal WiFi hotspot account at a coffee shop).
Therefore, in this document it is assumed that network access and Therefore, in this document it is assumed that network access and
mobility service are authorized by different entities, which means mobility service are authorized by different entities, which means
that authentication and authorization for mobility service and that authentication and authorization for mobility service and
network access will be considered separately. This scenario is network access will be considered separately. This scenario is
called split scenario. called split scenario.
Moreover, the model defined in [6] separates the entity providing the Moreover, the model defined in [7] separates the entity providing the
service from the entity that authenticates and authorizes the user. service from the entity that authenticates and authorizes the user.
This is similar to the roaming model for network access. Therefore, This is similar to the roaming model for network access. Therefore,
in the split scenario, two different cases can be identified in the split scenario, two different cases can be identified
depending on the relationship between the entity that provides the depending on the relationship between the entity that provides the
mobility service (i.e. Mobility Service Provider, MSP) and the mobility service (i.e. Mobility Service Provider, MSP) and the
entity that authenticates and authorizes the user (i.e. Mobility entity that authenticates and authorizes the user (i.e. Mobility
Service Authorizer, MSA). Service Authorizer, MSA).
Figure 1 depicts the split scenario when the MSP and the MSA are the Figure 1 depicts the split scenario when the MSP and the MSA are the
same entity. This means that the network operator that provides the same entity. This means that the network operator that provides the
skipping to change at page 6, line 40 skipping to change at page 6, line 40
Note that Figure 1 and Figure 2 assume the use of an AAA protocol to Note that Figure 1 and Figure 2 assume the use of an AAA protocol to
authenticate and authorize the Mobile Node for mobility service. authenticate and authorize the Mobile Node for mobility service.
However, since IKEv2 allows EAP client authentication only and the However, since IKEv2 allows EAP client authentication only and the
server authentication needs to be performed based on certificates or server authentication needs to be performed based on certificates or
public keys, the Mobile Node potentially requires a certificate public keys, the Mobile Node potentially requires a certificate
revocation list check (CRL check) even though an AAA protocol is used revocation list check (CRL check) even though an AAA protocol is used
to authenticate and authorize the Mobile Node for mobility service. to authenticate and authorize the Mobile Node for mobility service.
If, instead, PKI is used, the Mobile Node and HA use certificates to If, instead, PKI is used, the Mobile Node and HA use certificates to
authenticate each other and there is no AAA server involved [8]. authenticate each other and there is no AAA server involved [9].
This is conceptually similar to Figure 1, since the MSP == MSA, This is conceptually similar to Figure 1, since the MSP == MSA,
except the Home Agent, and potentially the Mobile Node, may require a except the Home Agent, and potentially the Mobile Node, may require a
certificate revocation list check (CRL check) with the Certificate certificate revocation list check (CRL check) with the Certification
Authority (CA). The CA may be either internal or external to the Authority (CA). The CA may be either internal or external to the
MSP. Figure 3 illustrates this. MSP. Figure 3 illustrates this.
Certificate Certification
Authority Authority
+-------------+ +-------------+
| CA | | CA |
| server | | server |
+-------------+ +-------------+
^ ^
| |
CRL Check | CRL Check |
| Mobility Service | Mobility Service
| Provider and Authorizer | Provider and Authorizer
skipping to change at page 7, line 31 skipping to change at page 7, line 31
| +-------------+ | | +-------------+ |
| | | |
+-------------------+ +-------------------+
+--+ +--+
|MN| |MN|
+--+ +--+
Figure 3 -- Split Scenario with PKI Figure 3 -- Split Scenario with PKI
For more details on the use of PKI for IKEv2 authentication, please
refer to [3] and [10].
The split scenario is the simplest model that can be identified, The split scenario is the simplest model that can be identified,
since no assumptions about the access network are made. This implies since no assumptions about the access network are made. This implies
that the mobility service is bootstrapped independently from the that the mobility service is bootstrapped independently from the
authentication protocol for network access used (e.g. EAP or even authentication protocol for network access used (e.g. EAP or even
open access). For this reason, the solution described in this open access). For this reason, the solution described in this
document and developed for this scenario could also be applied to the document and developed for this scenario could also be applied to the
integrated access network deployment model [6], even if it might not integrated access network deployment model [7], even if it might not
be optimized. be optimized.
4. Components of the solution 4. Components of the solution
The bootstrapping problem is composed of different sub-problems that The bootstrapping problem is composed of different sub-problems that
can be solved independently in a modular way. The components can be solved independently in a modular way. The components
identified and a brief overview of their solution follow. identified and a brief overview of their solution follow.
HA address discovery HA address discovery
The Mobile Node needs to discover the address of its Home Agent. The Mobile Node needs to discover the address of its Home Agent.
The main objective of a bootstrapping solution is to minimize the The main objective of a bootstrapping solution is to minimize the
data pre-configured on the Mobile Node. For this reason, the data pre-configured on the Mobile Node. For this reason, the
DHAAD defined in [1] may not be applicable in real deployments DHAAD defined in [1] may not be applicable in real deployments
since it is required that the Mobile Node is pre-configured with since it is required that the Mobile Node is pre-configured with
the home network prefix and it does not allow an operator to load the home network prefix and it does not allow an operator to load
balance by having Mobile Nodes dynamically assigned to Home Agents balance by having Mobile Nodes dynamically assigned to Home Agents
located in different subnets. This document defines a solution located in different subnets. This document defines a solution
for Home Agent address discovery that is based on Domain Name for Home Agent address discovery that is based on Domain Name
Service (DNS), introducing a new DNS SRV record [3]. The unique Service (DNS), introducing a new DNS SRV record [4]. The unique
information that needs to be pre-configured on the Mobile Node is information that needs to be pre-configured on the Mobile Node is
the domain name of the MSP. the domain name of the MSP.
IPsec Security Associations setup IPsec Security Associations setup
Mobile IPv6 requires that a Mobile Node and its Home Agent share Mobile IPv6 requires that a Mobile Node and its Home Agent share
an IPsec SA in order to protect binding updates and other Mobile an IPsec SA in order to protect binding updates and other Mobile
IPv6 signaling. This document provides a solution that is based IPv6 signaling. This document provides a solution that is based
on IKEv2 and follows what is specified in [4]. The IKEv2 peer on IKEv2 and follows what is specified in [3]. The IKEv2 peer
authentication can be performed both using certificates and using authentication can be performed both using certificates and using
EAP, depending on the network operator's deployment model. EAP, depending on the network operator's deployment model.
Home Address (HoA) assignment Home Address (HoA) assignment
The Mobile Node needs to know its Home Address in order to The Mobile Node needs to know its Home Address in order to
bootstrap Mobile IPv6 operation. The Home Address is assigned by bootstrap Mobile IPv6 operation. The Home Address is assigned by
the Home Agent during the IKEv2 exchange (as described in [4]). the Home Agent during the IKEv2 exchange (as described in [3]).
The solution defined in this document also allows the Mobile Node The solution defined in this document also allows the Mobile Node
to auto-configure its Home Address based on stateless auto- to auto-configure its Home Address based on stateless auto-
configuration [9], Cryptographically Generated Addresses [10] or configuration [11], Cryptographically Generated Addresses [12] or
privacy addresses [11]. privacy addresses [13].
Authentication and Authorization with MSA Authentication and Authorization with MSA
The user must be authenticated in order for the MSP to grant the The user must be authenticated in order for the MSP to grant the
service. Since the user credentials can be verified only by the service. Since the user credentials can be verified only by the
MSA, this authorization step is performed by the MSA. Moreover, MSA, this authorization step is performed by the MSA. Moreover,
the mobility service must be explicitly authorized by the MSA the mobility service must be explicitly authorized by the MSA
based on the user's profile. These operations are performed in based on the user's profile. These operations are performed in
different ways depending on the credentials used by the Mobile different ways depending on the credentials used by the Mobile
Node during the IKEv2 peer authentication and on the backend Node during the IKEv2 peer authentication and on the backend
skipping to change at page 9, line 21 skipping to change at page 9, line 26
5.1. Home Agent Address Discovery 5.1. Home Agent Address Discovery
Once a Mobile Node has obtained network access, it can perform Mobile Once a Mobile Node has obtained network access, it can perform Mobile
IPv6 bootstrapping. For this purpose, the Mobile Node queries the IPv6 bootstrapping. For this purpose, the Mobile Node queries the
DNS server to request information on Home Agent service. As DNS server to request information on Home Agent service. As
mentioned before in the document, the Mobile Node should be pre- mentioned before in the document, the Mobile Node should be pre-
configured with the domain name of the Mobility Service Provider. configured with the domain name of the Mobility Service Provider.
The Mobile Node needs to obtain the IP address of a DNS server before The Mobile Node needs to obtain the IP address of a DNS server before
it can send a DNS request. This can be configured on the Mobile Node it can send a DNS request. This can be configured on the Mobile Node
or obtained through DHCPv6 from the visited link [12]. In any case, or obtained through DHCPv6 from the visited link [14]. In any case,
it is assumed that there is some kind of mechanism by which the it is assumed that there is some kind of mechanism by which the
Mobile Node is configured with a DNS server since a DNS server is Mobile Node is configured with a DNS server since a DNS server is
needed for many other reasons. needed for many other reasons.
Two options for DNS lookup for a Home Agent address are identified in Two options for DNS lookup for a Home Agent address are identified in
this document: DNS lookup by Home Agent Name and DNS lookup by this document: DNS lookup by Home Agent Name and DNS lookup by
service name. service name.
This document does not provide a specific mechanism to load balance This document does not provide a specific mechanism to load balance
different Mobile Nodes among Home Agents. It is possible for an MSP different Mobile Nodes among Home Agents. It is possible for an MSP
to achieve coarse-grained load balancing by dynamically updating the to achieve coarse-grained load balancing by dynamically updating the
SRV RR priorities to reflect the current load on the MSP's collection SRV RR priorities to reflect the current load on the MSP's collection
of Home Agents. Mobile Nodes then use the priority mechanism to of Home Agents. Mobile Nodes then use the priority mechanism to
preferentially select the least loaded HA. The effectiveness of this preferentially select the least loaded HA. The effectiveness of this
technique depends on how much of a load it will place on the DNS technique depends on how much of a load it will place on the DNS
servers, particularly if dynamic DNS is used for frequent updates. servers, particularly if dynamic DNS is used for frequent updates.
While this document specifies a Home Agent Address Discovery solution While this document specifies a Home Agent Address Discovery solution
based on DNS, when the ASP and the MSP are the same entity DHCP may based on DNS, when the ASP and the MSP are the same entity DHCP may
be used. See [13] for details. be used. See [15] for details.
5.1.1. DNS lookup by Home Agent Name 5.1.1. DNS lookup by Home Agent Name
In this case, the Mobile Node is configured with the Fully Qualified In this case, the Mobile Node is configured with the Fully Qualified
Domain Name of the Home Agent. As an example, the Mobile Node could Domain Name of the Home Agent. As an example, the Mobile Node could
be configured with the name "ha1.example.com", where "example.com" is be configured with the name "ha1.example.com", where "example.com" is
the domain name of the MSP granting the mobility service. the domain name of the MSP granting the mobility service.
The Mobile Node constructs a DNS request, by setting the QNAME to the The Mobile Node constructs a DNS request, by setting the QNAME to the
name of the Home Agent. The request has QTYPE set to 'AAAA', so that name of the Home Agent. The request has QTYPE set to 'AAAA', so that
skipping to change at page 10, line 18 skipping to change at page 10, line 29
Note that the configuration of a home agent FQDN on the mobile node Note that the configuration of a home agent FQDN on the mobile node
can also be extended to dynamically assign a local home agent from can also be extended to dynamically assign a local home agent from
the visited network. Such dynamic assignment would be useful, for the visited network. Such dynamic assignment would be useful, for
instance, from the point of view of improving routing efficiency in instance, from the point of view of improving routing efficiency in
bidirectional tunneling mode. Enhancements or conventions for bidirectional tunneling mode. Enhancements or conventions for
dynamic assignment of local home agents are outside the scope of this dynamic assignment of local home agents are outside the scope of this
specification. specification.
5.1.2. DNS lookup by service name 5.1.2. DNS lookup by service name
RFC 2782 [3] defines the service resource record (SRV RR) that allows RFC 2782 [4] defines the service resource record (SRV RR) that allows
an operator to use several servers for a single domain, to move an operator to use several servers for a single domain, to move
services from host to host, and to designate some hosts as primary services from host to host, and to designate some hosts as primary
servers for a service and others as backups. Clients ask for a servers for a service and others as backups. Clients ask for a
specific service/protocol for a specific domain and get back the specific service/protocol for a specific domain and get back the
names of any available servers. names of any available servers.
RFC 2782 [3] also describes the policies to choose a service agent RFC 2782 [4] also describes the policies to choose a service agent
based on the preference and weight values. The DNS SRV record may based on the preference and weight values. The DNS SRV record may
contain the preference and weight values for multiple Home Agents contain the preference and weight values for multiple Home Agents
available to the Mobile Node in addition to the Home Agent FQDNs. If available to the Mobile Node in addition to the Home Agent FQDNs. If
multiple Home Agents are available in the DNS SRV record then Mobile multiple Home Agents are available in the DNS SRV record then Mobile
Node is responsible for processing the information as per policy and Node is responsible for processing the information as per policy and
for picking one Home Agent. If the Home Agent of choice does not for picking one Home Agent. If the Home Agent of choice does not
respond to the IKE_SA_INIT messages or if IKEv2 authentication fails, respond to the IKE_SA_INIT messages or if IKEv2 authentication fails,
the Mobile Node SHOULD try the next Home Agent on the list. If none the Mobile Node SHOULD try the next Home Agent on the list. If none
of the Home Agents respond, the Mobile Node SHOULD try again after a of the Home Agents respond, the Mobile Node SHOULD try again after a
period of time that is configurable on the Mobile Node. If IKEv2 period of time that is configurable on the Mobile Node. If IKEv2
skipping to change at page 11, line 11 skipping to change at page 11, line 21
RECOMMENDED that the DNS server also return the IP addresses of the RECOMMENDED that the DNS server also return the IP addresses of the
Home Agents in AAAA records as part of the additional data section Home Agents in AAAA records as part of the additional data section
(in order to avoid requiring an additional DNS round trip to resolve (in order to avoid requiring an additional DNS round trip to resolve
the FQDNs). the FQDNs).
5.2. IPsec Security Associations setup 5.2. IPsec Security Associations setup
As soon as the Mobile Node has discovered the Home Agent Address, it As soon as the Mobile Node has discovered the Home Agent Address, it
establishes an IPsec Security Association with the Home Agent itself establishes an IPsec Security Association with the Home Agent itself
through IKEv2. The detailed description of this procedure is through IKEv2. The detailed description of this procedure is
provided in [4]. If the Mobile Node wants the HA to register the provided in [3]. If the Mobile Node wants the HA to register the
Home Address in the DNS, it MUST use the FQDN as the initiator Home Address in the DNS, it MUST use the FQDN as the initiator
identity in IKE_AUTH step of the IKEv2 exchange (IDi). This is identity in IKE_AUTH step of the IKEv2 exchange (IDi). This is
needed because the Mobile Node has to prove it is the owner of the needed because the Mobile Node has to prove it is the owner of the
FQDN provided in the subsequent DNS Update Option. See section 6 and FQDN provided in the subsequent DNS Update Option. See section 6 and
section 9 for a more detailed analysis on this issue. section 9 for a more detailed analysis on this issue.
The IKEv2 Mobile Node to Home Agent authentication can be performed The IKEv2 Mobile Node to Home Agent authentication can be performed
using either IKEv2 public key signatures or the Extensible using either IKEv2 public key signatures or the Extensible
Authentication Protocol (EAP). The details about how to use IKEv2 Authentication Protocol (EAP). The details about how to use IKEv2
authentication are described in [4] and [5]. Choice of an IKEv2 peer authentication are described in [3] and [5]. Choice of an IKEv2 peer
authentication method depends on the deployment. The Mobile Node authentication method depends on the deployment. The Mobile Node
should be configured with the information on which IKEv2 should be configured with the information on which IKEv2
authentication method to use. However, IKEv2 restricts the Home authentication method to use. However, IKEv2 restricts the Home
Agent to Mobile Node authentication to use public key signature-based Agent to Mobile Node authentication to use public key signature-based
authentication. authentication.
5.3. Home Address assignment 5.3. Home Address assignment
Home Address assignment is performed during the IKEv2 exchange. The Home Address assignment is performed during the IKEv2 exchange. The
Home Address can be assigned directly by the Home Agent or can be Home Address can be assigned directly by the Home Agent or can be
auto-configured by the Mobile Node. auto-configured by the Mobile Node.
5.3.1. Home Address assignment by the Home Agent 5.3.1. Home Address assignment by the Home Agent
When the Mobile Node runs IKEv2 with its Home Agent, it can request a When the Mobile Node runs IKEv2 with its Home Agent, it can request a
HoA through the Configuration Payload in the IKE_AUTH exchange by HoA through the Configuration Payload in the IKE_AUTH exchange by
including an INTERNAL_IP6_ADDRESS attribute. When the Home Agent including an INTERNAL_IP6_ADDRESS attribute. When the Home Agent
processes the message, it allocates a HoA and sends it a CFG_REPLY processes the message, it allocates a HoA and sends it a CFG_REPLY
message. The Home Agent could consult a DHCP server on the home link message. The Home Agent could consult a DHCP server on the home link
for the actual home address allocation. This is explained in detail for the actual home address allocation. This is explained in detail
in [4]. in [3].
5.3.2. Home Address auto-configuration by the Mobile Node 5.3.2. Home Address auto-configuration by the Mobile Node
With the type of assignment described in the previous section, the With the type of assignment described in the previous section, the
Home Address cannot be generated based on Cryptographically Generated Home Address cannot be generated based on Cryptographically Generated
Addresses (CGAs) [10] or based on the privacy extensions for Addresses (CGAs) [12] or based on the privacy extensions for
stateless auto-configuration [11]. However, the Mobile Node might stateless auto-configuration [13]. However, the Mobile Node might
want to have an auto-configured HoA based on these mechanisms. It is want to have an auto-configured HoA based on these mechanisms. It is
worthwhile to mention that the auto-configuration procedure described worthwhile to mention that the auto-configuration procedure described
in this section cannot be used in some possible deployments, since in this section cannot be used in some possible deployments, since
the Home Agents might be provisioned with pools of allowed Home the Home Agents might be provisioned with pools of allowed Home
Addresses. Addresses.
In the simplest case, the Mobile Node is provided with a pre- In the simplest case, the Mobile Node is provided with a pre-
configured home prefix and home prefix length. In this case the configured home prefix and home prefix length. In this case the
Mobile Node creates a Home Address based on the pre-configured prefix Mobile Node creates a Home Address based on the pre-configured prefix
and sends it to the Home Agent including an INTERNAL_IP6_ADDRESS and sends it to the Home Agent including an INTERNAL_IP6_ADDRESS
skipping to change at page 14, line 13 skipping to change at page 14, line 24
Mobile Node is going to expire. Mobile Node is going to expire.
Due to all these reasons, the Home Agent may need to contact the MSA Due to all these reasons, the Home Agent may need to contact the MSA
in order to authenticate the Mobile Node and authorize mobility in order to authenticate the Mobile Node and authorize mobility
service. This can be accomplished based on a Public Key service. This can be accomplished based on a Public Key
Infrastructure if certificates are used and a PKI is deployed by the Infrastructure if certificates are used and a PKI is deployed by the
MSP and MSA. On the other hand, if the Mobile Node is provided with MSP and MSA. On the other hand, if the Mobile Node is provided with
other types of credentials, the AAA infrastructure must be used. other types of credentials, the AAA infrastructure must be used.
The definition of this backend communication is out of the scope of The definition of this backend communication is out of the scope of
this document. In [14] a list of goals for such a communication is this document. In [16] a list of goals for such a communication is
provided. [15] and [16] define the RADIUS and Diameter extensions, provided. [17] and [18] define the RADIUS and Diameter extensions,
respectively, for the backend communication. respectively, for the backend communication.
6. Home Address registration in the DNS 6. Home Address registration in the DNS
In order that the Mobile Node is reachable through its dynamically In order that the Mobile Node is reachable through its dynamically
assigned Home Address, the DNS needs to be updated with the new Home assigned Home Address, the DNS needs to be updated with the new Home
Address. Since applications make use of DNS lookups on FQDN to find Address. Since applications make use of DNS lookups on FQDN to find
a node, the DNS update is essential for providing IP reachability to a node, the DNS update is essential for providing IP reachability to
the Mobile Node, which is the main purpose of the Mobile IPv6 the Mobile Node, which is the main purpose of the Mobile IPv6
protocol. The need for DNS updating is not discussed in RFC 3775 protocol. The need for DNS updating is not discussed in RFC 3775
skipping to change at page 14, line 49 skipping to change at page 15, line 12
Therefore, due to security and administrative reasons, it is Therefore, due to security and administrative reasons, it is
RECOMMENDED that the Home Agent perform DNS entry updates for the RECOMMENDED that the Home Agent perform DNS entry updates for the
Mobile Node. For this purpose the Mobile Node MAY include a new Mobile Node. For this purpose the Mobile Node MAY include a new
mobility option in the Binding Update, the DNS Update option, with mobility option in the Binding Update, the DNS Update option, with
the flag R not set in the option. This option is defined in the flag R not set in the option. This option is defined in
Section 8 and includes the FQDN that needs to be updated. After Section 8 and includes the FQDN that needs to be updated. After
receiving the Binding Update, the Home Agent MUST update the DNS receiving the Binding Update, the Home Agent MUST update the DNS
entry with the identifier provided by the Mobile Node and the Home entry with the identifier provided by the Mobile Node and the Home
Address included in the Home Address Option. The procedure for Address included in the Home Address Option. The procedure for
sending a dynamic DNS update message is specified in [17]. The sending a dynamic DNS update message is specified in [6]. The
dynamic DNS update SHOULD be performed in a secure way; for this dynamic DNS update SHOULD be performed in a secure way; for this
reason, the usage of TKEY and TSEC or DNSSEC is recommended (see reason, the usage of TKEY and TSEC or DNSSEC is recommended (see
Section 9.5 for details). As soon as the Home Agent has updated the Section 9.5 for details). As soon as the Home Agent has updated the
DNS, it MUST send a Binding Acknowledgement message to the Mobile DNS, it MUST send a Binding Acknowledgement message to the Mobile
Node including the DNS Update mobility option with the correct value Node including the DNS Update mobility option with the correct value
in the Status field (see Section 8.1). in the Status field (see Section 8.1).
This procedure can be performed directly by the Home Agent if the This procedure can be performed directly by the Home Agent if the
Home Agent has a security association with the domain specified in Home Agent has a security association with the domain specified in
the Mobile Node's FQDN. the Mobile Node's FQDN.
On the other hand, if the Mobile Node wants to be reachable through a On the other hand, if the Mobile Node wants to be reachable through a
FQDN that belongs to the MSA, the Home Agent and the DNS server that FQDN that belongs to the MSA, the Home Agent and the DNS server that
must be updated belong to different administrative domains. In this must be updated belong to different administrative domains. In this
case the Home Agent may not share a security association with the DNS case the Home Agent may not share a security association with the DNS
server and the DNS entry update can be performed by the AAA server of server and the DNS entry update can be performed by the AAA server of
the MSA. In order to accomplish this, the Home Agent sends to the the MSA. In order to accomplish this, the Home Agent sends to the
AAA server the FQDN-HoA pair through the AAA protocol. This message AAA server the FQDN-HoA pair through the AAA protocol. This message
is proxied by the AAA infrastructure of the MSP and is received by is proxied by the AAA infrastructure of the MSP and is received by
the AAA server of the MSA. The AAA server of the MSA perform the DNS the AAA server of the MSA. The AAA server of the MSA perform the DNS
update based on [17]. Notice that, even in this case, the Home Agent update based on [6]. Notice that, even in this case, the Home Agent
is always required to perform a DNS update for the reverse entry, is always required to perform a DNS update for the reverse entry,
since this is always performed in the DNS server of the MSP. The since this is always performed in the DNS server of the MSP. The
detailed description of the communication between Home Agent and AAA detailed description of the communication between Home Agent and AAA
is out of the scope of this document. More details are provided in is out of the scope of this document. More details are provided in
[14]. [16].
A mechanism to remove stale DNS entries is needed. A DNS entry A mechanism to remove stale DNS entries is needed. A DNS entry
becomes stale when the related Home Address is no longer used by the becomes stale when the related Home Address is no longer used by the
Mobile Node. To remove a DNS entry, the Mobile Node includes in the Mobile Node. To remove a DNS entry, the Mobile Node includes in the
Binding Update the DNS Update mobility option, with the flag R set in Binding Update the DNS Update mobility option, with the flag R set in
the option. After receiving the Binding Update, the Home Agent MUST the option. After receiving the Binding Update, the Home Agent MUST
remove the DNS entry identified by the FQDN provided by the Mobile remove the DNS entry identified by the FQDN provided by the Mobile
Node and the Home Address included in the Home Address Option. The Node and the Home Address included in the Home Address Option. The
procedure for sending a dynamic DNS update message is specified in procedure for sending a dynamic DNS update message is specified in
[17]. As mentioned above, the dynamic DNS update SHOULD be performed [6]. As mentioned above, the dynamic DNS update SHOULD be performed
in a secure way; for this reason, the usage of TKEY and TSEC or in a secure way; for this reason, the usage of TKEY and TSEC or
DNSSEC is recommended (see Section 9.5 for details). DNSSEC is recommended (see Section 9.5 for details).
If there is no explicit de-registration BU from the Mobile Node, then If there is no explicit de-registration BU from the Mobile Node, then
the HA MAY use the binding cache entry expiration as a trigger to the HA MAY use the binding cache entry expiration as a trigger to
remove the DNS entry. remove the DNS entry.
7. Summary of Bootstrapping Protocol Flow 7. Summary of Bootstrapping Protocol Flow
The message flow of the whole bootstrapping procedure when the The message flow of the whole bootstrapping procedure when the
skipping to change at page 18, line 26 skipping to change at page 19, line 7
MUST be set to 0 MUST be set to 0
MN identity MN identity
The identity of the Mobile Node in FQDN format to be used by the The identity of the Mobile Node in FQDN format to be used by the
Home Agent to send a Dynamic DNS update. It is a variable length Home Agent to send a Dynamic DNS update. It is a variable length
field field
8.2. MIP6_HOME_PREFIX attribute 8.2. MIP6_HOME_PREFIX attribute
The MIP6_HOME_PREFIX attribute is carried in IKEv2 Configuration
Payload messages. This attribute is used to convey the home prefix
from which the Mobile Node auto-configures its home address.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | |R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Prefix Length | | Prefix Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| home prefix | | Home Prefix |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Lifetime | | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Reserved (1 bit) Reserved (1 bit)
This bit MUST be set to zero and MUST be ignored on receipt This bit MUST be set to zero and MUST be ignored on receipt
Attribute Type (15 bits) Attribute Type (15 bits)
A unique identifier for the MIP6_HOME_PREFIX attribute. To be A unique identifier for the MIP6_HOME_PREFIX attribute. To be
assigned by IANA assigned by IANA
Length (2 octets) Length (2 octets)
Length in octets of Value field (home prefix and Prefix Length). Length in octets of Value field (Home Prefix, Prefix Lifetime and
This is multi-valued and can be 0 or 17 Prefix Length). This can be 0 or 21
Prefix Length (2 octets) Prefix Lifetime (4 octets)
The length in bits of the home prefix specified in the field Home The lifetime of the Home Prefix
Prefix
Home Prefix (16 octets) Home Prefix (16 octets)
The prefix of the home link through which the Mobile Node may The prefix of the home link through which the Mobile Node may
auto-configure its Home Address auto-configure its Home Address
Prefix Lifetime (4 octets) Prefix Length (1 octet)
The lifetime of the Home Prefix The length in bits of the home prefix specified in the field Home
Prefix
When the MIP6_HOME_PREFIX attribute is included by the Mobile Node in When the MIP6_HOME_PREFIX attribute is included by the Mobile Node in
the CFG_REQUEST payload, the value of the Length field is 0. On the the CFG_REQUEST payload, the value of the Length field is 0. When
other hand, when the MIP6_HOME_PREFIX attribute is included in the the MIP6_HOME_PREFIX attribute is included in the CFG_REPLY payload
CFG_REPLY payload by the Home Agent, the value of the Length field is by the Home Agent, the value of the Length field is 21 and the
17 and the attribute contains also the Home Prefix and the Prefix attribute contains also the home prefix information.
Length fields.
9. Security Considerations 9. Security Considerations
9.1. HA Address Discovery 9.1. HA Address Discovery
Use of DNS for address discovery carries certain security risks. DNS Use of DNS for address discovery carries certain security risks. DNS
transactions in the Internet are typically done without any transactions in the Internet are typically done without any
authentication of the DNS server by the client or of the client by authentication of the DNS server by the client or of the client by
the server. There are two risks involved: the server. There are two risks involved:
skipping to change at page 21, line 4 skipping to change at page 21, line 37
intensity should be foiled during the IKEv2 transaction. IKEv2 intensity should be foiled during the IKEv2 transaction. IKEv2
implementations are expected to generate their cookies without any implementations are expected to generate their cookies without any
saved state, and to time out cookie generation parameters frequently, saved state, and to time out cookie generation parameters frequently,
with the timeout value increasing if a DoS attack is suspected. This with the timeout value increasing if a DoS attack is suspected. This
should prevent state depletion attacks, and should assure continued should prevent state depletion attacks, and should assure continued
service to legitimate clients until the practical limits on the service to legitimate clients until the practical limits on the
network bandwidth and processing capacity of the Home Agent network network bandwidth and processing capacity of the Home Agent network
are reached. are reached.
Explicit security measures between the DNS server and host, such Explicit security measures between the DNS server and host, such
DNSSEC [18] or TSIG/TKEY [19] [20] can mitigate the risk of 1) and DNSSEC [19] or TSIG/TKEY [20] [21] can mitigate the risk of 1) and
2), but these security measures are not widely deployed on end nodes. 2), but these security measures are not widely deployed on end nodes.
These security measures are not sufficient to protect the Home Agent These security measures are not sufficient to protect the Home Agent
address against DoS attack, however, because a node having a address against DoS attack, however, because a node having a
legitimate security association with the DNS server could legitimate security association with the DNS server could
nevertheless intentionally or inadvertently cause the Home Agent nevertheless intentionally or inadvertently cause the Home Agent
address to become the target of DoS. address to become the target of DoS.
Finally notice that assignment of an home agent from the serving Finally notice that assignment of an home agent from the serving
network access provider's (local home agent) or a home agent from a network access provider's (local home agent) or a home agent from a
nearby network (nearby home agent) may set up the potential to nearby network (nearby home agent) may set up the potential to
compromise a mobile node's location privacy. A home address anchored compromise a mobile node's location privacy. A home address anchored
at such home agent contains some information about the topological at such home agent contains some information about the topological
location of the mobile node. Consequently, a mobile node requiring location of the mobile node. Consequently, a mobile node requiring
location privacy should not disclose this home address to nodes that location privacy should not disclose this home address to nodes that
are not authorized to learn the mobile node's location, e.g., by are not authorized to learn the mobile node's location, e.g., by
updating DNS with the new home address. updating DNS with the new home address.
Security considerations for discovering HA using DHCP are covered in Security considerations for discovering HA using DHCP are covered in
[21]. [22].
9.2. Home Address Assignment through IKEv2 9.2. Home Address Assignment through IKEv2
Mobile IPv6 bootstrapping assigns the home address through the IKEv2 Mobile IPv6 bootstrapping assigns the home address through the IKEv2
transaction. The Mobile Node can either choose to request an transaction. The Mobile Node can either choose to request an
address, similar to DHCP, or the Mobile Node can request a prefix on address, similar to DHCP, or the Mobile Node can request a prefix on
the home link then auto-configure an address. the home link then auto-configure an address.
RFC 3775 [1] requires that a Home Agent check authorization of a home RFC 3775 [1] requires that a Home Agent check authorization of a home
address received during a Binding Update. Therefore, the home agent address received during a Binding Update. Therefore, the home agent
skipping to change at page 22, line 13 skipping to change at page 22, line 45
exists, and are associated with the identity of the mobile node that exists, and are associated with the identity of the mobile node that
made the allocation. made the allocation.
In addition, the home agent MUST ensure that the requested address is In addition, the home agent MUST ensure that the requested address is
not the authorized address of any other mobile node, if both FCFS and not the authorized address of any other mobile node, if both FCFS and
configured modes use the same address space. configured modes use the same address space.
9.3. SA Establishment Using EAP Through IKEv2 9.3. SA Establishment Using EAP Through IKEv2
Security considerations for authentication of the IKE transaction Security considerations for authentication of the IKE transaction
using EAP are covered in [4] . using EAP are covered in [3] .
9.4. Back End Security Between the HA and AAA Server 9.4. Back End Security Between the HA and AAA Server
Some deployments of Mobile IPv6 bootstrapping may use an AAA server Some deployments of Mobile IPv6 bootstrapping may use an AAA server
to handle authorization for mobility service. This process has its to handle authorization for mobility service. This process has its
own security requirements, but the back end protocol for Home Agent own security requirements, but the back end protocol for Home Agent
to AAA server interface is not covered in this draft. Please see to AAA server interface is not covered in this draft. Please see
[14] for a discussion of this interface. [16] for a discussion of this interface.
9.5. Dynamic DNS Update 9.5. Dynamic DNS Update
If a Home Agent performs dynamic DNS update on behalf of the Mobile If a Home Agent performs dynamic DNS update on behalf of the Mobile
Node directly with the DNS server, the Home Agent MUST have a Node directly with the DNS server, the Home Agent MUST have a
security association of some type with the DNS server. The security security association of some type with the DNS server. The security
association MAY be established either using DNSSEC [18] or TSIG/TKEY association MAY be established either using DNSSEC [19] or TSIG/TKEY
[19][20]. A security association is REQUIRED even if the DNS server [20][21]. A security association is REQUIRED even if the DNS server
is in the same administrative domain as the Home Agent. The security is in the same administrative domain as the Home Agent. The security
association SHOULD be separate from the security associations used association SHOULD be separate from the security associations used
for other purposes, such as AAA. for other purposes, such as AAA.
In the case where the Mobility Service Provider is different from the In the case where the Mobility Service Provider is different from the
Mobility Service Authorizer, the network administrators may want to Mobility Service Authorizer, the network administrators may want to
limit the number of cross-administrative domain security limit the number of cross-administrative domain security
associations. If the Mobile Node's FQDN is in the Mobility Service associations. If the Mobile Node's FQDN is in the Mobility Service
Authorizer's domain, since a security association for AAA signaling Authorizer's domain, since a security association for AAA signaling
involved in mobility service authorization is required in any case, involved in mobility service authorization is required in any case,
the Home Agent can send the Mobile Node's FQDN to the AAA server the Home Agent can send the Mobile Node's FQDN to the AAA server
under the HA-AAA server security association, and the AAA server can under the HA-AAA server security association, and the AAA server can
perform the update. In that case, a security association is required perform the update. In that case, a security association is required
between the AAA server and DNS server for the dynamic DNS update. between the AAA server and DNS server for the dynamic DNS update.
See [14] for a deeper discussion of the Home Agent to AAA server See [16] for a deeper discussion of the Home Agent to AAA server
interface. interface.
Regardless of whether the AAA server or Home Agent performs DNS Regardless of whether the AAA server or Home Agent performs DNS
update, the authorization of the Mobile Node to update a FQDN MUST be update, the authorization of the Mobile Node to update a FQDN MUST be
checked prior to the performance of the update. It is an checked prior to the performance of the update. It is an
implementation issue as to how authorization is determined. However, implementation issue as to how authorization is determined. However,
in order to allow this authorization step, the Mobile Node MUST use a in order to allow this authorization step, the Mobile Node MUST use a
FQDN as the IDi in IKE_AUTH step of the IKEv2 exchange. The FQDN FQDN as the IDi in IKE_AUTH step of the IKEv2 exchange. The FQDN
MUST be the same that will be provided by the Mobile Node in the DNS MUST be the same as the FQDN that will be provided by the Mobile Node
Update Option. in the DNS Update Option.
In case EAP over IKEv2 is used to set-up the IPsec SA, the Home Agent In case EAP over IKEv2 is used to set-up the IPsec SA, the Home Agent
gets authorization information about the Mobile Node's FQDN via the gets authorization information about the Mobile Node's FQDN via the
AAA back end communication performed during IKEv2 exchange. The AAA back end communication performed during IKEv2 exchange. The
outcome of this step will give the Home Agent the necessary outcome of this step will give the Home Agent the necessary
information to authorize the DNS update request of the Mobile Node. information to authorize the DNS update request of the Mobile Node.
See [14] for details about the communication between the AAA server See [16] for details about the communication between the AAA server
and the Home Agent needed to perform the authorization. and the Home Agent needed to perform the authorization.
In case certificates are used in IKEv2, the authorization information In case certificates are used in IKEv2, the authorization information
about the FQDN for DNS update MUST be present in the certificate about the FQDN for DNS update MUST be present in the certificate
provided by the Mobile Node. Since the IKEv2 specification does not provided by the Mobile Node. Since the IKEv2 specification does not
include a required certificate type, it is not possible to specify include a required certificate type, it is not possible to specify
precisely how the Mobile Node's FQDN should appear in the precisely how the Mobile Node's FQDN should appear in the
certificate. However, as an example, if the certificate type is certificate. However, as an example, if the certificate type is
"X.509 Certificate - Signature" (one of the recommended types) then "X.509 Certificate - Signature" (one of the recommended types) then
the FQDN may appear in the subjectAltName attribute extension [22]. the FQDN may appear in the subjectAltName attribute extension [23].
10. IANA Considerations 10. IANA Considerations
This document defines a new Mobility Option and a new IKEv2 This document defines a new Mobility Option and a new IKEv2
Configuration Attribute Type. Configuration Attribute Type.
The following values should be assigned: The following values should be assigned:
o from "Mobility Option" namespace ([1]): DNS-UPDATE-TYPE o from "Mobility Option" namespace ([1]): DNS-UPDATE-TYPE
(Section 8.1) (Section 8.1)
skipping to change at page 24, line 45 skipping to change at page 25, line 30
13. References 13. References
13.1. Normative References 13.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [3] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[4] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007. April 2007.
[4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
13.2. Informative References 13.2. Informative References
[6] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping [7] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
Mobile IPv6 (MIPv6)", RFC 4640, September 2006. Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[7] Manner, J. and M. Kojo, "Mobility Related Terminology", [8] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[8] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet [9] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet
X.509 Public Key Infrastructure Certificate Management Protocol X.509 Public Key Infrastructure Certificate Management Protocol
(CMP)", RFC 4210, September 2005. (CMP)", RFC 4210, September 2005.
[9] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", [10] Korver, B., "The Internet IP Security PKI Profile of IKEv1/
ISAKMP, IKEv2, and PKIX",
draft-ietf-pki4ipsec-ikecert-profile-12 (work in progress),
February 2007.
[11] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-11 (work in progress), March 2007. draft-ietf-ipv6-2461bis-11 (work in progress), March 2007.
[10] Aura, T., "Cryptographically Generated Addresses (CGA)", [12] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[11] Narten, T. and R. Draves, "Privacy Extensions for Stateless [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[12] Droms, R., "DNS Configuration options for Dynamic Host [14] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003. December 2003.
[13] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the [15] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
Integrated Scenario", Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-04 (work in draft-ietf-mip6-bootstrapping-integrated-dhc-04 (work in
progress), June 2007. progress), June 2007.
[14] Giaretta, G., "AAA Goals for Mobile IPv6", [16] Giaretta, G., "AAA Goals for Mobile IPv6",
draft-ietf-mip6-aaa-ha-goals-03 (work in progress), draft-ietf-mip6-aaa-ha-goals-03 (work in progress),
September 2006. September 2006.
[15] Chowdhury, K., "RADIUS Mobile IPv6 Support", [17] Chowdhury, K., "RADIUS Mobile IPv6 Support",
draft-ietf-mip6-radius-02 (work in progress), March 2007. draft-ietf-mip6-radius-02 (work in progress), March 2007.
[16] Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA Support", [18] Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA Support",
draft-ietf-dime-mip6-split-02 (work in progress), May 2007. draft-ietf-dime-mip6-split-02 (work in progress), May 2007.
[17] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic [19] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[18] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033, "DNS Security Introduction and Requirements", RFC 4033,
March 2005. March 2005.
[19] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, [20] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", "Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000. RFC 2845, May 2000.
[20] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", [21] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
RFC 2930, September 2000. RFC 2930, September 2000.
[21] Jang, H., "DHCP Option for Home Information Discovery in [22] Jang, H., "DHCP Option for Home Information Discovery in
MIPv6", draft-ietf-mip6-hiopt-05 (work in progress), June 2007. MIPv6", draft-ietf-mip6-hiopt-05 (work in progress), June 2007.
[22] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 [23] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
Authors' Addresses Authors' Addresses
Gerardo Giaretta Gerardo Giaretta
Qualcomm Qualcomm
Email: gerardog@qualcomm.com Email: gerardog@qualcomm.com
 End of changes. 76 change blocks. 
102 lines changed or deleted 113 lines changed or added

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