[radvd-devel-l] RemoveRDNSS option

[Mark Smith]

Hi Pekka,

On Tue, 22 Mar 2011 08:26:21 +0200 (EET)
Pekka Savola <pekkas at netcore.fi> wrote:

> On Tue, 22 Mar 2011, Mark Smith wrote:
> > Another Remove option, this time to remove RDNSS entries from
> > end-nodes' lists of RDNSS servers upon shutdown. Manual page text -
> 
> As a general comment, maybe these options should be named like 
> "FlushRDNSS" instead of "Remove".  That might set the expectations 
> closer to "remove stale entries".
> 

I debated that a bit when thinking about what to token to use for the
options. For the RemoveRoute option, I followed the wording that was
used in the RFC for when the lifetime of the RIO was set to zero e.g.

"  If the received
   route's lifetime is zero, the route is removed from the Routing Table
   if present."

The RFC for RDNSS and DNSSL says 

"A value of zero means that the DNSSL
                  domain name MUST no longer be used."

so the RFC doesn't suggest a simple word to use. I considered the word
"Invalidate" e.g. InvalidateRDNSS, however that seemed a bit unwieldy.
So I thought consistency of using "Remove" for these DNS options
similar to the RemoveRoute option would be reasonable. I hadn't
considered "Flush" and am not strongly against it.

> I'm also wondering if these could be the only supported behaviour, 
> i.e., is a toggle needed at all.  Is it feasible that someone would 
> want to turn this off?  Maybe in a scenario with multiple advertising 
> routers, but even then it's maybe not a problem.
> 

I think the use for the RDNSS options in the v6ops CPE draft has exposed
a use for the toggle but has also shown that there is a flaw in
RFC6106.

In the 09 revision of the CPE draft, when the WAN link goes down, it
says that the CPE should invalidate itself as a default router by
setting the router lifetime to zero. For local routing of ULAs,
the RIO is used to provide end-nodes with local topology knowledge
despite the default router going away. According to RFC6106, I think it
says the RDNSS and DNSSL options should stop being used when the router
ceases to be a default -

  Note:  An RDNSS address or a DNSSL domain name MUST be used only as
      long as both the RA router Lifetime (advertised by a Router
      Advertisement message [RFC4861]) and the corresponding option
      Lifetime have not expired.  The reason is that in the current
      network to which an IPv6 host is connected, the RDNSS may not be
      currently reachable, that the DNSSL domain name is not valid any
      more, or that these options do not provide service to the host's
      current address (e.g., due to network ingress filtering
      [RFC2827][RFC5358]).

An example of when the problem would occur is if the CPE (or some
other local device) is providing DNS resolver, for both local
and global address resolution, and is advertising it to the end-nodes
using either a link-local or ULA address. Both the link-local or ULA
prefix would still be valid if the WAN link goes down, yet according to
the above, end-nodes invalidate their RDNSS and DNSSL entries when the
default router goes away.

In other words, I think the flawed assumption in RFC6106 is that the
RDNSS addresses are always off-link, and therefore they should be
invalidated when the default router goes away. I think the RDNSS
entries actually should be considered valid if either the default
router lifetime is greater than zero, the RDNSS addresses fall
within any of the prefixes on the end-nodes' on-link prefix list
(as per prefix lists in RFC5942), or the RDNSS addresses fall within
any prefixes announced using the Route Information Option. The DNSSL
entries should then continue to be considered valid if the RDNSS entries
continue to be valid.

So if the logic in RFC6106 was changed to allow for the CPE draft
situation, then switching off removing the RDNSS and DNSSL
entries would be valid and useful.

> Or, is there a case where some of these would be On and others Off? 
> Maybe "FlushAdvertisementsOnExit On/Off" (or whatever) could do 
> everything with just one toggle?
> 

It seems that there are two main scenarios. The first scenario is a
generic, enterprise type LAN environment, where there is a more likely
possibility of multiple redundant routers with redundant uplinks into
the rest of the enterprise network. The other scenario is that
described in the CPE draft, where the CPE provides both internal
connectivity between multiple LANs and external connectivity to the
Internet. It seems that whether the Route, RDNSS and DNSSL options are
used, and the defaults for the options, is tightly bound to the type of
scenario. Most of the defaults in the Route, RDNSS and DNSSL option RFCs
seem to be oriented towards the enterprise LAN scenario, even though
the Route, RDNSS and DNSSL options are probably more likely to
be useful in the CPE scenario. Could it be too hard to have a single
global option that usefully summarises the defaults for each of these
scenarios and their likely options?

Regards,
Mark.