idnits 2.17.1 draft-ietf-6man-rfc3484-revise-02.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 (March 14, 2011) is 4785 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 294, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 297, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-addr-select-considerations' is defined on line 332, 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 (-05) exists of draft-ietf-6man-addr-select-considerations-02 == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-00 Summary: 4 errors (**), 0 flaws (~~), 7 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: September 15, 2011 NTT 6 March 14, 2011 8 Update to RFC 3484 Default Address Selection for IPv6 9 draft-ietf-6man-rfc3484-revise-02.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 provide fixes for the identified issues. 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 September 15, 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. ULAs in the policy table . . . . . . . . . . . . . . . 4 69 2.1.2. Teredo in the policy table . . . . . . . . . . . . . . 4 70 2.1.3. Deprecated addresses in the policy table . . . . . . . 4 71 2.1.4. Renewed default policy table . . . . . . . . . . . . . 4 72 2.2. The longest matching rule . . . . . . . . . . . . . . . . 5 73 2.3. Utilize next-hop for source address selection . . . . . . 5 74 2.4. Private IPv4 address scope . . . . . . . . . . . . . . . . 6 75 2.5. Deprecation of site-local unicast address . . . . . . . . 6 76 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 80 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 82 Appendix B. Discussion . . . . . . . . . . . . . . . . . . . . . 8 83 B.1. Centrally assigned ULA . . . . . . . . . . . . . . . . . . 8 84 B.2. 6to4, Teredo, and IPv4 prioritization . . . . . . . . . . 9 85 B.3. Deprecated address . . . . . . . . . . . . . . . . . . . . 9 86 B.4. The longest match rule . . . . . . . . . . . . . . . . . . 9 87 Appendix C. Revision History . . . . . . . . . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 92 The IPv6 addressing architecture [RFC4291] allows multiple unicast 93 addresses to be assigned to interfaces. Because of this IPv6 94 implementations need to handle multiple possible source and 95 destination addresses when initiating communication. RFC 3484 96 [RFC3484] specifies the default algorithms, common across all 97 implementations, for selecting source and destination addresses so 98 that it is easier to predict the address selection behavior. 100 Since RFC 3484 was published, some issues have been identified with 101 the algorithm specified there. The issues are related to the longest 102 match algorithm used in Rule 9 of Destination address selection 103 breaking DNS round-robin techniques, and prioritization of poor IPv6 104 connectivity using transition mechanisms over native IPv4 105 connectivity. 107 There have also been some significant changes to the IPv6 addressing 108 architecture that require changes in the RFC 3484 policy table. Such 109 changes include the deprecation of site-local unicast addresses 110 [RFC3879] and the IPv4-compatible IPv6 addresses, the introduction of 111 Unique Local Addresses [RFC4193] etc. 113 This document specifies a set of updates that modify the algorithms 114 and provide fixes for the identified issues. 116 2. Specification 118 2.1. Changes related to the default policy table 120 The default policy table is defined in RFC 3484 Section 2.1 as 121 follows: 123 Prefix Precedence Label 124 ::1/128 50 0 125 ::/0 40 1 126 2002::/16 30 2 127 ::/96 20 3 128 ::ffff:0:0/96 10 4 130 The changes that should be included into the default policy table are 131 those rules that are universally useful and do no harm in every 132 reasonable network environment. The changes we should consider for 133 the default policy table are listed in this sub-section. 135 The policy table is defined to be configurable. If the local site 136 policy needs to be different changes can be put into the policy table 137 manually or by using the auto-configuration mechanism proposed as a 138 DHCP option [I-D.ietf-6man-addr-select-opt]. 140 2.1.1. ULAs in the policy table 142 RFC 5220 [RFC5220] Section 2.1.4, 2.2.2, and 2.2.3 describes address 143 selection problems related to ULAs [RFC4193]. These problems can be 144 solved by either changing the scope of ULAs to site-local, or by 145 adding an entry to the default policy table entry that has its own 146 label for ULAs. 148 ULAs has been specified with a global scope because the reachability 149 of the ULAs was intended to be restricted by the routing system. 150 Since a ULA will not be exposed outside of its reachability domain, 151 if a ULA is available as a candidate destination address, it can be 152 expected to be reachable. In fact, such ULA to ULA communication is 153 often desired (in particular in sites where ULAs are intended to 154 provide stable addresses when the global prefix may be changing) and 155 thus needs to be prioritized. 157 Therefore, the scope of ULA should be kept global, and prioritization 158 of ULA to ULA communication should be implemented in the policy 159 table, by assigning a specific label for ULAs using fc00::/7. 161 2.1.2. Teredo in the policy table 163 Teredo [RFC4380] is defined and has been assigned 2001::/32. This 164 address block should be assigned its own label in the policy table. 165 Teredo's priority should be less than or equal to 6to4, considering 166 its characteristic of being a transitional tunnel mechanism. Windows 167 already implements this. 169 2.1.3. Deprecated addresses in the policy table 171 IPv4-compatible IPv6 addresses are deprecated [RFC4291]. IPv6 site- 172 local unicast addresses are deprecated [RFC3879]. Moreover, the 173 6bone testing address has also been phased out[RFC3701]. The issue 174 is how we treat these outdated addresses. 176 2.1.4. Renewed default policy table 178 After applying these updates, the default policy table becomes: 180 Prefix Precedence Label 181 ::1/128 60 0 182 fc00::/7 50 1 183 ::/0 40 2 184 ::ffff:0:0/96 30 3 185 2002::/16 20 4 186 2001::/32 10 5 187 ::/96 1 10 188 fec::/16 1 11 189 3ffe::/16 1 12 191 2.2. The longest matching rule 193 This issue is related to a problem with the longest matching rule, as 194 reported by Dave Thaler. It is a malfunction of the DNS round-robin 195 technique. It is common for both IPv4 and IPv6. 197 When a destination address DA, DB, and the source address of DA 198 Source(DA) are on the same subnet and Source(DA) == Source(DB), DNS 199 round robin load-balancing cannot function. By considering prefix 200 lengths that are longer than the subnet prefix, this rule establishes 201 preference between addresses that have no substantive differences 202 between them. The rule functions as an arbitrary tie-breaker between 203 the hosts in a round robin, causing a given host to always prefer a 204 given member of the round robin. 206 By limiting the calculation of common prefixes to a maximum length 207 equal to the length of the subnet prefix of the source address, rule 208 9 can continue to favor hosts that are nearby in the network 209 hierarchy without arbitrarily sorting addresses within a given 210 network. This modification could be written as follows: 212 Rule 9: Use longest matching prefix. 214 When DA and DB belong to the same address family (both are IPv6 or 215 both are IPv4): If CommonPrefixLen(DA & Netmask(Source(DA)), 216 Source(DA)) > CommonPrefixLen(DB & Netmask(Source(DB)), Source(DB)), 217 then prefer DA. Similarly, if CommonPrefixLen(DA & 218 Netmask(Source(DA)), Source(DA)) < CommonPrefixLen(DB & 219 Netmask(Source(DB)), Source(DB)), then prefer DB. 221 2.3. Utilize next-hop for source address selection 223 RFC 3484 source address selection rule 5 states that the address that 224 is attached to the outgoing interface should be preferred as the 225 source address. This rule is reasonable considering the prevalence 226 of Ingress Filtering described in BCP 38 [RFC2827]. This is because 227 an upstream network provider usually assumes it receives those 228 packets from customers that will use the delegated addresses as their 229 source addresses. 231 This rule, however, is not effective in an environment such as 232 described in RFC 5220 Section 2.1.1, where a host has multiple 233 upstream routers on the same link and has addresses delegated from 234 each upstream on single interface. 236 So, a new rule 5.1 that utilizes next-hop information for source 237 address selection is inserted just after the rule 5. 239 Rule 5.1: Use an address assigned by the selected next-hop. 241 If SA is assigned by the selected next-hop that will be used to send 242 to D and SB is assigned by a different next-hop, then prefer SA. 243 Similarly, if SB is assigned by the next-hop that will be used to 244 send to D and SA is assigned by a different next-hop, then prefer SB. 246 2.4. Private IPv4 address scope 248 When a packet goes through a NAT, its source or destination address 249 can get replaced with another address with a different scope. It 250 follows that the result of the source address selection algorithm may 251 be different when the original address is replaced with the NATed 252 address. 254 The algorithm currently specified in RFC 3484 is based on the 255 assumption that a source address with a small scope cannot reach a 256 destination address with a larger scope. This assumption does not 257 hold if private IPv4 addresses and a NAT are used to reach public 258 IPv4 addresses. 260 Due to this assumption, in the presence of both NATed private IPv4 261 address and transitional addresses (like 6to4 and Teredo), the host 262 will choose the transitional IPv6 address to access dual-stack peers 263 [I-D.denis-v6ops-nat-addrsel]. Choosing transitional IPv6 264 connectivity over native IPv4 connectivity is not desirable. 266 This issue can be fixed by changing the address scope of private IPv4 267 addresses to global. Such a change has already been implemented in 268 some OSes. 270 2.5. Deprecation of site-local unicast address 272 RFC 3484 contains a few "site-local unicast" and "fec::" 273 descriptions. It's better to remove examples related to site-local 274 unicast address, or change examples to use ULAs. Points that need to 275 be re-written are: 277 - the 2nd paragraph in RFC 3484 Section 3.1 describing the scope 278 comparison mechanism. 279 - RFC 3484 Section 10 containing examples for site-local address. 281 3. Security Considerations 283 No security risk is found that degrades RFC 3484. 285 4. IANA Considerations 287 An address type number for the policy table may have to be assigned 288 by IANA. 290 5. References 292 5.1. Normative References 294 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 295 April 1995. 297 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 298 E. Lear, "Address Allocation for Private Internets", 299 BCP 5, RFC 1918, February 1996. 301 [RFC3484] Draves, R., "Default Address Selection for Internet 302 Protocol version 6 (IPv6)", RFC 3484, February 2003. 304 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 305 Allocation) Phaseout", RFC 3701, March 2004. 307 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 308 Addresses", RFC 3879, September 2004. 310 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 311 Addresses", RFC 4193, October 2005. 313 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 314 Architecture", RFC 4291, February 2006. 316 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 317 Network Address Translations (NATs)", RFC 4380, 318 February 2006. 320 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 321 "Problem Statement for Default Address Selection in Multi- 322 Prefix Environments: Operational Issues of RFC 3484 323 Default Rules", RFC 5220, July 2008. 325 5.2. Informative References 327 [I-D.denis-v6ops-nat-addrsel] 328 Denis-Courmont, R., "Problems with IPv6 source address 329 selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 330 (work in progress), February 2009. 332 [I-D.ietf-6man-addr-select-considerations] 333 Chown, T., "Considerations for IPv6 Address Selection 334 Policy Changes", 335 draft-ietf-6man-addr-select-considerations-02 (work in 336 progress), July 2010. 338 [I-D.ietf-6man-addr-select-opt] 339 Matsumoto, A., Fujisaki, T., and J. Kato, "Distributing 340 Address Selection Policy using DHCPv6", 341 draft-ietf-6man-addr-select-opt-00 (work in progress), 342 December 2010. 344 [I-D.ietf-ipv6-ula-central] 345 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 346 Addresses", draft-ietf-ipv6-ula-central-02 (work in 347 progress), June 2007. 349 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 350 Defeating Denial of Service Attacks which employ IP Source 351 Address Spoofing", BCP 38, RFC 2827, May 2000. 353 Appendix A. Acknowledgements 355 The authors would like to thank to Dave Thaler, Pekka Savola, Remi 356 Denis-Courmont and the members of 6man's address selection design 357 team for their invaluable contributions to this document. 359 Appendix B. Discussion 361 B.1. Centrally assigned ULA 363 Discussion: Centrally assigned ULA [I-D.ietf-ipv6-ula-central] is 364 proposed, and assigned fc00::/8. Using the different labels for 365 fc00::/8 and fd00::/8 makes sense if we can assume the same kind 366 of address block is assigned in the same or adjacent network. 368 However, the way of assignment and network adjancency may not have 369 any relationships. 371 B.2. 6to4, Teredo, and IPv4 prioritization 373 Discussion: Regarding the prioritization between IPv4 and these 374 transitional mechanisms, their connectivity quality is recently 375 known to be worse than IPv4. These mechiansms are said to be the 376 last resort access to IPv6 resources. The 6to4 should have higher 377 precedence over Teredo, in that 6to4 host to 6to4 host 378 communication runs over IPv4, which can result in a more optimal 379 path, and 6to4 does not need NAT traversal. 381 B.3. Deprecated address 383 Discussion: These addresses were removed from the current 384 specification. So, they should not be treated differently, 385 especially if we think about future re-use of these address 386 blocks. 388 Considering the inappropriate use of these address blocks, 389 especially in outdated implementations, and bad effects caused by 390 them, however, they should be labeled differently from the 391 legitimate address blocks. 392 Or should we keep this entry for the sake of backward 393 compatibility? 395 B.4. The longest match rule 397 RFC 3484 defines that the destination address selection rule 9 should 398 be applied to both IPv4 and IPv6, which spoils the DNS based load 399 balancing technique that is widely used in the IPv4 Internet today. 401 When two or more destination addresses are acquired from one FQDN, 402 rule 9 states that the longest matching destination and source 403 address pair should be chosen. As stated in RFC 1794, the DNS based 404 load balancing technique is achieved by not re-ordering the 405 destination addresses returned from the DNS server. Rule 9 defines a 406 deterministic rule for re-ordering at hosts, hence the technique of 407 RFC 1794 is not available anymore. 409 Regarding this problem, there was discussion in the IETF and other 410 places that led to some different options being suggested, as listed 411 below. 413 Discussion: The possible changes to RFC 3484 are as follows: 415 1. To delete Rule 9 completely. 416 2. To apply Rule 9 only for IPv6 and not for IPv4. In IPv6, 417 hierarchical address assignment is a general principle, hence the 418 longest matching rule is beneficial in many cases. In IPv4, as 419 stated above, the DNS based load balancing technique is widely 420 used. 421 3. To apply Rule 9 for IPv6 conditionally and not for IPv4. When 422 the length of matching bits of the destination address and the 423 source address is longer than N, rule 9 is applied. Otherwise, 424 the order of the destination addresses do not change. The N 425 should be configurable and it should be 32 by default. This is 426 simply because the two sites whose matching bit length is longer 427 than 32 are probably adjacent. 429 Now that IPv6 PI addressing is being assigned by some RIRs, 430 hierachical address assignment is not fully maintained anymore. It 431 seems that the longest matching algorithm may not be worth the 432 adverse effect of disalbing the DNS based load balance technique. 434 Appendix C. Revision History 436 02: 437 Suresh Krishnan's comments were incorporated. 438 A new source address selection rule that utilizes the next-hop 439 information is included in Section 2.3 441 01: 442 Restructured to contain only the actual changes to RFC 3484. 444 00: 445 Published as a 6man working group item. 447 03: 448 Added acknowledgements. 449 Added longest matching algorithm malfunction regarding local DNS 450 round robin. 451 The proposed changes section was restructured. 452 The issue of 6to4/Teredo and IPv4 prioritization was included. 453 The issue of deprecated addresses was added. 454 The renewed default policy table was changed accordingly. 456 02: 457 Added the reference to address selection design team's proposal. 459 01: 461 The issue of private IPv4 address scope was added. 462 The issue of ULA address scope was added. 463 Discussion of longest matching rule was expanded. 465 Authors' Addresses 467 Arifumi Matsumoto 468 NTT SI Lab 469 Midori-Cho 3-9-11 470 Musashino-shi, Tokyo 180-8585 471 Japan 473 Phone: +81 422 59 3334 474 Email: arifumi@nttv6.net 476 Jun-ya Kato 477 NTT SI Lab 478 Midori-Cho 3-9-11 479 Musashino-shi, Tokyo 180-8585 480 Japan 482 Phone: +81 422 59 2939 483 Email: kato@syce.net 485 Tomohiro Fujisaki 486 NTT PF Lab 487 Midori-Cho 3-9-11 488 Musashino-shi, Tokyo 180-8585 489 Japan 491 Phone: +81 422 59 7351 492 Email: fujisaki@syce.net