Subject: DNSEXT WGLC: IPv6 Name Auto Registration

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Tue, 04 Feb 2003 14:51:01 -0500

This starts a 2 week Working Group last call on this document, concluding on
February 19'th.

This document defines a mechanism to register IPv6 auto configuration in DNS.
This document does not change the DNS protocol in any way or add new
requirements for DNS servers or resolvers.

This document is on experimental track and is available via following URL:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt

Silence on this document during the last call will be taken as instruction to
chairs to drop this document from consideration.

	Olafur

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Johan Ihren <[email-masked]>
Date: 05 Feb 2003 11:43:03 +0100

Francis Dupont <[email-masked]> writes:

>  In your previous mail you wrote:
> 
> => I support this document.

I don't. 

I think this is a really bad idea that would be much better solved by
a combination of DHCPv6 and dynamic updates. Either the v6 devices
need cuddly infrastructure to be happy (that's called DHCP) or they
don't (that's called ad-hoc networking). As far as I understand
arguments have been in favour of supporting the latter and then it
seems a rather bad idea to start reinventing the support services of
the infrastructure that was rejected in the first place.

Furthermore, since:

> This document defines a mechanism to register IPv6 auto
> configuration in DNS.  This document does not change the DNS
> protocol in any way or add new requirements for DNS servers or
> resolvers.

I don't really see what it is doing in DNSEXT. 

But, of course, it is likely that I have not really understood this
and that I'm just acting in the tradition of being mistaken ;-)

Johan Ihrén
Autonomica

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Feb 2003 13:29:35 +0100

I don't. 
   
   I think this is a really bad idea that would be much better solved by
   a combination of DHCPv6 and dynamic updates.

=> near 100% of current IPv6 networks don't use DHCPv6 for
address allocation, and most won't. Dynamic updates alone
are not easy to use, IMHO the basic idea of the IPv6 NAR draft
is a good one. But the question here is not if we believe it
is or not a good idea, it is if there is or is not enough interest...

   Either the v6 devices need cuddly infrastructure to be happy (that's
   called DHCP)

=> unfortunateley DHCP is not that. DHCPv6 is an IPv6 version of
DHCP with addresses considered as a very rare resource... even
if there are near 2^64 available addresses per link.

   or they don't (that's called ad-hoc networking).

=> no, this is "plug and play".

   
   
=> DNSEXT was proposed by the chairs of the WGs. This draft needs
a WG and DNSEXT is not so bad.

Regards

[email-masked]

---

From: Jim Reid <[email-masked]>
Date: Wed, 05 Feb 2003 11:49:59 -0800

I agree wholeheartedly with Johan. If IPv6 devices need configuration
data to locate things like DNS and NTP servers, they should use DHCP
and not re-invent the wheel. If DHCPv6 does not meet those needs, it
should be fixed. I suspect that even "plug and play" networks will
require DHCP too. There doesn't seem to be much point having a network
that's totally isolated from the internet. [The chances are than even
in those unconnected networks -- say my mother's house -- there will
be some smart device like a video recorder that would have a simple
DHCP server embedded in it. My $400 AirPort base station has a DHCP
server and it's been simple to set up and even simpler to look after.]
And anyway a DHCP based solution is likely to be much cleaner than an
ever-increasing bunch of discovery protocols to find out how many
lightbulbs or whatever are on some local IPv6 subnet.

This draft should die in dnsext and go to dhc.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Feb 2003 15:48:12 -0600

> There's
> nothing wrong with the Experimental status; it should not be
> considered a dead end into which rejected ideas are shunted.

Hear, hear!

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Feb 2003 14:31:41 +0100

I agree wholeheartedly with Johan. If IPv6 devices need configuration
   data to locate things like DNS and NTP servers, they should use DHCP
   and not re-invent the wheel...

=> please read the IPv6 Name Auto Registration draft!

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Feb 2003 17:15:41 +0100

DHCPv6 has been accepted as a proposed standard and is in the RFC Editor 
   queue for publication.
   
=> so it is not today published as a RFC, i.e., we don't have a published
spec, we have a to be published soon spec (this discussion should
make it magically publish in some hours :-).

   DHCPv6 is not just for address allocation.  "Stateless" DHCPv6, or 
   DHCPv6-lite, is an integral part of the specification and guidelines for 
   implementation are published as an I-D.  Stateless DHCPv6 ([opinion] which 
   will be widely used for DNS configuration) can be used with DDNS for 
   autoregistration of nodes that are incapable of registering themselves.
   
=> I disagree about the level of help/assistance DHCPv6-Lite can give
for the DDNS autoregistration because the real issue is the security
issue (DDNS without security is not usable) and as the addresses are
not allocated by DHCPv6 the standard assumption that DHCP allocates
the addresses so has the authority at least on the PTR RRs is no more
true (this is a part of the "+" in DHCP+DDNS). Robert Elz' message
gives a good description of this issue.

Regards

PS: I have a real problem to solve:
 - to manage by hand the DNS zones is not a good solution
 - DDNS startup scripts don't work well because of the security 
   pb and of the difference of nature between address management
   and RR management (which gives years of DHCP/DNS interaction drafts)
 - etc.
So even if the IPv6 NAR draft is far to be perfect, it is the beginning
of a solution and I wouldn't like to see further works on it stopped
(i.e., I support it as a WG document).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Feb 2003 15:51:46 -0600

> no, we asked for no address allocation service, not for no services
> but in the address allocation is main function of DHCPv6...

Address allocation is _not_ the main function of DHCPv6.   It is one of 
the *two* main functions of DHCPv6.   The other main function of DHCPv6 
is network configuration/resource discovery - that is, what are the 
local constants, and what are the local services?

DHCPv6 works fine if you just use it for the second of the two 
functions.   There was a recent interoperability test where only this 
functionality was tested, and it apparently did quite nicely (I wasn't 
there).

---

From: Paul Vixie <[email-masked]>
Date: Thu, 06 Feb 2003 22:48:05 +0000

this seemingly interminable thread may actually be ready to shed some light.

i am no fan of dhcp.  isc's implementation (mostly written by ted lemon,
to whom i am apparently but accidentally replying) is excellent, but the
client side (mostly windows and mac) has taken a terrible toll on
resources.  just this morning a client was once again stuck and only a
release/renew cycle made it work again.

as a distributed system (sorry johan, you missed the reference, a
distributed system is anything limited to message passing and possessing
asynchrony, so a dhcp server + its clients definitely qualifies) dhcp in
practice is just terrible.

compared to dhcp, the ipv6 autoconf ("EUI64") is wonderful.  since it is
stateless, there's no opportunity for the client to disagree with the server
or with other clients what the state currently is.  Hashing Is Your Friend.

all i personally need is a working dns-update strategy based on ipv6 autoconf.
this involves two changes: (1) a hook on the client side so i can update the
A and PTR following a successful autoconf (and again, just before shutdown);
(2) syntactic sugar in the dns server so that any host is allowed to update
(using tcp, not udp, to avoid spoofing) the PTR for their own address.  (the
A RR update can involve tsig, but for the PTR RR update tsig is impractical.)

dhcpv6 might be useful for learning a dns search list or discovering local
servers (though stuart cheshire's way is more dynamic and therefore better)
but it's a silly "cling to the past" solution compared to ipv6 autoconfig.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Feb 2003 20:22:15 -0600

>> Sorry, misuse of terminology.   It sends an update to the reverse
>> server signed in the private half of the SIG key from its forward 
>> FQDN.
>> The reverse server has to know to do step 6 to validate the update.
>
> because my laptop has a relationship to the server for psg.com, and
> can put something kinky into the forward name should not mean that
> the owner of the reverse zone should trust the data in the forward
> zone or that the laptop asserts.  is the attack not pretty obvious?

It was a rough outline.   Obviously the checking the reverse server has 
to do to make it work is more than what I said, but it's totally 
doable.   The validation I described prevents a random host on the 
network from trivially stuffing the DNS server with bogus PTR records.  
  You could do an additional validation where if someone wants to stuff 
a new valid into an old PTR record, the DNS server looks to see if the 
old FQDN in that PTR record still points back to the address referred 
to by the PTR record, and if it does, refuses the update.   This 
prevents PTR record stealing.

Is there some other attack I'm not thinking of here?

Obviously this assumes that the DNS server for the zone in question is 
willing to have arbitrary clients establish PTR records.   I can 
imagine a variety of administrative policies, from "allow all domains" 
to "allow only this set of domains" to "allow only my domain" to "allow 
no PTR updates at all."

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Feb 2003 18:24:50 -0600

> well, imiho, you were already three klud^H^H^Hheuristics deep

Heh!   I have to admit that it has its problems, but it seems like not 
a completely rotten idea.   In order for it to work nicely, you 
probably need an extra protocol, so that the DNS server doesn't have to 
be responsible for all the validation and bookkeeping, and so that you 
can have, *ahem*, leases on the PTR records, so that they get cleaned 
up when the registrant goes away.   I think we've pretty soundly 
rejected the idea that the DNS server might have such a mechanism.

But this seems more functional than a solution that doesn't involve any 
actual communication with the device that has autoconfigured.

> and the basic dynmaic update it all relies on is still not reliable in
> my daily use experience.

All of the solutions we've talked about rely on the basic dynamic 
update mechanism, which I have to say works just fine for me (I wish 
more DHCP clients supported it, though).