Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[Eliot Lear <lear () ofcourseimright com>]

Greg

Thanks for posting the links.  Our old draft seems to have largely had 
its intended effect without ever having been issued as an RFC 
(moohaha).  Most implementations don't hardcode 240/4 into a bogon 
filter.  We had at the time left open what next steps should be.

So what's the road to actually being able to use this space?  It 
depends.  If you want to use it for your interior, and return 
routability beyond your AS and external in-addr service is NOT 
important, all that stops you today is whatever set of issues you find 
in your own back yard.

If you want to allocate space to customers or need in-addr/return 
routability, obviously that's More Work that should not be 
underestimated.  240/4 appears in a number of bogon filters, not all of 
which are controlled by people tracking operator lists or the IETF.

And that complicates matters in terms of whether the space should be 
moved to a unallocated or treated like 10/8.  At least the latter seems 
to match the testing that has thus far been performed.

Eliot


On 23.11.21 02:01, Greg Skinner via NANOG wrote:
> > On Nov 21, 2021, at 1:20 PM, William Herrin <bill () herrin us> wrote:
> >
> > On Sun, Nov 21, 2021 at 4:16 AM Eliot Lear <lear at 
> > ofcourseimright.com <http://ofcourseimright.com>> wrote:
> > > In 2008, Vince Fuller, Dave Meyer, and I put together
> > > draft-fuller-240space, and we presented it to the IETF. There were
> > > definitely people who thought we should just try to get to v6, but what
> > > really stopped us was a point that Dave Thaler made: unintended impact
> > > on non-participating devices, and in particular CPE/consumer firewall
> > > gear, and at the time there were  serious concerns about some endpoint
> > > systems as well.  Back then it might have been possible to use the space
> > > as part of an SP interior, but no SP demonstrated any interest at the
> > > time, because it would have amounted to an additional transition.
> >
> > Hi Eliot,
> >
> > I wasn't in the working group so I'll take your word for it. Something
> > rather different happened later when folks on NANOG discovered that
> > the IETF had considered and abandoned the idea. Opinion coalesced into
> > two core groups:
> >
> > Group 1: Shut up and use IPv6. We don't want the IETF or vendors
> > distracted from that effort with improvements to IPv4. Mumble mumble
> > titanic deck chairs harrumph.
> >
> > Group 2: Why is the IETF being so myopic? We're likely to need more
> > IPv4 addresses, 240/4 is untouched, and this sort of change has a long
> > lead time. Mumble mumble heads up tailpipes harrumph.
> >
> >
> > More than a decade later, the "titantic" is shockingly still afloat
> > and it would be strikingly useful if there were a mostly working /4 of
> > IP addresses we could argue about how best to employ.
> >
> > Regards,
> > Bill Herrin
> >
> >
> > --
> > William Herrin
> > bill at herrin.us <http://herrin.us>
> > https://bill.herrin.us/
>
> I agree, generally speaking.  IMO, it’s unfortunate that these 
> addresses are being held in “limbo” while these debates go on.  I’m 
> not complaining about the debates per se, but the longer we go without 
> resolution, these addresses can’t be put to any (documented) use.
>
> There’s background information available that might be helpful to 
> those who haven’t yet seen it:
>
> https://datatracker.ietf.org/doc/slides-70-intarea-4/ (links to the 
> draft-fuller-240space slides from IETF 70)
> https://datatracker.ietf.org/doc/minutes-70-intarea/ (IETF 70 INTAREA 
> meeting minutes)
> https://mailman.nanog.org/pipermail/nanog/2007-October/thread.html (NANOG 
> October 2007 mail archives, containing links to the “240/4” thread)
> https://puck.nether.net/pipermail/240-e/ (the 240-e archives)
> https://mailarchive.ietf.org/arch/browse/int-area/ (IETF INTAREA 
> archives, containing comments on the 240space draft and related 
> issues, roughly in the same time frame as in the previous links)
>
> —gregbo

Attachment: OpenPGP_signature
Description: OpenPGP digital signature