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

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

Hi Jinmei,
I have submitted the revised draft:
https://tools.ietf.org/html/draft-ietf-6man-rdnss-rfc6106bis-09

Here are my answers for your comments below.

On Tue, Mar 8, 2016 at 3:21 AM, 神明達哉 <[e-mail]> wrote:

> 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.
>
>  => Along with Ole's comments, I prefer to leave Section 6 for the general
guidelines of the implementation of the RA DNS Options.
I modified the beginning of Section 6 as follows:

   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.  These two
   repositories should be synchronized however the processing of RA DNS
   options are implemented in the kernel space or user space.

 => Also, I specified this change in Appendix A:

   o  The guidance of the specific implementation for the
      synchronization of the DNS Repository and Resolver Repository on
      the kernel space and user space is removed.


> 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 removed the 'e.g.' as follows:

   When an IPv6 host receives the information of multiple DNSSL domain
   names within a network through an RA message with DNSSL option(s), it
   stores the DNSSL domain names (in order) into both the DNS Search
   List and the Resolver Repository.

> >   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.
>
>  => I removed the keyword "MAY" for SEND and have the following text:

   The Secure Neighbor Discovery (SEND) protocol [RFC3971] is designed
   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.

 => Also, I specified this change in Appendix A:

   o  The usage of the keywords of SHOULD and RECOMMENDED in RFC 2119 is
       removed in the recommendation of using SEND for secure ND.
       Instead of the keywords, SEND is specified as a possible solution
       for secure ND.

 Thanks.

 Best Regards,
 Paul

--
> JINMEI, Tatuya
>



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