idnits 2.17.1 draft-ietf-6man-rfc3484-revise-00.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (September 13, 2010) is 4974 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) ** 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 (~~), 3 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: March 17, 2011 NTT 6 September 13, 2010 8 Things To Be Included in RFC 3484 Revision 9 draft-ietf-6man-rfc3484-revise-00.txt 11 Abstract 13 RFC 3484 has several known issues to be fixed. Deprecation of IPv6 14 site-local unicast address and the coming of ULA brought some 15 preferable changes to the rules. Additionally, the rule 9 of the 16 destination address selection rules, namely the longest matching 17 rule, is known for its adverse effect on the round robin DNS 18 technique. This document covers these points to be fixed and 19 proposes possible useful changes to be included in the revision of 20 RFC 3484. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 17, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Problem Example . . . . . . . . . . . . . . . . . . . . . 4 70 2. Proposed Changes to RFC 3484 . . . . . . . . . . . . . . . . . 5 71 2.1. Changes related to the default policy table . . . . . . . 5 72 2.1.1. Arrival of ULA . . . . . . . . . . . . . . . . . . . . 6 73 2.1.2. Arrival of Teredo and harm of transitional 74 mechanisms . . . . . . . . . . . . . . . . . . . . . . 6 75 2.1.3. Deprecated addresses . . . . . . . . . . . . . . . . . 7 76 2.1.4. Renewed default policy table . . . . . . . . . . . . . 7 77 2.2. Source address selection for multicast packet . . . . . . 7 78 2.3. RFC 3484 Section 6 Rule 9 and DNS round robin . . . . . . 8 79 2.4. RFC 3484 Section 6 Rule 9 and local DNS round robin . . . 9 80 2.5. Deprecation of site-local unicast address . . . . . . . . 9 81 2.6. Private IPv4 address scope . . . . . . . . . . . . . . . . 10 82 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 87 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 88 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 89 Appendix B. Revision History . . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 RFC 3484 [RFC3484] defines default address selection rules for IPv6 95 and IPv4. Because of the deprecation of IPv6 site-local unicast 96 address[RFC3879] and the coming of ULA, [RFC4193] these rules in RFC 97 3484 are known to cause communication failures depending on the 98 network environment. 100 Additionally, there was a discussion at v6ops and ietf mailing lists 101 that the rule 9 of the destination address selection has a serious 102 adverse effect on the round robin DNS technique. [RFC1794] RFC 3484 103 defines that the destination address selection rule 9 should be 104 applied to both IPv4 and IPv6, which spoils the DNS based load 105 balancing technique that is widely used in the IPv4 Internet today. 107 Remi Denis-Courmont summarized NAT related address selection problems 108 and possible solutions in [I-D.denis-v6ops-nat-addrsel]. 110 Problems related to IPv6 and IPv4 address selection are described in 111 RFC 5220 [RFC5220]. Some of them can be fixed by updating RFC 3484, 112 and some of the others are solved by address selection design team's 113 proposal [I-D.chown-addr-select-considerations]. 115 This document covers these points to be fixed and proposes possible 116 useful changes to be included in the revision of RFC 3484. 118 1.1. Problem Example 120 When an enterprise has IPv4 Internet connectivity but does not yet 121 have IPv6 Internet connectivity, and the enterprise wants to provide 122 site-local IPv6 connectivity, ULA is the best choice for site-local 123 IPv6 connectivity. Each employee host will have both an IPv4 global 124 or private address [RFC1918] and a ULA. Here, when this host tries 125 to connect to Host-C that has registered both A and AAAA records in 126 the DNS, the host will choose AAAA as the destination address and ULA 127 for the source address. This will clearly result in a connection 128 failure. 130 +--------+ 131 | Host-C | AAAA = 2001:db8::80 132 +-----+--+ A = 192.47.163.1 133 | 134 ============ 135 | Internet | 136 ============ 137 | no IPv6 connectivity 138 +----+----+ 139 | Gateway | 140 +----+----+ 141 | 142 | fd01:2:3::/48 (ULA) 143 | 192.0.2.0/24 144 ++--------+ 145 | Router | 146 +----+----+ 147 | fd01:2:3:4::/64 (ULA) 148 | 192.0.2.240/28 149 ------+---+---------- 150 | 151 +-+----+ fd01:2:3:4::100 (ULA) 152 | Host | 192.0.2.245 153 +------+ 155 [Fig. 1] 157 This problem can be solved by changing the scope of ULA to site- 158 local, or by adding one entry to the default policy table that sets 159 lower priority for ULA than IPv4 address. 161 This problem was mentioned at ipv6 mailing lists by Pekka Savola. 163 2. Proposed Changes to RFC 3484 165 2.1. Changes related to the default policy table 167 The default policy table is defined in RFC 3484 Section 2.1 as 168 follows: 170 Prefix Precedence Label 171 ::1/128 50 0 172 ::/0 40 1 173 2002::/16 30 2 174 ::/96 20 3 175 ::ffff:0:0/96 10 4 177 The changes that should be included into the default policy table are 178 those rules that are universally useful and do no harm in every 179 reasonable network envionment. The changes we should consider for 180 the default policy table are listed in this sub-section. 182 The policy table is defined to be configurable. The changes that are 183 useful not universally but locally can be put into the policy table 184 manually or by using the auto-configuration mechanism proposed as a 185 DHCP option [I-D.fujisaki-dhc-addr-select-opt]. 187 2.1.1. Arrival of ULA 189 RFC 5220 Section 2.1.4, 2.2.2, and 2.2.3 describes address selection 190 problems related to ULA. These problems can be solved by changing 191 the scope of ULA to site-local, or by adding an entry for default 192 policy table entry that has its own label for ULA. 194 In its nature, ULA has global scope. This is because ULA's scope is 195 defined to be defined in routing mechanism. It may be the case that 196 ULA and global IPv6 address are used for source and destination 197 addresses of communication. 199 On the other hand, to prioritize ULA to ULA communication is 200 basically reasonable. ULA should not be exposed to outside of its 201 routable routing domain, so if ULA is given from the application as a 202 candidate destination address, it can be generally expected that the 203 ULA is within or at least close to the source host. 205 Therefore, the scope of ULA should be global, and prioritization of 206 ULA to ULA communication should be implemented in policy table, by 207 assigning its own label for ULA fc00::/7. 209 Discussion: Centrally assigned ULA [I-D.ietf-ipv6-ula-central] is 210 proposed, and assigned fc00::/8. Using the different labels for 211 fc00::/8 and fd00::/8 makes sense if we can assume the same kind 212 of address block is assigned in the same or adjacent network. 213 However, the way of assignment and network adjancency may not have 214 any relationships. 216 2.1.2. Arrival of Teredo and harm of transitional mechanisms 218 Teredo [RFC4380] is defined and has been assigned 2001::/32. 219 Teredo's priority should be less or equal to 6to4, considering its 220 characteristic of tunnel mechanism. About Windows, this is already 221 in the implementation. 223 Discussion: Regarding the prioritization between IPv4 and these 224 transitional mechanisms, the connectivity of them are recently 225 known to be worse than IPv4. These mechiansms are said to be the 226 last resort access to IPv6 resources. While 6to4 should have 227 higher precedence over Teredo, in that 6to4 host to 6to4 host 228 communication can be over IPv4, which can result in more optimal 229 path, and 6to4 does not need NAT traversal. 231 2.1.3. Deprecated addresses 233 IPv4-compatible IPv6 address is deprecated. [RFC4291] IPv6 site- 234 local unicast address is deprecated. [RFC3879] Moreover, 6bone 235 testing address was [RFC3701] The issue is how we treat these 236 outdated addresses. 238 Discussion: These addresses was removed from the current 239 specification. So, it should not be treated differently, 240 especially if we think about future re-use of these address 241 blocks. 243 Considering the inappropriate use of these address blocks 244 especially in outdated implementations and bad effects brought by 245 them, however, it should be labeled differently from the 246 legitimate address blocks. 248 2.1.4. Renewed default policy table 250 When we apply these changes, the default policy table will be: 252 Prefix Precedence Label 253 ::1/128 60 0 254 fc00::/7 50 1 255 ::/0 40 2 256 ::ffff:0:0/96 30 3 257 2002::/16 20 4 258 2001::/32 10 5 259 ::/96 1 10 260 fec::/16 1 11 261 3ffe::/16 1 12 263 2.2. Source address selection for multicast packet 265 Source address selection for a multicast packet easily fails. It is 266 suggested to add some notes describing this issue of multicast 267 address selection. 269 As described in RFC 5220 Section 2.1.6, by default, ULA will be 270 chosen for a multicast packet of any scope. 272 This issue cannot be solved by changing a RFC 3484 rule. This is 273 because, multicast and unicast have different sets of scope and it is 274 site-dependent which unicast address scope is appropriate for the 275 site's multicast scope. Therefore, this issue can be solved, for 276 example, by configuring the policy table per-site. 278 2.3. RFC 3484 Section 6 Rule 9 and DNS round robin 280 There was a discussion at v6ops and ietf@ietf.org mailing lists that 281 the rule 9 of the destination address selection has a serious adverse 282 effect on the round robin DNS technique. RFC 3484 defines that the 283 destination address selection rule 9 should be applied to both IPv4 284 and IPv6, which spoils the DNS based load balancing technique that is 285 widely used in the IPv4 Internet today. 287 When the destination address acquired from one FQDN are two or more, 288 the Rule 9 defines that the longest matching destination and source 289 address pair should be chosen. As in RFC 1794, the DNS based load 290 balancing technique is achived by not re-ordering the destination 291 addresses returned from the DNS server. The Rule 9 defines 292 deterministic rule for re-ordering at hosts, hence the technique of 293 RFC 1794 is not available anymore. 295 Regarding this problem, there was discussion in IETF and other places 296 like below. 297 http://drplokta.livejournal.com/109267.html 298 http://www.ietf.org/mail-archive/web/ietf/current/msg51874.html 299 http://www.ietf.org/mail-archive/web/discuss/current/msg01035.html 300 http://www.ietf.org/mail-archive/web/dnsop/current/msg05847.html 301 http://lists.debian.org/debian-ctte/2007/11/msg00029.html 302 http://www.ietf.org/mail-archive/web/ietf/current/msg55991.html 304 Discussion: The possible changes to RFC 3484 are as follows: 306 1. To delete Rule 9 completely. 307 2. To apply Rule 9 only for IPv6 and not for IPv4. In IPv6, 308 hiearchical address assignment is general principle, hence the 309 longest matchin rule is beneficial in many cases. In IPv4, as 310 stated above, the DNS based load balancing technique is widely 311 used. 312 3. To apply Rule 9 for IPv6 conditionally and not for IPv4. When 313 the length of matching bits of the destination address and the 314 source address is longer than N, the rule 9 is applied. 315 Otherwise, the order of the destination addresses do not change. 316 The N should be configurable and it should be 32 by default. 317 This is simply because the two sites whose matching bit length is 318 longer than 32 are probably adjacent. 320 Now that IPv6 PI address is admitted in some RIRs, hierachical 321 address assignment is not maintained anymore. It seems that the 322 longest matching algorithm may not worth the adverse effect of 323 disalbing the DNS based load balance technique. 325 2.4. RFC 3484 Section 6 Rule 9 and local DNS round robin 327 There is another issue related to the longest matching rule, which 328 was found by Dave Thaler. It is also malfunction of DNS round robin 329 technique. It is common for both IPv4 and IPv6. 331 When a destination address DA, DB, and the source address of DA 332 Source(DA) are on the same subnet and Source(DA) == Source(DB), DNS 333 round robin load-balancing cannot function. By considering prefix 334 lengths that are longer than the subnet prefix, this rule establishes 335 preference between addresses that have no substantive differences 336 between them. The rule functions as an arbitrary tie-breaker between 337 the hosts in a round robin, causing a given host to always prefer a 338 given member of the round robin. 340 By limiting the calculation of common prefixes to a maximum length 341 equal to the length of the subnet prefix of the source address, rule 342 9 can continue to favor hosts that are nearby in the network 343 hierarchy without arbitrarily sorting addresses within a given 344 network. This modification could be written as follows: 346 Rule 9: Use longest matching prefix. 348 When DA and DB belong to the same address family (both are IPv6 or 349 both are IPv4): If CommonPrefixLen(DA & Netmask(Source(DA)), 350 Source(DA)) > CommonPrefixLen(DB & Netmask(Source(DB)), Source(DB)), 351 then prefer DA. Similarly, if CommonPrefixLen(DA & 352 Netmask(Source(DA)), Source(DA)) < CommonPrefixLen(DB & 353 Netmask(Source(DB)), Source(DB)), then prefer DB. 355 2.5. Deprecation of site-local unicast address 357 RFC3484 contains a few "site-local unicast" and "fec::" description. 358 It's better to remove examples related to site-local unicast address, 359 or change examples to use ULA. Possible points to be re-written are 360 below. 361 - 2nd paragraph in RFC 3484 Section 3.1 describes scope comparison 362 mechanism. 363 - RFC 3484 Section 10 contains examples for site-local address. 365 2.6. Private IPv4 address scope 367 As detailed in Remi's draft [I-D.denis-v6ops-nat-addrsel], when a 368 host is in NATed site, and has a private IPv4 address and 369 transitional addresses like 6to4 and Teredo, the host chooses 370 transitional IPv6 address to access most of the dual-stack servers. 372 This is because private IPv4 address is defined to be site-local 373 scope, and as in RFC 3484, the scope matching rules (Rule 2) set 374 lower priority for private IPv4 address. 376 By changing the address scope of private IPv4 address to global, this 377 problem can be solved. Considering the widely deployed NAT with IPv4 378 private address model, this change works in most of the cases. If 379 not, this behavior can be overridden by configuring policy table, or 380 by configuring routing table on a host. 382 Moreover, some modern OSs have already implemented this change. 384 3. Conclusion 386 This document lists several issues that should be included in the 387 revision of RFC 3484, which are useful universally and do no harm in 388 reasonable network environments. 390 As the deployment of IPv6 progresses, the role of the address 391 selection mechanism is getting more important. This situation 392 revealed several important issues about the current address selection 393 rules. 395 It is much anticipated to provide the solutions for these issues. 396 Part of them, which are common issues for most of the reasonable 397 environment, should be done by updating the default address selection 398 rules as stated in this document, and the lest of them should be done 399 on per site basis by configuring the policy table manually, or using 400 the proposed policy updating mechanism. 402 4. Security Considerations 404 No security risk is found that degrades RFC 3484. 406 5. IANA Considerations 408 Address type number for the policy table may have to be assigned by 409 IANA. 411 6. References 413 6.1. Normative References 415 [I-D.denis-v6ops-nat-addrsel] 416 Denis-Courmont, R., "Problems with IPv6 source address 417 selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 418 (work in progress), February 2009. 420 [I-D.ietf-ipv6-ula-central] 421 Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast 422 Addresses", draft-ietf-ipv6-ula-central-02 (work in 423 progress), June 2007. 425 [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, 426 April 1995. 428 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 429 E. Lear, "Address Allocation for Private Internets", 430 BCP 5, RFC 1918, February 1996. 432 [RFC3484] Draves, R., "Default Address Selection for Internet 433 Protocol version 6 (IPv6)", RFC 3484, February 2003. 435 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 436 Allocation) Phaseout", RFC 3701, March 2004. 438 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 439 Addresses", RFC 3879, September 2004. 441 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 442 Addresses", RFC 4193, October 2005. 444 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 445 Architecture", RFC 4291, February 2006. 447 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 448 Network Address Translations (NATs)", RFC 4380, 449 February 2006. 451 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 452 "Problem Statement for Default Address Selection in Multi- 453 Prefix Environments: Operational Issues of RFC 3484 454 Default Rules", RFC 5220, July 2008. 456 6.2. Informative References 458 [I-D.chown-addr-select-considerations] 459 Chown, T., "Considerations for IPv6 Address Selection 460 Policy Changes", draft-chown-addr-select-considerations-03 461 (work in progress), July 2009. 463 [I-D.fujisaki-dhc-addr-select-opt] 464 Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing 465 Address Selection Policy using DHCPv6", 466 draft-fujisaki-dhc-addr-select-opt-09 (work in progress), 467 March 2010. 469 Appendix A. Acknowledgements 471 Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- 472 Courmont and the members of 6man's address selection design team for 473 their invaluable inputs. 475 Appendix B. Revision History 477 00: 478 Published as a 6man working group item. 480 03: 481 Added acknowledgements. 482 Added longest matching algorithm malfunction regarding local DNS 483 round robin. 484 The proposed changes section was re-structured. 485 The issue of 6to4/Teredo and IPv4 prioritization was included. 486 The issue of deprecated addresses was added. 487 The renewed default policy table was changed accordingly. 489 02: 490 Added the reference to address selection design team's proposal. 492 01: 493 The issue of private IPv4 address scope was added. 494 The issue of ULA address scope was added. 495 Discussion of longest matching rule was expanded. 497 Authors' Addresses 499 Arifumi Matsumoto 500 NTT SI Lab 501 Midori-Cho 3-9-11 502 Musashino-shi, Tokyo 180-8585 503 Japan 505 Phone: +81 422 59 3334 506 Email: arifumi@nttv6.net 508 Jun-ya Kato 509 NTT SI Lab 510 Midori-Cho 3-9-11 511 Musashino-shi, Tokyo 180-8585 512 Japan 514 Phone: +81 422 59 2939 515 Email: kato@syce.net 517 Tomohiro Fujisaki 518 NTT PF Lab 519 Midori-Cho 3-9-11 520 Musashino-shi, Tokyo 180-8585 521 Japan 523 Phone: +81 422 59 7351 524 Email: fujisaki@syce.net