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

[Brian E Carpenter]

I think this subthread is about over, but, yes, IPAE was around
and I cited it in draft-carpenter-aeiou-00. However, the consensus
(which it wasn't my job to assess) seemed to be that the IETF
wanted to make a clean break. If we'd done something like IPAE,
EIP (RFC1385) or AEIOU, things would certainly have been different.
Whether they would have been better is hard to say.

Regards
    Brian Carpenter

On 11-Aug-23 15:45, Dave Crocker wrote:
> 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
>