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