Live data from Hacker News

Why IPv6 is so complicated

github.com

321–330 of 519 posts

Re: Why IPv6 is so complicated

#321
post #307

personally I just hate this -> http://[0123::4567]:5000/whatever

This. It’s ugly. All of talk about the technical merits or demerits misses the point. I can spout of a dozen or more memorized IPv4 addresses. IPv6? Good luck.

There's nothing stopping you from using memorable ULA prefixes on your LAN [0] and requiring the use of DHCPv6 for addressing so that each host gets a host part that is easy to remember. Hand-selecting your ULA prefix abandons the collision-resistance that you get from using The Technique to generate one, but if that's something you don't care about, then it's something you don't care about.

Plus, manual address assignment is just as viable in an IPv6 world as it is in IPv4.

[0] fd00::/64 is quite easy to remember, as are fd00::1 and similar.

Re: Why IPv6 is so complicated

#322

Earlier quoted context omitted.

> keeping backward operational compatibility It is not possible to be backwards compatibility with a larger address space

You are right that a 32 bit ipv4 stack can not understand a 64 bit packet format. The thing I am trying to get at is not native compatibility, it is operational compatibility via translation. I know, I know, you will probably say that is what ipv6 bridges do. But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow tr…

Your proposal (translation) is addressed as point 3B in the article.

Re: Why IPv6 is so complicated

#323

I disagree that it would've been just as hard anyway. The people who say "I just wanted v4 with more bits" have a point that most of these arguments completely ignore, but this one touches on it: Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The practical use would'v…

> But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT... Well, the good news is that we've had DHCPv6 and IPv6 NAT for at least like 25 years. It's true that these weren't standardized in 1995, but I always wonder how long things need to be fully supported [0] before people stop acting like they don't exist. It took something like a decade for IPv4 to get DHCP, and I don't know how…

The defaults determine what like 95% of users end up actually using, even if they have their own preference. Like you said, even if I wanted to use DHCP6, Android won't use it. My router also doesn't support it.

Re: Why IPv6 is so complicated

#324

Earlier quoted context omitted.

You can add bits to your own systems fine. When you want your packets to work on other people's routers, it stops being fine.

If that means those other people cannot reach the internet, then I'm sure those people will fix that faster than anything ever fixed before.

No, it means you can't reach the Internet.

Or it means a ton of people can't connect to you because of your netcode preferences, and that makes your boss very upset. It'll get fixed extremely fast, and fixed means turning IPv4 back on.

Re: Why IPv6 is so complicated

#325

Earlier quoted context omitted.

> But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT... Well, the good news is that we've had DHCPv6 and IPv6 NAT for at least like 25 years. It's true that these weren't standardized in 1995, but I always wonder how long things need to be fully supported [0] before people stop acting like they don't exist. It took something like a decade for IPv4 to get DHCP, and I don't know how…

The defaults determine what like 95% of users end up actually using, even if they have their own preference. Like you said, even if I wanted to use DHCP6, Android won't use it. My router also doesn't support it.

> My router also doesn't support it.

I'm sorry your router sucks. If -for example- my router intermittently fucked up its IPv4 NAT and sent NATted packets into the Internet Bitbucket, it would be incorrect for me to claim that IPv4 NAT sucks or isn't supported by default. The correct claim would be that my router's NAT implementation sucks.

Re: Why IPv6 is so complicated

#326

Earlier quoted context omitted.

What purpose do you have for NAT other than putting it where you should actually be putting a firewall?

Obfuscation. By inspecting packets coming from my network now you can tell what MAC addresses are in my network and also internal network topology. It's part of the reason your cell phone feels the need to randomize its MAC.

This concern is addressed in RFC 4941 (IPv6 privacy extensions).

Re: Why IPv6 is so complicated

#327

Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is. For this reason, at ever…

Its not just NAT, it's also DHCP. Somehow the nerds creating IPv6 decided to not only add bytes (which is what people wanted), but also "fix" DHCP and NAT, which nobody asked for.

> Its not just NAT, it's also DHCP.

I'm not sure what you mean by "fix" DHCP and NAT, but FYI: RFC 3315 was published in 2003.

As far as NAT goes, it looks like iptables added IPv6 support to the MASQUERADE, SNAT, and DNAT targets in kernel version 3.7, released in 2012. IDK when other OSs added such support.

Re: Why IPv6 is so complicated

#328
post #307

Earlier quoted context omitted.

This. It’s ugly. All of talk about the technical merits or demerits misses the point. I can spout of a dozen or more memorized IPv4 addresses. IPv6? Good luck.

There's nothing stopping you from using memorable ULA prefixes on your LAN [0] and requiring the use of DHCPv6 for addressing so that each host gets a host part that is easy to remember. Hand-selecting your ULA prefix abandons the collision-resistance that you get from using The Technique to generate one, but if that's something you don't care about, then it's something you don't care about. Plus, manual address assi…

Another option for simplicity in dual stack is to assign visually similar addresses:

    - ipv4: 192.168.0.42
    - ipv6: prefix:192:168:0:42
I only do this for static/server machines, configuring Linux with a fixed ipv4, and append the fixed ipv6 host to the Router Advertisement prefix.

Re: Why IPv6 is so complicated

#329

Personally, i feel it is complicated because ISPs are highly afraid of trying it. I understand that such novel technology would be risky to use. But after 20+ years there are still many countries, like Spain, which are barely using it. After that much time has passed, it is already well battle-tested. At this point, you don't want to make the move either because you are too afraid of anything or you have commercial r…

I think they are not afraid, they just see 0 reasons to without IPv6: everything works already, your customers can access any website with IPv6: ...what are the benifits to them? they still have to provide IPv4 to customers or do some ipv6 to ipv4 translation to make sure ipv4 websites still work (I've never worked at an ISP so my opinion might be useless)

> I think they are not afraid, they just see 0 reasons to

This is a big part of it. Apart from extra addresses, it offers remarkably little benefit in terms of networking features from an operational management perspective. It sounds like it should be better when you look at the features, but, in actual operation the features don't really offer that much.

Further, there's the general problem that for some reason the network equipment manufacturers seem to think that because you don't frequently need NAT that now you don't need to have a stateful firewall just always on by default on a network edge device.

Plus the general confusion among tech neophytes that NAT itself is offering actual security features, so that a stateful firewall is a downgrade. This is such a fundamental misunderstanding that you can't even communicate with a person that believes it to be the case. I fear that this confusion will remain with us for decades. I'm sure me even mentioning it will spawn a whole thread of people vehemently disagreeing, because there is always at least one.

This is coupled with the fact that the addresses are just ugly. Like, I'm sorry, but unless you're exactly an electrical engineer, the IPv6 addressing scheme is difficult to remember. IPv4 has the same problem -- the magic numbers are only easy to remember if you have memorized the binary values, too -- but it's really only a handful of things to remember in comparison. Hex values are just not as easy to read or remember compared to decimal numbers. So even though IPv6 isn't harder to use, it feels like it's much harder to use.

Re: Why IPv6 is so complicated

#330

Earlier quoted context omitted.

NAT is a crutch to circumvent the problem of "there are not enough addresses for each device". I _assume_ you are referring to a default deny inbound firewall (so that devices are not reachable from the outside), but these are very different, completely orthogonal concerns (and independent of the IP version in use).

Everyone I've talked to with this opinion are typically mobile devs thinking about cell phones. Ipv6 works great there, but NATs are often used in corporate networks for isolation and in particular obfuscation. You can't tell what's behind a NAT by inspecting traffic coming from inside it like you can with no NAT networks. Some of the networks I administrate are contractually obligated to be so isolated.

> I administrate are contractually obligated to be so isolated

Yeah, I've seen those contracts. They just reference a SeCuRiTy doc that's 20+ years old, and has never been re-evaluated. Things are secure because they follow the doc, not because they have actually evaluated the reasonable attack space.

I've fighting customers for years on their ideas of proper TLS usage and it's always the same thing. They've got a security doc that never changes and has never evaluated any of the trade-offs. Almost to the point that the people who wrote them choose things that increase downtime and KTLO work without helping security.

Post reply on HN