RE: [dhcwg] client unicast/client unicast option
"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Wed, 05 September 2001 14:55 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 KAA05939; Wed, 5 Sep 2001 10:55:15 -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 KAA11741; Wed, 5 Sep 2001 10:51:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11714 for <dhcwg@ns.ietf.org>; Wed, 5 Sep 2001 10:51:43 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05625 for <dhcwg@ietf.org>; Wed, 5 Sep 2001 10:50:16 -0400 (EDT)
Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f85EpC527782 for <dhcwg@ietf.org>; Wed, 5 Sep 2001 09:51:12 -0500 (CDT)
Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f85EpC321322 for <dhcwg@ietf.org>; Wed, 5 Sep 2001 09:51:12 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Sep 05 09:51:11 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <P4M9YTRX>; Wed, 5 Sep 2001 09:51:11 -0500
Message-ID: <66F66129A77AD411B76200508B65AC697B352F@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] client unicast/client unicast option
Date: Wed, 05 Sep 2001 09:51:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1361A.306C5460"
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
In general, looks fine to me. Don't know if it is worth adding a line into the Release/Decline text to specifically indicate that a client can obviously not use one of the addresses it is Releasing or Declining (that is obvious isn't it). The one other minor comment is whether a client *MUST* send unicast packets out the interface for which the client is obtaining configuration information? As long as the client's SOURCE address is set correctly to reflect the proper interface, there really is no problem in it sending the packet out whatever interface the routing table indicates, is there? In the multicast case (or if the SOURCE address is a link scoped address), it is important since the client must use its link local address (and that is only valid on that interface). I'm probably being too nit picky! - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, September 05, 2001 10:09 AM To: dhcwg@ietf.org Subject: [dhcwg] client unicast/client unicast option Here's the text that has been changed to allow for client unicast, controlled by the client unicast option. Please review and comment... - Ralph ===== 15.3.1. Creation and transmission of Request messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Request message to the server. Otherwise, the client sends the Request message to the All_DHCP_Agents multicast address. The client sends the Request message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 15.3.3. Creation and transmission of Renew messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Renew message to the server. Otherwise, the client sends the Renew message to the All_DHCP_Agents multicast address. The client sends the Renew message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 15.3.6. Creation and transmission of Release messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Release message to the server. Otherwise, the client sends the Release message to the All_DHCP_Agents multicast address. The client sends the Release message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 15.3.8. Creation and transmission of Decline messages If the client has a source address that can be used by the server as a return address and the client has received a Client Unicast option (section 19.12) from the server, the client SHOULD unicast the Decline message to the server. Otherwise, the client sends the Decline message to the All_DHCP_Agents multicast address. The client sends the Decline message through the interface for which the client is interested in obtaining configuration information, with the destination port set to 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. 19.12. Server unicast option This option is used by a server to send to a client to inform the client it can send a Request, Renew, Release, and Decline by unicasting directly to the server instead of the All_DHCPv6_Agents Multicast address as an optimization, when the client as an address of sufficient scope to reach the server. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_UNICAST | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_UNICAST (9) option-length 0 This option only applies to the server address that sends this to the client. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] client unicast/client unicast option Ralph Droms
- RE: [dhcwg] client unicast/client unicast option Bernie Volz (EUD)