idnits 2.17.1 draft-ietf-6man-rfc3484-revise-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, 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 (July 1, 2011) is 4654 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 327, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'I-D.chown-addr-select-considerations' is defined on line 364, 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: 5 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: January 2, 2012 NTT 6 T. Chown 7 University of Southampton 8 July 1, 2011 10 Update to RFC 3484 Default Address Selection for IPv6 11 draft-ietf-6man-rfc3484-revise-04.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 January 2, 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 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 81 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 5.1. Normative References . . . . . . . . . . . . . . . . . . . 8 83 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 84 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 85 Appendix B. Past Discussion . . . . . . . . . . . . . . . . . . . 9 86 B.1. The longest match rule . . . . . . . . . . . . . . . . . . 9 87 B.2. NAT64 prefix issue . . . . . . . . . . . . . . . . . . . . 10 88 B.3. ISATAP issue . . . . . . . . . . . . . . . . . . . . . . . 10 89 Appendix C. Revision History . . . . . . . . . . . . . . . . . . 10 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 The IPv6 addressing architecture [RFC4291] allows multiple unicast 95 addresses to be assigned to interfaces. Because of this IPv6 96 implementations need to handle multiple possible source and 97 destination addresses when initiating communication. RFC 3484 98 [RFC3484] specifies the default algorithms, common across all 99 implementations, for selecting source and destination addresses so 100 that it is easier to predict the address selection behavior. 102 Since RFC 3484 was specified, some issues have been identified with 103 the algorithms specified there. The issues include the longest match 104 algorithm used in Rule 9 of destination address selection breaking 105 DNS round-robin techniques, and prioritization of poor IPv6 106 connectivity using transition mechanisms over native IPv4 107 connectivity. 109 There have also been some significant changes to the IPv6 addressing 110 architecture that require changes in the RFC 3484 policy table. Such 111 changes include the deprecation of site-local unicast addresses 112 [RFC3879] and of IPv4-compatible IPv6 addresses, and the introduction 113 of Unique Local Addresses [RFC4193]. 115 This document specifies a set of updates that modify the algorithms 116 and fix the known defects. 118 2. Specification 120 2.1. Changes related to the default policy table 122 The default policy table is defined in RFC 3484 Section 2.1 as 123 follows: 125 Prefix Precedence Label 126 ::1/128 50 0 127 ::/0 40 1 128 2002::/16 30 2 129 ::/96 20 3 130 ::ffff:0:0/96 10 4 132 The changes that should be included into the default policy table are 133 those rules that are universally useful and do no harm in every 134 reasonable network environment. The changes we should consider for 135 the default policy table are listed in this sub-section. 137 The policy table is defined to be configurable. The changes that are 138 useful locally but not universally can be put into the policy table 139 manually or by using the policy distribution mechanism proposed as a 140 DHCP option [I-D.ietf-6man-addr-select-opt]. 142 2.1.1. ULA in the policy table 144 RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address 145 selection problems related to ULAs [RFC4193]. These problems can be 146 solved by either changing the scope of ULAs to site-local, or by 147 adding an entry for the default policy table that has its own label 148 for ULAs. 150 Centrally assigned ULAs [I-D.ietf-ipv6-ula-central] have been 151 proposed, and are assigned fc00::/8. Using the different labels for 152 fc00::/8 and fd00::/8 makes sense if we assume the same kind of 153 address block is assigned in the same or adjacent network. However, 154 we cannot expect that the type of ULA address block and network 155 adjacency commonly have any relationships. 157 Regarding the scope of ULAs, ULAs have been specified with a global 158 scope because the reachability of ULAs was intended to be restricted 159 by the routing system. Since the ULAs will not be exposed outside of 160 their reachability domain, if a ULA is available as a candidate 161 destination address, it can be expected to be reachable. 163 If we change the scope of ULAs to be smaller than global, we can 164 prioritize ULA to ULA communication over GUA to GUA communication. 165 At the same time, however, finer-grained configuration of ULA address 166 selection will be impossible. For example, even if you want to 167 prioritize communication related to the only /48 ULA prefix used in 168 your site, and do not want to prioritize communication to any other 169 ULA prefix, such a policy cannot be implemented in the policy table. 170 So, this draft proposes the use of the policy table to differentiate 171 ULAs from GUAs. 173 2.1.2. Teredo in the policy table 175 Teredo [RFC4380] is defined and has been assigned 2001::/32. This 176 address block should be assigned its own label in the policy table. 177 Teredo's priority should be less than or equal to 6to4, considering 178 its characteristic of being a transitional tunnel mechanism. 180 2.1.3. 6to4, Teredo, and IPv4 prioritization 182 Regarding the prioritization between IPv4 and these transitional 183 mechanisms, their connectivity is known to usually be worse than 184 IPv4. These mechanisms are said to be the last resort access method 185 to IPv6 resources. 6to4 should have higher precedence than Teredo, 186 given that 6to4 host to 6to4 host communication can be over IPv4 187 (which can result in a more optimal path) and that 6to4 should not 188 used behind a NAT device. 190 2.1.4. Deprecated addresses in the policy table 192 IPv4-compatible IPv6 addresses (::/96) are deprecated [RFC4291]. 193 IPv6 site-local unicast addresses (fec0::/10) are deprecated 194 [RFC3879]. 6bone testing addresses [RFC3701] were returned. 196 These addresses were removed from the current specification. So they 197 should not be treated differently, especially if we plan future re- 198 use of these address blocks. The 6bone testing address block should 199 not be treated specially. 201 Considering the inappropriate use of these address blocks, especially 202 in outdated implementations and bad effects brought by them, they 203 should be labeled differently from the legitimate address blocks as 204 long as the address block is reserved by IANA. 206 2.1.5. Renewed default policy table 208 After applying these updates, the default policy table will be: 210 Prefix Precedence Label 211 ::1/128 60 0 212 fc00::/7 50 1 213 ::/0 40 2 214 ::ffff:0:0/96 30 3 215 2002::/16 20 4 216 2001::/32 10 5 217 ::/96 1 10 218 fec0::/10 1 11 220 2.2. The longest matching rule 222 This issue is related to the longest matching rule, which was found 223 by Dave Thaler. It causes a malfunction of the DNS round robin 224 technique, as described below. It is common for both IPv4 and IPv6. 226 When a destination address DA, DB, and the source address of DA 227 Source(DA) are on the same subnet and Source(DA) == Source(DB), DNS 228 round robin load-balancing cannot function. By considering prefix 229 lengths that are longer than the subnet prefix, this rule establishes 230 preference between addresses that have no substantive differences 231 between them. The rule functions as an arbitrary tie-breaker between 232 the hosts in a round robin, causing a given host to always prefer a 233 given member of the round robin. 235 By limiting the calculation of common prefixes to a maximum length 236 equal to the length of the subnet prefix of the source address, rule 237 9 can continue to favor hosts that are nearby in the network 238 hierarchy without arbitrarily sorting addresses within a given 239 network. This modification could be written as follows: 241 Rule 9: Use longest matching prefix. 243 When DA and DB belong to the same address family (both are IPv6 or 244 both are IPv4): If CommonPrefixLen(DA & Netmask(Source(DA)), 245 Source(DA)) > CommonPrefixLen(DB & Netmask(Source(DB)), Source(DB)), 246 then prefer DA. Similarly, if CommonPrefixLen(DA & 247 Netmask(Source(DA)), Source(DA)) < CommonPrefixLen(DB & 248 Netmask(Source(DB)), Source(DB)), then prefer DB. 250 2.3. Utilize next-hop for source address selection 252 RFC 3484 source address selection rule 5 says that the address that 253 is attached to the outgoing interface should be preferred as the 254 source address. This rule is reasonable considering the prevalence 255 of ingress filtering described in BCP 38 [RFC2827]. This is because 256 an upstream network provider usually assumes it receives packets from 257 their customer that only have the delegated addresses as the source 258 addresses. 260 This rule, however, is not effective in an environment such as that 261 described in RFC 5220 Section 2.1.1, where a host has multiple 262 upstream routers on the same link and has addresses delegated from 263 each upstream router on a single interface. 265 Also, DHCPv6 assigned addresses are not associated like SLAAC 266 assigned addresses to a next-hop gateway, so implementations usually 267 can't apply this heuristic in a DHCPv6 network. 269 So, a new rule 5.1 that utilizes next-hop information for source 270 address selection is inserted just after rule 5. 272 Rule 5.1: Use an address assigned by the selected next-hop. 274 If SA is assigned by the selected next-hop that will be used to send 275 to D and SB is assigned by a different next-hop, then prefer SA. 276 Similarly, if SB is assigned by the next-hop that will be used to 277 send to D and SA is assigned by a different next-hop, then prefer SB. 279 2.4. Private IPv4 address scope 281 When a packet goes through a NAT, its source or destination address 282 can get replaced with another address with a different scope. It 283 follows that the result of the source address selection algorithm may 284 be different when the original address is replaced with the NATed 285 address. 287 The algorithm currently specified in RFC 3484 is based on the 288 assumption that a source address with a small scope cannot reach a 289 destination address with a larger scope. This assumption does not 290 hold if private IPv4 addresses and a NAT are used to reach public 291 IPv4 addresses. 293 Due to this assumption, in the presence of both a NATed private IPv4 294 address and a transitional address (like 6to4 or Teredo), the host 295 will choose the transitional IPv6 address to access dual-stack peers 296 [I-D.denis-v6ops-nat-addrsel]. Choosing transitional IPv6 297 connectivity over native IPv4 connectivity, particularly where the 298 transitional connectivity is unmanaged, is not considered to be 299 generally desirable. 301 This issue can be fixed by changing the address scope of private IPv4 302 addresses to global. 304 2.5. Deprecation of site-local unicast address 306 RFC 3484 contains a few "site-local unicast" and "fec0::" 307 descriptions. It's better to remove examples related to site-local 308 unicast addresses, or change the examples to use ULAs. Possible 309 points to be re-written are listed below. 311 - 2nd paragraph in RFC 3484 Section 3.1 describes the scope 312 comparison mechanism. 313 - RFC 3484 Section 10 contains examples for site-local addresses. 315 3. Security Considerations 317 No security risk is found that degrades RFC 3484. 319 4. IANA Considerations 321 Address type number for the policy table may have to be assigned by 322 IANA. 324 5. References 325 5.1. Normative References 327 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 328 April 1995. 330 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 331 E. Lear, "Address Allocation for Private Internets", 332 BCP 5, RFC 1918, February 1996. 334 [RFC3484] Draves, R., "Default Address Selection for Internet 335 Protocol version 6 (IPv6)", RFC 3484, February 2003. 337 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 338 Allocation) Phaseout", RFC 3701, March 2004. 340 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 341 Addresses", RFC 3879, September 2004. 343 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 344 Addresses", RFC 4193, October 2005. 346 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 347 Architecture", RFC 4291, February 2006. 349 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 350 Network Address Translations (NATs)", RFC 4380, 351 February 2006. 353 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 354 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 355 March 2008. 357 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 358 "Problem Statement for Default Address Selection in Multi- 359 Prefix Environments: Operational Issues of RFC 3484 360 Default Rules", RFC 5220, July 2008. 362 5.2. Informative References 364 [I-D.chown-addr-select-considerations] 365 Chown, T., "Considerations for IPv6 Address Selection 366 Policy Changes", draft-chown-addr-select-considerations-03 367 (work in progress), July 2009. 369 [I-D.denis-v6ops-nat-addrsel] 370 Denis-Courmont, R., "Problems with IPv6 source address 371 selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 372 (work in progress), February 2009. 374 [I-D.ietf-6man-addr-select-opt] 375 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 376 "Distributing Address Selection Policy using DHCPv6", 377 draft-ietf-6man-addr-select-opt-01 (work in progress), 378 June 2011. 380 [I-D.ietf-ipv6-ula-central] 381 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 382 Addresses", draft-ietf-ipv6-ula-central-02 (work in 383 progress), June 2007. 385 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 386 Defeating Denial of Service Attacks which employ IP Source 387 Address Spoofing", BCP 38, RFC 2827, May 2000. 389 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 390 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 391 October 2010. 393 Appendix A. Acknowledgements 395 Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- 396 Courmont and the members of 6man's address selection design team for 397 their invaluable contributions to this document. 399 Appendix B. Past Discussion 401 This section summarizes discussions we had before related to address 402 selection mechanisms. 404 B.1. The longest match rule 406 RFC 3484 defines that destination address selection rule 9 should be 407 applied to both IPv4 and IPv6, which spoils the DNS-based load 408 balancing technique that is widely used in the IPv4 Internet today. 410 When two or more destination addresses are acquired from one FQDN, 411 rule 9 states that the longest matching destination and source 412 address pair should be chosen. As in RFC 1794, the DNS-based load 413 balancing technique is achieved by not re-ordering the destination 414 addresses returned from the DNS server. Rule 9 defines a 415 deterministic rule for re-ordering hosts, hence the technique 416 described in RFC 1794 is not available anymore. 418 Regarding this problem, there was discussion in IETF and other places 419 like below. 421 Discussion: The possible changes to RFC 3484 are as follows: 423 1. To delete Rule 9 completely. 424 2. To apply Rule 9 only for IPv6 and not for IPv4. In IPv6, 425 hierarchical address assignment generally used at present, hence 426 the longest matching rule is beneficial in many cases. In IPv4, 427 as stated above, the DNS based load balancing technique is widely 428 used. 429 3. To apply Rule 9 for IPv6 conditionally and not for IPv4. When 430 the length of matching bits of the destination address and the 431 source address is longer than N, rule 9 is applied. Otherwise, 432 the order of the destination addresses do not change. The value 433 of N should be configurable and it should be 32 by default. This 434 is simply because the two sites whose matching bit length is 435 longer than 32 are probably adjacent. 437 Now that IPv6 PI addresses are being introduced by RIRs, hierarchical 438 address assignment is not always maintained anymore. It seems that 439 the longest matching algorithm may not worth the adverse effect of 440 disabling the DNS-based load balance technique. 442 B.2. NAT64 prefix issue 444 The NAT64 WKP has recently been defined[RFC6052]. It depends site by 445 site whether NAT64 should be preferred over IPv4, in other words 446 NAT44, or NAT44 over NAT64. So, the issue of local site policy 447 should be solved by manual policy table changes locally, or by use of 448 the proposed DHCP-based policy distribution mechanism. 450 B.3. ISATAP issue 452 Where a site is using ISATAP [RFC5214], there is generally no way to 453 differentiate an ISATAP address from a native address without 454 interface information. However, a site will assign a prefix for its 455 ISATAP overlay, and can choose to add an entry for that prefix to the 456 policy table if it wishes to change the default preference for that 457 prefix. 459 Appendix C. Revision History 461 04: 462 Added comment about ISATAP. 464 03: 466 ULA address selection issue was expanded. 467 6to4, Teredo and IPv4 prioritization issue was elaborated. 468 Deprecated address blocks in policy table section was elaborated. 469 In appendix, NAT64 prefix issue was added. 471 02: 472 Suresh Krishnan's suggestions for better english sentences were 473 incorporated. 474 A new source address selection rule that utilizes the next-hop 475 information is included in Section 2.3. 476 Site local address prefix was corrected. 478 01: 479 Re-structured to contain only the actual changes to RFC 3484. 481 00: 482 Published as a 6man working group item. 484 03: 485 Added acknowledgements. 486 Added longest matching algorithm malfunction regarding local DNS 487 round robin. 488 The proposed changes section was re-structured. 489 The issue of 6to4/Teredo and IPv4 prioritization was included. 490 The issue of deprecated addresses was added. 491 The renewed default policy table was changed accordingly. 493 02: 494 Added the reference to address selection design team's proposal. 496 01: 497 The issue of private IPv4 address scope was added. 498 The issue of ULA address scope was added. 499 Discussion of longest matching rule was expanded. 501 Authors' Addresses 503 Arifumi Matsumoto 504 NTT SI Lab 505 Midori-Cho 3-9-11 506 Musashino-shi, Tokyo 180-8585 507 Japan 509 Phone: +81 422 59 3334 510 Email: arifumi@nttv6.net 511 Jun-ya Kato 512 NTT SI Lab 513 Midori-Cho 3-9-11 514 Musashino-shi, Tokyo 180-8585 515 Japan 517 Phone: +81 422 59 2939 518 Email: kato@syce.net 520 Tomohiro Fujisaki 521 NTT PF Lab 522 Midori-Cho 3-9-11 523 Musashino-shi, Tokyo 180-8585 524 Japan 526 Phone: +81 422 59 7351 527 Email: fujisaki@syce.net 529 Tim Chown 530 University of Southampt on 531 Southampton, Hampshire SO17 1BJ 532 United Kingdom 534 Email: tjc@ecs.soton.ac.uk