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

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

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.
Re: Some thoughts/comments on draft-gont-6man-slaac-dns-config-issues-01

|   |
|   |   |   |   |   |
| Re: Some thoughts/comments on draft-gont-6man-slaac-dns-config-issues-01Hi, CC'ing Mark Andrews, because he is one of the DNS experts I'm aware of, so it would be good to get his input. I'm having a read though, here are some thoughts/comments I have on it.  |
|  |
| View on www.ietf.org | Preview by Yahoo |
|  |
|   |


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