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

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

At Mon, 7 Mar 2016 04:21:59 +0900,
"Mr. Jaehoon Paul Jeong" <[e-mail]> wrote:

> > - Section 6

> >   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: [...]  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.
> >
> >  => I tried the current text as follows:

I don't think the revised text really addresses my point (or I was not
clear enough).  According to a follow-up message from the chairs they
don't seem to be willing to change text that hasn't been changed from
RFC6106, but just in case we can still make it the document more
sense, I'd like to propose alternate text.  It replaces the entire
Section 6, although the first paragraph is intact:

   For the configuration and management of DNS information, the
   advertised DNS configuration information can be stored and managed in
   both the DNS Repository and the Resolver Repository.

   Since there is nothing special in an RA message as a link-local
   ICMPv6 message, a user space application should be readily able to
   get access to its content including the RDNSS or DNSSL option by
   the standard socket API [RFC3542].  Environments where the DNS
   information (i.e., RDNSS addresses and DNS search domain names) is
   stored in the user space can take this approach.  Note that this is
   the case even if some other parts of the ND protocol such as router
   discovery or link-layer address resolution are performed within the
   kernel.

   For some peculiar environments that do not provide such an API and
   still need to store the DNS information in the user space, it is
   necessary to synchronize the DNS information in the kernel space
   and the Resolver Repository in user space.  For the
   synchronization, the implementation should provide a write
   operation for updating DNS information from the kernel to the
   Resolver Repository.  One 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.  Whenever there is an expired entry in the DNS
   Repository, the daemon can delete the corresponding entry from the
   Resolver Repository.

BTW, out of curiosity is there any such "peculiar" environment?  As I
said BSDs shouldn't need such an ugly hack.  I don't know much detail
of Linux, but a quick look at the man page of its rdnssd(8) it also
seems to work on the received RA content directly (though not using
the standard API - Linux is notorious about its lack of support of the
API).  If this "environment" is only an imaginary thing, I'd even
consider removing the third paragraph (or the second paragraph of the
original draft).

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

I'd also remove the duplicate 'e.g.' from the first sentence of
Section 6.3:

   When an IPv6 host receives the information of multiple DNSSL domain
   names within a network (e.g., campus network and company network)

> >   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.
> >
> >  => I replaced "RECOMMENDED" with "MAY" as follows:
>       The Secure Neighbor Discovery (SEND) protocol [RFC3971] MAY be used
>       as a security mechanism for ND.  In this case, ND can use SEND to
>       allow all the ND options including the RDNSS and DNSSL options to be
>       automatically included in the signatures.  Other approaches specified
>       in [RFC4861] can be used for securing the RA options for DNS
>       configuration.

Personally, I don't even see the need for using an RFC2119 keyword
here, but if non one else bothers I wouldn't object.  But in any case
I think this change has to be noted in Appendix A.

--
JINMEI, Tatuya