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

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

Hi Jinmei,
Thanks for your comments.
I will reflect yours on the revision.

6MAN WG,
for Linux implementation for RDNSS,
are there any other comments from Jinmei below?

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

Thanks.

Paul

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



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