Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header

Ted Lemon <mellon@nominum.com> Thu, 30 August 2001 14:37 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18560; Thu, 30 Aug 2001 10:37:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29564; Thu, 30 Aug 2001 10:36:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29545 for <dhcwg@ns.ietf.org>; Thu, 30 Aug 2001 10:36:18 -0400 (EDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18445 for <dhcwg@ietf.org>; Thu, 30 Aug 2001 10:34:57 -0400 (EDT)
Received: from grosse.bisbee.fugue.com (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7UEUPf15495; Thu, 30 Aug 2001 07:30:25 -0700 (PDT)
Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7UEaEl00456; Thu, 30 Aug 2001 10:36:14 -0400 (EDT)
Message-Id: <200108301436.f7UEaEl00456@grosse.bisbee.fugue.com>
To: Josh Littlefield <joshl@cisco.com>
cc: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>, "'Ralph Droms'" <rdroms@cisco.com>, dhcwg@ietf.org
Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header
In-Reply-To: Message from Josh Littlefield <joshl@cisco.com> of "Wed, 29 Aug 2001 16:30:17 EDT." <3B8D50D9.D86E9BF7@cisco.com>
Date: Thu, 30 Aug 2001 10:36:14 -0400
From: Ted Lemon <mellon@nominum.com>
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

> I believe if the relay is using the simple API and it must specify the right
> source address, then the relay will need to send through a socket which is
> bound to the desired local address.  I believe it will also receive its
> response through that bound socket, so learning the responses packet's
> destination address is accomplished by noticing the socket through which it
> arrived.  So, its doable with the simple API, though I think its a bit more
> complexity than you'd want relays to have to implement.
> 
> As you note below, if using the advanced API, then specifying the source
> address on sending and learning the destination address on receiving is
> easier, and is almost as easy as writing a the relay's local address into a
> fixed place in the packet, but not quite.

This is kind of a strange thing.  If you need the functionality of the
advanced API, why not use the advanced API?

> I think the explicit specification of a relay-address is needed in cases
> where either the relay has no global address on the proper interface (and
> thus needs to indicate a prefix-only address, which should work just fine),
> or where specifying the source address may complicate the packet's route out
> of the relay (this is speculation).  If a relay must detect one of these
> conditions, then it complicates the relay, or encourages relay authors to
> opt for the safer solution and always use the option (in which case it isn't
> optional in a practical sense).

I think the DHCP server should be using the prefix that the relay
reports when doing address assignments, not the IP address that the
relay reports.   Maybe I'm missing something here - are we back to
overloading these two functions?

			       _MelloN_

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