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

From: Ole Troan <[email-masked]>
Date: Mon, 8 Jun 2015 22:11:50 +0200

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

---

From: Tomoyuki Sahara <[email-masked]>
Date: Fri, 19 Jun 2015 14:39:49 +0900

I support adoption.

> On Jun 9, 2015, at 05:11, Ole Troan <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Erik Kline <[email-masked]>
Date: Fri, 19 Jun 2015 11:05:14 +0900

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

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 19 Jun 2015 07:59:23 +0000 (UTC)

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 <[email-masked]>
 To: Ole Troan <[email-masked]> 
Cc: 6man Chairs <[email-masked]>; 6man WG <[email-masked]> 
 Sent: Friday, 19 June 2015, 12:05
 Subject: Re: 6MAN WG Adoption call : draft-jeong-6man-rdnss-rfc6106-bis

"""

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Fri, 19 Jun 2015 12:27:13 +0200

> Why not just have a 2-pager that updates 6106 with some discussion of

If the Appendix B is the only diff from 6106, then:

+1 to have a short doc like Erik proposes above that makes a point
update relaxing the constraints in 6106

-1 to adopt a doc doing wholesale rewrite of 6106

--a

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Jun 2015 08:08:19 +1200

> -1 to adopt a doc doing wholesale rewrite of 6106

+1 to a simple update with only the directly affected words rewritten.
(I think a better final state is to have only one RFC that future implementers
need to read.)

-1 to any changes except the minimum necessary to change the default value.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 19 Jun 2015 13:39:49 -0700

Brian,

> On Jun 19, 2015, at 1:08 PM, Brian E Carpenter <[email-masked]> wrote:
> 

The chairs thought it would be a better outcome to have a single RFC for implementors than, in this case two for them to read.  Especially given the change to fix the problem is very confined.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 Jun 2015 08:06:01 -0300

Folks,

FWIW, that's what we tried to do in:
<https://www.ietf.org/id/draft-gont-6man-slaac-dns-config-issues-01.txt>

Thanks,
Fernando

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492