[radvd-devel-l] Advertise different router?

[Mark Smith]

Hi Curtis,

On Wed, 1 Jun 2011 08:20:18 -0500
"STARNES, CURTIS" <Curtis.Starnes at granburyisd.org> wrote:

> In your Cisco router make sure the 'M' and 'O' flags are both set.
> 
> ipv6 nd managed-config-flag
> ipv6 nd other-config-flag
> 
> The managed-config-flag - 'M' flag tells the router to use a DHCP server.
> The other-config-flag - 'O' flag tells the router to send the "Other" DHCP configuration options set in the DHCP scope, including the DNS servers.
> 
> If you use radvd to send out the advertisements, then the RA's will originate from the radvd box and then the clients will believe that the radvd box is the router.
> 

Only if the router lifetime field value is non-zero. The router
lifetime field is possibly a slighly misnamed field, so people seem
to commonly think it applies to the contents of the whole RA. It
actually only refers to the device announcing the RA being considered a
default router. Here's what RFC4861 says about it -

      Router Lifetime
                     16-bit unsigned integer.  The lifetime associated
                     with the default router in units of seconds.  The
                     field can contain values up to 65535 and receivers
                     should handle any value, while the sending rules in
                     Section 6 limit the lifetime to 9000 seconds.  A
                     Lifetime of 0 indicates that the router is not a
                     default router and SHOULD NOT appear on the default



Narten, et al.              Standards Track                    [Page 20]
^L
RFC 4861               Neighbor Discovery in IPv6         September 2007


                     router list.  The Router Lifetime applies only to
                     the router's usefulness as a default router; it
                     does not apply to information contained in other
                     message fields or options.  Options that need time
                     limits for their information include their own
                     lifetime fields.


What makes Dyonisius situation interesting is that if there are two
devices on a segment announcing RAs, they are supposed to check each
other's RA contents to see if they match up, and generate system alerts
if they don't. So in theory, using radvd to announce RDNSS information,
while using another device as the default router (that can't
announce RDNSS information) is an invalid configuration.


> I am running the M and O flags set in our Cisco sup720/msfc3 core to deliver the RDNSS information in the DHCP packets.
> I am also using the ipv6 dhcp relay destination command in the above Cisco config to request ipv6 DHCP addresses across VLAN's.
> 

I think this is a better set up. If you want to make more
service/application settings available via a new DHCPv6 option, the only
dependency you have is that the DHCPv6 server and the DHCPv6 clients
that are interested in the new option support it.

Although there are currently only a couple of RA option equivalents to
DHCPv6 options, if you choose to go down the RA configuration path, in
addition to caring about which clients support the RA options, you also
have to care about which routers in your network can convey those
options and whether the clients will ever connect to them. In a large
network, with a variety of router models, that can be lots of checking.
If your some of your routers don't currently support the options you'll
also need to perform scheduled outages to upgrade their firmware or find
some other work around. This is Dyonisius's current problem. radvd
might be able to be used as a work around, but ultimately to
permanently eliminate these sorts of issues, a minimal stateless DHCPv6
client/relay/server setup is necessary.

Regards,
Mark.