Subject: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address

From: Seth David Schoen <[email-masked]>
Date: Sun, 1 Aug 2021 22:59:16 -0700

Hi,

John Gilmore, Dave Taht and I have proposed a recent Internet-Draft that
relates to the Internet Area.  We hope you'll read it and discuss it:

  https://datatracker.ietf.org/doc/draft-schoen-intarea-lowest-address/

  With ever-increasing pressure to conserve IP address space on the
  Internet, it makes sense to consider where relatively minor changes
  can be made to fielded practice to improve numbering efficiency.  One
  such change, proposed by this document, is to increase the number of
  unicast addresses in each existing subnet, by redefining the use of
  the lowest-numbered (zeroth) host address in each IPv4 subnet as an
  ordinary unicast host identifier, instead of as a duplicate segment-
  directed broadcast address.

Our IPv4 Unicast Extensions team is working on several related
proposals for improving address space utilization, of which this is
the first.  We are also editing I-Ds for each of the other proposals
and will upload them to the datatracker when they're ready.  Each
proposal changes the status of some particular unused IPv4 addresses
in order to make more address space available, and each has involved
experimentation with real-world operating systems to explore the ease
with which the proposed change can be made and learn about its
consequences.

These proposals would, if adopted and deployed, produce another tens
to hundreds of millions of IPv4 addresses usable for unicast traffic.
This can be accomplished by making quite small, easy to make, easy to
test, incremental changes in popular TCP/IP implementations.  (The Lowest
Address patch for Linux is less than 10 lines long, and the BSD patch is
similar.  They interoperate with each other and are already addressable
by unpatched implementations when distant from the local subnet.)  As we
will describe in more detail in future posts, we expect these changes will
create enormous economic value, and they are not intended as an attack on
the IPv6 transition.

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 2 Aug 2021 16:50:11 +0100

>   https://datatracker.ietf.org/doc/draft-schoen-intarea-lowest-address/

I'd suggest you'd have a hard job making local links safe for on-link
use of the all-0-host address, if only because of the number of routers
deployed (e.g. Cisco boxes, but probably others as wlll) which have that
knowledge hard coded.  i.e.  they treat them on RX just like the
IPv6 "any router" case, so will not ARP for the target.

It isn't difficult to remove from some places in s/w, but getting the
boxes upgraded may well be difficult.  Fixing the 'directed broadcast'
case was an easier sell.

So I'd suggest that ship has sailed wrt on-link all-0-host addresses.

That said, I already make use of the the subnet all-0 and all-1 host
addresses, but off-link. e.g. as NAT addresses because off link devices
simply can not know where the CIDR boundaries are.  I suspect that
is about the best which can be done.

I'd suggest it wouldn't be safe to hand such out to "normal" hosts,
e.g. by DHCP, but one could envisage some special UDP based services
using the address.

So while we could make this change, I suspect it will be a long time
before such all-0-host addresses are generally usable on-link.

It is possible some routers drop off-link packets destined to the
all zero host address not only due to ACLs, but due to the don't
forward directed broadcast behaviour.

(Note you could also pursue deprecating the all-1-host address being
 used as a local broadcast, as 255.255.255.255 can replace most such
 on link uses.  That would also strike me as a forlone hope).

DF

---

From: Bob Hinden <[email-masked]>
Date: Mon, 2 Aug 2021 09:45:07 -0700

Seth,

Do I understand correctly, that you are proposing that all hosts, routers, firewalls, middle boxes, etc. on the Internet, be updated in order to get a single extra IP address per subnet?  Plus then having to deal with the complexities of mixed implementations for a very long transition period.

To me this fails the cost benefit analysis.

Bob

> On Aug 1, 2021, at 10:59 PM, Seth David Schoen <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Aug 2021 08:44:45 +1200

> As we

Most of the consolidation of IPv4 usage by ISPs in recent years has been
in the deployment of CGNs and aggressive address sharing. As far as I can
tell, most consolidation of IPv4 usage within enterprises has been based
on Net 10. So I am not at all clear where this economic value would be,
or why the IETF should even care about it. 

Regards
   Brian

On 02-Aug-21 17:59, Seth David Schoen wrote:
> .

---

From: Seth David Schoen <[email-masked]>
Date: Mon, 2 Aug 2021 17:07:00 -0700

Hi Derek, thanks for your comments.

> IPv6 "any router" case, so will not ARP for the target.

Yes, that's the common behavior of existing devices.

> is about the best which can be done.

Yes, for example if you go to http://ec2-reachability.amazonaws.com/
your client will connect to numerous hosts ending in .0, which in a /24
or smaller would be the lowest addresses in their respective subnets.
We can't tell from the outside whether those hosts are actually the
lowest addresses (with host and router patches to allow them to be
reachable) or whether they are part of a larger-than-/24 subnet in each
case and just happen to be ordinary hosts in the middle.  As you
suggested, RFC 4632 already expects distant hosts ("off-link") not to
make assumptions about this.

> e.g. by DHCP, but one could envisage some special UDP based services

In our view, it would be entirely at the discretion of the network
administrator, based on his or her knowledge of the local network
environment, and we wouldn't suggest that it be a default behavior in
a DHCP server configuration as shipped by an OS vendor.  For instance,
if you told a DHCP server to hand out addresses from 192.168.42.0/24,
it would continue to default to not assigning 192.168.42.0 due to
uncertainty about whether a device could usefully accept such an
assignment.  But a network administrator could individually choose to
assign it on a particular network where it's clear that all of the
devices had been upgraded.  This is especially straightforward in a
managed hosting environment, which is also where IPv4 addresses are
most in demand.

In support of this, we have a patch in the Linux kernel, currently
included in the 5.14 kernel release candidates, which changes
the host and router behavior for Linux routers and hosts to remove
the interpretation of the lowest address as a directed broadcast.
Clearly, this will be an interoperability problem initially for
unpatched devices, so we haven't done anything to make userspace (or
users) make use of these addresses.  But, as you note, if you know
that you're able to do so on a particular network, you can do that
right away and it should interoperate with distant hosts today.

> before such all-0-host addresses are generally usable on-link.

I agree.  A nice thing for this particular proposal is the on-link
versus off-link distinction that you mention: here the off-link work
was already done for RFC 4632 so if you know that your segment will
be OK, you can opt into it.  (Note that this is already true now,
because nobody on the rest of the Internet can even tell the
difference!  But right now the IETF standards are calling for
implementations _not_ to facilitate this within a link.)

More generally, we don't expect our proposals to have an immediate
positive effect of achieving global interoperability; there will be
no "flag days".  The idea is that IETF would first approve some or
all of these proposed extensions of the IPv4 protocol, changing the
behavior expected of hosts and routers.  New releases of existing
software (like operating systems) and firmware (like dedicated router
software) will then make these small changes.  (Some of our proposals,
as we'll describe more when we submit our other drafts, are already
implemented in major operating systems.  One has been enabled for a
decade without any ill effects; another for a year, also without ill
effects.)

We don't expect many people to deliberately install new software or
firmware in order to enable these IP protocol changes.  Instead, we
expect the changes to roll out as part of the usual process of
refreshing equipment in the field.

Network operators and end-users will gradually install these newer
releases, for whatever reason, whether they buy new equipment, upgrade
existing OS's, install security updates, etc.  The Internet community
has done this twice before for CIDR and for IPv6 -- in both cases,
piecemeal as software and devices were gradually updated.  CIDR and
IPv6 edge support took years, and we expect our proposed improvements
to take years also.  And yet, today, many more operating systems now
have automatic over-the-net update mechanisms, which will reduce the
manual labor of installing upgrades, in many cases to zero for end-users.

Eventually, after years, there will be corner cases in which a
particular site may want to use an IP protocol improvement, and finds a
needs to upgrade or replace some older equipment merely to enable the
protocol improvement throughout their subnet.  (We have similar
situations today, in which a user may need to upgrade their ancient DSL
router before they can participate in IPv6, for example.)  But we expect
that to be a small minority of situations.  Instead, the capabilities
will just roll out gradually, until a point when, after years, they
become more generally usable than unusable.

One could argue, that given the years it would take, it's not worth doing
at all.  The same wasn't true of CIDR, and it wasn't true of IPv6.
Regarding improvements to IPv4 unicast, that argument won the day 13
years ago, when similar ideas were proposed and not accepted (in
draft-wilson-class-e and draft-fuller-240space).  From the viewpoint of
today, we would have been better off if 10 years ago we had said "Go
ahead", because if we had, today the protocol improvements would be
fully landed and we would be using them.  As the saying goes, the best
time to plant a tree is 10 years ago, and the second best is now.

> forward directed broadcast behaviour.

Assuming you're referring to distant routers that don't have any
interfaces on the affected link at all (wrongly assuming that the
distant destination address is a directed broadcast when it ends with
8 or more zero bits), there was a NANOG mailing list thread talking
about this behavior not long ago.  While it's an improper assumption
under RFC 4632, it may occur here and there.  But we don't think it's
particularly common; we ran some tests on RIPE Atlas, for example, to
connect to some of the .0 hosts in the EC2 test services mentioned
above.  They were roughly as reachable as non-.0 hosts.

If you're talking about routers that do have an interface on the
affected link, they would already not deliver those packets successfully
for the reason you mentioned that they wouldn't ARP for them and would
instead deliver them -- if at all -- as link-layer broadcasts.

>  on link uses.  That would also strike me as a forlone hope).

We've also thought about this, and it seems clear, e.g. from IPv6's
approach to address scope, that we would have been better off overall
with a significantly different broadcast architecture in IPv4 as well.
However, we chose to propose deprecating only the all-0s form because
it has consistently been described for decades as obsolete, and as
existing only for backwards compatibility with systems that no longer
exist today, for decades.  By contrast, there could be a few real
applications using the all-1s form in places, even if there are better
alternatives available for it.

Our view is that it's wasteful to have two different directed broadcast
addresses for a reason long acknowledged as obsolete.  Having a directed
broadcast concept at all may not have been an ideal choice in retrospect
-- certainly RFC 2644 means that it's a lot less useful than was first
anticipated, since it came to be abused for denial-of-service attack
amplification -- but we're not proposing to eliminate that concept.

---

From: Seth David Schoen <[email-masked]>
Date: Mon, 2 Aug 2021 17:14:44 -0700

> To me this fails the cost benefit analysis.

Hi Bob, thanks for your reply.

Yes, we're proposing a change that affects all hosts and routers in
order to get an extra address per subnet.  As I described in my reply
to Derek Fawcus, this change -- unlike some of the other changes we
will propose :-) -- has a particularly nice incremental-deployment story
due to RFC 4632 and the largely correct existing behavior around it.

This is to say that, if you patch your own devices and then deliberately
number a host with the lowest address, the rest of the world can already
talk to that host under existing standards.  (Patching your devices has
little cost in functionality to you; you lose only a disused obsolete
form of directed broadcast.)

In this case, if you don't patch your devices, you can also already
talk to anyone else who does; there's no way for you to know!

Thus, the biggest benefit of officially standardizing this is to
encourage vendors to start changing this behavior now, so that it will
be correspondingly more likely that people who care will have
fully-patched or sufficiently-patched network segments in the future.
With this change, people who don't care or don't know the compatibility
details of devices on their local networks can just continue not to
assign the lowest address at all.  (Conveniently, the networks where a
single extra IPv4 address is most valuable are also generally the same
networks where it's easiest for the network administrator to know and
predict what software is running on the network segment.)

While our other proposals don't have these same properties, they also
imply much larger numbers of IP addresses becoming available, which
might change the cost-benefit comparison.

---

From: John Gilmore <[email-masked]>
Date: Tue, 03 Aug 2021 02:43:10 -0700

> Do I understand correctly, that you are proposing that all hosts,
> routers, firewalls, middle boxes, etc. on the Internet, be updated in
> order to get a single extra IP address per subnet?  ...

You may be right (see below).  One confounding factor is that the
lowest-address draft is the first of a set of upcoming drafts that
propose small, easy improvements in IPv4.  This set of changes, in
aggregate, will be worth implementing, because they create hundreds of
millions of newly usable addresses, worth billions of dollars at current
prices.  If the cost-vs-benefit is worth doing for ANY ONE of these
changes, or for any subset of these changes, then the deployment effort
may as well include the other, smaller, improvements, which will come
for very close to free.

I agree that the "lowest address" protocol change is only likely to
produce tens of millions of newly usable addresses, creating only
perhaps $250M to $500M of benefits at current prices.  That alone might
not be worth doing, particularly since predicting FUTURE prices of IPv4
addresses is risky.  But let's look at the costs.  The end-user cost of
updating can be zero because it can be deferred until equipment is
naturally upgraded for other reasons.  Nobody would buy a new router to
get this feature, but eventually almost everybody buys a new router.  Or
installs the latest OS release.  The change is completely compatible
with existing networks, since the lowest addresses are currently not
known to be used for anything and have been declared obsolete in IETF
standards for decades.  This makes the deployment risk very low.

So I expect the main cost would be for each vendor to make and test
small patches to their existing IPv4 implementations, and then include
those changes as part of their next release or product.  Our team
successfully patched both Linux and BSD over a few weeks, and
interoperated them successfully.  Based on that experience, I estimate
implementation costs to major IPv4 vendors to be under $10M in total.
By 5 to 10 years after adoption, the improvement would be everywhere,
and will probably have paid off about 25-to-1.  I agree that the people
incurring the costs of this proposal are not the people who end up
getting the benefit of the IP addresses; the benefit goes to the
vendors' customers, benefiting the vendors indirectly.  So the
cost-benefit tradeoff might be more societal (or network-wide) than
individual or corporate.  My understanding is that IETF's role is as a
steward of network-wide value, which is why I thought this might
interest IETF.

	John Gilmore
	IPv4 Unicast Extensions

---

From: Derek Fawcus <[email-masked]>
Date: Tue, 3 Aug 2021 12:24:15 +0100

On Tue, Aug 03, 2021 at 02:43:10AM -0700, John Gilmore wrote:
> Our team successfully patched both Linux and BSD over a few weeks, and
> interoperated them successfully.

Linux doesn't need a patch, just a configuration change
(use the 'ip' command to delete the 0-host address/prefix).

I know because a number of years ago I did this with my home set up
where my ISP proveded a /29, and I used all 8 addresses without NAT.

As I recall, I did something like using a RFC 1918 prefix as the
attached net to an interface, and installed a static /28 route for
the public prefix to the same interface on the router (so it would ARP).

Then it was simply a question of how to get the various hosts to
initiate outgoing connections using that public address.  Linux was
easy, as one can specify the source address for the default route.

One one box I used a tunnel to the edge router to achieve a similar effect.

I imagine there are a few ways to achieve these w/o forcing use of NAT.

So operationally one can reclaim both the all-0 and all-1 host
addresses _now_, if one knows what one is doing.  So while I don't
object to the change, I don't view it as freeing up addresses which
can't already be used.

DF

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 Aug 2021 14:55:32 +0200

On 2021-08-03, at 11:43, John Gilmore <[email-masked]> wrote:
> create hundreds of
> prices.

How do you make sure those billions arrive at the millions who get fed with the externality of this change?  Changing routers, even if it is only a config change, costs money and creates opportunity costs (lost time), a cost that is better invested in accelerating the migration to IPv6.

Grüße, Carsten

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Aug 2021 06:24:30 -0700

What's the problem you're trying to solve here, John, that's not already
solved by just using IPv6? I'm not saying there isn't one, but if there is,
I'm not seeing it.

The ability to free up IPv4 addresses to monetize doesn't seem like it
would pay back the people who would be doing the work to free them up, so
it's hard to see where the incentive would be for this work to be deployed.
Even if there were some small benefit per individual person, it probably
wouldn't be enough to justify the trouble of individually making this
change. Sure, if a single entity could reap the rewards of this work, that
might be worth it to that entity, but that entity couldn't be the one that
would pay the cost of making this change.

On Tue, Aug 03, 2021 at 4:43 AM, John Gilmore <[email-masked]> wrote:

> Do I understand correctly, that you are proposing that all hosts, routers,
> firewalls, middle boxes, etc. on the Internet, be updated in order to get a
> single extra IP address per subnet? ... To me this fails the cost benefit
> analysis.
>
> lowest-address draft is the first of a set of upcoming drafts that propose
> small, easy improvements in IPv4. This set of changes, in aggregate, will
> be worth implementing, because they create hundreds of millions of newly
> usable addresses, worth billions of dollars at current prices. If the
> cost-vs-benefit is worth doing for ANY ONE of these changes, or for any
> subset of these changes, then the deployment effort may as well include the
> other, smaller, improvements, which will come for very close to free.
>
> produce tens of millions of newly usable addresses, creating only perhaps
> $250M to $500M of benefits at current prices. That alone might not be worth
> doing, particularly since predicting FUTURE prices of IPv4 addresses is
> risky. But let's look at the costs. The end-user cost of updating can be
> zero because it can be deferred until equipment is naturally upgraded for
> other reasons. Nobody would buy a new router to get this feature, but
> eventually almost everybody buys a new router. Or installs the latest OS
> release. The change is completely compatible with existing networks, since
> the lowest addresses are currently not known to be used for anything and
> have been declared obsolete in IETF standards for decades. This makes the
> deployment risk very low.
>
> So I expect the main cost would be for each vendor to make and test small
> patches to their existing IPv4 implementations, and then include those
> changes as part of their next release or product. Our team successfully
> patched both Linux and BSD over a few weeks, and interoperated them
> successfully. Based on that experience, I estimate implementation costs to
> major IPv4 vendors to be under $10M in total. By 5 to 10 years after
> adoption, the improvement would be everywhere, and will probably have paid
> off about 25-to-1. I agree that the people incurring the costs of this
> proposal are not the people who end up getting the benefit of the IP
> addresses; the benefit goes to the vendors' customers, benefiting the
> vendors indirectly. So the cost-benefit tradeoff might be more societal (or
> network-wide) than individual or corporate. My understanding is that IETF's
> role is as a steward of network-wide value, which is why I thought this
> might interest IETF.
>
> John Gilmore
> IPv4 Unicast Extensions
>

---

From: Bob Hinden <[email-masked]>
Date: Tue, 3 Aug 2021 10:12:34 -0700

Seth,

> On Aug 2, 2021, at 5:14 PM, Seth David Schoen <[email-masked]> wrote:
> 
> Bob Hinden writes:
> 
>> Seth,
>> 

We must live in different worlds.  I have many devices on my home network, but I have no ability to patch any of them myself, software updates come from the vendors of these devices.  I suspect this is the same for the vast majority of Internet users.

I also have no way to know when they would be updated to support your proposal to start using the extra address.

Lastly, most users with IPv4, use NAT.  There is no address scarcity for them.  For example, I use Net 10 on my home network.   Adding one additional address isn’t very interesting.

Bob

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 3 Aug 2021 15:11:21 -0400

Dear colleagues,

I work at the Internet Society but am not speaking for them.

On Tue, Aug 03, 2021 at 02:43:10AM -0700, John Gilmore wrote:

>propose small, easy improvements in IPv4.

I think I recalled an (int area?) meeting something like a decade ago where there was a pretty strong sense of consensus that the right thing for the IETF to do is to stop fiddling with IPv4 and to make the path to v6 easier.  How would this set of work contribute to that direction?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Tue, 3 Aug 2021 21:47:44 +0200

Hi Andrew,

On 03.08.21 21:11, Andrew Sullivan wrote:
> I think I recalled an (int area?) meeting something like a decade ago 
> where there was a pretty strong sense of consensus that the right 
> thing for the IETF to do is to stop fiddling with IPv4 and to make the 
> path to v6 easier. 

Dave Meyer, Vince Fuller, and I were the co-authors of that work that 
was presented here at the int-area.  We dropped the idea because there 
were some serious concerns about undefined behaviors in endpoints that 
would not expect to see packets with those addresses.  If memory serves, 
Dave Thaler raised those issues, and referred to CPEs and firewalls in 
particular.

The part of the logic that ran *for* using this address space was that 
it would show appropriate stewardship, by being as efficient as 
possible.  Since then, IPv6 adoption is way up, and so are IPv4 prices; 
which is why this proposal is so interesting now.  That doesn't 
invalidate your logic, but it's not why we dropped the proposal.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Aug 2021 08:35:54 +1200

> My understanding is that IETF's role is as a

Not quite. The mission is "to make the Internet work better" and
affecting the sales value of 32 bit numbers is not really the same
thing, especially since 128 bit numbers are already much cheaper. 

Regards
   Brian Carpenter

---

From: John Gilmore <[email-masked]>
Date: Tue, 10 Aug 2021 15:29:41 -0700

Brian E Carpenter <[email-masked]> wrote:
>             The mission is "to make the Internet work better" and

If 128-bit numbers were a fungible replacement for 32-bit numbers,
telling people to just get cheap 128-bit ones would work; but they
aren't.  As you point out in their prices, the public values the 32-bit
ones much more than they value the 128-bit ones.

IPv6 doesn't need any of our proposed improvements, since many of them
are historical artifacts of IPv4's evolution that were never carried
over to IPv6.  For example, IPv6 has a single loopback address, not 16
million of them; and no broadcast addresses, not two per subnet.  Making
improvements to IPv4 that IPv6 doesn't need is not a crime.

We have no wish to stop or slow the deployment of IPv6.  IPv4 and IPv6
are not in opposition; they are complementary.  Both exist on the
Internet today, have coexisted for decades, and will likely continue to
coexist for decades.  Much of today's demand for IPv4 space is driven by
organizations that have already adopted IPv6 intensively and which
systematically offer dual-stack services.  They are friends, not foes,
of IPv6 deployment.  As Mueller and Kuerbis said in 2019 in an
ICANN-funded report, "Even if they have deployed IPv6, growing networks
must continue to acquire scarce, increasingly expensive IPv4 addresses
to interconnect with the rest of the Internet. Deploying IPv6 does not
immediately end the problem of IPv4 address exhaustion."  See:

  https://www.internetgovernance.org/2019/02/20/report-on-ipv6-get-ready-for-a-mixed-internet-world/

> thing for the IETF to do is to stop fiddling with IPv4 and to make the

As we heard from Eliot Lear, this wasn't how the 2008 decision was made
regarding 240/4 (the Class E address block).  But if the consensus at
some point did go there, it would have been a false choice, because
"[keep] fiddling with IPv4" and "make the path to v6 easier" aren't
strict alternatives or substitutes at all.  If treated as two separate
suggestions ("stop fiddling with IPv4" and "make the path to v6
easier"), each may have merit; but the connection between them is not
simple or obvious.

The theory behind "stop fiddling with IPv4 and make the path to v6
easier" seems to be that if IETF stopped making any improvements to
IPv4, then users would respond by spending all their efforts on IPv6.
In actuality, users have thousands of other things that they can spend
their efforts on besides either IPv4 and IPv6.  If they don't spend time
and money following IETF's fiddling with IPv4 (because IETF stopped
fiddling with IPv4), they might instead add features to their product.
They might pay higher dividends to their stockholders.  They might write
better manuals.  They might try to corner a market.  They might acquire
another company.  They might do academic research.  They might design
and deploy NAT in their network.  They might go home and watch TV.  Oh
yes, and they might work on IPv6!  But merely saying "No more
improvements will happen to IPv4" will not force them to do any
particular one of those things.  The two choices presented do not
exhaust the space of possibilities, and this is a classic way to fall
into a fallacy:

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

Even if IETF stopped fiddling with IPv4, that didn't stop users from
fiddling with IPv4 themselves.  Many IPv4 implementations have evolved
their "running code" despite the absence of IETF's "rough consensus".
Some of our proposals attempt to form a consensus informed by these
existing implementions.  We think that's better than each implementation
going off in different directions because they haven't found a forum in
which discussions of IPv4 evolution will be taken seriously.

IETF's (and intarea's) area of responsibility is the stewardship of the
IP protocol suite, certainly including the original one, IPv4.  If IETF
or intarea had really decided to stop all future work on the standards
that carry the majority of the world's Internet traffic, that would have
been a drastic shift for the organization.  For that to have happened
without even publishing an RFC documenting the decision would have been
highly unusual.  Is there such an RFC?

Whether IETF should actually "fiddle with IPv4" is a decision that
should be made on the merits of each proposed fiddle, as with every
other protocol proposal at IETF.  To the extent that IETF has or had a
policy of "stop fiddling with IPv4", a decade+ of this did not cause
IPv6 to supplant IPv4.  So if any such policy existed, it should be
re-examined based on its results in the real world.

Finally, if intarea or IETF knows a way to "make the path to v6 easier",
we welcome such work and recommend approving it.  And yet, the community
has looked in vain so far for an IPv6 silver bullet that would obviate
the ongoing demand for IPv4 address space.  That's why we worked on
easy ways to increase the supply rather than on reducing the demand.

	John Gilmore & Seth David Schoen

---

From: Seth David Schoen <[email-masked]>
Date: Fri, 13 Aug 2021 11:49:03 -0700

Carsten Bormann <[email-masked]> wrote:

> Changing routers, even if it is only a config change, costs money and
> creates opportunity costs (lost time)

We don't propose that everyone change out or reconfigure all their routers.

We propose that new routers be shipped with these improvements, so that
as equipment in the field is gradually installed or replaced, the
improvements gradually become available.

The roll-out would actually be significantly faster than the replacement
schedule for equipment.  Some of our proposals are already implemented
today in major platforms.  Many kinds of equipment get updates to their
operating systems and firmware.  If the truly tiny changes that we
propose are approved by IETF, the remaining vendors would put them into
their subsequent OS releases.  Then anyone who installs a new Linux or
BSD release, or a new OpenWRT or Juniper firmware release in a router,
or a new Windows or macOS release, will receive the improvements.  This
will commonly happen long before they replace their physical equipment.

As precedent, IETF protocol evolution has relied on software updates in
multiple situations.  The rollout of CIDR in the 1990s and early 2000's
is an obvious example.  RFC 8996 (Deprecating TLS 1.0 and TLS 1.1), a
Best Current Practice, is a recent 2021 example.  There, everyone was
given about 13 years' notice of an impending protocol change, then the
new RFC said: "TLS 1.0 MUST NOT be used." and "TLS 1.1 MUST NOT be
used."  The small number of 13-year-old devices that couldn't be
updated, are no longer interoperable with the devices updated to the new
RFC.  IETF determined that the change was worth it, and documented why
in the RFC.  This shows the importance of software updates, the fact
that they do happen, and the fact that the Internet community can
sometimes choose to rely on them.  (The IPv4 Unicast Extensions
situation is much less intrusive; software updates would *create* new
interoperability where none previously existed.)

Our improvements will just work in local networks, without needing any
more reconfiguration than is normally needed for an OS upgrade.  Most of
our proposed improvements take something that currently produces an
error or is unusable, and make it usable in the future.  This is the
least problematic kind of upgrade.  (One of our proposals has been
implemented in Linux, macOS and Solaris for more than a decade -- and
nobody noticed.)  If intarea members can identify any part of our
suggestions that WOULD cause other things to break, we would be happy to
hear about it, and to revise our proposals accordingly.

It is true that address-unreserving changes would mean that some hosts
and routers differ in their ability to use newly-available addresses.
That is a consideration when proposing to allocate previously reserved
addresses for use on the Internet, which we are not proposing at this
time.  At any point, the Internet community can also assess how pervasive
the new capabilities are, empirically, by conducting experiments with
Internet measurement platforms such as RIPE Atlas.  Concurrently,
experimenters or recipients will be able to "debogonize" the various
address ranges they measure, by interacting with network operators,
Martian filter distributors, and vendors.  This has been repeatedly done
before.  See CloudFlare's report
on checking and repairing the reachability of 1.1.1.1:
  https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/
Or Geoff Huston's testing of multiple address blocks using Google ads:
  https://labs.ripe.net/author/gih/detecting-ip-address-filters/
Or RIPE's efforts on 1/8, 2a10::12, and 128.0/16:
  https://labs.ripe.net/author/franz/pollution-in-18/ (1/8)
  https://labs.ripe.net/author/emileaben/the-debogonisation-of-2a1012/
  https://labs.ripe.net/author/emileaben/the-curious-case-of-128016/

> a cost that is better invested in accelerating the migration to IPv6.

IETF could deny the community a forum in which to form a consensus
about how IPv4 can usefully evolve.  But it can't force everyone to
spend an equivalent amount of energy on doing one particular other
thing, like "accelerating the migration to IPv6".  As we discussed in
our message responding to Brian Carpenter and Andrew Sullivan, that is a
false dilemma.  Neglecting or abandoning IPv4 isn't an IPv6 transition
strategy.

	John Gilmore & Seth Schoen

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Aug 2021 09:26:48 +1200

> Carsten Bormann <[email-masked]> wrote:
...
> about how IPv4 can usefully evolve.  

"The IAB expects that the IETF will stop requiring IPv4 compatibility in new or extended protocols. Future IETF protocol work will then optimize for and depend on IPv6." [https://www.iab.org/2016/11/07/iab-statement-on-ipv6/] So any IETF effort
on "evolving" IPv4 is really not on the radar. Patching it up operationally is
in scope, of course. That's what you seem to be proposing.

> But it can't force everyone to
> false dilemma. 

Not really; the total effort available to get documents through the IETF
process is a finite resource. (Not the effort to create -00 drafts, which
appears to be an infinite resource, but the process that follows, which is
already far too slow because the pipeline is full. Actual the Suez Canal
is a better analogy, because each step in the process works like a basin
and a lock, with finite throughput.)

> Neglecting or abandoning IPv4 isn't an IPv6 transition
> strategy.

As I've been saying for 15+ years, we don't have a transistion strategy,
we have a co-existence strategy. That's indeed orthogonal to a marginal
extra supply of IPv4 addresses.

     Brian