Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
Le 21/11/2021 à 20:56, Keith Moore a écrit : I don't hate this draft. But making tweaks to IPv4 at this stage seems like making improvements to the altimeter in a Dusenberg. The other day I noticed dedibox allocates a /128 IPv6 'subnet' when enabling SLAAC on a virtual server. That is supposedly a technique similar to this I-D 'lowest-address' but in IPv6. As such, it might make sense to ask dedibox scaleway what is their algorithm to form that /128 'subnet' when enabling SLAAC, and maybe document that instead. https://www.scaleway.com/en/docs/dedibox-network/ipv6/quickstart/ How to enable IPv6 SLAAC Activation of IPv6 SLAAC assigns one /128 IPv6 subnet to your server (one usable IPv6 address). This IP will be statically linked to your server and can not be attributed to another server. Note: This feature is not yet available for all servers. Only the servers that are compatible will show the related button. IMO IPv4 should be declared at EOL in 2025, and further work on IPv4 should require significant justification. I agree. The questions for any proposed enhancements to IPv4 at this stage should be like: (a) will this change to IPv4 improve or facilitate adoption of IPv6 or ease the transition away from IPv4 in favor of IPv6? (b) is this change to IPv4 helpful to permit continued interoperability with legacy IPv4-only systems that are still needed? It's a good list. Alex I'm not saying these are absolutely the only reasons to do additional work on IPv4 at this stage, but the list of valid reasons is probably small. Perhaps more importantly, while protocol changes that require software changes can sometimes be widely deployed rather quickly (thanks to automatic or semi-automatic over-the-wire software updates), protocol changes that require changes to manual configuration of hosts, routers, or middleboxes are unlikely to be deployed nearly as quickly. In this case it seems like use of .0 at this late date creates additional potential for operational networks to become more brittle and to result in strange inconsistencies that are difficult for ordinary users (and some other operators of small LAN segments) to track down. *** But I am somewhat sympathetic to the idea that tiny subnets need all of the addresses that they can get. It shouldn't be necessary to get a /29 prefix just to be able to put three hosts on a LAN segment. My house has a /28 and sometimes that's not been enough (though thankfully my carrier is finally supporting IPv6, so I care much less now). It strikes me that it is the tiny subnets that not only need this relief most, but also are the ones that are least likely to be disrupted by meddleboxes, intrusion detectors, security monitors, etc. trying to be too clever. But plenty of tiny networks have such meddleboxes. Or maybe .0 should be the preferred address for the on prem router's configuration interface, freeing up other addresses on the subnet for ordinary hosts. That way, most problems will show up immediately, and the ISP will be the ones who have to deal with it when it breaks. (How many consumer-facing ISPs would want to make that change to their default router configurations? I'm guessing not many, which might be a good indication of something.) Overall, I think there's some potential for publication of this document to do more harm than good, even if it only recommends use of .0 for hosts on network segments that have, say, /26 or longer prefixes. Is it really worth it? (Or as one person suggested, is this a way to make IPv4 even more broken so that people will have to switch to IPv6?) Keith On 11/16/21 2:09 AM, Loganaden Velvindron wrote: I would support seeing this work move forward. There are still many countries in the developing world who will not be able to update to IPv6 any time soon due to legacy equipment and will be using IPv4 for a long time. (Disclaimer: I submitted a few patches to the IPv4 extension project). ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
I don't hate this draft. But making tweaks to IPv4 at this stage seems like making improvements to the altimeter in a Dusenberg. IMO IPv4 should be declared at EOL in 2025, and further work on IPv4 should require significant justification. The questions for any proposed enhancements to IPv4 at this stage should be like: (a) will this change to IPv4 improve or facilitate adoption of IPv6 or ease the transition away from IPv4 in favor of IPv6? (b) is this change to IPv4 helpful to permit continued interoperability with legacy IPv4-only systems that are still needed? I'm not saying these are absolutely the only reasons to do additional work on IPv4 at this stage, but the list of valid reasons is probably small. Perhaps more importantly, while protocol changes that require software changes can sometimes be widely deployed rather quickly (thanks to automatic or semi-automatic over-the-wire software updates), protocol changes that require changes to manual configuration of hosts, routers, or middleboxes are unlikely to be deployed nearly as quickly. In this case it seems like use of .0 at this late date creates additional potential for operational networks to become more brittle and to result in strange inconsistencies that are difficult for ordinary users (and some other operators of small LAN segments) to track down. *** But I am somewhat sympathetic to the idea that tiny subnets need all of the addresses that they can get. It shouldn't be necessary to get a /29 prefix just to be able to put three hosts on a LAN segment. My house has a /28 and sometimes that's not been enough (though thankfully my carrier is finally supporting IPv6, so I care much less now). It strikes me that it is the tiny subnets that not only need this relief most, but also are the ones that are least likely to be disrupted by meddleboxes, intrusion detectors, security monitors, etc. trying to be too clever. But plenty of tiny networks have such meddleboxes. Or maybe .0 should be the preferred address for the on prem router's configuration interface, freeing up other addresses on the subnet for ordinary hosts. That way, most problems will show up immediately, and the ISP will be the ones who have to deal with it when it breaks. (How many consumer-facing ISPs would want to make that change to their default router configurations? I'm guessing not many, which might be a good indication of something.) Overall, I think there's some potential for publication of this document to do more harm than good, even if it only recommends use of .0 for hosts on network segments that have, say, /26 or longer prefixes. Is it really worth it? (Or as one person suggested, is this a way to make IPv4 even more broken so that people will have to switch to IPv6?) Keith On 11/16/21 2:09 AM, Loganaden Velvindron wrote: I would support seeing this work move forward. There are still many countries in the developing world who will not be able to update to IPv6 any time soon due to legacy equipment and will be using IPv4 for a long time. (Disclaimer: I submitted a few patches to the IPv4 extension project). ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
Greg, With my AD hat on, you are correct: intarea WG is currently the only suitable WG for discussion as its charter includes: The Internet Area Working Group (INTAREA WG) acts primarily as a forum for discussing far-ranging topics that affect the entire area. Such topics include, for instance, address space issues, basic IP layer functionality, and architectural questions. But please also note the 2nd condition for new work in https://datatracker.ietf.org/group/intarea/about/ Up to the authors if they want to try to get this work adopted but, honestly, I have hard time to see this being adopted. Regards -éric On 18/11/2021, 05:50, "Int-area on behalf of Greg Skinner" wrote: On the general subject of the recent IPv4 Unicast Extensions Project drafts, is the intarea WG the intended WG for adopting them? I ask because discussion of issues raised in these drafts took place in the sunset4 WG before it concluded. Regards, Greg > On Nov 15, 2021, at 11:09 PM, Loganaden Velvindron wrote: > > I would support seeing this work move forward. There are still many > countries in the developing world who will not be able to update to > IPv6 any time soon due to legacy equipment and will be using IPv4 for > a long time. > > (Disclaimer: I submitted a few patches to the IPv4 extension project). > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
On the general subject of the recent IPv4 Unicast Extensions Project drafts, is the intarea WG the intended WG for adopting them? I ask because discussion of issues raised in these drafts took place in the sunset4 WG before it concluded. Regards, Greg > On Nov 15, 2021, at 11:09 PM, Loganaden Velvindron > wrote: > > I would support seeing this work move forward. There are still many > countries in the developing world who will not be able to update to > IPv6 any time soon due to legacy equipment and will be using IPv4 for > a long time. > > (Disclaimer: I submitted a few patches to the IPv4 extension project). > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
I would support seeing this work move forward. There are still many countries in the developing world who will not be able to update to IPv6 any time soon due to legacy equipment and will be using IPv4 for a long time. (Disclaimer: I submitted a few patches to the IPv4 extension project). ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
On 14-Aug-21 06:49, Seth David Schoen wrote: > Carsten Bormann wrote: ... >> 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. "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 > 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. 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
Carsten Bormann 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 Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
Brian E Carpenter wrote:
> 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.
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/
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.
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
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
> My understanding is that IETF's role is as a > steward of network-wide value, which is why I thought this might > interest IETF. 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 On 03-Aug-21 21:43, John Gilmore 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. > > 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 > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
Hi Andrew, On 03.08.21 21:11, Andrew Sullivan wrote: On Tue, Aug 03, 2021 at 02:43:10AM -0700, John Gilmore wrote: lowest-address draft is the first of a set of upcoming drafts that 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. 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 OpenPGP_signature Description: OpenPGP digital signature ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
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: lowest-address draft is the first of a set of upcoming drafts that 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 a...@anvilwalrusden.com ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
Seth, > On Aug 2, 2021, at 5:14 PM, Seth David Schoen wrote: > > Bob Hinden writes: > >> 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. > > 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.) 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 > > 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. signature.asc Description: Message signed with OpenPGP ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
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 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. > > 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 > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
On 2021-08-03, at 11:43, John Gilmore wrote: > > create hundreds of > millions of newly usable addresses, worth billions of dollars at current > 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
> 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. 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
Bob Hinden writes: > 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. 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. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
Hi Derek, thanks for your comments.
Derek Fawcus writes:
> 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.
Yes, that's the common behavior of existing devices.
> 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.
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.
> 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.
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.
> 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.
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
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
> 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. 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: > 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. > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > . > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
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 wrote: > > 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. > > ___ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area signature.asc Description: Message signed with OpenPGP ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
On Sun, Aug 01, 2021 at 10:59:16PM -0700, Seth David Schoen wrote: > 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/ 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
[Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address
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. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
