RE: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header
Ralph Droms <rdroms@cisco.com> Thu, 30 August 2001 18:06 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 OAA23959; Thu, 30 Aug 2001 14:06:49 -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 OAA05745; Thu, 30 Aug 2001 14:05:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05722 for <dhcwg@ns.ietf.org>; Thu, 30 Aug 2001 14:05:52 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23774 for <dhcwg@ietf.org>; Thu, 30 Aug 2001 14:04:32 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA10607 for <dhcwg@ietf.org>; Thu, 30 Aug 2001 14:05:22 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010830135626.03920b88@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 30 Aug 2001 14:04:35 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header
In-Reply-To: <66F66129A77AD411B76200508B65AC697B34D3@eambunt705.ena-east .ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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
Bernie opined:
>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 3, we can either do a variable length length+prefix field or send
a prefix with 0's in the interface-id or just send an address
from the appropriate link and let the server deduce the
prefix (which is what we do in DHCPv4, right?). I've written up
the third alternative, which is as easy as any. I'll rewrite
it as soon as someone expresses a preference for one of the
other alternatives or comes up with a different plan.
- 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 An address with a prefix that is
assigned to the link from
which the client should be assigned
an address.
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. The relay
MUST include a "circuit-ID option" if
it needs to explicitly identify the
link on which the client message should
be forwarded to the client
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg