idnits 2.17.1 draft-arifumi-v6ops-addr-select-sol-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 715. 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 == Line 540 has weird spacing: '...4update shim...' -- 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 (May 2007) is 6162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-v6ops-addr-select-ps-01 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-addr-select-req-02 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-07) exists of draft-chakrabarti-ipv6-addrselect-api-06 == Outdated reference: A later version (-09) exists of draft-fujisaki-dhc-addr-select-opt-03 == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-07 == Outdated reference: A later version (-04) exists of draft-ietf-shim6-locator-pair-selection-01 == Outdated reference: A later version (-17) exists of draft-ietf-shim6-multihome-shim-api-02 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 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: November 2, 2007 R. Hiromi 6 K. Kanayama 7 Intec Netcore 8 May 2007 10 Solution approaches for address-selection problems 11 draft-arifumi-v6ops-addr-select-sol-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 2, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 In response to address selection problem statement and requirement 45 documents, this document describes approaches to solutions and 46 evaluates proposed solution mechanisms in line with requirements. It 47 also examines the applicability of each solution mechanism from the 48 viewpoint of practical application. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Solution Design . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Proactive approaches . . . . . . . . . . . . . . . . . . . 3 55 2.2. Reactive approaches . . . . . . . . . . . . . . . . . . . 4 56 3. Solution approaches . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Obtain all information prior to communication (Most 58 Proactive) . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1.2. Requirements correspondence analysis . . . . . . . . . 5 61 3.1.3. Other issues . . . . . . . . . . . . . . . . . . . . . 6 62 3.2. Routing system assistance for address selection 63 (Proactive) . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2.2. Requirements correspondence analysis . . . . . . . . . 6 66 3.2.3. Other issues . . . . . . . . . . . . . . . . . . . . . 7 67 3.3. Trial-and-error approach (Reactive) . . . . . . . . . . . 7 68 3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.3.2. Requirement correspondence analysis . . . . . . . . . 8 70 3.3.3. Other issues . . . . . . . . . . . . . . . . . . . . . 9 71 3.4. All-by-oneself approach (Most Reactive) . . . . . . . . . 9 72 3.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.4.2. Requirement correspondence analysis . . . . . . . . . 9 74 3.4.3. Other issues . . . . . . . . . . . . . . . . . . . . . 10 75 4. Applicability Comparison . . . . . . . . . . . . . . . . . . . 11 76 4.1. Dynamic-static and managed-unmanaged . . . . . . . . . . . 11 77 4.2. Deployment Difficulty . . . . . . . . . . . . . . . . . . 12 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 85 Intellectual Property and Copyright Statements . . . . . . . . . . 16 87 1. Introduction 89 One physical network can have multiple logical networks. In that 90 case, an end-host has multiple IP addresses. (e.g, in the IPv4-IPv6 91 dual-stack environment, in a site that uses both ULA [RFC4193] and 92 global scope addresses or in a site connected to multiple upstream 93 IPv6 networks.) For such a host, RFC 3484 [RFC3484] defines default 94 address-selection rules for the source and destination addresses. 96 Today, the RFC 3484 mechanism is widely implemented in major OSs. 97 However, many people, including us, have found that in many sites the 98 default address-selection rules are not appropriate for the network 99 structure. PS [I-D.ietf-v6ops-addr-select-ps] lists problematic 100 cases that resulted from incorrect address selection. 102 Though RFC 3484 made the address-selection behavior of a host 103 configurable, typical users cannot make use of that because of the 104 complexity of the mechanism and their lack of knowledge about their 105 network topologies. Therefore, an address-selection 106 autoconfiguration mechanism is necessary, especially for the 107 unmanaged hosts of typical users. 109 REQ [I-D.ietf-v6ops-addr-select-req] document enumerates requirements 110 for address-selection mechanisms that enable hosts to perform 111 appropriate address selection automatically. 113 In the IETF mailing lists and in the internet-draft archives, some 114 mechanisms for solving address-selection problems have already been 115 proposed. This document describes possible design approaches for 116 solving address selection problems. After that, we try to put 117 together an overview as well as an analysis of how well the method 118 corresponds with the requirements. 120 2. Solution Design 122 There are two types of approaches that can control the behavior of 123 hosts in terms of the selection of destination address and source 124 address. The first type is proactive, where the host is given the 125 necessary information to decide the destination and source addresses 126 before the beginning of transmission. The other type is reactive, 127 where the host decides appropriate destination address and source 128 addresses through trial and error. 130 2.1. Proactive approaches 132 There can be two types of proactive approaches. One gives hosts all 133 the information for selecting destination and address and source 134 addresses beforehand. Under some circumstances, a lot of information 135 could be stored in hosts. 137 The other type informs hosts about which prefixes should be used in 138 the source address for the different destinations every time before 139 starting each connection. 141 2.2. Reactive approaches 143 In these approaches, the host does not have initial information for 144 address selection. It will try using different pairs of destination 145 and source addresses until the connection is established. When an 146 outage occurs, the host must detect it and try again with a new pair 147 of destination address and source address. Some reactive solutions 148 may use some kind of control message that enables the gateway to 149 indicate the outage. 151 3. Solution approaches 153 This section describes the evaluation of the four approaches to 154 finding solutions. The evaluation value has a 3-point scale for each 155 of 8 requirements in the requirement document. The meaning of the 156 points is as follows. 158 1 : bad 159 2 : fair 160 3 : good 162 About "Effectiveness", the score is 1 if the approach solves no 163 problematic cases described in the problem statement document, 2 if 164 it can handle at least one, and 3 if it solves every case. 166 3.1. Obtain all information prior to communication (Most Proactive) 168 3.1.1. Overview 170 In this approach, a host obtains everything needed to select 171 addresses at once prior to communication. A host receives all policy 172 information from a server beforehand. It then sets up communication 173 whenever it wants to. DHCPv6 and RA fall into this category as known 174 protocols. There is a reference document 175 [I-D.fujisaki-dhc-addr-select-opt] in which DHCPv6 is used for this 176 purpose. 178 This approach can take advantage of the RFC 3484 Policy Table, which 179 is already widely deployed. By distributing policies for the Policy 180 Table, you can auto-configure a host's address selection policy. 182 3.1.2. Requirements correspondence analysis 184 1. Effectiveness: 3 185 It can support all cases by using the policy table. 187 2. Timing: 3 188 All information for communication is in a host in advance. 189 Communication starts at once when it is necessary and the 190 communication process refers to local policy information, so it 191 exhibits good usability. Moreover, this leads to fewer overheads 192 than per-connection mechanisms. 194 3. Dynamic update: 3 195 Though it depends on what protocol is used to distribute the 196 policies, some mechanisms support information updates from the 197 server. Moreover, it is difficult to support dynamic network 198 changes and real-time updates in some specific protocols. 200 4. Node-specific behavior: 3 201 For distribution to individual hosts in the same segment, DHCPv6 202 can be used. 204 5. Application-specific behavior: 2 205 The policy table itself doesn't support application-specific 206 address selection. It can be done using the address selection 207 API. [I-D.chakrabarti-ipv6-addrselect-api] 209 6. Multiple interfaces: 2 210 If all interfaces belong to the same administration domain, it is 211 possible for the address-selection information to be controlled by 212 administrators of that domain. However, if not, routing 213 information and address selection policies are not always 214 equivalent between domains, and it is not possible to handle them. 216 7. Central control: 3 217 It can support central control. A site administrator or a service 218 provider can determine users' policy tables. 220 8. Route selection: 2 221 Current solutions, such as DHCPv6 and RA, do not have a mechanism 222 for cooperation with routing protocols. This could be done with 223 other techniques such as "source address based routing" or 224 "Default Router Preferences and More-Specific Routes" RFC4191. 225 [RFC4191] 227 3.1.3. Other issues 228 - The traffic volume will be equal to the number of policies. 230 - Hosts and servers need to support this function. 232 3.2. Routing system assistance for address selection (Proactive) 234 3.2.1. Overview 236 Fred Baker proposed this approach. A host asks the DMZ routers or 237 the local router which is the best pair of source and destination 238 addresses when the host has a set of addresses A and the destination 239 host has a set of addresses B. Then, the host uses the policy 240 provided by the server/routing system as a guide in applying the 241 response. He also proposed a mechanism that utilizes the ICMP error 242 message to change the source address of the existing session. This 243 point resembles Section 3.3 3484update mechanism, so the following 244 evaluation is based on only the first part of his proposal. 246 3.2.2. Requirements correspondence analysis 248 1. Effectiveness: 3 249 A routing system knows about information about paths toward the 250 destination and information about which of their prefixes should 251 be used. Therefore, it is possible to select an appropriate pair 252 of source and destination addresses. 254 2. Timing: 3 255 A routing system always has up-to-date routing information, so it 256 will be possible to provide suitable information whenever requests 257 come. However, the amount of information that the system must 258 handle is huge, so there will be cases where it takes time to 259 answer the request because appropriate information must be 260 retrieved from a huge database. 261 If any server or routing trouble occurs, the requester cannot get 262 the answer, and address selection will fail. This point is the 263 same in all systems that depend on other servers. 265 3. Dynamic update: 3 266 A routing system always has up-to-date routing information, and it 267 will be possible to provide suitable information whenever requests 268 come. 270 4. Node-pecific behavior: 3 271 Node-specific information can be provided if a server recognizes 272 individual nodes. 274 5. Application-specific behavior: 2 275 A routing system does not care about applications. Using address 276 selection API allows nodes to behave in an application-specific 277 way. 279 6. Multiple Interfaces: 2 280 If all interfaces belong to the same administration domain, it is 281 possible for the address-selection information to be controlled by 282 administrators of that domain. However, if not, routing 283 information and address selection policies are not always 284 equivalent between domains, and it is not possible to handle them. 286 7. Central Control: 3 287 It is possible to provide address selection information from one 288 source. However, because routing information changes dynamically, 289 it is difficult to control it in the way that administrators want. 291 8. Route Selection: 3 292 It is possible to give next-hop selection advice to a host. As 293 routers have routing information, it would seem to be easier for 294 routers to implement this function. 296 3.2.3. Other issues 297 - A host must consult the routing system every time it starts a 298 connection if the host does not have address selection information 299 for the destination host or if the information lifetime has 300 expired. This could be a possible scalability problem. 302 - The existing host/router OS implementation must be changed a lot. 303 In the existing TCP/IP protocol stack implementation, destination 304 address selection is mainly the role of the application and not 305 that of the kernel unlike source address selection. Therefore, 306 implementing this model without affecting applications is not so 307 easy. 309 3.3. Trial-and-error approach (Reactive) 311 3.3.1. Overview 313 M. Bagnulo proposed a new address selection method in his draft. 314 When the host notices that a network failure has occurred or packets 315 have been dropped somewhere in the network by, for example, an 316 ingress filter, the host changes the source address of the connection 317 to another source address. 319 Hosts may use some kinds of error messages, e.g, ICMP error messages, 320 from a network to detect that sent packets did not reach the 321 destination quickly. 323 The host stores a cache of address selection information so that the 324 host can select an appropriate source address for new connections. 326 For source address selection by the application that initiated a 327 communication, this method provides an ordered list of source 328 addresses for the destination address to the application. 330 3.3.2. Requirement correspondence analysis 332 1. Effectiveness: 2 333 This solution is not effective for the problem about IPv4 or IPv6 334 prioritization described in the problem statement document. 336 2. Timing: 2 337 Hosts should try to use all the available source addresses to the 338 maximum to find an appropriate source address. If the host tries 339 the next source address after the previous trial using another 340 source address has failed, it may take a long time because this 341 trial-and-error process lasts until the connection succeeds. If 342 the host does not use an error message from a network to detect a 343 connection error, it takes longer to wait for a time-out. 345 3. Dynamic update: 3 346 If hosts detect a connection failure using some reliable 347 mechanism, such like TCP or ICMP error messages, a connection 348 failure caused by some changes in the network will be detected 349 immediately by the hosts. 351 4. Node-specific behavior: 2 352 This solution does not have a function for node-specific behavior. 353 However, it is not impossible to implement by setting a packet 354 filter for each node at the gateways through which the packets 355 from nodes pass. 357 5. Application-specific behavior: 2 358 This solution does not have a function for application-specific 359 behavior. However, the mechanism of this approach does not 360 exclude address selection by each application. 362 6. Multiple interfaces: 3 363 If the protocol-stack or an application supports interface 364 selection and it tries to establish a connection by changing 365 addresses and also interfaces, it can find a working combination 366 of addresses and interface. 368 7. Central control: 2 369 The only way that a central administrator has to control the node 370 behavior is switching a filter on/off on the network. Therefore, 371 advanced control such as traffic engineering and QoS is almost 372 impossible. 374 8. Route Selection: 2 375 This solution does not refer to next-hop selection for the 376 transmission of a packet. So, it should be used with some routing 377 function such as RFC 4191 on the nodes. 379 3.3.3. Other issues 380 - A host must learn address selection information for each 381 destination host. Therefore, the number of cache entries could be 382 very large. 384 - The existing host/router OS implementation must be changed a lot. 385 In particular, changing the source address of the existing 386 connection is not so easy and has a big impact on the existing 387 TCP/IP protocol stack implementation. 389 3.4. All-by-oneself approach (Most Reactive) 391 3.4.1. Overview 393 shim6 was designed for site-multihoming. This mechanism introduces a 394 new address selection method for session initiation and session 395 survivability; it is documented in two drafts: 396 [I-D.ietf-shim6-locator-pair-selection] and 397 [I-D.ietf-shim6-failure-detection]. 399 The shim6 host detects connection failures and changes the 400 destination and source addresses during the session. 402 In this document, we focus on address selection issues in the 403 connection initiation phase of shim6 and not on any other functions, 404 such as session survivability. 406 3.4.2. Requirement correspondence analysis 408 1. Effectiveness: 2 409 This solution is not effective for the problem about IPv4 or IPv6 410 prioritization described in the problem statement document. 412 2. Timing: 2 413 Hosts should try to use all the available source addresses to the 414 maximum to find an appropriate source address. If the host tries 415 the next source address after the previous trial using another 416 source address has failed, it may take a long time because this 417 trial-and-error process lasts until the connection succeeds. If 418 the host does not use error messages from a network to detect a 419 connection error, it takes longer to wait for a time-out. 421 3. Dynamic update: 3 422 It can reflect dynamically changing network, as far as it always 423 tries all possible addresses and next-hops. 425 4. Node-specific behavior: 2 426 This solution does not have a function for node-specific behavior. 427 However, it is not impossible to implement by setting a packet 428 filter for each node on the gateways through which the packets 429 from nodes pass. 431 5. Application-specific behavior: 2 432 The use of shim6 API [I-D.ietf-shim6-multihome-shim-api] allows 433 applications to override address selection behavior. 435 6. Multiple interfaces: 3 436 If the protocol-stack supports interface selection and it tries to 437 establish a connection by changing addresses and also interfaces, 438 it can find a working combination of addresses and interface. 440 7. Central control: 2 441 The only way that a central administrator has to control the node 442 behavior is switching a filter on/off on the network. Therefore, 443 advanced control such as traffic engineering and QoS is almost 444 impossible. 446 8. Route Selection: 2 447 This solution does not refer to next-hop selection for the 448 transmission of a packet. Therefore, it should be used with some 449 routing function such as RFC 4191 on the nodes. 451 3.4.3. Other issues 452 - The shim6 host performs address selection that reflects network 453 failures that have occurred between the source and destination 454 host. 456 - End hosts themselves can avoid network failure. There is no need 457 to modify or reconfigure routers in the path. 459 - A host must learn address selection information for each 460 destination host. Therefore, the number of cache entries can be 461 very large. 463 - The existing host OS implementation must be changed significantly. 465 4. Applicability Comparison 467 In the previous section, every approach scored "fair" or better for 468 every requirement. This means that every approach can meet the 469 demands of address selection. However, if you actually want to 470 choose one mechanism to solve your address selection problem, it is 471 important to figure out which approach is best suited to your 472 situation. This section tries to evaluate the applicability of each 473 approach from several aspects. 475 4.1. Dynamic-static and managed-unmanaged 477 First, we use two axes to evaluate the applicability of the four 478 approaches. One axis shows whether or not the network structure 479 changes dynamically and the other axis shows whether the site is 480 managed or unmanaged. In a managed network, by our definition, a 481 network administrator manages his or her network, routers, and hosts. 482 For example, an enterprise network is managed, whereas a home network 483 and a SOHO network are unmanaged. 485 static dynamic 486 <--------------------------------------------> 487 unmanaged ^ +----------+ +---------------------------+ 488 | | | +-+--------------+ shim6 | 489 | | | | | | | 490 | | +--+-+-+------------+ | | 491 | | | | | | | | | 492 | | | | | | | | | 493 | | | | | +------------+-+------------+ 494 | | | | | 3484update| | 495 | | +--+-+--------------+ | 496 | | | | | 497 | | | | | 498 | | Policy | | RouterAssist | 499 | | Dist | | | 500 | | | | | 501 | +----------+ +----------------+ 503 managed v 505 PolicyDist: 506 - In a dynamic site, the policy table must be updated accordingly 507 and traffic for policy table distribution increases. 509 3484update: 510 - This is a slightly manageable than shim6 in that 3484update does 511 not change the paths of established connections dynamically. 513 - In a very dynamic site, the use of an address selection 514 information cache does not have a good effect. This results in 515 connection failure and may degrade usability badly. 517 - Even in a very static site, a host may try inappropriate addresses 518 or next-hops and experience connection failures. 520 RouterAssist: 521 - A host must send at least as many queries as the number 522 destination hosts. Therefore, in a static site, this method is 523 not optimal. 525 - In a very dynamic site, address selection information cache is no 526 help. If the cache function is not used, then connection failures 527 do not occur. 529 shim6: 530 - In a static site, shim6 is not desirable because of its connection 531 sequence overhead and timeout-wait for path exploration. 533 - In a managed site, shim6 is not easy to manage in terms of node- 534 specific address selection control and central control. 536 4.2. Deployment Difficulty 538 less more 539 <-------------------------------------------> 540 policy-dist 3484update shim6 Fred 542 PolicyDist: 543 - What must be implemented is a distribution mechanism. The 544 existing protocols, such as RA and DHCP, can be used for this 545 purpose. 547 3484update: 549 - The protocol stack or applications on a host must be modified. 550 Routers in a site must be configured to return error messages to 551 the sender of inappropriately addressed packets. 553 RouterAssist: 554 - The protocol stack and applications on a host must be modified. 555 Furthermore, routers must be modified. 557 shim6: 558 - The protocol stack must be modified. For this address selection 559 purpose, corresponding nodes need not support shim6. Basically, 560 there is no need to change the router implementation or 561 configuration. 563 5. Security Considerations 565 Incorrect address selection can lead to serious security problems, 566 such as session hijacking. However, we should note that address- 567 selection is ultimately decided by nodes and their users. There are 568 no means to enforce a specific address-selection behavior upon every 569 end-host from outside the host. Therefore, a network administrator 570 must take countermeasures against unexpected address selection. 572 6. IANA Considerations 574 This document has no actions for IANA. 576 7. Conclusions 578 In this document, we examined solutions to address selection problems 579 in the IPv6 multi-prefix environment. Although almost all solutions 580 examined in this document could be applied to any environment and 581 situation, a solution with a mechanism that is suitable for the 582 situation should be selected. 584 8. References 586 8.1. Normative References 588 [I-D.ietf-v6ops-addr-select-ps] 589 Matsumoto, A., "Problem Statement of Default Address 590 Selection in Multi-prefix Environment: Operational Issues 591 of RFC3484 Default Rules", 592 draft-ietf-v6ops-addr-select-ps-01 (work in progress), 593 April 2007. 595 [I-D.ietf-v6ops-addr-select-req] 596 Matsumoto, A., "Requirements for address selection 597 mechanisms", draft-ietf-v6ops-addr-select-req-02 (work in 598 progress), May 2007. 600 [RFC3484] Draves, R., "Default Address Selection for Internet 601 Protocol version 6 (IPv6)", RFC 3484, February 2003. 603 8.2. Informative References 605 [I-D.chakrabarti-ipv6-addrselect-api] 606 Nordmark, E., "IPv6 Socket API for Address Selection", 607 draft-chakrabarti-ipv6-addrselect-api-06 (work in 608 progress), May 2007. 610 [I-D.fujisaki-dhc-addr-select-opt] 611 Fujisaki, T., "Distributing Default Address Selection 612 Policy using DHCPv6", 613 draft-fujisaki-dhc-addr-select-opt-03 (work in progress), 614 January 2007. 616 [I-D.ietf-shim6-failure-detection] 617 Arkko, J. and I. Beijnum, "Failure Detection and Locator 618 Pair Exploration Protocol for IPv6 Multihoming", 619 draft-ietf-shim6-failure-detection-07 (work in progress), 620 December 2006. 622 [I-D.ietf-shim6-locator-pair-selection] 623 Bagnulo, M., "Default Locator-pair selection algorithm for 624 the SHIM6 protocol", 625 draft-ietf-shim6-locator-pair-selection-01 (work in 626 progress), October 2006. 628 [I-D.ietf-shim6-multihome-shim-api] 629 Komu, M., "Socket Application Program Interface (API) for 630 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-02 631 (work in progress), March 2007. 633 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 634 More-Specific Routes", RFC 4191, November 2005. 636 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 637 Addresses", RFC 4193, October 2005. 639 Authors' Addresses 641 Arifumi Matsumoto 642 NTT PF Lab 643 Midori-Cho 3-9-11 644 Musashino-shi, Tokyo 180-8585 645 Japan 647 Phone: +81 422 59 3334 648 Email: arifumi@nttv6.net 650 Tomohiro Fujisaki 651 NTT PF Lab 652 Midori-Cho 3-9-11 653 Musashino-shi, Tokyo 180-8585 654 Japan 656 Phone: +81 422 59 7351 657 Email: fujisaki@syce.net 659 Ruri Hiromi 660 Intec Netcore, Inc. 661 Shinsuna 1-3-3 662 Koto-ku, Tokyo 136-0075 663 Japan 665 Phone: +81 3 5665 5069 666 Email: hiromi@inetcore.com 668 Ken-ichi Kanayama 669 Intec Netcore, Inc. 670 Shinsuna 1-3-3 671 Koto-ku, Tokyo 136-0075 672 Japan 674 Phone: +81 3 5665 5069 675 Email: kanayama@inetcore.com 677 Full Copyright Statement 679 Copyright (C) The IETF Trust (2007). 681 This document is subject to the rights, licenses and restrictions 682 contained in BCP 78, and except as set forth therein, the authors 683 retain all their rights. 685 This document and the information contained herein are provided on an 686 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 687 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 688 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 689 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 690 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 693 Intellectual Property 695 The IETF takes no position regarding the validity or scope of any 696 Intellectual Property Rights or other rights that might be claimed to 697 pertain to the implementation or use of the technology described in 698 this document or the extent to which any license under such rights 699 might or might not be available; nor does it represent that it has 700 made any independent effort to identify any such rights. Information 701 on the procedures with respect to rights in RFC documents can be 702 found in BCP 78 and BCP 79. 704 Copies of IPR disclosures made to the IETF Secretariat and any 705 assurances of licenses to be made available, or the result of an 706 attempt made to obtain a general license or permission for the use of 707 such proprietary rights by implementers or users of this 708 specification can be obtained from the IETF on-line IPR repository at 709 http://www.ietf.org/ipr. 711 The IETF invites any interested party to bring to its attention any 712 copyrights, patents or patent applications, or other proprietary 713 rights that may cover technology that may be required to implement 714 this standard. Please address the information to the IETF at 715 ietf-ipr@ietf.org. 717 Acknowledgment 719 Funding for the RFC Editor function is provided by the IETF 720 Administrative Support Activity (IASA).