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

[Abraham Y. Chen]

Dear BZS:

1)   " ... it was more likely due to the success of CGNAT.":   Looking 
forward from this milestone marker, what would you envision as the 
possible additions to CG-NAT's characteristics and capabilities for the 
potential expansion of its services and enhancement to its performances?


Thanks,


Abe (2023-01-16 10:22)


On 2023-01-11 19:33, b...@theworld.com wrote:

On January 12, 2023 at 02:11n...@neo.co.tz  (Noah) wrote:
  > Hi John,
  >
  > So, It was assumed that IPv4 depletion would effectively lead to the 
adoption
  > of IPv6. This has not been the case in the last decade save for a very few
  > countries in the world.
  >
  > It was also assumed that IPv6 only networks would crop all over the place 
as a
  > result, providing the same interconnectivity benefits enjoyed by the IPv4
  > internet.
  >
  > Out of curiosity,did the emergency of transfer markets slow IPNG adoption 
while
  > creating prolonged dependence on IPv4?

Probably ten people have said this already but it was more likely due
to the success of CGNAT.




--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

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

[Masataka Ohta]

Pascal Thubert (pthubert) wrote:

Hi,


Solutions must first avoid broadcast as much as possible, because
there's also the cost of it.


Though I'm not saying all the broadcast must be repeated,
if you think moderate broadcast is costly, just say,
CATENET.

I remember old days when entire network of CERN with
thousands of hosts was managed to be a single Ethernet
several years after we learned dividing network by
routers can prevent various problems caused by broadcast.

It was, at least partly, because operating multi-protocol
routers is painful. Unlike most sites at that time, non
IP protocols such as DECnet was popular at CERN.

As IPv4 became dominant, problems went away.


Then you want zerotrust, ND is so easy to
attack from inside and even outside. This is RFC 8928.


As many people are saying zerotrust relying on PKI, which
blindly trust CAs as TPPs (trusted third parties), which
are confirmed-to-be-untrustworthy third parties by
Diginotar, zerotrust is not very meaningful beyond
marketing hype.

Anyway, relying on link broadcast implies that the link
is trusted to some extent, which is not ND specific.


Ethernet is enterprise networks is largely virtualized. We cannot
offer fast and reliable broadcast services on a worldwide overlay.


Unlike CERN in the past, today, I can see no point to have large
Ethernet, though some operators may be hyped to deploy expensive
service of telco for nothing.


Add to that the desire by the device to own more and more addresses.


What? How can it happen with IPv4?


You want a contract between that the host and the network that the
host owns an address and is reachable at that address. Like any
contract, that must be a negotiation. ND is not like that. RFC 8505
is exactly that.


Ignoring poor IPv6, I'm afraid it a property of not ARP but DHCP.


It may be more constructive to work for proxy ARP suitable for
Wifi, which may be enforced by Wifi alliance. An RFC may be
published if Wifi industry request IETF to do so.


This is effectively done already for ND.


I agree with you but my point is that it is more constructive for ARP.


I guess the design can be easily retrofitted to ARP. ND is really
designed exactly as ARP. The differences were for the show, the real
steps that should have been made were not. But now with RFC 8505 we
have a modern solution. The problem is no more on the standard side,
it is adoption. People will not move if it does not hurt enough. And
they can bear a lot.


But, for adoption, some formal document, not necessarily a (standard
track) rfc, is necessary.

Masataka Ohta

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

[Pascal Thubert (pthubert) via NANOG]

Hello Masataka-san

> When I mentioned a problem for the first time in IPng or IPv6 (I can't
> find any archive, are there any?) list, Christian Huitema mentioned it
> could be solved by ND over NBMA but the problem is not NB but broadcast
> of Wifi is unreliable.
> 
> As such, the solutions should be based on a fact that repeated
> unreliable broadcast is reliable.

Solutions must first avoid broadcast as much as possible, because there's also 
the cost of it. There's a scale where it hurts any network, and repeating them 
even more cannot be the answer.
And then, I agree with you completely, whatever is broadcast (e.g., beacons for 
initial discovery) is repeated and, not expected to be reliable.
This is in essence RFC 8505.
Then you want zerotrust, ND is so easy to attack from inside and even outside. 
This is RFC 8928.

>   Reducing the speed at the physical (PHY) layer for
>   broadcast transmissions can increase the reliability
> 
> longer packets mean more collision (with hidden terminals) probability
> and less reliability.

Agreed. The draft tries to look at all angles. It is certainly not pleading to 
use broadcast. It is pleading to deprecate ND because of its use of broadcast 
even on networks where it plain does not work. In practice today, DAD is a joke 
on any large wireless fabric and still you see all those broadcasts in the air. 
Save the planet! 

> >  So far we failed to get those RFCs implemented on the major stacks
> > for WiFi or Ethernet.
> 
> Ethernet? Even though its broadcast is reliable?

Ethernet is enterprise networks is largely virtualized. We cannot offer fast 
and reliable broadcast services on a worldwide overlay. 

If we filter BUM we end up with so-called "silent nodes" that are effectively 
disconnected. If we try and serve them broadcast storms are a visible penalty 
on the overlay.

Add to that the desire by the device to own more and more addresses. You end up 
in a situation where the devices thinks the own an address and are reachable at 
that address but in fact the network will not serve that address because 1) it 
missed the creation (a snooped DAD?), 2) it has forgotten about it, or 3) the 
max count of addresses that the network maintains per host is passed. Note that 
3) may be reached because the network ignores that the host deprecated one of 
the addresses. 

You want a contract between that the host and the network that the host owns an 
address and is reachable at that address. Like any contract, that must be a 
negotiation. ND is not like that. RFC 8505 is exactly that. 

> It may be more constructive to work for proxy ARP suitable for Wifi,
> which may be enforced by Wifi alliance. An RFC may be published if Wifi
> industry request IETF to do so.

This is effectively done already for ND. 

The draft text in .11me recommends RFC 8929 as the ND proxy. 802.11md had it 
already since the Bangkok meeting but at the time of the freeze, RFC 8929 was 
still a draft and the text was removed at the last minute. RFC 8929 describes 
how RFC 8505 can be used buy the STA to negotiate a contract with the AP so the 
AP does ND proxy. Then the draft discusses how the AP represents the STA over 
the wired backbone, how mobility is handled, etc...

I guess the design can be easily retrofitted to ARP. ND is really designed 
exactly as ARP. The differences were for the show, the real steps that should 
have been made were not. But now with RFC 8505 we have a modern solution. The 
problem is no more on the standard side, it is adoption. People will not move 
if it does not hurt enough. And they can bear a lot.

All the best

Pascal 

> -Original Message-
> From: Masataka Ohta 
> Sent: vendredi 13 janvier 2023 6:36
> To: Pascal Thubert (pthubert) ; nanog@nanog.org
> Subject: Re: A straightforward transition plan (was: Re: V6 still not
> supported)
> 
> Pascal Thubert (pthubert) wrote:
> 
> Hi,
> 
> > For that issue at least there was some effort. Though ATM and FR
> > appear to be long gone, the problem got even worse with pseudo wires /
> > overlays and wireless.
> >
> > It was tackled in the IoT community 10+ years ago and we ended up with
> > RFC 8505 and 8928. This is implemented in LoWPAN devices and deployed
> > by millions. Allowing IPv6 subnets of thousands on constrained radios.
> 
> When I mentioned a problem for the first time in IPng or IPv6 (I can't
> find any archive, are there any?) list, Christian Huitema mentioned it
> could be solved by ND over NBMA but the problem is not NB but broadcast
> of Wifi is unreliable.
> 
> As such, the solutions should be based on a fact that repeated
> unreliable broadcast is reliable.
> 
> > I spent a bit of time explaining the architecture issue (in mild
> > terms) and solutions in
> > https://datatracker.ietf.org/doc

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

[Masataka Ohta]

Pascal Thubert (pthubert) wrote:

Hi,


For that issue at least there was some effort. Though ATM and FR
appear to be long gone, the problem got even worse with pseudo wires
/ overlays and wireless.

It was tackled in the IoT community 10+ years ago and we ended up
with RFC 8505 and 8928. This is implemented in LoWPAN devices and
deployed by millions. Allowing IPv6 subnets of thousands on
constrained radios.


When I mentioned a problem for the first time in IPng or IPv6
(I can't find any archive, are there any?) list, Christian
Huitema mentioned it could be solved by ND over NBMA but
the problem is not NB but broadcast of Wifi is unreliable.

As such, the solutions should be based on a fact that
repeated unreliable broadcast is reliable.


I spent a bit of time explaining the architecture issue (in mild
terms) and solutions in
https://datatracker.ietf.org/doc/html/draft-thubert-6man-ipv6-over-wireless-12.


Though you wrote in the draft:

Reducing the speed at the physical (PHY) layer for
broadcast transmissions can increase the reliability

longer packets mean more collision (with hidden terminals)
probability and less reliability.

A link broadcast domain must be same for all the members
of the link and should be defined as set of terminals which
can receive broadcast from a central station (or, stations)
with certain probability, which is why Wifi broadcast is
relayed by a central station.


 So far we failed to get those RFCs implemented on the major stacks
for WiFi or Ethernet.


Ethernet? Even though its broadcast is reliable?

Though Wifi bridged by Ethernet may have its own problems,
they are Wifi-specific problems.


There’s a new thread at IETF 6MAN just now on adopting just the draft
above - not even the solution. It is facing the same old opposition
from the same few and a lot of silence.


You can't expect people still insisting on IPv6 as is much.


My suggestion is still to fix IPv6 as opposed to drop it, because I
don’t see that we have another bullet to fire after that one. For
that particular issue of fixing ND, new comments and support at the
6MAN on the draft above may help.


It may be more constructive to work for proxy ARP suitable
for Wifi, which may be enforced by Wifi alliance. An RFC
may be published if Wifi industry request IETF to do so.

Masataka Ohta

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

[William Herrin]

On Wed, Jan 11, 2023 at 11:16 PM Vasilenko Eduard via NANOG
 wrote:
> The comment looks outdated: Who cares now about ATM?

You may have missed the sarcasm. The 1995 Addison Wesley IPng book
spends pages and pages talking about potential IPv6 use in the Navy
and interoperability with ATM before it gets around to discussing IPv6
in the enterprise and acceptance on the general Internet. It's an
understatement to say their priorities were out of whack.

Regards,
Bill Herrin


-- 
For hire. https://bill.herrin.us/resume/

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

[Vasilenko Eduard via NANOG]

The comment looks outdated: Who cares now about ATM?
But all wireless (including WiFi) emulate broadcast in a very unsatisfactory 
way.
Hence, the requirement is still very accurate.

-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Masataka Ohta
Sent: Thursday, January 12, 2023 7:32 AM
To: nanog@nanog.org
Subject: Re: A straightforward transition plan (was: Re: V6 still not supported)

Randy Bush wrote:

> three of the promises of ipng which ipv6 did not deliver
>o compatibility/transition,
>o security, and
>o routing & renumbering

You miss a promise of

o ND over ATM/NBMA

which caused IPv6 lack a notion of link broadcast.

Masataka Ohta

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

[Pascal Thubert (pthubert) via NANOG]

Hello Masataka-san

For that issue at least there was some effort.
Though ATM and FR appear to be long gone, the problem got even worse with 
pseudo wires / overlays and wireless.

It was tackled in the IoT community 10+ years ago and we ended up with RFC 8505 
and 8928. This is implemented in LoWPAN devices and deployed by millions. 
Allowing IPv6 subnets of thousands on constrained radios.

I spent a bit of time explaining the architecture issue (in mild terms) and 
solutions in 
https://datatracker.ietf.org/doc/html/draft-thubert-6man-ipv6-over-wireless-12.

So far we failed to get those RFCs implemented on the major stacks for WiFi or 
Ethernet.

There’s a new thread at IETF 6MAN just now on adopting just the draft above - 
not even the solution. It is facing the same old opposition from the same few 
and a lot of silence.

Somehow the group can spend years of heated discussions figuring out if you can 
insert a header or how you can build a 64 bits IID, but looking at a 
fundamental architecture issue like the one you point out does not raise much 
interest.

My suggestion is still to fix IPv6 as opposed to drop it, because I don’t see 
that we have another bullet to fire after that one. For that particular issue 
of fixing ND, new comments and support at the 6MAN on the draft above may help.

All the best;

Pascal

Le 12 janv. 2023 à 05:34, Masataka Ohta  a 
écrit :

Randy Bush wrote:

three of the promises of ipng which ipv6 did not deliver
  o compatibility/transition,
  o security, and
  o routing & renumbering

You miss a promise of

  o ND over ATM/NBMA

which caused IPv6 lack a notion of link broadcast.

   Masataka Ohta

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

[Masataka Ohta]

Randy Bush wrote:


three of the promises of ipng which ipv6 did not deliver
   o compatibility/transition,
   o security, and
   o routing & renumbering


You miss a promise of

   o ND over ATM/NBMA

which caused IPv6 lack a notion of link broadcast.

Masataka Ohta

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

[bzs]

On January 12, 2023 at 02:11 n...@neo.co.tz (Noah) wrote:
 > Hi John,
 > 
 > So, It was assumed that IPv4 depletion would effectively lead to the adoption
 > of IPv6. This has not been the case in the last decade save for a very few
 > countries in the world.
 > 
 > It was also assumed that IPv6 only networks would crop all over the place as 
 > a
 > result, providing the same interconnectivity benefits enjoyed by the IPv4
 > internet.
 > 
 > Out of curiosity,did the emergency of transfer markets slow IPNG adoption 
 > while
 > creating prolonged dependence on IPv4?

Probably ten people have said this already but it was more likely due
to the success of CGNAT.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

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

[John Curran]

Randy -

Full agreement - nicely said.

/John

P.s disclaimer: my views alone - do not eat packet.

> On Jan 11, 2023, at 7:10 PM, Randy Bush  wrote:
> 
> 
>> 
>> It was assumed that IPng would include a standard straightforward
>> technological solution to support communication with IPv4 hosts – this
>> was a defined hard requirement.
>> 
>> This transition mechanism wasn’t available at the time of the
>> selection of IPng, and instead was left as a future deliverable.
> 
> three of the promises of ipng which ipv6 did not deliver
>  o compatibility/transition,
>  o security, and 
>  o routing & renumbering
> 
> the real goal of those who made the ipv6 decision was to stop the press
> from screaming about the end of the internet.  in this they succeeded.
> 
> and the ops community has paid an insane penalty ere since.
> 
> randy

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

[Randy Bush]

> It was assumed that IPng would include a standard straightforward
> technological solution to support communication with IPv4 hosts – this
> was a defined hard requirement.
> 
> This transition mechanism wasn’t available at the time of the
> selection of IPng, and instead was left as a future deliverable.

three of the promises of ipng which ipv6 did not deliver
  o compatibility/transition,
  o security, and 
  o routing & renumbering

the real goal of those who made the ipv6 decision was to stop the press
from screaming about the end of the internet.  in this they succeeded.

and the ops community has paid an insane penalty ere since.

randy

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

[John Curran]

Noah -

It was assumed that IPng would include a standard straightforward technological 
solution to support communication with IPv4 hosts – this was a defined hard 
requirement. 

This transition mechanism wasn’t available at the time of the selection of 
IPng, and instead was left as a future deliverable.  The future deliverable was 
then abandoned, leaving transition mechanisms as an area where service 
providers had to fill in the gaps years later through their own efforts. 

The failure to deliver on a standard interoperability method to existing IPv4 
hosts (something that major ISPs now commonly do today but only after a decade 
or so of their own work)  is precisely why all early plans and assumptions 
about IPv6 deployment became moot. 

Your questions about IPv6 deployment assumptions is a question about 
assumptions that were known to be invalid the moment that we choose a new IP 
protocol that lacked the required interoperability. 

Thanks,
/John

p.s. Disclaimer: my views alone - objects in the past may be larger than they 
actually appear. 

> On Jan 11, 2023, at 6:11 PM, Noah  wrote:
> 
> Hi John,
> 
> So, It was assumed that IPv4 depletion would effectively lead to the adoption 
> of IPv6. This has not been the case in the last decade save for a very few 
> countries in the world.
> 
> It was also assumed that IPv6 only networks would crop all over the place as 
> a result, providing the same interconnectivity benefits enjoyed by the IPv4 
> internet.
> 
> Out of curiosity,did the emergency of transfer markets slow IPNG adoption 
> while creating prolonged dependence on IPv4?
> 
> Cheers,
> ./noah
> 
> 
> On Thu, Mar 24, 2022 at 4:03 PM John Curran  > wrote:
>> On 24 Mar 2022, at 5:19 AM, Mark Delany > > wrote:
>>> 
>>> On 24Mar22, Greg Skinner via NANOG allegedly wrote:
>>> 
 straightforward transition plan
>>> 
 in-hand working transition strategy
>>> 
 nor a straightforward transition
>> 
>> The words quoted above are mine, not Greg’s, so let’s send the blame in my 
>> direction not his… :-)
>> 
>>> Any such "transition plan" whether "working" or "straightforward" is 
>>> logically
>>> impossible. 
>> 
>> That entirely depends on what is meant by “straightforward transition plan”… 
>>  If one means a plan that provides that “Network ABC will transition on this 
>> date with this approach, and then Network JKL will transition using this 
>> approach, then network XYZ shall transition on this date, etc. ” then you 
>> are indeed correct – such a command-and-control approach is not "the 
>> Internet way", comrade. 
>> 
>> If by “straightforward transition plan” one means a clear and rational set 
>> of options that allows networks to plan their own migration from IPv4-only 
>> to IPv6, while maintaining connectivity to IPv4-only hosts and with a level 
>> of effort reasonable comparable to just running IPv4, then I would disagree, 
>> as such an "IPng transition plan” was achievable, expected, and we 
>> collectively failed to deliver on it (as noted below) 
>> 
>> The "Technical Criteria for Choosing IP The Next Generation (IPng)” 
>> [RFC1726] did have a specific requirement in this regard (see quoted section 
>> attached to this email), and that requirement postulated that “there will be 
>> IPv4 hosts on the Internet effectively forever.  IPng must provide 
>> mechanisms to allow these hosts to communicate, even after IPng has become 
>> the dominant network layer protocol in the Internet.”   It also noted that 
>> we must be able to run dual-stack with a comparable level of effort as 
>> IPv4-only, but that dual-stack alone was not sufficient and actual 
>> interoperability mechanisms would be required between IPv4 and IPng for IPng 
>> success. 
>> 
>> The IPng recommendation [RFC 1752, 
>> https://datatracker.ietf.org/doc/html/rfc1752] 
>>  proceeded with the SIPP 
>> proposal as the basis for IPv6, just noting some weakness with respect to 
>> satisfying this IPng transition requirement – 
>> 
>>The biggest problem the reviewers had with SIPP was with IPAE, SIPP's
>>transition plan.  The overwhelming feeling was that IPAE is fatally
>>flawed and could not be made to work reliably in an operational
>>Internet.
>> 
>> The work to meet this requirement was punted to a newly-defined IETF IPng 
>> Transition (NGTRANS) Working Group - the working group was to design the 
>> mechanisms to necessary for a straightforward transition of the Internet 
>> from IPv4 to IPv6 and to give advice on what procedures and techniques are 
>> preferred.  NGTRANS did define a set of dual-stack and tunneling solutions 
>> [RFC 4213], but didn’t get to actual interoperability mechanisms or clear 
>> roadmap of options that would have met IPng’s requirement for 
>> straightforward transition plan.  
>> 
>> In fact, what happened instead is that dual-stack (aka “Ships in the 

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

[Noah]

Hi John,

So, It was assumed that IPv4 depletion would effectively lead to the
adoption of IPv6. This has not been the case in the last decade save for a
very few countries in the world.

It was also assumed that IPv6 only networks would crop all over the place
as a result, providing the same interconnectivity benefits enjoyed by the
IPv4 internet.

Out of curiosity,did the emergency of transfer markets slow IPNG adoption
while creating prolonged dependence on IPv4?

Cheers,
*.**/noah*



On Thu, Mar 24, 2022 at 4:03 PM John Curran  wrote:

> On 24 Mar 2022, at 5:19 AM, Mark Delany  wrote:
>
>
> On 24Mar22, Greg Skinner via NANOG allegedly wrote:
>
> straightforward transition plan
>
>
> in-hand working transition strategy
>
>
> nor a straightforward transition
>
>
> The words quoted above are mine, not Greg’s, so let’s send the blame in my
> direction not his… :-)
>
> Any such "transition plan" whether "working" or "straightforward" is
> logically
> impossible.
>
>
> That entirely depends on what is meant by “straightforward transition
> plan”…  If one means a plan that provides that “Network ABC will transition
> on this date with this approach, and then Network JKL will transition using
> this approach, then network XYZ shall transition on this date, etc. ” then
> you are indeed correct – such a command-and-control approach is not "the
> Internet way", comrade.
>
> If by “straightforward transition plan” one means a clear and rational set
> of options that allows networks to plan their own migration from IPv4-only
> to IPv6, while maintaining connectivity to IPv4-only hosts and with a level
> of effort reasonable comparable to just running IPv4, then I would
> disagree, as such an "IPng transition plan” was achievable, expected, and
> we collectively failed to deliver on it (as noted below)
>
> The "Technical Criteria for Choosing IP The Next Generation (IPng)”
> [RFC1726] did have a specific requirement in this regard (see quoted
> section attached to this email), and that requirement postulated that
> “there will be IPv4 hosts on the Internet effectively forever.  IPng must
> provide mechanisms to allow these hosts to communicate, even after IPng has
> become the dominant network layer protocol in the Internet.”   It also
> noted that we must be able to run dual-stack with a comparable level of
> effort as IPv4-only, but that dual-stack alone was not sufficient and
> actual interoperability mechanisms would be required between IPv4 and IPng
> for IPng success.
>
> The IPng recommendation [RFC 1752,
> https://datatracker.ietf.org/doc/html/rfc1752] proceeded with the SIPP
> proposal as the basis for IPv6, just noting some weakness with respect to
> satisfying this IPng transition requirement –
>
>The biggest problem the reviewers had with SIPP was with IPAE, SIPP's
>transition plan.  The overwhelming feeling was that IPAE is fatally
>flawed and could not be made to work reliably in an operational
>Internet.
>
>
> The work to meet this requirement was punted to a newly-defined IETF IPng
> Transition (NGTRANS) Working Group - the working group was to design the
> mechanisms to necessary for a straightforward transition of the Internet
> from IPv4 to IPv6 and to give advice on what procedures and techniques are
> preferred.  NGTRANS did define a set of dual-stack and tunneling solutions
> [RFC 4213], but didn’t get to actual interoperability mechanisms or clear
> roadmap of options that would have met IPng’s requirement for
> straightforward transition plan.
>
> In fact, what happened instead is that dual-stack (aka “Ships in the
> Night” - both protocols should be able to run on the same host unaware of
> the others existence) ended up as the de facto IPv6 transition strategy,
> and anything more was left to be researcher/vendor/user defined…   For
> those who want a really nice summary of the state of affairs on IPv6
> transition around 2008 (more than 10 years after the IPng recommendation) I
> would suggest Geoff Huston’s "IPv6 Transition at IETF 72” summary in the
> IETF Journal  –
> as usual, Geoff does a great job with a rather complex topic.
>
> So instead of having a clear & straightforward menu of options for network
> operators on how to deploy IPv6 in parallel in their network without
> breaking anything (i.e. a set of coherent strategies to choose from that
> would have constituted a “a straightforward transition plan”), we ended up
> with an explosion of transition approaches in various states of
> functionality, side-effects, and maturity – the exact opposite of what a
> network operator wants to face when considering transitioning their
> production network to IPv6.   There was even an attempt to inventory the
> various solutions -
> https://www.ietf.org/archive/id/draft-jankiewicz-v6ops-v4v6biblio-03.txt –
> but keeping track of them all is akin to counting tribbles so I don’t
> believe it was ever published.
>
> 

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

[Pascal Thubert (pthubert) via NANOG]

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  On Behalf Of Mark
> Andrews
> Sent: jeudi 31 mars 2022 1:32
> To: NANOG 
> Subject: Re: A straightforward transition plan (was: Re: V6 still not
> supported)
> 
> 
> 
> > On 26 Mar 2022, at 21:51, Philip Homburg 
> 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, 

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

[Mark Andrews]

> On 26 Mar 2022, at 21:51, Philip Homburg  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: ma...@isc.org

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

[Joe Maimon]

Philip Homburg wrote:
It should be clear that an IPv4-only host only speaks IPv4. This means 
that communication with an IPv4-only host has to be IPv4.


This did not have to be true, had there been an extension/option 
standardized at the same time as IPv6 for IPv4 packets to be gateway'd 
into IPv6 transparently and efficiently (thru any dual stacked 
host/router), than at this point we would have likely been looking at 4 
classes of nodes


- IPv4 only, legacy, requires translation to communicate directly with ipv6

- IPv4 only, extended, just needs a gateway to communicate directly with 
IPv6


- Dual Stack

- IPv6 only

Such additional functionality, could have been organically updated into 
most major OS's without any required network topology changes.


Joe

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

[Ca By]

On Mon, Mar 28, 2022 at 6:22 AM Philip Homburg 
wrote:

> >If by ?straightforward transition plan? one means a clear and rational
> set of
> >options that allows networks to plan their own migration from IPv4-only
> to IPv
> >6, while maintaining connectivity to IPv4-only hosts and with a level of
> effor
> >t reasonable comparable to just running IPv4, then I would disagree, as
> such a
> >n "IPng transition plan? was achievable, expected, and we collectively
> failed
> >to deliver on it (as noted below)
>
> I'm a bit confused about the achievable part.
>
> Obviously, the adoption of IPv6 without a clear transition plan was a
> process
> failure. However, it is not clear to me that waiting a few years would
> have brought something much better. And waiting more than a decade would
> mean that today there would not be a mature IPv6.
>
> Transition to IPv6 so far seems to have consisted of 3 phases:
> 1) Lots of tunnels due lack of a wide spread IPv6 backbone.
> 2) Early adopters being happy that they can run IPv6 native, usually as
>dual stack.
> 3) Lots of people looking into IPv6-only.
>
> I'd say 1) mostly worked. 6to4 was a bit of mess. But otherwise tunnels
> worked. Obviously, deploying IPv6 using tunnels is a lot more complex
> than deploying native IPv4 without NAT.
> From a technical perspective 2) just works. From an operational perspective
> it is about twice as expensive as IPv4-only. So 2) is popular with people
> who really want IPv6.
>
> The big issue is 3). If we look at the current internet, there are parties
> who lack IPv4 addresses and want to switch to IPv6. Obviously, they
> want to be IPv6-only. The lack of IPv4 address makes dual stack even
> harder.
> On the other hand, there are parties who have enough IPv4 addresses and
> have no reason to switch to IPv6.
>
> So we are clearly in the situation of 'migration from IPv4-only to IPv6,
> while maintaining connectivity to IPv4-only hosts'
>
> It should be clear that an IPv4-only host only speaks IPv4. This means that
> communication with an IPv4-only host has to be IPv4. So either the
> IPv6-only host or something in the network has to speak IPv4. If the
> IPv6 host speaks IPv4 then we get dual stack, which has been rejected
> as a broken solution. Technically, it is also possible to tunnel IPv4
> packets, then the host is in some sense dual stack, but most of the network
> is not. However, automatic tunnel configuration is hard, and tunnels
> tend to be fragile.
>
> So the only option is a device in the network that translates between
> IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
> a technical point of view it is a disaster.




I think what you mean to say is you don’t like NAT64.

You may also be trying to say you disapprove of how history unfolded.

Fair.

But it may be worth acknowledge that some small and some very large (100M
mobiles, growing FWA broadband business) have happily operated NAT64 for
coming on 10 years  with no problems or regrets.

Yes, we would like the internet to be on a single unified and high scale
address family, but we all play the hand we are dealt.



>
> Looking back, we can say that the only feature of IPv6 that makes people
> invest in IPv6 is the bigger address space. So it is safe to say that
> most of the internet would have waited to invest in IPv6 until we were
> (almost) out of IPv4 addresses. So by its very nature this transation
> between IPv6 and IPv4 would have NAT component.
>
> In my opinion, It is clear that during the time IPv6 was developed, any
> solution involving NAT would have been rejected.
>
> So I'm confused, what transition technology was achievable (also in the
> political sense) but not delivered?
>
> If there is a magical transition technology that allows an IPv6-only host
> to
> talk to an IPv4-only host, then let's deploy it.
>

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

[JORDI PALET MARTINEZ via NANOG]

I don't think we can say that NAT64 is a disaster. I will say so if we want to 
keep IPv4 only hosts in the "6" side, of course it doesn't work. However, 
that's why we moved further with 464XLAT. And the demonstration is that most of 
the operators are using it.

I think in your picture you're missing 2 phases:
4) IPv6-only with IPv4aaS (we have 5 technologies, see RFC8585 for a summary of 
what is needed in the CPEs), when there is still a significant amount of IPv4 
traffic in the customer LANs.
5) IPv6-only with IPv4aaS when IPv4 traffic is residual in most of the 
customers LANs. How fast we move to this phase depends on more and more 
devices, and apps using IPv6.

The advantage is:
a) The job is done in the CPE (no need for a more powerful one, etc.), 
customers are not aware of it. Part of the job is done in the operators 
networks, of course, but it is comparable and much cheaper, in terms of OpEx 
and CapEx, to alternatives such as dual-stack or NAT444/CGN.
b) When moving to 5 above, the operators can measure the reduction on the usage 
of the NAT64 (in the case of 464XLAT), and even in the usage of IPv4 public 
addresses, so they can transfer them, so laggers can use them for their own 
transition. On the side of the customers, there is nothing to do. You may 
remove IPv4, but actually is not costing you "anything" to keep it.
 

Regards,
Jordi
@jordipalet
 
 

El 28/3/22, 15:23, "NANOG en nombre de Philip Homburg" 
 escribió:

>If by ?straightforward transition plan? one means a clear and rational set 
of 
>options that allows networks to plan their own migration from IPv4-only to 
IPv
>6, while maintaining connectivity to IPv4-only hosts and with a level of 
effor
>t reasonable comparable to just running IPv4, then I would disagree, as 
such a
>n "IPng transition plan? was achievable, expected, and we collectively 
failed 
>to deliver on it (as noted below) 

I'm a bit confused about the achievable part.

Obviously, the adoption of IPv6 without a clear transition plan was a 
process
failure. However, it is not clear to me that waiting a few years would 
have brought something much better. And waiting more than a decade would
mean that today there would not be a mature IPv6.

Transition to IPv6 so far seems to have consisted of 3 phases:
1) Lots of tunnels due lack of a wide spread IPv6 backbone.
2) Early adopters being happy that they can run IPv6 native, usually as
   dual stack.
3) Lots of people looking into IPv6-only.

I'd say 1) mostly worked. 6to4 was a bit of mess. But otherwise tunnels
worked. Obviously, deploying IPv6 using tunnels is a lot more complex
than deploying native IPv4 without NAT. 
From a technical perspective 2) just works. From an operational perspective
it is about twice as expensive as IPv4-only. So 2) is popular with people
who really want IPv6. 

The big issue is 3). If we look at the current internet, there are parties
who lack IPv4 addresses and want to switch to IPv6. Obviously, they
want to be IPv6-only. The lack of IPv4 address makes dual stack even harder.
On the other hand, there are parties who have enough IPv4 addresses and
have no reason to switch to IPv6.

So we are clearly in the situation of 'migration from IPv4-only to IPv6,
while maintaining connectivity to IPv4-only hosts'

It should be clear that an IPv4-only host only speaks IPv4. This means that
communication with an IPv4-only host has to be IPv4. So either the
IPv6-only host or something in the network has to speak IPv4. If the
IPv6 host speaks IPv4 then we get dual stack, which has been rejected
as a broken solution. Technically, it is also possible to tunnel IPv4
packets, then the host is in some sense dual stack, but most of the network
is not. However, automatic tunnel configuration is hard, and tunnels
tend to be fragile.

So the only option is a device in the network that translates between
IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
a technical point of view it is a disaster.

Looking back, we can say that the only feature of IPv6 that makes people
invest in IPv6 is the bigger address space. So it is safe to say that
most of the internet would have waited to invest in IPv6 until we were
(almost) out of IPv4 addresses. So by its very nature this transation 
between IPv6 and IPv4 would have NAT component.

In my opinion, It is clear that during the time IPv6 was developed, any
solution involving NAT would have been rejected.

So I'm confused, what transition technology was achievable (also in the
political sense) but not delivered?

If there is a magical transition technology that allows an IPv6-only host to
talk to an IPv4-only host, then let's deploy it.



**
IPv4 is over
Are you ready for the new Internet ?

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

[Philip Homburg]

> > 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.

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

[Philip Homburg]

>If by ?straightforward transition plan? one means a clear and rational set of 
>options that allows networks to plan their own migration from IPv4-only to IPv
>6, while maintaining connectivity to IPv4-only hosts and with a level of effor
>t reasonable comparable to just running IPv4, then I would disagree, as such a
>n "IPng transition plan? was achievable, expected, and we collectively failed 
>to deliver on it (as noted below) 

I'm a bit confused about the achievable part.

Obviously, the adoption of IPv6 without a clear transition plan was a process
failure. However, it is not clear to me that waiting a few years would 
have brought something much better. And waiting more than a decade would
mean that today there would not be a mature IPv6.

Transition to IPv6 so far seems to have consisted of 3 phases:
1) Lots of tunnels due lack of a wide spread IPv6 backbone.
2) Early adopters being happy that they can run IPv6 native, usually as
   dual stack.
3) Lots of people looking into IPv6-only.

I'd say 1) mostly worked. 6to4 was a bit of mess. But otherwise tunnels
worked. Obviously, deploying IPv6 using tunnels is a lot more complex
than deploying native IPv4 without NAT. 
>From a technical perspective 2) just works. From an operational perspective
it is about twice as expensive as IPv4-only. So 2) is popular with people
who really want IPv6. 

The big issue is 3). If we look at the current internet, there are parties
who lack IPv4 addresses and want to switch to IPv6. Obviously, they
want to be IPv6-only. The lack of IPv4 address makes dual stack even harder.
On the other hand, there are parties who have enough IPv4 addresses and
have no reason to switch to IPv6.

So we are clearly in the situation of 'migration from IPv4-only to IPv6,
while maintaining connectivity to IPv4-only hosts'

It should be clear that an IPv4-only host only speaks IPv4. This means that
communication with an IPv4-only host has to be IPv4. So either the
IPv6-only host or something in the network has to speak IPv4. If the
IPv6 host speaks IPv4 then we get dual stack, which has been rejected
as a broken solution. Technically, it is also possible to tunnel IPv4
packets, then the host is in some sense dual stack, but most of the network
is not. However, automatic tunnel configuration is hard, and tunnels
tend to be fragile.

So the only option is a device in the network that translates between
IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
a technical point of view it is a disaster.

Looking back, we can say that the only feature of IPv6 that makes people
invest in IPv6 is the bigger address space. So it is safe to say that
most of the internet would have waited to invest in IPv6 until we were
(almost) out of IPv4 addresses. So by its very nature this transation 
between IPv6 and IPv4 would have NAT component.

In my opinion, It is clear that during the time IPv6 was developed, any
solution involving NAT would have been rejected.

So I'm confused, what transition technology was achievable (also in the
political sense) but not delivered?

If there is a magical transition technology that allows an IPv6-only host to
talk to an IPv4-only host, then let's deploy it.

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

[John Curran]

On 25 Mar 2022, at 2:27 PM, Philip Homburg  wrote:
> 
>> If by ?straightforward transition plan? one means a clear and rational set 
>> of 
>> options that allows networks to plan their own migration from IPv4-only to 
>> IPv
>> 6, while maintaining connectivity to IPv4-only hosts and with a level of 
>> effor
>> t reasonable comparable to just running IPv4, then I would disagree, as such 
>> a
>> n "IPng transition plan? was achievable, expected, and we collectively 
>> failed 
>> to deliver on it (as noted below) 
> 
> I'm a bit confused about the achievable part.
> 
> Obviously, the adoption of IPv6 without a clear transition plan was a process
> failure. However, it is not clear to me that waiting a few years would 
> have brought something much better. And waiting more than a decade would
> mean that today there would not be a mature IPv6.
> ...
> The big issue is 3). If we look at the current internet, there are parties
> who lack IPv4 addresses and want to switch to IPv6. Obviously, they
> want to be IPv6-only. The lack of IPv4 address makes dual stack even harder.
> On the other hand, there are parties who have enough IPv4 addresses and
> have no reason to switch to IPv6.
> 
> So we are clearly in the situation of 'migration from IPv4-only to IPv6,
> while maintaining connectivity to IPv4-only hosts'

Correct (although I will also point out that having zero IPv4 addresses isn’t 
really the problem but rather “not enough IPv4 space for their networking 
needs” – in the ARIN region, for example, organizations can obtain a small 
amount of IPv4 address space specifically for purposes of IPv6 transition 
technology use - it’s quite necessary for nearly any IPv6/IPv6 interoperability 
solution since they need to have an IPv4-facing interfaces)

> It should be clear that an IPv4-only host only speaks IPv4. This means that
> communication with an IPv4-only host has to be IPv4. So either the
> IPv6-only host or something in the network has to speak IPv4. If the
> IPv6 host speaks IPv4 then we get dual stack, which has been rejected
> as a broken solution. Technically, it is also possible to tunnel IPv4
> packets, then the host is in some sense dual stack, but most of the network
> is not. However, automatic tunnel configuration is hard, and tunnels
> tend to be fragile.
> 
> So the only option is a device in the network that translates between
> IPv6 and IPv4. Currently we have such a protocol, NAT64. And from
> a technical point of view it is a disaster.

We actually have an abundance of technical solutions that provide some degree 
of IPv6/IPv4 interoperability, all with various tradeoffs, and which address 
various deployment scenarios such as whether the network service has 
involvement in the individual CPE, DNS resolution, ability to alter/profile 
applications, etc…  it’s a rather complex mess, and there’s far more solutions 
in use that just NAT64.  

> Looking back, we can say that the only feature of IPv6 that makes people
> invest in IPv6 is the bigger address space. So it is safe to say that
> most of the internet would have waited to invest in IPv6 until we were
> (almost) out of IPv4 addresses. So by its very nature this transation 
> between IPv6 and IPv4 would have NAT component.

 Full agreement there…  one would have expected a strong focused 
effort in making a small number of standard NAT-based interoperability 
protocols for IPng, including working through the transition scenario 
implications. 

> In my opinion, It is clear that during the time IPv6 was developed, any
> solution involving NAT would have been rejected.

Pretty much correct…  As you may be aware, there was a large focus on 
tunnel-bases solutions (so that various islands of IPv6 exploration could be 
interconnected) but actual NAT-based interoperability wasn’t in the cards.

> So I'm confused, what transition technology was achievable (also in the
> political sense) but not delivered?

Well, I think you’ve hit the nail on the head - we certainly could have 
delivered on the actual IPng technical requirements for a straightforward 
transition plan (and ended up with a short finite number of well-tested 
protocols with far more attention paid to them starting 10 years earlier in the 
process) rather than present cornucopia of last-minute solutions of various 
technical strength – alas, taking that path of actually working on NAT-based 
interoperability solutions did not align with the culture/politics of the IETF. 

> If there is a magical transition technology that allows an IPv6-only host to
> 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...)

FYI,
/John