A straightforward transition plan (was: Re: V6 still not supported)

Thu Mar 31 09:03:42 UTC 2022

Hi Mark and all:

Indeed, we have a plethora of IPv4 encapsulation and 4-to-6 techniques. 

I read somewhere down the threads that we (at IETF) made a "stupendously" bad bet thinking that IPv6 would be generalized quickly thanks to those techniques.

Being partially guilty of that (e.g., but not limited to, USPTO 7,443,880 filed in 2004 that became 464XLAT), I can see that the 4-to-6 step involving CG NATs and all was a too big step to be taken. It's not a step, it's a 100m jump. 

Looking at it from a distance, I came to challenge that it is even a requirement to the transition plan. If we look at it, a stack that is not capable of IPv6 is now a legacy stack. It's ultimate goal is probably to connect a legacy IPv4 client application to a legacy IPv4 server and it will not need anything more in its whole life. For that use case, both app and server can live forever as they are, as far as the plan is concerned, provided that we continue to give them a 464XLAT or a DSlite tunnel, which is not that hard if the numbers are counted.

If we accept that connecting that legacy device with any future IPv6-only application is effectively a non-goal, then we open the thought process to a migration that takes several baby steps, each step easy to make, as opposed to the large one that proved unfeasible in 20 years. 

Instead, what we really want for this plan is to design feasible baby steps, each representing connectivity between a level of evolution and the next, BUT NOT attempting to provide connectivity between the first level (legacy IPv4 only app) and the ultimate level (IPv6-only networks and servers). Something like  1<->2<->..<->N as opposed to 1<->N which proved unfeasible.

My view of the steps we'd need to make:

- extend the size of public IPv4 addressable realms. I read the ask in many threads in this list
- extend that to some IPv6-only end-points leveraging the above
- extend that to generic IPv6

With design constraints that make this deployable:

- allow IPv4-only network domains
- allow IPv6-only network domains  
- use stateless NATs only
- allow the NAT to be anywhere from bump in the stack to X-only realm borders

Does this seem desirable to you?

If so, yes, we can make that happen. Then we'll see how the IPvx domains play GO together, based on real usefulness vs cost.

Pascal

> -----Original Message-----
> From: NANOG <nanog-bounces+pthubert=cisco.com at nanog.org> On Behalf Of Mark
> Andrews
> Sent: jeudi 31 mars 2022 1:32
> To: NANOG <nanog at nanog.org>
> Subject: Re: A straightforward transition plan (was: Re: V6 still not
> supported)
> 
> 
> 
> > On 26 Mar 2022, at 21:51, Philip Homburg <pch-nanog-2 at u-1.phicoh.com>
> wrote:
> >
> >>> If there is a magical transition technology that allows an IPv6-only
> >>> host t
> >> o
> >>> talk to an IPv4-only host, then let's deploy it.
> >>
> >> DNS64/NAT64, DS-Lite, 6rd, 464XLAT, MAP-T, MAP-E, ? pick a transition
> >> protocol and see what happens!  (with more coming every year...)
> >
> > The problem with these is that they are not full solutions. That's why
> > we get new ones every year: everybody picks the subset of the problem
> > they want solve.
> >
> > To go over the ones you listed:
> > - 6rd. That's the odd one out here. 6rd privdes IPv6 over an IPv4
> > infrastructure. Very useful when there was not a lot of IPv6 native.
> > Not a good approach for organisations that lack IPv4 addresses. Also
> > not a good approach if you want to switch off IPv4 at some point.
> > - DS-Lite, MAP-T, MAP-E. Good for connecting CPEs to IPv4aaS over an
> > IPv6-only backbone. Downstream from the CPE is dual stack. For this
> > reason those protocols do not see much use outside ISP networks. Got a
> > great transition technology because hosts will keep IPv4 until the
> > last IPv4 on the internet is gone. It is a bit of an IETF failure that
> > we have so many ways to connect a CPE to IPv4aaS.
> > - NAT64/DNS64. This is the closest to an actual transition technology.
> > Unfortunately it is completely flawed in too many ways.
> > - 464XLAT fixes many issues with NAT64/DNS64. The downside is again
> > that hosts have to have an IPv4 stack until forever and in addition to
> > that a complex IPv4-to-IPv6 translation module. That fails the
> > requirement that an IPv6 stack should have roughly the same complexity
> > as IPv4 and talk to IPv4-only.
> >
> > Basically, there is no solution to the transition problem. There are
> > lots of partial solutions, each with their own advantages and
> disadvantages.
> >
> > If we could go back in time, then developing NAT64 along with IPv6 and
> > making sure the translation really works including edge cases like
> > IPv4 literals, DNS A records, NAT traversal, etc. would have made a
> > difference.
> >
> > I don't know if such translation gateways were considered, I can't
> > recall much discussion about them. By the time the IPv6 socket API was
> > created it was already too late to get things like IPv4 literals right.
> 
> DS-Lite was designed to be implemented in the node.  You can run IPv6-only
> everywhere in your network.  It is simple IPv4 in IPv6 encapsulation.  There
> was a DHCPv6 option to tell the node how to configure the remote IPv6 tunnel
> end point and everything else had defaults.  You could implement this in
> stack that only presented IPv6 to the application using IPv4 mapped address.
> You use getaddrinfo with AI_V4MAPPED set for domain names and address
> literals which should preference IPv6 over mapped IPv4 moving the traffic to
> IPv6.  Yes, you still have a stub IPv4 implementation.  All this was
> available before DNS64/NAT64, MAP-E, MAP-T, and 464XLAT.
> 
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org