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

[Noah <noah () neo co tz>]

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