To be fair - I don't think anyone is saying "We should totally encourage 6to4!", even in the short-term ... or any other auto-tunneling transition mechanism, really.
In fact, I think the debate here largely stems from a valid desire to discourage 6to4. Note: That goal, I am in favor of (recommending that 6to4 be disabled by default on client platforms). However, the proposals on the table seek to reclassify 6to4 as historic - something that has raised a noticeable amount of debate about 1) what historic really means and/or 2) what impact that re-classification may have on currently-functional 6to4 usage today. /TJ ... who wishes to note that 6to4 works *just fine* ... except when it doesn't. PS - And in those cases, proper address selection is a much better solution (IMHO) than hitting this screw with a hammer. On Wed, Jul 27, 2011 at 23:15, Brzozowski, John < [email protected]> wrote: > From an operators point of view, specifically one that has deployed 6to4 > relays, use of the same should not be encouraged. > > I fully hope and expect the use of 6to4 to systematically decrease over > time so the associated infrastructure can be decommissioned. > > While we have seen issues related to 6to4 decrease recently the deployment > of the same over the years, in particular open relays, has grossly > complicated deploying 6to4 in a reliable manner. > > I have not been able to keep up with all the emails and threads related to > this topic, I apologize for this. > > The bottom line from my point of view is that we (the IETF) should do > something to discourage the use of the same. > > John > ========================================= > John Jason Brzozowski > Comcast Cable > e) mailto:[email protected] > o) 609-377-6594 > m) 484-962-0060 > w) http://www.comcast6.net > ========================================= > > > > > On 7/27/11 2:18 PM, "Keith Moore" <[email protected]> wrote: > > >On Jul 27, 2011, at 3:32 AM, t.petch wrote: > > > > > >I oppose this action. > > > >I see clear evidence that 6to4 is damaging the Internet and although > >there are > >those who can use it without causing damage, I believe that the principle > >is > >'First, do no harm' > >so the IETF has a responsibility to discourage its use. [...] > > > > > > > > > > > >I'd like to address the point that "6to4 damages the Internet". > > > >I do understand the content providers' argument - if 6to4 is turned on at > >the originator's host or network, the destination is advertising both A > >and AAAA records, and the AAAA record is chosen in preference to the A > >record, the user's experience is degraded. Sometimes the performance is > >degraded marginally (but the cumulative effect of lots of small delays on > >a web page that loads dozens of images is large). Sometimes it's > >degraded significantly because the 6to4 address doesn't work at all. Both > >cases matter, and they do provide a disincentive to content providers to > >just slap AAAA records onto their sites and be done with it. (There are > >other ways of a web site utilizing v6, but they require more work.) > > > >A lot of the arguments that I hear about 6to4 being "bad" in a universal > >sense seem to be based on the assumption that it's only access to > >"content" in the public Internet that matters. But anyone who has > >followed IPv6 development should know better than that. If access to > >"content" in the public Internet were all that mattered, there would have > >been no interest in ULAs. It remains the case that many enterprise > >networks have all kinds of "internal" resources that are useful to them > >even if they're not publicly addressable, and are only usable from within > >that network or from other networks with which they have made explicit > >arrangements. > > > >For better or worse, an explicit design "feature" of IPv6 is that hosts > >can have multiple addresses, and that different addresses might be needed > >in different contexts. A host's public address might be used when > >contacting a public web server, but when communicating within an > >enterprise network or between networks each using ULA space, the host > >might need to use its ULA address as a source address (the other host > >might not have a public address or the ability to send traffic to the > >public IPv6 network). > > > >I put the word "feature" in quotes because this can be a pain in the a** > >for applications and users. The default address selection rules don't > >really handle this case very well, nor can any set of static default > >rules handle this case. Essentially what having multiple addresses per > >host implies is that hosts or applications need to do routing in the > >absence of routing information. It shouldn't surprise anybody that the > >use of addresses that only work well (or at all) within a limited scope > >creates situations where a host will try to send traffic down a path that > >will never get it there, even when a different path would have worked. > > > >Introducing IPv6 - any kind of IPv6 - into a world of hosts that already > >support IPv4, creates exactly this situation. > > > >Nothing in IPv4 prohibited hosts from having multiple addresses and from > >advertising multiple addresses in DNS. But this "feature" was rarely > >used, except in cases where all of the addresses were approximately > >equivalent in performance, because it didn't work well if some addresses > >performed better than others. Then, as now, hosts and applications had > >no good way of reliably choosing which source and destination address to > >use. But unlike IPv4, IPv6 deliberately chose to not only support the > >ability to have multiple addresses per host, but to actually expect it in > >a number of cases. > > > >One way to look at the content providers' complaint against 6to4, is that > >6to4 addresses are not "approximately equivalent in performance" to IPv4 > >addresses. So when hosts or applications happen to choose the 6to4 > >address over an IPv4 address for the same resource, sometimes that choice > >ends up not working, or being suboptimal. This is nothing new with 6to4. > > It's inherently the case that having multiple addresses for a host that > >aren't equivalent in performance leads to suboptimal choices in some > >cases. > > > >So essentially, the argument that "6to4 damages the Internet", is > >tantamount to "having multiple addresses for hosts damages the Internet". > > > >And this is an explicitly chosen architectural "feature" of IPv6. > >Blaming 6to4 for the problems caused by this "feature" is like blaming > >the canary carried by a coal miner for ceasing to chirp. > > > >(Though as it turns out, in the case of 6to4 the fix is relatively easy - > >just make 6to4 lower preference than either IPv4 or native IPv6 addresses > >except when the source and destination are both 6to4. ) > > > >-- > > > >People who are entirely engaged in providing content may have a hard time > >seeing any utility in 6to4. They may ask, "if it doesn't deliver > >content as well as IPv4 does, what good is it?". My answer to that > >question is, "what good are private networks and ULAs? " > > > >6to4 as defined by RFC 3056 is a bit like a ULA. It provides a way for > >individual hosts that have a public IPv4 address, and hosts on small > >networks that have a public IPv4 address, to be able to interchange IPv6 > >traffic. True, it doesn't work through NAT, but it can be used as a way > >to provide IPv6 service within the 6to4 realm. This lets users leverage > >the IPv6 protocol and IPv6 aware applications to get useful things done, > >that they would not have been able to do using IPv4. Personally, I've > >found 6to4 useful to let me log into my home machines remotely, to > >remotely access file systems, to print to my home printer from work and > >my work printer from home, and a number of other things - all without > >making any application-specific arrangements. For years I've heard from > >and read about other people using 6to4 in similar ways. > > > >The mechanism defined in RFC 3068 takes a step down the slippery slope of > >trying to make 6to4 into a means to access the public IPv6 Internet (and > >vice versa). Because it was designed in an era where managed, supported > >IPv6 service was not widely available, it necessarily relies on the good > >will of people willing to provide relay routers. And relying on the good > >will of those people comes with, or should come with, decreased > >expectations. Note, however that we're still in the era where managed, > >supported IPv6 service is not widely available. As long as we're in that > >era, and as long as native v4 access is available to some users, any > >statements to the effect that 6to4 is evil, obsolete, historic, etc., > >even for the purposes of accessing the public v6 internet, are premature. > > (But if you want to say that it's not reliable for this purpose, that's > >a defensible statement.) > > > >The problem is that ordinary users don't know that they should have > >decreased expectations. They might not even be aware that they're using > >6to4, or relying on the good will of others. > > > >Keith > > > > > > > >_______________________________________________ > >Ietf mailing list > >[email protected] > >https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf >
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
