idnits 2.17.1 draft-axu-addr-sel-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 12, 2010) is 5030 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man A. Suhonen 3 Internet-Draft Tampere University of Technology, 4 Updates: 3484 (if approved) Finland 5 Intended status: Experimental July 12, 2010 6 Expires: January 13, 2011 8 Address Selection Using Source Address Specific Routing Tables 9 draft-axu-addr-sel-01 11 Abstract 13 RFC 3484 defines two algorithms for default source and destination 14 address selection, but it has several shortcomings. This document 15 specifies an alternate address selection algorithm that uses routing 16 tables as policy input. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 13, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Filter Algorithm . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.1. Scope Recognition . . . . . . . . . . . . . . . . . . . . 6 68 3. Precedences and Labels . . . . . . . . . . . . . . . . . . . . 6 69 4. Routing Table and Address Properties . . . . . . . . . . . . . 7 70 4.1. Local Scope . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. Link Local Scope . . . . . . . . . . . . . . . . . . . . . 8 72 4.3. Autoconfiguration for Global Scope . . . . . . . . . . . . 8 73 4.4. Limited Scope . . . . . . . . . . . . . . . . . . . . . . 9 74 4.5. Transition Technique Routing Tables . . . . . . . . . . . 9 75 4.6. IPv4 Compatible Routing Tables . . . . . . . . . . . . . . 10 76 4.7. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.8. Reachability Information . . . . . . . . . . . . . . . . . 10 78 4.9. Additional Filter Constraints . . . . . . . . . . . . . . 10 79 4.10. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . 11 80 4.11. Dynamic Routing Protocols . . . . . . . . . . . . . . . . 11 81 5. RFC3484 Rule Comparison . . . . . . . . . . . . . . . . . . . 11 82 5.1. Source Address Selection Rules . . . . . . . . . . . . . . 12 83 5.1.1. Prefer Same Address . . . . . . . . . . . . . . . . . 12 84 5.1.2. Prefer Appropriate Scope . . . . . . . . . . . . . . . 12 85 5.1.3. Avoid Deprecated Addresses . . . . . . . . . . . . . . 12 86 5.1.4. Prefer Home Address . . . . . . . . . . . . . . . . . 12 87 5.1.5. Prefer Outgoing Interface . . . . . . . . . . . . . . 12 88 5.1.6. Prefer Matching Label . . . . . . . . . . . . . . . . 12 89 5.1.7. Prefer Public Addresses . . . . . . . . . . . . . . . 12 90 5.1.8. Use Longest Matching Prefix . . . . . . . . . . . . . 12 91 5.2. Destination Address Selection Rules . . . . . . . . . . . 13 92 5.2.1. Avoid Unusable Destinations . . . . . . . . . . . . . 13 93 5.2.2. Prefer Matching Scope . . . . . . . . . . . . . . . . 13 94 5.2.3. Avoid Deprecated Addresses . . . . . . . . . . . . . . 13 95 5.2.4. Prefer Home Address . . . . . . . . . . . . . . . . . 13 96 5.2.5. Prefer Matching Label . . . . . . . . . . . . . . . . 13 97 5.2.6. Prefer Higher Precedence . . . . . . . . . . . . . . . 13 98 5.2.7. Prefer Native Transport . . . . . . . . . . . . . . . 13 99 5.2.8. Prefer Smaller Scope . . . . . . . . . . . . . . . . . 13 100 5.2.9. Use Longest Matching Prefix . . . . . . . . . . . . . 14 101 5.2.10. Leave Order Unchanged . . . . . . . . . . . . . . . . 14 102 6. RFC5220 Concerns . . . . . . . . . . . . . . . . . . . . . . . 14 103 6.1. Multiple Routers on a Single Interface . . . . . . . . . . 14 104 6.2. Ingress Filtering Problem . . . . . . . . . . . . . . . . 14 105 6.3. Half-Closed Network Problem . . . . . . . . . . . . . . . 14 106 6.4. Combined Use of Global and ULA . . . . . . . . . . . . . . 15 107 6.5. Site Renumbering . . . . . . . . . . . . . . . . . . . . . 15 108 6.6. Multicast Source Address Selection . . . . . . . . . . . . 15 109 6.7. Temporary Address Selection . . . . . . . . . . . . . . . 15 110 6.8. IPv4 or IPv6 Prioritization . . . . . . . . . . . . . . . 16 111 6.9. ULA and IPv4 Dual-Stack Environment . . . . . . . . . . . 16 112 6.10. ULA or Global Prioritization . . . . . . . . . . . . . . . 16 113 7. RFC5221 Requirements . . . . . . . . . . . . . . . . . . . . . 16 114 7.1. Effectiveness . . . . . . . . . . . . . . . . . . . . . . 16 115 7.2. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 16 116 7.3. Dynamic Behavior Update . . . . . . . . . . . . . . . . . 16 117 7.4. Node-Specific Behavior . . . . . . . . . . . . . . . . . . 17 118 7.5. Application-Specific Behavior . . . . . . . . . . . . . . 17 119 7.6. Multiple Interface . . . . . . . . . . . . . . . . . . . . 17 120 7.7. Central Control . . . . . . . . . . . . . . . . . . . . . 17 121 7.8. Next-Hop Selection . . . . . . . . . . . . . . . . . . . . 17 122 7.9. Compatibility with RFC 3493 . . . . . . . . . . . . . . . 17 123 7.10. Compatibility and Interoperability with RFC 3484 . . . . . 18 124 7.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18 125 8. Implementation Issues and Other Concerns . . . . . . . . . . . 18 126 8.1. Low Memory and Power Concerns . . . . . . . . . . . . . . 18 127 8.2. Differing Larger Scopes . . . . . . . . . . . . . . . . . 18 128 8.3. Connection Pooling . . . . . . . . . . . . . . . . . . . . 19 129 8.4. Using Just One Table with Tags . . . . . . . . . . . . . . 19 130 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 131 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 132 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 133 11.1. RFC5220 Considerations . . . . . . . . . . . . . . . . . . 20 134 11.2. RFC5221 Requirements . . . . . . . . . . . . . . . . . . . 20 135 11.2.1. List of threats introduced by new 136 address-selection mechanism . . . . . . . . . . . . . 20 137 11.2.2. List of recommendations in which security 138 mechanism should be applied . . . . . . . . . . . . . 20 139 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 140 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 141 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 142 Appendix A. Routing Table Example . . . . . . . . . . . . . . . . 22 143 A.1. Before . . . . . . . . . . . . . . . . . . . . . . . . . . 22 144 A.2. After Conversion . . . . . . . . . . . . . . . . . . . . . 23 146 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 148 1. Introduction 150 [RFC3484] defines default address selection rules for IPv6 and for 151 IPv4 in relation to IPv6. Several shortcomings in the original 152 address selection rules have been identified in [RFC5220] and its 153 sister document [RFC5221] specifies some requirements for any 154 attempts to update the original address selection algorithm. 156 A further concern comes from multipath protocols. When SCTP 157 [RFC4960], for example, finds that its active source destination 158 address pair is no longer functional, it will need to start searching 159 for a new one. If the multipath protocol doesn't respect address 160 selection policy, it may cause similar security incidents as the old 161 address selection algorithm. A multipath protocol should also 162 consult the algorithm during the session and not only on connection 163 setup. SHIM6 [RFC5533] has similar concerns. 165 The communicating hosts may both have a dozen addresses so it might 166 take unacceptably long to iterate through all combinations before 167 finding a functional pair. On the other hand, many of the invalid 168 combinations could be filtered out using this algorithm, making the 169 process noticeably faster. 171 This algorithm always performs address selection on source- 172 destination address pairs with additional information such as next 173 hop attached. Preferences are also associated with address pairs 174 instead of single addresses. 176 1.1. Terminology 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 An autoconfiguration method is any process or protocol that acquires 183 or creates an IP address for a link. Examples of autoconfiguration 184 methods include RARP [RFC0903], DHCPv4 [RFC2131], ICMPv6 RA 185 [RFC4862], DHCPv6 [RFC3315], Teredo [RFC4380], 6to4 [RFC3056], ISATAP 186 [RFC5214], IPv4 Link Local [RFC3927], PPP [RFC1661] and mDNS. 188 An autoconfiguration agent is a process or daemon that executes an 189 autoconfiguration method on the host. 191 Autoconfiguration methods may also produce other information such as 192 default routes and DNS resolvers. The complete collection of 193 information produced by an autoconfiguration method is called an 194 autoconfiguration blob in this document. 196 2. Filter Algorithm 198 When a host has several addresses, they SHOULD each be associated 199 with their own routing tables. The first stage in selecting source 200 and destination addresses SHOULD be to filter out combinations where 201 the routing table attached with the source (local) address does not 202 have a valid route for the destination (remote) address. If more 203 than one route matches, the most specific route SHOULD be checked for 204 validity. 206 If a destination address can't be found from the routing table for a 207 given source address the system MUST discard that destination address 208 for that source address. 210 If none of the possible destination addresses can be found in the 211 routing table for a source address, then that source address MUST be 212 discarded for those destination addresses. 214 2.1. Scope Recognition 216 One side effect of this filter algorithm is that it doesn't need to 217 know anything about scopes. The routing tables associated with 218 source address candidates will determine what destination addresses 219 they are usable with. This effect is demonstrated below and later in 220 this document. 222 Whenever scopes are mentioned in this draft, they are always 223 mentioned in the context of generating policy input for the 224 algorithm. 226 3. Precedences and Labels 228 Each routing table has a default precedence, meaning all routes added 229 to that table will have that precedence in the absence of a specific 230 precedence. 232 This precedence MUST be used to sort the source and destination 233 address pairs after the filtering stage according to preference. 234 Higher precedence values have higher preference. In effect, the 235 precedence is for the address pair, not for a single address. 237 When two or more address pairs have the same precedence, their 238 destination prefix lengths MUST be compared and the longer prefixes 239 MUST be considered more preferable. 241 When two or more address pairs are still equal, their destination 242 metrics in the routing table MUST be compared and address pairs with 243 better metrics MUST be considered more preferable. 245 If there are still ties, they MAY be broken by some Equal Cost Multi- 246 Path load sharing techniques. Otherwise the algorithm SHOULD output 247 the equal address pairs in the same order as they appeared in its 248 input. 250 The label abstraction used by the original RFC [RFC3484] loosely 251 corresponds to the routing table abstraction in this algorithm. If a 252 database table join is performed on the source address policy table 253 and the destination address policy table as defined by [RFC3484] on 254 the label field and the precedences are added together, the result 255 resembles the policy tables used by this algorithm. 257 This algorithm normally performs both source and destination address 258 selection simultaneously and efficiently. 260 In order to perform source address selection, only one destination 261 address SHOULD be presented to the algorithm, which will then look 262 for the address in all tables and sort the source addresses where it 263 was found according to the precedences. 265 In order to perform destination address selection, only one source 266 address SHOULD be presented to the algorithm along with the set of 267 destination addresses. The algorithm will then look for all the 268 given destination addresses in the table associated with the source 269 address and sort the results according to the precedences. 271 4. Routing Table and Address Properties 273 FIXME: come up with a better section title 275 This section details how source address specific routing tables 276 should be populated to be usable as input data for this algorithm. 278 4.1. Local Scope 280 The routing tables associated with localhost addresses (127.0.0.1 and 281 ::1) SHOULD only have routes to localhost address space. (127.0.0.0/8 282 and ::1/128) In addition, if the host supports node local multicast, 283 a route for the node local scope multicast space MAY also appear in 284 this table. (e.g. ff01::/16, ff11::/16) 286 The routing tables associated with any other addresses assigned to 287 the host SHOULD have a host route for the address itself pointing to 288 the loopback interface. 290 The default precedence for all local scope route entries SHOULD be 291 500. 293 4.2. Link Local Scope 295 The routing table associated with a link local address (e.g. 296 169.254.123.45%le0) SHOULD only have one external unicast route, the 297 link local network for that link (e.g. 169.254.0.0%le0/16). In 298 addition, if the host supports multicast on this link, a route for 299 the link local scope multicast space MAY also appear in this table. 300 (e.g. ff02::/16, ff12::/16) 302 This means that the link local source address is usable only with 303 other link local destination addresses on the same link. 305 The default precedence for all link local scope route entries SHOULD 306 be 500. 308 4.3. Autoconfiguration for Global Scope 310 When global scope addresses are assigned to interfaces dynamically 311 through stateless or stateful autoconfiguration the process MUST 312 yield a default route. That default route SHOULD be placed only into 313 the routing table associated with that address. In addition, if the 314 host and network support multicast, a route for the global scope 315 multicast space SHOULD also appear in this table. (e.g. ff0e::/16, 316 ff1e::/16) 318 This usually means that the next hop of that default route will only 319 be useable with the source address learned from that default router. 321 Some autoconfiguration methods (see [RFC3442] and [RFC4191]) can be 322 used to communicate other routes in addition to the default route. 323 Those routes SHOULD likewise be added only into the routing table 324 associated with the address configured using that same interchange. 326 The default precedence for all global scope route entries SHOULD be 327 400. 329 The system MAY automatically add depreference routes to global scope 330 routing tables. These routes will cover address space reserved for 331 transition techniques, such as 2002::/16 (FIXME: add xrefs) and 332 2001::/32. They SHOULD have the same next-hop information as the 333 default route in the same table, but their precedence SHOULD be 150. 335 The system MAY automatically add blackhole routes to global scope 336 routing tables for illegal address combinations. An example of such 337 an illegal combination is IPv6 prefix 2002:a00::/24, which 338 corresponds to 6to4 addresses generated from IPv4 addresses inside 339 10.0.0.0/8 which can't be used on the Internet. 341 Another example of automatically generated extra routes is fc00::/7 342 for ULA addresses as defined by [RFC4193]. However, the routing 343 table for a ULA should only have a route for the address space it's 344 usable in, and that route should be more specific than the default 345 routes for globally usable source addresses, it should win according 346 to the longest matching prefix rule. 348 4.4. Limited Scope 350 The routing tables for site local addresses SHOULD have routes for 351 site local address space. They SHOULD NOT have the default route, so 352 that they would be automatically eliminated when selecting address 353 pairs for site external communication. 355 However, if the site edge automatically translates limited scope 356 addresses to global addresses, the routing tables associated with 357 limited scope addresses MAY have the default route. 359 This algorithm effectively treats all addresses that aren't 360 associated with a default route as limited scope. The system MAY 361 automatically recognize addresses within the ULA prefix fc00::/7 362 [RFC4193] and treat them as limited scope. 364 The default precedence for limited scope addresses SHOULD be the same 365 as global scope addresses (400), but it SHOULD be simple for the 366 system or network administration to change this setting. 368 In addition, if the host and network support multicast, a route for 369 the site local scope multicast space MAY also appear in this table. 370 (e.g. ff05::/16, ff15::/16) 372 4.5. Transition Technique Routing Tables 374 The default precedence for all route entries for source addresses 375 generated through transition techniques SHOULD be 300. 377 The transition table SHOULD NOT of course have a depreference route 378 for its own address space. Instead, the precedence of the route for 379 its own address space SHOULD be 350. This is to make using the same 380 transition technique source address more preferable than some 381 different transition technique. 383 Individual transition techniques or the system administrator MAY 384 specify different default precedences to establish relative 385 preferences between transition techniques or the proxies/servers 386 associated with them. 388 4.6. IPv4 Compatible Routing Tables 390 The precedence for all IPv4 compatible global scope route entries 391 SHOULD be easily configurable. The default precedence should be 400. 392 If administration wishes to promote the use of IPv6, then the IPv4 393 entries should have a precedence of 200. 395 4.7. Mobility 397 The precedence of route entries in the tables for home addresses and 398 care-of addresses SHOULD be easily configurable. The default 399 precedence for home addresses should be 425 and for care-of addresses 400 it should be 400. If an address is simultaneously a home address and 401 a care-of address, then the precedence should be 450. When the host 402 is ''at one home'', that address will be used, and when the host is 403 visiting ''at the other home'', the home address of that other home 404 will be preferred. 406 4.8. Reachability Information 408 If the next-hop information associated with a route in any table has 409 been found unreachable or the link is down the precedence of the 410 affected routes MAY be temporarily dropped to zero until they work 411 again. 413 4.9. Additional Filter Constraints 415 The address selection algorithm MAY also be given additional filter 416 constraints, such as "use only link#3" or "do not use next-hop 417 10.0.0.1". [RFC5014] specifies an interface that does something very 418 similar. 420 Work is going on in the MIF-wg [I-D.blanchet-mif-problem-statement] 421 to tie address selection and next-hop selection with DNS resolver 422 selection and other similar resources. That is, when using the DNS 423 resolvers received from one autoconfiguration agent, the host SHOULD 424 also always use the default route received from the same 425 autoconfiguration agent. 427 This algorithm supports those efforts by making it possible to 428 restrict a process to one routing table for both address resolution 429 and selection. 431 4.10. Forwarding 433 If a host is configured to forward packets between networks, it 434 SHOULD combine the routing tables for the networks in question into 435 one. Link local scope tables MUST NOT be combined. 437 If the host has multiple addresses from different global scope 438 prefixes then system administration MAY specify which addresses are 439 combined to form routing tables. The resulting functionality 440 resembles the VRF functionality found in some modern routers. 442 One purpose behind this algorithm is to move source routing burden 443 from the network to the host. So if a router wants to advertise two 444 (or more) prefixes on the subnet, but to keep their routing separate, 445 it should use different link local and link layer addresses when 446 advertising them. It can then choose the correct VRF to forward a 447 packet depending on which link layer address it received it on. 449 4.11. Dynamic Routing Protocols 451 Hosts don't usually run dynamic routing protocols, but since they 452 sometimes do, this subsection is included for completeness. Dynamic 453 routing protocols can be used to convey address selection 454 configuration information for this algorithm. 456 Dynamic routing protocol instances are usually bound to links or 457 interfaces. With this algorithm network administrators MAY bind 458 routing protocol instances to specific addresses or prefixes on a 459 link and the routing tables associated with them. The routing 460 protocol instance MUST update only the routing table it is associated 461 with. 463 A reasonable default setting is that all addresses that are not link 464 local are associated with the routing protocol instance. Thus, they 465 will share a routing table. 467 If the network administration wants to separate traffic belonging to 468 different upstream operator prefixes, it may wish to run separate 469 routing protocol instances throughout the network for different 470 upstream prefixes. 472 5. RFC3484 Rule Comparison 474 The algorithm defined by [RFC3484] uses a set of rules to perform its 475 function. Those rules are compared to this algorithm in this 476 section. 478 5.1. Source Address Selection Rules 480 5.1.1. Prefer Same Address 482 The interface address is added with a higher metric to its address 483 specific routing table than any other routes. This ensures that this 484 algorithm conforms to this rule. 486 5.1.2. Prefer Appropriate Scope 488 The routes of different scopes are assigned different precedences. 489 They correspond to the scope values of the original algorithm. 491 5.1.3. Avoid Deprecated Addresses 493 If precedences for deprecated addresses are zeroed, they should 494 automatically be depreferred against any other addresses. 496 5.1.4. Prefer Home Address 498 The higher precedences assigned to home addresses make them always 499 preferable when compared to almost everything else, apart from link 500 local addresses. If a host has two home addresses in different 501 networks, the rules presented will make it prefer the correct address 502 depending on the current location of the mobile node. 504 5.1.5. Prefer Outgoing Interface 506 The metric for the route on the table for the address on the outgoing 507 interface should be better than on other interfaces, so all else 508 being equal, it should break the tie to ensure that this rule is met. 510 5.1.6. Prefer Matching Label 512 This algorithm doesn't have labels at all. However, automatically 513 added depreference routes will take care of this rule. 515 5.1.7. Prefer Public Addresses 517 The section on temporary address selection (Section 6.7) already 518 deals with this rule. 520 5.1.8. Use Longest Matching Prefix 522 This is a debated rule so reproducing it is also questionable. 524 5.2. Destination Address Selection Rules 526 5.2.1. Avoid Unusable Destinations 528 This algorithm conforms to this rule by design. 530 5.2.2. Prefer Matching Scope 532 The routes of different scopes are assigned different precedences. 533 The routes of matching scopes are assigned higher precedences than 534 routes of differing scopes. 536 5.2.3. Avoid Deprecated Addresses 538 If precedences for deprecated addresses are zeroed, they should 539 automatically be depreferred against any other addresses. 541 5.2.4. Prefer Home Address 543 The higher precedences assigned to home addresses make them always 544 preferable when compared to almost everything else, apart from link 545 local addresses. If a host has two home addresses in different 546 networks, the rules presented will make it prefer the correct address 547 depending on the current 549 5.2.5. Prefer Matching Label 551 This algorithm doesn't have labels at all. However, automatically 552 added depreference routes will take care of this rule. 554 5.2.6. Prefer Higher Precedence 556 This algorithm primarily compares precedence values only. All the 557 rules above are encoded as precedence values into the routing tables. 559 5.2.7. Prefer Native Transport 561 This rule essentially is a special case of the matching scope and 562 matching label rules. The special routing table generation rules for 563 transition mechanisms make sure that this algorithm behaves the same 564 way as the original algorithm. 566 5.2.8. Prefer Smaller Scope 568 The routes of different scopes are assigned different precedences. 569 They correspond to the scope values of the original algorithm. 571 5.2.9. Use Longest Matching Prefix 573 This is a debated rule so reproducing it is also questionable. 575 5.2.10. Leave Order Unchanged 577 This new algorithm conforms to this rule. 579 6. RFC5220 Concerns 581 [RFC5220] presents several problems and issues with the original 582 default address selection algorithm. The following subsections 583 address these issues. 585 6.1. Multiple Routers on a Single Interface 587 This problem was one of the starting points for the development of 588 this algorithm. This algorithm solves the problem by having separate 589 routing tables for addresses learned from different routers. 591 6.2. Ingress Filtering Problem 593 This algorithm will always choose the correct link and next-hop 594 address for each source address. However, if several source 595 addresses share the same next-hop on the same link, then there's 596 nothing the algorithm can do. The problem has to be fixed inside the 597 router announcing the prefixes. 599 6.3. Half-Closed Network Problem 601 This problem was one of the starting points for the development of 602 this algorithm. This algorithm solves the problem by having separate 603 routing tables for different addresses. 605 The default assumption is that the auto-configuration method supplies 606 a default route for all globally usable addresses. The routing 607 tables of source addresses usable only within a closed network SHOULD 608 NOT have a default route. They SHOULD only have routes to the 609 networks they are usable within. 611 System or network administration MUST specify allowed or disallowed 612 connections by modifying the auto-configuration input or the routing 613 tables. 615 6.4. Combined Use of Global and ULA 617 This algorithm solves the problem by having separate routing tables 618 for different addresses. Scope of address usage is controlled by the 619 routing tables. 621 Implementations MAY recognize ULA addresses and other limited scope 622 addresses as scopes of their own, and treat them properly when 623 autogenerating the routing tables. 625 System or network administration MUST specify allowed or disallowed 626 address pair selection by modifying the auto-configuration input or 627 the routing tables. 629 6.5. Site Renumbering 631 When the autoconfiguration client discovers that a prefix or address 632 has been deprecated, it SHOULD drop the route precedences for all the 633 routes associated with the deprecated resource to zero. 635 When such deprecated routing information finally times out and is no 636 longer in use, the routing table associated with it MAY be removed 637 entirely. 639 6.6. Multicast Source Address Selection 641 Multicast address selection works the same way as unicast address 642 selection. The source address candidate routing tables SHOULD have 643 only the appropriate multicast scope routes. 645 6.7. Temporary Address Selection 647 A temporary addresses MAY be associated with routing tables of its 648 own, instead of sharing a routing table with the address used to 649 generate the temporary address. 651 The precedences for the table for a temporary address would be lower 652 than that of a similar but permanent address. Clients wishing to 653 make use of the temporary address would add appropriate constraints 654 to their address selection. 656 Alternatively, if the system or network administration wishes that 657 the host use a temporary address with some certain destination 658 network, a route to that network could be added to the routing table 659 for the temporary address with a higher than normal precedence. 661 6.8. IPv4 or IPv6 Prioritization 663 This is a configuration issue with the routing tables. The algorithm 664 itself doesn't dictate policy for sites. 666 6.9. ULA and IPv4 Dual-Stack Environment 668 This special case is easily handled by omitting the default route 669 from the routing table for ULA addresses. This would result in site- 670 external destination IPv6 addresses not having any usable source 671 addresses and thus they would never be considered by this algorithm. 673 6.10. ULA or Global Prioritization 675 Already covered in Section 6.4. 677 7. RFC5221 Requirements 679 [RFC5221] defines a set of requirements for the address selection 680 algorithm. The subsection headings used in that document have been 681 copied here and an explanation of how this algorithm deals with each 682 issue is given. 684 7.1. Effectiveness 686 The effectiveness of the proposed solution to solve problems 687 presented in [RFC5220] is covered by Section 6. 689 7.2. Timing 691 This algorithm relies on other methods and protocols to submit 692 address selection configuration and information and to place it in 693 the routing table. These other methods include auto-configuration 694 and routing protocols. 696 Once the routing table is updated, the address selection algorithm 697 will start making decisions based on the new information. 699 7.3. Dynamic Behavior Update 701 From the point of view of this algorithm, this problem is a feature 702 of auto-configuration methods. If the autoconfiguration methods 703 rewrite routing tables, the address selection algorithm will always 704 use the updated information when it's invoked. 706 7.4. Node-Specific Behavior 708 From the point of view of this algorithm, this problem is a feature 709 of autoconfiguration methods. This algorithm will happily make 710 address selection decisions according to any input it is given. 712 7.5. Application-Specific Behavior 714 Additional filter constraints from Section 4.9 can be used to 715 influence address selection per application. 717 7.6. Multiple Interface 719 This algorithm doesn't differenciate between cases where a host has 720 multiple interfaces and where it has multiple prefixes on a single 721 interface. If it solves a problem satisfactorily for one case, it 722 solves it identically for the other case as well. 724 7.7. Central Control 726 This algorithm doesn't specify new methods for central control. It 727 does, however, work well with other protocols that provide methods of 728 central control, such as routing protocols. 730 7.8. Next-Hop Selection 732 The next-hop and interface used is a side product of the source 733 address specific routing table lookup, which is performed in the 734 filtering stage. 736 A very pleasing feature of this algorithm is that there can be 737 multiple routers advertising different prefixes on the same subnet, 738 and this algorithm will still select proper address pairs and next- 739 hops to satisfy any SAVI requirements. 741 7.9. Compatibility with RFC 3493 743 FIXME TBD 745 On first impression, this algorithm shouldn't have any impact on the 746 Socket API. Then again, routing table index could be referenced as 747 part of some process. 749 Solaris, for example, creates new alias-interfaces for each new 750 address assigned to a physical interface. So if_index could also be 751 used to uniquely identify a source address specific routing table on 752 that platform. Other operating systems do not work the same way. 754 7.10. Compatibility and Interoperability with RFC 3484 756 When a host implementing this address selection algorithm and a host 757 implementing the [RFC3484] algorithm interact, this algorithm will 758 become constrained by the choices made by the peer. 760 One key difference between this algorithm and the [RFC3484] algorithm 761 is that this algorithm considers all valid source address candidates, 762 where as the original algorithm chooses only one source address per 763 every destination address. This difference can be easily overcome by 764 an extra filter rule, that accepts only the highest precedence 765 source-destination address pair for every given destination address. 767 7.11. Security 769 Security issues raised in [RFC5221] are covered by Section 11.2. 771 8. Implementation Issues and Other Concerns 773 Some popular operating systems already implement all the features 774 required to implement this algorithm. In such cases all that is 775 required is to integrate the features together. 777 The trickiest feature required by this algorithm is probably support 778 for multiple routing tables. This may also create backward 779 compatibility issues in some implementations. More discussion may be 780 required here. 782 8.1. Low Memory and Power Concerns 784 The biggest worry is that creating lots of routing tables will waste 785 memory and power. However, when compared to the old way (see 786 Appendix A), memory consumption doesn't explode. Every route that 787 was present in the monolithic routing table will usually be present 788 in only one source address specific routing table. 790 CGAs (ADD XREF) MAY reuse the same routing table. 792 8.2. Differing Larger Scopes 794 The default route for global scope addresses is 0::0/0, but this 795 route will also cover addresses of potentially incompatible scopes. 796 For example, the basic algorithm would accept a link local 797 destination address with a global scope source address. 799 One way to prevent this would be to add blackhole routes into the 800 routing tables of global scope addresses for address space belonging 801 to incompatible scopes. The filter algorithm SHOULD treat a 802 blackhole route as an indication that no valid route was found for 803 addresses matching the blackhole in that table. 805 8.3. Connection Pooling 807 When trying to establish a new connection, the stack MAY send open 808 packets to all source/destination/nexthop combinations that pass the 809 filter stage at a pace of three per second until it receives a 810 response. 812 When the connection is established the addresses are fixed (for non- 813 multipathing protocols, such as TCP). 815 If the peer also responds to the other connection attempts after the 816 first connection is established, those connections MAY either be 817 reset immediately, or the stack MAY pool them for a short while in an 818 incomplete handshake state, in case some application tries to open an 819 identical socket. 821 This would benefit applications such as web browsers, mail transfer 822 agents and database clients, which routinely create more than one 823 connection between the same two hosts and the same destination port. 825 It would also benefit dual stacked or multi-homed hosts where some of 826 the addresses or networks are misconfigured and don't work. 828 8.4. Using Just One Table with Tags 830 It is possible to implement this algorithm with just one routing 831 table, if tags or bitfields are used to identify which routing table 832 each route really belongs to. 834 However, since a less specific route in one table can have higher 835 precedence than a more specific route in another table, care must be 836 taken in the implementation. 838 It is also possible to implement this algorithm without interfering 839 with the actual routing table at all, by just mirroring all the 840 routing table information and changes in a policy table used by this 841 algorithm only. 843 9. Acknowledgements 845 This document was written using the template derived from an initial 846 version written by Pekka Savola and contributed by him to the xml2rfc 847 project. 849 Thanks to the following people for giving feedback during the writing 850 of this document: Jari Arkko, Jan Melen, Arifumi Matsumoto, James 851 Morse, Tim Chown, Brian E Carpenter, . 853 10. IANA Considerations 855 This document has no IANA Actions. 857 11. Security Considerations 859 11.1. RFC5220 Considerations 861 Section 4 of [RFC5220] raises a concern that a malicious attacker can 862 gather information about addresses connected to the target host by 863 triggering the address selection algorithm on the target host by 864 various methods and listening to what candidates it produces. 866 This algorithm doesn't completely remove that possibility, but due to 867 the filtering stage, the attacker can only gain information on 868 addresses routable to the address used by the attacker. 870 11.2. RFC5221 Requirements 872 Section 3 of [RFC5221] lists two security concerns which are dealt 873 with in subsections below. 875 11.2.1. List of threats introduced by new address-selection mechanism 877 This specification relies on existing autoconfiguration methods and 878 routing protocols to distribute address selection hints. Each of 879 those SHOULD have their own methods to combat leakage, hijacking and 880 denial of service. 882 11.2.2. List of recommendations in which security mechanism should be 883 applied 885 This specification relies on existing autoconfiguration methods and 886 routing protocols to distribute address selection hints. Each of 887 those SHOULD have their own methods to ensure integrity, 888 authentication and authorization. 890 12. References 891 12.1. Normative References 893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 894 Requirement Levels", BCP 14, RFC 2119, March 1997. 896 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 897 Static Route Option for Dynamic Host Configuration 898 Protocol (DHCP) version 4", RFC 3442, December 2002. 900 [RFC3484] Draves, R., "Default Address Selection for Internet 901 Protocol version 6 (IPv6)", RFC 3484, February 2003. 903 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 904 More-Specific Routes", RFC 4191, November 2005. 906 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 907 RFC 4960, September 2007. 909 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 910 "Problem Statement for Default Address Selection in Multi- 911 Prefix Environments: Operational Issues of RFC 3484 912 Default Rules", RFC 5220, July 2008. 914 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 915 "Requirements for Address Selection Mechanisms", RFC 5221, 916 July 2008. 918 12.2. Informative References 920 [I-D.blanchet-mif-problem-statement] 921 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 922 Statement", draft-blanchet-mif-problem-statement-01 (work 923 in progress), June 2009. 925 [RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, 926 "Reverse Address Resolution Protocol", STD 38, RFC 903, 927 June 1984. 929 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 930 RFC 1661, July 1994. 932 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 933 RFC 2131, March 1997. 935 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 936 via IPv4 Clouds", RFC 3056, February 2001. 938 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 939 and M. Carney, "Dynamic Host Configuration Protocol for 940 IPv6 (DHCPv6)", RFC 3315, July 2003. 942 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 943 Configuration of IPv4 Link-Local Addresses", RFC 3927, 944 May 2005. 946 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 947 Addresses", RFC 4193, October 2005. 949 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 950 Network Address Translations (NATs)", RFC 4380, 951 February 2006. 953 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 954 Address Autoconfiguration", RFC 4862, September 2007. 956 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 957 Socket API for Source Address Selection", RFC 5014, 958 September 2007. 960 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 961 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 962 March 2008. 964 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 965 Shim Protocol for IPv6", RFC 5533, June 2009. 967 Appendix A. Routing Table Example 969 This section demonstrates how this algorithm affects the routing 970 table of a multi-homed host. Appendix A.1 shows the routing table 971 using only methods without this algorithm. Appendix A.2 shows the 972 routing tables produced on the same host if this algorithm is 973 applied. 975 A.1. Before 977 This routing table was initially copied from a system running Linux 978 2.6.25. The addresses were then greatly simplified to make the table 979 fit better on the page. 981 +--------------------------------+----------+--------+--------+ 982 | Network | Next-Hop | Link | Metric | 983 +--------------------------------+----------+--------+--------+ 984 | 2001::/32 | :: | teredo | 256 | 985 | 2001:db8:1::/64 | :: | eth0 | 256 | 986 | 2001:db8:2::/64 | :: | eth1 | 256 | 987 | fe80::/64 | :: | teredo | 256 | 988 | fe80::/64 | :: | eth0 | 256 | 989 | fe80::/64 | :: | eth1 | 256 | 990 | ::/0 | :: | teredo | 1029 | 991 | ::/0 | fe80::13 | eth0 | 1024 | 992 | ::/0 | fe80::ce | eth1 | 1024 | 993 | ::/0 | :: | lo | -1 !U | 994 | ::1/128 | :: | lo | 0 | 995 | 2001:db8:1:0:a00:ff:fedc:a/128 | :: | lo | 0 | 996 | 2001:db8:2:0:200:ff:fec4:b/128 | :: | lo | 0 | 997 | 2001:0:c200:201::3/128 | :: | lo | 0 | 998 | fe80::a00:ff:fedc:a/128 | :: | lo | 0 | 999 | fe80::200:ff:fec4:b/128 | :: | lo | 0 | 1000 | fe80::ffff:ffff:ffff/128 | :: | lo | 0 | 1001 +--------------------------------+----------+--------+--------+ 1003 Table 1: Routing Table w/o Modifications 1005 "!U" after metric denotes unreachable or blackhole routes. 1007 A.2. After Conversion 1009 These tables contain and implement just the basic idea. Thus the 1010 combined size of these tables is equal to Table 1. Optional 1011 improvements are presented in the next subsection. 1013 +---------+----------+------+-------+ 1014 | Network | Next-Hop | Link | Prec | 1015 +---------+----------+------+-------+ 1016 | ::/0 | :: | lo | -1 !U | 1017 | ::1/128 | :: | lo | 500 | 1018 +---------+----------+------+-------+ 1020 Table 2: Routing Table for ::1 1022 +------------------------+----------+--------+------+ 1023 | Network | Next-Hop | Link | Prec | 1024 +------------------------+----------+--------+------+ 1025 | 2001::/32 | :: | teredo | 350 | 1026 | ::/0 | :: | teredo | 300 | 1027 | 2001:0:c200:201::3/128 | :: | lo | 500 | 1028 +------------------------+----------+--------+------+ 1030 Table 3: Routing Table for 2001:0:c200:201::3%teredo 1032 +--------------------------+----------+--------+------+ 1033 | Network | Next-Hop | Link | Prec | 1034 +--------------------------+----------+--------+------+ 1035 | fe80::/64 | :: | teredo | 500 | 1036 | fe80::ffff:ffff:ffff/128 | :: | lo | 500 | 1037 +--------------------------+----------+--------+------+ 1039 Table 4: Routing Table for fe80::ffff:ffff:ffff%teredo 1041 +--------------------------------+----------+------+------+ 1042 | Network | Next-Hop | Link | Prec | 1043 +--------------------------------+----------+------+------+ 1044 | 2001:db8:1::/64 | :: | eth0 | 400 | 1045 | ::/0 | fe80::13 | eth0 | 400 | 1046 | 2001:db8:1:0:a00:ff:fedc:a/128 | :: | lo | 500 | 1047 +--------------------------------+----------+------+------+ 1049 Table 5: Routing Table for 2001:db8:1:0:a00:ff:fedc:a%eth0 1051 +-------------------------+----------+------+------+ 1052 | Network | Next-Hop | Link | Prec | 1053 +-------------------------+----------+------+------+ 1054 | fe80::/64 | :: | eth0 | 500 | 1055 | fe80::a00:ff:fedc:a/128 | :: | lo | 500 | 1056 +-------------------------+----------+------+------+ 1058 Table 6: Routing Table for fe80::a00:ff:fedc:a%eth0 1060 +--------------------------------+----------+------+------+ 1061 | Network | Next-Hop | Link | Prec | 1062 +--------------------------------+----------+------+------+ 1063 | 2001:db8:2::/64 | :: | eth1 | 400 | 1064 | 2001:db8:2:0:200:ff:fec4:b/128 | :: | lo | 500 | 1065 | ::/0 | fe80::ce | eth1 | 400 | 1066 +--------------------------------+----------+------+------+ 1068 Table 7: Routing Table for 2001:db8:2:0:200:ff:fec4:b%eth1 1069 +-------------------------+----------+------+------+ 1070 | Network | Next-Hop | Link | Prec | 1071 +-------------------------+----------+------+------+ 1072 | fe80::/64 | :: | eth1 | 500 | 1073 | fe80::200:ff:fec4:b/128 | :: | lo | 500 | 1074 +-------------------------+----------+------+------+ 1076 Table 8: Routing Table for fe80::200:ff:fec4:b%eth1 1078 Author's Address 1080 Aleksi Suhonen 1081 Tampere University of Technology, Finland 1082 Korkeakoulunkatu 1 1083 Tampere 33720 1084 FI 1086 Phone: +358 45 670 2048 1087 Email: i-d-2010@ssd.axu.tm