Mailing List Archive

A straightforward transition plan (was: Re: V6 still not supported)
On 24 Mar 2022, at 5:19 AM, Mark Delany <k3f@november.emu.st> 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] <https://datatracker.ietf.org/doc/html/rfc1752%5D> 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 <https://www.ietfjournal.org/ipv6-transition-at-ietf-72/ <https://www.ietfjournal.org/ipv6-transition-at-ietf-72/>> – 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 <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.

Luckily, necessity is the mother of invention, and those whose operators experiencing the most significant network growth have figured out the particular protocols and techniques necessary for their transition to IPv6. Of course, that also meant each operator and their vendors have to work out all of the inevitable interactions with other protocols, security aspects, etc. anew with their particular chosen approach and selected technologies – hence why even to this day there is not a standard “cookbook” or “straightforward transition plan” for networks on how to deploy IPv6. I’ll be the first to admit that there are many networks that have sufficient complexity or unique aspects that warrant their own custom plan for IPv6, but disbelieve that the majority of network operators could not benefit from a clear set of standardized transition approaches for IPv6 rollout. (Alas, Internet standards work has generally taken a “let a thousand flowers bloom” approach to such matters, despite the IPng requirement to the contrary.)

FYI,
/John

==== Excerpt - "Technical Criteria for Choosing IP The Next Generation (IPng)” <https://datatracker.ietf.org/doc/html/rfc1726 <https://datatracker.ietf.org/doc/html/rfc1726>>

5.5 <https://datatracker.ietf.org/doc/html/rfc1726#section-5.5> Transition

CRITERION
The protocol must have a straightforward transition plan from the
current IPv4.

DISCUSSION
A smooth, orderly, transition from IPv4 to IPng is needed. If we
can't transition to the new protocol, then no matter how wonderful
it is, we'll never get to it.

We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.

Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.

Furthermore, we note that, in all probability, 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.

The absence of a rational and well-defined transition plan is not
acceptable. Indeed, the difficulty of running a network that is
transitioning from IPv4 to IPng must be minimized. (A good target
is that running a mixed IPv4-IPng network should be no more and
preferably less difficult than running IPv4 in parallel with
existing non-IP protocols).

Furthermore, a network in transition must still be robust. IPng
schemes which maximize stability and connectivity in mixed IPv4-
IPng networks are preferred.

Finally, IPng is expected to evolve over time and therefore, it
must be possible to have multiple versions of IPng, some in
production use, some in experimental, developmental, or evaluation
use, to coexist on the network. Transition plans must address
this issue.



Partridge and Kastenholz [Page 12]

RFC 1726 <https://datatracker.ietf.org/doc/html/rfc1726> IPng Technical Criteria December 1994


The transition plan must address the following general areas of
the Internet's infrastructure:

Host Protocols and Software
Router Protocols and Software
Security and Authentication
Domain Name System
Network Management
Operations Tools (e.g., Ping and Traceroute)
Operations and Administration procedures

The impact on protocols which use IP addresses as data (e.g., DNS,
distributed file systems, SNMP and FTP) must be specifically
addressed.

The transition plan should address the issue of cost distribution.
That is, it should identify what tasks are required of the service
providers, of the end users, of the backbones and so on.

Time Frame
A transition plan is required immediately.

===
Re: A straightforward transition plan (was: Re: V6 still not supported) [ In reply to ]
>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) [ In reply to ]
On 25 Mar 2022, at 2:27 PM, Philip Homburg <pch-nanog-2@u-1.phicoh.com> 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.

<chuckle> 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
Re: A straightforward transition plan (was: Re: V6 still not supported) [ In reply to ]
> > 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) [ In reply to ]
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" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de pch-nanog-2@u-1.phicoh.com> 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 ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Re: A straightforward transition plan (was: Re: V6 still not supported) [ In reply to ]
On Mon, Mar 28, 2022 at 6:22 AM Philip Homburg <pch-nanog-2@u-1.phicoh.com>
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) [ In reply to ]
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) [ In reply to ]
> On 26 Mar 2022, at 21:51, Philip Homburg <pch-nanog-2@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@isc.org
RE: A straightforward transition plan (was: Re: V6 still not supported) [ In reply to ]
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@nanog.org> On Behalf Of Mark
> Andrews
> Sent: jeudi 31 mars 2022 1:32
> To: NANOG <nanog@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@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@isc.org
Re: A straightforward transition plan (was: Re: V6 still not supported) [ In reply to ]
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 <jcurran@istaff.org> wrote:

> On 24 Mar 2022, at 5:19 AM, Mark Delany <k3f@november.emu.st> 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 <https://www.ietfjournal.org/ipv6-transition-at-ietf-72/> –
> 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.
>
> Luckily, necessity is the mother of invention, and those whose operators
> experiencing the most significant network growth have figured out the
> particular protocols and techniques necessary for their transition to IPv6.
> Of course, that also meant each operator and their vendors have to work
> out all of the inevitable interactions with other protocols, security
> aspects, etc. anew with their particular chosen approach and selected
> technologies – hence why even to this day there is not a standard
> “cookbook” or “straightforward transition plan” for networks on how to
> deploy IPv6. I’ll be the first to admit that there are many networks that
> have sufficient complexity or unique aspects that warrant their own custom
> plan for IPv6, but disbelieve that the majority of network operators could
> not benefit from a clear set of standardized transition approaches for IPv6
> rollout. (Alas, Internet standards work has generally taken a “let a
> thousand flowers bloom” approach to such matters, despite the IPng
> requirement to the contrary.)
>
> FYI,
> /John
>
> ==== Excerpt - "Technical Criteria for Choosing IP The Next Generation
> (IPng)” <https://datatracker.ietf.org/doc/html/rfc1726>
>
> 5.5 <https://datatracker.ietf.org/doc/html/rfc1726#section-5.5> Transition
>
> CRITERION
> The protocol must have a straightforward transition plan from the
> current IPv4.
>
> DISCUSSION
> A smooth, orderly, transition from IPv4 to IPng is needed. If we
> can't transition to the new protocol, then no matter how wonderful
> it is, we'll never get to it.
>
> We believe that it is not possible to have a "flag-day" form of
> transition in which all hosts and routers must change over at
> once. The size, complexity, and distributed administration of the
> Internet make such a cutover impossible.
>
> Rather, IPng will need to co-exist with IPv4 for some period of
> time. There are a number of ways to achieve this co-existence
> such as requiring hosts to support two stacks, converting between
> protocols, or using backward compatible extensions to IPv4. Each
> scheme has its strengths and weaknesses, which have to be weighed.
>
> Furthermore, we note that, in all probability, 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.
>
> The absence of a rational and well-defined transition plan is not
> acceptable. Indeed, the difficulty of running a network that is
> transitioning from IPv4 to IPng must be minimized. (A good target
> is that running a mixed IPv4-IPng network should be no more and
> preferably less difficult than running IPv4 in parallel with
> existing non-IP protocols).
>
> Furthermore, a network in transition must still be robust. IPng
> schemes which maximize stability and connectivity in mixed IPv4-
> IPng networks are preferred.
>
> Finally, IPng is expected to evolve over time and therefore, it
> must be possible to have multiple versions of IPng, some in
> production use, some in experimental, developmental, or evaluation
> use, to coexist on the network. Transition plans must address
> this issue.
>
>
> Partridge and Kastenholz [Page 12]
>
> ------------------------------
>
> RFC 1726 <https://datatracker.ietf.org/doc/html/rfc1726> IPng Technical Criteria December 1994
>
>
> The transition plan must address the following general areas of
> the Internet's infrastructure:
>
> Host Protocols and Software
> Router Protocols and Software
> Security and Authentication
> Domain Name System
> Network Management
> Operations Tools (e.g., Ping and Traceroute)
> Operations and Administration procedures
>
> The impact on protocols which use IP addresses as data (e.g., DNS,
> distributed file systems, SNMP and FTP) must be specifically
> addressed.
>
> The transition plan should address the issue of cost distribution.
> That is, it should identify what tasks are required of the service
> providers, of the end users, of the backbones and so on.
>
> Time Frame
> A transition plan is required immediately.
>
>
> ===
>
>
Re: A straightforward transition plan (was: Re: V6 still not supported) [ In reply to ]
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 <noah@neo.co.tz> 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 <jcurran@istaff.org <mailto:jcurran@istaff.org>> wrote:
>> On 24 Mar 2022, at 5:19 AM, Mark Delany <k3f@november.emu.st <mailto:k3f@november.emu.st>> 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] <https://datatracker.ietf.org/doc/html/rfc1752%5D> 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 <https://www.ietfjournal.org/ipv6-transition-at-ietf-72/> – 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.
>>
>> Luckily, necessity is the mother of invention, and those whose operators experiencing the most significant network growth have figured out the particular protocols and techniques necessary for their transition to IPv6. Of course, that also meant each operator and their vendors have to work out all of the inevitable interactions with other protocols, security aspects, etc. anew with their particular chosen approach and selected technologies – hence why even to this day there is not a standard “cookbook” or “straightforward transition plan” for networks on how to deploy IPv6. I’ll be the first to admit that there are many networks that have sufficient complexity or unique aspects that warrant their own custom plan for IPv6, but disbelieve that the majority of network operators could not benefit from a clear set of standardized transition approaches for IPv6 rollout. (Alas, Internet standards work has generally taken a “let a thousand flowers bloom” approach to such matters, despite the IPng requirement to the contrary.)
>>
>> FYI,
>> /John
>>
>> ==== Excerpt - "Technical Criteria for Choosing IP The Next Generation (IPng)” <https://datatracker.ietf.org/doc/html/rfc1726>
>>
>> 5.5 <https://datatracker.ietf.org/doc/html/rfc1726#section-5.5> Transition
>>
>> CRITERION
>> The protocol must have a straightforward transition plan from the
>> current IPv4.
>>
>> DISCUSSION
>> A smooth, orderly, transition from IPv4 to IPng is needed. If we
>> can't transition to the new protocol, then no matter how wonderful
>> it is, we'll never get to it.
>>
>> We believe that it is not possible to have a "flag-day" form of
>> transition in which all hosts and routers must change over at
>> once. The size, complexity, and distributed administration of the
>> Internet make such a cutover impossible.
>>
>> Rather, IPng will need to co-exist with IPv4 for some period of
>> time. There are a number of ways to achieve this co-existence
>> such as requiring hosts to support two stacks, converting between
>> protocols, or using backward compatible extensions to IPv4. Each
>> scheme has its strengths and weaknesses, which have to be weighed.
>>
>> Furthermore, we note that, in all probability, 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.
>>
>> The absence of a rational and well-defined transition plan is not
>> acceptable. Indeed, the difficulty of running a network that is
>> transitioning from IPv4 to IPng must be minimized. (A good target
>> is that running a mixed IPv4-IPng network should be no more and
>> preferably less difficult than running IPv4 in parallel with
>> existing non-IP protocols).
>>
>> Furthermore, a network in transition must still be robust. IPng
>> schemes which maximize stability and connectivity in mixed IPv4-
>> IPng networks are preferred.
>>
>> Finally, IPng is expected to evolve over time and therefore, it
>> must be possible to have multiple versions of IPng, some in
>> production use, some in experimental, developmental, or evaluation
>> use, to coexist on the network. Transition plans must address
>> this issue.
>>
>>
>>
>> Partridge and Kastenholz [Page 12]
>>
>> RFC 1726 <https://datatracker.ietf.org/doc/html/rfc1726> IPng Technical Criteria December 1994
>>
>>
>> The transition plan must address the following general areas of
>> the Internet's infrastructure:
>>
>> Host Protocols and Software
>> Router Protocols and Software
>> Security and Authentication
>> Domain Name System
>> Network Management
>> Operations Tools (e.g., Ping and Traceroute)
>> Operations and Administration procedures
>>
>> The impact on protocols which use IP addresses as data (e.g., DNS,
>> distributed file systems, SNMP and FTP) must be specifically
>> addressed.
>>
>> The transition plan should address the issue of cost distribution.
>> That is, it should identify what tasks are required of the service
>> providers, of the end users, of the backbones and so on.
>>
>> Time Frame
>> A transition plan is required immediately.
>>
>> ===
Re: A straightforward transition plan (was: Re: V6 still not supported) [ In reply to ]
> It was assumed that IPng would include a standard straightforward
> technological solution to support communication with IPv4 hosts ?V 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) [ In reply to ]
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 <randy@psg.com> 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) [ In reply to ]
On January 12, 2023 at 02:11 noah@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 | bzs@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) [ In reply to ]
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) [ In reply to ]
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 <mohta@necom830.hpcl.titech.ac.jp> 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) [ In reply to ]
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.com@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) [ In reply to ]
On Wed, Jan 11, 2023 at 11:16 PM Vasilenko Eduard via NANOG
<nanog@nanog.org> 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) [ In reply to ]
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) [ In reply to ]
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 <mohta@necom830.hpcl.titech.ac.jp>
> Sent: vendredi 13 janvier 2023 6:36
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>; 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/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) [ In reply to ]
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) [ In reply to ]
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, bzs@theworld.com wrote:
> On January 12, 2023 at 02:11noah@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