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

Hi all,
Here is the revision draft having the changes from RFC 6106, which are
based on
the email discussion.
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-02

The changes are as follows:
------------------------------------------------------------------------
Appendix B.  Changes from RFC 6106

   The following changes were made from RFC 6106 "IPv6 Router
   Advertisement Options for DNS Configuration":

   o  The generation of Router Solicitation to ensure that the RDNSS
      information is fresh before the expiry of the RDNSS option is
      removed in order to prevent multicast traffic on the link from
      increasing.

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

   o  The lifetimes of RDNSS and DNSSL options are decoupled from Router
      Lifetime.  An RA router lifetime of zero does not cause the RDNSS
      and DNSSL options to be considered invalid because these options
      have their own lifetime values.  Thus, due to the expiry of the RA
      router lifetime, the lists in the RDNSS and DNSSL options are not
      guaranteed to be reachable at any point in time.

   o  The recommendation that at most three RDNSS addresses to maintain
      by RDNSS options should be limited is removed.  By this removal,
      the number of RDNSSes to maintain is up to an implementer's local
      policy.

   o  The recommendation that at most three DNS domains to maintain by
      DNSSL options should be limited is removed.  By this removal, when
      the set of unique DNSSL values are not equivalent, none of them
      are ignored for hostname lookups.
------------------------------------------------------------------------

Thanks.

Paul

On Mon, Aug 10, 2015 at 5:42 PM, David Farmer <farmer@umn.edu> wrote:

> I would think a summary of the changes just made needs to be added to
> Appendix B.  To accurately reflect the changes since RFC6106 and help
> implementers know what they need to change to comply with the new
> specification.
>
> Other than that looks good to me.
>
> Thanks
>
> On 8/10/15 15:31 , Mr. Jaehoon Paul Jeong wrote:
>
>> Hi all,
>> I reflected Ole's suggestion on the revised draft:
>> https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-01
>>
>> If you have further comments, please let us know.
>>
>> Thanks.
>>
>> Paul
>>
>> On Fri, Jul 24, 2015 at 2:00 AM, Ole Troan <otroan@employees.org
>> <mailto:otroan@employees.org>> wrote:
>>
>>     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
>>
>>     --------------------------------------------------------------------
>>     IETF IPv6 working group mailing list
>>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>     --------------------------------------------------------------------
>>
>>
>>
>>
>> --
>> ===========================
>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>> Assistant Professor
>> Department of Software
>> Sungkyunkwan University
>> Office: +82-31-299-4957
>> Email: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>,
>> pauljeong@skku.edu <mailto:pauljeong@skku.edu>
>> Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>
> --
> ================================================
> David Farmer               Email: farmer@umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE     Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> ================================================
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@gmail.com, pauljeong@skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php