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

[Dave Crocker]

On 8/10/2023 8:08 PM, Brian E Carpenter wrote:
> 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/ ?
I think it was IPAE, though they don't show Bob as co-chair:

IP Address Encapsulation (ipae) <#>

🔗 https://datatracker.ietf.org/wg/ipae/about/ 
<https://datatracker.ietf.org/wg/ipae/about/>


However the associated ID does have us as co-authors:

Logo of the IETF

IP Address Encapsulation (IPAE): A Mechanism for Introducing a New IP <#>

The Internet seeks to increase the amount of IP address space that is 
available for hosts and to decrease the amount of table storage that is 
required by routers. Ultimately, the current IP (IP version 4) and any 
replacement are inherently incompatible and movement to the new version 
requires very substantial change to the IP installed base. This 
specification describes an approach which retains as much software, 
operations and training as possible, and minimizes overall operational 
disruption by allowing subsets of the Internet to carry the new-format 
Internet datagrams inside old-style IPv4 datagrams, using a technique 
called 'IP Address Encapsulation' (IPAE). This permits incremental and 
asynchronous introduction and makes transition entirely optional for 
portions of the Internet infrastructure. It further permits early 
reduction to routing table size.

🔗 https://datatracker.ietf.org/doc/draft-ietf-ipae-new-ip/ 
<https://datatracker.ietf.org/doc/draft-ietf-ipae-new-ip/>

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

It is always easy to make design choices that prevent something, as well 
as allow something.

Note that I referred to Steve's original proposal. And my suggestion of 
using a subset and allocate it to IPv4.

Your comment references a scheme outside of that.


>
> Actually we never said it should be an independent stack. In fact,

But the pragmatics basically dictated it.


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

Perhaps my point about taking issues out of critical path, where 
possible, was missed?

There was a pervasive feeling that all sorts of problems had to be fixed 
simultaneously.  When working at scale, that tends to be a problematic 
choice.  30 years later, one would think the lesson would be 
self-explanatory.


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

Except that my point was that it could have been central, in terms of 
operational transition focus.

You are merely citing yet-another piece that would have benefited from 
being taken out of initial adoption critical path.



d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker at mastodon.social