Mailing List Archive

Mark Andrews wrote:
> CIDR is much older than that and we still have to avoid .0 and .255
> addresses in class C space.

I use .0 all the time.

> Similarly for .0.0 and .255.255 for class B space and .0.0.0 and
> .255.255.255 for class A space. Getting everybody you want to contact
> and the path in between to be clean for 240/4 is more than just a
> replacement cycle. There is a lot of really old gear out there that
> still talks to the world and it will never work with 240/4 addresses.
> If you are selling IPv4 connectivity and your customer is given a
> 240/4 address but can’t reach some place on the internet that their
> neighbour with out a 240/4 can who are they going to blame? Can you
> afford the defective product law suite. You gave then an address that
> you knew fore well would not work reliably with the Internet as a
> whole. Using 1/8 is still fraught. At least with 1/8 you are not
> fighting kernels that need to be modified for which source is not
> available.

No address comes with any guarantees. Suppose you are 100% correct. Its
not the IETF's role to manage the community at large resource
expenditures, whatever their opinion may be.

The only effort involved on the IETF's jurisdiction was to stop
squatting on 240/4 and perhaps maybe some other small pieces of IPv4
that could possibly be better used elsewhere by others who may choose to
do so.

Joe

How much runway would a single /8 give us? Is it worth the headache to gain a single /8 ?

If we’re going to do something that Majorly Breaks the Internet(tm), why not talk about the 240/4 space instead?

<economics>We can’t fight address exhaustion on the supply side. The only way to fix IPv4 exhaustion is by shifting the demand curve inward and that is through IPV6 and aggressive reclamation of IPv4 space.<economics />

Jonathan

Jonathan Kalbfeld

office: +1 310 317 7933 <tel:%28310%29%20317-7933>
fax: +1 310 317 7901 <tel:%28310%29%20317-7901>
home: +1 310 317 7909 <tel:%28310%29%20317-7909>
mobile: +1 310 227 1662 <tel:%28310%29%20227-1662>

ThoughtWave Technologies, Inc.
Studio City, CA 91604
https://thoughtwave.com <https://thoughtwave.com/>

View our network at
https://bgp.he.net/AS54380 <https://bgp.he.net/AS54380>

+1 213 984 1000

> On Nov 17, 2021, at 3:29 PM, Jay R. Ashworth <jra@baylink.com> wrote:
>
> This seems like a really bad idea to me; am I really the only one who noticed?
>
> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
> That's over a week old and I don't see 3000 comments on it, so maybe it's just
> me. So many things are just me.
>
> [. Hat tip to Lauren Weinstein, whom I stole it from ]
>
> Cheers,
> -- jra
>
> --
> Jay R. Ashworth Baylink jra@baylink.com
> Designer The Things I Think RFC 2100
> Ashworth & Associates http://www.bcp38.info
> St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

Dave Taht wrote:
> I am sad to see the most controversial of the proposals (127/16) > first discussed here. > > Try this instead? > >
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/
> > >
in my mind, has the most promise for making the internet better in the
> nearer term. > > Could I get y'all to put aside the 127 proposal and read that
over, > instead?

/30 now becomes 2 usable IP addresses for the customer.

/29 "5 static IP addresses" now becomes 6?

Doing vrrp for a customer /29 gets a bit easier.


> > > ... > > It's ok, I'll wait... > > ... > > There were two other
proposals concerning 240/4 and 0/8 also worth > reading for their
research detail and attention to history.

Good thing they werent worried about wasting the IETF's valuable and
precious time running the internet, because the masses cant possibly be
trusted.

> > The amount of work required to make 240/4 work in most places is now
> very close to zero, having been essentially completed a decade ago. >
240/4 and 0/8 checking is not present in the SDN codes we tried, and >
we ripped the 0/8 check out of linux 3? 4? years back. Saves a few > ns.
> > All but one iOt stack we tried worked with these, many of those >
stacks still lack, or have poor ipv6 support. esp32 anyone? > > Just as
ipv6 today is not globally reachable, these address spaces > may never
be globally reachable, but defining a standard for their > potential
sub-uses seems like a viable idea. > >

On the face of it, any of the above statements should be enough to
silence and shameface any and all of the historical naysayers.

However it would appear they are still living in the past, as evidenced
by continued citing of "pre-exhaustion burn rate" as if the excesses of
the past are somehow relevant to the consumption of the future other
than an indictment of non-prudence.

Joe

> The only effort involved on the IETF's jurisdiction was to stop squatting on
> 240/4 and perhaps maybe some other small pieces of IPv4 that could possibly
> be better used elsewhere by others who may choose to do so.

The IETF is not the Network Police, and all IETF standards are entirely
voluntary.

Nothing is keeping you from persuading people to change their software to
treat class E addresses as routable other than the detail that the idea is
silly.

R's,
John

John R. Levine wrote:
>> The only effort involved on the IETF's jurisdiction was to stop
>> squatting on 240/4 and perhaps maybe some other small pieces of IPv4
>> that could possibly be better used elsewhere by others who may choose
>> to do so.
>
> The IETF is not the Network Police, and all IETF standards are
> entirely voluntary.

And that is exactly why they said that even though they think it might
possibly entail similar effort to deployment of IPv6 and that IPv6 is
supposed to obsolete IPv4 before any such effort can be realized, they
would be amenable to reclassifying 240/4 as anything other than
reserved, removing that barrier from those whom may voluntarily decide
to follow that updated standard, should they find the time to squeeze in
another project the same size and effort of IPv6 into their spare time.

Seems the IETF does indeed think it is the network police. And that they
get to decide winners and losers.
>
> Nothing is keeping you from persuading people to change their software
> to treat class E addresses as routable other than the detail that the
> idea is silly.
>
> R's,
> John
>

And indeed, they have done so. Now who looks silly?

Joe

Jonathan Kalbfeld via NANOG wrote:
> How much runway would a single /8 give us?
Up to 65280 /24's becoming available through registrars would be quite
welcome to lots of small organizations or startups.

> Is it worth the headache to gain a single /8 ?

I support serious consideration be given to determine the extent of the
headache and to answer that question.

>
> If we’re going to do something that Majorly Breaks the Internet(tm),
> why not talk about the 240/4 space instead?

I think 240/4 is indeed a very good idea deserving of proper
consideration. That does not mean that other ideas arent worthy as well.

But at this point 240/4 is practically a no brainer.

>
> <economics>We can’t fight address exhaustion on the supply side. The
> only way to fix IPv4 exhaustion is by shifting the demand curve inward
> and that is through IPV6 and aggressive reclamation of IPv4
> space.<economics />
>
> Jonathan
>
> Jonathan Kalbfeld
>
> office: +1 310 317 7933 <tel:%28310%29%20317-7933>
> fax: +1 310 317 7901 <tel:%28310%29%20317-7901>
> home: +1 310 317 7909 <tel:%28310%29%20317-7909>
> mobile: +1 310 227 1662 <tel:%28310%29%20227-1662>
>
> ThoughtWave Technologies, Inc.
> Studio City, CA 91604
> https://thoughtwave.com
>
> View our network at
> https://bgp.he.net/AS54380
>
> +1 213 984 1000
>
>> On Nov 17, 2021, at 3:29 PM, Jay R. Ashworth <jra@baylink.com
>> <mailto:jra@baylink.com>> wrote:
>>
>> This seems like a really bad idea to me; am I really the only one who
>> noticed?
>>
>> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>>
>> That's over a week old and I don't see 3000 comments on it, so maybe
>> it's just
>> me. So many things are just me.
>>
>> [. Hat tip to Lauren Weinstein, whom I stole it from ]
>>
>> Cheers,
>> -- jra
>>
>> --
>> Jay R. Ashworth Baylink
>> jra@baylink.com
>> Designer The Things I Think
>> RFC 2100
>> Ashworth & Associates http://www.bcp38.info
>> St Petersburg FL USA BCP38: Ask For It By Name! +1 727
>> 647 1274
>

On Nov 18, 2021, at 9:00 AM, John R. Levine <johnl@iecc.com> wrote:
>> The only effort involved on the IETF's jurisdiction was to stop squatting on 240/4 and perhaps maybe some other small pieces of IPv4 that could possibly be better used elsewhere by others who may choose to do so.
>
> The IETF is not the Network Police, and all IETF standards are entirely voluntary.

True…

> Nothing is keeping you from persuading people to change their software to treat class E addresses as routable other than the detail that the idea is silly.

Of course, it’s not quite that simple.

First, https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml <https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml> would need to be updated, then the RIRs would need to issue a request according to https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en <https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en>. At that point, existing requests lodged at the RIRs could be fulfilled using the formerly reserved space. Network operators that received the allocations could then number their devices with the new address space and announcing that space into the routing system.

Of course, there are probably an unknowable number of “bogon” filters out there that are hardcoded into various bits of infrastructure that would need to be updated. There are also various hardware, firmware, and software IP stack implementations, perhaps sitting in closets somewhere, that still think they can’t use reserved space that would need to be updated/replaced.

As far as I can tell, assertions about the scale of that update/replace exercise are based on limited data. Perhaps as an alternative to declaring various chunks of reserved space as free for use, a chunk of that space could be allocated to one or more of the RIRs and announced with a set of services placed upon it to see just how much actually breaks, similar to what APNIC and Cloudflare did with 1.1.1.0/24?

Regards,
-drc

On Thu, 18 Nov 2021 08:53:53 -0800
Jonathan Kalbfeld via NANOG <nanog@nanog.org> wrote:

> If we’re going to do something that Majorly Breaks the Internet(tm),
> why not talk about the 240/4 space instead?

I like the proposal that suggest include a plan to reuse 224/4 (with
the exception of 224.0.0.0/24, but it looks like the plan is OK with
not using any of 224.0.0.0/8). With apologies to our small set of
friends who are keeping the interdomain dream alive, I might help
advocate for such a plan not because of what it adds, but because
of what it helps hasten the demise of. :-)

John

----- Original Message -----
> From: "Justin Keller" <justincompsci@gmail.com>

> I'd be fine if newish devices use it like a 1918 but I don't think
> it's worth the headache and difficulty of making it globally routed.
> Maybe Amazon could use it too

I could be wrong, but I don't think expanding 1918 was the goal of these
proponents....

Cheers,
-- jra

> On Wed, Nov 17, 2021 at 6:31 PM Jay R. Ashworth <jra@baylink.com> wrote:
>>
>> This seems like a really bad idea to me; am I really the only one who noticed?
>>
>> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>>
>> That's over a week old and I don't see 3000 comments on it, so maybe it's just
>> me. So many things are just me.
>>
>> [. Hat tip to Lauren Weinstein, whom I stole it from ]
>>
>> Cheers,
>> -- jra
>>
>> --
>> Jay R. Ashworth Baylink jra@baylink.com
>> Designer The Things I Think RFC 2100
>> Ashworth & Associates http://www.bcp38.info
> > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII
St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

On Thu, Nov 18, 2021 at 10:14 AM Jay R. Ashworth <jra@baylink.com> wrote:
> I could be wrong, but I don't think expanding 1918 was the goal of these
> proponents....

Hi Jay,

I would be happy with the compromise where the addresses are assigned
to "unicast; reserved." We can fight over exactly what unicast use
they should be put to 20 years from now when ordinary equipment and
software churn has rendered the addresses more or less usable.

Regards,
Bill Herrin

--
William Herrin
bill@herrin.us
https://bill.herrin.us/

The proposals I've seen all seem to deliver minimal benefit for the massive
lift (technical, administrative, political, etc) involved to keep IPv4
alive a little longer.

Makes about as much sense as trying to destabilize US currency by
counterfeiting pennies.

Thank you
jms



On Thu, Nov 18, 2021 at 12:39 PM Joe Maimon <jmaimon@jmaimon.com> wrote:

>
>
> John R. Levine wrote:
> >> The only effort involved on the IETF's jurisdiction was to stop
> >> squatting on 240/4 and perhaps maybe some other small pieces of IPv4
> >> that could possibly be better used elsewhere by others who may choose
> >> to do so.
> >
> > The IETF is not the Network Police, and all IETF standards are
> > entirely voluntary.
>
> And that is exactly why they said that even though they think it might
> possibly entail similar effort to deployment of IPv6 and that IPv6 is
> supposed to obsolete IPv4 before any such effort can be realized, they
> would be amenable to reclassifying 240/4 as anything other than
> reserved, removing that barrier from those whom may voluntarily decide
> to follow that updated standard, should they find the time to squeeze in
> another project the same size and effort of IPv6 into their spare time.
>
> Seems the IETF does indeed think it is the network police. And that they
> get to decide winners and losers.
> >
> > Nothing is keeping you from persuading people to change their software
> > to treat class E addresses as routable other than the detail that the
> > idea is silly.
> >
> > R's,
> > John
> >
>
> And indeed, they have done so. Now who looks silly?
>
> Joe
>
>

I have read through this thread, and you'll pardon me if it sounds like yet another rehash on yet another list. You might take a look at https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/, which responds to https://datatracker.ietf.org/doc/html/draft-wilson-class-e. I'm not sure what has changed in the past lotsa years other than which prefix people want to make essentially the same arguments about. My observation has been that people don't want to extend the life of IPv4 per se; people want to keep using it for another very short time interval and then blame someone else for the fact that the 32 bit integers are a finite set.

That strikes me as crazy. Put all of the remaining IPv4 prefixes (for some suitable definition of "remaining") in a bucket, decide that if they were all made unicast IP address space that would add <mumble> microfortnights to the life of the IPv4 Internet, and think about what happens next. Immediately, we all go back to sleep, fail to update our applications and deployments, and when that time interval has expired, we all whine about the stupidity of the IPv4 designers that didn't not make IPv4 forward compatible with *any*thing* - the next step has to be a replacement - and try to figure out a way to represent more than 2^32 interfaces in a single 32 bit number (https://datatracker.ietf.org/doc/html/draft-terrell-math-ipaddr-ipv4) or redesign the Internet in some way that would require as much effort and money to deploy as IPv6 has since its inception.

If you don't think that's a true statement, I'd be very interested to hear what you think might be true.

Fred Baker wrote:
> I have read through this thread, and you'll pardon me if it sounds like yet another rehash on yet another list. You might take a look at https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/, which responds to https://datatracker.ietf.org/doc/html/draft-wilson-class-e. I'm not sure what has changed in the past lotsa years other than which prefix people want to make essentially the same arguments about.

What has changed is that the intervening years have demonstrated that
the proponents were right and the detractors were wrong. Very much so.

> My observation has been that people don't want to extend the life of IPv4 per se; people want to keep using it for another very short time interval and then blame someone else for the fact that the 32 bit integers are a finite set.
>
>
>
> If you don't think that's a true statement, I'd be very interested to hear what you think might be true.
>
On this thread alone very thoughtful and knowledgeable sounding folk
have made it quite clear that the efforts involved are a lot less and
the potential benefits a lot more than the naysayers mantra.

Its time to update some assumptions.

Joe

On Thu, Nov 18, 2021 at 12:40 PM Fred Baker <fredbaker.ietf@gmail.com> wrote:
> I'm not sure what has changed in the past lotsa years other
> than which prefix people want to make essentially the same
> arguments about. My observation has been that people don't
> want to extend the life of IPv4 per se; people want to keep using
> it for another very short time interval and then blame someone
> else for the fact that the 32 bit integers are a finite set.

Hi Fred,

The detractors for this proposal and those like it make the core claim
that we shouldn't take the long view improving IPv4 because IPv6 is
going to replace it any day now. Each day that passes with the end of
IPv4 still not in sight demonstrates how very wrong that strategy is.

If there's a change we can make to a standard now which will result in
IPv4 being better 20 years from now, we should make it. We should hope
that we never need the result because IPv6 takes over the world but we
should make the change anyway. Because hedging our bets is what
responsible people do.

Regards,
Bill Herrin


--
William Herrin
bill@herrin.us
https://bill.herrin.us/

On Thu, Nov 18, 2021 at 11:05 AM John R. Levine <johnl@iecc.com> wrote:
..> The IETF is not the Network Police, and all IETF standards are entirely
> voluntary.

Yes, however the IETF standards can be an obstacle -- if they are, then
it is reasonable to adjust that which might impede a future useful development:
regardless of the fact that other obstacles may exist and it may be predicted
to be infeasible in the end. The estimation that effort to update
software will not be
worthwhile much later (10 years from now) cannot be made with enough
confidence;
the other efforts that need to happen is not justification to keep the
standard from changing so
that new/updated software coming out in the near future have a chance to
avoid making making future efforts to reclaim class E or a portion of
127/8 any harder than
they already are today.

The improbability or cost involved in getting software updated should
not impede updating a standard -- Just like the low rate of IPv6
deployment and the
estimation that IPv6 Never manage to fully and totally replace IPv4
should Not prevent
further development of IPv6 nor giving up on IPv6, etc.

Both IPv4 and IPv6 are important standards that should continue to be
maintained.

> Nothing is keeping you from persuading people to change their software to
> treat class E addresses as routable other than the detail that the idea is

The standard could keep you from persuading people - if the standard
says that class E is something else, then the chance of it ever getting close
to be globally usable is about zero .

If the Standards are updated to say that it is globally routable,
Then the chance
of it ever becoming globally routable is still close to zero, at least
for a long period of time,
BUT at least it is improved, even the small improvement that can
come from fewer new software programs
outright blocking it justifies updating the standard, there is no
real downside other than the time and effort'
to actually update the standards..


Adjusting 127/8 is the same way. It seem pretty obvious this should be done..
make the reservation 127.0.0.0/24, or /32, even, and declare the full
of 127.0.0.0/8 as
Unicast reserved. This does not immediately change any software or
operating systems nor
affect anyone's network, since the range in question is non-routable
it has only to do
with individual systems using IPv4 internally and privately, not
related to the internet
or any IP networks to begin with (unless some router internally have
a large swath
of 127/8 for internal system services on its main routing table) - anyway,
System applications can continue using 127/8
internally on local loopback interfaces for local IPC to the heart's content,
Until such time as Operating Systems choose to make (or choose not to
make) changes
to their own system networking functions and network libraries.

Or perhaps they would consider a configuration option such as
- "use one of the /8s from Class E for loopback, in Lieu of 127/8."


As a practical matter on modern OSes: "127.*" seem more of a convenience; You
can run network-based apps privately and use standard network tools such
as "telnet 127.0.0.0" to test protocols over your local Loopback
'devices' without needing
to give an interface such as "ssh -B lo0 127.0.0.0" --

If that's not the scenario (Not a need to access Local applications
using a common network utilities such
as 'ssh' or 'web browser'), Then there are ample alternatives
for example: "Open connection to file /opt/var/run/mysql.sock"
So, uh you only really have reason to use by design 127.0.0.0 if your
software wish to be used over a network.

If it's not such a "standard" client/server program being tested locally,
you can give an interface within the design of your local apps and use
Loopback networks all day without any 127 addresses.. if your OS
make you specify an interface instead of routing Loopback device
traffic, then you could
potentially be allowed to accept and use Any IP in all of the IPv4
space on the Loopback
as part of a separate and distinct private "network", so you could
Re-Use all the RFC1918
IP space for your Loopback IP space without conflicting with other
RFC1918 address usage.

You need only 1 IP address to talk to your local system - Maybe you
run something such as Docker container host, I guess, then a whole /16
seem Ok...


> R's,
> John
--
-JH

On November 18, 2021 at 11:15 cabo@tzi.org (Carsten Bormann) wrote:
> On 2021-11-18, at 00:29, Jay R. Ashworth <jra@baylink.com> wrote:
> >
> > This seems like a really bad idea
>
> Right up there with the FUSSP.

They do have one thing in common which is people will immediately
shoot down proposals because they would take TEN (pick a number) YEARS
to make any difference.

And they'll continue saying that for 20+ years every time it comes up
absolutely certain each time that it's a showstopper.

My take is people reflexively don't like change, they tend to not like
others' solutions (the NIH reaction), and if they can get past those
they certainly want only a solution which can be deployed in a very
short period of time, likely to make a difference in a year or two if
not sooner, at no "cost".

Which is how we get things like yet another layer of encryption since
they're invariably voluntary (DO/DON'T, WILL/WON'T designs, default
DON'T), just cobbled into some existing protocol so can be deployed
immediately at least by a handful of supporters w/o any disruption or
urgency. At least those are failsafe, when almost no one adopts it who
cares?

(I realize there's no encryption involved here IT'S AN ANALOGY, a
meta-observation, OK?)

>
> https://www.rhyolite.com/anti-spam/you-might-be.html
>
> Someone should write a page like that about the FUSIAS (final ultimate solution to the IPv4 address shortage) proposals.
>
> Gr??e, Carsten
>

I don't believe this is being proposed as a final...etc, just:

So long as we do have a shortage how might we at least not waste what
we do have so history doesn't laugh at us.

Let's engineer it to its inevitable depletion and not be even the
tiniest bit guilty of having exacerbated the runout in the vain and
futile hope that it might speed up IPv6 adoption.

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

Time comes at you fast :-)

The POSIX committee has officially adopted 64-bit time_t as a requirement
in the working draft of IEEE Std. 1003.1-202x and ISO/IEC 9945.

One thing to cross off my list. And I was looking forward to all the time
machines crashing into the University of California Berkeley quad on
03:14:07 UTC on 19 January 2038.


On Wed, 17 Nov 2021, Sean Donelan wrote:
> Other problems which will occur sooner:
>
> 1. Unix 32-bit time_t overflow.
> 2. North American Numbering Plan runs out of +1 zone phone numbers
> 3. IPv6 deployed and working everywhere/everything on the Internet
> 4. Analog AM and FM radio broadcasting deprecated (see digital DAB/DRM/HD)
> 5. Heat death of the universe

Fred Baker <fredbaker.ietf@gmail.com> wrote:
> My observation has been that people don't want to extend the life of
> IPv4 per se; people want to keep using it for another very short time
> interval and then blame someone else for the fact that the 32 bit
> integers are a finite set.

It's an attractive strawman, but knocking it down doesn't
contribute to the discussion.

I am not blaming anybody for the finity of 32-bit integers.

Nor am I trying to extend the lifetime of IPv4, for either a short or a
long time. Personally, I think that IPv4 will already be with us for
the rest of my lifetime. Its life will already extend beyond mine,
without any effort on my part. It was a good design, and it will
outlive its makers. The people who in 2008 predicted that it was
senseless to improve IPv4 because it would be dead by 2018, were
objectively wrong, because it's not dead.

IETF did what the objectors said, back in 2008: They didn't improve
IPv4, on the exact theory that effort would go into IPv6 instead. Hmm.
13 years later, that decision did not cause IPv6 to take over the world
and obsolete IPv4. IPv4 is still here, and the improvements that would
have been fully rolled out to the user base by now, if standardized in
2008, are still missing. Perhaps we should reconsider that wrong
advice, rather than regurgitate the same decision every time the issue
is raised?

> If you don't think that's a true statement, I'd be very interested to
> hear what you think might be true.

IPv6 is still on a remarkable if not meteoric growth ramp; in the last
year it's gone from 30% to 34% of the Internet, according to Google.
There is no need to cut off IPv4 maintenance at the knees in order to
make IPv6 look good. We can make both v4 and v6 better, and let people
choose which one(s) they prefer to use.

That's what I think might be true about why simple low-risk tweaks that
make IPv4 better are not an obviously stupid tactic.

As Brian Carpenter has been saying for 15+ years, IPv4 and IPv6 don't
have a transition strategy, they have a co-existence strategy.
Neglecting or abandoning IPv4 is not a useful part of that strategy.

Keeping the price of IPv4 addresses reasonable means that dual-stack
servers can continue to be deployed at reasonable cost, so that it
doesn't matter whether clients have IPv6 or IPv4. Any company that put
its services on IPv6-only sites today would be cutting off 65% of their
potential customers. Even if v6 had 90% of the market, why would a
company want 10% of its prospects to be unable to reach its service?

(Big companies who run massive public-facing server farms are the
biggest buyers of IPv4 addresses in the market, spending hundreds of
millions of dollars every year. Amazon, Google, Alibaba, Microsoft,
etc. They are already running IPv6, and all their servers already have
free IPv6 addresses from a RIR. Why are they spending that money?
It isn't because they are stupid doodooheads who hate IPv6.)

As Fred points out, this issue has been discussed since 2008. IETF also
faced it in 2014-2018 in the now-sunsetted "sunset4" working group.
That group wrote a bunch of drafts proposing to disable or sunset IPv4.
None of these became RFCs. They didn't pass the sniff test. They
weren't what users and customers wanted.

The issue keeps coming back because the wrong decision keeps getting
offered: "Just switch everybody to use IPv6, and if they won't, then
deny their proposals for IPv4." Another way of putting it was proposed
by Dave Thaler: "Rather than changing any existing software (OS's or
apps) to allow class E addresses, the effort would be better spent
towards getting more IPv6 deployment."

This is not an objection to deploying reserved addresses in IPv4, it is
a plea for more IPv6 deployment. It is like saying, "Do not spend your
time fixing the environment, instead we need to fix the political
system."

It is a hopeless plea, since "allowing Class E addresses" and "more IPv6
deployment" are not the only two possible goals to put forth effort on.
Merely stopping work on one, will not cause the other to be advanced.
There must be a name for this fallacious argument...thank you, Wikipedia,
it's a "false dilemma":

https://en.wikipedia.org/wiki/False_dilemma

The two goals can proceed in parallel, and many of the people who would
happily do Goal 1 are not in any position to affect Goal 2 -- just as
with the environment and politics.

It's pretty simple to understand why IPv6 has not taken over the world
yet. IPv4 got rapid adoption because it was so much better than all the
alternatives available at the time. IPv6 would have gotten equally
rapid adoption if it had been the thing so much better than all the
alternatives. IPv6 is not getting that rapid adoption today, because it
has to compete with the already pervasive IPv4. IPv4 is better in one
key way: everybody you want to talk with is already there. (It's akin
to the issue of why can't people just switch to a better social network
than Facebook? They can, but everybody else they want to talk with is
already on Facebook.)

There is no need to cut off IPv4 maintenance at the knees in order to
make IPv6 look good. Simple, low-risk tweaks that make IPv4 better are
not a stupid thing to do.

John

Sent using a machine that autocorrects in interesting ways...

> On Nov 18, 2021, at 5:15 PM, John Gilmore <gnu@toad.com> wrote:
>
> Keeping the price of IPv4 addresses reasonable means that dual-stack
> servers can continue to be deployed at reasonable cost, so that it
> doesn't matter whether clients have IPv6 or IPv4. Any company that put
> its services on IPv6-only sites today would be cutting off 65% of their
> potential customers. Even if v6 had 90% of the market, why would a
> company want 10% of its prospects to be unable to reach its service?

I find myself thinking about Reliance JIO, an Indian company. Iirc, their IPv4 and IPv6 statistics are in the slide deck they presented to the IETF a year or two back, and they came to me/us a little later wanting somehow expand the IPv4 address pool. In short, most of their services are IPv6 only. The only thing they want IPv4 addresses for is their enterprise customers, who want an IPv4 option wherever IPv6 is an option - so they don’t have to select IPv6.

That’s all we’ll and good if the IPv4 addresses exist and work globally. Someone (was it you?) noted earlier in the thread that it might be acceptable to provide IPv4 address space that only worked in certain places. I find myself thinking about the arguments for a global DNS root. What a regional IPv4 connectivity limit creates is a network that doesn’t work everywhere, meaning that the government of <> will be incented to deploy that address space locally within their country and provide a national NAT firewall to somehow protect their citizens - because of course the bad guys are always somewhere else. Kind of like the US wants to regulate encryption because nobody outside the US uses it or whatever. WHATEVER!

I tend to think that if we can somehow bless a prefix and make be global unicast address space, it needs to become Global Unicast Address Space.

This is becoming a rant, so I’ll stop…

Subject: Re: Redploying most of 127/8 as unicast public Date: Thu, Nov 18, 2021 at 01:46:04PM -0800 Quoting William Herrin (bill@herrin.us):
>
> The detractors for this proposal and those like it make the core claim
> that we shouldn't take the long view improving IPv4 because IPv6 is
> going to replace it any day now. Each day that passes with the end of
> IPv4 still not in sight demonstrates how very wrong that strategy is.

Aw, come on. There is noone (except naive ones in power) who expect this
to happen immediately. We all knew there would be a transition
period. The "improvement" part was CIDR. And a very good one it is at
that -- it sort of sets the standard as to what an improvement should
be to count. 6,25% new addresses from Net 240 is not an improvement in
that regard, and neither would the much smaller contribution from Net
127 be. Both are no more than holding paper money on the deck of the
Titanic.

The essence of an IP address is that it is unique. The larger the network
area is that recognizes it as unique, the better it is. That's why RFC
1918 is free and useless. We all know this.

The only viable future is to convert. This is not group-think, it is simple math.

> If there's a change we can make to a standard now which will result in
> IPv4 being better 20 years from now, we should make it. We should hope
> that we never need the result because IPv6 takes over the world but we
> should make the change anyway. Because hedging our bets is what
> responsible people do.

You are proposing a deal involving paper money you have on your person
to your fellow passengers on the Titanic; that is the essence of your
proposed bet hedging. Having studied the market for IPv4, it is a no-
brainer to realise the driving force behind all these schemes. Delaying
the inevitable is just going to make some people richer, to the detriment
of others. I see no reason to support that.

--
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE SA0XLR +46 705 989668
Yow! It's a hole all the way to downtown Burbank!

On Thu, Nov 18, 2021 at 11:20 PM Måns Nilsson <mansaxel@besserwisser.org> wrote:
> Subject: Re: Redploying most of 127/8 as unicast public Date: Thu, Nov 18, 2021 at 01:46:04PM -0800 Quoting William Herrin (bill@herrin.us):
> > The detractors for this proposal and those like it make the core claim
> > that we shouldn't take the long view improving IPv4 because IPv6 is
> > going to replace it any day now. Each day that passes with the end of
> > IPv4 still not in sight demonstrates how very wrong that strategy is.
>
> Aw, come on. There is noone (except naive ones in power) who expect this
> to happen immediately. We all knew there would be a transition
> period. The "improvement" part was CIDR. And a very good one it is at
> that -- it sort of sets the standard as to what an improvement should
> be to count. 6,25% new addresses from Net 240 is not an improvement in
> that regard, and neither would the much smaller contribution from Net
> 127 be. Both are no more than holding paper money on the deck of the
> Titanic.
>
> The essence of an IP address is that it is unique. The larger the network
> area is that recognizes it as unique, the better it is. That's why RFC
> 1918 is free and useless. We all know this.
>
> The only viable future is to convert. This is not group-think, it is simple math.
>
> > If there's a change we can make to a standard now which will result in
> > IPv4 being better 20 years from now, we should make it. We should hope
> > that we never need the result because IPv6 takes over the world but we
> > should make the change anyway. Because hedging our bets is what
> > responsible people do.
>
> You are proposing a deal involving paper money you have on your person
> to your fellow passengers on the Titanic; that is the essence of your
> proposed bet hedging. Having studied the market for IPv4, it is a no-
> brainer to realise the driving force behind all these schemes. Delaying
> the inevitable is just going to make some people richer, to the detriment
> of others. I see no reason to support that.

Howdy,

I can't tell if you believe what you just wrote or are trolling me
with satire. If it's satire... good one.

Regards,
Bill Herrin

--
William Herrin
bill@herrin.us
https://bill.herrin.us/

Mans Nilsson wrote:

> The essence of an IP address is that it is unique. The larger the network
> area is that recognizes it as unique, the better it is.

With proper layering, network addresses including IP ones, certainly,
uniquely identify *hosts*.

However, with proper layering, *applications* only require uniqueness
of IP+Port, which is enough for the worldwide IPv4 network.

As a result, NAT won the battle against IPv6.

IPv6 addresses are free but useless.

Masataka Ohta

This will break a significant number of existing deployments where people
have come to depend on a feature in Linux where any address within 127.0.0.0/8
can be “listened” and operate as a valid loopback address without configuring
the addresses individually as unicast on the interface.

In fact, this is true of any prefix assigned to the loopback interface, but 127.0.0.0/8
is automatic and difficult to change.

While I’m not sure this implementation in the Linux kernel was such a wonderful
idea, it is widely deployed and in use in a number of environments.

If we’re still using IPv4 widely enough that GUA space matters, we will have
far bigger problems than the lack of available GUA for it.

Owen


> On Nov 17, 2021, at 16:15 , William Herrin <bill@herrin.us> wrote:
>
> On Wed, Nov 17, 2021 at 3:31 PM Jay R. Ashworth <jra@baylink.com> wrote:
>> This seems like a really bad idea to me; am I really the only one who noticed?
>>
>> https://www.ietf.org/id/draft-schoen-intarea-unicast-127-00.html
>
> Hi Jay,
>
> I think it's a good idea. It won't be usable any time in the next two
> decades but if we're still using IPv4 in two decades we'll be glad to
> have anything we can scrounge. Why not ask OS authors to start
> assigning 127.0.0.1/16 to loopback instead of 127.0.0.1/8?
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> bill@herrin.us
> https://bill.herrin.us/

> On Nov 17, 2021, at 16:32 , Sean Donelan <sean@donelan.com> wrote:
>
> On Wed, 17 Nov 2021, Jay R. Ashworth wrote:
>> That's over a week old and I don't see 3000 comments on it, so maybe it's just
>> me. So many things are just me.
>
> Someone is wrong on the Internet.
> https://xkcd.com/386/
>
> Other problems which will occur sooner:
>
> 1. Unix 32-bit time_t overflow.
> 2. North American Numbering Plan runs out of +1 zone phone numbers
> 3. IPv6 deployed and working everywhere/everything on the Internet

How is this a problem?

> 4. Analog AM and FM radio broadcasting deprecated (see digital DAB/DRM/HD)
> 5. Heat death of the universe
>
> Again, covered by XKCD
> https://xkcd.com/2240/
>
> I've got other things to do first.

> On Nov 17, 2021, at 19:03 , John Levine <johnl@iecc.com> wrote:
>
> It appears that Joe Maimon <jmaimon@jmaimon.com> said:
>> Mark Andrews wrote:
>>> It’s a denial of service attack on the IETF process to keep bringing up drafts like this that are never going to be approved. 127/8 is
>> in use. It isn’t free.
>>
>> There are so many things wrong with this statement that I am not even
>> going to try to enumerate them.
>
> Aw, c'mon, don't leave us guessing.
>
>> For example
>> https://datatracker.ietf.org/doc/html/draft-fuller-240space-02 from 2008
>> which fell prey to the "by the time this is usable IPv6 will have taken
>> over" groupthink.
>>
>> Objectively wrong.
>
> I will agree that your explanation of the reasons the IETF didn't repurpose 240/8 is objectively wrong.
>
> The amount of work to change every computer in the world running
> TCP/IP and every IP application to treat 240/4 as unicast (or to treat
> some of 127/8) is not significantly less than the work to get them to
> support IPv6. So it would roughly double the work, for a 2% increase
> in the address space, or for 127/8 less than 1%. The code for IPv6
> is already written, after all.

There is an (admittedly questionable) argument to be made that application updates would not
have been necessary for this, just every OS/Computer/Router/Switch/IDS/IPS/etc.

> Also, while the world has run out of free IPv4 address space, there is
> plenty of IPv4 if you are willing to pay for it. A 2% increase in v4
> addresses would not change that.

In fact, the world has not run out, AFRINIC still has a free pool. Unfortunately in an astonishing display
of collective “don’t get it”, they’ve deployed protectionist policies that make it incredibly difficult to get
addresses from AFRINIC, ensuring that while the continent still suffers from the same level of IPv4
address shortage as the rest of the world, the illusion of a useful free pool there will remain for years
to come.

>>> "By contrast, IPv6, despite its vastly larger pool of available address space, allocates only a single local loopback address (::1)
>> [RFC4291]. This appears to be an architectural vote of confidence in the idea that Internet protocols ultimately do not require millions of
>> distinct loopback addresses.”
>>>
>>> This is an apples-to-oranges comparison. IPv6 has both link and site local addresses and an architecture to deliver packets to specific
>>> instances of each. This does not exist in the IPv4 world.

Site local was deprecated many many years ago.

>> SO an IPv6 only system without any network interfaces can run multiple
>> discrete instances of the same daemon accepting connections on the same
>> TCP port?

Depends on your definition of “without any network interfaces”, since technically the loopback interface is a network interface.

If you mean “an IPv6 system with no interfaces other than loopback”, then yes, it can because you are free to assign additional
addresses to the loopback interface, but ::1/128 is the only address universally assigned to the loopback interface.

> Sure.
>
>> Can I script that, can I template that with hardcoded
>> addresses, same as I can now for 127/8?
>
> Sure, if you think that's a good idea which it isn't. Use LLAs on your loopback interface.

On a system with no network interfaces other than loopback, it really doesn’t matter what you do… LLA, ULA, and GUA
could be used in any combination without negative impact. Nothing is leaving the box, so it might as well be an entire
IPv6 internet unto itself.

> Personally, I take my 127/8 addresses from a configuration file since I don't know in advance what
> other daemons might also want to run on addresses only visible on the local machine. Or, you know,
> some maniac might decide that part of 127/8 isn't loopback so I have to move them to the part that
> still is.

Meh. I think individually assigning addresses for those cases isn’t the worst thing in the world, but there are some
circumstances in which the linux kernel’s unique behavior in this regard can be convenient.

> In IPv6 I use ULAs since that gives me the option of routing them or not.

Well… I use GUAs because that gives me the option of routing them widely or narrowly or not.

ULAs don’t have the option to route them widely without resorting to at least NPT which is nearly as hideous as NAPT.

Owen