Re: Redploying most of 127/8 as unicast public

[William Herrin]

On Thu, Nov 18, 2021 at 11:20 PM Måns Nilsson  wrote:
> Subject: Re: Redploying most of 127/8 as unicast public Date: Thu, Nov 18, 
> 2021 at 01:46:04PM -0800 Quoting William Herrin (b...@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
b...@herrin.us
https://bill.herrin.us/

Re: Redploying most of 127/8 as unicast public

[Måns Nilsson]

Subject: Re: Redploying most of 127/8 as unicast public Date: Thu, Nov 18, 2021 
at 01:46:04PM -0800 Quoting William Herrin (b...@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!


signature.asc
Description: PGP signature

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[David Conrad]

> I would be happy to fund or run a project that would announce small
> global routes in each of these ranges, and do some network probing, to
> actually measure how well they work on the real Internet.

To be clear, despite my skepticism, I think this would be an interesting 
experiment to run.  I believe it would be useful to get some actual data on 
reachability/usefulness as the question of deployment of reserved space is a 
recurrent question, both in technical and political spaces.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[David Conrad]

John,

On Nov 18, 2021, at 12:54 PM, John Gilmore  wrote:
> Is it even *doable*?

With enough thrust, pigs fly quite well, although the landing can be messy.

> What's the *risk*?

Some (not me) might argue it could (further) hamper IPv6 deployment by 
diverting limited resources.

> What will it *cost* to upgrade
> every node on the Internet?  And *how long* might it take?

These are the pertinent questions, which are, of course extremely hard to 
estimate.

> We succeeded in upgrading every end-node and every router in the
> Internet in the late '90s and early 2000's, when we deployed CIDR.

My recollection was that CIDR deployment was a bit early than that, but 
regardless, the Internet of the late '90s and early 2000’s was vastly different 
than the Internet today.  For one thing, most of the end nodes still had people 
with technical clue managing them.  That’s not the case today.

> So today if we decide that unicast use of the 268 million addresses in
> 240/4 is worth doing, we can upgrade every node.

Can we?  We can’t even get some DNS resolvers to stop querying root server IP 
addresses that were renumbered two decades ago. People aren’t even 
patching/updating publicly available systems with active security exploits that 
are impacting them directly and you believe they’ll be willing to update all 
their devices to benefit other people (the ones who want the 240/4 space)?  You 
must be more optimistic than I.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Fred Baker]

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

> On Nov 18, 2021, at 5:15 PM, John Gilmore  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…

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Gilmore]

Randy Bush  wrote:
> as a measurement kinda person, i wonder if anyone has looked at how much
> progress has been made on getting hard coded dependencies on D, E, 127,
> ... out of the firmware in all networked devices.

The drafts each have an Implementation Status section that describes
what we know.  The authors would be happy to receive updates for any of
that information.

240/4 is widespread everywhere except in Microsoft products.  It works
so reliably that both Google and Amazon appear to be bootlegging it on
their internal networks.  Google even advises customers to use it:

  https://cloud.google.com/vpc/docs/vpc#valid-ranges

0/8, and the lowest address per subnet, have interoperable
implementations that don't cause problems with legacy equipment, but
they are not widely deployed.  0/8 has a few years in Linux & Android
kernels and distros.  Lowest address is in the most recent Linux and
FreeBSD kernels, but not yet in any OS distros.  In particular, OpenWRT
doesn't implement it yet, which could easily be a fast path to a free
extra IP address for anyone who has a compatible home router and a
globally routed small network like a /29.

We used RIPE Atlas to test the reachability of many addresses that end
in .0 and .0.0, and they were reachable from all but one probe that we
tried.  Amazon offers

  https://ec2-reachability.amazonaws.com/

for this purpose; try it on your own network!

Some embedded TCP stacks treat 127/8 as unicast (simply because they
don't special-case much of anything), but otherwise we don't know of any
current OS distributions that implement unicast for 127/8.  The Linux
kernel has long had a non-default "route_localnet" option offering
similar but more problematic behavior.

I would be happy to fund or run a project that would announce small
global routes in each of these ranges, and do some network probing, to
actually measure how well they work on the real Internet.  We are
working with RIPE Atlas already to enable this.  I thought it would be
prudent to propose the changes in detail to IETF, before "bogus" routes
showed up in BGP and the screaming on the NANOG list started.  :-/

John

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[David Conrad]

John,

On Nov 18, 2021, at 11:37 AM, John Gilmore  wrote:
> At current rates, 300 to 400 million addresses would last more than a decade!

Doesn’t this presume the redeployed addresses would be allocated via a market 
rather than via the RIRs?

If so, who would receive the money?

> There will be no future free-for-all that burns through 300 million IPv4 
> addresses in 4 months.

I suspect you underestimate the global demand and may not fully understand the 
rationale for address acquisition.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[bzs]

That suggests an idea:

Repurpose these addresses and allow the RIRs to sell them in the IPv4
secondary markets with some earmark for the funds. Plus or minus
perhaps some worthy causes for "free" (not quite free but old school)
allocations.

If you can't agree on any worthwhile earmark you can always send me
the proceeds.

-- 
-Barry Shein

Software Tool & Die| b...@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*

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Gilmore]

Fred Baker  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?  

Re: Redploying most of 127/8 as unicast public

[Sean Donelan]

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

Re: Redploying most of 127/8 as unicast public

[bzs]

On November 18, 2021 at 11:15 c...@tzi.org (Carsten Bormann) wrote:
 > On 2021-11-18, at 00:29, Jay R. Ashworth  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| b...@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*

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Jim]

On Thu, Nov 18, 2021 at 11:05 AM John R. Levine  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 downsideother 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

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Karsten Thomann via NANOG]

I find it a bit interesting to follow this thread...

There was a discussion in March where Douglas Fischer shared this 
picture which shows that Amazon is already using 240/4 space internally.

https://pasteboard.co/JRHNVKw.png
And I heard it from other sources, too (not an AWS customer so wont try 
to verify it).


Therefore it is probably nearly impossible to get it to public routeable.
In my opinion it is like RFC 1918, 10.64/10 CGN space or the reserved 
test networks.
Do what ever you want with it internally, but you won't get it into the 
DFZ.


The problem is not to get it routable, but to get it usable in a way 
that you could assign it to customers without causing massive support 
problems.


Am 18.11.2021 um 21:54 schrieb John Gilmore:

Steven Bakker  wrote:

The ask is to update every ip stack in the world (including validation,
equipment retirement, reconfiguration, etc)...

This raises a great question.

Is it even *doable*?  What's the *risk*?  What will it *cost* to upgrade
every node on the Internet?  And *how long* might it take?

We succeeded in upgrading every end-node and every router in the
Internet in the late '90s and early 2000's, when we deployed CIDR.  It
was doable.  We know that because we did it!  (And if we hadn't done it,
the Internet would not have scaled to world scale.)

So today if we decide that unicast use of the 268 million addresses in
240/4 is worth doing, we can upgrade every node.  If we do, we might as
well support unicast on the other 16 million addresses in 0/8, and the
16 million in 127/8, and the other about 16 million reserved for
4.2BSD's pre-standardized subnet broadcast address that nobody has used
since 1985.  And take a hard look at another hundred million addresses
in the vast empty multicast space, that have never been assigned by IANA
for anybody or anything.  Adding the address blocks around the edges
makes sense; you only have to upgrade everything once, but the 268
million addresses becomes closer to 400 million formerly wasted
addresses.  That would be worth half again as much to end users,
compared to just doing 240/4!

That may not be worth it to you.  Or to your friends.  But it would be
useful to a lot of people -- hundreds of millions of people who you may
never know.  People who didn't get IP addresses when they were free,
people outside the US and Europe, who will be able to buy and use them
in 5 or 10 years, rather than leaving them unused and rotting on the
vine.

We already know that making these one-line patches is almost risk-free.
240/4 unicast support is in billions of nodes already, without trouble.
Linux, Android, MacOS, iOS, and Solaris all started supporting unicast
use of 240/4 in 2008!  Most people -- even most people in NANOG --
didn't even notice.  0/8 unicast has been in Linux and Android kernels
for multiple years, again with no problems.  Unicast use of the lowest
address in each subnet is now in Linux and NetBSD, recently (see the
drafts for specifics).  If anyone knows of security issues that we
haven't addressed in the drafts, please tell us the details!  There has
been some arm-waving about a need to update firewalls, but most of these
addresses have been usable as unicast on LANs and private networks for
more than a decade, and nobody's reported any firewall vulnerabilities
to CERT.

Given the low risk, the natural way for these unicast extensions to roll
out is to simply include them in new releases of the various operating
systems and router OS's that implement the Internet protocols.  It is
already happening, we're just asking that the process be adopted
universally, which is why we wrote Internet-Drafts for IETF.  Microsoft
Windows is the biggest laggard; they drop any packet whose destination
OR SOURCE address is in 240/4.  When standards said 240/4 was reserved
for what might become future arcane (variable-length, anycast, 6to4,
etc) addressing modes, that made sense.  It doesn't make sense in 2021.
IPv4 is stable and won't be inventing any new addressing modes.  The
future is here, and all it wants out of 240/4 is more unicast addresses.

By following the normal OS upgrade path, the cost of upgrading is almost
zero.  People naturally upgrade their OS's every few years.  They
replace their server or laptop with a more capable one that has the
latest OS.  Laggards might take 5 or 10 years.  Peoples' home WiFi
routers break, or are upgraded to faster models, or they change ISPs and
throw the old one out, every 3 to 5 years.  A huge proportion of
end-users get automatic over-the-net upgrades, via an infrastructure
that had not yet been built for consumers during the CIDR transition.
"Patch Tuesday" could put some or all of these extensions into billions
of systems at scale, for a one-time fixed engineering and testing cost.

We have tested major routers, and none so far require software updates
to enable most of these addresses (except on the lowest address per
subnet).  At worst, the ISP would have to turn off 

Re: Redploying most of 127/8 as unicast public

[William Herrin]

On Thu, Nov 18, 2021 at 12:40 PM Fred Baker  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
b...@herrin.us
https://bill.herrin.us/

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Joe Maimon]

Nick Hilliard wrote:

John Gilmore wrote on 18/11/2021 19:37:

There will be no future free-for-all that burns through 300 million
IPv4 addresses in 4 months.


this is correct not necessarily because of the reasons you state, but 
because all the RIRs have changed their ipv4 allocation policies to 
policies which assume complete or near-complete depletion of the 
available pools, rather than policies which allocate / assign on the 
basis of stated requirement.  For sure, organisations were previously 
requesting more than they needed, but if stated-requirement were 
reinstituted as a policy basis, the address space would disappear in a 
flash.


I think it more likely that organizations will treat new space like they 
do their reclaimed/returned allocations right now. We are not going 
back. IPv4 only becomes plentiful again upon obsolescence.


Need is elastic based upon general availability of supply. To say it 
differently, organizations were requesting more than than they 
absolutely required to get by. And that was ok, because there was no 
reason to require them to twist themselves into engineering pretzels 
when IPv4 was freely available.


Simple example, back in the day you could choose to deploy a T1 customer 
with a public /30 and routed /29 and that would have easily met needs 
requirements.


On the other hand, you could also deploy the same customer with 
unnumbered or private /30 and routed to loopback public /32.



The point remains that 127/8, 0/8, 240/4 are problematic to 
debogonise, and are not going to make a dramatic impact to the 
availability of ipv4 addresses in the longer term. Same with using the 
lowest ip address in a network block.  Nice idea, but 30 years late.


There's no problem implementing these ideas in code and quietly using 
the address space in private contexts.


Nick




Right or wrong, it would be nice to remove any impediment to the effort 
absent justifiable document-able and insurmountable reason why the space 
should NOT be usable.


And those impediments manifest themselves even for quietly using the 
address space in private contexts.


Also, the 30 intervening years have dramatically upped the stakes in 
terms of RoI.


I suggest considering these proposals in the light that IPv4 may be 
obsolete in a decade. And maybe not.


If it is obsolete, whats the harm?

And if it not, the benefits are clearer than ever.

Joe

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Randy Bush]

as a measurement kinda person, i wonder if anyone has looked at how much
progress has been made on getting hard coded dependencies on D, E, 127,
... out of the firmware in all networked devices.

randy

VIDEO | WATCH NANOG 83 Keynotes + More

[Nanog News]

*VIDEO | NANOG 83 KEYNOTE*
*Bert Hubert Asks Who Controls the Internet? And Should They?*

*Keynote: *Who really controls the Internet? And should they?
*Speaker:* Bert Hubert

This talk is not for the faint of heart. Bert shares the more disconcerting
details of government control within each country. He additionally
discusses how control of the internet experience is moving more and more
into the hands of browser and phone vendors. The advent of end-to-end
encryption, also on control planes and metadata like DNS, means that no one
else is able to influence the internet - except in extremely heavy handed
and binary fashion.

*WATCH BERT *


*VIDEO | NANOG 83 KEYNOTE *
John Jason Brzozowski discusses the Near Future of IPv6

*Keynote:* IPv6 - The next 10 years
*Speaker: *John Jason Brzozowski

World IPv6 Day was in 2011, World IPv6 Launch in 2012. John will briefly
reflect on the status of IPv6 deployment across eyeball and content
networks ~10 years later. He takes a look at statistics across a wide range
of public and private (cited) sources. In 2021 the cost of IPv4 address
acquisition is increasing, dramatically. He will take a close look at what
has worked and what has not, across the board, focusing on what the next 10
years of IPv6 needs to look like to not just increase adoption, but to
increase bonafide end to end usage.

*WATCH JOHN*


*WANTED: Experts to Train + Inspire our Next-Gen *
The NANOG Education Committee is seeking proposals from experienced
consulting firms or individuals to develop a NANOG proprietary
technology-based program that will be offered to the NANOG community in
continuing education.

To learn more about how your expertise can inspire + educate our next
generation of networking professionals click below.

*LEARN MORE *

*VIDEO | Empowering "Courageous Women of NANOG"  *
Chief commercial officer + co-founder of PacketFabric, Jezzibell Gilmore
shared a powerful talk at our NANOG 83 meeting, acknowledging the powerful
impact our female leaders have had (and continue to have) on the industry.

*WATCH JEZZIBELL * 

*Get Your NANOG 83 Swag On*

Share the love + show off your NANOG pride with a t-shirt, sweatshirt,
polo, cap, or laptop stickers. And don’t forget to tag us in your NANOG
pics on Facebook, Instagram, Twitter, and LinkedIn so we can follow along!
#WeAreNANOG

*SHOP NOW  *

[NANOG-announce] VIDEO | WATCH NANOG 83 Keynotes + More

[Nanog News]

*VIDEO | NANOG 83 KEYNOTE*
*Bert Hubert Asks Who Controls the Internet? And Should They?*

*Keynote: *Who really controls the Internet? And should they?
*Speaker:* Bert Hubert

This talk is not for the faint of heart. Bert shares the more disconcerting
details of government control within each country. He additionally
discusses how control of the internet experience is moving more and more
into the hands of browser and phone vendors. The advent of end-to-end
encryption, also on control planes and metadata like DNS, means that no one
else is able to influence the internet - except in extremely heavy handed
and binary fashion.

*WATCH BERT *


*VIDEO | NANOG 83 KEYNOTE *
John Jason Brzozowski discusses the Near Future of IPv6

*Keynote:* IPv6 - The next 10 years
*Speaker: *John Jason Brzozowski

World IPv6 Day was in 2011, World IPv6 Launch in 2012. John will briefly
reflect on the status of IPv6 deployment across eyeball and content
networks ~10 years later. He takes a look at statistics across a wide range
of public and private (cited) sources. In 2021 the cost of IPv4 address
acquisition is increasing, dramatically. He will take a close look at what
has worked and what has not, across the board, focusing on what the next 10
years of IPv6 needs to look like to not just increase adoption, but to
increase bonafide end to end usage.

*WATCH JOHN*


*WANTED: Experts to Train + Inspire our Next-Gen *
The NANOG Education Committee is seeking proposals from experienced
consulting firms or individuals to develop a NANOG proprietary
technology-based program that will be offered to the NANOG community in
continuing education.

To learn more about how your expertise can inspire + educate our next
generation of networking professionals click below.

*LEARN MORE *

*VIDEO | Empowering "Courageous Women of NANOG"  *
Chief commercial officer + co-founder of PacketFabric, Jezzibell Gilmore
shared a powerful talk at our NANOG 83 meeting, acknowledging the powerful
impact our female leaders have had (and continue to have) on the industry.

*WATCH JEZZIBELL * 

*Get Your NANOG 83 Swag On*

Share the love + show off your NANOG pride with a t-shirt, sweatshirt,
polo, cap, or laptop stickers. And don’t forget to tag us in your NANOG
pics on Facebook, Instagram, Twitter, and LinkedIn so we can follow along!
#WeAreNANOG

*SHOP NOW  *
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Gilmore]

Steven Bakker  wrote:
> The ask is to update every ip stack in the world (including validation,
> equipment retirement, reconfiguration, etc)...

This raises a great question.

Is it even *doable*?  What's the *risk*?  What will it *cost* to upgrade
every node on the Internet?  And *how long* might it take?

We succeeded in upgrading every end-node and every router in the
Internet in the late '90s and early 2000's, when we deployed CIDR.  It
was doable.  We know that because we did it!  (And if we hadn't done it,
the Internet would not have scaled to world scale.)

So today if we decide that unicast use of the 268 million addresses in
240/4 is worth doing, we can upgrade every node.  If we do, we might as
well support unicast on the other 16 million addresses in 0/8, and the
16 million in 127/8, and the other about 16 million reserved for
4.2BSD's pre-standardized subnet broadcast address that nobody has used
since 1985.  And take a hard look at another hundred million addresses
in the vast empty multicast space, that have never been assigned by IANA
for anybody or anything.  Adding the address blocks around the edges
makes sense; you only have to upgrade everything once, but the 268
million addresses becomes closer to 400 million formerly wasted
addresses.  That would be worth half again as much to end users,
compared to just doing 240/4!

That may not be worth it to you.  Or to your friends.  But it would be
useful to a lot of people -- hundreds of millions of people who you may
never know.  People who didn't get IP addresses when they were free,
people outside the US and Europe, who will be able to buy and use them
in 5 or 10 years, rather than leaving them unused and rotting on the
vine.

We already know that making these one-line patches is almost risk-free.
240/4 unicast support is in billions of nodes already, without trouble.
Linux, Android, MacOS, iOS, and Solaris all started supporting unicast
use of 240/4 in 2008!  Most people -- even most people in NANOG --
didn't even notice.  0/8 unicast has been in Linux and Android kernels
for multiple years, again with no problems.  Unicast use of the lowest
address in each subnet is now in Linux and NetBSD, recently (see the
drafts for specifics).  If anyone knows of security issues that we
haven't addressed in the drafts, please tell us the details!  There has
been some arm-waving about a need to update firewalls, but most of these
addresses have been usable as unicast on LANs and private networks for
more than a decade, and nobody's reported any firewall vulnerabilities
to CERT.

Given the low risk, the natural way for these unicast extensions to roll
out is to simply include them in new releases of the various operating
systems and router OS's that implement the Internet protocols.  It is
already happening, we're just asking that the process be adopted
universally, which is why we wrote Internet-Drafts for IETF.  Microsoft
Windows is the biggest laggard; they drop any packet whose destination
OR SOURCE address is in 240/4.  When standards said 240/4 was reserved
for what might become future arcane (variable-length, anycast, 6to4,
etc) addressing modes, that made sense.  It doesn't make sense in 2021.
IPv4 is stable and won't be inventing any new addressing modes.  The
future is here, and all it wants out of 240/4 is more unicast addresses.

By following the normal OS upgrade path, the cost of upgrading is almost
zero.  People naturally upgrade their OS's every few years.  They
replace their server or laptop with a more capable one that has the
latest OS.  Laggards might take 5 or 10 years.  Peoples' home WiFi
routers break, or are upgraded to faster models, or they change ISPs and
throw the old one out, every 3 to 5 years.  A huge proportion of
end-users get automatic over-the-net upgrades, via an infrastructure
that had not yet been built for consumers during the CIDR transition.
"Patch Tuesday" could put some or all of these extensions into billions
of systems at scale, for a one-time fixed engineering and testing cost.

We have tested major routers, and none so far require software updates
to enable most of these addresses (except on the lowest address per
subnet).  At worst, the ISP would have to turn off or reconfigure a
bogon filter with a config setting.  Also, many "Martian address" bogon
lists are centrally maintained
(e.g. https://team-cymru.com/community-services/bogon-reference/ ) and
can easily be updated.  We have found no ASIC IP implementations that
hardwire in assumptions about specific IP address ranges.  If you know
of any, please let us know, otherwise, let's let that strawman rest.

Our drafts don't propose to choose between public and private use of the
newly usable unicast addresses (so the prior subject line that said
"unicast public" was incorrect).  Since the kernel and router
implementation is the same in either case, we're trying to get those
fixed first.  There will be plenty of years and plenty of forums (NANOG,
IETF, 

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[Nick Hilliard]

John Gilmore wrote on 18/11/2021 19:37:

There will be no future free-for-all that burns through 300 million
IPv4 addresses in 4 months.


this is correct not necessarily because of the reasons you state, but 
because all the RIRs have changed their ipv4 allocation policies to 
policies which assume complete or near-complete depletion of the 
available pools, rather than policies which allocate / assign on the 
basis of stated requirement.  For sure, organisations were previously 
requesting more than they needed, but if stated-requirement were 
reinstituted as a policy basis, the address space would disappear in a 
flash.


The point remains that 127/8, 0/8, 240/4 are problematic to debogonise, 
and are not going to make a dramatic impact to the availability of ipv4 
addresses in the longer term.  Same with using the lowest ip address in 
a network block.  Nice idea, but 30 years late.


There's no problem implementing these ideas in code and quietly using 
the address space in private contexts.


Nick

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

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

Re: Redploying most of 127/8 as unicast public

[Fred Baker]

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

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Justin Streiner]

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

Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[John Gilmore]

Steven Bakker  wrote:
> > ... the gain is 4 weeks of
> > extra ip address space in terms of estimated consumption.
>
> The burn rate is the best argument I've seen against the idea so far.

I'm glad you think so, since it's easy to refute.

There will be no future free-for-all that burns through 300 million
IPv4 addresses in 4 months.

When IPv4 addresses were being given away for free, of course people
were grabbing them as fast as they could.  Particularly after everyone
could see the end of the supply coming.  It took detailed administrative
bureacracy, checking paperwork "justifications", to just slow down the
free-for-all!  (In the early '90s I got 140.174/16 for the same cost as
a /24, by sending a few emails asking for it.  By the end of the '90s,
that /16 was one of the major assets of our small ISP!)

Now that has ended, and addresses actually cost money in a real market.
Companies are only buying what they need, because they have other uses
for their money.  And other companies are selling addresses that they
once obtained and no longer plan to use.  It's like the difference
between getting free land from the government, versus having to pay for
it.  You'd rather have 100 acres or 1000 acres if it's free.  But if you
have to buy it, well, half an acre is still pretty nice, and leaves you
some money to build a house on it.

Now we have a market.  When low supply raises the price of something,
people are going to buy less of it.  The initial price rise from $0/each
to $11.25 was in 2011, after ARIN announced there would be no more free
addresses, and Microsoft bought Nortel's addresses out of bankruptcy.
The Internet world has adapted.  It's been a decade since that
adaptation.  Adding some global unicast address supply in a few years
would reduce prices, benefiting consumers, but won't take us back to the
old pre-market model.

Here's an analysis as of late 2020 of the IPv4 transfer market:

  https://circleid.com/posts/20201125-ipv4-market-and-ipv6-deployment

It shows a range of 6 million to 16 million addresses transferred (sold)
per quarter.  This roughly matches Geoff Huston's analysis of both free
RIR allocations, and purchased IPv4 transfers.  Geoff reports about
2.2 million allocated and 26 million transferred in 2020:

  
https://circleid.com/posts/20210117-a-look-back-at-the-world-of-ip-addressing-in-2020

At current rates, 300 to 400 million addresses would last more than a
decade!  (Compare this to the ~50 /8s unadvertised in global routing
tables, about 838 million addresses, that are currently owned but likely
to be sold to someone who'll route them, sometime in the next decade.)

There will be no future free-for-all that burns through 300 million
IPv4 addresses in 4 months.

John

Re: Redploying most of 127/8 as unicast public

[William Herrin]

On Thu, Nov 18, 2021 at 10:14 AM Jay R. Ashworth  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
b...@herrin.us
https://bill.herrin.us/

Re: Redploying most of 127/8 as unicast public

[Jay R. Ashworth]

- Original Message -
> From: "Justin Keller" 

> 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  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   
>> j...@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   j...@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

Re: Redploying most of 127/8 as unicast public

[John Kristoff]

On Thu, 18 Nov 2021 08:53:53 -0800
Jonathan Kalbfeld via NANOG  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

Re: WKBI #586, Redploying most of 127/8 as unicast public

[David Conrad]

On Nov 18, 2021, at 9:00 AM, 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.

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



signature.asc
Description: Message signed with OpenPGP

Re: Redploying most of 127/8 as unicast public

[Joe Maimon]

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.



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.


Jonathan

Jonathan Kalbfeld

office: +1 310 317 7933 
fax: +1 310 317 7901 
home: +1 310 317 7909 
mobile: +1 310 227 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 > 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 
  j...@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

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Joe Maimon]

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

Re: WKBI #586, Redploying most of 127/8 as unicast public

[John R. Levine]

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

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Joe Maimon]

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

Re: Redploying most of 127/8 as unicast public

[Jonathan Kalbfeld via NANOG]

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?  

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.

Jonathan

Jonathan Kalbfeld

office: +1 310 317 7933 
fax:+1 310 317 7901 
home:   +1 310 317 7909 
mobile: +1 310 227 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  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   
> j...@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

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Joe Maimon]

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

Re: FERC releases final report on Texas power outages (2021)

[Andy Ringsmuth]

> On Nov 17, 2021, at 11:31 PM, Haudy Kazemi via NANOG  wrote:
> 
> Yet, in spite of claims of TX being an island, customers all over the country 
> are now being forced to pay energy surcharges specifically tied to the Feb 
> 2021 TX event. It was a line item on my last bill.
> 
> 
> On Wed, Nov 17, 2021, 21:03 Sean Donelan  wrote:
> "Those Who Do Not Learn History Are Doomed To Repeat It."
> 
> 
> However, Texas maintains its electric grid as an isolated island, and 
> hasn't followed past recommendations to avoid electric grid outages.
> 
> https://www.mysanantonio.com/news/local/article/Federal-report-warns-Texas-power-outages-16628257.php

“specifically tied to” ≠ "Caused by."

Do you mean to say that an ELECTRIC bill elsewhere in the country has gone up 
SPECIFICALLY because of what happened last February in Texas? I note the use of 
the phrasing “energy surcharges” without specifying what kind of energy.

You may have a natural gas line item, but that was not CAUSED BY what happened 
in Texas. It was in the same timeframe, but what happened was a weather issue, 
not a Texas issue. Unusually extreme cold weather across an unusually large 
part of the country caused temporary insane demand in the natural gas markets 
around the country, resulting in huge spikes in cost for natural gas on the 
spot market. Some gas utilities around the country had prepared for such an 
eventuality by storing gas or with long-term price contracts, others did not.

That does not necessarily mean Texas CAUSED the problem.

-Andy

Re: Redploying most of 127/8 as unicast public

[Justin Keller]

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

On Wed, Nov 17, 2021 at 6:31 PM Jay R. Ashworth  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   
> j...@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

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Dave Taht]

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?

...

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.

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.

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Steven Bakker]

On Thu, 2021-11-18 at 10:51 +, Nick Hilliard wrote:
> The ask is to update every ip stack in the world (including
> validation, 
> equipment retirement, reconfiguration, etc) and the gain is 4 weeks
> of 
> extra ip address space in terms of estimated consumption.

(Not to mention the static 127.in-addr.arpa zone that pretty much every
resolver has configured by default these days.)

The burn rate is the best argument I've seen against the idea so far.

-- Steven


signature.asc
Description: This is a digitally signed message part

Re: Redploying most of 127/8 as unicast public

[jim deleskie]

This is actually worse than our collective progress on replacing v4 to
date.

-jim

On Wed, Nov 17, 2021 at 7:31 PM Jay R. Ashworth  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
> j...@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
>

Re: Redploying most of 127/8 as unicast public

[John Curran]

On 17 Nov 2021, at 6:29 PM, Jay R. Ashworth  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


Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-schoen-intarea-unicast-127-00
Updates:
1122 , 1812 
, 2827 
, 3704 
 (if approved)
Published:
8 November 2021






Perhaps it was just submitted 144 days too earlier and thus was miscategorized?
;-) 
/John

Disclaimer(s): my views alone.  Contains 100% recycled electrons.

Re: Redploying most of 127/8 as unicast public

[Masataka Ohta]

Jay R. Ashworth 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 definitely a stupid idea.

As it requires to update all the end systems not to recognize 127/8
as loopback, releasing Class E, which is 16 times larger than 127/8,
as an additional public unicast address range is a lot (16 times)
better.

Though intermediate systems such as backbone routers must be updated
to release Class E, that is a lot lot lot less painful to replace the
end systems.

Masataka Ohta

Re: WKBI #586, Redploying most of 127/8 as unicast public

[Nick Hilliard]

John Levine wrote on 18/11/2021 03:03:

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.

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.


putting more numbers on the table, the pre-exhaustion burn rate of 
unallocated ipv4 address space was around 13 x /8 a year, i.e. a /8 
every four weeks.


The ask is to update every ip stack in the world (including validation, 
equipment retirement, reconfiguration, etc) and the gain is 4 weeks of 
extra ip address space in terms of estimated consumption.


Nick

Re: Redploying most of 127/8 as unicast public

[Carsten Bormann]

On 2021-11-18, at 00:29, Jay R. Ashworth  wrote:
> 
> This seems like a really bad idea

Right up there with the FUSSP.

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

Re: Redploying most of 127/8 as unicast public

[Greg Skinner via NANOG]

It’s being discussed on Hacker News.

https://news.ycombinator.com/item?id=29246420

> On Nov 17, 2021, at 3:29 PM, Jay R. Ashworth  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 at 
> 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

Re: Redploying most of 127/8 as unicast public

[borg]

No, you are not alone. This just gets kinda pathetic.
It also shows how an IPv6 is a failure.
(No please, leave me alone all you IPv6 zealots).

I think its time to go back to design board and start
working on IPv8 ;) so we finnaly get rid of IPv4...

-- Original message --

From: Jay R. Ashworth 
To: nanog 
Subject: Redploying most of 127/8 as unicast public
Date: Wed, 17 Nov 2021 23:29:49 + (UTC)

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   j...@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