idnits 2.17.1 draft-ietf-v6ops-addr-select-ps-09.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 17, 2008) is 5785 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 19, 2008 R. Hiromi 6 Intec Netcore 7 K. Kanayama 8 INTEC Systems 9 June 17, 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-09.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 19, 2008. 40 Abstract 42 A single physical link can have multiple prefixes assigned to it. In 43 that environment, end hosts might have multiple IP addresses and be 44 required to use them selectively. RFC 3484 defines default source 45 and destination address selection rules and is implemented in a 46 variety of OS's. But, it has been too difficult to use operationally 47 for several reasons. In some environment where multiple prefixes are 48 assigned on a single physical link, the host using the default 49 address selection rules will experience some trouble in 50 communication. This document describes the possible problems that 51 end hosts could encounter in an environment with multiple prefixes. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3 57 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Source Address Selection . . . . . . . . . . . . . . . . . 4 59 2.1.1. Multiple Routers on Single Interface . . . . . . . . . 4 60 2.1.2. Ingress Filtering Problem . . . . . . . . . . . . . . 5 61 2.1.3. Half-Closed Network Problem . . . . . . . . . . . . . 6 62 2.1.4. Combined Use of Global and ULA . . . . . . . . . . . . 7 63 2.1.5. Site Renumbering . . . . . . . . . . . . . . . . . . . 8 64 2.1.6. Multicast Source Address Selection . . . . . . . . . . 9 65 2.1.7. Temporary Address Selection . . . . . . . . . . . . . 9 66 2.2. Destination Address Selection . . . . . . . . . . . . . . 10 67 2.2.1. IPv4 or IPv6 prioritization . . . . . . . . . . . . . 10 68 2.2.2. ULA and IPv4 dual-stack environment . . . . . . . . . 11 69 2.2.3. ULA or Global Prioritization . . . . . . . . . . . . . 12 70 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 76 Appendix A. Appendix. Revision History . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 78 Intellectual Property and Copyright Statements . . . . . . . . . . 17 80 1. Introduction 82 In IPv6, a single physical link can have multiple prefixes assigned 83 to it. In such cases, an end-host may have multiple IP addresses 84 assigned to an interface on that link. In the IPv4-IPv6 dual stack 85 environment or in a site connected to both a ULA [RFC4193] and 86 Globally routable networks, an end-host typically has multiple IP 87 addresses. These are examples of the networks that we focus on in 88 this document. In such an environment, an end-host may encounter 89 some communication troubles. 91 Inappropriate source address selection at the end-host causes 92 unexpected asymmetric routing, filtering by a router or discarding of 93 packets because there is no route to the host. 95 Considering a multi-prefix environment, destination address selection 96 is also important for correct or better communication establishment. 98 RFC 3484 [RFC3484] defines default source and destination address 99 selection algorithms and is implemented in a variety of OS's. But, 100 it has been too difficult to use operationally for several reasons, 101 such as lack of autoconfiguration method. There are some problematic 102 cases where the hosts using the default address selection rules 103 encounter communication troubles. 105 This document describes such possibilities of incorrect address 106 selection which leads to dropping packets and communication failure. 108 1.1. Scope of this document 110 As other mechanisms already exist, the multi-homing techniques for 111 achieving redundancy are basically out of our scope. 113 We focus on an end-site network environment and unmanaged hosts in 114 such an environment. This is because address selection behavior at 115 this kind of hosts is difficult to manipulate owing to the users' 116 lack of knowledge, hosts' location, or massiveness of the hosts. 118 The scope of this document is to sort out problematic cases related 119 to address selection. It includes problems that can be solved in the 120 framework of RFC 3484 and problems that cannot. For the latter, RFC 121 3484 might be modified to meet their needs, or another address 122 selection solution might be necessary. For the former, an additional 123 mechanism that mitigates the operational difficulty might be 124 necessary. 126 This document also includes simple solution analysis for each 127 problematic case. This analysis basically just focuses on whether 128 the case can be solved in the framework of RFC 3484 or not. If not, 129 some possible solutions are described. Even if a case can be solved 130 in the framework of RFC 3484, as mentioned above, it does not 131 necessarily mean that there is no operational difficulty. For 132 example, in the environment stated above, it is not a feasible 133 solution to configure each host's policy table by hand. So, for such 134 an solution, configuration pain is yet another common problem. 136 2. Problem Statement 138 2.1. Source Address Selection 140 2.1.1. Multiple Routers on Single Interface 142 ================== 143 | Internet | 144 ================== 145 | | 146 2001:db8:1000::/36 | | 2001:db8:8000::/36 147 +----+-+ +-+----+ 148 | ISP1 | | ISP2 | 149 +----+-+ +-+----+ 150 | | 151 2001:db8:1000:::/48 | | 2001:db8:8000::/48 152 +-----+---+ +----+----+ 153 | Router1 | | Router2 | 154 +-------+-+ +-+-------+ 155 | | 156 2001:db8:1000:1::/64 | | 2001:db8:8000:1::/64 157 | | 158 -----+-+-----+------ 159 | 160 +-+----+ 2001:db8:1000:1::100 161 | Host | 2001:db8:8000:1::100 162 +------+ 164 [Fig. 1] 166 Generally speaking, there is no interaction between next-hop 167 determination and address selection. In this example, when a host 168 starts a new connection and sends a packet via Router1, the host does 169 not necessarily choose address 2001:db8:1000:1::100 given by Router1 170 as the source address. This causes the same problem as described in 171 the next section 'Ingress Filtering Problem'. 173 Solution analysis: 175 As this case depends on next hop selection, controling the address 176 selection behavior at Host alone doesn't solve the entire problem. 177 One possible solution for this case is adopting source address 178 based routing at Router1 and Router2. Another solution may be 179 using static routing at Router1, Router2 and Host, and using the 180 corresponding static address selection policy at Host. 182 2.1.2. Ingress Filtering Problem 184 ================== 185 | Internet | 186 ================== 187 | | 188 2001:db8:1000::/36 | | 2001:db8:8000::/36 189 +----+-+ +-+----+ 190 | ISP1 | | ISP2 | 191 +----+-+ +-+----+ 192 | | 193 2001:db8:1000:::/48 | | 2001:db8:8000::/48 194 ++-------++ 195 | Router | 196 +----+----+ 197 | 2001:db8:1000:1::/64 198 | 2001:db8:8000:1::/64 199 ------+---+---------- 200 | 201 +-+----+ 2001:db8:1000:1::100 202 | Host | 2001:db8:8000:1::100 203 +------+ 205 [Fig. 2] 207 When a relatively small site, which we call a "customer network", is 208 attached to two upstream ISPs, each ISP delegates a network address 209 block, which is usually /48, and a host has multiple IPv6 addresses. 211 When the source address of an outgoing packet is not the one that is 212 delegated by an upstream ISP, there is a possibility that the packet 213 will be dropped at the ISP by its Ingress Filter. Ingress filtering 214 is becoming more popular among ISPs to mitigate the damage of DoS 215 attacks. 217 In this example, when the Router chooses the default route to ISP2 218 and the Host chooses 2001:db8:1000:1::100 as the source address for 219 packets sent to a host (2001:db8:2000::1) somewhere on the Internet, 220 the packets may be dropped at ISP2 because of Ingress Filtering. 222 Solution analysis: 224 One possible solution for this case is adopting source address 225 based routing at Router. Another solution may be using static 226 routing at Router, and using the corresponding static address 227 selection policy at Host. 229 2.1.3. Half-Closed Network Problem 231 You can see a second typical source address selection problem in a 232 multihome site with global-closed mixed connectivity like in the 233 figure below. In this case, Host-A is in a multihomed network and 234 has two IPv6 addresses, one delegated from each of the upstream ISPs. 235 Note that ISP2 is a closed network and does not have connectivity to 236 the Internet. 238 +--------+ 239 | Host-C | 2001:db8:a000::1 240 +-----+--+ 241 | 242 ============== +--------+ 243 | Internet | | Host-B | 2001:db8:8000::1 244 ============== +--------+ 245 | | 246 2001:db8:1000:/36 | | 2001:db8:8000::/36 247 +----+-+ +-+---++ 248 | ISP1 | | ISP2 | (Closed Network/VPN tunnel) 249 +----+-+ +-+----+ 250 | | 251 2001:db8:1000:/48 | | 2001:db8:8000::/48 252 ++-------++ 253 | Router | 254 +----+----+ 255 | 2001:db8:1000:1::/64 256 | 2001:db8:8000:1::/64 257 ------+---+---------- 258 | 259 +--+-----+ 2001:db8:1000:1::100 260 | Host-A | 2001:db8:8000:1::100 261 +--------+ 263 [Fig. 3] 265 You do not need two physical network connections here. The 266 connection from the Router to ISP2 can be a logical link over ISP1 267 and the Internet. 269 When Host-A starts the connection to Host-B in ISP2, the source 270 address of a packet that has been sent will be the one delegated from 271 ISP2, that is 2001:db8:8000:1::100, because of rule 8 (longest 272 matching prefix) in RFC 3484. 274 Host-C is located somewhere on the Internet and has IPv6 address 275 2001:db8:a000::1. When Host-A sends a packet to Host-C, the longest 276 matching algorithm chooses 2001:db8:8000:1::100 for the source 277 address. In this case, the packet goes through ISP1 and may be 278 filtered by ISP1's ingress filter. Even if the packet is not 279 filtered by ISP1, a return packet from Host-C cannot possibly be 280 delivered to Host-A because the return packet is destined for 2001: 281 db8:8000:1::100, which is closed from the Internet. 283 The important point is that each host chooses a correct source 284 address for a given destination address. To solve this kind of 285 network policy based address selection problems, it is likely that 286 delivering additional information to a node fits better than 287 algorithmic solutions that are local to the node. 289 Solution analysis: 290 This problem can be solved in the RFC 3484 framework. For 291 example, configuring some address selection policies into Host-A's 292 RFC 3484 policy table can solve this problem. 294 2.1.4. Combined Use of Global and ULA 296 ============ 297 | Internet | 298 ============ 299 | 300 | 301 +----+----+ 302 | ISP | 303 +----+----+ 304 | 305 2001:db8:a::/48 | 306 +----+----+ 307 | Router | 308 +-+-----+-+ 309 | | 2001:db8:a:100::/64 310 fd01:2:3:200:/64 | | fd01:2:3:100:/64 311 -----+--+- -+--+---- 312 | | 313 fd01:2:3:200::101 | | 2001:db8:a:100::100 314 +----+----+ +-+----+ fd01:2:3:100::100 315 | Printer | | Host | 316 +---------+ +------+ 318 [Fig. 4] 320 As RFC 4864 [RFC4864] describes, using a ULA may be beneficial in 321 some scenarios. If the ULA is used for internal communication, 322 packets with ULA need to be filtered at the Router. 324 This case does not presently create an address selection problem 325 because of the dissimilarity between the ULA and the Global Unicast 326 Address. The longest matching rule of RFC 3484 chooses the correct 327 address for both intra-site and extra-site communication. 329 In the future, however, there is a possibility that the longest 330 matching rule will not be able to choose the correct address anymore. 331 That is the moment when the assignment of those Global Unicast 332 Addresses starts, where the first bit is 1. In RFC 4291 [RFC4291], 333 almost all address spaces of IPv6, including those whose first bit is 334 1, are assigned as Global Unicast Addresses. 336 Namely, when we start to assign a part of the address block 8000::/1 337 as the global unicast address and that part is used somewhere in the 338 Internet, the longest matching rule ceases to function properly for 339 the people trying to connect to the servers with those addresses. 341 For example, when the destination host has an IPv6 address 8000::1, 342 and the originating host has 2001:db8::1 and fd0:1::1, the source 343 address will be fd00:1::1, because the longest matching bit length is 344 0 for 2001:db8::1 and 1 for fd0:1::1 respectively. 346 Solution analysis: 347 This problem can be solved in the RFC 3484 framework. For 348 example, configuring some address selection policies into Host's 349 RFC 3484 policy table can solve this problem. Another solution is 350 to modify RFC 3484 and define ULA's scope smaller than the global 351 scope. 353 2.1.5. Site Renumbering 355 RFC 4192 [RFC4192] describes a recommended procedure for renumbering 356 a network from one prefix to another. An autoconfigured address has 357 a lifetime, so by stopping advertisement of the old prefix, the 358 autoconfigured address is eventually invalidated. 360 However, invalidating the old prefix takes a long time. You cannot 361 stop routing to the old prefix as long as the old prefix is not 362 removed from the host. This can be a tough issue for ISP network 363 administrators. 365 There is a technique of advertising the prefix with the preferred 366 lifetime zero, however, RFC 4862 [RFC4862] 5.5.4 does not absolutely 367 prohibit the use of a deprecated address for a new outgoing 368 connection due to limitations relating to what applications are 369 capable of doing." 371 +-----+---+ 372 | Router | 373 +----+----+ 374 | 2001:db8:b::/64 (new) 375 | 2001:db8:a::/64 (old) 376 ------+---+---------- 377 | 378 +--+---+ 2001:db8:b::100 (new) 379 | Host | 2001:db8:a::100 (old) 380 +------+ 382 [Fig. 5] 384 Solution analysis: 385 This problem can be mitigated in the RFC 3484 framework. For 386 example, configuring some address selection policies into Host's 387 RFC 3484 policy table can solve this problem. 389 2.1.6. Multicast Source Address Selection 391 This case is an example of site-local or global unicast 392 prioritization. When you send a multicast packet across site- 393 borders, the source address of the multicast packet should be a 394 globally routable address. The longest matching algorithm, however, 395 selects a ULA if the sending host has both a ULA and a Global Unicast 396 Address. 398 Solution analysis: 399 This problem can be solved in the RFC 3484 framework. For 400 example, configuring some address selection policies into the 401 sending host's RFC 3484 policy table can solve this problem. 403 2.1.7. Temporary Address Selection 405 RFC 3041 [RFC3041] defines a Temporary Address. The usage of a 406 Temporary Address has both pros and cons. That is good for viewing 407 web pages or communicating with the general public, but that is bad 408 for a service that uses address-based authentication and for logging 409 purposes. 411 If you could turn the temporary address on and off, that would be 412 better. If you could switch its usage per service (destination 413 address), that would also be better. The same situation can be found 414 when using HA (home address) and CoA (care-of address)in a Mobile 415 IPv6 [RFC3775] network. 417 The Future Work section in RFC 3041 discusses that an API extension 418 might be necessary to achieve a better address selection mechanism 419 with finer granularity. 421 Solution analysis: 422 This problem can not be solved in the RFC 3484 framework. A 423 possible solution is to make applications to select desirable 424 addresses by using the IPv6 Socket API for Source Address 425 Selection defined in RFC 5014 [RFC5014]. 427 2.2. Destination Address Selection 429 2.2.1. IPv4 or IPv6 prioritization 431 The default policy table gives IPv6 addresses higher precedence than 432 IPv4 addresses. There seem to be many cases, however, where network 433 administrators want to control the address selection policy of end- 434 hosts the other way around. 436 +---------+ 437 | Tunnel | 438 | Service | 439 +--+---++-+ 440 | || 441 | || 442 ===========||== 443 | Internet || | 444 ===========||== 445 | || 446 192.0.2.0/24 | || 447 +----+-+ || 448 | ISP | || 449 +----+-+ || 450 | || 451 IPv4 (Native) | || IPv6 (Tunnel) 452 192.0.2.0/26 | || 453 ++-----++-+ 454 | Router | 455 +----+----+ 456 | 2001:db8:a:1::/64 457 | 192.0.2.0/28 458 | 459 ------+---+---------- 460 | 461 +-+----+ 2001:db8:a:1::100 462 | Host | 192.0.2.2 463 +------+ 465 [Fig. 6] 467 In the figure above, a site has native IPv4 and tunneled-IPv6 468 connectivity. Therefore, the administrator may want to set a higher 469 priority for using IPv4 than using IPv6 because the quality of the 470 tunnel network seems to be worse than that of the native transport. 472 Solution analysis: 473 This problem can be solved in the RFC 3484 framework. For 474 example, configuring some address selection policies into Host's 475 RFC 3484 policy table can solve this problem. 477 2.2.2. ULA and IPv4 dual-stack environment 479 This is a special form of IPv4 and IPv6 prioritization. When an 480 enterprise has IPv4 Internet connectivity but does not yet have IPv6 481 Internet connectivity, and the enterprise wants to provide site-local 482 IPv6 connectivity, a ULA is the best choice for site-local IPv6 483 connectivity. Each employee host will have both an IPv4 global or 484 private address and a ULA. Here, when this host tries to connect to 485 Host-B that has registered both A and AAAA records in the DNS, the 486 host will choose AAAA as the destination address and the ULA for the 487 source address. This will clearly result in a connection failure. 489 +--------+ 490 | Host-B | AAAA = 2001:db8::80 491 +-----+--+ A = 192.0.2.1 492 | 493 ============ 494 | Internet | 495 ============ 496 | no IPv6 connectivity 497 +----+----+ 498 | Router | 499 +----+----+ 500 | 501 | fd01:2:3::/48 (ULA) 502 | 192.0.2.128/25 503 ++--------+ 504 | Router | 505 +----+----+ 506 | fd01:2:3:4::/64 (ULA) 507 | 192.0.2.240/28 508 ------+---+---------- 509 | 510 +-+------+ fd01:2:3:4::100 (ULA) 511 | Host-A | 192.0.2.245 512 +--------+ 514 [Fig. 7] 516 Solution analysis: 517 This problem can be solved in the RFC 3484 framework. For 518 example, configuring some address selection policies into Host-A's 519 RFC 3484 policy table can solve this problem. 521 2.2.3. ULA or Global Prioritization 523 Differentiating services by the client's source address is very 524 common. IP-address-based authentication is an typical example of 525 this. Another typical example is a web service that has pages for 526 the public and internal pages for employees or involved parties. Yet 527 another example is DNS zone splitting. 529 However, a ULA and IPv6 global address both have global scope, and 530 RFC3484 default rules do not specify which address should be given 531 priority. This point makes IPv6 implementation of address-based 532 service differentiation a bit harder. 534 +--------+ 535 | Host-B | 536 +-+--|---+ 537 | | 538 ===========|== 539 | Internet | | 540 ===========|== 541 | | 542 | | 543 +----+-+ +-->+------+ 544 | ISP +------+ DNS | 2001:db8:a::80 545 +----+-+ +-->+------+ fc12:3456:789a::80 546 | | 547 2001:db8:a::/48 | | 548 fc12:3456:789a::/48 | | 549 +----+----|+ 550 | Router || 551 +---+-----|+ 552 | | 2001:db8:a:100::/64 553 | | fc12:3456:789a:100::/64 554 --+-+---|----- 555 | | 556 +-+---|--+ 2001:db8:a:100::100 557 | Host-A | fc12:3456:789a:100::100 558 +--------+ 560 [Fig. 7] 562 Solution analysis: 563 This problem can be solved in the RFC 3484 framework. For 564 example, configuring some address selection policies into Host-A's 565 RFC 3484 policy table can solve this problem. 567 3. Conclusion 569 We have covered problems related to destination or source address 570 selection. These problems have their roots in the situation where 571 end-hosts have multiple IP addresses. In this situation, every end- 572 host must choose an appropriate destination and source address, which 573 cannot be achieved only by routers. 575 It should be noted that end-hosts must be informed about routing 576 policies of their upstream networks for appropriate address 577 selection. A site administrator must consider every possible address 578 false-selection problem and take countermeasures beforehand. 580 4. Security Considerations 582 When an intermediate router performs policy routing (e.g. source 583 address based routing), inappropriate address selection causes 584 unexpected routing. For example, in the network described in 2.1.3, 585 when Host-A uses a default address selection policy and chooses an 586 inappropriate address, a packet sent to VPN can be delivered to a 587 location via the Internet. This issue can lead to packet 588 eavesdropping or session hijack. However, sending the packet back to 589 the correct path from the attacker to the node is not easy, so these 590 two risks are not serious. 592 As documented in the security consideration section in RFC 3484, 593 address selection algorithms expose a potential privacy concern. 594 When a malicious host can make a target host perform address 595 selection, for example by sending a anycast or a multicast packet, 596 the malicious host can get knowledge multiple addresses attached to 597 the target host. In a case like 2.1.4, if an attacker can make Host 598 to send a multicast packet and Host performs the default address 599 selection algorithm, the attacker may be able to determine the ULAs 600 attached to the Host. 602 These security risks have roots in inappropriate address selection. 603 Therefore, if a countermeasure is taken, and hosts always select an 604 appropriate address that is suitable to a site's network structure 605 and routing, these risks can be avoided. 607 5. IANA Considerations 609 This document has no actions for IANA. 611 6. References 613 6.1. Normative References 615 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 616 Stateless Address Autoconfiguration in IPv6", RFC 3041, 617 January 2001. 619 [RFC3484] Draves, R., "Default Address Selection for Internet 620 Protocol version 6 (IPv6)", RFC 3484, February 2003. 622 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 623 in IPv6", RFC 3775, June 2004. 625 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 626 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 627 September 2005. 629 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 630 Addresses", RFC 4193, October 2005. 632 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 633 Architecture", RFC 4291, February 2006. 635 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 636 Address Autoconfiguration", RFC 4862, September 2007. 638 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 639 E. Klein, "Local Network Protection for IPv6", RFC 4864, 640 May 2007. 642 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 643 Socket API for Source Address Selection", RFC 5014, 644 September 2007. 646 6.2. Informative References 648 Appendix A. Appendix. Revision History 650 01: 651 IP address notations changed to documentation address. 652 Description of solutions deleted. 653 02: 654 Security considerations section rewritten according to comments 655 from SECDIR. 656 03: 657 Intended status changed to Informational. 658 04: 659 This version reflects comments from IESG members. 660 05: 661 This version reflects comments from IESG members and Bob Hinden. 662 06: 663 This version reflects comments from Thomas Narten. 664 07: 665 This version reflects comments from Alfred Hoenes. 666 08: 667 Solution analysis for the section 2.1.6 was added. 668 09: 670 Typos were fixed, thanks to Jari Arrko. 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.