idnits 2.17.1 draft-ietf-6man-addr-select-sol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 == Line 687 has weird spacing: '...4update shim...' -- 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 (July 2, 2009) is 5383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-09) exists of draft-fujisaki-dhc-addr-select-opt-07 == Outdated reference: A later version (-17) exists of draft-ietf-shim6-multihome-shim-api-08 Summary: 2 errors (**), 0 flaws (~~), 4 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: January 3, 2010 R. Hiromi 6 Intec Netcore 7 K. Kanayama 8 INTEC Systems 9 July 2, 2009 11 Solution approaches for address-selection problems 12 draft-ietf-6man-addr-select-sol-02.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on January 3, 2010. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 In response to address selection problem statement and requirement 60 documents, this document describes approaches to solutions and 61 evaluates proposed solution mechanisms in line with requirements. It 62 also examines the applicability of each solution mechanism from the 63 viewpoint of practical application. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. Solution Design . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1. Proactive approaches . . . . . . . . . . . . . . . . . . . 4 70 2.2. Reactive approaches . . . . . . . . . . . . . . . . . . . 5 71 3. Solution approaches . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Obtain all information prior to communication (Most 73 Proactive) . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1.2. Requirements correspondence analysis . . . . . . . . . 6 76 3.1.3. Other issues . . . . . . . . . . . . . . . . . . . . . 7 77 3.2. Routing system assistance for address selection 78 (Proactive) . . . . . . . . . . . . . . . . . . . . . . . 7 79 3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.2.2. Requirements correspondence analysis . . . . . . . . . 8 81 3.2.3. Other issues . . . . . . . . . . . . . . . . . . . . . 9 82 3.3. Trial-and-error approach (Reactive) . . . . . . . . . . . 10 83 3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 10 84 3.3.2. Requirement correspondence analysis . . . . . . . . . 10 85 3.3.3. Other issues . . . . . . . . . . . . . . . . . . . . . 12 86 3.4. All-by-oneself approach (Most Reactive) . . . . . . . . . 12 87 3.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 12 88 3.4.2. Requirement correspondence analysis . . . . . . . . . 13 89 3.4.3. Other issues . . . . . . . . . . . . . . . . . . . . . 14 90 4. Applicability Comparison . . . . . . . . . . . . . . . . . . . 14 91 4.1. Dynamic-static and managed-unmanaged . . . . . . . . . . . 15 92 4.2. Deployment Difficulty . . . . . . . . . . . . . . . . . . 16 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 95 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 98 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 99 Appendix A. Appendix. Revision History . . . . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 102 1. Introduction 104 One physical network can have multiple logical networks. In that 105 case, an end-host has multiple IP addresses. (e.g, in the IPv4-IPv6 106 dual-stack environment, in a site that uses both ULA [RFC4193] and 107 global scope addresses or in a site connected to multiple upstream 108 IPv6 networks.) For such a host, RFC 3484 [RFC3484] defines default 109 address-selection rules for the source and destination addresses. 111 Today, the RFC 3484 mechanism is widely implemented in major OSs. 112 However, many people, including us, have found that in many sites the 113 default address-selection rules are not appropriate for the network 114 structure. RFC 5220 [RFC5220] lists problematic cases that resulted 115 from incorrect address selection. 117 Though RFC 3484 made the address-selection behavior of a host 118 configurable, typical users cannot make use of that because of the 119 complexity of the mechanism and their lack of knowledge about their 120 network topologies. Therefore, an address-selection 121 autoconfiguration mechanism is necessary, especially for the 122 unmanaged hosts of typical users. 124 RFC 5221 [RFC5221] document enumerates requirements for address- 125 selection mechanisms that enable hosts to perform appropriate address 126 selection automatically. 128 In the IETF mailing lists and in the internet-draft archives, some 129 mechanisms for solving address-selection problems have already been 130 proposed. This document describes possible design approaches for 131 solving address selection problems. After that, we try to put 132 together an overview as well as an analysis of how well the method 133 corresponds with the requirements. 135 2. Solution Design 137 There are two types of approaches that can control the behavior of 138 hosts in terms of the selection of destination address and source 139 address. The first type is proactive, where the host is given the 140 necessary information to decide the destination and source addresses 141 before the beginning of transmission. The other type is reactive, 142 where the host decides appropriate destination address and source 143 addresses through trial and error. 145 2.1. Proactive approaches 147 There can be two types of proactive approaches. One gives hosts all 148 the information for selecting destination and address and source 149 addresses beforehand. Under some circumstances, a lot of information 150 could be stored in hosts. 152 The other type informs hosts about which prefixes should be used in 153 the source address for the different destinations every time before 154 starting each connection. 156 2.2. Reactive approaches 158 In these approaches, the host does not have initial information for 159 address selection. It will try using different pairs of destination 160 and source addresses until the connection is established. When an 161 outage occurs, the host must detect it and try again with a new pair 162 of destination address and source address. Some reactive solutions 163 may use some kind of control message that enables the gateway to 164 indicate the outage. 166 3. Solution approaches 168 This section describes the evaluation of the four approaches to 169 finding solutions. The evaluation value has a 3-point scale for each 170 of 8 requirements in the requirement document. The meaning of the 171 points is as follows. 173 1 : bad 174 2 : fair 175 3 : good 177 About "Effectiveness", the score is 1 if the approach solves no 178 problematic cases described in the problem statement document, 2 if 179 it can handle at least one, and 3 if it solves every case. 181 3.1. Obtain all information prior to communication (Most Proactive) 183 3.1.1. Overview 185 In this approach, a host obtains everything needed to select 186 addresses at once prior to communication. A host receives all policy 187 information from a server beforehand. It then sets up communication 188 whenever it wants to. DHCPv6 and RA fall into this category as known 189 protocols. There is a reference document 190 [I-D.fujisaki-dhc-addr-select-opt] in which DHCPv6 is used for this 191 purpose. 193 This approach can take advantage of the RFC 3484 Policy Table, which 194 is already widely deployed. By distributing policies for the Policy 195 Table, you can auto-configure a host's address selection policy. 197 Other than policy table based approach, Aleksi Suhonen proposed his 198 idea where a host has a separate routing table for each attached 199 address. He has not submitted any internet draft, but he posted it 200 to the mailing list and referred to it as draft-axu-addr-sel-pre00. 201 The documented idea was still incompleted, but basically it should 202 have characteristics in common with above mentioned policy table 203 based mechanism except the implementation characteristic. 205 3.1.2. Requirements correspondence analysis 207 1. Effectiveness: 3 209 It can support all cases by using the policy table. 211 2. Timing: 3 213 All information for communication is in a host in advance. 214 Communication starts at once when it is necessary and the 215 communication process refers to local policy information, so it 216 exhibits good usability. Moreover, this leads to fewer overheads 217 than per-connection mechanisms. 219 3. Dynamic update: 3 221 Though it depends on what protocol is used to distribute the 222 policies, some mechanisms support information updates from the 223 server. Moreover, it is difficult to support dynamic network 224 changes and real-time updates in some specific protocols. 226 4. Node-specific behavior: 3 228 For distribution to individual hosts in the same segment, DHCPv6 229 can be used. 231 5. Application-specific behavior: 2 233 The policy table itself doesn't support application-specific 234 address selection. It can be done using the address selection 235 API. [RFC5014] 237 6. Multiple interfaces: 2 239 If all interfaces belong to the same administration domain, it is 240 possible for the address-selection information to be controlled by 241 administrators of that domain. However, if not, routing 242 information and address selection policies are not always 243 equivalent between domains, and it is not possible to handle them. 245 7. Central control: 3 247 It can support central control. A site administrator or a service 248 provider can determine users' policy tables. 250 8. Route selection: 2 252 Current solutions, such as DHCPv6 and RA, do not have a mechanism 253 for cooperation with routing protocols. This could be done with 254 other techniques such as "source address based routing" or 255 "Default Router Preferences and More-Specific Routes" RFC 4191. 256 [RFC4191] 258 9. Compatibility with RFC 3493: 3 260 This approach is able to coexist with any kind of applications 261 (socket API). In detail, any types of function such as 262 getaddrinfo(), getsockname(), connect() or other typical system 263 calls will work without alterations if this mechanism is applied 264 to a host. 266 10. Compatibility and Interoperability with RFC 3484: 3 268 The basic idea of this approach has a compatibility with RFC3484. 269 This approach make RFC3484 policy table configurable to put some 270 hints related with it's individual network case. 272 11. Security: 2 274 This approach has a weakness on hijacking. A combination of Layer 275 2 securing techniques and this mechanism will be able to be 276 effective against security concerns. DHCP and RA protocol have 277 own security measures and they also protect from them. 279 3.1.3. Other issues 281 - The traffic volume will be equal to the number of policies. 283 - Hosts and servers need to support this function. 285 3.2. Routing system assistance for address selection (Proactive) 287 3.2.1. Overview 289 Fred Baker proposed this approach. A host asks the DMZ routers or 290 the local router which is the best pair of source and destination 291 addresses when the host has a set of addresses A and the destination 292 host has a set of addresses B. Then, the host uses the policy 293 provided by the server/routing system as a guide in applying the 294 response. He also proposed a mechanism that utilizes the ICMP error 295 message to change the source address of the existing session. This 296 point resembles Section 3.3 3484update mechanism, so the following 297 evaluation is based on only the first part of his proposal. 299 3.2.2. Requirements correspondence analysis 301 1. Effectiveness: 3 303 A routing system knows about information about paths toward the 304 destination and information about which of their prefixes should 305 be used. Therefore, it is possible to select an appropriate pair 306 of source and destination addresses. 308 2. Timing: 3 310 A routing system always has up-to-date routing information, so it 311 will be possible to provide suitable information whenever requests 312 come. However, the amount of information that the system must 313 handle is huge, so there will be cases where it takes time to 314 answer the request because appropriate information must be 315 retrieved from a huge database. 316 If any server or routing trouble occurs, the requester cannot get 317 the answer, and address selection will fail. This point is the 318 same in all systems that depend on other servers. 320 3. Dynamic update: 3 322 A routing system always has up-to-date routing information, and it 323 will be possible to provide suitable information whenever requests 324 come. 326 4. Node-specific behavior: 3 328 Node-specific information can be provided if a server recognizes 329 individual nodes. 331 5. Application-specific behavior: 2 333 A routing system does not care about applications. Using address 334 selection API allows nodes to behave in an application-specific 335 way. 337 6. Multiple Interfaces: 2 338 If all interfaces belong to the same administration domain, it is 339 possible for the address-selection information to be controlled by 340 administrators of that domain. However, if not, routing 341 information and address selection policies are not always 342 equivalent between domains, and it is not possible to handle them. 344 7. Central Control: 3 346 It is possible to provide address selection information from one 347 source. However, because routing information changes dynamically, 348 it is difficult to control it in the way that administrators want. 350 8. Route Selection: 3 352 It is possible to give next-hop selection advice to a host. As 353 routers have routing information, it would seem to be easier for 354 routers to implement this function. 356 9. Compatibility with RFC 3493: 3 358 This approach is able to coexist with any kind of applications 359 (socket API). In detail, any types of function such as 360 getaddrinfo(), getsockname(), connect() or other typical system 361 calls will work without alterations if this mechanism is applied 362 to a host. In the existing TCP/IP protocol stack implementation, 363 destination address selection is mainly the role of the 364 application and not that of the kernel unlike source address 365 selection. Therefore, implementing this model without affecting 366 applications is not so easy. 368 10. Compatibility and Interoperability with RFC 3484: 2 370 Currently it just proposed and there is no implementation. 371 Therefore, it depends on how to implement with this requirement 372 and it can be coexistence with RFC3484. 374 11. Security: 2 376 This approach has a weakness on hijacking. Currently it just 377 proposed and there is no implementation. Therefore, it depends on 378 how to define security protection mechanism and how to implement 379 it. 381 3.2.3. Other issues 382 - A host must consult the routing system every time it starts a 383 connection if the host does not have address selection information 384 for the destination host or if the information lifetime has 385 expired. This could be a possible scalability problem. 387 - The existing host/router OS implementation must be changed a lot. 388 In the existing TCP/IP protocol stack implementation, destination 389 address selection is mainly the role of the application and not 390 that of the kernel unlike source address selection. Therefore, 391 implementing this model without affecting applications is not so 392 easy. 394 3.3. Trial-and-error approach (Reactive) 396 3.3.1. Overview 398 M. Bagnulo presented a new address selection idea in his draft. 399 Hirotaka Matsuoka extended and elaborated this approach in his draft. 400 [I-D.matsuoka-multihoming-try-and-error] When the host notices that a 401 network failure has occurred or packets have been dropped somewhere 402 in the network by, for example, an ingress filter, the host changes 403 the source address of the connection to another source address. 405 Hosts may use some kinds of error messages, e.g, ICMP error messages, 406 from a network to detect that sent packets did not reach the 407 destination quickly. 409 The host stores a cache of address selection information so that the 410 host can select an appropriate source address for new connections. 412 For source address selection by the application that initiated a 413 communication, this method provides an ordered list of source 414 addresses for the destination address to the application. 416 3.3.2. Requirement correspondence analysis 418 1. Effectiveness: 2 420 This solution is not effective for the problem about IPv4 or IPv6 421 prioritization described in the problem statement document. 423 2. Timing: 2 425 Hosts should try to use all the available source addresses to the 426 maximum to find an appropriate source address. If the host tries 427 the next source address after the previous trial using another 428 source address has failed, it may take a long time because this 429 trial-and-error process lasts until the connection succeeds. If 430 the host does not use an error message from a network to detect a 431 connection error, it takes longer to wait for a time-out. 433 3. Dynamic update: 3 435 If hosts detect a connection failure using some reliable 436 mechanism, such like TCP or ICMP error messages, a connection 437 failure caused by some changes in the network will be detected 438 immediately by the hosts. 440 4. Node-specific behavior: 2 442 This solution does not have a function for node-specific behavior. 443 However, it is not impossible to implement by setting a packet 444 filter for each node at the gateways through which the packets 445 from nodes pass. 447 5. Application-specific behavior: 2 449 This solution does not have a function for application-specific 450 behavior. However, the mechanism of this approach does not 451 exclude address selection by each application. 453 6. Multiple interfaces: 3 455 If the protocol-stack or an application supports interface 456 selection and it tries to establish a connection by changing 457 addresses and also interfaces, it can find a working combination 458 of addresses and interface. 460 7. Central control: 2 462 The only way that a central administrator has to control the node 463 behavior is switching a filter on/off on the network. Therefore, 464 advanced control such as traffic engineering and QoS is almost 465 impossible. 467 8. Route Selection: 2 469 This solution does not refer to next-hop selection for the 470 transmission of a packet. So, it should be used with some routing 471 function such as RFC 4191 on the nodes. 473 9. Compatibility with RFC 3493: 1 474 This approach has possibility to interfere with coexistence with 475 applications(socket APIs). The returen value of functions would 476 be changed for its meaning. A case is suspected that the return 477 value of connect() system call will change its state from "non- 478 blocking" to "blocking" and this will bring alteration to the 479 application behaviours. Because of this suspicion, this approach 480 scores 1. 482 10. Compatibility and Interoperability with RFC 3484: 2 484 It depends on how to implement with this requirement. But there 485 will be possible conflict which a result will be overwrite the 486 3484 policy table without any permission of domain administrators. 488 11. Security: 2 490 This approach has a weakness on hijacking. Currently it just 491 proposed and there is no implementation. Therefore, it depends on 492 how to define security protection mechanism and how to implement 493 it. 495 3.3.3. Other issues 497 - A host must learn address selection information for each 498 destination host. Therefore, the number of cache entries could be 499 very large. 501 - The existing host/router OS implementation must be changed a lot. 502 In particular, changing the source address of the existing 503 connection is not so easy and has a big impact on the existing 504 TCP/IP protocol stack implementation. 506 3.4. All-by-oneself approach (Most Reactive) 508 3.4.1. Overview 510 shim6 [RFC5533] was designed for site-multihoming. This mechanism 511 introduces a new address selection method for session initiation and 512 session survivability; it is documented in RFC 5534. [RFC5534] 514 The shim6 host detects connection failures and changes the 515 destination and source addresses during the session. 517 In this document, we focus on address selection issues in the 518 connection initiation phase of shim6 and not on any other functions, 519 such as session survivability. 521 3.4.2. Requirement correspondence analysis 523 1. Effectiveness: 2 525 This solution is not effective for the problem about IPv4 or IPv6 526 prioritization described in the problem statement document. 528 2. Timing: 2 530 Hosts should try to use all the available source addresses to the 531 maximum to find an appropriate source address. If the host tries 532 the next source address after the previous trial using another 533 source address has failed, it may take a long time because this 534 trial-and-error process lasts until the connection succeeds. If 535 the host does not use error messages from a network to detect a 536 connection error, it takes longer to wait for a time-out. 538 3. Dynamic update: 3 540 It can reflect dynamically changing network, as far as it always 541 tries all possible addresses and next-hops. 543 4. Node-specific behavior: 2 545 This solution does not have a function for node-specific behavior. 546 However, it is not impossible to implement by setting a packet 547 filter for each node on the gateways through which the packets 548 from nodes pass. 550 5. Application-specific behavior: 2 552 The use of shim6 API [I-D.ietf-shim6-multihome-shim-api] allows 553 applications to override address selection behavior. 555 6. Multiple interfaces: 3 557 If the protocol-stack supports interface selection and it tries to 558 establish a connection by changing addresses and also interfaces, 559 it can find a working combination of addresses and interface. 561 7. Central control: 2 563 The only way that a central administrator has to control the node 564 behavior is switching a filter on/off on the network. Therefore, 565 advanced control such as traffic engineering and QoS is almost 566 impossible. 568 8. Route Selection: 2 569 This solution does not refer to next-hop selection for the 570 transmission of a packet. Therefore, it should be used with some 571 routing function such as RFC 4191 on the nodes. 573 9. Compatibility with RFC 3493: 3 575 This approach is able to coexist with any kind of applications 576 (socket API). In detail, any types of function such as 577 getaddrinfo(), getsockname(), connect() or other typical system 578 calls will work without alterations if this mechanism is applied 579 to a host. 581 10. Compatibility and Interoperability with RFC 3484: 1 583 shim6 has different framework and coordination with RFC 3484. The 584 shim6 host performs address selection that reflects network host. 585 This may lead some interference with RFC3484 policy table. 587 11. Security: 1 589 This approach has a weakness on Denial of Service attack. It will 590 be concerned that the malicious users can abuse of failure 591 detection and make the network falling into critical condition. 592 However, it depends on a situation how shim6 operate with ICMPv6. 594 3.4.3. Other issues 596 - The shim6 host performs address selection that reflects network 597 failures that have occurred between the source and destination 598 host. 600 - End hosts themselves can avoid network failure. There is no need 601 to modify or reconfigure routers in the path. 603 - A host must learn address selection information for each 604 destination host. Therefore, the number of cache entries can be 605 very large. 607 - The existing host OS implementation must be changed significantly. 609 4. Applicability Comparison 611 In the previous section, every approach scored "fair" or better for 612 every requirement. This means that every approach can meet the 613 demands of address selection. However, if you actually want to 614 choose one mechanism to solve your address selection problem, it is 615 important to figure out which approach is best suited to your 616 situation. This section tries to evaluate the applicability of each 617 approach from several aspects. 619 4.1. Dynamic-static and managed-unmanaged 621 First, we use two axes to evaluate the applicability of the four 622 approaches. One axis shows whether or not the network structure 623 changes dynamically and the other axis shows whether the site is 624 managed or unmanaged. In a managed network, by our definition, a 625 network administrator manages his or her network, routers, and hosts. 626 For example, an enterprise network is managed, whereas a home network 627 and a SOHO network are unmanaged. 629 static dynamic 630 <--------------------------------------------> 631 unmanaged ^ +----------+ +---------------------------+ 632 | | | +-+--------------+ shim6 | 633 | | | | | | | 634 | | +--+-+-+------------+ | | 635 | | | | | | | | | 636 | | | | | | | | | 637 | | | | | +------------+-+------------+ 638 | | | | | 3484update| | 639 | | +--+-+--------------+ | 640 | | | | | 641 | | | | | 642 | | Policy | | RouterAssist | 643 | | Dist | | | 644 | | | | | 645 | +----------+ +----------------+ 646 managed v 648 PolicyDist: 650 - In a dynamic site, the policy table must be updated accordingly 651 and traffic for policy table distribution increases. 653 3484update: 655 - This is a slightly manageable than shim6 in that 3484update does 656 not change the paths of established connections dynamically. 658 - In a very dynamic site, the use of an address selection 659 information cache does not have a good effect. This results in 660 connection failure and may degrade usability badly. 662 - Even in a very static site, a host may try inappropriate addresses 663 or next-hops and experience connection failures. 665 RouterAssist: 667 - A host must send at least as many queries as the number 668 destination hosts. Therefore, in a static site, this method is 669 not optimal. 671 - In a very dynamic site, address selection information cache is no 672 help. If the cache function is not used, then connection failures 673 do not occur. 675 shim6: 677 - In a static site, shim6 is not desirable because of its connection 678 sequence overhead and timeout-wait for path exploration. 680 - In a managed site, shim6 is not easy to manage in terms of node- 681 specific address selection control and central control. 683 4.2. Deployment Difficulty 685 less more 686 <-------------------------------------------> 687 policy-dist 3484update shim6 Fred 689 PolicyDist: 691 - What must be implemented is a distribution mechanism. The 692 existing protocols, such as RA and DHCP, can be used for this 693 purpose. 695 3484update: 697 - The protocol stack or applications on a host must be modified. 698 Routers in a site must be configured to return error messages to 699 the sender of inappropriately addressed packets. In RFC3484, 700 precedences and labels are configurable, but not scopes. Those of 701 issues with ULA prefix or non routable global prefix still be left 702 behind even if this RFC would be updated. 704 RouterAssist: 706 - The protocol stack and applications on a host must be modified. 707 Furthermore, routers must be modified. 709 shim6: 711 - The protocol stack must be modified. For this address selection 712 purpose, corresponding nodes need not support shim6. Basically, 713 there is no need to change the router implementation or 714 configuration. 716 5. Security Considerations 718 Incorrect address selection can lead to serious security problems, 719 such as session hijacking. However, we should note that address- 720 selection is ultimately decided by nodes and their users. There are 721 no means to enforce a specific address-selection behavior upon every 722 end-host from outside the host. Therefore, a network administrator 723 must take countermeasures against unexpected address selection. 725 6. IANA Considerations 727 This document has no actions for IANA. 729 7. Conclusions 731 In this document, we examined solutions to address selection problems 732 in the IPv6 multi-prefix environment. Although almost all solutions 733 examined in this document could be applied to any environment and 734 situation, a solution with a mechanism that is suitable for the 735 situation should be selected. 737 8. References 739 8.1. Normative References 741 [RFC3484] Draves, R., "Default Address Selection for Internet 742 Protocol version 6 (IPv6)", RFC 3484, February 2003. 744 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 745 "Problem Statement for Default Address Selection in Multi- 746 Prefix Environments: Operational Issues of RFC 3484 747 Default Rules", RFC 5220, July 2008. 749 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 750 "Requirements for Address Selection Mechanisms", RFC 5221, 751 July 2008. 753 8.2. Informative References 755 [I-D.fujisaki-dhc-addr-select-opt] 756 Fujisaki, T., Matsumoto, A., Niinobe, S., Hiromi, R., and 757 K. Kanayama, "Distributing Address Selection Policy using 758 DHCPv6", draft-fujisaki-dhc-addr-select-opt-07 (work in 759 progress), March 2009. 761 [I-D.ietf-shim6-multihome-shim-api] 762 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 763 "Socket Application Program Interface (API) for 764 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-08 765 (work in progress), May 2009. 767 [I-D.matsuoka-multihoming-try-and-error] 768 Matsuoka, H., "A Try and Error type approach for 769 multihoming", draft-matsuoka-multihoming-try-and-error-00 770 (work in progress), April 2009. 772 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 773 More-Specific Routes", RFC 4191, November 2005. 775 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 776 Addresses", RFC 4193, October 2005. 778 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 779 Socket API for Source Address Selection", RFC 5014, 780 September 2007. 782 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 783 Shim Protocol for IPv6", RFC 5533, June 2009. 785 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 786 Locator Pair Exploration Protocol for IPv6 Multihoming", 787 RFC 5534, June 2009. 789 Appendix A. Appendix. Revision History 791 02: 792 Updated references for documents that were approved as RFCs. 794 Added reference to Hirotaka Matsuoka's try-and-error mechanism. 795 Added description about Aleksi Suhonen's routing table based 796 mechanism. 798 01: 799 Corresponding to the increase of RFC 5221 requirements, 800 considerations about requirement #9, #10, #11 are added for each 801 approach. 803 00: 804 Approved as a 6man working group item. 806 Authors' Addresses 808 Arifumi Matsumoto 809 NTT PF Lab 810 Midori-Cho 3-9-11 811 Musashino-shi, Tokyo 180-8585 812 Japan 814 Phone: +81 422 59 3334 815 Email: arifumi@nttv6.net 817 Tomohiro Fujisaki 818 NTT PF Lab 819 Midori-Cho 3-9-11 820 Musashino-shi, Tokyo 180-8585 821 Japan 823 Phone: +81 422 59 7351 824 Email: fujisaki@syce.net 826 Ruri Hiromi 827 Intec Netcore, Inc. 828 Shinsuna 1-3-3 829 Koto-ku, Tokyo 136-0075 830 Japan 832 Phone: +81 3 5665 5069 833 Email: hiromi@inetcore.com 834 Ken-ichi Kanayama 835 INTEC Systems Institute, Inc. 836 Shimoshin-machi 5-33 837 Toyama-shi, Toyama 930-0804 838 Japan 840 Phone: +81 76 444 8088 841 Email: kanayama_kenichi@intec-si.co.jp