Message-ID: <546B4FF8.9070205@network-heretics.com>
Date: Tue, 18 Nov 2014 08:56:08 -0500
From: Keith Moore <moore@network-heretics.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: v6ops@ietf.org
References: <20141117212302.4DCB6238B1B6@rock.dv.isc.org>
 <506DB2D3-F2E2-4437-B2CB-2DB9000F548A@cisco.com>
 <546A7432.4090206@network-heretics.com>
 <5DDF2696-C2A3-447D-85FA-05C4A2BB8C29@employees.org>
 <546A9538.5040208@gmail.com> <546AA2E9.3080904@network-heretics.com>
 <546ADDB9.8030509@dougbarton.us> <546AEF92.8050103@network-heretics.com>
 <20141118105218.GI28745@Space.Net> <546B4792.6050900@network-heretics.com>
 <20141118132824.GU28745@Space.Net>
In-Reply-To: <20141118132824.GU28745@Space.Net>
Content-Type: multipart/alternative;
 boundary="------------010908040304050803080304"
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/tNpixrrBFGEcgdfHHwD7JNzqjh8
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
Precedence: list

This is a multi-part message in MIME format.
--------------010908040304050803080304
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------010908040304050803080304
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 11/18/2014 08:28 AM, Gert Doering
      wrote:<br>
    </div>
    <blockquote cite="mid:20141118132824.GU28745@Space.Net" type="cite">
      <pre wrap="">Hi,

On Tue, Nov 18, 2014 at 08:20:18AM -0500, Keith Moore wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 11/18/2014 05:52 AM, Gert Doering wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">On Tue, Nov 18, 2014 at 02:04:50AM -0500, Keith Moore wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">Also, 6to4 hasn't hurt more people than it helped.
</pre>
          </blockquote>
          <pre wrap="">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.
</pre>
        </blockquote>
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
The measurements quite clearly demonstrate that anycasted 6to4 works
*less* well than native IPv4.  This is not assuming IPv4 works 100%.</pre>
    </blockquote>
    That's not a valid basis for comparison, for several reasons:<br>
    <ul>
      <li>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.<br>
      </li>
      <li>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.</li>
      <li>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.<br>
      </li>
    </ul>
    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.)<br>
    <br>
    <blockquote cite="mid:20141118132824.GU28745@Space.Net" type="cite">
      <pre wrap="">

[..]
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">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?
</pre>
        </blockquote>
        <pre wrap="">
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.   
</pre>
      </blockquote>
      <pre wrap="">
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 </pre>
    </blockquote>
    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.<br>
    <br>
    <blockquote cite="mid:20141118132824.GU28745@Space.Net" type="cite">
      <pre wrap="">(actually, CGN should help avoid anycast 6to4 brokenness,
as nodes won't fire up 6to4 if they have no public IPv4 address at all).</pre>
    </blockquote>
    <br>
    Except that CGN doesn't tend to use RFC 1918 addresses, so existing
    6to4 implementations won't know to disable 6to4 in those conditions.<br>
    <br>
    <blockquote cite="mid:20141118132824.GU28745@Space.Net" type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">But if we're going to cast blame, 
let's put the blame where it belongs.
</pre>
      </blockquote>
      <pre wrap="">
The blame belongs to a non-workable deployment model for relays - someone
pays, someone else benefits. </pre>
    </blockquote>
    <br>
    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.<br>
    <br>
    Keith<br>
    <br>
  </body>
</html>

--------------010908040304050803080304--