idnits 2.17.1 draft-axu-addr-sel-00.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.ii 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC3484, but the abstract doesn't seem to directly say this. It does mention RFC3484 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3484, updated by this document, for RFC5378 checks: 2003-03-04) -- 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 29, 2009) is 5385 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 none yet A. Suhonen 3 Internet-Draft Tampere University of Technology, 4 Updates: 3484 (if approved) Finland 5 Intended status: Experimental July 29, 2009 6 Expires: January 30, 2010 8 Address Selection Using Source Address Specific Routing Tables 9 draft-axu-addr-sel-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 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 January 30, 2010. 44 Copyright Notice 46 Copyright (c) 2009 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 in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 RFC 3484 defines two algorithms for default source and destination 58 address selection, but it has several shortcomings as specified in 59 RFC 5220. RFC 5221 lists some requirements for any attempts to 60 update the original RFC. This document specifies an alternate 61 address selection algorithm to fulfill those requirements. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2. Filter Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Link Local Scope . . . . . . . . . . . . . . . . . . . . . 5 69 2.2. Autoconfiguration for Global Scope . . . . . . . . . . . . 5 70 2.3. Site Local Scope . . . . . . . . . . . . . . . . . . . . . 5 71 2.4. Additional Filter Constraints . . . . . . . . . . . . . . 6 72 2.5. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 6 73 2.6. Dynamic Routing Protocols . . . . . . . . . . . . . . . . 6 74 3. Precedences and Labels . . . . . . . . . . . . . . . . . . . . 7 75 3.1. Route and Table Preferences . . . . . . . . . . . . . . . 7 76 3.1.1. Local and Link Local Scope Routing Tables . . . . . . 8 77 3.1.2. Global Scope Routing Tables . . . . . . . . . . . . . 8 78 3.1.3. Transition Technique Routing Tables . . . . . . . . . 8 79 3.1.4. IPv4 Compatible Routing Tables . . . . . . . . . . . . 9 80 3.1.5. Reachability Information . . . . . . . . . . . . . . . 9 81 4. RFC3484 Rule Comparison . . . . . . . . . . . . . . . . . . . 9 82 5. RFC5220 Concerns . . . . . . . . . . . . . . . . . . . . . . . 9 83 5.1. Multiple Routers on a Single Interface . . . . . . . . . . 9 84 5.2. Ingress Filtering Problem . . . . . . . . . . . . . . . . 9 85 5.3. Half-Closed Network Problem . . . . . . . . . . . . . . . 9 86 5.4. Combined Use of Global and ULA . . . . . . . . . . . . . . 10 87 5.5. Site Renumbering . . . . . . . . . . . . . . . . . . . . . 10 88 5.6. Multicast Source Address Selection . . . . . . . . . . . . 10 89 5.7. Temporary Address Selection . . . . . . . . . . . . . . . 10 90 5.8. IPv4 or IPv6 Prioritization . . . . . . . . . . . . . . . 11 91 5.9. ULA and IPv4 Dual-Stack Environment . . . . . . . . . . . 11 92 5.10. ULA or Global Prioritization . . . . . . . . . . . . . . . 11 93 6. RFC5221 Requirements . . . . . . . . . . . . . . . . . . . . . 11 94 6.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . 11 95 6.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 6.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . 11 97 6.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 12 98 6.5. Application-Specific Behavior . . . . . . . . . . . . . . 12 99 6.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 12 100 6.7. Central Control . . . . . . . . . . . . . . . . . . . . . 12 101 6.8. Next-Hop Selection . . . . . . . . . . . . . . . . . . . . 12 102 6.9. Compatibility with RFC 3493 . . . . . . . . . . . . . . . 12 103 6.10. Compatibility and Interoperability with RFC 3484 . . . . . 13 104 6.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 13 105 7. Implementation Issues and Other Concerns . . . . . . . . . . . 13 106 7.1. Low Memory and Power Concerns . . . . . . . . . . . . . . 13 107 7.2. Differing Larger Scopes . . . . . . . . . . . . . . . . . 13 108 7.3. Connection Pooling . . . . . . . . . . . . . . . . . . . . 14 109 7.4. Using Just One Table with Tags . . . . . . . . . . . . . . 14 110 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 112 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 113 10.1. RFC5220 Considerations . . . . . . . . . . . . . . . . . . 15 114 10.2. RFC5221 Requirements . . . . . . . . . . . . . . . . . . . 15 115 10.2.1. List of threats introduced by new 116 address-selection mechanism . . . . . . . . . . . . . 15 117 10.2.2. List of recommendations in which security 118 mechanism should be applied . . . . . . . . . . . . . 15 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 120 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 121 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 122 Appendix A. Routing Table Example . . . . . . . . . . . . . . . . 16 123 A.1. Before . . . . . . . . . . . . . . . . . . . . . . . . . . 16 124 A.2. After Conversion . . . . . . . . . . . . . . . . . . . . . 17 125 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 127 1. Introduction 129 [RFC3484] defines default address selection rules for IPv6 and IPv4. 130 Several shortcomings in the original address selection rules have 131 been identified in [RFC5220] and its sister document [RFC5221] 132 specifies some requirements for any attempts to update the original 133 address selection algorithm. 135 A further concern comes from multipath protocols. When SCTP 136 [RFC2960], for example, finds that its active source destination 137 address pair is no longer functional, it will need to start searching 138 for a new one. 140 The communicating hosts may both have a dozen addresses so it might 141 take unacceptably long to iterate through all combinations before 142 finding a functional pair. On the other hand, many of the invalid 143 combinations could be filtered out using this algorithm, making the 144 process noticeably faster. 146 1.1. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 2. Filter Algorithm 154 When a host has several addresses, they SHOULD each be associated 155 with their own routing tables. When selecting source and destination 156 addresses, the first stage is to filter out combinations where the 157 routing table attached with the source (local) address does not have 158 a valid route for the destination (remote) address. In other words, 159 if a destination address can't be found from the routing table for a 160 given source address the system MUST discard that destination address 161 for that source address. 163 If none of the possible destination addresses can be found in the 164 routing table for a source address, then that source address MUST be 165 discarded for those destination addresses. 167 One side effect of this filter algorithm is that it doesn't need to 168 know anything about scopes. The routing tables associated with 169 source address candidates will determine what destination addresses 170 they are usable with. This effect is demonstrated below and later in 171 this document. 173 2.1. Link Local Scope 175 The routing table associated with a link local address (e.g. 176 169.254.123.45%le0) SHOULD only have one external unicast route, the 177 link local network for that link (e.g. 169.254.0.0%le0 /16). In 178 addition, if the host supports multicast on this link, a route for 179 the local scope multicast space SHOULD also appear in this table. 181 This means that the link local address is usable only with other link 182 local addresses on the same link. 184 The localhost addresses and prefixes (127.0.0.1/8 and ::1/128) SHOULD 185 be treated like link local scope in this algorithm. 187 2.2. Autoconfiguration for Global Scope 189 When addresses are assigned to interfaces dynamically through 190 stateless or stateful autoconfiguration the process usually also 191 yields a default route. That default route SHOULD be placed only 192 into the routing table associated with that address. In addition, if 193 the host and network support multicast, a route for the global scope 194 multicast space SHOULD also appear in this table. 196 This usually means that the next hop of that default route will only 197 be useable with the source address learned from that default router. 199 Some autoconfiguration methods (see [RFC3442] and [RFC4191]) can be 200 used to communicate other routes in addition to the default route. 201 Those routes SHOULD likewise be added only into the routing table 202 associated with the address configured using that same interchange. 204 Examples of autoconfiguration methods include RARP, DHCPv4, ICMPv6 205 RA, DHCPv6, Teredo, 6to4, ISATAP, PPP, mDNS. 207 2.3. Site Local Scope 209 The routing tables for site local addresses SHOULD have routes for 210 site local address space. They SHOULD NOT have the default route, so 211 that they would be automatically eliminated when selecting address 212 pairs for site external communication. 214 However, if the site edge automatically translates site local 215 addresses to global addresses, the routing tables associated with 216 site local scope addresses MAY have the default route. 218 2.4. Additional Filter Constraints 220 The address selection algorithm MAY also be given additional filter 221 constraints, such as "use only link#3" or "do not use next-hop 222 10.0.0.1". [RFC5014] specifies an interface that does something very 223 similar. 225 Work is going on in the MIF-wg [I-D.blanchet-mif-problem-statement] 226 to tie address selection and next-hop selection with DNS resolver 227 selection and other similar resources. That is, when using the DNS 228 resolvers received from one DHCP server, the terminal should also 229 always use the default route received from that DHCP server. 231 This algorithm supports those efforts by making it possible to 232 restrict a process to one routing table for both address resolution 233 and selection. 235 2.5. Forwarding 237 If a host is configured to forward packets between networks, it 238 SHOULD combine the routing tables for the networks in question into 239 one. Link local scope tables MUST NOT be combined. 241 If the host has multiple addresses from different global scope 242 prefixes then system administration MAY specify which addresses are 243 combined to form routing tables. The resulting functionality 244 resembles the VRF functionality found in some modern routers. 246 One purpose behind this algorithm is to move source routing burden 247 from the network to the host. So if a router wants to advertise two 248 (or more) prefixes on the subnet, but to keep their routing separate, 249 it should use different link local and link layer addresses when 250 advertising them. It can then choose the correct VRF to forward a 251 packet depending on which link layer address it received it on. 253 2.6. Dynamic Routing Protocols 255 Hosts don't usually run dynamic routing protocols, but since they 256 sometimes do, this subsection is included for completeness. 258 Dynamic routing protocol instances are usually bound to links or 259 interfaces. With this algorithm network administrators MAY bind 260 routing protocol instances to specific addresses or prefixes on a 261 link and the routing tables associated with them. The routing 262 protocol instance MUST update only the routing table it is associated 263 with. 265 A reasonable default setting is that all addresses that are not link 266 local are associated with the routing protocol instance. Thus, they 267 will share a routing table. 269 If the network administration wants to separate traffic belonging to 270 different upstream operator prefixes, it may wish to run separate 271 routing protocol instances throughout the network for different 272 upstream prefixes. 274 3. Precedences and Labels 276 TBD 278 My original thought was to follow the metrics systems of the original 279 RFC here, since candidate filtering and proper next hop selection 280 were my primary concerns. However, it might be a good idea to just 281 rethink the issue one more time. 283 Perhaps it might be a good idea to associate preferences with 284 individual routes and/or whole routing tables. In that case, the 285 routing table lookup performed in the filtering phase would also 286 yield the precedence of the address in addition to next-hop 287 information. 289 The label abstraction used by the original RFC loosely corresponds to 290 the routing table abstraction in this algorithm. That is, different 291 scopes had different labels in [RFC3484] but in this algorithm 292 different scopes SHOULD have their own routing tables. 294 The rest of this section outlines one approach to sorting addresses 295 by preference. 297 3.1. Route and Table Preferences 299 Each routing table has a default precedence, meaning all routes added 300 to that table will have that precedence in the absence of a specific 301 precedence. 303 This precedence MUST be used to sort the source and destination 304 address pairs according to preference. In effect, the precedence is 305 for the address pair, not for a single address. 307 When two routes have the same precedence, their prefix lengths MUST 308 be compared and the longer prefix MUST be considered more preferable. 310 The algorithm normally performs both source and destination address 311 selection simultaneously and efficiently. 313 In order to perform source address selection, only one destination 314 address SHOULD be presented to the algorithm, which will then look 315 for the address in all tables and sort the source addresses where it 316 was found according to the precedences. 318 In order to perform destination address selection, only one source 319 address SHOULD be presented to the algorithm along with the set of 320 destination addresses. The algorithm will then look for all the 321 given destination addresses in the table associated with the source 322 address and sort the results according to the precedences. 324 3.1.1. Local and Link Local Scope Routing Tables 326 The default precedence for all local and link local scope route 327 entries SHOULD be 50. 329 3.1.2. Global Scope Routing Tables 331 The default precedence for all global scope route entries SHOULD be 332 40. 334 System or network administrators or operating systems MAY alter this 335 default precedence to account for things like link speeds. Such 336 environmental precedence modifiers SHOULD NOT alter the precedence by 337 more than +-4. 339 The system MAY automatically add depreference routes to global scope 340 routing tables. These routes will cover address space reserved for 341 transition techniques, such as 2002::/16 (FIXME: add xrefs) and 342 2001::/32. They SHOULD have the same next-hop information as the 343 default route in the same table, but their precedence SHOULD be 15. 345 The system MAY automatically add blackhole routes to global scope 346 routing tables for illegal address combinations. An example of such 347 an illegal combination is IPv6 prefix 2002:a00::/24, which 348 corresponds to 6to4 addresses generated from IPv4 addresses inside 349 10.0.0.0/8 which can't be used on the Internet. 351 3.1.3. Transition Technique Routing Tables 353 The default precedence for all route entries for source addresses 354 generated through transition techniques SHOULD be 30. 356 The transition table SHOULD NOT of course have a depreference route 357 for its own address space. Instead, the precedence of the route for 358 its own address space SHOULD be 35. 360 Individual transition techniques or the system administrator MAY 361 specify different default precedences to establish relative 362 preferences between transition techniques or the proxies/servers 363 associated with them. 365 3.1.4. IPv4 Compatible Routing Tables 367 The default precedence for all IPv4 compatible global scope route 368 entries SHOULD be 20. 370 3.1.5. Reachability Information 372 If the next-hop information associated with a route in any table has 373 been found unreachable or the interface link is down the precedence 374 of that route MAY be temporarily dropped to zero until it works 375 again. 377 4. RFC3484 Rule Comparison 379 The algorithm defined by [RFC3484] uses a set of rules to perform its 380 function. Those rules are compared to this algorithm in this 381 section. 383 FIXME: write this section 385 5. RFC5220 Concerns 387 [RFC5220] presents several problems and issues with the original 388 default address selection algorithm. The following subsections 389 address these issues. 391 5.1. Multiple Routers on a Single Interface 393 This problem was one of the starting points for the development of 394 this algorithm. This algorithm solves the problem by having separate 395 routing tables for addresses learned from different routers. 397 5.2. Ingress Filtering Problem 399 This problem was one of the starting points for the development of 400 this algorithm. This algorithm solves the problem by having separate 401 routing tables for different addresses. 403 5.3. Half-Closed Network Problem 405 This problem was one of the starting points for the development of 406 this algorithm. This algorithm solves the problem by having separate 407 routing tables for different addresses. 409 System or network administration MUST specify allowed or disallowed 410 connections by modifying the routing tables. 412 5.4. Combined Use of Global and ULA 414 This algorithm solves the problem by having separate routing tables 415 for different addresses. Scope of address usage is controlled by the 416 routing tables. 418 Implementations MAY recognize ULA addresses and other site local 419 addresses as scopes of their own, and treat them properly when 420 autogenerating the routing tables. 422 System or network administration MUST specify allowed or disallowed 423 address pair selection by modifying the routing tables. 425 5.5. Site Renumbering 427 When the autoconfiguration client discovers that a prefix or address 428 has been deprecated, it SHOULD drop the route precedences for all the 429 routes associated with the deprecated resource to zero. 431 When such deprecated routing information finally times out and is no 432 longer in use, the routing table associated with it MAY be removed 433 entirely. 435 5.6. Multicast Source Address Selection 437 TBD 439 5.7. Temporary Address Selection 441 Conceivably temporary addresses could be associated with routing 442 tables of their own, instead of sharing routing tables with the 443 addresses used to generate the temporary addresses. 445 The precedences for the table for a temporary address would be lower 446 than that of a similar but more permanent address. Clients wishing 447 to make use of the temporary address would add appropriate 448 constraints to their address selection. 450 Alternatively, if the system or network administration wishes that 451 the host use a temporary address with some certain destination 452 network, a route to that network could be added to the routing table 453 for the temporary address with a higher than normal precedence. 455 5.8. IPv4 or IPv6 Prioritization 457 This is a configuration issue with the routing tables. 459 Connection pooling, as specified in Section 7.3, could mitigate this 460 problem. 462 5.9. ULA and IPv4 Dual-Stack Environment 464 This special case is easily handled by omitting the default route for 465 the routing table for ULA addresses. 467 5.10. ULA or Global Prioritization 469 Already covered in Section 5.4. 471 6. RFC5221 Requirements 473 [RFC5221] defines a set of requirements for the address selection 474 algorithm. The subsection headings used in that document have been 475 copied here and an explanation of how this algorithm deals with each 476 issue is given. 478 6.1. Effectiveness 480 The effectiveness of the proposed solution to solve problems 481 presented in [RFC5220] is covered by Section 5. 483 6.2. Timing 485 This algorithm relies on other methods and protocols to submit 486 address selection configuration and information and to place it in 487 the routing table. 489 Once the routing table is updated, the address selection algorithm 490 will start making decisions based on the new information. 492 6.3. Dynamic Behavior Update 494 From the point of view of this algorithm, this problem is a feature 495 of autoconfiguration methods. If the autoconfiguration methods 496 rewrite routing tables, the address selection algorithm will always 497 use the updated information when it's invoked. 499 6.4. Node-Specific Behavior 501 From the point of view of this algorithm, this problem is a feature 502 of autoconfiguration methods. This algorithm will happily make 503 address selection decisions according to any input it is given. 505 6.5. Application-Specific Behavior 507 Additional filter constraints from Section 2.4 can be used to 508 influence address selection per application. 510 6.6. Multiple Interface 512 This algorithm doesn't differenciate between cases where a host has 513 multiple interfaces and where it has multiple prefixes on a single 514 interface. If it solves a problem satisfactorily for one case, it 515 solves it identically for the other case as well. 517 6.7. Central Control 519 This algorithm doesn't specify new methods for central control. It 520 does, however, work well with other protocols that provide methods of 521 central control, such as routing protocols. 523 6.8. Next-Hop Selection 525 The next-hop and interface used is a side product of the source 526 address specific routing table lookup, which is performed in the 527 filtering stage. 529 A very pleasing feature of this algorithm is that there can be 530 multiple routers advertising different prefixes on the same subnet, 531 and this algorithm will still select proper address pairs and next- 532 hops to satisfy any SAVI requirements. 534 6.9. Compatibility with RFC 3493 536 TBD 538 On first impression, this algorithm shouldn't have any impact on the 539 Socket API. Then again, routing table index could be referenced as 540 part of some process. 542 Solaris, for example, creates new alias-interfaces for each new 543 address assigned to a physical interface. So if_index could also be 544 used to uniquely identify a source address specific routing table on 545 that platform. Other operating systems do not work the same way. 547 6.10. Compatibility and Interoperability with RFC 3484 549 When a host implementing this address selection algorithm and a host 550 implementing the [RFC3484] algorithm interact, this algorithm will 551 become constrained by the choices made by the peer. 553 6.11. Security 555 Security issues raised in [RFC5221] are covered by Section 10.2. 557 7. Implementation Issues and Other Concerns 559 Some popular operating systems already implement all the features 560 required to implement this algorithm. In such cases all that is 561 required is to integrate the features together. 563 The trickiest feature required by this algorithm is probably support 564 for multiple routing tables. This may also create backward 565 compatibility issues in some implementations. More discussion may be 566 required here. 568 7.1. Low Memory and Power Concerns 570 The biggest worry is that creating lots of routing tables will waste 571 memory and power. However, when compared to the old way (see 572 Appendix A), memory consumption doesn't explode. Every route that 573 was present in the monolithic routing table will usually be present 574 in only one source address specific routing table. 576 CGAs (ADD XREF) MAY reuse the same routing table. 578 7.2. Differing Larger Scopes 580 The default route for global scope addresses is 0::0/0, but this 581 route will also cover addresses of potentially incompatible scopes. 582 For example, the basic algorithm would accept a link local 583 destination address with a global scope source address. 585 One way to prevent this would be to add blackhole routes into the 586 routing tables of global scope addresses for address space belonging 587 to incompatible scopes. The filter algorithm SHOULD treat a 588 blackhole route as an indication that no valid route was found for 589 addresses matching the blackhole in that table. 591 7.3. Connection Pooling 593 When trying to establish a new connection, the stack MAY send open 594 packets to all source/destination/nexthop combinations that pass the 595 filter stage at a pace of three per second until it receives a 596 response. 598 When the connection is established the addresses are fixed (for non- 599 multipathing protocols, such as TCP). 601 If the peer also responds to the other connection attempts after the 602 first connection is established, those connections MAY either be 603 reset immediately, or the stack MAY pool them for a short while in an 604 incomplete handshake state, in case some application tries to open an 605 identical socket. 607 This would benefit applications such as web browsers, mail transfer 608 agents and database clients, which routinely create more than one 609 connection between the same two hosts and the same destination port. 611 It would also benefit dual stacked or multi-homed hosts where some of 612 the addresses or networks are misconfigured and don't work. 614 7.4. Using Just One Table with Tags 616 It is possible to implement this algorithm with just one routing 617 table, if tags or bitfields are used to identify which routing table 618 each route really belongs to. 620 However, since a less specific route in one table can have higher 621 precedence than a more specific route in another table, care must be 622 taken in the implementation. 624 It is also possible to implement this algorithm without interfering 625 with the actual routing table at all, by just mirroring all the 626 routing table information and changes in a policy table used by this 627 algorithm only. 629 8. Acknowledgements 631 This document was written using the template derived from an initial 632 version written by Pekka Savola and contributed by him to the xml2rfc 633 project. 635 Thanks to the following people for giving feedback during the writing 636 of this document: Jari Arkko, Jan Melen, Arifumi Matsumoto, James 637 Morse, . 639 9. IANA Considerations 641 This document has no IANA Actions. 643 10. Security Considerations 645 10.1. RFC5220 Considerations 647 Section 4 of [RFC5220] raises a concern that a malicious attacker can 648 gather information about addresses connected to the target host by 649 triggering the address selection algorithm on the target host by 650 various methods and listening to what candidates it produces. 652 This algorithm doesn't completely remove that possibility, but due to 653 the filtering stage, the attacker can only gain information on 654 addresses routable to the address used by the attacker. 656 10.2. RFC5221 Requirements 658 Section 3 of [RFC5221] lists two security concerns which are dealt 659 with in subsections below. 661 10.2.1. List of threats introduced by new address-selection mechanism 663 This specification relies on existing autoconfiguration methods and 664 routing protocols to distribute address selection hints. Each of 665 those SHOULD have their own methods to combat leakage, hijacking and 666 denial of service. 668 10.2.2. List of recommendations in which security mechanism should be 669 applied 671 This specification relies on existing autoconfiguration methods and 672 routing protocols to distribute address selection hints. Each of 673 those SHOULD have their own methods to combat leakage, hijacking and 674 denial of service. 676 11. References 678 11.1. Normative References 680 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 681 Requirement Levels", BCP 14, RFC 2119, March 1997. 683 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 684 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 685 Zhang, L., and V. Paxson, "Stream Control Transmission 686 Protocol", RFC 2960, October 2000. 688 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 689 Static Route Option for Dynamic Host Configuration 690 Protocol (DHCP) version 4", RFC 3442, December 2002. 692 [RFC3484] Draves, R., "Default Address Selection for Internet 693 Protocol version 6 (IPv6)", RFC 3484, February 2003. 695 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 696 More-Specific Routes", RFC 4191, November 2005. 698 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 699 "Problem Statement for Default Address Selection in Multi- 700 Prefix Environments: Operational Issues of RFC 3484 701 Default Rules", RFC 5220, July 2008. 703 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 704 "Requirements for Address Selection Mechanisms", RFC 5221, 705 July 2008. 707 11.2. Informative References 709 [I-D.blanchet-mif-problem-statement] 710 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 711 Statement", draft-blanchet-mif-problem-statement-01 (work 712 in progress), June 2009. 714 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 715 Socket API for Source Address Selection", RFC 5014, 716 September 2007. 718 Appendix A. Routing Table Example 720 This section demonstrates how this algorithm affects the routing 721 table of a multi-homed host. Appendix A.1 shows the routing table 722 using only methods without this algorithm. Appendix A.2 shows the 723 routing tables produced on the same host if this algorithm is 724 applied. 726 A.1. Before 728 This routing table was initially copied from a system running Linux 729 2.6.25. The addresses were then greatly simplified to make the table 730 fit better on the page. 732 +--------------------------------+----------+--------+--------+ 733 | Network | Next-Hop | Link | Metric | 734 +--------------------------------+----------+--------+--------+ 735 | 2001::/32 | :: | teredo | 256 | 736 | 2001:db8:1::/64 | :: | eth0 | 256 | 737 | 2001:db8:2::/64 | :: | eth1 | 256 | 738 | fe80::/64 | :: | teredo | 256 | 739 | fe80::/64 | :: | eth0 | 256 | 740 | fe80::/64 | :: | eth1 | 256 | 741 | ::/0 | :: | teredo | 1029 | 742 | ::/0 | fe80::13 | eth0 | 1024 | 743 | ::/0 | fe80::ce | eth1 | 1024 | 744 | ::/0 | :: | lo | -1 !U | 745 | ::1/128 | :: | lo | 0 | 746 | 2001:db8:1:0:a00:ff:fedc:a/128 | :: | lo | 0 | 747 | 2001:db8:2:0:200:ff:fec4:b/128 | :: | lo | 0 | 748 | 2001:0:c200:201::3/128 | :: | lo | 0 | 749 | fe80::a00:ff:fedc:a/128 | :: | lo | 0 | 750 | fe80::200:ff:fec4:b/128 | :: | lo | 0 | 751 | fe80::ffff:ffff:ffff/128 | :: | lo | 0 | 752 +--------------------------------+----------+--------+--------+ 754 Table 1: Routing Table w/o Modifications 756 "!U" after metric denotes unreachable or blackhole routes. 758 A.2. After Conversion 760 These tables contain and implement just the basic idea. Thus the 761 combined size of these tables is equal to Table 1. Optional 762 improvements are presented in the next subsection. 764 +---------+----------+------+--------+ 765 | Network | Next-Hop | Link | Metric | 766 +---------+----------+------+--------+ 767 | ::/0 | :: | lo | -1 !U | 768 | ::1/128 | :: | lo | 50 | 769 +---------+----------+------+--------+ 771 Table 2: Routing Table for ::1 773 +------------------------+----------+--------+--------+ 774 | Network | Next-Hop | Link | Metric | 775 +------------------------+----------+--------+--------+ 776 | 2001::/32 | :: | teredo | 35 | 777 | ::/0 | :: | teredo | 30 | 778 | 2001:0:c200:201::3/128 | :: | lo | 50 | 779 +------------------------+----------+--------+--------+ 781 Table 3: Routing Table for 2001:0:c200:201::3%teredo 783 +--------------------------+----------+--------+--------+ 784 | Network | Next-Hop | Link | Metric | 785 +--------------------------+----------+--------+--------+ 786 | fe80::/64 | :: | teredo | 50 | 787 | fe80::ffff:ffff:ffff/128 | :: | lo | 50 | 788 +--------------------------+----------+--------+--------+ 790 Table 4: Routing Table for fe80::ffff:ffff:ffff%teredo 792 +--------------------------------+----------+------+--------+ 793 | Network | Next-Hop | Link | Metric | 794 +--------------------------------+----------+------+--------+ 795 | 2001:db8:1::/64 | :: | eth0 | 40 | 796 | ::/0 | fe80::13 | eth0 | 40 | 797 | 2001:db8:1:0:a00:ff:fedc:a/128 | :: | lo | 50 | 798 +--------------------------------+----------+------+--------+ 800 Table 5: Routing Table for 2001:db8:1:0:a00:ff:fedc:a%eth0 802 +-------------------------+----------+------+--------+ 803 | Network | Next-Hop | Link | Metric | 804 +-------------------------+----------+------+--------+ 805 | fe80::/64 | :: | eth0 | 50 | 806 | fe80::a00:ff:fedc:a/128 | :: | lo | 50 | 807 +-------------------------+----------+------+--------+ 809 Table 6: Routing Table for fe80::a00:ff:fedc:a%eth0 811 +--------------------------------+----------+------+--------+ 812 | Network | Next-Hop | Link | Metric | 813 +--------------------------------+----------+------+--------+ 814 | 2001:db8:2::/64 | :: | eth1 | 40 | 815 | 2001:db8:2:0:200:ff:fec4:b/128 | :: | lo | 50 | 816 | ::/0 | fe80::ce | eth1 | 40 | 817 +--------------------------------+----------+------+--------+ 819 Table 7: Routing Table for 2001:db8:2:0:200:ff:fec4:b%eth1 820 +-------------------------+----------+------+--------+ 821 | Network | Next-Hop | Link | Metric | 822 +-------------------------+----------+------+--------+ 823 | fe80::/64 | :: | eth1 | 50 | 824 | fe80::200:ff:fec4:b/128 | :: | lo | 50 | 825 +-------------------------+----------+------+--------+ 827 Table 8: Routing Table for fe80::200:ff:fec4:b%eth1 829 Author's Address 831 Aleksi Suhonen 832 Tampere University of Technology, Finland 833 Korkeakoulunkatu 1 834 Tampere 33720 835 FI 837 Phone: +358 45 670 2048 838 Email: i-d-2009@ssd.axu.tm