Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

Mailman List Mirror (Read Only)
1

Dear Seth:

  1. " … should be … ": Instead of “hand wave”, this is a diplomatic expression to challenge the software engineers’ knowledge of the networking program code for the current case. 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? … etc. We also could not find anyone who could describe to us how was it being handled in the existing programs. This included those who claimed to be experts in the subject. Perhaps they intentionally tried to hide the detail, or they also did not know? One day, we finally came across a program fragment that could perform the “disabling 240/4 netblock” function. Upon presenting it to an acquaintance knowledgeable of networking programs, he confirmed that it was one concise technique to do the job. That was sufficient for our purpose as system engineers, because we should not overstep our duties by doing software engineer’s programing task. That is, as long as we can demonstrate that “there exists” a solution, like proofing a mathematics theorem, we have completed our part of the deal.

  2. " … discussed to death many times over … ": This was what we were told when we first looked into this subject over half a dozen years ago, and more times along the way. As long as there was an issue not resolved, however, every angle should be continuously explored. In science and engineering, if we stopped studying, because of this kind of viewpoint, we would have missed a lot of inventions and discoveries. So, this particular consideration is not in our books.

Regards,

Abe (2022-03-10 22:49 EST)

2

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

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

You are now informed about its current status along with when and how
it got to be that way.

Regards,
Bill Herrin

3

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?

IANA IPv4 Special-Purpose Address Registry

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

4

Hi, Bill:

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.

2) My curiosity questions were not about "when" or "how", but "why" and for "whom". Particularly at a time that IPv4 was planned to be "dead" soon, what was its "Future" that deserved to be Reserved for?

Regards,

Abe (2022-03-11 09:36)

5

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

6

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

7

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

8

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

9

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ó:

10

Hi, Bill:

1) Thanks for confirming my understanding of the 240/4 history. Basically, those in charge of the Internet appear to be leaving the community in the state of informal debates, since there is no more formal IPv4 working group.

2) On the other hand, there was a recent APNIC blog that specifically reminded us of a fairly formal request for re-designating the 240/4 netblock back in 2008 (second grey background box). To me, this means whether to change the 240/4 status is not an issue. The question is whether we can identify an application that can maximize its impact.

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.

Regards,

Abe (2022-03-12 11:15)

11

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?

12

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.

However, such an announcement would actually signal that we should do all those things now to IPv4 that will take 10 years to be useful, because then they will be useful for at least another 10 years.

Seriously, we have already had this sort of experiment play out numerous times, both with a governing body and without. We already know how it goes.

With a governing body: lack of progress right up until the deadline, gnashing of teeth ensues until deadline is extended, more often than not comprehensive conversion finally completes, later than scheduled.

Without: lack of progress right up to deadline, teeth gnashing, deadline is arbitrarily extended, nothing much changes and deadline is forgotten.

When IPv4 is properly obsoleted, we will see many of those announcements and some will matter and most wont. As it should be. However proclamations are not going to obsolete IPv4. As we have already seen.

I dont think advocating for large players to band together to form their own internet-ops standard body is going to save IPv6 and the internet. More likely it will doom both as we know it.

Here is an equally unlikely thought experiment.

What if many/most large CDN, cloud, tier1 would commonly announce a plan to compatibly extend IPv4, citing a lack of progress in IPv6 deployment and resulting IPv4 elimination as well as a stagnant stalemate on any such efforts within the would-be-relevant standard bodies?

Joe

13

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?

Improving IPv6? Keep up the good work and thank you.

Protesting IPv4 efforts? Not very altruistic, more like you are motivated by various deep-seated emotional responses to the continuation of the IPv4 internet.

El 12/3/22 9:10, "William Herrin" <bill@herrin.us> escribió:

     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

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.

Joe

14
15

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

16

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?

a vast number of large non-us mobile networks and non-us fixed eyeball
networks use cgn, sad to say.

as saku says, when v6 was 'designed', the expected transition time was
relatively short. yes, they had negative ops clue; in fact, ops were
openly declared to be the enemy of the v6 'architects' (remember NLA and
TLA). this led, among other things, to the short-sighted plan for dual
stack to be the only needed transition mechanism. the first problem
with this is that it requires as much v4 space as v6 space, oops. thus
was born the plethora of transition mechanisms.

imiho, v6 will continue to slowly deploy with some lulls and some
spurts. and mailing list religious rants about it will continue
unabated. in parallel, efforts to de-frag the v4 space are worthwhile,
though they will only slightly alleviate the v4 shortage.

we do what we can. i only wish we would make less ineffective noise
about it.

randy

17

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’.

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.

All of this to regain ~16 /8’s worth of space (presuming you could use 255/8?).
I think a /8 is ‘free’ on the internet for about a month, so 1.5 yrs of new address allocations, terrific?

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?
is there a reason that all of the softare/hardware uplift and time to deploy is not being spent on v6?”

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?”

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 :frowning: I think Grant’s “not until i’m long retired” guess
is as good as any though :frowning:

-chris

18

Christopher Morrow 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 :frowning: I think Grant's "not until i'm long retired" guess
is as good as any though :frowning:

-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

19

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.

20

* 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.