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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>


-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: [phone]
Email: [e-mail], [e-mail]
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php