On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher 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 / vers
Dave Taht wrote on 11/01/2024 09:40:
240/4 is intensely routable and actually used in routers along hops
inside multiple networkstoday, but less so as a destination.
240/4 is fine for private use, but the OP needed publicly routable IP
addresses, which 240/4 are definitely not.
Nick
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 th
On Thu, 11 Jan 2024 at 12:57, Christopher Hawker wrote:
> 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
> w
Saku Ytti writes:
> We don't need to extend IPv4, we need to figure out why we are in this
> dual-stack mess, which was never intended, and how to get out of it.
Few have figured out how to reliably deliver IPv4 over a IPv6 network,
and customers need IPv4 more than they need IPv6.
There is no
Christopher Hawker wrote on 11/01/2024 10:54:
Reclassifying this space, would add 10+ years onto the free pool for
each RIR
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
+1 to the Christopher comment
> On 11-Jan-2024, at 16:24, 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
>
> 1)Your caution advice to Karim is professional. With a lot of
> convoluted topics behind it, however, the net result is basically
> discouraging the listener from investigating the possibilities.
No, it is not.
The original question from Karim was about acquiring some IPv4 space. We
can
Hi, Michael:
1) " ... While you may be able to get packets from point A to B in a
private setting, using them might also be .. a challenge. ... ":
EzIP uses 240/4 netblock only within the RAN (Regional Area
Network) as "Private" address, not "publicly" routable, according to the
con
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-201
On Thu, Jan 11, 2024 at 12:26 PM Tom Beecher 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.
>>
Abraham,
You're arguing semantics instead of the actual point. Residential customers
want Internet access, not intranet access. Again, VRFs are plentiful and so are
CG-NAT firewall appliances or servers to run those VMs.
Save yourself the time and effort on this and implement IPv6.
Ryan
_
*NANOG 90 Keynotes *
*Rob Shakir + Mark Johnson Take the N90 Stage*
Did you know North Carolina boasts a rich computer science and
communications legacy? Or do you want a more candid look at the evolution
of the next generation of Google's management (and control) planes?
Whether you want to delv
>
> Thought that 12 month argument was purest BS in light of all the
> events since 2011. We have been "out" of IPv4 space for many years
> now, and there is a functioning market for IPv4 space that seems to be
> serving the purpose. 240/4 is only marginally useful today, but useful
> it is.
>
Su
On Thu, Jan 11, 2024 at 9:29 AM Tom Beecher 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.
>> Reclas
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
ARIN has been gutting IPv4 free-pool based policy left and right lately… Other
RIRs have not been quite as aggressive, but have done some similar things.
This, if for no other reason, makes it a bad idea to suddenly restore RIR IPv4
free pools.
Just my $0.02.
I’ve got as little power in the IE
At the time this was being considered, ARIN, APNIC, and RIPE NCC were each
burning approximately 6 /8s per year. 240/4 is 16x/8, so with an RIR burn rate
of 18 /8s per year (not counting LACNIC and AFRINIC which each accounted for <1
per year IIRC), it seemed the 240/4 lasting a year was an opti
Hi, Vasilenko:
1) ... These “multi-national conglo” has enough influence on the IETF
to not permit it.":
As classified by Vint Cerf, 240/4 enabled EzIP is an overlay
network that may be deployed stealthily (just like the events reported
by the RIPE-LAB). So, EzIP deployment does not n
Hi, Forrest:
0) Thanks for your in-depth analysis.
1) However, my apologies for not presenting the EzIP concept
clearer. That is, one way to look at the EzIP scheme is to substitute
the current 100.64/10 netblock in the CG-NAT with 240/4. Everything
else in the current CG-NAT setup st
Hi, Nick:
1) Perhaps it will be easier to visualize the EzIP scheme by
replacing the 100.64/10 netblock with 240/4, so that the CG-NAT is
enhanced, starting from being 64 fold bigger in address capacity.
Regards,
Abe (2024-01-11 22:42)
On 2024-01-11 05:25, Nick Hilliard wrote:
Dave Ta
Not going to lie, EzIP just seems to be some version of destination/source
NAT on steroids.
Regards,
Christopher Hawker
On Fri, 12 Jan 2024 at 14:36, Abraham Y. Chen wrote:
> Hi, Forrest:
>
> 0)Thanks for your in-depth analysis.
>
> 1) However, my apologies for not presenting the EzIP c
Hi, Nick:
1) " ... So that suggests that 240/4 would provide a little more than
1Y of consumption, ... ":
EzIP proposes to use 240/4 CG-NAT's 100.64/10. So, 240/4 will be
reusable worldwide and no need to consider consumption rate.
Regards,
Abe (2024-01-11 23:06)
On 2024-01-11 0
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
int
Yes, my suggestion wasn't to permit 240/4 for use in EzIP, rather it was
for it to be reclassified as Unicast (instead of Reserved) space for
delegations by RIRs to members.
100.64/10 will never go back into the free pool, it's too heavily
integrated into CG-NATted networks. The technical involvem
Hi, Saku:
1) " ...we need to figure out why we are in this dual-stack mess,
which was never intended, and how to get out of it. ... ":
After our team worked out the EzIP scheme and then classified by
Vint Cerf as an overlay network, more than a couple of the
considerations that you ou
Abraham,
You may not need permission from the IETF, but you effectively need it from
every networking vendor, hardware vendor, and OS vendor. If you do not have buy
in from key stakeholders, it's dead-on arrival.
Ryan
From: NANOG on behalf of Abraham Y.
Chen
> We don't need to extend IPv4, we need to figure out why we are in this
> dual-stack mess, which was never intended, and how to get out of it.
it was intended. it was the original transition plan. like many things
about ipv6, it could have been a bit better thought out.
randy
>> We don't need to extend IPv4, we need to figure out why we are in this
>> dual-stack mess, which was never intended, and how to get out of it.
>
> it was intended. it was the original transition plan. like many things
> about ipv6, it could have been a bit better thought out.
What was not
The problem isn't the quantity of "inside" CG-NAT address space. It's the
existence of CG-NAT at all.
It doesn't matter if the available space is a /12 or a /4, you still need
something to translate it to the public internet. The existence of that
CG-NAT box is a thorn in every provider's side
On 12/01/24 06:41, Giorgio Bonfiglio via NANOG wrote:
We don't need to extend IPv4, we need to figure out why we are in this
dual-stack mess, which was never intended, and how to get out of it.
it was intended. it was the original transition plan. like many things
about ipv6, it could have
31 matches
Mail list logo
