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

[[e-mail]]

I would in general prefer not to see implementation specific text or text on specific implementation issues in a protocol specification.
I don't think any discussion on kernel vs user space belongs.

Best regards,
Ole


> On 07 Mar 2016, at 19:21, 神明達哉 <[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
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------