idnits 2.17.1 draft-ietf-6man-rfc3484-revise-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (October 15, 2010) is 4936 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 263, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 279, but no explicit reference was found in the text == Unused Reference: 'RFC5220' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'I-D.chown-addr-select-considerations' is defined on line 296, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-denis-v6ops-nat-addrsel (ref. 'I-D.denis-v6ops-nat-addrsel') ** 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 Summary: 5 errors (**), 0 flaws (~~), 8 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 18, 2011 NTT 6 October 15, 2010 8 Update to RFC 3484 Default Address Selection for IPv6 9 draft-ietf-6man-rfc3484-revise-01.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 April 18, 2011. 36 Copyright Notice 38 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . 3 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. Private IPv4 address scope . . . . . . . . . . . . . . . . 5 74 2.4. Deprecation of site-local unicast address . . . . . . . . . 6 75 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 77 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 79 5.2. Informative References . . . . . . . . . . . . . . . . . . 7 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 7 81 Appendix B. Discussion . . . . . . . . . . . . . . . . . . . . . . 7 82 B.1. Centrally assigned ULA . . . . . . . . . . . . . . . . . . 7 83 B.2. 6to4, Teredo, and IPv4 prioritization . . . . . . . . . . . 8 84 B.3. Deprecated address . . . . . . . . . . . . . . . . . . . . 8 85 B.4. The longest match rule . . . . . . . . . . . . . . . . . . 8 86 Appendix C. Revision History . . . . . . . . . . . . . . . . . . . 9 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 89 1. Introduction 91 RFC 3484 describes algorithms for source address selection and for 92 destination address selection. The algorithms specify default 93 behavior for all Internet Protocol version 6 (IPv6) implementations. 95 RFC 3484 has several known issues to be fixed. Deprecation of IPv6 96 site-local unicast address and the coming of ULA brought some 97 preferable changes to the rules. Additionally, the rule 9 of the 98 destination address selection rules, namely the longest matching 99 rule, is known for its adverse effect on the round robin DNS 100 technique. 102 This document specifies a set of updates that modify the algorithms 103 and fix the known defects. 105 2. Specification 107 2.1. Changes related to the default policy table 109 The default policy table is defined in RFC 3484 Section 2.1 as 110 follows: 112 Prefix Precedence Label 113 ::1/128 50 0 114 ::/0 40 1 115 2002::/16 30 2 116 ::/96 20 3 117 ::ffff:0:0/96 10 4 119 The changes that should be included into the default policy table are 120 those rules that are universally useful and do no harm in every 121 reasonable network envionment. The changes we should consider for 122 the default policy table are listed in this sub-section. 124 The policy table is defined to be configurable. The changes that are 125 useful not universally but locally can be put into the policy table 126 manually or by using the auto-configuration mechanism proposed as a 127 DHCP option [I-D.fujisaki-dhc-addr-select-opt]. 129 2.1.1. ULA in the policy table 131 RFC 5220 Section 2.1.4, 2.2.2, and 2.2.3 describes address selection 132 problems related to ULA. These problems can be solved by changing 133 the scope of ULA to site-local, and/or by adding an entry for default 134 policy table entry that has its own label for ULA. 136 In its nature, ULA has global scope. This is because ULA's scope is 137 expected to be defined in routing system. It may be the case that 138 ULA and global IPv6 address are used for source and destination 139 addresses of communication. 141 On the other hand, to prioritize ULA to ULA communication is 142 basically reasonable. ULA should not be exposed to outside of its 143 routable routing domain, so if ULA is given from the application as a 144 candidate destination address, it can be generally expected that the 145 ULA is within or at least close to the source host. 147 Therefore, the scope of ULA should be kept global, and prioritization 148 of ULA to ULA communication should be implemented in policy table, by 149 assigning its own label for ULA fc00::/7. 151 2.1.2. Teredo in the policy table 153 Teredo [RFC4380] is defined and has been assigned 2001::/32. This 154 address block should be assigned its own label in the policy table. 155 Teredo's priority should be less or equal to 6to4, considering its 156 characteristic of transitional tunnel mechanism. About Windows, this 157 is already in the implementation. 159 2.1.3. Deprecated addresses in the policy table 161 IPv4-compatible IPv6 address is deprecated. [RFC4291] IPv6 site- 162 local unicast address is deprecated. [RFC3879] Moreover, 6bone 163 testing address was [RFC3701] The issue is how we treat these 164 outdated addresses. 166 2.1.4. Renewed default policy table 168 After applying these updates, the default policy table will be: 170 Prefix Precedence Label 171 ::1/128 60 0 172 fc00::/7 50 1 173 ::/0 40 2 174 ::ffff:0:0/96 30 3 175 2002::/16 20 4 176 2001::/32 10 5 177 ::/96 1 10 178 fec::/16 1 11 179 3ffe::/16 1 12 181 2.2. The longest matching rule 183 This issue is related to the longest matching rule, which was found 184 by Dave Thaler. It is malfunction of DNS round robin technique. It 185 is common for both IPv4 and IPv6. 187 When a destination address DA, DB, and the source address of DA 188 Source(DA) are on the same subnet and Source(DA) == Source(DB), DNS 189 round robin load-balancing cannot function. By considering prefix 190 lengths that are longer than the subnet prefix, this rule establishes 191 preference between addresses that have no substantive differences 192 between them. The rule functions as an arbitrary tie-breaker between 193 the hosts in a round robin, causing a given host to always prefer a 194 given member of the round robin. 196 By limiting the calculation of common prefixes to a maximum length 197 equal to the length of the subnet prefix of the source address, rule 198 9 can continue to favor hosts that are nearby in the network 199 hierarchy without arbitrarily sorting addresses within a given 200 network. This modification could be written as follows: 202 Rule 9: Use longest matching prefix. 204 When DA and DB belong to the same address family (both are IPv6 or 205 both are IPv4): If CommonPrefixLen(DA & Netmask(Source(DA)), 206 Source(DA)) > CommonPrefixLen(DB & Netmask(Source(DB)), Source(DB)), 207 then prefer DA. Similarly, if CommonPrefixLen(DA & 208 Netmask(Source(DA)), Source(DA)) < CommonPrefixLen(DB & 209 Netmask(Source(DB)), Source(DB)), then prefer DB. 211 2.3. Private IPv4 address scope 213 As detailed in Remi's draft [I-D.denis-v6ops-nat-addrsel], when a 214 host is in NATed site, and has a private IPv4 address and 215 transitional addresses like 6to4 and Teredo, the host chooses 216 transitional IPv6 address to access most of the dual-stack servers. 218 This is because private IPv4 address is defined to be site-local 219 scope, and as in RFC 3484, the scope matching rules (Rule 2) set 220 lower priority for private IPv4 address. 222 By changing the address scope of private IPv4 address to global, this 223 problem can be solved. Considering the widely deployed NAT with IPv4 224 private address model, this change works in most of the cases. If 225 not, this behavior can be overridden by configuring policy table, or 226 by configuring routing table on a host. 228 Moreover, some modern OSs have already implemented this change. 230 2.4. Deprecation of site-local unicast address 232 RFC3484 contains a few "site-local unicast" and "fec::" description. 233 It's better to remove examples related to site-local unicast address, 234 or change examples to use ULA. Possible points to be re-written are 235 below. 236 - 2nd paragraph in RFC 3484 Section 3.1 describes scope comparison 237 mechanism. 238 - RFC 3484 Section 10 contains examples for site-local address. 240 3. Security Considerations 242 No security risk is found that degrades RFC 3484. 244 4. IANA Considerations 246 Address type number for the policy table may have to be assigned by 247 IANA. 249 5. References 251 5.1. Normative References 253 [I-D.denis-v6ops-nat-addrsel] 254 Denis-Courmont, R., "Problems with IPv6 source address 255 selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 256 (work in progress), February 2009. 258 [I-D.ietf-ipv6-ula-central] 259 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 260 Addresses", draft-ietf-ipv6-ula-central-02 (work in 261 progress), June 2007. 263 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 264 April 1995. 266 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 267 E. Lear, "Address Allocation for Private Internets", 268 BCP 5, RFC 1918, February 1996. 270 [RFC3484] Draves, R., "Default Address Selection for Internet 271 Protocol version 6 (IPv6)", RFC 3484, February 2003. 273 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 274 Allocation) Phaseout", RFC 3701, March 2004. 276 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 277 Addresses", RFC 3879, September 2004. 279 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 280 Addresses", RFC 4193, October 2005. 282 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 283 Architecture", RFC 4291, February 2006. 285 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 286 Network Address Translations (NATs)", RFC 4380, 287 February 2006. 289 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 290 "Problem Statement for Default Address Selection in Multi- 291 Prefix Environments: Operational Issues of RFC 3484 292 Default Rules", RFC 5220, July 2008. 294 5.2. Informative References 296 [I-D.chown-addr-select-considerations] 297 Chown, T., "Considerations for IPv6 Address Selection 298 Policy Changes", draft-chown-addr-select-considerations-03 299 (work in progress), July 2009. 301 [I-D.fujisaki-dhc-addr-select-opt] 302 Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing 303 Address Selection Policy using DHCPv6", 304 draft-fujisaki-dhc-addr-select-opt-09 (work in progress), 305 March 2010. 307 Appendix A. Acknowledgements 309 Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- 310 Courmont and the members of 6man's address selection design team for 311 their invaluable inputs. 313 Appendix B. Discussion 315 B.1. Centrally assigned ULA 317 Discussion: Centrally assigned ULA [I-D.ietf-ipv6-ula-central] is 318 proposed, and assigned fc00::/8. Using the different labels for 319 fc00::/8 and fd00::/8 makes sense if we can assume the same kind 320 of address block is assigned in the same or adjacent network. 322 However, the way of assignment and network adjancency may not have 323 any relationships. 325 B.2. 6to4, Teredo, and IPv4 prioritization 327 Discussion: Regarding the prioritization between IPv4 and these 328 transitional mechanisms, the connectivity of them are recently 329 known to be worse than IPv4. These mechiansms are said to be the 330 last resort access to IPv6 resources. While 6to4 should have 331 higher precedence over Teredo, in that 6to4 host to 6to4 host 332 communication can be over IPv4, which can result in more optimal 333 path, and 6to4 does not need NAT traversal. 335 B.3. Deprecated address 337 Discussion: These addresses was removed from the current 338 specification. So, it should not be treated differently, 339 especially if we think about future re-use of these address 340 blocks. 342 Considering the inappropriate use of these address blocks 343 especially in outdated implementations and bad effects brought by 344 them, however, it should be labeled differently from the 345 legitimate address blocks. 346 keep this entry for the sake of backward compatibility ? 348 B.4. The longest match rule 350 RFC 3484 defines that the destination address selection rule 9 should 351 be applied to both IPv4 and IPv6, which spoils the DNS based load 352 balancing technique that is widely used in the IPv4 Internet today. 354 When two or more destination addresses are acquired from one FQDN, 355 the rule 9 defines that the longest matching destination and source 356 address pair should be chosen. As in RFC 1794, the DNS based load 357 balancing technique is achived by not re-ordering the destination 358 addresses returned from the DNS server. The Rule 9 defines 359 deterministic rule for re-ordering at hosts, hence the technique of 360 RFC 1794 is not available anymore. 362 Regarding this problem, there was discussion in IETF and other places 363 like below. 365 Discussion: The possible changes to RFC 3484 are as follows: 366 1. To delete Rule 9 completely. 367 2. To apply Rule 9 only for IPv6 and not for IPv4. In IPv6, 368 hiearchical address assignment is general principle, hence the 369 longest matchin rule is beneficial in many cases. In IPv4, as 370 stated above, the DNS based load balancing technique is widely 371 used. 372 3. To apply Rule 9 for IPv6 conditionally and not for IPv4. When 373 the length of matching bits of the destination address and the 374 source address is longer than N, the rule 9 is applied. 375 Otherwise, the order of the destination addresses do not change. 376 The N should be configurable and it should be 32 by default. 377 This is simply because the two sites whose matching bit length is 378 longer than 32 are probably adjacent. 380 Now that IPv6 PI address is admitted in some RIRs, hierachical 381 address assignment is not maintained anymore. It seems that the 382 longest matching algorithm may not worth the adverse effect of 383 disalbing the DNS based load balance technique. 385 Appendix C. Revision History 387 01: 388 Re-structured to contain only the actual changes to RFC 3484. 390 00: 391 Published as a 6man working group item. 393 03: 394 Added acknowledgements. 395 Added longest matching algorithm malfunction regarding local DNS 396 round robin. 397 The proposed changes section was re-structured. 398 The issue of 6to4/Teredo and IPv4 prioritization was included. 399 The issue of deprecated addresses was added. 400 The renewed default policy table was changed accordingly. 402 02: 403 Added the reference to address selection design team's proposal. 405 01: 406 The issue of private IPv4 address scope was added. 407 The issue of ULA address scope was added. 408 Discussion of longest matching rule was expanded. 410 Authors' Addresses 412 Arifumi Matsumoto 413 NTT SI Lab 414 Midori-Cho 3-9-11 415 Musashino-shi, Tokyo 180-8585 416 Japan 418 Phone: +81 422 59 3334 419 Email: arifumi@nttv6.net 421 Jun-ya Kato 422 NTT SI Lab 423 Midori-Cho 3-9-11 424 Musashino-shi, Tokyo 180-8585 425 Japan 427 Phone: +81 422 59 2939 428 Email: kato@syce.net 430 Tomohiro Fujisaki 431 NTT PF Lab 432 Midori-Cho 3-9-11 433 Musashino-shi, Tokyo 180-8585 434 Japan 436 Phone: +81 422 59 7351 437 Email: fujisaki@syce.net