Re: "6to4 damages the Internet" (was Re: draft-ietf-v6ops-6to4-to-histor

> 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:john_brzozowski(_at_)cable(_dot_)comcast(_dot_)com
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================




On 7/27/11 2:18 PM, "Keith Moore" <moore(_at_)network-heretics(_dot_)com> 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
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf