Hi, Christopher:
1) " ... I would like to see 240/4 reclassified as unicast space ...
":
We are in agreement with this first part.
2) " ... 2 x /8s delegated to each RIR with the /8s for AFRINIC ... ":
This second part is not what EzIP is proposing, because it will run
into the old trap of "quickly used up". Instead, 240/4 should be used to
replace 100.64/10 in creating RANs (Regional Area Networks) that are the
same as the existing CG-NAT clusters but 64 fold bigger. So that 240/4
is reused worldwide like the RFC6598 netblocks, plus other possible
benefits such as putting 100.64/10 back into the allocatable pool
(Wasn't this pulled out of ARIN for worldwide use?) doing so, we do not
have 240/4 exhaustion issue to consider.
Regards,
Abe (2024-01-11 23:40)
On 2024-01-11 05:54, Christopher Hawker 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.taht@gmail.com> wrote:
>
> On Wed, Jan 10, 2024 at 11:06?AM Tom Beecher <beecher@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
> <imb@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
>
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
1) " ... I would like to see 240/4 reclassified as unicast space ...
":
We are in agreement with this first part.
2) " ... 2 x /8s delegated to each RIR with the /8s for AFRINIC ... ":
This second part is not what EzIP is proposing, because it will run
into the old trap of "quickly used up". Instead, 240/4 should be used to
replace 100.64/10 in creating RANs (Regional Area Networks) that are the
same as the existing CG-NAT clusters but 64 fold bigger. So that 240/4
is reused worldwide like the RFC6598 netblocks, plus other possible
benefits such as putting 100.64/10 back into the allocatable pool
(Wasn't this pulled out of ARIN for worldwide use?) doing so, we do not
have 240/4 exhaustion issue to consider.
Regards,
Abe (2024-01-11 23:40)
On 2024-01-11 05:54, Christopher Hawker 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.taht@gmail.com> wrote:
>
> On Wed, Jan 10, 2024 at 11:06?AM Tom Beecher <beecher@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
> <imb@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
>
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com