I don't understand why you can't have any protocol that can (potentially recursively) resolve to a layer 2 address as a next hop.
v4 route with v6 next hop? Seems reasonable.
v6 route with v4 next hop? Why not?
v4/v6 route with a mac address as a next hop? Trivial.
v4/v6 route with a DNS next hop? Could be recursively resolved to a v4/v6 address, and then potentially recursively resolved to a MAC address. I wouldn't recommend it, but sure.
v4/v6 route with a netbeui name as a next hop? You appear to be mad, but I'm not going to be the one to stand in your way.
> I don't understand why you can't have any protocol that can (potentially recursively) resolve to a layer 2 address as a next hop.
Which Layer 2? Ethernet? Token Ring? Infiniband? ATM? Fibre Channel?
Both IPv4 and IPv6 were created when there were multiple Layer 2 protocols in use. That's why where was a completely different protocol to handle Layer 2 to 3 mappings (often itself referred to as a Layer "2.5" one):
I find the reason why I can't run IPv6 is that we have ISP failover and the IPv6 doesn't failover gracefully with two different wan providers. With IPv4, the local ip table isn't impacted by a change in WAN ip for the most part and the local network keeps on chugging perfectly.
(Short version: IPv6-only networks can provide a gateway for IPv4-only clients and advertise it via reverse DNS.)
SixGate has an interesting contrast with this RFC. RFC8950 removes IPv4 from the network core while preserving IPv4 reachability, whereas SixGate removes IPv4 from the service side while preserving reachability for IPv4-only clients.
In both cases, IPv4 survives as a compatibility layer rather than a fundamental requirement. The difference is that RFC8950 is aimed at network operators, while SixGate is aimed at the last remaining IPv4-only users.
In both cases, the goal is the same. Turn IPv4 from a requirement into an optional compatibility feature.
You still need at least one IPv4 address somewhere if you want to send ICMP back, yes. (Typically a loopback, i.e., something not connected to a specific interface. Routers use loopback interfaces for rather different purposes than a Linux workstation.) But you don't need to set up an IPv4 address on every interface, so you don't need a linknet plan.
You can also forego the IPv4 addresses entirely, but then traceroute (and presumably also stuff like Path MTU Discovery; have consistent MTUs!) won't work. traceroute is often broken for entirely different reasons, though.
> They still do things the old way but Backbone can run IPv6 only at its core.
This would turn an internal IPv4 into an externally routed IPv6, which is a neat trick which would replace all the NAT madness that we do run today.
I'd like nothing more than the ability to run ipv4 internally indefinitely, especially with things like mesh networks where the ACLs are carried over from ages ago (2018 doesn't feel that long ago, but it is).
Most of the time I don't even need a route to a direct connection, I just need legible flow logs out of a kubernetes platform.
More like, the point is to facilitate turning off IPv4. It's much nicer to manage a single-stacked backbone, but you still need IPv4 out in the edges somehow (for many cases, anyway). I guess this is another way to do that.
Heck, I would be happy if I could remove some IPv4 linknets from my IS-IS, myself, and just route using IPv6 link-local nexthops…
It's also just nice to not need numbered point-to-point links (ie. just use IPv6 LL).
(this is one of those things that's really magical with OSPv3 - it just runs on IPv6 LL addresses, no need to set anything up other than set the link to be within some area and it just works! well, as much as they do with OSPF anyway.)
A router still needs a non-link-local address in order to be able to send ICMP errors off-link -- which you're going to want if you want sensible output from traceroute..
The Abstract and Introduction sections of the RFC [0] explain what the point of this is. The "Changes Compared to RFC 5549" section is especially good reading, as it both alerts you to the fact that this is an update to a seventeen year old RFC and explains what changed in the update.
Multiple ISPs in my country have already deployed IPv6 with NAT64 support, and with CLAT support now available, I think IPv6-only networks will be the next step for most ISPs.
IPv6 mostly (RFC 8925) is a rather nice migration option.
Modern operating systems will gladly do CLAT, and old operating systems (or fussy users) can still get their IPv4 by just ignoring the new DHCPv4 option. But admins can finally stop keeping an IPv4 around for every potential client as most applications and users really don't care.
There is also MAP-T which basically does CGNAT with IPv6-only provider network. The local network gets IPv4, the router translates to IPv6 which goes to stateless IPv4 NAT proxy. The advantage is that the proxy is stateless unlike CGNAT. The downside is requires custom code on the router.
In other words, given a need for IPv4, it enables switching to mostly IPv6... seems like transition technology and reality might finally meet because both moved towards the other.
A few more RFCs, a few more IP over IP bandaid, a few more extensions, and we will get there. By God IPv6 is a stain in the history of computer science.
IPv6 should have really just worked like NAT/IP over IP on IPv4 hardware and fast path on IPv6 hardware. But instead we got a monster that keeps growing with things like NAT64, 4over6, DS-Lite, MAP-E, and now BGP stopgaps and a growing
> IPv6 should have really just worked like NAT/IP over IP on IPv4 hardware
This literally exists. There's no need for it to be part of the original specification because it's a completely separate concept.
There's nothing wrong with ipv6 other than the general human desire to not change things that "work" and for people who are currently powerful because they own a bunch of ipv4 to resist changes.
> There's nothing wrong with ipv6 other than [long list of human things]
The unfortunate reality is that technology exists to serve us. If humans don't want to use it, it means that your technology is wrong. End of story. It doesn't matter if you (or any of us) think it's elegant and beautifully designed.
Declaring a technology-in-transition dead is truly a take.
It's like declaring SSL/TLS dead in 2012 because some websites were not using it. (Yes, I remember the dark times when even authentication data was transmitted over plain text.)
My first job out of college passed the authentication over SSL/TLS, but the page that *contained* the login form? That was sent in the clear.... Truly dark days.
If your solution is that “if everyone just used IPv6 we wouldn’t have this problem” then it’s not a solution. Standards like USB, Wi-Fi, HDMI, DP, etc. are so successful because they are by out-of-the-box backwards compatible with their predecessors.
You missed the part where DP didn't come with it's own Audio Codec and GPU architecture. Of course, I am exaggerating, but the point is that the problem with IPv6 is not just that it suffers from bad design on merit, it also critically suffers from scope creep. We wanted a larger IP space, instead we got network discovery and globally unique cookies as a bundle deal, with a whole lot of other crap.
You're basically saying "only if people all moved to IPv6 we wouldn't have any problems", which is laughable at best.
But to answer your question, no, supporting dp is not as easy as just slapping a 50 cent port, but it also doesn't make things worst in unrelated areas. That is the point you seem to gloss over with IPv6. It is an ugly over engineered mess.
> Close to 3 decades and we are barely scraping 50%
That's what I'd regard as a success.
With majority IPv6 in most leading economies, and getting close to or just over 50% worldwide, the tipping point has been reached and IPv6 is now the dominant IP protocol. The future is a long slow slide of the public use of IPv4 into oblivion, just as envisaged in the original IPv6 planning, and IPv4 support will eventually become a compatibility layer tunnelled over all-IPv6 networks, just as IPv6 was originally tunnelled via IPv4. In the longer-term future, once public IPv4 traffic has reduced to only a couple of percent, ISPs will start to turn it off as an irrelevance, leaving v4 as a legacy protocol for LANs and private networks. Expect this sometime in the late 21st century or early 22nd. Some very old IoT devices may stop working, but everyone who cares about any important use will have replaced them long before.
Meanwhile, the Internet will continue to operate seamlessly for everyone else.
Yeah, that is the whole point. It was never going to be a clean cut. "Works in my lab" isn't good enough for real world.
The issue isn't that it wasn't planned properly, the issue is that the real world wasn't taken into consideration by people who either worked for the likes of Google who were aching for a globally unique identifier per device or just delusional about how much we can change in real world.
> Yeah, that is the whole point. It was never going to be a clean cut.
As predicted:
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
Creating an IPng was always going to be complicated:
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
It was never going to be a clean cut, which is why we didn't design it for a clean cut and instead developed a bunch of approaches to transitioning to it that deal with the real-world problems of the transition.
What more do you want from it?
What could they have possibly done differently to make you happy with it?
> people who either worked for the likes of Google who were aching for a globally unique identifier per device
v6 doesn't give you globally unique device identifiers. Devices get IPs from the network in v6, just like they do in v4. You're either thinking of MAC addresses or perhaps things like HIP (https://datatracker.ietf.org/doc/html/rfc7401). I guess there is Mobile IPv6 which allows you to take your address to another network, but then there's also privacy extensions which prevent your machine from using the same IP for very long, so it's still not a unique identifier for your device.
> The issue isn't that it wasn't planned properly, the issue is that the real world wasn't taken into consideration by people who either worked for the likes of Google who were aching for a globally unique identifier per device or just delusional about how much we can change in real world.
All this complaining and not so much as a single hint or even belief that there's a better solution.
I suppose we could read into the complaint some kind of faith that one does exist, but since nobody has found it yet, the faith is a little uncompelling so far.
There's EVERYTHING wrong with IPv6. It's a recursively bad protocol. From the basic header design (extension headers, wtf) to the "human management" layer ("why should we deploy IPv6 if it actively _breaks_ stuff?").
As an example, try to design a standards-compliant IPv6 network where you can reliably print from an Android phone if your Internet connection goes down and the router withdraws the prefix. It's trivial with IPv4 and _impossible_ with IPv6.
> if your Internet connection goes down and the router withdraws the prefix
My router advertises both the public prefix from my ISP and a ULA prefix for internal LAN connections (essentially the IPv6 equivalent to RFC-1918). This gives me stable local addresses that do not change and work without public internet access.
> My router advertises both the public prefix from my ISP and a ULA prefix for internal LAN connections
You'd think so, but you'd be wrong. If you have a GUA and a ULA, and the printer has both a GUA and a ULA, then your host is going to prefer the GUA when connecting to the printer.
So when a router withdraws a prefix, it's possible for your computer to still have a (stale) GUA while the printer only has a ULA. Whoops, and your printing is broken.
Moreover, some devices will refuse to connect to IPv6 GUA with ULA addresses altogether.
> Yes, your local devices will use the ULA to attempt to connect to Internet destinations if that’s the only v6 address they have. It works fine.
You're half right. The devices will work fine because they won't be using IPv6 at all.
As I said, IPv6 is a recursive WTF.
How do I know that? I made a personal goal to create a dualstack demo network that is fully standards compliant and supports the bare minimum functionality that I would expect from a SOHO network. So far, I keep finding new and exciting breakages on every level.
> This is an option, but ULAs are ranked _below_ IPv4 in address selection preferences. So your network will essentially operate in IPv4 mode
If they don’t have an v4 address then they don’t have that problem.
NPT solves the issue of your devices losing global addresses.
Ideally you wouldn’t need NPT, and you should have an RA for the ULA and an RA for the GUA and then use the ULA locally... but then you end up with a different problem (and why I didn’t do it at home). Doing this means you have little control about which upstream ISP gets chosen. I have two ISPs at home, and router will failover between them; however, even though I have PI IP space, finding a residential ISP that will let me use it is nearly impossible (good luck finding someone there who even knows what BGP is).
So the tradeoff here for me is not letting my devices have a GUA so that my router can control outbound traffic policy completely (like it can with v4), and just NPT it to what I need it to be externally. Works great (but again, if you only have one global prefix you need to deal with, separate RAs for ULA/GUA do work better).
> You're half right. The devices will work fine because they won't be using IPv6 at all.
Not if they don’t have an IPv4 address to begin with!
You can also coax your local DNS resolver to... just not let A records through if the name also has an AAAA record.
Even better than that would be out of the box like magic 464XLAT in home routers / ISPs. As it is 464XLAT is not the nicest thing in the world to configure; however, it does work very well, and does allow for a network to be entirely v6 except at the very edge. Heck, I’d love it if enterprise gear had “like magic” 464XLAT too. Would make a lot of things easier.
> How do I know that? I made a personal goal to create a dualstack demo network that is fully standards compliant and supports the bare minimum functionality that I would expect from a SOHO network. So far, I keep finding new and exciting breakages on every level.
If you really want to accomplish that, completely forget about trying to make dual stack work throughout the network. It’s an exercise in frustration, mostly in needing to duplicate config in v4 and v6, and you will inevitably have them end up out of sync with each other.
464XLAT is good standard here, DNS64 with a NAT64 does also work... for things with names at least.
One of the other comments around here about not providing a “migration plan” does have a lot of truth to it. If, 30 years ago, they envisioned 464XLAT and made it part of the default features a v6 capable router should have, I bet v4 would be long dead (or nearly there) by now.
IPv6-only is not a reasonable assumption for the next 10 years or so. Networks must support IPv4 for the reasonable future in some form, just because of a huge amount of V4-only IoT devices with long expected lifetimes.
But anyway, ULA vs. GUA preference is mostly an academic question. In practice, you can just squat on an unused IPv6 range and avoid the precedence issue.
The deeper problem is that the solution to IPv6 problems appears to be NAT. And we're switching from IPv4 to avoid NAT. And you'll need a stateful firewall for IPv6 anyway (it's a recommendation for SOHO, there's an RFC for it, too lazy to dig it up now).
I'm stubborn, so my house now has its own ASN, a PI block, and a DIA connection to two ISPs. Which is the only NAT-less way to achieve my goal.
> One of the other comments around here about not providing a “migration plan” does have a lot of truth to it. If, 30 years ago, they envisioned 464XLAT and made it part of the default features a v6 capable router should have, I bet v4 would be long dead (or nearly there) by now.
464XLAT (and its evil twin IPv6 RD) were envisioned in the early 2000-s. Along with about 20 various "migration plans". They all missed the point, though. Some people are still missing it.
The key to migration has never been some form of tunneling. The key to migration is making IPv4 and IPv6 coexist side-by-side, in other words, the Happy Eyeballs algorithm. It should have been reified to the TCP level in the late 90-s. So that applications could just do: `connect("somehost.com", 80)` and transparently get either an IPv4 or IPv6 connection, depending on whichever one works better locally. Other operational headaches like the ULA priority would have surfaced much earlier then.
>IPv6-only is not a reasonable assumption for the next 10 years or so. Networks must support IPv4 for the reasonable future in some form, just because of a huge amount of V4-only IoT devices with long expected lifetimes.
I’d say it’s a perfectly reasonable assumption. Why? In practice most mobile carriers (notably T-Mobile USA likes to discuss it) are entirely v6 only, with 464XLAT at the edges.
If mobile carriers can do it, and support $billions of devices, it does work, and works well.
If you do have any v4-only IoT trash, put it on its own VLAN (where all the IoT garbage should be no matter what anyway), and let that sole VLAN have v4 addresses.
>But anyway, ULA vs. GUA preference is mostly an academic question. In practice, you can just squat on an unused IPv6 range and avoid the precedence issue.
Totally, but it’s not a good practice to do, even if the risks are generally low. I don’t like to recommend it.
>The deeper problem is that the solution to IPv6 problems appears to be NAT. And we're switching from IPv4 to avoid NAT.
No one should be using NAT with v6 except in extremely limited circumstances. NPT is not NAT, the host portion of the network and, more importantly, the port do not change with NPT. Many of the issues of working around NAT on v4 just don’t exist with NPT. The only “real” limitation with NPT is global address discovery. (Which you’d also have with squatting, and one of the many reasons you shouldn’t do that).
>I'm stubborn, so my house now has its own ASN, a PI block, and a DIA connection to two ISPs. Which is the only NAT-less way to achieve my goal.
I’m very close to doing something similar. There’s an ISP POP that has a few Colo racks about 5 miles away that has clear radio line of sight to my house. I’ve strongly considered using a PtP radio and putting my home internet connection at the POP, just so I can use BGP with my own space to resolve this issue to my satisfaction. The alternative is tunneled connections to where I can use BGP and all of the headaches that go along with that.
>464XLAT (and its evil twin IPv6 RD) were envisioned in the early 2000-s. Along with about 20 various "migration plans". They all missed the point, though. Some people are still missing it.
Doesn’t matter when it was envisioned if it’s not a “just works” tech. There’s a silly amount of minutiae you have to work through to make it work. It should be as simple as enabling it for a VLAN and assigning v4 addresses to the XLAT on a router. Except for rare cases, it’s not the easy. It should be though.
>The key to migration has never been some form of tunneling. The key to migration is making IPv4 and IPv6 coexist side-by-side, in other words, the Happy Eyeballs algorithm. It should have been reified to the TCP level in the late 90-s. So that applications could just do: `connect("somehost.com", 80)` and transparently get either an IPv4 or IPv6 connection, depending on whichever one works better locally. Other operational headaches like the ULA priority would have surfaced much earlier then.
That is effectively how it works, they can coexist together, but it is significantly simpler to only use one. I do agree with you on the ULA priority though. Was a moronic decision to place that below v4, likely again, a lack of imagination on their part.
> I’d say it’s a perfectly reasonable assumption. Why? In practice most mobile carriers (notably T-Mobile USA likes to discuss it) are entirely v6 only, with 464XLAT at the edges.
Carriers have their own specific challenges. Like not having enough private or even squattable IPv4 space for the voice circuits.
> If mobile carriers can do it, and support $billions of devices, it does work, and works well.
Mobile devices are actually pretty much the best case for IPv6. The phone environment is standardized and highly controlled. And yet some telecoms still don't provide end-user IPv6, even when the voice circuits use IPv6.
> No one should be using NAT with v6 except in extremely limited circumstances. NPT is not NAT, the host portion of the network and, more importantly, the port do not change with NPT.
This is really a distinction without difference. In practice, SOHO border routers have to be stateful to provide meaningful security for UDP-based protocols like SIP or QUIC.
> That is effectively how it works, they can coexist together, but it is significantly simpler to only use one.
The socket API still doesn't allow this. You have to implement Happy Eyeballs on the app level.
> I do agree with you on the ULA priority though. Was a moronic decision to place that below v4, likely again, a lack of imagination on their part.
If you want to look at politics, this was a compromise. There was a strong faction of "network fundamentalists" in the IETF that had a vision of a transparent end-to-end network with global addressing. So that a lightbulb in China could connect to a toaster in the US at will. So they resisted anything that could promote locally isolated networks.
But most of the IETF had a clue and actual operational experience, so they pushed for things like the ULA and PI space for IPv6. So we got these compromises that don't work well as a result.
Most things IoT are trash, the v4 only special kinds are even bigger pieces of trash.
If you happen to have millions of dollars worth of v4-only IoT devices, that sounds like a you problem. v4 exhaustion has been known for decades, IoT devices that don’t support v6 were ewaste before they even left the factory.
While this is going to be fine for many users, wouldn't this continue our reliance on STUN for UDP hole punching? I'd certainly prefer a world where peer-to-peer networking is less reliant on work-arounds created for the NAT era.
Not necessarily, NPT is stateless as the only thing changing is the network prefix (hence NP). The host portion of the address doesn’t change and the ports stay the same on both sides of the translation.
There would still need to be some form of global address discovery, but that’s a much simpler problem to solve in nearly all scenarios.
You’d still have the issue of whether the firewalls in between you and the remote end allow that connection through in the first place though.
That RFC does look like a nice improvement! Until then, since both devices have a ULA address, wouldn't simply deleting the printer from your phone/computer and re-adding it resolve the issue? Doing it when your public internet is down would probably even be best to ensure you're getting the ULA instead of GUA, thereby avoiding this issue entirely in the future.
(Admittedly I haven't had a printer for over a decade and I have never printed from a phone, so maybe I am missing something.)
In practice, nobody uses IPv6 for printers, so it'll work just fine over IPv4.
I used a printer as an example of a local device, it can be any other device: a smart lightbulb, a TV you're casting to, a SIP phone, etc. And I used Android as an example of a device where you can't easily change the source address selection preference.
What is more shocking is that this problem has been known for three decades, yet somehow nobody cared enough to fix it. And it's far from the only issue.
The extension headers are fine, because they frequently are not needed, so the fact that they are optional allows the IPv6 header to be significantly simpler than the IPv4 header, which has some seldom used fields which are always present.
No, they are not fine. Their design means that the router needs to know all possible extension headers to just be able to route the packets. Oh, and you also have to do offset-chasing in the hardware fastpath.
As a consequence, IPv6 with extension headers are just dropped by routers in the public Internet.
With one exception, extension headers are not examined or processed
by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header.
That seems like the opposite of needing to know all possible extension headers in order to route a packet.
The issue is that the extension headers can be used for nefarious purposes, such as hop-by-hop routing. So your fast hardware-based border routers might be EH-agnostic and transmit packets to your core network. And then a helpful Linux box that implements all of IPv6 in software would reflect the traffic right past your firewall.
Implementing the EHs in hardware is expensive, as you need to do conditional checks. So routers just drop them.
On the other hand, if Android supported IA_NA we would probably be seeing ISPs in the wild handing out /112s and going "But it's 2^16 IPs! We're being so generous, what could you possibly have to complain about?", so it's quite possible that adding support would be to the detriment of all Internet users.
Android does now support IA_PD, so the people who need to track IP use via DHCPv6 requests should now be happy. (We'll just put aside the question of whether doing that even makes sense in a world where devices can be told to use any IP.)
When v6 was “invented” I believe they thought “everyone” would have PI addresses, as was (relatively) common 30 years ago.
If everyone has their own PI space, and used BGP with their ISPs this would also be “zero setup” with v6 as that’s the entire point of BGP and PI addresses.
It was a definite failure of imagination that they did not think of how this would work if you don’t control your own IP space.
If you have ISPs you can peer with over BGP and your own PI IP space this does “just work” as you’d expect. The same way it “just works” with v4 in a NATless world.
A lot of the things that “just work” in v4 are really just NAT sweeping the rough edges under the rug. The same problems exist in v4, but don’t get seen in practice as local / global addresses are effectively always different on your network (unless you’re lucky enough to be a legacy allocation that has an /8 of v4 I suppose).
If you enforce that same “separation” in v6 (with NPT, or NAT) surprise the “problems” also go away, like they do in v4.
Not really. Believe it or not, but the initial plan for IPv6 was to NOT have the PI blocks at all. Everyone was supposed to use PA (Provider Aggregated) blocks.
The needs for dual-homing and failover were completely glossed over in the IPv6 design, and the IETF has not acknowledged these needs even to this day.
"PA" or "PI" is an administrative distinction and technically has nothing to do with BGP or multi-homing. You can still announce PA blocks under your own ASN. I do that today, actually.
It's the same with IPv4, by the way. An ISP can assign you a block from their allocation, you can still announce it with your own ASN as long as it doesn't violate the issuing provider's policy, you're still a customer, etc.
It does have the effect of requiring you to follow the upstream ISP's numbering system. So if they switch the prefix, you have to follow.
And it's more of the "it's the thought that counts" thing. Multihoming was considered to be something rather exotic and mostly a requirement for ISPs or large companies.
Yes, but that rarely happens with IPv6. ISP / LIRs get huge allocations.
The real problem is BGP isn't available from most home or "small business" internet connections. You can't multihome even if you want to. You need a DIA / enterprise plan, or you need to use tunneling (which is what I do, from several BGP capable VPSes, in a configuration that is too complex for the typical SMB.)
I do admit this is a challenge. The only reason it's "easy" with IPv4 is because of NAT. With IPv6 you'll need prefix translation. I've found someone with a failover solution for UniFi but in general you are correct, it's a pain: https://github.com/mattackerman808/ipv6-wan-failover
You can do it with prefix translation. Unfortunately, it's one of the many things where v6 almost provides a nice solution, but reality is terrible. If you just advertise both prefixes, your clients are going to do cool stuff like use an address from one router and send packets to the other router.
I don't understand why you can't have any protocol that can (potentially recursively) resolve to a layer 2 address as a next hop.
v4 route with v6 next hop? Seems reasonable. v6 route with v4 next hop? Why not? v4/v6 route with a mac address as a next hop? Trivial. v4/v6 route with a DNS next hop? Could be recursively resolved to a v4/v6 address, and then potentially recursively resolved to a MAC address. I wouldn't recommend it, but sure. v4/v6 route with a netbeui name as a next hop? You appear to be mad, but I'm not going to be the one to stand in your way.
> I don't understand why you can't have any protocol that can (potentially recursively) resolve to a layer 2 address as a next hop.
Which Layer 2? Ethernet? Token Ring? Infiniband? ATM? Fibre Channel?
Both IPv4 and IPv6 were created when there were multiple Layer 2 protocols in use. That's why where was a completely different protocol to handle Layer 2 to 3 mappings (often itself referred to as a Layer "2.5" one):
* https://en.wikipedia.org/wiki/Address_Resolution_Protocol
That's basically MP-BGP! Your dream is real.
(Keep in mind that the setup described here has work for years now.)
https://www.rfc-editor.org/info/rfc8950/
I find the reason why I can't run IPv6 is that we have ISP failover and the IPv6 doesn't failover gracefully with two different wan providers. With IPv4, the local ip table isn't impacted by a change in WAN ip for the most part and the local network keeps on chugging perfectly.
Shameless plug: https://billpg.com/sixgate/
(Short version: IPv6-only networks can provide a gateway for IPv4-only clients and advertise it via reverse DNS.)
SixGate has an interesting contrast with this RFC. RFC8950 removes IPv4 from the network core while preserving IPv4 reachability, whereas SixGate removes IPv4 from the service side while preserving reachability for IPv4-only clients.
In both cases, IPv4 survives as a compatibility layer rather than a fundamental requirement. The difference is that RFC8950 is aimed at network operators, while SixGate is aimed at the last remaining IPv4-only users.
In both cases, the goal is the same. Turn IPv4 from a requirement into an optional compatibility feature.
> R1 & R2 are IPv6 only with no IPv4 anywhere on their interfaces (but carry IPv4 routes in their table)
… proceeds to traceroute with IPv4 addresses showing up for each router…
It’s neat but still requires IPv4 to be configured on the router? What am I missing?
You still need at least one IPv4 address somewhere if you want to send ICMP back, yes. (Typically a loopback, i.e., something not connected to a specific interface. Routers use loopback interfaces for rather different purposes than a Linux workstation.) But you don't need to set up an IPv4 address on every interface, so you don't need a linknet plan.
You can also forego the IPv4 addresses entirely, but then traceroute (and presumably also stuff like Path MTU Discovery; have consistent MTUs!) won't work. traceroute is often broken for entirely different reasons, though.
> They still do things the old way but Backbone can run IPv6 only at its core.
This would turn an internal IPv4 into an externally routed IPv6, which is a neat trick which would replace all the NAT madness that we do run today.
I'd like nothing more than the ability to run ipv4 internally indefinitely, especially with things like mesh networks where the ACLs are carried over from ages ago (2018 doesn't feel that long ago, but it is).
Most of the time I don't even need a route to a direct connection, I just need legible flow logs out of a kubernetes platform.
I guess the point with this to facilitate usage of IPv6.
More like, the point is to facilitate turning off IPv4. It's much nicer to manage a single-stacked backbone, but you still need IPv4 out in the edges somehow (for many cases, anyway). I guess this is another way to do that.
Heck, I would be happy if I could remove some IPv4 linknets from my IS-IS, myself, and just route using IPv6 link-local nexthops…
It's also just nice to not need numbered point-to-point links (ie. just use IPv6 LL).
(this is one of those things that's really magical with OSPv3 - it just runs on IPv6 LL addresses, no need to set anything up other than set the link to be within some area and it just works! well, as much as they do with OSPF anyway.)
A router still needs a non-link-local address in order to be able to send ICMP errors off-link -- which you're going to want if you want sensible output from traceroute..
Use a loopback address! Only one to configure per host, and useful to establish iBGP sessions on them afterwards.
There is an RFC for ICMP extensions that fix this, RFC 5837.
> I guess the point with this to facilitate usage of IPv6.
See §6, "Usage Examples": IPv4 over IPv6 Core, IPv4 VPN Unicast over IPv6 Core, IPv4 VPN Multicast over IPv6 Core.
* https://datatracker.ietf.org/doc/html/rfc8950#name-usage-exa...
So it's to facilitate legacy IPv4 usage when the rest of your infrastructure is IPv6.
The Abstract and Introduction sections of the RFC [0] explain what the point of this is. The "Changes Compared to RFC 5549" section is especially good reading, as it both alerts you to the fact that this is an update to a seventeen year old RFC and explains what changed in the update.
[0] <https://datatracker.ietf.org/doc/html/rfc8950>
Multiple ISPs in my country have already deployed IPv6 with NAT64 support, and with CLAT support now available, I think IPv6-only networks will be the next step for most ISPs.
IPv6 mostly (RFC 8925) is a rather nice migration option.
Modern operating systems will gladly do CLAT, and old operating systems (or fussy users) can still get their IPv4 by just ignoring the new DHCPv4 option. But admins can finally stop keeping an IPv4 around for every potential client as most applications and users really don't care.
There is also MAP-T which basically does CGNAT with IPv6-only provider network. The local network gets IPv4, the router translates to IPv6 which goes to stateless IPv4 NAT proxy. The advantage is that the proxy is stateless unlike CGNAT. The downside is requires custom code on the router.
It's to facilitate use of IPv4 in an IPv6-mostly network.
In other words, given a need for IPv4, it enables switching to mostly IPv6... seems like transition technology and reality might finally meet because both moved towards the other.
[flagged]
[flagged]
Your comment was flagged, I vouched it
It's AI-generated.
Uh, why do you think that?
Edit: After reviewing their post history it makes a bit more sense.
[dead]
A few more RFCs, a few more IP over IP bandaid, a few more extensions, and we will get there. By God IPv6 is a stain in the history of computer science.
IPv6 should have really just worked like NAT/IP over IP on IPv4 hardware and fast path on IPv6 hardware. But instead we got a monster that keeps growing with things like NAT64, 4over6, DS-Lite, MAP-E, and now BGP stopgaps and a growing
https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...
> IPv6 should have really just worked like NAT/IP over IP on IPv4 hardware
This literally exists. There's no need for it to be part of the original specification because it's a completely separate concept.
There's nothing wrong with ipv6 other than the general human desire to not change things that "work" and for people who are currently powerful because they own a bunch of ipv4 to resist changes.
> There's nothing wrong with ipv6 other than [long list of human things]
The unfortunate reality is that technology exists to serve us. If humans don't want to use it, it means that your technology is wrong. End of story. It doesn't matter if you (or any of us) think it's elegant and beautifully designed.
That's like blaming the photovoltaic cell for the lack of solar power in america.
There's no way to design a technical solution to a social/human problem at ipv4 shortage is a human problem.
People have spent literally the last 40 years trying to come up with a solution "better than ipv6" and NOBODY HAS. Does that tell you anything?
Declaring a technology-in-transition dead is truly a take.
It's like declaring SSL/TLS dead in 2012 because some websites were not using it. (Yes, I remember the dark times when even authentication data was transmitted over plain text.)
People still mine, ship and burn coal for energy.
Turns out its hard to get people to change their own habits to help other people.
My first job out of college passed the authentication over SSL/TLS, but the page that *contained* the login form? That was sent in the clear.... Truly dark days.
If your solution is that “if everyone just used IPv6 we wouldn’t have this problem” then it’s not a solution. Standards like USB, Wi-Fi, HDMI, DP, etc. are so successful because they are by out-of-the-box backwards compatible with their predecessors.
>HDMI, DP, etc. are so successful because they are by out-of-the-box backwards compatible with their predecessors
Takes on Hacker News can truly be wild sometimes.
I certainly don't recall being able to use DP on a VGA monitor without some sort of adapter!
You missed the part where DP didn't come with it's own Audio Codec and GPU architecture. Of course, I am exaggerating, but the point is that the problem with IPv6 is not just that it suffers from bad design on merit, it also critically suffers from scope creep. We wanted a larger IP space, instead we got network discovery and globally unique cookies as a bundle deal, with a whole lot of other crap.
> You missed the part where DP didn't come with it's own Audio Codec and GPU architecture
Do you think supporting dp is as easy as just slapping a 50 cent port on the side of the display??
> but the point is that the problem with IPv6 is not just that it suffers from bad design on merit
It doesn't.
> instead we got network discovery and globally unique cookies as a bundle deal, with a whole lot of other crap.
How does any of this apply to people not replacing hardware that is ipv4 only?
You're basically saying "only if people all moved to IPv6 we wouldn't have any problems", which is laughable at best.
But to answer your question, no, supporting dp is not as easy as just slapping a 50 cent port, but it also doesn't make things worst in unrelated areas. That is the point you seem to gloss over with IPv6. It is an ugly over engineered mess.
> This literally exists. There's no need for it to be part of the original specification because it's a completely separate concept.
By that token, IPv6 never had to exist at all then, but we know that is completely missing the point.
IPv6 is a privacy nightmare without privacy extensions. It is designed with "a stupid desire to pretend we can boil the ocean".
Close to 3 decades and we are barely scraping 50%: https://stats.labs.apnic.net/ipv6/
> Close to 3 decades and we are barely scraping 50%
That's what I'd regard as a success.
With majority IPv6 in most leading economies, and getting close to or just over 50% worldwide, the tipping point has been reached and IPv6 is now the dominant IP protocol. The future is a long slow slide of the public use of IPv4 into oblivion, just as envisaged in the original IPv6 planning, and IPv4 support will eventually become a compatibility layer tunnelled over all-IPv6 networks, just as IPv6 was originally tunnelled via IPv4. In the longer-term future, once public IPv4 traffic has reduced to only a couple of percent, ISPs will start to turn it off as an irrelevance, leaving v4 as a legacy protocol for LANs and private networks. Expect this sometime in the late 21st century or early 22nd. Some very old IoT devices may stop working, but everyone who cares about any important use will have replaced them long before.
Meanwhile, the Internet will continue to operate seamlessly for everyone else.
Running a IPv6-only network that doesn’t interact with IPv4 networks in any way is great and it works.
The actual gap is the mess of mixing/transitioning, and it wasnt planned properly in the last 30years
Yeah, that is the whole point. It was never going to be a clean cut. "Works in my lab" isn't good enough for real world.
The issue isn't that it wasn't planned properly, the issue is that the real world wasn't taken into consideration by people who either worked for the likes of Google who were aching for a globally unique identifier per device or just delusional about how much we can change in real world.
> Yeah, that is the whole point. It was never going to be a clean cut.
As predicted:
* https://datatracker.ietf.org/doc/html/rfc1726#section-5.5Creating an IPng was always going to be complicated:
* https://github.com/becarpenter/misc/blob/main/why6why.md* https://datatracker.ietf.org/doc/html/rfc1671
[dead]
It was never going to be a clean cut, which is why we didn't design it for a clean cut and instead developed a bunch of approaches to transitioning to it that deal with the real-world problems of the transition.
What more do you want from it?
What could they have possibly done differently to make you happy with it?
> people who either worked for the likes of Google who were aching for a globally unique identifier per device
v6 doesn't give you globally unique device identifiers. Devices get IPs from the network in v6, just like they do in v4. You're either thinking of MAC addresses or perhaps things like HIP (https://datatracker.ietf.org/doc/html/rfc7401). I guess there is Mobile IPv6 which allows you to take your address to another network, but then there's also privacy extensions which prevent your machine from using the same IP for very long, so it's still not a unique identifier for your device.
> The issue isn't that it wasn't planned properly, the issue is that the real world wasn't taken into consideration by people who either worked for the likes of Google who were aching for a globally unique identifier per device or just delusional about how much we can change in real world.
All this complaining and not so much as a single hint or even belief that there's a better solution.
I suppose we could read into the complaint some kind of faith that one does exist, but since nobody has found it yet, the faith is a little uncompelling so far.
This is hardly useful point. Internet is a collective project and there is only so much resources for making changes and improving things.
The problem with IPv6 apologists is that they're ignoring reality and just crying "only if everyone switched it would be fine."
We're out of ipv4. We need a solution that isn't 5 layers of nested nats. What is it?
> without privacy extensions
Privacy extensions are enabled by default on every major operating system.
> There's nothing wrong with ipv6
Sweet summer child...
There's EVERYTHING wrong with IPv6. It's a recursively bad protocol. From the basic header design (extension headers, wtf) to the "human management" layer ("why should we deploy IPv6 if it actively _breaks_ stuff?").
As an example, try to design a standards-compliant IPv6 network where you can reliably print from an Android phone if your Internet connection goes down and the router withdraws the prefix. It's trivial with IPv4 and _impossible_ with IPv6.
> if your Internet connection goes down and the router withdraws the prefix
My router advertises both the public prefix from my ISP and a ULA prefix for internal LAN connections (essentially the IPv6 equivalent to RFC-1918). This gives me stable local addresses that do not change and work without public internet access.
https://en.wikipedia.org/wiki/Unique_local_address
> My router advertises both the public prefix from my ISP and a ULA prefix for internal LAN connections
You'd think so, but you'd be wrong. If you have a GUA and a ULA, and the printer has both a GUA and a ULA, then your host is going to prefer the GUA when connecting to the printer.
So when a router withdraws a prefix, it's possible for your computer to still have a (stale) GUA while the printer only has a ULA. Whoops, and your printing is broken.
There is an RFC in review that would fix this: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda... . It'll likely be approved in 2027, so you'd be able to use ULAs some time in the 2030-s once it trickles down.
Ditch advertising public addresses to local devices at all.
Have the router issue ULAs only and let the router do stateless NPT (network prefix translation) only.
Done, works great. Doesn’t matter what your internet connection is doing.
Yes, your local devices will use the ULA to attempt to connect to Internet destinations if that’s the only v6 address they have. It works fine.
> Have the router issue ULAs only and let the router do stateless NPT (network prefix translation) only.
This is an option, but ULAs are ranked _below_ IPv4 in address selection preferences. So your network will essentially operate in IPv4 mode: https://www.ietf.org/archive/id/draft-buraglio-6man-rfc6724-...
Moreover, some devices will refuse to connect to IPv6 GUA with ULA addresses altogether.
> Yes, your local devices will use the ULA to attempt to connect to Internet destinations if that’s the only v6 address they have. It works fine.
You're half right. The devices will work fine because they won't be using IPv6 at all.
As I said, IPv6 is a recursive WTF.
How do I know that? I made a personal goal to create a dualstack demo network that is fully standards compliant and supports the bare minimum functionality that I would expect from a SOHO network. So far, I keep finding new and exciting breakages on every level.
> This is an option, but ULAs are ranked _below_ IPv4 in address selection preferences. So your network will essentially operate in IPv4 mode
If they don’t have an v4 address then they don’t have that problem.
NPT solves the issue of your devices losing global addresses.
Ideally you wouldn’t need NPT, and you should have an RA for the ULA and an RA for the GUA and then use the ULA locally... but then you end up with a different problem (and why I didn’t do it at home). Doing this means you have little control about which upstream ISP gets chosen. I have two ISPs at home, and router will failover between them; however, even though I have PI IP space, finding a residential ISP that will let me use it is nearly impossible (good luck finding someone there who even knows what BGP is).
So the tradeoff here for me is not letting my devices have a GUA so that my router can control outbound traffic policy completely (like it can with v4), and just NPT it to what I need it to be externally. Works great (but again, if you only have one global prefix you need to deal with, separate RAs for ULA/GUA do work better).
> You're half right. The devices will work fine because they won't be using IPv6 at all.
Not if they don’t have an IPv4 address to begin with!
You can also coax your local DNS resolver to... just not let A records through if the name also has an AAAA record.
Even better than that would be out of the box like magic 464XLAT in home routers / ISPs. As it is 464XLAT is not the nicest thing in the world to configure; however, it does work very well, and does allow for a network to be entirely v6 except at the very edge. Heck, I’d love it if enterprise gear had “like magic” 464XLAT too. Would make a lot of things easier.
> How do I know that? I made a personal goal to create a dualstack demo network that is fully standards compliant and supports the bare minimum functionality that I would expect from a SOHO network. So far, I keep finding new and exciting breakages on every level.
If you really want to accomplish that, completely forget about trying to make dual stack work throughout the network. It’s an exercise in frustration, mostly in needing to duplicate config in v4 and v6, and you will inevitably have them end up out of sync with each other.
464XLAT is good standard here, DNS64 with a NAT64 does also work... for things with names at least.
One of the other comments around here about not providing a “migration plan” does have a lot of truth to it. If, 30 years ago, they envisioned 464XLAT and made it part of the default features a v6 capable router should have, I bet v4 would be long dead (or nearly there) by now.
IPv6-only is not a reasonable assumption for the next 10 years or so. Networks must support IPv4 for the reasonable future in some form, just because of a huge amount of V4-only IoT devices with long expected lifetimes.
But anyway, ULA vs. GUA preference is mostly an academic question. In practice, you can just squat on an unused IPv6 range and avoid the precedence issue.
The deeper problem is that the solution to IPv6 problems appears to be NAT. And we're switching from IPv4 to avoid NAT. And you'll need a stateful firewall for IPv6 anyway (it's a recommendation for SOHO, there's an RFC for it, too lazy to dig it up now).
I'm stubborn, so my house now has its own ASN, a PI block, and a DIA connection to two ISPs. Which is the only NAT-less way to achieve my goal.
> One of the other comments around here about not providing a “migration plan” does have a lot of truth to it. If, 30 years ago, they envisioned 464XLAT and made it part of the default features a v6 capable router should have, I bet v4 would be long dead (or nearly there) by now.
464XLAT (and its evil twin IPv6 RD) were envisioned in the early 2000-s. Along with about 20 various "migration plans". They all missed the point, though. Some people are still missing it.
The key to migration has never been some form of tunneling. The key to migration is making IPv4 and IPv6 coexist side-by-side, in other words, the Happy Eyeballs algorithm. It should have been reified to the TCP level in the late 90-s. So that applications could just do: `connect("somehost.com", 80)` and transparently get either an IPv4 or IPv6 connection, depending on whichever one works better locally. Other operational headaches like the ULA priority would have surfaced much earlier then.
>IPv6-only is not a reasonable assumption for the next 10 years or so. Networks must support IPv4 for the reasonable future in some form, just because of a huge amount of V4-only IoT devices with long expected lifetimes.
I’d say it’s a perfectly reasonable assumption. Why? In practice most mobile carriers (notably T-Mobile USA likes to discuss it) are entirely v6 only, with 464XLAT at the edges.
If mobile carriers can do it, and support $billions of devices, it does work, and works well.
If you do have any v4-only IoT trash, put it on its own VLAN (where all the IoT garbage should be no matter what anyway), and let that sole VLAN have v4 addresses.
>But anyway, ULA vs. GUA preference is mostly an academic question. In practice, you can just squat on an unused IPv6 range and avoid the precedence issue.
Totally, but it’s not a good practice to do, even if the risks are generally low. I don’t like to recommend it.
>The deeper problem is that the solution to IPv6 problems appears to be NAT. And we're switching from IPv4 to avoid NAT.
No one should be using NAT with v6 except in extremely limited circumstances. NPT is not NAT, the host portion of the network and, more importantly, the port do not change with NPT. Many of the issues of working around NAT on v4 just don’t exist with NPT. The only “real” limitation with NPT is global address discovery. (Which you’d also have with squatting, and one of the many reasons you shouldn’t do that).
>I'm stubborn, so my house now has its own ASN, a PI block, and a DIA connection to two ISPs. Which is the only NAT-less way to achieve my goal.
I’m very close to doing something similar. There’s an ISP POP that has a few Colo racks about 5 miles away that has clear radio line of sight to my house. I’ve strongly considered using a PtP radio and putting my home internet connection at the POP, just so I can use BGP with my own space to resolve this issue to my satisfaction. The alternative is tunneled connections to where I can use BGP and all of the headaches that go along with that.
>464XLAT (and its evil twin IPv6 RD) were envisioned in the early 2000-s. Along with about 20 various "migration plans". They all missed the point, though. Some people are still missing it.
Doesn’t matter when it was envisioned if it’s not a “just works” tech. There’s a silly amount of minutiae you have to work through to make it work. It should be as simple as enabling it for a VLAN and assigning v4 addresses to the XLAT on a router. Except for rare cases, it’s not the easy. It should be though.
>The key to migration has never been some form of tunneling. The key to migration is making IPv4 and IPv6 coexist side-by-side, in other words, the Happy Eyeballs algorithm. It should have been reified to the TCP level in the late 90-s. So that applications could just do: `connect("somehost.com", 80)` and transparently get either an IPv4 or IPv6 connection, depending on whichever one works better locally. Other operational headaches like the ULA priority would have surfaced much earlier then.
That is effectively how it works, they can coexist together, but it is significantly simpler to only use one. I do agree with you on the ULA priority though. Was a moronic decision to place that below v4, likely again, a lack of imagination on their part.
> I’d say it’s a perfectly reasonable assumption. Why? In practice most mobile carriers (notably T-Mobile USA likes to discuss it) are entirely v6 only, with 464XLAT at the edges.
Carriers have their own specific challenges. Like not having enough private or even squattable IPv4 space for the voice circuits.
> If mobile carriers can do it, and support $billions of devices, it does work, and works well.
Mobile devices are actually pretty much the best case for IPv6. The phone environment is standardized and highly controlled. And yet some telecoms still don't provide end-user IPv6, even when the voice circuits use IPv6.
> No one should be using NAT with v6 except in extremely limited circumstances. NPT is not NAT, the host portion of the network and, more importantly, the port do not change with NPT.
This is really a distinction without difference. In practice, SOHO border routers have to be stateful to provide meaningful security for UDP-based protocols like SIP or QUIC.
> That is effectively how it works, they can coexist together, but it is significantly simpler to only use one.
The socket API still doesn't allow this. You have to implement Happy Eyeballs on the app level.
> I do agree with you on the ULA priority though. Was a moronic decision to place that below v4, likely again, a lack of imagination on their part.
If you want to look at politics, this was a compromise. There was a strong faction of "network fundamentalists" in the IETF that had a vision of a transparent end-to-end network with global addressing. So that a lightbulb in China could connect to a toaster in the US at will. So they resisted anything that could promote locally isolated networks.
But most of the IETF had a clue and actual operational experience, so they pushed for things like the ULA and PI space for IPv6. So we got these compromises that don't work well as a result.
> If you do have any v4-only IoT trash
If it works and gets the job done. Who are you to call it trash? Are you happy to pay a few million dollars for me to upgrade my infra?
Most things IoT are trash, the v4 only special kinds are even bigger pieces of trash.
If you happen to have millions of dollars worth of v4-only IoT devices, that sounds like a you problem. v4 exhaustion has been known for decades, IoT devices that don’t support v6 were ewaste before they even left the factory.
But how do you know it is trash? You don't know anything about my devices.
[dead]
While this is going to be fine for many users, wouldn't this continue our reliance on STUN for UDP hole punching? I'd certainly prefer a world where peer-to-peer networking is less reliant on work-arounds created for the NAT era.
Not necessarily, NPT is stateless as the only thing changing is the network prefix (hence NP). The host portion of the address doesn’t change and the ports stay the same on both sides of the translation.
There would still need to be some form of global address discovery, but that’s a much simpler problem to solve in nearly all scenarios.
You’d still have the issue of whether the firewalls in between you and the remote end allow that connection through in the first place though.
That RFC does look like a nice improvement! Until then, since both devices have a ULA address, wouldn't simply deleting the printer from your phone/computer and re-adding it resolve the issue? Doing it when your public internet is down would probably even be best to ensure you're getting the ULA instead of GUA, thereby avoiding this issue entirely in the future.
(Admittedly I haven't had a printer for over a decade and I have never printed from a phone, so maybe I am missing something.)
In practice, nobody uses IPv6 for printers, so it'll work just fine over IPv4.
I used a printer as an example of a local device, it can be any other device: a smart lightbulb, a TV you're casting to, a SIP phone, etc. And I used Android as an example of a device where you can't easily change the source address selection preference.
What is more shocking is that this problem has been known for three decades, yet somehow nobody cared enough to fix it. And it's far from the only issue.
[dead]
The extension headers are fine, because they frequently are not needed, so the fact that they are optional allows the IPv6 header to be significantly simpler than the IPv4 header, which has some seldom used fields which are always present.
No, they are not fine. Their design means that the router needs to know all possible extension headers to just be able to route the packets. Oh, and you also have to do offset-chasing in the hardware fastpath.
As a consequence, IPv6 with extension headers are just dropped by routers in the public Internet.
https://datatracker.ietf.org/doc/html/rfc2460#section-4:
That seems like the opposite of needing to know all possible extension headers in order to route a packet.Again, in practice the packets with _any_ IPv6 extension headers are unusable when traversing the public Internet: https://blog.apnic.net/2022/10/13/ipv6-extension-headers-rev...
The issue is that the extension headers can be used for nefarious purposes, such as hop-by-hop routing. So your fast hardware-based border routers might be EH-agnostic and transmit packets to your core network. And then a helpful Linux box that implements all of IPv6 in software would reflect the traffic right past your firewall.
Implementing the EHs in hardware is expensive, as you need to do conditional checks. So routers just drop them.
That really seems more like a problem with the people dropping the packets than with the packet design itself.
How else would you do it? Forcing every packet to reserve space for every possible option (including all future ones) seems obviously worse.
If it works with mainstream Linux, sounds like an Android problem
Android’s developers have long had their own vision on how v6 should work to the detriment of their own users...
Exhibit A: https://issuetracker.google.com/issues/36949085
On the other hand, if Android supported IA_NA we would probably be seeing ISPs in the wild handing out /112s and going "But it's 2^16 IPs! We're being so generous, what could you possibly have to complain about?", so it's quite possible that adding support would be to the detriment of all Internet users.
Android does now support IA_PD, so the people who need to track IP use via DHCPv6 requests should now be happy. (We'll just put aside the question of whether doing that even makes sense in a world where devices can be told to use any IP.)
That's not a very good example.
1) I can count on one hand the number of times my Internet connection has gone down in the past 5 years.
2) I can count on zero hands the number of times I've tried to print from a phone, ever.
I explained the problem in a sibling post on this thread.
But you want a more complex challenge? Here you go!
You have a small business office that has two Internet uplinks for redundancy. You want to balance the load across them and failover broken links.
This can be done with literally zero setup with IPv4.
This is teasing at a bigger issue.
When v6 was “invented” I believe they thought “everyone” would have PI addresses, as was (relatively) common 30 years ago.
If everyone has their own PI space, and used BGP with their ISPs this would also be “zero setup” with v6 as that’s the entire point of BGP and PI addresses.
It was a definite failure of imagination that they did not think of how this would work if you don’t control your own IP space.
If you have ISPs you can peer with over BGP and your own PI IP space this does “just work” as you’d expect. The same way it “just works” with v4 in a NATless world.
A lot of the things that “just work” in v4 are really just NAT sweeping the rough edges under the rug. The same problems exist in v4, but don’t get seen in practice as local / global addresses are effectively always different on your network (unless you’re lucky enough to be a legacy allocation that has an /8 of v4 I suppose).
If you enforce that same “separation” in v6 (with NPT, or NAT) surprise the “problems” also go away, like they do in v4.
Not really. Believe it or not, but the initial plan for IPv6 was to NOT have the PI blocks at all. Everyone was supposed to use PA (Provider Aggregated) blocks.
The needs for dual-homing and failover were completely glossed over in the IPv6 design, and the IETF has not acknowledged these needs even to this day.
They weren't glossed over. Dual-homing is handled in RFC 3484 (https://datatracker.ietf.org/doc/html/rfc3484#section-5 under rule 5) and ND is designed to detect unreachable routers and stop using them (see e.g. https://datatracker.ietf.org/doc/html/rfc1970#section-6.3.6). You can also specify router preference in RAs (https://datatracker.ietf.org/doc/html/rfc4191).
They thought about these things and put features into the protocol to support them. This is, once again, the opposite of your belief that they didn't.
"PA" or "PI" is an administrative distinction and technically has nothing to do with BGP or multi-homing. You can still announce PA blocks under your own ASN. I do that today, actually.
It's the same with IPv4, by the way. An ISP can assign you a block from their allocation, you can still announce it with your own ASN as long as it doesn't violate the issuing provider's policy, you're still a customer, etc.
It does have the effect of requiring you to follow the upstream ISP's numbering system. So if they switch the prefix, you have to follow.
And it's more of the "it's the thought that counts" thing. Multihoming was considered to be something rather exotic and mostly a requirement for ISPs or large companies.
Yes, but that rarely happens with IPv6. ISP / LIRs get huge allocations.
The real problem is BGP isn't available from most home or "small business" internet connections. You can't multihome even if you want to. You need a DIA / enterprise plan, or you need to use tunneling (which is what I do, from several BGP capable VPSes, in a configuration that is too complex for the typical SMB.)
I do admit this is a challenge. The only reason it's "easy" with IPv4 is because of NAT. With IPv6 you'll need prefix translation. I've found someone with a failover solution for UniFi but in general you are correct, it's a pain: https://github.com/mattackerman808/ipv6-wan-failover
You can do it with prefix translation. Unfortunately, it's one of the many things where v6 almost provides a nice solution, but reality is terrible. If you just advertise both prefixes, your clients are going to do cool stuff like use an address from one router and send packets to the other router.
Good times!
[dead]
This isn't one of those. It's for ISPs who run a native IPv6 backbone and want to exchange and route IPv4 traffic without setting up IPv4 addressing.
It is a network. No part of it is exactly a surprise. But 3 decades in, we are still getting there. Almost 50% any year from now!