Subject: Sense of the WG on DNS discovery

From: Rob Austein <[email-masked]>
Date: Thu, 06 Nov 2003 12:51:34 -0500

Your friendly neighborhood WG chairs have been watching the ongoing
discussion and trying to see whether we determine the will of the
working group in this matter.  Here's what we think we've seen in the
time since this topic first landed on the WG's plate:

- The WG thinks that picking a DNS discovery solution and moving on is
  probably more important than the specifics of the solution, so long
  as there are no show-stopper problems with the solution picked.

- DHCPv6-Lite appears to have more support than the other alternatives.

- DHCPv6-Lite does not appear to have any show-stopper problems.

- Therefore, while some clearly would prefer other solutions, the WG
  thinks it's time to declare DHCPv6-lite to be good enough for the
  decision we need to make now, pick it, and move on.

- We may revisit this decision a few years down the road if new data
  from deployment experience suggests that we made the wrong choice.

The question to the WG here is not "Do you agree that DHCPv6-Lite is
the best choice?" (we know that some would disagree with that), but
rather "Do you agree that this is the sense of the WG?"

We're posting this now so that folks have time to think about this
before next week's face-to-face meeting.

--Rob and Dave
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 07 Nov 2003 04:03:43 +0900

>>>>> On Thu, 06 Nov 2003 12:51:34 -0500, 
>>>>> Rob Austein <[email-masked]> said:

> rather "Do you agree that this is the sense of the WG?"

A quick check: what exactly do you mean by "DHCPv6-Lite"?

1. a "stateless" subset of the current DHCPv6, as specified in
   draft-ietf-dhc-dhcpv6-stateless-01.txt
2. an extension to the current DHCPv6 that has the ability to
   multicast the stateless information (that I guess Alain first
   proposed)
3. others

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Rob Austein <[email-masked]>
Date: Thu, 06 Nov 2003 14:19:01 -0500

>    multicast the stateless information (that I guess Alain first

I meant (1).

(2) is an interesting idea that might well be worth discussing with
the DHC WG, but my sense is that we can defer that discussion.  YMMV.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 07 Nov 2003 05:38:55 +0900

>>>>> On Thu, 06 Nov 2003 14:19:01 -0500, 

> I meant (1).

Okay thanks, that's what I initially expected.

					JINMEI, Tatuya

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 07 Nov 2003 06:46:19 +0900

Rob Austein;

> working group in this matter.

Watching? I think you have been actively acting for DHCPv6-Lite.

						Masataka Ohta

PS

Can you agree that your attack on well known address approach
on failure mode is unfounded and applicable to all the
approaches?

As I saw no response from you to my counter arguement, I thought
you are convinced that well know address approach is good enough.

---

From: Rob Austein <[email-masked]>
Date: Thu, 06 Nov 2003 17:22:33 -0500

> Watching? I think you have been actively acting for DHCPv6-Lite.

Nolo contendre, but the two are not mutually exclusive, since the
question was about what the WG believes, not about what I believe.

> on failure mode is unfounded and applicable to all the

I still think there's a difference in the default query propegation
behavior for a badly configured network, if that's what you're asking.
Whether that's relevant to anything the WG cares about is for the WG
to decide.

> you are convinced that well know address approach is good enough.

I had nothing new to say on the subject.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: David Meyer <[email-masked]>
Date: Thu, 6 Nov 2003 15:09:57 -0800

>> Watching? I think you have been actively acting for DHCPv6-Lite.

	I would phrase it somewhat differently.  And what I can
	say on this topic is that in Vienna, I asked the
	DHCPv6-lite question in a several different forms,
	including:  

	(i).	In what way is DHCPv6-lite insufficient?

	(ii).	Why not DHCPv6-lite?

	Neither was ever really answered, either during our
	meeting or subsequently. One can also do a functional and
	deployment analysis and arrive at the same (unanswered)
	question(s). 

	Dave

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 07 Nov 2003 09:32:37 +0900

David Meyer;

> 	DHCPv6-lite question in a several different forms,

As a co-chair of our friendly neighborhood WG, you MUST be
aware that the ML is the WG.

> 	(i).	In what way is DHCPv6-lite insufficient?

Too complex and heavy weighted than a simple alternative, which
was abandoned with wrong reasons long before and resurrected
after the meeting.

> 	(ii).	Why not DHCPv6-lite?

See above.

> 	meeting or subsequently.

I haven't asked the question.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 07 Nov 2003 09:35:52 +0900

Rob Austein;

> question was about what the WG believes, not about what I believe.

Which WG are you talking about?

> behavior for a badly configured network, if that's what you're asking.

Queries propagate to the configured IP addresses, regardless of how
the addresses are configured.

						Masataka Ohta

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Fri, 07 Nov 2003 11:29:45 +0900 (JST)

>	(i).	In what way is DHCPv6-lite insufficient?

DHCPv6-lite has no way to inform a DNS recursing server renumbering.
A DHCPv6-lite server could send Reconfigure messages for its clients,
if the server hold a client list, but it's not -lite.

DHCPv6-lite with a multicast extension might help this.

--
SHIRASAKI Yasuhiro @ NTT Communications
t: +81-3-6800-3262, f: +81-3-5365-2990
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 06 Nov 2003 22:18:37 -0500

Fair enough, but asynchronous notification of configuration changes hasn't
been a requirement in IPv4 (well, there is the FORCERENEW message in RFC
3203; as far as I know there are no implementations of RFC 3203).  Why would
it be needed for IPv6?

- Ralph

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Fri, 07 Nov 2003 13:33:51 +0900 (JST)

DHCPv6-full (for host) and DHCPv6-PD (for CPE) has timers such as T1,
T2, and lifetimes, so clients poll their servers periodically and
could realize a DNS recursive name server renumbering as a "side effect".

Because DHCPv6-lite and DNS Recursive Name Server option has no timer,
once a client configured its address with RA and knew a DNS recursive
name server address with DHCPv6-lite, a chance for the client to
realize a renumbering might be its reboot.

On Thu, 06 Nov 2003 22:18:37 -0500,

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 06 Nov 2003 23:16:15 -0600

> - DHCPv6-Lite does not appear to have any show-stopper problems.

Is there an I-D describing DNS discovery over DHCPv6-lite yet?

The last major discussion on this subject was in July. There was a lot of
hand-waving about how easy it would be to use this technology for this
service ("just do x, and y, and zz,"), but no effort has yet been made to
my knowledge at actually deonstrating this simplicity with an I-D that
actually describes the basic mechanics of the approach. I mean, there at
least needs to be a discussion on client-side sorting and/or weighting
algorithms for those cases when multiple answers are received, just so
folks can see that this approach might actually work, or to get an idea at
how difficult it will be. How can there be consensus on a proposal when
said proposal does not exist?

> rather "Do you agree that this is the sense of the WG?"

There does not appear to be any such consensus.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 07 Nov 2003 15:20:21 +0900

SHIRASAKI san;

> DHCPv6-lite has no way to inform a DNS recursing server renumbering.

That is a good reason to use well known addresses not affected by
renumbering.

						Masataka Ohta

---

From: Tim Chown <[email-masked]>
Date: Fri, 7 Nov 2003 09:03:45 +0000

> 3203; as far as I know there are no implementations of RFC 3203).  Why would

I thought one goal of IPv6 was that renumbering would become a simpler process
than it is in IPv4.   We have tools like Neighbour Discovery and Address
Autoconifguration for (multi)addressed hosts, and Router Renumbering.  Having 
to reboot to renumber is not ideal in many situations. 

This would apply to other DHCPv6 served addresses like NTP server.  It seems
like an argument for considering the multicast option for stateless DHCPv6
as suggested by Alain.

Tim

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Fri, 07 Nov 2003 18:05:41 +0900 (JST)

> That is a good reason to use well known addresses not affected by

So we've used 'Well known "site-local" unicast addresses' in our ADSL
service since the summer of 2002, but traditional site-local unicast
address is expected to be deprecated soon...

---

From: Rob Austein <[email-masked]>
Date: Fri, 07 Nov 2003 04:17:33 -0500

> Is there an I-D describing DNS discovery over DHCPv6-lite yet?

Whoops, the DNS discovery part of the reading list got left out of the
draft agenda we sent earlier this week.  Draft authors please correct
me if these aren't the current I-Ds:

- draft-ietf-dhc-dhcpv6-stateless-01.txt
- draft-jeong-dnsop-ipv6-dns-discovery-00.txt
- draft-ohta-preconfigured-dns-00.txt
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 07 Nov 2003 19:08:54 +0900

SHIRASAKI san;

> address is expected to be deprecated soon...

Of course, site-local addresses (either uni- or multi- cast) are
almost as bad as "stateelss" that they should be, if not yet,
deprecated.

So?

Have you read the draft?

						Masataka Ohta

---

From: Ralph Droms <[email-masked]>
Date: Fri, 07 Nov 2003 05:43:17 -0500

The dhc WG discussed this issue briefly during the WG last call on
draft-ietf-dhc-dhcpv6-stateless-*.txt (see the thread starting at
http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02005.html).
If polling by clients using DHCPv6-lite is a desirable feature, it could
be added to draft-ietf-dhc-dhcpv6-stateless-01.txt.

We could probably argue a little about whether the Reconfigure message is
part of DHCPv6-lite.  On the one hand, using Reconfigure would require that
the DHCPv6 server retain some dynamic state about clients: a list of active
clients to which the Reconfigure message must be sent.  Perhaps that
requirement could be addressed through the use of a multicast Reconfigure
message.

If security is desired for the Reconfigure message, the server would also
have to retain the "Reconfigure Key" for each active client (see section
21.5 of RFC 3315).  Note that section 21.5 only prevents an attack through
spoofed Reconfigure messages, not an initial attack by a spoofing DHCPv6
server.  I don't think security has been a requirement for DNS configuration
up to this point.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 07 Nov 2003 06:01:34 -0500

Eric,

As Rob pointed out, stateless DHCPv6 is described in
draft-ietf-dhc-dhcpv6-stateless-01.txt, which is in IETF last call.  There
has been one comment on the draft during the IETF last call,
http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02630.html.

The DNS configuration options are described in
draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt, which has been approved as PS.

Several implementations of RFC3315, draft-ietf-dhc-dhcpv6-stateless-01.txt
and draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt exist and have been tested
for interoperability earlier this year at TAHI, Connectathon and a DHCPv6
interoperability event hosted by NEC in Vienna.  Note that
draft-ietf-dhc-dhcpv6-stateless-01.txt describes a subset of RFC 3315, so a
server implementation of RFC 3315 would be interoperable with stateless
DHCPv6 client.  I contributed to the Cisco implementation of both a
stateless DHCPv6 client and server and use that experience as the basis for
my comments on the complexity of the implementation of stateless DHCPv6.

We discussed the issue of receiving multiple responses to the DNS
configuration information option in an ipv6 WG meeting.  Turns out, in
theory, the order of appearance of DNS recursive name servers in the list
doesn't matter because every server should return the same response to a
given query.  More generally, receiving multiple different responses from
DHCP servers (either IPv4 or IPv6) represents a misconfiguration and is an
operational problem - which could occur with other DNS configuration
mechanisms as well.

- Ralph

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 07 Nov 2003 20:52:31 +0900

Ralph;

> be added to draft-ietf-dhc-dhcpv6-stateless-01.txt.

Don't do that.

> requirement could be addressed through the use of a multicast Reconfigure

You are caught in the pitfall of "stateless autoconfiguration" only
to damege the protocol.

> server.  I don't think security has been a requirement for DNS 

There was someone requesting autoconfiguration of not only a DNS but
also an NTP server to be used to confirm timestamps of secure DNS,
even though the autoconfigured NTP server is no secure. :-|

							Masataka Ohta

---

From: Pekka Savola <[email-masked]>
Date: Fri, 7 Nov 2003 15:40:01 +0200 (EET)

> 3203; as far as I know there are no implementations of RFC 3203).  Why would

IMHO, this certainly shouldn't be in the stateless DHCP spec at least.   
The point is to run a user-level process to configure settings, and exist.  
The latter would require some form of a daemon, and add complexity.

If we want to make renumbering easier (I suggest we do!), my 
recommendation would be stating that implementations should consider 
running stateless DHCP service every N <time-units>, e.g. once a week, 
day, hour, whatever is required.  Nothing prevents that.  There is little 
need for "network-forced renumber that I could see.  Going even a bit 
further, one could add the code in an implementation so that when new 
prefixes are seen in RA's, one would re-run DHCP-lite (with some 
rate-limit) again, just to be sure..

Conclusion: with a stateless method, there is little need for 
network-forced reconfiguration.  With a stateful method, there may be a 
need for it, because you can't really run stateful DHCP many times in a 
row..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 07 Nov 2003 09:13:07 -0600

Ralph Droms wrote:

> theory, the order of appearance of DNS recursive name servers in the
> list doesn't matter because every server should return the same
> response to a given query.  More generally, receiving multiple
> different responses from DHCP servers (either IPv4 or IPv6) represents
> a misconfiguration and is an operational problem - which could occur
> with other DNS configuration mechanisms as well.

Doesn't that dis-prove the claim that "A minimal DHCPv6-lite server
co-located with a recursive name server [c]ould just respond with its own
address"? (see <[email-masked]> and its
thread-context neighbors)

So going this way means additional DNS-specific maintenance would be
mandatory after all.

---

From: Ralph Droms <[email-masked]>
Date: Sat, 08 Nov 2003 07:06:03 -0500

Eric - good point.  I was thinking of the usual deployment of DHCP servers
and meant "misconfiguration" to apply to DHCP servers intended to give
consistent replies.  Receiving different answers from different servers
doesn't violate any part of the DHCP spec itself.

Although the usual practice (in DHCPv4) is to accept the configuration
parameters from one server and ignore the others, I'll review the
words in RFC 3315 and the DNS config option doc to confirm that combining
information from multiple responses is within the spec.  We have an
opportunity to clarify the DNS config option spec if necessary, as it is
currently still in the RFC Editor's publication queue.

- Ralph

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Tue, 11 Nov 2003 06:56:05 +0900 (JST)

On Fri, 07 Nov 2003 19:08:54 +0900,
> almost as bad as "stateelss" that they should be, if not yet,

I've just missed your draft and thought you've been talking about
site-local anycast, but now I read your draft and thought it might work,
once IANA assgins addresses.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 11 Nov 2003 08:09:25 +0900

SHIRASAKI san;

> I've just missed your draft

Thanks.

> and thought you've been talking about

It should be noted that, technically, defact standard addresses
(extracted from an address space of a large PC vendor) are enough,
though it is politically easier to mention IANA. :-)

							Masataka Ohta