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.