Part of me feels like this will not be enough if they continue to give huge blocks away. We will find trivial ways to use them. ipv8 or ipv16 or ipv1024 will come in our life times.
Sadly at the same time in many countries IPv6 is next to non-existent[1]. I follow closely when China will adapt it, since was announced long time ago, but seems no progress since.
The three major ISPs in China just deployed IPv6 in most cities, though IPv6 based routing and DNS is still suboptimal. I don't know how Google generate the ipv6 statistics, but in the case of China it may not be very accurate. Most Google services are blocked there.
I live there and I don't see a change. Other, non-Google counters are also not very optimistic.
EDIT: My bad, I just checked today and there are positive changes - all my connections are now IPv6, mobile and fixed line. The IPv6 speed as opposing IPv4 one is very low though...
That chart seems very hopeful to me. Constant linear growth. I expect there will be a tipping point where enough people have it that some smaller sites go v6 only to cut costs and the rest of ISPs are forced to adopt it. My vps provider gives you a $2/month discount if you don't take a v4 address.
A thought: you could address all the bits in a 1TB hard drive with 8e+12 IPv6 addresses. Meaning you could do this with up to 4.25e+25 1TB hard drives.
Makes me wonder if this could be used as an obfuscated comms channel? (I'm sure there's a term covering it, steganography doesn't quite describe it).
If you owned a bunch of ipv6 addresses on multiple ISPs, you could use the timing of pings from these addresses as a comms protocol. You could even rotate IP addresses and use the modulus of the address to add a layer of obfuscation.
Quiet hosts with an unpublished v6 address are AFAIK impossible to discover in a better-than-linear-scan fashion from other networks (e.g. The Internet).
No different than obfuscating in higher level abstractions on a single IP as has been done forever. In either case you are getting a block of identifiers which have guidelines on how they should be used but no enforcement by design of the protocols.
As an example things like port knocking can be carelessly translated into IP knocking. Doesn't make it any sneakier though, just less header.
This is true of IPv4 ICMP as well. Same PMTU issues, but many IPv4 implementations fallback to allowing in-path packet fragmentation by the routers (which IPv6 discontinued), which is less visible breakage but still inefficient/problematic.
It's also slightly more complicated than "outbound allow, inbound deny" because you want to accept reply packets to the outbound ones, using something like the iptables "-m state --state related,established" match.
NAT is not an 'implicit firewall'. Firewalls do packet filtering, NAT mangles routing. These are different things.
If you're trying to solve the problems of "How do we stop anyone on the internet sending packets to grandma's open ports?", then the answer is a packet filter. Thankfully, must sane consumer routers come with these.
NAT overloading private IPs onto a single IP (what 99% of consumer routers are doing) is an implicit firewall. Without additional protocols like UPNP or manual configuration of port forwarding, nothing behind this style NAT can receive unsolicited traffic.
“Mangling routing” to a single source IP requires state tracking of outbound sessions to know where to send inbound traffic. No outbound traffic, no session, no inbound traffic.
Nobody is advocating replacing cheap NAT home routers with unprotected routers. They're all advocating replacing cheap NAT home routers with cheap stateful firewall home routers.
What the GP is trying to tell you is that you're conflating sateful filtering with NAT. If you rip the address translation part out of a NAT implementation, you get a stateful firewall. You're probably better off with a purpose-designed stateful firewall, but ripping the NAT out of NAT works and is an obvious reduction in complexity.
Insisting that you lose packet filtering if you get rid of NAT is a straw man argument. Nobody is arguing for that. They just want to remove the address mangling portion of the cheap router while keeping the packet filtering.
No it's not. Case in point, I've had a misconfigured router provided by an ISP with proper NAT but bad firewalling, and hacking on routes allowed me to jump into neighbors LANs on the same ISP. Crazy.
If NAT is an implicit firewall, then so is an unplugged network cable. I guess it's technically true, but isn't a particularly meaningful assertion - you might as well say that NAT is also 'not a donkey'. Again, technically true, but doesn't really help.
Firewalls are packet filters. Confusing routing and packet filtering doesn't help anybody solve any problems.
We're talking (I think) about how to mitigate threats from the public internet by dropping unwanted traffic with IPv6. The answer is a firewall (as it is with IPv4).
I can hook grandma up with a $30 chinese NAT box, disable UPNP and she's mostly safe from all sorts of port knocking attempts - while still having internet that seems to work great for her.
What would be the ipv6 equivalent? You can call it a donkey all you want.
The problem is that you can perfectly fail at implementing a firewall without breaking access to google.com, whereas broken NAT will mean no google for you. A bridge is not NAT with some features switched off, it's an entirely different topology. A v6 router without the firewall will still be a router. When setting up, people just want "the internet" to appear in their browser, that's their definition of done and NAT made it extremely unlikely to get there with universally open ports.
> The problem is that you can perfectly fail at implementing a firewall without breaking access to google.com, whereas broken NAT will mean no google for you.
Google works fine, but when somebody sends the external interface of my router a packet with destination address 192.168.1.42 (as can often be done from any compromised router on the same cable segment), it gets forwarded to 192.168.1.42 on the internal network.
Exactly. Rip out all of that logic that maintains the address translation table and performs address mangling and you have a simple stateful firewall that's obviously less complex. It's difficult to see how ripping out the address translation could be more exploitable or costly to maintain. Ideally, we'd start with things written from the beginning to be stateful firewalls, but if I worked for a home/small office router ventor, my first course of action would be to just ripp out that potentially buggy address translation part of our existing NAT implementation.
My expectation is far far lower. And those that are might not still be decent after an upgrade (and you won't know if the hardware or software you buy will be of another revision).
Hardware that happens to be popular are often updated to a cheaper variant where the manufacturer rides on the fame and good reviews of the original version.
So you can't even do the research once and expect it to hold for future purchases/replacements.
No amount of FUD comes close to the reality when it comes to home routers.
usrusr explained it nicely. It will likely take years before anyone will realize that the firewall doesn't work at all. Whereas a similarly broken NAT router will be declared DOA.
But how so? If my public address gets a random packet and there are 5 devices on the lan side, which local address did those devices send unsolicited inbound traffic to? Where's the insecure part?
If your public address gets a random packet then the packet is addressed to your router, not one of your local devices. This is insecure if the router is providing some insecure service on that port, but otherwise it's irrelevant to this discussion.
The problem comes when your router receives a packet addressed to one of your local devices. Many people in this thread believe that if the router is NATing outbound connections, it'll drop this inbound packet, but that's not what happens -- the packet will actually be routed to whichever local device it was addressed to, just like any other packet would be.
This should be fairly obvious, because the only thing NAT does is change the apparent source address on outbound connections. It does nothing at all to inbound ones (and you can demonstrate this to yourself by setting up a test network in some VMs and NATing traffic between them with Linux and iptables).
(You can configure a NAT to do things to inbound connections using port forwarding rules and/or a DMZ, but those rules only apply to specific inbound connections. Connections not covered by those rules are treated as normal, and "as normal" for a router means normal routing.)
NAT isn't a firewall, because it doesn't drop connections. All it does is rewrite addresses on connections, not decide which connections can and can't be made.
> This should be fairly obvious, because the only thing NAT does is change the apparent source address on outbound connections. It does nothing at all to inbound ones (and you can demonstrate this to yourself by setting up a test network in some VMs and NATing traffic between them with Linux and iptables).
Absolutely. It's trivial to demonstrate how utterly useless a router configured with NAT, with routing, but without a firewall is. (Useless in the context of a home CPE device for the average home internet subscriber..)
As a side note, yes, packets arriving towards your router with a destination address on your LAN will be forwarded by the router piece of your router.. the firewall piece would prevent this. This is independent of the use of/absence of NAT though..
If one of those 5 tries to connect e.g. to a remote windows file server .. you now have an open port on your public IP which will accept packets from any IP on the internet and will forward them to the windows file share service on your desktop.
Add a stateful firewall with connection tracking, and that port is only open to the 1 server you tried to connect to.
Yes that's true, but not a problem for TCP since the attacker had to know the outgoing port from the ephemeral port range your PC or router picked, and then had to take over the running TCP session by additionally knowing the connections state (sequence number etc). For UDP you indeed have higher chances of talking to that device in an unsolicited manner, and this has been exploited by games and later Skype in the past. So yes, indeed more insecure, I stand corrected. I'm still more worried for actual exploits or security holes even in modern devices that can do proper firewalling the ISPs provide due to incompetence or laziness. Like the TR069 port being open on many devices two years ago.
Yes, the modem/router is likely buggy as hell, most "consumer grade" CPEs are. The best defence for that IMO is to remove as much code as possible - like the unnecessary for IPv6 NAT stack..
To the various remote management ports listening on the DSL modem itself. Between RCE vulnerabilities, accidentally unauthenticated management features or even just upnp listening on the WAN port, there are infinite means for owning the network behind the device.
But that's more of a general problem that still happens on modern devices, even with ipv6. ISP wants some port open on the device for remote management but is so incompetent that it's actually reachable worldwide.
Yes. I was just responding to the claim that with IPv4, thanks to NAT a malicious packet would not be able to be routed anywhere unsafe.
A NAT router without any kind of firewall functionality is incredibly unsafe too so even the cheapest ones have some of it these days.
Which follows that the cheapest IPv6 routers would also have a firewall and thus would not be inherently worse at protecting the internal network than a v4 router doing NAT would.
Exactly. Remove the firewall state, and you're wide open for all the NAT'd ports. And if someone thinks they don't have any NAT ports, they would be wrong. You likely have 10's or 100's ports NATd for every device activity being used on your network.
This seems to be agreeing with me and many of the others? A stateful firewall is a useful thing on its own, but it's also a fundamental requirement for modern NAT implementations.
NAT on the other hand is not a fundamental requirement for a firewall.
NAT bolts onto a firewall, and it's the firewall that provides the security. Remove NAT, and you haven't lost anything in terms of security.
A stateful firewall isn't a fundamental requirement for NAT though, even modern NAT ("or actually PAT", as other posters seem to like saying...). State tracking is certainly a requirement, but tracking state is separate from firewalling based on that state.
This is why firewalling is separate from NAT, and why NAT isn't a firewall. Yes, it's true that both NATing and firewalling rely on tracking state, and typically both NAT and firewalling are implemented together in the same software and hardware, but they're two separate behaviors and you can do one without doing the other.
> nothing behind this style NAT can receive unsolicited traffic
This isn't really 100% true though. Since IPv4 NAT was never standardized, many many variations exist in the wild and some can be exploited to send unsolicited traffic inside the network defeating the implicit "firewall" aspect of NAT.
NAT translates IPs. Firewalls allow or block traffic based on a policy. In some configurations (static NAT, port forwarding, etc. etc.), there's no firewall aspect to NAT at all. In others (PAT, what this discussion is mostly about), there's often an implicit firewall, but different implementations have widely variable behavior, and it basically should not be depended on as a firewall.
If you want to deny inbound unsolicited traffic, then you need a firewall.
This is true, and it's the very minor security benefit of NAT. However, without the stateful firewall in addition, you're wide open to attack.
Have a windows PC? Did you try access a network share that exists outside your network? Well, now the SMB port is open. Anyone on the internet can reach it. Hopefully your desktop has a stateful firewall to mitigate the hole in your router....
I don't think that remote network share access is very common among home Windows users, but Skype is. The last time that I pointed nmap at a PC with Skype on a conversation, the output of open ports was more than a screenful. Skype listens on literally tens of ports.
It's been a while since I used a windows machine that wasn't connected to a domain / managed by a IT dept... But isn't windows file sharing enabled by default on home editions? And from memory, no authentication is required to interact with the service - it's only after you connect, obtain a list of shares, and attempt to open a share that authentication becomes required - leaving plenty of room for bugs to be exploited.
At the end of the day, opening ports, any ports, is "dangerous".. A stateful firewall prevents much of the danger introduced by ports opened via NAT.
Right, but if someone thinks NAT on its own is protecting them... I'll bet they turned that local firewall off too the moment it got in the way of $thing they needed to do ;)
Not really, NAT will keep track of destination address as well so unless the network share outside the network is also the address of an adversary, the SMB port isn't open to the internet.
Your thinking of the firewall that's built into most consumer routers. The exact technicalities of NAT (PAT actually) are not super well defined, and many implementations will not track the destination address.
You need basically the exact same stateful firewall you already need with IPv4 even with NAT, except that with IPv6 you need to allow ICMP as well otherwise path MTU can break.
On the in chain - allow ICMP, allow established/related, block otherwise. Open up any additional ports as needed, just the same as you used to do with port forwarding before.
All routers, even crappy consumer ones should have a basic stateful firewall on by default. Hopefully with sane default settings.
It is nice because it's a xmas display, but it's nothing magic. IPv6 lets you do many things very simply, and it can get very messy too (which is fun by itself!)
They got a /48, and they got some inspiration. You too can get a /48 easily if you want to play! Even if you don't get a /48, you can do some messy play very easily.
My personal experience being messy: when I had to handle multiple containers on one actual computer, I had enough IPv4 addresses (like A.B.C.D) to give one per container, but just a single regular W:X:Y:Z/64 (the suggested minimum default for IPv6, like with SLAAC, while a /56 is often better even for a home network)
The provider wanted some insane amount of money for a decent IPv6 allocation while usually it's the opposite, and IPv4 is expansive but IPv6 is mostly free. I didn't want to use tunnelbroker to keep the latency low.
So I simply assigned W:X:Y:Z:A:B:C:D to each container -- because, why not? Yes it's wasteful, but it's easy to figure out which is which!
IPv6 make many creative things possible and simpler than what the equivalent IPv4 solution would be, simply because of space constraints.
> So I simply assigned W:X:Y:Z:A:B:C:D to each container -- because, why not? Yes it's wasteful, but it's easy to figure out which is which!
It makes me curious. Did you apply any service-discovery mechanism in your IPv6-based container cluster? I wonder if IPv6 makes orchestration easier, tougher, or actually things just work transparently.
No, I didn't do anything that fancy even if it's what I really wanted in the first place :-)
Full story: initially I wanted to do SLAAC with different subnets for the different physical computers.
To do that and use the MAC address of the containers in a "standard" way, I would have needed a larger subnet that what the provider even had for sale - but then everything would indeed have been much easier and automatic.
In case it's not clear, imagine having W:X:Y::/48 like the xmas tree example, then using Z to identify which physical computer the container is on: then A:B:C:D are automatically derived from the hardware address of the (here virtual) interface.
It's also very handy if you have multiple networks - say a wired and wireless setup: use a different value for each network on each site say Z=1 for your wired netword, Z=2 for your wireless, etc.
Then you can automatically populate AAAA records like computername.connection.site.yourdomain.com. Why is it cool?
Then if you need to check connectivity or push updates or whatever, you can ping6 ceolaptop.wifi.nycoffice.yourdomain.com- but don't worry, that IPv6 address will not be leaked if you are using the privacy additions (lft=0 aka deprecation): this laptop will use a "throwaway" IPv6 access so it can't be tracked (well, at least the mac address part, but good luck finding the needle in a haystack!)
See https://en.wikipedia.org/wiki/IPv6_address#Stateless_address... : A 64-bit interface identifier is most commonly derived from its 48-bit MAC address. A MAC address 00-0C-29-0C-47-D5 is turned into a 64-bit EUI-64 by inserting FF-FE in the middle: 00-0C-29-FF-FE-0C-47-D5. When this EUI-64 is used to form an IPv6 address it is modified:[1] the meaning of the Universal/Local bit (the 7th most significant bit of the EUI-64, starting from 1) is inverted, so that a 1 now means Universal. To create an IPv6 address with the network prefix 2001:db8:1:2::/64 it yields the address 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the Universal/Local bit, the second-least-significant bit of the underlined quartet, inverted to 1 in this case because the MAC address is universally unique).
I'm not very experienced when it comes to such low-level networking, but I'm curious as to how they claimed all those contiguous addresses. Is there some fundamental difference between IPv4 and IPv6 that let's you do this?
Not as such, it's just that v4 is so small that most ISPs don't bother to give routed prefixes -- or rather they can't, since there aren't enough addresses available to do so. In v6 it's typical to get something like a /56 from your ISP, which is 2^(128-56) = 2^72 addresses.
(v6 also has a protocol, DHCPv6-PD, to manage prefix delegations automatically, whereas v4 requires manual config or some custom mechanism.)
You could argue that the difference between 2^32 and 2^128 is big enough to be considered a fundamental difference.
You sure that’s the right link? The presentation slides link on that page didn’t seem related.
Edit: n/m, watching the video made more sense. That said, it wasn’t simply “adding the X Y coordinates”, the Christmas tree example didn’t use IPv6 or Ping, but I’m sure the process was likely similar.
tl;dr
They use a Microtik firewall which uses an rsyslog forwarder with an Arduino to control the Christmas lights.
And people say that Moore’s Law has broken down! Sure, processor speeds aren’t increasing as fast, but that’s more than made up for by the incredibly rapid increase in the number of Internet addresses per device.
What does the density of transistors in a circuit have to do with switching to larger addressed v6 which was standardized and first implemented in the late 90s?
Think a little broader. The IPv6 Privacy Extensions just shield your mac address unless I've missed something.
Let's say I'm a transit provider [like Google]. Right now, I see TLS traffic from your public IPv4 address to another public IPv4 address. I have no idea how many devices are behind those public IP addresses. I can maybe combine a few assumptions with my browser-based tracking, but it's difficult to identify you in apps I don't have control over.
Switch to IPv6, now I know exactly how many devices behind your firewall are talking and how many devices you're talking to.
Even better, I can combine this with a browser-based tracker and I can see what you're doing in apps I don't control. I first identify you with the browser and what IPv6 address you're using. Then as you use other apps that I can't spy on, I just have to look for your IPv6 address in my transit traffic to figure out what you're doing.
A solution could be a Firefox browser extension that allocates a huge number of v6 addresses to your computer dynamically from your LAN /64 or /56 and creates fake garbage google usage data, so that google can never build a profile on you based on v6 address (if you are this paranoid).
Or... just stop using google and use uBlock Origin to block all Google domains.
No, it’s not. My concern isn’t this particular implementation, it’s that implementations will keep using up larger and larger chunks of adressable space.
Thinking something is unlimited is the fastest way to find out that it is.
No, it's not, it is many, many times larger than 'usable v4 space'. Like, if each of the hypothetical 10^27 displays was given a single IPv4 address we'd run out and still need to assign billions of billions of displays.
It's _massively_ bigger - (10^27)/(2^32) = 2*10^17. 17 orders of magnitude is not in the same ballpark (you could give every IPv4 address an entire IPv4 address space, and it'd _still_ be bigger (54 million times bigger)).
If this becomes more common, the IPv6 address space will be exhausted pretty quickly. There already was a proposal on encoding phone numbers in IPv6 addresses.
Everybody seems to make a big fuzz about ipv6. Yet for some reason, it seems to be of no importance to my life at all.
I'm a fulltime native of the web and yet I don't even know if I have ipv6.
I just typed 'do i have ipv6' into Google and the first page I landed on says "0/10 You appear to be able to browse the IPv4 Internet only.".
I doubt I am missing out on anything. I'm sure I would have noticed.
I also make a living from the web, yet I don't even know if my websites support ipv6.
Let me type 'test website for ipv6' into Google and see what happens ...
...ok here we go:
"No AAAA record. This website is not ready for IPv6."
I get that for all my websites.
Again, I would be very surprised if that has any impact. Somebody would surely have told me that my websites don't work for them. They are constantly in the press and on social media. Some users would surely mention it if they had problems accessing them.
IPv4 is not sustainable, we're already running out of IPv4 addresses.
Unfortunately, some ISPs only provide IPv4 support, so (almost) all websites have to support IPv4. And as all websites support IPv4 there is no insentive for ISPs to add IPv6 support. Repeat ad infinitum.
You can always get a tunnel from one of the many tunnel brokers. Some are even free. I've used he.net back in the days before my ISP had native IPv6 support.
I'm still using my HE.net tunnel, and have been using it for more than 4 years. My ISP started BGP-advertising 2 IPv6 /32s 2 years ago... still no news. I fully expect that when they do deploy IPv6 to their customers (at this rate, it will be some time in the 2030s) that they'll only give you a single /64; they're that annoying.
Very excellent tunnel service too. I'm pretty sure it's gone down less than 8 times in that interval.
If you make a living of the webpages you might want to read up on the IPv6 adoption on mobile networks, as supporting it can greatly increase the network performance for your customers. Your websites will work, but for some clients the traffic might end up going on a little detour, slowing things down on an already slow network connection (relatively speaking).
I bet you already support IPv6, you just need to configure the relevant DNS records. If not, you might want to consider a change of host, as there's no good reasons for them to not support it today, and you're probably better off with someone else then.
A lot of mobile users don't have an IPv4 address on their phone. The magic of NAT64 is allowing IPv6 users to talk to your IPv4 sites just like the magic of NAT was the only thing keeping your IPv4 sites being reachable the last decade since we started to run out of addresses.
You may not need to know about it but it's already started to save your ass without you knowing.
That was probably inevitable.
The last scrolling LED message I read was "Uncaught type error: Undefined is not a function."
Is one of you out there trying to fuzz this poor tree? :)