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

Tue Nov 22 04:12:57 UTC 2022

John Curran wrote:
>
>> On Nov 21, 2022, at 7:18 PM, Joe Maimon <jmaimon at jmaimon.com> wrote:
>> … Further, presentment of options in this fashion presumes that we 
>> have some ability to control or decide how engineering efforts across 
>> the entirety of the internet should be spent.
>
> Joe -
>
> In the snippet above you allude to a very important aspect of the 
> Internet that is rather germane to this discussion – ii.e. that we 
> really don’t really have any "ability to control or decide how 
> engineering efforts across the entirety of the internet should be 
> spent” –, but then you don’t really work through what that fact means 
> for realistic outcomes of class E space re-utilization…
>
True

>
> As you alluded to, we really don’t have any "ability to control or 
> decide how engineering efforts across the entirety of the internet 
> should be spent”, and the practical implications of this fact is that 
> there will always be many devices out there in production that will 
> not pass IP packets with class E addresses in them…   (just as there’s 
> always going to be some devices, somewhere that don’t know about IPv6.)
To what extent will this be? And to what extent could it have been had 
this been seriously considered dozen+ years ago? We wont really know 
until we can get serious about it.
>
> Of course, the difference is that with IPv6 we can attempt a 
> connection and then fall back to IPv4, and further that devices out 
> there either support and are configured for IPv6 routing, or they are 
> not - networks rather quickly learn not to announce (via routing & 
> DNS) IPv6 connectivity for devices without it actually being in place 
> and operational or having solid IPv4 fall-back and relying fast 
> fallback/happy eyeballs.

This is a very fair point. Or perhaps we can have reverse happy eyeballs 
for IPv4 fallling back to sub-optimal auto-tunneled IPv6?
>
> With your using repurposed class E address space in the headers, your 
> customers with such addresses are rather unlikely to ever know why a 
> connection won’t establish – or why existing connections sometime fail 
> mid-stream – as it only takes a single non-conforming device along the 
> ever-changing path through any number of network operators to 
> resulting in the silent drop of that packet.

I am not that sure about silent, presumably traceroute will be just as 
(un)usable.

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

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.

So thank you.

Best,

Joe