idnits 2.17.1 draft-ietf-6man-rfc3484-revise-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 317: '...pecified address, MUST NOT be included...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (October 2011) is 4575 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1794' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'I-D.chown-addr-select-considerations' is defined on line 373, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1794 ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 3701 ** Downref: Normative reference to an Informational RFC: RFC 5214 ** Downref: Normative reference to an Informational RFC: RFC 5220 == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-01 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Matsumoto 3 Internet-Draft J. Kato 4 Intended status: Standards Track T. Fujisaki 5 Expires: April 3, 2012 NTT 6 T. Chown 7 University of Southampton 8 October 2011 10 Update to RFC 3484 Default Address Selection for IPv6 11 draft-ietf-6man-rfc3484-revise-05.txt 13 Abstract 15 RFC 3484 describes algorithms for source address selection and for 16 destination address selection. The algorithms specify default 17 behavior for all Internet Protocol version 6 (IPv6) implementations. 18 This document specifies a set of updates that modify the algorithms 19 and fix the known defects. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 3, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Changes related to the default policy table . . . . . . . 3 70 2.1.1. ULA in the policy table . . . . . . . . . . . . . . . 4 71 2.1.2. Teredo in the policy table . . . . . . . . . . . . . . 4 72 2.1.3. 6to4, Teredo, and IPv4 prioritization . . . . . . . . 4 73 2.1.4. Deprecated addresses in the policy table . . . . . . . 5 74 2.1.5. Renewed default policy table . . . . . . . . . . . . . 5 75 2.2. The longest matching rule . . . . . . . . . . . . . . . . 5 76 2.3. Utilize next-hop for source address selection . . . . . . 6 77 2.4. Private IPv4 address scope . . . . . . . . . . . . . . . . 6 78 2.5. Deprecation of site-local unicast address . . . . . . . . 7 79 2.6. Anycast addresses for candidate source addresses . . . . . 7 80 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 82 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 5.1. Normative References . . . . . . . . . . . . . . . . . . . 8 84 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 85 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 86 Appendix B. Past Discussion . . . . . . . . . . . . . . . . . . . 9 87 B.1. The longest match rule . . . . . . . . . . . . . . . . . . 9 88 B.2. NAT64 prefix issue . . . . . . . . . . . . . . . . . . . . 10 89 B.3. ISATAP issue . . . . . . . . . . . . . . . . . . . . . . . 10 90 Appendix C. Revision History . . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 93 1. Introduction 95 The IPv6 addressing architecture [RFC4291] allows multiple unicast 96 addresses to be assigned to interfaces. Because of this IPv6 97 implementations need to handle multiple possible source and 98 destination addresses when initiating communication. RFC 3484 99 [RFC3484] specifies the default algorithms, common across all 100 implementations, for selecting source and destination addresses so 101 that it is easier to predict the address selection behavior. 103 Since RFC 3484 was specified, some issues have been identified with 104 the algorithms specified there. The issues include the longest match 105 algorithm used in Rule 9 of destination address selection breaking 106 DNS round-robin techniques, and prioritization of poor IPv6 107 connectivity using transition mechanisms over native IPv4 108 connectivity. 110 There have also been some significant changes to the IPv6 addressing 111 architecture that require changes in the RFC 3484 policy table. Such 112 changes include the deprecation of site-local unicast addresses 113 [RFC3879] and of IPv4-compatible IPv6 addresses, and the introduction 114 of Unique Local Addresses [RFC4193]. 116 This document specifies a set of updates that modify the algorithms 117 and fix the known defects. 119 2. Specification 121 2.1. Changes related to the default policy table 123 The default policy table is defined in RFC 3484 Section 2.1 as 124 follows: 126 Prefix Precedence Label 127 ::1/128 50 0 128 ::/0 40 1 129 2002::/16 30 2 130 ::/96 20 3 131 ::ffff:0:0/96 10 4 133 The changes that should be included into the default policy table are 134 those rules that are universally useful and do no harm in every 135 reasonable network environment. The changes we should consider for 136 the default policy table are listed in this sub-section. 138 The policy table is defined to be configurable. The changes that are 139 useful locally but not universally can be put into the policy table 140 manually or by using the policy distribution mechanism proposed as a 141 DHCP option [I-D.ietf-6man-addr-select-opt]. 143 2.1.1. ULA in the policy table 145 RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address 146 selection problems related to ULAs [RFC4193]. These problems can be 147 solved by either changing the scope of ULAs to site-local, or by 148 adding an entry for the default policy table that has its own label 149 for ULAs. 151 Centrally assigned ULAs [I-D.ietf-ipv6-ula-central] have been 152 proposed, and are assigned fc00::/8. Using the different labels for 153 fc00::/8 and fd00::/8 makes sense if we assume the same kind of 154 address block is assigned in the same or adjacent network. However, 155 we cannot expect that the type of ULA address block and network 156 adjacency commonly have any relationships. 158 Regarding the scope of ULAs, ULAs have been specified with a global 159 scope because the reachability of ULAs was intended to be restricted 160 by the routing system. Since the ULAs will not be exposed outside of 161 their reachability domain, if a ULA is available as a candidate 162 destination address, it can be expected to be reachable. 164 If we change the scope of ULAs to be smaller than global, we can 165 prioritize ULA to ULA communication over GUA to GUA communication. 166 At the same time, however, finer-grained configuration of ULA address 167 selection will be impossible. For example, even if you want to 168 prioritize communication related to the only /48 ULA prefix used in 169 your site, and do not want to prioritize communication to any other 170 ULA prefix, such a policy cannot be implemented in the policy table. 171 So, this draft proposes the use of the policy table to differentiate 172 ULAs from GUAs. 174 2.1.2. Teredo in the policy table 176 Teredo [RFC4380] is defined and has been assigned 2001::/32. This 177 address block should be assigned its own label in the policy table. 178 Teredo's priority should be less than or equal to 6to4, considering 179 its characteristic of being a transitional tunnel mechanism. 181 2.1.3. 6to4, Teredo, and IPv4 prioritization 183 Regarding the prioritization between IPv4 and these transitional 184 mechanisms, their connectivity is known to usually be worse than 185 IPv4. These mechanisms are said to be the last resort access method 186 to IPv6 resources. 6to4 should have higher precedence than Teredo, 187 given that 6to4 host to 6to4 host communication can be over IPv4 188 (which can result in a more optimal path) and that 6to4 should not 189 used behind a NAT device. 191 2.1.4. Deprecated addresses in the policy table 193 IPv4-compatible IPv6 addresses (::/96) are deprecated [RFC4291]. 194 IPv6 site-local unicast addresses (fec0::/10) are deprecated 195 [RFC3879]. 6bone testing addresses [RFC3701] has also been phased 196 out. 198 These addresses were removed from the current specification. 199 Considering the inappropriate use of these address blocks, especially 200 in outdated implementations and bad effects brought by them, they 201 should be labeled differently from the legitimate address blocks as 202 long as the address block is reserved by IANA. 204 2.1.5. Renewed default policy table 206 After applying these updates, the default policy table will be: 208 Prefix Precedence Label 209 ::1/128 60 0 210 fc00::/7 50 1 211 ::/0 40 2 212 ::ffff:0:0/96 30 3 213 2002::/16 20 4 214 2001::/32 10 5 215 ::/96 1 10 216 fec0::/10 1 11 217 3ffe::/16 1 12 219 2.2. The longest matching rule 221 This issue is related to the longest matching rule, which was found 222 by Dave Thaler. It causes a malfunction of the DNS round robin 223 technique, as described below. It is common for both IPv4 and IPv6. 225 When a destination address DA, DB, and the source address of DA 226 Source(DA) are on the same subnet and Source(DA) == Source(DB), DNS 227 round robin load-balancing cannot function. By considering prefix 228 lengths that are longer than the subnet prefix, this rule establishes 229 preference between addresses that have no substantive differences 230 between them. The rule functions as an arbitrary tie-breaker between 231 the hosts in a round robin, causing a given host to always prefer a 232 given member of the round robin. 234 By limiting the calculation of common prefixes to a maximum length 235 equal to the length of the subnet prefix of the source address, rule 236 9 can continue to favor hosts that are nearby in the network 237 hierarchy without arbitrarily sorting addresses within a given 238 network. This modification could be written as follows: 240 Rule 9: Use longest matching prefix. 242 When DA and DB belong to the same address family (both are IPv6 or 243 both are IPv4): If CommonPrefixLen(DA & Netmask(Source(DA)), 244 Source(DA)) > CommonPrefixLen(DB & Netmask(Source(DB)), Source(DB)), 245 then prefer DA. Similarly, if CommonPrefixLen(DA & 246 Netmask(Source(DA)), Source(DA)) < CommonPrefixLen(DB & 247 Netmask(Source(DB)), Source(DB)), then prefer DB. 249 2.3. Utilize next-hop for source address selection 251 RFC 3484 source address selection rule 5 says that the address that 252 is attached to the outgoing interface should be preferred as the 253 source address. This rule is reasonable considering the prevalence 254 of ingress filtering described in BCP 38 [RFC2827]. This is because 255 an upstream network provider usually assumes it receives packets from 256 their customer that only have the delegated addresses as the source 257 addresses. 259 This rule, however, is not effective in an environment such as that 260 described in RFC 5220 Section 2.1.1, where a host has multiple 261 upstream routers on the same link and has addresses delegated from 262 each upstream router on a single interface. 264 Also, DHCPv6 assigned addresses are not associated like SLAAC 265 assigned addresses to a next-hop gateway, so implementations usually 266 can't apply this heuristic in a DHCPv6 network. 268 So, a new rule 5.1 that utilizes next-hop information for source 269 address selection is inserted just after rule 5. 271 Rule 5.1: Use an address assigned by the selected next-hop. 273 If SA is assigned by the selected next-hop that will be used to send 274 to D and SB is assigned by a different next-hop, then prefer SA. 275 Similarly, if SB is assigned by the next-hop that will be used to 276 send to D and SA is assigned by a different next-hop, then prefer SB. 278 2.4. Private IPv4 address scope 280 When a packet goes through a NAT, its source or destination address 281 can get replaced with another address with a different scope. It 282 follows that the result of the source address selection algorithm may 283 be different when the original address is replaced with the NATed 284 address. 286 The algorithm currently specified in RFC 3484 is based on the 287 assumption that a source address with a small scope cannot reach a 288 destination address with a larger scope. This assumption does not 289 hold if private IPv4 addresses and a NAT are used to reach public 290 IPv4 addresses. 292 Due to this assumption, in the presence of both a NATed private IPv4 293 address and a transitional address (like 6to4 or Teredo), the host 294 will choose the transitional IPv6 address to access dual-stack peers 295 [I-D.denis-v6ops-nat-addrsel]. Choosing transitional IPv6 296 connectivity over native IPv4 connectivity, particularly where the 297 transitional connectivity is unmanaged, is not considered to be 298 generally desirable. 300 This issue can be fixed by changing the address scope of private IPv4 301 addresses to global. 303 2.5. Deprecation of site-local unicast address 305 RFC 3484 contains a few "site-local unicast" and "fec0::" 306 descriptions. It's better to remove examples related to site-local 307 unicast addresses, or change the examples to use ULAs. Possible 308 points to be re-written are listed below. 310 - 2nd paragraph in RFC 3484 Section 3.1 describes the scope 311 comparison mechanism. 312 - RFC 3484 Section 10 contains examples for site-local addresses. 314 2.6. Anycast addresses for candidate source addresses 316 RFC 3484 Section 4 states that anycast addresses, as well as 317 multicast addresses and the unspecified address, MUST NOT be included 318 in a candidate set of source address. Now that RFC 4291 Section 2.6 319 [RFC4291] removed the restrictions on using IPv6 anycast addresses as 320 the source address of an IPv6 packet, this restriction of RFC 3484 321 should also be removed. 323 3. Security Considerations 325 No security risk is found that degrades RFC 3484. 327 4. IANA Considerations 329 Address type number for the policy table may have to be assigned by 330 IANA. 332 5. References 334 5.1. Normative References 336 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 337 April 1995. 339 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 340 E. Lear, "Address Allocation for Private Internets", 341 BCP 5, RFC 1918, February 1996. 343 [RFC3484] Draves, R., "Default Address Selection for Internet 344 Protocol version 6 (IPv6)", RFC 3484, February 2003. 346 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 347 Allocation) Phaseout", RFC 3701, March 2004. 349 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 350 Addresses", RFC 3879, September 2004. 352 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 353 Addresses", RFC 4193, October 2005. 355 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 356 Architecture", RFC 4291, February 2006. 358 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 359 Network Address Translations (NATs)", RFC 4380, 360 February 2006. 362 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 363 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 364 March 2008. 366 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 367 "Problem Statement for Default Address Selection in Multi- 368 Prefix Environments: Operational Issues of RFC 3484 369 Default Rules", RFC 5220, July 2008. 371 5.2. Informative References 373 [I-D.chown-addr-select-considerations] 374 Chown, T., "Considerations for IPv6 Address Selection 375 Policy Changes", draft-chown-addr-select-considerations-03 376 (work in progress), July 2009. 378 [I-D.denis-v6ops-nat-addrsel] 379 Denis-Courmont, R., "Problems with IPv6 source address 380 selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 381 (work in progress), February 2009. 383 [I-D.ietf-6man-addr-select-opt] 384 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 385 "Distributing Address Selection Policy using DHCPv6", 386 draft-ietf-6man-addr-select-opt-01 (work in progress), 387 June 2011. 389 [I-D.ietf-ipv6-ula-central] 390 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 391 Addresses", draft-ietf-ipv6-ula-central-02 (work in 392 progress), June 2007. 394 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 395 Defeating Denial of Service Attacks which employ IP Source 396 Address Spoofing", BCP 38, RFC 2827, May 2000. 398 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 399 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 400 October 2010. 402 Appendix A. Acknowledgements 404 Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- 405 Courmont, Francois-Xavier Le Bail, and the members of 6man's address 406 selection design team for their invaluable contributions to this 407 document. 409 Appendix B. Past Discussion 411 This section summarizes discussions we had before related to address 412 selection mechanisms. 414 B.1. The longest match rule 416 RFC 3484 defines that destination address selection rule 9 should be 417 applied to both IPv4 and IPv6, which spoils the DNS-based load 418 balancing technique that is widely used in the IPv4 Internet today. 420 When two or more destination addresses are acquired from one FQDN, 421 rule 9 states that the longest matching destination and source 422 address pair should be chosen. As in RFC 1794, the DNS-based load 423 balancing technique is achieved by not re-ordering the destination 424 addresses returned from the DNS server. Rule 9 defines a 425 deterministic rule for re-ordering hosts, hence the technique 426 described in RFC 1794 is not available anymore. 428 Regarding this problem, there was discussion in IETF and other places 429 like below. 431 Discussion: The possible changes to RFC 3484 are as follows: 433 1. To delete Rule 9 completely. 434 2. To apply Rule 9 only for IPv6 and not for IPv4. In IPv6, 435 hierarchical address assignment generally used at present, hence 436 the longest matching rule is beneficial in many cases. In IPv4, 437 as stated above, the DNS based load balancing technique is widely 438 used. 439 3. To apply Rule 9 for IPv6 conditionally and not for IPv4. When 440 the length of matching bits of the destination address and the 441 source address is longer than N, rule 9 is applied. Otherwise, 442 the order of the destination addresses do not change. The value 443 of N should be configurable and it should be 32 by default. This 444 is simply because the two sites whose matching bit length is 445 longer than 32 are probably adjacent. 447 Now that IPv6 PI addresses are being introduced by RIRs, hierarchical 448 address assignment is not always maintained anymore. It seems that 449 the longest matching algorithm may not worth the adverse effect of 450 disabling the DNS-based load balance technique. 452 B.2. NAT64 prefix issue 454 The NAT64 WKP has recently been defined[RFC6052]. It depends site by 455 site whether NAT64 should be preferred over IPv4, in other words 456 NAT44, or NAT44 over NAT64. So, the issue of local site policy 457 should be solved by manual policy table changes locally, or by use of 458 the proposed DHCP-based policy distribution mechanism. 460 B.3. ISATAP issue 462 Where a site is using ISATAP [RFC5214], there is generally no way to 463 differentiate an ISATAP address from a native address without 464 interface information. However, a site will assign a prefix for its 465 ISATAP overlay, and can choose to add an entry for that prefix to the 466 policy table if it wishes to change the default preference for that 467 prefix. 469 Appendix C. Revision History 471 05: 472 6bone testing addresses were back in the default policy table. 473 Section 2.6 for allowing anycast source address were added. 475 04: 476 Added comment about ISATAP. 478 03: 479 ULA address selection issue was expanded. 480 6to4, Teredo and IPv4 prioritization issue was elaborated. 481 Deprecated address blocks in policy table section was elaborated. 482 In appendix, NAT64 prefix issue was added. 484 02: 485 Suresh Krishnan's suggestions for better english sentences were 486 incorporated. 487 A new source address selection rule that utilizes the next-hop 488 information is included in Section 2.3. 489 Site local address prefix was corrected. 491 01: 492 Re-structured to contain only the actual changes to RFC 3484. 494 00: 495 Published as a 6man working group item. 497 03: 498 Added acknowledgements. 499 Added longest matching algorithm malfunction regarding local DNS 500 round robin. 501 The proposed changes section was re-structured. 502 The issue of 6to4/Teredo and IPv4 prioritization was included. 503 The issue of deprecated addresses was added. 504 The renewed default policy table was changed accordingly. 506 02: 507 Added the reference to address selection design team's proposal. 509 01: 510 The issue of private IPv4 address scope was added. 511 The issue of ULA address scope was added. 512 Discussion of longest matching rule was expanded. 514 Authors' Addresses 516 Arifumi Matsumoto 517 NTT SI Lab 518 Midori-Cho 3-9-11 519 Musashino-shi, Tokyo 180-8585 520 Japan 522 Phone: +81 422 59 3334 523 Email: arifumi@nttv6.net 525 Jun-ya Kato 526 NTT SI Lab 527 Midori-Cho 3-9-11 528 Musashino-shi, Tokyo 180-8585 529 Japan 531 Phone: +81 422 59 2939 532 Email: kato@syce.net 534 Tomohiro Fujisaki 535 NTT PF Lab 536 Midori-Cho 3-9-11 537 Musashino-shi, Tokyo 180-8585 538 Japan 540 Phone: +81 422 59 7351 541 Email: fujisaki@syce.net 543 Tim Chown 544 University of Southampt on 545 Southampton, Hampshire SO17 1BJ 546 United Kingdom 548 Email: tjc@ecs.soton.ac.uk