Much of this boils down to "IPv6 sucks because it's so different from IPv4", which has never been a very convincing criticism to me.
The conclusion of "It's hard to memorize or type plain IPv6 addresses" has always been "I guess I need (m)DNS" for me, not "wow, IPv6 is bad". And some years later, I'm extremely happy I don't have to memorize even local IPv4 addresses anymore – mDNS together with a proxying/caching local router works that well.
Regarding the "unnecessary" changes (i.e. everything besides just adding 96 more bits to every address):
When implementing a new IP protocol version literally touches every single device on the network (at some point), why not use that opportunity to revisit some of the historically grown cruft?
For me IPv6 sucks because it doesn't really solve my problems in a better way, and instead seemingly introduces a lot more fragility and complexity.
I still have to mess with the firewall to open ports, not much different from doing IPv4 NAT as my router software (pfSense) automatically creates firewall rules tracking the port mapping. Except it is worse, because my firewall software don't track IPv6 changes so breaks whenever the device gets a new IP (say new prefix).
When exposing services to the internet it's even more PITA since each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP.
IPv6 on the LAN is quite a pita due to the massive "random" prefix, gone are the days of easy addresses like 10.0.0.12. Yeah I guess I could just use the local address space but what does that really bring over the IPv4 that I know?
And then there's the software that just doesn't follow the times. My router just doesn't handle getting a new prefix. Yeah OK the initial IPv6 wet dream was for an eternal prefix. But clearly that's been unrealistic for quite some time, and sadly not all software has caught up.
I will admit that some of it is probably down to me learning more. But I struggle to find the motivation. There's no "killer app", just a lot of pain so far.
When exposing services to the internet it's even more PITA since each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP.
Presumably because you configured the forwarding on the router? I mean, that should still be possible, right? Set up a name for the routers IP, and have it forward the connections statically.
IPv6 on the LAN is quite a pita due to the massive "random" prefix, gone are the days of easy addresses like 10.0.0.12.
Or just use the hostname? Sometime a couple of years ago, local names just started working, sort of on their own. My Synology is nas.local, Linux boxes are reachable using their configured hostname, even my elderly printer shows up as vigor2.local.
> Set up a name for the routers IP, and have it forward the connections statically.
If you mean NAT, then what does that buy me over what I got? If you don't mean NAT then how would that work?
> Or just use the hostname?
Right, but that requires the DNS to register the host names, and for it to respond. Or since you mention .local I guess you mean mDNS, which requires a service to run on each device and seems to be hit and miss at least for me (I just tried, several of my devices do not respond).
> But you can just keep doing what you are doing now, even with IPv6.
Do you mean keep using IPv4 or use NAT with IPv6? If the former then well, so much for that IPv6 future. If you mean the latter, the whole point of IPv6 was death to NAT no?
> Or just use the hostname? Sometime a couple of years ago, local names just started working, sort of on their own.
That highly depends on what router you have. For mine, the actual suffix is Speedport_W_123V_2_34_000, which is complex and/or invalid enough that a lot of software refuses to resolve it.
My home router does something even better out of the box: Every device that's hostname.local or hostname.my.router locally is also globally resolvable through hostname.myusername.routervendor.com.
This is basically DnyDNS at the router level, rather than the device level (which has many downsides as you describe), and it's been a game changer for my IPv6 home use.
I run my own copy of bind, and use https://dns.he.net as a slave pulling the zones from it. As a result I can actually use all DNS features.
I find it super frustrating that most dynamic DNS providers use their own custom API rather than just using the update mechanism that's in the protocol itself. That said, if they support v6 then you can probably use them by installing their update client on each machine that you want a hostname for. It just won't integrate with pfsense.
it has nothing to do with IPv6 specifically but i mostly have a haproxy instance on every "edge" for public and private services. I also do TLS there. However, everything gets its own records in DNS too. I use dynamic updates from my DHCP server to a bind9 instance for that. This all works very well for IPv4 and IPv6 simultaneously... I admit its more complicated to set all of this up properly but maybe its just the way it is ;)
There is a huge hole in functionality of IPv6 in most common networking equipment. I have a Mikrotik and the IPv6 functionality is signifiantly worse than the IPv4 one:
- There's no caching DNS and I can't set static DNS entries for IPv6
- There's no way to use DHCPv6 to give out addresses.
- Because of lack of DHCPv6, there's not way to give out static addresses to devices on LAN and manage them centrally.
- Because of lack of DHCPv6 and static addressing, it's really annoying to configure firewall to allow outside access to services on LAN devices (on IPv4 you either have static entries or NAT-PMP).
- There's no fasttrack functionality so IPv6 traffic will max out CPU and prevent me from fully using my Gbit fiber line.
- There's no UI way of announcing DNS to clients via DHCPv6 - you can set some option amanually but it's far from setting a nice UI entry like for DNS.
And yes, those are all holes in my routers Firmware, but it's been YEARS and they're still lacking. Other SOHO routers aren't faring any better, I haven't seen these features configurable on any of them.
I have a LAN which has a PiHole and a Synology NAS at home + some entertainment devices. Configuring IPv6 to allow access to same services as IPv4 from WAN via public DNS has been practically impossible, undocumented and huge pain. For pretty much no gain and loss of bandwidth.
It's a shiny toy to play with. However, it has so many weird bugs that never get addressed that it's just not worth the grief.
Why can't the wired ping the wireless but the wireless can ping the wired? Why can I connect every device except my Samsung phone? Why is my throughput so much worse than the manufacturer firmware? Why are the LED's doing weird things that correspond to nothing useful?
I've never even tried IPv6 on a <Foo>WRT because it's handling of basic IPv4 stuff is so dreadful.
(Please don't read this is as dig on the <Foo>WRT developers--they're doing their best. However, the sheer variety of platforms, the lack of documentation, and the small number of developers simply creates an impossible situation.)
I can't say I've had those problems, other than throughput being worse (which is a result of proprietary acceleration chips with no published specs to write OSS drivers with). v6 works great on OpenWRT for me -- but then again, so does v4.
I addressed that - OpenWRT is a 3rd party firmware you need to reflash on your router (if you're lucky). It also doesn't install on an equipment I need.
I've never seen this features out of the box on SOHO equipment like ASUS routers, TP-Links, FritzBoxes, Apple routers and other equipment that actually ends up in peoples homes. And again, we're YEARS after the standard and there still doesn't seem to be feature parity between the two stadards on even basic home equipment.
One of my routers came with OpenWRT, so it's certainly possible to get routers that use it as 1st party firmware.
As for routers with random vendor firmware, I'm not familiar enough with all of the vendors out there to give an authoritative answer but I've seen or helped with plenty of routers that support many of the things on your list.
My off-the-shelf home router (sub-100€, very popular brand in Germany) supports all of that. I don't doubt that this will vary across vendors, but it definitely does exist.
> whenever the device gets a new IP (say new prefix)
Prefixes shouldn't change, that's the whole point. And you can use fixed addresses for IPv6 just as you had for IPv4.
> each device needs a DynDNS client configured, whereas with IPv4 just the router needs one for my single public IP.
Sure, but if you're doing that at an industrial size, you should consider buying/renting a fixed IP (range). You don't do production at home now, do you?
> IPv6 on the LAN is quite a pita due to the massive "random" prefix
You probably mean suffix? Anyway, your systems can be configured to either not have that random suffix, and they can also be configured to still reply on their fixed address (the one that's not random). Maybe try using the fe80:: address if your prefix does change.
>Prefixes shouldn't change, that's the whole point.
They shouldn't, but they change all the time. I gave up on Ipv6 in my last house because of this reason: my prefixes were changing every few weeks. In my new household, my ISP doesn't even off IPv6.
You shouldn't get a new prefix - it should be static from your ISP, and your IP shouldn't be changing, so you don't need DynDNS per-client and can just add a static entry to a hosted DNS zone file somewhere that shouldn't change.
This is intentional. In order to make renumbering possible at all, it needs to be done regularly. If the equipment didn’t handle DHCP-PD regularly the code would rot and other devices and people would assume that address prefixes would never change. That, in turn, would cause lots of things to break when prefixes were forced to change (new ISP, merger, change in upstream architecture, etc).
> Much of this boils down to "IPv6 sucks because it's so different from IPv4"
In fact, "IPv6 sucks because it's not broken in the same ways as IPv4". NAT, for example, was only ever a hack to get around limited address space, and the fact that it 'hid' your internal network was an accidental side effect. People started architecting their networks around that, and now are annoyed that IPv6 isn't broken in the exact same way.
Saying that IPv4 gave you network privacy for free is like claiming that old-school single-line home phones were an advantage over personal cell phones because they gave you some amount of extra privacy 'for free'.
The article makes a lot of points and all of them are pretty weak and stem entirely from ipv4 being the "established" protocol. In every case if you had an ipv6 config that worked and you wanted to switch to the ipv4 way of doing thing the result would be just plain worse.
> The conclusion of "It's hard to memorize or type plain IPv6 addresses" has always been "I guess I need (m)DNS" for me, not "wow, IPv6 is bad".
DHCP servers like dnsmasq can already serve lan hostnames even for ipv4.
SixXS no longer does and I never was able to use them. For some reason one person assumed that information I provided were fake and I never was able to get an account with them until they ceased their activity.
HE.net works and was relatively nice experience to learn how IPv6 work, although both SixXS and HE you still had the disadvantages of tunneling like low speeds, outages etc.
It's nice to test if your application can work on IPv6, but you still won't get benefits of natively using it.
Well, change has high costs, that's why. So the benefits need to be big as well. I think the issue for Python 3 is the benefits weren't that large compared to the costs, and for IPv6 it's the same, albeit people know that the cost/benefit ratio changes over time as IPv4 gets more and more overloaded.
And weirdly, it's not even very different to v4. Most parts of v6 work exactly the same as they do in v4. Most other L3 protocols we've used have been far more different than these two are.
Can you recommend any good resources for setting up mDNS? It sounds like you managed to get it working across routers (networks?), which would be quite useful to have documented.
I'm not really using mDNS across networks, but rather just my home router's DNS functionality: Every device requesting an IP via DHCP automatically is made available as clientid.some.privatetld on the local DNS server.
This works for both IPv4 and IPv6.
As far as I remember, OpenWRT's default setup (probably using dnsmasq?) provides something very similar.
It definitely supports at least the "client" side of it, i.e. resolving host names and discovering services (Chromecast is based on this, after all), and it looks like broadcasting services is supported as well:
https://developer.android.com/training/connect-devices-wirel...
> "It's hard to memorize or type plain IPv6 addresses"
We should create a system to translate IPv6 address to a phrase in English or user language, which is easy to memorize and type. E.g. "hoards of sleepy beefs" is much easier to remember, dictate over phone, or type (maybe even with autocompletion), than raw IPv6 address.
IPv6 is designed for computers. Humans need an adapter.
You can imagine similar arguments against IPv4 back in the day: "I used to only have to know what interface to send stuff to, and now I need this long complicated number?! What the hell is wrong with /etc/hosts?"
You don't understand - we've had DNS for a couple decades now, but I often have to deal with IP addresses directly still. Even if just to check where a given DNS record points to.
The problem is that an ipv6 address is not something you can pronounce, recognize at a glance, or remember. All of these are unfortunately still things one has to do, despite there being name servers. The (proposed) solution is to have a 1:1 algorithm that translates an ipv6 address into a value that a human can work with.
If I'm troubleshooting an issue on an ipv6 network, and my colleague asks me for the IP of a machine, I have no choice but to either text it to him, or painfully, tediously and error-pronely spell it out.
As a networking novice that article actually made me feel positive about IPv6 during most of it.
I feel like maybe firewall based security is a bit of an outdated model. It’s going to take a while to figure out how to secure our networks/devices well, but it feels like a model that pushes more of the configuration to the device will be more secure and more universal (since more and more devices will be LTE connected)
The model where you by default have access to everything inside the network if you can just get a connection behind the firewall never seemed all that great to me. If we can’t assume that any connection from the local network is authorized anymore, maybe it’ll push us to make servers/services more inherently secure, and accept/reject connections based on actually authenticating the user/device connecting to it. But then again, I’m not a professional so I may be wrong.
A layered approach to security (onion model) is the only sane approach because any given layer will always have flaws.
The notion I get from the article is that security becomes a huge problem when every node is exposed to almost every other node by design intent. That's why NAT is mentioned several times.
NAT was never intended to be a firewall and there are mulitple ways of bypassing it to talk to the hosts behind it without them initiating a connection. A new method was just discovered (link: https://samy.pl/slipstream/).
It's very very easy to replicate the filtering behaviour of NAT for situations where its being used that way. Simply block connections into the network that weren't initiated by clients in the network itself. Every stateful firewall can easily handle that and it doesn't come with the security loopholes of NAT.
Exactly. Security at the endpoint level, rather than the firewall level, means that those that build those applications are in charge of security. There is no way my multi-business-unit company is going to solely trust developers with its security and compliance story. It's going to hire people whose job it is to secure the network as well. Given that these people don't even know all of the developers (or yet even their managers) inside this multi-business business, the only good thing those people have is firewalls and traffic inspection at large.
While the evil-Internet, DMZ, walled-garden scheme might be flawed, I doubt it'll go away anytime soon.
- compute clusters / rendering farms: people pay for performance and aren't necessarily willing to sacrifice it for increased security (be it local firewall or SPECTRE mitigation) there
- engineering sub-divisions in large enterprises: its not unheard of that equipment in those is maintained by the engineers themselves (who are not necessarily well versed in network security matters and have other priorities) rather then the enterprise's IT team (this can coincide with the MS Windows / Unix schism)
Depends on your scale.. As soon as you start to have to resort to overlapping private IPv4 networks it really starts to get fun if you have to connect certain things together that weren't planned to be able to reach each other initially.
It is outdated, and the Zero Trust model is gaining traction. Make access default closed, authenticate everyone and everything, and of course encrypt everything.
This article boils down to "this is different! I don't like different even if it does solve HUGE problems".
I love NPT. Complex NAT over tunnels and shit is an absolute disaster. NPT makes everything easy to troubleshoot and enables many solutions that IPv4 just cannot even touch.
And also, if you really want IPv6, it's there. IPv6 works just fine with NAT if you believe that's best for you.
"I'll never run IPv6 because it's different!" is a closed mind, and is just choosing to not even try to solve problems. What's your alternative? Just run IPv4 forever? Ugh. Awful.
> "I'll never run IPv6 because it's different!" is a closed mind, and is just choosing to not even try to solve problems.
Bit of a straw-man argument here.
IPv6 is intimidating to work with, even for experienced engineers, but I don't believe that "just because it's different" is the reason that people don't like working with it.
IPv6 solves some real problems with IPv4, but also adds a lot of non-intuitive standards to an already complex system.
On your point about "NPT better than NAT, so IPv6 = superior!" - which I don't instinctively agree with, it's just different. The fact is, NAT still exists and will for a long time. It's so commonplace that almost every house and office in the modern world that has internet uses a NAT gateway. People generally understand what a LAN is and can differentiate between a LAN and a WAN (or "the internet"). Even high school kids can set up LAN parties with little difficulty.
Telling people that "Hey, all that stuff you've know about the internet, well, it's still going to exist, but also we are going to throw a new standard on top of it that is suuuuper non-intuitive to work with but it makes things awesomer because, just take my word for it!! If you don't like it, you're just closed minded" is extremely closed minded...
Also, try telling your friend over the phone, "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade: NO 8a DEEE EEE. Not C E... Ugh....nevermind"
IPv6 is awesome in many ways, but it comes with a lot of frustrations to work with. Which I believe the author covered pretty well.
> IPv6 is intimidating to work with, even for experienced engineers, but I don't believe that "just because it's different" is the reason that people don't like working with it.
No, it's not. It has been around, in production, for TWENTY YEARS. If you didn't learn about it when you were learning IPv4 you're either old and should already have enough experience to know that new things come up, or you should've listened when everyone told you that attending ITT wasn't a good idea.
"But MY company never deployed it!" Bad excuse. Your phone started using it years ago. If you're a network engineer and didn't realize that, nobody is going to feel bad for you.
Not intuitive? The same can be said about most technologies. Without real examples, this means little.
Can't phone a friend and give an IP address? I've literally never done this. We all use SMS, Messages, email, whatever, and anyone who does anything like run gaming servers knows about dynamic DNS services.
Apparently it is if we are still having this conversation after "TWENTY YEARS".
Is there a particular reason that every aspect of your comment is toned with subversive rudeness and you made zero actual good points? Making snide comments about being "old" or how I "should've listened" and "no one is going to feel bad" really doesn't help anyone understand why IPv6 is all that great.
> Come up with some better complaints, please.
The author already listed several frustrations with the protocol. Feel free to read the article again if you'd like some examples.
Twenty years of poor adoption world-wide demonstrates its lack of easy integration. I don't need to argue this, you just did.
Also, mentioning dynamic DNS services at all in regards to trying to send an IP address to someone is yet another point to support why IPv6 is not an intuitive protocol to work with, even for something as simple as setting up a gaming server with a few friends.
> Twenty years of poor adoption world-wide demonstrates its lack of easy integration. I don't need to argue this, you just did.
This isn't down to the design of v6 though, it's down to two things: the design of v4, and human laziness.
v4 isn't forwards compatible with a larger address space, so there's no way to magically integrate a larger address space with existing v4 nodes. All of the possible ways to make cross-compatibility easier are already available in v6. Updating the internet's L3 protocol is simply a hard problem with no real shortcuts.
As for human laziness: v6 deployment didn't really start until 2013. Deployment was at 1% in 2013, and is at 30-35% today. People put it off until after the RIRs started running out of addresses to allocate, even at the cost of paying extra money to keep v4 working. This isn't a technology problem, it's a human problem.
> even for something as simple as setting up a gaming server with a few friends.
This isn't even possible in v4 for a lot of people today, due to v4 exhaustion. It's going to become less and less possible over time, as v4 exhaustion gets ever more acute. Even if we took at face value your claims that v6 is unintuitive (which I would disagree with), surely it's better to be able to set a gaming server up with v6 than to not be able to do it at all?
The fact that IPv4 is reasonably usable by itself and IPv6 is not (it basically requires DNS) is a completely valid point against IPv6. Also, the joke about "it's always DNS" is there for a reason; depending on that makes it less resilient.
> "The IP for my Minecraft server is ff01:119c:19f9:aaaa:8ade: NO 8a DEEE EEE. Not C E... Ugh....nevermind"
IMO ipv6 would have gotten far more adoption had they used a different assignment scheme:
* Turn every ipv4 assignment into an ipv6 assignment by zero-extending to the left, i.e. 72.217.16.142 becomes ::72.217.16.142
* New addresses come from a new assignment ::2a00:0000:0000/96 which contains as much as the ipv4 space. So new addresses look like ::2a00:72.217.16.142. A little bit messier than ipv4, but still tidy mostly.
In fact, this address syntax is a valid syntax variant of ipv6 addresses. These addresses are just not assigned today.
Had we used this scheme instead of the current one with its extremely long addresses, we'd have had far greater adoption than now.
Note: yes I'm aware of slight incompatibility issues between ipv6 and ipv4, like higher minimum MTU values of ipv6. I'm not suggesting a translation of ipv4 to ipv6 here, the hosts would still speak the two different protocols, but the assignment would match the ipv4 assignment.
Every IPv4 address has its own IPv6 /48 automatically assigned to it. Forget getting more adoption, apparently it wasn't even enough to stop people from suggesting that v6 should've done something it already did!
Yes there are multiple ways that ipv4 can be translated into the ipv6 range. That's not what I'm suggesting here. I'm suggesting the existing ipv4 assignments to natively work in ipv6.
That would only work, at best, in 1 direction. If Alice has IPv6 and Bob has IPv4, Alice can send Bob a packet to either 1.2.3.4 or ::01:02:03:04, but if Alice's IPv6 number isn't in the IPv4 range (ex: ::10:11:12:13:14), then her IPv6 number won't have a corresponding IPv4 number that she can put in the IPv4 IP header (because the IPv4 header only allocates enough bytes to exactly fit 1 IPv4 header in the from field and 1 IPv4 header in the to field).
This means she'll have to either send an IPv6 header or an IPv4 header with a false or blank IPv4 from address. If she sends an IPv6 packet, Bob's IPv4 network stack won't be able to understand it and drop the packet. If she sends an IPv4 packet with a blank or false IPv4 from address, Bob will receive the packet, but won't be able to send a response.
What I'm suggesting is both Alice and Bob speaking ipv6. ipv4 is only used for handing out assignments to ipv6 users. If most dual stack networks use the same assignments for ipv6 and ipv4, and ipv6 routing tables are directly copied from ipv4 routing tables, then Bob can talk to Alice if their ISPs support ipv6. It's a simple upgrade instead of having to get totally separate assignments.
What I indicated in my comment above is that I dont know which of the many existing ways to embed the v4 range into the v6 address space you are talking about. Can you please tell me so that we can discuss it?
Generally, if it's not being routed right now on the public internet, and just used inside networks for migration purposes, it's not as useful for the "my Minecraft server has this IP" use case.
Then you are missing the chance to simplify things though.
In IPv6 most ISPs (except very large ones) are assigned one /32, which they can then subdivide how it fits their network.
Every LAN gets it's own /64 (now one could debate if that should be smaller or not) and one doesn't really have to think hard how many hosts one expects in that broadcast domain.. do I want a /26 or is a /28 enough?
In addition in the IPv6 case you can get away with a single route in the routing table to reach all the networks of this ISP.
Compare this to the IPv4 case where each ISP will have hundreds of /24s.
Of course if one starts with multiple sites and traffic engineering that benefit goes away a bit, but still.. for most cases it does help with routing table fragmentation.
Indeed the routing tables can be simplified with ipv6. However I believe that the current solution is optimized too much for routing tables, and not at all for end-user usability.
You can modify my proposal to have multiple 16-bit prefixes to the 32-bit range syntax, and from that /80 range you give ASs depending on size a /104, /96, or /88, or something in between. That would still leave plenty of room for the ASs to distribute addresses to customers. Maybe customers could get /8s or such, with the option for bigger customers to get larger assignments. NAT on the router could be enabled by default, reserving the range for devices which explicitly request a publicly reachable address. Usually in most networks that number should be small.
End users do not need easier IP address unless they host something. even then one can use address compressed address and DNS.
The thing with IPv6 is it very different than IPv4, as such how we use it should not be compared with IPv4.
My ISP gives /64 for CPE and the internal routing is very easily setuped. My devices in the hotspot has different IPv6 address, VMs have different IP address. The communication between the devices happen locally without any NAT.
What happens when future people want to use other addresses outside those rules? Tons of software will have been written only ever seeing the limited address range and will have bugs for more general addresses. Some programmers might even forget that other addresses are possible and intentionally limit what their software can handle. It could become a defacto smaller address space, making the rest of the address as complete waste forever.
That's a good point. Indeed, in a vacuum world it would be very much a problem that needs to be addressed. Right now however, there are ipv6 addresses in use that use the other end of the spectrum already. During the migration period it won't be a problem either. In the far future, where most traffic uses the new scheme, one can hand out temporary ranges from the traditional ipv6 assignments to high-traffic ASs.
And even if you don't do such measures, the rest of the address space won't be a "complete waste forever", one will just have to identify the implementations which have problems with these addresses and change them. It's a solvable technical task like any other.
Try telling your friend a URL over the phone! They were designed to be human readable but they're usually far more impossible than IPv6 addresses.
If you're going to complain about something, you should have an alternative solution in mind. Otherwise it might be possible that there really is no better way and nature just hates humans. Then your real complaint might be that humans are bad at long strings or there are too many devices on the internet or too many people in the world or whatever.
There are two scenarios though: a) you know the network and know you can rely on router.lan or whatever else the manual tells you, or b) you don't know the network and you'll have to check the gateway / route table anyway, so you can copy-paste. Or c) it's not a simple home network and you can design naming as you want / have routers documented.
Sure, 10.0.0.1 is convenient, but my router changed from 10.0.0.1 to 10.1.1.1 with a firmware update. Not relying on remembering that IP would've been better.
fe80::1? Yeah, I know that. It's not hard to type either, although I don't really ever need to type it because v6 has a method to automatically configure the default route.
Thats why home routers has its own domain. mine is homerouter.cpe (this comes with the router)
Also remembering IP address does not get you so far. the last company I worked at had a spreadsheet of IPv4 address of the Jenkins boxes that we managed.
One problem I rarely read about IPv6 is the mixing of responsibility levels. Sure, we have 2128 IPv6 addresses or so because nobody knows how internet infrastructure will look like in 30 years (maybe internet node virtualization is gone mad). But it's my feeling that the IP address should only be an address and not that half-mixed anonymity-related thing.
See, a general problem I see with IPv6 and all the protocols around is their enormous complexity. As a hobbyist in the last decades, you could learn about IPv4 and DHCP in a couple of afternoons. It was simple the same way as HTTP1 was simple compared with HTTP2. Complexity means the learning curve is enormous and in the end only a fraction of experts will understand.
My personal opinion is that complexity in computing will evventually kill everything: security dies first, innovation comes last.
Sorry for this rant. I assume the IPv6 design was carefully crafted by gifted and highly skilled people. We'll use it anyway, some day :-)
> As a hobbyist in the last decades, you could learn about IPv4 and DHCP in a couple of afternoons.
The same is true for IPv6! Granted, beginner-friendly documentation is a bit harder to find, but I was able to set it up for my home network through OpenWRT in a couple of afternoons as well.
In the process, by necessity I also learned something about setting up local DNS properly, which in the end has been very beneficial also for IPv4 hobbyist use cases.
The comparison with HTTP1 vs. HTTP2 seems a bit unfair – it was never possible to write plain IPv4 packets to the network via Telnet/nc.
And if you're talking about the availability of tooling: Don't forget that IPv4 is several decades more mature than IPv6 :)
One could implement a rudimentary IPv4 stack in a couple of afternoons. There is not much magic in parsing Ethernet / ARP / IPv4 / UDP. For IPv6, a node needs to speak ICMPv6/NDP/MLDv2 which are all orders of magnitude more complex than their predecessors.
All your points are valid. I have to be honest, I was always scared off the sheer amount of protocols and ressources around IPv6. It felt that I have to deal with anycast, self-organized networks, anonymous embedding of MAC addresses, some NAT-replacement, etc. when I touch IPv6. It's probably not true and one can start with IPv6 also in a simpler fashion. Maybe I'm also just too much used to ifconfig and nat tables that the switch feels hard.
The comparison of HTTP1 vs. HTTP2 is in fact only valid on a level of complexity.
As an hobbyist, I'm actually quite excited of finally abandoning NAT and being able to reach my Raspberry at home from anywhere in the net. This dream is still far away, given that many places don't have access to IPv6 (without a tunnel).
Yes, firewalls are very much required for IPv6 home networks.
Default global reachability is definitely not advisable, but having the option for individual devices and/or ports is just great, and doubly so with not having to resort to using non-standard ports.
I've always despised the pattern of having device 1's SSH exposed on port 22001, device 2 on 22002 etc., especially for protocols/applications not supporting SRV records.
And for many client to client use cases these days, port forwarding isn't even necessary: UDP hole punching is just a breeze with IPv6 and works consistently and reliably without any STUN/ICE guesswork, as long as UDP is not outright blocked.
Home routers with IPv6 sensibly default to deny all from the internet, so you get the same security position as you would on IPv4 with NAT. As others have said the difference is you now have flexibility to open stuff up if you want to.
In theory. I very much want IPv6 to take over, but a firewall does not provide the same level of security as a NAT when a bug is found.
If a bug is found in a non-NAT firewall that prevents it from blocking a packet for some reason, you have a routable address from the outside that you can send packets to. If a bug is found in a NAT firewall that prevents it from blocking a packet, it's very difficult to tell the router which internal address to route the packet to since the IP header only holds 1 "TO" address and by necessity, that's the public address of the NAT firewall.
There are of course some edge cases (double-headers, being on the same L2 network as the firewall, etc), but for most cases, the fact that the internal network is on IP addresses that won't route to their public interface (the NAT firewall) is in and of itself a layer of protection.
Personally, I think this trade-off is worth it in the long run, but it's simply not correct to claim they are equivalent when router firmware bugs are still discovered on a regular basis and consumer network equipment rarely gets security updates (and it's even rarer for consumers to install them).
IPv6 is relatively simple. However it is hard to learn if you are coming from IPv4 and you try to relate everything back to that.
If you approach IPv6 as "oh so this is how IPv6 does X" or "this is the IPv6 name for Y" then it's going to be confusing. It's not just IPv4 with bigger addresses, its a new approach to addressing and sending information between endpoints.
See, a general problem I see with IPv6 and all the protocols around is their enormous complexity. As a hobbyist in the last decades, you could learn about IPv4 and DHCP in a couple of afternoons. It was simple the same way as HTTP1 was simple compared with HTTP2. Complexity means the learning curve is enormous and in the end only a fraction of experts will understand.
That's not really the real internet, though. How much did you learn about MPLS and BGP and ISIS from working at home as a hobbyist? I didn't know much of anything about that stuff before I started programming routers and switches (real switches - like the ones your ISP uses).
IPv6 is so ridiculously similar to IPv4, it's a bit funny reading about people complaining about how different they are. Seriously - go to wikipedia and read about something like ATM and how crazy different that is. Compared to the stuff you actually need to know and should know about if you're a network admin, IPv6 is easy-peasy.
> Well, by breaking it again, naturally. To connect to a raw IPv6 address, you wrap it in square brackets. To connect to 2607:f0d0:1002:51::4 directly, that’s http://[2607:f0d0:1002:51::4]/ Why is this a thing?!.
It’s a point-to-point 25Gbit fiber link directly between the two machines, not switched like the rest of my network, and I didn’t feel like complicating it more than that :)
Not very convincing. Addresses cannot be handled by humans?
The same is true for all modern computing. Intels CPU has several prefetch queues, some with more than 200 entries. Who can handle this? Well, not even Intel's engineers as Meltdown and the later discoveries have shown. Have you looked how a GPU works? Recently there has been discussion that Kubernetes depends on 200 libraries. The list goes on and on.
That said, he might or might not have some point in the address translation section. But not being an expert in IPv6, he has wasted his trust by useless complaining before he gets to the possible beef.
AIUI, address translation isn't how it's done. Rather, if you want the hosts on a network to be reachable under some other prefix, you advertise that other prefix (in addition) and then the hosts have an extra address.
IPv6 hosts have lots of addresses. v4 needs to scrimp, v6 doesn't.
So what would have been an ideal length for you? I think the fixed separation into centrally and privately managed halves is a good idea. 48 + 48? Would that stop your critique? I guess that would cause all kind of alignment issues. 64 + 32? Probably enough, but the gain seems marginal to me.
To be honest, other than running out of space, the length of an IP address has never truly mattered, because you don't typically use the IP address to access microsoft.com, e.g. Also routing uses subtrees, so we could have had just grown IPv4 with an extra 4 octets too.
Does every cold virus need an IP address, no. But on the other hand it might make sense to give every planet and asteroid in the solar system one.
He may be downvoted because counting that is a bit disingenious.
The central concept in v4 is an interface, which has a 32-bit address and of which a host tends to have one. The central concept in v6 is a network, which has a 64-bit address and which may be populated by one or many hosts.
The number of /64 network addresses per m² of the planet is also a large number, I'm sure. (That it is a large number is intentional, in order to permit simple routing even when that simplicity leads to lower addressing density.) But counting that is honest in a way which counting /128 addresses isn't.
Not necessarily. I am also sceptical of the extreme optimization tricks done for Intel architecture CPUsm because they lead to security vulnerabilities. A simpler RISC style ISA would be preferable. And of 4K displays, because the complications it brings for (Linux) desktops and more importantly the increased power consumption it causes for irrelvant benefit for the majority of users. I could continue the list, I still enjoy to run Linux on a laptop with 2G of memory (not for building Yocto, but for basic web browsing and doing script programming at least.) Incidently it has no problems with IPv6.
But losing that many words about addresses not to be used by humans anyway seems out of proportion for relevant critique.
One actual problem not mentioned in the article is that, by default, SLAAC embeds the MAC address of the interface when generating the autoconfigured IPv6 address.
As an example, if an interface’s MAC address was `01:23:45:67:89:ab`, the lower 64 bits of the SLAAC assignment (the “host” part) results in an IPv6 address of `:123:45ff:fe67:89ab` (the extra `ff:fe` bytes are constant, making it more obvious the surrounding bytes are likely a MAC address). This has huge implications to privacy, since even as you roam and change networks (and thus the upper part of the address changes), the lower 64-bits stay exactly the same, making it easy to “follow” a device from session to session and site to site.
This was addressed by an update to SLAAC: “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” in RFC 4941[0]... but it has to be explicitly enabled on a per-interface basis.
A great thing about this feature is that these random, private addresses timeout and become “deprecated” (and a new random address gets assigned to the interface and used for new connections), making it harder for third-parties to track connections over the long-term.
Unfortunately, address privacy is a SLAAC thing, so if you want the benefit of registering a device on your network (via DHCPv6, so you can actually correlate IPv6 traffic on your network to a device), you don’t get the benefits of SLAAC’s privacy extensions.
> This was addressed by an update to SLAAC: “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” in RFC 4941[0]... but it has to be explicitly enabled on a per-interface basis.
That's not really a problem with ipv6 so much as a problem with defaults. Nothing stops distributions from enabling the privacy extensions by default, and I'm sure many already do.
I would argue this is barely the default these days. Windows, OS X, and on the Linux side network-manager, dhcpcd, systemd-networkd etc all have privacy addresses enabled by default. Many OSs/distros also have RFC7217-style addresses enabled by default too, so even the SLAAC base address doesn't contain the MAC on those.
DHCPv6 does actually implement temporary addresses too. Support for that is legitimately rare though.
> on the Linux side network-manager, dhcpcd, systemd-networkd etc all have privacy addresses enabled by default.
There used to be a bug though that it only works for hotplugged interface cards, not for coldplugged ones (present during boot already). Don't know when it got fixed exactly, but I have one Ubuntu 16.04 machine (even with HWE kernel) and it still has the bug.
I don't get why people keep advocating for IPv6, when it has all the adoption of the Dart Programming Language. It's obviously not working for a majority of businesses, or they would have adopted it. We just need to create an IPv7, which is just IPv4 with 64 bits of address space. I don't get why this is such a hard concept for people to swallow. IPv4 works fine, we're comfortable with it, we like it, let's just make it bigger. We can even make the new system backwards compatible. 0.0.0.0.127.0.0.1 is still localhost, for example.
"But that's so hacky", you say. "We need to fix the old standard." This is what Intel said with its Intel 64 Itanium processor. Break with the old instruction set and make it better. AMD came out with Opteron[1], a hacky extension of the x86 ISA but for 64 bit. Backwards compatible. Swept the market. It's why your binaries are compiled to "amd64" now.
Yes, IPv4 has quirks, and those quirks are well understood and lots of code exists now to deal with them. Let's not find out all the quirks of a new system the hard way for seemingly little benefit.
This makes no sense at all. The notation can basically be anything you want - you could, if you wanted, invent a new notation for IPv4 or IPv6 right now.
What actually matters is the packet format.
You cannot make it backwards compatible because it is impossible to expand the IP header's address space without it becoming unparseable to existing network equipment.
"Ah" you say, "but we could put the extra bits after the end of what is basically an IPv4 packet"
Well no, you can't do that either because it would require executing a global seizure of existing IPv4 space and reorganising the entirety of the IPv4 internet into a hierarchical manner where your "IPv7" extra bits can be processed prior to the final destination.
IPv6 works fine and is well-designed. Hardware and software implementations have been in-production for decades now; Google alone see 30% of their total traffic over v6.
Fundamentally, support of any network protocol is subject to Internet participants having compatible kit; x86-64 wasn't immune to this; if you didn't buy the chips, you couldn't use the software. The reason it actually won is that the Itanium architecture was completely different and resorted to translating x86 instructions which, unsurprisingly, ran like treacle and never made it to the consumer market either.
The idea of inventing yet another internet protocol is patently absurd when you consider it would require yet more upgrades across the globe to hardware and software in order to support it.
The idea that there are already devices out there designed for a new protocol was considered an advantage of the TUBA protocol to replace IPv4 before v6 was chosen:
"The reviewers generally felt that the most important thing that TUBA has offers is that it is based on CLNP and there is significant deployment of CLNP-capable routers throughout the Internet." [0]
Totally agree. Most people seem to assume that v6 is inevitable just because it's a standard. But its adoption is so low and has taken so many years that it's entirely possible that it will just become irrelevant and an evolutionary dead end. The history of tech is littered with abandoned standards that were replaced with something better. Ethernet was supposed to be replaced with ATM...
Not a good idea. It’s still a new protocol so you still have to build support for it. You’d have to fix all the software again to understand ipv7 and you have to start again from zero adoption. And what you get is as you state worse than ipv6 which is already widely adopted.
Ah, but you could do things like put logic in routers like this: "I see you're giving me a 32 bit address. I'm just gonna interpret that as a 64 address padded left with zeroes." Now router firmware, network stacks, kernel modules -- It's not a full rewrite, just an extension. Now all the bugfixes and workarounds we've written over 50 years still apply. If it were made truly backwards compatible, you'd instantly have tons of adoption because anyone that runs IPv4 is supported and works without any changes. That's way more adoption than IPv6. You wouldn't instantly have to fix all the software again. It would work with old software. This is why hacks like UTF-8 exists. Old systems that understand only ASCII still work fine and communicate well with the systems that deal in UTF-8.
You haven't given that anywhere near enough thought.
You can't just slap some zeros onto the start of a v4 address and come up with a bigger address space that somehow works with v4 networking code. The problem isn't backwards compatibility, it's forwards compatibility: v4 isn't forwards compatible with larger address spaces, so it's not possible to do what you're suggesting.
There are various ways of making a bigger address space with backwards compatibility to v4 though -- and all of the ways which are actually possible and work are already implemented by v6.
The majority of packets on the internet pass through fairly hard-coded switching chips that probably couldn't be updated to handle this. They can handle IPv6, though.
If it were made truly backwards compatible
It can't be made backward compatible. Every switch on the internet needs to understand your new extended address scheme otherwise they'll send your packets to a dead-zone somewhere in Uzbekistan. Backward compatibility was never an option. As soon as you add new bits to the address, old routers won't send them to the right place.
How would you make your ipv7 get adopted? It still won't be IPv4 compatible so why would anyone move? I can't come up with any reason that doesn't also apply to ipv6.
RFC = "Request For Comment", not actual standard. It's just when RFCs are published, generally people start immediately implementing them as if they were.
The RFC publication series is where all kinds of IETF documents are published, standards or not. Having a RFC number doesn't mean that a document is or isn't standards track. IOW all IETF standards are RFCs, but not all RFCs are standards or proposed standards.
The "request for comments" title of the series does remind us of the collegial and unbureucratic roots of the IETF, vowing to reject kings, presidents and voting & believing in rough consensus plus running code etc :) however in the standards track case there is no rfc number assigned to the doc in the draft phase, it's instead published in the separate internet-drafts directory by the working group and goes through all kinds of process and iteration before getting published as a proposed standard RFC.
> With NPt, you cannot do this, you’d have to have an additional device like a layer 7 proxy (like HAProxy) to take in everything and send it to the correct destination
This is mostly incorrect. Yes, NPT can't do this. No, you don't need an additional proxy. All the usual methods work, they're just not called NPT. On linux MASQ and REDIRECT targets work on ipv6. You can change addresses and ports exactly the same way you'd do it for ipv4.
There are other wrong things in this rant too. I'm curious if the author ran into many issues while implementing ipv6 or just doesn't like the idea in general. The problems and some solutions seem very contrived and there are better ways to solve them.
- Some ISPs do not offer prefix delegation, so I have to use weird hacks like NDP proxying (I use ndppd for this).
- My dhcpcd.exit-hook script is becoming a monstrosity to maintain the prefixes and routes for two different ISPs. With NDP proxying I need to have routes with metrics defined or else the LAN-side IPv6 global addresses are inaccessible to the outside world. I also need to maintain route advertisement configs for these prefixes via either radvd or dnsmasq (and need to restart the relevant services when those prefixes change).
- Prefix deprecation route advertisement (i.e. when one global address prefix is no longer valid because that ISP went down) is difficult to implement properly. dnsmasq refuses to advertise a prefix (even with 0 lifetime to mark it deprecated) if there isn't an address for that prefix on an interface -- and tools like dhcpcd will remove those addresses automatically when the WAN-side interface goes down or the RAs expire, etc. radvd can deprecate all advertised prefixes on shutdown/restart, but that's not entirely desirable either.
- Multihoming has no truly good solution right now. If you advertise two different global network prefixes (e.g. for different ISPs), then the individual client nodes decide which source address to use via the "longest common prefix" match (RFC 6724). This implicitly decides which ISP their outbound traffic will go through. The problem is that these individual clients are poorly placed to make those kinds of route decisions. With the two ISPs I have, some remote hosts exhibit better behavior (i.e. higher raw throughput, lower loss, lower latency, whatever) with one network or the other. With IPv4, I am using NAT and doing load balancing across the two ISPs (round robin selection basically). I also have some hard rules on the IPv4 NAT side about which network to prefer for specific remote addresses. With IPv6, I could do the same approach (via IPv6 ULA + NAT), but that defeats the main advantage of IPv6 where everything can have global addresses.
- Debugging IPv6 problems can be a pain, because you have to check several more moving parts than with IPv4. Route advertisements, neighbor advertisements, DHCPv6, routing tables, IGMP/multicast snooping (which on some NETGEAR switches will drop IPv6 multicast traffic necessary for advertisements), etc.
>- Some ISPs do not offer prefix delegation, so I have to use weird hacks like NDP proxying (I use ndppd for this).
Do you mean your ISP does not give you a larger block than a /64 ? If so, name and shame please. Otherwise, you don't need your ISP to support prefix delegation. If they give you a larger block than a /64 then your router is the one that delegates prefixes within your LAN.
I don't know what ISP the OP is using, but Singtel did exactly this. I got a /64 with 6rd. It was quite horrible and the main reason I switched ISP's. Now I have a static /48, which is what all ISP's should be doing in my opinion.
They only announce a /64 prefix via RA (with no DHCPv6 or DHCPv6-PD), so address assignments are via SLAAC. For that ISP (Wave G), I use NDP proxying to allow the LAN side to utilize those addresses as well.
The big advantage to Wave G is that they have symmetrical gigabit download/upload rates. Comcast, on the other hand, provides gigabit download rates but ~30-40Mbit upload rates.
Whining. IPv6 is fantastic for two reasons: address space and no NAT.
NAT, network address translation, means an artificial address space. That is all it means and it is limited by network size, even if that network is artificially addressed with nonrouteable addresses, which is small compared to PAT (port address translation).
NAT is great if you want to hide from the world. It doesn't mean you have privacy. Everything can still leak out. It just means the outside cannot see you without a tunnel. In many way that actually hurts privacy because you cannot establish a point-to-point tunnel without a third party and that third party must have access to the transmission headers. NAT was never created for privacy or security. NAT and PAT were only created to extend the range of IPv4 addresses.
In the web there is no point-to-point communication such as client-to-client. The web is only client-server. You make a request to the server, which establishes a tunnel and the server talks back with a response that follows the request in reverse. If you wanted to talk with a peer you would do so through a server. For example if you use iMessenger, Signal, or whatever you aren't directly talking to people. You are talking to a server and that server shares your messages with your friends. The server sees everything... no privacy. Even with end-to-end encryption you still relay everything through a server that knows half of every conversation.
IPv6 does not have NAT. That is great. The security benefits of an artificial address space that isn't routed are still available in IPv6. This is from a range of addresses called link local that do not route.
Since there is no NAT in IPv6 if you can see an outside computer that outside computer can see you equally. That means you don't need a server to chat with your friends. Just directly talk to your damn friends. No tunnel needed. End-to-end encryption can be as simple as HTTPS. You cannot get that with IPv4, largely due to NAT.
Yes, only nerds care about privacy.... Well, no. If privacy is the default and end-to-end encryption is always the default you can do things and share things you would NEVER in a million years put on Facebook, because its actually private, like giving a USB hard drive directly to your life partner. That is a massive new set of business opportunities that scares the shit out of people on today's web (for good reason).
>Even though the entire “special” address assignments are exactly 1.271% of the entire IPv6 address space, we’re still allocating giant swathes of addresses. History repeats itself, you can see that right here.
So what? The whole point of IPv6 is that wasting address space like that is irrelevant - there is going to be enough space regardless
I listened to a podcast where Geoff Huston argued that the address space of IPv6 when compared to IPv4 isn't going to give us as much runway as people suspect:
He's wrong. Not only do we have a lot of space in 2000::/3, but we also have five completely untouched /3s available, so if we do somehow run out of space in 2000::/3 we can always start using one of those /3s with tighter allocation policies.
Plus, the idea of waiting until we "run out of v4 with NATs" is getting it wrong. NAT starts causing problems long, long before it gets to the stage where the very last person says "I give up".
Can you give a summary? ISPs would have to assign a /32 prefix to every connection before we'd be in the same boat as IPv4, but my ISP gives out /64 prefixes (and so uses a 4-billionth as much of the address space as IPv4 does).
Didn't have time to listen to the whole thing yet, but from what I gathered it's two things: the lower 64bits of the 128bit addresses doesn't count (due to privacy), and that carrier-grade NAT might go much further than what some people think.
If all you want to do is to watch YouTube and check out Instagram, and Google and Facebook have servers in a rack "nearby" (in the network sense) ala what Netflix does, then you don't need a globally unique IP to talk to them.
> If all you want to do is to watch YouTube and check out Instagram, and Google and Facebook have servers in a rack "nearby" (in the network sense) ala what Netflix does, then you don't need a globally unique IP to talk to them.
A "consume only" internet sounds like a second rate dystopia, doesn't it? (Where does the next YouTube/Instagram/Google/Facebook come from when the hurdle is they need to install lots of middle boxes to small, more siloed networks?) Not to mention the name "internet" itself comes from the global joining of a lot of individual networks. A re-balkanized "internet" with a lot of mostly disparate networks that don't really talk directly to one another hardly deserves the name "internet" at that point. (From that perspective CGNAT is an attempt to murder the internet from the inside.)
> the lower 64bits of the 128bit addresses doesn't count (due to privacy)
That's not how that works? For privacy a device is picking a 64-bit random number, sure, but that's still 64-bits of random numbers for a lot of devices to roll before collisions. It's not like it is just one device per lower 64-bits of address space. (Sure, maybe for "privacy" to avoid easy/obvious port scanning you superstitiously avoid "unlucky numbers" like ::1 or ::ffff:ffff:ffff:ffff, but that's still a lot more random numbers to roll than anything "the lower 64bits doesn't count" implies.)
(ETA: And of course, that assumes you are using privacy-focused SLAAC. There's still the power to micromanage a prefix with DHCPv6 and allocate every single one of those lower 64-bits if you really must.)
> For privacy a device is picking a 64-bit random number, sure, but that's still 64-bits of random numbers for a lot of devices to roll before collisions.
I don't have billions of devices in my home network, yet they eat 2^64 worth of addresses cause my ISP hands me a /64.
Which is fine. There are 330 million /64s available... per person on the planet. Your home network using one single /64 out of that isn't even a blip.
(Actually, if that's all you can get then it's not fine. Your ISP should be handing you, perhaps not by default but certainly on request, at least a /56 so you can have multiple networks.)
On a personal note, I used an ISP with CGNAT for a very short while, and it was despicable. It completely, utterly breaks any possibility of peer-to-peer stuff, in million little ways like UPnP being insufficient to make online gaming work as expected. It was just awful.
If we're going to talk about "need", then you don't even need a computer. You could walk over to the rack and watch the yougram on its management console.
But there are advantages to having a computer. Similarly, there are advantages to doing your networking right, and that means globally-unique IPs.
I listened to it some more, and he goes into this more specifically.
He says that because things has to work behind NAT these days ("or it won't get deployed"), then the effective address space of IPv4 is much larger.
For one it includes the source/destination ports, but in addition those ports can be time-multiplexed, so you get more effective bits out of that. He suggests the effective address space of IPv4 is closer to 52 bits.
On the flip side, in IPv6 the recommendation is for ISPs to hand out /48's. Add a few hosts inside there, and you got an effective address space that's roughly the same as the effective IPv4+NAT address space.
I don't believe that's correct because IPv6 could have time-multiplexed ports, too, which would vastly extend the IPv6 space if the podcaster wants to compare apples to apples.
Yeah I'm note sure I entirely agree with his arguments around the address space.
His other points seem stronger, like how IPv6 is a mess for backbone router hardware due to variable length headers, how to get IPv6 working really well requires you to control the entire network and how it might not matter much since we're moving towards a naming-oriented network. Overall interesting podcast IMHO.
If I understand certain parts of this article right, it suggests that IPv6 could in fact replace both the Network Layer (IPv4) as well as the Data Link Layer.
Is this correct? Has anyone put this into practice?
Imagine that we lived in such a world: wifi repeaters would just be IPv6 routers. So would wifi access points. So would ethernet switches. So would SDN. ARP storms would be gone. "IGMP snooping bridges" would be gone. Bridging loops would be gone. Every routing problem would be traceroute-able. And best of all, we could drop 12 bytes (source/dest ethernet addresses) from every ethernet packet, and 18 bytes (source/dest/AP addresses) from every wifi packet. Sure, IPv6 adds an extra 24 bytes of address (vs IPv4), but you're dropping 12 bytes of ethernet, so the added overhead is only 12 bytes - pretty comparable to using two 64-bit IP addresses but having to keep the ethernet header. The idea that we could someday drop ethernet addresses helped to justify the oversized IPv6 addresses.
It would have been beautiful. Except for one problem: it never happened.
I'm surprised no one has linked to these two articles by @apenwarr yet, I consider them "the bible" for understanding IPv6 and why it was designed and implemented the way it was.
As the article points out the zone identifiers are primarily for making sure you are sending packets out on the right device (network adapter) and extremely rarely play into receiving data, so it would be extremely uncommon/unlikely to see zone identifiers in URLs because presumably they would only make sense, pending some unspecified future usage, for diagnostics on a single device (as the zone identifiers mostly don't "leave" a specific device; they aren't advertised externally, there is no way to query them, etc. Explicitly per RFC 4007 that defines zone identifiers, "The zone indices are strictly local to the node.").
(Which the RFC 6874 mentions it's primarily expected these URLs to be intended for diagnostics and unlikely to be seen in the "wild" much less expected to ever be seen in Anchor tags in HTML documents.)
(Even for diagnostics situations it sounds like it should be rare for instance that you might have different web servers on the same device running depending on which ethernet port or wifi device a message arrives on. Outside of routers and firewalls and crazy proxies that should be extremely rare, I would imagine. Device based zone identifiers are not going to replace Host header based Virtual Hosting any time soon I'd imagine, for example.)
>anything from 127.0.0.0 to 127.255.255.255 all mean the exact same thing
Uhh no they don't. They're all unique addresses that can be explicitly listened on and connected to.. they just have to be routed to your lo interface by spec.
There's path MTU blackhole detection. See RFC 4821. This or similar systems are enabled in most mainstream operating systems (but not Android, because Google would rather replace TCP with TCP over UDP than fix TCP with existing fixes).
Like cesarb's sibling comment, I think router driven packet truncation would be useful. IP fragmentation is generally problematic and router driven fragmentation was eliminated from IPv6, but truncation with in-band indication would work a lot better. For TCP, the kernel on the receiver of a truncated packet could send an in-band ack of the received bytes, with a tcp option indicating the effective MTU.
For UDP, it would be a bit more complicated, you would need to alter the recvmsg syscall to provide both the original size and the received size, and transmitting that information back to the sender would be protocol specific of course. The sender would then either trigger IP fragmentation to appropriate sizes or some protocol specific fragmentation.
In my opinion (with hindsight), the IPv4/IPv6 model of "drop packets which exceed MTU" as the alternative to fragmenting packets was a bad choice. It would have been much better to take a third option and truncate the oversized packet. That would avoid both the bad effects of fragmentation (slow path in the routers, memory use in the receivers, non-initial fragments which lack the higher level headers making it a pain for firewalls) and the bad effects of dropping (waste of the bandwidth to send the dropped packet, broken firewalls discarding the ICMP message, CPU use in the router to send the ICMP message).
Except in practice this is useless because you're now transmitting what is basically a corrupted packet.
For this to work, L4 protocols would need to be completely redone to consider and work with this concept.
Also, what is actually meant to happen is that an ICMP(v6) packet too big message is supposed to be sent back to inform the sender that they need to reduce the packet size.
Unfortunately, with the pervasiveness of idiotic firewall configurations that blanket block ICMP, this falls apart which is why we have to deal with ugly hacks like TCP MSS mangling.
IPv6 might be a nice thing for companys. But at home you don't have a static IP. With IPv6, I get a new address every 24 hours from my provider. The devices always change last part of the address because of privacy. How can you write firewall rules to a such network.
By any combination of assigning static IPv6 addresses, organising devices into separate L2 links (VLANs) and firewalling by IP prefix, rather than the entire /128.
Hasnt the privacy issue been helped by using temporary ipv6 addresses? This is why my Windows machines have 3 v6 address with only one being permanent and the other 2 being called temporary? The temporary address did change after a restart.
I checked my Linux VMs and none of them have this security feature yet.
The complaints about allocating a percentage of IPv6 addresses for certain usages are a bit silly. Yeah, 1.271% of the addresses are private addresses. IPv6 has 340 trillion trillion trillion possible addresses. IPv4 has 4.2 billion.
```
Remember, this will blindly just swap prefixes in and out. Gone are the days of “only the traffic I explicitly create a rule for can get in”. See, now, just adding that one step will, be default, expose your entire network! You now need firewall rules to block what you don’t want and add explicit allows, this time manually as an additional step. This is more of a “default pass” routing — unless I tell you not to, let it through.
```
This seems like a great security concern
Would be good to know if this statement is accurate
Not many firewalls support NPT. OpenBSD PF doesn't, where IPv6 NAT works much the same as IPv4 NAT.
I wouldn't put much stock into that article. Many of their points are IPv6 pros (and the sections seem to make that clear), and many of the cons simply boil down to IPv6 being different, often necessarily so--for example, PTR records for a 128-bit address space were always going to be long even if the delegation prefix chunks were larger (e.g. 8 or 16 bits instead of 4). And I don't see how any of those problems constitute a nightmare.
The only real pain point for IPv6 deployment IME is DHCP.[1] DHCPv6 was never even supposed to be a thing; the very fact that it exists shows that the alternatives can be replaced or supplemented. But either way this problem really comes down to tooling and operating system support. IPv6 deployment and the standards and software for deploying it will mature together, and complexity will ebb and flow as alternatives enter and leave the fray. It could never have been any other way. IPv4 was hardly without its hiccups. Heck, the switch to classless IPv4 addressing was somewhat bumpy and confusing even as late as the early 2000s simply because a lot of software, including standard tools like ifconfig(1), didn't make it ergonomic or even possible. Frankly the latent complexity is still annoying.
I think it pays to remember that a lot of these articles are written by people with an eye toward job recruiting, interviewing, and generally grooming their credentials. The conclusions don't matter, they're just an excuse to exhibit familiarity with the technical details. They're a sales pitch for the author, and that essay is a particularly good one--the author demonstrates a comprehensive familiarity with the issues, notwithstanding their framing and conclusions.
[1] The biggest pain point in earlier years was the need for BSD Sockets API support in application software. But it seems we're mostly over that hump, notwithstanding the regressions caused during the shift to cloud computing, where IPv6 support was and remains much more immature than in the wider ecosystem.
AFAIU, SLAAC and RA were supposed to be the answers for the problems solved by DHCP. But people don't really get SLAAC and RA. I think, based on my own personal experience and ignorance, this is partly because SLAAC and RA emphasize the adoption of sophisticated prefixing and routing strategies that people (who aren't BGP router administrators) aren't accustomed to caring about, let alone rigorously thinking about and accommodating, especially on their LANs. Also, neither directly solve the problem of advertising DNS hosts and other options, like NTP hosts, that piggyback on DHCP. I'm not particularly well versed with all things IPv6, but AFAIU the alternatives arrived belatedly--e.g. RFC 6106 (currently RFC 8106) which extends RA to propagate DNS configuration. I'm not sure if NTP and other DHCP extensions even have non-DHCPv6 alternatives, yet.
I don't know if DHCPv6 will win the day, or the vision of a leaner, more distributed addressing and routing infrastructure will prevail. And I don't have any opinions on which is better. I just know it's all rather confusing and still in flux.
I'm one of those. Say I connect my new Pi Zero to the network, and I want it to be a server of some sort.
In a IPv6-without-DHCPv6 world, how do I make sure I can always reach my Pi server?
With DHCP it's easy, I can assign it a fixed lease in the DHCP server and the DHCP server automatically registers the name in the DNS server for convenience.
How do I get the same when using IPv6-without-DHCPv6. Keep in mind my IPv6 prefix changes frequentl, sometimes multiple times a day, and this is out of my control (changing ISP is not an option).
To this time of writing The Android AOSP Team still refuses to adopt DHCPv6. Lorenzo (one of the team) agreed to a commenter that IPv6 should not be treated equivalently as IPv4 with more bits.
> Lorenzo (one of the team) agreed to a commenter that IPv6 should not be treated equivalently as IPv4 with more bits.
Judging by the list of standardized IPv6 Neighbor Discovery Option types, https://www.iana.org/assignments/icmpv6-parameters/icmpv6-pa..., it seems like that's exactly what is happening. Not only does that list make it seem like RA/ND ICMP messages are being used/abused to mirror 1:1 their DHCP field counterparts, but several of those RFCs define RA/ND and DHCPv6 options together.
I'm curious: what sort of meaningful network management possibilities, beyond stateless addressing, are made practical with RA/ND that aren't with DHCPv6, especially considering that stateless DHCPv6 is a thing? At first I thought it might be easier to relay/passthrough specific extensions, but a cursory reading of RFC 4861 (Neighbor Discovery) makes me think you can aggregate these options in the same packet, in which case it would be no more easier (from the perspective of implementations) to selectively relay these configuration parameters than with DHCPv6. And if I'm also reading RFC 3315 (DHCPv6) correctly, ND is an even better DHCP as solicitors/requesters can selectively query specific options rather than the advertisers/responders having to send all options down in the same reply.
If RA/ND is already being used/abused this way, why would people dislike DHCPv6 on principle, as opposed to disliking DHCPv6 as unnecessarily duplicative (notwithstanding that it came before most of these ND options). If anything I would think such people would be advocates for DHCPv6 if they were afraid of ND becoming a dumping ground for extensions unrelated to fundamental addressing and routing issues.
> There's a different protocol to do the same job. Or two if you want, RA and ND. Router advertisement, neighbour discovery.
> DHCPv6 does exist, but I don't really understand what it offers over RA+ND.
How does RA/ND solve the problem of client auto-configuration of services? Rightly or wrongly, DHCP has been traditionally used for service discovery ("Hey! Here's some NTP servers, a TFTP server and a SIP server") as well as config discovery (useful for autoprovisioning of many devices) and I didn't think you could achieve that just with RA/ND.
Has anyone managed to get netboot or PXE working on IPv6 without DHCP?
Edit just saw a sibling thread about DNS adverts in RA. I guess RA could do all these things, but if it doesn't support it today, DHCP is going to fill the gap.
Or the gap goes unfilled. We live in an age where small diskless devices are uncommon and another type of small device now called "phone" is common. A small device nowadays doesn't boot from PXE+TFTP, it has its own SSD and doesn't even trust the network.
I think this statement should be considered more as a criticism of pfSense and not of IPv6 in general. In fact there are a number of RFCs around how IPv6 firewalling should be implemented on _consumer_ routers but since pfSense seems to be mostly aimed at enterprise customers my guess is they don't necessarily follow all that.
Specifically I'm referring to:
- RFC4864 | Local Network Protection for IPv6,
- RFC6092 | Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service and
- RFC7084 | Basic Requirements for IPv6 Customer Edge Routers, which pulls in the other two by reference.
In fact RFC4864 is specifically about this "Perceived Benefit of NAT" and how to preserve the security benefits in the v6 world.
Just as an example, OpenWrt, a more consumer focused router distribution follows RFC7084 and provides the default deny behaviour on IPv6 ingress from WAN much like IPv4-NAT would do.
Also note that IMO the author is simply conflating NAT as known in the IPv4 world with it's usual implementation of actual Address Translation plus Stateful firewalling. In fact prefix translation which he's going on about here isn't necessary at all to be exposed to this security problem.
Just plugging a IPv6 (and DHCPv6-PD) capable router into a WAN would do if it weren't for the stateful firewall.
I've been running pfSense for years, but it's clear that it just is not made with residential IPv6 in mind. Been looking at the NanoPi R2S, think I'll try out OpenWrt on that as a replacement.
NPT does that if your default firewall rule is "allow all incoming". Atleast on my router, if I setup NPT it also automatically creates a firewall rule to drop all non-relevant traffic unless I allow it.
I feel like I should point out that in IPv4 NAT you also still have a firewall to drop incoming traffic unrelated to anything.
To provide a data point to your assertion my brand new tp-link wifi router has a setting for ipv6 firewall, but it does nothing. Yes all my home devices are exposed to the public internet. Yikes!
The tech support team even confirmed that ipv6 firewall support is coming ‘soon’.
Meanwhile my ASUS router’s ipv6 support is broken as well for dns configuration.
So, yeh it is still early days for consumer ipv6 adoption.
Can't home routers, much like they all now have NTP by default, just have a firewall installed that by default blocks all incoming traffic unless it's a response to outgoing traffic? So, no prefix translation, everything has a real IP, and all incoming traffic still gets dropped on the floor by default.
IPv6 is a crux example of the tradeoff between security and convenience.
I understand a lot of the pros of it, and I like them, but...
The protocol is certainly much less human-brain-friendly, which gives points for security, but kills in the area of convenience - even for experienced engineers. As someone who frequently manages networks professionally and personally, I constantly need to look up information on the how the address hashing works, CIDR block ranges, short-hand notation, etc, etc...etc (because there is a lot). It's really added a hinderance to my workflow and makes typical network configuration take much longer than it would have before.
It was easy for me to differentiate between LANs and WANs, subnets, etc in IPv4-land because the address space is much more intuitive to work with. CIDR block notation for IPv4 takes a minute to get used to (for new people), but it's easy to learn quickly and understand the ranges of your networks, or at least get a feel for it.
Even after working with IPv6 for over a year, I still do not have an intuitive feel for how many addresses or what address range a CIDR block contains - which is extremely useful for debugging issues. If I can look at an IPv4 address in a log, I can immediately track down what subnet/machine had the issue and dig into the issue. IPv6 requires extra steps, and a lot of them.
Naturally, NAT became a thing for IPv4. I don't know if it was originally introduced as a firewall mechanism or to cut down on publicly used IPs, but it works well for both. IPv6 circumvents the need for NAT, but then we have NPT, which is also unintuitive.
Numbers are much more human friendly, as time has shown. It's easy to understand 127.x.x.x and 192.x.x.x are common prefix to local networks and I think that most people who have worked with computers at all have some understanding of what a "local" network is, but even after reading the article, my brain says "any IPv6 address that starts with an f is probably a special one, but I don't know why, just assume it means something and I'll have to do some Googling about 'prefixes' to figure it out".
I like some of the pros of IPv6, and maybe after another year of usage it might feel more intuitive, but right now it comes with a serious learning curve and anytime I need to work with it, I get an instant headache.
Also, have you ever looked at one screen to mentally grab an IP address and then needed to type it into another? Or asked a coworker for the machine's address so that you can take a look? Get used to using copy-paste a lot, because there's no way that you can glance at a screen for 2 seconds and mentally go, "aaah. Just need to ssh user@aksj:dfja:skja:sviw:eijf:000i:hate:00my:life....easy peasy"
When you've got a host whose address is 192.168.2.42, but it shows up as 203.0.113.8 to internet hosts, but you had an RFC1918 clash on a few of your acquisitions so some parts of your company access it via 192.168.202.42 and other parts need 172.16.1.42 and your VPN sometimes can't reach it because some home users use 192.168.2.0/24... how is that easier than "the IP is 2001:db8:113:2::42"?
> I still do not have an intuitive feel for how many addresses or what address range a CIDR block contains
This is just lack of practice, not an issue with v6. Also, v6 subnets are basically always /64, so the answer to the question of how many addresses are in them is always who cares it's enough. I find v4 and its fiddly /27s and /21s much more of a pain (partly because, yes, I'm out of practice dealing with them).
Same deal with knowing the prefixes. 'fd' is "RFC1918", 'fe' is link-local, 'ff' is multicast. This isn't hard stuff.
> 192.x.x.x are common prefix to local networks
This is 99.6% wrong. I guess v4 isn't _that_ simple, huh?
I think v6 is simpler in practice, due to not needing NAT. If the first part of my post is difficult to understand then that serves as a good demonstration of how hard v4 is once address exhaustion and NAT enter the picture.
we need a new standard for human design that emphasizes the simplicity and intuitive aspects.
In all places. Laws, programming, etc.
If it is too complex to readily use it and easily debug it, then it is bad. It is bad not because it is complex, but because it inserts overhead, and overhead in time spent solving problems is always exponential.
I am for the idea of using ipv6 as a sort of nation-level NAT for big corporations and countries to expose part of a private address space over a section of ipv4, while each country gets most of ipv4 to itself along with a section where you can route to other countries, in exchange for a small fee. Say 30% of the ipv4 space is globally shared by everyone and the rest is local to your own country. Also IOT local mesh networks all would be on auto configured tunnels with only certain gateway systems hard coded- systems you can block at your router.
That’s the most sensible solution. It will be a real shame if it is not the reality. Arrogance and “hurr durr i’m so smart and i spent 40 hours this week setting up this brilliant ipv6 network topology for my company that will require five manuals to fully explore and retain me in my job for a minimum of 10 years to keep it all working”- meanwhile the rest of us will suffer.
The biggest most canally disgusting thing about ipv6 is that it will render dns based ad blocking a thing of the past. If you want any kind of blocking you will have to go with curated WHITELISTS, instead of blacklists. And that may be more secure but it will also be a lot more work, which, again, the ipv6 nerds will love to do but will present a hassle for the rest of us. You won’t be able to manually check the dns list anymore. you will simply have to accept that the overhead and the security risk of trusting all of the 35 million addresses in the whitelist is a cost you are willing to accept.
Say no to ipv6.
I have already blocked it on everything and will never adopt. it is the ethanol of internet addressing.
You say you want simplicity, then you suggest a "nation-level NAT" that includes keeping v4 alive with overlapping allocations in multiple countries, NATing into v6 to talk to other countries, apparently for a fee that will need to be paid somehow. This is not simple, and is certainly not the most sensible solution. The simple and sensible solution is to just use v6.
> The biggest most canally disgusting thing about ipv6 is that it will render dns based ad blocking a thing of the past.
This claim is completely nonsensical. DNS-based ad blacklisting works just fine in v6. None of the problems you list with it exist.
I suggest you unblock v6 and use it. You'll find it works the same as v4 does, just without the added complexity of NAT.
The conclusion of "It's hard to memorize or type plain IPv6 addresses" has always been "I guess I need (m)DNS" for me, not "wow, IPv6 is bad". And some years later, I'm extremely happy I don't have to memorize even local IPv4 addresses anymore – mDNS together with a proxying/caching local router works that well.
Regarding the "unnecessary" changes (i.e. everything besides just adding 96 more bits to every address):
When implementing a new IP protocol version literally touches every single device on the network (at some point), why not use that opportunity to revisit some of the historically grown cruft?