Hacker News new | ask | show | jobs
by AbacusAvenger 2052 days ago
The major problems I've run into with IPv6:

- 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.

2 comments

>- 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.
That is amazingly shitty.
Yes, their IPv6 support has been mediocre.

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.

I would find a blog post going into depth about these issues enjoyable reading frankly.