Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration

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

Francis Dupont <[email-masked]> writes:

Hi Francis,

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

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

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

>    or they don't (that's called ad-hoc networking).
> 
> => 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".

>    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. 
>    
> => DNSEXT was proposed by the chairs of the WGs. This draft needs
> 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

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

[email-masked]

---

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

]       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"); [