Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt

[Keith Moore <[e-mail]>]

On 12/13/2014 03:08 PM, Brian E Carpenter wrote:
> Section 1:
>     There would appear to be little evidence of substantial active use of
>     the original form of 6to4 described in [RFC3056].
>
> This statement is unsupported,
> Well, proving a negative is always hard. I personally have seen no
> evidence of any usage whatsoever of the pure RFC 3056 mechanism.

I've certainly used it, I think before RFC 3056 was even published.   
Before NAT became commonplace, it was a great way to facilitate remote 
access to my hosts at home.   Even after NAT became the norm while 
roaming, it was useful to communicate between individual hosts residing 
on networks that each had 6to4-capable routers.   Of course, that's not 
evidence of substantial use.

I think it would be hard to establish evidence of substantial use (or 
lack thereof), because that would require measurement of not only the 
number of IPv4 protocol 41 packets, but also the number of such packets 
where both source and destination IPv6 addresses in the IPv4 payload had 
2002: prefixes.   And you'd need to measure it at several well-chosen 
and geographically dispersed points to have confidence in the conclusion.
> I used my contacts in the IP trace collecting world to see if any
> trace files from ISPs or IXPs are available that would allow 6to4
> usage to be measured, and failed. I have also never seen any
> information suggesting the existence of the type of operator
> agreements needed for routing according to sections 5.2.2.1 or
> 5.2.2.2 of RFC 3056.
>
>> and I believe, superfluous.
> That's defensible. But some kind of introductory sentence is needed.
> Any suggestion?

My understanding is that the things that motivated writing this document 
were that:
(a) anycast 6to4 was observed to be often unreliable, and
(b) this had the effect of discouraging deployment of IPv6 access to 
services already accessible via IPv4, and perhaps discouraging user 
acceptance of IPv6 in general.
Something along those lines seems like an appropriate introduction to 
this document.


>
>>
>>     [RFC6343] analyses the known operational issues in detail and
>>     describes a set of suggestions to improve 6to4 reliability, given the
>>     widespread presence of hosts and customer premises equipment that
>>     support it.  However, experience shows that operational failures have
>>     continued despite this advice being available.  Fortunately the
>>     advice to disable 6to4 by default has been widely adopted in recent
>>     operating systems, and the failure modes have been largely hidden
>>     from users by many browsers adopting the "Happy Eyeballs" approach
>>     [RFC6555].  Nevertheless, a substantial amount of 6to4 traffic is
>>     still observed and the operational problems caused by 6to4 still
>>     occur.
>>
>>     Although facts are hard to obtain, the remaining successful users of
>>     anycast 6to4 are likely to be on hosts using the obsolete policy
>>     table [RFC3484] (which prefers 6to4 above IPv4), without Happy
>>     Eyeballs, with a route to an operational anycast relay, and accessing
>>     sites that have a route to an operational return relay.
>>> Taken together these statements seem confusing at best.
> Well, it's a matter of judgment of course, but I disagree. I don't see
> any confusion.
>
>> Here's my attempt to sort things out:
>>> Measures that have been taken in the past (recommending disabling 6to4 by default, use of happy eyeballs) have had some useful effect.
>>> However some hosts are still observed (again, without any reference to the observations) to use 6to4
> We have observations from a couple of sources (Google, which
> whether you like it or not, sees traffic from a very large
> proportion of ordinary users, and Geoff Huston's work, which
> obviously sees a much more restricted cross-section of users).
> It's above my pay grade to decide, but this document doesn't seem
> like the place for a detailed report on those observations.

I am presuming that Google most sees traffic exchanged with Google's 
servers, which are mostly accessible via either IPv4 and IPv6. That's 
just one kind of use of 6to4, it's not an indication of overall 
"success" using anycast 6to4.

Again, the justification / use case for 6to4 isn't to facilitate 
communication that could just as easily be done using IPv4, it is to 
facilitate communication that could not be done using IPv4, or for which 
using IPv4 would be suboptimal in some way.   So if we're trying to 
measure "success" of 6to4, what needs to be measured is communications 
between peers that don't both have IPv4 addresses, and/or communications 
that would be adversely affected by v4 NAT. HTTP and SMTP aren't 
examples of that kind of traffic.

(Google might be in a good position to see how well 6to4 works with 
webrtc, but that would have to be done by looking at things like how 
often a webrtc connection "fell back" to a STUN/TURN path when there was 
a v6 path available using 6to4 on one or both ends.  )

>
>> Presumably the hosts that are still having operational problems are those that have, for whatever reason, failed to implement those measures (perhaps because they are running obsolete code, perhaps because they are behind routers that implement 6to4).
> Undoubtedly. I'm big-headed enough to believe that if RFC 6343 had
> been universally and completely implemented, there would be no more
> problems ;-). But we know, for example, that ~10% of the Windows market
> is still Windows XP, which means RFC 3484.

Aside: it's really unfortunate that updating old versions of several 
operating systems often cannot be done without one or more of of: 
hardware upgrade, significant service disruption, significant harm to 
usability, user training, admin training, changes in administrative 
procedures, and sometimes tremendous expense due to the need to qualify 
the new hardware/software combination in certain environments (e.g. 
medical, aviation).   There needs to be a way to fix serious defects, 
with minimal disruption, even in older software.   Obviously IETF can't 
fix this, but IETF might actually be able to have some influence over 
this.   (end of rant)

>
>>> Much of the latter paragraph seems completely unsupportable.   The RFC3484 prefix selection table doesn't affect address selection for applications requiring or deliberately preferring IPv6 (say to circumvent NAT) and having only a single IPv6 address.
> No. It affects ordinary users with ordinary applications.

There's a widespread, strong, and unfortunate tendency to think that 
"ordinary users with ordinary applications" means pretty much web and 
email, or only client-server apps where the servers are in the "cloud", 
and I don't think that's valid at all.  Ordinary users play distributed 
games, chat, use audio and video telephony, exchange files in various 
ways, all of which benefit from availability of direct peer-to-peer 
communications between users' hosts.   Ordinary users install arbitrary 
apps, with a broad spectrum of uses and communications patterns, on 
their computers and phones.    Moreover, the Internet isn't supposed to 
be only a client-server network.   It is designed to allow arbitrary 
hosts to exchange data with other arbitrary hosts, and we need to defend 
the Internet architecture from attempts to characterize it as, or 
constrain it to be, client-server.

There's also the problem that we've suffered through use of a 
NAT-impaired IPv4 network for so long that we've come to accept as 
"ordinary" applications that suffer from NAT-impairment.   But we 
shouldn't be assuming that IPv6 usage patterns will resemble what is 
"normal" in the NATted IPv4 world.

>
>> (Perhaps the authors are under the impression that the only hosts anyone wishes to communicate with using anycast 6to4 are those which also have IPv4 addresses, or the only apps using IPv6 are those which could work equally well through IPv4 NAT?)
> I am under that impression as far as the large majority of users goes, yes.

Obviously, I do not share that impression.
>
>> Happy Eyeballs isn't generally applicable to all applications using IPv6, and even when it's useful only helps if there are multiple source/destination address pairs from which to choose.   Again, it's not correct to assume that either end of traffic using 6to4 has an IPv4 address that would work better for that application.
> I only make that assumption for the large majority of users, who do
> most things through an HTTP browser.

The Internet doesn't just exist to support HTTP, or client-server apps.  
And relative traffic measurements are not a good proxy for the 
importance of particular applications or protocols.

>
>> Just to pick one example, I've seen bittorrent use IPv6 addresses, including 6to4 addresses, when doing so would circumvent NAT brain-damage.
> Definitely. That's the largest known use case for peer-to-peer 6to4.
> afaik, the draft does nothing to damage that use case.

You might notice that I didn't actually object to any of the specific 
recommendations made in the current draft, just to the way that the 
situation with 6to4 is characterized.

>
>>     IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969]
>>     explicitly builds on the 6to4 mechanism, and could be viewed as a
>>     superset of 6to4, using a service provider prefix instead of
>>     2002::/16.  However, the deployment model is based on service povider
>>     support, such that 6rd can avoid the problems described here.  In
>>     this sense, 6rd can be viewed as superseding 6to4 as described in
>>     section 4.2.4 of [RFC2026].
>>   
>> While 6rd is indeed useful, and it seems like a good solution for access providers wishing to provide their customers with an interim IPv6 solution until they deploy native IPv6, it is  misleading to call it a "superset" of 6to4 or to claim that it supersedes it.  6rd would be better described as a subset, since it's potentially applicable in fewer situations than 6to4 is.   Or perhaps it would be better to say that 6rd and 6to4 have different use cases.   In particular, 6rd doesn't provide any help to a user needing to reach IPv6 hosts if the ISP to which he's currently connected doesn't support it.
> I agree that the word "superset" is slightly off target. But it is an
> objective fact that 6rd builds on 6to4; I could root out early email
> from 6rd's designer to justify that.

No argument there.

>
> The 6rd use case is (and always has been) to get the benefits of 6to4
> without the problems, by relying on ISP support. However, I also
> agree that the last sentence "In this sense..." is a bit OTT.
I just think that this paragraph inaccurately conveys the notion that 
6rd is an adequate substitute/replacement for all uses of 6to4, when 
it's not.   However, 6rd is generally a good substitute/replacement for 
6to4 for users whose ISP is providing the 6rd service *, and I have no 
problem with this document saying that.

* presuming that the hardware that they supply to customers actually 
supports that service, unlike one of my current ISPs.

>
>>> Recommendation: delete the paragraph.  6rd is irrelevant to this document.
>>>
>>>     Given that native IPv6 support and various reliable transition
>>>     mechanisms are now becoming common, the IETF sees no evolutionary
>>>     future for the 6to4 mechanism.
>>>
>>> Whether native IPv4 support or reliable transition mechanisms are "becoming common" depends on your definition of "common", but we're still a long way from a point where such mechanisms are generally available and applicable to ordinary users.   The main reason that there's no evolutionary future for the 6to4 mechanism is exhaustion of IPv4 address space and widespread deployment of NAT including carrier-side NAT.    (The problems with use of anycast could be fixed if there were much to be gained by fixing them, but the inevitably-increasing use of carrier-side NAT means there's really no point in doing so.)   Also, the paragraph could be taken to mean that these "reliable transition mechanisms" are good substitutes for 6to4, when reality is that there is currently no good replacement for 6to4.
>>>
>>> Recommendation: reword to say "Given that due to exhaustion of IPv4 address space carrier-side NAT is now becoming common, the IETF sees no evolutionary future for the 6to4 mechanism"
> That's a judgment call. I'm like "shrug".

This sentence could give the reader the impression that there are 
commonly available replacements/substitutes available for 6to4, and 
that's simply not the case at the present time.

And why not place the blame where it belongs?   The main reason that 
6to4 isn't more widely applicable, and is not worth fixing, is that the 
IPv4 Internet has become so dysfunctional that you can't even count on 
it to carry packets intact from source to destination anymore.   We had 
an opportunity to facilitate a much easier transition to native v6, and 
we blew it by not insisting that all v4 NATs (especially carrier-side 
NATs) support a well-engineered, standard, v6 transition mechanism.

>
>>> Section 3:
>>>
>>>                            With the increased deployment of IPv6, the
>>>     mechanism has been shown to have a number of fundamental
>>>     shortcomings.
> I have an alternative proposal for all the bullet points. Just replace the
> whole list with this:
>
>   With the increased deployment of IPv6, the
>   mechanism has been shown to have a number of fundamental
>   shortcomings that are fully described in [RFC6343].

While I might quibble with the word "fully", overall that seems like a 
reasonable approach.  In general I find the RFC6343 discussion of 6to4 
issues more readable, more comprehensive, and more objective than those 
in 6to4-to-historic.    Not rehashing those issues in the context of 
this draft makes good sense to me.

Keith