Subject: Gen-ART LC Review of draft-ietf-6man-dns-options-bis-03

From: Ben Campbell <[email-masked]>
Date: Mon, 21 Jun 2010 17:07:50 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-6man-dns-options-bis-03
Reviewer: Ben Campbell
Review Date: 2010-06-21
IETF LC End Date: 2010-06-23
IESG Telechat date: (if known)

Summary:

This draft is almost ready for publication as a proposed standard. However, there are some issues, both substantive and editorial, that should be considered prior to publication.

Major issues:

-- 5.3.1, last paragraph: 
"In the case where the DNS options of RDNSS and DNSSL can be obtained
from multiple sources, such as RA and DHCP, the IPv6 host can keep
some DNS options from RA and some from DHCP; for example, two RDNSS
addresses (or DNS search domain names) from RA and one RDNSS address
(or DNS search domain name) from DHCP."

This seems underspecified. For example, can it choose the last value from each? How is the host to guess which to keep? How can an administrator get predictable behavior? Mixing some from one source and another from the second seems, on the surface, like the worst possible behavior. Since using RA for this was described as an alternative for when DHCPv6 was not available, wouldn't it make more sense for dhcp to win?

Furthermore, this makes me wonder if the concept here needs more thought. Under what circumstance would you be both doing stateless autoconfig and getting DHCPv6 for the _same_ interface?

Minor issues:

-- 5.3.1, 2nd to last paragraph: "When the IPv6 host has gathered a sufficient number (e.g., three)"

Can you provide guidance on what is reasonable sufficient? Did you mean 3 as a recommendation?

--5.3.1, 2nd to last paragraph: "it MAY ignore additional RDNSS addresses (or DNS search domain names) within an
RDNSS (or DNSSL) option and/or additional RDNSS (or DNSSL) options within an RA."

How does this interact with lifetimes? This seems a little underespecified.

-- 6.2, 2nd to last paragraph: "Note that, in the case where there are several routers advertising RDNSS option(s) in a subnet, the RDNSSes that have been announced recently are preferred."

Can you elaborate on why this is the case?

Nits/editorial comments:

-- General
 Idnits reports some lines over 72 characters. Please check.

-- Section 4, paragraph 1: "option called RDNSS option"

 _the_ RDNSS option

-- section 4, paragraph 1:"called DNSSL option"
 
_the_ DNSLL option

-- section 4, paragraph 2:"Existing ND message"

_The_ [or An] existing ND message ...

-- Section 5.1, Field Type :"8-bit identifier of the RDNSS option type as assigned by the IANA: 25"

Has IANA already assigned 25, or is this a recommendation? Why is there a number here but TBD in the other field type?

-- Section 5.1, Lifetime: "the value of Lifetime should be at least as long as the Maximum RA Interval (MaxRtrAdvInterval) in [RFC4861], and be at SHOULD be bounded as follows: MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval."

If I'm reading this right, it seems like the sentence repeats the same thing twice.

-- 5.3.1, first paragraph: "follow:"
 
follows

-- 5.3.1, first two bullets:  

This is confusing to me due to the way the determination of validity and actions to take if it is valid or invalid are intertwined. It would be better to first state how to determine validity, then say what actions to take if it is valid or invalid.

-- 6.2, 2nd paragraph (Step a): "Note that Step (e) is performed whenever an entry expires in the
DNS Server List."

It seems like step (e)  doesn't belong in the list, since the rest of e list is triggered by receiving an RA. That is, it's not part of the same sequence of actions as the rest of the list.

-- 6.2, 2nd to last paragraph: "In the order in the RDNSS option, position the newly added RDNSS addresses in front of
the Resolver Repository so that the new RDNSS addresses may be name resolution."

The sentence is hard to parse. Are the two mentions of RDNSS order redundant?

-- 6.3, 2nd paragraph: "Note that Step (e) is performed whenever an entry expires in
the DNS Search List."

It seems like step (e)  doesn't belong in the list, since the rest of e list is triggered by receiving an RA. That is, it's not part of the same sequence of actions as the rest of the list.

-- 7, first paragraph: "It can be claimed that the..."

So are you asserting that claim, or just mentioning that you could? (Pattern repeats at least one more time further down.)

---

From: Jaehoon Paul Jeong <[email-masked]>
Date: Thu, 24 Jun 2010 18:13:22 -0500

Hi Ben,
First of all, I sincerely appreciate your review work on our I-D.
I tried to address all of your comments with a revised version:
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-04.txt

The difference between version 03-and version-04 can be found in
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdiff%20draft-ietf-6man-dns-options-bis-03_txt%20draft-ietf-6man-dns-options-bis-04_txt.htm

Also, I answered your comments inline as below:

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Monday, June 21, 2010 5:08 PM
> To: [email-masked]
> Cc: General Area Review Team; IETF Discussion
> Subject: Gen-ART LC Review of draft-ietf-6man-dns-options-bis-03
>

The new text for these questions is as follows:

   In the case where the DNS options of RDNSS and DNSSL can be obtained
   from multiple sources, such as RA and DHCP, the IPv6 host can keep
   some DNS options from RA; the sufficient number of RDNSS addresses or
   DNS search domain names is determined as a reasonable number (e.g.,
   three) by the local policy.  On the other hand, for DHCP DNS options,
   the DHCP configuration determines the number of DNS options
   advertised to IPv6 hosts, so the sufficient number is out of scope in
   this document.  With these sufficient numbers of RDNSS addresses and
   DNS search domain names, the DNS options from RA and DHCP are stored
   into DNS Repository and Resolver Repository in the order that the
   latest received RDNSS or DNSSL is most preferably used for DNS
   queries.

With this text, the sufficient number of RDNSS addresses in RA DNS
options is determined
according to the local policy, independent of DHCP.

> Can you provide guidance on what is reasonable sufficient? Did you mean 3 as a recommendation?

The number of three is arguable, but the previous DNS work recommended
three for RDNSS addresses as follows:
http://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07

Also, I added the new text in Section 5.3.1 as follows:

   In this document, three is recommended as a
   sufficient number considering both the robust DNS query and the
   reasonably time-bounded recognition of the unreachability of DNS
   servers.

> How does this interact with lifetimes? This seems a little underespecified.

The new text for this comment is as follows:

   When the IPv6 host has gathered a sufficient number (e.g., three) of
   RDNSS addresses (or DNS search domain names), it SHOULD maintain
   RDNSS addresses (or DNS search domain names) by the sufficient number
   such that the latest received RDNSS or DNSSL is more preferred to the
   old ones; that is, when the number of RDNSS addresses (or DNS search
   domain names) is already the sufficient number, the new one replaces
   the old one that will expire first in terms of Lifetime.  In this
   case, the IPv6 host SHOULD ignore additional RDNSS addresses (or DNS
   search domain names) within an RDNSS (or DNSSL) option and/or
   additional RDNSS (or DNSSL) options within an RA.  Note that the
   sufficient number is a system parameter, so it can be determined by a
   local policy.  Also, separate parameters can be specified for the
   sufficient number of RDNSS addresses and that of DNS search domain
   names, respectively.  In this document, three is recommended as a
   sufficient number considering both the robust DNS query and the
   reasonably time-bounded recognition of the unreachability of DNS
   servers.

> Can you elaborate on why this is the case?

I deleted this sentence because our DNS options can work regardless of
the number of routers advertising
RA DNS options in a subnet.

>  Idnits reports some lines over 72 characters. Please check.

I checked Idnits. There is no issue.

> -- Section 4, paragraph 1: "option called RDNSS option"

I added "the".

> -- section 4, paragraph 1:"called DNSSL option"

I added "the".

> _The_ [or An] existing ND message ...

I added "The".

> Has IANA already assigned 25, or is this a recommendation? Why is there a number here but TBD in the other field type?

As the revised I-D, RDNSS option is assigned an option type in RFC
5006, but DNSSL option needs another option type.

> -- Section 5.1, Lifetime: "the value of Lifetime should be at least as long as the Maximum RA Interval (MaxRtrAdvInterval) in [RFC4861], and be at SHOULD be bounded as follows: MaxRtrAdvInterval <=…

The new text is as follows:

  the value of Lifetime SHOULD be bounded as MaxRtrAdvInterval <=
  Lifetime <= 2*MaxRtrAdvInterval where MaxRtrAdvInterval is
  the Maximum RA Interval defined in [RFC4861].

> -- 5.3.1, first paragraph: "follow:"

I corrected it as follows.

> This is confusing to me due to the way the determination of validity and actions to take if it is valid or invalid are intertwined. It would be better to first state how to determine validity, then…

The new text is organized according to this comment as follows:

   When an IPv6 host receives DNS options (i.e., RDNSS option and DNSSL
   option) through RA messages, it processes the options as follows:

   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 also the value of the
      Length field in the DNSSL option is greater than or equal to the
      minimum value (2).

   o  If the DNS options are valid, the host SHOULD copy the values of
      the options into the DNS Repository and the Resolver Repository in
      order.  Otherwise, the host MUST discard the options.

> It seems like step (e)  doesn't belong in the list, since the rest of e list is triggered by receiving an RA. That is, it's not part of the same sequence of actions as the rest of the list.

The new text is to reflect this comment as follows:

   The handling of expired RDNSSes is as follows: Whenever an entry
   expires in the DNS Server List, the expired entry is deleted from the
   DNS Server List, and also the RDNSS address corresponding to the
   entry is deleted from the Resolver Repository.

> The sentence is hard to parse. Are the two mentions of RDNSS order redundant?

The new text is as follows:

      For the ordering of RDNSS addresses in an RDNSS
      option, position the first RDNSS address in the RDNSS option as
      the first one in the Resolver Repository, the second RDNSS address
      in the option as the second one in the repository, and so on.
      This ordering allows the RDNSS addresses in the RDNSS option to be
      preferred according to their order in the RDNSS option for the DNS
      name resolution.

> It seems like step (e)  doesn't belong in the list, since the rest of e list is triggered by receiving an RA. That is, it's not part of the same sequence of actions as the rest of the list.

The new text is as follows:

      The handling of expired DNSSLs is as follows: Whenever an entry
      expires in the DNS Search List, the expired entry is deleted from
      the DNS Search List, and also the DNSSL domain name corresponding
      to the entry is deleted from the Resolver Repository.

> So are you asserting that claim, or just mentioning that you could? (Pattern repeats at least one more time further down.)

The new text is as follows:

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

Could you confirm whether the revised  I-D addressed all of your comments?

Once I get your confirmation, I will submit this revised I-D to IETF.

Thanks.

Best Regards,
Paul
 --
===========================
Paul (Jaehoon) Jeong
Software Engineer, Ph.D
Brocade
6000 Nathan Ln N, Plymouth, MN 55442
Mobile: +1.651.587.7774
Email: [email-masked]
URI: http://www.cs.umn.edu/~jjeong/

---

From: Jari Arkko <[email-masked]>
Date: Sat, 26 Jun 2010 12:11:13 +0300

Thanks for your review, Ben!

> Furthermore, this makes me wonder if the concept here needs more thought. Under what circumstance would you be both doing stateless autoconfig and getting DHCPv6 for the _same_ interface?

Let me speak with my "I deployed both mechanisms in my network" hat on 
:-) Sometimes you have to enable all possible mechanisms on the network 
side to make sure that your Windows/Apple/Linux/BSD computers and 
various appliances have a maximum chance of operating correctly.

But lets talk about the issue of underspecification. I think some of 
that is intentional, because I don't think we should specify a hard 
limit on the number of servers specified or the number of sources the 
information can come from.

However, I think I agree with you that it would be good to provide some 
predictability and make the language also tighter in other ways. And I 
don't think we can rule the DHCP side of this out of scope, because the 
DHCP RFC did not specify the interaction. How about this:

OLD: (From Paul's new version)
In the case where the DNS options of RDNSS and DNSSL can be obtained
from multiple sources, such as RA and DHCP, the IPv6 host can keep
some DNS options from RA; the sufficient number of RDNSS addresses or
DNS search domain names is determined as a reasonable number (e.g.,
three) by the local policy. On the other hand, for DHCP DNS options,
the DHCP configuration determines the number of DNS options
advertised to IPv6 hosts, so the sufficient number is out of scope in
this document. With these sufficient numbers of RDNSS addresses and
DNS search domain names, the DNS options from RA and DHCP are stored
into DNS Repository and Resolver Repository in the order that the
latest received RDNSS or DNSSL is most preferably used for DNS
queries.
NEW:
In the case where the DNS options of RDNSS and DNSSL can be obtained
from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep
some DNS options from all sources. 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. However,
it is RECOMMENDED that at least three sets of addresses and domain names
can be stored from at least two different sources. The DNS options from 
Router
Advertisements and DHCP SHOULD be stored into DNS Repository and Resolver
Repository so that information from DHCP appears there first and therefore
takes precedence.

Jari

---

From: Ben Campbell <[email-masked]>
Date: Fri, 25 Jun 2010 16:02:03 -0500

Hi, thanks for the quick response.

Followup comments inline:

> according to the local policy, independent of DHCP.

I'm still confused. Are we still talking about getting entries from both RA and DHCP on the same interface? Would this happen other than in error conditions?

>   reasonably time-bounded recognition of the unreachability of DNS

Okay, except you probably want a normative RECOMMENDED

>   reasonably time-bounded recognition of the unreachability of DNS

I'm still confused. I read this to say that, once I reach the "sufficient" number of entries, any new entry should replace the oldest existing one, but then it goes on to say that if I have enough entries I should ignore new ones?

Also, when ignoring entries, one must at least make sure the ignored entry does not match an existing entry and set the lifetime to zero, right? Otherwise, you may be ignoring a request to delete an entry.

> RA DNS options in a subnet.

Okay.

>> -- Section 4, paragraph 1: "option called RDNSS option"

Do you mean no issue for 03, or on the new version? idnits still shows the following on 03: (See http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-6man-dns-options-bis-03.txt )

>   Checking nits according to http://www.ietf.org/id-info/checklist :
>   ----------------------------------------------------------------------------
> 
>   ** There are 4 instances of too long lines in the document, the longest one
>      being 51 characters in excess of 72.
> 
> 

[...]

> 5006, but DNSSL option needs another option type.

Okay, that make sense as long as IANA understands what is meant.

>  the Maximum RA Interval defined in [RFC4861].

Okay.

[...]

>      order.  Otherwise, the host MUST discard the options.

Okay, that helps.

>   entry is deleted from the Resolver Repository.

Okay.

>      preferred according to their order in the RDNSS option for the DNS

Okay.

>      to the entry is deleted from the Resolver Repository.

Okay

>   a LAN can do independently of ND.

Okay

> Could you confirm whether the revised  I-D addressed all of your comments?

I think it addresses all of my comments except when I explicitly mentioned otherwise above. (That is, I believe anything I responded with as "okay" and anything I deleted without response to be addressed.)

---

From: Jaehoon Paul Jeong <[email-masked]>
Date: Sat, 26 Jun 2010 22:19:53 -0500

Ben,
I revised the I-D according to your follow-up comments as below:

The revised I-D is located at the following link:
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-04.txt

The difference between 03-version and 04-version is located:
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdiff%20draft-ietf-6man-dns-options-bis-03_txt%20draft-ietf-6man-dns-options-bis-04_txt.htm

> I'm still confused. Are we still talking about getting entries from both RA and DHCP on the same interface? Would this happen other than in error conditions?

According to Jari's comments and text, the new text is as follows:

   In the case where the DNS options of RDNSS and DNSSL can be obtained
   from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep
   some DNS options from all sources.  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.
   However, it is RECOMMENDED that at least three sets of addresses and
   domain names can be stored from at least two different sources.  The
   DNS options from Router Advertisements and DHCP SHOULD be stored into
   DNS Repository and Resolver Repository so that information from DHCP
   appears there first and therefore takes precedence.

   However, it is RECOMMENDED that at least three sets of addresses and
   domain names can be stored from at least two different sources.

> Also, when ignoring entries, one must at least make sure the ignored entry does not match an existing entry and set the lifetime to zero, right? Otherwise, you may be ignoring a request to delete a…

To clarify this question, the following text is suggested:

   When the IPv6 host has gathered a sufficient number (e.g., three) of
   RDNSS addresses (or DNS search domain names), it SHOULD maintain
   RDNSS addresses (or DNS search domain names) by the sufficient number
   such that the latest received RDNSS or DNSSL is more preferred to the
   old ones; that is, when the number of RDNSS addresses (or DNS search
   domain names) is already the sufficient number, the new one replaces
   the old one that will expire first in terms of Lifetime.  As an
   exceptional case, if the received RDNSS addresses (or DNS search
   domain names) already exist in the IPv6 host, their Lifetime fields
   update their expiration time, that is, when the corresponding DNS
   information expires in the IPv6 host; note that when the Lifetime
   field has zero, the corresponding RDNSS (or DNS search domain name)
   is deleted from the IPv6 host.  Except for this update, the IPv6 host
   SHOULD ignore other RDNSS addresses (or DNS search domain names)
   within an RDNSS (or a DNSSL) option and/or additional RDNSS (or
   DNSSL) options within an RA.  Refer to Section 6 for the detailed
   procedure.  Note that the sufficient number is a system parameter, so
   it can be determined by a local policy.  Also, separate parameters
   can be specified for the sufficient number of RDNSS addresses and
   that of DNS search domain names, respectively.  In this document,
   three is RECOMMENDED as a sufficient number considering both the
   robust DNS query and the reasonably time-bounded recognition of the
   unreachability of DNS servers.

>>   Checking nits according to http://www.ietf.org/id-info/checklist :

The current 04-version has no such issues.

>> Once I get your confirmation, I will submit this revised I-D to IETF.

Could you confirm whether this update is fine with you?

Thanks.

Best Regards,
Paul

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jun 2010 15:51:21 -0500

Hi, Jari,

See comments inline:

On Jun 26, 2010, at 4:11 AM, Jari Arkko wrote:

>> -- 5.3.1, last paragraph: "In the case where the DNS options of RDNSS and DNSSL can be obtained
> Let me speak with my "I deployed both mechanisms in my network" hat on :-) Sometimes you have to enable all possible mechanisms on the network side to make sure that your Windows/Apple/Linux/BSD computers and various appliances have a maximum chance of operating correctly.
> 
> But lets talk about the issue of underspecification. I think some of that is intentional, because I don't think we should specify a hard limit on the number of servers specified or the number of sources the information can come from.
> 
> However, I think I agree with you that it would be good to provide some predictability and make the language also tighter in other ways. And I don't think we can rule the DHCP side of this out of scope, because the DHCP RFC did not specify the interaction. How about this:
> 
> can be stored from at least two different sources. The DNS options from Router

That last SHOULD helps a lot, as it does seem to give more predicability.

But I'm still having trouble with how this fits together. We are talking about the configuration for a particular interface on the host, right? I admit to not being an expert in DHCPv6, but: If the host wants (or is told) to use DHCP to get the DNS configuration, it made an explicit decision to send a DHCP request, right? That is, it's not getting this sort of thing from the DHCP server unsolicited? If it requests the info from DHCP, and gets it, why would it even pay attention to the DNS info from an RA?

The part I still find under specificed is whether or not there are further management considerations for mixing and matching between DHCP and RAs.  For example, is there a need to coordinate what is sent in DHCP and in RAs so that they don't conflict. As an extreme example, is there any expectation that a DNS server assigned via DCHP and another assigned in an RA would return the same response for a given DNS query? 

I will yield to your expertise if this is just a matter of me not understanding how DHCPv6 works. Or if such questions are simply out of scope, it might make sense to mention that. Same if they are discussed in some other draft or RFC.

Thanks!

Ben.

> Jari
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Ben Campbell <[email-masked]>
Date: Mon, 28 Jun 2010 17:10:48 -0500

Hi,

Looking at the update:

Section 5.3.1, last two paragraphs:

I think the text is saying the right thing, but it seems a bit rushed could use another round of word-smithing.

In the last paragraph, when you say, "However, it is RECOMMENDED that at least three sets of addresses and
   domain names can be stored from at least two different sources.", do you mean 3 sets from each of 2 sources(i.e. 6 sets), or 3 sets total across two sources?

Also, see my response to Jari concerning the last paragraph.

Otherwise, I think this version has addressed the rest of my comments.

Thanks!

Ben.

---

From: Jaehoon Paul Jeong <[email-masked]>
Date: Mon, 28 Jun 2010 18:57:05 -0500

Ben,
The last paragraph can be written to clarify your question:

   However, it is RECOMMENDED that at least three RDNSS addresses (or
   DNSSL domain names) can be stored from at least two different
   sources.

That is, the total number is three for RDNSS addresses (or DNSSL domain names).

I believe that I can submit the 04 version.

Thanks.

Best Regards,
Paul