summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5026.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5026.txt')
-rw-r--r--doc/rfc/rfc5026.txt1571
1 files changed, 1571 insertions, 0 deletions
diff --git a/doc/rfc/rfc5026.txt b/doc/rfc/rfc5026.txt
new file mode 100644
index 0000000..345ce37
--- /dev/null
+++ b/doc/rfc/rfc5026.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Network Working Group G. Giaretta, Ed.
+Request for Comments: 5026 Qualcomm
+Category: Standards Track J. Kempf
+ DoCoMo Labs USA
+ V. Devarapalli, Ed.
+ Azaire Networks
+ October 2007
+
+
+ Mobile IPv6 Bootstrapping in Split Scenario
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ A Mobile IPv6 node requires a Home Agent address, a home address, and
+ IPsec security associations with its Home Agent before it can start
+ utilizing Mobile IPv6 service. RFC 3775 requires that some or all of
+ these are statically configured. This document defines how a Mobile
+ IPv6 node can bootstrap this information from non-topological
+ information and security credentials pre-configured on the Mobile
+ Node. The solution defined in this document solves the split
+ scenario described in the Mobile IPv6 bootstrapping problem statement
+ in RFC 4640. The split scenario refers to the case where the Mobile
+ Node's mobility service is authorized by a different service provider
+ than basic network access. The solution described in this document
+ is also generically applicable to any bootstrapping case, since other
+ scenarios are more specific realizations of the split scenario.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 1]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. Split Scenario ..................................................4
+ 4. Components of the Solution ......................................7
+ 5. Protocol Operations .............................................9
+ 5.1. Home Agent Address Discovery ...............................9
+ 5.1.1. DNS Lookup by Home Agent Name ......................10
+ 5.1.2. DNS Lookup by Service Name .........................10
+ 5.2. IPsec Security Associations Setup .........................11
+ 5.3. Home Address Assignment ...................................11
+ 5.3.1. Home Address Assignment by the Home Agent ..........11
+ 5.3.2. Home Address Auto-Configuration by the
+ Mobile Node ........................................12
+ 5.4. Authorization and Authentication with MSA .................14
+ 6. Home Address Registration in the DNS ...........................14
+ 7. Summary of Bootstrapping Protocol Flow .........................16
+ 8. Option and Attribute Format ....................................17
+ 8.1. DNS Update Mobility Option ................................17
+ 8.2. MIP6_HOME_PREFIX Attribute ................................19
+ 9. Security Considerations ........................................20
+ 9.1. HA Address Discovery ......................................20
+ 9.2. Home Address Assignment through IKEv2 .....................22
+ 9.3. SA Establishment Using EAP through IKEv2 ..................22
+ 9.4. Backend Security between the HA and AAA Server ............22
+ 9.5. Dynamic DNS Update ........................................23
+ 10. IANA Considerations ...........................................24
+ 11. Contributors ..................................................24
+ 12. Acknowledgements ..............................................25
+ 13. References ....................................................25
+ 13.1. Normative References .....................................25
+ 13.2. Informative References ...................................26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 2]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+1. Introduction
+
+ Mobile IPv6 [1] requires the Mobile Node to know its Home Agent
+ Address, its own Home Address, and the cryptographic materials (e.g.,
+ shared keys or certificates) needed to set up IPsec security
+ associations with the Home Agent (HA) in order to protect Mobile IPv6
+ signaling. This is generally referred to as the Mobile IPv6
+ bootstrapping problem [7].
+
+ The Mobile IPv6 base protocol does not specify any method to
+ automatically acquire this information, which means that network
+ administrators are normally required to manually set configuration
+ data on Mobile Nodes and HAs. However, in real deployments, manual
+ configuration does not scale as the Mobile Nodes increase in number.
+
+ As discussed in [7], several bootstrapping scenarios can be
+ identified depending on the relationship between the network operator
+ that authenticates a mobile node for granting network access service
+ (Access Service Authorizer, ASA) and the service provider that
+ authorizes Mobile IPv6 service (Mobility Service Authorizer, MSA).
+ This document describes a solution to the bootstrapping problem that
+ is applicable in a scenario where the MSA and the ASA are different
+ entities (i.e., a split scenario).
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [2].
+
+ General mobility terminology can be found in [8]. The following
+ additional terms are used here:
+
+ Access Service Authorizer (ASA)
+
+ A network operator that authenticates a mobile node and
+ establishes the mobile node's authorization to receive Internet
+ service.
+
+ Access Service Provider (ASP)
+
+ A network operator that provides direct IP packet forwarding to
+ and from the end host.
+
+
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 3]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ Mobility Service Authorizer (MSA)
+
+ A service provider that authorizes Mobile IPv6 service.
+
+ Mobility Service Provider (MSP)
+
+ A service provider that provides Mobile IPv6 service. In order to
+ obtain such service, the mobile node must be authenticated and
+ prove authorization to obtain the service.
+
+ Split scenario
+
+ A scenario where mobility service and network access service are
+ authorized by different entities. This implies that MSA is
+ different from ASA.
+
+3. Split Scenario
+
+ In the problem statement description [7], there is a clear assumption
+ that mobility service and network access service can be separate.
+ This assumption implies that mobility service and network access
+ service may be authorized by different entities. As an example, the
+ service model defined in [7] allows an enterprise network to deploy a
+ Home Agent and offer Mobile IPv6 service to a user, even if the user
+ is accessing the Internet independent of its 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
+ mobility service are authorized by different entities, which means
+ that authentication and authorization for mobility service and
+ network access will be considered separately. This scenario is
+ called split scenario.
+
+ Moreover, the model defined in [7] separates the entity providing the
+ service from the entity that authenticates and authorizes the user.
+ This is similar to the roaming model for network access. Therefore,
+ in the split scenario, two different cases can be identified
+ depending on the relationship between the entity that provides the
+ mobility service (i.e., Mobility Service Provider, MSP) and the
+ entity that authenticates and authorizes the user (i.e., Mobility
+ Service Authorizer, MSA).
+
+
+
+
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 4]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ Figure 1 depicts the split scenario when the MSP and the MSA are the
+ same entity. This means that the network operator that provides the
+ Home Agent authenticates and authorizes the user for mobility
+ service.
+
+ Mobility Service
+ Provider and Authorizer
+ +-------------------------------------------+
+ | |
+ | +-------------+ +--+ |
+ | | MSA/MSP AAA | <-------------> |HA| |
+ | | server | AAA protocol +--+ |
+ | +-------------+ |
+ | |
+ +-------------------------------------------+
+
+ +--+
+ |MN|
+ +--+
+
+ Figure 1 -- Split Scenario (MSA == MSP)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 5]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ Figure 2 shows the split scenario in case the MSA and the MSP are two
+ different entities. This might happen if the Mobile Node is far from
+ its MSA network and is assigned a closer HA to optimize performance
+ or if the MSA cannot provide any Home Agent and relies on a third
+ party (i.e., the MSP) to grant mobility service to its users. Notice
+ that the MSP might or might not also be the network operator that is
+ providing network access (i.e., ASP, Access Service Provider).
+
+ Mobility Service
+ Authorizer
+ +-------------+
+ | MSA AAA |
+ | server |
+ +-------------+
+ ^
+ |
+ AAA protocol |
+ | Mobility Service
+ | Provider
+ +--------|----------------------------------+
+ | V |
+ | +-------------+ +--+ |
+ | | MSP AAA | <-------------> |HA| |
+ | | server | AAA protocol +--+ |
+ | +-------------+ |
+ | |
+ +-------------------------------------------+
+
+ +--+
+ |MN|
+ +--+
+
+ Figure 2 -- Split Scenario (MSA != MSP)
+
+ Note that Figure 1 and Figure 2 assume the use of an Authentication,
+ Authorization, and Accounting (AAA) protocol to authenticate and
+ authorize the Mobile Node for mobility service. However, since the
+ Internet Key Exchange Protocol (IKEv2) allows an Extensible
+ Authentication Protocol (EAP) client authentication only and the
+ server authentication needs to be performed based on certificates or
+ public keys, the Mobile Node potentially requires a Certificate
+ Revocation List check (CRL check) even though an AAA protocol is used
+ to authenticate and authorize the Mobile Node for mobility service.
+
+ If, instead, a Public Key Infrastructure (PKI) is used, the Mobile
+ Node and HA use certificates to authenticate each other and there is
+ no AAA server involved [9]. This is conceptually similar to Figure
+ 1, since the MSP == MSA, except the Home Agent, and potentially the
+
+
+
+Giaretta, et al. Standards Track [Page 6]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ Mobile Node, may require a certificate revocation list check (CRL
+ check) with the Certification Authority (CA). The CA may be either
+ internal or external to the MSP. Figure 3 illustrates this.
+
+ Certification
+ Authority
+ +-------------+
+ | CA |
+ | server |
+ +-------------+
+ ^
+ |
+ CRL Check |
+ | Mobility Service
+ | Provider and Authorizer
+ +--------|----------+
+ | V |
+ | +-------------+ |
+ | | HA | |
+ | | | |
+ | +-------------+ |
+ | |
+ +-------------------+
+
+ +--+
+ |MN|
+ +--+
+
+ Figure 3 -- Split Scenario with PKI
+
+ For more details on the use of PKI for IKEv2 authentication, please
+ refer to [3] and [10].
+
+ The split scenario is the simplest model that can be identified,
+ since no assumptions about the access network are made. This implies
+ that the mobility service is bootstrapped independently from the
+ authentication protocol for network access used (e.g., EAP or even
+ open access). For this reason, the solution described in this
+ document and developed for this scenario could also be applied to the
+ integrated access-network deployment model [7], even if it might not
+ be optimized.
+
+4. Components of the Solution
+
+ The bootstrapping problem is composed of different sub-problems that
+ can be solved independently in a modular way. The components are
+ identified and a brief overview of their solution follow.
+
+
+
+
+Giaretta, et al. Standards Track [Page 7]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ HA address discovery
+
+ The Mobile Node needs to discover the address of its Home Agent.
+ The main objective of a bootstrapping solution is to minimize the
+ data pre-configured on the Mobile Node. For this reason, the
+ DHAAD defined in [1] may not be applicable in real deployments
+ since it is required that the Mobile Node is pre-configured with
+ the home network prefix and does not allow an operator to load
+ balance by having Mobile Nodes dynamically assigned to Home Agents
+ located in different subnets. This document defines a solution
+ for Home Agent address discovery that is based on Domain Name
+ Service (DNS), introducing a new DNS SRV record [4]. The unique
+ information that needs to be pre-configured on the Mobile Node is
+ the domain name of the MSP.
+
+ IPsec Security Associations setup
+
+ Mobile IPv6 requires that a Mobile Node and its Home Agent share
+ an IPsec SA in order to protect binding updates and other Mobile
+ IPv6 signaling. This document provides a solution that is based
+ on IKEv2 and follows what is specified in [3]. The IKEv2 peer
+ authentication can be performed both using certificates and using
+ EAP depending on the network operator's deployment model.
+
+ Home Address (HoA) assignment
+
+ The Mobile Node needs to know its Home Address in order to
+ bootstrap Mobile IPv6 operation. The Home Address is assigned by
+ the Home Agent during the IKEv2 exchange (as described in [3]).
+ The solution defined in this document also allows the Mobile Node
+ to auto-configure its Home Address based on stateless auto-
+ configuration [11], Cryptographically Generated Addresses [12], or
+ privacy addresses [13].
+
+ Authentication and Authorization with MSA
+
+ The user must be authenticated in order for the MSP to grant the
+ service. Since the user credentials can be verified only by the
+ MSA, this 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
+ Node during the IKEv2 peer authentication and on the backend
+ infrastructure (PKI or AAA).
+
+ An optional part of bootstrapping involves providing a way for the
+ Mobile Node to have its Fully Qualified Domain Name (FQDN) updated in
+ the DNS with a dynamically assigned home address. While not all
+
+
+
+Giaretta, et al. Standards Track [Page 8]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ applications will require this service, many networking applications
+ use the FQDN to obtain an address for a node prior to starting IP
+ traffic with it. The solution defined in this document specifies
+ that the dynamic DNS update is performed by the Home Agent or through
+ the AAA infrastructure, depending on the trust relationship in place.
+
+5. Protocol Operations
+
+ This section describes in detail the procedures needed to perform
+ Mobile IPv6 bootstrapping based on the components identified in the
+ previous section.
+
+5.1. Home Agent Address Discovery
+
+ Once a Mobile Node has obtained network access, it can perform Mobile
+ IPv6 bootstrapping. For this purpose, the Mobile Node queries the
+ DNS server to request information on Home Agent service. As
+ mentioned before in the document, the Mobile Node should be pre-
+ configured with the domain name of the Mobility Service Provider.
+
+ The Mobile Node needs to obtain the IP address of a DNS server before
+ it can send a DNS request. This can be configured on the Mobile Node
+ or obtained through DHCPv6 from the visited link [14]. In any case,
+ it is assumed that there is some kind of mechanism by which the
+ Mobile Node is configured with a DNS server since a DNS server is
+ needed for many other reasons.
+
+ Two options for DNS lookup for a Home Agent address are identified in
+ this document: DNS lookup by Home Agent Name and DNS lookup by
+ service name.
+
+ This document does not provide a specific mechanism to load balance
+ different Mobile Nodes among Home Agents. It is possible 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.
+
+
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 9]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+5.1.1. DNS Lookup by Home Agent Name
+
+ In this case, the Mobile Node is configured with the Fully Qualified
+ Domain Name of the Home Agent. As an example, the Mobile Node could
+ be configured with the name "ha1.example.com", where "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
+ name of the Home Agent. The request has QTYPE set to "AAAA" so that
+ the DNS server sends the IPv6 address of the Home Agent. Once the
+ DNS server replies to this query, the Mobile Node knows its Home
+ Agent address and can run IKEv2 in order to set up the IPsec SAs and
+ get a Home Address.
+
+ Note that the configuration of a home agent FQDN on the mobile node
+ can also be extended to dynamically assign a local home agent from
+ the visited network. Such dynamic assignment would be useful, for
+ instance, from the point of view of improving routing efficiency in
+ bidirectional tunneling mode. Enhancements or conventions for
+ dynamic assignment of local home agents are outside the scope of this
+ specification.
+
+5.1.2. DNS Lookup by Service Name
+
+ RFC 2782 [4] defines the service resource record (SRV RR) that allows
+ an operator to use several servers for a single domain, to move
+ services from host to host, and to designate some hosts as primary
+ servers for a service and others as backups. Clients ask for a
+ specific service/protocol for a specific domain and get back the
+ names of any available servers.
+
+ RFC 2782 [4] also describes the policies to choose a service agent
+ based on the preference and weight values. The DNS SRV record may
+ contain the preference and weight values for multiple Home Agents
+ available to the Mobile Node in addition to the Home Agent FQDNs. If
+ multiple Home Agents are available in the DNS SRV record, then the
+ Mobile Node is responsible for processing the information as per
+ policy and for picking one Home Agent. If the Home Agent of choice
+ does not respond to the IKE_SA_INIT messages or if IKEv2
+ authentication fails, the Mobile Node SHOULD try the next Home Agent
+ on the list. If none of the Home Agents respond, the Mobile Node
+ SHOULD try again after a period of time that is configurable on the
+ Mobile Node. If IKEv2 authentication fails with all Home Agents, it
+ is an unrecoverable error on the Mobile Node.
+
+ 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
+
+
+
+
+Giaretta, et al. Standards Track [Page 10]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ transport name cannot be used here because Mobile IPv6 does not run
+ over a transport protocol.
+
+ The SRV RR has a DNS type code of 33. As an example, the Mobile
+ constructs a request with QNAME set to "_mip6._ipv6.example.com" and
+ QTYPE to SRV. The reply contains the FQDNs of one or more servers
+ that can then be resolved in a separate DNS transaction to the IP
+ addresses. However, if there is room in the SRV reply, it is
+ RECOMMENDED that the DNS server also return the IP addresses of the
+ Home Agents in AAAA records as part of the additional data section
+ (in order to avoid requiring an additional DNS round trip to resolve
+ the FQDNs).
+
+5.2. IPsec Security Associations Setup
+
+ As soon as the Mobile Node has discovered the Home Agent Address, it
+ establishes an IPsec Security Association with the Home Agent itself
+ through IKEv2. The detailed description of this procedure is
+ provided in [3]. If the Mobile Node wants the HA to register the
+ Home Address in the DNS, it MUST use the FQDN as the initiator
+ identity in the IKE_AUTH step of the IKEv2 exchange (IDi). This is
+ needed because the Mobile Node has to prove it is the owner of the
+ FQDN provided in the subsequent DNS Update Option. See Sections 6
+ and 9 for a more detailed analysis on this issue.
+
+ The IKEv2 Mobile Node to Home Agent authentication can be performed
+ using either IKEv2 public key signatures or the Extensible
+ Authentication Protocol (EAP). The details about how to use IKEv2
+ authentication are described in [3] and [5]. The choice of an IKEv2
+ peer authentication method depends on the deployment. The Mobile
+ Node should be configured with the information on which IKEv2
+ authentication method to use. However, IKEv2 restricts the Home
+ Agent to Mobile Node authentication to use public key signature-based
+ authentication.
+
+5.3. Home Address Assignment
+
+ Home Address assignment is performed during the IKEv2 exchange. The
+ Home Address can be assigned directly by the Home Agent or it can be
+ auto-configured by the Mobile Node.
+
+5.3.1. Home Address Assignment by the Home Agent
+
+ When the Mobile Node runs IKEv2 with its Home Agent, it can request a
+ HoA through the Configuration Payload in the IKE_AUTH exchange by
+ including an INTERNAL_IP6_ADDRESS attribute. When the Home Agent
+ processes the message, it allocates a HoA and sends it a CFG_REPLY
+ message. The Home Agent could consult a DHCP server on the home link
+
+
+
+Giaretta, et al. Standards Track [Page 11]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ for the actual home address allocation. This is explained in detail
+ in [3].
+
+5.3.2. Home Address Auto-Configuration by the Mobile Node
+
+ With the type of assignment described in the previous section, the
+ Home Address cannot be generated based on Cryptographically Generated
+ Addresses (CGAs) [12] or based on the privacy extensions for
+ stateless auto-configuration [13]. However, the Mobile Node might
+ want to have an auto-configured HoA based on these mechanisms. It is
+ worthwhile to mention that the auto-configuration procedure described
+ in this section cannot be used in some possible deployments, 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-
+ configured home prefix and home prefix length. In this case, the
+ Mobile Node creates a Home Address based on the pre-configured prefix
+ and sends it to the Home Agent, including an INTERNAL_IP6_ADDRESS
+ attribute in a Configuration Payload of type CFG_REQUEST. If the
+ Home Address is valid, the Home Agent replies with a CFG_REPLY,
+ including an INTERNAL_IP6_ADDRESS with the same address. If the Home
+ Address provided by the Mobile Node is not valid, the Home Agent
+ assigns a different Home Address including an INTERNAL_IP6_ADDRESS
+ attribute with a new value. According to [5], the Mobile Node MUST
+ use the address sent by the Home Agent. Later, if the Mobile Node
+ wants to use an auto-configured Home Address (e.g., based on CGA), it
+ can run Mobile Prefix Discovery, 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,
+ the Mobile cannot simply propose an auto-configured HoA in the
+ Configuration Payload since the Mobile Node does not know the home
+ prefix before the start of the IKEv2 exchange. The Mobile Node must
+ obtain the home prefix and the home prefix length before it can
+ configure a home address.
+
+ One simple solution would be for the Mobile Node to just assume that
+ the prefix length on the home link is 64 bits and extract the home
+ prefix from the Home Agent's address. The disadvantage with this
+ solution is that the home prefix cannot be anything other than /64.
+ Moreover, this ties the prefix on the home link and the Home Agent's
+ address, but, in general, a Home Agent with a particular address
+ should be able to serve a number of prefixes on 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
+ prefix length on the home link is 64 bits and send its interface
+
+
+
+Giaretta, et al. Standards Track [Page 12]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ identifier to the Home Agent in the INTERNAL_IP6_ADDRESS attribute
+ 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
+ requires that the home prefix length is 64 bits.
+
+ For this reason, the Mobile Node needs to obtain the home link
+ prefixes through the IKEv2 exchange. In the Configuration Payload
+ during the IKE_AUTH exchange, the Mobile Node includes the
+ MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home
+ Agent, when it processes this message, MUST include in the CFG_REPLY
+ payload prefix information for one prefix on the home link. This
+ prefix information includes the prefix length (see Section 8.2). The
+ Mobile Node auto-configures a Home Address from the prefix returned
+ in the CFG_REPLY message and runs a CREATE_CHILD_SA exchange to
+ create security associations for the new Home Address.
+
+ As mentioned before in this document, there are deployments where
+ auto-configuration of the Home Address cannot be used. In this case,
+ when the Home Agent receives a CFG_REQUEST that includes a
+ MIP6_HOME_PREFIX attribute in the subsequent IKE response, it
+ includes a Notify Payload type "USE_ASSIGNED_HoA" and the related
+ Home Address in a INTERNAL_IP6_ADDRESS attribute. If the Mobile Node
+ gets a "USE_ASSIGNED_HoA" Notify Payload in response to the
+ Configuration Payload containing the MIP6_HOME_PREFIX attribute, it
+ looks for an INTERNAL_IP6_ADDRESS attribute and MUST use the address
+ contained in it in the subsequent CREATE_CHILD_SA exchange.
+
+ When the Home Agent receives a Binding Update for the Mobile Node, it
+ performs proxy DAD for the auto-configured Home Address. If DAD
+ fails, the Home Agent rejects the Binding Update. If the Mobile Node
+ receives a Binding Acknowledgement with status 134 (DAD failed), it
+ MUST stop using the current Home Address, configure a new HoA, and
+ then run IKEv2 CREATE_CHILD_SA exchange to create security
+ associations based on the new HoA. The Mobile Node does not need to
+ run IKE_INIT and IKE_AUTH exchanges again. Once the necessary
+ security associations are created, the Mobile Node sends a Binding
+ Update for the new Home Address.
+
+ It is worth noting that with this mechanism, the prefix information
+ carried in MIP6_HOME_PREFIX attribute includes only one prefix and
+ does not carry all the information that is typically present when
+ received through a IPv6 router advertisement. Mobile Prefix
+ Discovery, specified in RFC 3775, is the mechanism through which the
+ Mobile Node can get all prefixes on the home link and all related
+ information. That means that MIP6_HOME_PREFIX attribute is only used
+ for Home Address auto-configuration and does not replace the usage of
+ Mobile Prefix Discovery for the purposes detailed in RFC 3775.
+
+
+
+
+Giaretta, et al. Standards Track [Page 13]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+5.4. Authorization and Authentication with MSA
+
+ In a scenario where the Home Agent is discovered dynamically by the
+ Mobile Node, it is very likely that the Home Agent is not able to
+ verify by its own the credentials provided by the Mobile Node during
+ the IKEv2 exchange. Moreover, the mobility service needs to be
+ explicitly authorized based on the user's profile. As an example,
+ the Home Agent might not be aware of whether the mobility service can
+ be granted at a particular time of the day or when the credit of the
+ Mobile Node is going to expire.
+
+ Due to all these reasons, the Home Agent may need to contact the MSA
+ in order to authenticate the Mobile Node and authorize mobility
+ service. This can be accomplished based on a Public Key
+ Infrastructure if certificates are used and a PKI is deployed by the
+ MSP and MSA. On the other hand, if the Mobile Node is provided with
+ other types of credentials, the AAA infrastructure must be used.
+
+ The definition of this backend communication is out of the scope of
+ this document. In [16], a list of goals for such a communication is
+ provided. [17] and [18] define the RADIUS and Diameter extensions,
+ respectively, for the backend communication.
+
+6. Home Address Registration in the DNS
+
+ In order that the Mobile Node is reachable through its dynamically
+ assigned Home Address, the DNS needs to be updated with the new Home
+ Address. Since applications make use of DNS lookups on FQDN to find
+ a node, the DNS update is essential for providing IP reachability to
+ the Mobile Node, which is the main purpose of the Mobile IPv6
+ protocol. The need for DNS updating is not discussed in RFC 3775
+ since it assumes that the Mobile Node is provisioned with a static
+ Home Address. However, when a dynamic Home Address is assigned to
+ the Mobile Node, any existing DNS entry becomes 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
+ attacks or modifications from malicious nodes, the node performing
+ this update must share a security association with the DNS server.
+ Having all possible Mobile Nodes sharing a security association with
+ the DNS servers of the MSP might be cumbersome from an administrative
+ perspective. Moreover, even if a Mobile Node has a security
+ association with a DNS server of its MSP, an address authorization
+ issue comes into the picture. A detailed analysis of possible
+ threats against DNS update is provided in Section 9.5.
+
+ Therefore, due to security and administrative reasons, it is
+ RECOMMENDED that the Home Agent perform DNS entry updates for the
+
+
+
+Giaretta, et al. Standards Track [Page 14]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ Mobile Node. For this purpose, the Mobile Node MAY include a new
+ mobility option in the Binding Update, the DNS Update option, with
+ the flag R not set in the option. This option is defined in Section
+ 8 and includes the FQDN that needs to be updated. After receiving
+ the Binding Update, the Home Agent MUST update the DNS entry with the
+ identifier provided by the Mobile Node and the Home Address included
+ in the Home Address Option. The procedure for sending a dynamic DNS
+ update message is specified in [6]. The dynamic DNS update SHOULD be
+ performed in a secure way; for this reason, the usage of TKEY and
+ TSEC or DNSSEC is recommended (see Section 9.5 for details). As soon
+ as the Home Agent has updated the DNS, it MUST send a Binding
+ Acknowledgement message to the Mobile Node, including the DNS Update
+ mobility option with the correct value in the Status field (see
+ Section 8.1).
+
+ This procedure can be performed directly by the Home Agent if the
+ Home Agent has a security association with the domain specified in
+ the Mobile Node's FQDN.
+
+ On the other hand, if the Mobile Node wants to be reachable through a
+ FQDN that belongs to the MSA, the Home Agent and the DNS server that
+ must be updated belong to different administrative domains. In this
+ case, the Home Agent may not share a security association with the
+ DNS server and the DNS entry update can be performed by the AAA
+ server of the MSA. In order to accomplish this, the Home Agent sends
+ to the AAA server the FQDN-HoA pair through the AAA protocol. This
+ message is proxied by the AAA infrastructure of the MSP and is
+ received by the AAA server of the MSA. The AAA server of the MSA
+ performs the DNS update based on [6]. Notice that, even in this
+ case, the Home Agent is always required to perform a DNS update for
+ the reverse entry, since this is always performed in the DNS server
+ of the MSP. The detailed description of the communication between
+ Home Agent and AAA is out of the scope of this document. More
+ details are provided in [16].
+
+ A mechanism to remove stale DNS entries is needed. A DNS entry
+ becomes stale when the related Home Address is no longer used by the
+ Mobile Node. To remove a DNS entry, the Mobile Node includes in the
+ Binding Update the DNS Update mobility option, with the flag R set in
+ the option. After receiving the Binding Update, the Home Agent MUST
+ remove the DNS entry identified by the FQDN provided by the Mobile
+ Node and the Home Address included in the Home Address Option. The
+ procedure for sending a dynamic DNS update message is specified in
+ [6]. As mentioned above, the dynamic DNS update SHOULD be performed
+ in a secure way; for this reason, the usage of TKEY and TSEC or
+ DNSSEC is recommended (see Section 9.5 for details).
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 15]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ If there is no explicit de-registration BU from the Mobile Node, then
+ the HA MAY use the binding cache entry expiration as a trigger to
+ remove the DNS entry.
+
+7. Summary of Bootstrapping Protocol Flow
+
+ The message flow of the whole bootstrapping procedure when the
+ dynamic DNS update is performed by the Home Agent is depicted below.
+
+ +----+ +----+ +-----+
+ | MN | | HA | | DNS |
+ +----+ +----+ +-----+
+
+ IKEv2 exchange
+ (HoA configuration)
+ <======================>
+
+ BU (DNS update option)
+ ----------------------->
+ DNS update
+ <------------------->
+ BA (DNS update option)
+ <-----------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 16]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ On the contrary, the figure below shows the message flow of the whole
+ bootstrapping procedure when the dynamic DNS update is performed by
+ the AAA server of the MSA.
+
+ +----+ +----+ +---+ +---+
+ | MN | | HA | |AAA| |DNS|
+ +----+ +----+ +---+ +---+
+
+ IKEv2 exchange
+ (HoA configuration)
+ <======================>
+
+ BU (DNS update option)
+ ----------------------->
+
+ AAA request
+ (FQDN, HoA)
+ <-------------->
+
+ DNS update
+ <----------->
+ AAA answer
+ (FQDN, HoA)
+ <-------------->
+ BA (DNS update option)
+ <-----------------------
+
+ 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 always
+ performed in the DNS server of the MSP. This is not depicted in the
+ figure above.
+
+8. Option and Attribute Format
+
+8.1. DNS Update Mobility Option
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Option Type | Option Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Status |R| Reserved | MN identity (FQDN) ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Option Type
+
+ DNS-UPDATE-TYPE (17)
+
+
+
+
+Giaretta, et al. Standards Track [Page 17]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ Option Length
+
+ 8-bit unsigned integer indicating the length of the option
+ excluding the type and length fields
+
+ Status
+
+ 8-bit unsigned integer indicating the result of the dynamic DNS
+ update procedure. This field MUST be set to 0 and ignored by the
+ receiver when the DNS Update mobility option is included in a
+ Binding Update message. When the DNS Update mobility option is
+ included in the Binding Acknowledgement message, values of the
+ Status field less than 128 indicate that the dynamic DNS update
+ was performed successfully by the Home Agent. Values greater than
+ or equal to 128 indicate that the dynamic DNS update was not
+ completed by the HA. The following Status values are currently
+ defined:
+
+ 0 DNS update performed
+
+ 128 Reason unspecified
+
+ 129 Administratively prohibited
+
+ 130 DNS update failed
+
+ R flag
+
+ If set, the Mobile Node is requesting the HA to remove the DNS
+ entry identified by the FQDN specified in this option and the HoA
+ of the Mobile Node. If not set, the Mobile Node is requesting the
+ HA to create or update a DNS entry with its HoA and the FQDN
+ specified in the option.
+
+ Reserved
+
+ MUST be set to 0.
+
+ MN identity
+
+ The identity of the Mobile Node in FQDN format to be used by the
+ Home Agent to send a Dynamic DNS update. It is a variable length
+ field.
+
+
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 18]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+8.2. MIP6_HOME_PREFIX Attribute
+
+ The MIP6_HOME_PREFIX attribute is carried in IKEv2 Configuration
+ Payload messages. This attribute is used to convey the home prefix
+ from which the Mobile Node auto-configures its home address.
+
+ 0 1 2 3
+ 0 1 2 3 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Prefix Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ | Home Prefix |
+ | |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Prefix Length |
+ +-+-+-+-+-+-+-+-+
+
+ Reserved (1 bit)
+
+ This bit MUST be set to zero and MUST be ignored on receipt.
+
+ Attribute Type (15 bits)
+
+ A unique identifier for the MIP6_HOME_PREFIX attribute (16).
+
+ Length (2 octets)
+
+ Length in octets of Value field (Home Prefix, Prefix Lifetime and
+ Prefix Length). This can be 0 or 21.
+
+ Prefix Lifetime (4 octets)
+
+ The lifetime of the Home Prefix.
+
+ Home Prefix (16 octets)
+
+ The prefix of the home link through which the Mobile Node may
+ auto-configure its Home Address.
+
+ Prefix Length (1 octet)
+
+ The length in bits of the home prefix specified in the field Home
+ Prefix.
+
+
+
+
+Giaretta, et al. Standards Track [Page 19]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ When the MIP6_HOME_PREFIX attribute is included by the Mobile Node in
+ the CFG_REQUEST payload, the value of the Length field is 0. When
+ the MIP6_HOME_PREFIX attribute is included in the CFG_REPLY payload
+ by the Home Agent, the value of the Length field is 21 and the
+ attribute contains also the home prefix information.
+
+9. Security Considerations
+
+9.1. HA Address Discovery
+
+ Use of DNS for address discovery carries certain security risks. DNS
+ transactions in the Internet are typically done without any
+ authentication of the DNS server by the client or of the client by
+ the server. There are two risks involved:
+
+ 1. A legitimate client obtains a bogus Home Agent address from a
+ bogus DNS server. This is sometimes called a "pharming" attack.
+
+ 2. An attacking client obtains a legitimate Home Agent address from
+ a legitimate server.
+
+ The risk in Case 1 is mitigated because the Mobile Node is required
+ to conduct an IKE transaction with the Home Agent prior to performing
+ a Binding Update to establish Mobile IPv6 service. According to the
+ IKEv2 specification [5], the responder must present the initiator
+ with a valid certificate containing the responder's public key, and
+ the responder to initiator IKE_AUTH message must be protected with an
+ authenticator calculated using the public key in the certificate.
+ Thus, an attacker would have to set up both a bogus DNS server and a
+ bogus Home Agent, and provision the Home Agent with a certificate
+ that a victim Mobile Node could verify. If the Mobile Node can
+ detect that the 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
+ transaction if the attacker does not possess proper credentials to
+ authenticate with the Home Agent. The IKE SA establishment will fail
+ when the attacking Mobile Node attempts to authenticate itself with
+ the Home Agent. Regardless of whether the Home Agent utilizes EAP or
+ host-side certificates to authenticate the Mobile Node, the
+ authentication will fail unless the Mobile Node has valid
+ credentials.
+
+ Another risk exists in Case 2 because the attacker may be attempting
+ to propagate a Denial of Service (DoS) attack on the Home Agent. In
+ that case, the attacker obtains the Home Agent address from the DNS,
+ then propagates the address to a network of attacking hosts that
+ bombard the Home Agent with traffic. This attack is not unique to
+
+
+
+Giaretta, et al. Standards Track [Page 20]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ the bootstrapping solution, however, it is actually a risk that any
+ Mobile IPv6 Home Agent installation faces. In fact, the risk is
+ faced by any service in the Internet that distributes a unicast
+ globally routable address to clients. Since Mobile IPv6 requires
+ that the Mobile Node communicate through a globally routable unicast
+ address of a Home Agent, it is possible that the Home Agent address
+ could be propagated to an attacker by various means (theft of the
+ Mobile Node, malware installed on the Mobile Node, evil intent of the
+ Mobile Node owner him/herself, etc.) even if the home address is
+ manually configured on the Mobile Node. Consequently, every Mobile
+ IPv6 Home Agent installation will likely be required to mount anti-
+ DoS measures. Such measures include overprovisioning of links to and
+ from Home Agents and of Home Agent processing capacity, vigilant
+ monitoring of traffic on the Home Agent networks to detect when
+ traffic volume increases 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 intensity should be foiled during the IKEv2 transaction.
+ IKEv2 implementations are expected to generate their cookies without
+ any saved state, and to time out cookie generation parameters
+ frequently, with the timeout value increasing if a DoS attack is
+ suspected. This should prevent state depletion attacks, and should
+ assure continued service to legitimate clients until the practical
+ limits on the network bandwidth and processing capacity of the Home
+ Agent network are reached.
+
+ Explicit security measures between the DNS server and host, such as
+ DNSSEC [19] or TSIG/TKEY [20] [21], can mitigate the risk of 1) and
+ 2), but these security measures are not widely deployed on end nodes.
+ These security measures are not sufficient to protect the Home Agent
+ address against DoS attack, however, because a node having a
+ legitimate security association with the DNS server could
+ nevertheless intentionally or inadvertently cause the Home Agent
+ address to become the target of DoS.
+
+ Finally, notice that the assignment of a home agent from the serving
+ 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 mobile node's location privacy. A home address anchored
+ at such a home agent contains some information about the topological
+ location of the mobile node. Consequently, a mobile node requiring
+ location privacy should not disclose this home address to nodes that
+ are not authorized to learn the mobile node's location, e.g., by
+ updating DNS with the new home address.
+
+ Security considerations for discovering HA using DHCP are covered in
+ [22].
+
+
+
+
+Giaretta, et al. Standards Track [Page 21]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+9.2. Home Address Assignment through IKEv2
+
+ Mobile IPv6 bootstrapping assigns the home address through the IKEv2
+ transaction. The Mobile Node can either choose to request an
+ address, similar to DHCP, or the Mobile Node can request a prefix on
+ the home link, then auto-configure an address.
+
+ RFC 3775 [1] requires that a Home Agent check authorization of a home
+ address received during a Binding Update. Therefore, the home agent
+ MUST authorize each home address allocation and use. This
+ authorization is based on linking the mobile node identity used in
+ the IKEv2 authentication process and the home address. Home agents
+ MUST implement at least the following two modes of authorization:
+
+ o Configured home address(es) for each mobile node. In this mode,
+ the home agent or infrastructure nodes behind it know what
+ addresses a specific mobile node is authorized to use. The mobile
+ node is allowed to request these addresses, or if the mobile node
+ requests any home address, these addresses are returned to it.
+
+ o First-come-first-served (FCFS). In this mode, the home agent
+ maintains a pool of "used" addresses, and allows mobile nodes to
+ request any address, as long as it is not used by another mobile
+ node.
+
+ Addresses MUST be marked as used for at least as long as the binding
+ exists, and are associated with the identity of the mobile node that
+ made the allocation.
+
+ In addition, the home agent MUST ensure that the requested address is
+ not the authorized address of any other mobile node, i.e., if both
+ FCFS and configured modes use the same address space.
+
+9.3. SA Establishment Using EAP through IKEv2
+
+ Security considerations for authentication of the IKE transaction
+ using EAP are covered in [3] .
+
+9.4. Backend Security between the HA and AAA Server
+
+ Some deployments of Mobile IPv6 bootstrapping may use an AAA server
+ to handle authorization for mobility service. This process has its
+ own security requirements, but the backend protocol for a Home Agent
+ to an AAA server interface is not covered in this document. Please
+ see [16] for a discussion of this interface.
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 22]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+9.5. Dynamic DNS Update
+
+ If a Home Agent performs dynamic DNS update on behalf of the Mobile
+ Node directly with the DNS server, the Home Agent MUST have a
+ security association of some type with the DNS server. The security
+ association MAY be established either using DNSSEC [19] or TSIG/TKEY
+ [20][21]. A security association is REQUIRED even if the DNS server
+ is in the same administrative domain as the Home Agent. The security
+ association SHOULD be separate from the security associations used
+ for other purposes, such as AAA.
+
+ In the case where the Mobility Service Provider is different from the
+ Mobility Service Authorizer, the network administrators may want to
+ limit the number of cross-administrative domain security
+ associations. If the Mobile Node's FQDN is in the Mobility Service
+ Authorizer's domain, since a security association for AAA signaling
+ involved in mobility service authorization is required in any case,
+ the Home Agent can send the Mobile Node's FQDN to the AAA server
+ under the HA-AAA server security association, and the AAA server can
+ perform the update. In that case, a security association is required
+ between the AAA server and DNS server for the dynamic DNS update.
+ See [16] for a deeper discussion of the Home Agent to AAA server
+ interface.
+
+ Regardless of whether the AAA server or Home Agent performs DNS
+ update, the authorization of the Mobile Node to update a FQDN MUST be
+ checked prior to the performance of the update. It is an
+ 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 as the FQDN that will be provided by the Mobile Node
+ in the DNS Update Option.
+
+ In case EAP over IKEv2 is used to set-up the IPsec SA, the Home Agent
+ gets authorization information about the Mobile Node's FQDN via the
+ 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 [16] for details about the communication between the AAA server
+ and the Home Agent needed to perform the authorization.
+
+ In case 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. Since the IKEv2 specification does not
+ include a required certificate type, it is not possible to specify
+ precisely how the Mobile Node's FQDN should appear in the
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 23]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ certificate. However, as an example, if the certificate type is
+ "X.509 Certificate - Signature" (one of the recommended types), then
+ the FQDN may appear in the subjectAltName attribute extension [23].
+
+10. IANA Considerations
+
+ This document defines a new Mobility Option and a new IKEv2
+ Configuration Attribute Type.
+
+ The following values have been assigned:
+
+ o from the "Mobility Option" namespace ([1]): DNS-UPDATE-TYPE, 17
+ (Section 8.1)
+
+ o from the "IKEv2 Configuration Payload Attribute Types" namespace
+ ([5]): MIP6_HOME_PREFIX attribute, 16 (Section 8.2)
+
+ o from the "IKEv2 Notify Payload Error Types" namespace ([5]):
+ USE_ASSIGNED_HoA error type, 42 (Section 5.3.2)
+
+ This document creates a new name space "Status Codes (DNS Update
+ Mobility Option)" for the status field in the DNS Update mobility
+ option. The current values are described in Section 8.1 and are
+ listed below.
+
+ 0 DNS update performed
+
+ 128 Reason unspecified
+
+ 129 Administratively prohibited
+
+ 130 DNS update failed
+
+ Future values of the Status field in the DNS Update mobility option
+ can be allocated using Standards Action or IESG approval.
+
+11. Contributors
+
+ This contribution is a joint effort of the bootstrapping solution
+ design team of the MIP6 WG. The contributors include Basavaraj
+ Patil, Alpesh Patel, Jari Arkko, James Kempf, Yoshihiro Ohba, Gopal
+ Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal
+ Chowdury, and Julien Bournelle.
+
+
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 24]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ The design team members can be reached at:
+
+ Gerardo Giaretta, gerardog@qualcomm.com
+
+ Basavaraj Patil, basavaraj.patil@nokia.com
+
+ Alpesh Patel, alpesh@cisco.com
+
+ Jari Arkko, jari.arkko@kolumbus.fi
+
+ James Kempf, kempf@docomolabs-usa.com
+
+ Yoshihiro Ohba, yohba@tari.toshiba.com
+
+ Gopal Dommety, gdommety@cisco.com
+
+ Alper Yegin, alper.yegin@samsung.com
+
+ Vijay Devarapalli, vijay.devarapalli@azairenet.com
+
+ Kuntal Chowdury, kchowdury@starentnetworks.com
+
+ Junghoon Jee, jhjee@etri.re.kr
+
+ Julien Bournelle, julien.bournelle@gmail.com
+
+12. Acknowledgements
+
+ The authors would like to thank Rafa Lopez, Francis Dupont, Jari
+ Arkko, Kilian Weniger, Vidya Narayanan, Ryuji Wakikawa, and Michael
+ Ye for their valuable comments.
+
+13. References
+
+13.1. Normative References
+
+ [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
+ IPv6", RFC 3775, June 2004.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
+ IKEv2 and the Revised IPsec Architecture", RFC 4877, April
+ 2007.
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 25]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ [4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
+ 4306, December 2005.
+
+ [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
+ Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+ April 1997.
+
+13.2. Informative References
+
+ [7] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping
+ Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
+
+ [8] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
+ 3753, June 2004.
+
+ [9] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet
+ X.509 Public Key Infrastructure Certificate Management Protocol
+ (CMP)", RFC 4210, September 2005.
+
+ [10] Korver, B., "The Internet IP Security PKI Profile of
+ IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
+
+ [11] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+ "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+ September 2007.
+
+ [12] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC
+ 3972, March 2005.
+
+ [13] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions
+ for Stateless Address Autoconfiguration in IPv6", RFC 4941,
+ September 2007.
+
+ [14] Droms, R., "DNS Configuration options for Dynamic Host
+ Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
+ 2003.
+
+ [15] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
+ Integrated Scenario", Work in Progress, June 2007.
+
+ [16] Giaretta, G., "AAA Goals for Mobile IPv6", Work in Progress,
+ September 2006.
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 26]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+ [17] Chowdhury, K., "RADIUS Mobile IPv6 Support", Work in Progress,
+ March 2007.
+
+ [18] Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA Support",
+ Work in Progress, May 2007.
+
+ [19] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033, March
+ 2005.
+
+ [20] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
+ "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+ 2845, May 2000.
+
+ [21] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
+ 2930, September 2000.
+
+ [22] Jang, H., "DHCP Option for Home Information Discovery in
+ MIPv6", Work in Progress, June 2007.
+
+ [23] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
+ Public Key Infrastructure Certificate and Certificate
+ Revocation List (CRL) Profile", RFC 3280, April 2002.
+
+Authors' Addresses
+
+ Gerardo Giaretta
+ Qualcomm
+
+ EMail: gerardog@qualcomm.com
+
+
+ James Kempf
+ DoCoMo Labs USA
+ 181 Metro Drive
+ San Jose, CA 95110
+ USA
+
+ EMail: kempf@docomolabs-usa.com
+
+
+ Vijay Devarapalli
+ Azaire Networks
+ 3121 Jay Street
+ Santa Clara, CA 95054
+ USA
+
+ EMail: vijay.devarapalli@azairenet.com
+
+
+
+Giaretta, et al. Standards Track [Page 27]
+
+RFC 5026 MIP6 Bootstrapping in Split Scenario October 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Giaretta, et al. Standards Track [Page 28]
+