Re: [dhcwg] Request for review of 3315id draft...

Ted Lemon <mellon@fugue.com> Thu, 08 January 2004 22:47 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15879 for <dhcwg-archive@odin.ietf.org>; Thu, 8 Jan 2004 17:47:14 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeivP-0002Sd-HL for dhcwg-archive@odin.ietf.org; Thu, 08 Jan 2004 17:46:47 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i08MklhC009453 for dhcwg-archive@odin.ietf.org; Thu, 8 Jan 2004 17:46:47 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeivP-0002SO-E4 for dhcwg-web-archive@optimus.ietf.org; Thu, 08 Jan 2004 17:46:47 -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 RAA15787 for <dhcwg-web-archive@ietf.org>; Thu, 8 Jan 2004 17:46:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeivM-0004hn-00 for dhcwg-web-archive@ietf.org; Thu, 08 Jan 2004 17:46:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeitX-0004Wx-00 for dhcwg-web-archive@ietf.org; Thu, 08 Jan 2004 17:44:52 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aeirl-0004Nk-00 for dhcwg-web-archive@ietf.org; Thu, 08 Jan 2004 17:43:01 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aeirk-00029w-Kw; Thu, 08 Jan 2004 17:43:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeirX-00029N-Bi for dhcwg@optimus.ietf.org; Thu, 08 Jan 2004 17:42:47 -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 RAA15602 for <dhcwg@ietf.org>; Thu, 8 Jan 2004 17:42:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeirU-0004KR-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 17:42:44 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeipa-0004ER-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 17:40:47 -0500
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1Aeinz-00048D-00 for dhcwg@ietf.org; Thu, 08 Jan 2004 17:39:08 -0500
Received: from [81.200.65.85] (dhcp-85.wl.nominum.com [81.200.65.85]) by toccata.fugue.com (Postfix) with ESMTP id D744C1B200C; Thu, 8 Jan 2004 16:33:37 -0600 (CST)
In-Reply-To: <000101c3d633$7e467a10$6401a8c0@BVolz>
References: <000101c3d633$7e467a10$6401a8c0@BVolz>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <7782F257-422B-11D8-98A2-000A95D9C74C@fugue.com>
Content-Transfer-Encoding: 7bit
Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>
From: Ted Lemon <mellon@fugue.com>
Subject: Re: [dhcwg] Request for review of 3315id draft...
Date: Thu, 08 Jan 2004 14:39:06 -0800
To: Bernie Volz <volz@metrocast.net>
X-Mailer: Apple Mail (2.609)
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

On Jan 8, 2004, at 2:05 PM, Bernie Volz wrote:
> Well, why don't we just do what we do for DHCPv6 ... add an IA 
> (Identity
> Association) Option. That way, if the client has two interfaces, it can
> either chose to use two different IAs or none (in which case it may 
> well get
> the same address).

Hm, good point - letting the client decide whether or not to use two 
IAs for two interfaces probably produces the right result.

> This doesn't fully solve the DNS issue, but at least it gives the 
> server a
> hint that if an IA was sent, it might not be wise for the server to 
> wipe out
> other A records that the client has (since another server may have 
> assigned
> the client a different address). The DHCP server can always look at 
> the A
> record(s) and if the target address is within its authority, it can 
> delete
> the old A record (assuming the client does not have a valid lease for 
> the
> address).

I think that an ad-hoc implementation like this is more likely to cause 
harm than good - it's really easy to imagine algorithms for doing this, 
and it's equally easy to imagine cases in which they would produce 
exactly the wrong results.   If we think it's important to handle these 
cases, we should define a system that supports it.   This is doable - 
we just need more TXT records, but that's easy.   You'd have a TXT 
record indicating which node owned the name, and then another TXT 
record indicating which IP address goes with which individual IA.

The problem with this is that it's a lot of complexity for little 
benefit.   Generally speaking, I would expect that even when a client 
has multiple interfaces, advertising multiple A records for it on the 
same name is not going to produce the result that the user actually 
wants.   It would probably be better to just have a system on the 
client for deciding which interface is primary, and setting the name on 
that one.   Apple has such a system now, although I do not know how 
well it works, nor whether they use it in deciding for which interface 
to request that an A record be installed.   In general, I think that 
when you want to advertise A records on multiple interfaces, you 
probably want the client to do the update so that it can be customized 
according to the client's wishes.

> (Note that this also has the nice feature of allowing a client to get
> multiple addresses if it indeed wanted to even on a single interface - 
> why
> it would ever want to do this is beyond me, but ... It's also much 
> better
> than having multiple identifiers for the client, which is what would 
> happen
> today.)

Yup, this is a win.   Maybe it's better to just specify the slightly 
more complex solution.   Does anybody but Bernie want to vote on this?  
  I get the impression that Vasu is in favor of doing it this way, and 
possibly the folks in favor of the rentschler interface id draft would 
be satisfied by this approach as well?


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