Subject: review of draft-ietf-6man-dns-options-bis

From: Jari Arkko <[email-masked]>
Date: Fri, 14 May 2010 11:38:28 +0300

Thanks for writing this draft. I've read it and had a few comments:

> The purpose of this document is to standardize IPv6 Router
> Advertisement (RA) option for DNS configuration in IPv6 hosts
> specified in [RFC5006] and also to define a new RA option for Domain
> Name Search lists.
>
Maybe: ... specified in an earlier experimental specification [RFC5006] 
and ...

> It is infeasible for nomadic hosts, such as laptops, to be configured
> manually with a DNS resolver each time they connect to a different
> wireless LAN (WLAN) such as IEEE 802.11 a/b/g [IEEE-802.11]
> [IEEE-802.11a][IEEE-802.11b][IEEE-802.11g].  This document defines a
> mechanism based on IPv6 RA options to allow IPv6 hosts to perform the
> automatic DNS configuration.  As an alternative to the DNS
> configuration provided by DHCP [RFC3315][RFC3736][RFC3646], the RA-
> based DNS configuration can allow network operators or users to
> select an appropriate automatic DNS configuration for IPv6 hosts,
> depending on the types of their networks [RFC4339].

This rationale has several issues. First, I'm not sure the listing of 
different radio types is really relevant here. Second, there are 
multiple ways of handling the manual DNS configuration, such as doing it 
once, not per network. Finally, I do not think the explanation of the 
differences of this vs. DHCP approach really capture the essential 
reasons why we believes good standardize this mechanism.

I would suggest the following paragraph instead.

"It is infeasible to manually configure nomadic hosts each time they 
connect to a different network. While a one-time static configuration is 
possible it is generally not desirable on general purpose hosts such as 
laptops. 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. The DNS information can also be 
provided through DHCP [RFC3315][RFC3736][RFC3646]. However, access to 
DNS is a fundamental requirement for almost all hosts, and stateless 
IPv6 autoconfiguration cannot stand on its own as an alternative 
deployment model in any practical network without support for DNS 
configuration. These issues are not pressing in dual stack networks as 
long as a DNS server is available on the IPv4 side, but become more 
critical with the deployment of IPv6-only networks. As a result, this 
document defines a mechanism based on IPv6 RA options to allow IPv6 
hosts to perform the automatic DNS configuration."

>    RA-based DNS configuration is a useful alternative in networks where
>    an IPv6 host's address is autoconfigured through IPv6 stateless
>    address autoconfiguration, where the delays in acquiring server
>    addresses and communicating with the servers are critical, or where
>    the network operator or host operator does not want the additional
>    operational complexity of running DHCPv6 to provide the same
>    information to all hosts on the network.

Overselling the point. And missing some. And I'm not convinced about any 
delay issues. I would just say this:

   RA-based DNS configuration is a useful alternative in networks where
   an IPv6 host's address is autoconfigured through IPv6 stateless
   address autoconfiguration, and where there is either no DHCPv6
   infrastructure at all or some hosts do not have a DHCPv6 client.
   The intention is to enable full configuration basic networking
   information for hosts without requiring DHCPv6. However,
   when in many networks some additional information needs to
   be distributed, and those networks are likely to employ DHCPv6.
   In these networks RA-based DNS configuration may not be needed.

>   This can be
>    beneficial in some mobile environments, such as with Mobile IPv6
>    [RFC3775].

Maybe. Mobile can also be like VPN in the sense that you want your home 
environment and home DNS visible. I would just strike this sentence, 
because full treatment of the topic will be more complicated than this 
simple claim.

> To order the RA and DHCP approaches, the O (Other stateful 
> configuration) flag can be used in the RA message [RFC4861].

To order? As in sequencing them, or as in requesting their use? But the 
RA options cannot be negotiated, you will always send them, and I 
presume, always accept information, no?

>  Based on the definition of the O flag above, if RA options for DNS
>    configuration are included in the RA messages, an IPv6 host may
>    perform another DNS configuration through DHCPv6 only when the O flag
>    is set.  On the other hand, if no RA options for DNS configuration
>    are included in the RA messages, an IPv6 host may perform DNS
>    configuration through DHCPv6 regardless of whether the O flag is set
>    or not.

And I do not understand the need to talk about the M and O options in 
Section 1.2 at all. I know I will not enjoy yet another instance of the 
M&O bit discussion on this document. But I fail to see what changes with 
respect to the M&O bits in this document. This is RFC 4861 domain, for 
better or worse. And I'm not sure RFC4339 really gives any useful rules, 
at least in the normative sense. I would just say:

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].  They can be used together. The rules 
governing the decision to use stateful configuration mechanisms are 
specified in RFC 4861. Hosts conforming to this specification MUST 
extract DNS information from Router Advertisement messages, unless 
static DNS configuration has been specified by the user. If there is DNS 
information available from multiple Router Advertisements and/or from 
DHCP, the host MUST maintain an ordered list of this information as 
specified in Section 5.3.1.

> This is for two reasons for the new option, the
>    first is to maintain parity with the DHCPv6 options for DNS
>    configuration [RFC3646], so that RA and DHCPv6 do not unnecessarily
>    diverge and so that RA can provide the same DNS configuration as
>    DHCPv6.  The second reason is that a Domain Search List is useful to
>    support multi-homed hosts querying DNS servers which provide
>    different answers [ID-savolainen].

There are functional differences to providing the domain as well, e.g., 
resolving local names. I would just say:

"This is to maintain parity with the DHCPv6 options and to ensure that 
there is necessary functionality to determine the search domains."

>    Existing ND transport mechanisms (i.e., advertisements and
>    solicitations) are used.  This works in the same way that hosts learn
>    about routers and prefixes.  An IPv6 host can configure the IPv6
>    addresses of one or more RDNSSes via RA messages periodically sent by
>    a router or solicited by a Router Solicitation (RS).

But this draft -- I hope -- does not change the overall messaging, e.g., 
you would not send extra solicitations. I would just say:

"Existing ND message, Router Advertisement is used to carry this 
information. An IPv6 host can configure the IPv6 addresses of one or 
more RDNSSes via RA messages."

>    When the IPv6 host has gathered a sufficient number of RDNSS
>    addresses (or DNS search domain names), 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.

I would specify a minimum required number of supported addresses.

>    o  RDNSS address for DNS Server List: IPv6 address of the Recursive
>       DNS Server, which is available for recursive DNS resolution
>       service in the network advertising the RDNSS option; such a
>       network is called "site" in this document.
>
>    o  DNSSL domain name for DNS Search List: DNS suffix domain names,
>       which is used to perform DNS query searches for short, unqualified
>       domain names in the network advertising the DNSSL option; such a
>       network is called "site" in this document.

Text duplication, and I don't think you actually use the term site in 
this sense elsewhere in the document.
>
>    Note:  An RDNSS address or a DNSSL domain name MUST be used only as
>       long as both the RA router lifetime and the option lifetime have
>       not expired.  The reason is that the RDNSS may not be currently
>       reachable, that the DNSSL domain name is not valid any more, or
>       that these options do not provide service to the host's current
>       address (e.g., due to network ingress filtering
>       [RFC2827][RFC5358]).

... and as long as you are still attached to this network.

Missing things:

I think the Section 5.3.1 rules on maintaining the list need to be more 
explicit about getting information from multiple sources. E.g., if you 
get plenty from one RA maybe you should keep some from that and some 
from DHCP, as opposed to throwing away everything from DHCP...

I wonder if some of the steps from Section 6 of this draft should be in 
earlier sections as normative behaviour requirements.

Jari

P.S. What would it take to make rdnssd a part of the default Linux 
distribution? Its currently a separate piece that must be installed...

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 May 2010 13:28:31 -0700

-----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Friday, May 14, 2010 1:38 AM
> To: [email-masked]; IETF IPv6 
> Mailing List
> Subject: review of draft-ietf-6man-dns-options-bis
> 

All very good suggestions which improve the document.

-d

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Jaehoon Paul Jeong <[email-masked]>
Date: Fri, 14 May 2010 16:26:15 -0500

Hi Jari,
I will reflect your good comments on the next revision.

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/

On Fri, May 14, 2010 at 3:38 AM, Jari Arkko <[email-masked]> wrote:
> Maybe: ... specified in an earlier experimental specification [RFC5006] and ...
>
> This rationale has several issues. First, I'm not sure the listing of different radio types is really relevant here. Second, there are multiple ways of handling the manual DNS configuration, such as doing it once, not per network. Finally, I do not think the explanation of the differences of this vs. DHCP approach really capture the essential reasons why we believes good standardize this mechanism.
>
> "It is infeasible to manually configure nomadic hosts each time they connect to a different network. While a one-time static configuration is possible it is generally not desirable on general purpose hosts such as laptops. 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. The DNS information can also be provided through DHCP [RFC3315][RFC3736][RFC3646]. However, access to DNS is a fundamental requirement for almost all hosts, and stateless IPv6 autoconfiguration cannot stand on its own as an alternative deployment model in any practical network without support for DNS configuration. These issues are not pressing in dual stack networks as long as a DNS server is available on the IPv4 side, but become more critical with the deployment of IPv6-only networks. As a result, this document defines a mechanism based on IPv6 RA options to allow IPv6 hosts to perform the automatic DNS configuration."
>
> Overselling the point. And missing some. And I'm not convinced about any delay issues. I would just say this:
>
> Maybe. Mobile can also be like VPN in the sense that you want your home environment and home DNS visible. I would just strike this sentence, because full treatment of the topic will be more complicated than this simple claim.
>
>> To order the RA and DHCP approaches, the O (Other stateful configuration) flag can be used in the RA message [RFC4861].
>
> To order? As in sequencing them, or as in requesting their use? But the RA options cannot be negotiated, you will always send them, and I presume, always accept information, no?
>
> And I do not understand the need to talk about the M and O options in Section 1.2 at all. I know I will not enjoy yet another instance of the M&O bit discussion on this document. But I fail to see what changes with respect to the M&O bits in this document. This is RFC 4861 domain, for better or worse. And I'm not sure RFC4339 really gives any useful rules, at least in the normative sense. I would just say:
>
> 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].  They can be used together. The rules governing the decision to use stateful configuration mechanisms are specified in RFC 4861. Hosts conforming to this specification MUST extract DNS information from Router Advertisement messages, unless static DNS configuration has been specified by the user. If there is DNS information available from multiple Router Advertisements and/or from DHCP, the host MUST maintain an ordered list of this information as specified in Section 5.3.1.
>
> There are functional differences to providing the domain as well, e.g., resolving local names. I would just say:
>
> "This is to maintain parity with the DHCPv6 options and to ensure that there is necessary functionality to determine the search domains."
>
> But this draft -- I hope -- does not change the overall messaging, e.g., you would not send extra solicitations. I would just say:
>
> "Existing ND message, Router Advertisement is used to carry this information. An IPv6 host can configure the IPv6 addresses of one or more RDNSSes via RA messages."
>
> Text duplication, and I don't think you actually use the term site in this sense elsewhere in the document.
>>
> I think the Section 5.3.1 rules on maintaining the list need to be more explicit about getting information from multiple sources. E.g., if you get plenty from one RA maybe you should keep some from that and some from DHCP, as opposed to throwing away everything from DHCP...
>
> I wonder if some of the steps from Section 6 of this draft should be in earlier sections as normative behaviour requirements.
>
> Jari
>
> P.S. What would it take to make rdnssd a part of the default Linux distribution? Its currently a separate piece that must be installed...
>

---

From: Mark Smith <[email-masked]>
Date: Sun, 16 May 2010 11:07:25 +0930

On Fri, 14 May 2010 11:38:28 +0300
Jari Arkko <[email-masked]> wrote:

<snip>

> distribution? Its currently a separate piece that must be installed...

As it should be. The way people sell this RDNSS option is low
end/embedded hosts that are so low powered they aren't capable of
running stateless DHCPv6. Any host capable of running Linux should
easily be able to do that. I think any other argument for it creates
the situation where the whole design of IPv6 automated parameter
configuration is open for questioning. Any time there are two nearly
equivalent methods of solving a problem then you're into second system
syndrome territory.

If these people can implement RPL - IPv6 Routing Protocol for Low power
and Lossy Networks in "5 kb of ROM and 0.5 kb of RAM."[1] or
IPv6/6lowpan/802.15.4 in "35KB of ROM and around 3K of RAM' [2], then
the thresholds where stateless DHCPv6 cannot be implemented has to be
extremely low.

[1]
http://www.sics.se/contiki/tutorials/contikirpl-the-new-default-contiki-ipv6/6lowpan-routing-protocol.html

[2]
http://www.sics.se/contiki/contiki-6lowpan-uipv6-faq.html

---

From: Tore Anderson <[email-masked]>
Date: Sun, 16 May 2010 12:39:02 +0200

* Jari Arkko

> distribution? Its currently a separate piece that must be installed...

NetworkManager has over the last few weeks received decent IPv6 support,
including support for RDNSS.  NM is installed by default in most
distributions, so I think rdnssd will become more or less obsolete.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: Jari Arkko <[email-masked]>
Date: Sun, 16 May 2010 18:57:09 +0300

Ah, good. Thanks for the update.

Jari

Tore Anderson kirjoitti:

* Jari Arkko

Best regards,