idnits 2.17.00 (12 Aug 2021) /tmp/idnits14136/draft-ietf-mip6-bootstrapping-split-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1232. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1253), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 33 longer pages, the longest (page 1) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 260 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 377 has weird spacing: '...olution based...' == Line 434 has weird spacing: '... run over...' == Line 1077 has weird spacing: '...iaretta gerar...' == Line 1079 has weird spacing: '...j Patil basa...' == Line 1087 has weird spacing: '...ro Ohba yoh...' == (2 more instances...) -- 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 (October 21, 2005) is 6055 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) == Unused Reference: '13' is defined on line 1154, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-mip6-bootstrap-ps has been published as RFC 4640 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-bootstrap-ps (ref. '4') == Outdated reference: draft-ietf-mip6-ikev2-ipsec has been published as RFC 4877 -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: draft-ietf-ipv6-privacy-addrs-v2 has been published as RFC 4941 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-00 -- No information found for draft-koodli-mip6-location-privacy-solutions - is the name correct? == Outdated reference: draft-ietf-mip6-bootstrapping-integrated-dhc has been published as RFC 6611 -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '17') (Obsoleted by RFC 8945) == Outdated reference: draft-ietf-mip6-ro-sec has been published as RFC 4225 == Outdated reference: draft-ietf-ipv6-2461bis has been published as RFC 4861 Summary: 8 errors (**), 0 flaws (~~), 17 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 WG G. Giaretta, Editor 3 Internet Draft Tilab 4 Expires: April 21, 2006 J. Kempf 5 DoCoMo Labs USA 6 V. Devarapalli 7 Nokia 8 October 21, 2005 10 Mobile IPv6 bootstrapping in split scenario 11 draft-ietf-mip6-bootstrapping-split-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that 16 any applicable patent or other IPR claims of which he or she is 17 aware have been or will be disclosed, and any of which he or she 18 becomes aware will be disclosed, in accordance with Section 6 of 19 BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on April 21, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). All Rights Reserved. 44 Abstract 46 A Mobile IPv6 node requires a Home Agent address, a home address, 47 and IPsec security associations with its Home Agent before it can 48 start utilizing Mobile IPv6 service. RFC 3775 requires that some 49 or all of these are statically configured. This document defines 50 how a Mobile IPv6 node can bootstrap this information from non- 51 topological information and security credentials preconfigured on 52 the Mobile Node. The solution defined in this document solves the 53 bootstrapping problem from draft-ietf-mip6-bootstrapping-ps-02 54 when the Mobile Node's mobility service is authorized by a 55 different service provider than basic network access, and is 56 therefore generically applicable to any bootstrapping case. 58 Conventions used in this document 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 61 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 62 in this document are to be interpreted as described in RFC-2119 63 [1]. 65 Table of Contents 67 1. Introduction...................................................4 68 2. Terminology....................................................5 69 3. Split scenario.................................................6 70 4. Components of the solution.....................................9 71 5. Protocol Operations...........................................11 72 5.1. Home Agent Address Discovery.............................11 73 5.1.1. DNS lookup by Home Agent Name.......................11 74 5.1.2. DNS lookup by service name..........................12 75 5.2. IPsec Security Associations setup........................13 76 5.3. Home Address assignment..................................13 77 5.3.1. Home Address assignment by the Home Agent...........13 78 5.3.2. Home Address auto-configuration by the Mobile Node..13 79 5.4. Authorization and Authentication with MSA................15 80 6. Home Address registration in the DNS..........................17 81 7. Summary of Bootstrapping Protocol Flow........................19 82 8. Option and Attribute Format...................................21 83 8.1. DNS Update mobility option...............................21 84 8.2. MIP6_HOME_PREFIX attribute...............................22 85 9. Security Considerations.......................................23 86 9.1. HA Address Discovery.....................................23 87 9.2. Home Address Assignment through IKEv2....................24 88 9.3. SA Establishment Using EAP Through IKEv2.................25 89 9.4. Back End Security Between the HA and AAA Server..........25 90 9.5. Dynamic DNS Update.......................................25 91 10. IANA Considerations..........................................27 92 11. Contributors.................................................28 93 12. Acknowledgments..............................................29 94 13. References...................................................30 95 13.1. Normative References....................................30 96 13.2. Informative References..................................30 97 Authors' Addresses...............................................32 98 Intellectual Property Statement..................................33 99 Disclaimer of Validity...........................................33 100 Copyright Statement..............................................33 101 Acknowledgment...................................................33 103 1. Introduction 105 Mobile IPv6 [2] requires the Mobile Node to know its Home Agent 106 Address, its own Home Address and the cryptographic materials 107 (e.g. shared keys or certificates) needed to set-up IPsec security 108 associations with the Home Agent in order to protect MIPv6 109 signaling. This is generally referred to as the Mobile IPv6 110 bootstrapping problem [4]. 112 Mobile IPv6 base protocol does not specify any method to 113 automatically acquire this information, which means that network 114 administrators are normally required to manually set configuration 115 data on MNs and HAs. However, in real deployments, manual 116 configuration does not scale as the Mobile Nodes increase in 117 number. 119 As discussed in [4], several bootstrapping scenarios can be 120 identified depending on the relationship between the network 121 operator that authenticates a mobile host for granting network 122 access service (Access Service Authorizer, ASA) and the service 123 provider that authorizes Mobile IPv6 service (Mobility Service 124 Authorizer, MSA). This document describes a solution to the 125 bootstrapping problem that is applicable in a scenario where the 126 MSA and the ASA are different entities (i.e. split scenario). 128 2. Terminology 130 General mobility terminology can be found in [8]. The following 131 additional terms are used here: 133 ASA 134 Access Service Authorizer. A network operator that 135 authenticates a mobile host and establishes the mobile host's 136 authorization to receive Internet service. 138 ASP 139 Access Service Provider. A network operator that provides 140 direct IP packet forwarding to and from the end host. 142 MSA 143 Mobility Service Authorizer. A service provider that 144 authorizes Mobile IPv6 service. 146 MSP 147 Mobility Service Provider. A service provider that provides 148 Mobile IPv6 service. In order to obtain such service, the 149 mobile host must be authenticated and prove authorization to 150 obtain the service. 152 Split scenario 153 A scenario where mobility service and network access service 154 are authorized by different entities. This implies that MSA is 155 different from ASA. 157 3. Split scenario 159 In the problem statement draft [4] there is a clear assumption 160 that mobility service and network access service can be separate. 161 This assumption implies that mobility service and network access 162 service may be authorized by different entities. As an example, 163 the service model defined in [4] allows an enterprise network to 164 deploy a Home Agent and offer Mobile IPv6 service to a user, even 165 if the user is accessing the Internet independent of its 166 enterprise account (e.g., by using his personal WiFi hotspot 167 account at a coffee shop). 169 Therefore, in this document it is assumed that network access and 170 mobility service are authorized by different entities, which means 171 that authentication and authorization for mobility service and 172 network access will be considered separately. This scenario is 173 called split scenario. 175 Moreover, the model defined in [4] separates the entity providing 176 the service from the entity that authenticates and authorizes the 177 user. This is similar to the roaming model for network access. 178 Therefore, in the split scenario, two different cases can be 179 identified depending on the relationship between the entity that 180 provides the mobility service (i.e. Mobility Service Provider, 181 MSP) and the entity that authenticates and authorizes the user 182 (i.e. Mobility Service Authorizer, MSA). 184 Figure 1 depicts the split scenario when the MSP and the MSA are 185 the same entity. This means that the network operator that 186 provides the Home Agent authenticates and authorizes the user for 187 mobility service. 189 Mobility Service 190 Provider and Authorizer 191 +-------------------------------------------+ 192 | | 193 | +-------------+ +--+ | 194 | | MSA/MSP AAA | <-------------> |HA| | 195 | | server | AAA protocol +--+ | 196 | +-------------+ | 197 | | 198 +-------------------------------------------+ 200 +--+ 201 |MN| 202 +--+ 204 Figure 1 - Split Scenario (MSA == MSP) 206 Figure 2 shows the split scenario in case the MSA and the MSP are 207 two different entities. This might happen if the Mobile Node is 208 far from its MSA network and is assigned a closer HA to optimize 209 performance or if the MSA cannot provide any Home Agent and relies 210 on a third party (i.e. the MSP) to grant mobility service to its 211 users. Notice that the MSP might be or might not be also the 212 network operator that is providing network access (i.e. ASP, 213 Access Service Provider). 215 Mobility Service 216 Authorizer 217 +-------------+ 218 | MSA AAA | 219 | server | 220 +-------------+ 221 ^ 222 | 223 AAA protocol | 224 | Mobility Service 225 | Provider 226 +--------|----------------------------------+ 227 | V | 228 | +-------------+ +--+ | 229 | | MSP AAA | <-------------> |HA| | 230 | | server | AAA protocol +--+ | 231 | +-------------+ | 232 | | 233 +-------------------------------------------+ 235 +--+ 236 |MN| 237 +--+ 239 Figure 2 - Split Scenario (MSA != MSP) 241 Note that Figure 1 and Figure 2 assume the use of an AAA protocol 242 to authenticate and authorize the MN for mobility service. If, 243 instead, a PKI is used, the MN and HA exchange certificates and 244 there is no AAA server involved. This is conceptually similar to 245 Figure 1, since the MSP == MSA, except the HA may require a 246 certificate revocation list check (CRL check) with the Certificate 247 Authority (CA). The CA may be either internal or external to the 248 MSP. Figure 3 illustrates. 250 Certificate 251 Authority 252 +-------------+ 253 | CA | 254 | server | 255 +-------------+ 256 ^ 257 | 258 CRL Check | 259 | Mobility Service 260 | Provider and Authorizer 261 +--------|----------+ 262 | V | 263 | +-------------+ | 264 | | HA | | 265 | | | | 266 | +-------------+ | 267 | | 268 +-------------------+ 270 +--+ 271 |MN| 272 +--+ 274 Figure 3 - Split Scenario with PKI 276 The split scenario is the simplest model that can be identified, 277 since no assumptions about the access network are made. This 278 implies that the mobility service is bootstrapped independently 279 from the authentication protocol for network access used (e.g. 280 PANA, EAP). For this reason, the solution described in this 281 document and developed for this scenario could also be applied to 282 the integrated access network deployment model [4], even if it 283 might not be optimized. 285 4. Components of the solution 287 The bootstrapping problem is composed of different sub-problems 288 that can be solved independently in a modular way. The components 289 identified and a brief overview of their solution follow. 291 o HA address discovery. The Mobile Node needs to discover the 292 address of its Home Agent. The main objective of a 293 bootstrapping solution is to minimize the data pre-configured 294 on the Mobile Node. For this reason, the DHAAD defined in [2] 295 may not be applicable in real deployments since it is required 296 that the Mobile Node is pre-configured with the home network 297 prefix and it does not allow an operator to load balance by 298 having Mobile Nodes dynamically assigned to Home Agents located 299 in different subnets. This document defines a solution for Home 300 Agent address discovery that is based on Domain Name Service 301 (DNS), introducing a new DNS SRV record [5]. The unique 302 information that needs to be pre-configured on the Mobile Node 303 is the domain name of the MSP. 305 o IPsec Security Associations setup. MIPv6 requires that a Mobile 306 Node and its Home Agent share an IPsec SA in order to protect 307 binding updates and other MIPv6 signaling. This document 308 provides a solution that is based on IKEv2 and follows what is 309 specified in [6]. The IKEv2 peer authentication can be 310 performed both using certificates and using EAP, depending on 311 the network operator's deployment model. 313 o HoA assignment. The Mobile Node needs to know its Home Address 314 in order to bootstrap Mobile IPv6 operation. The Home Address 315 is assigned by the Home Agent during the IKEv2 exchange (as 316 described in [6]). The solution defined in this draft also 317 allows the Mobile Node to auto-configure its Home Address based 318 on stateless auto-configuration ([20]), Cryptographically 319 Generated Addresses ([9]) or privacy addresses ([10]). 321 o Authentication and Authorization with MSA. The user must be 322 authenticated in order for the MSP to grant the service. Since 323 the user credentials can be verified only by the MSA, this 324 authorization step is performed by the MSA. Moreover, the 325 mobility service must be explicitly authorized by the MSA based 326 on the user's profile. These operations are performed in 327 different ways depending on the credentials used by the Mobile 328 Node during the IKEv2 peer authentication and on the backend 329 infrastructure (PKI or AAA). 331 An optional part of bootstrapping involves providing a way for the 332 Mobile Node to have its FQDN updated in the DNS with a dynamically 333 assigned home address. While not all applications will require 334 this service, many networking applications use the FQDN to obtain 335 an address for a node prior to starting IP traffic with it. The 336 solution defined in this document specifies that the dynamic DNS 337 update is performed by the Home Agent or through the AAA 338 infrastructure, depending on the trust relationship in place. 340 5. Protocol Operations 342 This section describes in detail the procedures needed to perform 343 Mobile IPv6 bootstrapping based on the components identified in 344 the previous section. 346 5.1. Home Agent Address Discovery 348 Once a Mobile Node has obtained network access, it can perform 349 Mobile IPv6 bootstrapping. For this purpose, the Mobile Node 350 queries the DNS server to request information on Home Agent 351 service. As mentioned before in the document, the only information 352 that needs to be pre-configured on the Mobile Node is the domain 353 name of the Mobility Service Provider. 355 The Mobile Node needs to obtain the IP address of the DNS server 356 before it can send a DNS request. This can be pre-configured on 357 the Mobile Node or obtained through DHCPv6 from the visited link 358 [11]. In any case, it is assumed that there is some kind of 359 mechanism by which the Mobile Node is configured with a DNS server 360 since a DNS server is needed for many other reasons. 362 Two options for DNS lookup for a Home Agent address are identified 363 in this document: DNS lookup by Home Agent Name and DNS lookup by 364 service name. 366 This document does not provide a specific mechanism to load 367 balance different Mobile Nodes among Home Agents. It is possible 368 for an MSP to achieve coarse-grained load balancing by dynamically 369 updating the SRV RR priorities to reflect the current load on the 370 MSP's collection of Home Agents. Mobile Nodes then use the 371 priority mechanism to preferentially select the least loaded HA. 372 The effectiveness of this technique depends on how much of a load 373 it will place on the DNS servers, particularly if dynamic DNS is 374 used for frequent updates. 376 While this document specifies a Home Agent Address Discovery 377 solution based on DNS, when the ASP and the MSP are the same 378 entity DHCP may be used. See [15] for details. 380 5.1.1. DNS lookup by Home Agent Name 382 In this case, the Mobile Node is configured with the Fully 383 Qualified Domain Name of the Home Agent. As an example, the Mobile 384 Node could be configured with the name "ha1.example.com", where 385 "example.com" is the domain name of the MSP granting the mobility 386 service. 388 The Mobile Node constructs a DNS request, by setting the QNAME to 389 the name of the Home Agent. The request has QTYPE set to 'AAAA', 390 so that the DNS server sends the IPv6 address of the Home Agent. 391 Once the DNS server replies to this query, the Mobile Node knows 392 its Home Agent address and can run IKEv2 in order to set up the 393 IPsec SAs and get a Home Address. 395 Additionally, the ability to provide a mobile node with a 396 localized home agent (e.g. on the visited link) can help to 397 optimize handover signaling and improve routing efficiency in bi- 398 directional tunneling mode. There are a variety of ways this can 399 be achieved in an interoperable way. One way is to provision the 400 mobile node with an FQDN for a local home agent when it configures 401 for the local link. Another way is to specify an interoperable 402 naming convention for constructing home agent FQDNs based on 403 location. For example, an operator might assign the FQDN 404 "ha.locationA.operator.com" to the Home Agent located in "location 405 A" and the FQDN "ha.locationB.operator.com" to the Home Agent 406 located in "location B". If the Mobile Node wants to use a Home 407 Agent located in "location A", it will set the QNAME to 408 "ha.locationA.operator.com" in the DNS request. The exact way in 409 which localized Home Agents are configured is out of scope for 410 this draft. 412 5.1.2. DNS lookup by service name 414 RFC 2782 [5] defines the service resource record (SRV RR), that 415 allows an operator to use several servers for a single domain, to 416 move services from host to host, and to designate some hosts as 417 primary servers for a service and others as backups. Clients ask 418 for a specific service/protocol for a specific domain and get back 419 the names of any available servers. 421 RFC 2782[5] describes also the policies to choose a service agent 422 based on the preference and weight values. The DNS SRV record may 423 contain the preference and weight values for multiple Home Agents 424 available to the Mobile Node in addition to the Home Agent FQDNs. 425 If multiple Home Agents are available in the DNS SRV record then 426 Mobile Node is responsible for processing the information as per 427 policy and for picking one Home Agent. If the Home Agent of choice 428 does not respond for some reason or the IKEv2 authentication 429 fails, the Mobile Node SHOULD try other Home Agents on the list. 431 The service name for Mobile IPv6 Home Agent service as required by 432 RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a 433 transport name cannot be used here because Mobile IPv6 does not 434 run over a transport protocol. 436 The SRV RR has a DNS type code of 33. As an example, the Mobile 437 constructs a request with QNAME set to "_mip6_ipv6.example.com" 438 and QTYPE to SRV. The reply contains the FQDNs of one or more 439 servers, that can then be resolved in a separate DNS transaction 440 to the IP addresses. However, it is RECOMMENDED that the DNS 441 server also return the IP addresses of the Home Agents in AAAA 442 records as part of the additional data section in order to avoid 443 requiring an additional DNS round trip to resolve the FQDNs, if 444 there is room in the SRV reply. 446 5.2. IPsec Security Associations setup 448 As soon as the Mobile Node has discovered the Home Agent Address, 449 it establishes an IPsec Security Association with the Home Agent 450 itself through IKEv2. The detailed description of this procedure 451 is provided in [6]. If the Mobile Node wants the HA to register 452 the Home Address in the DNS, it MUST use the FQDN as the initiator 453 identity in IKE_AUTH step of the IKEv2 exchange (IDi). This is 454 needed because the Mobile Node has to provide it is the owner of 455 the FQDN provided in the subsequent DNS Update Option. See section 456 6 and section 9 for a more detailed analysis on this issue. 458 The IKEv2 Mobile Node to Home Agent authentication can be 459 performed using either IKEv2 public key signatures or the 460 Extensible Authentication Protocol (EAP). The details about how 461 IKEv2 authentication is done are described in [6] and [7]. Choice 462 of an IKEv2 peer authentication method depends on the deployment. 463 However, IKEv2 restricts the Home Agent to Mobile Node 464 authentication to use public key signature based authentication. 466 5.3. Home Address assignment 468 Home Address assignment is performed during the IKEv2 exchange. 469 The Home Address can be assigned directly by the Home Agent or can 470 be auto-configured by the Mobile Node. 472 5.3.1. Home Address assignment by the Home Agent 474 When the Mobile Node runs IKEv2 with its Home Agent, it can 475 request a HoA through the Configuration Payload in the IKE_AUTH 476 exchange by including an INTERNAL_IP6_ADDRESS attribute. When the 477 Home Agent processes the message, it allocates a HoA and sends it 478 a CFG_REPLY message. The Home Agent could consult a DHCP server on 479 the home link for the actual home address allocation. This is 480 explained in detail in [6]. 482 5.3.2. Home Address auto-configuration by the Mobile Node 484 With the type of assignment described in the previous section, the 485 Home Address cannot be generated based on Cryptographically 486 Generated Addresses (CGAs) [9] or based on the privacy extensions 487 for stateless autoconfiguration [10]. However, the Mobile Node 488 might want to have an auto-configured HoA based on these 489 mechanisms. It is worthwhile to mention that the auto- 490 configuration procedure described in this section cannot be used 491 in some possible deployment, since the Home Agents might be 492 provisioned with pools of allowed Home Addresses. 494 In the simplest case, the Mobile Node is provided with a pre- 495 configured home prefix and home prefix length. In this case the 496 Mobile Node creates a Home Address based on the pre-configured 497 prefix and sends it to the Home Agent including an 498 INTERNAL_IP6_ADDRESS attribute in a Configuration Payload of type 499 CFG_REQUEST. If the Home Address is valid, the Home Agent replies 500 with a CFG_REPLY, including an INTERNAL_IP6_ADDRESS with the same 501 address. If the Home Address provided by the Mobile Node is not 502 valid, the Home Agent assigns a different Home Address including 503 an INTERNAL_IP6_ADDRESS attribute with a new value. According to 504 [7] the Mobile Node MUST use the address sent by the Home Agent. 505 Later, if the Mobile Node wants to use an auto-configured Home 506 Address (e.g. based on CGA), it can run Mobile Prefix Discovery, 507 obtain a prefix, auto-configure a new Home Address and then 508 perform a new CREATE_CHILD_SA exchange. 510 If the Mobile Node is not provided with a pre-configured Home 511 Prefix, the Mobile cannot simply propose an auto-configured HoA in 512 the Configuration Payload since the Mobile Node does not know the 513 home prefix before the start of the IKEv2 exchange. The Mobile 514 Node must obtain the home prefix and the home prefix length before 515 it can configure a home address. 517 One simple solution would be for the Mobile Node to just assume 518 that the prefix length on the home link is 64 bits and extract the 519 home prefix from the Home Agent's address. The disadvantage with 520 this solution is that the home prefix cannot be anything other 521 than /64. Moreover, this ties the prefix on the home link and the 522 Home Agent's address, but, in general, a Home Agent with a 523 particular address should be able to serve a number of prefixes on 524 the home link, not just the prefix from which its address is 525 configured. 527 Another solution would be for the Mobile Node to assume that the 528 prefix length on the home link is 64 bits and send its interface 529 identifier to the Home Agent in the IP6_INTERNAL_ADDRESS attribute 530 within the CFG_REQ payload. Even though this approach does not tie 531 the prefix on the home link and the Home Agent's address, it still 532 requires that the home prefix length is 64 bits. 534 For this reason the Mobile Node needs to obtain the home link 535 prefixes through the IKEv2 exchange. In the Configuration Payload 536 during the IKE_AUTH exchange, the Mobile Node includes the 537 MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home 538 Agent, when it processes this message, should include in the 539 CFG_REPLY payload prefix information for one prefix on the home 540 link. This prefix information includes the prefix length (see 541 section 8.2). The Mobile Node auto-configures a Home Address from 542 the prefix returned in the CFG_REPLY message and runs a 543 CREATE_CHILD_SA exchange to create security associations for the 544 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 548 case, 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 552 Node gets a "USE_ASSIGNED_HoA" Notify Payload in response to the 553 Configuration Payload containing the MIP6_HOME_PREFIX attribute, 554 it looks for an INTERNAL_IP6_ADDRESS attribute and MUST use the 555 address contained in it in the subsequent CREATE_CHILD_SA 556 exchange. 558 When the Home Agent receives a Binding Update for the Mobile Node, 559 it performs proxy DAD for the auto-configured Home Address. If DAD 560 fails, the Home Agent rejects the Binding Update. If the Mobile 561 Node receives a Binding Acknowledgement with status 134 (DAD 562 failed), it MUST stop using the current Home Address, configure a 563 new HoA, and then run IKEv2 CREATE_CHILD_SA exchange to create 564 security associations based on the new HoA. The Mobile Node does 565 not need to run IKE_INIT and IKE_AUTH exchanges again. Once the 566 necessary security associations are created, the Mobile Node sends 567 a Binding Update for the new Home Address. 569 It is worth noting that with this mechanism, the prefix 570 information carried in MIP6_HOME_PREFIX attribute includes only 571 one prefix and does not carry all the information that is 572 typically present when received through a IPv6 router 573 advertisement. Mobile Prefix Discovery, specified in RFC 3775 [2], 574 is the mechanism through which the Mobile Node can get all 575 prefixes on the home link and all related information. That means 576 that MIP6_HOME_PREFIX attribute is only used for Home Address 577 auto-configuration and does not replace the usage of Mobile Prefix 578 Discovery for the purposes detailed in RFC 3775. 580 5.4. Authorization and Authentication with MSA 582 In a scenario where the Home Agent is discovered dynamically by 583 the Mobile Node, it is very likely that the Home Agent is not able 584 to verify by its own the credentials provided by the Mobile Node 585 during the IKEv2 exchange. Moreover, the mobility service needs to 586 be explicitly authorized based on the user's profile. As an 587 example, the Home Agent might not be aware if the mobility service 588 can be granted at a particular time of the day or if the credit of 589 the Mobile Node is going to expire. 591 Due to all these reasons, the Home Agent may need to contact the 592 MSA in order to authenticate the Mobile Node and authorize 593 mobility service. This can be accomplished based on a Public Key 594 Infrastructure if certificates are used and a PKI is deployed by 595 the MSP and MSA. On the other hand, if the Mobile Node is provided 596 with other types of credentials, the AAA infrastructure must be 597 used. 599 The definition of this backend communication is out of the scope 600 of this document. In [12] a list of goals for such a communication 601 is provided. 603 6. Home Address registration in the DNS 605 In order that the Mobile Node is reachable through its dynamically 606 assigned Home Address, the DNS needs to be updated with the new 607 Home Address. Since applications make use of DNS lookups on FQDN 608 to find a node, the DNS update is essential for providing IP 609 reachability to the Mobile Node, which is the main purpose of the 610 Mobile IPv6 protocol. The need of DNS update is not discussed in 611 RFC 3775 since it assumes that the Mobile Node is provisioned with 612 a static home address. However, when a dynamic Home Address is 613 assigned to the Mobile Node, any existing DNS entry becomes 614 invalid and the Mobile Node becomes unreachable unless a DNS 615 update is performed. 617 Since the DNS update must be performed securely in order to 618 prevent attacks or modifications from malicious nodes, the node 619 performing this update must share a security association with the 620 DNS server. Having all possible Mobile Nodes sharing a security 621 association with the DNS servers of the MSP might be cumbersome 622 from an administrative perspective. Moreover, even if a Mobile 623 Node has a security association with a DNS server of its MSP, an 624 address authorization issue comes into the picture. A detailed 625 analysis of possible threats against DNS update is provided in 626 section 9.5. 628 Therefore, due to security and administrative reasons, it is 629 RECOMMENDED that the Home Agent perform DNS entry update for the 630 Mobile Node. For this purpose the Mobile Node MAY include a new 631 mobility option, the DNS Update option, with the flag R not set in 632 the Binding Update. This option is defined in section 8 and 633 includes the FQDN that needs to be updated. After receiving the 634 Binding Update, the Home Agent MUST update the DNS entry with the 635 identifier provided by the Mobile Node and the Home Address 636 included in the Home Address Option. The procedure for sending a 637 dynamic DNS update message is specified in [14]. The dynamic DNS 638 update SHOULD be performed in a secure way; for this reason, the 639 usage of TKEY and TSEC or DNSSEC is recommended (see section 9.5. 640 for details). As soon as the Home Agent has updated the DNS, it 641 MUST send a Binding Acknowledgement message to the Mobile Node 642 including the DNS Update mobility option with the correct value in 643 the Status field (see section 8.1). 645 This procedure can be performed directly by the Home Agent if the 646 Home Agent has a security association with the domain specified in 647 the Mobile Node's FQDN. 649 On the other hand, if the Mobile Node wants to be reachable 650 through a FQDN that belongs to the MSA, the Home Agent and the DNS 651 server that must be updated belong to different administrative 652 domain. In this case the Home Agent may not share a security 653 association with the DNS server and the DNS entry update can be 654 performed by the AAA server of the MSA. In order to accomplish 655 this, the Home Agent sends to the AAA server the FQDN-HoA pair 656 through the AAA protocol. This message is proxied by the AAA 657 infrastructure of the MSP and is received by the AAA server of the 658 MSA. The AAA server of the MSA perform the DNS update based on 659 [14]. The detailed description of the communication between Home 660 Agent and AAA is out of the scope of this draft. More details are 661 provided in [12]. 663 A mechanism to remove stale DNS entries is needed. A DNS entry 664 becomes stale when the related Home Address is no more used by the 665 Mobile Node. To remove a DNS entry, the MN includes the DNS Update 666 mobility option, with the flag R set in the Binding Update. After 667 receiving the Binding Update, the Home Agent MUST remove the DNS 668 entry identified by the FQDN provided by the Mobile Node and the 669 Home Address included in the Home Address Option. The procedure 670 for sending a dynamic DNS update message is specified in [14]. As 671 mentioned above, the dynamic DNS update SHOULD be performed in a 672 secure way; for this reason, the usage of TKEY and TSEC or DNSSEC 673 is recommended (see section 9.5. for details). 675 This approach does not work if the Mobile Node stops using the 676 Home Address without sending a Binding Update message (e.g. in 677 case of crash). In this case, an additional mechanism to trigger 678 the DNS entry removal is needed. For this purpose, the Home Agent 679 has a timer related to the DNS entry of the Mobile Node. This 680 timer is initialized when the Mobile Node sends a Binding Update 681 with R==0 (i.e. when the MN asks the Home Agent to bind the FQDN 682 to the Home Address). The initial value of this timer is 683 configurable by the network operator. 685 If the Home Agent receives a Binding Update with R==1, it removes 686 the DNS entry as described in the previous paragraph and removes 687 the timer associated to that entry. If the timer expires without 688 receiving a Binding Update with R==1, the HA checks the Binding 689 Cache. If there is an existing Binding Cache entry for the HoA, 690 the HA does not remove the DNS entry and re-initialize the timer. 691 If there is not a Binding Cache entry, it sends a Neighbor 692 Solicitation message to check if the MN is at home and is using 693 the HoA. If the HA gets a Neighbor Advertisement message, it does 694 not remove the DNS entry and re-initialize the timer. If it does 695 not receive a NA, it removes the DNS entry and the timer 696 associated to it. 698 7. Summary of Bootstrapping Protocol Flow 700 The message flow of the whole bootstrapping procedure when the 701 dynamic DNS update is performed by the Home Agent is depicted in 702 Figure 3. 704 +----+ +----+ +-----+ 705 | MN | | HA | | DNS | 706 +----+ +----+ +-----+ 708 IKEv2 exchange 709 (HoA configuration) 710 <======================> 712 BU (DNS update option) 713 -----------------------> 714 DNS update 715 <-------------------> 716 BU (DNS update option) 717 <----------------------- 719 Figure 3 - Dynamic DNS update by the HA 721 Figure 4 shows the message flow of the whole bootstrapping 722 procedure when the dynamic DNS update is performed by the AAA 723 server of the MSA. 725 +----+ +----+ +---+ +---+ 726 | MN | | HA | |AAA| |DNS| 727 +----+ +----+ +---+ +---+ 729 IKEv2 exchange 730 (HoA configuration) 731 <======================> 733 BU (DNS update option) 734 -----------------------> 736 AAA request 737 (FQDN, HoA) 738 <--------------> 740 DNS update 741 <-----------> 742 AAA answer 743 (FQDN, HoA) 744 <--------------> 745 BU (DNS update option) 746 <----------------------- 748 Figure 4 - Dynamic DNS update by the AAA 750 Notice that, even in this last case, the Home Agent is always 751 required to perform a DNS update for the reverse entry, since this 752 is always performed in the DNS server of the MSP. This is not 753 depicted in Figure 4. 755 8. Option and Attribute Format 757 8.1. DNS Update mobility option 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Option Type | Option Length | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Status |R| Reserved | MN identity (FQDN) ... 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 o Option Type - DNS-UPDATE-TYPE to be defined by IANA 769 o Option Length - 8 bit unsigned integer indicating the length of 770 the option excluding the type and length fields 772 o Status - 8 bit unsigned integer indicating the result of the 773 dynamic DNS update procedure. This field MUST be set to 0 and 774 ignored by the receiver when the DNS Update mobility option is 775 included in a Binding Update message. When the DNS Update 776 mobility option is included in the Binding Acknowledgement 777 message, values of the Status field less than 128 indicate that 778 the dynamic DNS update was performed successfully by the Home 779 Agent. Values greater than or equal to 128 indicate that the 780 dynamic DNS update was not completed by the HA. The following 781 Status values are currently defined: 783 0 DNS update performed 785 128 Reason unspecified 787 129 Administratively prohibited 789 130 DNS Update Failed 791 o R flag - if set the MN is requesting the HA to remove the DNS 792 entry identified by the FQDN specified in this option and the 793 HoA of the MN. If not set, the MN is requesting the HA to 794 create or update a DNS entry with its HoA and the FQDN 795 specified in the option. 797 o Reserved - these bits are reserved for future purposes and MUST 798 be set to 0. 800 o MN identity - the identity of the Mobile Node to be used by the 801 Home Agent to send a Dynamic DNS update. It is a variable 802 length field. 804 8.2. MIP6_HOME_PREFIX attribute 806 The MIP6_HOME_PREFIX attribute is included in the IKEv2 807 CFG_REQUEST by the Mobile Node to ask the Home Agent for the home 808 prefix and is included in the CFG_REPLY by the Home Agent to 809 provide the Mobile Node with home prefix and home prefix length. 810 The format of this attribute is equal to the format of the 811 Configuration Attributes defined in [7] and is depicted below. 813 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 !R| Attribute Type ! Length | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | | 819 | home prefix | 820 | | 821 | | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Prefix Length | 824 +-+-+-+-+-+-+-+-+ 826 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 827 ignored on receipt. 829 o Attribute Type (7 bits) - A unique identifier for the 830 MIP6_HOME_PREFIX attribute. To be assigned by IANA. 832 o Length (2 octets) - Length in octets of Value field (home 833 prefix and Prefix Length). This is multi-valued and can be 0 or 834 17. 836 o Home Prefix (16 octets) - The prefix of the home link through 837 which the Mobile Node must auto-configure its Home Address. 839 o Prefix Length (1 octet) - The length of the home prefix 840 specified in the field Home Prefix. 842 When the MIP6_HOME_PREFIX attribute is included by the Mobile Node 843 in the CFG_REQUEST payload, the value of the Length field is 0. On 844 the other hand, when the MIP6_HOME_PREFIX attribute is included in 845 the CFG_REPLY payload by the Home Agent, the value of the Length 846 field is 17 and the attribute contains also the Home Prefix and 847 the Prefix Length fields. 849 9. Security Considerations 851 9.1. HA Address Discovery 853 Use of DNS for address discovery carries certain security risks. 854 DNS transactions in the Internet are typically done without any 855 authentication of the DNS server by the client or of the client by 856 the server. There are two risks involved: 858 1) A legitimate client obtains a bogus Home Agent address from a 859 bogus DNS server. This is sometimes called a "pharming" attack, 861 2) An attacking client obtains a legitimate Home Agent address 862 from a legitimate server. 864 The risk in Case 1 is mitigated because the Mobile Node is 865 required to conduct an IKE transaction with the Home Agent prior 866 to performing a Binding Update to establish Mobile IPv6 service. 867 According to the IKEv2 specification [7], the responder must 868 present the initiator with a valid certificate containing the 869 responder's public key, and the responder to initiator IKE_AUTH 870 message must be protected with an authenticator calculated using 871 the public key in the certificate. Thus, an attacker would have to 872 set up both a bogus DNS server and a bogus Home Agent, and 873 provision the Home Agent with a certificate that a victim Mobile 874 Node could verify. If the Mobile Node can detect that the 875 certificate is not trustworthy, the attack will be foiled when the 876 Mobile Node attempts to set up the IKE SA. 878 The risk in Case 2 is limited for a single Mobile Node to Home 879 Agent transaction if the attacker does not possess proper 880 credentials to authenticate with the Home Agent. The IKE SA 881 establishment will fail when the attacking Mobile Node attempts to 882 authenticate itself with the Home Agent. Regardless of whether the 883 Home Agent utilizes EAP or host-side certificates to authenticate 884 the Mobile Node, the authentication will fail unless the Mobile 885 Node has valid credentials. 887 Another risk exists in Case 2 because the attacker may be 888 attempting to propagate a DoS attack on the Home Agent. In that 889 case, the attacker obtains the Home Agent address from the DNS, 890 then propagates the address to a network of attacking hosts that 891 bombard the Home Agent with traffic. This attack is not unique to 892 the bootstrapping solution, however, it is actually a risk that 893 any Mobile IPv6 Home Agent installation faces. In fact, the risk 894 is faced by any service in the Internet that distributes a unicast 895 globally routable address to clients. Since Mobile IPv6 requires 896 that the Mobile Node communicate through a globally routable 897 unicast address of a Home Agent, it is possible that the Home 898 Agent address could be propagated to an attacker by various means 899 (theft of the Mobile Node, malware installed on the Mobile Node, 900 evil intent of the Mobile Node owner him/herself, etc.) even if 901 the home address is manually configured on the Mobile Node. 902 Consequently, every Mobile IPv6 Home Agent installation will 903 likely be required to mount anti-DoS measures. Such measures 904 include overprovisioning of links to and from Home Agents and of 905 Home Agent processing capacity, vigilant monitoring of traffic on 906 the Home Agent networks to detect when traffic volume increases 907 abnormally indicating a possible DoS attack, and hot spares that 908 can quickly be switched on in the event an attack is mounted on an 909 operating collection of Home Agents. DoS attacks of moderate 910 intensity should be foiled during the IKEv2 transaction. IKEv2 911 implementations are expected to generate their cookies without any 912 saved state, and to time out cookie generation parameters 913 frequently, with the timeout value increasing if a DoS attack is 914 suspected. This should prevent state depletion attacks, and should 915 assure continued service to legitimate clients until the practical 916 limits on the network bandwith and processing capacity of the Home 917 Agent network are reached. 919 Explicit security measures between the DNS server and host, such 920 DNSSEC [16] or TSIG/TKEY [17] [18] can mitigate the risk of 1) and 921 2), but these security measures are not widely deployed on end 922 nodes. These security measures are not sufficient to protect the 923 Home Agent address against DoS attack, however, because a node 924 having a legitimate security association with the DNS server could 925 nevertheless intentionally or inadvertently cause the Home Agent 926 address to become the target of DoS. 928 Finally notice that assignment of an home agent from the serving 929 network access provider's (local home agent) or a home agent from 930 a nearby network (nearby home agent) may set up the potential to 931 compromise a MN's location privacy. However, since a standardized 932 mechanism of assigning local or nearby home agents is out of scope 933 for this document, it is not possible to present detailed security 934 considerations. Please see other drafts that contain detailed 935 mechanisms for localized home agent assignment, such as [15], for 936 information on the location privacy properties of particular home 937 agent assignment mechanisms. 939 Security considerations for discovering HA using DHCP are covered 940 in draft-jang-dhc-haopt-01 [15]. 942 9.2. Home Address Assignment through IKEv2 944 Mobile IPv6 bootstrapping assigns the home address through the 945 IKEv2 transaction. The Mobile Node can either choose to request an 946 address, similar to DHCP, or the Mobile Node can request a prefix 947 on the home link then autoconfigure an address. 949 RFC 3775 [2] and 3776 [3] require that a Home Agent check 950 authorization on a home address received during a Binding Update. 952 The Home Agent MUST set up authorization by linking the home 953 address to the identity of the IPsec SAs used to authenticate the 954 Binding Update message. The linking MUST be done either during the 955 IKE_AUTH phase or CREATE_CHILD_SA phase when the IPsec SAs are 956 constructed. 958 If the address is autoconfigured, RFC 3775 requires the Home Agent 959 to proxy-defend the address on the home link after the Mobile Node 960 performs the initial Binding Update. Since it is not currently 961 possible to securely proxy CGAs using SEND, attacks on address 962 resolution for Neighbor Discovery listed in RFC 3756 are possible 963 on dynamically assigned home addresses that are proxied by the 964 Home Agent. 966 9.3. SA Establishment Using EAP Through IKEv2 968 Security considerations for authentication of the IKE transaction 969 using EAP are covered in draft-ietf-mip6-ikev2-ipsec [6]. 971 9.4. Back End Security Between the HA and AAA Server 973 Some deployments of Mobile IPv6 bootstrapping may use an AAA 974 server to handle authorization for mobility service. This process 975 has its own security requirements, but the back end protocol for 976 Home Agent to AAA server interface is not covered in this draft. 977 Please see draft-ietf-mip6-aaa-ha-goals [12] for a discussion of 978 this interface. 980 9.5. Dynamic DNS Update 982 Mobile IPv6 bootstrapping recommends the Home Agent to update the 983 Mobile Node's FQDN with a dynamically assigned home address rather 984 than have the Mobile Node itself do it (see Section 6 above). This 985 choice was motivated by a concern for preventing redirection-based 986 flooding attacks (see draft-ietf-mip6-ro-sec [19] for more 987 information about redirection-based flooding attacks and the role 988 preventing them played in the design of Mobile IPv6 route 989 optimization security). Exactly as for route optimization, it is 990 possible for a node that is the legitimate owner of a DNS FQDN - 991 in the sense that it has a security association with the DNS 992 server allowing it to perform dynamic DNS update of its FQDN - to 993 bind its FQDN to the address of a victim, then redirect large 994 volumes of traffic at the victim. The attack may be propagated 995 without the owner's knowledge, for example, if the node is 996 compromised by malware, or it may be intentional if the node 997 itself is the attacker. 999 While it is possible to prevent redirection attacks through 1000 ingress filtering on access routers, ISPs have little or no 1001 incentive to deploy ingress filtering. In some cases, if an attack 1002 could result in substantial financial gain, it is even possible 1003 that a corrupt ISP may have an incentive not to deploy ingress 1004 filters such as has been the case for spam. Consequently, the 1005 security for dynamic Mobile Node FQDN update has been assigned to 1006 the Home Agent, where active network administration and vigilant 1007 defense measures are more likely to (but are not assured of) 1008 mitigating problems, and the owner of the Mobile Node is more 1009 likely to detect a problem if it occurs. 1011 If a Home Agent performs dynamic DNS update on behalf of the 1012 Mobile Node directly with the DNS server, the Home Agent MUST have 1013 a security association of some type with the DNS server. The 1014 security association MAY be established either using DNSSEC [16] 1015 or TSIG/TKEY [17][18]. A security association is required even if 1016 the DNS server is in the same administrative domain as the Home 1017 Agent. The security association SHOULD be separate from the 1018 security associations used for other purposes, such as AAA. 1020 In the case where the Mobility Service Provider is different from 1021 the Mobility Service Authorizer, the network administrators may 1022 want to limit the number of cross-administrative domain security 1023 associations. If the Mobile Node's FQDN is in the Mobility Service 1024 Authorizer's domain, since a security association for AAA 1025 signaling involved in mobility service authorization is required 1026 in any case, the Home Agent can send the Mobile Node's FQDN to the 1027 AAA server under the HA-AAA server security association, and the 1028 AAA server can perform the update. In that case, a security 1029 association is required between the AAA server and DNS server for 1030 the dynamic DNS update. See draft-ietf-mip6-aaa-ha-goals [12] for 1031 a deeper discussion of the Home Agent to AAA server interface. 1033 Regardless of whether the AAA server or Home Agent performs DNS 1034 update, the authorization of the Mobile Node to update a FQDN MUST 1035 be checked prior to the performance of the update. It is an 1036 implementation issue as to how authorization is determined. 1037 However, in order to allow this authorization step, the Mobile 1038 Node MUST use a FQDN as the IDi in IKE_AUTH step of the IKEv2 1039 exchange. The FQDN MUST be the same that will be provided by the 1040 MN in the DNS Update Option. This allows the Home Agent to get 1041 authorization information about the Mobile Node's FQDN via the AAA 1042 back end communication performed during IKEv2 exchange. The 1043 outcome of this step will give the Home Agent the necessary 1044 information to authorize the DNS update request of the Mobile 1045 Node. See draft-ietf-mip6-aaa-ha-goals [12] for details about the 1046 communication between the AAA server and the Home Agent needed to 1047 perform the authorization. Notice that if certificates are used in 1048 IKEv2, the authorization information about the FQDN for DNS update 1049 MUST be present in the certificate provided by the Mobile Node. 1051 10. IANA Considerations 1053 This document defines a new Mobility Option and a new IKEv2 1054 Configuration Attribute Type. 1056 The following values should be assigned: 1058 o from "Mobility Option" namespace ([2]): DNS-UPDATE-TYPE 1059 (section 8.1) 1061 o from "IKEv2 Configuration Payload Attribute Types" namespace 1062 ([7]): MIP6_HOME_PREFIX attribute (section 8.2) 1064 o from "IKEv2 Notify Payload Error Types" namespace ([7]): 1065 USE_ASSIGNED_HoA error type (section 5.3.2) 1067 11. Contributors 1069 This contribution is a joint effort of the bootstrapping solution 1070 design team of the MIP6 WG. The contributors include Basavaraj 1071 Patil, Alpesh Patel, Jari Arkko, James Kempf, Yoshihiro Ohba, 1072 Gopal Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, 1073 Kuntal Chowdury, Julien Bournelle. 1075 The design team members can be reached at: 1077 Gerardo Giaretta gerardo.giaretta@tilab.com 1079 Basavaraj Patil basavaraj.patil@nokia.com 1081 Alpesh Patel alpesh@cisco.com 1083 Jari Arkko jari.arkko@kolumbus.fi 1085 James Kempf kempf@docomolabs-usa.com 1087 Yoshihiro Ohba yohba@tari.toshiba.com 1089 Gopal Dommety gdommety@cisco.com 1091 Alper Yegin alper.yegin@samsung.com 1093 Vijay Devarapalli vijayd@iprg.nokia.com 1095 Kuntal Chowdury kchowdury@starentnetworks.com 1097 Junghoon Jee jhjee@etri.re.kr 1099 Julien Bournelle julien.bournelle@int-evry.fr 1101 12. Acknowledgments 1103 The authors would like to thank Rafa Lopez, Francis Dupont, 1104 Basavaraj Patil, Jari Arkko, Kilian Weniger for their valuable 1105 comments. 1107 13. References 1109 13.1. Normative References 1111 [1] Bradner, S., "Key words for use in RFCs to Indicate 1112 Requirement Levels", BCP 14, RFC 2119, March 1997. 1114 [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 1115 in IPv6", RFC 3775, June 2004. 1117 [3] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to 1118 Protect Mobile IPv6 Signaling between Mobile Nodes and 1119 Home Agents", RFC 3776, June 2004 1121 [4] Patel, A., "Problem Statement for bootstrapping Mobile 1122 IPv6", Internet-Draft draft-ietf-mip6-bootstrap-ps- 1123 03, July 2005. 1125 [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1126 specifying the location of services (DNS SRV)", RFC 2782, 1127 February 2000. 1129 [6] Devarapalli, V., " Mobile IPv6 Operation with IKEv2 and the 1130 revised IPsec Architecture", Internet-Draft draft-ietf-mip6- 1131 ikev2-ipsec-03, September 2005. 1133 [7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1135 13.2. Informative References 1137 [8] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 1138 3753, June 2004. 1140 [9] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 1141 3972, March 2005. 1143 [10] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions 1144 for Stateless Address Autoconfiguration in IPv6", Internet- 1145 Draft draft-ietf-ipv6-privacy-addrs-v2-04, May 2005. 1147 [11] Droms, R., Ed., "DNS Configuration options for Dynamic Host 1148 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1149 December 2003. 1151 [12] Giaretta, G., Ed. "Goals for AAA-HA interface", Internet- 1152 Draft draft-ietf-mip6-aaa-ha-goals-00, April 2005. 1154 [13] Koodli, R., Devarapalli, V., Perkins, C., Flinck, H., 1155 "Solutions for IP Address Location Privacy in the presence 1156 of IP Mobility", Internet-Draft, draft-koodli-mip6-location- 1157 privacy-solutions-00, February 2005. 1159 [14] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. 1160 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1161 RFC 2136, April 1997. 1163 [15] Chowdhury, K., Yegin, A., Choi, J., "MIP6-bootstrapping via 1164 DHCPv6 for the Integrated Scenario", Internet-Draft, draft- 1165 ietf-mip6-bootstrapping-integrated-dhc-00, October 2005. 1167 [16] Arends, R., Austein, R., Larson, M., Massey, D., Rose, S., 1168 "DNS Security Introduction and Requirements", RFC 4033, 1169 March 2005. 1171 [17] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., Wellington, 1172 B., "Secret Key Transaction Authentication for DNS (TSIG)", 1173 RFC 2845, May 2000. 1175 [18] Eastlake 3rd, D., " Secret Key Establishment for DNS (TKEY 1176 RR)", RFC 2930, September 2000. 1178 [19] Nikander, P., Arkko, J., Aura, T., Montenegro, G., 1179 Nordmark, E., "Mobile IP version 6 Route Optimization 1180 Security Design Background", Internet-Draft, draft-ietf- 1181 mip6-ro-sec-02, October 2004. 1183 [20] Narten, T., Nordmark, E., Simpson, W., Soliman, H., 1184 "Neighbor Discovery for IP version 6 (IPv6)"`, Internet- 1185 Draft, draft-ietf-ipv6-2461bis-03, May 2005. 1187 Authors' Addresses 1189 Gerardo Giaretta 1190 Telecom Italia Lab 1191 via Reiss Romoli 274 1192 10148 Torino 1193 Italy 1195 Phone: +39 011 228 6904 1196 Email: gerardo.giaretta@tilab.com 1198 James Kempf 1199 DoCoMo Labs USA 1200 181 Metro Drive 1201 Suite 300 1202 San Jose, CA, 95110 1203 USA 1205 Phone: +1 408 451 4711 1206 Email: kempf@docomolabs-usa.com 1208 Vijay Devarapalli 1209 Nokia Research Center 1210 313 Fairchild Drive 1211 Mountain View, CA 94043 1212 USA 1214 Email: vijay.devarapalli@nokia.com 1216 Intellectual Property Statement 1218 The IETF takes no position regarding the validity or scope of any 1219 Intellectual Property Rights or other rights that might be claimed 1220 to pertain to the implementation or use of the technology 1221 described in this document or the extent to which any license 1222 under such rights might or might not be available; nor does it 1223 represent that it has made any independent effort to identify any 1224 such rights. Information on the procedures with respect to rights 1225 in RFC documents can be found in BCP 78 and BCP 79. 1227 Copies of IPR disclosures made to the IETF Secretariat and any 1228 assurances of licenses to be made available, or the result of an 1229 attempt made to obtain a general license or permission for the use 1230 of such proprietary rights by implementers or users of this 1231 specification can be obtained from the IETF on-line IPR repository 1232 at http://www.ietf.org/ipr. 1234 The IETF invites any interested party to bring to its attention 1235 any copyrights, patents or patent applications, or other 1236 proprietary rights that may cover technology that may be required 1237 to implement this standard. Please address the information to the 1238 IETF at ietf-ipr@ietf.org 1240 Disclaimer of Validity 1242 This document and the information contained herein are provided on 1243 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1244 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1245 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1246 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1247 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1248 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1249 PARTICULAR PURPOSE. 1251 Copyright Statement 1253 Copyright (C) The Internet Society (2005). 1255 This document is subject to the rights, licenses and restrictions 1256 contained in BCP 78, and except as set forth therein, the authors 1257 retain all their rights. 1259 Acknowledgment 1261 Funding for the RFC Editor function is currently provided by the 1262 Internet Society.