< draft-ietf-mip6-bootstrapping-split-00.txt   draft-ietf-mip6-bootstrapping-split-01.txt >
MIP6 WG G. Giaretta, Editor MIP6 WG G. Giaretta, Editor
Internet Draft Tilab Internet Draft Tilab
Expires: December 22, 2005 J. Kempf Expires: April 21, 2006 J. Kempf
DoCoMo Labs USA DoCoMo Labs USA
V. Devarapalli V. Devarapalli
Nokia Nokia
June 22, 2005 October 21, 2005
Mobile IPv6 bootstrapping in split scenario Mobile IPv6 bootstrapping in split scenario
draft-ietf-mip6-bootstrapping-split-00.txt draft-ietf-mip6-bootstrapping-split-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress." as reference 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 22, 2005. This Internet-Draft will expire on April 21, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
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,
IPsec security associations with its Home Agent before it can start and IPsec security associations with its Home Agent before it can
utilizing Mobile IPv6 service. RFC 3775 requires that some or all of start utilizing Mobile IPv6 service. RFC 3775 requires that some
these are statically configured. This document defines how a Mobile or all of these are statically configured. This document defines
IPv6 node can bootstrap this information from non-topological how a Mobile IPv6 node can bootstrap this information from non-
information and security credentials preconfigured on the Mobile topological information and security credentials preconfigured on
Node. The solution defined in this document solves the boostrapping the Mobile Node. The solution defined in this document solves the
problem from draft-ietf-mip6-bootstrapping-ps-02 when the Mobile bootstrapping problem from draft-ietf-mip6-bootstrapping-ps-02
Node's mobility service is authorized by a different service provider when the Mobile Node's mobility service is authorized by a
than basic network access, and is therefore generically applicable to different service provider than basic network access, and is
any bootstrapping case. therefore generically applicable to any bootstrapping case.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
document are to be interpreted as described in RFC-2119 [1]. in this document are to be interpreted as described in RFC-2119
[1].
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
2. Terminology....................................................5 2. Terminology....................................................5
3. Split scenario.................................................6 3. Split scenario.................................................6
4. Components of the solution.....................................8 4. Components of the solution.....................................9
5. Protocol Operations...........................................10 5. Protocol Operations...........................................11
5.1. Home Agent Address Discovery.............................10 5.1. Home Agent Address Discovery.............................11
5.1.1. DNS lookup by Home Agent Name.......................10 5.1.1. DNS lookup by Home Agent Name.......................11
5.1.2. DNS lookup by service name..........................11 5.1.2. DNS lookup by service name..........................12
5.2. IPsec Security Associations setup........................12 5.2. IPsec Security Associations setup........................13
5.3. Home Address assignment..................................12 5.3. Home Address assignment..................................13
5.3.1. Home Address assignment by the Home Agent...........12 5.3.1. Home Address assignment by the Home Agent...........13
5.3.2. Home Address auto-configuration by the Mobile Node..12 5.3.2. Home Address auto-configuration by the Mobile Node..13
5.4. Authorization and Authentication with MSA................14 5.4. Authorization and Authentication with MSA................15
6. Home Address registration in the DNS..........................16 6. Home Address registration in the DNS..........................17
7. Summary of Bootstrapping Protocol Flow........................18 7. Summary of Bootstrapping Protocol Flow........................19
8. Option and Attribute Format...................................20 8. Option and Attribute Format...................................21
8.1. DNS Update mobility option...............................20 8.1. DNS Update mobility option...............................21
8.2. MIP6_HOME_PREFIX attribute...............................21 8.2. MIP6_HOME_PREFIX attribute...............................22
9. Security Considerations.......................................23 9. Security Considerations.......................................23
9.1. HA Address Discovery.....................................23 9.1. HA Address Discovery.....................................23
9.2. Home Address Assignment through IKEv2....................24 9.2. Home Address Assignment through IKEv2....................24
9.3. SA Establishment Using EAP Through IKEv2.................25 9.3. SA Establishment Using EAP Through IKEv2.................25
9.4. Back End Security Between the HA and AAA Server..........25 9.4. Back End Security Between the HA and AAA Server..........25
9.5. Dynamic DNS Update.......................................25 9.5. Dynamic DNS Update.......................................25
10. IANA Considerations..........................................27 10. IANA Considerations..........................................27
11. Contributors.................................................28 11. Contributors.................................................28
12. References...................................................29 12. Acknowledgments..............................................29
12.1. Normative References....................................29 13. References...................................................30
12.2. Informative References..................................29 13.1. Normative References....................................30
Authors' Addresses...............................................31 13.2. Informative References..................................30
Intellectual Property Statement..................................32 Authors' Addresses...............................................32
Disclaimer of Validity...........................................32 Intellectual Property Statement..................................33
Copyright Statement..............................................32 Disclaimer of Validity...........................................33
Acknowledgment...................................................32 Copyright Statement..............................................33
Acknowledgment...................................................33
1. Introduction 1. Introduction
Mobile IPv6 [2] requires the Mobile Node to know its Home Agent Mobile IPv6 [2] 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
shared keys or certificates) needed to set-up IPsec security (e.g. shared keys or certificates) needed to set-up IPsec security
associations with the Home Agent in order to protect MIPv6 signaling. associations with the Home Agent in order to protect MIPv6
This is generally referred to as the Mobile IPv6 bootstrapping signaling. This is generally referred to as the Mobile IPv6
problem [4]. bootstrapping problem [4].
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 MNs and HAs. However, in real deployments, manual data on MNs 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 [4], several bootstrapping scenarios can be As discussed in [4], several bootstrapping scenarios can be
identified depending on the relationship between the network operator identified depending on the relationship between the network
that authenticates a mobile host for granting network access service operator that authenticates a mobile host for granting network
(Access Service Authorizer, ASA) and the service provider that access service (Access Service Authorizer, ASA) and the service
authorizes Mobile IPv6 service (Mobility Service Authorizer, MSA). provider that authorizes Mobile IPv6 service (Mobility Service
This document describes a solution to the bootstrapping problem that Authorizer, MSA). This document describes a solution to the
is applicable in a scenario where the MSA and the ASA are different bootstrapping problem that is applicable in a scenario where the
entities (i.e. split scenario). MSA and the ASA are different entities (i.e. split scenario).
2. Terminology 2. Terminology
General mobility terminology can be found in [8]. The following General mobility terminology can be found in [8]. The following
additional terms are used here: additional terms are used here:
ASA ASA
Access Service Authorizer. A network operator that authenticates Access Service Authorizer. A network operator that
a mobile host and establishes the mobile host's authorization to authenticates a mobile host and establishes the mobile host's
receive Internet service. authorization to receive Internet service.
ASP ASP
Access Service Provider. A network operator that provides direct Access Service Provider. A network operator that provides
IP packet forwarding to and from the end host. direct IP packet forwarding to and from the end host.
MSA MSA
Mobility Service Authorizer. A service provider that authorizes Mobility Service Authorizer. A service provider that
Mobile IPv6 service. authorizes Mobile IPv6 service.
MSP MSP
Mobility Service Provider. A service provider that provides Mobility Service Provider. A service provider that provides
Mobile IPv6 service. In order to obtain such service, the mobile Mobile IPv6 service. In order to obtain such service, the
host must be authenticated and prove authorization to obtain the mobile host must be authenticated and prove authorization to
service. 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
authorized by different entities. This implies that MSA is are 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 draft [4] there is a clear assumption that In the problem statement draft [4] there is a clear assumption
mobility service and network access service can be separate. This that mobility service and network access service can be separate.
assumption implies that mobility service and network access service This assumption implies that mobility service and network access
may be authorized by different entities. As an example, the service service may be authorized by different entities. As an example,
model defined in [4] allows an enterprise network to deploy a Home the service model defined in [4] allows an enterprise network to
Agent and offer Mobile IPv6 service to a user, even if the user is deploy a Home Agent and offer Mobile IPv6 service to a user, even
accessing the Internet independent of its enterprise account (e.g., if the user is accessing the Internet independent of its
by using his personal WiFi hotspot account at a coffee shop). enterprise account (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 called network access will be considered separately. This scenario is
split scenario. called split scenario.
Moreover, the model defined in [4] separates the entity providing the Moreover, the model defined in [4] separates the entity providing
service from the entity that authenticates and authorizes the user. the service from the entity that authenticates and authorizes the
This is similar to the roaming model for network access. Therefore, user. This is similar to the roaming model for network access.
in the split scenario, two different cases can be identified Therefore, in the split scenario, two different cases can be
depending on the relationship between the entity that provides the identified depending on the relationship between the entity that
mobility service (i.e. Mobility Service Provider, MSP) and the entity provides the mobility service (i.e. Mobility Service Provider,
that authenticates and authorizes the user (i.e. Mobility Service MSP) and the entity that authenticates and authorizes the user
Authorizer, MSA). (i.e. Mobility 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
same entity. This means that the network operator that provides the the same entity. This means that the network operator that
Home Agent authenticates and authorizes the user for mobility provides the Home Agent authenticates and authorizes the user for
service. mobility service.
Mobility Service Mobility Service
Provider and Authorizer Provider and Authorizer
+-------------------------------------------+ +-------------------------------------------+
| | | |
| +-------------+ +--+ | | +-------------+ +--+ |
| | MSA/MSP AAA | <-------------> |HA| | | | MSA/MSP AAA | <-------------> |HA| |
| | server | AAA protocol +--+ | | | server | AAA protocol +--+ |
| +-------------+ | | +-------------+ |
| | | |
+-------------------------------------------+ +-------------------------------------------+
+--+ +--+
|MN| |MN|
+--+ +--+
Figure 1 - Split Scenario (MSA == MSP) Figure 1 - Split Scenario (MSA == MSP)
Figure 2 shows the split scenario in case the MSA and the MSP are two Figure 2 shows the split scenario in case the MSA and the MSP are
different entities. This might happen if the Mobile Node is far from two different entities. This might happen if the Mobile Node is
its MSA network and is assigned a closer HA to optimize performance far from its MSA network and is assigned a closer HA to optimize
or if the MSA cannot provide any Home Agent and relies on a third performance or if the MSA cannot provide any Home Agent and relies
party (i.e. the MSP) to grant mobility service to its users. Notice on a third party (i.e. the MSP) to grant mobility service to its
that the MSP might be or might not be also the network operator that users. Notice that the MSP might be or might not be also the
is providing network access (i.e. ASP, Access Service Provider). network operator that is providing network access (i.e. ASP,
Access Service Provider).
Mobility Service Mobility Service
Authorizer Authorizer
+-------------+ +-------------+
| MSA AAA | | MSA AAA |
| server | | server |
+-------------+ +-------------+
^ ^
| |
AAA protocol | AAA protocol |
skipping to change at page 7, line 37 skipping to change at page 7, line 35
| | MSP AAA | <-------------> |HA| | | | MSP AAA | <-------------> |HA| |
| | server | AAA protocol +--+ | | | server | AAA protocol +--+ |
| +-------------+ | | +-------------+ |
| | | |
+-------------------------------------------+ +-------------------------------------------+
+--+ +--+
|MN| |MN|
+--+ +--+
Figure 2 - Split Scenario (MSA != MSP) Figure 2 - Split Scenario (MSA != MSP)
Note that Figure 1 and Figure 2 assume the use of an AAA protocol
to authenticate and authorize the MN for mobility service. If,
instead, a PKI is used, the MN and HA exchange certificates and
there is no AAA server involved. This is conceptually similar to
Figure 1, since the MSP == MSA, except the HA may require a
certificate revocation list check (CRL check) with the Certificate
Authority (CA). The CA may be either internal or external to the
MSP. Figure 3 illustrates.
Certificate
Authority
+-------------+
| CA |
| server |
+-------------+
^
|
CRL Check |
| Mobility Service
| Provider and Authorizer
+--------|----------+
| V |
| +-------------+ |
| | HA | |
| | | |
| +-------------+ |
| |
+-------------------+
+--+
|MN|
+--+
Figure 3 - Split Scenario with PKI
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
that the mobility service is bootstrapped independently from the implies that the mobility service is bootstrapped independently
authentication protocol for network access used (e.g. PANA, EAP). For from the authentication protocol for network access used (e.g.
this reason, the solution described in this document and developed PANA, EAP). For this reason, the solution described in this
for this scenario could also be applied to the integrated access document and developed for this scenario could also be applied to
network deployment model [4], even if it might not be optimized . the integrated access network deployment model [4], even if it
might not 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
can be solved independently in a modular way. The components that 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.
o HA address discovery. The Mobile Node needs to discover the o HA address discovery. The Mobile Node needs to discover the
address of its Home Agent. The main objective of a bootstrapping address of its Home Agent. The main objective of a
solution is to minimize the data pre-configured on the Mobile bootstrapping solution is to minimize the data pre-configured
Node. For this reason, the DHAAD defined in [2] may not be on the Mobile Node. For this reason, the DHAAD defined in [2]
applicable in real deployments since it is required that the may not be applicable in real deployments since it is required
Mobile Node is pre-configured with the home network prefix and it that the Mobile Node is pre-configured with the home network
does not allow an operator to load balance by having Mobile Nodes prefix and it does not allow an operator to load balance by
dynamically assigned to Home Agents located in different subnets. having Mobile Nodes dynamically assigned to Home Agents located
This document defines a solution for Home Agent address discovery in different subnets. This document defines a solution for Home
that is based on Domain Name Service (DNS), introducing a new DNS Agent address discovery that is based on Domain Name Service
SRV record [5]. The unique information that needs to be pre- (DNS), introducing a new DNS SRV record [5]. The unique
configured on the Mobile Node is the domain name of the MSP. information that needs to be pre-configured on the Mobile Node
is the domain name of the MSP.
o IPsec Security Associations setup. MIPv6 requires that a Mobile o IPsec Security Associations setup. MIPv6 requires that a Mobile
Node and its Home Agent share an IPsec SA in order to protect Node and its Home Agent share an IPsec SA in order to protect
binding updates and other MIPv6 signaling. This document provides binding updates and other MIPv6 signaling. This document
a solution that is based on IKEv2 and follows what is specified in provides a solution that is based on IKEv2 and follows what is
[6]. The IKEv2 peer authentication can be performed both using specified in [6]. The IKEv2 peer authentication can be
certificates and using EAP, depending on the network operator's performed both using certificates and using EAP, depending on
deployment model. the network operator's deployment model.
o HoA assignment. The Mobile Node needs to know its Home Address in o HoA assignment. The Mobile Node needs to know its Home Address
order to bootstrap Mobile IPv6 operation. The Home Address is in order to bootstrap Mobile IPv6 operation. The Home Address
assigned by the Home Agent during the IKEv2 exchange (as described is assigned by the Home Agent during the IKEv2 exchange (as
in [6]). The solution defined in this draft also allows the Mobile described in [6]). The solution defined in this draft also
Node to auto-configure its Home Address based on stateless auto- allows the Mobile Node to auto-configure its Home Address based
configuration ([20]), Cryptographically Generated Addresses ([9]) on stateless auto-configuration ([20]), Cryptographically
or privacy addresses ([10]). Generated Addresses ([9]) or privacy addresses ([10]).
o Authentication and Authorization with MSA. The user must be o Authentication and Authorization with MSA. The user must be
authenticated in order for the MSA to grant the service. Moreover, authenticated in order for the MSP to grant the service. Since
the mobility service must be explicitly authorized by the MSA the user credentials can be verified only by the MSA, this
based on the user's profile. These operations are performed in authorization step is performed by the MSA. Moreover, the
mobility service must be explicitly authorized by the MSA 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
infrastructure (PKI or AAA). infrastructure (PKI or AAA).
An optional part of bootstrapping involves providing a way for the An optional part of bootstrapping involves providing a way for the
Mobile Node to have its FQDN updated in the DNS with a dynamically Mobile Node to have its FQDN updated in the DNS with a dynamically
assigned home address. While not all applications will require this assigned home address. While not all applications will require
service, many networking applications use the FQDN to obtain an this service, many networking applications use the FQDN to obtain
address for a node prior to starting IP traffic with it. The solution an address for a node prior to starting IP traffic with it. The
defined in this document specifies that the dynamic DNS update is solution defined in this document specifies that the dynamic DNS
performed by the Home Agent or through the AAA infrastructure, update is performed by the Home Agent or through the AAA
depending on the trust relationship in place. infrastructure, depending on the trust relationship in place.
5. Protocol Operations 5. Protocol Operations
This section describes in detail the procedures needed to perform This section describes in detail the procedures needed to perform
Mobile IPv6 bootstrapping based on the components identified in the Mobile IPv6 bootstrapping based on the components identified in
previous section. the previous section.
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
IPv6 bootstrapping. For this purpose, the Mobile Node queries the DNS Mobile IPv6 bootstrapping. For this purpose, the Mobile Node
server to request information on Home Agent service. As mentioned queries the DNS server to request information on Home Agent
before in the document, the only information that needs to be auto- service. As mentioned before in the document, the only information
configured on the Mobile Node is the domain name of the Mobility that needs to be pre-configured on the Mobile Node is the domain
Service Provider. name of the Mobility Service Provider.
The Mobile Node needs to obtain the IP address of the DNS server The Mobile Node needs to obtain the IP address of the DNS server
before it can send a DNS request. This can be pre-configured on the before it can send a DNS request. This can be pre-configured on
Mobile Node or obtained through DHCPv6 from the visited link [11]. In the Mobile Node or obtained through DHCPv6 from the visited link
any case, it is assumed that there is some kind of mechanism by which [11]. In any case, it is assumed that there is some kind of
the Mobile Node is configured with a DNS server since a DNS server is mechanism by which the Mobile Node is configured with a DNS server
needed for many other reasons. since a DNS server is 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
this document: DNS lookup by Home Agent Name and DNS lookup by in this document: DNS lookup by Home Agent Name and DNS lookup by
service name. service name.
While this document specifies a Home Agent Address Discovery solution This document does not provide a specific mechanism to load
based on DNS, when the ASP and the MSP are the same entity DHCP may balance different Mobile Nodes among Home Agents. It is possible
be used. See [15] for details. for an MSP to achieve coarse-grained load balancing by dynamically
updating the SRV RR priorities to reflect the current load on the
MSP's collection of Home Agents. Mobile Nodes then use the
priority mechanism to preferentially select the least loaded HA.
The effectiveness of this technique depends on how much of a load
it will place on the DNS servers, particularly if dynamic DNS is
used for frequent updates.
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 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
Domain Name of the Home Agent. As an example, the Mobile Node could Qualified Domain Name of the Home Agent. As an example, the Mobile
be configured with the name "ha1.example.com", where "example.com" is Node could be configured with the name "ha1.example.com", where
the domain name of the MSP granting the mobility service. "example.com" is 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
name of the Home Agent. The request has QTYPE set to 'AAAA', so that the name of the Home Agent. The request has QTYPE set to 'AAAA',
the DNS server sends the IPv6 address of the Home Agent. Once the DNS so that the DNS server sends the IPv6 address of the Home Agent.
server replies to this query, the Mobile Node knows its Home Agent Once the DNS server replies to this query, the Mobile Node knows
address and can run IKEv2 in order to set up an IPsec SA and get a its Home Agent address and can run IKEv2 in order to set up the
Home Address. IPsec SAs and get a Home Address.
Additionally, it could be useful to provide an ability for the Mobile Additionally, the ability to provide a mobile node with a
Node to discover a Home Agent placed in a particular location (e.g. localized home agent (e.g. on the visited link) can help to
on the visited link). In order to achieve this, the Mobile Node must optimize handover signaling and improve routing efficiency in bi-
be able to construct a DNS request such that the DNS server will be directional tunneling mode. There are a variety of ways this can
able to reply with a Home Agent from the requested location. This can be achieved in an interoperable way. One way is to provision the
be accomplished by using a specific naming convention for the FQDNs mobile node with an FQDN for a local home agent when it configures
of the Home Agents. As an example, an operator might assign the FQDN for the local link. Another way is to specify an interoperable
"ha.locationA.operator.com" to the Home Agent located in "location A" naming convention for constructing home agent FQDNs based on
and the FQDN "ha.locationB.operator.com" to the Home Agent located in location. For example, an operator might assign the FQDN
"location B". If the Mobile Node wants to use a Home Agent located in "ha.locationA.operator.com" to the Home Agent located in "location
"location A", it will set the QNAME to "ha.locationA.operator.com" in A" and the FQDN "ha.locationB.operator.com" to the Home Agent
the DNS request. located in "location B". If the Mobile Node wants to use a Home
Agent located in "location A", it will set the QNAME to
"ha.locationA.operator.com" in the DNS request. The exact way in
which localized Home Agents are configured is out of scope for
this draft.
5.1.2. DNS lookup by service name 5.1.2. DNS lookup by service name
RFC 2782 [5] defines the service resource record (SRV RR), that RFC 2782 [5] defines the service resource record (SRV RR), that
allows an operator to use several servers for a single domain, to allows an operator to use several servers for a single domain, to
move services from host to host, and to designate some hosts as move services from host to host, and to designate some hosts as
primary servers for a service and others as backups. Clients ask for primary servers for a service and others as backups. Clients ask
a specific service/protocol for a specific domain and get back the for a specific service/protocol for a specific domain and get back
names of any available servers. the names of any available servers.
RFC 2782 [5] describes also the policies to choose a service agent RFC 2782[5] describes also 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.
multiple Home Agents are available in the DNS SRV record then Mobile If multiple Home Agents are available in the DNS SRV record then
Node is responsible for processing the information as per policy and Mobile Node is responsible for processing the information as per
for picking one Home Agent. If the Home Agent of choice does not policy and for picking one Home Agent. If the Home Agent of choice
respond for some reason or the IKEv2 authentication fails, the Mobile does not respond for some reason or the IKEv2 authentication
Node SHOULD try other Home Agents on the list. fails, the Mobile Node SHOULD try other Home Agents on the list.
The service name for Mobile IPv6 Home Agent service as required by The service name for Mobile IPv6 Home Agent service as required by
RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a
transport name cannot be used here because Mobile IPv6 does not run transport name cannot be used here because Mobile IPv6 does not
over a transport protocol. run over a transport protocol.
The SRV RR has a DNS type code of 33. As an example, the Mobile The SRV RR has a DNS type code of 33. As an example, the Mobile
constructs a request with QNAME set to "mip6.example.com" and QTYPE constructs a request with QNAME set to "_mip6_ipv6.example.com"
to SRV. The reply contains the FQDNs of one or more servers, that can and QTYPE to SRV. The reply contains the FQDNs of one or more
then be resolved in a separate DNS transaction to the IP addresses. servers, that can then be resolved in a separate DNS transaction
However, it is RECOMMENDED that the DNS server also return the IP to the IP addresses. However, it is RECOMMENDED that the DNS
addresses of the Home Agents in AAAA records as part of the server also return the IP addresses of the Home Agents in AAAA
additional data section in order to avoid requiring an additional DNS records as part of the additional data section in order to avoid
round trip to resolve the FQDNs, if there is room in the SRV reply. requiring an additional DNS round trip to resolve the FQDNs, if
there is room in the SRV reply.
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,
establishes an IPsec Security Association with the Home Agent itself it establishes an IPsec Security Association with the Home Agent
through IKEv2. The detailed description of this procedure is provided itself through IKEv2. The detailed description of this procedure
in [6]. is provided in [6]. If the Mobile Node wants the HA to register
the 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
needed because the Mobile Node has to provide it is the owner of
the FQDN provided in the subsequent DNS Update Option. See section
6 and 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
using either IKEv2 public key signatures or the Extensible performed using either IKEv2 public key signatures or the
Authentication Protocol (EAP). The details about how IKEv2 Extensible Authentication Protocol (EAP). The details about how
authentication is done are described in [6] and [7]. Choice of an IKEv2 authentication is done are described in [6] and [7]. Choice
IKEv2 peer authentication method depends on the deployment. However, of an IKEv2 peer authentication method depends on the deployment.
IKEv2 restricts the Home Agent to Mobile Node authentication to use However, IKEv2 restricts the Home Agent to Mobile Node
public key signature based authentication. authentication to use public key signature based 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.
Home Address can be assigned directly by the Home Agent or can be The Home Address can be assigned directly by the Home Agent or can
auto-configured by the Mobile Node. be 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
HoA through the Configuration Payload in the IKE_AUTH exchange by request a HoA through the Configuration Payload in the IKE_AUTH
including an INTERNAL_IP6_ADDRESS attribute. When the Home Agent exchange by including an INTERNAL_IP6_ADDRESS attribute. When the
processes the message, it allocates a HoA and sends it a CFG_REPLY Home Agent processes the message, it allocates a HoA and sends it
message. The Home Agent could consult a DHCP server on the home link a CFG_REPLY message. The Home Agent could consult a DHCP server on
for the actual home address allocation. This is explained in detail the home link for the actual home address allocation. This is
in [6]. explained in detail in [6].
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
Addresses (CGAs) [9] or based on the privacy extensions for stateless Generated Addresses (CGAs) [9] or based on the privacy extensions
autoconfiguration [10]. However, the Mobile Node might want to have for stateless autoconfiguration [10]. However, the Mobile Node
an auto-configured HoA based on these mechanisms. It is worthwhile to might want to have an auto-configured HoA based on these
mention that the auto-configuration procedure described in this mechanisms. It is worthwhile to mention that the auto-
section cannot be used in some possible deployment, since the Home configuration procedure described in this section cannot be used
Agents might be provisioned with pools of allowed Home Addresses. in some possible deployment, since the Home Agents might be
provisioned with pools of allowed Home 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
and sends it to the Home Agent including an INTERNAL_IP6_ADDRESS prefix and sends it to the Home Agent including an
attribute in a Configuration Payload of type CFG_REQUEST. If the Home INTERNAL_IP6_ADDRESS attribute in a Configuration Payload of type
Address is valid, the Home Agent replies with a CFG_REPLY, including CFG_REQUEST. If the Home Address is valid, the Home Agent replies
an INTERNAL_IP6_ADDRESS with the same address. If the Home Address with a CFG_REPLY, including an INTERNAL_IP6_ADDRESS with the same
provided by the Mobile Node is not valid, the Home Agent assigns a address. If the Home Address provided by the Mobile Node is not
different Home Address including an INTERNAL_IP6_ADDRESS attribute valid, the Home Agent assigns a different Home Address including
with a new value. According to [7] the Mobile Node MUST use the an INTERNAL_IP6_ADDRESS attribute with a new value. According to
address sent by the Home Agent. Later, if the Mobile Node wants to [7] the Mobile Node MUST use the address sent by the Home Agent.
use an auto-configured Home Address (e.g. based on CGA), it can run Later, if the Mobile Node wants to use an auto-configured Home
Mobile Prefix Discovery, obtain a prefix, auto-configure a new Home Address (e.g. based on CGA), it can run Mobile Prefix Discovery,
Address and then perform a new CREATE_CHILD_SA exchange. obtain a prefix, auto-configure a new Home Address and then
perform a new CREATE_CHILD_SA exchange.
If the Mobile Node is not provided with a pre-configured Home Prefix, If the Mobile Node is not provided with a pre-configured Home
the Mobile cannot simply propose an auto-configured HoA in the Prefix, the Mobile cannot simply propose an auto-configured HoA in
Configuration Payload since the Mobile Node does not know the home the Configuration Payload since the Mobile Node does not know the
prefix before the start of the IKEv2 exchange. The Mobile Node must home prefix before the start of the IKEv2 exchange. The Mobile
obtain the home prefix and the home prefix length before it can Node must obtain the home prefix and the home prefix length before
configure a home address. it can configure a home address.
One simple solution would be for the Mobile Node to just assume that One simple solution would be for the Mobile Node to just assume
the prefix length on the home link is 64 bits and extract the home that the prefix length on the home link is 64 bits and extract the
prefix from the Home Agent's address. The disadvantage with this home prefix from the Home Agent's address. The disadvantage with
solution is that the home prefix cannot be anything other than /64. this solution is that the home prefix cannot be anything other
Moreover, this ties the prefix on the home link and the Home Agent's than /64. Moreover, this ties the prefix on the home link and the
address, but, in general, a Home Agent with a particular address Home Agent's address, but, in general, a Home Agent with a
should be able to serve a number of prefixes on the home link, not particular address should be able to serve a number of prefixes on
just the prefix from which its address is configured. the home link, not just the prefix from which its address is
configured.
Another solution would be for the Mobile Node to assume that the Another solution would be for the Mobile Node to assume that the
prefix length on the home link is 64 bits and send its interface prefix length on the home link is 64 bits and send its interface
identifier to the Home Agent in the IP6_INTERNAL_ADDRESS attribute identifier to the Home Agent in the IP6_INTERNAL_ADDRESS attribute
within the CFG_REQ payload. Even though this approach does not tie within the CFG_REQ payload. Even though this approach does not tie
the prefix on the home link and the Home Agent's address, it still the prefix on the home link and the Home Agent's address, it still
requires that the home prefix length is 64 bits. requires that the home prefix length is 64 bits.
For this reason the Mobile Node needs to obtain the home link For this reason the Mobile Node needs to obtain the home link
prefixes through the IKEv2 exchange. In the Configuration Payload prefixes through the IKEv2 exchange. In the Configuration Payload
during the IKE_AUTH exchange, the Mobile Node includes the during the IKE_AUTH exchange, the Mobile Node includes the
MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home
Agent, when it processes this message, should include in the Agent, when it processes this message, should include in the
CFG_REPLY payload prefix information for one prefix on the home link. CFG_REPLY payload prefix information for one prefix on the home
This prefix information includes the prefix length (see section 8.2). link. This prefix information includes the prefix length (see
The Mobile Node auto-configures a Home Address from the prefix section 8.2). The Mobile Node auto-configures a Home Address from
returned in the CFG_REPLY message and runs a CREATE_CHILD_SA exchange the prefix returned in the CFG_REPLY message and runs a
to create security associations for the new Home Address. CREATE_CHILD_SA exchange to create security associations for the
new Home Address.
As mentioned before in this document, there are deployments where As mentioned before in this document, there are deployments where
auto-configuration of the Home Address cannot be used. In this case, auto-configuration of the Home Address cannot be used. In this
when the Home Agent receives a CFG_REQUEST including a case, when the Home Agent receives a CFG_REQUEST including a
MIP6_HOME_PREFIX attribute, in the subsequent IKE response it MIP6_HOME_PREFIX attribute, in the subsequent IKE response it
includes a Notify Payload type "USE_ASSIGNED_HoA" and the related includes a Notify Payload type "USE_ASSIGNED_HoA" and the related
Home Address in a INTERNAL_IP6_ADDRESS attribute. If the Mobile Node Home Address in a INTERNAL_IP6_ADDRESS attribute. If the Mobile
gets a "USE_ASSIGNED_HoA" Notify Payload in response to the Node gets a "USE_ASSIGNED_HoA" Notify Payload in response to the
Configuration Payload containing the MIP6_HOME_PREFIX attribute, it Configuration Payload containing the MIP6_HOME_PREFIX attribute,
looks for an INTERNAL_IP6_ADDRESS attribute and MUST use the address it looks for an INTERNAL_IP6_ADDRESS attribute and MUST use the
contained in it in the subsequent CREATE_CHILD_SA exchange. address contained in it in the subsequent CREATE_CHILD_SA
exchange.
When the Home Agent receives a Binding Update for the Mobile Node, it When the Home Agent receives a Binding Update for the Mobile Node,
performs proxy DAD for the auto-configured Home Address. If DAD it performs proxy DAD for the auto-configured Home Address. If DAD
fails, the Home Agent rejects the Binding Update. If the Mobile Node fails, the Home Agent rejects the Binding Update. If the Mobile
receives a Binding Acknowledgement with status 134 (DAD failed), it Node receives a Binding Acknowledgement with status 134 (DAD
MUST stop using the current Home Address, configure a new HoA, and failed), it MUST stop using the current Home Address, configure a
then run IKEv2 CREATE_CHILD_SA exchange to create security new HoA, and then run IKEv2 CREATE_CHILD_SA exchange to create
associations based on the new HoA. The Mobile Node does not need to security associations based on the new HoA. The Mobile Node does
run IKE_INIT and IKE_AUTH exchanges again. Once the necessary not need to run IKE_INIT and IKE_AUTH exchanges again. Once the
security associations are created, the Mobile Node sends a Binding necessary security associations are created, the Mobile Node sends
Update for the new Home Address. a Binding Update for the new Home Address.
It is worth noting that with this mechanism, the prefix information It is worth noting that with this mechanism, the prefix
carried in MIP6_HOME_PREFIX attribute includes only one prefix and information carried in MIP6_HOME_PREFIX attribute includes only
does not carry all the information that is typically present when one prefix and does not carry all the information that is
received through a IPv6 router advertisement. Mobile Prefix typically present when received through a IPv6 router
Discovery, specified in RFC 3775 [2], is the mechanism through which advertisement. Mobile Prefix Discovery, specified in RFC 3775 [2],
the Mobile Node can get all prefixes on the home link and all related is the mechanism through which the Mobile Node can get all
information. That means that MIP6_HOME_PREFIX attribute is only used prefixes on the home link and all related information. That means
for Home Address auto-configuration and does not replace the usage of that MIP6_HOME_PREFIX attribute is only used for Home Address
Mobile Prefix Discovery for the purposes detailed in RFC 3775. auto-configuration and does not replace the usage of Mobile Prefix
Discovery for the purposes detailed in RFC 3775.
5.4. Authorization and Authentication with MSA 5.4. Authorization and Authentication with MSA
In a scenario where the Home Agent is discovered dynamically by the In a scenario where the Home Agent is discovered dynamically by
Mobile Node, it is very likely that the Home Agent is not able to the Mobile Node, it is very likely that the Home Agent is not able
verify by its own the credentials provided by the Mobile Node during to verify by its own the credentials provided by the Mobile Node
the IKEv2 exchange. Moreover, the mobility service needs to be during the IKEv2 exchange. Moreover, the mobility service needs to
explicitly authorized based on the user's profile. As an example, the be explicitly authorized based on the user's profile. As an
Home Agent might not be aware if the mobility service can be granted example, the Home Agent might not be aware if the mobility service
at a particular time of the day or if the credit of the Mobile Node can be granted at a particular time of the day or if the credit of
is going to expire. the 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
in order to authenticate the Mobile Node and authorize mobility MSA in order to authenticate the Mobile Node and authorize
service. This can be accomplished based on a Public Key mobility 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
MSP and MSA. On the other hand, if the Mobile Node is provided with the MSP and MSA. On the other hand, if the Mobile Node is provided
other types of credentials, the AAA infrastructure must be used. with 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
this document. In [12] a list of goals for such a communication is of this document. In [12] a list of goals for such a communication
provided. is provided.
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
Address. Since applications make use of DNS lookups on FQDN to find a Home Address. Since applications make use of DNS lookups on FQDN
node, the DNS update is essential for providing IP reachability to to find a node, the DNS update is essential for providing IP
the Mobile Node, which is the main purpose of the Mobile IPv6 reachability to the Mobile Node, which is the main purpose of the
protocol. The need of DNS update is not discussed in RFC 3775 since Mobile IPv6 protocol. The need of DNS update is not discussed in
it assumes that the Mobile Node is provisioned with a static home RFC 3775 since it assumes that the Mobile Node is provisioned with
address. However, when a dynamic Home Address is assigned to the a static home address. However, when a dynamic Home Address is
Mobile Node, any existing DNS entry becomes invalid and the Mobile assigned to the Mobile Node, any existing DNS entry becomes
Node becomes unreachable unless a DNS update is performed. invalid and the Mobile Node becomes unreachable unless a DNS
update is performed.
Since the DNS update must be performed securely in order to prevent Since the DNS update must be performed securely in order to
attacks or modifications from malicious nodes, the node performing prevent attacks or modifications from malicious nodes, the node
this update must share a security association with the DNS server. performing this update must share a security association with the
Having all possible Mobile Nodes sharing a security association with DNS server. Having all possible Mobile Nodes sharing a security
the DNS servers of the MSP might be cumbersome from an administrative association with the DNS servers of the MSP might be cumbersome
perspective. Moreover, even if a Mobile Node has a security from an administrative perspective. Moreover, even if a Mobile
association with a DNS server of its MSP, an address authorization Node has a security association with a DNS server of its MSP, an
issue comes into the picture. A detailed analysis of possible threats address authorization issue comes into the picture. A detailed
against DNS update is provided in section 9.5. analysis of possible threats against DNS update is provided in
section 9.5.
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 update for the RECOMMENDED that the Home Agent perform DNS entry update 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, the DNS Update option, with the flag R not set in mobility option, the DNS Update option, with the flag R not set in
the Binding Update. This option is defined in section 8 and includes the Binding Update. This option is defined in section 8 and
the FQDN that needs to be updated. After receiving the Binding includes the FQDN that needs to be updated. After receiving the
Update, the Home Agent MUST update the DNS entry with the identifier Binding Update, the Home Agent MUST update the DNS entry with the
provided by the Mobile Node and the Home Address included in the Home identifier provided by the Mobile Node and the Home Address
Address Option. The procedure for sending a dynamic DNS update included in the Home Address Option. The procedure for sending a
message is specified in [14]. The dynamic DNS update SHOULD be dynamic DNS update message is specified in [14]. The dynamic DNS
performed in a secure way; for this reason, the usage of TKEY and update SHOULD be performed in a secure way; for this reason, the
TSEC or DNSSEC is recommended (see section 9.5 for details). As usage of TKEY and TSEC or DNSSEC is recommended (see section 9.5.
soon as the Home Agent has updated the DNS, it MUST send a Binding for details). As soon as the Home Agent has updated the DNS, it
Acknowledgement message to the Mobile Node including the DNS Update MUST send a Binding Acknowledgement message to the Mobile Node
mobility option with the correct value in the Status field (see including the DNS Update mobility option with the correct value in
section 8.1). 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
FQDN that belongs to the MSA, the Home Agent and the DNS server that through a FQDN that belongs to the MSA, the Home Agent and the DNS
must be updated belong to different administrative domain. In this server that must be updated belong to different administrative
case the Home Agent may not share a security association with the DNS domain. In this case the Home Agent may not share a security
server and the DNS entry update can be performed by the AAA server of association with the DNS server and the DNS entry update can be
the MSA. In order to accomplish this, the Home Agent sends to the AAA performed by the AAA server of the MSA. In order to accomplish
server the FQDN-HoA pair through the AAA protocol. This message is this, the Home Agent sends to the AAA server the FQDN-HoA pair
proxied by the AAA infrastructure of the MSP and is received by the through the AAA protocol. This message is proxied by the AAA
AAA server of the MSA. The AAA server of the MSA perform the DNS infrastructure of the MSP and is received by the AAA server of the
update based on [14]. The detailed description of the communication MSA. The AAA server of the MSA perform the DNS update based on
between Home Agent and AAA is out of the scope of this draft. More [14]. The detailed description of the communication between Home
details are provided in [12]. Agent and AAA is out of the scope of this draft. More details are
provided in [12].
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 more used by the becomes stale when the related Home Address is no more used by the
Mobile Node. To remove a DNS entry, the MN includes the DNS Update Mobile Node. To remove a DNS entry, the MN includes the DNS Update
mobility option, with the flag R set in the Binding Update. After mobility option, with the flag R set in the Binding Update. After
receiving the Binding Update, the Home Agent MUST remove the DNS receiving the Binding Update, the Home Agent MUST remove the DNS
entry identified by the FQDN provided by the Mobile Node and the Home entry identified by the FQDN provided by the Mobile Node and the
Address included in the Home Address Option. The procedure for Home Address included in the Home Address Option. The procedure
sending a dynamic DNS update message is specified in [14]. As for sending a dynamic DNS update message is specified in [14]. As
mentioned above, the dynamic DNS update SHOULD be performed in a mentioned above, the dynamic DNS update SHOULD be performed in a
secure way; for this reason, the usage of TKEY and TSEC or DNSSEC is secure way; for this reason, the usage of TKEY and TSEC or DNSSEC
recommended (see section 9.5 for details). is recommended (see section 9.5. for details).
This approach does not work if the Mobile Node stops using the Home This approach does not work if the Mobile Node stops using the
Address without sending a Binding Update message (e.g. in case of Home Address without sending a Binding Update message (e.g. in
crash). In this case, an additional mechanism to trigger the DNS case of crash). In this case, an additional mechanism to trigger
entry removal is needed. For this purpose, the Home Agent has a timer the DNS entry removal is needed. For this purpose, the Home Agent
related to the DNS entry of the Mobile Node. This timer is has a timer related to the DNS entry of the Mobile Node. This
initialized when the Mobile Node sends a Binding Update with R==0 timer is initialized when the Mobile Node sends a Binding Update
(i.e. when the MN asks the Home Agent to bind the FQDN to the Home with R==0 (i.e. when the MN asks the Home Agent to bind the FQDN
Address). The initial value of this timer is configurable by the to the Home Address). The initial value of this timer is
network operator. configurable by the network operator.
If the Home Agent receives a Binding Update with R==1, it removes the If the Home Agent receives a Binding Update with R==1, it removes
DNS entry as described in the previous paragraph and removes the the DNS entry as described in the previous paragraph and removes
timer associated to that entry. If the timer expires without the timer associated to that entry. If the timer expires without
receiving a Binding Update with R==1, the HA checks the Binding receiving a Binding Update with R==1, the HA checks the Binding
Cache. If there is an existing Binding Cache entry for the HoA, the Cache. If there is an existing Binding Cache entry for the HoA,
HA does not remove the DNS entry and re-initialize the timer. If the HA does not remove the DNS entry and re-initialize the timer.
there is not a Binding Cache entry, it sends a Neighbor Soliciation If there is not a Binding Cache entry, it sends a Neighbor
message to check if the MN is at home and is using the HoA. If the HA Solicitation message to check if the MN is at home and is using
gets a Neighbor Advertisement message, it does not remove the DNS the HoA. If the HA gets a Neighbor Advertisement message, it does
entry and re-initialize the timer. If it does not receive a NA, it not remove the DNS entry and re-initialize the timer. If it does
removes the DNS entry and the timer associated to it. not receive a NA, it removes the DNS entry and the timer
associated to it.
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
dynamic DNS update is performed by the Home Agent is depicted in dynamic DNS update is performed by the Home Agent is depicted in
Figure 3. Figure 3.
+----+ +----+ +-----+ +----+ +----+ +-----+
| MN | | HA | | DNS | | MN | | HA | | DNS |
+----+ +----+ +-----+ +----+ +----+ +-----+
skipping to change at page 18, line 26 skipping to change at page 19, line 26
(HoA configuration) (HoA configuration)
<======================> <======================>
BU (DNS update option) BU (DNS update option)
-----------------------> ----------------------->
DNS update DNS update
<-------------------> <------------------->
BU (DNS update option) BU (DNS update option)
<----------------------- <-----------------------
Figure 3 - Dynamic DNS update by the HA Figure 3 - Dynamic DNS update by the HA
Figure 4 shows the message flow of the whole bootstrapping procedure Figure 4 shows the message flow of the whole bootstrapping
when the dynamic DNS update is performed by the AAA server of the procedure when the dynamic DNS update is performed by the AAA
MSA. server of the MSA.
+----+ +----+ +---+ +---+ +----+ +----+ +---+ +---+
| MN | | HA | |AAA| |DNS| | MN | | HA | |AAA| |DNS|
+----+ +----+ +---+ +---+ +----+ +----+ +---+ +---+
IKEv2 exchange IKEv2 exchange
(HoA configuration) (HoA configuration)
<======================> <======================>
BU (DNS update option) BU (DNS update option)
skipping to change at page 19, line 28 skipping to change at page 20, line 28
<--------------> <-------------->
DNS update DNS update
<-----------> <----------->
AAA answer AAA answer
(FQDN, HoA) (FQDN, HoA)
<--------------> <-------------->
BU (DNS update option) BU (DNS update option)
<----------------------- <-----------------------
Figure 4 - Dynamic DNS update by the AAA Figure 4 - Dynamic DNS update by the AAA
Notice that, even in this last case, the Home Agent is always Notice that, even in this last case, the Home Agent is always
required to perform a DNS update for the reverse entry, since this is required to perform a DNS update for the reverse entry, since this
always performed in the DNS server of the MSP. This is not depicted is always performed in the DNS server of the MSP. This is not
in Figure 4. depicted in Figure 4.
8. Option and Attribute Format 8. Option and Attribute Format
8.1. DNS Update mobility option 8.1. DNS Update mobility option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 25 skipping to change at page 21, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Option Type - DNS-UPDATE-TYPE to be defined by IANA o Option Type - DNS-UPDATE-TYPE to be defined by IANA
o Option Length - 8 bit unsigned integer indicating the length of o Option Length - 8 bit unsigned integer indicating the length of
the option excluding the type and length fields the option excluding the type and length fields
o Status - 8 bit unsigned integer indicating the result of the o Status - 8 bit unsigned integer indicating the result of the
dynamic DNS update procedure. This field MUST be set to 0 and dynamic DNS update procedure. This field MUST be set to 0 and
ignored by the receiver when the DNS Update mobility option is ignored by the receiver when the DNS Update mobility option is
included in a Binding Update message. When the DNS Update mobility included in a Binding Update message. When the DNS Update
option is included in the Binding Acknowledgement message, values mobility option is included in the Binding Acknowledgement
of the Status field less than 128 indicate that the dynamic DNS message, values of the Status field less than 128 indicate that
update was performed successfully by the Home Agent. Values the dynamic DNS update was performed successfully by the Home
greater than or equal to 128 indicate that the dynamic DNS update Agent. Values greater than or equal to 128 indicate that the
was not completed by the HA. The following Status values are dynamic DNS update was not completed by the HA. The following
currently defined: Status values are currently defined:
0 DNS update performed 0 DNS update performed
128 Reason unspecified 128 Reason unspecified
129 Administratively prohibited 129 Administratively prohibited
130 DNS Update Failed 130 DNS Update Failed
o R flag - if set the MN is requesting the HA to remove the DNS o R flag - if set the MN is requesting the HA to remove the DNS
entry identified by the FQDN specified in this option and the HoA entry identified by the FQDN specified in this option and the
of the MN. If not set, the MN is requesting the HA to create or HoA of the MN. If not set, the MN is requesting the HA to
update a DNS entry with its HoA and the FQDN specified in the create or update a DNS entry with its HoA and the FQDN
option. specified in the option.
o Reserved - these bits are reserved for future purposes and MUST be o Reserved - these bits are reserved for future purposes and MUST
set to 0. be set to 0.
o MN identity - the identity of the Mobile Node to be used by the o MN identity - the identity of the Mobile Node 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
field. length field.
8.2. MIP6_HOME_PREFIX attribute 8.2. MIP6_HOME_PREFIX attribute
The MIP6_HOME_PREFIX attribute is included in the IKEv2 CFG_REQUEST The MIP6_HOME_PREFIX attribute is included in the IKEv2
by the Mobile Node to ask the Home Agent for the home prefix and is CFG_REQUEST by the Mobile Node to ask the Home Agent for the home
included in the CFG_REPLY by the Home Agent to provide the Mobile prefix and is included in the CFG_REPLY by the Home Agent to
Node with home prefix and home prefix length. The format of this provide the Mobile Node with home prefix and home prefix length.
attribute is equal to the format of the Configuration Attributes The format of this attribute is equal to the format of the
defined in [7] and is depicted below. Configuration Attributes defined in [7] and is depicted below.
1 2 3 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 ! Length | !R| Attribute Type ! Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| home prefix | | home prefix |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | | Prefix Length |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
o Reserved (1 bit) - This bit MUST be set to zero and MUST be o Reserved (1 bit) - This bit MUST be set to zero and MUST be
ignored on receipt. ignored on receipt.
o Attribute Type (7 bits) - A unique identifier for the o Attribute Type (7 bits) - A unique identifier for the
MIP6_HOME_PREFIX attribute. To be assigned by IANA. MIP6_HOME_PREFIX attribute. To be assigned by IANA.
o Length (2 octets) - Length in octets of Value field (home prefix o Length (2 octets) - Length in octets of Value field (home
and Prefix Length). This is multi-valued and can be 0 or 17. prefix and Prefix Length). This is multi-valued and can be 0 or
17.
o Home Prefix (16 octets) - The prefix of the home link through o Home Prefix (16 octets) - The prefix of the home link through
which the Mobile Node must auto-configure its Home Address. which the Mobile Node must auto-configure its Home Address.
o Prefix Length (1 octet) - The length of the home prefix specified o Prefix Length (1 octet) - The length of the home prefix
in the field 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
the CFG_REQUEST payload, the value of the Length field is 0. On the in the CFG_REQUEST payload, the value of the Length field is 0. On
other hand, when the MIP6_HOME_PREFIX attribute is included in the the other hand, when the MIP6_HOME_PREFIX attribute is included in
CFG_REPLY payload by the Home Agent, the value of the Length field is the CFG_REPLY payload by the Home Agent, the value of the Length
17 and the attribute contains also the Home Prefix and the Prefix field is 17 and the attribute contains also the Home Prefix and
Length fields. the Prefix 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.
transactions in the Internet are typically done without any DNS 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:
1) A legitimate client obtains a bogus Home Agent address from a 1) A legitimate client obtains a bogus Home Agent address from a
bogus DNS server. This is sometimes called a "pharming" attack, bogus DNS server. This is sometimes called a "pharming" attack,
2) An attacking client obtains a legitimate Home Agent address from a 2) An attacking client obtains a legitimate Home Agent address
legitimate server. from a legitimate server.
The risk in Case 1 is mitigated because the Mobile Node is required The risk in Case 1 is mitigated because the Mobile Node is
to conduct an IKE transaction with the Home Agent prior to performing required to conduct an IKE transaction with the Home Agent prior
a Binding Update to establish Mobile IPv6 service. According to the to performing a Binding Update to establish Mobile IPv6 service.
IKEv2 specification [7], the responder must present the initiator According to the IKEv2 specification [7], the responder must
with a valid certificate containing the responder's public key, and present the initiator with a valid certificate containing the
the responder to initiator IKE_AUTH message must be protected with an responder's public key, and the responder to initiator IKE_AUTH
authenticator calculated using the public key in the certificate. message must be protected with an authenticator calculated using
Thus, an attacker would have to set up both a bogus DNS server and a the public key in the certificate. Thus, an attacker would have to
bogus Home Agent, and provision the Home Agent with a certificate set up both a bogus DNS server and a bogus Home Agent, and
that a victim Mobile Node could verify. If the Mobile Node can detect provision the Home Agent with a certificate that a victim Mobile
that the certificate is not trustworthy, the attack will be foiled Node could verify. If the Mobile Node can detect that the
when the Mobile Node attempts to set up the IKE SA. certificate is not trustworthy, the attack will be foiled when the
Mobile Node attempts to set up the IKE SA.
The risk in Case 2 is limited for a single Mobile Node to Home Agent The risk in Case 2 is limited for a single Mobile Node to Home
transaction if the attacker does not possess proper credentials to Agent transaction if the attacker does not possess proper
authenticate with the Home Agent. The IKE SA establishment will fail credentials to authenticate with the Home Agent. The IKE SA
when the attacking Mobile Node attempts to authenticate itself with establishment will fail when the attacking Mobile Node attempts to
the Home Agent. Regardless of whether the Home Agent utilizes EAP or authenticate itself with the Home Agent. Regardless of whether the
host-side certificates to authenticate the Mobile Node, the Home Agent utilizes EAP or host-side certificates to authenticate
authentication will fail unless the Mobile Node has valid the Mobile Node, the authentication will fail unless the Mobile
credentials. Node has valid credentials.
Another risk exists in Case 2 because the attacker may be attempting Another risk exists in Case 2 because the attacker may be
to propagate a DoS attack on the Home Agent. In that case, the attempting to propagate a DoS attack on the Home Agent. In that
attacker obtains the Home Agent address from the DNS, then propagates case, the attacker obtains the Home Agent address from the DNS,
the address to a network of attacking hosts that bombard the Home then propagates the address to a network of attacking hosts that
Agent with traffic. This attack is not unique to the bootstrapping bombard the Home Agent with traffic. This attack is not unique to
solution, however, it is actually a risk that any Mobile IPv6 Home the bootstrapping solution, however, it is actually a risk that
Agent installation faces. In fact, the risk is faced by any service any Mobile IPv6 Home Agent installation faces. In fact, the risk
in the Internet that distributes a unicast globally routable address is faced by any service in the Internet that distributes a unicast
to clients. Since Mobile IPv6 requires that the Mobile Node globally routable address to clients. Since Mobile IPv6 requires
communicate through a globally routable unicast address of a Home that the Mobile Node communicate through a globally routable
Agent, it is possible that the Home Agent address could be propagated unicast address of a Home Agent, it is possible that the Home
to an attacker by various means (theft of the Mobile Node, malware Agent address could be propagated to an attacker by various means
installed on the Mobile Node, evil intent of the Mobile Node owner (theft of the Mobile Node, malware installed on the Mobile Node,
him/herself, etc.) even if the home address is manually configured on evil intent of the Mobile Node owner him/herself, etc.) even if
the Mobile Node. Consequently, every Mobile IPv6 Home Agent the home address is manually configured on the Mobile Node.
installation will likely be required to mount anti-DoS measures. Such Consequently, every Mobile IPv6 Home Agent installation will
measures include overprovisioning of links to and from Home Agents likely be required to mount anti-DoS measures. Such measures
and of Home Agent processing capacity, vigilant monitoring of traffic include overprovisioning of links to and from Home Agents and of
on the Home Agent networks to detect when traffic volume increases Home Agent processing capacity, vigilant monitoring of traffic on
abnormally indicating a possible DoS attack, and hot spares that can the Home Agent networks to detect when traffic volume increases
quickly be switched on in the event an attack is mounted on an abnormally indicating a possible DoS attack, and hot spares that
can quickly be switched on in the event an attack is mounted on an
operating collection of Home Agents. DoS attacks of moderate operating collection of Home Agents. DoS attacks of moderate
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
with the timeout value increasing if a DoS attack is suspected. This frequently, with the timeout value increasing if a DoS attack is
should prevent state depletion attacks, and should assure continued suspected. This should prevent state depletion attacks, and should
service to legitimate clients until the practical limits on the assure continued service to legitimate clients until the practical
network bandwith and processing capacity of the Home Agent network limits on the network bandwith and processing capacity of the Home
are reached. Agent network are reached.
Explicit security measures between the DNS server and host, such Explicit security measures between the DNS server and host, such
DNSSEC [16] or TSIG/TKEY [17] [18] can mitigate the risk of 1) and DNSSEC [16] or TSIG/TKEY [17] [18] 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
These security measures are not sufficient to protect the Home Agent nodes. These security measures are not sufficient to protect the
address against DoS attack, however, because a node having a Home Agent address against DoS attack, however, because a node
legitimate security association with the DNS server could having a 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.
Security considerations for discovering HA using DHCP are covered in Finally notice that assignment of an home agent from the serving
draft-jang-dhc-haopt-01 [15]. network access provider's (local home agent) or a home agent from
a nearby network (nearby home agent) may set up the potential to
compromise a MN's location privacy. However, since a standardized
mechanism of assigning local or nearby home agents is out of scope
for this document, it is not possible to present detailed security
considerations. Please see other drafts that contain detailed
mechanisms for localized home agent assignment, such as [15], for
information on the location privacy properties of particular home
agent assignment mechanisms.
Security considerations for discovering HA using DHCP are covered
in draft-jang-dhc-haopt-01 [15].
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
transaction. The Mobile Node can either choose to request an address, IKEv2 transaction. The Mobile Node can either choose to request an
similar to DHCP, or the Mobile Node can request a prefix on the home address, similar to DHCP, or the Mobile Node can request a prefix
link then autoconfigure an address. on the home link then autoconfigure an address.
RFC 3775 [2] and 3776 [3] require that a Home Agent check RFC 3775 [2] and 3776 [3] require that a Home Agent check
authorization on a home address received during a Binding Update. The authorization on a home address received during a Binding Update.
Home Agent MUST set up authorization by linking the home address to
the identity of the IPsec SAs used to authenticate the Binding Update
message. The linking MUST be done either during the IKE_AUTH phase or
CREATE_CHILD_SA phase when the IPsec SAs are constructed.
If the address is autoconfigured, RFC 3775 requires the Home Agent to The Home Agent MUST set up authorization by linking the home
proxy-defend the address on the home link after the Mobile Node address to the identity of the IPsec SAs used to authenticate the
Binding Update message. The linking MUST be done either during the
IKE_AUTH phase or CREATE_CHILD_SA phase when the IPsec SAs are
constructed.
If the address is autoconfigured, RFC 3775 requires the Home Agent
to proxy-defend the address on the home link after the Mobile Node
performs the initial Binding Update. Since it is not currently performs the initial Binding Update. Since it is not currently
possible to securely proxy CGAs using SEND, attacks on address possible to securely proxy CGAs using SEND, attacks on address
resolution for Neighbor Discovery listed in RFC 3756 are possible on resolution for Neighbor Discovery listed in RFC 3756 are possible
dynamically assigned home addresses that are proxied by the Home on dynamically assigned home addresses that are proxied by the
Agent. Home Agent.
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 draft-ietf-mip6-ikev2-ipsec [6]. using EAP are covered in draft-ietf-mip6-ikev2-ipsec [6].
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
to handle authorization for mobility service. This process has its server to handle authorization for mobility service. This process
own security requirements, but the back end protocol for Home Agent has its own security requirements, but the back end protocol for
to AAA server interface is not covered in this draft. Please see Home Agent to AAA server interface is not covered in this draft.
draft-ietf-mip6-aaa-ha-goals [12] for a discussion of this interface. Please see draft-ietf-mip6-aaa-ha-goals [12] for a discussion of
this interface.
9.5. Dynamic DNS Update 9.5. Dynamic DNS Update
Mobile IPv6 bootstrapping recommends the Home Agent to update the Mobile IPv6 bootstrapping recommends the Home Agent to update the
Mobile Node's FQDN with a dynamically assigned home address rather Mobile Node's FQDN with a dynamically assigned home address rather
than have the Mobile Node itself do it (see Section 6 above). This than have the Mobile Node itself do it (see Section 6 above). This
choice was motivated by a concern for preventing redirection-based choice was motivated by a concern for preventing redirection-based
flooding attacks (see draft-ietf-mip6-ro-sec [19] for more flooding attacks (see draft-ietf-mip6-ro-sec [19] for more
information about redirection-based flooding attacks and the role information about redirection-based flooding attacks and the role
preventing them played in the design of Mobile IPv6 route preventing them played in the design of Mobile IPv6 route
optimization security). Exactly as for route optimization, it is optimization security). Exactly as for route optimization, it is
possible for a node that is the legitimate owner of a DNS FQDN - in possible for a node that is the legitimate owner of a DNS FQDN -
the sense that it has a security association with the DNS server in the sense that it has a security association with the DNS
allowing it to perform dynamic DNS update of its FQDN - to bind its server allowing it to perform dynamic DNS update of its FQDN - to
FQDN to the address of a victim, then redirect large volumes of bind its FQDN to the address of a victim, then redirect large
traffic at the victim. The attack may be propagated without the volumes of traffic at the victim. The attack may be propagated
owner's knowledge, for example, if the node is compromised by without the owner's knowledge, for example, if the node is
malware, or it may be intentional if the node itself is the attacker. compromised by malware, or it may be intentional if the node
itself is the attacker.
While it is possible to prevent redirection attacks through ingress While it is possible to prevent redirection attacks through
filtering on access routers, ISPs have little or no incentive to ingress filtering on access routers, ISPs have little or no
deploy ingress filtering. In some cases, if an attack could result in incentive to deploy ingress filtering. In some cases, if an attack
substantial financial gain, it is even possible that a corrupt ISP could result in substantial financial gain, it is even possible
may have an incentive not to deploy ingress filters such as has been that a corrupt ISP may have an incentive not to deploy ingress
the case for spam. Consequently, the security for dynamic Mobile Node filters such as has been the case for spam. Consequently, the
FQDN update has been assigned to the Home Agent, where active network security for dynamic Mobile Node FQDN update has been assigned to
administration and vigilant defense measures are more likely to (but the Home Agent, where active network administration and vigilant
are not assured of) mitigating problems, and the owner of the Mobile defense measures are more likely to (but are not assured of)
Node is more likely to detect a problem if it occurs. mitigating problems, and the owner of the Mobile Node is more
likely to detect a problem if it occurs.
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
Node directly with the DNS server, the Home Agent MUST have a Mobile Node directly with the DNS server, the Home Agent MUST have
security association of some type with the DNS server. The security a security association of some type with the DNS server. The
association MAY be established either using DNSSEC [16] or TSIG/TKEY security association MAY be established either using DNSSEC [16]
[17][18]. A security association is required even if the DNS server or TSIG/TKEY [17][18]. A security association is required even if
is in the same administrative domain as the Home Agent. The security the DNS server is in the same administrative domain as the Home
association SHOULD be separate from the security associations used Agent. The security association SHOULD be separate from the
for other purposes, such as AAA. security associations used 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
Mobility Service Authorizer, the network administrators may want to the Mobility Service Authorizer, the network administrators may
limit the number of cross-administrative domain security want to 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
involved in mobility service authorization is required in any case, signaling involved in mobility service authorization is required
the Home Agent can send the Mobile Node's FQDN to the AAA server in any case, the Home Agent can send the Mobile Node's FQDN to the
under the HA-AAA server security association, and the AAA server can AAA server under the HA-AAA server security association, and the
perform the update. In that case, a security association is required AAA server can perform the update. In that case, a security
between the AAA server and DNS server for the dynamic DNS update. See association is required between the AAA server and DNS server for
draft-ietf-mip6-aaa-ha-goals [12] for a deeper discussion of the Home the dynamic DNS update. See draft-ietf-mip6-aaa-ha-goals [12] for
Agent to AAA server interface. a deeper discussion of the Home Agent to AAA server 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
checked prior to the performance of the update. It is an be checked prior to the performance of the update. It is an
implementation issue as to how authorization is determined. implementation issue as to how authorization is determined.
However, 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 MUST be the same that will be provided by the
MN in the DNS Update Option. This allows the Home Agent to get
authorization information about the Mobile Node's FQDN via the AAA
back end communication performed during IKEv2 exchange. The
outcome of this step will give the Home Agent the necessary
information to authorize the DNS update request of the Mobile
Node. See draft-ietf-mip6-aaa-ha-goals [12] for details about the
communication between the AAA server and the Home Agent needed to
perform the authorization. Notice that if certificates are used in
IKEv2, the authorization information about the FQDN for DNS update
MUST be present in the certificate provided by the Mobile Node.
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 ([2]): DNS-UPDATE-TYPE (section o from "Mobility Option" namespace ([2]): DNS-UPDATE-TYPE
8.1) (section 8.1)
o from "IKEv2 Configuration Payload Attribute Types" namespace o from "IKEv2 Configuration Payload Attribute Types" namespace
([7]): MIP6_HOME_PREFIX attribute (section 8.2) ([7]): MIP6_HOME_PREFIX attribute (section 8.2)
o from "IKEv2 Notify Payload Error Types" namespace ([7]): o from "IKEv2 Notify Payload Error Types" namespace ([7]):
USE_ASSIGNED_HoA error type (section 5.3.2) USE_ASSIGNED_HoA error type (section 5.3.2)
11. Contributors 11. 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 Basavaraj design team of the MIP6 WG. The contributors include Basavaraj
Patil, Alpesh Patel, Jari Arkko, James Kempf, Yoshihiro Ohba, Gopal Patil, Alpesh Patel, Jari Arkko, James Kempf, Yoshihiro Ohba,
Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli,
Chowdury, Julien Bournelle. Kuntal Chowdury, Julien Bournelle.
The design team members can be reached at: The design team members can be reached at:
Gerardo Giaretta gerardo.giaretta@tilab.com Gerardo Giaretta gerardo.giaretta@tilab.com
Basavaraj Patil basavaraj.patil@nokia.com Basavaraj Patil basavaraj.patil@nokia.com
Alpesh Patel alpesh@cisco.com Alpesh Patel alpesh@cisco.com
Jari Arkko jari.arkko@kolumbus.fi Jari Arkko jari.arkko@kolumbus.fi
skipping to change at page 29, line 5 skipping to change at page 29, line 5
Alper Yegin alper.yegin@samsung.com Alper Yegin alper.yegin@samsung.com
Vijay Devarapalli vijayd@iprg.nokia.com Vijay Devarapalli vijayd@iprg.nokia.com
Kuntal Chowdury kchowdury@starentnetworks.com Kuntal Chowdury kchowdury@starentnetworks.com
Junghoon Jee jhjee@etri.re.kr Junghoon Jee jhjee@etri.re.kr
Julien Bournelle julien.bournelle@int-evry.fr Julien Bournelle julien.bournelle@int-evry.fr
12. References 12. Acknowledgments
12.1. Normative References The authors would like to thank Rafa Lopez, Francis Dupont,
Basavaraj Patil, Jari Arkko, Kilian Weniger for their valuable
comments.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 13. References
Levels", BCP 14, RFC 2119, March 1997.
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[3] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to [3] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Protect Mobile IPv6 Signaling between Mobile Nodes and
Home Agents", RFC 3776, June 2004 Home Agents", RFC 3776, June 2004
[4] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", [4] Patel, A., "Problem Statement for bootstrapping Mobile
Internet-Draft draft-ietf-mip6-bootstrap-ps-02, March 2005. IPv6", Internet-Draft draft-ietf-mip6-bootstrap-ps-
03, July 2005.
[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[6] Devarapalli, V., " Mobile IPv6 Operation with IKEv2 and the [6] Devarapalli, V., " Mobile IPv6 Operation with IKEv2 and the
revised IPsec Architecture", Internet-Draft draft-ietf-mip6- revised IPsec Architecture", Internet-Draft draft-ietf-mip6-
ikev2-ipsec-01, February 2005. ikev2-ipsec-03, September 2005.
[7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
12.2. Informative References 13.2. Informative References
[8] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753, [8] Manner, J., Kojo, M. "Mobility Related Terminology", RFC
June 2004. 3753, June 2004.
[9] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC [9] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC
3972, March 2005. 3972, March 2005.
[10] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions for [10] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions
Stateless Address Autoconfiguration in IPv6", Internet-Draft for Stateless Address Autoconfiguration in IPv6", Internet-
draft-ietf-ipv6-privacy-addrs-v2-03, April 2005. Draft draft-ietf-ipv6-privacy-addrs-v2-04, May 2005.
[11] Droms, R., Ed., "DNS Configuration options for Dynamic Host [11] Droms, R., Ed., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
2003. December 2003.
[12] Giaretta, G., Ed. "Goals for AAA-HA interface", Internet-Draft [12] Giaretta, G., Ed. "Goals for AAA-HA interface", Internet-
draft-ietf-mip6-aaa-ha-goals-00, April 2005. Draft draft-ietf-mip6-aaa-ha-goals-00, April 2005.
[13] Koodli, R., Devarapalli, V., Perkins, C., Flinck, H., [13] Koodli, R., Devarapalli, V., Perkins, C., Flinck, H.,
"Solutions for IP Address Location Privacy in the presence of "Solutions for IP Address Location Privacy in the presence
IP Mobility", Internet-Draft, draft-koodli-mip6-location- of IP Mobility", Internet-Draft, draft-koodli-mip6-location-
privacy-solutions-00, February 2005. privacy-solutions-00, February 2005.
[14] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. "Dynamic [14] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound.
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)",
April 1997. RFC 2136, April 1997.
[15] Jang, H.J., Yegin, A., Choi, J., "DHCP Option for Home Agent [15] Chowdhury, K., Yegin, A., Choi, J., "MIP6-bootstrapping via
Discovery in MIPv6", Internet-Draft, draft-jang-dhc-haopt-01, DHCPv6 for the Integrated Scenario", Internet-Draft, draft-
April 2005. ietf-mip6-bootstrapping-integrated-dhc-00, October 2005.
[16] Arends, R., Austein, R., Larson, M., Massey, D., Rose, S., "DNS [16] Arends, R., Austein, R., Larson, M., Massey, D., Rose, S.,
Security Introduction and Requirements", RFC 4033, March 2005. "DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[17] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., Wellington, B., [17] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC B., "Secret Key Transaction Authentication for DNS (TSIG)",
2845, May 2000. RFC 2845, May 2000.
[18] Eastlake 3rd, D., " Secret Key Establishment for DNS (TKEY [18] Eastlake 3rd, D., " Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000. RR)", RFC 2930, September 2000.
[19] Nikander, P., Arkko, J., Aura, T., Montenegro, G., Nordmark, [19] Nikander, P., Arkko, J., Aura, T., Montenegro, G.,
E., "Mobile IP version 6 Route Optimization Security Design Nordmark, E., "Mobile IP version 6 Route Optimization
Background", Internet-Draft, draft-ietf-mip6-ro-sec-02, October Security Design Background", Internet-Draft, draft-ietf-
2004. mip6-ro-sec-02, October 2004.
[20] Narten, T., Nordmark, E., Simpson, W., Soliman, H., "Neighbor [20] Narten, T., Nordmark, E., Simpson, W., Soliman, H.,
Discovery for IP version 6 (IPv6)"`, Internet-Draft, draft- "Neighbor Discovery for IP version 6 (IPv6)"`, Internet-
ietf-ipv6-2461bis-03, May 2005. Draft, draft-ietf-ipv6-2461bis-03, May 2005.
Authors' Addresses Authors' Addresses
Gerardo Giaretta Gerardo Giaretta
Telecom Italia Lab Telecom Italia Lab
via Reiss Romoli 274 via Reiss Romoli 274
10148 Torino 10148 Torino
Italy Italy
Phone: +39 011 228 6904 Phone: +39 011 228 6904
skipping to change at page 32, line 8 skipping to change at page 33, line 8
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: vijay.devarapalli@nokia.com Email: vijay.devarapalli@nokia.com
Intellectual Property Statement Intellectual Property Statement
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
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in this document or the extent to which any license
might or might not be available; nor does it represent that it has under such rights might or might not be available; nor does it
made any independent effort to identify any such rights. Information represent that it has made any independent effort to identify any
on the procedures with respect to rights in RFC documents can be such rights. Information on the procedures with respect to rights
found in BCP 78 and BCP 79. in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of this of 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
http://www.ietf.org/ipr. at 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
copyrights, patents or patent applications, or other proprietary any copyrights, patents or patent applications, or other
rights that may cover technology that may be required to implement proprietary rights that may cover technology that may be required
this standard. Please address the information to the IETF at to implement this standard. Please address the information to the
ietf-ipr@ietf.org IETF at ietf-ipr@ietf.org
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Acknowledgment Acknowledgment
 End of changes. 124 change blocks. 
593 lines changed or deleted 711 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/