Yes. It's a bit like, "Do you need a car?". If you're only going very popular places public transport might work. But to be able to surf the 'net you need ipv4.
You do though. It's only consuming generic content from generic websites that works with ipv6 cnat. Try to actually participate in the 'net (ie, host a video game server, do some peer to peer task, port scan to explore, etc) and you find out very fast you have no ports and can't do anything.
"End devices" are not mindless consumers of content like this very naming and article suggest. They are participants in the internet, if you let them. It's a shame kids are growing up today without being able to participate. Most are going to be intellectually stunted by it.
There’s not enough v4 addresses to go around, so if you want to “participate in the net”, then the approach of assigning public IPv6 addresses to end devices is better, not somehow worse.
The article accepts this premise, but argues that you only need it on the provider's edge, not on end-user devices.
> First of all, let’s start with stating the obvious: most devices will have to talk to legacy services. This post will not argue against this, despite excuses for this decreasing.
> Luckily, IPv6-only devices can still talk to IPv4-only ones, and this is getting easier than ever before.
I was surprised today to find that Spectrum doesn't enable IPv6 by default. Only figured this out after way too long trying to ssh into my IPv6-only Hetzner instance.
Ended up just paying for an IPv4 address to avoid the hassle.
I don't think this is "the year of IPv6" but it might be its decade.
I was dealing with this the other day. Spectrum was giving me IPv6 - annoying when developing an IPv4 service. Ended up switching router to one that only support IPv4 and it reverted back to IPv4. If I plug my MacBook directly into the modem, get ipv6.
>I'm hoping/assuming/guessing those won't have that odd IPv4/IPv6 switching behaviour...
As a Spectrum Business customer, I wish I could tell you whether or not that was true, but IPv6 isn't available to me at all. I'd happily (okay, not happily, but I'd be willing to do so) pay for an IPv6 block (I currently pay for five static IPv4 addresses -- one of which is eaten by Spectrum's required router, the other eaten by my own router, but that's a different discussion..Grrr!), but I can't even do that -- as it's not even on offer here (NYC).
It seems that there's wide disparity in how/where Spectrum implements its IPv6, so YMMV.
I have used Spectrum and they gave me a v6 route without asking. Maybe your DHCP client or OS was to blame? I am not sure if it shook out via router advertisements or DHCPv6, it just worked with dhcpcd.
Might be a regional thing or something to do with your router. I have Spectrum and my router gets a global IPv4 address and IPv6 prefix over DHCP(4/6) just fine without doing anything special.
I have Spectrum at my house & while they will give me an IPv6 address it doesn't really work. The network offers up a wide range of IPv6 blocks I can choose to use. But whatever IP you use first, that is the only address you ever get traffic for. So the delegation is basically just 1 IP in practice.
Also IPv6 doesn't actually work reliably. You'll notice it when browsing the web for example, there are periods of 2-3 seconds without IPv6 connectivity. This does not happen on IPv4.
> Since a lot of mobile networks (5G, 4G, etc.) in the world are IPv6-only, and have no IPv4, there’s luckily a solution for this already.
Ha! I have an iPhone 15 and when I switch to mobile I get an IPv4-only address! My mobile provider is Verizon. I assume results are going to vary drastically based on region. I feel there are a lot of assertions in this article without any real data to back them up. If it makes any difference, AS6167.
I have IPv4-only AS6167 on my Verizon iPhone as well, but I was under the impression the reason I only have IPv4 is a limitation from also having a static IPv4 address on my phone.
If your getting a public IPv4 i wouldn't be complaining lol, if it's cgnat or ds-lite or something then sure bitch, but if your ISP has the ip space to give you public IPv4 for free i'd be happy lol
Still lots of dark areas [1] and lots of unnecessary allocated space to original adopters. I wonder if the Governments will ever exercise an Eminent Domain on IPv4 one day?
There is no government control on IP address space. The only actual binding is to the 5 RIRs*, and if you want to see how eminent domain would fare there... Take a look at the current AfriNIC situation :(
And certainly on local networks. It's way more convenient to work with.
The only thing I can see replacing it is if something I'll call "easyip" came around - something even more convenient than ipv4 for networks of under, say a few hundred devices
We're talking local here. Once you get to the gateway, you can go ipv6 but the iot camera, cups printer and smart plug is perfectly happy in the world of 192.168
Again, the only replacement I can foresee is for an address schema that either doesn't pretend to even attempt global space or has a UUID scheme where network addresses are immutable, globally unique and inviolable.
This would potentially simplify an iot world if the addresses are known, globally unique and static.
> Again, the only replacement I can foresee is for an address schema that either doesn't pretend to even attempt global space or has a UUID scheme where network addresses are immutable, globally unique and inviolable.
Currently when you get an iot device you usually connect to it through the smartphone, tell it your Wi-Fi hotspot, give it the password and have it go online.
Instead there could be a flow of going to the routers interface, select "scan new qr code" and you add the device that way - more realistically this would be done through the "myspectrum" or equivalent app as the isp usually issues the modem/hotspot for the majority of consumers.
A number of things would have to change to make that possible but it's a much easier setup flow and it likely requires less complex software on the device itself.
It sounds like you're trying to re-implement IPv6 Neighbor Discovery using qr codes. I really don't see the point of this or how it relates to private networking.
If you want really simple solution on device itself, just let it NDP for router info and drop any incoming SYN that's not already in the conntrack table or part of the ULA space. Boom - done.
Genuine question—how are ip4 local networks any easier to administrate with ip4 than ip6? Ip6 seems like it has the same capabilities but without the misery of a constrictive address space and its solution, NAT. Hell, if I could DISABLE ip4 locally on my router it'd only make my life easier.
(The only answer that makes sense here is supporting legacy devices, which will probably be a problem we'll have to deal with for the rest of our lives. Thankfully I don't appear to have any such devices on my network!)
#1 issue ... you've gotta hold shift for : it's a minor annoyance but it's an annoyance lol that you have to do 3 times even in those nice short addresses
Can't speak for the commenter, but I'm not personally planning on shifting my LAN to IPv6 because doing that is a heavy lift (made worse by having many IPv4-only devices), and IPv6 doesn't bring anything to my LAN that I want or need. It's as simple as that.
Are you talking about home or work network? If you have dual-stack gateway, then your LAN has should have IPv6 unless you deliberately disabled it. For simple networks, should just need to enable IPv6 on router. If you haven't disabled it on each machine, they are using site-local IPv6. I don't know which devices on my home network use IPv6, but I haven't had to enter IPv6 addresses anywhere.
IPv6 networks are simpler. They do many things automatically that have to be entered manually. The big one is don't have to worry about subnet size or subnet masks; all subnets are /64 and effectively infinite. This doesn't matter for home network but it is big advantage for corporate networks.
Home network, albeit a complex one. I did deliberately disable IPv6 on my LAN, because configuring and administering a dual-stack LAN is more hassle than I'm willing to engage in. The cost/benefit of doing that just isn't favorable for me.
All I really need is to be able to accommodate IPv6 on the internet side, which I can currently do.
ipv6 was designed for global addresses used on the global address namespace. The community hates anything not doing that since that would remind too much of NAT. So anything intentionally not on the global namespace is second rate and not quite supported*.
Alas, being on the global namespace means being dependent on your ISP** - what if they renumber or you want to move ISPs? - or going through the bureaucracy of registering your own block. Yes, despite an infinite space you still need to register to avoid fragmentation. That's something I never want to do.
* For example, IPv6 ULAs have a stupid lookup precedence - IPv4 addresses are higher which means ULA can't be used anywhere which is dual stack.
** There are ways around the latter like ULAs (see above) or using a local DNS (more mess if it fails, assuming everything supports this), or NPT - which would work, but again, the community hates anything that reminds of NAT even when it's totally stateless, so this is little documented. I don't think going against the entire community is a worthwhile endeavor. This should also limit your choice of routers since IIRC not everything supports this.
My main problem with IPv6-only on local networks is static IP assignment. With NAT (IPv4 or IPv6) I could assign my own addresses to devices, which could remain the same forever even when changing ISPs. This is not possible when using IPv6 GUAs via PD.
Yes, I could assign every device a ULA with NAT. That would defeat a major selling point of IPv6. An alternative would be to assign both a GUA and ULA to every device, via DHCPv6 and SLAAC. However, not all devices support this. For example Android doesn't support DHCPv6 and NetworkManager doesn't seem to support multiple auto configuration methods
> IPv4 will be around forever. It'll just get more expensive.
Not necessarily: as IPv6 becomes more and more mainstream (Google is saying 50% traffic), the need for IPv4 will become less, and so it may be relegated to 'legacy' status and a secondary consideration.
I find IPv6 to be a very mobile centric technology. As a back-end developer and infrastructure engineer I don't see the point of it. If I used IPv6 everywhere in my server room outsiders could see the topology of my internal Network. NAT isn't an annoyance on the server side, it's a requirement for security.
I have yet to meet an infrastructure engineer or even hear of one who switched to IPv6 on purpose because they thought it was better. They always switch because they have more than 65k servers or to support mobile better. I feel like the people in charge who say that we should all move to IPv6 are the same people that we should that say we should all move QUIC and for the same reason: mobile clients like it better. But it's just not useful on the server side.
Proper security is when everything is closed off and inaccessible by default.
IPv6 where your home network or backend infrastructure is a transparent glass house is a failure by design. I hope I never get to be a DevOps and support that. Or have IPv6 in my home network. One bad firewall rule or insecure port open, and you get ransomware in your face.
Proper security is when everything is closed off and inaccessible by default.
I have met a lot of infrastructure engineers who do that... then never give the people who need access access. So the system just sits and collects dust.
You have users. Acknowledge them. The network shouldn't even be the primary security boundary to begin with.
One bad firewall rule or insecure port open
Firewall !== routing. Nobody said you can't run a border firewall on your home network.
More of the same with this situation. A bunch of client developers telling me how to do my job.
It's such a huge risk to show people what is in my network. It's such a huge risk to the business. It makes no sense to It makes no sense to reveal that. But I suppose telling you is not worth anyone's time, you're just going to say you like it better because you're a mobile developer.
> I don't want to run a border firewall on my home network, because I am not devops,
Well... too bad? Do you want security or not?
> neither is my mother, who also has a home network, etc.
If your hypothetical non-technical mother just buys a normal off-the-shelf router (+AP+switch+...) then it'll already have a firewall by default. It's not like end-users are expected to design/implement these things themselves.
Acknowledging users is important, of course. I'd
switch to IPv6 if clients really needed it. But the Glass House argument still applies. I'm still locking my doors by running a firewall, but I still don't want to show you what's all in my house and available to steal. Locks are not perfect. I'd much rather do dual stack or something similar so that I could keep my NAT.
Glass house... Of random numbers, assigned randomly? All of which are largely inaccessible unless they connect out first? Which is the same with NAT...
Are IP addresses really such sensitive secrets from your POV?
Especially since it contains Mac addresses, which are very much not random, encoding such info as the manufacturer of the device. Yes, these can be randomized, but you don't generally want to do this with servers. You want to know the Mac of your box. You certainly don't want to leak it or show bad actors what subnet it's in. Again, the non-mac part of the numbers leak information; they are very much not random.
> Especially since it contains Mac addresses, which are very much not random, encoding such info as the manufacturer of the device. Yes, these can be randomized, but you don't generally want to do this with servers.
You also don't have to use the MAC-based addresses on the server either. You can generate a random address and use that for your service.
Or you can regularly generate addresses on the server and update DNS so that the service has a new address every x hours or days. Or you could have the server not have any 'public' addresses, and whenever a new client wants to connect a new address is generated just for that client (with a TTL).
We actually gave up on wrong-layer firewalling where I work, as it was just too much upkeep. We had enough engineers (… like two dozen, so not a lot in absolute terms) and ISPs rotate public IP address assignments way too often. And every time it happens it takes a while, as that person has to debug with usually terrible diagnostics. (Since the network is just dropping their packets.)
The thing about v6 is … you can just firewall permit like the entire North America block to whatever ports absolutely must be exposed … and just not get any attacking traffic?, at least if the address isn't somehow otherwise discoverable. This isn't possible on v4 (there is no such block, due to the space's fragmentation), and opening up v4 otherwise does expose you to a cesspool of incoming maliciousness. (Though … there are tools for this.)
If there was decent tooling available to me for "here are the IP addresses of the userbase" (e.g., some sort of phone-home system) that could keep the firewalls in sync with reality, I'd be more enthusiastic about it.
But the status quo is largely "security teams want IP firewalling, but don't want to figure out how to actually implement that in a manner that it will realistically work and not waste engineers time filing dozens of security requests".
>The thing about v6 is … you can just firewall permit like the entire North America block to whatever ports absolutely must be exposed … and just not get any attacking traffic?, at least if the address isn't somehow otherwise discoverable.
I have a live feed of packets dropped by my firewall's "deny incoming on WAN by default" rule for fun, and I do occasionally see v6 packets being dropped. They're random addresses under the /48 that was delegated to me but which don't actually belong to any devices. So it doesn't seem to be because someone is actually harvesting IPs from my outgoing traffic, just guesswork. There was also one time where someone was very methodically testing every /64 by incrementing one at a time, with random bytes in the lower half, ie 2001:db8:abcd::$random, 2001:db8:abcd:1::$random, ...
The vast majority of dropped packets are v4 though.
What component on your router prevents a packet with destination IP 192.168.1.2 appearing on WAN from crossing over to the 192.168.1/24 LAN and reaching the device with that IP? Hint: It's the same one that also prevents IPv6 packets from making that same crossing.
This makes exactly zero sense. So my home network appliances have public IPv6 addreases, but everything sent to these addresses is null routed? How does that work? At least with NAT there is a known set of rules regarding how masquerading works, that I can reason about.
WAN will not sent such malformed packets in the first place, unless we are talking of mom and pop ISP.
>So my home network appliances have public IPv6 addreases, but everything sent to these addresses is null routed?
Of course. Unless you add rules to allow incoming traffic, say a rule to allow incoming traffic for $LAN_MACHINE1_IP:$PORT/tcp, to cross from WAN to LAN.
>At least with NAT there is a known set of rules regarding how masquerading works, that I can reason about.
The reason the scenario in my previous comment doesn't work has nothing to do with NAT. The reason such a packet would be dropped is because the firewall has a rule to filter bogons on the WAN interface. More generally, your home network firewall will have a default rule to block all incoming traffic on WAN unless explicitly allowed via additional rules, and that applies to both IPv4 and IPv6.
>WAN will not sent such malformed packets in the first place, unless we are talking of mom and pop ISP.
Well if you trust your ISP so much then I assume you just have your firewall turned off always, right?
Not really no it's not the same. But this whole argument I feel like it's trying to explain flying to a fish. Most developers are so far removed from this world they have no practical experience keeping the chaos out of the network, it's very frustrating from my end.
Also my network (dual stack) is quite orderly as far as I can tell, thank you very much. I promise I won't ask you for help if that ever changes, if it helps :)
> Not really no it's not the same. But this whole argument I feel like it's trying to explain flying to a fish.
No, it's like you're a fish trying to explain flying to birds.
You don't understand the fundamentals of IPv6 (among other things, in other comments you have revealed that you think IPv6 addresses are MAC-based, think Comcast is a wireless ISP, and aren't aware of stateful firewalls). You have so many misconceptions about IPv6 it's no wonder you hate it.
> Proper security is when everything is closed off and inaccessible by default.
Not only that. PCI DSS explicitly requires hiding the network topology from outsiders - even though they cannot connect. So it is either NAT or very short-lived IPv6 addresses, and guess what - for internal audits of who did what, NAT works better.
To be honest, I don't care at all what the site I'm trying to reach does internally after it terminates my connection to them via either IPv4 and IPv6 – just don't pretend that IPv6 is not a thing.
> If I used IPv6 everywhere in my server room outsiders could see the topology of my internal Network. NAT isn't an annoyance on the server side, it's a requirement for security.
You can NAT IPv6, but it really sounds like you're doing security-by-obscurity, which is less than rigorous. If your servers are properly secured you should be able to publish a complete list of your servers and their IPs on your website and not impact your security at all.
> I have yet to meet an infrastructure engineer or even hear of one who switched to IPv6 on purpose because they thought it was better.
Of course we should do more than security by obscurity, but sometimes obscurity is the only thing we have. We need to do everything in our power to secure the servers. Of course we're going to lock the doors, but if we can also obscure what's there, we should.
Security by obscurity if these servers could be reached if you knew their "real names". In case of NAT, no amount of information will let you access these machines, so it is proper security. It is almost as good as airgap.
With IPv6, knowing addresses of these machines will let you spam them with packets and possibly breach them the second firewall goes down for any reason.
> Security by obscurity if these servers could be reached if you knew their "real names". In case of NAT, no amount of information will let you access these machines, so it is proper security. It is almost as good as airgap.
If you have a firewall, then no amount of information will give you access either.
> the second firewall goes down for any reason
Is this like... a thing that you've actually seen happen? Because it really sounds like something that at best happened 20 years ago in a freak accident that will never happen again.
If we're allowing equipment to just randomly break to that degree then I get to assume that your NAT will just forward incoming traffic directly to servers.
Why won't it? Seriously, it looks like the default state for me: If you have an external, globally visible IP address and a port is open on it, everyone in the world can try and connect to it.
With NAT, there's no obvious way to connect from the outside to the inside, because the inside cannot be addressed from the outside.
> Why won't it? Seriously, it looks like the default state for me: If you have an external, globally visible IP address and a port is open on it, everyone in the world can try and connect to it.
Well... yeah, if you open a port then the port is open. Since every firewall I've seen - including the ones in cheap garbage home routers - defaults to deny all inbound / allow all outbound, that's not the "default state", that's something you have to specifically add. (And again, same applies to NAT; you can add a port-forward rule, but if you care about security maybe don't.)
> With NAT, there's no obvious way to connect from the outside to the inside, because the inside cannot be addressed from the outside.
I am precisely concerned with the non-obvious ways. If we're talking about a server environment where every single device on the private subnet is trusted and doesn't get compromised, no ports are forwarded, there is no DMZ, and UPnP is absent or disabled, then it might work, but I would still trust it less than a firewall. In a home or office environment those constraints go out the window (UPnP was quite popular once, IoT ensures there's an endless supply of untrusted devices, and, y'know, Cross-Site Scripting attacks making every device with a browser a potential threat), which is probably why I have the cached heuristic of "don't trust NAT for security".
>If you have an external, globally visible IP address and a port is open on it, everyone in the world can try and connect to it.
As someone who have been running IPv6-only services and before that, IPv4-only services, I find this premise to be untrue more or less.
Indeed, my topology is exposed to the internet. But no one has ever exploited that, because IPv6 networks are huge, super huge.
At best a random attacker will be able to tell which network one of your servers is located in, but they cannot find the other networked equipments inside this network. No one in their right mind will bother with your 2^64-sized network like how they did with IPv4.
A random attacker will buy a "6 billion real IPv6 addresses" database dump for $15 and then will spam your specific IPs as soon as they will produce any outgoing packets at all. Only a matter of time.
This assumes that they have a database on my IPv6 addresses though (one which would be easily invalidated because SLAAC is just awesome), and furthermore assumes that I don't have a firewall to block off unwanted incoming connections -- you know, just like how NAT is basically a firewall with packet-modifying capabilities.
Spoken like a person who clearly never had to peer two vpcs that just happened to have intersecting subnets
> Of course it's great for ephemeral stuff. It's just that most people don't have that problem
A lot of people run containers these days. It’s not unusual to have endpoints in the tens of thousands or more and there are other considerations that make ipv4 management hard/impossible
Ha, you better believe it - even /8 would be tight for them. Ultimately, it comes down to segmentation creating a ton of waste and you need segmentation to manage ACLs and things like that
With ipv6 you can just assign every actor a /96 and they get 4 billion IPs to play with
> I have yet to meet an infrastructure engineer or even hear of one who switched to IPv6 on purpose because they thought it was better.
Go talk to the infra people at Comcast. Their infra network is 100% IPv6 and their customers are almost exclusively fixed-location.
> ...I don't see the point of it.
I've personally seen (on more than one occasion) the IT infra mergers of pairs of companies delayed by 12+ months because of the need to renumber (and/or decom because there's just not enough IP address space) machines using RFC 1918 space. RFC 4193 eliminates the need for renumbering.
There are many other reasons for it, but that's one of the ones that tears my heart to pieces each time I have to use multiple VPNs for a year or more while the Great Renumbering is underway.
There are mobile providers so your argument is invalid. Also on the server side they are a famous case of people who need more than 65,000 servers which I covered in my comment.
And renumbering is so, so much easier than switching network stacks. It'd be years to switch network stacks, not only to change over the addresses but also to change over entire business processes and higher swaths of security engineers to keep track of your now much more vulnerable network. It would be a business change, not just a network change.
What servers? They're a cable ISP. I'm sure they also have some business users, many of which will be hosting servers, but that's not really the first thing I think of when I hear "Comcast has deployed IPv6".
I'm thinking people connecting iPads and lightbulbs to some CPE, not data centers. And Comcast does that via IPv6, as do many cable or fiber ISPs these days. Many don't assign public IPv4 addresses to their residential customers anymore.
> I'm thinking people connecting iPads and lightbulbs to some CPE, not data centers.
It's that, sure. But it's also Comcast's internal infrastructure devices. Comcast went all-IPv6 on their internal network because they have so very many things that they need to directly address... _internally_... that IPv4 wasn't cutting it anymore.
Even if they didn't provide IPv6 service to their end-users, they'd still be using IPv6 on their internal network.
You should be relying on a firewall, not NAT. Coincidentally, most NAT boxes are also firewalls, but it's not the same thing. IPv6 is better because you have end-to-end connectivity, no private/public address hacks, which is how the Internet is supposed to work.
> If I used IPv6 everywhere in my server room outsiders could see the topology of my internal Network.
When was the last time an attacker punched a hole through a firewall device?
Attacks generally start from compromising a user machine (e.g., phishing) or a server (via server-software exploit), installing some malware on already-internal machine, and start probing from there. Not being able to see the internal topology has hindered precisely zero network compromises.
> While we definitely need firewalls and/or packet filters at the network edge, most of today’s attacks work on application-layer, using SQL injection or “Advanced Persistent Threats” like sending an Excel or PDF file with a 0-day exploit to a click-happy user.
IPv4+NAT does not remove any more classes of problems than IPv6+firewall. Firewalls under IPv6 work exactly the same way as they do with IPv4:
An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table(s) it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.
The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.
With IPv6 the address/port rewriting is not done.† Only state tables are updated and checked.
New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.‡
There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence.
NAT is not a security feature but a workaround for the lack of IPv4 addresses. The security comes from the state checking.
† It is possible to have private IPv6 addresses using ULA, and then the router/firewall uses NPTv6 to rewrite the prefix (leaving the /64 interface component alone).
‡ Just like with IPv4 (NAT), to allow unsolicited 'new' connections in you have to do do firewall hole punching with (e.g.) UPNP. But by default things are blocked.
Yes because 6 is garbage around here. 2+ minutes to establish a connection to some servers. The comparison with public transport in another comment is apt. The bus is only once an hour.
Half[0] of AWS's services don't work with IPv6, despite Amazon charging extortionate rents on IPv4 addresses.
So... yeah, for that reason I do need to keep using IPv4, at least until either 1) AWS gets its act together; or 2) my employer moves away from AWS (which is very unlikely).
[0] Hyperbole... but probably not that unrealistic.
Yea, the AWS situation is pretty dumb. We know full well that under the hood, every component that Amazon uses to build those services supports IPv6. When you star using some AWS service, it starts up a fleet of compute instances behind the scenes to handle the traffic you’re going to send it. If the developer of the service remembered to check the “IPv6” checkbox for those instances then the service will support IPv6, otherwise it won't.
But as the article points out, it doesn't really matter. You could run a NAT64 service of your own, inside the VPC that AWS gives you. Your own systems can then be IPv6–only, saving you money while still using AWS services that still don't support IPv6.
$ dig -t AAAA gitlab.com.
gitlab.com. 300 IN AAAA 2606:4700:90:0:f22e:fbec:5bed:a9b9
It's not that I excuse them, and doubly so now that they're owned by Microsoft (which for sure supports IPv6 on their control plane), but I'm just saying they're not the only game in town
Related question: I asked my ISP for IPv6 and they gave me a static assignment like this:
WAN: A:B:C:D::1/126
LAN: A:B:110::/48
I tried to read up on this but am still confused. Why are they giving me WAN and LAN addresses? I thought the whole point of IPv6 is that you give your devices publicly routable IP addresses. If an address is publicly routable, what's "LAN" about it? I haven't been able to find a working configuration for Unifi, though their IPv6 support is like 20% implemented at best.
And no, the LAN subnet isn't in the ULA or link-local space.
Traffic for that /48 will be routed to your router. You're free to divvy up that /48 into /64 subnets on your LAN. Eg you can make one subnet A:B:110::/64, another A:B:110:1::/64, and so on all the way to A:B:110:ffff::/64. ("Making a subnet" == setting up at least RA to advertise that prefix, along with DHCPv6 / SLAAC options as you want.) Then LAN devices on those subnets can use any IP in the /64 for themselves.
In your case it's a static assignment, but otherwise it can be assigned via DHCPv6-PD (when your router asks for a WAN IP using DHCPv6, it also gets told that some prefix like your /48 has been "delegated" to it). The result is the same.
If you want your devices on your LAN to have publicly routable IP addresses, by definition they need to be GUA. I think you just mis-understand what end-to-end connectivity means.
Your "WAN" is a small transit subnet between your router and your ISPs, while the "LAN" is the actual public ip space you will be assigning to your end devices.
>If an address is publicly routable, what's "LAN" about it?
Routable or not, it's LAN because it's in your network behind your router. It's just an identifier.
A router (discounting unnumbered and ARP/NDP proxying) will have at least 2 IP addresses, otherwise how can it route packets between two different networks? It needs one IP for itself on each network.
For IPv4, you will be given <some random IP> on the WAN side and typically you assign 192.168.x.x (or other RFC1918 addresses) to your devices on the LAN side.
For IPv6, you will be given two random IP blocks with similar usage as the IPv4 ones, except that the LAN side is now publicly routable.
I run a server and have yet to adopt IPv6. My logic is: people can type in a URL and get to my site. Am I missing out on anything by continuing to pretend that IPv6 doesn't exist?
Yes. You are missing out on information security auditor complaints. They are happy now because your server complies with one more bullet point (in particular, 3.7, "Disable IPv6") from the CIS benchmark: https://github.com/skylens/CIS/blob/master/CIS_Distribution_...
The big reason to support IPv6 to learn about it and get ahead of the curve. If your hosting provider support IPv6, it should be easy to add IPv6 address to server and DNS. You will also need to check your software doesn't assume IPv4 addresses.
With single server, there aren't the networking advantages to using IPv6 internally.
As new ISP's and enterprises start up who cannot obtain legacy IPv4 address space, there are going to be more and more people who will not be able to access an IPv4-only resource without using some form of tunnel.
You seem to assume IPv4aaS implies charging for access to IPv4. That's not the case here. (...And where did you get the impression?)
The term is hinging more on the on-demand aspect of "X as a Service".
To use an analogy, IPv4 was like the harddrive of a computer. Removing it rendered the computer inoperable. But nowadays some ISPs are moving towards an IPv6-only core (much like how modern PCs are moving towards solid-state drivers) and IPv4, becoming IPv4aaS, (like the HDD becoming an external HDD) is no longer an integral part of the ISP network.
IPv4aaS simply means that: IPv4 is now removable.
We haven't removed IPv4 because right now, the HDD still contains a lot of stuffs so although unplugging it does not render the computer inoperable, it'll still create a giant headache. That's the on-demand part of IPv4aaS. Doesn't mean it'll be plugged in forever, and don't expect it to be when half of the Internet is already on this analogical SSD.
So in answer to my original question, the tl;dr is that I can continue to pretend that IPv6 doesn’t exist.
I’ve been hearing that I need to prepare for IPv6 for the past 20 years, and the benefits are always exceptionally vague or don’t apply to me. I’ll check back in a few years from now.
It's all fun and games until your ISP's IPv4 CGNAT gets overloaded. [0]
If my network wasn't prepared with IPv6, I'd had experienced dialup-era speeds for an entire week, but since I was, only half of the Internet were unusable. After some DNS tricks, I was actually able to browse the Internet entirely on IPv6 minus a few websites, Imgur being one of them.
Did you enable IPv6 on your router? A lot of routers ship with it disabled.
Comcast has supported IPv6 for a decade. I've been using it that long, I'm using it access this site.
Err what? I won't say many nice things about Comcast, but they treat IPv6 as a first-class network citizen and actually follow all the best practices for IPv6 (like DHCP-PD'ing /56's by default). Their support for IPv6 is top notch.
I do not need IPv4, BUT I need IPv6 with a global per host, without tricks to avoid my free use of hosts, just to keep the users "a bit out of internet"...
I recently moved to Ireland. Here I have Virgin Media fiber, and I was pretty upset to learn the router was very locked down, and I can't even port forward.
I have a bunch of services that I host from home, and with my previous provider (and country) I had a static IP with all the associated DNS and DMZ stuff to make it work.
I was about 2 days into a VPN rabbit hole when I discovered that Virgin gives out IPV6 AND IPV4 IPs, and that the v6 ones are publically routable! I was able to access my hosted service by plugging in the server and going to it's IPv6 address on my phone. Some quick Cloudflare IPV4 to IPV6 proxying later and I'm up and running as before. Can now access the service from any internet network (even IPV4 ones). No more DMZ, port forwarding, etc. Happy days.
So yes, I moved away from V4 in about an afternoon, no issues.
I'm not sure if the IP is static though. The server has a reserved V4 IP for internal stuff, I hope the router is clever enough to then keep the V6 one also static. With the address space being so large, I guess giving clients entire blocks of addresses that are static is perfectly fine?
Do you have a blog post or something detailing your experience? I'm in the exact same situation (Ireland, Virgin, self-hosting) and after a week of struggling I couldn't find a way to expose my services. I'm happy to run everything locally at the moment as I only have a media server but I'm interested in running a few websites and services.
Is it possible to use tailscale to punch out to the public internet, having the service available behind normal DNS, accesible by clients that are not part of your tailnet?
There are a whole bunch of alternatives too - https://github.com/anderspitman/awesome-tunneling. I will advocate for zrok.io as I work on its parent project, OpenZiti. zrok is open source and has a free SaaS as well as more built in security.
I dont, sorry! But I'll see if I can find some time to write something up and put it somewhere for you to access. Media server is also the service that I host :)
Yes, roughly 8,000 clients, 4 remote sites, 2 clouds, 2 colos, one private datacenter, for a major financial firm. The whole thing was much easier on a single protocol stack: only one set of firewall rules to manage.
>do you really think Roomba is going to allow you to directly connect to your vacuum without going through them? Absolutely not, they will _never_ give up that control.
This is such a strange chain of reasoning.
1. With IPv4, IoT management must go through a centralized service due to NATs.
2. With IPv6, IoT management may go through a centralized due to corporate greed.
You see the difference there? This reasoning is unsound because it's more or less "we shouldn't eat because we'd choke on food".
>Ipv4 is a very important protocol because it accidentally protects against casual identification from the Facebooks, Apples, Googles, Amazons, etc
Coincidentally, if the world is stuck on IPv4 then hobbyists/"privacyists" will be the group of people who are hurt the most. Hosting a service is becoming more difficult when CGNAT is imposed on everyone, everywhere.
It shouldn't be difficult to imagine a future (as a matter of fact, it is happening now) when, to host a server, you _must_ rent a VPS or something from the tech companies since it's impossible to do it from home. Does your VPS provider allow you to host Tor services? Run BitTorrrent?
Comment #42069 on "HN doesn't understand the Internet Protocol". This opinion is frequently repeated here on HN but -- you CAN'T use IPv4 internally and expect to talk to external IPv6 hosts.
How would this IPv4 internal host (say 192.168.1.10) send a packet destined to 2001:db8::1? You can't stick a 128-bit IPv6 address into your IPv4 packet - there are only 32 bits available for the destination address inside its header.
NAT is not magic, it cannot extract a 128-bit number out of your 32-bit number.
Ironically, you are the one who needs to do more research.
I have deployed NAT64 in multiple networks before.
NAT64 is used when you have _internal_ IPv6 hosts who want to reach the _external_ IPv4 hosts. In order words, 2001:db8::1 can send something to 198.51.100.1 but not vice versa.
Your proposal is that we use IPv4 _internally_ since you think "internal IPv6 is overly complex" and we should "NAT to internal IPv4's". It doesn't exist since IPv4 is inherently forwards incompatible.
"HN doesn't understand the Internet Protocol" strikes again.
IPv6 internal network is simpler and probably a good idea for a brand-new network.
The big advantage is that don't have to worry about subnet size. No deciding how big subnet is going to be, and either making it too small and having to resize or making it too big and wasting space.
IPv6 is more complicated in that supports multiple addresses, but that is an advantage. For internal use, assign ULA addresses and route those over VPNs. For accessing Internet, computers use the ISP assigned addresses. Then assign fixed addresses from hosting provider to load balancers and external servers. This means that only Internet only sees random addresses; they know the provider but that is known with IPv4.
You ever ran out of ipv4 addresses on a home network? I find this probably does not apply to vast majority of users. And even if you do run out... If using DHCP is it trivial to change network prefix.
(Obligatory "anecdotal, but") I noticed that some routers have a very limited DHCP server, for example being limited to 100 simultaneously-connected devices only. Multi-tenant households with IoT devices may approach that number, the highest number I've seen is around 80 currently.
The S in IoT stands for security, of course. But it's going to be a bummer if my IoT devices forces me or my guests out of my network.
IPv6 can be made stateless with SLAAC so DHCP (and any DHCP-related limitations in the router) are completely out of the picture.
178 comments
[ 5.0 ms ] story [ 135 ms ] threadThis exception doesn't apply to cities that have their acts together.
"End devices" are not mindless consumers of content like this very naming and article suggest. They are participants in the internet, if you let them. It's a shame kids are growing up today without being able to participate. Most are going to be intellectually stunted by it.
> First of all, let’s start with stating the obvious: most devices will have to talk to legacy services. This post will not argue against this, despite excuses for this decreasing.
> Luckily, IPv6-only devices can still talk to IPv4-only ones, and this is getting easier than ever before.
Ended up just paying for an IPv4 address to avoid the hassle.
I don't think this is "the year of IPv6" but it might be its decade.
(Though I agree there should be no such distinction, in a real P2P internet)
As a Spectrum Business customer, I wish I could tell you whether or not that was true, but IPv6 isn't available to me at all. I'd happily (okay, not happily, but I'd be willing to do so) pay for an IPv6 block (I currently pay for five static IPv4 addresses -- one of which is eaten by Spectrum's required router, the other eaten by my own router, but that's a different discussion..Grrr!), but I can't even do that -- as it's not even on offer here (NYC).
It seems that there's wide disparity in how/where Spectrum implements its IPv6, so YMMV.
Also IPv6 doesn't actually work reliably. You'll notice it when browsing the web for example, there are periods of 2-3 seconds without IPv6 connectivity. This does not happen on IPv4.
Ha! I have an iPhone 15 and when I switch to mobile I get an IPv4-only address! My mobile provider is Verizon. I assume results are going to vary drastically based on region. I feel there are a lot of assertions in this article without any real data to back them up. If it makes any difference, AS6167.
APNIC 34 (2017) presentation on Verizon and IPv6:
* https://www.apnic.net/wp-content/uploads/2017/01/vzw_apnic_1...
Also, a 2017 presentation on T-Mobile US going IPv6-only:
* https://www.youtube.com/watch?v=nNMNglk_CvE
Also ask nicely, maybe today'll be the day they offer up a v6 route :p
1. https://www.caida.org/archive/id-consumption/census-map/
(* Legacy space doesn't even have that)
The only thing I can see replacing it is if something I'll call "easyip" came around - something even more convenient than ipv4 for networks of under, say a few hundred devices
Only if you’re not the one who’s responsible for designing and managing cidr allocations
Again, the only replacement I can foresee is for an address schema that either doesn't pretend to even attempt global space or has a UUID scheme where network addresses are immutable, globally unique and inviolable.
This would potentially simplify an iot world if the addresses are known, globally unique and static.
You mean like IPv6 ULA? =)
No.
Currently when you get an iot device you usually connect to it through the smartphone, tell it your Wi-Fi hotspot, give it the password and have it go online.
Instead there could be a flow of going to the routers interface, select "scan new qr code" and you add the device that way - more realistically this would be done through the "myspectrum" or equivalent app as the isp usually issues the modem/hotspot for the majority of consumers.
A number of things would have to change to make that possible but it's a much easier setup flow and it likely requires less complex software on the device itself.
If you want really simple solution on device itself, just let it NDP for router info and drop any incoming SYN that's not already in the conntrack table or part of the ULA space. Boom - done.
(The only answer that makes sense here is supporting legacy devices, which will probably be a problem we'll have to deal with for the rest of our lives. Thankfully I don't appear to have any such devices on my network!)
Not that I'm advocating anyone use that particular subnet of fc00::/7 for their local network.
I dual-stack for my internet gateway.
IPv6 networks are simpler. They do many things automatically that have to be entered manually. The big one is don't have to worry about subnet size or subnet masks; all subnets are /64 and effectively infinite. This doesn't matter for home network but it is big advantage for corporate networks.
All I really need is to be able to accommodate IPv6 on the internet side, which I can currently do.
Alas, being on the global namespace means being dependent on your ISP** - what if they renumber or you want to move ISPs? - or going through the bureaucracy of registering your own block. Yes, despite an infinite space you still need to register to avoid fragmentation. That's something I never want to do.
* For example, IPv6 ULAs have a stupid lookup precedence - IPv4 addresses are higher which means ULA can't be used anywhere which is dual stack.
** There are ways around the latter like ULAs (see above) or using a local DNS (more mess if it fails, assuming everything supports this), or NPT - which would work, but again, the community hates anything that reminds of NAT even when it's totally stateless, so this is little documented. I don't think going against the entire community is a worthwhile endeavor. This should also limit your choice of routers since IIRC not everything supports this.
Not necessarily: as IPv6 becomes more and more mainstream (Google is saying 50% traffic), the need for IPv4 will become less, and so it may be relegated to 'legacy' status and a secondary consideration.
I have yet to meet an infrastructure engineer or even hear of one who switched to IPv6 on purpose because they thought it was better. They always switch because they have more than 65k servers or to support mobile better. I feel like the people in charge who say that we should all move to IPv6 are the same people that we should that say we should all move QUIC and for the same reason: mobile clients like it better. But it's just not useful on the server side.
You're just relying on a kludge that fucks up addressing which was only invented because there weren't enough addresses.
IPv6 where your home network or backend infrastructure is a transparent glass house is a failure by design. I hope I never get to be a DevOps and support that. Or have IPv6 in my home network. One bad firewall rule or insecure port open, and you get ransomware in your face.
I have met a lot of infrastructure engineers who do that... then never give the people who need access access. So the system just sits and collects dust.
You have users. Acknowledge them. The network shouldn't even be the primary security boundary to begin with.
One bad firewall rule or insecure port open
Firewall !== routing. Nobody said you can't run a border firewall on your home network.
The former sound like a management problem. One call from up above and access will appear.
If you're running a NAT, you're already running something much more complex than that.
It's not rocket science for CPE manufacturers to make "outbound connections only" the default. My home router does just that.
It's such a huge risk to show people what is in my network. It's such a huge risk to the business. It makes no sense to It makes no sense to reveal that. But I suppose telling you is not worth anyone's time, you're just going to say you like it better because you're a mobile developer.
> you're just going to say you like it better because you're a mobile developer.
Not sure what issues you have with mobile developers, but I'm not one, not that it should matter if the argument is sound.
Well... too bad? Do you want security or not?
> neither is my mother, who also has a home network, etc.
If your hypothetical non-technical mother just buys a normal off-the-shelf router (+AP+switch+...) then it'll already have a firewall by default. It's not like end-users are expected to design/implement these things themselves.
NAT is provided by a stateful border firewall.
Are you using NAT on your border device? Gratz, you're running a border firewall on your home network.
In my case, that worked... Sometimes. It really doesn't scale. At all.
Are IP addresses really such sensitive secrets from your POV?
https://datatracker.ietf.org/doc/html/rfc8064
* https://datatracker.ietf.org/doc/html/rfc3041
Updated in 2007:
* https://datatracker.ietf.org/doc/html/rfc4941
You also don't have to use the MAC-based addresses on the server either. You can generate a random address and use that for your service.
Or you can regularly generate addresses on the server and update DNS so that the service has a new address every x hours or days. Or you could have the server not have any 'public' addresses, and whenever a new client wants to connect a new address is generated just for that client (with a TTL).
The thing about v6 is … you can just firewall permit like the entire North America block to whatever ports absolutely must be exposed … and just not get any attacking traffic?, at least if the address isn't somehow otherwise discoverable. This isn't possible on v4 (there is no such block, due to the space's fragmentation), and opening up v4 otherwise does expose you to a cesspool of incoming maliciousness. (Though … there are tools for this.)
If there was decent tooling available to me for "here are the IP addresses of the userbase" (e.g., some sort of phone-home system) that could keep the firewalls in sync with reality, I'd be more enthusiastic about it.
But the status quo is largely "security teams want IP firewalling, but don't want to figure out how to actually implement that in a manner that it will realistically work and not waste engineers time filing dozens of security requests".
I have a live feed of packets dropped by my firewall's "deny incoming on WAN by default" rule for fun, and I do occasionally see v6 packets being dropped. They're random addresses under the /48 that was delegated to me but which don't actually belong to any devices. So it doesn't seem to be because someone is actually harvesting IPs from my outgoing traffic, just guesswork. There was also one time where someone was very methodically testing every /64 by incrementing one at a time, with random bytes in the lower half, ie 2001:db8:abcd::$random, 2001:db8:abcd:1::$random, ...
The vast majority of dropped packets are v4 though.
WAN will not sent such malformed packets in the first place, unless we are talking of mom and pop ISP.
Of course. Unless you add rules to allow incoming traffic, say a rule to allow incoming traffic for $LAN_MACHINE1_IP:$PORT/tcp, to cross from WAN to LAN.
>At least with NAT there is a known set of rules regarding how masquerading works, that I can reason about.
The reason the scenario in my previous comment doesn't work has nothing to do with NAT. The reason such a packet would be dropped is because the firewall has a rule to filter bogons on the WAN interface. More generally, your home network firewall will have a default rule to block all incoming traffic on WAN unless explicitly allowed via additional rules, and that applies to both IPv4 and IPv6.
>WAN will not sent such malformed packets in the first place, unless we are talking of mom and pop ISP.
Well if you trust your ISP so much then I assume you just have your firewall turned off always, right?
Yes!
> How does that work?
Stateful firewalling.
It's much simpler than NAT masquerading tables. Just imagine a NAT, but with all address and port mappings being the identity function.
With a default-deny rule in a stateful firewall?
Publicly addressable ≠ publicly reachable.
People also don't seem to have any issues getting hit by ransomware even in a world full of IPv4-only networks and NATs.
Also my network (dual stack) is quite orderly as far as I can tell, thank you very much. I promise I won't ask you for help if that ever changes, if it helps :)
No, it's like you're a fish trying to explain flying to birds.
You don't understand the fundamentals of IPv6 (among other things, in other comments you have revealed that you think IPv6 addresses are MAC-based, think Comcast is a wireless ISP, and aren't aware of stateful firewalls). You have so many misconceptions about IPv6 it's no wonder you hate it.
Please refer to RFC6092 "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service" (Jan 2011)
(Despite the 'recommended' in the title, this is made mandatory by other specifications.)
It does exactly what you ask for: "Proper security is when everything is closed off and inaccessible by default."
Not only that. PCI DSS explicitly requires hiding the network topology from outsiders - even though they cannot connect. So it is either NAT or very short-lived IPv6 addresses, and guess what - for internal audits of who did what, NAT works better.
only if you chose it be.
It doesn't differ from a public routable IPv4 block at all: or you explicitly allow anything being routed to addresses in that block - or not
To be honest, I don't care at all what the site I'm trying to reach does internally after it terminates my connection to them via either IPv4 and IPv6 – just don't pretend that IPv6 is not a thing.
You can NAT IPv6, but it really sounds like you're doing security-by-obscurity, which is less than rigorous. If your servers are properly secured you should be able to publish a complete list of your servers and their IPs on your website and not impact your security at all.
> I have yet to meet an infrastructure engineer or even hear of one who switched to IPv6 on purpose because they thought it was better.
I have. His designs were often... aspirational.
(And I say this not in jest or to be patronizing, I say this as a warning re. your security.)
Whether this applies to NAT is a different question.
Security by obscurity if these servers could be reached if you knew their "real names". In case of NAT, no amount of information will let you access these machines, so it is proper security. It is almost as good as airgap.
With IPv6, knowing addresses of these machines will let you spam them with packets and possibly breach them the second firewall goes down for any reason.
If you have a firewall, then no amount of information will give you access either.
> the second firewall goes down for any reason
Is this like... a thing that you've actually seen happen? Because it really sounds like something that at best happened 20 years ago in a freak accident that will never happen again. If we're allowing equipment to just randomly break to that degree then I get to assume that your NAT will just forward incoming traffic directly to servers.
With NAT, there's no obvious way to connect from the outside to the inside, because the inside cannot be addressed from the outside.
Well... yeah, if you open a port then the port is open. Since every firewall I've seen - including the ones in cheap garbage home routers - defaults to deny all inbound / allow all outbound, that's not the "default state", that's something you have to specifically add. (And again, same applies to NAT; you can add a port-forward rule, but if you care about security maybe don't.)
> With NAT, there's no obvious way to connect from the outside to the inside, because the inside cannot be addressed from the outside.
I am precisely concerned with the non-obvious ways. If we're talking about a server environment where every single device on the private subnet is trusted and doesn't get compromised, no ports are forwarded, there is no DMZ, and UPnP is absent or disabled, then it might work, but I would still trust it less than a firewall. In a home or office environment those constraints go out the window (UPnP was quite popular once, IoT ensures there's an endless supply of untrusted devices, and, y'know, Cross-Site Scripting attacks making every device with a browser a potential threat), which is probably why I have the cached heuristic of "don't trust NAT for security".
As someone who have been running IPv6-only services and before that, IPv4-only services, I find this premise to be untrue more or less.
Indeed, my topology is exposed to the internet. But no one has ever exploited that, because IPv6 networks are huge, super huge.
At best a random attacker will be able to tell which network one of your servers is located in, but they cannot find the other networked equipments inside this network. No one in their right mind will bother with your 2^64-sized network like how they did with IPv4.
Around 10 years ago the company I worked for used ipv6 to successfully deal with huge number of ephemeral VMs. It was a great solution.
I saw Fly.io using similar approach for their internal networking so I assume they did it bc they thought it was better as well.
So now you have.
Of course it's great for ephemeral stuff. It's just that most people don't have that problem and it's a huge pain to use it for anything else.
So no, I haven't.
> Of course it's great for ephemeral stuff. It's just that most people don't have that problem
A lot of people run containers these days. It’s not unusual to have endpoints in the tens of thousands or more and there are other considerations that make ipv4 management hard/impossible
And I manage a kubernetes container stack. It's simple, you NAT k8s connections to the outside network, or more likely use an nginx ingress.
I find it hard to believe that "huge" exceeds 65,536, which is how many addresses you get with a /16.
With ipv6 you can just assign every actor a /96 and they get 4 billion IPs to play with
Go talk to the infra people at Comcast. Their infra network is 100% IPv6 and their customers are almost exclusively fixed-location.
> ...I don't see the point of it.
I've personally seen (on more than one occasion) the IT infra mergers of pairs of companies delayed by 12+ months because of the need to renumber (and/or decom because there's just not enough IP address space) machines using RFC 1918 space. RFC 4193 eliminates the need for renumbering.
There are many other reasons for it, but that's one of the ones that tears my heart to pieces each time I have to use multiple VPNs for a year or more while the Great Renumbering is underway.
There are mobile providers so your argument is invalid. Also on the server side they are a famous case of people who need more than 65,000 servers which I covered in my comment.
And renumbering is so, so much easier than switching network stacks. It'd be years to switch network stacks, not only to change over the addresses but also to change over entire business processes and higher swaths of security engineers to keep track of your now much more vulnerable network. It would be a business change, not just a network change.
I'm thinking people connecting iPads and lightbulbs to some CPE, not data centers. And Comcast does that via IPv6, as do many cable or fiber ISPs these days. Many don't assign public IPv4 addresses to their residential customers anymore.
It's that, sure. But it's also Comcast's internal infrastructure devices. Comcast went all-IPv6 on their internal network because they have so very many things that they need to directly address... _internally_... that IPv4 wasn't cutting it anymore.
Even if they didn't provide IPv6 service to their end-users, they'd still be using IPv6 on their internal network.
When was the last time an attacker punched a hole through a firewall device?
Attacks generally start from compromising a user machine (e.g., phishing) or a server (via server-software exploit), installing some malware on already-internal machine, and start probing from there. Not being able to see the internal topology has hindered precisely zero network compromises.
> While we definitely need firewalls and/or packet filters at the network edge, most of today’s attacks work on application-layer, using SQL injection or “Advanced Persistent Threats” like sending an Excel or PDF file with a 0-day exploit to a click-happy user.
* https://blog.ipspace.net/2011/12/is-nat-security-feature.htm...
You may wish to start thinking beyond the castle-and-moat network security model:
* https://www.cloudflare.com/en-ca/learning/access-management/...
---
IPv4+NAT does not remove any more classes of problems than IPv6+firewall. Firewalls under IPv6 work exactly the same way as they do with IPv4:
An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table(s) it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.
The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.
With IPv6 the address/port rewriting is not done.† Only state tables are updated and checked.
New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.‡
There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence.
NAT is not a security feature but a workaround for the lack of IPv4 addresses. The security comes from the state checking.
† It is possible to have private IPv6 addresses using ULA, and then the router/firewall uses NPTv6 to rewrite the prefix (leaving the /64 interface component alone).
‡ Just like with IPv4 (NAT), to allow unsolicited 'new' connections in you have to do do firewall hole punching with (e.g.) UPNP. But by default things are blocked.
T-Mobile US:
* https://www.youtube.com/watch?v=nNMNglk_CvE
Wells Fargo:
* https://www.youtube.com/watch?v=EzTWjNUb4H4
Microsoft
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
* https://www.youtube.com/watch?v=nd0vgU6WbPo
Google:
* https://www.youtube.com/watch?v=hb98hAb5_W8
LinkedIn:
* https://www.youtube.com/watch?v=6ukwR86BClY
Facebook is famously IPv6-only internally (and as of 2016, 60% of user traffic was over IPv6):
* https://www.internetsociety.org/resources/deploy360/2014/cas...
* https://engineering.fb.com/2017/01/17/production-engineering...
* https://www.youtube.com/watch?v=lU_24f6Wr7E
[1] https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-run-out/
So... yeah, for that reason I do need to keep using IPv4, at least until either 1) AWS gets its act together; or 2) my employer moves away from AWS (which is very unlikely).
[0] Hyperbole... but probably not that unrealistic.
But as the article points out, it doesn't really matter. You could run a NAT64 service of your own, inside the VPC that AWS gives you. Your own systems can then be IPv6–only, saving you money while still using AWS services that still don't support IPv6.
And no, the LAN subnet isn't in the ULA or link-local space.
In your case it's a static assignment, but otherwise it can be assigned via DHCPv6-PD (when your router asks for a WAN IP using DHCPv6, it also gets told that some prefix like your /48 has been "delegated" to it). The result is the same.
Okay, now it makes sense. I'm not sure how else I expected it to work.
Your "WAN" is a small transit subnet between your router and your ISPs, while the "LAN" is the actual public ip space you will be assigning to your end devices.
>If an address is publicly routable, what's "LAN" about it?
Routable or not, it's LAN because it's in your network behind your router. It's just an identifier.
For IPv4, you will be given <some random IP> on the WAN side and typically you assign 192.168.x.x (or other RFC1918 addresses) to your devices on the LAN side.
For IPv6, you will be given two random IP blocks with similar usage as the IPv4 ones, except that the LAN side is now publicly routable.
/sarcasm
With single server, there aren't the networking advantages to using IPv6 internally.
"When" is the only remaining question.
The term is hinging more on the on-demand aspect of "X as a Service".
To use an analogy, IPv4 was like the harddrive of a computer. Removing it rendered the computer inoperable. But nowadays some ISPs are moving towards an IPv6-only core (much like how modern PCs are moving towards solid-state drivers) and IPv4, becoming IPv4aaS, (like the HDD becoming an external HDD) is no longer an integral part of the ISP network.
IPv4aaS simply means that: IPv4 is now removable.
We haven't removed IPv4 because right now, the HDD still contains a lot of stuffs so although unplugging it does not render the computer inoperable, it'll still create a giant headache. That's the on-demand part of IPv4aaS. Doesn't mean it'll be plugged in forever, and don't expect it to be when half of the Internet is already on this analogical SSD.
I’ve been hearing that I need to prepare for IPv6 for the past 20 years, and the benefits are always exceptionally vague or don’t apply to me. I’ll check back in a few years from now.
If my network wasn't prepared with IPv6, I'd had experienced dialup-era speeds for an entire week, but since I was, only half of the Internet were unusable. After some DNS tricks, I was actually able to browse the Internet entirely on IPv6 minus a few websites, Imgur being one of them.
But as the saying goes, ignorance is bliss. ;)
[0]: https://reddit.com/r/ipv6/comments/1as8dvy/is_there_a_way_to...
https://web.archive.org/web/20240411000150if_/https://blog.d...
I have a bunch of services that I host from home, and with my previous provider (and country) I had a static IP with all the associated DNS and DMZ stuff to make it work.
I was about 2 days into a VPN rabbit hole when I discovered that Virgin gives out IPV6 AND IPV4 IPs, and that the v6 ones are publically routable! I was able to access my hosted service by plugging in the server and going to it's IPv6 address on my phone. Some quick Cloudflare IPV4 to IPV6 proxying later and I'm up and running as before. Can now access the service from any internet network (even IPV4 ones). No more DMZ, port forwarding, etc. Happy days.
So yes, I moved away from V4 in about an afternoon, no issues.
I'm not sure if the IP is static though. The server has a reserved V4 IP for internal stuff, I hope the router is clever enough to then keep the V6 one also static. With the address space being so large, I guess giving clients entire blocks of addresses that are static is perfectly fine?
Also, IPv4 has nothing to do with "identification", does not work like that, is not used like that, does not matter in any ways, nor does ipv6
This is such a strange chain of reasoning.
1. With IPv4, IoT management must go through a centralized service due to NATs.
2. With IPv6, IoT management may go through a centralized due to corporate greed.
You see the difference there? This reasoning is unsound because it's more or less "we shouldn't eat because we'd choke on food".
>Ipv4 is a very important protocol because it accidentally protects against casual identification from the Facebooks, Apples, Googles, Amazons, etc
Coincidentally, if the world is stuck on IPv4 then hobbyists/"privacyists" will be the group of people who are hurt the most. Hosting a service is becoming more difficult when CGNAT is imposed on everyone, everywhere.
It shouldn't be difficult to imagine a future (as a matter of fact, it is happening now) when, to host a server, you _must_ rent a VPS or something from the tech companies since it's impossible to do it from home. Does your VPS provider allow you to host Tor services? Run BitTorrrent?
IPv6 from your ISP, fine, but once internal IPv6 is overly complex and unnecessary. Despite the claim to the contrary NAT is a feature, not bug.
The future for IPv6 is that Firewalls/Routers will handle IPv6 for the public addressees, then NAT to internal IPv4's.
How would this IPv4 internal host (say 192.168.1.10) send a packet destined to 2001:db8::1? You can't stick a 128-bit IPv6 address into your IPv4 packet - there are only 32 bits available for the destination address inside its header.
NAT is not magic, it cannot extract a 128-bit number out of your 32-bit number.
For your education:
https://en.m.wikipedia.org/wiki/NAT64
I have deployed NAT64 in multiple networks before.
NAT64 is used when you have _internal_ IPv6 hosts who want to reach the _external_ IPv4 hosts. In order words, 2001:db8::1 can send something to 198.51.100.1 but not vice versa.
Your proposal is that we use IPv4 _internally_ since you think "internal IPv6 is overly complex" and we should "NAT to internal IPv4's". It doesn't exist since IPv4 is inherently forwards incompatible.
"HN doesn't understand the Internet Protocol" strikes again.
The big advantage is that don't have to worry about subnet size. No deciding how big subnet is going to be, and either making it too small and having to resize or making it too big and wasting space.
IPv6 is more complicated in that supports multiple addresses, but that is an advantage. For internal use, assign ULA addresses and route those over VPNs. For accessing Internet, computers use the ISP assigned addresses. Then assign fixed addresses from hosting provider to load balancers and external servers. This means that only Internet only sees random addresses; they know the provider but that is known with IPv4.
The S in IoT stands for security, of course. But it's going to be a bummer if my IoT devices forces me or my guests out of my network.
IPv6 can be made stateless with SLAAC so DHCP (and any DHCP-related limitations in the router) are completely out of the picture.