Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

[Keith Moore <[e-mail]>]

On 11/18/2014 08:28 AM, Gert Doering wrote:
> Hi,
>
> On Tue, Nov 18, 2014 at 08:20:18AM -0500, Keith Moore wrote:
>> On 11/18/2014 05:52 AM, Gert Doering wrote:
>>> On Tue, Nov 18, 2014 at 02:04:50AM -0500, Keith Moore wrote:
>>>> Also, 6to4 hasn't hurt more people than it helped.
>>> Now *that* is a very bold statement, which (for the anycast relay 6to4)
>>> really contradicts existing measurements.  But of course with an
>>> adequate definition of "hurt" and "help", anything can be true.
>> It doesn't contradict existing measurements, just how those measurements
>> are interpreted.   If you interpret those measurements according to an
>> assumption that the network is in all respects functioning correctly
>> except for 6to4, you'll conclude that 6to4 is the problem.   But that's
>> not a valid premise, as we know that the network is not functioning
>> correctly in a great many respects.
> The measurements quite clearly demonstrate that anycasted 6to4 works
> *less* well than native IPv4.  This is not assuming IPv4 works 100%.
That's not a valid basis for comparison, for several reasons:

  * Of course tunneling v6 over v4 performs worse than native v4, if for
    no other reason than increased packet overhead, lower MTU, and
    likely longer path links.   That was always a given. The problem
    wasn't that 6to4 performed worse than v4, it was that early address
    selection rules were designed with the false assumption that (any
    kind of) v6 would provide at least as good a service as v4.
  * The purpose of 6to4 was never to work better than native v4 (in
    these respects), the purpose was to provide v6 access to users
    without v6 access and to do so in a fashion that required minimal
    configuration.
  * For some definitions of "better", e.g. ability to support p2p
    traffic, tunneled v6 could indeed work better than NATted v4 even
    when both paths were available.

And of course there's still the problem of interpreting those data.   So 
when the measurements showed (for example) protocol 41 blocking, 
concluding that 6to4 was the problem was fairly arbitrary - it was at 
least as valid to conclude that the problem was protocol 41 blocking.   
(Of course broken relays, unfiltered advertisements to relays not 
willing to forward all traffic, and NATs, were also parts of the problem.)

>
> [..]
>>> But I'm sure you know that quite well, and the draft authors already
>>> agreed to not deprecate your RFC, so I wonder what you are argueing for?
>> Truth.   Or is truth out-of-scope?
>>
>> More precisely:   I accept that as a practical matter, 6to4 is doomed
>> because of the exhaustion of IPv4 address space and increasingly wide
>> deployment of carrier-side NAT.
> Actually, that might be the doom for peer-to-peer 6to4, but *that* is
> totally out of scope.  Anycast 6to4 was broken long before widespread
> CGN deployment
Widespread CGN deployment resulting from v4 address space exhaustion is 
the reason 6to4 cannot be fixed, but not the reason 6to4 didn't work 
well for users.

> (actually, CGN should help avoid anycast 6to4 brokenness,
> as nodes won't fire up 6to4 if they have no public IPv4 address at all).

Except that CGN doesn't tend to use RFC 1918 addresses, so existing 6to4 
implementations won't know to disable 6to4 in those conditions.

>
>> But if we're going to cast blame,
>> let's put the blame where it belongs.
> The blame belongs to a non-workable deployment model for relays - someone
> pays, someone else benefits.

That's certainly a contributing factor, and one worth documenting. And 
yet, on another level, the Internet already assumes this model, and it 
more-or-less works.   I think the problem is a bit more subtle than 
that: (a) difficulty in fault diagnosis and tracing when using an 
anycast address as a default route, and (b) the belief that, unlike 
ordinary IP service, 6to4 service was not something that operators not 
providing relays needed to concern themselves with.   Thus 6to4 was seen 
as a problem by operators, whereas providing IPv4 connectivity to other 
networks was seen as part of doing business, even though both relied on 
the "non-workable" cost recovery model.

Keith