RA for a different router

[Bjørn Mork]

sthaug at nethelp.no writes:

>> I too would prefer using VRRP to a failover mechanism depending on RA
>> information being quickly timed out on the hosts.  But what is gained by
>> using DHCPv6 for configuring the default gateway/virtual router, compared
>> to simply announcing it in a standard RA packet?
>
> Old discussion. Think of aggregation routers with many thousands of
> customers. Customers get their addresses from DHCP, which also is
> connected to backend support systems (so the support people can see,
> for instance, which address does customer X have and when was it last
> renewed).
>
> Some of us crazy service provider types want our DHCP infrastructure
> to handle *all* customer related address info, even including default
> gateway. This is well established in the IPv4 world, and we want the
> IPv6 world to work the same way.

But the default gateway isn't really customer related.  It depends on
where the customer is connected.

With IPv4, you have to maintain a strong binding between the gateway
address and the delegated pre^H^H^Haddress, as that's the only way you
can ensure that the client can reach the gateway. So your DHCP server
will have to calculate both gateway and delegated address based on the
giaddr field.  This makes it logical to keep the gateway together with
the address.  I fully agree with that.

But this is not necessary for IPv6. The client can use any link local
gateway address regardless of the delegated prefix.  You know it's
reachable on that link.  You still want to aggregate of course, so the
prefix *may* depend on where the customer is connected.  However, there
is no need to make it as strict as with IPv4.  You can choose to
aggregate on a cluster of access routers, letting them share e.g. a /32.
Having the routers announce the default gateway (and WAN link prefix if
used), and keeping only the delegated prefix in your backend database,
makes it very simple to move an end user within an access router
cluster.  Or even to another cluster if you allow leaking some of the
delegated /48s (or /56s or whatever).




Bjørn