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

[Ole Troan <[e-mail]>]

Mark, et al:

looking more closely at the issues Mark has pointed out, I fear we have to fix a few more bugs than I originally intended.

possible set of changes:

Section 5.1:
OLD:
Lifetime      32-bit unsigned integer.  The maximum time, in
                   seconds (relative to the time the packet is sent),
                   over which this RDNSS address MAY be used for name
                   resolution.  Hosts MAY send a Router Solicitation to
                   ensure the RDNSS information is fresh before the
                   interval expires.  The value of Lifetime SHOULD by
                   default be at least 3 * MaxRtrAdvInterval where
                   MaxRtrAdvInterval is the Maximum RA Interval defined
                   in [RFC4861].  A value of all one bits (0xffffffff)
                   represents infinity.  A value of zero means that the
                   RDNSS address MUST no longer be used.

NEW:
Lifetime      32-bit unsigned integer.  The maximum time, in
                   seconds (relative to the time the packet is sent),
                   over which this RDNSS address MAY be used for name
                   resolution. The value of Lifetime SHOULD by
                   default be at least 3 * MaxRtrAdvInterval where
                   MaxRtrAdvInterval is the Maximum RA Interval defined
                   in [RFC4861].  A value of all one bits (0xffffffff)
                   represents infinity.  A value of zero means that the
                   RDNSS address MUST no longer be used.

Section 5.2
OLD:
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]).
NEW:
  <deleted paragraph>

Section 5.3.1
OLD:
   When the IPv6 host has gathered a sufficient number (e.g., three) of
   RDNSS addresses (or DNS search domain names), it SHOULD maintain
   RDNSS addresses (or DNS search domain names) by the sufficient number
   such that the latest received RDNSS or DNSSL is more preferred to the
   old ones; that is, when the number of RDNSS addresses (or DNS search
   domain names) is already the sufficient number, the new one replaces
   the old one that will expire first in terms of Lifetime.  As an
   exceptional case, if the received RDNSS addresses (or DNS search
   domain names) already exist in the IPv6 host, their Lifetime fields
   update their Expiration-time, that is, when the corresponding DNS
   information expires in the IPv6 host; note that when the Lifetime
   field has zero, the corresponding RDNSS (or DNS search domain name)
   is deleted from the IPv6 host.  Except for this update, the IPv6 host
   SHOULD ignore other RDNSS addresses (or DNS search domain names)
   within an RDNSS (or a DNSSL) option and/or additional RDNSS (or
   DNSSL) options within an RA.  Refer to Section 6 for the detailed
   procedure.  Note that the sufficient number is a system parameter, so
   it can be determined by a local policy.  Also, separate parameters
   can be specified for the sufficient number of RDNSS addresses and
   that of DNS search domain names, respectively.  In this document,
   three is RECOMMENDED as a sufficient number considering both the
   robust DNS query and the reasonably time-bounded recognition of the
   unreachability of DNS servers.

NEW:
   <deleted>
   (I tried making sense of this paragraph, I think the document would read better without it, but if someone can propose correct text that would be fine)

cheers,
Ole