12

We have a medium sized network with IPv4 and IPv6 across it, and our upstream provider is making IPv6 go away for two weeks while they do... something. (It's "experimental" and we don't pay for it, but it's been stable for years so we turned it on across the board.)

We have 150ish hosts on our network of at least a dozen different operating systems, plus a wireless network for people's phones and laptops, so disabling IPv6 on all our devices is a non-starter.

I would like to avoid too much of the classical broken IPv6 behaviour with long timeouts before failover to IPv4, and I am wondering what the best way of doing that is.

  • Should I block outgoing IPv6 packets at the border and return an unreachable message, or will that cause hosts to be marked unreachable without falling back to IPv4?
  • Is disabling AAAA resolution through our BIND nameserver feasible (and if so, how), and if so, is it sensible?
  • Alternatively, will turning off RADVD do the job? We do use static configuration on some of our servers, but there's few enough of those to do them by hand.
9

I would turn off RAs and manually disable the statically configured hosts. Setting up a tunnel is possible as well, but renumbering twice is going to be more work than temporarily disabling it.

If you advertise IPv6 reachability in DNS (publish AAAA records) then you should temporarily remove those as well. Don't forget those might be cached by users so leave enough time between removing the AAAA records and disabling IPv6.

1
  • 2
    Yep, we went with this as returning ICMP no route messages caused some clients to get very upset (particularly if multiple AAAA records were listed for a host). Notably, you don't have to remove the v6 address in Linux - just mark it all the globally routed addresses as deprecated and most clients happily ignore their existence.
    – Zanchey
    Jul 1 '14 at 11:30
6

The easiest on your clients would be to go the ipv6-tunnel route. If you can update your routing so your subnets go over the tunnel that would be awesome, but you may have to go to a 1:1 NAT method with the subnets given you by the tunnel provider mapping to your existing ones. You'd configure your routing core to send v6 traffic over the v6 tunnels so anything relying on it would continue to work, albeit perhaps a bit slower than before but faster than v4-failback at least. Subnets that are entirely dynamically assigned probably wouldn't need the 1:1 NAT, but anything with static assignments probably would.

1
  • 1
    A good suggestion for larger sites, but unfortunately the nearest feasible tunnel provider is many milliseconds away and 1:1 NAT for IPv6 looks tricky on our current routing system.
    – Zanchey
    Jul 1 '14 at 11:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.