idnits 2.17.1 draft-ietf-mip6-bootstrapping-split-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1227. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1233. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 22, 2007) is 6115 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (ref. '5') (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '13') (Obsoleted by RFC 4941) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-04 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-radius-02 == Outdated reference: A later version (-17) exists of draft-ietf-dime-mip6-split-02 -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '20') (Obsoleted by RFC 8945) == Outdated reference: A later version (-18) exists of draft-ietf-mip6-hiopt-05 -- Obsolete informational reference (is this intentional?): RFC 3280 (ref. '23') (Obsoleted by RFC 5280) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group G. Giaretta, Ed. 3 Internet-Draft Qualcomm 4 Intended status: Standards Track J. Kempf 5 Expires: January 23, 2008 DoCoMo Labs USA 6 V. Devarapalli, Ed. 7 Azaire Networks 8 July 22, 2007 10 Mobile IPv6 bootstrapping in split scenario 11 draft-ietf-mip6-bootstrapping-split-07 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 23, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 A Mobile IPv6 node requires a Home Agent address, a home address, and 45 IPsec security associations with its Home Agent before it can start 46 utilizing Mobile IPv6 service. RFC 3775 requires that some or all of 47 these are statically configured. This document defines how a Mobile 48 IPv6 node can bootstrap this information from non-topological 49 information and security credentials pre-configured on the Mobile 50 Node. The solution defined in this document solves the split 51 scenario described in the Mobile IPv6 bootstrapping problem statement 52 in RFC 4640. The split scenario refers the case where the Mobile 53 Node's mobility service is authorized by a different service provider 54 than basic network access. The solution described in this document 55 is also generically applicable to any bootstrapping case, since other 56 scenarios are more specific realizations of the split scenario. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Split scenario . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Components of the solution . . . . . . . . . . . . . . . . . . 7 64 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Home Agent Address Discovery . . . . . . . . . . . . . . . 9 66 5.1.1. DNS lookup by Home Agent Name . . . . . . . . . . . . 10 67 5.1.2. DNS lookup by service name . . . . . . . . . . . . . . 10 68 5.2. IPsec Security Associations setup . . . . . . . . . . . . 11 69 5.3. Home Address assignment . . . . . . . . . . . . . . . . . 11 70 5.3.1. Home Address assignment by the Home Agent . . . . . . 11 71 5.3.2. Home Address auto-configuration by the Mobile Node . . 12 72 5.4. Authorization and Authentication with MSA . . . . . . . . 14 73 6. Home Address registration in the DNS . . . . . . . . . . . . . 14 74 7. Summary of Bootstrapping Protocol Flow . . . . . . . . . . . . 16 75 8. Option and Attribute Format . . . . . . . . . . . . . . . . . 17 76 8.1. DNS Update mobility option . . . . . . . . . . . . . . . . 17 77 8.2. MIP6_HOME_PREFIX attribute . . . . . . . . . . . . . . . . 19 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 9.1. HA Address Discovery . . . . . . . . . . . . . . . . . . . 20 80 9.2. Home Address Assignment through IKEv2 . . . . . . . . . . 22 81 9.3. SA Establishment Using EAP Through IKEv2 . . . . . . . . . 22 82 9.4. Back End Security Between the HA and AAA Server . . . . . 22 83 9.5. Dynamic DNS Update . . . . . . . . . . . . . . . . . . . . 23 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 85 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 88 13.1. Normative References . . . . . . . . . . . . . . . . . . . 25 89 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 91 Intellectual Property and Copyright Statements . . . . . . . . . . 28 93 1. Introduction 95 Mobile IPv6 [1] requires the Mobile Node to know its Home Agent 96 Address, its own Home Address and the cryptographic materials (e.g. 97 shared keys or certificates) needed to set up IPsec security 98 associations with the Home Agent in order to protect Mobile IPv6 99 signaling. This is generally referred to as the Mobile IPv6 100 bootstrapping problem [7]. 102 Mobile IPv6 base protocol does not specify any method to 103 automatically acquire this information, which means that network 104 administrators are normally required to manually set configuration 105 data on Mobile Nodes and HAs. However, in real deployments, manual 106 configuration does not scale as the Mobile Nodes increase in number. 108 As discussed in [7], several bootstrapping scenarios can be 109 identified depending on the relationship between the network operator 110 that authenticates a mobile node for granting network access service 111 (Access Service Authorizer, ASA) and the service provider that 112 authorizes Mobile IPv6 service (Mobility Service Authorizer, MSA). 113 This document describes a solution to the bootstrapping problem that 114 is applicable in a scenario where the MSA and the ASA are different 115 entities (i.e. split scenario). 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [2]. 123 General mobility terminology can be found in [8]. The following 124 additional terms are used here: 126 Access Service Authorizer (ASA) 128 A network operator that authenticates a mobile node and 129 establishes the mobile node's authorization to receive Internet 130 service. 132 Access Service Provider (ASP) 134 A network operator that provides direct IP packet forwarding to 135 and from the end host. 137 Mobility Service Authorizer (MSA) 139 A service provider that authorizes Mobile IPv6 service. 141 Mobility Service Provider (MSP) 143 A service provider that provides Mobile IPv6 service. In order to 144 obtain such service, the mobile node must be authenticated and 145 prove authorization to obtain the service. 147 Split scenario 149 A scenario where mobility service and network access service are 150 authorized by different entities. This implies that MSA is 151 different from ASA. 153 3. Split scenario 155 In the problem statement description [7] there is a clear assumption 156 that mobility service and network access service can be separate. 157 This assumption implies that mobility service and network access 158 service may be authorized by different entities. As an example, the 159 service model defined in [7] allows an enterprise network to deploy a 160 Home Agent and offer Mobile IPv6 service to a user, even if the user 161 is accessing the Internet independent of its enterprise account 162 (e.g., by using his personal WiFi hotspot account at a coffee shop). 164 Therefore, in this document it is assumed that network access and 165 mobility service are authorized by different entities, which means 166 that authentication and authorization for mobility service and 167 network access will be considered separately. This scenario is 168 called split scenario. 170 Moreover, the model defined in [7] separates the entity providing the 171 service from the entity that authenticates and authorizes the user. 172 This is similar to the roaming model for network access. Therefore, 173 in the split scenario, two different cases can be identified 174 depending on the relationship between the entity that provides the 175 mobility service (i.e. Mobility Service Provider, MSP) and the 176 entity that authenticates and authorizes the user (i.e. Mobility 177 Service Authorizer, MSA). 179 Figure 1 depicts the split scenario when the MSP and the MSA are the 180 same entity. This means that the network operator that provides the 181 Home Agent authenticates and authorizes the user for mobility 182 service. 184 Mobility Service 185 Provider and Authorizer 186 +-------------------------------------------+ 187 | | 188 | +-------------+ +--+ | 189 | | MSA/MSP AAA | <-------------> |HA| | 190 | | server | AAA protocol +--+ | 191 | +-------------+ | 192 | | 193 +-------------------------------------------+ 195 +--+ 196 |MN| 197 +--+ 199 Figure 1 -- Split Scenario (MSA == MSP) 201 Figure 2 shows the split scenario in case the MSA and the MSP are two 202 different entities. This might happen if the Mobile Node is far from 203 its MSA network and is assigned a closer HA to optimize performance 204 or if the MSA cannot provide any Home Agent and relies on a third 205 party (i.e. the MSP) to grant mobility service to its users. Notice 206 that the MSP might be or might not also be the network operator that 207 is providing network access (i.e. ASP, Access Service Provider). 209 Mobility Service 210 Authorizer 211 +-------------+ 212 | MSA AAA | 213 | server | 214 +-------------+ 215 ^ 216 | 217 AAA protocol | 218 | Mobility Service 219 | Provider 220 +--------|----------------------------------+ 221 | V | 222 | +-------------+ +--+ | 223 | | MSP AAA | <-------------> |HA| | 224 | | server | AAA protocol +--+ | 225 | +-------------+ | 226 | | 227 +-------------------------------------------+ 229 +--+ 230 |MN| 231 +--+ 233 Figure 2 -- Split Scenario (MSA != MSP) 235 Note that Figure 1 and Figure 2 assume the use of an AAA protocol to 236 authenticate and authorize the Mobile Node for mobility service. 237 However, since IKEv2 allows EAP client authentication only and the 238 server authentication needs to be performed based on certificates or 239 public keys, the Mobile Node potentially requires a certificate 240 revocation list check (CRL check) even though an AAA protocol is used 241 to authenticate and authorize the Mobile Node for mobility service. 243 If, instead, PKI is used, the Mobile Node and HA use certificates to 244 authenticate each other and there is no AAA server involved [9]. 245 This is conceptually similar to Figure 1, since the MSP == MSA, 246 except the Home Agent, and potentially the Mobile Node, may require a 247 certificate revocation list check (CRL check) with the Certification 248 Authority (CA). The CA may be either internal or external to the 249 MSP. Figure 3 illustrates this. 251 Certification 252 Authority 253 +-------------+ 254 | CA | 255 | server | 256 +-------------+ 257 ^ 258 | 259 CRL Check | 260 | Mobility Service 261 | Provider and Authorizer 262 +--------|----------+ 263 | V | 264 | +-------------+ | 265 | | HA | | 266 | | | | 267 | +-------------+ | 268 | | 269 +-------------------+ 271 +--+ 272 |MN| 273 +--+ 275 Figure 3 -- Split Scenario with PKI 277 For more details on the use of PKI for IKEv2 authentication, please 278 refer to [3] and [10]. 280 The split scenario is the simplest model that can be identified, 281 since no assumptions about the access network are made. This implies 282 that the mobility service is bootstrapped independently from the 283 authentication protocol for network access used (e.g. EAP or even 284 open access). For this reason, the solution described in this 285 document and developed for this scenario could also be applied to the 286 integrated access network deployment model [7], even if it might not 287 be optimized. 289 4. Components of the solution 291 The bootstrapping problem is composed of different sub-problems that 292 can be solved independently in a modular way. The components 293 identified and a brief overview of their solution follow. 295 HA address discovery 297 The Mobile Node needs to discover the address of its Home Agent. 298 The main objective of a bootstrapping solution is to minimize the 299 data pre-configured on the Mobile Node. For this reason, the 300 DHAAD defined in [1] may not be applicable in real deployments 301 since it is required that the Mobile Node is pre-configured with 302 the home network prefix and it does not allow an operator to load 303 balance by having Mobile Nodes dynamically assigned to Home Agents 304 located in different subnets. This document defines a solution 305 for Home Agent address discovery that is based on Domain Name 306 Service (DNS), introducing a new DNS SRV record [4]. The unique 307 information that needs to be pre-configured on the Mobile Node is 308 the domain name of the MSP. 310 IPsec Security Associations setup 312 Mobile IPv6 requires that a Mobile Node and its Home Agent share 313 an IPsec SA in order to protect binding updates and other Mobile 314 IPv6 signaling. This document provides a solution that is based 315 on IKEv2 and follows what is specified in [3]. The IKEv2 peer 316 authentication can be performed both using certificates and using 317 EAP, depending on the network operator's deployment model. 319 Home Address (HoA) assignment 321 The Mobile Node needs to know its Home Address in order to 322 bootstrap Mobile IPv6 operation. The Home Address is assigned by 323 the Home Agent during the IKEv2 exchange (as described in [3]). 324 The solution defined in this document also allows the Mobile Node 325 to auto-configure its Home Address based on stateless auto- 326 configuration [11], Cryptographically Generated Addresses [12] or 327 privacy addresses [13]. 329 Authentication and Authorization with MSA 331 The user must be authenticated in order for the MSP to grant the 332 service. Since the user credentials can be verified only by the 333 MSA, this authorization step is performed by the MSA. Moreover, 334 the mobility service must be explicitly authorized by the MSA 335 based on the user's profile. These operations are performed in 336 different ways depending on the credentials used by the Mobile 337 Node during the IKEv2 peer authentication and on the backend 338 infrastructure (PKI or AAA). 340 An optional part of bootstrapping involves providing a way for the 341 Mobile Node to have its FQDN updated in the DNS with a dynamically 342 assigned home address. While not all applications will require this 343 service, many networking applications use the FQDN to obtain an 344 address for a node prior to starting IP traffic with it. The 345 solution defined in this document specifies that the dynamic DNS 346 update is performed by the Home Agent or through the AAA 347 infrastructure, depending on the trust relationship in place. 349 5. Protocol Operations 351 This section describes in detail the procedures needed to perform 352 Mobile IPv6 bootstrapping based on the components identified in the 353 previous section. 355 5.1. Home Agent Address Discovery 357 Once a Mobile Node has obtained network access, it can perform Mobile 358 IPv6 bootstrapping. For this purpose, the Mobile Node queries the 359 DNS server to request information on Home Agent service. As 360 mentioned before in the document, the Mobile Node should be pre- 361 configured with the domain name of the Mobility Service Provider. 363 The Mobile Node needs to obtain the IP address of a DNS server before 364 it can send a DNS request. This can be configured on the Mobile Node 365 or obtained through DHCPv6 from the visited link [14]. In any case, 366 it is assumed that there is some kind of mechanism by which the 367 Mobile Node is configured with a DNS server since a DNS server is 368 needed for many other reasons. 370 Two options for DNS lookup for a Home Agent address are identified in 371 this document: DNS lookup by Home Agent Name and DNS lookup by 372 service name. 374 This document does not provide a specific mechanism to load balance 375 different Mobile Nodes among Home Agents. It is possible for an MSP 376 to achieve coarse-grained load balancing by dynamically updating the 377 SRV RR priorities to reflect the current load on the MSP's collection 378 of Home Agents. Mobile Nodes then use the priority mechanism to 379 preferentially select the least loaded HA. The effectiveness of this 380 technique depends on how much of a load it will place on the DNS 381 servers, particularly if dynamic DNS is used for frequent updates. 383 While this document specifies a Home Agent Address Discovery solution 384 based on DNS, when the ASP and the MSP are the same entity DHCP may 385 be used. See [15] for details. 387 5.1.1. DNS lookup by Home Agent Name 389 In this case, the Mobile Node is configured with the Fully Qualified 390 Domain Name of the Home Agent. As an example, the Mobile Node could 391 be configured with the name "ha1.example.com", where "example.com" is 392 the domain name of the MSP granting the mobility service. 394 The Mobile Node constructs a DNS request, by setting the QNAME to the 395 name of the Home Agent. The request has QTYPE set to 'AAAA', so that 396 the DNS server sends the IPv6 address of the Home Agent. Once the 397 DNS server replies to this query, the Mobile Node knows its Home 398 Agent address and can run IKEv2 in order to set up the IPsec SAs and 399 get a Home Address. 401 Note that the configuration of a home agent FQDN on the mobile node 402 can also be extended to dynamically assign a local home agent from 403 the visited network. Such dynamic assignment would be useful, for 404 instance, from the point of view of improving routing efficiency in 405 bidirectional tunneling mode. Enhancements or conventions for 406 dynamic assignment of local home agents are outside the scope of this 407 specification. 409 5.1.2. DNS lookup by service name 411 RFC 2782 [4] defines the service resource record (SRV RR) that allows 412 an operator to use several servers for a single domain, to move 413 services from host to host, and to designate some hosts as primary 414 servers for a service and others as backups. Clients ask for a 415 specific service/protocol for a specific domain and get back the 416 names of any available servers. 418 RFC 2782 [4] also describes the policies to choose a service agent 419 based on the preference and weight values. The DNS SRV record may 420 contain the preference and weight values for multiple Home Agents 421 available to the Mobile Node in addition to the Home Agent FQDNs. If 422 multiple Home Agents are available in the DNS SRV record then Mobile 423 Node is responsible for processing the information as per policy and 424 for picking one Home Agent. If the Home Agent of choice does not 425 respond to the IKE_SA_INIT messages or if IKEv2 authentication fails, 426 the Mobile Node SHOULD try the next Home Agent on the list. If none 427 of the Home Agents respond, the Mobile Node SHOULD try again after a 428 period of time that is configurable on the Mobile Node. If IKEv2 429 authentication fails with all Home Agents, it is an unrecoverable 430 error on the Mobile Node. 432 The service name for Mobile IPv6 Home Agent service as required by 433 RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a 434 transport name cannot be used here because Mobile IPv6 does not run 435 over a transport protocol. 437 The SRV RR has a DNS type code of 33. As an example, the Mobile 438 constructs a request with QNAME set to "_mip6._ipv6.example.com" and 439 QTYPE to SRV. The reply contains the FQDNs of one or more servers, 440 that can then be resolved in a separate DNS transaction to the IP 441 addresses. However, if there is room in the SRV reply, it is 442 RECOMMENDED that the DNS server also return the IP addresses of the 443 Home Agents in AAAA records as part of the additional data section 444 (in order to avoid requiring an additional DNS round trip to resolve 445 the FQDNs). 447 5.2. IPsec Security Associations setup 449 As soon as the Mobile Node has discovered the Home Agent Address, it 450 establishes an IPsec Security Association with the Home Agent itself 451 through IKEv2. The detailed description of this procedure is 452 provided in [3]. If the Mobile Node wants the HA to register the 453 Home Address in the DNS, it MUST use the FQDN as the initiator 454 identity in IKE_AUTH step of the IKEv2 exchange (IDi). This is 455 needed because the Mobile Node has to prove it is the owner of the 456 FQDN provided in the subsequent DNS Update Option. See section 6 and 457 section 9 for a more detailed analysis on this issue. 459 The IKEv2 Mobile Node to Home Agent authentication can be performed 460 using either IKEv2 public key signatures or the Extensible 461 Authentication Protocol (EAP). The details about how to use IKEv2 462 authentication are described in [3] and [5]. Choice of an IKEv2 peer 463 authentication method depends on the deployment. The Mobile Node 464 should be configured with the information on which IKEv2 465 authentication method to use. However, IKEv2 restricts the Home 466 Agent to Mobile Node authentication to use public key signature-based 467 authentication. 469 5.3. Home Address assignment 471 Home Address assignment is performed during the IKEv2 exchange. The 472 Home Address can be assigned directly by the Home Agent or can be 473 auto-configured by the Mobile Node. 475 5.3.1. Home Address assignment by the Home Agent 477 When the Mobile Node runs IKEv2 with its Home Agent, it can request a 478 HoA through the Configuration Payload in the IKE_AUTH exchange by 479 including an INTERNAL_IP6_ADDRESS attribute. When the Home Agent 480 processes the message, it allocates a HoA and sends it a CFG_REPLY 481 message. The Home Agent could consult a DHCP server on the home link 482 for the actual home address allocation. This is explained in detail 483 in [3]. 485 5.3.2. Home Address auto-configuration by the Mobile Node 487 With the type of assignment described in the previous section, the 488 Home Address cannot be generated based on Cryptographically Generated 489 Addresses (CGAs) [12] or based on the privacy extensions for 490 stateless auto-configuration [13]. However, the Mobile Node might 491 want to have an auto-configured HoA based on these mechanisms. It is 492 worthwhile to mention that the auto-configuration procedure described 493 in this section cannot be used in some possible deployments, since 494 the Home Agents might be provisioned with pools of allowed Home 495 Addresses. 497 In the simplest case, the Mobile Node is provided with a pre- 498 configured home prefix and home prefix length. In this case the 499 Mobile Node creates a Home Address based on the pre-configured prefix 500 and sends it to the Home Agent including an INTERNAL_IP6_ADDRESS 501 attribute in a Configuration Payload of type CFG_REQUEST. If the 502 Home Address is valid, the Home Agent replies with a CFG_REPLY, 503 including an INTERNAL_IP6_ADDRESS with the same address. If the Home 504 Address provided by the Mobile Node is not valid, the Home Agent 505 assigns a different Home Address including an INTERNAL_IP6_ADDRESS 506 attribute with a new value. According to [5] the Mobile Node MUST 507 use the address sent by the Home Agent. Later, if the Mobile Node 508 wants to use an auto-configured Home Address (e.g. based on CGA), it 509 can run Mobile Prefix Discovery, obtain a prefix, auto-configure a 510 new Home Address and then perform a new CREATE_CHILD_SA exchange. 512 If the Mobile Node is not provided with a pre-configured Home Prefix, 513 the Mobile cannot simply propose an auto-configured HoA in the 514 Configuration Payload since the Mobile Node does not know the home 515 prefix before the start of the IKEv2 exchange. The Mobile Node must 516 obtain the home prefix and the home prefix length before it can 517 configure a home address. 519 One simple solution would be for the Mobile Node to just assume that 520 the prefix length on the home link is 64 bits and extract the home 521 prefix from the Home Agent's address. The disadvantage with this 522 solution is that the home prefix cannot be anything other than /64. 523 Moreover, this ties the prefix on the home link and the Home Agent's 524 address, but, in general, a Home Agent with a particular address 525 should be able to serve a number of prefixes on the home link, not 526 just the prefix from which its address is configured. 528 Another solution would be for the Mobile Node to assume that the 529 prefix length on the home link is 64 bits and send its interface 530 identifier to the Home Agent in the INTERNAL_IP6_ADDRESS attribute 531 within the CFG_REQ payload. Even though this approach does not tie 532 the prefix on the home link and the Home Agent's address, it still 533 requires that the home prefix length is 64 bits. 535 For this reason the Mobile Node needs to obtain the home link 536 prefixes through the IKEv2 exchange. In the Configuration Payload 537 during the IKE_AUTH exchange, the Mobile Node includes the 538 MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home 539 Agent, when it processes this message, MUST include in the CFG_REPLY 540 payload prefix information for one prefix on the home link. This 541 prefix information includes the prefix length (see Section 8.2). The 542 Mobile Node auto-configures a Home Address from the prefix returned 543 in the CFG_REPLY message and runs a CREATE_CHILD_SA exchange to 544 create security associations for the new Home Address. 546 As mentioned before in this document, there are deployments where 547 auto-configuration of the Home Address cannot be used. In this case, 548 when the Home Agent receives a CFG_REQUEST including a 549 MIP6_HOME_PREFIX attribute, in the subsequent IKE response it 550 includes a Notify Payload type "USE_ASSIGNED_HoA" and the related 551 Home Address in a INTERNAL_IP6_ADDRESS attribute. If the Mobile Node 552 gets a "USE_ASSIGNED_HoA" Notify Payload in response to the 553 Configuration Payload containing the MIP6_HOME_PREFIX attribute, it 554 looks for an INTERNAL_IP6_ADDRESS attribute and MUST use the address 555 contained in it in the subsequent CREATE_CHILD_SA exchange. 557 When the Home Agent receives a Binding Update for the Mobile Node, it 558 performs proxy DAD for the auto-configured Home Address. If DAD 559 fails, the Home Agent rejects the Binding Update. If the Mobile Node 560 receives a Binding Acknowledgement with status 134 (DAD failed), it 561 MUST stop using the current Home Address, configure a new HoA, and 562 then run IKEv2 CREATE_CHILD_SA exchange to create security 563 associations based on the new HoA. The Mobile Node does not need to 564 run IKE_INIT and IKE_AUTH exchanges again. Once the necessary 565 security associations are created, the Mobile Node sends a Binding 566 Update for the new Home Address. 568 It is worth noting that with this mechanism, the prefix information 569 carried in MIP6_HOME_PREFIX attribute includes only one prefix and 570 does not carry all the information that is typically present when 571 received through a IPv6 router advertisement. Mobile Prefix 572 Discovery, specified in RFC 3775, is the mechanism through which the 573 Mobile Node can get all prefixes on the home link and all related 574 information. That means that MIP6_HOME_PREFIX attribute is only used 575 for Home Address auto-configuration and does not replace the usage of 576 Mobile Prefix Discovery for the purposes detailed in RFC 3775. 578 5.4. Authorization and Authentication with MSA 580 In a scenario where the Home Agent is discovered dynamically by the 581 Mobile Node, it is very likely that the Home Agent is not able to 582 verify by its own the credentials provided by the Mobile Node during 583 the IKEv2 exchange. Moreover, the mobility service needs to be 584 explicitly authorized based on the user's profile. As an example, 585 the Home Agent might not be aware of whether the mobility service can 586 be granted at a particular time of the day or when the credit of the 587 Mobile Node is going to expire. 589 Due to all these reasons, the Home Agent may need to contact the MSA 590 in order to authenticate the Mobile Node and authorize mobility 591 service. This can be accomplished based on a Public Key 592 Infrastructure if certificates are used and a PKI is deployed by the 593 MSP and MSA. On the other hand, if the Mobile Node is provided with 594 other types of credentials, the AAA infrastructure must be used. 596 The definition of this backend communication is out of the scope of 597 this document. In [16] a list of goals for such a communication is 598 provided. [17] and [18] define the RADIUS and Diameter extensions, 599 respectively, for the backend communication. 601 6. Home Address registration in the DNS 603 In order that the Mobile Node is reachable through its dynamically 604 assigned Home Address, the DNS needs to be updated with the new Home 605 Address. Since applications make use of DNS lookups on FQDN to find 606 a node, the DNS update is essential for providing IP reachability to 607 the Mobile Node, which is the main purpose of the Mobile IPv6 608 protocol. The need for DNS updating is not discussed in RFC 3775 609 since it assumes that the Mobile Node is provisioned with a static 610 Home Address. However, when a dynamic Home Address is assigned to 611 the Mobile Node, any existing DNS entry becomes invalid and the 612 Mobile Node becomes unreachable unless a DNS update is performed. 614 Since the DNS update must be performed securely in order to prevent 615 attacks or modifications from malicious nodes, the node performing 616 this update must share a security association with the DNS server. 617 Having all possible Mobile Nodes sharing a security association with 618 the DNS servers of the MSP might be cumbersome from an administrative 619 perspective. Moreover, even if a Mobile Node has a security 620 association with a DNS server of its MSP, an address authorization 621 issue comes into the picture. A detailed analysis of possible 622 threats against DNS update is provided in Section 9.5. 624 Therefore, due to security and administrative reasons, it is 625 RECOMMENDED that the Home Agent perform DNS entry updates for the 626 Mobile Node. For this purpose the Mobile Node MAY include a new 627 mobility option in the Binding Update, the DNS Update option, with 628 the flag R not set in the option. This option is defined in 629 Section 8 and includes the FQDN that needs to be updated. After 630 receiving the Binding Update, the Home Agent MUST update the DNS 631 entry with the identifier provided by the Mobile Node and the Home 632 Address included in the Home Address Option. The procedure for 633 sending a dynamic DNS update message is specified in [6]. The 634 dynamic DNS update SHOULD be performed in a secure way; for this 635 reason, the usage of TKEY and TSEC or DNSSEC is recommended (see 636 Section 9.5 for details). As soon as the Home Agent has updated the 637 DNS, it MUST send a Binding Acknowledgement message to the Mobile 638 Node including the DNS Update mobility option with the correct value 639 in the Status field (see Section 8.1). 641 This procedure can be performed directly by the Home Agent if the 642 Home Agent has a security association with the domain specified in 643 the Mobile Node's FQDN. 645 On the other hand, if the Mobile Node wants to be reachable through a 646 FQDN that belongs to the MSA, the Home Agent and the DNS server that 647 must be updated belong to different administrative domains. In this 648 case the Home Agent may not share a security association with the DNS 649 server and the DNS entry update can be performed by the AAA server of 650 the MSA. In order to accomplish this, the Home Agent sends to the 651 AAA server the FQDN-HoA pair through the AAA protocol. This message 652 is proxied by the AAA infrastructure of the MSP and is received by 653 the AAA server of the MSA. The AAA server of the MSA perform the DNS 654 update based on [6]. Notice that, even in this case, the Home Agent 655 is always required to perform a DNS update for the reverse entry, 656 since this is always performed in the DNS server of the MSP. The 657 detailed description of the communication between Home Agent and AAA 658 is out of the scope of this document. More details are provided in 659 [16]. 661 A mechanism to remove stale DNS entries is needed. A DNS entry 662 becomes stale when the related Home Address is no longer used by the 663 Mobile Node. To remove a DNS entry, the Mobile Node includes in the 664 Binding Update the DNS Update mobility option, with the flag R set in 665 the option. After receiving the Binding Update, the Home Agent MUST 666 remove the DNS entry identified by the FQDN provided by the Mobile 667 Node and the Home Address included in the Home Address Option. The 668 procedure for sending a dynamic DNS update message is specified in 669 [6]. As mentioned above, the dynamic DNS update SHOULD be performed 670 in a secure way; for this reason, the usage of TKEY and TSEC or 671 DNSSEC is recommended (see Section 9.5 for details). 673 If there is no explicit de-registration BU from the Mobile Node, then 674 the HA MAY use the binding cache entry expiration as a trigger to 675 remove the DNS entry. 677 7. Summary of Bootstrapping Protocol Flow 679 The message flow of the whole bootstrapping procedure when the 680 dynamic DNS update is performed by the Home Agent is depicted below. 682 +----+ +----+ +-----+ 683 | MN | | HA | | DNS | 684 +----+ +----+ +-----+ 686 IKEv2 exchange 687 (HoA configuration) 688 <======================> 690 BU (DNS update option) 691 -----------------------> 692 DNS update 693 <-------------------> 694 BA (DNS update option) 695 <----------------------- 697 On the contrary, the figure below shows the message flow of the whole 698 bootstrapping procedure when the dynamic DNS update is performed by 699 the AAA server of the MSA. 701 +----+ +----+ +---+ +---+ 702 | MN | | HA | |AAA| |DNS| 703 +----+ +----+ +---+ +---+ 705 IKEv2 exchange 706 (HoA configuration) 707 <======================> 709 BU (DNS update option) 710 -----------------------> 712 AAA request 713 (FQDN, HoA) 714 <--------------> 716 DNS update 717 <-----------> 718 AAA answer 719 (FQDN, HoA) 720 <--------------> 721 BA (DNS update option) 722 <----------------------- 724 Notice that, even in this last case, the Home Agent is always 725 required to perform a DNS update for the reverse entry, since this is 726 always performed in the DNS server of the MSP. This is not depicted 727 in the figure above. 729 8. Option and Attribute Format 731 8.1. DNS Update mobility option 733 0 1 2 3 734 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 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Option Type | Option Length | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Status |R| Reserved | MN identity (FQDN) ... 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 Option Type 742 DNS-UPDATE-TYPE to be defined by IANA 744 Option Length 746 8-bit unsigned integer indicating the length of the option 747 excluding the type and length fields 749 Status 751 8-bit unsigned integer indicating the result of the dynamic DNS 752 update procedure. This field MUST be set to 0 and ignored by the 753 receiver when the DNS Update mobility option is included in a 754 Binding Update message. When the DNS Update mobility option is 755 included in the Binding Acknowledgement message, values of the 756 Status field less than 128 indicate that the dynamic DNS update 757 was performed successfully by the Home Agent. Values greater than 758 or equal to 128 indicate that the dynamic DNS update was not 759 completed by the HA. The following Status values are currently 760 defined: 762 0 DNS update performed 764 128 Reason unspecified 766 129 Administratively prohibited 768 130 DNS Update Failed 770 R flag 772 If set the Mobile Node is requesting the HA to remove the DNS 773 entry identified by the FQDN specified in this option and the HoA 774 of the Mobile Node. If not set, the Mobile Node is requesting the 775 HA to create or update a DNS entry with its HoA and the FQDN 776 specified in the option 778 Reserved 780 MUST be set to 0 782 MN identity 784 The identity of the Mobile Node in FQDN format to be used by the 785 Home Agent to send a Dynamic DNS update. It is a variable length 786 field 788 8.2. MIP6_HOME_PREFIX attribute 790 The MIP6_HOME_PREFIX attribute is carried in IKEv2 Configuration 791 Payload messages. This attribute is used to convey the home prefix 792 from which the Mobile Node auto-configures its home address. 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 |R| Attribute Type | Length | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Prefix Lifetime | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | | 802 | Home Prefix | 803 | | 804 | | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Prefix Length | 807 +-+-+-+-+-+-+-+-+ 809 Reserved (1 bit) 811 This bit MUST be set to zero and MUST be ignored on receipt 813 Attribute Type (15 bits) 815 A unique identifier for the MIP6_HOME_PREFIX attribute. To be 816 assigned by IANA 818 Length (2 octets) 820 Length in octets of Value field (Home Prefix, Prefix Lifetime and 821 Prefix Length). This can be 0 or 21 823 Prefix Lifetime (4 octets) 825 The lifetime of the Home Prefix 827 Home Prefix (16 octets) 829 The prefix of the home link through which the Mobile Node may 830 auto-configure its Home Address 832 Prefix Length (1 octet) 834 The length in bits of the home prefix specified in the field Home 835 Prefix 837 When the MIP6_HOME_PREFIX attribute is included by the Mobile Node in 838 the CFG_REQUEST payload, the value of the Length field is 0. When 839 the MIP6_HOME_PREFIX attribute is included in the CFG_REPLY payload 840 by the Home Agent, the value of the Length field is 21 and the 841 attribute contains also the home prefix information. 843 9. Security Considerations 845 9.1. HA Address Discovery 847 Use of DNS for address discovery carries certain security risks. DNS 848 transactions in the Internet are typically done without any 849 authentication of the DNS server by the client or of the client by 850 the server. There are two risks involved: 852 1. A legitimate client obtains a bogus Home Agent address from a 853 bogus DNS server. This is sometimes called a "pharming" attack, 855 2. An attacking client obtains a legitimate Home Agent address from 856 a legitimate server. 858 The risk in Case 1 is mitigated because the Mobile Node is required 859 to conduct an IKE transaction with the Home Agent prior to performing 860 a Binding Update to establish Mobile IPv6 service. According to the 861 IKEv2 specification [5], the responder must present the initiator 862 with a valid certificate containing the responder's public key, and 863 the responder to initiator IKE_AUTH message must be protected with an 864 authenticator calculated using the public key in the certificate. 865 Thus, an attacker would have to set up both a bogus DNS server and a 866 bogus Home Agent, and provision the Home Agent with a certificate 867 that a victim Mobile Node could verify. If the Mobile Node can 868 detect that the certificate is not trustworthy, the attack will be 869 foiled when the Mobile Node attempts to set up the IKE SA. 871 The risk in Case 2 is limited for a single Mobile Node to Home Agent 872 transaction if the attacker does not possess proper credentials to 873 authenticate with the Home Agent. The IKE SA establishment will fail 874 when the attacking Mobile Node attempts to authenticate itself with 875 the Home Agent. Regardless of whether the Home Agent utilizes EAP or 876 host-side certificates to authenticate the Mobile Node, the 877 authentication will fail unless the Mobile Node has valid 878 credentials. 880 Another risk exists in Case 2 because the attacker may be attempting 881 to propagate a DoS attack on the Home Agent. In that case, the 882 attacker obtains the Home Agent address from the DNS, then propagates 883 the address to a network of attacking hosts that bombard the Home 884 Agent with traffic. This attack is not unique to the bootstrapping 885 solution, however, it is actually a risk that any Mobile IPv6 Home 886 Agent installation faces. In fact, the risk is faced by any service 887 in the Internet that distributes a unicast globally routable address 888 to clients. Since Mobile IPv6 requires that the Mobile Node 889 communicate through a globally routable unicast address of a Home 890 Agent, it is possible that the Home Agent address could be propagated 891 to an attacker by various means (theft of the Mobile Node, malware 892 installed on the Mobile Node, evil intent of the Mobile Node owner 893 him/herself, etc.) even if the home address is manually configured on 894 the Mobile Node. Consequently, every Mobile IPv6 Home Agent 895 installation will likely be required to mount anti-DoS measures. 896 Such measures include overprovisioning of links to and from Home 897 Agents and of Home Agent processing capacity, vigilant monitoring of 898 traffic on the Home Agent networks to detect when traffic volume 899 increases abnormally indicating a possible DoS attack, and hot spares 900 that can quickly be switched on in the event an attack is mounted on 901 an operating collection of Home Agents. DoS attacks of moderate 902 intensity should be foiled during the IKEv2 transaction. IKEv2 903 implementations are expected to generate their cookies without any 904 saved state, and to time out cookie generation parameters frequently, 905 with the timeout value increasing if a DoS attack is suspected. This 906 should prevent state depletion attacks, and should assure continued 907 service to legitimate clients until the practical limits on the 908 network bandwidth and processing capacity of the Home Agent network 909 are reached. 911 Explicit security measures between the DNS server and host, such 912 DNSSEC [19] or TSIG/TKEY [20] [21] can mitigate the risk of 1) and 913 2), but these security measures are not widely deployed on end nodes. 914 These security measures are not sufficient to protect the Home Agent 915 address against DoS attack, however, because a node having a 916 legitimate security association with the DNS server could 917 nevertheless intentionally or inadvertently cause the Home Agent 918 address to become the target of DoS. 920 Finally notice that assignment of an home agent from the serving 921 network access provider's (local home agent) or a home agent from a 922 nearby network (nearby home agent) may set up the potential to 923 compromise a mobile node's location privacy. A home address anchored 924 at such home agent contains some information about the topological 925 location of the mobile node. Consequently, a mobile node requiring 926 location privacy should not disclose this home address to nodes that 927 are not authorized to learn the mobile node's location, e.g., by 928 updating DNS with the new home address. 930 Security considerations for discovering HA using DHCP are covered in 931 [22]. 933 9.2. Home Address Assignment through IKEv2 935 Mobile IPv6 bootstrapping assigns the home address through the IKEv2 936 transaction. The Mobile Node can either choose to request an 937 address, similar to DHCP, or the Mobile Node can request a prefix on 938 the home link then auto-configure an address. 940 RFC 3775 [1] requires that a Home Agent check authorization of a home 941 address received during a Binding Update. Therefore, the home agent 942 MUST authorize each home address allocation and use. This 943 authorization is based on linking the mobile node identity used in 944 the IKEv2 authentication process and the home address. Home agents 945 MUST implement at least the following two modes of authorization: 947 o Configured home address(es) for each mobile node. In this mode, 948 the home agent or infrastructure nodes behind it know what 949 addresses a specific mobile node is authorized to use. The mobile 950 node is allowed to request these addresses, or if the mobile node 951 requests any home address, these addresses are returned to it. 953 o First-come-first-served (FCFS). In this mode, the home agent 954 maintains a pool of "used" addresses, and allows mobile nodes to 955 request any address, as long as it is not used by another mobile 956 node. 958 Addresses MUST be marked as used for at least as long as the binding 959 exists, and are associated with the identity of the mobile node that 960 made the allocation. 962 In addition, the home agent MUST ensure that the requested address is 963 not the authorized address of any other mobile node, if both FCFS and 964 configured modes use the same address space. 966 9.3. SA Establishment Using EAP Through IKEv2 968 Security considerations for authentication of the IKE transaction 969 using EAP are covered in [3] . 971 9.4. Back End Security Between the HA and AAA Server 973 Some deployments of Mobile IPv6 bootstrapping may use an AAA server 974 to handle authorization for mobility service. This process has its 975 own security requirements, but the back end protocol for Home Agent 976 to AAA server interface is not covered in this draft. Please see 977 [16] for a discussion of this interface. 979 9.5. Dynamic DNS Update 981 If a Home Agent performs dynamic DNS update on behalf of the Mobile 982 Node directly with the DNS server, the Home Agent MUST have a 983 security association of some type with the DNS server. The security 984 association MAY be established either using DNSSEC [19] or TSIG/TKEY 985 [20][21]. A security association is REQUIRED even if the DNS server 986 is in the same administrative domain as the Home Agent. The security 987 association SHOULD be separate from the security associations used 988 for other purposes, such as AAA. 990 In the case where the Mobility Service Provider is different from the 991 Mobility Service Authorizer, the network administrators may want to 992 limit the number of cross-administrative domain security 993 associations. If the Mobile Node's FQDN is in the Mobility Service 994 Authorizer's domain, since a security association for AAA signaling 995 involved in mobility service authorization is required in any case, 996 the Home Agent can send the Mobile Node's FQDN to the AAA server 997 under the HA-AAA server security association, and the AAA server can 998 perform the update. In that case, a security association is required 999 between the AAA server and DNS server for the dynamic DNS update. 1000 See [16] for a deeper discussion of the Home Agent to AAA server 1001 interface. 1003 Regardless of whether the AAA server or Home Agent performs DNS 1004 update, the authorization of the Mobile Node to update a FQDN MUST be 1005 checked prior to the performance of the update. It is an 1006 implementation issue as to how authorization is determined. However, 1007 in order to allow this authorization step, the Mobile Node MUST use a 1008 FQDN as the IDi in IKE_AUTH step of the IKEv2 exchange. The FQDN 1009 MUST be the same as the FQDN that will be provided by the Mobile Node 1010 in the DNS Update Option. 1012 In case EAP over IKEv2 is used to set-up the IPsec SA, the Home Agent 1013 gets authorization information about the Mobile Node's FQDN via the 1014 AAA back end communication performed during IKEv2 exchange. The 1015 outcome of this step will give the Home Agent the necessary 1016 information to authorize the DNS update request of the Mobile Node. 1017 See [16] for details about the communication between the AAA server 1018 and the Home Agent needed to perform the authorization. 1020 In case certificates are used in IKEv2, the authorization information 1021 about the FQDN for DNS update MUST be present in the certificate 1022 provided by the Mobile Node. Since the IKEv2 specification does not 1023 include a required certificate type, it is not possible to specify 1024 precisely how the Mobile Node's FQDN should appear in the 1025 certificate. However, as an example, if the certificate type is 1026 "X.509 Certificate - Signature" (one of the recommended types) then 1027 the FQDN may appear in the subjectAltName attribute extension [23]. 1029 10. IANA Considerations 1031 This document defines a new Mobility Option and a new IKEv2 1032 Configuration Attribute Type. 1034 The following values should be assigned: 1036 o from "Mobility Option" namespace ([1]): DNS-UPDATE-TYPE 1037 (Section 8.1) 1039 o from "IKEv2 Configuration Payload Attribute Types" namespace 1040 ([5]): MIP6_HOME_PREFIX attribute (Section 8.2) 1042 o from "IKEv2 Notify Payload Error Types" namespace ([5]): 1043 USE_ASSIGNED_HoA error type (Section 5.3.2) 1045 11. Contributors 1047 This contribution is a joint effort of the bootstrapping solution 1048 design team of the MIP6 WG. The contributors include Basavaraj 1049 Patil, Alpesh Patel, Jari Arkko, James Kempf, Yoshihiro Ohba, Gopal 1050 Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal 1051 Chowdury, Julien Bournelle. 1053 The design team members can be reached at: 1055 Gerardo Giaretta gerardog@qualcomm.com 1057 Basavaraj Patil basavaraj.patil@nokia.com 1059 Alpesh Patel alpesh@cisco.com 1061 Jari Arkko jari.arkko@kolumbus.fi 1063 James Kempf kempf@docomolabs-usa.com 1065 Yoshihiro Ohba yohba@tari.toshiba.com 1067 Gopal Dommety gdommety@cisco.com 1068 Alper Yegin alper.yegin@samsung.com 1070 Vijay Devarapalli vijay.devarapalli@azairenet.com 1072 Kuntal Chowdury kchowdury@starentnetworks.com 1074 Junghoon Jee jhjee@etri.re.kr 1076 Julien Bournelle julien.bournelle@gmail.com 1078 12. Acknowledgements 1080 The authors would like to thank Rafa Lopez, Francis Dupont, Jari 1081 Arkko, Kilian Weniger, Vidya Narayanan, Ryuji Wakikawa, Michael Ye 1082 for their valuable comments. 1084 13. References 1086 13.1. Normative References 1088 [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1089 IPv6", RFC 3775, June 2004. 1091 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1092 Levels", BCP 14, RFC 2119, March 1997. 1094 [3] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1095 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1096 April 2007. 1098 [4] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1099 specifying the location of services (DNS SRV)", RFC 2782, 1100 February 2000. 1102 [5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1103 RFC 4306, December 2005. 1105 [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic 1106 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1107 April 1997. 1109 13.2. Informative References 1111 [7] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping 1112 Mobile IPv6 (MIPv6)", RFC 4640, September 2006. 1114 [8] Manner, J. and M. Kojo, "Mobility Related Terminology", 1115 RFC 3753, June 2004. 1117 [9] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet 1118 X.509 Public Key Infrastructure Certificate Management Protocol 1119 (CMP)", RFC 4210, September 2005. 1121 [10] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ 1122 ISAKMP, IKEv2, and PKIX", 1123 draft-ietf-pki4ipsec-ikecert-profile-12 (work in progress), 1124 February 2007. 1126 [11] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 1127 draft-ietf-ipv6-2461bis-11 (work in progress), March 2007. 1129 [12] Aura, T., "Cryptographically Generated Addresses (CGA)", 1130 RFC 3972, March 2005. 1132 [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1133 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1135 [14] Droms, R., "DNS Configuration options for Dynamic Host 1136 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1137 December 2003. 1139 [15] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1140 Integrated Scenario", 1141 draft-ietf-mip6-bootstrapping-integrated-dhc-04 (work in 1142 progress), June 2007. 1144 [16] Giaretta, G., "AAA Goals for Mobile IPv6", 1145 draft-ietf-mip6-aaa-ha-goals-03 (work in progress), 1146 September 2006. 1148 [17] Chowdhury, K., "RADIUS Mobile IPv6 Support", 1149 draft-ietf-mip6-radius-02 (work in progress), March 2007. 1151 [18] Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA Support", 1152 draft-ietf-dime-mip6-split-02 (work in progress), May 2007. 1154 [19] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 1155 "DNS Security Introduction and Requirements", RFC 4033, 1156 March 2005. 1158 [20] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, 1159 "Secret Key Transaction Authentication for DNS (TSIG)", 1160 RFC 2845, May 2000. 1162 [21] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", 1163 RFC 2930, September 2000. 1165 [22] Jang, H., "DHCP Option for Home Information Discovery in 1166 MIPv6", draft-ietf-mip6-hiopt-05 (work in progress), June 2007. 1168 [23] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 1169 Public Key Infrastructure Certificate and Certificate 1170 Revocation List (CRL) Profile", RFC 3280, April 2002. 1172 Authors' Addresses 1174 Gerardo Giaretta 1175 Qualcomm 1177 Email: gerardog@qualcomm.com 1179 James Kempf 1180 DoCoMo Labs USA 1181 181 Metro Drive 1182 San Jose, CA 95110 1183 USA 1185 Email: kempf@docomolabs-usa.com 1187 Vijay Devarapalli 1188 Azaire Networks 1189 3121 Jay Street 1190 Santa Clara, CA 95054 1191 USA 1193 Email: vijay.devarapalli@azairenet.com 1195 Full Copyright Statement 1197 Copyright (C) The IETF Trust (2007). 1199 This document is subject to the rights, licenses and restrictions 1200 contained in BCP 78, and except as set forth therein, the authors 1201 retain all their rights. 1203 This document and the information contained herein are provided on an 1204 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1205 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1206 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1207 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1208 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1209 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1211 Intellectual Property 1213 The IETF takes no position regarding the validity or scope of any 1214 Intellectual Property Rights or other rights that might be claimed to 1215 pertain to the implementation or use of the technology described in 1216 this document or the extent to which any license under such rights 1217 might or might not be available; nor does it represent that it has 1218 made any independent effort to identify any such rights. Information 1219 on the procedures with respect to rights in RFC documents can be 1220 found in BCP 78 and BCP 79. 1222 Copies of IPR disclosures made to the IETF Secretariat and any 1223 assurances of licenses to be made available, or the result of an 1224 attempt made to obtain a general license or permission for the use of 1225 such proprietary rights by implementers or users of this 1226 specification can be obtained from the IETF on-line IPR repository at 1227 http://www.ietf.org/ipr. 1229 The IETF invites any interested party to bring to its attention any 1230 copyrights, patents or patent applications, or other proprietary 1231 rights that may cover technology that may be required to implement 1232 this standard. Please address the information to the IETF at 1233 ietf-ipr@ietf.org. 1235 Acknowledgment 1237 Funding for the RFC Editor function is provided by the IETF 1238 Administrative Support Activity (IASA).