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

Josh Littlefield <> Thu, 30 August 2001 20:06 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id QAA26813; Thu, 30 Aug 2001 16:06:03 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id QAA09449; Thu, 30 Aug 2001 16:05:20 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id QAA09426 for <>; Thu, 30 Aug 2001 16:05:18 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id QAA26771 for <>; Thu, 30 Aug 2001 16:03:57 -0400 (EDT)
Received: from ( []) by (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA28093; Thu, 30 Aug 2001 16:04:45 -0400 (EDT)
Message-ID: <>
Date: Thu, 30 Aug 2001 16:03:51 -0400
From: Josh Littlefield <>
Organization: Cisco Systems
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Bernie Volz (EUD)" <>
CC: 'Ralph Droms' <>,
Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header
References: <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>
Content-Transfer-Encoding: 7bit

> "Bernie Volz (EUD)" wrote:
> Yeah, in thinking some more about this, perhaps it is better that the
> relay
> doesn't know about prefix lengths (it doesn't really need to) - though it
> likely will anyway (because of Router Advertisements, etc).
> It also is one more thing that could get misconfigured in some way between
> the relay and server, so perhaps best to just let the server deal with it.

I agree.  I think having the relay include the prefix length is almost
over-specifying the subnet to the server.  The server had its configuration
of subnets, and the relay needs only to provide an address within a subnet. 
Then the address either maps to a subnet, or it doesn't.  But it won't run
the risk of mapping to more than one if the relay-communicated prefix length
is smaller than expected).

> Therefore, I would suggest it can either be the prefix (with 0's in the
> interface
> id) or just an address. Since the server knows the prefix lengths, it can
> find
> the appropriate "network" by doing the checks only against the
> prefix-length
> bits. Essentially, only the prefix bits are significant and the remaining
> bits
> are don't care. But, I have no major issue if we want to force it to be
> just
> the prefix (with 0's in the other bits).

This is what I was trying to get at before.  The relay-address can be a full
address, or a "prefix-only" address (0's in the other bits) and the server
shouldn't care one way or the other as long as it maps to a subnet and isn't
used to address packets.  I see no reason to force the relay-address to be
prefix-only, or to disallow it.

Josh Littlefield                                  Cisco Systems, Inc.                                      250 Apollo Drive
tel: 978-244-8378  fax: same               Chelmsford, MA  01824-3627

dhcwg mailing list