Subject: Issue 20: Node Requirements - DHC vs. RA text

From: Thomas Narten <[email-masked]>
Date: Thu, 22 Jul 2010 14:05:04 -0400

The revised version of draft-ietf-6man-node-req-bis-05.txt contains
some new text related to DHC and the RA DNS config option.

In writing the text, I tried to provide more background and guidance
regarding DHC vs. RAs. Like it or not, we have the problem today that
we are a bit unclear in what our recomendations are to
implementors. This has been made worse with 5006bis, as we will now
have 2 ways of configuring the DNS.

The reality is that both DHCP and SLAAC will be used for address
configuration. That said, the choice of which to use is made by the
network operator, not the end users. Right now, SLAAC seems to be the
default preference for the majority of LANs. But there are also
deployment scenarios where DHC is prefered. (Please, can we not debate
whether this makes sense and just accept it as fact? - Thanks!)

To summarize, the current document
 - retains  SLAAC as a MUST
 - lists DHC (for address config) as a MAY
 - makes DHC for other configuration a SHOULD.
 - lists rfc5006bis (DNS RA Config) as a SHOULD

Thoughts?

I've included some of the relevant new text below

Thomas

Current text in document:

6.  DHCP vs. Router Advertisement Options for Host Configuration

   In IPv6, there are two main protocol mechanisms for propagating
   configuration information to hosts: Router Advertisements and DHCP.
   Historically, RA options have been restricted to those deemed
   essential for basic network functioning and for which all nodes are
   configured with exactly the same information.  Examples include the
   Prefix Information Options, the MTU option, etc.  On the other hand,
   DHCP has generally been preferred for configuration of more general
   parameters and for parameters that may be client-specific.  That
   said, identifying the exact line on when whether a particular option
   should be configured via DHCP vs an RA option has not always been
   easy.  Generally speaking, however, there has been a desire to define
   only one mechanism for configuring a given option, rather than
   defining multiple (different) ways of configurating the same
   information.

   One issue with having multiple ways of configuring the same
   information is that if a host choses one mechanism, but the network
   operator chooses a different mechanism, interoperability suffers.
   For "closed" environments, where the network operator has significant
   influence over what devices connect to the network and thus what
   configuration mechanisms they support, the operator may be able to
   ensure that a particular mechanism is supported by all connected
   hosts.  In more open environments, however, where arbitrary devices
   may connect (e.g., a WIFI hotspot), problems can arise.  To maximize
   interoperability in such environments hosts may need to implement
   multiple configuration mechanisms to ensure interoperability.

   Originally in IPv6, configuring information about DNS servers was
   performed exclusively via DHCP.  In 2007, an RA option was defined,
   but was published as Experimental [RFC5006].  In 2010, "IPv6 Router
   Advertisement Options for DNS Configuration" was placed on the
   Standards Track.  Consequently, DNS configuration information can now
   be learned either through DHCP or through RAs.  Hosts will need to
   decide which mechanism (or whether both) should be implemented.

7.  DNS and DHCP

...

7.2.  Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315

7.2.1.  Managed Address Configuration

   DHCP can be used to obtain and configure addresses.  In general, a
   network may provide for the configuration of addresses through RAs,
   DHCP or both.  At the present time, the configuration of stateless
   address autoconfiguraiton is more widely implemented in hosts than
   address configuration through DHCP.  However, some environments may
   require the use of DHCP and may not support the configuration of
   addresses via RAs.  Implementations should be aware of what operating
   environment their devices will be deployed.  Hosts MAY implement
   address configuration via DHCP.

   In the absence of a router, IPv6 nodes using DHCP for address
   assignment MAY initiate DHCP to obtain IPv6 addresses and other
   configuration information, as described in Section 5.5.2 of
   [RFC4862].

7.2.2.  Other Configuration Information

   IPv6 nodes use DHCP to obtain additional (non-address) configuration.
   If a host implementation will support applications or other protocols
   that require configuration that is only available via DHCP, hosts
   SHOULD implement DHCP.  For specialized devices on which no such
   configuration need is present, DHCP is not necessary.

   An IPv6 node can use the subset of DHCP (described in [RFC3736]) to
   obtain other configuration information.

7.2.3.  Use of Router Advertisements in Managed Environments

   Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
   are expected to determine their default router information and on-
   link prefix information from received Router Advertisements.

7.3.  IPv6 Router Advertisement Options for DNS Configuration - RFC XXXX

   Router Advertisements have historically limited options to those that
   are critical to basic IPv6 functioning.  Originally, DNS
   configuration was not included as an RA option and DHCP was the
   recommended way to obtain DNS configuration information.  Over time,
   the thinking surrounding such an option has evolved.  It is now
   generally recognized that few nodes can function adequately without
   having access to a working DNS resolver.  RFC 5006 was published as
   an experimental document in 2007, and recently, a revised version was
   placed on the Standards Track [I-D.I-D.ietf-6man-dns-options-bis].

   Implementations SHOULD implement the DNS RA option.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Jul 2010 09:27:16 +1200

>  - lists rfc5006bis (DNS RA Config) as a SHOULD

That seems compatible with reality, although I'd expect most
software writers to treat DHC as a "MUST implement" in practice.

    Brian

---

From: <[email-masked]>
Date: Fri, 23 Jul 2010 05:46:33 +0200

I think for general purpose nodes, ones that can expect to be deployed in a number of
different scenarios (or are mobile / nomadic), I would agree with Brian.  When a node
attaches to a network, it will not know before hand what kind of configuration is 
supported by the network.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Brian E Carpenter
> Sent: Thursday, July 22, 2010 2:27 PM
> To: Thomas Narten
> Cc: [email-masked]
> Subject: Re: Issue 20: Node Requirements - DHC vs. RA text
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Fri, 23 Jul 2010 09:20:54 -0400

>  - lists rfc5006bis (DNS RA Config) as a SHOULD

I would prefer if nodes were required (MUST) to support one or the other
mechanism for DNS config. Given SLAAC is a must, it would probably make
the most sense to make rfc5006 the must.

My goal is predictability. From a service provider help desk
perspective, if I'm trying to troubleshoot a customer who can't get
their Internet connection working, and I discover that they can ping an
IPv4 address (and somehow also test they can ping an IPv6 address), but
not a FQDN, then my next steps are much easier if I can predict how DNS
is acquired. This is not an uncommon scenario in IPv4. Having to figure
out if the device supports DNS by RA or DHCPv6, and has one or the other
or both enabled, adds unnecessary steps and complexity to
troubleshooting. 

The routers the service provider ships would also have to be default
configured to provide the identical DNS info through both mechanisms.

All of this extra effort could be avoided (and better user experience
provided) if one of the mechanisms were required.
Barbara

---

From: Mark Smith <[email-masked]>
Date: Sat, 24 Jul 2010 13:34:52 +0930

On Fri, 23 Jul 2010 09:20:54 -0400

> or both enabled, adds unnecessary steps and complexity to

It probably doesn't add much to this discussion, however there is a
third option for DNS - manual configuration.

In my experience, it seems in IPv4 for a common troubleshooting step
for the helpdesk to manually configure DNS IP addresses. The existing
settings are not even queried i.e. "robotically" the DNS settings are
changed from being automatically configured to manual. That may have
either been because it was specified in a troubleshooting procedure, or
through rumour - it may have worked successfully often enough that
it gets spread throughout the helpdesk as a step that has a higher
chance of succeeding. As helpdesks tend to be driven more by phone
calls answered, and numbers of customers back online, the quality of
true cause identification and troubleshooting suffers.

A few years back, when wanting to change the DNS IP addresses for a
50K+ ADSL subscriber base, I thought we'd need to preserve the old IP
addresses for in the order of at least 5 years because of this manual
setting of DNS addresses. It's a shame because we wanted to free up
that /24 (an old Class C) for use somewhere else, and the two legacy DNS
IP addresses were the only ones that continued to be in use.

With two dynamic methods of acquiring DNS under IPv6, and the
possibility that they could present different DNS addresses, that may
create even more of an incentive for helpdesks to override the automatic
DNS settings with manual ones. Validating the automated DNS addresses
is probably more work and therefore time on the phone with the customer.
With luck, the length and obscurity of an IPv6 address might contribute
to preventing that, but I wouldn't bet on it.

> provided) if one of the mechanisms were required.

I agree with Barbara. Twice as many automated mechanisms creates the
opportunity for twice as many errors.

Regards,
Mark.

---

From: Antonio Querubin <[email-masked]>
Date: Sat, 24 Jul 2010 17:36:04 -1000 (HST)

> the most sense to make rfc5006 the must.

++

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  [email-masked]

---

From: Brian Haberman <[email-masked]>
Date: Sun, 25 Jul 2010 03:34:13 -0400

>> the most sense to make rfc5006 the must.

Just for clarity... Do you mean RFC 5006 or its standards-track
successor draft-ietf-6man-dns-options-bis?

Regards,
Brian

---

From: Antonio Querubin <[email-masked]>
Date: Mon, 26 Jul 2010 02:23:15 -1000 (HST)

> successor draft-ietf-6man-dns-options-bis?

The discussion started with bis but it looks like that got dropped 
somewhere along the way.  I think it would be problematic to require a 
feature that is considered experimental rather than standards track.

Antonio Querubin
808-545-5282 x3003

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Mon, 26 Jul 2010 08:54:31 -0400

I think I mean the RDNSS option of RFC5006's standards-track successor. 
I believe the RDNSS option of draft-ietf-6man-dns-options-bis is
formatted the same as the RDNSS option of RFC5006, but
draft-ietf-6man-dns-options-bis has improved guidance for host handling
of the option, especially in the presence of DHCPv6 DNS and other
options.
Barbara

> Brian Haberman
> Sent: Sunday, July 25, 2010 3:34 AM
> To: [email-masked]