Re: Review of draft-ietf-6man-rdnss-rfc6106bis-06

[[e-mail]]

All,

We are trying to limit comments and possible changes to this document to the change from RFC6106.
Apologies for not making that clear in the WGLC announcement.

Best regards,
Ole


> On 23 Feb 2016, at 23:03, Fernando Gont <[e-mail]> wrote:
> 
> Folks,
> 
> Below you'll find a detailed review of this document. (I would be great
> if, besides the authors, other folks could comment on the technical
> issues raised below)
> 
> 
> ** Technical **
> 
> * Section 1, page 3:
>> Most Internet services are
>>   identified by using a DNS name.  The two RA options defined in this
>>   document provide the DNS information needed for an IPv6 host to reach
>>   Internet services.
> 
> I'd not use the term "services" here, but rather use "names" in the
> first instance, and possible "servers" in the second one.
> 
> 
> * Section 1, page 3:
>> For instance, locally defined name
>>   spaces would not be available to the host if it were to run its own
>>   name server software directly connected to the global DNS.
> 
> s/name server software/recursive name server/?
> 
> 
> * Section 1, page 3:
>> The DNS information can also be provided through DHCP [RFC3315]
>> [RFC3736][RFC3646].
> 
> s/DHCP/DHCPv6/
> 
> 
> * Section 3, page 4:
>> 
>>   o  Recursive DNS Server (RDNSS): Server that provides a recursive DNS
>>      resolution service for translating domain names into IP addresses
>>      as defined in [RFC1034] and [RFC1035].
> 
> Not sure if you should augment this definition, as e.g. resolving PTR
> records is not about "mapping names into IP addresses".
> 
> 
> * Section 3, page 5:
>> 
>>   o  DNS Repository: Two data structures for managing DNS Configuration
>>      Information in the IPv6 protocol stack in addition to Neighbor
>>      Cache and Destination Cache for Neighbor Discovery [RFC4861].  The
>>      first data structure is the DNS Server List for RDNSS addresses
>>      and the second is the DNS Search List for DNS search domain names.
> 
> Maybe call this structure "Recursive DNS Server List" instead?
> 
> 
> * Section 3, page 5:
>> 
>>   o  DNS Repository: Two data structures for managing DNS Configuration
>>      Information in the IPv6 protocol stack in addition to Neighbor
>>      Cache and Destination Cache for Neighbor Discovery [RFC4861].  The
>>      first data structure is the DNS Server List for RDNSS addresses
>>      and the second is the DNS Search List for DNS search domain names.
>> 
>>   o  Resolver Repository: Configuration repository with RDNSS addresses
>>      and a DNS Search List that a DNS resolver on the host uses for DNS
>>      name resolution; for example, the Unix resolver file (i.e., /etc/
>>      resolv.conf) and Windows registry.
> 
> 
> The difference between these two is not clear. Is the only difference
> that the later is maintained in persistent storage, or what?
> 
> 
> * Section 4, page 5:
>> 
>>   This document standardizes the ND option called the RDNSS option
>>   defined in [RFC5006] that contains the addresses of recursive DNS
>>   servers.
> 
> This text is confusing. Advice: Do not mention RFC5006 other than in the
> intro.
> 
> 
> * Section 4, page 5:
>> The
>>   RA options for RDNSS and DNSSL can be used on any network that
>>   supports the use of ND.
> 
> mmm... isn't ND mandatory, anyway?
> 
> 
> * Section 5.3.1, page 8:
>>   o  The validity of DNS options is checked with the Length field; that
>>      is, the value of the Length field in the RDNSS option is greater
>>      than or equal to the minimum value (3), and the value of the
>>      Length field in the DNSSL option is greater than or equal to the
>>      minimum value (2).
> 
> The RDNSS option should have an additional validation check:
> (Length -1) % 2 == 0
> 
> Additionally, you should validate the addresses: e.g., they should be
> unicast addresses.
> 
> 
> 
> * Section 5.3.1, page 9:
>> Unless explicitly specified for
>>   the discovery mechanism, the exact number of addresses and domain
>>   names to keep is a matter of local policy and implementation choice.
> 
> Are you referring to some local configuration option, or something else?
> 
> 
> * Section 5.3.1, page 9:
>> However, the ability to store at least three RDNSS addresses (or
>>   DNSSL domain names) from at least two different sources is
>>   RECOMMENDED.
> 
> If there are two sources, this would mean e.g., a total of 6 addresses?
> Or a total of three?
> 
> 
> * Section 5.3.2, page 9:
>> Therefore,
>>   the network administrator needs to configure DNS options in multiple
>>   sources in order to prevent such problems from happening.
> 
> As per draft-ietf-v6ops-dhcpv6-slaac-problem, this may not be enough.
> 
> 
> * Section 5.3.2, page 9:
>> Therefore,
>>   the network administrator needs to configure DNS options in multiple
>>   sources in order to prevent such problems from happening.
> 
> You mean configure *the same* info in all sources, or something else?
> (it's not clear)
> 
> 
> * Section 5.3.2, page 9:
>> 
>>   Second, if different DNS information is provided on different network
>>   interfaces, this can lead to inconsistent behavior.  The IETF is
>>   working on solving this problem for both DNS and other information
>>   obtained by multiple interfaces [MIF-PROBLEM][MIF-PRACTICE].
> 
> Without checking [MIF-PROBLEM][MIF-PRACTICE], how about mitigating this
> issue a bit by maintaining per-interface configuration -- e.g., if you
> receive DNS information in each of your interfaces, you keep such info
> on a per-interface basis rather than on a global/system-wide basis.
> 
> 
> * Section 6, pages 9-10
>>   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.
> 
> Why not just have a lib/syscall that allows you to read it from
> userspace, rather than have the kernel write to userspace?
> 
> 
> * Section 6.1, page 10:
>>   o  DNSSL domain name for DNS Search List: DNS suffix domain names,
>>      which are used to perform DNS query searches for short,
>>      unqualified domain names in the network advertising the DNSSL
>>      option.
> 
> What if you receive the RDNSS on one interface, and the DNSSL on
> another? -- put another way, not sure what you mean by "in the network
> advertising the DNSSL option"
> 
> 
> * Section 7.1, page 13:
>> Therefore, the vulnerability
>>   of ND is not worse and is a subset of the attacks that any node
>>   attached to a LAN can do independently of ND.
> 
> Not sure what you mean by "...independently of ND".
> 
> 
> 
> * Section 7.2, page 14:
> Here you're making recommendations with RFC2119. I recommend you don't.
> 
> One one hand, SEND is extremely hard to deploy (if at all possible). A
> number of popular OSes don't support it, it requires a PKI, etc., etc.
> 
> Besides, all these are operational mitigations, and your document is a
> Std Track document.
> 
> So my recommendation would be: discuss possible mitigations, reference
> the appropriate RFCs, but do not make any RFC2119 recommendations about
> this.
> 
> 
> 
> 
> ** Editorial **
> 
> * Section 1, page 3:
>>   The purpose of this document is to standardize an IPv6 Router
>>   Advertisement (RA) option for DNS Recursive Server Addresses used for
>>   the DNS name resolution in IPv6 hosts.  This RA option was originally
>>   specified in an earlier Experimental specification [RFC5006].
> 
> You should note that it was later published as Std Track in RFC6106 --
> this is not explicitly noted otherwise.
> 
> 
> * Section 1, page 3:
>>   Neighbor Discovery (ND) for IP version 6 and IPv6 stateless address
>>   autoconfiguration
> 
> Please capitalize SLAAC  -- each word, and then add the acronymn.
> 
> 
> * Section 1.2, page 4:
>> 
>>   Two protocols exist to configure the DNS information on a host, the
>>   Router Advertisement options described in this document and the
>>   DHCPv6 options described in [RFC3646].
> 
> s/described/specified/
> 
> 
> * Section 3, page 4:
>>   This document uses the terminology described in [RFC4861] and
>>   [RFC4862].  In addition, four new terms are defined below:
> 
> s/described/defined/
> 
> 
> * Section 6.1, page 10:
>> When Expiration-time becomes less than the current system
>>      time, this entry is regarded as expired.
> 
> Probably just me being pedantic, but I'd phrase it as "when the current
> time becomes larger than..." (it's the current time that changes, rather
> than the expiration time).
> 
> 
> * Appendix A, page 17:
> 
> Please remove this appendix. Such changelog is in 6106, already.
> 
> 
> * Appendix B, page 18:
>> 
>>   o  The lifetimes of RDNSS and DNSSL options are decoupled from Router
>>      Lifetime.  An RA router lifetime of zero does not cause the RDNSS
>>      and DNSSL options to be considered invalid because these options
>>      have their own lifetime values.  Thus, due to the expiry of the RA
>>      router lifetime, the lists in the RDNSS and DNSSL options are not
>>      guaranteed to be reachable at any point in time.
> 
> While you have removed the corresponding text, I think this deserves a
> clarification in the body of the document. i.e., clarify that the DNS
> info need not be dropped if [..].
> 
> Thanks!
> 
> Best regards,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------