RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header
"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Thu, 30 August 2001 15: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 LAA19818; Thu, 30 Aug 2001 11:37:56 -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 LAA01274; Thu, 30 Aug 2001 11:37:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01202 for <dhcwg@ns.ietf.org>; Thu, 30 Aug 2001 11:36:59 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19749 for <dhcwg@ietf.org>; Thu, 30 Aug 2001 11:35:39 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7UFb0p15979 for <dhcwg@ietf.org>; Thu, 30 Aug 2001 10:37:01 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7UFb0O22372 for <dhcwg@ietf.org>; Thu, 30 Aug 2001 10:37:00 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Aug 30 10:37:00 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <P4M9Q6A1>; Thu, 30 Aug 2001 10:37:00 -0500
Message-ID: <66F66129A77AD411B76200508B65AC697B34D3@eambunt705.ena-east.ericsson.se>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: 'Ralph Droms' <rdroms@cisco.com>, dhcwg@ietf.org
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"
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
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 [mailto:rdroms@cisco.com] Sent: Thursday, August 30, 2001 10:58 AM To: dhcwg@ietf.org 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, and: * 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 link-prefix 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 dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Josh Littlefield
- RE: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- RE: [dhcwg] Changes to remove "client-link-local-… Bernie Volz (EUD)
- Re: [dhcwg] Changes to remove "client-link-local-… Josh Littlefield
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- Re: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- Re: [dhcwg] client unicast/client unicast option Ted Lemon
- Re: [dhcwg] Incorporation of WG last call comment… Ted Lemon
- Re: [dhcwg] Assigning DHCPv6 option codes Thomas Narten
- Re: FW: [dhcwg] co-existence of temp and normal a… Thomas Narten
- Re: FW: [dhcwg] co-existence of temp and normal a… Thomas Narten
- Re: [dhcwg] dhcpv6-24: Rapid Commit Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- Re: [dhcwg] dhcpv6-24: Interface-ID option Thomas Narten
- Re: [dhcwg] dhcpv6-24: Temporary addresses Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Ted Lemon
- Re: [dhcwg] DHCP Option for CableLabs Client Conf… Thomas Narten
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Thomas Narten
- Re: [dhcwg] Conflicting information regarding DHC… Thomas Narten
- Re: [dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay… Thomas Narten