Carsten Bormann <[email protected]> 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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
