William Herrin wrote:

...

Ever since we started our study, we were quite puzzled by why the 240/4 netblock was regarded so special? Why no one could tell us what led to its current status, and even after IPv4 was set to transition to IPv6?

https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia...

Which leads to RFC 1112 section 4, the disposition of which last changed in 1989.

IIRC, at some time, perhaps when CIDR was deployed widely and having something other than IPv4 was a hot topic, there was a discussion on releasing 240/4 in IETF. Reasonings against it were that the released space will be consumed quickly (at that time, NAT already existed but was uncommon) and that new IP will be designed and deployed quickly (we were optimistic). Masataka Ohta

Exactly, many previous unsuccessful discussions at IETF about 240/4: IPv6 is the only viable long-term solution. The effort to “reinvent” any part of IPv4 or patches to it, then test that everything keeps working as expected, versus the benefits and gained time, it is much best invested in continue the IPv6 deployment which is already going on in this region and the rest of the world. It would not make sense, to throw away all the efforts that have been already done with IPv6 and we should avoid confusing people. I just think that even this thread is a waste of time (and will not further participate on it), time that can be employed in continue deploying IPv6. Regards, Jordi @jordipalet El 12/3/22 6:32, "NANOG en nombre de Greg Skinner via NANOG" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de nanog@nanog.org> escribió: On Mar 10, 2022, at 8:44 PM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote: IIRC, at some time, perhaps when CIDR was deployed widely and having something other than IPv4 was a hot topic, there was a discussion on releasing 240/4 in IETF. Reasonings against it were that the released space will be consumed quickly (at that time, NAT already existed but was uncommon) and that new IP will be designed and deployed quickly (we were optimistic).                                                                                                Masataka Ohta There have been many discussions about 240/4 in the IETF. For some examples, query “240/4” in the ‘ietf’ mail archive on mailarchive.ietf.org. —gregbo ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

Because it is a single Internet, and what we do in some parts of Internet will affect others? Because, at least in my case, I'm investing my efforts in what it seems to be the best in the long-term for the global community, not my personal preferences? El 12/3/22 9:10, "William Herrin" <bill@herrin.us> escribió: On Fri, Mar 11, 2022 at 11:58 PM JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote: > Exactly, many previous unsuccessful discussions at IETF about 240/4: IPv6 is the only viable long-term solution. > > The effort to “reinvent” any part of IPv4 or patches to it, then test that everything keeps working as expected, versus the benefits and gained time, it is much best invested in continue the IPv6 deployment which is already going on in this region and the rest of the world. > > It would not make sense, to throw away all the efforts that have been already done with IPv6 and we should avoid confusing people. > > I just think that even this thread is a waste of time (and will not further participate on it), time that can be employed in continue deploying IPv6. Why are so many otherwise smart engineers so vulnerable to false dilemma style fallacies? There's no "either/or" here. It's not a zero sum game. If you don't see value in doing more with IPv4 then why don't you get out of the way of folks who do? Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/ ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

On Sun, Mar 13, 2022 at 1:22 AM Joe Maimon <jmaimon@jmaimon.com> wrote:

The true dilemma is that any amelioration of IPv4 scarcity may indeed contribute to further delaying mass global IPv6 adoption, regardless of whose effort and time is involved.

And I find advocating for that to be wrong and perhaps to some extent, immoral. Unlikely to be productive. And potentially counter-productive.

https://xkcd.com/2592/ -- William Herrin bill@herrin.us https://bill.herrin.us/

Christopher Morrow wrote:

On Sun, Mar 13, 2022 at 10:39 AM William Herrin <bill@herrin.us <mailto:bill@herrin.us>> wrote:

On Sun, Mar 13, 2022 at 1:22 AM Joe Maimon <jmaimon@jmaimon.com <mailto:jmaimon@jmaimon.com>> wrote: > The true dilemma is that any amelioration of IPv4 scarcity may indeed > contribute to further delaying mass global IPv6 adoption, regardless of > whose effort and time is involved.

What's the actual proposal for 240/4? Is it: "Make this usable by me on my /intranet/?" Is it: "Make this usable across the internet between bespoke endpoints?" Is it: "Make this usable for any services/users on the wider internet, treat it like any other unicast ipv4 address?" Is it: "Something entirely different"

The first 2 probably already work today, if you take the time to control the horizontal and vertical of your networking space. The last is probably workable, given enough time to flush out all of the endpoints which (today) probably treat 240/4 as 'special'.

240/4 has a special problem. The problem is that the smallest bit of cooperation from the broader community, other than those expending effort on 240/4 directly is required. Mostly so that any potential use of 240/4 continues to be standardized. Which in theory, is in all parties best interest. I think the current draft pretty much wanted a word or two changed.

So.. to move forward with 240/4 on the wider internet you'd need a bunch of software / hardware updates, and time for those to rollout. Then you'd need sacrificial lambs in the user and service endpoints.

Nobody is asking for any assistance with that. It will happen or not based upon those who wish to expend effort on it. Apparently, most if it has already happened.

All of this to regain ~16 /8's worth of space (presuming you could use 255/8?).

Really, so that anything standardized can be done with it, rather than nothing. This is about extending some utilization capability of IPv4, but it is also about preserving standard driven behavior.

I think a /8 is 'free' on the internet for about a month, so 1.5 yrs of new address allocations, terrific?

That was the old paradigm, in the old days. Currently a /8 goes pretty far and its likely to only get further.

At the end of the day, again, almost all proposals to 'add more ipv4 space' come down to 1 month per /8. I think part of Jordi's point is: "Is that 1 month really worth the effort?

All the effort requested is for all those who think its wall head banging to say knock yourself out, we are unopposed to changing how IPv4 obsolete addresses are managed because we have already bet on IPv6. Take whatever you want. Change whatever you want. We dont care. Thats not a whole lot of effort being requested of the unwilling in exchange for their continued relevance. All the rest of the efforts are expected to come from the willing, able and ready. Not your concern. But perhaps you do care. Why?

is there a reason that all of the softare/hardware uplift and time to deploy is not being spent on v6?"

Perhaps you think that stymieing any effort on IPv4 is important to marshall the worlds attention to IPv6. Which if the shoe were on the other foot you would find galling and obnoxious. There are many reasons why IPv6 hasnt done that all on its own and pretty much most if not all of them have nothing to do with 240/4 They have to do with IPv6. And we have heard them over and over again. Look inwards. In short, IPv6 apparently keep losing to the cost vs. benefits analysis being performed by countless people in countless situations. You can claim that it should not, but that is not what is happening. You cant make IPv4 more expensive than it already is doing all by itself. It is wrong to try. And apparently, its not expensive enough to drive mass adoption of v6, with any degree of alacrity. v6 must have costs in contexts that have been under-addressed. Its time to knowledge them and perhaps work to address them.

At this point in our matrix timeline it seems to me that: "If you were going to deploy v6, you did... if you didn't oh, well.. eventually you will?"

Much like Itanium vs. amd64, there are other ways this can turn out, the longer it drags out. I think those ways are potentially more undesirable than extending IPv4 use in a standardized fashion now.

I'd prefer to not have to deploy in a rush or on timelines I can't cointrol if I hadn't deployed already. Will that timeline be 'soon' anytime soon? I don't know :( I think Grant's "not until i'm long retired" guess is as good as any though :(

-chris

I for one would like to say I did all the tiny amount I conceivably could to leave the internet a better place than I found it. And I think that means giving IPv4 all the runway it needs to properly decelerate to the fullest extent possible or at least not obstructing those who would try. Remember, the dual stack migration was predicated on working v4. They are just trying to patch that flawed transition plan to keep it going. Its really hard to explain to people how 4bn IPv4 addresses are all used up while at the same time there are still more than a hundred million of addresses in theory potentially available but unusable by anybody. Without pointing fingers. Especially when its the same people who have just paid some significant sum for the rights to use a few of those numbers. Joe

On Sun, Mar 13, 2022 at 7:55 PM William Herrin <bill@herrin.us> wrote:

...

What's the actual proposal for 240/4? Is it: "Make this usable by me on my /intranet/?" Is it: "Make this usable across the internet between bespoke endpoints?" Is it: "Make this usable for any services/users on the wider internet,

On Sun, Mar 13, 2022 at 12:29 PM Christopher Morrow <morrowc.lists@gmail.com> wrote: treat it like any other unicast ipv4 address?"

Hi Chris,

I can't speak for anyone else but my proposal is: (A) do the standards-level activity which is common to all three proposals, (B) give the vendors a couple years to catch up to the new standard, and then (C) pick a next step based on what's then the operational reality.

The standards-level activity common to all three proposals is:

1. Define 240/4 excluding 255.255.255.255/32 as unicast addresses (no longer "undefined" future use) but continue holding them in reserve. 2. Advise hardware and software vendors to treat 240/4 as unicast when configured by the user or received by protocol. 3. Stop.

ok, sounds interesting/ok to me :) I was mostly wondering about the endgame, the 'reason' for the proposal(s) that keep coming up. One version of them is: "well, that's 16 /8's!!! think of the ipv4 market!" (or similar) I don't think it's particularly productive to wait on 16 /8's which really are a 1.5 yr lengthening of the v4 runway/landing-strip. I get that we'll be doing ipv4 things at scale for at least a decade more, but even the most generous reading of your 'do standads, get vendors, let rolllout happen' is, I think at least 10 yrs away as well. using the space intenrally kinda already works... having some standards action that said: "err, this is rfc1918-like space" would help internal uses. Not having that means that you are (as a deployer of 240/4 internally) constantly ~1 IANA/RIR decision away from not being able ot route to parts of the internet. -chris

On Fri, Mar 11, 2022 at 6:36 AM Abraham Y. Chen <aychen@avinta.com> wrote:

1) Thanks for the reference. However, Informative Reference 7 of our IETF Draft cites another IANA document which puts the initial date of the 240/4 topic back to 1981-09 which was much earlier, in fact, coincided with that of RFC 791.

Hi Abraham, As I said, RFC1112 documents the _most recent_ standards action with respect to 240/4. The earlier RFC 791 you mention described 224/3 (which included 240/4) as "escape to extended addressing mode" which it specified as "undefined" and "reserved for future use." RFC 988 then redefined and split 224/3 into "class D" and "class E" addresses, defined "class D" as multicast and "class E" as reserved for future use without any particular purpose. This saw updates in RFC1112 which has the current disposition of "class E" aka 240/4. RFC 1112 spends a grand total of one sentence on Class E addresses. If you're looking for more, you won't find it. That one sentence is all they said.

2) My curiosity questions were not about "when" or "how", but "why" and for "whom".

As documented or unambiguously inferred, "why" is because the folks in the 1980s wanted to hold some addresses aside for uses not then known, and "for whom" was explicitly undefined.

Particularly at a time that IPv4 was planned to be "dead" soon, what was its "Future" that deserved to be Reserved for?

As I've said in other postings on the subject, I believe the time has passed where it was reasonable to expect that a non-unicast use might be found for 240/4 within the remaining lifetime of the IPv4 protocol. Nor is there any reason to believe we will need more of another sort of address such as multicast or broadcast. More, it's well understood that the network routing and software client behavior for anycast is identical to unicast, and indeed addresses defined as global unicast have been routinely allocated to anycast uses. I thus think a standards action changing 240/4 from "reserved, undefined" to "reserved, unicast" is justified. Exactly what unicast use remains a reasonable topic of debate. Such debate, however, is irrelevant to the hardware and software implementing it which need only care that the addresses should be handled in normal unicast routing and termination. Changes to hardware and software to make use of 240/4 as ordinary unicast IP addresses can and should proceed in parallel to such debate. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Sat, 12 Mar 2022 at 18:19, Abraham Y. Chen <aychen@avinta.com> wrote:

3) " ... Changes to hardware and software to make use of 240/4 as ordinary unicast IP addresses can and should proceed in parallel to such debate. ": Agreed. Since through the EzIP Project, we have identified that the hardware does not need change, and the software modification is minimal, we should proceed to discuss what is the best application for the 240/4 netblock, after is re-classified as an ordinary unicast address pool.

It would surprise me greatly if there isn't hardware in the field which physically cannot be retrofitted for 240/4, as we have a very diverse set of hardware which very liberally makes assumptions of the environment it will be in, to both reduce cost and to improve PPS. These assumptions cause issues already in the environment they are in, because engineers aren't always correct. It is crucial to understand not all lookups are equal, and determinism isn't perfect, the devices are not complex, but they are more complex than that. And of course a lot more which by software do not, and will not, as they've stopped receiving software updates. The marginal increase in cost and effort in any of these cases between CPR and IPv6 is trivial. Any narrative to prolong dual-stack with the argument 'it is just SW update' is broken. Only reason we are not 100% IPv6 today, is because we failed to foresee IPv6 won't take off, we all kind of assumed it will of course happen organically in due time. I don't think anyone really believed in 2002 that in 2022 we are still IPv4 and IPv6 is after thought. And now we should understand, the organic market-driven move to IPv6 may not ever happen, and are we going to accept all this cost involved maintaining dual-stack or do we want to reduce CAPEX and OPEX and have specific plans to return to single-stack world? What if many/most large CDN, cloud, tier1 would commonly announce a plan to drop all IPv4 at their edge 20 years from now? How would that change our work? What would we stop doing and what would we start doing? -- ++ytti

It appears that Joe Maimon <jmaimon@jmaimon.com> said:

Saku Ytti wrote:

...

What if many/most large CDN, cloud, tier1 would commonly announce a plan to drop all IPv4 at their edge 20 years from now? How would that change our work? What would we stop doing and what would we start doing?

I cant see how it would change or do anything IPv6-related for myself for at least 19 years. And I suspect most others would fall somewhere between that and never.

Yet the four largest cable networks and all of the mobile networks in the US have had full IPv6 support for years as do AWS, Google, Azure, Digital Ocean, Linode, and many other hosting providers. Could you explain what "most" means where you are? R's, John

Personally I'd rather hear from the RIRs regarding the value or not of making more IPv4 space such as 240/4 available. They're on the front lines of this. I think sometimes what we're manipulating in these debates is the time factor: Someone with a worthy, immediate, urgent need versus some distant horizon which might be preferable in the big picture but is demanding possibly unreasonable sacrifices of some in the short term. I don't believe we are pondering making this IPv4 space available and then returning to the 1980s/1990s relative free-for-all. This all might be more interesting if driven by consideration of those needs. On March 13, 2022 at 13:54 johnl@iecc.com (John Levine) wrote:

It appears that Joe Maimon <jmaimon@jmaimon.com> said:

...

Saku Ytti wrote:

...

What if many/most large CDN, cloud, tier1 would commonly announce a plan to drop all IPv4 at their edge 20 years from now? How would that change our work? What would we stop doing and what would we start doing?

I cant see how it would change or do anything IPv6-related for myself for at least 19 years. And I suspect most others would fall somewhere between that and never.

Yet the four largest cable networks and all of the mobile networks in the US have had full IPv6 support for years as do AWS, Google, Azure, Digital Ocean, Linode, and many other hosting providers.

Could you explain what "most" means where you are?

R's, John

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

But the RIRs are the ones fielding requests for IPv4 space, and have some notion of how policy implementation might work in practice, so should have a lot of useful input. On March 14, 2022 at 00:45 niels=nanog@bakker.net (Niels Bakker) wrote:

* bzs@theworld.com (bzs@theworld.com) [Mon 14 Mar 2022, 00:31 CET]:

...

Personally I'd rather hear from the RIRs regarding the value or not of making more IPv4 space such as 240/4 available. They're on the front lines of this.

You've got your policy development process diagram upside down. The community decides what the RIRs implement. They're not in touch with merchant silicon manufacturers.

-- Niels.

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able to claim some detailed knowledge on the subject. In general, the RIRs themselves maintain neutrality about such things, looking to their respective communities for input on what to do. However, so long as the IETF and has not designated the space Unicast Address Space to be delegated to the RIRs for allocation/assignment, IANA will not delegate it to the RIRs and the RIRs won’t, therefore, delegate it to users. If you really want to see this happen (and I still argue that the amount of effort already wasted discussing this idea vastly exceeds what would be needed towards IPv6 to get beyond caring about it), then the first step must be to convince the IETF to designate the space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the RIRs. Once that happens, the rest of the allocation process is basically automatic. From a policy perspective at the RIR level, it will be no different than say 4/8 or 1/8. Now, convincing vendors to update their firmware, software, etc. is another matter and entirely outside of the control of the RIRs. Merchant compliance with IETF standards is generally considered useful, but it is entirely voluntary and even in the best of circumstances doesn’t every happen instantaneously and almost always involves some stumbles along the way. Owen

On Mar 15, 2022, at 02:54 , Sylvain Baya <abscoco@gmail.com> wrote:

Dear NANOG-ers, Hope this email finds you in good health! Please see my comments below, inline...

Le mardi 15 mars 2022, <bzs@theworld.com <mailto:bzs@theworld.com>> a écrit :

Hi Barry, Thanks for your email, brother!

But the RIRs are the ones fielding requests for IPv4 space, and have some notion of how policy implementation might work in practice, so should have a lot of useful input.

...of course, it appears that RIRs have the opportunity to add their useful inputs, as Impact Analysis Report (IAR); during the Policy Development Process (PDP) initiated by the *appropriate* [1] Internet community. They explain it themselves here [2]. __ [1]: <https://tools.ietf.org/html/rfc7020 <https://tools.ietf.org/html/rfc7020>> [2]: <https://www.nro.net/accountability/rir-accountability/q-and-a/ <https://www.nro.net/accountability/rir-accountability/q-and-a/>>

Shalom, --sb.

On March 14, 2022 at 00:45 niels=nanog@bakker.net <mailto:nanog@bakker.net> (Niels Bakker) wrote:

...

* bzs@theworld.com <mailto:bzs@theworld.com> (bzs@theworld.com <mailto:bzs@theworld.com>) [Mon 14 Mar 2022, 00:31 CET]:

...

Personally I'd rather hear from the RIRs regarding the value or not of making more IPv4 space such as 240/4 available. They're on the front lines of this.

You've got your policy development process diagram upside down. The community decides what the RIRs implement. They're not in touch with merchant silicon manufacturers.

-- Niels.

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com <http://www.theworld.com/> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

-- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure <https://cmnog.cm/dokuwiki/Structure>> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/ <https://lists.cmnog.cm/mailman/listinfo/cmnog/>> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

On Mar 15, 2022, at 19:23 , Mark Andrews <marka@isc.org> wrote:

...

On 16 Mar 2022, at 02:54, Owen DeLong via NANOG <nanog@nanog.org> wrote:

Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able to claim some detailed knowledge on the subject.

In general, the RIRs themselves maintain neutrality about such things, looking to their respective communities for input on what to do. However, so long as the IETF and has not designated the space Unicast Address Space to be delegated to the RIRs for allocation/assignment, IANA will not delegate it to the RIRs and the RIRs won’t, therefore, delegate it to users.

If you really want to see this happen (and I still argue that the amount of effort already wasted discussing this idea vastly exceeds what would be needed towards IPv6 to get beyond caring about it), then the first step must be to convince the IETF to designate the space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the RIRs.

Once that happens, the rest of the allocation process is basically automatic. From a policy perspective at the RIR level, it will be no different than say 4/8 or 1/8.

Actually it would be fundamentally different to 4/8 or 1/8. You are looking at firmware upgrades rather than dealing with squatters and out-of-date ACLs both of which are self-inflicted by one of the parties. Routers and end devices that don’t know how to hand 240/4 are no self inflicted injuries. Issuing 4/8 or 1/8 worked for parties that had been following the rules. With 240/4 there where no rules to follow which results in RIR’s leasing known defective addresses.

I was speaking from an RIR allocation perspective, NOT talking about the technological hurdles to implementation. I was specifically responding to someone’s question about how the RIRs would be impacted by this if it were to come to pass. I addressed your concern in the following paragraph as an aside, however.

...

Now, convincing vendors to update their firmware, software, etc. is another matter and entirely outside of the control of the RIRs. Merchant compliance with IETF standards is generally considered useful, but it is entirely voluntary and even in the best of circumstances doesn’t every happen instantaneously and almost always involves some stumbles along the way.

Owen

...

On Mar 15, 2022, at 02:54 , Sylvain Baya <abscoco@gmail.com> wrote:

Dear NANOG-ers, Hope this email finds you in good health! Please see my comments below, inline...

Le mardi 15 mars 2022, <bzs@theworld.com> a écrit :

Hi Barry, Thanks for your email, brother!

But the RIRs are the ones fielding requests for IPv4 space, and have some notion of how policy implementation might work in practice, so should have a lot of useful input.

...of course, it appears that RIRs have the opportunity to add their useful inputs, as Impact Analysis Report (IAR); during the Policy Development Process (PDP) initiated by the *appropriate* [1] Internet community. They explain it themselves here [2]. __ [1]: <https://tools.ietf.org/html/rfc7020> [2]: <https://www.nro.net/accountability/rir-accountability/q-and-a/>

Shalom, --sb.

On March 14, 2022 at 00:45 niels=nanog@bakker.net (Niels Bakker) wrote:

...

* bzs@theworld.com (bzs@theworld.com) [Mon 14 Mar 2022, 00:31 CET]:

...

Personally I'd rather hear from the RIRs regarding the value or not of making more IPv4 space such as 240/4 available. They're on the front lines of this.

You've got your policy development process diagram upside down. The community decides what the RIRs implement. They're not in touch with merchant silicon manufacturers.

-- Niels.

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

-- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

I think I basically understand the policy and allocation processes. What I was looking for was some characterization of the current trends for IPv4 requests, particularly how urgent and worthy they might be and the amount of space being sought. RIRs will receive those requests. The rest of us don't see them. There is also the secondary market which is related but perhaps not the RIRs' concern or place to characterize though I'd imagine they have some information based on transfer requests. That might give us some insight based on actual requests, queues, etc. Put another way, are those trying to get 240/4, 127/16, etc, space released for allocation actually solving a real problem beyond some broad hand wave of "more (IPv4 space) is always better"? On March 15, 2022 at 08:54 nanog@nanog.org (Owen DeLong via NANOG) wrote:

Having spent nearly 15 years on the ARIN Advisory Council, I think I’m able to claim some detailed knowledge on the subject.

In general, the RIRs themselves maintain neutrality about such things, looking to their respective communities for input on what to do. However, so long as the IETF and has not designated the space Unicast Address Space to be delegated to the RIRs for allocation/assignment, IANA will not delegate it to the RIRs and the RIRs won’t, therefore, delegate it to users.

If you really want to see this happen (and I still argue that the amount of effort already wasted discussing this idea vastly exceeds what would be needed towards IPv6 to get beyond caring about it), then the first step must be to convince the IETF to designate the space IPv4 Unicast and instruct the IANA to begin issuing those /8s to the RIRs.

Once that happens, the rest of the allocation process is basically automatic. From a policy perspective at the RIR level, it will be no different than say 4/8 or 1/8.

Now, convincing vendors to update their firmware, software, etc. is another matter and entirely outside of the control of the RIRs. Merchant compliance with IETF standards is generally considered useful, but it is entirely voluntary and even in the best of circumstances doesn’t every happen instantaneously and almost always involves some stumbles along the way.

Owen

On Mar 15, 2022, at 02:54 , Sylvain Baya <abscoco@gmail.com> wrote:

Dear NANOG-ers, Hope this email finds you in good health! Please see my comments below, inline...

Le mardi 15 mars 2022, <bzs@theworld.com> a écrit :

Hi Barry, Thanks for your email, brother!

But the RIRs are the ones fielding requests for IPv4 space, and have some notion of how policy implementation might work in practice, so should have a lot of useful input.

...of course, it appears that RIRs have the opportunity to add their useful inputs, as Impact Analysis Report (IAR); during the Policy Development Process (PDP) initiated by the *appropriate* [1] Internet community. They explain it themselves here [2]. __ [1]: <https://tools.ietf.org/html/rfc7020> [2]: <https://www.nro.net/accountability/rir-accountability/q-and-a/>

Shalom, --sb.

On March 14, 2022 at 00:45 niels=nanog@bakker.net (Niels Bakker) wrote: > * bzs@theworld.com (bzs@theworld.com) [Mon 14 Mar 2022, 00:31 CET]: > >Personally I'd rather hear from the RIRs regarding the value or not > >of making more IPv4 space such as 240/4 available. They're on the > >front lines of this. > > You've got your policy development process diagram upside down. The > community decides what the RIRs implement. They're not in touch with > merchant silicon manufacturers. > > > -- Niels.

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http:// www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

--

Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<https://cmnog.cm/dokuwiki/Structure> Subscribe to Mailing List: <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*