Subject: RE: How IPv6 host gets DNS address

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Wed, 5 Nov 2003 16:23:49 +0100

sorry for the delay.

I agree with the point of Pekka. 

Moreover DHCP-lite means another process on the server side, where in
other solutions use existing processes (well-known adresses use routing
features, RA-based solution can be merged with RA deamon). Am I wrong ?

I do think that "complexity" may not be the most important criteria to
choose "the" solution. 

Is there a consensus on "we need first a solution to known how to
contact DNS resolvers" ? Is there a consensus on "the solution found
should also be able to give othe information other information (NTP,
SMTP server addresses, search path list, ...) " ?

Luc

> -----Message d'origine-----
> De : Pekka Savola [mailto:[email-masked]]
> Envoye : mardi 7 octobre 2003 07:15
> A : John Schnizlein
> Cc : BELOEIL Luc FTRD/DMI/CAE; [email-masked]
> Objet : RE: How IPv6 host gets DNS address
> 
> 
> On Mon, 6 Oct 2003, John Schnizlein wrote:
> > At 10:32 AM 10/6/2003, BELOEIL Luc FTRD/DMI/CAE wrote:
> > >...
> > >Some do think DNS resolver address is enough. I agree with 
> that, when
> > >one trust its local network and/or when one just need simple Ip
> > >connectivity (see Pekka Savola example), DNS resolver 
> addresses is the
> > >only "information" to add to stateless address 
> autoconfiguration. There
> > >I have the feeling that DHCP-lite is still to complicated...
> > 
> > What is complicated about DHCP-lite?
> [...]
> 
> About 100+ pages of specification?
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 

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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 5 Nov 2003 08:19:28 -0800 (PST)

Luc, Pekka,

Please see draft-ietf-dhc-dhcpv6-stateless-01.txt, which is
in IETF last call.  It gives the subset of DHCPv6 that must be implemented
for host configuration without address assignment.

"another process on the server side" is an implementation detail.  Because
the DHCPv6 function for host configuration maintains no dynamic per-client
state, the code can, in fact, be implemented as code that is executed in
the same way as router solicitation code.  I strongly believe, based on
implementation experience, that the implementation complexity of DHCPv6
for host configuration is *not* prohibitive.

Another way to phrase the quesion about consensus is "do we have consensus
about a specific function or functions that DHCPv6 does not meet for host
configuration such as DNS?"  I think this problem is solved RFC 3315 and
draft-ietf-dhc-dhcpv6-stateless-01.txt.  There are multiple independent
implementations that have demonstrated interoperability at TAHI,
Connectathon and the DHCPv6 interop tests run by NEC in Vienna.

We have other significant problems to solve to complete the IPv6
name-and-address management story - most importantly at this point, how do
we arrange for population of PTR records by roaming hosts using stateless
address autoconfiguration?  We should be spending our cycles on those
problems...

- Ralph

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 06 Nov 2003 03:32:25 +0900

>>>>> On Wed, 5 Nov 2003 08:19:28 -0800 (PST), 
>>>>> Ralph Droms <[email-masked]> said:

> Please see draft-ietf-dhc-.txt, which is

> Connectathon and the DHCPv6 interop tests run by NEC in Vienna.

I basically agree with Ralph here.

Regarding complexity: I often feel people tend to say a particular
technology is complicated when they do not like (or do not support)
the technology.  But if something is complicated is often more or less
subjective.  It is the fact that RFC3315 (DHCPv6) is a specification
of about 100 pages, and I agree that a thick specification can often
be "complicated".  However, I don't think it's fair to say the
specification is complicated (or too complicated to take it as a
method for the DNS recursing server discovery) just because of the
number of pages.  It may just be a result of trying to be clear.  I
also do not think this argument is fair, since the RA-based discovery
has not become an RFC, while DHCPv6 has.  How can we be so sure that
the (future) RFC of the RA-based method won't be a specification of
200+ pages?  (I admit I don't actually expect such a huge document for
this, but my point is that it's not fair to compare the complexity of
a published document to that of an unpublished one by their thickness)

Besides, if the DHCPv6 specification is that complicated, why have we
seen more than 5 implementations (I'm trying to be moderate here.  I'm
quite sure there are more than 5) that are interoperable?  Again, I
agree with Ralph on his point.

I tend to agree that the things would be much easier if the stateless
part of the DHCPv6 specification was clearly more separated from its
stateful part *from the beginning*.  However, I'm convinced that the
attempt of clarification by dhcpv6-stateless-01 is a reasonable
compromise.  I don't think the fact the current shape of the
specification is not ideal (IMO) can be a reason to take DHCPv6 as
"the" method for DNS recursing sever discovery.

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 06 Nov 2003 03:41:47 +0900

>>>>> On Thu, 06 Nov 2003 03:32:25 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

>> for host configuration is *not* prohibitive.

(I forgot to mention one important thing in my previous response)

I also strongly believe, *based on my implementation experience*, that
the implementation complexity of DHCPv6 for host configuration is
*not* prohibitive.  Of course, this is just a subjective impression,
but I believe the implementation complexity should be measured by
implementors, not (mainly) by protocol designers who do not implement
it.

					JINMEI, Tatuya

---

From: masataka ohta <[email-masked]>
Date: Thu, 06 Nov 2003 10:28:23 +0900

Ralph;
 
> address autoconfiguration?  We should be spending our cycles on those

Wrong problem.

The problem to be solved (if not yet solved) is

	how do we arrange for population of PTR records by roaming
	hosts using address autoconfiguration

and DHCP, rather than DHCP-lite, is, it seems to me, the only
way to go.

> I strongly believe, based on

Compared to the implementation complexity of ND, yes.

The easiest, simplest and fastest way to go is to remove ND,
a full set of useless features, entirely.

						Masataka Ohta

---

From: Ralph Droms <[email-masked]>
Date: Wed, 05 Nov 2003 22:50:35 -0500

Ohta-san,

Your use of English was almost too subtle for me.  I had to read your
problem statement a couple of times before I realized you were turning
around my basic assumption.  So, rather than assuming stateless address
autoconfiguration and trying to solve the PTR record population problem, we
should solve the PTR problem by picking the right address configuration
process.

I believe there are some sites who have come to the conclusion that DHCPv6
address assignment is the right deployment model, exactly because it avoids
the PTR record problem as well as giving network administrators reliable
information about mappings between devices and IPv6 addresses.

- Ralph

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 06 Nov 2003 23:00:59 +0900

Ralph;

> Your use of English was almost too subtle for me.

That has been my problem as a non-native user of English that
I'm glad to be able to be a source of the problem. :-)

However, in this case, it is merely a technical issue that I am
and you should be keen against dumb word of "stateless".

Stateless autoconfiguration has damaged protocols such as
MIPv6 to be useless.

> So, rather than assuming stateless address

There is no stateless address autoconfiguration with PTR record
population problem. See below.

> information about mappings between devices and IPv6 addresses.

With ND, neither routers nor hosts can register PTR of reverse domain.

But, I'm afraid you don't see the other half of the problem. Reverse
domain registration is meaningful if and only if forward domain is
properly registered. To let a host register its autoconfigured address
to the forward domain, the host must be configured with cryptographic
key information for dynamic update of the forward domain, which means
the host is stateful.

So called "stateless autocnfiguration" is a mechanism imitating
features of poor IPX or windows and is mostly useless except for
a small (single link) private IP network isolated from the Internet
that it should not have affected protocols designed primarily for
the Internet, such as IPv6 or MIPv6, so badly.

PS

I wrote DHCP, not necessariry DHCPv6 as is, as the latter is a
little too much bloated with a meaningless feature of authentication.
Misconfiguration occurs often on servers with proper authentication
key. Not giving out addresses does not prevent attackers copy
assigned addresses of other hosts.

---

From: Alain Durand <[email-masked]>
Date: Fri, 07 Nov 2003 09:15:06 -0800

> address autoconfiguration?  We should be spending our cycles on those

I agree 100%. We already have one solution to discover the DNS server 
address.
Some like it, some don't, but the fact and the matter is that we have 
_a_ solution.
So, let's spend valuable cycle to fix problems that do not have any 
solution yet.

	- Alain.