Most of the "unwanted" things in IPv6 aren't actually required by IPv6. Temporary addresses, most of the feature complexity in NDP, SLAAC, link-local addresses for anything but the underlying stuff that happens automatically, "no NAT, you must use PD", probably more I'm forgetting. Another large portion is things related to trying to be dual stack like concurrent resolutions/requests, various forms of tunneling, NAT64, and others.

They're almost always deployed though because people end up liking the ideas. They don't want to configure VRRP for gateway redundancy, they don't want a DHCP server for clients to be able to connect, they want to be able to use link-local addresses for certain application use cases, they want the random addresses for increased privacy, they want to dual stack for compatibility, etc. For the people that don't care they see people deploying all of this and think "oh damn, that's nuts", not realizing you can still just deploy it almost exactly the same as IPv4 with longer addresses if that's all you want.

▲ yjftsjthsd-h 6 days ago | parent | next [-]

I'm not convinced that's true in practice. I would like to have an IPv6 network that I can connect Android devices to and on which I can connect to the devices by their host name. Android refuses to support DHCPv6, telling the local DNS server about SLAAC addresses involves awful and unreliable hacks, mDNS requires extra daemons and resolver configuration. I looked at just copying my v4 stack to v6; it doesn't appear possible.

▲

zamadatix 6 days ago | parent [-]

Android was nearly my real life example a la "IPv6 doesn't mandate anything be different, some guy at Android just likes doing things that way more". I.e. nothing needs to be changed in the IPv6 standard, there's just some guy on the Android team who really likes SLAAC and thinks DHCPv6 is an abomination.

▲

yjftsjthsd-h 6 days ago | parent [-]

Okay, but that's not useful. In practice in the real world you cannot run a v6 network the way you would a v4 network even if you want to. That you theoretically could go implement changes to bring them into line doesn't really affect that.

▲

zamadatix 6 days ago | parent | next [-]

I think we're saying the same thing except I'm splitting the blame from IPv6 (which was very much about adding more bits) and placing it on the unrelated hobby horses people like whats-his-name on Android ride in on. Intentionally not supporting DHCP in the new protocol had nothing to do with the design of IPv6, it's just something they prefer.

To put it from another perspective: If the situation was reversed would you be blaming IPv4 and saying IPv4 should have been designed differently or would you just be asking why this guy from Android doesn't want to add DHCPv4 when DHCPv6 is supported? In both situations it's not IPv4/IPv6 to blame for the inconvenience, it's the guy taking advantage of the transition between protocols to do something stupid at the same time. No amount of changing the definition of IP is going to make them like DHCP, they'll always push some SLAAC-like address assignment onto users. The only reason they didn't for IPv4 was they came in after it was already the way instead of before networks were deployed and they could force it.

It's often very difficult to use IPv6 in practice, but not because IPv6 made it that way.

	▲	yjftsjthsd-h 6 days ago \| parent [-]
		Oh, yes, we do (mostly) agree then. Thanks for clarifying:)

▲

6 days ago | parent | prev [-]

[deleted]

▲ JoshTriplett 6 days ago | parent | prev [-]

> They're almost always deployed though because people end up liking the ideas.

Or they're deployed because it's difficult to use IPv6 without them, even if you want to. For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.

Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.

▲ zamadatix 6 days ago | parent [-]

Side note: I'm not sure why folks downvoted you. Even if they disagree it seems like an honest question.

> For instance, it's quite difficult to use Linux with IPv6 in a static configuration without any form of autodiscovery of addresses or routes; I've yet to achieve such a configuration. With IPv4, I can bring up the network in a tiny fraction of a second and have it work; with IPv6, the only successful configuration I've found takes many seconds to decide it has a working network, and sometimes flakes out entirely.

On IPv4 I assume you're doing something which boils down to (from whatever network configuration tool you use):

  ip addr add 192.168.1.100/24 dev eth0
  ip route add default via 192.168.1.1 dev eth0

Which maps directly to:

  ip -6 addr add 2001:db8:abcd:0012::1/64 dev eth0
  ip -6 route add default via 2001:db8:abcd:0012::1 dev eth0

If you're also doing a static ARP to be "fully" static then you'll also have an additional config which boils down to something akin to:

  ip neigh add 192.168.1.50 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent

Which maps to this config to statically set the MAC instead of using ND:

  ip -6 neigh add 2001:db8:abcd:0012::2 lladdr aa:bb:cc:dd:ee:ff dev eth0 nud permanent

In both cases you either need to still locally respond to dynamic ARP/ND request or also statically configure the rest of the devices in the subnet (including the router) in a similar fashion, but there's not really much difference beyond the extra bits in the address.

> Challenge: boot up an AWS instance, configure networking using your preferred IP version, successfully make a connection to an external server using that version, and get a packet back, in under 500ms from the time your instance gets control, succeeding 50 times out of 50. Very doable with IPv4; I have yet to achieve that with IPv6.

I have a strong aversion to AWS... but if there is anything more difficult about this for IPv6 than IPv4 then that's entirely on what AWS likes to do rather than what IPv6 requires. E.g. if they only give you a dynamic link local gateway it's because they just don't want you to use a public address as the static gateway, not because IPv6 said it had to be so by not supporting unicast gateways or something.

There's also nothing about IPv6 ND that would make it take longer to discover the gateway from a statically configured unicast address than IPv4 ARP would take, but AWS may be doing a lot of optional stuff beyond just being a dumb gateway in their IPv6 implementation - again, not because IPv6 itself said it should be so but because they want to do whatever they are doing.

▲

JoshTriplett 5 days ago | parent [-]

That's really helpful, thank you; I'll give that a try the next time I'm attempting to make this work.

(I'm doing this using direct netlink calls from my init; this is all about booting as fast as possible. The IPv6 address information is coming from instance metadata.)

▲

Dagger2 5 days ago | parent [-]

You probably want to add the "optimistic" or "nodad" flags when adding the address, or you'll need to wait for DAD to finish.

	▲	JoshTriplett 5 days ago \| parent [-]
		I'd figured that specific detail out already, though it was hard-won knowledge. But there's a lot more where that came from before getting to the point of bringing up IPv6 and sending packets without dealing with slow RA and various other slow processes of waiting for data from the network, for instance.