Mailing List Archive

* aychen@avinta.com (Abraham Y. Chen) [Fri 12 Jan 2024, 13:09 CET]:
>    EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is
>reusable for each isolated geographical area. Thus, there is no
>"Burn-rate" to talk about.

You have posted this statement like five times now in the past two days.

Who is asking for this expansion of 100.64/10 (which you misspelled,
by the way)? Where are the claims that the amount of private space
behind a CGNAT is the limiting factor in CGNAT deployments?

[five meters of superfluous quote history snipped]


-- Niels.

>
> EzIP proposes


EzIP is a concept that has zero interest in the field , aside from Mr. Chen
himself. It's been discussed and analysed. Legitimate issues have been
raised, and Mr. Chen simply handwaves them away.

The only IETF actions on it has been Mr. Chen refreshing the draft every 6
months.

There's really no point in talking about what it is , or what it wants to
do, when it has the same force and effect as the legendary IPv10 draft, and
April Fools RFCs.

On Fri, Jan 12, 2024 at 7:08?AM Abraham Y. Chen <aychen@avinta.com> wrote:

> Hi, Owen:
>
> 1) "... it seemed the 240/4 lasting a year was an optimistic count. ":
>
> EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is
> reusable for each isolated geographical area. Thus, there is no "Burn-rate"
> to talk about.
>
> Regards,
>
>
> Abe (2024-01-12 07:07)
>
>
> On 2024-01-11 19:10, Owen DeLong wrote:
>
> 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
> optimistic count.
>
> Owen
>
>
> On Jan 11, 2024, at 13:15, Christopher Hawker <chris@thesysadmin.au>
> <chris@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 <beecher@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 <chris@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.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
>>>>
>>>
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> Virus-free.www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> <#m_-2250022354537390834_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Hi, Niels:

0)    Your sender name is in an unusual format. It becomes just the
generic NANOG address as the recipient for me to MSG send to.

1)   "  You have posted this statement like five times now in the past
two days.   ":

    Perhaps so, I have been responding to numerous comments since my
initial post in response to Karim Mekkaoui's inquiry. Since I have to
address each individually, some from different angles, while some others
are new discussions or debates, it is no surprise that the same
expression has been used more than once to deal with them respectively.
If you count this specific item on the sideline, you definitely will see
the repeats. The important criterion here is whether any of them are out
of the context? (To be honest with you, I myself feel that I have been
playing broken records on this pretty simple and straightforward topic.)

2)   " Who is asking for this expansion of 100.64/10 (which you
misspelled, by the way)?    ":

    Thanks for catching the typo. My understanding is that there is a
general desire (human nature) to get a larger netblock than 100.64/10 in
CG-NAT. This could be used for either growing market or less dynamic
reassignment. The 240/4 can provide additional benefits to CG-NAT
operations such as static addressing that no one has realized possible.
So, I am putting the solution on the table. This is a basic process of
sharing the new discoveries. Is there anything wrong with the process?
On the other hand, if RFC6598 had picked 240/4 instead of 100.64/10 as
the netblock, we do not need today's discussions.

Regards,

Abe (2024-01-13 12:14)


On 2024-01-12 07:34, Niels Bakker wrote:
> * aychen@avinta.com (Abraham Y. Chen) [Fri 12 Jan 2024, 13:09 CET]:
>>     EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which
>> is reusable for each isolated geographical area. Thus, there is no
>> "Burn-rate" to talk about.
>
> You have posted this statement like five times now in the past two days.
>
> Who is asking for this expansion of 100.64/10 (which you misspelled,
> by the way)? Where are the claims that the amount of private space
> behind a CGNAT is the limiting factor in CGNAT deployments?
>
> [five meters of superfluous quote history snipped]
>
>
>     -- Niels.



--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

* aychen@avinta.com (Abraham Y. Chen) [Sat 13 Jan 2024, 18:16 CET]:
>0)    Your sender name is in an unusual format. It becomes just the
>generic NANOG address as the recipient for me to MSG send to.

Your numbered lists are 0-indexed. So clever! Also, your MUA
seems to understand Mail-Followup-To, which is nice.


>    Thanks for catching the typo. My understanding is that there is a
>general desire (human nature) to get a larger netblock than 100.64/10
>in CG-NAT. This could be used for either growing market or less
>dynamic reassignment. The 240/4 can provide additional benefits to

So nobody in particular is asking for this. Thanks for confirming.


>CG-NAT operations such as static addressing that no one has realized
>possible. So, I am putting the solution on the table. This is a basic
>process of sharing the new discoveries. Is there anything wrong with
>the process? On the other hand, if RFC6598 had picked 240/4 instead of
>100.64/10 as the netblock, we do not need today's discussions.

What's wrong with the process is that you're wasting the time of a lot
of people on this mailing list with this crusade that has already
veered into personal attacks such as when you questioned Randy Bush's
experience. In that respect it would indeed have been better for
RFC6598 to have picked 240/4 in the sense that it would have saved us
94 out of the 104 mails currently in this thread and, unfortunately,
counting.


-- Niels.