From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5026.txt | 1571 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1571 insertions(+) create mode 100644 doc/rfc/rfc5026.txt (limited to 'doc/rfc/rfc5026.txt') 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] + -- cgit v1.2.3