RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header

"Bernie Volz (EUD)" <> Thu, 30 August 2001 15:37 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id LAA19818; Thu, 30 Aug 2001 11:37:56 -0400 (EDT)
Received: from (localhost []) by (8.9.1a/8.9.1) with ESMTP id LAA01274; Thu, 30 Aug 2001 11:37:03 -0400 (EDT)
Received: from (odin []) by (8.9.1a/8.9.1) with ESMTP id LAA01202 for <>; Thu, 30 Aug 2001 11:36:59 -0400 (EDT)
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id LAA19749 for <>; Thu, 30 Aug 2001 11:35:39 -0400 (EDT)
Received: from ( []) by (8.11.3/8.11.3) with ESMTP id f7UFb0p15979 for <>; Thu, 30 Aug 2001 10:37:01 -0500 (CDT)
Received: from eamrcnt749 ( []) by (8.11.3/8.11.3) with SMTP id f7UFb0O22372 for <>; Thu, 30 Aug 2001 10:37:00 -0500 (CDT)
Received: FROM BY eamrcnt749 ; Thu Aug 30 10:37:00 2001 -0500
Received: by with Internet Mail Service (5.5.2653.19) id <P4M9Q6A1>; Thu, 30 Aug 2001 10:37:00 -0500
Message-ID: <>
From: "Bernie Volz (EUD)" <>
To: 'Ralph Droms' <>,
Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header
Date: Thu, 30 Aug 2001 10:36:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13169.9A6B60A0"
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <>

Just to be clear, there are three pieces of information:

1. The address used to communicate with the relay.
2. The link on which the client's packet was received.
3. The prefix to be used for address assignment for the client.

I think 1 is easy and it should just be the IPv6 source address of the Relay-Forw.

In many cases 2 and 3 are the same but they need not be. I would suggest we solve
this by doing the following:

For 3, the relay should send a prefix and prefix-length.

For 2, the relay can either use 3 or provide some other means of identifying this
information. It may not be an address - it could just be an interface id or some
other opaque info. So, I suggest that for 2, we simply have an "Interface-ID" option
which is whatever the relay wants it to be. The server should treat it as opaque
and simply echo it back to the relay. If the relay doesn't need it (because the
info in (3) is sufficient), it need not provide this option.

Relay-Interface-ID Option:

	2-byte option id
	2-byte option length
	data - interface ID - whatever the relay wants

For example, a relay could simply send 1 byte of data which is the interface number.
Or, it could send 16 bytes to represent an address of the interface.

- Bernie

-----Original Message-----
From: Ralph Droms []
Sent: Thursday, August 30, 2001 10:58 AM
Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from
the DHCPv6 header 

At 10:36 AM 8/30/2001 -0400, Ted Lemon wrote:
>> 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_

Suppose the field name and definition are changed as in the figure below,

* The server chooses an address for the client
  based on the link-prefix (details TBD; could
  use 0s to indicate prefix length or include
  explicit prefix length or ???)
* The server sends the Relay-reply message to 
  the source address in the IP header of the
  Relay-forward message
* The relay forwards the Reply message to the
  client on the link identified by the

This proposal still overloads the identification of the link
on which the relay forward the Reply to the client with the
selection of an address for the client by the server.  We
could either add a separate field for specifying a prefix
for address selection or define an option (like the DHCPv4
subnet selection option).  I would be inclined to define
an option that might be used by either a client or a
relay (or both?). 

- Ralph

9.1. Relay-forward message

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     |    msg-type   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                          link-prefix                          |
     |                                                               |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                     client-return-address                     |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     .                                                               .
     .            options (variable number and length)   ....        .
     |                                                               |

      msg-type                    RELAY-FORW

      link-prefix                 A prefix assigned to the link from
                                  which the client message was received.

      client-return-address       The source address from the IP
                                  datagram in which the message from the
                                  client was received by the relay agent

      options                     MUST include a "Client message
                                  option"; see section 18.7.

dhcwg mailing list