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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf