Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt

Ted Lemon <mellon@fugue.com> Mon, 09 February 2004 17:23 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29146 for <dhcwg-archive@odin.ietf.org>; Mon, 9 Feb 2004 12:23:56 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF85-00089A-GF for dhcwg-archive@odin.ietf.org; Mon, 09 Feb 2004 12:23:29 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19HNT4q031310 for dhcwg-archive@odin.ietf.org; Mon, 9 Feb 2004 12:23:29 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF85-00088v-Cl for dhcwg-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 12:23:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29106 for <dhcwg-web-archive@ietf.org>; Mon, 9 Feb 2004 12:23:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqF83-0003iw-00 for dhcwg-web-archive@ietf.org; Mon, 09 Feb 2004 12:23:27 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqF79-0003cN-00 for dhcwg-web-archive@ietf.org; Mon, 09 Feb 2004 12:22:31 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqF6d-0003Vw-00 for dhcwg-web-archive@ietf.org; Mon, 09 Feb 2004 12:21:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF6e-0007q3-Ch; Mon, 09 Feb 2004 12:22:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqF5s-0007is-O0 for dhcwg@optimus.ietf.org; Mon, 09 Feb 2004 12:21:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28947 for <dhcwg@ietf.org>; Mon, 9 Feb 2004 12:21:09 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqF5r-0003UP-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:21:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqF52-0003QM-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:20:21 -0500
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AqF4L-0003Lb-00 for dhcwg@ietf.org; Mon, 09 Feb 2004 12:19:37 -0500
Received: from [10.0.1.3] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 0DABE1B2E29; Mon, 9 Feb 2004 11:08:38 -0600 (CST)
In-Reply-To: <2427813621.1076316018@localhost>
References: <2427813621.1076316018@localhost>
Mime-Version: 1.0 (Apple Message framework v612)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <1F64DC40-5B24-11D8-93AF-000A95D9C74C@fugue.com>
Content-Transfer-Encoding: 7bit
Cc: dhcwg@ietf.org
From: Ted Lemon <mellon@fugue.com>
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt
Date: Mon, 09 Feb 2004 11:19:31 -0600
To: Harald Tveit Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.612)
Content-Transfer-Encoding: 7bit
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> - Mark each and every DHCPv6 configuration parameter with "Interface 
> specific" or "Host specific".

All of your proposals have been discussed before, and in fact at least 
some have been implemented, although I just reread parts of RFC3315 and 
was unable to find a place where you would have been able to easily 
find out about this.

In particular, DHCPv6 uses option encapsulation pretty heavily to form 
a hierarchy of applicability.   A DHCP packet contains options.   Some 
of these options are identity associations.   Identity associations 
generally correspond to interfaces, although some hosts may have more 
than one identity per interface.   Within each identity association 
there may be one or more IP address options, each of which can itself 
contain options.

Options that are contained within IP address options are specific to 
that IP address.   Options contained in identity association options 
are specific to that identity association (e.g., interface).   Options 
at the top level are general - they apply regardless of the identity 
association.   So you'd put the IP address of your name server there, 
most likely.

In reviewing RFC3315 with what you've said in mind, I realize that it 
doesn't ever explicitly say this, or at least I can't find where it 
says it.   It's all there in a way in the definitions of the various 
options, but you'd have to read the draft pretty carefully and 
creatively to realize that what I've said is what's being implied.

> - For "Host specific", make it easy for a host to figure out which set 
> of parameters it uses, and let it stick to that set only. No mixing!

Okay, but how do we specify this?   I guess saying "no mixing" is 
pretty easy, but I don't see how we can go beyond that, and I'm not 
sure that just specifying that is going to result in reliable behavior 
- it's easy to imagine a dumb DHCP client stubbornly making the wrong 
choice every single time.

> - Make sure that all "Host specific" parameters are able to specify 
> values that make sense for both IPv4 and IPv6

I'm not sure we've been doing this, but I agree that it's a reasonable 
thing to do.

> - In all the instances I've seen so far, declare that if you need an 
> IPv4 address, put it in as an IPv4-mapped IPv6 address (::12.34.56.78) 
> - no other changes needed.

So are you saying that a DHCPv6 client should be able to acquire IPv4 
addresses, or just that when it gives the addresses of the DNS server, 
it should be able to give the IPv4 addresses as well as the IPv6 
addresses?   I can see a lot of problems with the former; in the case 
of the latter, it makes sense, although I would argue that the server 
administrator should be able to enable or disable IPv4 to IPv6 address 
mapping, because I can imagine cases where you'd want it and cases 
where you wouldn't.

> I may now have repeated a proposal that was suggested and rejected 3.5 
> years ago - that's life too. But you asked......

It's good that you're asking these questions.  I'm sorry for dumping a 
pile more on you, but I am definitely interested in your answers.   We 
needed to kick 3315 out the door, for obvious reasons, but that doesn't 
mean that it requires no further tweaking.   Fortunately, I don't think 
what we're talking about here requires any incompatible changes.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg