idnits 2.17.1 draft-ietf-v6ops-addr-select-ps-08.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 735. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 12, 2008) is 5768 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations Working Group A. Matsumoto 3 Internet-Draft T. Fujisaki 4 Intended status: Informational NTT 5 Expires: December 14, 2008 R. Hiromi 6 Intec Netcore 7 K. Kanayama 8 INTEC Systems 9 June 12, 2008 11 Problem Statement of Default Address Selection in Multi-prefix 12 Environment: Operational Issues of RFC3484 Default Rules 13 draft-ietf-v6ops-addr-select-ps-08.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in 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 December 14, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 A single physical link can have multiple prefixes assigned to it. In 47 that environment, end hosts might have multiple IP addresses and be 48 required to use them selectively. RFC 3484 defines default source 49 and destination address selection rules and is implemented in a 50 variety of OS's. But, it has been too difficult to use operationally 51 for several reasons. In some environment where multiple prefixes are 52 assigned on a single physical link, the host using the default 53 address selection rules will experience some trouble in 54 communication. This document describes the possible problems that 55 end hosts could encounter in an environment with multiple prefixes. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3 61 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Source Address Selection . . . . . . . . . . . . . . . . . 4 63 2.1.1. Multiple Routers on Single Interface . . . . . . . . . 4 64 2.1.2. Ingress Filtering Problem . . . . . . . . . . . . . . 5 65 2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 6 66 2.1.4. Combined Use of Global and ULA . . . . . . . . . . . . 7 67 2.1.5. Site Renumbering . . . . . . . . . . . . . . . . . . . 8 68 2.1.6. Multicast Source Address Selection . . . . . . . . . . 9 69 2.1.7. Temporary Address Selection . . . . . . . . . . . . . 9 70 2.2. Destination Address Selection . . . . . . . . . . . . . . 10 71 2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 10 72 2.2.2. ULA and IPv4 dual-stack environment . . . . . . . . . 11 73 2.2.3. ULA or Global Prioritization . . . . . . . . . . . . . 12 74 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 79 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 80 Appendix A. Appendix. Revision History . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 82 Intellectual Property and Copyright Statements . . . . . . . . . . 17 84 1. Introduction 86 In IPv6, a single physical link can have multiple prefixes assigned 87 to it. In such cases, an end-host may have multiple IP addresses 88 assigned to an interface on that link. In the IPv4-IPv6 dual stack 89 environment or in a site connected to both a ULA [RFC4193] and 90 Globally routable networks, an end-host typically has multiple IP 91 addresses. These are examples of the networks that we focus on in 92 this document. In such an environment, an end-host may encounter 93 some communication troubles. 95 Inappropriate source address selection at the end-host causes 96 unexpected asymmetric routing, filtering by a router or discarding of 97 packets bacause there is no route to the host. 99 Considering a multi-prefix environment, destination address selection 100 is also important for correct or better communication establishment. 102 RFC 3484 [RFC3484] defines default source and destination address 103 selection algorithms and is implemented in a variety of OS's. But, 104 it has been too difficult to use operationally for several reasons, 105 such as lack of autoconfiguration method. There are some problematic 106 cases where the hosts using the default address selection rules 107 encounter communication troubles. 109 This document describes such possibilities of incorrect address 110 selection which leads to dropping packets and communication failure. 112 1.1. Scope of this document 114 As other mechanisms already exist, the multi-homing techniques for 115 achieving redundancy are basically out of our scope. 117 We focus on an end-site network environment and unmanaged hosts in 118 such an environment. This is because address selection behavior at 119 this kind of hosts is difficult to manipulate owing to the users's 120 lack of knowledge, hosts' location, or massiveness of the hosts. 122 The scope of this document is to sort out problematic cases related 123 to address selection. It includes problems that can be solved in the 124 framework of RFC 3484 and problems that cannot. For the latter, RFC 125 3484 might be modified to meet their needs, or another address 126 selection solution might be necessary. For the former, an additional 127 mechanism that mitigates the operational difficulty might be 128 necessary. 130 This document also includes simple solution analysis for each 131 problematic case. This analysis basically just focuses on whether 132 the case can be solved in the framework of RFC 3484 or not. If not, 133 some possible solutions are described. Even if a case can be solved 134 in the framework of RFC 3484, as mentioned above, it does not 135 necessarily mean that there is no operational difficulty. For 136 example, in the environment stated above, it is not a feasible 137 solution to configure each host's policy table by hand. So, for such 138 an solution, configuration pain is yet another common problem. 140 2. Problem Statement 142 2.1. Source Address Selection 144 2.1.1. Multiple Routers on Single Interface 146 ================== 147 | Internet | 148 ================== 149 | | 150 2001:db8:1000::/36 | | 2001:db8:8000::/36 151 +----+-+ +-+----+ 152 | ISP1 | | ISP2 | 153 +----+-+ +-+----+ 154 | | 155 2001:db8:1000:::/48 | | 2001:db8:8000::/48 156 +-----+---+ +----+----+ 157 | Router1 | | Router2 | 158 +-------+-+ +-+-------+ 159 | | 160 2001:db8:1000:1::/64 | | 2001:db8:8000:1::/64 161 | | 162 -----+-+-----+------ 163 | 164 +-+----+ 2001:db8:1000:1::100 165 | Host | 2001:db8:8000:1::100 166 +------+ 168 [Fig. 1] 170 Generally speaking, there is no interaction between next-hop 171 determination and address selection. In this example, when a host 172 starts a new connection and sends a packet via Router1, the host does 173 not necessarily choose address 2001:db8:1000:1::100 given by Router1 174 as the source address. This causes the same problem as described in 175 the next section 'Ingress Filtering Problem'. 177 Solution analysis: 179 As this case depends on next hop selection, controling the address 180 selection behavior at Host alone doesn't solve the entire problem. 181 One possible solution for this case is adopting source address 182 based routing at Router1 and Router2. Another solution may be 183 using static routing at Router1, Router2 and Host, and using the 184 corresponding static address selection policy at Host. 186 2.1.2. Ingress Filtering Problem 188 ================== 189 | Internet | 190 ================== 191 | | 192 2001:db8:1000::/36 | | 2001:db8:8000::/36 193 +----+-+ +-+----+ 194 | ISP1 | | ISP2 | 195 +----+-+ +-+----+ 196 | | 197 2001:db8:1000:::/48 | | 2001:db8:8000::/48 198 ++-------++ 199 | Router | 200 +----+----+ 201 | 2001:db8:1000:1::/64 202 | 2001:db8:8000:1::/64 203 ------+---+---------- 204 | 205 +-+----+ 2001:db8:1000:1::100 206 | Host | 2001:db8:8000:1::100 207 +------+ 209 [Fig. 2] 211 When a relatively small site, which we call a "customer network", is 212 attached to two upstream ISPs, each ISP delegates a network address 213 block, which is usually /48, and a host has multiple IPv6 addresses. 215 When the source address of an outgoing packet is not the one that is 216 delegated by an upstream ISP, there is a possibility that the packet 217 will be dropped at the ISP by its Ingress Filter. Ingress filtering 218 is becoming more popular among ISPs to mitigate the damage of DoS 219 attacks. 221 In this example, when the Router chooses the default route to ISP2 222 and the Host chooses 2001:db8:1000:1::100 as the source address for 223 packets sent to a host (2001:db8:2000::1) somewhere on the Internet, 224 the packets may be dropped at ISP2 because of Ingress Filtering. 226 Solution analysis: 228 One possible solution for this case is adopting source address 229 based routing at Router. Another solution may be using static 230 routing at Router, and using the corresponding static address 231 selection policy at Host. 233 2.1.3. Half-Closed Network Problem 235 You can see a second typical source address selection problem in a 236 multihome site with global-closed mixed connectivity like in the 237 figure below. In this case, Host-A is in a multihomed network and 238 has two IPv6 addresses, one delegated from each of the upstream ISPs. 239 Note that ISP2 is a closed network and does not have connectivity to 240 the Internet. 242 +--------+ 243 | Host-C | 2001:db8:a000::1 244 +-----+--+ 245 | 246 ============== +--------+ 247 | Internet | | Host-B | 2001:db8:8000::1 248 ============== +--------+ 249 | | 250 2001:db8:1000:/36 | | 2001:db8:8000::/36 251 +----+-+ +-+---++ 252 | ISP1 | | ISP2 | (Closed Network/VPN tunnel) 253 +----+-+ +-+----+ 254 | | 255 2001:db8:1000:/48 | | 2001:db8:8000::/48 256 ++-------++ 257 | Router | 258 +----+----+ 259 | 2001:db8:1000:1::/64 260 | 2001:db8:8000:1::/64 261 ------+---+---------- 262 | 263 +--+-----+ 2001:db8:1000:1::100 264 | Host-A | 2001:db8:8000:1::100 265 +--------+ 267 [Fig. 3] 269 You do not need two physical network connections here. The 270 connection from the Router to ISP2 can be a logical link over ISP1 271 and the Internet. 273 When Host-A starts the connection to Host-B in ISP2, the source 274 address of a packet that has been sent will be the one delegated from 275 ISP2, that is 2001:db8:8000:1::100, because of rule 8 (longest 276 matching prefix) in RFC 3484. 278 Host-C is located somewhere on the Internet and has IPv6 address 279 2001:db8:a000::1. When Host-A sends a packet to Host-C, the longest 280 matching algorithm chooses 2001:db8:8000:1::100 for the source 281 address. In this case, the packet goes through ISP1 and may be 282 filtered by ISP1's ingress filter. Even if the packet is not 283 filtered by ISP1, a return packet from Host-C cannot possibly be 284 delivered to Host-A because the return packet is destined for 2001: 285 db8:8000:1::100, which is closed from the Internet. 287 The important point is that each host chooses a correct source 288 address for a given destination address. To solve this kind of 289 network policy based address selection problems, it is likely that 290 delivering addtional information to a node fits better than 291 algorithmic solutions that are local to the node. 293 Solution analysis: 294 This problem can be solved in the RFC 3484 framework. For 295 example, configuring some address selection policies into Host-A's 296 RFC 3484 policy table can solve this problem. 298 2.1.4. Combined Use of Global and ULA 300 ============ 301 | Internet | 302 ============ 303 | 304 | 305 +----+----+ 306 | ISP | 307 +----+----+ 308 | 309 2001:db8:a::/48 | 310 +----+----+ 311 | Router | 312 +-+-----+-+ 313 | | 2001:db8:a:100::/64 314 fd01:2:3:200:/64 | | fd01:2:3:100:/64 315 -----+--+- -+--+---- 316 | | 317 fd01:2:3:200::101 | | 2001:db8:a:100::100 318 +----+----+ +-+----+ fd01:2:3:100::100 319 | Printer | | Host | 320 +---------+ +------+ 322 [Fig. 4] 324 As RFC 4864 [RFC4864] describes, using a ULA may be beneficial in 325 some scenarios. If the ULA is used for internal communication, 326 packets with ULA need to be filtered at the Router. 328 This case does not presently create an address selection problem 329 because of the dissimilarity between the ULA and the Global Unicast 330 Address. The longest matching rule of RFC 3484 chooses the correct 331 address for both intra-site and extra-site communication. 333 In the future, however, there is a possibility that the longest 334 matching rule will not be able to choose the correct address anymore. 335 That is the moment when the assignment of those Global Unicast 336 Addresses starts, where the first bit is 1. In RFC 4291 [RFC4291], 337 almost all address spaces of IPv6, including those whose first bit is 338 1, are assigned as Global Unicast Addresses. 340 Namely, when we start to assign a part of the address block 8000::/1 341 as the global unicast address and that part is used somewhere in the 342 Internet, the longest matching rule ceases to function properly for 343 the people trying to connect to the servers with those addresses. 345 For example, when the destination host has an IPv6 address 8000::1, 346 and the originating host has 2001:db8::1 and fd0:1::1, the source 347 address will be fd00:1::1, because the longest matching bit length is 348 0 for 2001:db8::1 and 1 for fd0:1::1 respectively. 350 Solution analysis: 351 This problem can be solved in the RFC 3484 framework. For 352 example, configuring some address selection policies into Host's 353 RFC 3484 policy table can solve this problem. Another solution is 354 to modify RFC 3484 and define ULA's scope smaller than the global 355 scope. 357 2.1.5. Site Renumbering 359 RFC 4192 [RFC4192] describes a recommended procedure for renumbering 360 a network from one prefix to another. An autoconfigured address has 361 a lifetime, so by stopping advertisement of the old prefix, the 362 autoconfigured address is eventually invalidated. 364 However, invalidating the old prefix takes a long time. You cannot 365 stop routing to the old prefix as long as the old prefix is not 366 removed from the host. This can be a tough issue for ISP network 367 administrators. 369 There is a technique of advertising the prefix with the preferred 370 lifetime zero, however, RFC 4862 [RFC4862] 5.5.4 does not absolutely 371 prohibit the use of a deprecated address for a new outgoing 372 connection due to limitations relating to what applications are 373 capable of doing." 375 +-----+---+ 376 | Router | 377 +----+----+ 378 | 2001:db8:b::/64 (new) 379 | 2001:db8:a::/64 (old) 380 ------+---+---------- 381 | 382 +--+---+ 2001:db8:b::100 (new) 383 | Host | 2001:db8:a::100 (old) 384 +------+ 386 [Fig. 5] 388 Solution analysis: 389 This problem can be mitigated in the RFC 3484 framework. For 390 example, configuring some address selection policies into Host's 391 RFC 3484 policy table can solve this problem. 393 2.1.6. Multicast Source Address Selection 395 This case is an example of site-local or global prioritization. When 396 you send a multicast packet across site-borders, the source address 397 of the multicast packet should be a globally routable address. The 398 longest matching algorithm, however, selects a ULA if the sending 399 host has both a ULA and a Global Unicast Address. 401 Solution analysis: 402 This problem can be solved in the RFC 3484 framework. For 403 example, configuring some address selection policies into the 404 sending host's RFC 3484 policy table can solve this problem. 406 2.1.7. Temporary Address Selection 408 RFC 3041 [RFC3041] defines a Temporary Address. The usage of a 409 Temporary Address has both pros and cons. That is good for viewing 410 web pages or communicating with the general public, but that is bad 411 for a service that uses address-based authentication and for logging 412 purposes. 414 If you could turn the temporary address on and off, that would be 415 better. If you could switch its usage per service (destination 416 address), that would also be better. The same situation can be found 417 when using HA (home address) and CoA (care-of address)in a Mobile 418 IPv6 [RFC3775] network. 420 The Future Work section in RFC 3041 discusses that an API extension 421 might be necessary to achieve a better address selection mechanism 422 with finer granularity. 424 Solution analysis: 425 This problem can not be solved in the RFC 3484 framework. A 426 possible solution is to make applications to select desirable 427 addresses by using the IPv6 Socket API for Source Address 428 Selection defind in RFC 5014 [RFC5014]. 430 2.2. Destination Address Selection 432 2.2.1. IPv4 or IPv6 prioritization 434 The default policy table gives IPv6 addresses higher precedence than 435 IPv4 addresses. There seem to be many cases, however, where network 436 administrators want to control the address selection policy of end- 437 hosts the other way around. 439 +---------+ 440 | Tunnel | 441 | Service | 442 +--+---++-+ 443 | || 444 | || 445 ===========||== 446 | Internet || | 447 ===========||== 448 | || 449 192.0.2.0/24 | || 450 +----+-+ || 451 | ISP | || 452 +----+-+ || 453 | || 454 IPv4 (Native) | || IPv6 (Tunnel) 455 192.0.2.0/26 | || 456 ++-----++-+ 457 | Router | 458 +----+----+ 459 | 2001:db8:a:1::/64 460 | 192.0.2.0/28 461 | 462 ------+---+---------- 463 | 464 +-+----+ 2001:db8:a:1::100 465 | Host | 192.0.2.2 466 +------+ 468 [Fig. 6] 470 In the figure above, a site has native IPv4 and tunneled-IPv6 471 connectivity. Therefore, the administrator may want to set a higher 472 priority for using IPv4 than using IPv6 because the quality of the 473 tunnel network seems to be worse than that of the native transport. 475 Solution analysis: 476 This problem can be solved in the RFC 3484 framework. For 477 example, configuring some address selection policies into Host's 478 RFC 3484 policy table can solve this problem. 480 2.2.2. ULA and IPv4 dual-stack environment 482 This is a special form of IPv4 and IPv6 prioritization. When an 483 enterprise has IPv4 Internet connectivity but does not yet have IPv6 484 Internet connectivity, and the enterprise wants to provide site-local 485 IPv6 connectivity, a ULA is the best choice for site-local IPv6 486 connectivity. Each employee host will have both an IPv4 global or 487 private address and a ULA. Here, when this host tries to connect to 488 Host-B that has registered both A and AAAA records in the DNS, the 489 host will choose AAAA as the destination address and the ULA for the 490 source address. This will clearly result in a connection failure. 492 +--------+ 493 | Host-B | AAAA = 2001:db8::80 494 +-----+--+ A = 192.0.2.1 495 | 496 ============ 497 | Internet | 498 ============ 499 | no IPv6 connectivity 500 +----+----+ 501 | Router | 502 +----+----+ 503 | 504 | fd01:2:3::/48 (ULA) 505 | 192.0.2.128/25 506 ++--------+ 507 | Router | 508 +----+----+ 509 | fd01:2:3:4::/64 (ULA) 510 | 192.0.2.240/28 511 ------+---+---------- 512 | 513 +-+------+ fd01:2:3:4::100 (ULA) 514 | Host-A | 192.0.2.245 515 +--------+ 517 [Fig. 7] 519 Solution analysis: 520 This problem can be solved in the RFC 3484 framework. For 521 example, configuring some address selection policies into Host-A's 522 RFC 3484 policy table can solve this problem. 524 2.2.3. ULA or Global Prioritization 526 Differentiating services by the client's source address is very 527 common. IP-address-based authentication is an typical example of 528 this. Another typical example is a web service that has pages for 529 the public and internal pages for employees or involved parties. Yet 530 another example is DNS zone splitting. 532 However, a ULA and IPv6 global address both have global scope, and 533 RFC3484 default rules do not specify which address should be given 534 priority. This point makes IPv6 implementation of address-based 535 service differentiation a bit harder. 537 +--------+ 538 | Host-B | 539 +-+--|---+ 540 | | 541 ===========|== 542 | Internet | | 543 ===========|== 544 | | 545 | | 546 +----+-+ +-->+------+ 547 | ISP +------+ DNS | 2001:db8:a::80 548 +----+-+ +-->+------+ fc12:3456:789a::80 549 | | 550 2001:db8:a::/48 | | 551 fc12:3456:789a::/48 | | 552 +----+----|+ 553 | Router || 554 +---+-----|+ 555 | | 2001:db8:a:100::/64 556 | | fc12:3456:789a:100::/64 557 --+-+---|----- 558 | | 559 +-+---|--+ 2001:db8:a:100::100 560 | Host-A | fc12:3456:789a:100::100 561 +--------+ 563 [Fig. 7] 565 Solution analysis: 566 This problem can be solved in the RFC 3484 framework. For 567 example, configuring some address selection policies into Host-A's 568 RFC 3484 policy table can solve this problem. 570 3. Conclusion 572 We have covered problems related to destination or source address 573 selection. These problems have their roots in the situation where 574 end-hosts have multiple IP addresses. In this situation, every end- 575 host must choose an appropriate destination and source address, which 576 cannot be achieved only by routers. 578 It should be noted that end-hosts must be informed about routing 579 policies of their upstream networks for appropriate address 580 selection. A site administrator must consider every possible address 581 false-selection problem and take countermeasures beforehand. 583 4. Security Considerations 585 When an intermediate router performs policy routing (e.g. source 586 address based routing), inappropriate address selection causes 587 unexpected routing. For example, in the network described in 2.1.3, 588 when Host-A uses a default address selection policy and chooses an 589 inappropriate address, a packet sent to VPN can be delivered to a 590 location via the Internet. This issue can lead to packet 591 eavesdropping or session hijack. However, sending the packet back to 592 the correct path from the attacker to the node is not easy, so these 593 two risks are not serious. 595 As documented in the security consideration section in RFC 3484, 596 address selection algorithms expose a potential privacy concern. 597 When a malicious host can make a target host perform address 598 selection, for example by sending a anycast or a multicast packet, 599 the malicious host can get knowledge multiple addresses attached to 600 the target host. In a case like 2.1.4, if an attacker can make Host 601 to send a multicast packet and Host performs the default address 602 selection algorithm, the attacker may be able to determine the ULAs 603 attached to the Host. 605 These security risks have roots in inappropriate address selection. 606 Therefore, if a countermeasure is taken, and hosts always select an 607 appropriate address that is suitable to a site's network structure 608 and routing, these risks can be avoided. 610 5. IANA Considerations 612 This document has no actions for IANA. 614 6. References 616 6.1. Normative References 618 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 619 Stateless Address Autoconfiguration in IPv6", RFC 3041, 620 January 2001. 622 [RFC3484] Draves, R., "Default Address Selection for Internet 623 Protocol version 6 (IPv6)", RFC 3484, February 2003. 625 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 626 in IPv6", RFC 3775, June 2004. 628 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 629 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 630 September 2005. 632 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 633 Addresses", RFC 4193, October 2005. 635 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 636 Architecture", RFC 4291, February 2006. 638 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 639 Address Autoconfiguration", RFC 4862, September 2007. 641 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 642 E. Klein, "Local Network Protection for IPv6", RFC 4864, 643 May 2007. 645 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 646 Socket API for Source Address Selection", RFC 5014, 647 September 2007. 649 6.2. Informative References 651 Appendix A. Appendix. Revision History 653 01: 654 IP addresse notations changed to documentation address. 655 Description of solutions deleted. 656 02: 657 Security considerations section rewritten according to comments 658 from SECDIR. 659 03: 660 Intended status changed to Informational. 661 04: 662 This version reflects comments from IESG members. 663 05: 664 This version reflects comments from IESG members and Bob Hinden. 665 06: 666 This version reflects comments from Thomas Narten. 667 07: 668 This version reflects comments from Alfred Hoenes. 669 08: 670 Solution analysis for the section 2.1.6 was added. 672 Authors' Addresses 674 Arifumi Matsumoto 675 NTT PF Lab 676 Midori-Cho 3-9-11 677 Musashino-shi, Tokyo 180-8585 678 Japan 680 Phone: +81 422 59 3334 681 Email: arifumi@nttv6.net 683 Tomohiro Fujisaki 684 NTT PF Lab 685 Midori-Cho 3-9-11 686 Musashino-shi, Tokyo 180-8585 687 Japan 689 Phone: +81 422 59 7351 690 Email: fujisaki@nttv6.net 692 Ruri Hiromi 693 Intec Netcore, Inc. 694 Shinsuna 1-3-3 695 Koto-ku, Tokyo 136-0075 696 Japan 698 Phone: +81 3 5665 5069 699 Email: hiromi@inetcore.com 701 Ken-ichi Kanayama 702 INTEC Systems Institute, Inc. 703 Shimoshin-machi 5-33 704 Toyama-shi, Toyama 930-0804 705 Japan 707 Phone: +81 76 444 8088 708 Email: kanayama_kenichi@intec-si.co.jp 710 Full Copyright Statement 712 Copyright (C) The IETF Trust (2008). 714 This document is subject to the rights, licenses and restrictions 715 contained in BCP 78, and except as set forth therein, the authors 716 retain all their rights. 718 This document and the information contained herein are provided on an 719 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 720 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 721 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 722 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 723 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 724 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 726 Intellectual Property 728 The IETF takes no position regarding the validity or scope of any 729 Intellectual Property Rights or other rights that might be claimed to 730 pertain to the implementation or use of the technology described in 731 this document or the extent to which any license under such rights 732 might or might not be available; nor does it represent that it has 733 made any independent effort to identify any such rights. Information 734 on the procedures with respect to rights in RFC documents can be 735 found in BCP 78 and BCP 79. 737 Copies of IPR disclosures made to the IETF Secretariat and any 738 assurances of licenses to be made available, or the result of an 739 attempt made to obtain a general license or permission for the use of 740 such proprietary rights by implementers or users of this 741 specification can be obtained from the IETF on-line IPR repository at 742 http://www.ietf.org/ipr. 744 The IETF invites any interested party to bring to its attention any 745 copyrights, patents or patent applications, or other proprietary 746 rights that may cover technology that may be required to implement 747 this standard. Please address the information to the IETF at 748 ietf-ipr@ietf.org. 750 Acknowledgment 752 Funding for the RFC Editor function is provided by the IETF 753 Administrative Support Activity (IASA).