IPv4 is never going away barring massive adoption of p2p protocols to drive the switch. Sadly NAT and SNI solve most of the problems well enough for things to limp along indefinitely. The only orgs with the power to fix this from the top down are incentivized to maintain the centralized status quo.
This was considered likely when IPng was being discussed in 1990s:
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.
Yep. And the reason they were successful is because you can solve the problem on your end without the other end needing to do anything. IPv6 requires both parties to do something. So now we're stuck with NAT and SNI.
If I have a bunch of machines on my network and want them all to be able to access the internet, I can use NAT and let them all share a single IP. No one on the internet needs to do anything.
If I have a bunch of servers and want them to be accessible by the internet, I can use SNI and let them all share a single IP, again with no special action required by those connecting.
With IPv6, it doesn't solve case 1 until all the servers on the internet support IPv6. AFAIK it doesn't support case 2 either, because you would need some way to route an incoming IPv4 connection to the right IPv6 server. IDK maybe there's a way.
For case 1, there is nat64. IPv6-only clients can use a special dns (dns64) to get access to the IPv4-only hosts while being able to talk directly to IPv6 hosts. It doesn't even require special support on the client.
For case 2, a dual-stack reverse-proxy will do the job and can talk to the IPv6-only servers without issue.
If I run out of IPv4 addresses for my own network, I can install NAT and make that problem (sort of, mostly, vaguely) go away.
If I want to use IPv6 to solve my IPv4 address shortage problem, and I want to communicate with you, I have to wait for you to also install IPv6.
SNI isn't really the same thing. For one thing it has actual positive benefits, very much unlike NAT (and no NAT is not a fucking security feature and is orthogonal to fucking firewalls don't make me come over there). And for me to use SNI, your browser (or whatever) has to send SNI, so it's still a change on only one end. But it still does let me put more than one service on a single IP address, and you only have to upgrade one program, probably a program you were going to upgrade anyway, rather than change your whole networking structure.
The way this should have worked was that IPv4 should have been turned off completely in the public Internet around 1997 or 1998. But ISPs didn't want to tell the much smaller number of much more sophisticated admins back then that they had to, you know, change things. So people just kept baking IPv4 into more and more things, and throwing in more and more NAT, and not even bothering learn or teach IPv6... and ignoring all the things they were breaking.
Many (not all!) of the things they were breaking were things that really came into play if you were trying to do P2P. Like, for instance, the ability to, you know, actually make a connection to any random peer. There are hacks, but they work poorly when they work at all. So since NAT was everywere, P2P didn't have a chance. There were other forces at work too, but basically everybody's business model and expectations gelled around centralization in a way that might have had a chance of not happening if there hadn't been NAT all over the place.
I'm not really familiar with IPv6. If I have a million IPv4 servers, it's pretty simple to set up a million subdomains and route incoming TLS requests using SNI. If I have a million IPv6 servers, can I somehow accomplish the same thing using DNS64/NAT64/464XLAT? Assuming the incoming request is from an IPv4-only host.
> what kind of p2p protocols are you thinking of ?
Skype was originally P2P, but because of NAT there had to exist "supernodes" which did STUN/TURN/ICE shenanigans to make it work (which caused scaling issues since there weren't enough of them):
file sharing, messaging, gaming, VOIP/VideoOIP, etc. basically everything we have today that has to route through a gateway in the cloud could be p2p . They actually all were int he 90s (e..g Napster, Limewire, ICQ) until vulnerabilities drove investment in aggressive firewall
I've done a few ipv6 migrations. The IPv6 fan community (e.g on reddit and other forums ) needs to accept a dual-stack world and the doubling of complexity required to operate that way. All effort should be about education and support for dual stack. That will be the only successful path to ipv6 adoption.
Sure ipv6 has some better features, but dual-stack means you are doubling all of your config (ACLs, naming, firewalls, routing) test cases and vulnerability surface. Moreover, ipv6 is not as intuitive.
Shaming people into ipv6 will never work. More effort should be invested into best practices, patterns, migration guides, support communities & more to assist in operating in a dual-stack environment for the foreseeable future.
Pure ipv6 will never happen because the weak link breaks the chain. How many people set up an ipv6 VPC with great excitement, and late in the project they deploy from github with "NS lookup failed".
So IPv6 is about 30 years old, and the testimony being shared is the chair of the group spending years of research and millions of dollars, finally launching ipv6 corporate lans in 2023.
Trying to re-engine a 747 in mid-air is a challenging operation.
> So IPv6 is about 30 years old, and the testimony being shared is the chair of the group spending years of research and millions of dollars, finally launching ipv6 corporate lans in 2023.
And how many years of research and millions of dollars was spent in the 1990s on IPv4? People used to use workstations as routers (e.g., see SunOS routeadm(1M)) and DNS caching servers before a lot of money was poured into ASICs for routing (and switching).
There are all sorts of dumbass things with IPv4: how much time has been wasted on engineering solutions around NAT (e.g., STUN/TURN/ICE)? But because IPv4 just happens to be the default we accept them as 'normal' and anything that is different is treated as 'abnormal'.
> You're not selling me on it's viability.
I'm not sure how it's not viable given there are mobile telco networks with tens (hundreds?) of millions of people getting only IPv6 addresses on their devices.
There are some folks who (a) were lucky enough to get in early on the IPv4 address land rush, or (b) are rich enough to be able to purchase IPv4 addresses, but there are also (c) plenty of folks who are left with scraps for IPv4 connectivity. The fact that you happen to fall into (a) or (b) does not mean you get to dismiss the folks in (c) who need IPv6, as otherwise they'd have no connectivity at all.
There's been endless effort into all of those things. What else are we supposed to do when people just aren't following them anyway?
It's not even double the config. For e.g. my firewall, which is a 300-line config that I've already designed and implemented, making it dual stack mostly involves writing "domain (ip ip6)" instead of "domain ip". That's simply not double.
It's not less intuitive than v4 either. That's a lack of experience talking. Meanwhile, trying to use v4 quickly devolves into needing to use NAT, which is less intuitive.
> Pure ipv6 will never happen because the weak link breaks the chain. How many people set up an ipv6 VPC with great excitement, and late in the project they deploy from github with "NS lookup failed".
My desktop is pure v6 and GitHub works fine, which I think disproves the "never" part.
When I used a small local ISP that did not support ipv6 before switching to AT&T fiber¹ I tried to set this up, but they demand an email on a non-gmail domain, and I wasn't going to pay to set that up nor was I going to use my work email. It's a bad assumption that any non-malicious user cares enough about websites to have one.
1: I'd prefer to have stayed with the local ISP despite the lack of ipv6, but they wanted $8,000 to bring fiber to my new place and that was not worth it with at&t fiber being present.
Gmail is a cesspool, and Google couldn't give the slightest bit of a shit. So does it really surprise you that people who share free services might not want to give those free services to people who use the cesspool service that doesn't care about abuse?
GMail is the most popular email provider by a wide margin. Denying service to the largest cohort of email users is indeed surprising, ridiculous, and self-defeating.
On the contrary: it's a decent filter for folks who would be very unlikely to be able to follow the instructions to set up and maintain their end of the tunnel.
(It also happens to be a fantastic filter for spammers and other abusers. Is it perfect? Hell no. But it is very good.)
Gmail rejects mailing list messages that every other email provider accepts. It is impossible to get a human at Google to look at these issues. That's kinda the worst of all worlds. At least other email providing companies have support teams that can be talked to when things go off the rails.
I can setup email on my own domain, but I don't want to. It isn't worth my time or money. This doesn't mean that I can't follow tunnel broker instructions.
I did this for a couple days when Comcast's DNS was fucking up when I moved into a new place and was stuck with their modem/router/AP for a bit (which was locked to like 6.6.6.6 or whatever it was).
Tried explaining it to several customer support techs but they all just gave up eventually.
Was fixed when I ended up getting my own modem and router/AP.
But those were an interesting few days. My partner was annoyed they couldn't use Pinterest but YouTube loaded fine. Google search worked but our local pizza joint's site didn't.
My networks are IPv6 only for a couple of years, but I do have to run NAT64 (jool) and use a DNS64 resolver (i use a google-provided, but you could run your own)
It had very little benefits at the beginning, but having dedicated publicly routed addresses started to become really conevinent.
IPv6 with a regulary changing dynamic prefix still sucks though to this day ... :-(
Huh, why IPv6 only instead of dual stack? Assuming you're talking about a home or small business network
The (occasionally, on Comcast) changing dynamic prefix was a pain for me too, when accessing things externally. For internal use I additionally set up a fixed ULA prefix.
The way I do this, my internal DNS resolves hosts to their fixed ULA addresses. For the handful that are accessible externally, public DNS resolves to their address on the current public prefix.
Note that currently with ULA if you have dual-stack IPv4 will be given priority over ULA. There is a late-stage—Submitted to IESG for Publication—draft that will change this:
More than just IPv4 priorities, almost all other IPv6 addresses are given higher priority which makes routing between ULAs on an internal network problematic.
That draft doc seems to fix multiple problems at once.
I did try that, but it ended in an infinite fight with the source address selection algorithm and DNS caches. Also, unique-local addresses are deprecated as far as I know.
> ...it ended in an infinite fight with the source address selection algorithm and DNS caches...
What did this fight look like? For the past fifteen, twenty years, I have NATted IPv4, globally-routable IPv6, and ULA IPv6 addresses on all of my machines attached to the internet-accessible VLANs on my LAN. The only trouble I've noticed was when ISP maintenance caused me to lose the globally-routable prefix for a little while and my franken-router started passing ULA traffic out the WAN interface. [0]
I'd love to hear what you've been seeing, so I can see if there's trouble that I've been overlooking.
> ...unique-local addresses are deprecated as far as I know.
ULAs are not deprecated. You may be thinking of site-local addresses. See the first paragraph of section 1 here: [1]
1) DNS caching: as devices roam in and out of my network, they don't always evict the cache and remember the wrong address.
When trying to connect to ULA from outside, that's not going to work.
When trying to connect to the public address from the inside, I face a firewal/config problem. Either I treat them as "outsider" and block/limit them incorrectly, or I need to dynamically update the setup to know what is internal.
2) DNS over HTTPS: which is forced by more and more things by default. They will always resolve to the outside address, even when on the local network. Causing the same problem as caching.
3) Source addr selection "stuck" on ULAs: When I loose the public prefix for a brief period, things tend to start using the ULA as a source for public destinations. This is not going to work as expected. However, when I get a new prefix, some things tend to be stuck for a long time on trying to use the ULA instead of using the new prefix.
4) I've seen devices incorrectly keep a ULA address from a different network, and attempting to use that on mine. This is definitely a bug in the device, but now it is my problem.
5) A variant of issue 4. is that some apple devices (TVs and similar) will just make up and start advertising their own ULA prefix. This is related to Matter support.
They should detect that there is already a ULA prefix and use that, but this detection is far from perfect, so sometimes they just do it anyway. Now my whole network has two ULAs. All devices should still use their "nearest" address to communicate, but - bugs again - sometimes they don't do that.
But hey, apple provides me with free pentesting to see if I have the RA filtering correctly setup in switches :-)
---
The list goes on, this is just what came to my mind immediately. There are really 3 conclusions I came to:
- Split-brain DNS is an outdated concept, being broken every day by new tech. You can't rely on the devices talking to the specific NS you want.
- There are a lot of buggy IPv6 implementations out there. Unless I control all devices on the network, I need to keep the advertised config very basic to keep everything working.
- Dual-stack and happy-eyeballs hide these issues too well. It is hard to detect and report them. Even if you do, vendors often just don't care or bother fixing because the issues do not have an immediate impact.
So, I think #3 will be solved by rejecting traffic from fc00::/7 that's going to be routed out the router's WAN interface. To do this on my network, I have this on the 'filter' table of my router firewall:
-A FORWARD -s fc00::/7 -o wan-interface -j REJECT
This should cause machines that attempt to use the only valid prefix during the outage to have their attempts to establish Internet connections during the outage actively rejected, rather than quietly dropped by your ISP. That will almost certainly cause them to use the globally-accessible prefix when it comes back up. You probably also need to do the same for RFC1918 and RFC3927 addresses on your IPv4 firewall... just in case.
> 1) ... When trying to connect to the public address from the inside, I face a firewal/config problem. Either I treat them as "outsider" and block/limit them incorrectly...
I'm fairly confused about why you need to treat them as an "outsider"? Same-subnet communications do not go through the router; hosts contact each other directly... so you're talking about firewalls running on each host, right? What are you doing to traffic destined to the globally-reachable address to treat it as an "outsider", and why? [0]
> 4) ... This is definitely a bug in the device, but now it is my problem.
How is this your problem? Your router won't have a route for traffic from that source address and will either drop or reject it... which is exactly the same as if a device erroneously retained an RFC1918 address in a subnet that isn't used on your LAN. [1] Are you seeing different behavior?
> 5) A variant of issue 4. is that some apple devices (TVs and similar) will just make up and start advertising their own ULA prefix.
That's pretty stupid behavior from the TV, but it's exactly the same sort of problem as the TV setting up a DHCP server on the LAN. It should not be doing that, and should be doing communications over the addresses already assigned to the interface (even the link-local address would work!). Do the RAs sent by the TV at least set the preference of the router to "low"? [2]
> Unless I control all devices on the network, I need to keep the advertised config very basic to keep everything working.
I'm curious about what things you put in the advertisement (other than DNS server) that didn't work.
> Split-brain DNS is an outdated concept, being broken every day by new tech.
Meh. Keep the TTL for your internal hostnames very low (60 seconds or less) and any problems you might have go away quickly. You're not serving a lot of DNS traffic, and it is all local, so the low TTLs won't be a problem.
[0] For services that I don't want to be Internet-reachable I either block the ports at the router (for things like NFS which cannot be bound to certain IPs), or I configure the daemon to listen on my ULA address. If you use "privacy" addresses, and the daemon doesn't permit bind addresses expressed as a subnet (e.g. fd06:0:0:1::/64), then this will probably be difficult to do. I recommend NOT using "privacy" addresses for your daemon-running machines.
[1] It's actually better than the typical "Apple devices fail to renew their DHCP lease on wake" situation with IPv4, as the chances of duplicate IP addresses (and resulting ARP/ND flapping) are effectively zero.
[2] Though, it's an Apple device, so I bet they set the preference to "high" and have an infinite lifetime for the prefix. XD
3) The ICMP rejects may help, that I did not test.
1) I run services which give you different permissions depending on wheter you are local. Think a fileshare which is RW internally and RO externally. Yes, you could - and often should - do it differently, but IPv6 limitations should not be the reason that force you.
4) If a device does not work when connected to my network, but works on other, than this is my problem. Good luck explaining that it's a device bug to anyone. If they even understand it, they are not gonna care.
This specific case is only a practical issue, when you have multiple networks interconnected, because the "correct" local prefix is always closer than the erroneously cached one. Besides, with a public-addr-only* network, this is not an issue.
5) Yes, it is stupid, but nobody is going to blame apple for the issues it causes to other devices. It's a problem with the network!
I have no idea about the RA preference, i filter them away on the switchport. I may check sometime.
> As for the advertisement contents:
That is a misunderstanding. I meant to keep the network configuration simple in general, (like no ULAs, no splitbrain DNS, ...) not specifically the RA contents.
But now that you mention it:
Android still does not support DHCPv6, so the "Other configuration" flag is a funny one.
I also put the PREF64 address in the RA for the NAT64, because apple devices require it. Android uses the ipv4only.arpa dns lookup instead. Isn't it lovely how consistently they behave?
> As for DNS:
Well, we completely disagree on this for multiple reasons:
- DNS over HTTPS and users connecting to other "privacy nameservers" or "adblocking nameservers" will not be solved by the low TTL
- Also 60 seconds is not an acceptable time for outage when nothing is phyisically broken
- That 60 seconds is often 300, because I have seen way to many recursors just extend TTL to a minimum of 5min. Again absolutely their fault and my problem.
[1] Just give them a "static lease" at the DHCP(v4) and it's never an issue again. Also, you should use DHCP-snooping (just like RA filtering) in switches all the time ;-)
*yes, there are still link-local addrs, but those are not used for any practical stuff, so it does not matter much.
Doesn't using ULAs kind of defeat the purpose (or one of the main intents) of IPv6, which is every device having a globally rotatable IP address? It kind of puts us right back in the IPv4 with NAT situation, only with longer, uglier addresses.
I personally think it is absurd that the ISPs that do actually support IPv6 are being so difficult and stingy about assigning static v6 prefixes.
IPv4/NAT is not the only "to get to system X you must pass through system Y" scenario.
Example: You have a bastion host that is Internet-accessible, and it has one or more server behind it you only want accessible "through" the bastion host. The bastion host might be running nginx and reverse proxying multiple servers behind it, and this host is doing caching in addition to WAF and some other stuff.
So this bastion host would have at least 2 NICs, one for the Internet-facing connection and one or more where servers exist on a non-public LAN. The small network(s) connecting these servers to the bastion host can use a ULA and thus be guaranteed to not be globally routable.
Link-locals are suboptimal because since they are link local, they only have to be unique per link. This means some commands insist you specify interface name with the LLA, e.g. fe80::aaaa%eth1.
But I have to admit, that I ended up buying my own IPv6 block from a local ISP and tunnel to them. They have great interconnections, so bandwidth is not an issue, and latency penalty is less then 2 ms an average.
TLDR: Turn the frequency of your RA-s waay up (3-5s) and their valid lifecycle way down (10-30s). There's still gonna be a hickup, but it should be tolerable.
The problem is I run my own DCHP server (mainly because I have stuff like PXE booting set up).
I can configure the ISC dhcpd for IPv6 but I wouldn’t know what prefix to use in any automated way. So whenever the modem disconnects/reconnects, for whatever reason, I then need to somehow manually update the DHCP server.
Not an issue for ipv4 with NAT. But enough of a problem with IPv6 that I gave up on it. However I do accept that this is a problem of my own making (ie not using ISP provided equipment).
You can run stateless DHCPv6, i.e., without handing out prefixes. It's a fairly normal situation that clients choose their own addresses from prefixes handed out via RA, but that they get auxiliary configuration (such as UEFI boot, or DNS servers before RDNSS was a thing) from DHCPv6. You'd probably need to make sure there was an RA on the network hinting about a DHCPv6 server (the “Other” flag), though.
For others who might be thinking about providing assistance, check this subthread to see if what you're thinking of suggesting has already been suggested: <https://news.ycombinator.com/item?id=44771590>
This is such a dumb problem with IPv6. Unless ISP stop being crappy and start offering static prefixes to regular residential subscribers, then I just don't see how v6 would ever be practical. This seems like a big oversight in the design and implementation of v6.
This guy cyber securities. Last thing I want are an infinite number of additional attack vectors on what will inevitably be a feeding frenzy of zero day exploits(not in the protocol but the implementation)
> Nowadays I consider IPv4 address scarcity almost a feature ...
The real godsend of IPv4 is that it accidentally forced NAT.
This saved, through the decades, hundreds of millions of vulnerable machines from being directly exposed and owned.
I consider IPv4 saved us from Windows botnets affecting nearly the entire world.
No, NAT is not security. But accidentally it prevented oh-so-many machines from getting owned.
When I got my first Internet connection I could literally access other people's Windows machine for my ISP was putting me on the same LAN as other people. I'd do silly things like have "Your Windows machine is insecure" printed on their printers. This was in IPv4 times: my ISP would put me on a subnet with 256 other machines (I'm talking about times where a 28.8 modem was still a thing btw).
I cannot being to imagine the total and complete chaos had IPv6 existed back then.
People don't understand how insecure and wild things were back in the days.
IPv4 saved the Internet, accidentally, thanks to NAT.
Thread was pretty much a greenfield deployment at the time, so it use of IPv6 was easy to specify. There was now legacy IPv4 to support or otherwise it would probably be a mess as well.
‘Considering the pool of available IPv4 addresses has been exhausted for quite a while now, and was running out for public use years ago’ I thought it was logical that most systems that have adopted IPv6. Crazy to think that it turns out it wasn’t, but shout out to apple and their stringent dev requirements bc they require support IPv6-only networks.
The pool is not exhausted, the IPv6 cabal realized after 20 years that actively fighting against freeing up more space was the only way they could drive adoption.
If we just stop listing 240/4 as a bogon we could be allocating from it in a few years.
If it’s for security then most of the actual security provided by NAT routing is actually just the routers firewall itself. So a good ipv6 firewall provides the same level of security.
If it’s just because you’re a bit of a control freak and like to manage the assignment of IP addresses (and I fall into that category too) then my understanding is that you can also do this with ipv6 as ISPs typically hand you a wider subnet range (unlike ipv4 where you get just 1 IP). However I’ve tried a couple of times to adopt ipv6 into my stupidly bespoke home networking stack and failed each time.
I really do want to adopt IPv6, if only because I like fiddling with tech, but, like yourself, I keep getting stuck on the “how do I integrate IPv6 into the infrastructure I already have” problem.
Edit: if anyone has any recommended guides to configuring IPv6 using ISC dhcpd and unknown addresses supplied by your ISP, then I’d be interested to read them.
To be clear, what you have is a router that's asking your ISP for a DHCPv6-PD prefix, assigning slices of that to one or more interfaces on that router, and what you want is for your dhcpd on that router to assign prefix-oblivious addresses to specific hosts on your LAN?
In other words, you want things to work like this?
If so, I'll poke around the docs to see if this is possible. I'm running both dhcpcd and ISC dhcpd on my LAN and have a hobbyist's experience with them.
But -honestly- what I've done is just relied on SLAAC to handle the globally-routable addresses, and advertised a ULA prefix for stable addresses. These go into my local DNS, but you could just as easily use that for DHCPd.
Not sure if this is what you were describing, but my dhcpd server is a separate machine to the router.
I’m just using an off the shelf
ASUS router because it’s actually surprisingly good at the basics. But I wanted PXE booting so set up ISC dhcpd on a home server.
To be fair, it might actually be possible to do this on my ASUS router. I’ve not actually checked. I’ve had the same setup up for years. Easily more than a decade. Only updating hardware when necessary. So I might be missing a trick with these latest ASUS routers.
> Not sure if this is what you were describing, but my dhcpd server is a separate machine to the router.
That was not what I was describing. I was figuring that your DHCPv6 client (that talks to your ISP) and your DHCPd would be on the same machine, but maybe that's okay. How does your dhcpd server get its address? A DHCPv6 request to the router? If so, the following report might (might!) be useful to you:
So, while I DID find out about dhcp-eval(5), it doesn't look to me like ISC DHCPd will do what you want. I didn't see any parameters documented in the dhcpd.conf manual that looked like they were prefix-independent.
Probably your best bet is to template your dhcpd.conf and known_hosts files, then use your network manager's [0] "on address change" hooks to fill in the currently-assigned prefix, write out new files, and bounce dhcpcd.
[0] NB: NOT (neccessarily) NetworkManager (that nasty, wretched thing), but maybe like dhcpcd's run hooks.
It’s hardcoded. For IPv4 it doesn’t need to be dynamic because NAT allows you to hardcode private address ranges. But that whole concept of networking doesn’t translate (no pun intended) to IPv6
This is the problem I’m running into with deploying IPv6. I don’t know what address ranges to allocate because the dhcp server doesn’t perform any handshakes with the ISP. And I’m a bit reluctant to rearchitect the network topology for IPv6 because everything already works really well without IPv6.
So ideally I’d want a way of sliding in IPv6 without having to break what’s already working.
Every solution I’ve explored thus far hasn’t achieved that. But there’s lots of good information shared here today so I’ll have another read and maybe they’ll offer up an insight I’d previously missed.
This allows me to have a mixture of both protocols and even some boxes that have both IPv4 and IPv6 addresses. I still have some issues writing routing rules that does not fail for link-local addresses, but the network has now been fully operational for well over a month.
Yeah, because you're gonna have to have a DHCPv6 client running on your router (and because your ISP is almost certainly using DHCPv6-PD the router is where you're pretty much going to have to first learn about your LAN-side DHCPv6 prefixes), it's probably going to be a bit tricky (but probably not impossible) to do what you want.
Best of luck. If you figure out how to do it within the HN comment freeze period (I think it's 14 days?), please do leave a follow-up comment. I'd be very interested in hearing what you come up with.
> If it’s for security then most of the actual security provided by NAT routing is actually just the routers firewall itself. So a good ipv6 firewall provides the same level of security.
Nitpicky, but I think this is not true. NAT's security is based on the router not knowing where to route the traffic and dropping it, where the firewall intentionally drops the traffic.
I think it is true... at least on Linux. I am pretty sure that if my firewall didn't have this line in the filter table
-A INPUT -i wan-interface -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
along with this line in the nat table (or the equivalent with the SNAT target if you have a static WAN IP)
-A POSTROUTING -o wan-interface -j MASQUERADE
then IPv4 NAT simply wouldn't work... well, not the NAT that nearly all regular folks have on their home networks.
It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0] But it's the decisions made in the firewall that both make the NAT work, and ensure that WAN traffic that hasn't been requested stays out.
[0] Unless the router were "excitingly" misconfigured!
The second line is the only one you need for NAT to work. The first is irrelevant to forwarded traffic. If you have no other rules then a) NAT will be applied to your outbound connections, and b) you'll have no firewall for the network behind the router.
NAT and firewalling might both done in netfilter via iptables/nftables rules, but they're completely orthogonal decisions. You can do either of them without the other.
> It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0]
Which means this is completely wrong. It won't do this unless you do something to make it do this (i.e. put some rules into FORWARD that control what traffic is/isn't allowed). MASQUERADE just changes the source IP on outbound connections; it doesn't drop inbound connections.
> [0] Unless the router were "excitingly" misconfigured!
This is probably the pivotal difference lol. Most of the ISP-provided routers I've used either have a default-allow policy or auto-create firewall rules when you add a NAT forwarding rule. I don't honestly recall which because it's been like a decade, but I do remember that I didn't have to explicitly add a firewall rule.
The exciting misconfiguration I was thinking of was one where Internet hosts could send packets to the router with LAN IPs as the destination IP and the router would happily forward those along and output them on the LAN interface(s).
On a Linux router, perhaps setting ip_forward to 1 and leaving rp_filter at 0 would do the trick? It has been ages since I've had to play with rp_filter, so I can't remember exactly what its behavior is.
> NAT's security is based on the router not knowing where to route the traffic and dropping it
Nope, the router does know where to route the traffic for obvious reasons. At least for Linux if it's able to do NAT then it's ipso facto able to forward packets from one interface to another, and will do so unless explicitly told not to.
NAT requires a stateful firewall too. In fact all router firewalls are stateful otherwise you’d have to have large ranges of ports permanently open to incoming connections.
So you don’t actually need anything different nor special to have the same level of security with IPv6 vs IPv4 + NAT.
Yes, you’re repeating what I’m saying. NAT forced router vendors to implement stateful connection tracking and it increased the security of everything behind them.
> So you don’t actually need anything different nor special to have the same level of security with IPv6 vs IPv4 + NAT.
This isn’t how it played out in practice though. Huge swaths of home routers had no firewall at all when you enabled IPv6 support because it would have taken slightly extra work to enable the v6 conn tracking.
I think enough consumer routers run upnp servers out of the box that relying on NAT as a firewall is very unreliable. Have a look at upnp state table on your router, you might be surprised at things that have poked holes for the whole world to hammer at without you noticing.
UPNP is not enabled by default on my router nor has it been on the last few. I think that was common like 15 years ago before all of the gaming consoles figured out how to do STUN on their own.
It's an imaginary firewall. NAT won't stop unsolicited connections in to your network -- if anything, its entire purpose is to do the exact opposite of that.
If you actually want to block inbound connections when you're doing NAT, you need the stateful firewall anyway. At that point, pretty much the only thing NAT is doing for your security is making it harder to understand what's going on.
When I was on an ISP with DS-Lite the IPv4 functionality regularly failed because the AFTR's port mapping saturated (equivalent to reaching ip_conntrack_max on linux). IPv6 wasn't affected since it doesn't involve a stateful middlebox that I don't control.
I've had "native" IPv6 service for something like twenty years. I've not had a problem with accessing any of the internet.
If you're hinting that roughly half of the internet-connected servers don't have IPv6 addresses, then my reply is "so what?". Only idiots are suggesting that folks who aren't running an experimental lab (or ISPs that have the expertise required to set up the NATs needed to reach the IPv4 internet from v6-only service) go IPv6-only.
I think they did in fact mean IPv6-only hosts. For instance, you can save some money getting a virtual box on Hetzner that doesn't have IPv4 connectivity. Of course, that box won't be able to talk to ex. github, so for some people it's really not worth it.
Yes, it makes a difference: about 8 milliseconds.
Properly implemented IPv6 has a lower latency.
(and is more efficient, though i believe the energy savings are negligible)
See this map: https://stats.labs.apnic.net/v6perf
Out of curiosity, I had a look at one of our service's login nodes, to see where SSH connections were originating from off-campus. What I found was that approximately 30% were over IPv6.
Anecdotally, during weekday working hours, the percentage of IPv6 is higher than (typically over 50%).
I recently switched ISP to one that supports IPv6 and I have had nothing but problems. I have had DNS servers going missing from OpenDNS, I have seen all sorts of really weird routing errors and transient problems, its barely usable at all. Linux seems to be more strict about how it handles IPv6 and I found my server couldn't find its upgrade packages because some of their mirrors are broken for IPv6 routing. All in all it was a mess and I turned it off. My ISP must be partially at fault but it was clear Debian was too as was OpenDNS and most of my problems no one could explain what was happening or why.
Not sure what specifically happened in your case, but FWIW... My ISP (Spectrum, previously Time Warner) has supported IPv6 at my location for a decade or more now. And I have been running with IPv6 enabled on my router, and on all my Linux boxen, and have had approximately zero problems related to IPv6 in that time. During that time I've had boxes running various Fedora versions, and PopOS and both have handled IPv6 just fine.
> I recently switched ISP to one that supports IPv6 and I have had nothing but problems.
I was previously with an ISP that support IPv6 and had zero problems.
In fact IPv6 worked "too well" at one point: I had put "facebook.com" in my /etc/hosts file pointing to 0.0.0.0 at one point to reduce tracking. I then noticed I got the little FB icons again at some point and couldn't figure out why things were 'broken' (i.e., not blocking).
Turned out that after IPv6 was enabled I had to add ::1. That blocked FB again. IPv6 made connectivity to FB work again.
Does running `ip link set mtu 1280 dev eth0` on the client machine fix it?
A lot of servers have somehow managed to screw up their path MTU discovery. People have been using client-side workarounds for this for many years, but I suspect the workarounds are often forgotten on v6. Unfortunately the resulting problems then get blamed on v6.
The other possibility is broken multicast on your local network. Some Wifi mesh APs and "range extenders" just don't work properly. The test for this would probably be to take them out of the network path by connecting directly to the main router via Ethernet and seeing if you can talk to Internet hosts properly.
I couldn't say what your issues are, but I have been on ipv6 (dual stack) on Comcast for over a decade and have had none of those problems. I've always had open source routers and plenty of Linux scattered around the house.
Hehe, it's kind of funny to contrast the IPv6 evangelists and the Linux desktop evangelists push hard for adoption, only for it to fall flat for ordinary users.
When an ISP assigns an IPv6 prefix, home networks / homelabs can use that prefix for internal addressing. But if the ISP later changes the prefix, all internal devices using the old addresses break. This makes the concept of globally unique IPv6 addresses seem problematic for end-users. Is there something I’m misunderstanding about how this is supposed to work?
I recently decided that it was high time to stop ignoring IPv6 after 30 years of computing and actually learn how it is supposed to work.
So I started digging in, and there's definitely a lot to like.
But I see two big problems that are showstoppers in my opinion, at least for my home network (not even considering the fact that very few residential ISPs even support v6 at this point):
1. Generally speaking, the IPs of your LAN are based on the prefix assigned by the ISP. Most residential ISPs don't offer static prefixes. This means that every time your prefix changes, the IPs of all your devices on your LAN change. Seems like this "feature" was developed in a more idealistic era when people probably thought everyone would be getting static IPv6 addresses, since shortages would never be an issue. Unfortuantely, they failed to foresee the fact that most major ISPs are terrible, greedy organizations that either outright refuse to offer static assignments, or continue treating them as if they were scarce IPv4 resources, charging a premium or requiring business-class service to even get them.
2. The ISPs that do support v6, like Comcast/Xfinity in the USA, are only allocating one /64 prefix. This means you can only have one subnet (VLAN) on your LAN! Why are they being so stingy?
I would love to migrate to IPv6, but these two issues alone make it feel like a clown show for home users.
Couple of things - if you want prefixes to stay the same you can use ULAs for your home network. Not ideal but it's available. The 'right' way to manage this is to use DNS, and just have the prefixes auto-update there, or mDNS. For prefix sizes you should be getting a /56 most of the time, especially from major US ISPs. If you're getting a single /64 it's almost definitely an issue with your router's PD setup.
Yeah, I know about the workarounds, but that just kind of defeats the purpose for me. Also, I've read comments from folks stating they were having a hard time getting a larger prefix from Comcast using PD... don't know how universally true that is.
Using DNS to resolve everything solves part of the problem, but firewall rules are another issue. The router would need to have the capability to update everything dynamically when the prefix changes. I think this in the works for pfSense, but I'm not sure if its actually supported yet. It looks like you might have to mess around with some 3rd-party script to make it work.
I guess I'm just generally disappointed that the whole process seems unnecessarily messy. I don't have a v6-compatible ISP right now anyway. I was thinking about trying a tunnel, but I'm not seeing the benefit in it right now.
Yeah, this is the constant problem with IPv6: it's a much better design than IPv4, it's simpler to understand, and it should be theoretically much easier to use, but the tooling is all so terrible that it's often easier to just use IPv4. Which is too bad, because so many of the problems with IPv4 completely go away when you use IPv6, but right now we're stuck with dual-stack, which just doubles the amount of work to set everything up.
1. nftables supports NPTv6 (Network Prefix Translation), which is similar to NAT, except it's stateless and every device remains individually addressable. So you can configure your DHCPv6/SLAAC to assign to each device both an address from your globally-routable prefix and from your ULA prefix, and then NPTv6 will handle mapping your ULA prefix to/from the internet.
2. Lots of ISPs only assign a /64 by default, but if you configure your router to request a /56 via DHCPv6 prefix delegation, you'll usually get the larger prefix.
FWIW, I'm using both of these on my home network, via a router running OpenWRT.
Thanks, I appreciate your explanation. I was aware that there are workarounds, but to me that defeats one of the core tenants of IPv6, which is that we're supposed to be doing away with this NAT and NAT-like nonsense by giving everything a globally rotatable IP.
When I was reading up on everything, I also learned that your router can request a bigger prefix, but I ran across several posts from various folks stating they could only get a /64 from Comcast no matter what they tried, so I'm not sure how universally supported DHCPv6-PD requests are.
> I was aware that there are workarounds, but to me that defeats one of the core tenants of IPv6, which is that we're supposed to be doing away with this NAT and NAT-like nonsense by giving everything a globally rotatable IP.
The nice thing with IPv6 is that devices have no problem with being assigned multiple addresses on the same interface. So most of my devices actually have 5 IPv6 addresses [0]: a globally-routable DHCPv6 address (the default), a globally-routable SLAAC address, a ULA DHCPv6 address, a ULA SLAAC address, and a link-local address. So you can have a globally-routable IP and a locally-stable IP at the same time. And this is arguably a good thing, since it would be annoying to have to renumber your local network if you ever changed ISPs.
> I ran across several posts from various folks stating they could only get a /64 from Comcast no matter what they tried, so I'm not sure how universally supported DHCPv6-PD requests are.
That's annoying, and also means that you probably won't be able to get NPT to work either. FWIW, both Shaw and Telus (in Canada) will assign you a /56 via DHCPv6-PD if you request it.
[0]: I don't actually want this many addresses, but a link-local address is required for IPv6, I want my devices to have constant/easily-memorable IP addresses so I need DHCPv6, Android only supports SLAAC so I have to keep that enabled too, devices will prefer IPv4 over a v6 ULA so I need to keep the globally-routable addresses, and I want to use static addresses in my LAN so I need ULA enabled as well.
When I bought a new gaming PC recently it default configured on my home network with IPv6 but not IPv4. It was interesting which features Microsoft considers crucial (and so worked on IPv6) and which were not important (and so they just didn't function, claiming that there's no Internet even though of course there is and e.g Google works)
Advertising for example, was essential. Spewing garbage I don't want, absolutely critical to Microsoft's bottom line apparently. But registration so that I can turn off that advertising? Not important, so that was not available until I gave the machine IPv4.
Work is exclusively IPv4 and nobody's talking about changing. Everything at home is IPv4 and I'm not even curious about IPv6. When I have to be, I'll figure it out. Until then, things seem to be working fine.
> I think IPv6 should have been 8 bytes instead of 16
You don't state why you think this, but this is almost always due to the flawed thinking that the IP address is a simple identifier, and then looking at "how many IPs does the world need?" → "64 bits is enough". (IPs are like street addresses, in that they're routing instructions. Having the space not fragment — like v4's space is doing — is part of it, and helps things like routing tables remain small.)
> and somewhat backward compatible with IPv4.
The pigeon-hole principle makes backwards compatibility impossible. No matter what concrete scheme you might propose, it is effectively equivalent to IPv6.
8 versus 16 bytes barely matters for using the addresses, especially because if you're assigning IPs to your devices you can have the second half of the address start with 6-7 zero bytes and collapse them all with ::
And I challenge you to name a way to be "somewhat backward compatible" that would actually function and IPv6 doesn't already do.
The design of IPv6 is for computers, not for humans. How do you even say an IPv6 address aloud? You need to be able to communicate "192 dot 168 dot 50 dot 1" over a voice medium.
That has very little to do with 8 versus 16 bytes.
Edit: And not only can you make your own addresses short, if I look up some IPv6 addresses meant to be said/remembered (public DNS IPs), none of them make you type more than 8 bytes (and that one repeats a cluster to make it easier) and some make you type as little as 4 bytes.
The extra space means you never have to calculate subnet sizes and you can let devices handle their own IPs. I think that's a pretty good tradeoff.
64 bits are already a pain in the ass to remember, and if you have specific memorization needs you can use small static IPs so that even with 128 bits available you only use about 64 of them.
It's a good strategy if deploying a bigger address space is easy and cheap. When it's incredibly difficult and time consuming, you should pause and consider a bit more carefully.
New L3 protocols on the Internet are firmly on the "incredibly difficult and time consuming" side.
Diceware is way easier to share over the phone than any IPv6 address (except for the few vanity ones like Google's 2001:4860:4860::8888 — then it's only slightly easier).
It's not just you, I completely agree. 128-bit addresses are overkill. 64-bit would have been fine, and yes, backwards-compatible would have gotten us there that much sooner. For me, it's a deal-breaker that I can't reasonably speak an IPv6 address aloud (for instance when doing tech support over the phone).
Overkill is good! It's impossible to get the size exactly correct; your only options are "too small" or "too big". Given how difficult it is to deploy a new L3 protocol, why wouldn't we pick the size that ensures we don't have to turn around and do it again immediately afterwards?
> backwards-compatible would have gotten us there that much sooner
v6 is already backwards compatible. Between dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6 and probably other things I'm forgetting, you could make a reasonable argument that it's too backwards compatible, even.
If you meant "v4 being forwards-compatible would have gotten us there sooner", then yes, I agree. It's unfortunate it's not. That's entirely v4's fault though, not v6's.
How does your backwards-compatibility dream handle ASICs built to handle only IPv4 and shitty middleboxes hard-coded to drop or -worse- mangle any IP traffic that doesn't fit a particular subset of what's permissible for IPv4?
Google and other big players go to huge lengths to build new Internet protocols on top of UDP because enough of the internet drops or mangles anything other than TCP or UDP that it's effectively impossible to use anything else on the Greater Internet. IPvNext by way of backwards-compatible IPv4 was (and continues to be) no easier than doing something that's backwards-incompatible.
As a bonus, doing the backwards-incompatible thing bypasses all the bad behavior of existing shitty middleboxes and crummy ASICs.
There is literally no way to get more than 4 bytes of address space out of midleware routers that limit the addresses to 4 bytes. There is no way to make that backwards compatible.
You aren't supposed to be manually assigning addresses except in very small networks. You should have that centrally managed by DNS or any number of other things. No one should have to speak their address to you. You don't know what you're doing.
I suspect the thinking is that all of IPv4 could have been a contained within the IPv6 space. Perhaps at at the very beginning or very end of it.
Any time you would reference an IPv4 address when v6 enabled, the stack would simply fill in the remaining bits and forward your packets down the line.
This had to have been thought about though, and I suspect the architects of v6 felt it would've been sub-par to what we have. No idea if that's true though.
> I suspect the thinking is that all of IPv4 could have been a contained within the IPv6 space. Perhaps at at the very beginning or very end of it.
They actually went with 64:ff9b::/96 as the default (though IPv6 is so big that you can just pick another area if you want in ULA space or whatever).
> Any time you would reference an IPv4 address when v6 enabled, the stack would simply fill in the remaining bits and forward your packets down the line.
There are actually multiple implementations, depending on OS and whether you want it in kernel space or user space.
> This had to have been thought about though, and I suspect the architects of v6 felt it would've been sub-par to what we have. No idea if that's true though.
::ffff:0:0/96 IPv6-mapped
This space is intended for an OS or network stack to map IPv4 addresses towards higher layers, so applications could technically be IPv6 only. The packet was/will be standard IPv4 when it reaches the network wire.
::/96 and ::ffff:0:0:0/96 IPv6-compatible/IPv6-mapped
These were originally intended to be used on networks to differentiate IPv4 addresses depending on the capability of the target and decide who will do the translation. These are now deprecated, but the whole ::/8 is reserved, and these addresses are promised to never be assigned to anything else.
64:ff9b::/96 IPv6-translated
This is the space for IPv6 to IPv4 NAT translators. Actually the whole /48 is reserved, so you can run address multiple private translators in a single network if required. This is widely used and supported.
As a side note Teredo addresses (2001::/32) and 6to4 addresses (2002::/16) all embed the entire IPv4 address space, although they are more complex than a simple 1-to-1 mapping. They are rarely used.
Problem always is how to get packet back. The IPv4 host can get packet from somewhere. But if it simply does not have enough bits to represent the return address it cannot send packet back that actually arrives. Unless you do something like NAT that is get help form something on the way. And that something then has to keep track of whatever was done.
So get out there and p2p
This was considered likely when IPng was being discussed in 1990s:
* https://datatracker.ietf.org/doc/html/rfc1726#section-5.5Please explain
If I have a bunch of servers and want them to be accessible by the internet, I can use SNI and let them all share a single IP, again with no special action required by those connecting.
With IPv6, it doesn't solve case 1 until all the servers on the internet support IPv6. AFAIK it doesn't support case 2 either, because you would need some way to route an incoming IPv4 connection to the right IPv6 server. IDK maybe there's a way.
For case 2, a dual-stack reverse-proxy will do the job and can talk to the IPv6-only servers without issue.
If I want to use IPv6 to solve my IPv4 address shortage problem, and I want to communicate with you, I have to wait for you to also install IPv6.
SNI isn't really the same thing. For one thing it has actual positive benefits, very much unlike NAT (and no NAT is not a fucking security feature and is orthogonal to fucking firewalls don't make me come over there). And for me to use SNI, your browser (or whatever) has to send SNI, so it's still a change on only one end. But it still does let me put more than one service on a single IP address, and you only have to upgrade one program, probably a program you were going to upgrade anyway, rather than change your whole networking structure.
The way this should have worked was that IPv4 should have been turned off completely in the public Internet around 1997 or 1998. But ISPs didn't want to tell the much smaller number of much more sophisticated admins back then that they had to, you know, change things. So people just kept baking IPv4 into more and more things, and throwing in more and more NAT, and not even bothering learn or teach IPv6... and ignoring all the things they were breaking.
Many (not all!) of the things they were breaking were things that really came into play if you were trying to do P2P. Like, for instance, the ability to, you know, actually make a connection to any random peer. There are hacks, but they work poorly when they work at all. So since NAT was everywere, P2P didn't have a chance. There were other forces at work too, but basically everybody's business model and expectations gelled around centralization in a way that might have had a chance of not happening if there hadn't been NAT all over the place.
is this about the meaning of the term "NAT"? because of course it is a security feature if something is offline by default
Or you set up DNS64/NAT64/464XLAT on your IPv6 end of things, and those on IPv4 side don't have to do anything.
Skype was originally P2P, but because of NAT there had to exist "supernodes" which did STUN/TURN/ICE shenanigans to make it work (which caused scaling issues since there weren't enough of them):
* https://spectrum.ieee.org/skype-scuppered-by-problem-with-su...
* https://www.zdnet.com/article/skype-ditched-peer-to-peer-sup...
Sure ipv6 has some better features, but dual-stack means you are doubling all of your config (ACLs, naming, firewalls, routing) test cases and vulnerability surface. Moreover, ipv6 is not as intuitive.
Shaming people into ipv6 will never work. More effort should be invested into best practices, patterns, migration guides, support communities & more to assist in operating in a dual-stack environment for the foreseeable future.
Pure ipv6 will never happen because the weak link breaks the chain. How many people set up an ipv6 VPC with great excitement, and late in the project they deploy from github with "NS lookup failed".
Define "pure". Jen Linkova has been running IPv6-only networks on Google's corporate networks for several years now:
* https://www.youtube.com/watch?v=UTRsi6mbAWM
She is a chair of the 6man WG (and involved in the v6ops WG), and has authored ten RFCs:
* https://datatracker.ietf.org/person/furry13@gmail.com
Microsoft also is IPv6-only on corporate networks (so more of their IPv4 addresses can be moved to Azure to produce revenue):
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
The author of that article, Veronika McKillop, is head of the UK IPv6 Council:
* https://www.youtube.com/@ukipv6council468/videos
where you'll find lots of videos on ISPs and other institutions doing IPv6-only or IPv6-mostly (especially nowadays with DHCPv4 Option 108, RFC 8925).
You're not selling me on it's viability.
> So IPv6 is about 30 years old, and the testimony being shared is the chair of the group spending years of research and millions of dollars, finally launching ipv6 corporate lans in 2023.
And how many years of research and millions of dollars was spent in the 1990s on IPv4? People used to use workstations as routers (e.g., see SunOS routeadm(1M)) and DNS caching servers before a lot of money was poured into ASICs for routing (and switching).
There are all sorts of dumbass things with IPv4: how much time has been wasted on engineering solutions around NAT (e.g., STUN/TURN/ICE)? But because IPv4 just happens to be the default we accept them as 'normal' and anything that is different is treated as 'abnormal'.
> You're not selling me on it's viability.
I'm not sure how it's not viable given there are mobile telco networks with tens (hundreds?) of millions of people getting only IPv6 addresses on their devices.
* https://www.youtube.com/watch?v=nNMNglk_CvE
* https://www.youtube.com/watch?v=QGbxCKAqNUE
There are some folks who (a) were lucky enough to get in early on the IPv4 address land rush, or (b) are rich enough to be able to purchase IPv4 addresses, but there are also (c) plenty of folks who are left with scraps for IPv4 connectivity. The fact that you happen to fall into (a) or (b) does not mean you get to dismiss the folks in (c) who need IPv6, as otherwise they'd have no connectivity at all.
It's not even double the config. For e.g. my firewall, which is a 300-line config that I've already designed and implemented, making it dual stack mostly involves writing "domain (ip ip6)" instead of "domain ip". That's simply not double.
It's not less intuitive than v4 either. That's a lack of experience talking. Meanwhile, trying to use v4 quickly devolves into needing to use NAT, which is less intuitive.
> Pure ipv6 will never happen because the weak link breaks the chain. How many people set up an ipv6 VPC with great excitement, and late in the project they deploy from github with "NS lookup failed".
My desktop is pure v6 and GitHub works fine, which I think disproves the "never" part.
Hurricane Electric (for one) offers IPv6 tunnels:
* https://ipv6.he.net
You can configure it on your router:
* https://openwrt.org/docs/guide-user/network/ipv6/ipv6_henet
* https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunn...
* https://docs.opnsense.org/manual/how-tos/ipv6_tunnelbroker.h...
Or an individual host:
* https://wiki.archlinux.org/title/IPv6_tunnel_broker_setup
* https://docs.rockylinux.org/guides/network/hurricane_electri...
* https://genneko.github.io/playing-with-bsd/networking/freebs...
1: I'd prefer to have stayed with the local ISP despite the lack of ipv6, but they wanted $8,000 to bring fiber to my new place and that was not worth it with at&t fiber being present.
(It also happens to be a fantastic filter for spammers and other abusers. Is it perfect? Hell no. But it is very good.)
I bet if someone made something in between, it might become at least a little popular.
Still works by the way!
- Cloudflare won't route to them. - Streaming services, such as Netflix, block them - They trigger extra validation all over the Internet
I used to have these on select hosts on my network and it was never a good experience.
That said, if it isn’t blocked for the services you use, I found it pretty straightforward to use.
Tried explaining it to several customer support techs but they all just gave up eventually.
Was fixed when I ended up getting my own modem and router/AP.
But those were an interesting few days. My partner was annoyed they couldn't use Pinterest but YouTube loaded fine. Google search worked but our local pizza joint's site didn't.
It had very little benefits at the beginning, but having dedicated publicly routed addresses started to become really conevinent.
IPv6 with a regulary changing dynamic prefix still sucks though to this day ... :-(
The (occasionally, on Comcast) changing dynamic prefix was a pain for me too, when accessing things externally. For internal use I additionally set up a fixed ULA prefix.
The way I do this, my internal DNS resolves hosts to their fixed ULA addresses. For the handful that are accessible externally, public DNS resolves to their address on the current public prefix.
* https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc672...
That draft doc seems to fix multiple problems at once.
What did this fight look like? For the past fifteen, twenty years, I have NATted IPv4, globally-routable IPv6, and ULA IPv6 addresses on all of my machines attached to the internet-accessible VLANs on my LAN. The only trouble I've noticed was when ISP maintenance caused me to lose the globally-routable prefix for a little while and my franken-router started passing ULA traffic out the WAN interface. [0]
I'd love to hear what you've been seeing, so I can see if there's trouble that I've been overlooking.
> ...unique-local addresses are deprecated as far as I know.
ULAs are not deprecated. You may be thinking of site-local addresses. See the first paragraph of section 1 here: [1]
[0] The obvious firewall rule fixed that.
[1] <https://www.ietf.org/archive/id/draft-ietf-v6ops-ula-usage-c...>
When trying to connect to ULA from outside, that's not going to work.
When trying to connect to the public address from the inside, I face a firewal/config problem. Either I treat them as "outsider" and block/limit them incorrectly, or I need to dynamically update the setup to know what is internal.
2) DNS over HTTPS: which is forced by more and more things by default. They will always resolve to the outside address, even when on the local network. Causing the same problem as caching.
3) Source addr selection "stuck" on ULAs: When I loose the public prefix for a brief period, things tend to start using the ULA as a source for public destinations. This is not going to work as expected. However, when I get a new prefix, some things tend to be stuck for a long time on trying to use the ULA instead of using the new prefix.
4) I've seen devices incorrectly keep a ULA address from a different network, and attempting to use that on mine. This is definitely a bug in the device, but now it is my problem.
5) A variant of issue 4. is that some apple devices (TVs and similar) will just make up and start advertising their own ULA prefix. This is related to Matter support.
They should detect that there is already a ULA prefix and use that, but this detection is far from perfect, so sometimes they just do it anyway. Now my whole network has two ULAs. All devices should still use their "nearest" address to communicate, but - bugs again - sometimes they don't do that.
But hey, apple provides me with free pentesting to see if I have the RA filtering correctly setup in switches :-)
---
The list goes on, this is just what came to my mind immediately. There are really 3 conclusions I came to:
- Split-brain DNS is an outdated concept, being broken every day by new tech. You can't rely on the devices talking to the specific NS you want.
- There are a lot of buggy IPv6 implementations out there. Unless I control all devices on the network, I need to keep the advertised config very basic to keep everything working.
- Dual-stack and happy-eyeballs hide these issues too well. It is hard to detect and report them. Even if you do, vendors often just don't care or bother fixing because the issues do not have an immediate impact.
So, I think #3 will be solved by rejecting traffic from fc00::/7 that's going to be routed out the router's WAN interface. To do this on my network, I have this on the 'filter' table of my router firewall:
This should cause machines that attempt to use the only valid prefix during the outage to have their attempts to establish Internet connections during the outage actively rejected, rather than quietly dropped by your ISP. That will almost certainly cause them to use the globally-accessible prefix when it comes back up. You probably also need to do the same for RFC1918 and RFC3927 addresses on your IPv4 firewall... just in case.> 1) ... When trying to connect to the public address from the inside, I face a firewal/config problem. Either I treat them as "outsider" and block/limit them incorrectly...
I'm fairly confused about why you need to treat them as an "outsider"? Same-subnet communications do not go through the router; hosts contact each other directly... so you're talking about firewalls running on each host, right? What are you doing to traffic destined to the globally-reachable address to treat it as an "outsider", and why? [0]
> 4) ... This is definitely a bug in the device, but now it is my problem.
How is this your problem? Your router won't have a route for traffic from that source address and will either drop or reject it... which is exactly the same as if a device erroneously retained an RFC1918 address in a subnet that isn't used on your LAN. [1] Are you seeing different behavior?
> 5) A variant of issue 4. is that some apple devices (TVs and similar) will just make up and start advertising their own ULA prefix.
That's pretty stupid behavior from the TV, but it's exactly the same sort of problem as the TV setting up a DHCP server on the LAN. It should not be doing that, and should be doing communications over the addresses already assigned to the interface (even the link-local address would work!). Do the RAs sent by the TV at least set the preference of the router to "low"? [2]
> Unless I control all devices on the network, I need to keep the advertised config very basic to keep everything working.
I'm curious about what things you put in the advertisement (other than DNS server) that didn't work.
> Split-brain DNS is an outdated concept, being broken every day by new tech.
Meh. Keep the TTL for your internal hostnames very low (60 seconds or less) and any problems you might have go away quickly. You're not serving a lot of DNS traffic, and it is all local, so the low TTLs won't be a problem.
[0] For services that I don't want to be Internet-reachable I either block the ports at the router (for things like NFS which cannot be bound to certain IPs), or I configure the daemon to listen on my ULA address. If you use "privacy" addresses, and the daemon doesn't permit bind addresses expressed as a subnet (e.g. fd06:0:0:1::/64), then this will probably be difficult to do. I recommend NOT using "privacy" addresses for your daemon-running machines.
[1] It's actually better than the typical "Apple devices fail to renew their DHCP lease on wake" situation with IPv4, as the chances of duplicate IP addresses (and resulting ARP/ND flapping) are effectively zero.
[2] Though, it's an Apple device, so I bet they set the preference to "high" and have an infinite lifetime for the prefix. XD
1) I run services which give you different permissions depending on wheter you are local. Think a fileshare which is RW internally and RO externally. Yes, you could - and often should - do it differently, but IPv6 limitations should not be the reason that force you.
4) If a device does not work when connected to my network, but works on other, than this is my problem. Good luck explaining that it's a device bug to anyone. If they even understand it, they are not gonna care.
This specific case is only a practical issue, when you have multiple networks interconnected, because the "correct" local prefix is always closer than the erroneously cached one. Besides, with a public-addr-only* network, this is not an issue.
5) Yes, it is stupid, but nobody is going to blame apple for the issues it causes to other devices. It's a problem with the network!
I have no idea about the RA preference, i filter them away on the switchport. I may check sometime.
> As for the advertisement contents:
That is a misunderstanding. I meant to keep the network configuration simple in general, (like no ULAs, no splitbrain DNS, ...) not specifically the RA contents.
But now that you mention it: Android still does not support DHCPv6, so the "Other configuration" flag is a funny one. I also put the PREF64 address in the RA for the NAT64, because apple devices require it. Android uses the ipv4only.arpa dns lookup instead. Isn't it lovely how consistently they behave?
> As for DNS:
Well, we completely disagree on this for multiple reasons: - DNS over HTTPS and users connecting to other "privacy nameservers" or "adblocking nameservers" will not be solved by the low TTL - Also 60 seconds is not an acceptable time for outage when nothing is phyisically broken - That 60 seconds is often 300, because I have seen way to many recursors just extend TTL to a minimum of 5min. Again absolutely their fault and my problem.
[1] Just give them a "static lease" at the DHCP(v4) and it's never an issue again. Also, you should use DHCP-snooping (just like RA filtering) in switches all the time ;-)
*yes, there are still link-local addrs, but those are not used for any practical stuff, so it does not matter much.
I personally think it is absurd that the ISPs that do actually support IPv6 are being so difficult and stingy about assigning static v6 prefixes.
Example: You have a bastion host that is Internet-accessible, and it has one or more server behind it you only want accessible "through" the bastion host. The bastion host might be running nginx and reverse proxying multiple servers behind it, and this host is doing caching in addition to WAF and some other stuff.
So this bastion host would have at least 2 NICs, one for the Internet-facing connection and one or more where servers exist on a non-public LAN. The small network(s) connecting these servers to the bastion host can use a ULA and thus be guaranteed to not be globally routable.
Link-locals are suboptimal because since they are link local, they only have to be unique per link. This means some commands insist you specify interface name with the LLA, e.g. fe80::aaaa%eth1.
* https://datatracker.ietf.org/doc/html/rfc8978
And "Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events":
* https://datatracker.ietf.org/doc/html/rfc9096
Also maybe "IPv6 Multihoming without Network Address Translation":
* https://datatracker.ietf.org/doc/html/rfc7157
Lots of good presentation at the IETF meeting for the 6man and 6ops WGs.
But I have to admit, that I ended up buying my own IPv6 block from a local ISP and tunnel to them. They have great interconnections, so bandwidth is not an issue, and latency penalty is less then 2 ms an average.
I’ll have a proper read of that tomorrow morning :)
You just update the IP (or just the prefix) when the IP changes
Perhaps keep in mind that the interface id of the device the DNS entry should point is different for every device in the network.
Some use the router to update the IP and put the interface id of the router into the update url...
I can configure the ISC dhcpd for IPv6 but I wouldn’t know what prefix to use in any automated way. So whenever the modem disconnects/reconnects, for whatever reason, I then need to somehow manually update the DHCP server.
Not an issue for ipv4 with NAT. But enough of a problem with IPv6 that I gave up on it. However I do accept that this is a problem of my own making (ie not using ISP provided equipment).
If you need IPv6 on Android, your only option is SLAAC.
https://www.google.com/intl/en/ipv6/statistics.html
The real godsend of IPv4 is that it accidentally forced NAT.
This saved, through the decades, hundreds of millions of vulnerable machines from being directly exposed and owned.
I consider IPv4 saved us from Windows botnets affecting nearly the entire world.
No, NAT is not security. But accidentally it prevented oh-so-many machines from getting owned.
When I got my first Internet connection I could literally access other people's Windows machine for my ISP was putting me on the same LAN as other people. I'd do silly things like have "Your Windows machine is insecure" printed on their printers. This was in IPv4 times: my ISP would put me on a subnet with 256 other machines (I'm talking about times where a 28.8 modem was still a thing btw).
I cannot being to imagine the total and complete chaos had IPv6 existed back then.
People don't understand how insecure and wild things were back in the days.
IPv4 saved the Internet, accidentally, thanks to NAT.
If we just stop listing 240/4 as a bogon we could be allocating from it in a few years.
If it’s for security then most of the actual security provided by NAT routing is actually just the routers firewall itself. So a good ipv6 firewall provides the same level of security.
If it’s just because you’re a bit of a control freak and like to manage the assignment of IP addresses (and I fall into that category too) then my understanding is that you can also do this with ipv6 as ISPs typically hand you a wider subnet range (unlike ipv4 where you get just 1 IP). However I’ve tried a couple of times to adopt ipv6 into my stupidly bespoke home networking stack and failed each time.
I really do want to adopt IPv6, if only because I like fiddling with tech, but, like yourself, I keep getting stuck on the “how do I integrate IPv6 into the infrastructure I already have” problem.
Edit: if anyone has any recommended guides to configuring IPv6 using ISC dhcpd and unknown addresses supplied by your ISP, then I’d be interested to read them.
In other words, you want things to work like this?
If so, I'll poke around the docs to see if this is possible. I'm running both dhcpcd and ISC dhcpd on my LAN and have a hobbyist's experience with them.But -honestly- what I've done is just relied on SLAAC to handle the globally-routable addresses, and advertised a ULA prefix for stable addresses. These go into my local DNS, but you could just as easily use that for DHCPd.
I’m just using an off the shelf ASUS router because it’s actually surprisingly good at the basics. But I wanted PXE booting so set up ISC dhcpd on a home server.
To be fair, it might actually be possible to do this on my ASUS router. I’ve not actually checked. I’ve had the same setup up for years. Easily more than a decade. Only updating hardware when necessary. So I might be missing a trick with these latest ASUS routers.
That was not what I was describing. I was figuring that your DHCPv6 client (that talks to your ISP) and your DHCPd would be on the same machine, but maybe that's okay. How does your dhcpd server get its address? A DHCPv6 request to the router? If so, the following report might (might!) be useful to you:
So, while I DID find out about dhcp-eval(5), it doesn't look to me like ISC DHCPd will do what you want. I didn't see any parameters documented in the dhcpd.conf manual that looked like they were prefix-independent.
Probably your best bet is to template your dhcpd.conf and known_hosts files, then use your network manager's [0] "on address change" hooks to fill in the currently-assigned prefix, write out new files, and bounce dhcpcd.
[0] NB: NOT (neccessarily) NetworkManager (that nasty, wretched thing), but maybe like dhcpcd's run hooks.
It’s hardcoded. For IPv4 it doesn’t need to be dynamic because NAT allows you to hardcode private address ranges. But that whole concept of networking doesn’t translate (no pun intended) to IPv6
This is the problem I’m running into with deploying IPv6. I don’t know what address ranges to allocate because the dhcp server doesn’t perform any handshakes with the ISP. And I’m a bit reluctant to rearchitect the network topology for IPv6 because everything already works really well without IPv6.
So ideally I’d want a way of sliding in IPv6 without having to break what’s already working.
Every solution I’ve explored thus far hasn’t achieved that. But there’s lots of good information shared here today so I’ll have another read and maybe they’ll offer up an insight I’d previously missed.
https://blog.infected.systems/posts/2024-12-07-building-an-i...
This allows me to have a mixture of both protocols and even some boxes that have both IPv4 and IPv6 addresses. I still have some issues writing routing rules that does not fail for link-local addresses, but the network has now been fully operational for well over a month.
Yeah, because you're gonna have to have a DHCPv6 client running on your router (and because your ISP is almost certainly using DHCPv6-PD the router is where you're pretty much going to have to first learn about your LAN-side DHCPv6 prefixes), it's probably going to be a bit tricky (but probably not impossible) to do what you want.
Best of luck. If you figure out how to do it within the HN comment freeze period (I think it's 14 days?), please do leave a follow-up comment. I'd be very interested in hearing what you come up with.
Nitpicky, but I think this is not true. NAT's security is based on the router not knowing where to route the traffic and dropping it, where the firewall intentionally drops the traffic.
Agreed that it's functionally equivalent, though.
It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0] But it's the decisions made in the firewall that both make the NAT work, and ensure that WAN traffic that hasn't been requested stays out.
[0] Unless the router were "excitingly" misconfigured!
NAT and firewalling might both done in netfilter via iptables/nftables rules, but they're completely orthogonal decisions. You can do either of them without the other.
> It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0]
Which means this is completely wrong. It won't do this unless you do something to make it do this (i.e. put some rules into FORWARD that control what traffic is/isn't allowed). MASQUERADE just changes the source IP on outbound connections; it doesn't drop inbound connections.
This is probably the pivotal difference lol. Most of the ISP-provided routers I've used either have a default-allow policy or auto-create firewall rules when you add a NAT forwarding rule. I don't honestly recall which because it's been like a decade, but I do remember that I didn't have to explicitly add a firewall rule.
On a Linux router, perhaps setting ip_forward to 1 and leaving rp_filter at 0 would do the trick? It has been ages since I've had to play with rp_filter, so I can't remember exactly what its behavior is.
Nope, the router does know where to route the traffic for obvious reasons. At least for Linux if it's able to do NAT then it's ipso facto able to forward packets from one interface to another, and will do so unless explicitly told not to.
NAT can be fine, but why would it be a feature? (I guess maybe some privacy by way of sharing a public IP?)
IPv6 requires a stateful firewall on the router to provide the same protection. Then if you turn that on, it kinda defeats the point.
So you don’t actually need anything different nor special to have the same level of security with IPv6 vs IPv4 + NAT.
Yes, you’re repeating what I’m saying. NAT forced router vendors to implement stateful connection tracking and it increased the security of everything behind them.
> So you don’t actually need anything different nor special to have the same level of security with IPv6 vs IPv4 + NAT.
This isn’t how it played out in practice though. Huge swaths of home routers had no firewall at all when you enabled IPv6 support because it would have taken slightly extra work to enable the v6 conn tracking.
If you actually want to block inbound connections when you're doing NAT, you need the stateful firewall anyway. At that point, pretty much the only thing NAT is doing for your security is making it harder to understand what's going on.
If you're hinting that roughly half of the internet-connected servers don't have IPv6 addresses, then my reply is "so what?". Only idiots are suggesting that folks who aren't running an experimental lab (or ISPs that have the expertise required to set up the NATs needed to reach the IPv4 internet from v6-only service) go IPv6-only.
- RFC 1631
Anecdotally, during weekday working hours, the percentage of IPv6 is higher than (typically over 50%).
This is followed by reasonable reasons they struggled to unwind themselves from IPv4 (for the experiment) - but eventually got it worked out.
Conversely: When I hotspot from my phone, T-Mobile frequently makes that an IPv6-only experience.
I was previously with an ISP that support IPv6 and had zero problems.
In fact IPv6 worked "too well" at one point: I had put "facebook.com" in my /etc/hosts file pointing to 0.0.0.0 at one point to reduce tracking. I then noticed I got the little FB icons again at some point and couldn't figure out why things were 'broken' (i.e., not blocking).
Turned out that after IPv6 was enabled I had to add ::1. That blocked FB again. IPv6 made connectivity to FB work again.
I dont think any normal person thinks about IPv6 or IPv4 here.
The parent poster's case is unusual. Normal people here don't think about v6 either, and the majority of people have a v6 connection.
A lot of servers have somehow managed to screw up their path MTU discovery. People have been using client-side workarounds for this for many years, but I suspect the workarounds are often forgotten on v6. Unfortunately the resulting problems then get blamed on v6.
The other possibility is broken multicast on your local network. Some Wifi mesh APs and "range extenders" just don't work properly. The test for this would probably be to take them out of the network path by connecting directly to the main router via Ethernet and seeing if you can talk to Internet hosts properly.
Have experienced this issue myself a few times. Really annoying.
I have a IPv6 checker and have a list of broken domains here. https://v6check.miyuru.lk/failed
centurylink ipv6 via their tunnel
So I started digging in, and there's definitely a lot to like.
But I see two big problems that are showstoppers in my opinion, at least for my home network (not even considering the fact that very few residential ISPs even support v6 at this point):
1. Generally speaking, the IPs of your LAN are based on the prefix assigned by the ISP. Most residential ISPs don't offer static prefixes. This means that every time your prefix changes, the IPs of all your devices on your LAN change. Seems like this "feature" was developed in a more idealistic era when people probably thought everyone would be getting static IPv6 addresses, since shortages would never be an issue. Unfortuantely, they failed to foresee the fact that most major ISPs are terrible, greedy organizations that either outright refuse to offer static assignments, or continue treating them as if they were scarce IPv4 resources, charging a premium or requiring business-class service to even get them.
2. The ISPs that do support v6, like Comcast/Xfinity in the USA, are only allocating one /64 prefix. This means you can only have one subnet (VLAN) on your LAN! Why are they being so stingy?
I would love to migrate to IPv6, but these two issues alone make it feel like a clown show for home users.
Using DNS to resolve everything solves part of the problem, but firewall rules are another issue. The router would need to have the capability to update everything dynamically when the prefix changes. I think this in the works for pfSense, but I'm not sure if its actually supported yet. It looks like you might have to mess around with some 3rd-party script to make it work.
I guess I'm just generally disappointed that the whole process seems unnecessarily messy. I don't have a v6-compatible ISP right now anyway. I was thinking about trying a tunnel, but I'm not seeing the benefit in it right now.
2. Lots of ISPs only assign a /64 by default, but if you configure your router to request a /56 via DHCPv6 prefix delegation, you'll usually get the larger prefix.
FWIW, I'm using both of these on my home network, via a router running OpenWRT.
When I was reading up on everything, I also learned that your router can request a bigger prefix, but I ran across several posts from various folks stating they could only get a /64 from Comcast no matter what they tried, so I'm not sure how universally supported DHCPv6-PD requests are.
The nice thing with IPv6 is that devices have no problem with being assigned multiple addresses on the same interface. So most of my devices actually have 5 IPv6 addresses [0]: a globally-routable DHCPv6 address (the default), a globally-routable SLAAC address, a ULA DHCPv6 address, a ULA SLAAC address, and a link-local address. So you can have a globally-routable IP and a locally-stable IP at the same time. And this is arguably a good thing, since it would be annoying to have to renumber your local network if you ever changed ISPs.
> I ran across several posts from various folks stating they could only get a /64 from Comcast no matter what they tried, so I'm not sure how universally supported DHCPv6-PD requests are.
That's annoying, and also means that you probably won't be able to get NPT to work either. FWIW, both Shaw and Telus (in Canada) will assign you a /56 via DHCPv6-PD if you request it.
[0]: I don't actually want this many addresses, but a link-local address is required for IPv6, I want my devices to have constant/easily-memorable IP addresses so I need DHCPv6, Android only supports SLAAC so I have to keep that enabled too, devices will prefer IPv4 over a v6 ULA so I need to keep the globally-routable addresses, and I want to use static addresses in my LAN so I need ULA enabled as well.
There are supposedly so many IPv6 addresses that you could assign every grain of sand on earth on the order of quintillion addresses.
So, yeah, there’s no excuse.
Advertising for example, was essential. Spewing garbage I don't want, absolutely critical to Microsoft's bottom line apparently. But registration so that I can turn off that advertising? Not important, so that was not available until I gave the machine IPv4.
Like how 2-byte Unicode was struggling and UTF-8 saved it.
You don't state why you think this, but this is almost always due to the flawed thinking that the IP address is a simple identifier, and then looking at "how many IPs does the world need?" → "64 bits is enough". (IPs are like street addresses, in that they're routing instructions. Having the space not fragment — like v4's space is doing — is part of it, and helps things like routing tables remain small.)
> and somewhat backward compatible with IPv4.
The pigeon-hole principle makes backwards compatibility impossible. No matter what concrete scheme you might propose, it is effectively equivalent to IPv6.
8 versus 16 bytes barely matters for using the addresses, especially because if you're assigning IPs to your devices you can have the second half of the address start with 6-7 zero bytes and collapse them all with ::
And I challenge you to name a way to be "somewhat backward compatible" that would actually function and IPv6 doesn't already do.
Edit: And not only can you make your own addresses short, if I look up some IPv6 addresses meant to be said/remembered (public DNS IPs), none of them make you type more than 8 bytes (and that one repeats a cluster to make it easier) and some make you type as little as 4 bytes.
Remembering and communicating mildly complex byte sequences should be an issue which is solved already.
It is solved already, it's called DNS.
IPv4 addresses are not any more difficult to remember than phone numbers, but the same can't be said of IPv6.
The other 4 billion people on the planet don't really need internet connections do they?
Doubling the address space is a good strategy when you need more. Quadrupling it is over-engineering.
64 bits are already a pain in the ass to remember, and if you have specific memorization needs you can use small static IPs so that even with 128 bits available you only use about 64 of them.
New L3 protocols on the Internet are firmly on the "incredibly difficult and time consuming" side.
https://www.eff.org/dice
> backwards-compatible would have gotten us there that much sooner
v6 is already backwards compatible. Between dual stack, Teredo, 6to4, 6rd, 6over4, ISATAP, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E, 4rd, LW4over6 and probably other things I'm forgetting, you could make a reasonable argument that it's too backwards compatible, even.
If you meant "v4 being forwards-compatible would have gotten us there sooner", then yes, I agree. It's unfortunate it's not. That's entirely v4's fault though, not v6's.
Google and other big players go to huge lengths to build new Internet protocols on top of UDP because enough of the internet drops or mangles anything other than TCP or UDP that it's effectively impossible to use anything else on the Greater Internet. IPvNext by way of backwards-compatible IPv4 was (and continues to be) no easier than doing something that's backwards-incompatible.
As a bonus, doing the backwards-incompatible thing bypasses all the bad behavior of existing shitty middleboxes and crummy ASICs.
How would it be at all backward compatible other than what NAT64 already does?
Any time you would reference an IPv4 address when v6 enabled, the stack would simply fill in the remaining bits and forward your packets down the line.
This had to have been thought about though, and I suspect the architects of v6 felt it would've been sub-par to what we have. No idea if that's true though.
They actually went with 64:ff9b::/96 as the default (though IPv6 is so big that you can just pick another area if you want in ULA space or whatever).
> Any time you would reference an IPv4 address when v6 enabled, the stack would simply fill in the remaining bits and forward your packets down the line.
There are actually multiple implementations, depending on OS and whether you want it in kernel space or user space.
> This had to have been thought about though, and I suspect the architects of v6 felt it would've been sub-par to what we have. No idea if that's true though.
They thought about it, named it NAT64 ( https://en.wikipedia.org/wiki/NAT64 ), published it, and it's in wide use. It frequently is combined with 464XLAT ( https://en.wikipedia.org/wiki/IPv6_transition_mechanism#464X... ) to make the transition mostly invisible to users/applications.
::ffff:0:0/96 IPv6-mapped This space is intended for an OS or network stack to map IPv4 addresses towards higher layers, so applications could technically be IPv6 only. The packet was/will be standard IPv4 when it reaches the network wire.
::/96 and ::ffff:0:0:0/96 IPv6-compatible/IPv6-mapped These were originally intended to be used on networks to differentiate IPv4 addresses depending on the capability of the target and decide who will do the translation. These are now deprecated, but the whole ::/8 is reserved, and these addresses are promised to never be assigned to anything else.
64:ff9b::/96 IPv6-translated This is the space for IPv6 to IPv4 NAT translators. Actually the whole /48 is reserved, so you can run address multiple private translators in a single network if required. This is widely used and supported.
As a side note Teredo addresses (2001::/32) and 6to4 addresses (2002::/16) all embed the entire IPv4 address space, although they are more complex than a simple 1-to-1 mapping. They are rarely used.