Subject: 6MAN Working group last call: draft-ietf-6man-rdnss-rfc6106bis

From: [email-masked]
Date: Tue, 9 Feb 2016 10:54:16 +0100

This message starts a two week 6MAN Working Group Last Call on advancing:

     Title    : IPv6 Router Advertisement Options for DNS Configuration
     Authors  : J. Jeong, S. Park, L. Beloeil, S. Madanapalli
     Filename : draft-ietf-6man-rdnss-rfc6106bis-06
     Pages    : 17
     Date     : 2015-10-09

    https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-06

as a Proposed Standard.  Substantive comments and statements of support for publishing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 23 February 2016.

We would like this document to follow the experimental document shepherd procedure. We will need a volunteer document shepherd, before we can advance this document.

Best regards,
Ole & Bob

---

From: Fernando Gont <[email-masked]>
Date: Tue, 9 Feb 2016 09:23:57 -0300

> We would like this document to follow the experimental document shepherd procedure. We will need a volunteer document shepherd, before we can advance this document.

I can volunteer for that if it helps.

Thanks!

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

---

From: [email-masked]
Date: Wed, 10 Feb 2016 11:04:25 +0100

> I can volunteer for that if it helps.

Thank you!

Shepherding educational material is here:

http://ietf.org/edu/tutorials/document-editing-sheparding.pdf
https://tools.ietf.org/html/rfc4858
https://www.ietf.org/iesg/statement/document-shepherds.html

I have updated the state in the datatracker to reflect the document shepherd:
https://datatracker.ietf.org/doc/draft-ietf-6man-rdnss-rfc6106bis/

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Feb 2016 23:58:28 -0300

Folks,

I'm shepherding this document, and so far there have been no comments or
reviews during the (on-going) WGLC.

If possible, please:

1) Send your comments as indicated by the 6man chairs (see below).

2) It would be great if two folks could volunteer for a detailed review.

Thanks!
Fernando

On 02/09/2016 06:54 AM, [email-masked] wrote:
> Authors  : J. Jeong, S. Park, L. Beloeil, S. Madanapalli Filename :
> draft-ietf-6man-rdnss-rfc6106bis-06 Pages    : 17 Date     :
> 2015-10-09
> 
> as a Proposed Standard.  Substantive comments and statements of
> support for publishing this document should be directed to the
> mailing list.  Editorial suggestions can be sent to the authors.
> This last call will end on 23 February 2016.
> 
> We would like this document to follow the experimental document
> shepherd procedure. We will need a volunteer document shepherd,
> before we can advance this document.
> 
> Best regards, Ole & Bob
> 
> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 24 Feb 2016 11:27:15 -0800

> This last call will end on 23 February 2016.

I've reviewed the 06 version.  I don't have a particular opinion on
whether to publish it, but I have some comments:

- Section 5

   The IPv6 DNS configuration mechanism in this document needs two new
   ND options in Neighbor Discovery: (i) the Recursive DNS Server
   (RDNSS) option and (ii) the DNS Search List (DNSSL) option.

  "new" sounds like awkward since, well, it's not new any more.  I
  don't know the usual practice (if any) in cases like this for "-bis"
  specifications, but I'd suggest just removing "new".

- Section 5.1

     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.

  Shouldn't "relative to the time the packet is sent" actually be
  "relative to the time the packet is received"?  In practice these
  two wouldn't be different very much anyway, but, technically, the
  former looks awkward to me since the recipient can't know that time.

- Section 5.1

   Note:  [...]  The link zone indices SHOULD be
      represented in the textual format for scoped addresses as
      described in [RFC4007].

  Perhaps the actual intent is "The link-local addresses SHOULD be
  represented with their link zone indices in the textual format for
  scoped addresses as described in [RFC4007]."?  Also, it's not very
  clear to me why it's a "SHOULD".  Maybe because it's convenient as
  the DNS client (stub resolver) implementation can simply pass the
  textual text (whether it's link-local or not) to a utility function
  like getaddrinfo()?  If so, that's understandable, but I guess it's
  not obvious and should be explained explicitly.  Also, I'm not sure
  if this convenience (if that's the reason for the SHOULD) is worth
  the RFC2119 keyword.  While it'd certainly be convenient, this seems
  to be a pure implementation choice.

- Section 5.2: s/name/names/

     Lifetime      32-bit unsigned integer.  The maximum time, in
                   [...]
                   (0xffffffff) represents infinity.  A value of zero
                   means that the DNSSL domain name MUST no longer be
                   used.

- Section 5.2

     Domain Names of DNS Search List
                   One or more domain names of DNS Search List that MUST
                   be encoded using the technique described in Section
                   3.1 of [RFC1035].

  The word "technique" sounds awkward to me as it's the standard wire
  format of domain names.  I suggest, e.g., just saying "...encoded as
  described in Section 3.1 of [RFC1035]".

- Section 6

   In environments where the DNS information is stored in user space and
   ND runs in the kernel, it is necessary to synchronize the DNS
   information (i.e., RDNSS addresses and DNS search domain names) in
   kernel space and the Resolver Repository in user space.  For the
   synchronization, an implementation where ND works in the kernel
   should provide a write operation for updating DNS information from
   the kernel to the Resolver Repository.  One simple approach is to
   have a daemon (or a program that is called at defined intervals) that
   keeps monitoring the Lifetimes of RDNSS addresses and DNS search
   domain names all the time.  [...]

  This seems to assume that "ND runs in the kernel" means that all
  information in RAs is managed in the kernel.  I don't know if
  there's such an implementation (does Linux work that way?), but it
  doesn't necessarily have to be so, and is actually different from
  the BSD implementation: the FreeBSD's rtsol(d) completely works as a
  user space application, receives RA via an ICMPv6 socket using the
  standard advanced socket API (RFC3542), and manages RDNSS
  implementation independently from the kernel (even if some other
  parts of the RA are managed in the kernel).  So, I'd at least
  suggest clarifying that this kind of approach is only necessary for
  some deviant protocol stack implementation that doesn't even support
  RFC3542.  And, I'd also mention the FreeBSD-style approach as it
  should be more generic and portable.

- Section 6.3: this section largely repeats the text of Section 6.2
  and looks redundant to me.  I'd consider unifying these two sections
  and eliminate unnecessary duplicates.

- Section 6.3: on a related point, this text looks awkward:

      Step (b): For each DNSSL domain name, check the following: [...]
      [...] for certain reasons in network management,
      e.g., the termination of the RDNSS or a renaming situation.  That
      is, the RDNSS can resign from its DNS service because the machine
      running the RDNSS is out of service intentionally or
      unintentionally.  Also, under the renaming situation, the DNSSL

  How can the termination of a particular RDNSS mean that DNSSL names
  are not usable anymore?  There may be a case where one event is
  realted to the other, but I don't see any obvious relationship
  between these two (the RDNSS may simply be replaced with a new,
  different node).  This text rather seems to be a result of a naive
  copy of Section 6.2.

- Section 7.1, second paragraph.  Most of the text in this paragraph
  is irrelevant to this protocol and looks redundant to me.  I'd
  consider just referring to some other document for the general
  issue.

- Section 7.2

   The Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a
   security mechanism for ND.  It is RECOMMENDED that ND use SEND to
   allow all the ND options including the RDNSS and DNSSL options to be
   automatically included in the signatures.

  I don't think this "RECOMMENDED" is realistic.  As a matter of fact,
  SEND isn't even widely implemented, and, IMO, its deployability
  issues are not easily resolved.  I don't have a specific suggestion
  on how to make the whole text realistic, but I'd at least suggest
  stopping to make such an unrealistic requirement, especially with an
  RFC2119 keyword.

--
JINMEI, Tatuya

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 25 Feb 2016 13:52:35 +0000

Hi Dear authors,

I've read the draft. It was my first time to read it, so please pardon me if I iterated some questions that had been addressed before.

1. Since RFC5006 was already obsolete by RFC6106, and this document is going to obsolete 6106, I guess this draft should not necessary to mention 5006 anymore?
When the document says it defines a "new" option (DNSSL), it is still comparing to 5006. But it is not "new" comparing to 6106. So this is a bit confusing for me.
So I'd suggest the whole text be tweaked in the perspective of obsolete RFC6106, not just iterate it.

2. Section 1.1, page3
"  Furthermore,
   the host learns this DNS configuration from the same RA message that
   provides configuration information for the link, thereby avoiding
   also running DHCPv6."
Do you mean the host decides not to initial DHCPv6?
I think "avoiding also running DHCPv6" should not be a principle from hosts' perspective. That should come from the administrator's deployment plan.

3. Section 5.3.2
" Second, if different DNS information is provided on different network
   interfaces, this can lead to inconsistent behavior.  The IETF is
   working on solving this problem for both DNS and other information
   obtained by multiple interfaces [MIF-PROBLEM][MIF-PRACTICE]. "

Regarding MIF problems, I think it's nice to mention RFC6731 here, which is the solution for DNSS selection.
Btw, the [MIF-PROBLEM][MIF-PRACTICE] are already RFC6418 and RFC6419.

4. Section 7.2
"It is RECOMMENDED that ND use SEND to
   allow all the ND options including the RDNSS and DNSSL options to be
   automatically included in the signatures."
I think recommending SEND is not very specific to this document. We should have more considerations whether to use SEND, not only in term of protecting RDNSS/DNSSL options.

5. Section 1.1, page 3
"However, when in many networks some additional information needs to be distributed, those networks are likely to employ DHCPv6."
This sentence reads a bit odd. I guess you intended to mean like this:
" However, for networks that need to distribute additional information, DHCPv6 is likely to be employed."

Best regards,
Bing

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, February 09, 2016 5:54 PM
> To: 6man WG
> Cc: [email-masked]
> Subject: 6MAN Working group last call: draft-ietf-6man-rdnss-rfc6106bis
> 
> as a Proposed Standard.  Substantive comments and statements of support
> for publishing this document should be directed to the mailing list.  Editorial
> suggestions can be sent to the authors.  This last call will end on 23
> February 2016.
> 
> We would like this document to follow the experimental document shepherd
> procedure. We will need a volunteer document shepherd, before we can
> advance this document.
> 
> Best regards,
> Ole & Bob