idnits 2.17.1 draft-ietf-6man-rfc3484-revise-03.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 (June 10, 2011) is 4705 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 321, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'I-D.chown-addr-select-considerations' is defined on line 354, 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 5220 == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-00 Summary: 4 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: December 12, 2011 NTT 6 June 10, 2011 8 Update to RFC 3484 Default Address Selection for IPv6 9 draft-ietf-6man-rfc3484-revise-03.txt 11 Abstract 13 RFC 3484 describes algorithms for source address selection and for 14 destination address selection. The algorithms specify default 15 behavior for all Internet Protocol version 6 (IPv6) implementations. 16 This document specifies a set of updates that modify the algorithms 17 and fix the known defects. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 12, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Changes related to the default policy table . . . . . . . 3 68 2.1.1. ULA in the policy table . . . . . . . . . . . . . . . 4 69 2.1.2. Teredo in the policy table . . . . . . . . . . . . . . 4 70 2.1.3. 6to4, Teredo, and IPv4 prioritization . . . . . . . . 4 71 2.1.4. Deprecated addresses in the policy table . . . . . . . 5 72 2.1.5. Renewed default policy table . . . . . . . . . . . . . 5 73 2.2. The longest matching rule . . . . . . . . . . . . . . . . 5 74 2.3. Utilize next-hop for source address selection . . . . . . 6 75 2.4. Private IPv4 address scope . . . . . . . . . . . . . . . . 6 76 2.5. Deprecation of site-local unicast address . . . . . . . . 7 77 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 81 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 82 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 83 Appendix B. Past Discussion . . . . . . . . . . . . . . . . . . . 9 84 B.1. The longest match rule . . . . . . . . . . . . . . . . . . 9 85 B.2. NAT64 prefix issue . . . . . . . . . . . . . . . . . . . . 10 86 Appendix C. Revision History . . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 The IPv6 addressing architecture [RFC4291] allows multiple unicast 92 addresses to be assigned to interfaces. Because of this IPv6 93 implementations need to handle multiple possible source and 94 destination addresses when initiating communication RFC 3484 95 [RFC3484]. specifies the default algorithms, common across all 96 implementations, for selecting source and destination addresses so 97 that it is easier to predict the address selection behavior. 99 After RFC 3484 was specified, some issues have been identified with 100 the algorithm specified there. The issues are related to the longest 101 match algorithm used in Rule 9 of Destination address selection 102 breaking DNS round-robin techniques, and prioritization of poor IPv6 103 connectivity using transition mechanisms over native IPv4 104 connectivity. 106 There have also been some significant changes to the IPv6 addressing 107 architecture that require changes in the RFC 3484 policy table. Such 108 changes include the deprecation of site-local unicast addresses 109 [RFC3879] and the IPv4-compatible IPv6 addresses, the introduction of 110 Unique Local Addresses [RFC4193] etc. 112 This document specifies a set of updates that modify the algorithms 113 and fix the known defects. 115 2. Specification 117 2.1. Changes related to the default policy table 119 The default policy table is defined in RFC 3484 Section 2.1 as 120 follows: 122 Prefix Precedence Label 123 ::1/128 50 0 124 ::/0 40 1 125 2002::/16 30 2 126 ::/96 20 3 127 ::ffff:0:0/96 10 4 129 The changes that should be included into the default policy table are 130 those rules that are universally useful and do no harm in every 131 reasonable network envionment. The changes we should consider for 132 the default policy table are listed in this sub-section. 134 The policy table is defined to be configurable. The changes that are 135 useful not universally but locally can be put into the policy table 136 manually or by using the auto-configuration mechanism proposed as a 137 DHCP option [I-D.ietf-6man-addr-select-opt]. 139 2.1.1. ULA in the policy table 141 RFC 5220 [RFC5220] Section 2.1.4, 2.2.2, and 2.2.3 describes address 142 selection problems related to ULA [RFC4193]. These problems can be 143 solved by either changing the scope of ULA to site-local, or by 144 adding an entry for default policy table entry that has its own label 145 for ULA. 147 Centrally assigned ULA [I-D.ietf-ipv6-ula-central] is proposed, and 148 is assigned fc00::/8. Using the different labels for fc00::/8 and 149 fd00::/8 makes sense if we assume the same kind of address block is 150 assigned in the same or adjacent network. However, we cannot expect 151 that the type of ULA address block and network adjancency commonly 152 have any relationships. 154 Regarding the scope of ULA, ULA has been specified with a global 155 scope because the reachability of the ULA was intended to be 156 restricted by the routing system. Since the ULAs will not be exposed 157 outside of its reachability domain, if an ULA is available as a 158 candidate destination address, it can be expected to be reachable. 160 if we change the scope of ULA smaller than global, we can prioritize 161 ULA to ULA communication over GUA to GUA communication. At the same 162 time, however, finer-grained configuration of ULA address selection 163 will be impossible. For example, even if you want to priorize 164 communication related to the only /48 ULA prefix used in your site, 165 and do not want to prioritize communication to any other ULA prefix, 166 such a policy cannot be implemented in the policy table. So, this 167 draft proposes the use of the policy table to differentiate ULA from 168 GUA. 170 2.1.2. Teredo in the policy table 172 Teredo [RFC4380] is defined and has been assigned 2001::/32. This 173 address block should be assigned its own label in the policy table. 174 Teredo's priority should be less or equal to 6to4, considering its 175 characteristic of transitional tunnel mechanism. About Windows, this 176 is already in the implementation. 178 2.1.3. 6to4, Teredo, and IPv4 prioritization 180 Regarding the prioritization between IPv4 and these transitional 181 mechanisms, the connectivity of them are known to be worse than IPv4. 182 These mechiansms are said to be the last resort access to IPv6 183 resources. While 6to4 should have higher precedence over Teredo, in 184 that 6to4 host to 6to4 host communication can be over IPv4, which can 185 result in more optimal path, and 6to4 does not need NAT traversal. 187 2.1.4. Deprecated addresses in the policy table 189 IPv4-compatible IPv6 address (::/96) is deprecated [RFC4291]. IPv6 190 site-local unicast address (fec0::/10) is deprecated [RFC3879]. 6bone 191 testing address [RFC3701] was returned. 193 These addresses were removed from the current specification. So, it 194 should not be treated differently, especially if we plan future re- 195 use of these address blocks. Hense, 6bone testing address block 196 should not be treated specially. 198 Considering the inappropriate use of these address blocks especially 199 in outdated implementations and bad effects brought by them, it 200 should be labeled differently from the legitimate address blocks as 201 far as the address block is reserved by IANA. 203 2.1.5. Renewed default policy table 205 After applying these updates, the default policy table will be: 207 Prefix Precedence Label 208 ::1/128 60 0 209 fc00::/7 50 1 210 ::/0 40 2 211 ::ffff:0:0/96 30 3 212 2002::/16 20 4 213 2001::/32 10 5 214 ::/96 1 10 215 fec0::/10 1 11 217 2.2. The longest matching rule 219 This issue is related to the longest matching rule, which was found 220 by Dave Thaler. It is malfunction of DNS round robin technique. It 221 is common for both IPv4 and IPv6. 223 When a destination address DA, DB, and the source address of DA 224 Source(DA) are on the same subnet and Source(DA) == Source(DB), DNS 225 round robin load-balancing cannot function. By considering prefix 226 lengths that are longer than the subnet prefix, this rule establishes 227 preference between addresses that have no substantive differences 228 between them. The rule functions as an arbitrary tie-breaker between 229 the hosts in a round robin, causing a given host to always prefer a 230 given member of the round robin. 232 By limiting the calculation of common prefixes to a maximum length 233 equal to the length of the subnet prefix of the source address, rule 234 9 can continue to favor hosts that are nearby in the network 235 hierarchy without arbitrarily sorting addresses within a given 236 network. This modification could be written as follows: 238 Rule 9: Use longest matching prefix. 240 When DA and DB belong to the same address family (both are IPv6 or 241 both are IPv4): If CommonPrefixLen(DA & Netmask(Source(DA)), 242 Source(DA)) > CommonPrefixLen(DB & Netmask(Source(DB)), Source(DB)), 243 then prefer DA. Similarly, if CommonPrefixLen(DA & 244 Netmask(Source(DA)), Source(DA)) < CommonPrefixLen(DB & 245 Netmask(Source(DB)), Source(DB)), then prefer DB. 247 2.3. Utilize next-hop for source address selection 249 The RFC 3484 source address selection rule 5 defines the address that 250 is attached to the outgoing interface should be preferred as the 251 source address. This rule is reasonable considering the prevalence 252 of Ingress Filtering described in BCP 38 [RFC2827]. This is because 253 an upstream network provider usually assumes it receives those 254 packets from their customer that have the delegated addresses as the 255 source addresses. 257 This rule, however, is not effective in such a environment described 258 in RFC 5220 Section 2.1.1, where a host has multiple upstream routers 259 on the same link and has addresses delegated from each upstream 260 routers on single interface. 262 So, a new rule 5.1 that utilizes next-hop information for source 263 address selection is inserted just after the rule 5. 265 Rule 5.1: Use an address assigned by the selected next-hop. 267 If SA is assigned by the selected next-hop that will be used to send 268 to D and SB is assigned by a different next-hop, then prefer SA. 269 Similarly, if SB is assigned by the next-hop that will be used to 270 send to D and SA is assigned by a different next-hop, then prefer SB. 272 2.4. Private IPv4 address scope 274 When a packet goes through a NAT, its source or destination address 275 can get replaced with another address with a different scope. It 276 follows that the result of the source address selection algorithm may 277 be different when the original address is replaced with the NATed 278 address. 280 The algorithm currently specified in RFC 3484 is based on the 281 assumption that a source address with a small scope cannot reach a 282 destination address with a larger scope. This assumption does not 283 hold if private IPv4 addresses and a NAT are used to reach public 284 IPv4 addresses. 286 Due to this assumption, in the presence of both NATed private IPv4 287 address and transitional addresses (like 6to4 and Teredo), the host 288 will choose the transitional IPv6 address to access dual-stack peers 289 [I-D.denis-v6ops-nat-addrsel]. Choosing transitional IPv6 290 connectivity over native IPv4 connectivity is not considered to be a 291 very wise result. 293 This issue can be fixed by changing the address scope of private IPv4 294 addresses to global. Such change has already been implemented in 295 some OSes. 297 2.5. Deprecation of site-local unicast address 299 RFC 3484 contains a few "site-local unicast" and "fec0::" 300 description. It's better to remove examples related to site-local 301 unicast address, or change examples to use ULA. Possible points to 302 be re-written are below. 304 - 2nd paragraph in RFC 3484 Section 3.1 describes scope comparison 305 mechanism. 306 - RFC 3484 Section 10 contains examples for site-local address. 308 3. Security Considerations 310 No security risk is found that degrades RFC 3484. 312 4. IANA Considerations 314 Address type number for the policy table may have to be assigned by 315 IANA. 317 5. References 319 5.1. Normative References 321 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 322 April 1995. 324 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 325 E. Lear, "Address Allocation for Private Internets", 326 BCP 5, RFC 1918, February 1996. 328 [RFC3484] Draves, R., "Default Address Selection for Internet 329 Protocol version 6 (IPv6)", RFC 3484, February 2003. 331 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 332 Allocation) Phaseout", RFC 3701, March 2004. 334 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 335 Addresses", RFC 3879, September 2004. 337 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 338 Addresses", RFC 4193, October 2005. 340 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 341 Architecture", RFC 4291, February 2006. 343 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 344 Network Address Translations (NATs)", RFC 4380, 345 February 2006. 347 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 348 "Problem Statement for Default Address Selection in Multi- 349 Prefix Environments: Operational Issues of RFC 3484 350 Default Rules", RFC 5220, July 2008. 352 5.2. Informative References 354 [I-D.chown-addr-select-considerations] 355 Chown, T., "Considerations for IPv6 Address Selection 356 Policy Changes", draft-chown-addr-select-considerations-03 357 (work in progress), July 2009. 359 [I-D.denis-v6ops-nat-addrsel] 360 Denis-Courmont, R., "Problems with IPv6 source address 361 selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 362 (work in progress), February 2009. 364 [I-D.ietf-6man-addr-select-opt] 365 Matsumoto, A., Fujisaki, T., and J. Kato, "Distributing 366 Address Selection Policy using DHCPv6", 367 draft-ietf-6man-addr-select-opt-00 (work in progress), 368 December 2010. 370 [I-D.ietf-ipv6-ula-central] 371 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 372 Addresses", draft-ietf-ipv6-ula-central-02 (work in 373 progress), June 2007. 375 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 376 Defeating Denial of Service Attacks which employ IP Source 377 Address Spoofing", BCP 38, RFC 2827, May 2000. 379 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 380 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 381 October 2010. 383 Appendix A. Acknowledgements 385 Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- 386 Courmont and the members of 6man's address selection design team for 387 their invaluable contributions to this document. 389 Appendix B. Past Discussion 391 This section summarizes discussions we had before related to address 392 selection mechanisms. 394 B.1. The longest match rule 396 RFC 3484 defines that the destination address selection rule 9 should 397 be applied to both IPv4 and IPv6, which spoils the DNS based load 398 balancing technique that is widely used in the IPv4 Internet today. 400 When two or more destination addresses are acquired from one FQDN, 401 the rule 9 defines that the longest matching destination and source 402 address pair should be chosen. As in RFC 1794, the DNS based load 403 balancing technique is achived by not re-ordering the destination 404 addresses returned from the DNS server. The Rule 9 defines 405 deterministic rule for re-ordering at hosts, hence the technique of 406 RFC 1794 is not available anymore. 408 Regarding this problem, there was discussion in IETF and other places 409 like below. 411 Discussion: The possible changes to RFC 3484 are as follows: 413 1. To delete Rule 9 completely. 414 2. To apply Rule 9 only for IPv6 and not for IPv4. In IPv6, 415 hiearchical address assignment is general principle, hence the 416 longest matchin rule is beneficial in many cases. In IPv4, as 417 stated above, the DNS based load balancing technique is widely 418 used. 420 3. To apply Rule 9 for IPv6 conditionally and not for IPv4. When 421 the length of matching bits of the destination address and the 422 source address is longer than N, the rule 9 is applied. 423 Otherwise, the order of the destination addresses do not change. 424 The N should be configurable and it should be 32 by default. 425 This is simply because the two sites whose matching bit length is 426 longer than 32 are probably adjacent. 428 Now that IPv6 PI address is admitted in some RIRs, hierachical 429 address assignment is not maintained anymore. It seems that the 430 longest matching algorithm may not worth the adverse effect of 431 disalbing the DNS based load balance technique. 433 After long discussion, however we could not reach any consensus here. 434 That means, we cannot change the current rules for this issue. 436 B.2. NAT64 prefix issue 438 NAT64 WKP was newly defined[RFC6052]. It depends site by site 439 whether NAT64 should be preferred over IPv4, in other words NAT44, or 440 NAT44 over NAT64. So, this issue of site local policy should be 441 solved by policy distribution mechanism. 443 Appendix C. Revision History 445 03: 446 ULA address selection issue was expanded. 447 6to4, Teredo and IPv4 priorization issue was elaborated. 448 Deperecated address blocks in policy table section was elaborated. 449 In appendix, NAT64 prefix issue was added. 451 02: 452 Suresh Krishnan's suggestions for better english sentences were 453 incorporated. 454 A new source address selection rule that utilizes the next-hop 455 information is included in Section 2.3. 456 Site local address prefix was corrected. 458 01: 459 Re-structured to contain only the actual changes to RFC 3484. 461 00: 462 Published as a 6man working group item. 464 03: 466 Added acknowledgements. 467 Added longest matching algorithm malfunction regarding local DNS 468 round robin. 469 The proposed changes section was re-structured. 470 The issue of 6to4/Teredo and IPv4 prioritization was included. 471 The issue of deprecated addresses was added. 472 The renewed default policy table was changed accordingly. 474 02: 475 Added the reference to address selection design team's proposal. 477 01: 478 The issue of private IPv4 address scope was added. 479 The issue of ULA address scope was added. 480 Discussion of longest matching rule was expanded. 482 Authors' Addresses 484 Arifumi Matsumoto 485 NTT SI Lab 486 Midori-Cho 3-9-11 487 Musashino-shi, Tokyo 180-8585 488 Japan 490 Phone: +81 422 59 3334 491 Email: arifumi@nttv6.net 493 Jun-ya Kato 494 NTT SI Lab 495 Midori-Cho 3-9-11 496 Musashino-shi, Tokyo 180-8585 497 Japan 499 Phone: +81 422 59 2939 500 Email: kato@syce.net 502 Tomohiro Fujisaki 503 NTT PF Lab 504 Midori-Cho 3-9-11 505 Musashino-shi, Tokyo 180-8585 506 Japan 508 Phone: +81 422 59 7351 509 Email: fujisaki@syce.net