Alternative Re: ipv4/25s and above Re: 202211210951.AYC

Tue Nov 22 05:18:19 UTC 2022

> On Nov 21, 2022, at 11:12 PM, Joe Maimon <jmaimon at jmaimon.com> wrote:
> 
> John Curran wrote:
>> ..
>> That may (or may not) lead to you experiencing what you consider reasonable support costs for your customers, but as we all know, everyone else has customers who are the other ends of those connections who will call their ISP’s customer support line trying to figure out why they can’t get your customer (or can only get there intermittently) – so it appears that your proposed use of de-reserved and repurposed class E space has some real interesting implications about imputed support burdens on everyone else – if indeed the intended use case is includes providing connectivity to the public Internet.
>> 
>> If you’re not proposing public Internet use, and rather just within your own administrative domain, then feel free to do – talk to your vendors, get them to support it, and turn it on. As you already noted, we really don’t centrally decide how everyone runs their own network – so using it locally is fine since it doesn’t presume others will diagnose connection problems with your customer traffic that quite reasonably is categorized as invalid.
>> 
>> Thanks,
>> /John
>> 
>> p.s. Disclaimer:  my views alone. Note: contents may be hot - use caution when opening.
>> 
>> 
> 
> Right now the gossiped growing use of 240/4 in private and non standardized fashions jeopardizes any potential use of it just as much as the factors you describe.

Joe - 

That may be the case - I have no data either way, but it would not be surprising if some folks were paying very careful attention to their vendor support of 240/4 routing so that they can use this address space in a private context.  

However, I still have not heard any reasonable explanation for how connections using de-reserved 240/4 space in a public scope will be operationally viable, given that there will always be devices which do not forward such packets…  

> In either event, my main point of contention is in the lack of willingness for serious and prudent consideration. Such as along the lines of what you have brought up.

You have an opportunity now - please explain how such connections will not pose an operations nightmare for the rest of the public Internet – it is not at all apparent how such is avoided if 240/4 is changed from reserved to general purpose (if that’s what you are suggesting that we should be doing.) 

Of course the other alternative is what Abe has been suggesting (repeatedly):  note that it is _not_ using 240/4 for general purpose address space, but rather for their "Adaptive IPv4 Address Space” <https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/> mapping protocol.  It seems to suffer from the same assumption of unmolested 240/4 transit in the public Internet (despite the current specification of such addresses as invalid) but then adds some further complication…   something akin to CG-NAT but with their new EZ-IP protocol and “semi-public routers” as gateways doing the address mapping function. 

I am all for serious discussion of either of these interesting proposals, but if we’re going to seriously discuss such being deployed in the real-world then it had best start with the question of how they will handle the current Internet which frequently drops packets containing 240/4 addresses as invalid and will be doing so in places for many years to come.  The upgrades in the real world to address that invalid-drop situation will take quite a while to happen (and note that time starts only after there’s an actual consensus for change in this regard), so  – just as it was with IPv6 – it's incumbent on those proposing change to explain how interoperability occurs during the transition period. 

Thanks,
/John

p.s.   Disclaimer(s):  my views alone - this message made from 100% recycled electrons. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221122/01540f81/attachment.html>