Re: [v6ops] my recommendation re: 6to4

["Templin, Fred L" <[e-mail]>]

FWIW, AERO works fine over ip-proto-41 when UDP is not needed. It's just that there
are lots of places UDP can go that ip-proto-41 can't - and that is without even taking
NATs into account. (UDP can also be easier to work with in application-layer
implementations, but that is a different subject.)

Also, ip-proto-41 does have path MTU challenges. We all know that PMTUD is
unreliable, which means the tunnel ingress has to set a "safe" MTU - usually to
something on the order of 1480 or smaller. But, that is incongruent with all of the
hosts that have become conditioned to expect an MTU of at least 1500. On top
of that, if the tunnel fragments at the IPv4 layer even after setting a "safe" MTU
there can be real problems. Unfortunately, after many years of study I finally
have to agree that *IPv4* fragmentation is indeed harmful.

The transitive connectivity question is an interesting one, and it may depend on
specific use cases and deployment scenarios. In enterprise networks, for example,
if A can send a tunneled packet to B, and B can send a tunneled packet to C, it does
not necessarily follow that A can send a tunneled packet to C. Chances are good
that it will work, but the best course of action is to test the path, i.e., even if you
take an initial optimistic leap of faith that the direct path works.

Thanks - Fred
[e-mail]

> -----Original Message-----
> From: Owen DeLong [mailto:[e-mail]]
> Sent: Saturday, November 01, 2014 6:46 PM
> To: Iljitsch van Beijnum
> Cc: Templin, Fred L; [e-mail] WG; Keith Moore
> Subject: Re: [v6ops] my recommendation re: 6to4
> 
> 
> On Nov 1, 2014, at 02:06 , Iljitsch van Beijnum <[e-mail]> wrote:
> 
> > On 01 Nov 2014, at 0:07, Templin, Fred L <[e-mail]> wrote:
> >
> >> Just a couple of quick comments:
> >
> > Famous last words... Here are mine:
> >
> > I haven't followed the previous discussions, but what problem are we trying to solve, exactly?
> >
> > Yes, 6to4 has tons of issues. All the same, there are still people using it out there today, and I would hazard to guess that they don't
> have a better alternative. So why make life worse for them by going out of our way to kill 6to4?
> >
> > Implementations already prefer IPv4 over 6to4, so I don't think having 6to4 enabled causes too many problems these days anyway.
> >
> >>> 4.  However the above actions are labeled, they make it all the more obvious that the Internet community lacks an obvious,
> recommended, and generally-applicable IPv6-over-IPv4 tunneling mechanism that can be implemented in a host or router
> >
> >> Maybe, but it does  not necessarily need to be ip-proto-41 based.
> >
> > I'll go one step further and say it MUST NOT be protocol 41 based.
> 
> Why not? What's wrong with explicitly configured 6in4 tunnels? I'll grant they don't buy much vs. protocol 45 IPv6 in GRE/IPv4 tunnels,
> but there's a little less overhead and the mechanism is already defined, working, and in fairly wide implementation in various systems,
> routers, etc.
> 
> 
> >
> >> And, it need not be specific to IPv6-over-IPv4 - it would be much better to have a single mechanism that can support tunneling of
> IPvX-over-IPvY for any values of X and Y.
> >
> > Not so sure. If it's strictly IPv6-over-IPv4 there are many optimizations and simplifications that are possible.
> 
> That seems to argue for preserving 6in4 over protocol 41.
> 
> >
> > However, if we want to go down this path (and we should have done that 10 years ago, it could very well be too late now) I strongly
> suggest we do it right and start with requirements. Here are a few:
> >
> > - if at all possible, autoconfigure everything, if not, configuration should be limited to something no more complex than a
> username/password
> 
> APIs can accomplish this for 6in4, actually. It's not there yet, but there's no reason this couldn't be built on existing systems.
> http://tunnelbroker.net already does this for the "server-side" of the equation. Username/Password and basically point-click-tunnel.
> 
> > - must be reliable and predictable, so if A - B works and B - C works, A - C should also work 99.9% of the time
> 
> I would argue that is by and large the case with HE's protocol 41 tunnelbroker. Can you point to reasons you believe otherwise?
> 
> > - explicit reachability check, so traffic doesn't continue to be sent into a black hole
> 
> This would be a lovely addition, but I think it can be added either to the existing protocol 41 tunnels or on top of them.
> 
> For example, to some extent, my BGP over 6in4 tunnels have this feature for some interpretations of the request.
> 
> > - work through NAT
> > - work through CGN
> 
> Meh... There are tunnel mechanisms that achieve this, but they create unnecessary pain in other areas where these are not a factor.
> OTOH, I'm not sure there needs to be "one true tunneling mechanism". Requiring the additional overhead of UDP in all cases and
> STUN in general doesn't feel like a win in the cases where NAT traversal is not required.
> 
> > - automatically adapts to changing addresses
> 
> Harder problem to solve. I could, however, do this today with some development work on an HE tunnel.
> 
> > - low overhead in gateways (preferably completely stateless)
> 
> 6in4 already meets this requirement.
> 
> > - can be terminated on a home gateway or on a host
> 
> 6in4 already meets this requirement.
> 
> > - doesn't require ISP cooperation
> 
> Since all packet forwarding requires some level of ISP cooperation, I think you need to be a little more clear about your meaning here.
> If you think this eliminates 6in4 because some ISPs are obnoxious enough to block protocol 41, then I would suggest there is a
> reasonable likelihood that said ISPs will block whatever they have to in order to block IPv6 tunneling for the same reasons they
> blocked protocol 41.
> 
> If you mean something else, then please explicate.
> 
> > - traffic flows are reasonably optimized (i.e., if ISP offers gateway service, by default, that gateway is used)
> 
> This requires some form of service discovery mechanism that can somehow be aware of what ISP you are using or otherwise has
> some mechanism for automatically interfacing with said ISPs provisioning. In the tradition of rough consensus and running code, it
> would be great if you put forward your vision for how this would work.
> 
> > As I read this, I'm pretty sure that some of the existing tunnel broker stuff that works over UDP today already does pretty much all
> of this as far as the actual tunneling goes. What would be needed is more streamlined signup and setup processes.
> 
> I think that could be achieved as an API on top of what exists. However, see my above comments as to why I don't think that should
> be the only available solution and I definitely think that deprecation of configured 6in4 tunnels would be very premature and
> somewhat harmful in general.
> 
> > Perhaps it could look like this: as a user, you either automatically get an account using your existing email / cloud service credentials,
> or you sign up for a separate account, like [e-mail]. You enter your username and password into the home
> gateways and hosts that you want to have tunneled IPv6 connectivity.
> 
> It's not UDP based, but FWIW there is an API to the HE tunnelbroker that was designed to allow home gateway implementers to do
> essentially just that through the web API on their gateways.
> 
> > The router or host, when it notices that there is no native IPv6, connects to _tunserv._tcp.<domain> or something like that and
> authenticates. The setup server then does a lookup of the source IPv4 address and redirects to a gateway serving that address range.
> Ideally, that would be the ISP providing service for those addresses. Or a public gateway that has good connectivity to those
> addresses. (There would be communication between the gateway and setup server operators to avoid lame delegations. And
> perhaps the setup server returns multiple delegations so if one gateway doesn't work the client tries the next one.)
> 
> This assumes a tremendous amount of cooperation and coordination not in evidence. Who runs this central "setup server" service?
> Why? How is it paid for?
> 
> > The router or host then talks to that gateway to obtain a prefix and other configuration info and sets up the tunnel. The host or
> home gateway is then responsible for keeping NAT mappings open and reconnecting when connectivity goes away for some reason.
> >
> > I guess it would be possible for devices to log in using their MAC address by default. Not sure how much authentication we really
> need for this. An account would still be better because that way any errors could be communicated through email. And logging in
> using a known service means the user's activities aren't exposed to additional parties.
> 
> There's also the issue that MAC addresses are only guaranteed to be segment unique. There are many cases where they are _NOT_
> globally unique.
> 
> Owen