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

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 11 Aug 2015 05:31:33 +0900

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 <[email-masked]> 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
> [email-masked]
> 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: [email-masked], [email-masked]
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php

---

From: David Farmer <[email-masked]>
Date: Mon, 10 Aug 2015 16:42:05 -0500

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:
> On Fri, Jul 24, 2015 at 2:00 AM, Ole Troan <[email-masked]
> <mailto:[email-masked]>> 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:
>         (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
>
>     [email-masked] <mailto:[email-masked]>
> Email: [email-masked] <mailto:[email-masked]>,
> [email-masked] <mailto:[email-masked]>

-- 
================================================
David Farmer               Email: [email-masked]
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
================================================

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 11 Aug 2015 07:02:22 -0400

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