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

Wed Jan 11 23:11:56 UTC 2023

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 at istaff.org> wrote:

> On 24 Mar 2022, at 5:19 AM, Mark Delany <k3f at 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.
>
>
> ===
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230112/e089433d/attachment.html>