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

[神明達哉 <[e-mail]>]

At Tue, 9 Feb 2016 10:54:16 +0100,
[e-mail] wrote:

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

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