Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header
Ralph Droms <rdroms@cisco.com> Fri, 31 August 2001 15:41 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 LAA08092; Fri, 31 Aug 2001 11:41:22 -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 LAA15384; Fri, 31 Aug 2001 11:38:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15356 for <dhcwg@ns.ietf.org>; Fri, 31 Aug 2001 11:38:53 -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 LAA08037 for <dhcwg@ietf.org>; Fri, 31 Aug 2001 11:37:30 -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 LAA12980 for <dhcwg@ietf.org>; Fri, 31 Aug 2001 11:38:22 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010831113644.01ca7ef8@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 31 Aug 2001 11:38:19 -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: <200108302311.f7UNBlf00374@grosse.bisbee.fugue.com>
References: <Message from "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> <66F66129A77AD411B76200508B65AC697B34DE@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
Here's the final text on this issue (extracted from the revved draft): 9. Relay messages Relay agents exchange messages with servers to forward messages between clients and servers that are not connected to the same link. 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. 9.2. Relay-reply 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-REPL 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 "Server message option"; see section 18.8. 16. Relay Behavior For this discussion, the Relay may be configured to use a list of server destination addresses, which may include unicast addresses, the All DHCP Servers multicast address, or other multicast addresses selected by the network administrator. If the Relay has not been explicitly configured, it MUST use the All DHCP Servers multicast address as the default. 16.1. Relaying of client messages When a Relay receives a valid client message, it constructs a Relay-forward message. The relay places an address with a prefix assigned to the link on which the client should be assigned an address in the link-prefix field. This address will be used by the server to determine the link from which the client should be assigned an address and other configuration information. If the relay cannot use the address in the link-prefix field to identify the interface through which the response to the client will be forwarded, the relay MUST include a circuit-id option (see section TBD)in the Relay-forward message. The server will include the circuit-id option in its Relay-reply message. The relay copies the source address from the IP datagram in which the message was received from the client into the client-return-address field in the Relay-forward message. The relay constructs a "client-message" option 18.7 that contains the entire message from the client in the data field of the option. The relay places the "relay-message" option along with any "relay-specific" options in the options field of the Relay-forward message. The Relay then sends the Relay-forward message to the list of server destination addresses that it has been configured with. 16.2. Relaying of server messages When the relay receives a Relay-reply message, it extracts the server message from the "server-message" option. If the Relay-reply message includes a circuit-id option, the relay forwards the message from the server to the client on the link identified by the circuit-id option. Otherwise, the relay forwards the message on the link identified by the link-prefix option. In either case, the relay forwards the message to the address in the client-return-address field in the Relay-reply message. _______________________________________________ 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