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

["Fred Baker (fred)" <[e-mail]>]

Begin forwarded message:

> From: Keith Moore <[e-mail]>
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
> Date: December 12, 2014 at 4:56:26 PM PST
> To: Brian E Carpenter <[e-mail]>
> Cc: "Fred Baker (fred)" <[e-mail]>, "[e-mail]" <[e-mail]>
> 
> 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, and I believe, superfluous.    Such a statement might be supportable via traffic measurements, depending on how the measurements were done.   But traffic measurements are often misinterpreted, and without a reference describing actual methods and results there's no way for the reader to assess the validity of the statement.   Whether it's a defensible statement also depends on what "substantial" means.    Anyway, the document would be stronger without it, as the document shouldn't really be about RFC 3056.
> 
> Recommendation: delete this sentence.
> 
>    [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.   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 and have operational problems doing so.   
> 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).   (Perhaps it is believed that publishing additional RFCs discouraging 6to4 use will help reduce those problems, as if somehow users will upgrade their systems and/or routers because we publish more RFCs.)
> 
> 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.  (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?)   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.  Just to pick one example, I've seen bittorrent use IPv6 addresses, including 6to4 addresses, when doing so would circumvent NAT brain-damage.
> 
> Of course successful use of 6to4 does require routes to working relays in both directions.
> 
> Recommendation: reword the former paragraph and (especially) delete the latter one.
> 
>    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.
> 
> 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"
> 
> Section 3:
> 
>                           With the increased deployment of IPv6, the
>    mechanism has been shown to have a number of fundamental
>    shortcomings.
> 
> Some of these shortcomings are not specifically shortcomings with 6to4, but rather shortcomings of original address selection rules (which incorrectly assumed that any v6 path would work at least as well as any v4 path), the Internet architecture itself (poor support for multihomed hosts which manifests in several ways and persists to this day) 
> 
>    o  Use of relays. 6to4 depends on an unknown third party to operate
>       the relays between the 6to4 cloud and the native IPv6 Internet.
> 
> I think this is redundant with the 3rd bullet, and the 3rd bullet states it better.
>    o  The placement of the relay can lead to increased latency, and in
>       the case the relay is overloaded, packet loss.
> 
> While this statement is true on its face, it's sort of meaningless or misleading.    It begs the question "increased latency as compared to what?"   6to4 actually did a fairly good job of finding nearby relays in both directions if they were available - often providing lower latency better than configured tunnels except those provided by one's own ISP.   
> 
> The real problem was with the original address prefix selection algorithm and its implicit assumption that any IPv6 path would be better than any IPv4 path.    If ISPs around the world had deployed native IPv6 15 years ago but initially with suboptimal routing, the same problem of decreased latency would have appeared due to hosts' blind preference of v6 over v4.   
> 
> For that matter, the intended purpose of 6to4 (or for that matter IPv6) never was to facilitate communications between hosts or application peers that could just as well use IPv4.
>    o  There is generally no customer relationship between the end-user
>       and the relay operator, or even a way for the end-user to know who
>       the relay operator is, so no support is possible.
> 
> Agreed.
>    o  A 6to4 relay for the reverse path and an anycast 6to4 relay used
>       for the forward path, are openly accessible, limited only by the
>       scope of routing. 6to4 relays can be used to anonymize traffic and
>       inject attacks into IPv6 that are very difficult to trace.
> 
> Two things: The first statement is true but as far as I can tell only half of it is relevant - the "reverse" (6->4) path relay doesn't permit anonymizing traffic as far as I can tell.  The "forward" (4->6) path relay permits anonymizing traffic if the relay doesn't check that the IPv4 source address on the inbound packet is consistent with the IPv6 source address on the inbound packet.   Otherwise, the degree of anonymizing possible is about the same as with NAT44 - the rest of the network can't tell which host the traffic came from but it can tell which network it came from.
> 
>    o  6to4 may silently discard traffic in the case where protocol (41)
>       is blocked in intermediate firewalls.  Even if a firewall sent an
>       ICMP message unreachable back, an IPv4 ICMP message rarely
>       contains enough of the original IPv6 packet so that it can be
>       relayed back to the IPv6 sender.  That makes this problem hard to
>       detect and react upon by the sender of the packet.
> 
> Well, of course it's not 6to4 discarding the traffic, it's the firewalls.   Place the blame where it belongs.   And these problems exist with protocol 41 tunnels in general, including 6rd tunnels, not just 6to4 tunnels.   (It seems especially odd for this document
> to be recommending 6rd as a replacement of sorts for 6to4 while at the same time
> citing 6to4 for shortcomings that are also present with 6rd.)
> 
> There are really two issues here:
> - "accidental" blocking of 6to4 by firewalls (i.e. because of naivete or misconfiguration rather than because of explicit policy)
> - hosts/apps not coping well with blocking of 6to4 by firewalls
> 
> Recommendation: separate into two bullets:
> 
> - 6to4 traffic was sometimes silently discarded by firewalls, either because they blocked
> protocol 41 indiscriminately, or because they blocked incoming traffic flows that weren't initiated by outgoing traffic flows, and were not configured to recognize outgoing flows over protocol 41.   Sometimes this blocking was deliberate, sometimes accidental due to underspecified configuration.
> 
> - Whether or not by accident, when encapsulated traffic was blocked by a IPv4-only firewall, an ICMPv4 response from the firewall was unlikely to be useful to the sender's IPv6 stack, and an IPv4-only firewall generally wouldn't know how to send ICMPv6 responses encapsulated in IPv4, to the sending host.   
> 
> 
> 
>    o  As 6to4 tunnels across the Internet, the IPv4 addresses used must
>       be globally reachable.  RFC 3056 states that a private address
>       [RFC1918] MUST NOT be used. 6to4 will not work in networks that
>       employ other addresses with limited topological span.  In
>       particular it will predictably fail in the case of double network
>       address translation (NAT444).
> 
> This bullet seems very muddy. 
> 
> "As 6to4 tunnels across the Internet"  should say "the IPv4 Internet".   The Internet isn't just IPv4.
> 
> The second sentence seems out of place.   It's not immediately clear what RFC 3056's statement about RFC 1918 addresses has to do with the argument that's being made.
> 
> - The general issue is that 6to4 doesn't work to provide IPv6 access to hosts or routers lacking a globally-scoped and globally-reachable IPv4 address.   This in combination with widespread use of NAT made 6to4 much less useful than it would otherwise have been, and is perhaps the biggest single problem with 6to4.
> 
> - A related problem was that it wasn't clear from the 6to4 specifications that hosts and routers supporting 6to4 needed a reliable way to detect that they had globally-scoped and globally-reachable IPv4 addresses.  RFC 1918 addresses were excluded by RFC 3056, but other unsuitable IPv4 addresses were not as easily recognized.   
> 
> - Some 6to4 implementations were once known to enable 6to4 by default for any non-RFC1918 address, having the effect of enabling a IPv6 address and interface that would never work, and (in the absence of modern address selection rules or happy eyeballs) causing traffic to be blackholed.   However this problem has largely been fixed.
> 
> As far as I can tell, the problem with double NAT is just one example of the general problem.   Even a single layer of NAT breaks 6to4.
> 
> Recommendation: reword the above bullet into two separate bullets, along the lines above.
> 
>