Re: 6MAN WG Adoption call : draft-jeong-6man-rdnss-rfc6106-bis

[Mark ZZZ Smith <[e-mail]>]

Hi,

My comments below in part on this draft and Fernando's earlier one seem to have been ignored again. 

The advice to consider RDNSS and DNSSL option values to be invalid if RA lifetime has expired is inconsistent with RFC4861's advice on the use of Router Lifetimes. A RA Lifetime of zero is valid, and should not cause options within the RA to be considered invalid - that is why they have their on lifetime values. Again quoting from RFC4861, 

"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. "

For example, RDNSS addresses could be link-local addresses, so the expiry of the default router information (specifically and only indicated by the Router Lifetime) would not impact the ability to use the on-link DNS resolvers. NUD and/or the DNS resolver's failure detection methods would determine if link-local addressed resolvers are still valid to send requests to.



There is also a problem with only using a subset of DNSSL options because they won't convey the equivalent service/values unless multiple DNSSL options have exactly the same values, unlike (in theory) RDNSS values.

For example, 3 x DNSSL of example.com, example.org and example.net, if the host ignores example.net DNSSL, then any relative lookups for hostnames within example.net that don't exist in example.com or example.org will be looked up in root, and perhaps resolve unexpectedly if they're for one of the new vanity GTLDs.

In other words, a host should remember completely the set of unique DNSSL values it receives, because they're each expressing something different. The set of unique DNSSL values are not equivalents, so none of them should be ignored.

Regards,
Mark.


________________________________
From: Mark ZZZ Smith <[e-mail]>
To: Erik Kline <[e-mail]>; Ole Troan <[e-mail]> 
Cc: 6man Chairs <[e-mail]>; 6man WG <[e-mail]> 
Sent: Friday, 19 June 2015, 17:59
Subject: Re: 6MAN WG Adoption call : draft-jeong-6man-rdnss-rfc6106-bis



Hi,

I provided quite a bit of feedback on the draft Fernando wrote up about this, which doesn't seem to have been considered/included. For example, I don't think retaining a subset of DNSSL option values is the right thing to do because they're not providing information about alternative entities that provide or are expected to provide the equivalent service, unlike the RDNSS options.


https://www.ietf.org/mail-archive/web/ipv6/current/msg22436.html

  

A further thought I've had is that if the DNS resolver addresses are on-link, then NUD status can also be an indication of DNS resolver liveness.

I don't think the following should be followed.

--
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]).
--

It is quite valid that RA lifetimes are less than the lifetimes of the options in them - a RA router lifetime of zero means that the router issuing them is not to be used as a default router, but that doesn't mean that the RA options the RA is carrying are now invalid too (which is I think the fundamental reason why options have their own lifetimes, so option information is decoupled from the RA router lifetime). Here's what RFC4861 says about Router Lifetimes:


      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]
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.


Regards,
Mark.




________________________________
From: Erik Kline <[e-mail]>
To: Ole Troan <[e-mail]> 
Cc: 6man Chairs <[e-mail]>; 6man WG <[e-mail]> 
Sent: Friday, 19 June 2015, 12:05
Subject: Re: 6MAN WG Adoption call : draft-jeong-6man-rdnss-rfc6106-bis


+1 to extending the lifetime, I suppose
-1 to obsoleting 6106

"""
Appendix B.  Changes from RFC 6106

   The lifetime's upper bound of 2 * MaxRtrAdvInterval was shown to lead
   to the expiry of these options on links with a relatively high rate
   of packet loss.  This revision relaxes the upper bound and sets a
   higher default value to avoid this problem.
"""

Why not just have a 2-pager that updates 6106 with some discussion of
lifetime changes?

On Tue, Jun 9, 2015 at 5:11 AM, Ole Troan <[e-mail]> wrote:
> This message starts a two week 6MAN Working Group Last Call on adopting:
>
>     Title           : IPv6 Router Advertisement Options for DNS Configuration
>     Authors     : J. Jeong, S. Park, L. Beloeil, S. Madanapalli
>     Filename   : draft-jeong-6man-rdnss-rfc6106-bis
>     Pages       : 18
>     Date          : 2015-05-09
>
>    http://datatracker.ietf.org/doc/draft-jeong-6man-rdnss-rfc6106-bis/
>
> as a working group item. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on June 22nd, 2015.
>
> This document is intended to resolve the issues with RFC6106 documented in draft-gont-6man-slaac-dns-config-issues.
>
> Regards,
>
> Bob Hinden & Ole Trøan
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6



> --------------------------------------------------------------------
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------