Do You Need IPv4 Anymore?(blog.daknob.net)
blog.daknob.net
Do You Need IPv4 Anymore?
https://blog.daknob.net/do-you-really-need-ipv4-anymore/
178 comments
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.
Tailscale can solve this problem
[deleted]
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?
Tailscale funnel does that, except the DNS uses the tailscale domain.
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 :)
Related question: I asked my ISP for IPv6 and they gave me a static assignment like this:
And no, the LAN subnet isn't in the ULA or link-local space.
WAN: A:B:C:D::1/126
LAN: A:B:110::/48
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.
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.
> Traffic for that /48 will be routed to your router.
Okay, now it makes sense. I'm not sure how else I expected it to work.
Okay, now it makes sense. I'm not sure how else I expected it to work.
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.
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.
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.
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.
[deleted]
Nah the point was that the public IPv4 space has run out. Anything like removing NAT or making everything routable is just more icing on the cake.
> 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.
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.
It's 464XLAT most of the time for mobile operators.
> Ha! I have an iPhone 15 and when I switch to mobile I get an IPv4-only address! My mobile provider is Verizon.
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
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
In your case is it CGNAT IPv4? Typically see that these days on mobile or cellular based ISP carriers.
I don’t believe so. The netblock is 174.192.0.0/10. I think CGNAT is all 100.64.0.0/10?
Not the parent, but in my case, it's a DS-Lite address.
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.
I get IPv6 on verizon
IPv4 will be around forever. It'll just get more expensive.
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
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
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!)
(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!)
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.
I dual-stack for my internet gateway.
I dual-stack for my internet gateway.
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.
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.
All I really need is to be able to accommodate IPv6 on the internet side, which I can currently do.
Can't speak for GP but I regularly type IPv4 addresses manually. That probably makes me a heathen but it just feels easier a lot of the time.
"fc12:3456::1", "fc12:3456::2", "fc12:3456::3", etc, seem pretty easy to type, no? It's literally one extra character compared to "192.168.0.1"
Not that I'm advocating anyone use that particular subnet of fc00::/7 for their local network.
Not that I'm advocating anyone use that particular subnet of fc00::/7 for their local network.
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.
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.
For a novice running a home network or lab there are a seemingly-endless number of on&offline resources and soft&hardware tools with IPv4 capability.
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.
Can't you use ULA addresses for this?
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
> It's way more convenient to work with.
Only if you’re not the one who’s responsible for designing and managing cidr allocations
Only if you’re not the one who’s responsible for designing and managing cidr allocations
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.
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.
You mean like IPv6 ULA? =)
You mean like IPv6 ULA? =)
I just read the Wikipedia on that.
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.
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.
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.
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.
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?
1. https://www.caida.org/archive/id-consumption/census-map/
1. https://www.caida.org/archive/id-consumption/census-map/
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 :(
(* Legacy space doesn't even have that)
(* Legacy space doesn't even have that)
> 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.
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.
Yes, and thus the people who need an IPv4 address really need an IPv4 address, and you can charge them for it. And they will pay whatever you ask.
We are past IPv4 peak prices though.
No one will ever convince me that running a local IPv6 network is a good idea.
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.
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.
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.
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.
This patently false, you should do more research before you make comments to inflate your ego.
For your education:
https://en.m.wikipedia.org/wiki/NAT64
For your education:
https://en.m.wikipedia.org/wiki/NAT64
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.
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.
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.
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.
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.
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.
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.
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.
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.
It seems you're running a "service" on a customer line? That's not exactly what they're selling them for...
(Though I agree there should be no such distinction, in a real P2P internet)
(Though I agree there should be no such distinction, in a real P2P internet)
Spectrum also sells business internet service, where you can have static IPs, speak to real engineers, etc.
I'm hoping/assuming/guessing those won't have that odd IPv4/IPv6 switching behaviour...
>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.
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.
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.
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.
> 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.
Well, as this post discusses, the end devices don’t need IPv4 to talk to IPv4-only services.
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.
"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.
[deleted]
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.
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.
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.
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?
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.
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.
If you can’t access IPv4, I don’t think you’re going to make it as an ISP
Some ISPs are now providing "IPv4 as a service", i.e. they are IPv6-only throughout their entire network infra and can easily pull the plug on IPv4.
"When" is the only remaining question.
"When" is the only remaining question.
Never lol, theres no chance any ISP decides any time in the next decades to drop NAT64/DNS64 at a minimum
Yes, but compared to 10 years ago where dropping IPv4 is a technical challenge, dropping NAT64 can quite literally be the same as pulling the plug.
Sounds like an interesting business model—I guess we’ll see if they survive.
T-Mobile seems to be alive and well ;)
Wasn’t aware that T-Mobile is charging for access to IPv4… is there a link to more info about this surprising turn of events?
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.
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.
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.
But as the saying goes, ignorance is bliss. ;)
[0]: https://reddit.com/r/ipv6/comments/1as8dvy/is_there_a_way_to...
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...
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_...
/sarcasm
/sarcasm
My ISP is still IPv4 only, sadly. So, yep.
Reminds me of the day when RIPE NCC announced that they had run out of IPv4 addresses. [1]
[1] https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-run-out/
[1] https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-run-out/
Can you tell Github about this?
$ dig -t AAAA gitlab.com.
gitlab.com. 300 IN AAAA 2606:4700:90:0:f22e:fbec:5bed:a9b9
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.
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 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.
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.
> 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.
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.
> Go talk to the infra people at Comcast.
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.
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? Comcast is primarily a fixed/wired network provider.
Still a case of over 65,000 servers. But yes they also still do run a mobile network.
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. 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.
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.
> 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.
I have. His designs were often... aspirational.
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.
That's not security by obscurity.
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.
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.
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.
With NAT, there's no obvious way to connect from the outside to the inside, because the inside cannot be addressed from the outside.
>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.
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.
> 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".
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".
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.
If obscurity is the only thing you have, you have nothing.
(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.
(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.
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.
> 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.
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
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
> 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.
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.
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.
So you fall in the more than 65,000 servers camp then.
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 and it's a huge pain to use it for anything else.
So no, I haven't.
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
> 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
Yeah, I have. Not that big of a deal. Most of it's just good network planning. We were able to get around the problem.
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.
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 worked for used ipv6 to successfully deal with huge number of ephemeral VMs.
I find it hard to believe that "huge" exceeds 65,536, which is how many addresses you get with a /16.
I find it hard to believe that "huge" exceeds 65,536, which is how many addresses you get with a /16.
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
With ipv6 you can just assign every actor a /96 and they get 4 billion IPs to play with
What does "useful on the server side" mean? And how useful is a server really that can't (efficiently) serve any clients because they're all on IPv6?
Depending on your architecture, it's easy to run dual-stack to the load balancer, and then pure IPv4 or IPv6 internally without any problems.
That's fair.
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.
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.
Do security properly.
You're just relying on a kludge that fucks up addressing which was only invented because there weren't enough addresses.
You're just relying on a kludge that fucks up addressing which was only invented because there weren't enough addresses.
Seems to me that IPv4 was invented back when cybersecurity was much less of a concern.
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.
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.
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.
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. 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.
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.
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?
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.
This has not been the case since RFC8064 (2017). Modern systems use stable, non-MAC-based IIDs.
https://datatracker.ietf.org/doc/html/rfc8064
https://datatracker.ietf.org/doc/html/rfc8064
Actually 2001:
* https://datatracker.ietf.org/doc/html/rfc3041
Updated in 2007:
* https://datatracker.ietf.org/doc/html/rfc4941
* https://datatracker.ietf.org/doc/html/rfc3041
Updated in 2007:
* https://datatracker.ietf.org/doc/html/rfc4941
> 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).
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).
I don't want to run a border firewall on my home network, because I am not devops, neither is my mother, who also has a home network, etc.
The former sound like a management problem. One call from up above and access will appear.
The former sound like a management problem. One call from up above and access will appear.
> 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.
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.
> I don't want to run a border firewall on my home network
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.
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.
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.
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'm responding to GP, not you, who mentioned their home network, not your business network.
> 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.
> 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.
> I don't want to run a border firewall on my home network...
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.
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.
One call from up above and access will appear.
In my case, that worked... Sometimes. It really doesn't scale. At all.
In my case, that worked... Sometimes. It really doesn't scale. At all.
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.
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?
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?
> So my home network appliances have public IPv6 addreases, but everything sent to these addresses is null routed?
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.
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.
> So my home network appliances have public IPv6 addreases, but everything sent to these addresses is null routed? How does that work?
With a default-deny rule in a stateful firewall?
Publicly addressable ≠ publicly reachable.
With a default-deny rule in a stateful firewall?
Publicly addressable ≠ publicly reachable.
It's a stateful firewall. New, incoming connections are denied. Outgoing or established connections are permitted.
Same for IPv4 and one bad port forwarding rule, no?
People also don't seem to have any issues getting hit by ransomware even in a world full of IPv4-only networks and NATs.
People also don't seem to have any issues getting hit by ransomware even in a world full of IPv4-only networks and NATs.
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.
Well, what's the difference?
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 :)
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.
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.
> IPv6 where your home network or backend infrastructure is a transparent glass house is a failure by design.
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."
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."
> 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.
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.
> IPv6 where your home network or backend infrastructure is a transparent glass house is a failure by design
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
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
> 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.
* 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.
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.
Glad the title wasn’t “IPV6 is all you need”
[deleted]
I can't reach any IPv6 addresses from Comcast/Xfinity soooooo...
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.
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.
Can you tell github about this?
exabrial(2)
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?