idnits 2.17.1 draft-ietf-6man-addr-select-sol-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5161 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3484' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-shim6-multihome-shim-api' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 648, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-02) exists of draft-arifumi-6man-addr-select-conflict-01 == Outdated reference: A later version (-01) exists of draft-axu-addr-sel-00 == Outdated reference: A later version (-05) exists of draft-ietf-6man-addr-select-considerations-00 == Outdated reference: A later version (-17) exists of draft-ietf-shim6-multihome-shim-api-13 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance Working Group A. Matsumoto 3 Internet-Draft T. Fujisaki 4 Intended status: Informational NTT 5 Expires: September 9, 2010 R. Hiromi 6 Intec Netcore 7 March 8, 2010 9 Solution approaches for address-selection problems 10 draft-ietf-6man-addr-select-sol-03.txt 12 Abstract 14 In response to address selection problem statement and requirement 15 documents, this document describes solution approaches and evaluates 16 proposed solution mechanisms in line with requirements. It also 17 examines the applicability for each solution mechanism, and concludes 18 that no single solution solves the problems and the combination of 19 the solutions should be the way forward. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 9, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 4 75 2.1. Proactive approach . . . . . . . . . . . . . . . . . . . . 4 76 2.2. Reactive approach . . . . . . . . . . . . . . . . . . . . 4 77 3. Solution Mechanisms . . . . . . . . . . . . . . . . . . . . . 4 78 3.1. Policy Distribution (Proactive Approach) . . . . . . . . . 5 79 3.1.1. Requirements correspondence analysis . . . . . . . . . 5 80 3.1.2. Other issues . . . . . . . . . . . . . . . . . . . . . 6 81 3.2. Routing system assistance (Proactive Approach) . . . . . . 6 82 3.2.1. Requirements correspondence analysis . . . . . . . . . 7 83 3.2.2. Other issues . . . . . . . . . . . . . . . . . . . . . 8 84 3.3. Trial-and-error based (Reactive Approach) . . . . . . . . 8 85 3.3.1. Requirement correspondence analysis . . . . . . . . . 8 86 3.3.2. Other issues . . . . . . . . . . . . . . . . . . . . . 10 87 3.4. All at once (Reactive Approach) . . . . . . . . . . . . . 10 88 3.4.1. Requirement correspondence analysis . . . . . . . . . 10 89 3.4.2. Other issues . . . . . . . . . . . . . . . . . . . . . 12 90 4. Applicability Comparison . . . . . . . . . . . . . . . . . . . 12 91 4.1. Dynamic-static and managed-unmanaged . . . . . . . . . . . 12 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 94 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 97 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 98 Appendix A. Other Solutions . . . . . . . . . . . . . . . . . . . 16 99 Appendix B. Revision History . . . . . . . . . . . . . . . . . . 16 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 102 1. Introduction 104 Today, the RFC 3484 mechanism is widely implemented in major OSs. 105 However, many people, including us, have found that in many sites the 106 default address selection rules do not work perfectly. RFC 5220 107 [RFC5220] lists problematic cases that resulted from incorrect 108 address selection. RFC 5221 [RFC5221] enumerates requirements for 109 address-selection mechanisms. 111 In the IETF mailing lists and in the internet-draft archives, some 112 mechanisms for solving address-selection problems were proposed. 113 This document describes possible design approaches for solving 114 address selection problems. After summarizing each existing proposal 115 mechanism and analyzing how well the method corresponds with the 116 requirements, applicability domain for each mechanism are evaluated. 118 2. Solution Approaches 120 There are two types of approaches that can control the behavior of 121 hosts in terms of the selection of destination address and source 122 address. The first type is proactive, where the host is given the 123 necessary information to decide the destination and source addresses 124 before the beginning of data transmission. The other type is 125 reactive, where the host decides appropriate destination address and 126 source addresses through trial and error. 128 2.1. Proactive approach 130 In this approach, hosts should have all or a part of the information 131 for selecting appropriate address pair before the actual data 132 transmission. 134 2.2. Reactive approach 136 In this approach, the host does not have initial information for 137 address selection. It will try using different pairs of destination 138 and source addresses until the connection is established. It can 139 take advantage of error messages, and can make use of it to prune 140 unworkable pair of addresses. 142 3. Solution Mechanisms 144 This section describes the evaluation of the four mechanisms. The 145 evaluation value has a 3-point scale for each of 8 requirements in 146 the requirement document. The meanings of the points are as follows. 148 1 : bad 149 2 : fair 150 3 : good 152 About "Effectiveness", the score is 1 if the approach solves no 153 problematic cases described in the problem statement document, 2 if 154 it can handle at least one, and 3 if it solves every case. 156 3.1. Policy Distribution (Proactive Approach) 158 In this approach, a host obtains everything, usually policies, needed 159 to select addresses prior to communication. The address selection 160 design team is working on this approach. 161 [I-D.ietf-6man-addr-select-considerations] DHCPv6 and RA are possible 162 transport protocols. There is a proposal document 163 [I-D.fujisaki-dhc-addr-select-opt] in which DHCPv6 is used for this 164 purpose. 166 This approach can take advantage of the RFC 3484 Policy Table, which 167 is already widely deployed. By distributing policies for the Policy 168 Table, you can auto-configure a host's address selection behavior. 170 3.1.1. Requirements correspondence analysis 172 1. Effectiveness: 3 173 It can support all cases by using the policy table. 175 2. Timing: 3 176 All information for communication is in a host in advance. 177 Communication starts at once when it is necessary and the 178 communication process refers to local policy information, which 179 does not cause any delay or incorrect address selection. 181 3. Dynamic update: 3 182 Though it depends on what protocol is used to distribute the 183 policies, some mechanisms support information updates from the 184 server, such as RA and DHCPv6 RECONFIGURE. 186 4. Node-specific behavior: 3 187 For distribution to individual hosts in the same segment, DHCPv6 188 and unicast based RA can be used. 190 5. Application-specific behavior: 2 191 The policy table itself doesn't support application-specific 192 address selection. It can be done using the address selection 193 API. [RFC5014] 195 6. Multiple interfaces: 2 196 If all interfaces belong to the same administration domain, it is 197 possible for the address-selection information to be controlled by 198 administrators of that domain. However, if not, routing 199 information and address selection policies are not always 200 equivalent between domains. For such cases, the algorithm for 201 merging policies have to be considered, which is documented in 202 this document. [I-D.arifumi-6man-addr-select-conflict] 204 7. Central control: 3 205 It can support central control. A site administrator or a service 206 provider can determine users' policy tables. 208 8. Route selection: 2 209 Current solutions, such as DHCPv6 and RA, do not have a mechanism 210 for cooperation with routing protocols. This could be done with 211 other techniques such as "source address based routing" or 212 "Default Router Preferences and More-Specific Routes" RFC 4191. 213 [RFC4191] 215 9. Compatibility with RFC 3493: 3 216 This approach is able to coexist with any kind of applications 217 (socket API). In detail, any types of function such as 218 getaddrinfo(), getsockname(), connect() or other typical system 219 calls will work without alterations if this mechanism is applied 220 to a host. 222 10. Compatibility and Interoperability with RFC 3484: 3 223 The basic idea of this approach has a compatibility with RFC3484. 224 This approach make RFC3484 policy table configurable to put some 225 hints related with it's individual network case. 227 11. Security: 2 228 By injecting address selection policy, a session hijacking can be 229 possible in this mechanism. A combination of Layer 2 securing 230 techniques and this mechanism will be able to be effective against 231 security concerns. DHCP and RA protocol have own security 232 measures and they also protect from them. 234 3.1.2. Other issues 236 None. 238 3.2. Routing system assistance (Proactive Approach) 240 Fred Baker proposed this approach. A host asks the DMZ routers or 241 the local router which is the best pair of source and destination 242 addresses when the host has a set of addresses A and the destination 243 host has a set of addresses B. Then, the host uses the policy 244 provided by the server/routing system as a guide in applying the 245 response. 247 3.2.1. Requirements correspondence analysis 249 1. Effectiveness: 3 250 A routing system knows about information about paths toward the 251 destination and information about which of their prefixes should 252 be used. Therefore, it is possible to select an appropriate pair 253 of source and destination addresses. 255 2. Timing: 3 256 A routing system always has up-to-date routing information, so it 257 will be possible to provide suitable information whenever requests 258 come. 260 3. Dynamic update: 3 261 A routing system always has up-to-date routing information, and it 262 will be possible to provide suitable information whenever requests 263 come. 265 4. Node-specific behavior: 3 266 Node-specific information can be provided if a server recognizes 267 individual nodes. 269 5. Application-specific behavior: 2 270 A routing system does not care about applications. Using address 271 selection API allows nodes to behave in an application-specific 272 way. 274 6. Multiple Interfaces: 2 275 The same as the policy based mechanism. 277 7. Central Control: 3 278 It is possible to provide address selection information from one 279 source. 281 8. Route Selection: 3 282 It is possible to give next-hop selection advice to a host. As 283 routers have routing information, it would seem to be easier for 284 routers to implement this function. 286 9. Compatibility with RFC 3493: 1 287 In the existing TCP/IP protocol stack implementation, destination 288 address selection is mainly the role of the application and not 289 that of the kernel unlike source address selection. Therefore, 290 implementing this model without affecting applications is not 291 feasible. 293 10. Compatibility and Interoperability with RFC 3484: 2< 294 Currently it just proposed and there is no implementation. 295 Therefore, it depends on how to implement with this requirement, 296 but it can be coexist with RFC3484. 298 11. Security: 2 300 This approach has a weakness on hijacking just like the previous 301 mechanism. 303 3.2.2. Other issues 305 - It has a possible scalability problem. A host must consult the 306 routing system every time it starts a connection if the host does 307 not have address selection information for the destination host or 308 if the information lifetime has expired. 310 - The existing host/router OS implementation must be changed a lot. 311 This can be problematic in some cases. 313 3.3. Trial-and-error based (Reactive Approach) 315 M. Bagnulo presented a new address selection idea in his draft. 316 Hirotaka Matsuoka extended and elaborated this approach in his draft. 317 [I-D.matsuoka-multihoming-try-and-error] When the host notices that a 318 network failure has occurred or packets have been dropped somewhere 319 in the network by, for example, an ingress filter, the host stores a 320 negative cache of address selection. 322 Hosts may use some kinds of error messages, e.g, ICMP error messages, 323 from a network to detect that sent packets did not reach the 324 destination quickly. 326 The host stores a cache of address selection information so that the 327 host can select an appropriate source address for new connections. 329 3.3.1. Requirement correspondence analysis 331 1. Effectiveness: 2 332 This solution is not effective for the destination address 333 selection cases, such as a problem about IPv4 or IPv6 334 prioritization described in the problem statement document. 336 2. Timing: 1 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. This 344 issue largely depends on the cacue functionality, but there is no 345 established algorithm for this. 347 3. Dynamic update: 3 348 If hosts detect a connection failure using some reliable 349 mechanism, such like TCP or ICMP error messages, a connection 350 failure caused by some changes in the network will be detected 351 immediately by the hosts. 353 4. Node-specific behavior: 2 354 This solution does not have a function for node-specific behavior. 355 However, it is not impossible to implement by deploying a packet 356 filter configured for each node at the gateways through which the 357 packets from nodes pass. 359 5. Application-specific behavior: 2 360 This solution does not have a function for application-specific 361 behavior. However, the mechanism of this approach does not 362 exclude address selection by each application. 364 6. Multiple interfaces: 3 365 If the protocol-stack or an application supports interface 366 selection and it tries to establish a connection by changing 367 addresses and also interfaces, it can find a working combination 368 of addresses and interface. 370 7. Central control: 2 371 The only way that a central administrator has to control the node 372 behavior is switching a filter on/off on the network. Therefore, 373 advanced control such as traffic engineering and QoS is almost 374 impossible. 376 8. Route Selection: 2 377 This solution does not refer to next-hop selection for the 378 transmission of a packet. So, it should be used with some routing 379 function such as RFC 4191 on the nodes. 381 9. Compatibility with RFC 3493: 1 382 This approach has possibility to interfere with coexistence with 383 applications(socket APIs). The returen value of functions would 384 be changed for its meaning. A case is suspected that the return 385 value of connect() system call will change its state from "non- 386 blocking" to "blocking" and this will bring alteration to the 387 application behaviours. Because of this suspicion, this approach 388 scores 1. 390 10. Compatibility and Interoperability with RFC 3484: 2 391 It depends on how to implement with this requirement. But there 392 will be possible conflict which a result will be overwrite the 393 3484 policy table without any permission of domain administrators. 395 11. Security: 1 396 This approach has a weakness on hijacking. Moreover, it may 397 expose the privacy of the user host by showing all or a part of 398 the addresses of the host to the destination host. 400 3.3.2. Other issues 402 - A host must learn address selection information for each 403 destination host. Therefore, the number of cache entries could be 404 very large. 406 - The existing host/router OS implementation must be changed a lot. 407 In particular, changing the source address of the existing 408 connection is not so easy and has a big impact on the existing 409 TCP/IP protocol stack implementation. 411 3.4. All at once (Reactive Approach) 413 This is another proposal by Fred Baker at 6man ML. By trying all the 414 pairs of source and destination addresses at once, or in a very shord 415 period of time, a connection can be established as far as there is at 416 least one working pair of addresses. 418 This mechiansm can easily combined with the error message retrieval 419 and cache function discussed in Section 3.3 to prune the unnecessary 420 connection trials. 422 3.4.1. Requirement correspondence analysis 424 1. Effectiveness: 2 425 This solution is not effective for the destination address 426 selection cases, such as a problem about IPv4 or IPv6 427 prioritization described in the problem statement document. 429 2. Timing: 3 430 The user does not have to wait for extra period of time. 432 3. Dynamic update: 3 433 It can reflect dynamically changing network, as far as it always 434 tries all possible addresses and next-hops. 436 4. Node-specific behavior: 2 437 This solution does not have a function for node-specific behavior. 438 However, it is not impossible to implement by setting a packet 439 filter for each node on the gateways through which the packets 440 from nodes pass. 442 5. Application-specific behavior: 2 443 This solution does not have a function for application-specific 444 behavior. However, the mechanism of this approach does not 445 exclude address selection by each application. 447 6. Multiple interfaces: 3 448 If the protocol-stack supports interface selection and it tries to 449 establish a connection by changing addresses and also interfaces, 450 it can find a working combination of addresses and interface. 451 But, in such a environment, a host has to try all the combinations 452 of source address, destination address, and next-hop addresses, 453 which can be huge amount of connection establishment trial. 455 7. Central control: 2 456 The only way that a central administrator has to control the node 457 behavior is switching a filter on/off on the network. Therefore, 458 advanced control such as traffic engineering and QoS is almost 459 impossible. 461 8. Route Selection: 2 462 This solution does not refer to next-hop selection for the 463 transmission of a packet. Therefore, it should be used with some 464 routing function such as RFC 4191 on the nodes. 466 9. Compatibility with RFC 3493: 1 467 For non-connected transport protocols, there is no universal nor 468 established way of telling a connection is successful or failure 469 from the viewpoint of anything other than the application. In 470 this sense, it does not work for non-connected transport 471 protocols. 473 10. Compatibility and Interoperability with RFC 3484: 1 474 This mechanism uses every possible addresses for its rather 475 initial connection setup. In that sense, it does not follow the 476 address selection rules of RFC 3484. 478 11. Security: 1 479 This approach has a weakness on hijacking. Moreover, it may 480 expose the privacy of the user host by showing all or a part of 481 the addresses of the host to the destination host. 483 3.4.2. Other issues 485 - It brings unnecessary traffic to network, host, routers, and 486 destinations. 488 - It breaks DNS round robin based load balancing. 490 - A host must learn address selection information for each 491 destination host. Therefore, the number of cache entries can be 492 very large. 494 - The existing host OS implementation must be changed significantly. 496 4. Applicability Comparison 498 If you actually want to choose one mechanism to solve your address 499 selection problem, it is important to figure out which approach is 500 best suited to your situation. This section tries to evaluate the 501 applicability of each approach from several aspects. 503 4.1. Dynamic-static and managed-unmanaged 505 We use two axes to evaluate the applicability of the four approaches. 506 One axis shows whether or not the network structure changes 507 dynamically and the other axis shows whether the site is managed or 508 unmanaged. In a managed network, by our definition, a network 509 administrator manages his or her network, routers, and hosts. For 510 example, an enterprise network is managed, whereas a home network and 511 a SOHO network are unmanaged. 513 static dynamic 514 <--------------------------------------------> 515 unmanaged ^ +----------+ +---------------------------+ 516 | | | +-+--------------+ all-at-once| 517 | | | | | | | 518 | | +--+-+-+------------+ | | 519 | | | | | | | | | 520 | | | | | | | | | 521 | | | | | +------------+-+------------+ 522 | | | | | try-error| | 523 | | +--+-+--------------+ | 524 | | | | | 525 | | | | | 526 | | Policy | | RouterAssist | 527 | | Dist | | | 528 | | | | | 529 | +----------+ +----------------+ 530 managed v 532 PolicyDist: 534 - In a dynamic site, the policy table must be updated accordingly 535 and traffic for policy table distribution increases. 537 try-and-error: 539 - This is a slightly manageable than all-at-once in that it does not 540 change the paths of established connections dynamically. 542 - In a very dynamic site, the use of an address selection 543 information cache does not have a good effect. This results in 544 connection failure and may degrade usability badly. 546 - Even in a very static site, a host may try inappropriate addresses 547 or next-hops and experience connection failures. 549 RouterAssist: 551 - A host must send at least as many queries as the number 552 destination hosts. Therefore, in a static site, this method is 553 not optimal. 555 - In a very dynamic site, address selection information cache is no 556 help. If the cache function is not used, then connection failures 557 do not occur. 559 all-at-once: 561 - In a static site, all-at-once is not desirable because of its 562 connection sequence overhead and timeout-wait for path 563 exploration. 565 - In a managed site, it is not easy to manage in terms of node- 566 specific address selection control and central control. 568 5. Security Considerations 570 Incorrect address selection can lead to serious security problems, 571 such as session hijacking. However, we should note that address- 572 selection is ultimately decided by nodes and their users. There are 573 no means to enforce a specific address-selection behavior upon every 574 end-host from outside the host. Therefore, a network administrator 575 must take countermeasures against unexpected address selection. 577 6. IANA Considerations 579 This document has no actions for IANA. 581 7. Conclusions 583 In this document, we examined solutions to address selection problems 584 in the IPv6 multi-prefix environment. From the requirement analysis 585 and applicability evaluation, it can be concluded that there is no 586 one perfect solution for this series of problems. 588 Hence, we have to combine two or more solutions together. The design 589 team proposal and all-at-once proposal are extreme opposite, and 590 combining these two seems to make the coverage biggest problem 591 spaces. 593 8. References 595 8.1. Normative References 597 [RFC3484] Draves, R., "Default Address Selection for Internet 598 Protocol version 6 (IPv6)", RFC 3484, February 2003. 600 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 601 "Problem Statement for Default Address Selection in Multi- 602 Prefix Environments: Operational Issues of RFC 3484 603 Default Rules", RFC 5220, July 2008. 605 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 606 "Requirements for Address Selection Mechanisms", RFC 5221, 607 July 2008. 609 8.2. Informative References 611 [I-D.arifumi-6man-addr-select-conflict] 612 Matsumoto, A., Fujisaki, T., and R. Hiromi, 613 "Considerations of address selection policy conflicts", 614 draft-arifumi-6man-addr-select-conflict-01 (work in 615 progress), October 2009. 617 [I-D.axu-addr-sel] 618 Suhonen, A., "Address Selection Using Source Address 619 Specific Routing Tables", draft-axu-addr-sel-00 (work in 620 progress), July 2009. 622 [I-D.fujisaki-dhc-addr-select-opt] 623 Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing 624 Address Selection Policy using DHCPv6", 625 draft-fujisaki-dhc-addr-select-opt-09 (work in progress), 626 March 2010. 628 [I-D.ietf-6man-addr-select-considerations] 629 Chown, T., "Considerations for IPv6 Address Selection 630 Policy Changes", 631 draft-ietf-6man-addr-select-considerations-00 (work in 632 progress), October 2009. 634 [I-D.ietf-shim6-multihome-shim-api] 635 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 636 "Socket Application Program Interface (API) for 637 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-13 638 (work in progress), February 2010. 640 [I-D.matsuoka-multihoming-try-and-error] 641 Matsuoka, H., "A Try and Error type approach for 642 multihoming", draft-matsuoka-multihoming-try-and-error-00 643 (work in progress), April 2009. 645 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 646 More-Specific Routes", RFC 4191, November 2005. 648 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 649 Addresses", RFC 4193, October 2005. 651 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 652 Socket API for Source Address Selection", RFC 5014, 653 September 2007. 655 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 656 Shim Protocol for IPv6", RFC 5533, June 2009. 658 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 659 Locator Pair Exploration Protocol for IPv6 Multihoming", 660 RFC 5534, June 2009. 662 Appendix A. Other Solutions 664 Other than policy table distribution based approach, Aleksi Suhonen 665 proposed his idea [I-D.axu-addr-sel], where a host has a separate 666 routing table for each attached address. The document is still 667 incompleted, but basically it should have characteristics in common 668 with above mentioned policy table based mechanism except for the 669 implementation characteristics. 671 shim6 [RFC5533] was designed for site-multihoming. This mechanism 672 introduces a new sub-layer in IP layer, and new address selection 673 method for session initiation and session survivability. it is 674 documented in RFC 5534. [RFC5534] shim6 should fall into try-and- 675 error based category, in that it establishes a connection by trying 676 pairs of addresses. 678 Appendix B. Revision History 680 03: 681 Combined shim6 and try-and-error mechanisms into one section 3.3. 682 Removed deployment analysis in Section 4. 683 Made the introduction short and brief. 684 Added a reference to Design Team's work. 685 Added a reference to address selection conflict draft. 686 Created Appendix A. to mention about other solution proposals. 687 Conclusion and abstract was modified to reflect the discussion at 688 6man ML. 690 02: 691 Updated references for documents that were approved as RFCs. 692 Added reference to Hirotaka Matsuoka's try-and-error mechanism. 693 Added description about Aleksi Suhonen's routing table based 694 mechanism. 696 01: 698 Corresponding to the increase of RFC 5221 requirements, 699 considerations about requirement #9, #10, #11 are added for each 700 approach. 702 00: 703 Approved as a 6man working group item. 705 Authors' Addresses 707 Arifumi Matsumoto 708 NTT PF Lab 709 Midori-Cho 3-9-11 710 Musashino-shi, Tokyo 180-8585 711 Japan 713 Phone: +81 422 59 3334 714 Email: arifumi@nttv6.net 716 Tomohiro Fujisaki 717 NTT PF Lab 718 Midori-Cho 3-9-11 719 Musashino-shi, Tokyo 180-8585 720 Japan 722 Phone: +81 422 59 7351 723 Email: fujisaki@syce.net 725 Ruri Hiromi 726 Intec Netcore, Inc. 727 Shinsuna 1-3-3 728 Koto-ku, Tokyo 136-0075 729 Japan 731 Phone: +81 3 5665 5069 732 Email: hiromi@inetcore.com