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

[Seth David Schoen <[e-mail]>]

Carsten Bormann <[e-mail]> 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