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

Tue Nov 22 19:38:07 UTC 2022

> On Nov 22, 2022, at 2:13 PM, Tom Beecher <beecher at beecher.cc> wrote:
> 
>> Serious consideration requires a serious proposal - I don’t think we’ve seen one yet.
> 
> I would posit that draft-schoen-intarea-unicast-240-03 ( https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ ) should be considered a serious proposal, in so much as what is proposing is the most direct:
> 
> - Redesignate 240/4 from RESERVED - Future Use to be available for allocation as 'standard' IPv4 addresses. 
> 
> I personally disagree with their position, as does the IETF, so it doesn't appear there will be any more movement on it, but I do believe that the idea itself was serious.

Tom - 

Well, at least it is a readable and clear proposal, but again it lacks any meaningful treatment of interoperability – instead comparing the de-reservation and potential for future use of 240/4 with the various de-bogon efforts that were predominantly efforts to get long-time _already valid_ address space to be properly treated in the Internet –  

   Such a host might be inaccessible by some devices either on its local
   network segment or elsewhere on the Internet, due to a combination of
   host software limitations or reachability limitations in the network.
   IPv4 unicast interoperability with 240/4 can be expected to improve
   over time following the publication of this document.  Before or
   after allocations are eventually made within this range,
   "debogonization" efforts for allocated ranges can improve
   reachability to the whole address block.  Similar efforts have
   already been done by Cloudflare on 1.1.1.1 [Cloudflare], and by RIPE
   Labs on 1/8 [RIPElabs18], 2a10::/12 [RIPElabs2a1012], and 128.0/16
   [RIPElabs128016].  The Internet community can use network probing
   with any of several measurement-oriented platforms to investigate how
   usable these addresses are at any particular point in time, as well
   as to localize medium-to-large-scale routing problems.  (Examples are
   described in [Huston], [NLNOGRing], and [Atlas].)  Any network
   operator to whom such addresses are made available by a future
   allocation will have to examine the situation in detail to determine
   how well its interoperability requirements will be met.

I.w.  the suggestion that the utilization of 240/4 space will solely be an issue for the "operator to whom such addresses are made available “ to examine (with respect to their requirements) really completely ignores the fact that such address space utilized in the production Internet will experience unpredictable intermittent communication failures for years (if not decades) to come, and hence it an issue of concern for the entire operations community, not just those who may receive such allocations.   Again, the IETF's host and router requirements documents has specified discard of these packets since the 90’s, so there needs to be a clear model for transition (rather than vague statements left to the reader)l that covers how network operators at both ends will know of the failure (and workarounds) when the use of these addresses results in failed communication.  Absent such, I’m not sure why anyone should give consideration to this Internet draft– it can’t be safely deployed in the actual real-world Internet, making it more of a paper chimera than a serious proposal. 

Thanks,
/John

p.s.  Disclaimer(s):  my views alone - any hazards seen in them may be much closer than they appear…

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