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

Ted Lemon <> Thu, 30 August 2001 14:37 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id KAA18560; Thu, 30 Aug 2001 10:37:55 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id KAA29564; Thu, 30 Aug 2001 10:36:19 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id KAA29545 for <>; Thu, 30 Aug 2001 10:36:18 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id KAA18445 for <>; Thu, 30 Aug 2001 10:34:57 -0400 (EDT)
Received: from ( []) by (8.11.3/8.6.11) with ESMTP id f7UEUPf15495; Thu, 30 Aug 2001 07:30:25 -0700 (PDT)
Received: from (localhost []) by (8.11.3/8.6.11) with ESMTP id f7UEaEl00456; Thu, 30 Aug 2001 10:36:14 -0400 (EDT)
Message-Id: <>
To: Josh Littlefield <>
cc: "Bernie Volz (EUD)" <>, "'Ralph Droms'" <>,
Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header
In-Reply-To: Message from Josh Littlefield <> of "Wed, 29 Aug 2001 16:30:17 EDT." <>
Date: Thu, 30 Aug 2001 10:36:14 -0400
From: Ted Lemon <>
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

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


dhcwg mailing list