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.
If we just stop listing 240/4 as a bogon we could be allocating from it in a few years.
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.
Any Firewall can simply block all incoming traffic and it would have the same effect as NAT, without the computational overhead that NAT incurs...
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.
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.
centurylink ipv6 via their tunnel
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
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.
Hurricane Electric (for one) offers IPv6 tunnels:
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!
That said, if it isn’t blocked for the services you use, I found it pretty straightforward to use.
- 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.
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.
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 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?
ISP-provided-PD-prefix 2001::/64 + Host address ::22 = Assigned address 2001::22
ISP-provided-PD-prefix 2001:1:/64 + Host address ::22 = Assigned address 2001:1::22
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.
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.
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.
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.
-A INPUT -i wan-interface -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A POSTROUTING -o wan-interface -j MASQUERADE
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!
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.
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.
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.
- RFC 1631
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.
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 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.
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:
-A FORWARD -s fc00::/7 -o wan-interface -j REJECT
> 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.
* https://datatracker.ietf.org/doc/html/draft-ietf-6man-rfc672...
That draft doc seems to fix multiple problems at once.
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.
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.
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 :)
* 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.
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.
So get out there and p2p
Please explain
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.
Or you set up DNS64/NAT64/464XLAT on your IPv6 end of things, and those on IPv4 side don't have to do anything.
You can have a front-end with IPv4 and have a box send the request to the back-end which is IPv6.
This is how FaceMeta works for the last few years: they are completely IPv6 internally in their DC and only have IPv4 at the edges to service 'legacy' connections.
* https://www.youtube.com/watch?v=IKYw7JlyAQQ
* https://engineering.fb.com/2017/01/17/production-engineering...
And I still don't get any-to-any connectivity with the IPv4 people, which is what you need if P2P is going to be seamless.
You don't have to install NAT64 to connect to v4-only hosts -- you can run dual-stack, and use your existing v4 setup to reach them. NAT64 is just what you do when you want to turn off v4. You said in the post above that people running networks should have been told they had to change things, so you don't get to whinge about needing to do it yourself.
Also, you don't need to have a public v4 address for v4-only people to connect to you. Reverse proxying is a service you can pay for, and only the people running the proxy need v4. CloudFlare do this (for free, even, depending on what you're doing).
In fact the same is true of NAT64; set your DNS server to e.g. 2a01:4f8:c2c:123f::1 and away you go.
is this about the meaning of the term "NAT"? because of course it is a security feature if something is offline by default
I will be over there soon.
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.
BTW, NAT doesn’t scale forever. There are often several layers of NAT in carrier implementations and the port mapping issue alone can dictate the maximum number of clients-per-global-IPv4 address. One of the reasons NAT and IPv4 can still work is because much of the world has shifted to IPv6.
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.
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...
Like how 2-byte Unicode was struggling and UTF-8 saved it.
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.
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.
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.
> 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.
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.
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.
Anecdotally, during weekday working hours, the percentage of IPv6 is higher than (typically over 50%).
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.
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.
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.
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.
You can argue "it's only one line" but that one line is a new socket and new test variant needing testing. something that worked perfectly well for 5-10 years now needing a re-test.
I'm not arguing against ipv6 . I'm arguing for honest assessments of the effort needing to migrate a network , especially residential networks, to IPv6 -- as the only way to make it happen. Shaming people with "it's so easy and simple" is just dishonest and doesn't help the cause.
It's not no work. I'm just saying it's not double the work. You'd think knowing that would make people more likely to do it, but...
One appliance or service, but double the rules. The rules are all of the maintenance cost
> You can listen on a single socket too (sockets listening on :: will accept v4 connections by default on Linux).
Old apps need migrating. 99% of apps that listen 127.0.0.1:PORT and need a rebuild & re-test. Any app compiled with AF_INET need a rebuild.
I encountered this working on adding ipv6 support for oauth callbacks (127.0.0.1:3000) to rclone and it was a huge pain. still never got this working reliably enough for the maintainer to merge.
You're thinking about your desktop where you are recompiling constantly. I'm talking about embedded & unsupported IOT devices that are out there. Even with sources the effort to rebuild reinstall is heavy.
how?
$ dig A +short github.com
140.82.112.4
$ dig AAAA +short github.com
64:ff9b::8c52:7004
$ dig AAAA +short github.com @2a01:4f8:c2c:123f::1
2a01:4f8:c2c:123f:64:5:8c52:7004
2a00:1098:2c::5:8c52:7004
2a00:1098:2b::1:8c52:7004
$ getent ahosts 2a00:1098:2b::1:140.82.112.4
2a00:1098:2b::1:8c52:7004 STREAM 2a00:1098:2b::1:140.82.112.4I'm having an issue with ipv6 sockets not receiving ipv4 traffic. setsockopt IPV6_V6ONLY = 0 is supposed to make ipv6 sockets listen on ipv4 as well
Can you take a look at this and see why it's not working
https://gist.github.com/tonymet/a85b43831179055d16403a9d9be1...
sybercecurity•6mo ago