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: Francis Dupont <[email-masked]>
Date: Wed, 05 Feb 2003 10:43:30 +0100

In your previous mail you wrote:

=> I support this document.

Regards

[email-masked]

---

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

> => 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

---

From: Johan Ihren <[email-masked]>
Date: 05 Feb 2003 19:18:36 +0100

Hi Francis,

> is or not a good idea, it is if there is or is not enough interest...

They don't use DHCPv6 since there (as far as I know) was a concious
design decision made that it was not possible to rely on
"infrastructure services" being available on every piece of cable (or
air wave) that a v6 device would like to connect to. Which is fine.

But you got what you asked for: no services.

No DHCP server that can tell you about your FQDN, no trust
relationship with the friendly nearby DNS infrastructure (that you get
via DHCP and use for updating DNS). Nor will you get NTP clocks
(available through DHCP), printers (guess) or the location of the
local cola vending machine, etc, etc...

Design decision --> expected results followed --> no one is surprised.

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

Red herring (or I should perhaps say "fermented herring", a well known
swedish delicacy ;-). DHCP for v6 is not primarily about address
allocation (that is obviously not the major issue that it was for
v4). DHCP is about a standardized mechanism for "newly connected"
devices to locate stuff it has a need for (and possibly some stuff it
doesn't care about).

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

There are two kinds of networks (yes, we all know that there are two
kinds of everything, but that includes networks...): those with
infrastructure services and those without. You can plug-and-pray on
both types. But the rules are different. And *if* (please note the
*if*) your requirements also are different (let's say you suddenly
feel an urge to update DNS), then you should play by the rules.

For a network *with* infrastructure services the rule is:

        "Don't invent your own mechanism to locate stuff, use DHCP".

> a WG and DNSEXT is not so bad.

Hmm. Wrong choice. This should clearly be sent to DHC ;-)

Anyway, the point wasn't to spur discussion about this but rather to
argue that it should die. So I'll just shut up now and let everyone
get back to the previous programme...

Regards,

Johan

---

From: Rob Austein <[email-masked]>
Date: Wed, 05 Feb 2003 14:13:30 -0500

I think that Johan's analysis is correct.  DHCP combined with DNS
dynamic update already covers this space.

Having sent far too much mail about IPv6 and DHCP to the ipng list in
the past, I won't repeat all of that here, see the ipng list archives
for details.  Summary: with all due respect, most DHCP discussion in
the IPv6 WG has been heavily influenced by well-meaning people who do
not understand DHCP and are thus doomed to reinvent it.

So, while I can live with this draft going forward as experimental if
that's the DNSEXT WG consensus, I don't think it's necessary, and I
don't support it.

---

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: Randy Bush <[email-masked]>
Date: Wed, 05 Feb 2003 15:50:19 -0500

</chair hat>
<ops-ad hat>

> that's the DNSEXT WG consensus, I don't think it's necessary, and I

up a few thousand meters

there is a dichotomy between server-based resource discovery,
e.g., dhcp, and distributed service discovery, where the services
announce themselves or are discovered by non-centralized means.

the dchp-based approach has been deployed for some time, enhanced,
and is generally well-understood.

the distributed approach is less explored and well-documented.
various bits of it keep rising, most especially in the ipv6 world.

the problem is there has never been a coherent architecture of the
distributed approach, heck not even a picture or diagram of how it
all fits together.  so we get ad hoc pieces and no way to judge
how they all fit together, whether they are complete, etc.

</ops-ad hat>
<opinion>

imiho, unless and until we get a sufficient coherent picture of
distributed discovery with all the services explained, the pieces
that float up should be treated politely, but put aside as
experimental at best.  until the distributed architecture is well
described and well understood, the dhcp approach is well
understood, well documented, and well deployed.

randy

---

From: Scott Lawrence <[email-masked]>
Date: 05 Feb 2003 16:27:57 -0500

Randy Bush <[email-masked]> writes:

> experimental at best.  

As someone who's been interested in and working with a few different
discovery schemes for some time, I appreciate your inclusion of
'politely'; that has, regretably, not always been the case in some
IETF discussions.

I would also like to remind everyone concerned that the Internet
family of protocols was not developed by developing them from a
"coherent picture [...] with all the services explained".  There's
nothing wrong with the Experimental status; it should not be
considered a dead end into which rejected ideas are shunted.

---

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

> There's

Hear, hear!

---

From: [email-masked]
Date: Thu, 06 Feb 2003 18:20:21 +0900

> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt

I think most people are missing some important points which described
in this document.

1. This document provides GOOD NEWS to administrators of DNS servers.

   Most administrators of DNS servers are meeting problems how to
   collect IPv6 address information that should be registered to the
   DNS and how to prepare IPv6 address Data Base files for DNS servers.

   Especially, IPv6 addresses are too long to remember and EUI64-based
   addresses are too complicated to remember. Collecting such IPv6
   address information by hand is a terribly hard work.

   By using proposed mechanism, such IPv6 address information is collected
   automatically. Since the mechanism has intelligent candidates check
   functions, only IPv6 address information that should be registered is
   collected (there are no noise).
   
   # Dynamic Update in the DNS is a final procedure of the mechanism.
   Under some situations, Dynamic Update can be omitted.
   Namely, this mechanism can be used only for the IPv6 addresses
   collection.

   Administrators of DNS servers can used the collected data for the hints
   to prepare IPv6 address Data Base files for DNS servers.
  
   This usage helps administrators of DNS servers very much.

2. This document is on experimental track (not standard track)

   This information helps people.
   At least, administrators of DNS servers will become happy with
   this information.

3. This document provides a solution that can be used right now.
   This is a current applicable solution (not future solution).

   This mechanism can be introduced without modifying the existing DNS
   nor other IPv6 related implementations.

   This mechanism is highly modularized, it dose not cause any bad
   effects to other current existing mechanisms.
   
   Only sites which introduced this mechanism can get rewards.
   Introduce or not introduce is decided by sites' policies.

4. This mechanism is based on detecting DAD (Duplicate Address Detection)
   packets.

   So, the mechanism does not care about IPv6 address setting methods
   to nodes (by DHCPv6 or IPv6 Stateless Address Autoconfiguration
   [RFC2462] etc.).

   Only DAD packets are issued, the mechanism works under such situations.

5. This document do NOT prevent a future DHCPv6-based solution.
   
   DAD detection based solution and DHCPv6-based solution are NOT
   alternative.

Please reconsider above issues.

Regards,
Hiroshi

---

From: Johan Ihren <[email-masked]>
Date: 06 Feb 2003 09:25:00 +0100

JINMEI Tatuya / 神明達哉 <[email-masked]> writes:

Hi Jinmei,

> Please let me make it sure.  Could you be more specific about "a
> combination of DHCPv6 (and dynamic updates)"?  For what purpose are
> you intending to use DHCPv6?

I see two individual problems:

1. The device (according to the draft) has a problem knowing its
   FQDN. 

        DHCP will happily supply that information.

2. The device has a problem establishing a trust relationship with the
   nameserver maintaining the reverse zone the allocated address
   resides in.

        DHCP will assist with this, since it already has such a
        relationship (or at least can be configured to have that).

Regards,

Johan

---

From: Johan Ihren <[email-masked]>
Date: 06 Feb 2003 12:28:41 +0100

Hi Randy,

> how they all fit together, whether they are complete, etc.

I think this is wrong for two reasons.

One: this is about *discovery*. Discovery protocols are a special
     case, requiring special care, since they will typically have to
     be encoded into zillions of end devices, including the fabled v6
     enabled light bulbs. Keeping an open ended definition of what
     should be encoded in end devices to enable discovery seems to be
     a really Bad Idea.

     Ideally there should be exactly one "bootstrapping" protocol
     (i.e. DHCP in v4), but we already blew that for v6 since
     apparently RS/RA isn't enough (no surprise). 

     So perhaps we need two protocols, but in that case the second one
     (RS/RA being the first) should be generic enough to avoid the
     need for a third, and a fourth, and a .... DHCPv6 fits this bill
     rather neatly.

Two: this is not about *distributed* service discovery, this is by
     definition about *local* discovery. The situation is that a v6
     device is present on a particular physical link and doesn't know
     where to go for support.

     You take your v6 light bulb out for a spin on the water and find
     this new cable that you've never visited before. What do you do?
     You shouldn't just sail into the harbor, wildly firing all kinds
     of discovery bullets on various ports. Instead, just go and see
     the harbormaster and he'll tell you where the showers are.

     For every cable there should be at most one harbormaster.

     Having none is called "ad hoc". 

     Having more than one is called "mistake".

> understood, well documented, and well deployed.

Polite is good. We like that. However not speaking up when something
is wrong is not being polite, it is being overly passive. We all know
that it is important to do house cleaning because otherwise we will
suffocate under the burden of our collective bad ideas.

Johan

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 06 Feb 2003 22:14:59 +0900

>>>>> On 06 Feb 2003 09:25:00 +0100, 
>>>>> Johan Ihren <[email-masked]> said:

>         DHCP will happily supply that information.

Okay, then are you also assuming the DHCPv6 server assigns the IPv6
address(es) of the client?  Or are you thinking of some registration
mechanism from the client (that configures its address(es) in a
stateless manner) to the server?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

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

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

=> this is the DNS server discovery (or SLP server discovery),
and *not* the issue addressed by the IPv6 NAR draft.
   
   DHCP for v6 is not primarily about address allocation
   (that is obviously not the major issue that it was forv4).
   DHCP is about a standardized mechanism for "newly connected"
   devices to locate stuff it has a need for (and possibly some stuff it
   doesn't care about).
   
=> I'd like you are right but DHCPv6 is not what you describe.

=> no, the DHC WG has only one idea: how to fix all the issues of
DHCP in DHCPv6. The result is only few people still believe in
DHCPv6 and major implementors already claimed they'll *never* implement
the address allocation part of DHCPv6.

Regards

---

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

=> this is the case for IPv4 but not for IPv6 where the stateless
auto-configuration is used in place of DHCPv6.

=> the DHCP style of address allocation is not needed in IPv6 and
IMHO it even doesn't make sense. DHPCv6 is not published yet
when IPv6 networks exist for many years...

Regards

---

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 14:40:16 +0100

</chair hat>
   <ops-ad hat>
   
   ...
   
=> please note that the IPv6 Name Auto Registration is *not*
about resource discovery.

Regards

PS: the draft is about a mechanism to replace the "+" in the standard
DHCP+DDNS when DHCPv6 is not used for address allocation (as nearly
everybody use the stateless auto-configuration in existing IPv6 networks
and don't want to switch to something else, this "when" is the common
case :-).

---

From: Robert Elz <[email-masked]>
Date: Thu, 06 Feb 2003 22:06:55 +0700

Date:        05 Feb 2003 19:18:36 +0100
    From:        Johan Ihren <[email-masked]>
    Message-ID:  <[email-masked]>

Note, in the message below, please do not infer that I am disparaging the
usefulness of DHCP.   That is not the intent.   However, I also do not
believe that one can always require DHCP exist (especially not in IPv6
networks).

  | No DHCP server that can tell you about your FQDN,

True, but in many cases, the node already knows that (my nodes certainly
do, and when some DHCP server presumes to tell me different, I ignore it).

  | no trust relationship with the friendly nearby DNS infrastructure
  | (that you get via DHCP and use for updating DNS).

When I first read your message, this one I thought to be an important
point, but upon reflection, it isn't.

It is certainly true that the DHCP server can have a trust relationship
with the DNS server, but if the DHCP server is just going to blindly
forward an update request, sent by some client, to the DNS server, then
the DNS server may just as well have received it directly from the
client - whatever trust was assumed to exist, is all cast away.

For v4 things aren't quite as bad, as DHCP servers update the DNS only
with addresses the DHCP server has assigned, so there is at least some
general reason for believing the DHCP server there.  But for v6, DHCP
servers will almost never be actually assigning addresses, so the server
is just believing the client, and then taking that (unsubstantiated)
data and sending it to the DNS server.   That doesn't sound good.

The experiment proposed in this draft also has an entity (the registrar)
that can form a trust relationship with the DNS server, and but it doesn't
get its data from what some random client tells it, but from what another
(trusted) agent (the detector) tells it from what it observes of the network.

Personally I have my doubts that this can really work well - but what is
being proposed is an experiment, discovering whether things do work or not
is what experiments are all about, so I see no problem with doing it (nor
with publishing the doc that tells people how).

  | Nor will you get NTP clocks
  | (available through DHCP), printers (guess) or the location of the
  | local cola vending machine, etc, etc...

That's nonsense.  DHCP isn't the only way to obtain that kind of
information.  And while it is sometimes the best way, when it is
available, it isn't always going to work.

And note - it isn't the availability of a DHCP server implementation
that matters here, as has been pointed out, these days every matchstick
seems to come complete with a (rudimentary) DHCP server inside it.

What matters is collecting the data for the DHCP server to hand over to
clients, and then keeping it up to date.   On a well managed net, that's
not too hard.   On a (more or less) ad-hoc net, it is way too hard.
If the DHCP server can somehow automate that, then clients can just copy
its mechanism, and the DHCP server is redundant.   If it can't, then you're
requiring manual configuration.   Nasty.

  | For a network *with* infrastructure services the rule is:
  |         "Don't invent your own mechanism to locate stuff, use DHCP".

I don't know where that rule came from.   It is useful sometimes, but
not always.   But in any case, who says that the network where I'm
currently connected (which may have little or no services) has anything
to do with the network with the DNS server I want to update?

  | Anyway, the point wasn't to spur discussion about this but rather to
  | argue that it should die.

There is no reason for that.   I suspect that might be what will
eventually happen, as (to me) it looks like an over-elaborate mechanism
with too many problems left, but the way to find out that for sure, is
to actually have people (in different environments) try it, and see
whether or not it works.

Certainly just falling back on "worship no others before DHCP" dogma isn't
an appropriate response.

kre

---

From: Ralph Droms <[email-masked]>
Date: Thu, 06 Feb 2003 10:10:05 -0500

Francis,

At this point I must take exception with some of your recent statements 
about DHCPv6.

DHCPv6 has been accepted as a proposed standard and is in the RFC Editor 
queue for publication.

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.

Cisco has an implementation of stateless DHCPv6 that can be used without 
address assignment; that implementation is almost trivial (it must be; I 
contributed to the implementation and I have a PhD in CS).

We successfully demonstrated DHCPv6 interoperability at TAHI last month and 
will test other implementations at Connectathon next month.

We have a published spec for DHCPv6, running code and proven 
interoperability of independent implementations.

- Ralph

---

From: Francis Dupont <[email-masked]>
Date: Thu, 06 Feb 2003 16:13:33 +0100

=> can you rephrase this with the assumption the address was NOT
allocated by DHCP?

   

Regards

---

From: Ralph Droms <[email-masked]>
Date: Thu, 06 Feb 2003 10:24:01 -0500

What he said (far more concisely and elegantly than I ever could)...

- Ralph

---

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

=> 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 :-).

=> 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: Ralph Droms <[email-masked]>
Date: Thu, 06 Feb 2003 11:30:51 -0500

I do not support the publication of this specification on experimental
track, for the following reasons:

What, exactly, is being standardized as an experimental protocol in
this document; why is the IETF publishing it?  The detector function
is a set of heuristics which may be of use in detecting newly
connected nodes, but it's not a protocol.  The detector<->registrar
communication is only described as an example in Appendix A.  The
registrar then uses DDNS to change the information in DNS.  The
registrar function is a set of rules for generating names for nodes
and for managing information about nodes.  What is the protocol that
must be standardized for interoperability among different
implementations?

I don't understand the motivation for registering the information
collected by this mechanism.  Registering a binding between a name and
an address assigned to a device is of no value unless that name is
known to the entities that want to interact with the device.  My newly
connected device is assigned the FQDN 00-03-47-0F-2D-44.example.com,
that name is useless unless I can somehow discover it and use it
elsewhere.

Similarly, what is the "IP address information that should be
registered in the DNS"?  The information should go in the DNS only if
it's used as part of a name-address binding.  If the name is generated
automatically and isn't a name chosen to be associated with a device,
it's useless.

How do independent Registrars cooperate to resolve name conflicts?
(This is an issue we've spent a lot of time trying to resolve in
DHCP-DDNS interaction.)  Suppose I connect a device that indicates a
preference of "joe.example.com" that is registered by Registrar R1,
and you connect a device that also indicated a preference of
"joe.example.com" that is registered by Registrar R2.  Which device is
assigned joe.example.com, and how does the network administrator
control the resolution process?

- Ralph

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 07 Feb 2003 02:09:52 +0900

>>>>> On Thu, 06 Feb 2003 22:06:55 +0700, 
>>>>> Robert Elz <[email-masked]> said:

...

Excellent points, so can we stop using DHCPv6 as an excuse to deny the
draft and concentrate on the proposal itself?

(The latest message from Ralph would be a good restart of the
discussion.)

					JINMEI, Tatuya

---

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

> stateless manner) to the server?

The way that was proposed in the DHC working group to solve this 
problem was to update the PTR record in the DNS on receipt of the DHCP 
Information Request packet.

I think the question of the client knowing its domain name is 
overstated - if it's going to update the DNS itself, it knows its 
domain name.

---

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

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 17:01:42 -0600

I would argue, by the way, that the right way to do DNS updates in IPv6 
with stateless addrconf is this:

1. Client gets address.
2. Client discovers route to outside world.
3. Client, which knows its FQDN, and has a private key matching the 
public key in a SIG record on that FQDN, updates the primary nameserver 
for its FQDN with its new IP address, using SIG(0) with its key.
4. Client queries to find out who owns the reverse zone it needs to 
update.   It can do this either by walking the chain from the root, or 
by asking the local name server if it's gotten DNS server configuration 
information through DHCPv6.
5. Client sends a DNS update to the primary server for the reverse zone 
that owns its name, again using SIG(0) with the signature from its FQDN.
6. DNS server looks up the key on the FQDN, verifies that the client 
knows the private key, verifies that there is an A4 record for the IP 
address corresponding to the PTR the client is updating, and then does 
the update.

Now you have an automatic, standards-compliant update mechanism that 
doesn't require DHCP, is reasonably secure, and places the 
responsibility for doing the update on the device that is most capable 
of deciding to do it.   The one thing that's missing is a step for 
removing the name later.   Probably this would involve a step 7, where 
the client sends a delete, again signed with the private half of the 
SIG on its FQDN, and the DNS server verifies that the A4 record is 
gone, and then does the delete.

BTW, I used the term "client" above even though we're not doing DHCP, 
simply because it was easier than saying "configuring node."   I don't 
mean to imply anything by using the term "client" - it's just what 
rolled off my keyboard.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 6 Feb 2003 15:15:59 -0800

>a WG and DNSEXT is not so bad.

But, as was true when we met in Yokohama, this document does not fit 
within the charter of DNSEXT.  (This is not a comment on the content 
of the document.)  It's never been clear to me what is the 
justification for discussing this document on this mail list.

After an initial reading back then, I haven't considered it further 
as it looks to be out of scope to me.  I might be convinced to read 
it if the charter were to be changed to cover it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Feb 2003 18:43:21 -0500

> that owns its name, again using SIG(0) with the signature from its FQDN.

if it does not know who holds the reverse zone, and, in fact, is not
preconfigured, how the heck does it send a _validly signed_ sig(0)
update to the reverse server if and when it finds it?

randy

---

From: Ted Lemon <[email-masked]>
Date: Thu, 6 Feb 2003 17:55:31 -0600

> update to the reverse server if and when it finds it?

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.

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Feb 2003 19:03:44 -0500

> 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?

randy

---

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

> 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: Derek Atkins <[email-masked]>
Date: 07 Feb 2003 09:58:41 -0500

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

I rightfully grab an address and go through the process.  Then I go
offnet without removing my forward pointer.  My "lease" expires.  The
next person who happens to get my address can no longer get the PTR
entry because the old (stale) forward entry is still there.

> to "allow only this set of domains" to "allow only my domain" to
> "allow no PTR updates at all."

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Edward Lewis <[email-masked]>
Date: Fri, 7 Feb 2003 07:52:51 -0800

To some degree I agree with what Randy means here, but I'm not sure I 
agree with the logic.

>various bits of it keep rising, most especially in the ipv6 world.

Academically, I think the distributed approach has been explored a 
good deal.  I haven't the time to spend in a literature search, but 
I'm sure there are some research papers on the topic.  (I recall 
attending an IETF meeting in '94 on v6 address discovery and muttered 
- 'that's what Apple does' and 'that's what OSI does' to two of the 
tree approaches.)

'Course, Appletalk has gone IP and OSI has gone to rest, I think that 
says quite a bit about the promise of the approach.

Don't get me wrong, I think it's really cool, but empirical evidence 
says it isn't stable.

>how they all fit together, whether they are complete, etc.

There are a lot of needed components.  That means it is fertile 
ground for a Rube Goldberg design.

>understood, well documented, and well deployed.

That I agree with.

---

I thought more about Randy's assessment overnight.  I think there's 
more to the issue that what I saw at first.

Back when I taught a class on networking, I covered the topic of 
client-server.  After spending some time on that topic alone I recall 
making the comment that networking and distributed processing is not 
just client-server.  There are peer to peer approaches, etc.  I 
recall at the time having a nagging suspicion that client-server, 
although not exclusive would eventually dominate.  (This was even 
pre-WWW).

It seems that client-server has come to dominate, my guess is that it 
is because client-server is easier to operate and manage than 
hierarchy-less peer to peer.  This hypothesis seems to be tested 
again by this thread - whether one plucks an address from the ether 
and reports it to DNS (peer-based) or one consults a server for an 
assignment.

It's not that peer to peer is less worthy than client and server, 
it's that operators (enterprise in this context) will prefer the 
latter as it gives them a better ability to run a workable network.

---

And another thing.  One of the main principles that I apply to DNS is 
to keep it a simple service, to not add a lot of fancy feature cruft. 
This means that the features have to appear elsewhere.  What gives me 
pause in maintaining a hard line like this is that this philosophy 
runs counter to the peer-to-peer vs client-server ideas above.

Although client-server is easier to manage from some points of view, 
relying on it totally is wrong.  Client-server is counter to the 
philosophy of having strong end points and a passive core, which is a 
big part of the spirit of the Internet.

Perhaps there's some not yet understood (by me) threshold where 
client-server and peer-to-peer comparisons change the recommendation 
of the approach.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Ted Lemon <[email-masked]>
Date: Fri, 7 Feb 2003 13:08:17 -0600

> entry because the old (stale) forward entry is still there.

Yup.   We can't do much about this case without adding extra complexity 
we'd probably rather avoid.   Does that render the technique Not Useful?

---

From: Randy Bush <[email-masked]>
Date: Fri, 07 Feb 2003 18:39:07 -0500

> we'd probably rather avoid.   Does that render the technique Not Useful?

</tact>

well, imiho, you were already three klud^H^H^Hheuristics deep and
the basic dynmaic update it all relies on is still not reliable in
my daily use experience.

randy

---

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).

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 11 Feb 2003 10:53:37 +0100

> entry because the old (stale) forward entry is still there.

Huhhh??? The host that is managing the addresses also manages the
reverse tree.  As soon as an address is assigned to a new MAC address
the PTR should change to a default vallue or be dynamically updated by
the new host.

It would be a strange world if I would not be able to get a PTR RR
because somebody else uses a stale forward mapping.

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Derek Atkins <[email-masked]>
Date: 11 Feb 2003 10:00:42 -0500

> the PTR should change to a default vallue or be dynamically updated by

You're thinking of a V4 world.  Think "V6 Autoconfiguration".  When
using autoconfig the "host that is managing the address" is "MY
HOST".  My host, plugging into a v6 network, is certainly not in
charge or managing the reverse tree.

Not everyone in the v6 world is using DHCPv6.  In fact the IETF in
Atlanta certainly wasn't.

However we still want "proper" dns in such a world.

> because somebody else uses a stale forward mapping.

Agreed, which is why I brought up the issue.

-derek

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2003 19:46:56 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "jinmei" == jinmei  <Tatuya / ~~~~ <[email-masked]>> writes:

    >> 1. The device (according to the draft) has a problem knowing its FQDN.

    >> DHCP will happily supply that information.

    jinmei> Okay, then are you also assuming the DHCPv6 server assigns the
    jinmei> IPv6 address(es) of the client?  Or are you thinking of some
    jinmei> registration mechanism from the client (that configures its
    jinmei> address(es) in a stateless manner) to the server?

  I would think that the address of the DHCPv6 servers should simply
be returned by one (or all) of the routers in the router advertisements.
(As an option)

  As a fallback, the DHCPv6 server could have a well known link local
address. RS/RA gets you on the network. RFC2462 says:

   stateful autoconfiguration complement each other. For example, a host
   can use stateless autoconfiguration to configure its own addresses,
   but use stateful autoconfiguration to obtain other information.   
   Stateful autoconfiguration for IPv6 is the subject of future work
   [DHCPv6].

  The key thing to realize is that DHCP{v4} does not just do address
configuration - it establishes some level of trust between the end node and
the infrastructure. In particular, a random v6 node is just NOT going to have
any trust relationship with the DNS server such that it can update the
reverse map. A DHCP server can have that.

  The DHC WG is working on ways of making that trust stronger.
  SEND is also doing similar things. This is not a DNSext issue.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2003 20:02:47 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:
    >>> 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.
    >> 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?

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

  Maybe. I'm not convinced that the failure cases are tractable, or can
easily be dealt with. 

    Ted> Obviously this assumes that the DNS server for the zone in question
    Ted> is willing to have arbitrary clients establish PTR records.  I can

  It would a lot easier if a machine on the local LAN can control things to
a finer degree. A lot easier to deal with the trust relationships. It
provides a clearly local place to put administrative overrides, and to clear
up confusion. Such a machine can much more clearly check reachability of the
"client".

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Feb 2003 19:49:05 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Robert" == Robert Elz <[email-masked]> writes:
    Robert> For v4 things aren't quite as bad, as DHCP servers update the DNS
    Robert> only with addresses the DHCP server has assigned, so there is at
    Robert> least some general reason for believing the DHCP server there.
    Robert> But for v6, DHCP servers will almost never be actually assigning
    Robert> addresses, so the server is just believing the client, and then
    Robert> taking that (unsubstantiated) data and sending it to the DNS
    Robert> server.  That doesn't sound good.

  No, it does not. But, that's not how I would do it.
  
    Robert> The experiment proposed in this draft also has an entity (the
    Robert> registrar) that can form a trust relationship with the DNS
    Robert> server, and but it doesn't get its data from what some random
    Robert> client tells it, but from what another (trusted) agent (the
    Robert> detector) tells it from what it observes of the network.

    Robert> Personally I have my doubts that this can really work well - but
    Robert> what is being proposed is an experiment, discovering whether
    Robert> things do work or not is what experiments are all about, so I see
    Robert> no problem with doing it (nor with publishing the doc that tells
    Robert> people how).
  
  The detector sounds like a DHCPv6 server to me.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 12 Feb 2003 20:19:17 +0900

>>>>> On Fri, 07 Feb 2003 19:46:56 -0500, 
>>>>> Michael Richardson <[email-masked]> said:

...

Sorry, but you did not answer my question.  I didn't talk about the
address of the DHCPv6 server(s) at all.  I asked if you cared about a
host using stateless autoconfiguration to assign its own addresses in
your scenario.

BTW: (though this is not related to my question) your thought above is
incorrect.

> reverse map. A DHCP server can have that.

I know that.  This is not related to my question.

					JINMEI, Tatuya

---

From: [email-masked]
Date: Tue, 18 Feb 2003 11:31:22 +0900

Date: Thu, 06 Feb 2003 11:30:51 -0500
Message-ID: <[email-masked]>

> connected nodes, but it's not a protocol.  The detector<->registrar
                            ^^^^^^^^^^^^^^

Please read the I-D carefully.

Let me quote the beginning of the I-D.

   This document describes a scheme of "Domain Name Auto-Registration
                           ^^^^^^^^
   for Plugged-in IPv6 Nodes" mechanism that makes it possible to
   register both regular and inverse domain name information of plugged-
   in IPv6 nodes to DNS servers automatically.

The document describes a scheme (not a protocol).

Main goals of the document are:

  - to meet requirements to use logical names that are easy to remember
        to specify IPv6 nodes (even if they are just plugged-in).

  - to clarify problems that we meet when we apply the Dynamic Updates
        in the DNS [DYN-DNS] to automatic domain name information
        registration mechanisms.

  - to provide a scheme to solve above problems.

  - to provide a method to collect IPv6 address information that
        should be registered to DNS servers.
        (This will help administrators of DNS servers.)

  - ...

This document is on experimental track (not standard track), and 
the document describes enough information for it.

Regards,
Hiroshi

---

From: Ralph Droms <[email-masked]>
Date: Sat, 22 Feb 2003 11:04:06 -0500

Thanks for the clarification about the purpose of the document.

However, I still don't agree that the IETF should consider publishing
this document.  There are no parts of the scheme described in
the document that address or solve interoperability issues.

- Ralph

---

From: Edward Lewis <[email-masked]>
Date: Sun, 23 Feb 2003 14:23:11 +0800

>the document that address or solve interoperability issues.

FWIW - I had the same comment in :
    http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01152.html

(Not meaning to say "I said it first," but to say, "I agree.")

My other problem with the document is in:
    http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01152.html

and this hasn't been addressed (i.e., no update to the WG charter to 
allow this).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer