idnits 2.17.1 draft-ietf-mip6-bootstrapping-split-00.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 1131. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1108. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1115. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1135), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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 32 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 471 instances of too long lines in the document, the longest one being 5 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 344 has weird spacing: '...pecific namin...' == Line 968 has weird spacing: '...iaretta gerar...' == Line 970 has weird spacing: '...j Patil basa...' == Line 978 has weird spacing: '...ro Ohba yoh...' == Line 986 has weird spacing: '...howdury kcho...' == (1 more instance...) -- 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 (June 22, 2005) is 6883 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 1038, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-05) exists of draft-ietf-mip6-bootstrap-ps-02 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-bootstrap-ps (ref. '4') == Outdated reference: A later version (-08) exists of draft-ietf-mip6-ikev2-ipsec-01 -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: A later version (-05) exists of draft-ietf-ipv6-privacy-addrs-v2-03 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-aaa-ha-goals-00 == Outdated reference: A later version (-02) exists of draft-jang-dhc-haopt-01 -- Obsolete informational reference (is this intentional?): RFC 2845 (ref. '17') (Obsoleted by RFC 8945) == Outdated reference: A later version (-03) exists of draft-ietf-mip6-ro-sec-02 == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-03 Summary: 8 errors (**), 0 flaws (~~), 17 warnings (==), 8 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: December 22, 2005 J. Kempf 5 DoCoMo Labs USA 6 V. Devarapalli 7 Nokia 8 June 22, 2005 10 Mobile IPv6 bootstrapping in split scenario 11 draft-ietf-mip6-bootstrapping-split-00.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 months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on December 22, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 Abstract 45 A Mobile IPv6 node requires a Home Agent address, a home address, and 46 IPsec security associations with its Home Agent before it can start 47 utilizing Mobile IPv6 service. RFC 3775 requires that some or all of 48 these are statically configured. This document defines how a Mobile 49 IPv6 node can bootstrap this information from non-topological 50 information and security credentials preconfigured on the Mobile 51 Node. The solution defined in this document solves the boostrapping 52 problem from draft-ietf-mip6-bootstrapping-ps-02 when the Mobile 53 Node's mobility service is authorized by a different service provider 54 than basic network access, and is therefore generically applicable to 55 any bootstrapping case. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC-2119 [1]. 63 Table of Contents 65 1. Introduction...................................................4 66 2. Terminology....................................................5 67 3. Split scenario.................................................6 68 4. Components of the solution.....................................8 69 5. Protocol Operations...........................................10 70 5.1. Home Agent Address Discovery.............................10 71 5.1.1. DNS lookup by Home Agent Name.......................10 72 5.1.2. DNS lookup by service name..........................11 73 5.2. IPsec Security Associations setup........................12 74 5.3. Home Address assignment..................................12 75 5.3.1. Home Address assignment by the Home Agent...........12 76 5.3.2. Home Address auto-configuration by the Mobile Node..12 77 5.4. Authorization and Authentication with MSA................14 78 6. Home Address registration in the DNS..........................16 79 7. Summary of Bootstrapping Protocol Flow........................18 80 8. Option and Attribute Format...................................20 81 8.1. DNS Update mobility option...............................20 82 8.2. MIP6_HOME_PREFIX attribute...............................21 83 9. Security Considerations.......................................23 84 9.1. HA Address Discovery.....................................23 85 9.2. Home Address Assignment through IKEv2....................24 86 9.3. SA Establishment Using EAP Through IKEv2.................25 87 9.4. Back End Security Between the HA and AAA Server..........25 88 9.5. Dynamic DNS Update.......................................25 89 10. IANA Considerations..........................................27 90 11. Contributors.................................................28 91 12. References...................................................29 92 12.1. Normative References....................................29 93 12.2. Informative References..................................29 94 Authors' Addresses...............................................31 95 Intellectual Property Statement..................................32 96 Disclaimer of Validity...........................................32 97 Copyright Statement..............................................32 98 Acknowledgment...................................................32 100 1. Introduction 102 Mobile IPv6 [2] requires the Mobile Node to know its Home Agent 103 Address, its own Home Address and the cryptographic materials (e.g. 104 shared keys or certificates) needed to set-up IPsec security 105 associations with the Home Agent in order to protect MIPv6 signaling. 106 This is generally referred to as the Mobile IPv6 bootstrapping 107 problem [4]. 109 Mobile IPv6 base protocol does not specify any method to 110 automatically acquire this information, which means that network 111 administrators are normally required to manually set configuration 112 data on MNs and HAs. However, in real deployments, manual 113 configuration does not scale as the Mobile Nodes increase in number. 115 As discussed in [4], several bootstrapping scenarios can be 116 identified depending on the relationship between the network operator 117 that authenticates a mobile host for granting network access service 118 (Access Service Authorizer, ASA) and the service provider that 119 authorizes Mobile IPv6 service (Mobility Service Authorizer, MSA). 120 This document describes a solution to the bootstrapping problem that 121 is applicable in a scenario where the MSA and the ASA are different 122 entities (i.e. split scenario). 124 2. Terminology 126 General mobility terminology can be found in [8]. The following 127 additional terms are used here: 129 ASA 130 Access Service Authorizer. A network operator that authenticates 131 a mobile host and establishes the mobile host's authorization to 132 receive Internet service. 134 ASP 135 Access Service Provider. A network operator that provides direct 136 IP packet forwarding to and from the end host. 138 MSA 139 Mobility Service Authorizer. A service provider that authorizes 140 Mobile IPv6 service. 142 MSP 143 Mobility Service Provider. A service provider that provides 144 Mobile IPv6 service. In order to obtain such service, the mobile 145 host must be authenticated and prove authorization to obtain the 146 service. 148 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 draft [4] there is a clear assumption that 156 mobility service and network access service can be separate. This 157 assumption implies that mobility service and network access service 158 may be authorized by different entities. As an example, the service 159 model defined in [4] allows an enterprise network to deploy a Home 160 Agent and offer Mobile IPv6 service to a user, even if the user is 161 accessing the Internet independent of its enterprise account (e.g., 162 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 called 168 split scenario. 170 Moreover, the model defined in [4] 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 entity 176 that authenticates and authorizes the user (i.e. Mobility Service 177 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 be also 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 The split scenario is the simplest model that can be identified, 236 since no assumptions about the access network are made. This implies 237 that the mobility service is bootstrapped independently from the 238 authentication protocol for network access used (e.g. PANA, EAP). For 239 this reason, the solution described in this document and developed 240 for this scenario could also be applied to the integrated access 241 network deployment model [4], even if it might not be optimized . 243 4. Components of the solution 245 The bootstrapping problem is composed of different sub-problems that 246 can be solved independently in a modular way. The components 247 identified and a brief overview of their solution follow. 249 o HA address discovery. The Mobile Node needs to discover the 250 address of its Home Agent. The main objective of a bootstrapping 251 solution is to minimize the data pre-configured on the Mobile 252 Node. For this reason, the DHAAD defined in [2] may not be 253 applicable in real deployments since it is required that the 254 Mobile Node is pre-configured with the home network prefix and it 255 does not allow an operator to load balance by having Mobile Nodes 256 dynamically assigned to Home Agents located in different subnets. 257 This document defines a solution for Home Agent address discovery 258 that is based on Domain Name Service (DNS), introducing a new DNS 259 SRV record [5]. The unique information that needs to be pre- 260 configured on the Mobile Node is the domain name of the MSP. 262 o IPsec Security Associations setup. MIPv6 requires that a Mobile 263 Node and its Home Agent share an IPsec SA in order to protect 264 binding updates and other MIPv6 signaling. This document provides 265 a solution that is based on IKEv2 and follows what is specified in 266 [6]. The IKEv2 peer authentication can be performed both using 267 certificates and using EAP, depending on the network operator's 268 deployment model. 270 o HoA assignment. The Mobile Node needs to know its Home Address in 271 order to bootstrap Mobile IPv6 operation. The Home Address is 272 assigned by the Home Agent during the IKEv2 exchange (as described 273 in [6]). The solution defined in this draft also allows the Mobile 274 Node to auto-configure its Home Address based on stateless auto- 275 configuration ([20]), Cryptographically Generated Addresses ([9]) 276 or privacy addresses ([10]). 278 o Authentication and Authorization with MSA. The user must be 279 authenticated in order for the MSA to grant the service. Moreover, 280 the mobility service must be explicitly authorized by the MSA 281 based on the user's profile. These operations are performed in 282 different ways depending on the credentials used by the Mobile 283 Node during the IKEv2 peer authentication and on the backend 284 infrastructure (PKI or AAA). 286 An optional part of bootstrapping involves providing a way for the 287 Mobile Node to have its FQDN updated in the DNS with a dynamically 288 assigned home address. While not all applications will require this 289 service, many networking applications use the FQDN to obtain an 290 address for a node prior to starting IP traffic with it. The solution 291 defined in this document specifies that the dynamic DNS update is 292 performed by the Home Agent or through the AAA infrastructure, 293 depending on the trust relationship in place. 295 5. Protocol Operations 297 This section describes in detail the procedures needed to perform 298 Mobile IPv6 bootstrapping based on the components identified in the 299 previous section. 301 5.1. Home Agent Address Discovery 303 Once a Mobile Node has obtained network access, it can perform Mobile 304 IPv6 bootstrapping. For this purpose, the Mobile Node queries the DNS 305 server to request information on Home Agent service. As mentioned 306 before in the document, the only information that needs to be auto- 307 configured on the Mobile Node is the domain name of the Mobility 308 Service Provider. 310 The Mobile Node needs to obtain the IP address of the DNS server 311 before it can send a DNS request. This can be pre-configured on the 312 Mobile Node or obtained through DHCPv6 from the visited link [11]. In 313 any case, it is assumed that there is some kind of mechanism by which 314 the Mobile Node is configured with a DNS server since a DNS server is 315 needed for many other reasons. 317 Two options for DNS lookup for a Home Agent address are identified in 318 this document: DNS lookup by Home Agent Name and DNS lookup by 319 service name. 321 While this document specifies a Home Agent Address Discovery solution 322 based on DNS, when the ASP and the MSP are the same entity DHCP may 323 be used. See [15] for details. 325 5.1.1. DNS lookup by Home Agent Name 327 In this case, the Mobile Node is configured with the Fully Qualified 328 Domain Name of the Home Agent. As an example, the Mobile Node could 329 be configured with the name "ha1.example.com", where "example.com" is 330 the domain name of the MSP granting the mobility service. 332 The Mobile Node constructs a DNS request, by setting the QNAME to the 333 name of the Home Agent. The request has QTYPE set to 'AAAA', so that 334 the DNS server sends the IPv6 address of the Home Agent. Once the DNS 335 server replies to this query, the Mobile Node knows its Home Agent 336 address and can run IKEv2 in order to set up an IPsec SA and get a 337 Home Address. 339 Additionally, it could be useful to provide an ability for the Mobile 340 Node to discover a Home Agent placed in a particular location (e.g. 341 on the visited link). In order to achieve this, the Mobile Node must 342 be able to construct a DNS request such that the DNS server will be 343 able to reply with a Home Agent from the requested location. This can 344 be accomplished by using a specific naming convention for the FQDNs 345 of the Home Agents. As an example, an operator might assign the FQDN 346 "ha.locationA.operator.com" to the Home Agent located in "location A" 347 and the FQDN "ha.locationB.operator.com" to the Home Agent located in 348 "location B". If the Mobile Node wants to use a Home Agent located in 349 "location A", it will set the QNAME to "ha.locationA.operator.com" in 350 the DNS request. 352 5.1.2. DNS lookup by service name 354 RFC 2782 [5] defines the service resource record (SRV RR), that 355 allows an operator to use several servers for a single domain, to 356 move services from host to host, and to designate some hosts as 357 primary servers for a service and others as backups. Clients ask for 358 a specific service/protocol for a specific domain and get back the 359 names of any available servers. 361 RFC 2782 [5] describes also the policies to choose a service agent 362 based on the preference and weight values. The DNS SRV record may 363 contain the preference and weight values for multiple Home Agents 364 available to the Mobile Node in addition to the Home Agent FQDNs. If 365 multiple Home Agents are available in the DNS SRV record then Mobile 366 Node is responsible for processing the information as per policy and 367 for picking one Home Agent. If the Home Agent of choice does not 368 respond for some reason or the IKEv2 authentication fails, the Mobile 369 Node SHOULD try other Home Agents on the list. 371 The service name for Mobile IPv6 Home Agent service as required by 372 RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a 373 transport name cannot be used here because Mobile IPv6 does not run 374 over a transport protocol. 376 The SRV RR has a DNS type code of 33. As an example, the Mobile 377 constructs a request with QNAME set to "mip6.example.com" and QTYPE 378 to SRV. The reply contains the FQDNs of one or more servers, that can 379 then be resolved in a separate DNS transaction to the IP addresses. 380 However, it is RECOMMENDED that the DNS server also return the IP 381 addresses of the Home Agents in AAAA records as part of the 382 additional data section in order to avoid requiring an additional DNS 383 round trip to resolve the FQDNs, if there is room in the SRV reply. 385 5.2. IPsec Security Associations setup 387 As soon as the Mobile Node has discovered the Home Agent Address, it 388 establishes an IPsec Security Association with the Home Agent itself 389 through IKEv2. The detailed description of this procedure is provided 390 in [6]. 392 The IKEv2 Mobile Node to Home Agent authentication can be performed 393 using either IKEv2 public key signatures or the Extensible 394 Authentication Protocol (EAP). The details about how IKEv2 395 authentication is done are described in [6] and [7]. Choice of an 396 IKEv2 peer authentication method depends on the deployment. However, 397 IKEv2 restricts the Home Agent to Mobile Node authentication to use 398 public key signature based authentication. 400 5.3. Home Address assignment 402 Home Address assignment is performed during the IKEv2 exchange. The 403 Home Address can be assigned directly by the Home Agent or can be 404 auto-configured by the Mobile Node. 406 5.3.1. Home Address assignment by the Home Agent 408 When the Mobile Node runs IKEv2 with its Home Agent, it can request a 409 HoA through the Configuration Payload in the IKE_AUTH exchange by 410 including an INTERNAL_IP6_ADDRESS attribute. When the Home Agent 411 processes the message, it allocates a HoA and sends it a CFG_REPLY 412 message. The Home Agent could consult a DHCP server on the home link 413 for the actual home address allocation. This is explained in detail 414 in [6]. 416 5.3.2. Home Address auto-configuration by the Mobile Node 418 With the type of assignment described in the previous section, the 419 Home Address cannot be generated based on Cryptographically Generated 420 Addresses (CGAs) [9] or based on the privacy extensions for stateless 421 autoconfiguration [10]. However, the Mobile Node might want to have 422 an auto-configured HoA based on these mechanisms. It is worthwhile to 423 mention that the auto-configuration procedure described in this 424 section cannot be used in some possible deployment, since the Home 425 Agents might be provisioned with pools of allowed Home Addresses. 427 In the simplest case, the Mobile Node is provided with a pre- 428 configured home prefix and home prefix length. In this case the 429 Mobile Node creates a Home Address based on the pre-configured prefix 430 and sends it to the Home Agent including an INTERNAL_IP6_ADDRESS 431 attribute in a Configuration Payload of type CFG_REQUEST. If the Home 432 Address is valid, the Home Agent replies with a CFG_REPLY, including 433 an INTERNAL_IP6_ADDRESS with the same address. If the Home Address 434 provided by the Mobile Node is not valid, the Home Agent assigns a 435 different Home Address including an INTERNAL_IP6_ADDRESS attribute 436 with a new value. According to [7] the Mobile Node MUST use the 437 address sent by the Home Agent. Later, if the Mobile Node wants to 438 use an auto-configured Home Address (e.g. based on CGA), it can run 439 Mobile Prefix Discovery, obtain a prefix, auto-configure a new Home 440 Address and then perform a new CREATE_CHILD_SA exchange. 442 If the Mobile Node is not provided with a pre-configured Home Prefix, 443 the Mobile cannot simply propose an auto-configured HoA in the 444 Configuration Payload since the Mobile Node does not know the home 445 prefix before the start of the IKEv2 exchange. The Mobile Node must 446 obtain the home prefix and the home prefix length before it can 447 configure a home address. 449 One simple solution would be for the Mobile Node to just assume that 450 the prefix length on the home link is 64 bits and extract the home 451 prefix from the Home Agent's address. The disadvantage with this 452 solution is that the home prefix cannot be anything other than /64. 453 Moreover, this ties the prefix on the home link and the Home Agent's 454 address, but, in general, a Home Agent with a particular address 455 should be able to serve a number of prefixes on the home link, not 456 just the prefix from which its address is configured. 458 Another solution would be for the Mobile Node to assume that the 459 prefix length on the home link is 64 bits and send its interface 460 identifier to the Home Agent in the IP6_INTERNAL_ADDRESS attribute 461 within the CFG_REQ payload. Even though this approach does not tie 462 the prefix on the home link and the Home Agent's address, it still 463 requires that the home prefix length is 64 bits. 465 For this reason the Mobile Node needs to obtain the home link 466 prefixes through the IKEv2 exchange. In the Configuration Payload 467 during the IKE_AUTH exchange, the Mobile Node includes the 468 MIP6_HOME_PREFIX attribute in the CFG_REQUEST message. The Home 469 Agent, when it processes this message, should include in the 470 CFG_REPLY payload prefix information for one prefix on the home link. 471 This prefix information includes the prefix length (see section 8.2). 472 The Mobile Node auto-configures a Home Address from the prefix 473 returned in the CFG_REPLY message and runs a CREATE_CHILD_SA exchange 474 to create security associations for the new Home Address. 476 As mentioned before in this document, there are deployments where 477 auto-configuration of the Home Address cannot be used. In this case, 478 when the Home Agent receives a CFG_REQUEST including a 479 MIP6_HOME_PREFIX attribute, in the subsequent IKE response it 480 includes a Notify Payload type "USE_ASSIGNED_HoA" and the related 481 Home Address in a INTERNAL_IP6_ADDRESS attribute. If the Mobile Node 482 gets a "USE_ASSIGNED_HoA" Notify Payload in response to the 483 Configuration Payload containing the MIP6_HOME_PREFIX attribute, it 484 looks for an INTERNAL_IP6_ADDRESS attribute and MUST use the address 485 contained in it in the subsequent CREATE_CHILD_SA exchange. 487 When the Home Agent receives a Binding Update for the Mobile Node, it 488 performs proxy DAD for the auto-configured Home Address. If DAD 489 fails, the Home Agent rejects the Binding Update. If the Mobile Node 490 receives a Binding Acknowledgement with status 134 (DAD failed), it 491 MUST stop using the current Home Address, configure a new HoA, and 492 then run IKEv2 CREATE_CHILD_SA exchange to create security 493 associations based on the new HoA. The Mobile Node does not need to 494 run IKE_INIT and IKE_AUTH exchanges again. Once the necessary 495 security associations are created, the Mobile Node sends a Binding 496 Update for the new Home Address. 498 It is worth noting that with this mechanism, the prefix information 499 carried in MIP6_HOME_PREFIX attribute includes only one prefix and 500 does not carry all the information that is typically present when 501 received through a IPv6 router advertisement. Mobile Prefix 502 Discovery, specified in RFC 3775 [2], is the mechanism through which 503 the Mobile Node can get all prefixes on the home link and all related 504 information. That means that MIP6_HOME_PREFIX attribute is only used 505 for Home Address auto-configuration and does not replace the usage of 506 Mobile Prefix Discovery for the purposes detailed in RFC 3775. 508 5.4. Authorization and Authentication with MSA 510 In a scenario where the Home Agent is discovered dynamically by the 511 Mobile Node, it is very likely that the Home Agent is not able to 512 verify by its own the credentials provided by the Mobile Node during 513 the IKEv2 exchange. Moreover, the mobility service needs to be 514 explicitly authorized based on the user's profile. As an example, the 515 Home Agent might not be aware if the mobility service can be granted 516 at a particular time of the day or if the credit of the Mobile Node 517 is going to expire. 519 Due to all these reasons, the Home Agent may need to contact the MSA 520 in order to authenticate the Mobile Node and authorize mobility 521 service. This can be accomplished based on a Public Key 522 Infrastructure if certificates are used and a PKI is deployed by the 523 MSP and MSA. On the other hand, if the Mobile Node is provided with 524 other types of credentials, the AAA infrastructure must be used. 526 The definition of this backend communication is out of the scope of 527 this document. In [12] a list of goals for such a communication is 528 provided. 530 6. Home Address registration in the DNS 532 In order that the Mobile Node is reachable through its dynamically 533 assigned Home Address, the DNS needs to be updated with the new Home 534 Address. Since applications make use of DNS lookups on FQDN to find a 535 node, the DNS update is essential for providing IP reachability to 536 the Mobile Node, which is the main purpose of the Mobile IPv6 537 protocol. The need of DNS update is not discussed in RFC 3775 since 538 it assumes that the Mobile Node is provisioned with a static home 539 address. However, when a dynamic Home Address is assigned to the 540 Mobile Node, any existing DNS entry becomes invalid and the Mobile 541 Node becomes unreachable unless a DNS update is performed. 543 Since the DNS update must be performed securely in order to prevent 544 attacks or modifications from malicious nodes, the node performing 545 this update must share a security association with the DNS server. 546 Having all possible Mobile Nodes sharing a security association with 547 the DNS servers of the MSP might be cumbersome from an administrative 548 perspective. Moreover, even if a Mobile Node has a security 549 association with a DNS server of its MSP, an address authorization 550 issue comes into the picture. A detailed analysis of possible threats 551 against DNS update is provided in section 9.5. 553 Therefore, due to security and administrative reasons, it is 554 RECOMMENDED that the Home Agent perform DNS entry update for the 555 Mobile Node. For this purpose the Mobile Node MAY include a new 556 mobility option, the DNS Update option, with the flag R not set in 557 the Binding Update. This option is defined in section 8 and includes 558 the FQDN that needs to be updated. After receiving the Binding 559 Update, the Home Agent MUST update the DNS entry with the identifier 560 provided by the Mobile Node and the Home Address included in the Home 561 Address Option. The procedure for sending a dynamic DNS update 562 message is specified in [14]. The dynamic DNS update SHOULD be 563 performed in a secure way; for this reason, the usage of TKEY and 564 TSEC or DNSSEC is recommended (see section 9.5 for details). As 565 soon as the Home Agent has updated the DNS, it MUST send a Binding 566 Acknowledgement message to the Mobile Node including the DNS Update 567 mobility option with the correct value in the Status field (see 568 section 8.1). 570 This procedure can be performed directly by the Home Agent if the 571 Home Agent has a security association with the domain specified in 572 the Mobile Node's FQDN. 574 On the other hand, if the Mobile Node wants to be reachable through a 575 FQDN that belongs to the MSA, the Home Agent and the DNS server that 576 must be updated belong to different administrative domain. In this 577 case the Home Agent may not share a security association with the DNS 578 server and the DNS entry update can be performed by the AAA server of 579 the MSA. In order to accomplish this, the Home Agent sends to the AAA 580 server the FQDN-HoA pair through the AAA protocol. This message is 581 proxied by the AAA infrastructure of the MSP and is received by the 582 AAA server of the MSA. The AAA server of the MSA perform the DNS 583 update based on [14]. The detailed description of the communication 584 between Home Agent and AAA is out of the scope of this draft. More 585 details are provided in [12]. 587 A mechanism to remove stale DNS entries is needed. A DNS entry 588 becomes stale when the related Home Address is no more used by the 589 Mobile Node. To remove a DNS entry, the MN includes the DNS Update 590 mobility option, with the flag R set in the Binding Update. After 591 receiving the Binding Update, the Home Agent MUST remove the DNS 592 entry identified by the FQDN provided by the Mobile Node and the Home 593 Address included in the Home Address Option. The procedure for 594 sending a dynamic DNS update message is specified in [14]. As 595 mentioned above, the dynamic DNS update SHOULD be performed in a 596 secure way; for this reason, the usage of TKEY and TSEC or DNSSEC is 597 recommended (see section 9.5 for details). 599 This approach does not work if the Mobile Node stops using the Home 600 Address without sending a Binding Update message (e.g. in case of 601 crash). In this case, an additional mechanism to trigger the DNS 602 entry removal is needed. For this purpose, the Home Agent has a timer 603 related to the DNS entry of the Mobile Node. This timer is 604 initialized when the Mobile Node sends a Binding Update with R==0 605 (i.e. when the MN asks the Home Agent to bind the FQDN to the Home 606 Address). The initial value of this timer is configurable by the 607 network operator. 609 If the Home Agent receives a Binding Update with R==1, it removes the 610 DNS entry as described in the previous paragraph and removes the 611 timer associated to that entry. If the timer expires without 612 receiving a Binding Update with R==1, the HA checks the Binding 613 Cache. If there is an existing Binding Cache entry for the HoA, the 614 HA does not remove the DNS entry and re-initialize the timer. If 615 there is not a Binding Cache entry, it sends a Neighbor Soliciation 616 message to check if the MN is at home and is using the HoA. If the HA 617 gets a Neighbor Advertisement message, it does not remove the DNS 618 entry and re-initialize the timer. If it does not receive a NA, it 619 removes the DNS entry and the timer associated to it. 621 7. Summary of Bootstrapping Protocol Flow 623 The message flow of the whole bootstrapping procedure when the 624 dynamic DNS update is performed by the Home Agent is depicted in 625 Figure 3. 627 +----+ +----+ +-----+ 628 | MN | | HA | | DNS | 629 +----+ +----+ +-----+ 631 IKEv2 exchange 632 (HoA configuration) 633 <======================> 635 BU (DNS update option) 636 -----------------------> 637 DNS update 638 <-------------------> 639 BU (DNS update option) 640 <----------------------- 642 Figure 3 - Dynamic DNS update by the HA 644 Figure 4 shows the message flow of the whole bootstrapping procedure 645 when the dynamic DNS update is performed by the AAA server of the 646 MSA. 648 +----+ +----+ +---+ +---+ 649 | MN | | HA | |AAA| |DNS| 650 +----+ +----+ +---+ +---+ 652 IKEv2 exchange 653 (HoA configuration) 654 <======================> 656 BU (DNS update option) 657 -----------------------> 659 AAA request 660 (FQDN, HoA) 661 <--------------> 663 DNS update 664 <-----------> 665 AAA answer 666 (FQDN, HoA) 667 <--------------> 668 BU (DNS update option) 669 <----------------------- 671 Figure 4 - Dynamic DNS update by the AAA 673 Notice that, even in this last case, the Home Agent is always 674 required to perform a DNS update for the reverse entry, since this is 675 always performed in the DNS server of the MSP. This is not depicted 676 in Figure 4. 678 8. Option and Attribute Format 680 8.1. DNS Update mobility option 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Option Type | Option Length | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Status |R| Reserved | MN identity (FQDN) ... 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 o Option Type - DNS-UPDATE-TYPE to be defined by IANA 692 o Option Length - 8 bit unsigned integer indicating the length of 693 the option excluding the type and length fields 695 o Status - 8 bit unsigned integer indicating the result of the 696 dynamic DNS update procedure. This field MUST be set to 0 and 697 ignored by the receiver when the DNS Update mobility option is 698 included in a Binding Update message. When the DNS Update mobility 699 option is included in the Binding Acknowledgement message, values 700 of the Status field less than 128 indicate that the dynamic DNS 701 update was performed successfully by the Home Agent. Values 702 greater than or equal to 128 indicate that the dynamic DNS update 703 was not completed by the HA. The following Status values are 704 currently defined: 706 0 DNS update performed 708 128 Reason unspecified 710 129 Administratively prohibited 712 130 DNS Update Failed 714 o R flag - if set the MN is requesting the HA to remove the DNS 715 entry identified by the FQDN specified in this option and the HoA 716 of the MN. If not set, the MN is requesting the HA to create or 717 update a DNS entry with its HoA and the FQDN specified in the 718 option. 720 o Reserved - these bits are reserved for future purposes and MUST be 721 set to 0. 723 o MN identity - the identity of the Mobile Node to be used by the 724 Home Agent to send a Dynamic DNS update. It is a variable length 725 field. 727 8.2. MIP6_HOME_PREFIX attribute 729 The MIP6_HOME_PREFIX attribute is included in the IKEv2 CFG_REQUEST 730 by the Mobile Node to ask the Home Agent for the home prefix and is 731 included in the CFG_REPLY by the Home Agent to provide the Mobile 732 Node with home prefix and home prefix length. The format of this 733 attribute is equal to the format of the Configuration Attributes 734 defined in [7] and is depicted below. 736 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 !R| Attribute Type ! Length | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | | 742 | home prefix | 743 | | 744 | | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Prefix Length | 747 +-+-+-+-+-+-+-+-+ 749 o Reserved (1 bit) - This bit MUST be set to zero and MUST be 750 ignored on receipt. 752 o Attribute Type (7 bits) - A unique identifier for the 753 MIP6_HOME_PREFIX attribute. To be assigned by IANA. 755 o Length (2 octets) - Length in octets of Value field (home prefix 756 and Prefix Length). This is multi-valued and can be 0 or 17. 758 o Home Prefix (16 octets) - The prefix of the home link through 759 which the Mobile Node must auto-configure its Home Address. 761 o Prefix Length (1 octet) - The length of the home prefix specified 762 in the field Home Prefix. 764 When the MIP6_HOME_PREFIX attribute is included by the Mobile Node in 765 the CFG_REQUEST payload, the value of the Length field is 0. On the 766 other hand, when the MIP6_HOME_PREFIX attribute is included in the 767 CFG_REPLY payload by the Home Agent, the value of the Length field is 768 17 and the attribute contains also the Home Prefix and the Prefix 769 Length fields. 771 9. Security Considerations 773 9.1. HA Address Discovery 775 Use of DNS for address discovery carries certain security risks. DNS 776 transactions in the Internet are typically done without any 777 authentication of the DNS server by the client or of the client by 778 the server. There are two risks involved: 780 1) A legitimate client obtains a bogus Home Agent address from a 781 bogus DNS server. This is sometimes called a "pharming" attack, 783 2) An attacking client obtains a legitimate Home Agent address from a 784 legitimate server. 786 The risk in Case 1 is mitigated because the Mobile Node is required 787 to conduct an IKE transaction with the Home Agent prior to performing 788 a Binding Update to establish Mobile IPv6 service. According to the 789 IKEv2 specification [7], the responder must present the initiator 790 with a valid certificate containing the responder's public key, and 791 the responder to initiator IKE_AUTH message must be protected with an 792 authenticator calculated using the public key in the certificate. 793 Thus, an attacker would have to set up both a bogus DNS server and a 794 bogus Home Agent, and provision the Home Agent with a certificate 795 that a victim Mobile Node could verify. If the Mobile Node can detect 796 that the certificate is not trustworthy, the attack will be foiled 797 when the Mobile Node attempts to set up the IKE SA. 799 The risk in Case 2 is limited for a single Mobile Node to Home Agent 800 transaction if the attacker does not possess proper credentials to 801 authenticate with the Home Agent. The IKE SA establishment will fail 802 when the attacking Mobile Node attempts to authenticate itself with 803 the Home Agent. Regardless of whether the Home Agent utilizes EAP or 804 host-side certificates to authenticate the Mobile Node, the 805 authentication will fail unless the Mobile Node has valid 806 credentials. 808 Another risk exists in Case 2 because the attacker may be attempting 809 to propagate a DoS attack on the Home Agent. In that case, the 810 attacker obtains the Home Agent address from the DNS, then propagates 811 the address to a network of attacking hosts that bombard the Home 812 Agent with traffic. This attack is not unique to the bootstrapping 813 solution, however, it is actually a risk that any Mobile IPv6 Home 814 Agent installation faces. In fact, the risk is faced by any service 815 in the Internet that distributes a unicast globally routable address 816 to clients. Since Mobile IPv6 requires that the Mobile Node 817 communicate through a globally routable unicast address of a Home 818 Agent, it is possible that the Home Agent address could be propagated 819 to an attacker by various means (theft of the Mobile Node, malware 820 installed on the Mobile Node, evil intent of the Mobile Node owner 821 him/herself, etc.) even if the home address is manually configured on 822 the Mobile Node. Consequently, every Mobile IPv6 Home Agent 823 installation will likely be required to mount anti-DoS measures. Such 824 measures include overprovisioning of links to and from Home Agents 825 and of Home Agent processing capacity, vigilant monitoring of traffic 826 on the Home Agent networks to detect when traffic volume increases 827 abnormally indicating a possible DoS attack, and hot spares that can 828 quickly be switched on in the event an attack is mounted on an 829 operating collection of Home Agents. DoS attacks of moderate 830 intensity should be foiled during the IKEv2 transaction. IKEv2 831 implementations are expected to generate their cookies without any 832 saved state, and to time out cookie generation parameters frequently, 833 with the timeout value increasing if a DoS attack is suspected. This 834 should prevent state depletion attacks, and should assure continued 835 service to legitimate clients until the practical limits on the 836 network bandwith and processing capacity of the Home Agent network 837 are reached. 839 Explicit security measures between the DNS server and host, such 840 DNSSEC [16] or TSIG/TKEY [17] [18] can mitigate the risk of 1) and 841 2), but these security measures are not widely deployed on end nodes. 842 These security measures are not sufficient to protect the Home Agent 843 address against DoS attack, however, because a node having a 844 legitimate security association with the DNS server could 845 nevertheless intentionally or inadvertently cause the Home Agent 846 address to become the target of DoS. 848 Security considerations for discovering HA using DHCP are covered in 849 draft-jang-dhc-haopt-01 [15]. 851 9.2. Home Address Assignment through IKEv2 853 Mobile IPv6 bootstrapping assigns the home address through the IKEv2 854 transaction. The Mobile Node can either choose to request an address, 855 similar to DHCP, or the Mobile Node can request a prefix on the home 856 link then autoconfigure an address. 858 RFC 3775 [2] and 3776 [3] require that a Home Agent check 859 authorization on a home address received during a Binding Update. The 860 Home Agent MUST set up authorization by linking the home address to 861 the identity of the IPsec SAs used to authenticate the Binding Update 862 message. The linking MUST be done either during the IKE_AUTH phase or 863 CREATE_CHILD_SA phase when the IPsec SAs are constructed. 865 If the address is autoconfigured, RFC 3775 requires the Home Agent to 866 proxy-defend the address on the home link after the Mobile Node 867 performs the initial Binding Update. Since it is not currently 868 possible to securely proxy CGAs using SEND, attacks on address 869 resolution for Neighbor Discovery listed in RFC 3756 are possible on 870 dynamically assigned home addresses that are proxied by the Home 871 Agent. 873 9.3. SA Establishment Using EAP Through IKEv2 875 Security considerations for authentication of the IKE transaction 876 using EAP are covered in draft-ietf-mip6-ikev2-ipsec [6]. 878 9.4. Back End Security Between the HA and AAA Server 880 Some deployments of Mobile IPv6 bootstrapping may use an AAA server 881 to handle authorization for mobility service. This process has its 882 own security requirements, but the back end protocol for Home Agent 883 to AAA server interface is not covered in this draft. Please see 884 draft-ietf-mip6-aaa-ha-goals [12] for a discussion of this interface. 886 9.5. Dynamic DNS Update 888 Mobile IPv6 bootstrapping recommends the Home Agent to update the 889 Mobile Node's FQDN with a dynamically assigned home address rather 890 than have the Mobile Node itself do it (see Section 6 above). This 891 choice was motivated by a concern for preventing redirection-based 892 flooding attacks (see draft-ietf-mip6-ro-sec [19] for more 893 information about redirection-based flooding attacks and the role 894 preventing them played in the design of Mobile IPv6 route 895 optimization security). Exactly as for route optimization, it is 896 possible for a node that is the legitimate owner of a DNS FQDN - in 897 the sense that it has a security association with the DNS server 898 allowing it to perform dynamic DNS update of its FQDN - to bind its 899 FQDN to the address of a victim, then redirect large volumes of 900 traffic at the victim. The attack may be propagated without the 901 owner's knowledge, for example, if the node is compromised by 902 malware, or it may be intentional if the node itself is the attacker. 904 While it is possible to prevent redirection attacks through ingress 905 filtering on access routers, ISPs have little or no incentive to 906 deploy ingress filtering. In some cases, if an attack could result in 907 substantial financial gain, it is even possible that a corrupt ISP 908 may have an incentive not to deploy ingress filters such as has been 909 the case for spam. Consequently, the security for dynamic Mobile Node 910 FQDN update has been assigned to the Home Agent, where active network 911 administration and vigilant defense measures are more likely to (but 912 are not assured of) mitigating problems, and the owner of the Mobile 913 Node is more likely to detect a problem if it occurs. 915 If a Home Agent performs dynamic DNS update on behalf of the Mobile 916 Node directly with the DNS server, the Home Agent MUST have a 917 security association of some type with the DNS server. The security 918 association MAY be established either using DNSSEC [16] or TSIG/TKEY 919 [17][18]. A security association is required even if the DNS server 920 is in the same administrative domain as the Home Agent. The security 921 association SHOULD be separate from the security associations used 922 for other purposes, such as AAA. 924 In the case where the Mobility Service Provider is different from the 925 Mobility Service Authorizer, the network administrators may want to 926 limit the number of cross-administrative domain security 927 associations. If the Mobile Node's FQDN is in the Mobility Service 928 Authorizer's domain, since a security association for AAA signaling 929 involved in mobility service authorization is required in any case, 930 the Home Agent can send the Mobile Node's FQDN to the AAA server 931 under the HA-AAA server security association, and the AAA server can 932 perform the update. In that case, a security association is required 933 between the AAA server and DNS server for the dynamic DNS update. See 934 draft-ietf-mip6-aaa-ha-goals [12] for a deeper discussion of the Home 935 Agent to AAA server interface. 937 Regardless of whether the AAA server or Home Agent performs DNS 938 update, the authorization of the Mobile Node to update a FQDN MUST be 939 checked prior to the performance of the update. It is an 940 implementation issue as to how authorization is determined. 942 10. IANA Considerations 944 This document defines a new Mobility Option and a new IKEv2 945 Configuration Attribute Type. 947 The following values should be assigned: 949 o from "Mobility Option" namespace ([2]): DNS-UPDATE-TYPE (section 950 8.1) 952 o from "IKEv2 Configuration Payload Attribute Types" namespace 953 ([7]): MIP6_HOME_PREFIX attribute (section 8.2) 955 o from "IKEv2 Notify Payload Error Types" namespace ([7]): 956 USE_ASSIGNED_HoA error type (section 5.3.2) 958 11. Contributors 960 This contribution is a joint effort of the bootstrapping solution 961 design team of the MIP6 WG. The contributors include Basavaraj 962 Patil, Alpesh Patel, Jari Arkko, James Kempf, Yoshihiro Ohba, Gopal 963 Dommety, Alper Yegin, Junghoon Jee, Vijay Devarapalli, Kuntal 964 Chowdury, Julien Bournelle. 966 The design team members can be reached at: 968 Gerardo Giaretta gerardo.giaretta@tilab.com 970 Basavaraj Patil basavaraj.patil@nokia.com 972 Alpesh Patel alpesh@cisco.com 974 Jari Arkko jari.arkko@kolumbus.fi 976 James Kempf kempf@docomolabs-usa.com 978 Yoshihiro Ohba yohba@tari.toshiba.com 980 Gopal Dommety gdommety@cisco.com 982 Alper Yegin alper.yegin@samsung.com 984 Vijay Devarapalli vijayd@iprg.nokia.com 986 Kuntal Chowdury kchowdury@starentnetworks.com 988 Junghoon Jee jhjee@etri.re.kr 990 Julien Bournelle julien.bournelle@int-evry.fr 992 12. References 994 12.1. Normative References 996 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 997 Levels", BCP 14, RFC 2119, March 1997. 999 [2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 1000 in IPv6", RFC 3775, June 2004. 1002 [3] Arkko, J., Devarapalli, V., Dupont, F., "Using IPsec to 1003 Protect Mobile IPv6 Signaling between Mobile Nodes and 1004 Home Agents", RFC 3776, June 2004 1006 [4] Patel, A., "Problem Statement for bootstrapping Mobile IPv6", 1007 Internet-Draft draft-ietf-mip6-bootstrap-ps-02, March 2005. 1009 [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 1010 specifying the location of services (DNS SRV)", RFC 2782, 1011 February 2000. 1013 [6] Devarapalli, V., " Mobile IPv6 Operation with IKEv2 and the 1014 revised IPsec Architecture", Internet-Draft draft-ietf-mip6- 1015 ikev2-ipsec-01, February 2005. 1017 [7] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1019 12.2. Informative References 1021 [8] Manner, J., Kojo, M. "Mobility Related Terminology", RFC 3753, 1022 June 2004. 1024 [9] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 1025 3972, March 2005. 1027 [10] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions for 1028 Stateless Address Autoconfiguration in IPv6", Internet-Draft 1029 draft-ietf-ipv6-privacy-addrs-v2-03, April 2005. 1031 [11] Droms, R., Ed., "DNS Configuration options for Dynamic Host 1032 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 1033 2003. 1035 [12] Giaretta, G., Ed. "Goals for AAA-HA interface", Internet-Draft 1036 draft-ietf-mip6-aaa-ha-goals-00, April 2005. 1038 [13] Koodli, R., Devarapalli, V., Perkins, C., Flinck, H., 1039 "Solutions for IP Address Location Privacy in the presence of 1040 IP Mobility", Internet-Draft, draft-koodli-mip6-location- 1041 privacy-solutions-00, February 2005. 1043 [14] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. "Dynamic 1044 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1045 April 1997. 1047 [15] Jang, H.J., Yegin, A., Choi, J., "DHCP Option for Home Agent 1048 Discovery in MIPv6", Internet-Draft, draft-jang-dhc-haopt-01, 1049 April 2005. 1051 [16] Arends, R., Austein, R., Larson, M., Massey, D., Rose, S., "DNS 1052 Security Introduction and Requirements", RFC 4033, March 2005. 1054 [17] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., Wellington, B., 1055 "Secret Key Transaction Authentication for DNS (TSIG)", RFC 1056 2845, May 2000. 1058 [18] Eastlake 3rd, D., " Secret Key Establishment for DNS (TKEY 1059 RR)", RFC 2930, September 2000. 1061 [19] Nikander, P., Arkko, J., Aura, T., Montenegro, G., Nordmark, 1062 E., "Mobile IP version 6 Route Optimization Security Design 1063 Background", Internet-Draft, draft-ietf-mip6-ro-sec-02, October 1064 2004. 1066 [20] Narten, T., Nordmark, E., Simpson, W., Soliman, H., "Neighbor 1067 Discovery for IP version 6 (IPv6)"`, Internet-Draft, draft- 1068 ietf-ipv6-2461bis-03, May 2005. 1070 Authors' Addresses 1072 Gerardo Giaretta 1073 Telecom Italia Lab 1074 via Reiss Romoli 274 1075 10148 Torino 1076 Italy 1078 Phone: +39 011 228 6904 1079 Email: gerardo.giaretta@tilab.com 1081 James Kempf 1082 DoCoMo Labs USA 1083 181 Metro Drive 1084 Suite 300 1085 San Jose, CA, 95110 1086 USA 1088 Phone: +1 408 451 4711 1089 Email: kempf@docomolabs-usa.com 1091 Vijay Devarapalli 1092 Nokia Research Center 1093 313 Fairchild Drive 1094 Mountain View, CA 94043 1095 USA 1097 Email: vijay.devarapalli@nokia.com 1099 Intellectual Property Statement 1101 The IETF takes no position regarding the validity or scope of any 1102 Intellectual Property Rights or other rights that might be claimed to 1103 pertain to the implementation or use of the technology described in 1104 this document or the extent to which any license under such rights 1105 might or might not be available; nor does it represent that it has 1106 made any independent effort to identify any such rights. Information 1107 on the procedures with respect to rights in RFC documents can be 1108 found in BCP 78 and BCP 79. 1110 Copies of IPR disclosures made to the IETF Secretariat and any 1111 assurances of licenses to be made available, or the result of an 1112 attempt made to obtain a general license or permission for the use of 1113 such proprietary rights by implementers or users of this 1114 specification can be obtained from the IETF on-line IPR repository at 1115 http://www.ietf.org/ipr. 1117 The IETF invites any interested party to bring to its attention any 1118 copyrights, patents or patent applications, or other proprietary 1119 rights that may cover technology that may be required to implement 1120 this standard. Please address the information to the IETF at 1121 ietf-ipr@ietf.org 1123 Disclaimer of Validity 1125 This document and the information contained herein are provided on an 1126 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1127 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1128 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1129 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1130 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1131 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1133 Copyright Statement 1135 Copyright (C) The Internet Society (2005). 1137 This document is subject to the rights, licenses and restrictions 1138 contained in BCP 78, and except as set forth therein, the authors 1139 retain all their rights. 1141 Acknowledgment 1143 Funding for the RFC Editor function is currently provided by the 1144 Internet Society.