Re: maximum ipv4 bgp prefix length of /24 ?
On 6 Oct 2023, at 6:13 am, Owen DeLong <owen@delong.com> wrote:
Ratio of FIB to RIB is only part of the equation.
IPv6 is NOT under the disaggregation pressure that IPv4 is under because there is no pressure (other than perhaps scarcity mentality from those that don’t properly understand IPv6) to dense-pack IPv6 assignments or undersize IPv6 allocations.
Look at the difference in prefixes per ASN across the two tables and that tells a much grimmer story for IPv4 in terms of RIB growth vs. IPv6.
hmm - IPv4 is at [1], IPv6 is at [2] Now I’m trying to understand what your grimmer story for IPv4 might be here Owen. Since 2005 the number of IPv4 FIB entries per origin AS has increased fropm 8 to 12 in the past 20 years - or a 50% increase. Over ther same period the number of IPv6 prefix advertisements per origin AS has increased from 1.5 to 6, or a fourfold increase. If anything, the IPv6 story appears to me to be a far greater cause for concern, but you may have a different interpretation of this data. Geoff [1] https://bgp.potaroo.net/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2%2e0%2fbgp%2dentries%2das%2etxt&descr=Average%20entries%20per%20origin%20AS&ylabel=Average%20entries%20per%20origin%20AS&with=step@%82%966%88U [2] https://bgp.potaroo.net/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fv6%2fas2%2e0%2fbgp%2dentries%2das%2etxt&descr=Average%20entries%20per%20origin%20AS&ylabel=Average%20entries%20per%20origin%20AS&with=step
On Oct 5, 2023, at 15:51, Geoff Huston <gih@apnic.net> wrote:
On 6 Oct 2023, at 6:13 am, Owen DeLong <owen@delong.com> wrote:
Ratio of FIB to RIB is only part of the equation.
IPv6 is NOT under the disaggregation pressure that IPv4 is under because there is no pressure (other than perhaps scarcity mentality from those that don’t properly understand IPv6) to dense-pack IPv6 assignments or undersize IPv6 allocations.
Look at the difference in prefixes per ASN across the two tables and that tells a much grimmer story for IPv4 in terms of RIB growth vs. IPv6.
hmm - IPv4 is at [1], IPv6 is at [2]
Now I’m trying to understand what your grimmer story for IPv4 might be here Owen. Since 2005 the number of IPv4 FIB entries per origin AS has increased fropm 8 to 12 in the past 20 years - or a 50% increase. Over ther same period the number of IPv6 prefix advertisements per origin AS has increased from 1.5 to 6, or a fourfold increase. If anything, the IPv6 story appears to me to be a far greater cause for concern, but you may have a different interpretation of this data.
I admit I’m surprised that IPv6 has gotten to an average of 6, but it would be interesting to know why that is. Honestly, I expected it would end up closer to 4. I wonder how much of that is PI stub networks being originated by upstream transit networks. I also wonder to what extent the “average” might be misleading here. Is it a few ASs with large numbers of prefixes and mostly 1-2 prefixes per AS or is the average representative? I know that in IPv4, for example, there are several ASs originating MANY prefixes and lots of smaller ASs originating <4 prefixes. My grimmer picture for IPv4 is about the intrinsic pressure to deaggregate that comes from the ever finer splitting of blocks in the transfer market and the ever finer grained dense packing of hosts into prefixes that is forced from address scarcity. Those pressures don’t (or at least shouldn’t) exist for IPv6. YMMV Owen
On Mon, Oct 9, 2023 at 11:38 AM Delong.com via NANOG <nanog@nanog.org> wrote:
[...]
My grimmer picture for IPv4 is about the intrinsic pressure to deaggregate that comes from the ever finer splitting of blocks in the transfer market and the ever finer grained dense packing of hosts into prefixes that is forced from address scarcity. Those pressures don’t (or at least shouldn’t) exist for IPv6.
Well, it's also time to recognize and talk about the elephant in the room. We know we can have an IPv4-only internet, we've been doing it for decades. Our experiments thus far at an IPv6-only Internet have largely been (well, honestly, *compeletely*) unsuccessful. In order to exist on the Internet today, you *must* have some IPv4 presence. The reverse is not true; you can exist on the Internet with no IPv6 resources. As a result, as you noted, the pressure to split IPv4 ever-smaller so that everyone gets a tiny piece of that essential pie is nearly infinitely greater than it is for IPv6. As a community, we have failed, because we never acknowledged and addressed the need for backward compatibility between IPv6 and IPv4, and instead counted on magic handwaving about tipping points and transition dates where suddenly there would be "enough" IPv6-connected resources that new networks wouldn't *need* IPv4 address space any more. In doing so, we have sown the seeds of our own future pain and suffering. By allowing IPv6 to be defined and established as an incompatible network protocol to IPv4, we ensured that IPv4's future was assured. *Every* transition mechanism we have for networks today relies on having *some* amount of IPv4 address space for the translation gateway devices, which will continue to drive an ever-increasing demand for smaller and smaller chunks of IPv4 address space to be parceled out to every new network that wants to join the Internet. The only alternative is that web-scale companies like Amazon and Google stand up swaths of IPv6-to-IPv4 translation gateway boxes, and provide 6-to-4 bidirectional translation services, with some clever marketing person figuring out how to make money reliably from the service. At that point, new entrants could conceivably get on board the Internet with only IPv6 resources, with no need to scrabble for a chunk of ever-decreasing IPv4 space to perform the necessary gateway translation for their customers. Unfortunately, because it's not just a mapping problem but an actual packet-level incompatibility, the companies providing the magical bidirectional translation service are going to be in the pathway for the entire bitstream, making it a bandwidth-intensive product to deploy. :( On the plus side, they'd have the best view into everyone's traffic one could ever hope for. Forget just seeing DNS queries--you'd have visibility into *everything* the users were doing, no matter how tiny and mundane it might be. Imagine the data mining potential!! If I were younger, stupider, and much, much, MUCH richer, I might start a company to do just that... Matt
As a community, we have failed, because we never acknowledged and addressed the need for backward compatibility between IPv6 and IPv4, and instead counted on magic handwaving about tipping points and transition dates where suddenly there would be "enough" IPv6-connected resources that new networks wouldn't *need* IPv4 address space any more.
I’m not sure that we never acknowledged it, but we did fail to address it, largely because I think we basically determined that it’s “too hard”. There’s really no way for a machine with a >32 bit address to feasibly/reliably talk to a machine that only understands 32-bit addresses short of involving some sort of intermediate proxy host doing some form of address translation. We’ve actually got LOTS of those solutions deployed with varying levels of success/failure/idiosyncrasies. I’ve spent a fair amount of time thinking about alternatives and admit that I, myself am stumped as to how one would go about this.
In doing so, we have sown the seeds of our own future pain and suffering.
Do you have a proposal for how this problem could have been/could be solved?
By allowing IPv6 to be defined and established as an incompatible network protocol to IPv4, we ensured that IPv4's future was assured.
I’d argue that we did much more to achieve that by deploying NAT. Absent NAT, we wouldn’t be able to pretend that IPv4 still works.
*Every* transition mechanism we have for networks today relies on having *some* amount of IPv4 address space for the translation gateway devices, which will continue to drive an ever-increasing demand for smaller and smaller chunks of IPv4 address space to be parceled out to every new network that wants to join the Internet.
Well, at least theoretically, that can end when a sufficient critical mass of the internet is reachable via native IPv6 that we no longer care about reaching the outlying corners that aren’t. Let me ask you a slightly different question… Given a clean slate, what would you do differently so that a host with no possible capability to put more than 32-bits into the source or destination address field of a packet and no ability to look for address pieces elsewhere in the packet (i.e. a current IPv4 host without software modification) could talk to a host that doesn’t have a 32-bit address? It turns out to be _REALLY_ hard to put more than 32-bits into a 32-bit field without loss. Short of doing that, any translation mechanism is going to require some IPv4 address for the translation host (though it doesn’t necessarily have to be globally unique).
The only alternative is that web-scale companies like Amazon and Google stand up swaths of IPv6-to-IPv4 translation gateway boxes, and provide 6-to-4 bidirectional translation services, with some clever marketing person figuring out how to make money reliably from the service.
I’m not convinced this is the ONLY alternative, but it’s certainly one of the (sadly) less impractical ones.
At that point, new entrants could conceivably get on board the Internet with only IPv6 resources, with no need to scrabble for a chunk of ever-decreasing IPv4 space to perform the necessary gateway translation for their customers.
IPv4 is still relatively cheap at $50/address. The bigger problem, however, is that the people who need to migrate aren’t the ones paying the cost of failing to migrate. We’ve got an economy where the interests of the community are utterly divorced from the interests of those with no motivation to migrate to IPv6 and really, no way to provide that motivation through externalization of the cost. I don’t know of a practical way to do it, but if there was some economic cost that could be imposed on entities failing to implement IPv6 in their products and services, I would be willing to bet that IPv6 uptake among the remaining IPv4-only entities would be greatly accelerated. Especially if that cost somehow escalated each year they failed to act.
Unfortunately, because it's not just a mapping problem but an actual packet-level incompatibility, the companies providing the magical bidirectional translation service are going to be in the pathway for the entire bitstream, making it a bandwidth-intensive product to deploy. :(
Frankly, this almost certainly ends up being something that needs to be deployed close to the edge by two classes of entities: 1. Eyeball ISPs that have customers that can’t go IPv6-only. 2. Content providers that don’t provide native IPv6. Again, this comes back to the economic issue I’ve described above. Plenty of incentive for 1 and really, that’s no worse than CGNAT and is already being done by some, but for 2, so far, at least, that group has been able to externalize the costs onto everyone else by forcing them to figure out how to continue to preserve access to their IPv4-only content instead of having to adopt IPv6. Since it costs them nothing to ignore the plight of the eyeball providers (and sometimes may even provide an advantage), the economic incentives run contrary to the common good and we are where we are.
On the plus side, they'd have the best view into everyone's traffic one could ever hope for. Forget just seeing DNS queries--you'd have visibility into *everything* the users were doing, no matter how tiny and mundane it might be. Imagine the data mining potential!!
Well… Metadata at least… Unless everyone gets stupid enough to do stuff in clear text, all you’ll really know is flow sizes, rates, source/destination IP pairs, etc. You won’t actually get to peek at the content except for the people stupid enough to do anything in today’s world without end-to-end encryption.
If I were younger, stupider, and much, much, MUCH richer, I might start a company to do just that...
It’s certainly monetizable data, but trying to do that if you’re not somehow able to offer it as an appliance that you deploy into groups 1 and 2 above as a service (and somehow incentivize group 2 to accept your appliances), success remains “unlikely”. Owen
On 11 Oct 2023, at 09:43, Delong.com via NANOG <nanog@nanog.org> wrote:
As a community, we have failed, because we never acknowledged and addressed the need for backward compatibility between IPv6 and IPv4, and instead counted on magic handwaving about tipping points and transition dates where suddenly there would be "enough" IPv6-connected resources that new networks wouldn't *need* IPv4 address space any more.
I’m not sure that we never acknowledged it, but we did fail to address it, largely because I think we basically determined that it’s “too hard”.
It’s not actually that hard to do on a small scale, i.e. inside a home CPE with a DNS server and a NAT64 implementation that supports semi static mappings. It does require IPv4 sites have IPv6 connectivity. You stand up a DNS46 which requests an unused IPv4 address from a prefix block, say 10/8, when there is an IPv6 address without an IPv4 address from the NAT64 with the IPv6 address it needs to be mapped to with an initial NAT64 lifetime value. The DNS46 would forget the mapping after half that initial lifetime. The DNS46 would return A records limited half the lifetime or less so they timeout before the NAT64 mapping expires. The hard part is scaling up to a large client base because not every DNS query results in IP traffic and you need a prefix block big enough to support the add rate of the client base. Doing this at ISP scale would be interesting to say the least. This is not theoretical. It has been implemented in the past though some to the details might differ. Companies that have gone IPv6-only internally do this with fully static IPv4 to IPv6 mappings and skip the DNS46 step. So if you have a legacy device that can’t talk IPv6 there is a solution space that allows it to talk to the IPv6 internet. You need to install it however. Adding DNS46 to a nameserver is about a days if you already have a DNS64 model. The hard bit is working out how to talk to the NAT64 implementation. A good project to put on a Raspberry Pi or similar. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Oct 10, 2023, at 17:20, Mark Andrews <marka@isc.org> wrote:
On 11 Oct 2023, at 09:43, Delong.com via NANOG <nanog@nanog.org> wrote:
As a community, we have failed, because we never acknowledged and addressed the need for backward compatibility between IPv6 and IPv4, and instead counted on magic handwaving about tipping points and transition dates where suddenly there would be "enough" IPv6-connected resources that new networks wouldn't *need* IPv4 address space any more.
I’m not sure that we never acknowledged it, but we did fail to address it, largely because I think we basically determined that it’s “too hard”.
It’s not actually that hard to do on a small scale, i.e. inside a home CPE with a DNS server and a NAT64 implementation that supports semi static mappings. It does require IPv4 sites have IPv6 connectivity. You stand up a DNS46 which requests an unused IPv4 address from a prefix block, say 10/8, when there is an IPv6 address without an IPv4 address from the NAT64 with the IPv6 address it needs to be mapped to with an initial NAT64 lifetime value. The DNS46 would forget the mapping after half that initial lifetime. The DNS46 would return A records limited half the lifetime or less so they timeout before the NAT64 mapping expires. The hard part is scaling up to a large client base because not every DNS query results in IP traffic and you need a prefix block big enough to support the add rate of the client base. Doing this at ISP scale would be interesting to say the least. This is not theoretical. It has been implemented in the past though some to the details might differ.
That’s not what we’re talking about… That’s translation, not backwards compatibility.
Companies that have gone IPv6-only internally do this with fully static IPv4 to IPv6 mappings and skip the DNS46 step.
But doing that requires that the companies have a certain amount of V4. The question was how to talk to v4-only hosts with ZERO IPv4 addresses available to you.
So if you have a legacy device that can’t talk IPv6 there is a solution space that allows it to talk to the IPv6 internet. You need to install it however. Adding DNS46 to a nameserver is about a days if you already have a DNS64 model. The hard bit is working out how to talk to the NAT64 implementation. A good project to put on a Raspberry Pi or similar.
I’m a new entity. I need to talk to the IPv4 internet. I have zero IPv4 addresses and none are available to me. How do I make any of this work? That’s the question that remains unsolved and that’s the one we most desperately failed to tackle. Owen
It is no different to deploying PNAT44 in every CPE box in the world to allow you to connect to the global IPv4 internet today. Virtually no home network on the planet has fully functional IPv4 available to it. Many businesses networks don’t have fully functional IPv4 networks. We have already installed transition middle boxes between the public IPv4 internet and your private IPv4 internet. The are just so ubiquitous that you are unaware of them. This is just a transition between your IPv4 internet (public or private) and the global IPv6 internet. Almost all traffic flows go through a transition box today. If the router modifies the source or destination addresses or the ports of the packet it is a transition box. It is the border between two internets. -- Mark Andrews
On 12 Oct 2023, at 06:07, Delong.com <owen@delong.com> wrote:
On Oct 10, 2023, at 17:20, Mark Andrews <marka@isc.org> wrote:
On 11 Oct 2023, at 09:43, Delong.com via NANOG <nanog@nanog.org> wrote:
As a community, we have failed, because we never acknowledged and addressed the need for backward compatibility between IPv6 and IPv4, and instead counted on magic handwaving about tipping points and transition dates where suddenly there would be "enough" IPv6-connected resources that new networks wouldn't *need* IPv4 address space any more.
I’m not sure that we never acknowledged it, but we did fail to address it, largely because I think we basically determined that it’s “too hard”.
It’s not actually that hard to do on a small scale, i.e. inside a home CPE with a DNS server and a NAT64 implementation that supports semi static mappings. It does require IPv4 sites have IPv6 connectivity. You stand up a DNS46 which requests an unused IPv4 address from a prefix block, say 10/8, when there is an IPv6 address without an IPv4 address from the NAT64 with the IPv6 address it needs to be mapped to with an initial NAT64 lifetime value. The DNS46 would forget the mapping after half that initial lifetime. The DNS46 would return A records limited half the lifetime or less so they timeout before the NAT64 mapping expires. The hard part is scaling up to a large client base because not every DNS query results in IP traffic and you need a prefix block big enough to support the add rate of the client base. Doing this at ISP scale would be interesting to say the least. This is not theoretical. It has been implemented in the past though some to the details might differ.
That’s not what we’re talking about… That’s translation, not backwards compatibility.
Companies that have gone IPv6-only internally do this with fully static IPv4 to IPv6 mappings and skip the DNS46 step.
But doing that requires that the companies have a certain amount of V4. The question was how to talk to v4-only hosts with ZERO IPv4 addresses available to you.
So if you have a legacy device that can’t talk IPv6 there is a solution space that allows it to talk to the IPv6 internet. You need to install it however. Adding DNS46 to a nameserver is about a days if you already have a DNS64 model. The hard bit is working out how to talk to the NAT64 implementation. A good project to put on a Raspberry Pi or similar.
I’m a new entity. I need to talk to the IPv4 internet. I have zero IPv4 addresses and none are available to me.
How do I make any of this work?
That’s the question that remains unsolved and that’s the one we most desperately failed to tackle.
Owen
On Oct 11, 2023, at 12:47, Mark Andrews <marka@isc.org> wrote:
It is no different to deploying PNAT44 in every CPE box in the world to allow you to connect to the global IPv4 internet today. Virtually no home network on the planet has fully functional IPv4 available to it. Many businesses networks don’t have fully functional IPv4 networks. We have already installed transition middle boxes between the public IPv4 internet and your private IPv4 internet. The are just so ubiquitous that you are unaware of them. This is just a transition between your IPv4 internet (public or private) and the global IPv6 internet.
1. I’m one of the few homes that is an exception to that “virtually no home” statement. 2. Yes, I’m acutely aware of them, I’ve deployed plenty of them, and regret each and every one. 3. The difference is that you can deploy a PNAT44 CPE box without an IPv6 address. You cannot deploy a NAPT64 box without an IPv4 address.
Almost all traffic flows go through a transition box today.
Sad but true. Still not really relevant to the point being made.
If the router modifies the source or destination addresses or the ports of the packet it is a transition box. It is the border between two internets.
Absolutely agree… Still not the point… The point here is that at some point, even with translation, we run out of IPv4 addresses to use for this purpose. What then? Owen
-- Mark Andrews
On 12 Oct 2023, at 06:07, Delong.com <owen@delong.com> wrote:
On Oct 10, 2023, at 17:20, Mark Andrews <marka@isc.org> wrote:
On 11 Oct 2023, at 09:43, Delong.com via NANOG <nanog@nanog.org> wrote:
As a community, we have failed, because we never acknowledged and addressed the need for backward compatibility between IPv6 and IPv4, and instead counted on magic handwaving about tipping points and transition dates where suddenly there would be "enough" IPv6-connected resources that new networks wouldn't *need* IPv4 address space any more.
I’m not sure that we never acknowledged it, but we did fail to address it, largely because I think we basically determined that it’s “too hard”.
It’s not actually that hard to do on a small scale, i.e. inside a home CPE with a DNS server and a NAT64 implementation that supports semi static mappings. It does require IPv4 sites have IPv6 connectivity. You stand up a DNS46 which requests an unused IPv4 address from a prefix block, say 10/8, when there is an IPv6 address without an IPv4 address from the NAT64 with the IPv6 address it needs to be mapped to with an initial NAT64 lifetime value. The DNS46 would forget the mapping after half that initial lifetime. The DNS46 would return A records limited half the lifetime or less so they timeout before the NAT64 mapping expires. The hard part is scaling up to a large client base because not every DNS query results in IP traffic and you need a prefix block big enough to support the add rate of the client base. Doing this at ISP scale would be interesting to say the least. This is not theoretical. It has been implemented in the past though some to the details might differ.
That’s not what we’re talking about… That’s translation, not backwards compatibility.
Companies that have gone IPv6-only internally do this with fully static IPv4 to IPv6 mappings and skip the DNS46 step.
But doing that requires that the companies have a certain amount of V4. The question was how to talk to v4-only hosts with ZERO IPv4 addresses available to you.
So if you have a legacy device that can’t talk IPv6 there is a solution space that allows it to talk to the IPv6 internet. You need to install it however. Adding DNS46 to a nameserver is about a days if you already have a DNS64 model. The hard bit is working out how to talk to the NAT64 implementation. A good project to put on a Raspberry Pi or similar.
I’m a new entity. I need to talk to the IPv4 internet. I have zero IPv4 addresses and none are available to me.
How do I make any of this work?
That’s the question that remains unsolved and that’s the one we most desperately failed to tackle.
Owen
On 12 Oct 2023, at 06:51, Delong.com <owen@delong.com> wrote:
On Oct 11, 2023, at 12:47, Mark Andrews <marka@isc.org> wrote:
It is no different to deploying PNAT44 in every CPE box in the world to allow you to connect to the global IPv4 internet today. Virtually no home network on the planet has fully functional IPv4 available to it. Many businesses networks don’t have fully functional IPv4 networks. We have already installed transition middle boxes between the public IPv4 internet and your private IPv4 internet. The are just so ubiquitous that you are unaware of them. This is just a transition between your IPv4 internet (public or private) and the global IPv6 internet.
1. I’m one of the few homes that is an exception to that “virtually no home” statement. 2. Yes, I’m acutely aware of them, I’ve deployed plenty of them, and regret each and every one. 3. The difference is that you can deploy a PNAT44 CPE box without an IPv6 address. You cannot deploy a NAPT64 box without an IPv4 address.
Almost all traffic flows go through a transition box today.
Sad but true. Still not really relevant to the point being made.
If the router modifies the source or destination addresses or the ports of the packet it is a transition box. It is the border between two internets.
Absolutely agree… Still not the point…
The point here is that at some point, even with translation, we run out of IPv4 addresses to use for this purpose. What then?
You deliver the Internet over IPv6. A really large functional Internet exists today if you only have IPv6. It is only getting bigger. Lots of (the majority?) of CDNs deliver content over IPv6. Lots of companies outsource their SMTP to dual stacked service providers so that email still gets through. After 20 years there is no excuse for ISPs failing to deliver IPv6. If you have to you, outsource your NAT64, DS-Lite transition service to someone that has IPv4. I’m surprised that it isn’t common today.
Owen
-- Mark Andrews
On 12 Oct 2023, at 06:07, Delong.com <owen@delong.com> wrote:
On Oct 10, 2023, at 17:20, Mark Andrews <marka@isc.org> wrote:
On 11 Oct 2023, at 09:43, Delong.com via NANOG <nanog@nanog.org> wrote:
As a community, we have failed, because we never acknowledged and addressed the need for backward compatibility between IPv6 and IPv4, and instead counted on magic handwaving about tipping points and transition dates where suddenly there would be "enough" IPv6-connected resources that new networks wouldn't *need* IPv4 address space any more.
I’m not sure that we never acknowledged it, but we did fail to address it, largely because I think we basically determined that it’s “too hard”.
It’s not actually that hard to do on a small scale, i.e. inside a home CPE with a DNS server and a NAT64 implementation that supports semi static mappings. It does require IPv4 sites have IPv6 connectivity. You stand up a DNS46 which requests an unused IPv4 address from a prefix block, say 10/8, when there is an IPv6 address without an IPv4 address from the NAT64 with the IPv6 address it needs to be mapped to with an initial NAT64 lifetime value. The DNS46 would forget the mapping after half that initial lifetime. The DNS46 would return A records limited half the lifetime or less so they timeout before the NAT64 mapping expires. The hard part is scaling up to a large client base because not every DNS query results in IP traffic and you need a prefix block big enough to support the add rate of the client base. Doing this at ISP scale would be interesting to say the least. This is not theoretical. It has been implemented in the past though some to the details might differ.
That’s not what we’re talking about… That’s translation, not backwards compatibility.
Companies that have gone IPv6-only internally do this with fully static IPv4 to IPv6 mappings and skip the DNS46 step.
But doing that requires that the companies have a certain amount of V4. The question was how to talk to v4-only hosts with ZERO IPv4 addresses available to you.
So if you have a legacy device that can’t talk IPv6 there is a solution space that allows it to talk to the IPv6 internet. You need to install it however. Adding DNS46 to a nameserver is about a days if you already have a DNS64 model. The hard bit is working out how to talk to the NAT64 implementation. A good project to put on a Raspberry Pi or similar.
I’m a new entity. I need to talk to the IPv4 internet. I have zero IPv4 addresses and none are available to me.
How do I make any of this work?
That’s the question that remains unsolved and that’s the one we most desperately failed to tackle.
Owen
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
The point here is that at some point, even with translation, we run out of IPv4 addresses to use for this purpose. What then?
You deliver the Internet over IPv6. A really large functional Internet exists today if you only have IPv6. It is only getting bigger. Lots of (the majority?) of CDNs deliver content over IPv6. Lots of companies outsource their SMTP to dual stacked service providers so that email still gets through. After 20 years there is no excuse for ISPs failing to deliver IPv6. If you have to you, outsource your NAT64, DS-Lite transition service to someone that has IPv4. I’m surprised that it isn’t common today.
And now we have come full circle to the attitude that leads to Matt’s initial point:
As a community, we have failed, because we never acknowledged and addressed the need for backward compatibility between IPv6 and IPv4, and instead counted on magic handwaving about tipping points and transition dates where suddenly there would be "enough" IPv6-connected resources that new networks wouldn't *need* IPv4 address space any more.
Owen
On Wed, Oct 11, 2023 at 1:53 PM Mark Andrews <marka@isc.org> wrote:
On 12 Oct 2023, at 06:51, Delong.com <owen@delong.com> wrote:
The point here is that at some point, even with translation, we run out of IPv4 addresses to use for this purpose. What then?
You deliver the Internet over IPv6. A really large functional Internet exists today if you only have IPv6. It is only getting bigger. Lots of (the majority?) of CDNs deliver content over IPv6. Lots of companies outsource their SMTP to dual stacked service providers so that email still gets through. After 20 years there is no excuse for ISPs failing to deliver IPv6. If you have to you, outsource your NAT64, DS-Lite transition service to someone that has IPv4. I’m surprised that it isn’t common today.
While you claim "there is no excuse for ISPs failing to deliver IPv6", the reality is that many ISPs don't support fully functional IPv6 deployments. There are far too many networks that allocate a single /64 for a wireless customer, and ignore DHCPv6-PD requests. There's a reason that IPv6-relay functionality in OpenWRT is so widespread--because even when ISPs "support" IPv6, they often do so poorly, leading to awkward hacks like relaying the same /64 downstream through intervening routers. I'm all for the eventual success of IPv6, but at the moment, we're really not there. But the bigger point is that there's still big chunks of the content side that aren't reachable via IPv6. https://www.6connect.com/blog/ipv6-progress-report-top-sites-2019/ http://www.delong.com/ipv6_alexa500.html https://whynoipv6.com/ That last report shows that only half of the top 1000 websites on the Alexa ranking support IPv6. So we're a long way away from being able to simply say "You deliver the Internet over IPv6." Your last two sentences are exactly what I stated as a business proposition earlier. You said (fixing the typos): "If you have to, you outsource your NAT64, DS-Lite transition service to someone that has IPv4. I’m surprised that it isn’t common today." In a world where only half the content sites are reachable via IPv6, and IPv4 address space is exhausted, that requirement to outsource NAT64 functionality is becoming more and more a business reality going forward. Can you list any company today that provides an outsourced NAT64 translation service? The only one I'm aware of is the one Kasper Dupont is running, and he's got a very clear warning that it's not suitable for high-volume use. I can't help but see an up-and-coming demand for services to fill this need, as it's clear Kasper's setup isn't going to handle the load for all the IPv6-only networks that decide there's actually content they want to get to in the other half of the Alexa top 1000 sites that don't support IPv6. I'm enjoying being retired, but seeing a future demand with nobody stepping up to fulfill that demand is almost enticing enough to be worth un-retiring for to build out... Thanks! Matt
On Sat, 14 Oct 2023 13:59:11 -0700 Matthew Petach <mpetach@netflight.com> wrote:
That last report shows that only half of the top 1000 websites on the Alexa ranking support IPv6.
The Alexa ranking is no longer maintained. ISOC had a recent article talking about just this: <https://pulse.internetsociety.org/blog/do-half-of-the-most-popular-websites-use-ipv6> John
On Sat, Oct 14, 2023 at 2:37 PM John Kristoff <jtk@dataplane.org> wrote:
On Sat, 14 Oct 2023 13:59:11 -0700 Matthew Petach <mpetach@netflight.com> wrote:
That last report shows that only half of the top 1000 websites on the Alexa ranking support IPv6.
The Alexa ranking is no longer maintained. ISOC had a recent article talking about just this:
< https://pulse.internetsociety.org/blog/do-half-of-the-most-popular-websites-...
John
Good to know, John, though it doesn't change the underlying issue; as the Oct 12th Pulse report from your link says, "If we look at Figure 2, we can see nearly half of the top 1,000 websites are IPv6 capable." which basically says things haven't moved much since the last Alexa-rank-based measurements were taken. Thank you for the pointer to more-up-to-date data! Matt
Well, I think the sane solution would be to push customers/clients into IPv6 and keep services IPv4. Then start moving services to dualstack. Most of todays customers/clients are consumers. They just connect to server to get data, watch movies, listen to music. Gaming is similar. That way, ISPs could do NAT64 thingie to provide IPv6 -> IPv4 bridges. More IPv4 addresses would be freed for power users. After decade, IPv4 could be nearly gone. If only IPv6 would suck so badly... ;) ---------- Original message ---------- From: Delong.com via NANOG <nanog@nanog.org> To: Matthew Petach <mpetach@netflight.com> Cc: Geoff Huston <gih@apnic.net>, Delong.com via NANOG <nanog@nanog.org> Subject: Re: maximum ipv4 bgp prefix length of /24 ? Date: Tue, 10 Oct 2023 15:43:28 -0700 Im not sure that we never acknowledged it, but we did fail to address it, largely because I think we basically determined that its too hard. Theres really no way for a machine with a >32 bit address to feasibly/reliably talk to a machine that only understands 32-bit addresses short of involving some sort of intermediate proxy host doing some form of address translation. Weve actually got LOTS of those solutions deployed with varying levels of success/failure/idiosyncrasies. Ive spent a fair amount of time thinking about alternatives and admit that I, myself am stumped as to how one would go about this. Do you have a proposal for how this problem could have been/could be solved?
On 10 Oct 2023, at 5:35 am, Delong.com <owen@delong.com> wrote:
Now I’m trying to understand what your grimmer story for IPv4 might be here Owen. Since 2005 the number of IPv4 FIB entries per origin AS has increased fropm 8 to 12 in the past 20 years - or a 50% increase. Over ther same period the number of IPv6 prefix advertisements per origin AS has increased from 1.5 to 6, or a fourfold increase. If anything, the IPv6 story appears to me to be a far greater cause for concern, but you may have a different interpretation of this data.
I admit I’m surprised that IPv6 has gotten to an average of 6, but it would be interesting to know why that is. Honestly, I expected it would end up closer to 4. I wonder how much of that is PI stub networks being originated by upstream transit networks. I also wonder to what extent the “average” might be misleading here. Is it a few ASs with large numbers of prefixes and mostly 1-2 prefixes per AS or is the average representative?
I know that in IPv4, for example, there are several ASs originating MANY prefixes and lots of smaller ASs originating <4 prefixes.
My grimmer picture for IPv4 is about the intrinsic pressure to deaggregate that comes from the ever finer splitting of blocks in the transfer market and the ever finer grained dense packing of hosts into prefixes that is forced from address scarcity. Those pressures don’t (or at least shouldn’t) exist for IPv6.
The questions you ask Owen are obviously answerable by anyone with access to a BGP routing table dump (which is pretty much anyone!). BGP is many things - it is a topology maintenance protocol, but its a traffic engineering protocol and an attack mitigation protocol. In the latter two cases advertising more specifics play a crucial role. The pressure to slice and dice in IPv4 is a mix of reachability in a space where address availability is under acute pressure, and TE and DOS mitigation. The pressures on IPv6 are predominately from the latter two categories. I suspect that as IPv6 becomes a larger part of the traffic mix (and inexorably that appears to be happening) then the TE and DOS issues become more of an operational concern, hence rising more specifics in IPv6.
The questions you ask Owen are obviously answerable by anyone with access to a BGP routing table dump (which is pretty much anyone!).
BGP is many things - it is a topology maintenance protocol, but its a traffic engineering protocol and an attack mitigation protocol. In the latter two cases advertising more specifics play a crucial role. The pressure to slice and dice in IPv4 is a mix of reachability in a space where address availability is under acute pressure, and TE and DOS mitigation. The pressures on IPv6 are predominately from the latter two categories. I suspect that as IPv6 becomes a larger part of the traffic mix (and inexorably that appears to be happening) then the TE and DOS issues become more of an operational concern, hence rising more specifics in IPv6.
I think a certain amount of desegregation for TE is inevitable and will always be part of the system. At least theoretically, DDOS mitigation specifics should be relatively transient in nature and anti-hijacking more specifics should be solved by RPKI max prefix length attributes in ROAs. I guess it’s maybe good news that IPv6 rollout is happening faster than RPKI rollout, but IPv6 rollout is still way too slow. There is, however, recent very good news on that front: owendelong@PK9XYF9GRK-1346 ~ % host www.amazon.com www.amazon.com is an alias for tp.47cf2c8c9-frontier.amazon.com. tp.47cf2c8c9-frontier.amazon.com is an alias for d3ag4hukkh62yn.cloudfront.net. d3ag4hukkh62yn.cloudfront.net has address 108.138.248.64 d3ag4hukkh62yn.cloudfront.net has IPv6 address 2600:9000:24bb:fe00:7:49a5:5fd2:8621 d3ag4hukkh62yn.cloudfront.net has IPv6 address 2600:9000:24bb:2400:7:49a5:5fd2:8621 d3ag4hukkh62yn.cloudfront.net has IPv6 address 2600:9000:24bb:5e00:7:49a5:5fd2:8621 d3ag4hukkh62yn.cloudfront.net has IPv6 address 2600:9000:24bb:7600:7:49a5:5fd2:8621 d3ag4hukkh62yn.cloudfront.net has IPv6 address 2600:9000:24bb:7800:7:49a5:5fd2:8621 d3ag4hukkh62yn.cloudfront.net has IPv6 address 2600:9000:24bb:ae00:7:49a5:5fd2:8621 d3ag4hukkh62yn.cloudfront.net has IPv6 address 2600:9000:24bb:b600:7:49a5:5fd2:8621 d3ag4hukkh62yn.cloudfront.net has IPv6 address 2600:9000:24bb:f000:7:49a5:5fd2:8621 I don’t know how deep into the Amazon process that goes or if it’s possible to actually browse Amazon and complete an order without IPv4 yet, but this is at least significant progress from one of the biggest barriers to IPv6-only that remained a few years ago. Yes, I could get the answers from my own table dumps, even, but I would have to find/build the necessary analysis tools to crunch the almost 1M prefix tables to extract that information and even beyond that, attempting to infer the cause becomes an even more interesting challenge (as you not only well know, but have expressed in some of your rather excellent presentations on the subject in past years). At the moment, the things that pay the bills have higher priorities for my time than delving into these questions that deeply. Owen
participants (7)
-
borg＠uu3.net -
Delong.com -
Geoff Huston -
Geoff Huston -
John Kristoff -
Mark Andrews -
Matthew Petach