On Jan 11, 2024, at 13:15, Christopher Hawker <ch...@thesysadmin.au>
wrote:
Hi Tom,
I'm not too sure I understand where the idea came from that 2 x /8
would only last one year. APNIC received their final allocation of
the 103/8 prefix from ICANN/IANA on 03 February 2011, and commenced
delegating space from the prefix on 18 April 2011. With the right
policies in place, it can be well and truly extended.
Looking at an APNIC Blog article authored by Guangliang Pan on 09
October 2023
(https://blog.apnic.net/2023/10/09/nearing-the-end-of-103-8/), as of
the time the article was written there were 121 available /24
prefixes from the 103/8 pool still available. Not a great deal in the
grand scheme of things, however, it demonstrates that policy works in
preserving what finite resources we have left, and that a 2 x /8 will
last a lot longer than one year.
I could say the same, that 2 x /8 lasting a little more than a year
is an extremely remote and highly unlikely assumption. Bear in mind
that APNIC policy was changed 1/2 way through to drop 103/8
delegations from a /22 to a /23. Based on this, 65,536 x /23
delegations can be made to new members and as Peter said, if
post-exhaustion policy is applied to 240/4 it'll go an extremely long
way.
Regards,
Christopher Hawker
On Fri, 12 Jan 2024 at 04:26, Tom Beecher <beec...@beecher.cc> wrote:
Christopher-
Reclassifying this space, would add 10+ years onto the free
pool for each RIR. Looking at the APNIC free pool, I would
estimate there is about 1/6th of a /8 pool available for
delegation, another 1/6th reserved. Reclassification would
see available pool volumes return to pre-2010 levels.
Citing Nick Hilliard from another reply, this is an incorrect
statement.
on this point: prior to RIR depletion, the annual global
run-rate on /8s
measured by IANA was ~13 per annum. So that suggests that
240/4 would
provide a little more than 1Y of consumption, assuming no demand
back-pressure, which seems an unlikely assumption.
I share Dave's views, I would like to see 240/4 reclassified
as unicast space and 2 x /8s delegated to each RIR with the
/8s for AFRINIC to be held until their issues have been resolved.
This has been discussed at great length at IETF. The consensus on
the question has been consistent for many years now; doing work
to free up 12-ish months of space doesn't make much sense when
IPv6 exists, along with plenty of transition/translation
mechanisms. Unless someone is able to present new arguments that
change the current consensus, it's not going to happen.
On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker
<ch...@thesysadmin.au> wrote:
There really is no reason for 240/4 to remain "reserved". I
share Dave's views, I would like to see 240/4 reclassified as
unicast space and 2 x /8s delegated to each RIR with the /8s
for AFRINIC to be held until their issues have been resolved.
Reclassifying this space, would add 10+ years onto the free
pool for each RIR. Looking at the APNIC free pool, I would
estimate there is about 1/6th of a /8 pool available for
delegation, another 1/6th reserved. Reclassification would
see available pool volumes return to pre-2010 levels.
https://www.apnic.net/manage-ip/ipv4-exhaustion/
In the IETF draft that was co-authored by Dave as part of the
IPv4 Unicast Extensions Project, a very strong case was
presented to convert this space.
https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html
Regards,
Christopher Hawker
On Thu, 11 Jan 2024 at 20:40, Dave Taht <dave.t...@gmail.com>
wrote:
On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher
<beec...@beecher.cc> wrote:
>>
>> There's a whole bunch of software out there that makes
certain
>> assumptions about allowable ranges. That is, they've
been compiled with
>> a header that defines ..
>
>
> Of course correct. It really depends on the vendor /
software / versions in an environment. A lot of vendors
removed that years ago, because frankly a lot of large
networks have been using 240/4 as pseudo RFC1918 for
years. Others have worked with smaller vendors and open
source projects to do the same.
>
> It's consistently a topic in the debates about 240/4
reclassification.
There's debates still? I gave up. After making 240/4 and
0/8 work
across all of linux and BSD and all the daemons besides
bird (which
refused the patch , I took so much flack that I decided I
would just
work on other things. So much of that flack was BS - like
if you kill
the checks in the OS the world will end - that didn't
happen. Linux
has had these two address ranges just work for over 5
years now.
240/4 is intensely routable and actually used in routers
along hops
inside multiple networks today, but less so as a destination.
I would really like, one day, to see it move from
reserved to unicast
status, officially. I would have loved it if 0/8 was used
by a space
RIR, behind CGNAT, for starters, but with a plan towards
making it
routable. I am not holding my breath.
The principal accomplishment of the whole unicast
extensions project
was to save a nanosecond across all the servers in the
world on every
packet by killing the useless 0/8 check. That patch paid
for itself
the first weekend after that linux kernel deployed. It is the
simplest, most elegant, and most controversial patch I
have ever
written.
https://news.ycombinator.com/item?id=20430096
>
> On Wed, Jan 10, 2024 at 10:45 AM Michael Butler
<i...@protected-networks.net> wrote:
>>
>> On 1/10/24 10:12, Tom Beecher wrote:
>> > Karim-
>> >
>> > Please be cautious about this advice, and understand
the full context.
>> >
>> > 240/4 is still classified as RESERVED space. While
you would certainly
>> > be able to use it on internal networks if your
equipment supports it,
>> > you cannot use it as publicly routable space. There
have been many
>> > proposals over the years to reclassify 240/4, but
that has not happened,
>> > and is unlikely to at any point in the foreseeable
future.
>>
>> While you may be able to get packets from point A to B
in a private
>> setting, using them might also be .. a challenge.
>>
>> There's a whole bunch of software out there that makes
certain
>> assumptions about allowable ranges. That is, they've
been compiled with
>> a header that defines ..
>>
>> #define IN_BADCLASS(i) (((in_addr_t)(i) & 0xf0000000)
== 0xf0000000)
>>
>> Michael
>>
--
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos
