[ih] IETF relevance (was Memories of Flag Day?)

[Brian E Carpenter]

On 11-Aug-23 12:26, Dave Crocker wrote:
> On 8/10/2023 3:44 PM, Brian E Carpenter via Internet-history wrote:
>> What do you mean? There's always been a migration path. It has
>> been immensely complicated by the market success of NAT44, but
>> we knew from Day 1 that we needed both coexistence and a
>> transition plan. In fact, we knew it before IPv6 was picked
>> as the design (RFC1671).
> 
> Brian,
> 
> There was even a working group on transition to IPv6, before there was a
> chosen IPv6.  (Chaired by Bob Hinden and me.)  As nearly as I can tell,
> the work was ignored.

Interesting. Since this clearly wasn't ngtrans, can you point to it in
https://datatracker.ietf.org/group/concluded/ ?
> 
> The model for 'transition' that was adopted was "implement a parallel,
> independent stack".  This raised the adoption barrier to be as high as
> possible. Might as well have been an OSI stack.
Some of the coexistence mechanisms (e.g. IPv4-mapped IPv6 addresses)
would have been effectively impossible with OSI NSAP addressing.
I dread to think what NAT between IPv4 and CLNP would have looked
like. It really would have ships in the night, with icebergs.

Actually we never said it should be an independent stack. In fact,
RFC1671 said:
"This requirement does not imply that IPng hosts really have two
completely separate IP implementations (dual stacks and dual APIs),
but just that they behave as if they did."
I believe that is exactly what happened.

> 
> Note if there had been serious concern for minimizing adoption effort,
> an example alternative that could have been adopted -- especially if
> Steve Deering's original proposal had been adopted -- would have been to
> make IPv4 address space a subset of IPv6 address space.

My recollection, without looking at the archives, is that this was
*explicitly* rejected as a Bad Idea because it would have, by definition,
have imported the IPv4 BGP-4 "swamp" into the IPng default-free zone.
Whether that was the right decision could be analyzed today, but it was
very clear at that time.

> 
> This would have eliminated any initial administrative effort, with
> gateways could function largely as interoperable routers, and a minimum
> of address syntax adaptation.
> 
> That is, IPv6 address administration could have been entirely removed as
> an initial adoption barrier.

The real-world problem for a long time was that available commercial
enterprise IPAM (IP Address Management) systems could not handle addresses
larger than 32 bits. Whether the 128 bit space was a superset of the
32 bit space was a minor matter. As a matter of fact it *is* a superset;
that's the point of IPv4-mapped IPv6 addresses, and that format is very
useful for IPAM implementers. You even find it, bizarrely and mistakenly,
in DNS. See the "Bogus" column at https://www.employees.org/~dwing/aaaa-stats/
But on the wire, an IPv4-mapped IPv6 address leads to IPv4 packets.
  
> But as I say, that's just an example of a difference between taking
> barriers to adoption as a serious concern, versus what actually happened.

The main barrier to adoption has always been "if it ain't broke, don't
fix it." Where we see adoption is where people have hit IPv4 brokenness.

    Brian