Pushing Multiple Prefixes to Clients

[wswartzendruber]

The use-case is that a home network running DHCP-PD will have its IPv6 prefix change every now and again.  The desire is to maintain a consistent path of internal communication.

The immediate solution that comes to mind is to assign two addresses to each client interface:  a global unicast one and a ULA one.

QUESTION:  Is it feasible to configure a DHCPv6 server to push two separate prefixes to connecting clients?  The global unicast address would need the default route pushed, but I would also like to be able to push static routes along with the ULA one.

I am using the ISC's DHCP server.

EDIT:  Or maybe a default route wouldn't need to be pushed.  Windows 7 is reporting that my default route is (what appears to be) the gateway's link-local address.

[antillie]

If you only have one network segment then you should be able to use link local addresses for constant internal communication. If you have all of your hosts generate their link local addresses based on their MAC addresses then the link local IPs will be static.

If you have more than one network segment then you will need to setup a some ULA subnets. If that is the case you should be able to have your router advertise both an ISP provided delegated public prefix as well as a ULA prefix to each network segment. You should be able to do this with or without a DHCPv6 server if you setup the config flags in the prefix advertisements sent from the router properly.

[wswartzendruber]

You know what, you're absolutely right.  I just realized that a few minutes ago.  So I set everything on my router to bind to link-local addresses to they would (theoretically) always be available.

One problem with the GNU stack:  If you ever try to use a link-local address you need to put the interface name after it.  That's a pain.

Windows figures it out, though.

[antillie]

That's a bit odd. Every IPv6 capable device I have ever seen requires you to tell it what interface to use when you are working with link local addresses. This is because on a box with more than one NIC the routing table can't be used to determine what interface to send traffic from when the destination is a link local address. Even enterprise grade stuff like F5 load balancers, IOS routers, and firewalls work like that. So it makes perfect sense that Linux would do the same thing.

I guess if you only have one NIC in your box Windows just assumes that the lone NIC is the one you are talking about when you tell it to connect to a link local IP. I guess that's a reasonable assumption for a consumer OS to make, I'm just not sure I would want an enterprise grade device to make assumptions like that.

[kasperd]

That's a bit odd. Every IPv6 capable device I have ever seen requires you to tell it what interface to use when you are working with link local addresses.

Some do require it, but not all. I have seen systems where it was required and systems where it was not. I don't recall exactly which require it.

Having to specify an interface can be problematic. First of all you can no longer access devices by host name, so you have to use the IP address, which is more inconvenient with IPv6 than it was with IPv4.

And the usual APIs don't support specifying an interface, which has lead to a situation where only some applications will allow you to specify an interface.

I guess if you only have one NIC in your box Windows just assumes that the lone NIC is the one you are talking about when you tell it to connect to a link local IP. I guess that's a reasonable assumption for a consumer OS to make, I'm just not sure I would want an enterprise grade device to make assumptions like that.

Making the interface specifier optional when there is only a single network interface makes sense. But that is not the only way to make link-local addresses with no explicit interface possible. If there are multiple interfaces, the OS could have some heuristic for choosing which one will be the default for link-local addresses.

Either of those solutions is prone to break if you add another network interface. But there are also possible solutions, which are more resilient.

The IP stack can send the neighbour discovery message on all interfaces. Then from the replies it will know which interface to send the actual packet on. Once the entry is in the neighbour table it is obviously cached with information about which interface it applies to. For security reasons such an implementation should prioritize the interfaces to ensure that it is predictable which interface will be used if an IP address is claimed by hosts on different segments.

[wswartzendruber]

Okay that wasn't such a good experiment.  I can't connect to my router via SSH without specifying an interface.  Windows doesn't have a problem with this, but the GNU stack does.

I also noticed that both Windows and GNU hosts accept RAs even when they already have addresses statically configured.  This theoretically means I can assign servers ULAs while they'll still accept prefixes delegated from Comcast.