From daemon@optimus.ietf.org Fri Mar 1 07:08:08 2002 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 HAA15474 for ; Fri, 1 Mar 2002 07:08:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA22415 for dhcwg-archive@odin.ietf.org; Fri, 1 Mar 2002 07:08:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17663; Fri, 1 Mar 2002 07:02:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17574 for ; Fri, 1 Mar 2002 07:02:47 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12937; Fri, 1 Mar 2002 07:02:43 -0500 (EST) Message-Id: <200203011202.HAA12937@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Mar 2002 07:02:42 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-dstm-ports-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DSTM Ports Option for DHCPv6 Author(s) : M. Shin, Y. Kim Filename : draft-ietf-dhc-dhcpv6-opt-dstm-ports-00.txt Pages : 4 Date : 28-Feb-02 The DSTM Ports Option provide DSTM (Dual Stack Transition Mechanism) configuration information to DHCPv6 hosts A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dstm-ports-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-dstm-ports-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dstm-ports-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228134345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dstm-ports-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-dstm-ports-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228134345.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Mar 1 07:08:17 2002 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 HAA15619 for ; Fri, 1 Mar 2002 07:08:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA22649 for dhcwg-archive@odin.ietf.org; Fri, 1 Mar 2002 07:08:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17968; Fri, 1 Mar 2002 07:03:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17862 for ; Fri, 1 Mar 2002 07:03:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13007; Fri, 1 Mar 2002 07:02:58 -0500 (EST) Message-Id: <200203011202.HAA13007@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Mar 2002 07:02:58 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-timeconfig-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Time Configuration Options for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-timeconfig-00.txt Pages : 6 Date : 28-Feb-02 This document describes the options for Time related configuration information in DHCPv6: NTP Servers and IEEE 1003.1 POSIX Timezone specifier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-timeconfig-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228134426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-timeconfig-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228134426.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Mar 1 07:08:27 2002 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 HAA15797 for ; Fri, 1 Mar 2002 07:08:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA22665 for dhcwg-archive@odin.ietf.org; Fri, 1 Mar 2002 07:08:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17806; Fri, 1 Mar 2002 07:03:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17761 for ; Fri, 1 Mar 2002 07:02:57 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12981; Fri, 1 Mar 2002 07:02:53 -0500 (EST) Message-Id: <200203011202.HAA12981@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Mar 2002 07:02:53 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-nisconfig-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : NIS Configuration Options for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-nisconfig-00.txt Pages : 6 Date : 28-Feb-02 This document describes four options for NIS-related configuration information in DHCPv6: NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-nisconfig-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228134413.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-nisconfig-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228134413.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Mar 1 07:08:32 2002 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 HAA15857 for ; Fri, 1 Mar 2002 07:08:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA22679 for dhcwg-archive@odin.ietf.org; Fri, 1 Mar 2002 07:08:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17732; Fri, 1 Mar 2002 07:02:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17665 for ; Fri, 1 Mar 2002 07:02:52 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12956; Fri, 1 Mar 2002 07:02:48 -0500 (EST) Message-Id: <200203011202.HAA12956@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Mar 2002 07:02:47 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-loadb-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Load Balancing for DHCPv6 Author(s) : B. Volz Filename : draft-ietf-dhc-dhcpv6-loadb-00.txt Pages : 5 Date : 28-Feb-02 This document specifies a load balancing algorithm for use with DHCPv6. Load balancing enables multiple cooperating DHCPv6 servers to decide which one should service a client, without exchanging any information beyond initial configuration. It expands on RFC 3074 'DHC Load Balancing Algorithm' to include DHCPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-loadb-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-loadb-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-loadb-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228134401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-loadb-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-loadb-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228134401.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Mar 1 07:10:35 2002 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 HAA15960 for ; Fri, 1 Mar 2002 07:10:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA22811 for dhcwg-archive@odin.ietf.org; Fri, 1 Mar 2002 07:10:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17539; Fri, 1 Mar 2002 07:02:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17441 for ; Fri, 1 Mar 2002 07:02:42 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12919; Fri, 1 Mar 2002 07:02:38 -0500 (EST) Message-Id: <200203011202.HAA12919@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Mar 2002 07:02:38 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-host-option-considerations-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Considerations for the use of the Host Name option Author(s) : C. Smith, T. Lemon Filename : draft-ietf-dhc-host-option-considerations-00.txt Pages : 7 Date : 28-Feb-02 This document clarifies the use of the DHCP Host Name option. The primary point of this clarification addresses the use of the option by clients to request proxy DNS updates by DHCP servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-host-option-considerations-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-host-option-considerations-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-host-option-considerations-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020228134330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-host-option-considerations-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-host-option-considerations-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228134330.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Fri Mar 1 18:41:55 2002 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 SAA06484 for ; Fri, 1 Mar 2002 18:41:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA08124 for dhcwg-archive@odin.ietf.org; Fri, 1 Mar 2002 18:41:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08023; Fri, 1 Mar 2002 18:39:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07960 for ; Fri, 1 Mar 2002 18:39:51 -0500 (EST) Received: from mail.netisp.com (netisp.com [66.54.206.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06365 for ; Fri, 1 Mar 2002 18:39:48 -0500 (EST) Received: from STEALTH1 ([66.54.206.238]) by mail.netisp.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 14:00:25 -0600 Reply-To: "InfrastructureWorld" Date: Fri, 1 Mar 2002 14:00:25 -0600 From: "InfrastructureWorld" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C1C11F.00CA00F0" Message-ID: <159fc01c1c15b$ba097050$eece3642@netisp.com> X-Mailer: Microsoft CDO for Windows 2000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Class: urn:content-classes:message Thread-Index: AcHBUUr9OlPdv42kRkW+KAp3FYvTSw== X-OriginalArrivalTime: 01 Mar 2002 20:00:25.0545 (UTC) FILETIME=[BA55BB90:01C1C15B] Subject: [dhcwg] Essential Global Infrastructure Information and News Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C1C11F.00CA00F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Receive the NEW iwKnowledge - essential information, tools, and news for = today's competitive infrastructure environment. iwKnowledge from InfrastructureWorld is the leading, authoritative = source for global infrastructure information. iwKnowledge is now = directly available to individuals and organizations and offers four = types of key information to help you identify opportunities, assess = competition, and manage operations. These include: -a comprehensive database of 100,000 global infrastructure agencies, = companies, and organizations, country profiles, industry surveys=20 -a searchable Project Alerts and Tenders database of over 9,000 current = projects=20 -a real-time news feed from over 5,000 sources=20 -a powerful search tool which allows direct-targeted access to millions = of additional global infrastructure webpages/sites=20 iwKnowledge is available on a subscription basis for individuals, = corporations, governments, and agencies. Please accept our invitation to = register for a Free 15-day, no obligation, subscription to iwKnowledge. = Put today's essential information at your fingertips. Subscribe by = clicking on the link below: http://www.iwknowledge.com/iwknowledge/register.asp iwKnowledge creates visibility for thousands of global infrastructure = organizations. We invite you to visit iwKnowledge today to confirm, edit = or add your Free entry in our database to better reflect the services = you offer. Confirm your listing by clicking on the link below: http://www.iwknowledge.com/help/iwk_Feedback.asp InfrastructureWorld, Inc. also provides transaction facilitation, = life-cycle project management tools, and deal structuring assistance = through a combination of the Internet and other technology solutions, = along with advisory services for businesses and governments involved in = infrastructure projects around the world. Receive additional information = on these services by clicking on the link below: http://www.infrastructure.com/corporate/contact/default.asp=20 InfrastructureWorld, Inc. services include access to conferences, = technical papers, best practices guides and the additional required = information to conduct your business, whether you are developing a = project, evaluating the risk and rewards for investment decisions, = running a company or government agency, or managing the relief aid = program in an emerging country. Contact Info: Customer Service 400 Oyster Point Blvd, Suite 410 South San Francisco, CA 94080 tel 650.624.0600 fax 650.624.7808 customerservice@infrastructure.com InfrastructureWorld: saving time, reducing costs, enhancing deal flow=20 www.infrastructure.com 800-430-8042 or +1(650)-827-8802 (outside the U.S.) San Francisco - Houston - London - Tokyo - Hong Kong - Chenai, India To be removed from future mailings, please visit http://www.XStreamEmail.com/bin/optout.asp?p=3D122&l=3D141&e=3Ddhcwg@ietf= .org ------=_NextPart_000_0001_01C1C11F.00CA00F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Untitled Document
=20 =20 =20 =20
=20

iwKnowledge=20 from InfrastructureWorld is the leading, authoritative = source for=20 global infrastructure information. iwKnowledge is now = directly available=20 to individuals and organizations and offers four types of = key information=20 to help you identify opportunities, assess competition, = and manage=20 operations.
=20

These=20 include:

  • =20 a comprehensive database of 100,000 global = infrastructure agencies,=20 companies, and organizations, country profiles, industry = surveys
    • =20
  • =20 a searchable Project Alerts and Tenders database of over = 9,000=20 current projects
    • =20
  • =20 a real-time news feed from over 5,000 = sources
    • =20
  • =20 a powerful search tool which allows direct-targeted = access to=20 millions of additional global infrastructure = webpages/sites

iwKnowledge=20 is available on a subscription basis for individuals, = corporations,=20 governments, and agencies. Please accept=20 our invitation to register for a Free 15-day, no = obligation, subscription=20 to iwKnowledge. Put today's essential = information at=20 your fingertips. Subscribe=20 Here

iwKnowledge=20 creates visibility for thousands of global infrastructure = organizations.=20 We invite you to visit iwKnowledge=20 today to confirm, edit or add your Free entry in our = database to better=20 reflect the services you offer, Confirm=20 Your Listing Here

InfrastructureWorld,=20 Inc. also provides transaction facilitation, life-cycle=20 project management tools, and deal structuring assistance = through a combination of the Internet and other =20 technology solutions, along with advisory services for = businesses and governments involved in infrastructure = =20 projects around the world. Rece= ive=20 additional information on these services.

InfrastructureWorld,=20 Inc. services include access to conferences, technical = papers, best=20 practices guides and the additional required information = to conduct=20 your business, whether you are developing a project, = evaluating=20 the risk and rewards for investment decisions, running a = company=20 or government agency, or managing the relief aid program = in an emerging=20 country.

Contact=20 Info:
InfrastructureWorld: iwKnowledge Division
400 Oyster Point Blvd, Suite 410
South San Francisco, CA 94080
tel 800.430.8042; outside U.S. +1.650.827-8802
fax 650.624.7808
customerservice@infras= tructure.com

InfrastructureWorld:=20 saving time, reducing costs, enhancing=20 deal flow

www.infrastructure.com<= /b>


www.infrastructure.com

=20 800-430-8042=20 or +1(650)-827-8802 (outside the U.S.)
San Francisco Houston London=20 Tokyo Hong Kong Chenai,=20 India


www.infrastructure.com

=20

=20 3D"Visit

 

To be removed from future mailings, = please click here. ------=_NextPart_000_0001_01C1C11F.00CA00F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Mon Mar 4 15:47:54 2002 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 PAA21954 for ; Mon, 4 Mar 2002 15:47:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00212 for dhcwg-archive@odin.ietf.org; Mon, 4 Mar 2002 15:47:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00025; Mon, 4 Mar 2002 15:44:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29483 for ; Mon, 4 Mar 2002 15:31:58 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20448 for ; Mon, 4 Mar 2002 15:31:54 -0500 (EST) Received: from prattle.redback.com (hiddenuser@prattle.redback.com [155.53.12.9]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g24KVr206719 for ; Mon, 4 Mar 2002 15:31:53 -0500 (EST) Received: from wan-pppoe-1.lab.redback.com (wan-pppoe-1.lab.redback.com [10.13.48.37]) by prattle.redback.com (Postfix) with ESMTP id 9B11A262815 for ; Mon, 4 Mar 2002 12:31:51 -0800 (PST) From: Greg Kilfoyle To: dhcp-v4@bucknell.edu Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 04 Mar 2002 12:22:04 -0800 Message-Id: <1015273324.19876.61.camel@wan-pppoe-1.lab.redback.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Minimum length for inbound DHCP packets Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, For a DHCP server or relay agent, I was wondering what is a reasonable minimum length to check for on inbound packets. This is for DHCP support only, no BOOTP support. I was thinking an initial check should use the BOOTP minimum length and check for a DHCP packet length of 300 bytes (which makes 328 bytes including normal IP and UDP headers). Using a test tool to test the DHCP server implementation showed that the test tool was sending DHCP packets of less than 300 bytes (and the above check was failing). On one hand this is a problem with the test tool; on the other hand, how many clients out there do not send the minimum BOOTP length? In other words, if I don't allow less then the BOOTP minimum length, how many clients will not work correctly? Maybe a more forgiving approach would be a length that includes the magic cookie and at least one option (an end option being 1 byte). Any thoughts welcome. Thanks, Greg. -- Greg Kilfoyle (gregk@redback.com) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Mon Mar 4 16:39:56 2002 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 PAA21960 for ; Mon, 4 Mar 2002 15:47:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA00228 for dhcwg-archive@odin.ietf.org; Mon, 4 Mar 2002 15:47:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00045; Mon, 4 Mar 2002 15:44:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14273 for ; Mon, 4 Mar 2002 04:19:23 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17765 for ; Mon, 4 Mar 2002 04:19:19 -0500 (EST) Received: from oyensvaneeghen.nl (dmx.oyensvanheeghen.nl [213.201.171.187] (may be forged)) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g249JL231383 for ; Mon, 4 Mar 2002 04:19:22 -0500 (EST) Received: from HPreserve001 (oyensdgw.wox.org [213.201.171.186]) by oyensvaneeghen.nl (Postfix) with SMTP id 0923D6E704 for ; Mon, 4 Mar 2002 10:18:36 +0100 (CET) From: "Alwis Anil" To: Date: Mon, 4 Mar 2002 10:18:58 +0100 Message-ID: <000201c1c35d$a9c724e0$bb6ea8c0@Ads.Singel.Imc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [dhcwg] dhcp question... Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, I was wondering if you can help me. I would like to know, in a network, which computers are dependant on a specific IP address that it got through DHCP and should not be changed. Is there a file that lists specific computers that have been assigned rules (eg: connecting to another network) that will disappear if a new ip is specified? regards, Alwis Anil IT Support email: alwis@oyensvaneeghen.nl tel: +31 20 514 1 611 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 02:44:50 2002 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 CAA20196 for ; Tue, 5 Mar 2002 02:44:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA14645 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 02:44:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14484; Tue, 5 Mar 2002 02:39:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14445 for ; Tue, 5 Mar 2002 02:39:51 -0500 (EST) Received: from cichlid.adsl.duke.edu (user131-237.conference.apricot.net [169.223.131.237]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20087 for ; Tue, 5 Mar 2002 02:39:48 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g257akm02046; Tue, 5 Mar 2002 02:36:46 -0500 Message-Id: <200203050736.g257akm02046@cichlid.adsl.duke.edu> To: Ralph Droms , jschnizl@cisco.com cc: dhcwg@ietf.org Date: Tue, 05 Mar 2002 02:36:45 -0500 From: Thomas Narten Subject: [dhcwg] draft-ietf-dhc-agentopt-radius-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I'd like to better understand the need for this document and what problem it solves. The model here seems to be: 1) client authenticates itself with access device using 802.1X L2 signalling. 2) access device happens to also be a DHCP relay agent (required). 3) as part of 802.1x, access device talks to radius server, gets back some radius AVPs. It caches those AVPs. 4) when client sends DHCP packets, relay agent appends the radius AVPs to the DHCP message via an agent options sub-option. 5) DHC server then uses the radius AVPs to figure out which address to give out. What I'd like to understand better: 1) is this used to (say) assign an address from the correct VLAN? If so, can't this be done without using the radius AVPs? I.e., say with a generic agent options sub-options that identifies the vlan 2) Seems like it might be dangerous to cache the radius stuff and then later (how much later? hours?) include it in messages to the DHC server. How does the server know the information is accurate or relevant? Moreover, should the DHC server trust those radius AVPs without itself checking with the radius server? I would think not, in which case what is the benefit of even including that info in the DHCP messages, when the DHC server can presumably just get the info directly from the radius server itself? 3) Seems like a more general (and less radius specific) approach would be for the relay agent to include the information that the client provided, and then let the DHC server query the radius server itself (just like the access device does). Or, in fact, maybe it will query a diameter server. Why wire the RADIUS stuff into the DHCP protocol? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 07:52:03 2002 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 HAA26774 for ; Tue, 5 Mar 2002 07:52:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA00683 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 07:52:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00474; Tue, 5 Mar 2002 07:49:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00452 for ; Tue, 5 Mar 2002 07:49:35 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26653 for ; Tue, 5 Mar 2002 07:49:31 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA06219; Tue, 5 Mar 2002 07:49:01 -0500 (EST) Message-Id: <4.3.2.7.2.20020305073206.01905f60@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Mar 2002 07:48:59 -0500 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-agentopt-radius-00.txt Cc: jschnizl@cisco.com, dhcwg@ietf.org In-Reply-To: <200203050736.g257akm02046@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thomas, Your summary of the model is basically correct. In step 5, selecting an address is only one possible way in which the DHCP server might use the RADIUS AVPs. Other comments in line... - Ralph At 02:36 AM 3/5/2002 -0500, Thomas Narten wrote: >I'd like to better understand the need for this document and what >problem it solves. > >The model here seems to be: > >1) client authenticates itself with access device using 802.1X L2 > signalling. > >2) access device happens to also be a DHCP relay agent (required). > >3) as part of 802.1x, access device talks to radius server, gets back > some radius AVPs. It caches those AVPs. > >4) when client sends DHCP packets, relay agent appends the radius AVPs > to the DHCP message via an agent options sub-option. > >5) DHC server then uses the radius AVPs to figure out which address to > give out. > >What I'd like to understand better: > >1) is this used to (say) assign an address from the correct VLAN? If > so, can't this be done without using the radius AVPs? I.e., say > with a generic agent options sub-options that identifies the vlan The RADIUS server has specific information about the entity requesting the IP configuration, and authenticates the identity of the requester. This option obviates the need for pre-loading that information in the access device and leverages the RADIUS authentication. >2) Seems like it might be dangerous to cache the radius stuff and then > later (how much later? hours?) include it in messages to the DHC > server. How does the server know the information is accurate or > relevant? Dangerous in what way? Presumably the access device uses 802.1X to know reliably the identity of the device at the other end of the wire attached to the port through which the DHCP messages are subsequently received. The DHCP server can then assume that the AVPs have been associated with the correct DHCP messages. How would the information become inaccurate or irrelevant? > Moreover, should the DHC server trust those radius AVPs > without itself checking with the radius server? I would think not, > in which case what is the benefit of even including that info in > the DHCP messages, when the DHC server can presumably just get the > info directly from the radius server itself? The access device, RADIUS server and DHCP server are all presumed to be part of the same administrative domain, so that the DHCP server has a trust chain through the access device back to the RADIUS server. Additionally, the AVPs are signed by the RADIUS server so that the DHCP server can confirm their authenticity. The DHCP server cannot check directly with the RADIUS server because the DHCP server does not have the authentication credentials from the requesting device that were presented during 802.1X authentication. >3) Seems like a more general (and less radius specific) approach would > be for the relay agent to include the information that the client > provided, and then let the DHC server query the radius server > itself (just like the access device does). Or, in fact, maybe it > will query a diameter server. Why wire the RADIUS stuff into the > DHCP protocol? Are you suggesting that the access device pass along the 802.1X authentication stuff (identity & credentials) to the DHCP server? How is caching that information for subsequent inclusion in a DHCP message any different from caching the RADIUS AVPs? Requiring the DHCP server to query the RADIUS server would impose a performance constraint and require that the DHCP server and the access device be configured to use the same RADIUS service. Our original proposal (presented in SLC) was not RADIUS-specific. The WG asked for specificity, so we revised the spec to focus on RADIUS. >Thomas > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 07:52:57 2002 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 HAA26798 for ; Tue, 5 Mar 2002 07:52:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA00714 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 07:52:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00578; Tue, 5 Mar 2002 07:51:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00557 for ; Tue, 5 Mar 2002 07:51:20 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26701 for ; Tue, 5 Mar 2002 07:51:18 -0500 (EST) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn1-18.cisco.com [10.82.224.18]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA19570; Tue, 5 Mar 2002 04:50:47 -0800 (PST) Message-Id: <4.3.2.7.2.20020305071458.01ed6cc8@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Mar 2002 07:50:13 -0500 To: Thomas Narten From: John Schnizlein Subject: Re: [dhcwg] draft-ietf-dhc-agentopt-radius-00.txt Cc: Ralph Droms , dhcwg@ietf.org In-Reply-To: <200203050736.g257akm02046@cichlid.adsl.duke.edu> 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: X-BeenThere: dhcwg@ietf.org At 02:36 AM 3/5/2002, Thomas Narten wrote: >I'd like to better understand the need for this document and what >problem it solves. This draft specifies the particular use of the already accepted relay agent information option to convey the user's identity from a RADIUS authentication (as used with 802.1X) to the DHC server. This enables the DHC server to allocate parameters, including addresses, based on the user's identity without requiring an additional (repetitive) demand for credentials from the user. >The model here seems to be: Correct summary deleted. >What I'd like to understand better: > >1) is this used to (say) assign an address from the correct VLAN? If > so, can't this be done without using the radius AVPs? I.e., say > with a generic agent options sub-options that identifies the vlan This option is not necessary for selecting the VLAN. An 802.1X authenticator can get a VLAN ID as a AVP from the (RADIUS) AAA and put the port in that VLAN. The DCH server would learn the subnet from which to assign an address through the GIADDR field. If different address pools within the VLAN were to be used for different users, the radius agentopt could provide the additional information about the user's identity. >2) Seems like it might be dangerous to cache the radius stuff and then > later (how much later? hours?) include it in messages to the DHC > server. Could you identify a specific danger due to the 802.1X switch holding the identity of the user associated with the port, please? > How does the server know the information is accurate or relevant? The DHC server is assumed to trust the administration of the switch and the RADIUS server. The only way for the information to get associated with the port is a valid user authentication because it is sent by the AAA (RADIUS) server with an Accept message. The switch and RADIUS server are all part of the trusted network infrastructure, not necessarily the host. We anticipate further discussion of the security considerations in Minneapolis because forgery and replay of the identity in the option may not be blocked in sufficient depth. Perimeter protection may be insufficient. > Moreover, should the DHC server trust those radius AVPs > without itself checking with the radius server? I would think not, > in which case what is the benefit of even including that info in > the DHCP messages, when the DHC server can presumably just get the > info directly from the radius server itself? In most cases the host's next requirement, after enabling forwarding through the switch port, is an IP address to enable communication beyond the local (layer-2) link. Why add another AAA transaction by the DHC server when the user's identity has just been authenticated at the same access point for 802.1X? In order to check with the RADIUS server, the DHC server would need to provide user's credentials. But since the user in not actually involved in this check, any use of the user's credentials would be a replay, which some authentication methods (e.g. one-time passwords) effectively prevent. >3) Seems like a more general (and less radius specific) approach would > be for the relay agent to include the information that the client > provided, and then let the DHC server query the radius server > itself (just like the access device does). Or, in fact, maybe it > will query a diameter server. Why wire the RADIUS stuff into the > DHCP protocol? As answered above, the DHC server should not (cannot where one-time passwords are used) replay the user authentication. The DCHP traffic cannot pass the 802.1X switch until the original authentication is done. If the 802.1X switch is configured to use Diameter authentication, it would need an agentopt very similar to this one for that method. Since we have the Congdon et. al draft specifying RADIUS back-end authentication, we specified that. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 08:43:46 2002 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 IAA28948 for ; Tue, 5 Mar 2002 08:43:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA03891 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 08:43:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03774; Tue, 5 Mar 2002 08:41:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03745 for ; Tue, 5 Mar 2002 08:41:42 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28904 for ; Tue, 5 Mar 2002 08:41:41 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA08216; Tue, 5 Mar 2002 08:41:08 -0500 (EST) Message-Id: <4.3.2.7.2.20020305082927.00b6c0d8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Mar 2002 08:33:18 -0500 To: "Burcak Beser" From: Ralph Droms Subject: Re: [dhcwg] DHCP_DECLINE question Cc: In-Reply-To: <4.3.2.7.2.20020228121913.02444df0@goblet.cisco.com> References: <5B671CEC7A3CDA40BA4A8B081D7B046CFD7824@antiproton.jnpr.net > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I agree with Kim and Ted - DHCPDECLINE is defined in RFC2131 to be used in the case of an address conflict, and many DHCP servers will mark the address in a DHCPDECLINE so that it is not offered again in the future. If the client decides that the address or other parameters in a DHCPACK are not acceptable, the client should respond with a DHCPRELEASE and then restart the address assignment process with a DHCPDISCOVER. - Ralph At 12:26 PM 2/28/2002 -0500, Kim Kinnear wrote: >At 06:04 PM 2/27/2002, Burcak Beser wrote: > >I have a question regarding the use of DHCP_DECLINE message. If the > client is choosing a valid DHCP_OFFER using contents of the returned > options, and the DHCP SERVER changes the contents of the options while > sending the DHCP_ACK message, is it acceptable for client to use > DHCP_DECLINE? (The RFC 2131 states that DHCP_DECLINE is issued when the > IP address in use.) > > No, it is not. See below. > > > >In other words when a DHCP_DECLINE is received by the DHCP SERVER does > this mean that the client detected that the IP address is already used by > another entity? > > Yes, and the implication (as well as the explicit > direction) is that the DHCP server should not offer this > IP address to this client or any other client for at > least some time since it has been shown to be "unusable" > for DHCP client allocation (because some client (or > machine, maybe not a DHCP client) appears to be using it). > > From RFC2131.txt: > >4.3.3 DHCPDECLINE message > > If the server receives a DHCPDECLINE message, the client has > discovered through some other means that the suggested network > address is already in use. The server MUST mark the network address > as not available and SHOULD notify the local system administrator of > a possible configuration problem. > > > If you don't like the IP address, you could use a > DHCPRELEASE to give it back. Of course, you may in that > case be offered it next time, but you don't need to take > the offer. > > If you just want to give it back, use DHCPRELEASE. > > If you want to give it back and be offered a different IP > address from this server, that's a harder question, since > the DHCPDECLINE implies that the address isn't usable. > > Cheers -- Kim > > > > > > >-burcak > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 09:19:46 2002 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 JAA00996 for ; Tue, 5 Mar 2002 09:19:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA06353 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 09:19:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06190; Tue, 5 Mar 2002 09:16:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06171 for ; Tue, 5 Mar 2002 09:16:30 -0500 (EST) Received: from fatboy.rainville.net (IDENT:root@fatboy.rainville.net [216.174.196.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00799 for ; Tue, 5 Mar 2002 09:16:28 -0500 (EST) Received: from mushroom ([192.168.0.41]) by fatboy.rainville.net (8.11.0/8.8.7) with ESMTP id g25FMTh07319 for ; Tue, 5 Mar 2002 07:22:29 -0800 From: "Jim Rainville" To: Date: Tue, 5 Mar 2002 06:01:51 -0800 Message-ID: <000501c1c44e$5e125f00$2900a8c0@mushroom> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C1C40B.4FEF1F00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [dhcwg] DHCP over ATM Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C1C40B.4FEF1F00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi - I know DHCP was designed to work over a broadcast media but I need to do dynamic IP allocation over an ATM network. I have bought an off the shelf DHCP implementation that does not support this but the modifications should be fairly straight forward. My plan is to use a predefined vpi/vci for an end device to send its DHCP request. The DHCP server will know this is a DHCP request because of the vpi/vci it came in on. The server will also know how to route it back to the end device because it will know which physical interface it came in on. My question is this: Is there a standards defined vpi/vci to do this? Right now my company is making the end device as well as the server but we may have to work with third party vendors in the future so a standard vpi/vci would be nice. Thanks. Jim ------=_NextPart_000_0006_01C1C40B.4FEF1F00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi –

 

I know DHCP was designed to work over a broadcast = media but I need to do dynamic IP allocation over an ATM network. I have bought an = off the shelf DHCP implementation that does not support this but the = modifications should be fairly straight forward. My plan is to use a predefined vpi/vci for an end device to send its DHCP = request. The DHCP server will know this is a DHCP request because of the vpi/vci it came in on. The server will also know how to route it back to the end = device because it will know which physical interface it came in on. My question = is this: Is there a standards defined vpi/vci = to do this? Right now my company is making the end device as well as the = server but we may have to work with third party vendors in the future so a standard = vpi/vci would be = nice.

 

Thanks.

Jim

 

------=_NextPart_000_0006_01C1C40B.4FEF1F00-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 09:45:34 2002 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 JAA02288 for ; Tue, 5 Mar 2002 09:45:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA07920 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 09:45:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07739; Tue, 5 Mar 2002 09:41:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07711 for ; Tue, 5 Mar 2002 09:41:12 -0500 (EST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01940 for ; Tue, 5 Mar 2002 09:41:09 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA00644; Tue, 5 Mar 2002 15:41:01 +0100 (MET) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA14747; Tue, 5 Mar 2002 15:40:53 +0100 (MET) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 15:41:11 +0100 Message-ID: From: Brandner Rudolf To: "'Jim Rainville'" Cc: dhcwg@ietf.org Subject: AW: [dhcwg] DHCP over ATM Date: Tue, 5 Mar 2002 15:41:04 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA07712 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hi Jim, there are standards based ways of doing multicasting over NBMAs and ATM in particular. Following some RFCs dealing with this issue to begin with: 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks. G. Armitage. November 1996. (Format: TXT=189219 bytes) (Status: PROPOSED STANDARD) 2121 Issues affecting MARS Cluster Size. G. Armitage. March 1997. (Format: TXT=26781 bytes) (Status: INFORMATIONAL) 2149 Multicast Server Architectures for MARS-based ATM multicasting. R. Talpade, M. Ammar. May 1997. (Format: TXT=42007 bytes) (Status: INFORMATIONAL) 2269 Using the MARS Model in non-ATM NBMA Networks. G. Armitage. January 1998. (Format: TXT=12094 bytes) (Status: INFORMATIONAL) 2443 A Distributed MARS Service Using SCSP. J. Luciani, A. Gallo. November 1998. (Format: TXT=41451 bytes) (Status: EXPERIMENTAL) 2602 ILMI-Based Server Discovery for MARS. M. Davison. June 1999. (Format: TXT=12031 bytes) (Status: PROPOSED STANDARD) But as always, this might not what you have asked for.... Rudi -----Urspr�ngliche Nachricht----- Von: Jim Rainville [mailto:jim@fatboy.rainville.net] Gesendet: Dienstag, 5. M�rz 2002 15:02 An: dhcwg@ietf.org Betreff: [dhcwg] DHCP over ATM Hi - I know DHCP was designed to work over a broadcast media but I need to do dynamic IP allocation over an ATM network. I have bought an off the shelf DHCP implementation that does not support this but the modifications should be fairly straight forward. My plan is to use a predefined vpi/vci for an end device to send its DHCP request. The DHCP server will know this is a DHCP request because of the vpi/vci it came in on. The server will also know how to route it back to the end device because it will know which physical interface it came in on. My question is this: Is there a standards defined vpi/vci to do this? Right now my company is making the end device as well as the server but we may have to work with third party vendors in the future so a standard vpi/vci would be nice. Thanks. Jim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 11:12:27 2002 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 LAA06656 for ; Tue, 5 Mar 2002 11:12:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA13389 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 11:12:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12324; Tue, 5 Mar 2002 10:58:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12300 for ; Tue, 5 Mar 2002 10:58:23 -0500 (EST) Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05884 for ; Tue, 5 Mar 2002 10:58:21 -0500 (EST) From: webmaster@eprojectshop.com Message-Id: <200203051558.KAA05884@ietf.org> Received: from ietf.org ([66.130.10.43]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id GSICDA02.4WU for ; Tue, 5 Mar 2002 10:58:22 -0500 Content-Type: text/html; charset=US-ASCII Date: Tue, 5 Mar 2002 10:58:24 -0500 To: dhcwg@ietf.org X-Mailer: Version 5.0 Organization: eprojectshop.com Subject: [dhcwg] The new Portal For the IT Professional Community Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org

Dear IT professional,

History has shown that the most significant growth for IT project managers,
programmers and consultants is at the beginning of an economic
expansion.  The economy is clearly in a state of recovery and companies
are once again searching for the perfect IT Professional.

This week, we've launched a new Online Marketplace for Web Designers, 
Programmers, and IT Project Managers. 

Check out the new projects available by clicking here !

Contract job opportunities and salaries are rising and eprojectshop.com is
ready to match you with the perfect gig!  Don't let your competition
beat you to it!  Click here and visit eprojectshop.com today!

You're already a member so make sure to take full advantage of
eprojectshop.com by visiting the site daily.  By registering, you will sign up
for a eprojectshop Agent and you will be informed of new projects
as soon as they are posted.

Click here to get started!

Thank You,

The team of eprojectshop.com

Good Luck!
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 12:06:34 2002 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 MAA09459 for ; Tue, 5 Mar 2002 12:06:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA17641 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 12:06:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16961; Tue, 5 Mar 2002 12:00:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16921 for ; Tue, 5 Mar 2002 12:00:50 -0500 (EST) Received: from portal.incognito.com (HAZARD.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09217 for ; Tue, 5 Mar 2002 12:00:45 -0500 (EST) Received: from homer.incognito.com ([207.102.214.21] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 16iI3v-00027Y-00; Tue, 05 Mar 2002 08:45:15 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <13HA4987>; Tue, 5 Mar 2002 09:05:26 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D19849544D@homer.incognito.com.> From: "Kostur, Andre" To: "'Ralph Droms'" , Burcak Beser Cc: dhcwg@ietf.org Subject: RE: [dhcwg] DHCP_DECLINE question Date: Tue, 5 Mar 2002 09:05:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C467.EF2290A0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C467.EF2290A0 Content-Type: text/plain; charset="iso-8859-1" Drawback on the RELEASE/DISCOVER method: wouldn't this just simply send the client into an infinite loop of DISCOVER/REQUEST/RELEASE sequence? If the stuff sent by the server is unacceptable the first time around, why would the second time be any different? And, using DECLINE doesn't make it much better (actually has the potential to make it worse!). If a client DECLINES an unsuitable ACK because it doesn't like one of the DHCP options, the server would likely mark that IP as used. Then when that client came back, it will likely DECLINE the next IP that it's given, the DHCP server marks that IP as used too, and so on, and so on, until that one client has effectively consumed your entire IP space! > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Tuesday, March 5, 2002 5:33 AM > To: Burcak Beser > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] DHCP_DECLINE question > > > I agree with Kim and Ted - DHCPDECLINE is defined in RFC2131 > to be used in > the case of an address conflict, and many DHCP servers will mark the > address in a DHCPDECLINE so that it is not offered again in > the future. > > If the client decides that the address or other parameters in > a DHCPACK are > not acceptable, the client should respond with a DHCPRELEASE and then > restart the address assignment process with a DHCPDISCOVER. > > - Ralph > > At 12:26 PM 2/28/2002 -0500, Kim Kinnear wrote: > >At 06:04 PM 2/27/2002, Burcak Beser wrote: > > >I have a question regarding the use of DHCP_DECLINE > message. If the > > client is choosing a valid DHCP_OFFER using contents of the > returned > > options, and the DHCP SERVER changes the contents of the > options while > > sending the DHCP_ACK message, is it acceptable for client to use > > DHCP_DECLINE? (The RFC 2131 states that DHCP_DECLINE is > issued when the > > IP address in use.) > > > > No, it is not. See below. > > > > > > >In other words when a DHCP_DECLINE is received by the DHCP > SERVER does > > this mean that the client detected that the IP address is > already used by > > another entity? > > > > Yes, and the implication (as well as the explicit > > direction) is that the DHCP server should not offer this > > IP address to this client or any other client for at > > least some time since it has been shown to be "unusable" > > for DHCP client allocation (because some client (or > > machine, maybe not a DHCP client) appears to be using it). > > > > From RFC2131.txt: > > > >4.3.3 DHCPDECLINE message > > > > If the server receives a DHCPDECLINE message, the client has > > discovered through some other means that the suggested network > > address is already in use. The server MUST mark the > network address > > as not available and SHOULD notify the local system > administrator of > > a possible configuration problem. > > > > > > If you don't like the IP address, you could use a > > DHCPRELEASE to give it back. Of course, you may in that > > case be offered it next time, but you don't need to take > > the offer. > > > > If you just want to give it back, use DHCPRELEASE. > > > > If you want to give it back and be offered a different IP > > address from this server, that's a harder question, since > > the DHCPDECLINE implies that the address isn't usable. > > > > Cheers -- Kim > > > > > > > > > > > > >-burcak > > > > > >_______________________________________________ > > >dhcwg mailing list > > >dhcwg@ietf.org > > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C1C467.EF2290A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP_DECLINE question

Drawback on the RELEASE/DISCOVER method:  = wouldn't this just simply send the client into an infinite loop of = DISCOVER/REQUEST/RELEASE sequence?  If the stuff sent by the = server is unacceptable the first time around, why would the second time = be any different?

And, using DECLINE doesn't make it much better = (actually has the potential to make it worse!).  If a client = DECLINES an unsuitable ACK because it doesn't like one of the DHCP = options, the server would likely mark that IP as used.  Then when = that client came back, it will likely DECLINE the next IP that it's = given, the DHCP server marks that IP as used too, and so on, and so on, = until that one client has effectively consumed your entire IP = space!

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Tuesday, March 5, 2002 5:33 AM
> To: Burcak Beser
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] DHCP_DECLINE = question
>
>
> I agree with Kim and Ted - DHCPDECLINE is = defined in RFC2131
> to be used in
> the case of an address conflict, and many DHCP = servers will mark the
> address in a DHCPDECLINE so that it is not = offered again in
> the future.
>
> If the client decides that the address or other = parameters in
> a DHCPACK are
> not acceptable, the client should respond with = a DHCPRELEASE and then
> restart the address assignment process with a = DHCPDISCOVER.
>
> - Ralph
>
> At 12:26 PM 2/28/2002 -0500, Kim Kinnear = wrote:
> >At 06:04 PM 2/27/2002, Burcak Beser = wrote:
> > >I have a question regarding the use of = DHCP_DECLINE
> message. If the
> > client is choosing a valid DHCP_OFFER = using contents of the
> returned
> > options, and the DHCP SERVER changes the = contents of the
> options while
> > sending the DHCP_ACK message, is it = acceptable for client to use
> > DHCP_DECLINE? (The RFC 2131 states that = DHCP_DECLINE is
> issued when the
> > IP address in use.)
> >
> = >         No, it is not. See = below.
> >
> >
> > >In other words when a DHCP_DECLINE is = received by the DHCP
> SERVER does
> > this mean that the client detected that = the IP address is
> already used by
> > another entity?
> >
> >       &n= bsp; Yes, and the implication (as well as the explicit
> = >         direction) is that = the DHCP server should not offer this
> = >         IP address to this = client or any other client for at
> = >         least some time = since it has been shown to be "unusable"
> = >         for DHCP client = allocation (because some client (or
> = >         machine, maybe not = a DHCP client) appears to be using it).
> >
> = >         From = RFC2131.txt:
> >
> >4.3.3 DHCPDECLINE message
> >
> >    If the server receives a = DHCPDECLINE message, the client has
> >    discovered through some = other means that the suggested network
> >    address is already in = use.  The server MUST mark the
> network address
> >    as not available and = SHOULD notify the local system
> administrator of
> >    a possible configuration = problem.
> >
> >
> = >         If you don't like = the IP address, you could use a
> = >         DHCPRELEASE to = give it back.  Of course, you may in that
> = >         case be offered it = next time, but you don't need to take
> = >         the offer.
> >
> = >         If you just want = to give it back, use DHCPRELEASE.
> >
> = >         If you want to = give it back and be offered a different IP
> = >         address from this = server, that's a harder question, since
> = >         the DHCPDECLINE = implies that the address isn't usable.
> >
> = >         Cheers -- = Kim
> >
> >
> >
> >
> >
> > >-burcak
> > >
> > = >_______________________________________________
> > >dhcwg mailing list
> > >dhcwg@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/dhcwg
> >
> >
> = >_______________________________________________
> >dhcwg mailing list
> >dhcwg@ietf.org
> >https://www1.ietf.org/mailman/listinfo/dhcwg
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C1C467.EF2290A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 12:36:20 2002 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 MAA10943 for ; Tue, 5 Mar 2002 12:36:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19544 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 12:36:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18834; Tue, 5 Mar 2002 12:27:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18803 for ; Tue, 5 Mar 2002 12:27:19 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10496 for ; Tue, 5 Mar 2002 12:27:15 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA25680 for ; Tue, 5 Mar 2002 12:26:48 -0500 (EST) Message-Id: <4.3.2.7.2.20020305122006.03831e38@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Mar 2002 12:26:42 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] DHCP_DECLINE question In-Reply-To: <4FB49E60CFBA724E88867317DAA3D19849544D@homer.incognito.com .> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Good point re. potential for looping. This behavior should only occur when the parameters change between the DHCPOFFER and the DHCPACK. Presumably, on the retry after the RELEASE, the OFFER and the ACK will match and the client will accept the parameters in the ACK. The client will only send the REQUEST if the parameters in the OFFER are acceptable, so an infinite loop will only happen if the OFFER and ACK continue to "flap". This answer begs the question of how the client behaves if the client doesn't receive an acceptable OFFER; for example, the second OFFER matches the first ACK (which the client rejected). The behavior of the client when it receives no acceptable OFFERs is left to the implementation... - Ralph At 09:05 AM 3/5/2002 -0800, Kostur, Andre wrote: >Drawback on the RELEASE/DISCOVER method: wouldn't this just simply send >the client into an infinite loop of DISCOVER/REQUEST/RELEASE sequence? If >the stuff sent by the server is unacceptable the first time around, why >would the second time be any different? > >And, using DECLINE doesn't make it much better (actually has the potential >to make it worse!). If a client DECLINES an unsuitable ACK because it >doesn't like one of the DHCP options, the server would likely mark that IP >as used. Then when that client came back, it will likely DECLINE the next >IP that it's given, the DHCP server marks that IP as used too, and so on, >and so on, until that one client has effectively consumed your entire IP space! > > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Tuesday, March 5, 2002 5:33 AM > > To: Burcak Beser > > Cc: dhcwg@ietf.org > > Subject: Re: [dhcwg] DHCP_DECLINE question > > > > > > I agree with Kim and Ted - DHCPDECLINE is defined in RFC2131 > > to be used in > > the case of an address conflict, and many DHCP servers will mark the > > address in a DHCPDECLINE so that it is not offered again in > > the future. > > > > If the client decides that the address or other parameters in > > a DHCPACK are > > not acceptable, the client should respond with a DHCPRELEASE and then > > restart the address assignment process with a DHCPDISCOVER. > > > > - Ralph > > > > At 12:26 PM 2/28/2002 -0500, Kim Kinnear wrote: > > >At 06:04 PM 2/27/2002, Burcak Beser wrote: > > > >I have a question regarding the use of DHCP_DECLINE > > message. If the > > > client is choosing a valid DHCP_OFFER using contents of the > > returned > > > options, and the DHCP SERVER changes the contents of the > > options while > > > sending the DHCP_ACK message, is it acceptable for client to use > > > DHCP_DECLINE? (The RFC 2131 states that DHCP_DECLINE is > > issued when the > > > IP address in use.) > > > > > > No, it is not. See below. > > > > > > > > > >In other words when a DHCP_DECLINE is received by the DHCP > > SERVER does > > > this mean that the client detected that the IP address is > > already used by > > > another entity? > > > > > > Yes, and the implication (as well as the explicit > > > direction) is that the DHCP server should not offer this > > > IP address to this client or any other client for at > > > least some time since it has been shown to be "unusable" > > > for DHCP client allocation (because some client (or > > > machine, maybe not a DHCP client) appears to be using it). > > > > > > From RFC2131.txt: > > > > > >4.3.3 DHCPDECLINE message > > > > > > If the server receives a DHCPDECLINE message, the client has > > > discovered through some other means that the suggested network > > > address is already in use. The server MUST mark the > > network address > > > as not available and SHOULD notify the local system > > administrator of > > > a possible configuration problem. > > > > > > > > > If you don't like the IP address, you could use a > > > DHCPRELEASE to give it back. Of course, you may in that > > > case be offered it next time, but you don't need to take > > > the offer. > > > > > > If you just want to give it back, use DHCPRELEASE. > > > > > > If you want to give it back and be offered a different IP > > > address from this server, that's a harder question, since > > > the DHCPDECLINE implies that the address isn't usable. > > > > > > Cheers -- Kim > > > > > > > > > > > > > > > > > > >-burcak > > > > > > > >_______________________________________________ > > > >dhcwg mailing list > > > >dhcwg@ietf.org > > > >https://www1.ietf.org/m > ailman/listinfo/dhcwg > > > > > > > > >_______________________________________________ > > >dhcwg mailing list > > >dhcwg@ietf.org > > >https://www1.ietf.org/mai > lman/listinfo/dhcwg > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 13:15:40 2002 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 NAA13755 for ; Tue, 5 Mar 2002 13:15:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23570 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 13:15:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23146; Tue, 5 Mar 2002 13:09:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23104 for ; Tue, 5 Mar 2002 13:09:47 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13425 for ; Tue, 5 Mar 2002 13:09:45 -0500 (EST) Received: from BarrH63p601 ([63.193.193.26]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSI00EC4IGAPP@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Tue, 05 Mar 2002 10:09:46 -0800 (PST) Date: Tue, 05 Mar 2002 10:09:19 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] DHCP_DECLINE question In-reply-to: <4.3.2.7.2.20020305122006.03831e38@funnel.cisco.com> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Ralph Droms > Sent: Tuesday, March 05, 2002 09:27 > > Good point re. potential for looping. This behavior should only > occur when the parameters change between the DHCPOFFER and the > DHCPACK. Presumably, on the retry after the RELEASE, the OFFER > and the ACK will match and the client will accept the parameters > in the ACK. > ...while the parameters would likely match, it might be that the client still doesn't like the values and that takes us back to the initial question about the meaning of DHCPDECLINE. If the client is receiving offers from multiple servers, the client could simply ignore the offer it doesn't like (assuming that the parameters are actually different between the two offers, and not merely the IP address) which is our de facto standard for clients dealing with offers they do not like. It doesn't even have to be a mismatch between offer and ack that would cause a client to decide against using the lease, but as I think about it, it doesn't appear that v4 has a mechanism for rejecting the lease after the client sends a request -- only if there is an address conflict, not the more general case. > The client will only send the REQUEST if the parameters in the > OFFER are acceptable, so an infinite loop will only happen if > the OFFER and ACK continue to "flap". > ...exactly > This answer begs the question of how the client behaves if the > client doesn't receive an acceptable OFFER; for example, the > second OFFER matches the first ACK (which the client rejected). > The behavior of the client when it receives no acceptable OFFERs > is left to the implementation... > ...*IF* we were revisiting the details of the v4 protocol, it might well be worth providing a mechanism for the client to reject a lease after receiving the DHCPACK message, but short of that, we'll just have to live with implementation-specific solutions to this "problem." --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 14:21:19 2002 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 OAA22026 for ; Tue, 5 Mar 2002 14:21:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA28311 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 14:21:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27993; Tue, 5 Mar 2002 14:18:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27972 for ; Tue, 5 Mar 2002 14:18:13 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21764 for ; Tue, 5 Mar 2002 14:18:11 -0500 (EST) Received: from BarrH63p601 ([63.193.193.26]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSI00EN3LMBPX@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Tue, 05 Mar 2002 11:18:12 -0800 (PST) Date: Tue, 05 Mar 2002 11:17:44 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] Host Name option considerations draft In-reply-to: <200202220305.g1M35Nsu161909@jurassic.eng.sun.com> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT Carl, Ted, et al.-- I've cut and pasted some sections from the draft with my comments.... --Barr <*Snip!*> 3. Interactions with Name Services A DHCP client's use of the Host Name option should be fairly straightforward, but users report problems, particularly with the interactions between it and Domain Name option and between the DNS (RFC 1034 [5] and RFC 1035 [6]) and other naming services so we reiterate and expand the description of the expected behavior: if a DHCP server supplies both Host Name and Domain Name options to a client, the host name SHOULD NOT be fully- qualified *corollary one* -- the Domain Name option also SHOULD NOT be fully-qualified *corollary two* -- the name formed by concatenating Host Name and Domain Name MUST be the Fully-Qualified Domain Name of the host, that is, there should be no other prefixes or suffixes added to the Host Name and Domain Name parts in creating the FQDN if a DHCP server supplies only a Host Name option, the host name SHOULD be fully qualified; the server MUST append only DNS domain names in forming a fully-qualified name Carl, I don't understand your point here: if the Host Name part IS fully-qualified, how can any other information be added to it and make an understandable name? For example, if the Host Name part is "rabbit.warren.org" what could be appended that makes any sense? a client MUST check to see whether a Host Name option contains a fully-qualified name and if so, MUST NOT append the value of the Domain Name option (if present) in forming its fully- qualified domain name Carl, I think "MUST" is too strong here, plus I think this wording calls for a specific level of sophistication in a client where it really should be an implementation decision. Having said that, if I understand this point correctly, to mean that you are trying to guide a client so that invalid FQDNs are not unintentionally created, I agree with the concept. How about wording such as: "a client SHOULD check for the presence of both Host Name and Domain Name options, forming the FQDN by appending the Domain Name to the Host Name. A client MAY wish to compare the Host Name option to the Domain Name option to verify that the Host Name option does not include the Domain Name part before concatenating the parts." The proposed wording does not require the client either to have local knowledge of Top Level Domain names or to perform a DNS lookup on the Host Name to determine if it is fully-qualified, which are the only two ways I can imagine for the client to test the name as you proposed. since a Host Name option's value may be fully-qualified only by supplying the DNS domain name, a client that receives a fully- qualified name in the Host Name option MAY infer the DNS domain name from the suffix of the supplied host name. This inference remains valid even in the presence of client configuration information or policies that prefer other name services in favor of, or in place of, DNS. Carl, I don't understand what you're saying here. Perhaps a few examples will show you my confusion: 1. Host Name: "mike" Domain Name: "inside.sales.bluebear.co.uk" 2. Host Name: "mike.inside.sales" Domain Name: "bluebear.co.uk" 3. Host Name: "mike.inside.sales.bluebear.co.uk" Domain Name: "" In (1) and (2) appending the Domain Name to the Host Name clearly produces an FQDN, but which is the "correct" representation of the "DNS domain name" since both are valid representations? In (3), the Host Name *is* the FQDN, but how do I parse it properly into a "DNS domain name" given that simple rules such as "use the last two parts of the name" (which works for things like "dot.com") renders the DNS domain name as "co.uk" which I don't think is what you intend. <*Snip!*> 4.1 DHCP Client Considerations and Behavior A DHCP client that uses the Host Name option to request a DNS update MUST be prepared to independently verify the success or failure of the request before using the name in a manner that would imply its validity. If a DHCP server returns the requested name in the DHCPACK's Host Name option, the client MAY infer that the server has honored its request. There are a number of reasons that a DHCP server may fail to return a Host Name option, so nothing should be inferred from the option's absence in the DHCPACK. The client MAY supply the option on subsequent RENEW operations as a method of retrying the request. However, if the Host Name option is absent in the DHCPACK, the client MUST NOT use the requested name until it has verified the validity of the association between it and the IP address supplied in the yiaddr field. Moreover, if the name returned in the DHCPACK is different from the one requested, the client MUST use the new name. So, are you implying that (1) if a client does not request a Host Name option from the server [typical of several widely-deployed clients!] but (2) the server returns a Host Name option anyway in a DHCPACK, the client should accept the [presumably] unwanted name? I think this will break a whole lot of deployed clients. A DHCP client MAY send either an unqualified or fully-qualified name in the Host Name option. Clients sending unqualified names are implicitly relying on DHCP servers to associate the clients with the appropriate zone before issuing any updates to DNS. A DHCP client in INIT state SHOULD fill in the requested host name in the DHCPDISCOVER packet. It MUST do so in its subsequent DHCPREQUEST packet. Here, again, I don't know how the server can reliably parse an FQDN sent in the Host Name option. <*Snip!*> 4.2 DHCP Server Considerations and Behavior Use of the FQDN option makes it possible to easily separate update operations into pieces corresponding to what are thought of as the traditional ownership boundaries: DHCP servers own the addresses they lease, while the clients own their names. This boundary is not present when the Host Name option is used: the implied proxy update request assumes that the DHCP server has sufficient privilege to change both the A and PTR records. That is, it ``owns'' both. For this and other reasons, use of the FQDN option is preferred: a DHCP server that receives both a Host Name option and a client FQDN option MUST prefer the FQDN option. In such a case, the server SHOULD behave as if the Host Name option is not present. I'm inclined to go further and suggest: "If a server receives both the Host Name option and the FQDN option from a client [for whom DNS updates are being proxied] the fully qualified name formed by appending the Domain Name to the client-supplied Host Name MUST be identical to the FQDN option for the server to update DNS on behalf of the client. The server SHOULD return an error to the client if the names do not match." This is something that has always bothered me about the FQDN option and the DHCP-DNS update protocol -- is a mismatch an unintentional accident or an attempt to confuse and invalidate DNS records? <*Snip!*> _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 14:40:26 2002 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 OAA23292 for ; Tue, 5 Mar 2002 14:40:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA29763 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 14:40:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29535; Tue, 5 Mar 2002 14:37:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA29394 for ; Tue, 5 Mar 2002 14:37:36 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23006 for ; Tue, 5 Mar 2002 14:36:24 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-139-160.cisco.com [161.44.139.160]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA05913 for ; Tue, 5 Mar 2002 14:35:55 -0500 (EST) Message-Id: <4.3.2.7.2.20020305140546.00b82b20@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Mar 2002 14:35:54 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] DHCP_DECLINE question In-Reply-To: References: <4.3.2.7.2.20020305122006.03831e38@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Barr - comments in line... At 10:09 AM 3/5/2002 -0800, Richard Barr Hibbs wrote: > > -----Original Message----- > > From: Ralph Droms > > Sent: Tuesday, March 05, 2002 09:27 > > > > Good point re. potential for looping. This behavior should only > > occur when the parameters change between the DHCPOFFER and the > > DHCPACK. Presumably, on the retry after the RELEASE, the OFFER > > and the ACK will match and the client will accept the parameters > > in the ACK. > > >...while the parameters would likely match, it might be that the client >still doesn't like the values and that takes us back to the initial question >about the meaning of DHCPDECLINE. Barr - I'm with you here up to the last few words. What do you mean by "...the initial question about the meaning of DHCPDECLINE"? >If the client is receiving offers from multiple servers, the client could >simply ignore the offer it doesn't like (assuming that the parameters are >actually different between the two offers, and not merely the IP address) >which is our de facto standard for clients dealing with offers they do not >like. Agreed... >It doesn't even have to be a mismatch between offer and ack that would cause >a client to decide against using the lease, but as I think about it, it >doesn't appear that v4 has a mechanism for rejecting the lease after the >client sends a request -- only if there is an address conflict, not the more >general case. Bute, if the client doesn't like the OFFER, it won't send the REQUEST and won't get the ACK. I think of this case as the lease never being created, as opposed to a lease being created and then terminated in the case the client doesn't like what's in the ACK. I agree that there is no explicit mechanism for rejecting a lease (as opposed to releasing it) once the server sends the REQUEST. Is there much of a difference between the two cases? - Ralph > > The client will only send the REQUEST if the parameters in the > > OFFER are acceptable, so an infinite loop will only happen if > > the OFFER and ACK continue to "flap". > > >...exactly > > > > This answer begs the question of how the client behaves if the > > client doesn't receive an acceptable OFFER; for example, the > > second OFFER matches the first ACK (which the client rejected). > > The behavior of the client when it receives no acceptable OFFERs > > is left to the implementation... > > >...*IF* we were revisiting the details of the v4 protocol, it might well be >worth providing a mechanism for the client to reject a lease after receiving >the DHCPACK message, but short of that, we'll just have to live with >implementation-specific solutions to this "problem." > >--Barr > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 15:32:05 2002 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 PAA26723 for ; Tue, 5 Mar 2002 15:32:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03265 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 15:32:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02856; Tue, 5 Mar 2002 15:30:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02813 for ; Tue, 5 Mar 2002 15:30:20 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26610 for ; Tue, 5 Mar 2002 15:30:12 -0500 (EST) 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 g25KUEh07904 for ; Tue, 5 Mar 2002 14:30:14 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g25KUEj24900 for ; Tue, 5 Mar 2002 14:30:14 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Mar 05 14:30:13 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 14:30:13 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4D07B@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'rbhibbs@pacbell.net'" , dhcwg@ietf.org Subject: RE: [dhcwg] Host Name option considerations draft Date: Tue, 5 Mar 2002 14:30:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C484.8CDD11F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C484.8CDD11F0 Content-Type: text/plain; charset="iso-8859-1" Barr ... thanks for providing some of these comments - I had several of them but hadn't yet sent a message. And, Carl and Ted, thanks for writing this draft! FYI Barr, I believe regarding your issue: >In (3), the Host Name *is* the FQDN, but how do I parse it properly into a >"DNS domain name" given that simple rules such as "use the last two parts of >the name" (which works for things like "dot.com") renders the DNS domain >name as "co.uk" which I don't think is what you intend. The host would remove the first label to produce the Domain Name, hence "inside.sales.bluebear.co.uk". That's all it can and should do. --- > "a client SHOULD check for the presence of both Host Name > and Domain Name options, forming the FQDN by appending the > Domain Name to the Host Name. A client MAY wish to compare > the Host Name option to the Domain Name option to verify > that the Host Name option does not include the Domain Name > part before concatenating the parts." I like this better than what Mike was suggesting because I could easily see a case, such as your (2) below that should work and thus the client can not simply see if the Host Name has one or more dots to determine whether it is fully qualified. I would suggest that (a) if the host name has NO dots, the client should add the domain name. If the host name has one or more dots, the client should only add the domain name if the host name does not end in the domain name. >2. Host Name: "mike.inside.sales" > Domain Name: "bluebear.co.uk" --- Perhaps I missed it, but can we be clear about whether the trailing dot MUST NOT be included. And, for backwards compability, a client (and server) should remove any trailing dot if it does exist (this applies to the Host Name, Domain Name, and FQDN options). --- One thing that wasn't clear to me (and perhaps it is specified in RFC 2131?), but for a client REQUEST, does (MUST) a client send the Host Name and FQDN options the server sent in the OFFER, or MUST it send what it originally sent in the DISCOVER? From this draft, it would appear it MUST send what was in the DISCOVER and not what the server may have sent back. - Bernie -----Original Message----- From: Richard Barr Hibbs [mailto:rbhibbs@pacbell.net] Sent: Tuesday, March 05, 2002 2:18 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] Host Name option considerations draft Carl, Ted, et al.-- I've cut and pasted some sections from the draft with my comments.... --Barr <*Snip!*> 3. Interactions with Name Services A DHCP client's use of the Host Name option should be fairly straightforward, but users report problems, particularly with the interactions between it and Domain Name option and between the DNS (RFC 1034 [5] and RFC 1035 [6]) and other naming services so we reiterate and expand the description of the expected behavior: if a DHCP server supplies both Host Name and Domain Name options to a client, the host name SHOULD NOT be fully- qualified *corollary one* -- the Domain Name option also SHOULD NOT be fully-qualified *corollary two* -- the name formed by concatenating Host Name and Domain Name MUST be the Fully-Qualified Domain Name of the host, that is, there should be no other prefixes or suffixes added to the Host Name and Domain Name parts in creating the FQDN if a DHCP server supplies only a Host Name option, the host name SHOULD be fully qualified; the server MUST append only DNS domain names in forming a fully-qualified name Carl, I don't understand your point here: if the Host Name part IS fully-qualified, how can any other information be added to it and make an understandable name? For example, if the Host Name part is "rabbit.warren.org" what could be appended that makes any sense? a client MUST check to see whether a Host Name option contains a fully-qualified name and if so, MUST NOT append the value of the Domain Name option (if present) in forming its fully- qualified domain name Carl, I think "MUST" is too strong here, plus I think this wording calls for a specific level of sophistication in a client where it really should be an implementation decision. Having said that, if I understand this point correctly, to mean that you are trying to guide a client so that invalid FQDNs are not unintentionally created, I agree with the concept. How about wording such as: "a client SHOULD check for the presence of both Host Name and Domain Name options, forming the FQDN by appending the Domain Name to the Host Name. A client MAY wish to compare the Host Name option to the Domain Name option to verify that the Host Name option does not include the Domain Name part before concatenating the parts." The proposed wording does not require the client either to have local knowledge of Top Level Domain names or to perform a DNS lookup on the Host Name to determine if it is fully-qualified, which are the only two ways I can imagine for the client to test the name as you proposed. since a Host Name option's value may be fully-qualified only by supplying the DNS domain name, a client that receives a fully- qualified name in the Host Name option MAY infer the DNS domain name from the suffix of the supplied host name. This inference remains valid even in the presence of client configuration information or policies that prefer other name services in favor of, or in place of, DNS. Carl, I don't understand what you're saying here. Perhaps a few examples will show you my confusion: 1. Host Name: "mike" Domain Name: "inside.sales.bluebear.co.uk" 2. Host Name: "mike.inside.sales" Domain Name: "bluebear.co.uk" 3. Host Name: "mike.inside.sales.bluebear.co.uk" Domain Name: "" In (1) and (2) appending the Domain Name to the Host Name clearly produces an FQDN, but which is the "correct" representation of the "DNS domain name" since both are valid representations? In (3), the Host Name *is* the FQDN, but how do I parse it properly into a "DNS domain name" given that simple rules such as "use the last two parts of the name" (which works for things like "dot.com") renders the DNS domain name as "co.uk" which I don't think is what you intend. <*Snip!*> 4.1 DHCP Client Considerations and Behavior A DHCP client that uses the Host Name option to request a DNS update MUST be prepared to independently verify the success or failure of the request before using the name in a manner that would imply its validity. If a DHCP server returns the requested name in the DHCPACK's Host Name option, the client MAY infer that the server has honored its request. There are a number of reasons that a DHCP server may fail to return a Host Name option, so nothing should be inferred from the option's absence in the DHCPACK. The client MAY supply the option on subsequent RENEW operations as a method of retrying the request. However, if the Host Name option is absent in the DHCPACK, the client MUST NOT use the requested name until it has verified the validity of the association between it and the IP address supplied in the yiaddr field. Moreover, if the name returned in the DHCPACK is different from the one requested, the client MUST use the new name. So, are you implying that (1) if a client does not request a Host Name option from the server [typical of several widely-deployed clients!] but (2) the server returns a Host Name option anyway in a DHCPACK, the client should accept the [presumably] unwanted name? I think this will break a whole lot of deployed clients. A DHCP client MAY send either an unqualified or fully-qualified name in the Host Name option. Clients sending unqualified names are implicitly relying on DHCP servers to associate the clients with the appropriate zone before issuing any updates to DNS. A DHCP client in INIT state SHOULD fill in the requested host name in the DHCPDISCOVER packet. It MUST do so in its subsequent DHCPREQUEST packet. Here, again, I don't know how the server can reliably parse an FQDN sent in the Host Name option. <*Snip!*> 4.2 DHCP Server Considerations and Behavior Use of the FQDN option makes it possible to easily separate update operations into pieces corresponding to what are thought of as the traditional ownership boundaries: DHCP servers own the addresses they lease, while the clients own their names. This boundary is not present when the Host Name option is used: the implied proxy update request assumes that the DHCP server has sufficient privilege to change both the A and PTR records. That is, it ``owns'' both. For this and other reasons, use of the FQDN option is preferred: a DHCP server that receives both a Host Name option and a client FQDN option MUST prefer the FQDN option. In such a case, the server SHOULD behave as if the Host Name option is not present. I'm inclined to go further and suggest: "If a server receives both the Host Name option and the FQDN option from a client [for whom DNS updates are being proxied] the fully qualified name formed by appending the Domain Name to the client-supplied Host Name MUST be identical to the FQDN option for the server to update DNS on behalf of the client. The server SHOULD return an error to the client if the names do not match." This is something that has always bothered me about the FQDN option and the DHCP-DNS update protocol -- is a mismatch an unintentional accident or an attempt to confuse and invalidate DNS records? <*Snip!*> _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1C484.8CDD11F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Host Name option considerations draft

Barr ... thanks for providing some of these comments = - I had several of them but hadn't yet sent a message. And, Carl and = Ted, thanks for writing this draft!

FYI Barr, I believe regarding your issue:

>In (3), the Host Name *is* the FQDN, but how do I = parse it properly into a
>"DNS domain name" given that simple = rules such as "use the last two parts of
>the name" (which works for things like = "dot.com") renders the DNS domain
>name as "co.uk" which I don't think is = what you intend.

The host would remove the first label to produce the = Domain Name, hence
"inside.sales.bluebear.co.uk". That's all = it can and should do.

---

>      "a client = SHOULD check for the presence of both Host Name
>      and Domain Name = options, forming the FQDN by appending the
>      Domain Name to = the Host Name.  A client MAY wish to compare
>      the Host Name = option to the Domain Name option to verify
>      that the Host = Name option does not include the Domain Name
>      part before = concatenating the parts."

I like this better than what Mike was suggesting = because I could easily see a
case, such as your (2) below that should work and = thus the client can not simply
see if the Host Name has one or more dots to = determine whether it is fully qualified.
I would suggest that (a) if the host name has NO = dots, the client should add the
domain name. If the host name has one or more dots, = the client should only add
the domain name if the host name does not end in the = domain name.

>2.  Host Name:  = "mike.inside.sales"
>    Domain Name:  = "bluebear.co.uk"

---

Perhaps I missed it, but can we be clear about = whether the trailing dot MUST NOT
be included. And, for backwards compability, a = client (and server) should remove
any trailing dot if it does exist (this applies to = the Host Name, Domain Name,
and FQDN options).

---

One thing that wasn't clear to me (and perhaps it is = specified in RFC 2131?), but
for a client REQUEST, does (MUST) a client send the = Host Name and FQDN options the
server sent in the OFFER, or MUST it send what it = originally sent in the DISCOVER?
From this draft, it would appear it MUST send what = was in the DISCOVER and not
what the server may have sent back.


- Bernie

-----Original Message-----
From: Richard Barr Hibbs [mailto:rbhibbs@pacbell.net]
Sent: Tuesday, March 05, 2002 2:18 PM
To: dhcwg@ietf.org
Subject: RE: [dhcwg] Host Name option considerations = draft



Carl, Ted, et al.--

I've cut and pasted some sections from the draft with = my comments....

--Barr


<*Snip!*>

3. Interactions with Name Services

   A DHCP client's use of the Host Name = option should be fairly
   straightforward, but users report = problems, particularly with the
   interactions between it and Domain Name = option and between the DNS
   (RFC 1034 [5] and RFC 1035 [6]) and = other naming services so we
   reiterate and expand the description of = the expected behavior:

      if a DHCP server = supplies both Host Name and Domain Name
      options to a client, = the host name SHOULD NOT be fully-
      qualified

*corollary one* -- the Domain Name option also SHOULD = NOT be fully-qualified

*corollary two* -- the name formed by concatenating = Host Name and Domain
Name MUST be the Fully-Qualified Domain Name of the = host, that is, there
should be no other prefixes or suffixes added to the = Host Name and Domain
Name parts in creating the FQDN


      if a DHCP server = supplies only a Host Name option, the host
      name SHOULD be fully = qualified; the server MUST append only DNS
      domain names in = forming a fully-qualified name

Carl, I don't understand your point here:  if = the Host Name part IS
fully-qualified, how can any other information be = added to it and make an
understandable name?  For example, if the Host = Name part is
"rabbit.warren.org" what could be appended = that makes any sense?


      a client MUST check to = see whether a Host Name option contains
      a fully-qualified = name and if so, MUST NOT append the value of
      the Domain Name = option (if present) in forming its fully-
      qualified domain = name

Carl, I think "MUST" is too strong here, = plus I think this wording calls for
a specific level of sophistication in a client where = it really should be an
implementation decision.  Having said that, if = I understand this point
correctly, to mean that you are trying to guide a = client so that invalid
FQDNs are not unintentionally created, I agree with = the concept.  How about
wording such as:

      "a client SHOULD = check for the presence of both Host Name
      and Domain Name = options, forming the FQDN by appending the
      Domain Name to the = Host Name.  A client MAY wish to compare
      the Host Name option = to the Domain Name option to verify
      that the Host Name = option does not include the Domain Name
      part before = concatenating the parts."

The proposed wording does not require the client = either to have local
knowledge of Top Level Domain names or to perform a = DNS lookup on the Host
Name to determine if it is fully-qualified, which = are the only two ways I
can imagine for the client to test the name as you = proposed.


      since a Host Name = option's value may be fully-qualified only by
      supplying the DNS = domain name, a client that receives a fully-
      qualified name in the = Host Name option MAY infer the DNS domain
      name from the suffix = of the supplied host name.  This inference
      remains valid even in = the presence of client configuration
      information or = policies that prefer other name services in
      favor of, or in place = of, DNS.

Carl, I don't understand what you're saying = here.  Perhaps a few examples
will show you my confusion:

1.  Host Name:  "mike"
    Domain Name:  = "inside.sales.bluebear.co.uk"

2.  Host Name:  = "mike.inside.sales"
    Domain Name:  = "bluebear.co.uk"

3.  Host Name:  = "mike.inside.sales.bluebear.co.uk"
    Domain Name:  = ""

In (1) and (2) appending the Domain Name to the Host = Name clearly produces
an FQDN, but which is the "correct" = representation of the "DNS domain name"
since both are valid representations?

In (3), the Host Name *is* the FQDN, but how do I = parse it properly into a
"DNS domain name" given that simple rules = such as "use the last two parts of
the name" (which works for things like = "dot.com") renders the DNS domain
name as "co.uk" which I don't think is = what you intend.

<*Snip!*>

4.1 DHCP Client Considerations and Behavior

   A DHCP client that uses the Host Name = option to request a DNS
   update MUST be prepared to = independently verify the success or
   failure of the request before using the = name in a manner that
   would imply its validity.  If a = DHCP server returns the requested
   name in the DHCPACK's Host Name option, = the client MAY infer that
   the server has honored its = request.

   There are a number of reasons that a = DHCP server may fail to
   return a Host Name option, so nothing = should be inferred from the
   option's absence in the DHCPACK.  = The client MAY supply the option
   on subsequent RENEW operations as a = method of retrying the
   request.  However, if the Host = Name option is absent in the
   DHCPACK, the client MUST NOT use the = requested name until it has
   verified the validity of the = association between it and the IP
   address supplied in the yiaddr = field.  Moreover, if the name
   returned in the DHCPACK is different = from the one requested, the
   client MUST use the new name.

So, are you implying that (1) if a client does not = request a Host Name
option from the server [typical of several = widely-deployed clients!] but (2)
the server returns a Host Name option anyway in a = DHCPACK, the client should
accept the [presumably] unwanted name?  I think = this will break a whole lot
of deployed clients.


   A DHCP client MAY send either an = unqualified or fully-qualified
   name in the Host Name option.  = Clients sending unqualified names
   are implicitly relying on DHCP servers = to associate the clients
   with the appropriate zone before = issuing any updates to DNS.  A
   DHCP client in INIT state SHOULD fill = in the requested host name
   in the DHCPDISCOVER packet.  It = MUST do so in its subsequent
   DHCPREQUEST packet.

Here, again, I don't know how the server can reliably = parse an FQDN sent in
the Host Name option.

<*Snip!*>

4.2 DHCP Server Considerations and Behavior

   Use of the FQDN option makes it possible = to easily separate update
   operations into pieces corresponding to = what are thought of as the
   traditional ownership boundaries:  = DHCP servers own the addresses
   they lease, while the clients own their = names.  This boundary is
   not present when the Host Name option = is used:  the implied proxy
   update request assumes that the DHCP = server has sufficient
   privilege to change both the A and PTR = records.  That is, it
   ``owns'' both.

   For this and other reasons, use of the = FQDN option is preferred:
   a DHCP server that receives both a Host = Name option and a client
   FQDN option MUST prefer the FQDN = option.  In such a case, the
   server SHOULD behave as if the Host = Name option is not present.

I'm inclined to go further and suggest:

   "If a server receives both the Host = Name option and the FQDN
   option from a client [for whom DNS = updates are being proxied] the
   fully qualified name formed by = appending the Domain Name to the
   client-supplied Host Name MUST be = identical to the FQDN option
   for the server to update DNS on behalf = of the client.  The server
   SHOULD return an error to the client if = the names do not match."

This is something that has always bothered me about = the FQDN option and the
DHCP-DNS update protocol -- is a mismatch an = unintentional accident or an
attempt to confuse and invalidate DNS = records?

<*Snip!*>



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1C484.8CDD11F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 17:42:59 2002 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 RAA03915 for ; Tue, 5 Mar 2002 17:42:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA10664 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 17:42:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10208; Tue, 5 Mar 2002 17:37:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01982 for ; Tue, 5 Mar 2002 08:07:17 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27682 for ; Tue, 5 Mar 2002 08:07:14 -0500 (EST) Received: from symuk01.symbol.com (symuk01.uk.symbol.com [194.133.17.2]) by mail.bucknell.edu (8.11.6/8.11.6) with SMTP id g25D7E229820 for ; Tue, 5 Mar 2002 08:07:14 -0500 (EST) Received: from [157.235.159.239] by symuk01.symbol.com via smtpd (for marge.bucknell.edu [134.82.9.1]) with SMTP; 5 Mar 2002 13:07:14 UT Received: from emea-gateway.uk.symbol.com (emea-gateway.uk.symbol.com) by mailgw01.uk.symbol.com (Content Technologies SMTPRS 4.2.1) with SMTP id for ; Tue, 5 Mar 2002 13:06:09 +0000 Received: from EMEAGW-DOM-Message_Server by emea-gateway.uk.symbol.com with Novell_GroupWise; Tue, 05 Mar 2002 13:04:32 +0000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 05 Mar 2002 13:04:19 +0000 From: "Guy Verriest" To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_623FD770.7E1F6755" Subject: [dhcwg] DHCP process when several DHCP servers Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_623FD770.7E1F6755 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'm dealing with a situation where there are 2 DHCP servers involved. One i= s local and the other one is remote (behind routers). The remote one is use= d for redundancy purposes. Presumably, should the local DHCP server fail, t= he local users would get their IP address from the remote DHCP server. Converse to what we expect, the local clients are getting their IP address = from the remote DHCP server instead of getting it from the local one. The l= ocal server is active, the clients have been rebooted and they keep receivi= ng the IP addr from the remote site. My question is: - How the priority between several DHCP servers is handled, since the whole= process starts with a DHCP Broadcast ?=20 - Would it be possible to "force" the clients to go first to the local DHCP= server rather than to the remote, without introducing parameters on the cl= ient ? Thanks in advance, guy Guy VERRIEST RF CONNECTIVITY Support Engineer SYMBOL Technologies EMEA BRUSSELS, BELGIUM Phone: 32 2 6631509 Fax: 32 2 6609237 e-mail: =20 Web site: http://www.symbol.com This message has been checked for viruses. --=_623FD770.7E1F6755 Content-Type: text/html; charset=ISO-8859-1 Content-Description: HTML Content-Transfer-Encoding: quoted-printable
Hi,
 
I'm dealing with a situation where there are 2 DHCP ser= vers=20 involved. One is local and the other one is remote (behind routers). The re= mote=20 one is used for redundancy purposes. Presumably, should the local DHCP serv= er=20 fail, the local users would get their IP address from the remote DHCP=20 server.
 
Converse to what we expect, the local clients are getti= ng=20 their IP address from the remote DHCP server instead of getting it from the= l ocal one. The local server is active, the clients have been rebooted and t= hey=20 keep receiving the IP addr from the remote site.
 
My question is:
- How the priority between several DHCP servers is hand= led,=20 since the whole process starts with a DHCP Broadcast ?
 
- Would it be possible to "force" the clients to g= o first=20 to the local DHCP server rather than to the remote, without introducin= g=20 parameters on the client ?
 
Thanks in advance,
 
guy
 
Guy VERRIEST
 
RF CONNECTIVITY Support Engineer
SYMBOL Technologies= E MEA
BRUSSELS, BELGIUM
Phone: 32 2 6631509
Fax: 32 2 6609237
e-= mail:=20 <mailto:guy.verriest@be.symbol.co= m>=20
Web site: http://www.symbol.com


This message has been checked for viruses.
 --=_623FD770.7E1F6755-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 5 17:43:04 2002 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 RAA03931 for ; Tue, 5 Mar 2002 17:43:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA10708 for dhcwg-archive@odin.ietf.org; Tue, 5 Mar 2002 17:43:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10175; Tue, 5 Mar 2002 17:37:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05318 for ; Mon, 4 Mar 2002 17:26:54 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27803 for ; Mon, 4 Mar 2002 17:26:50 -0500 (EST) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g24MQr213376 for ; Mon, 4 Mar 2002 17:26:53 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15207; Mon, 4 Mar 2002 15:26:51 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.45]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA23557; Mon, 4 Mar 2002 14:26:55 -0800 (PST) Received: from sun.com (raistlin.Eng.Sun.COM [129.146.86.244]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24MQnsu964715; Mon, 4 Mar 2002 14:26:49 -0800 (PST) Message-ID: <3C83F4BE.6D303929@sun.com> Date: Mon, 04 Mar 2002 14:27:10 -0800 From: Tobin Coziahr Organization: Sun Microsystems X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Greg Kilfoyle CC: dhcp-v4@bucknell.edu Subject: Re: [dhcwg] Minimum length for inbound DHCP packets References: <1015273324.19876.61.camel@wan-pppoe-1.lab.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Greg- The generally accepted minimum length that I've seen in use is 240 bytes. This is the bare minimum, the basic fields and the magic cookie. I actually had to update a server recently that was dropping packets under 300 bytes, too. Clients are more frequently using packets under the BOOTP minimum size (Which is perfectly legal under RFC 2131). -Tobin Greg Kilfoyle wrote: > > Hi, > > For a DHCP server or relay agent, I was wondering what is a reasonable > minimum length to check for on inbound packets. This is for DHCP support > only, no BOOTP support. > > I was thinking an initial check should use the BOOTP minimum length and > check for a DHCP packet length of 300 bytes (which makes 328 bytes > including normal IP and UDP headers). > > Using a test tool to test the DHCP server implementation showed that the > test tool was sending DHCP packets of less than 300 bytes (and the above > check was failing). > > On one hand this is a problem with the test tool; on the other hand, how > many clients out there do not send the minimum BOOTP length? In other > words, if I don't allow less then the BOOTP minimum length, how many > clients will not work correctly? > > Maybe a more forgiving approach would be a length that includes the > magic cookie and at least one option (an end option being 1 byte). > > Any thoughts welcome. > > Thanks, Greg. > -- > Greg Kilfoyle (gregk@redback.com) > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- Tobin Coziahr 650-786-7118 (x87118) Solaris Networking tobin.coziahr@sun.com Sun Microsystems _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 02:49:05 2002 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 CAA26704 for ; Wed, 6 Mar 2002 02:49:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20076 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 02:49:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20013; Wed, 6 Mar 2002 02:47:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19981 for ; Wed, 6 Mar 2002 02:47:18 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26666 for ; Wed, 6 Mar 2002 02:47:15 -0500 (EST) Received: from bt08sp.cpe.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g267kbA04722; Wed, 6 Mar 2002 08:46:37 +0100 (MET) Received: from Alcatel.be (cpws62 [138.203.68.62]) by bt08sp.cpe.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id IAA21863; Wed, 6 Mar 2002 08:46:36 +0100 (MET) Message-ID: <3C85C95C.7C4BB13A@Alcatel.be> Date: Wed, 06 Mar 2002 08:46:36 +0100 From: Van Aken Dirk Organization: Alcatel Bell X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Jim Rainville CC: dhcwg@ietf.org Subject: Re: [dhcwg] DHCP over ATM References: <000501c1c44e$5e125f00$2900a8c0@mushroom> Content-Type: multipart/mixed; boundary="------------8F2BC6A5EB2BC660356CC799" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. --------------8F2BC6A5EB2BC660356CC799 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jim Rainville wrote:
Hi - 

I know DHCP was designed to work over a broadcast media but I need to do dynamic IP allocation over an ATM network. I have bought an off the shelf DHCP implementation that does not support this but the modifications should be fairly straight forward. My plan is to use a predefined vpi/vci for an end device to send its DHCP request. The DHCP server will know this is a DHCP request because of the vpi/vci it came in on. The server will also know how to route it back to the end device because it will know which physical interface it came in on. My question is this: Is there a standards defined vpi/vci to do this? Right now my company is making the end device as well as the server but we may have to work with third party vendors in the future so a standard vpi/vci would be nice.

Thanks.

Jim

Isn't this the same problem as DHCP over point to point links ? i.e. Appart from the AAL5/ATM encapsulation I see no real differences (assuming the DHCP application does not has to run over an NBMA style of ATM network).

Dirk. --------------8F2BC6A5EB2BC660356CC799 Content-Type: text/x-vcard; charset=us-ascii; name="Dirk.Van_Aken.vcf" Content-Description: Card for Van Aken Dirk Content-Disposition: attachment; filename="Dirk.Van_Aken.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Van Aken;Dirk tel;fax:32 3 451 27 35 tel;work:32 3 451 26 53 x-mozilla-html:FALSE org:Alcatel Bell;WN5 adr:;;Prins Boudewijnlaan 47-49;Edegem;Antwerp;B-2650;Belgium version:2.1 email;internet:dirk.van_aken@alcatel.be title:CPE System Architecture Engineer x-mozilla-cpt:;-10104 fn:Dirk Van Aken end:vcard --------------8F2BC6A5EB2BC660356CC799-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 08:17:33 2002 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 IAA06343 for ; Wed, 6 Mar 2002 08:17:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA09073 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 08:17:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08987; Wed, 6 Mar 2002 08:15:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08968 for ; Wed, 6 Mar 2002 08:15:34 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06170; Wed, 6 Mar 2002 08:15:29 -0500 (EST) Message-Id: <200203061315.IAA06170@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Mar 2002 08:15:29 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agent-vpn-id-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : VPN Identifier sub-option for the Relay Agent Information Option Author(s) : K. Kinnear, M. Stapp, R. Johnson, J. Kumarasamy Filename : draft-ietf-dhc-agent-vpn-id-01.txt Pages : 8 Date : 05-Mar-02 In some environments, a relay agent resides in a network element which also has access to one or more VPNs. If one DHCP server wishes to offer service to DHCP clients on those different VPNs the DHCP server needs to know the VPN on which each client resides. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-agent-vpn-id-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-vpn-id-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305134159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-vpn-id-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-vpn-id-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134159.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 08:17:33 2002 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 IAA06341 for ; Wed, 6 Mar 2002 08:17:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA09071 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 08:17:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08925; Wed, 6 Mar 2002 08:15:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08894 for ; Wed, 6 Mar 2002 08:15:24 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06144; Wed, 6 Mar 2002 08:15:20 -0500 (EST) Message-Id: <200203061315.IAA06144@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Mar 2002 08:15:19 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Lease Query Author(s) : R. Woundy, K. Kinnear Filename : draft-ietf-dhc-leasequery-03.txt Pages : 25 Date : 05-Mar-02 Access concentrators that act as DHCP relay agents need to determine the endpoint locations of IP addresses across public broadband access networks such as cable, DSL, and wireless networks. Because ARP broadcasts are undesirable in public networks, many access concentrator implementations 'glean' location information from DHCP messages forwarded by its relay agent function. Unfortunately, the typical access concentrator loses its gleaned information when the access concentrator is rebooted or is replaced. This memo proposes that when gleaned DHCP information is not available, the access concentrator/relay agent obtains the location information directly from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-leasequery-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-leasequery-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305134134.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-leasequery-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-leasequery-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134134.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 08:17:36 2002 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 IAA06377 for ; Wed, 6 Mar 2002 08:17:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA09097 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 08:17:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08959; Wed, 6 Mar 2002 08:15:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08928 for ; Wed, 6 Mar 2002 08:15:29 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06158; Wed, 6 Mar 2002 08:15:25 -0500 (EST) Message-Id: <200203061315.IAA06158@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 06 Mar 2002 08:15:24 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agent-subnet-selection-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Subnet Selection sub-option for the Relay Agent Information Option Author(s) : K. Kinnear, M. Stapp, R. Johnson, J. Kumarasamy Filename : draft-ietf-dhc-agent-subnet-selection-02.txt Pages : 8 Date : 05-Mar-02 In RFC2131, the giaddr specifies both the subnet on which a DHCP client resides as well as an IP address which can be used to communicate with the relay agent. The subnet selection option [RFC 3011] allows these functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet from which to allocate an IP address which is different from the IP address with which it desires to communicate with the DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-subnet-selection-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-agent-subnet-selection-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-subnet-selection-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020305134146.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-subnet-selection-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-subnet-selection-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020305134146.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 16:13:35 2002 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 QAA06193 for ; Wed, 6 Mar 2002 16:13:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18868 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 16:13:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18574; Wed, 6 Mar 2002 16:09:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18551 for ; Wed, 6 Mar 2002 16:09:42 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05972; Wed, 6 Mar 2002 16:09:35 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA29536; Wed, 6 Mar 2002 16:09:08 -0500 (EST) Message-Id: <4.3.2.7.2.20020306160621.00b895f0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Mar 2002 16:09:06 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] IETF 53 DHC WG agenda (rev 1) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org IETF 53 DHC WG agenda (rev 1, 3/6/2002) (contact Ralph Droms, rdroms@cisco.com for additions, revisions) Agenda bashing WG update - 10 minutes Henrik Levkowetz - 10 minutes DHCP Option for Mobile IP Foreign Agents draft-levkowetz-dhc-mip-fa-00.txt Smith/Lemon - 15 minutes Considerations for the use of the Host Name option draft-ietf-dhc-host-option-considerations-00.txt Josh Tseng - 10 minutes DHCP Options for Internet Storage Name Service draft-tseng-dhc-isnsoption-00.txt Bernie Volz - 10 minutes Load Balancing for DHCPv6 draft-ietf-dhc-dhcpv6-loadb-00.txt Droms/Troan - 15 minutes IPv6 Prefix Options for DHCPv6 draft-troan-dhcpv6-opt-prefix-delegation-00.txt Droms/Schnizlein - 15 minutes RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option draft-ietf-dhc-agentopt-radius-00.txt Droms/Narten/Aboba - 5 minutes Using DHCPv6 for DNS Configuration in Hosts draft-droms-dnsconfig-dhcpv6-01.txt Vijayabhaskar A K - 30 minutes DHCPv6 (rev -23) Issues _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 17:10:44 2002 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 RAA09861 for ; Wed, 6 Mar 2002 17:10:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23063 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 17:10:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22931; Wed, 6 Mar 2002 17:07:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22912 for ; Wed, 6 Mar 2002 17:07:05 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09516 for ; Wed, 6 Mar 2002 17:07:01 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11536 for ; Wed, 6 Mar 2002 15:07:04 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.82.37]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA13391 for ; Wed, 6 Mar 2002 14:07:12 -0800 (PST) Received: from kanawha (kanawha.Eng.Sun.COM [129.146.86.81]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26M73hh584398 for ; Wed, 6 Mar 2002 14:07:03 -0800 (PST) Message-Id: <200203062207.g26M73hh584398@jurassic.eng.sun.com> To: dhcwg@ietf.org Subject: Re: [dhcwg] Host Name option considerations draft Date: Wed, 06 Mar 2002 14:06:41 -0800 From: Carl Smith Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thanks to Barr and Bernie for the comments. > if a DHCP server supplies both Host Name and Domain Name > options to a client, the host name SHOULD NOT be fully- > qualified > > *corollary one* -- the Domain Name option also SHOULD NOT be fully-qualified I'm being slow in understanding what you're asking here. Is it that we should say the Domain Name option SHOULD NOT contain the host name? > *corollary two* -- the name formed by concatenating Host Name and Domain > Name MUST be the Fully-Qualified Domain Name of the host, that is, there > should be no other prefixes or suffixes added to the Host Name and Domain > Name parts in creating the FQDN Including, as Bernie pointed out, language clarifying what to do with a trailing dot. > if a DHCP server supplies only a Host Name option, the host > name SHOULD be fully qualified; the server MUST append only DNS > domain names in forming a fully-qualified name > > Carl, I don't understand your point here: if the Host Name part IS > fully-qualified, how can any other information be added to it and make an > understandable name? For example, if the Host Name part is > "rabbit.warren.org" what could be appended that makes any sense? I see this caused more confusion than it was intended to prevent. :-) The point is this: in constructing the FQDN, the server should use only DNS, and not be distracted by any of the other naming services which also claim to have domain names. > a client MUST check to see whether a Host Name option contains > a fully-qualified name and if so, MUST NOT append the value of > the Domain Name option (if present) in forming its fully- > qualified domain name > > Carl, I think "MUST" is too strong here, plus I think this wording calls for > a specific level of sophistication in a client where it really should be an > implementation decision. Having said that, if I understand this point > correctly, to mean that you are trying to guide a client so that invalid > FQDNs are not unintentionally created, I agree with the concept. How about > wording such as: > > "a client SHOULD check for the presence of both Host Name > and Domain Name options, forming the FQDN by appending the > Domain Name to the Host Name. A client MAY wish to compare > the Host Name option to the Domain Name option to verify > that the Host Name option does not include the Domain Name > part before concatenating the parts." I'd prefer to invert this if it allows us to keep the MUST: a client MUST NOT attempt to form its FQDN by concatenating the values of the Host Name and Domain Name options without first verifying that the Domain Name value is not already present (i.e. as the suffix) in the Host Name value > since a Host Name option's value may be fully-qualified only by > supplying the DNS domain name, a client that receives a fully- > qualified name in the Host Name option MAY infer the DNS domain > name from the suffix of the supplied host name. This inference > remains valid even in the presence of client configuration > information or policies that prefer other name services in > favor of, or in place of, DNS. > > Carl, I don't understand what you're saying here. Perhaps a few examples > will show you my confusion: > > 1. Host Name: "mike" > Domain Name: "inside.sales.bluebear.co.uk" > > 2. Host Name: "mike.inside.sales" > Domain Name: "bluebear.co.uk" > > 3. Host Name: "mike.inside.sales.bluebear.co.uk" > Domain Name: "" ... > In (3), the Host Name *is* the FQDN, but how do I parse it properly into a > "DNS domain name" given that simple rules such as "use the last two parts of > the name" (which works for things like "dot.com") renders the DNS domain > name as "co.uk" which I don't think is what you intend. Bernie's take on it is what is intended: | The host would remove the first label to produce the Domain Name, hence | "inside.sales.bluebear.co.uk". That's all it can and should do. > 4.1 DHCP Client Considerations and Behavior > > A DHCP client that uses the Host Name option to request a DNS > update MUST be prepared to independently verify the success or > failure of the request before using the name in a manner that > would imply its validity. If a DHCP server returns the requested > name in the DHCPACK's Host Name option, the client MAY infer that > the server has honored its request. > > There are a number of reasons that a DHCP server may fail to > return a Host Name option, so nothing should be inferred from the > option's absence in the DHCPACK. The client MAY supply the option > on subsequent RENEW operations as a method of retrying the > request. However, if the Host Name option is absent in the > DHCPACK, the client MUST NOT use the requested name until it has > verified the validity of the association between it and the IP > address supplied in the yiaddr field. Moreover, if the name > returned in the DHCPACK is different from the one requested, the > client MUST use the new name. > > So, are you implying that (1) if a client does not request a Host Name > option from the server [typical of several widely-deployed clients!] but (2) > the server returns a Host Name option anyway in a DHCPACK, the client should > accept the [presumably] unwanted name? I think this will break a whole lot > of deployed clients. That's not the intention. First, a clarification: the point is that if a client sent the Host Name option, it MUST accept the value that the server returns. Upon further reflection, perhaps a bit more should be said: if a client requests a Host Name via the Parameter Request List, it MUST accept the value the server returns. Second, on a more general note, there's no intention to break extant implementations, only to outline what we believe correct behavior is today. However, I don't believe we ought to soften the language (e.g. turn MUSTs into SHOULDs) simply to cater to those implementations. > A DHCP client MAY send either an unqualified or fully-qualified > name in the Host Name option. Clients sending unqualified names > are implicitly relying on DHCP servers to associate the clients > with the appropriate zone before issuing any updates to DNS. A > DHCP client in INIT state SHOULD fill in the requested host name > in the DHCPDISCOVER packet. It MUST do so in its subsequent > DHCPREQUEST packet. > > Here, again, I don't know how the server can reliably parse an FQDN sent in > the Host Name option. It's assumed that the server has some configuration information that will help it make this decision (for example, the value of a client's Domain Name option). > 4.2 DHCP Server Considerations and Behavior > > Use of the FQDN option makes it possible to easily separate update > operations into pieces corresponding to what are thought of as the > traditional ownership boundaries: DHCP servers own the addresses > they lease, while the clients own their names. This boundary is > not present when the Host Name option is used: the implied proxy > update request assumes that the DHCP server has sufficient > privilege to change both the A and PTR records. That is, it > ``owns'' both. > > For this and other reasons, use of the FQDN option is preferred: > a DHCP server that receives both a Host Name option and a client > FQDN option MUST prefer the FQDN option. In such a case, the > server SHOULD behave as if the Host Name option is not present. > > I'm inclined to go further and suggest: > > "If a server receives both the Host Name option and the FQDN > option from a client [for whom DNS updates are being proxied] the > fully qualified name formed by appending the Domain Name to the > client-supplied Host Name MUST be identical to the FQDN option > for the server to update DNS on behalf of the client. The server > SHOULD return an error to the client if the names do not match." > > This is something that has always bothered me about the FQDN option and the > DHCP-DNS update protocol -- is a mismatch an unintentional accident or an > attempt to confuse and invalidate DNS records? I'd be interested in hearing how many vendors feel the extra checking this would require would have aided in uncovering either client confusion or DNS subversives at work. | One thing that wasn't clear to me (and perhaps it is specified in | RFC 2131?), bu t for a client REQUEST, does (MUST) a client send the | Host Name and FQDN options the server sent in the OFFER, or MUST it | send what it originally sent in the DISCOVER? From this draft, it | would appear it MUST send what was in the DISCOVER and not what the | server may have sent back. The closest I could find in 2131 were these two 3.5 If the client includes a list of parameters in a DHCPDISCOVER message, it MUST include that list in any subsequent DHCPREQUEST messages. 4.3.2 If the client included a list of requested parameters in a DHCPDISCOVER message, it MUST include that list in all subsequent messages. both of which deal with presence, but do not address a change in value between DISCOVER and REQUEST. Carl _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 17:29:59 2002 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 RAA11480 for ; Wed, 6 Mar 2002 17:29:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23896 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 17:30:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23808; Wed, 6 Mar 2002 17:28:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23779 for ; Wed, 6 Mar 2002 17:28:02 -0500 (EST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11334 for ; Wed, 6 Mar 2002 17:27:57 -0500 (EST) Received: from BarrH63p601 ([63.193.193.26]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSK007DTP2NCY@mta7.pltn13.pbi.net> for dhcwg@ietf.org; Wed, 06 Mar 2002 14:28:01 -0800 (PST) Date: Wed, 06 Mar 2002 14:27:24 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] Host Name option considerations draft In-reply-to: <66F66129A77AD411B76200508B65AC69B4D07B@EAMBUNT705> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: multipart/alternative; boundary="Boundary_(ID_GvsEqDyvksLEk/ylTNElAg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_GvsEqDyvksLEk/ylTNElAg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT RE: [dhcwg] Host Name option considerations draft -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Tuesday, March 05, 2002 12:30 Barr, I believe regarding your issue: >In (3), the Host Name *is* the FQDN, but how do I parse it properly into a >"DNS domain name" given that simple rules such as "use the last two parts of >the name" (which works for things like "dot.com") renders the DNS domain >name as "co.uk" which I don't think is what you intend. The host would remove the first label to produce the Domain Name, hence "inside.sales.bluebear.co.uk". That's all it can and should do. Bernie: of course, that is a simple way to parse the name, but it ignores multi-part host names (such as "mike.inside.sales") -- I'll agree that it is probably the only way that a server or client could parse the name, absent much additional information --- > "a client SHOULD check for the presence of both Host Name > and Domain Name options, forming the FQDN by appending the > Domain Name to the Host Name. A client MAY wish to compare > the Host Name option to the Domain Name option to verify > that the Host Name option does not include the Domain Name > part before concatenating the parts." I like this better than what Mike was suggesting because I could easily see a case, such as your (2) below that should work and thus the client can not simply see if the Host Name has one or more dots to determine whether it is fully qualified. I would suggest that (a) if the host name has NO dots, the client should add the domain name. If the host name has one or more dots, the client should only add the domain name if the host name does not end in the domain name. >2. Host Name: "mike.inside.sales" > Domain Name: "bluebear.co.uk" Bernie-- examples always help: suppose a client receives my example (2) -- the correct FQDN should be "mike.inside.sales.bluebear.co.uk" if the client were to receive Host Name: "mike.inside.sales.bluebear.co.uk" and Domain Name: "bluebear.co.uk" then a simple string comparison yields the same result by preventing duplication of "bluebear.co.uk" but what if the client were to receive Host Name: "mike.inside.sales.bluebear" and Domain Name: "bluebear.co.uk" -- in this contrived example, we know the correct result, but in general, I don't think you can assert that two sequential parts of a name cannot be duplicated. It really depends entirely on how the RR's for the domain "bluebear.co.uk" are recorded in DNS. I'll defer to the experts on name matching for DNS as to whether names like "bluebear.bluebear.co.uk" are permitted. --- Perhaps I missed it, but can we be clear about whether the trailing dot MUST NOT be included. And, for backwards compability, a client (and server) should remove any trailing dot if it does exist (this applies to the Host Name, Domain Name, and FQDN options). your comments also suggested that clients should be prepared to deal with malformed host names, such as names ending with a separator (dot) or two consecutive separators -- they don't have to correct malformed names, but should be prepared to handle them in a predictable way. --- One thing that wasn't clear to me (and perhaps it is specified in RFC 2131?), but for a client REQUEST, does (MUST) a client send the Host Name and FQDN options the server sent in the OFFER, or MUST it send what it originally sent in the DISCOVER? From this draft, it would appear it MUST send what was in the DISCOVER and not what the server may have sent back. This raises the questions of what should the client do if it "requests" a host name by sending one in the discover message, but the server responds with a name the client doesn't like? Who owns the name (Carl tried to cover that point) and what recourse is there for a client who doesn't like an offered option value? Some additional discussion may be needed. --Barr --Boundary_(ID_GvsEqDyvksLEk/ylTNElAg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT RE: [dhcwg] Host Name option considerations draft

 
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Tuesday, March 05, 2002 12:30

 Barr, I believe regarding your issue:

>In (3), the Host Name *is* the FQDN, but how do I parse it properly into a
>"DNS domain name" given that simple rules such as "use the last two parts of
>the name" (which works for things like "dot.com") renders the DNS domain
>name as "co.uk" which I don't think is what you intend.

The host would remove the first label to produce the Domain Name, hence
"inside.sales.bluebear.co.uk". That's all it can and should do.

Bernie:  of course, that is a simple way to parse the name, but it ignores multi-part host names (such as "mike.inside.sales") -- I'll agree that it is probably the only way that a server or client could parse the name, absent much additional information

 ---

>      "a client SHOULD check for the presence of both Host Name
>      and Domain Name options, forming the FQDN by appending the
>      Domain Name to the Host Name.  A client MAY wish to compare
>      the Host Name option to the Domain Name option to verify
>      that the Host Name option does not include the Domain Name
>      part before concatenating the parts."

I like this better than what Mike was suggesting because I could easily see a
case, such as your (2) below that should work and thus the client can not simply
see if the Host Name has one or more dots to determine whether it is fully qualified.
I would suggest that (a) if the host name has NO dots, the client should add the
domain name. If the host name has one or more dots, the client should only add
the domain name if the host name does not end in the domain name.

>2.  Host Name:  "mike.inside.sales"
>    Domain Name:  "bluebear.co.uk"  

Bernie-- examples always help:

suppose a client receives my example (2) --  the correct FQDN should be "mike.inside.sales.bluebear.co.uk"

if the client were to receive Host Name: "mike.inside.sales.bluebear.co.uk" and Domain Name: "bluebear.co.uk" then a simple string comparison yields the same result by preventing duplication of "bluebear.co.uk"

but what if the client were to receive Host Name: "mike.inside.sales.bluebear" and Domain Name: "bluebear.co.uk" -- in this contrived example, we know the correct result, but in general, I don't think you can assert that two sequential parts of a name cannot be duplicated.  It really depends entirely on how the RR's for the domain "bluebear.co.uk" are recorded in DNS.  I'll defer to the experts on name matching for DNS as to whether names like "bluebear.bluebear.co.uk" are permitted.

---

Perhaps I missed it, but can we be clear about whether the trailing dot MUST NOT
be included. And, for backwards compability, a client (and server) should remove
any trailing dot if it does exist (this applies to the Host Name, Domain Name,
and FQDN options).

your comments also suggested that clients should be prepared to deal with malformed host names, such as names ending with a separator (dot) or two consecutive separators -- they don't have to correct malformed names, but should be prepared to handle them in a predictable way.

---

One thing that wasn't clear to me (and perhaps it is specified in RFC 2131?), but
for a client REQUEST, does (MUST) a client send the Host Name and FQDN options the
server sent in the OFFER, or MUST it send what it originally sent in the DISCOVER?
From this draft, it would appear it MUST send what was in the DISCOVER and not
what the server may have sent back.

This raises the questions of what should the client do if it "requests" a host name by sending one in the discover message, but the server responds with a name the client doesn't like?  Who owns the name (Carl tried to cover that point) and what recourse is there for a client who doesn't like an offered option value?  Some additional discussion may be needed.

 
--Barr
 


--Boundary_(ID_GvsEqDyvksLEk/ylTNElAg)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 18:29:40 2002 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 SAA14910 for ; Wed, 6 Mar 2002 18:29:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA27165 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 18:29:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27101; Wed, 6 Mar 2002 18:27:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27080 for ; Wed, 6 Mar 2002 18:27:09 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14804 for ; Wed, 6 Mar 2002 18:27:04 -0500 (EST) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g26NMaX26782; Wed, 6 Mar 2002 15:22:36 -0800 (PST) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g26NQxF00428; Wed, 6 Mar 2002 17:26:59 -0600 (CST) Date: Wed, 6 Mar 2002 17:26:59 -0600 Subject: Re: [dhcwg] DHCP_DECLINE question Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: dhcwg@ietf.org To: rbhibbs@pacbell.net From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit I don't see what kind of traction you'd expect to get by telling a DHCP server that gave you unacceptable parameters on a DHCPACK that you no longer want the IP address. The only way I can see this happening is if the DHCP server is broken - it sent a DHCPOFFER with different information than was contained in the DHCPACK. If it sent the same information in the DHCPACK, the client has no business declining the offer - if it didn't like it, it should never have sent a DHCPREQUEST. So if the server is broken and sends different information in the DHCPACK than in the DHCPOFFER, the client can either accept what the server sent, or write the server off as broken. Sending a DHCPRELEASE and then reconfiguring isn't going to work, and neither is sending a DHCPDECLINE - the server is broken, and no protocol action is going to fix it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 18:34:41 2002 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 SAA15140 for ; Wed, 6 Mar 2002 18:34:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA27781 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 18:34:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27713; Wed, 6 Mar 2002 18:32:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27688 for ; Wed, 6 Mar 2002 18:32:24 -0500 (EST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15076 for ; Wed, 6 Mar 2002 18:32:19 -0500 (EST) Received: from BarrH63p601 ([63.193.193.26]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSK007RHS1ZCG@mta7.pltn13.pbi.net> for dhcwg@ietf.org; Wed, 06 Mar 2002 15:32:23 -0800 (PST) Date: Wed, 06 Mar 2002 15:31:47 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] DHCP_DECLINE question In-reply-to: <4.3.2.7.2.20020305140546.00b82b20@funnel.cisco.com> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT I'll try to clarify the points..... --Barr > -----Original Message----- > From: Ralph Droms > Sent: Tuesday, March 05, 2002 11:36 > > Barr - comments in line... > > At 10:09 AM 3/5/2002 -0800, Richard Barr Hibbs wrote: > > > > Good point re. potential for looping. This behavior should only > > > occur when the parameters change between the DHCPOFFER and the > > > DHCPACK. Presumably, on the retry after the RELEASE, the OFFER > > > and the ACK will match and the client will accept the parameters > > > in the ACK. > > > > >...while the parameters would likely match, it might be that the client > >still doesn't like the values and that takes us back to the > initial question > >about the meaning of DHCPDECLINE. > > Barr - I'm with you here up to the last few words. What do you mean by > "...the initial question about the meaning of DHCPDECLINE"? > ...assuming I understood the question properly, it could be restated as "Can a client use DHCPDECLINE to reject an offered IP address after sending DHCPREQUEST?" Implied in that is what recourse is there for a client that doesn't like some or all of a server's offer? <*Snip!*> > I agree that there is no explicit mechanism for rejecting a lease (as > opposed to releasing it) once the server sends the REQUEST. Is > there much > of a difference between the two cases? > ...only that if a client releases the lease it is likely to get the same lease the next time it starts the cycle.... I don't think we should be making a change to the protocol at this point lacking sufficient evidedence of harm caused by the current behavior, but it does seem a bit of an oversight.... --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 18:45:30 2002 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 SAA15725 for ; Wed, 6 Mar 2002 18:45:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28397 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 18:45:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28357; Wed, 6 Mar 2002 18:43:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28338 for ; Wed, 6 Mar 2002 18:43:38 -0500 (EST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15609 for ; Wed, 6 Mar 2002 18:43:33 -0500 (EST) Received: from BarrH63p601 ([63.193.193.26]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSK0071OSKK9O@mta7.pltn13.pbi.net> for dhcwg@ietf.org; Wed, 06 Mar 2002 15:43:37 -0800 (PST) Date: Wed, 06 Mar 2002 10:42:39 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] DHCP_DECLINE question In-reply-to: To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Wednesday, March 06, 2002 15:27 > > I don't see what kind of traction you'd expect to get by telling a DHCP > server that gave you unacceptable parameters on a DHCPACK that you no > longer want the IP address. > ...I agree that a client should not arbitrarily change it's mind about a lease, just observing that we don't seem to have fully specified all of the cases, and trying to shine a little daylight on one or two.... > So if the server is broken and sends different information in the DHCPACK > than in the DHCPOFFER, the client can either accept what the server sent, > or write the server off as broken. Sending a DHCPRELEASE and then > reconfiguring isn't going to work, and neither is sending a DHCPDECLINE - > the server is broken, and no protocol action is going to fix it. > ...I agree, but I've also been trying to think of any cases where a client might find that an option value sent by a server just doesn't work after receiving a DHCPACK, and whether or not there is any possible recourse. The only one I can think of it DNS server addresses: if they are wrong, the client is effectively useless for many purposes, the client is not likely to learn of a bad DNS address until after it has received a DHCPACK, and there isn't a heck of a lot that the client (or protocol) could do about that, so your summary seems to be the end of the discussion. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 21:54:01 2002 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 VAA24229 for ; Wed, 6 Mar 2002 21:54:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA07772 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 21:54:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07682; Wed, 6 Mar 2002 21:52:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07605 for ; Wed, 6 Mar 2002 21:52:34 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24151 for ; Wed, 6 Mar 2002 21:52:29 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn1-150.cisco.com [10.21.96.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA16174 for ; Wed, 6 Mar 2002 21:52:02 -0500 (EST) Message-Id: <4.3.2.7.2.20020306214213.00b924e8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Mar 2002 21:51:31 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] DHCP_DECLINE question In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ted - I disagree with your flat statement that a server that returns different parameters in the DHCPACK is broken: From section 3.1 of RFC2131, in the 4th item in the numbered list: The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client. [...] Any configuration parameters in the DHCPACK message SHOULD NOT conflict with those in the earlier DHCPOFFER message to which the client is responding. The cited behavior is in conflict with the SHOULD NOT in the second sentence, so the server is not violating this part of the protocol spec. I can imagine a *transient* situation in which the server's configuration changes between transmission of the DHCPOFFER and the DHCPACK, causing a difference in the parameters in the two messages *for that one transaction*. In this situation, if the client sends a DHCPRELEASE and then tries again, the server will, presumably, either send a DHCPOFFER that the client will ignore (if the parameters are still unacceptable) or a DHCPOFFER that is followed by a consistent DHCPACK. So, there's an existence proof that the situation might be fixable through the protocol. Now, whether the possibility is worth trying to fix is open for discussion... - Ralph At 05:26 PM 3/6/2002 -0600, Ted Lemon wrote: >I don't see what kind of traction you'd expect to get by telling a DHCP >server that gave you unacceptable parameters on a DHCPACK that you no >longer want the IP address. The only way I can see this happening is if >the DHCP server is broken - it sent a DHCPOFFER with different information >than was contained in the DHCPACK. If it sent the same information in >the DHCPACK, the client has no business declining the offer - if it didn't >like it, it should never have sent a DHCPREQUEST. > >So if the server is broken and sends different information in the DHCPACK >than in the DHCPOFFER, the client can either accept what the server sent, >or write the server off as broken. Sending a DHCPRELEASE and then >reconfiguring isn't going to work, and neither is sending a DHCPDECLINE - >the server is broken, and no protocol action is going to fix it. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 22:01:59 2002 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 WAA24584 for ; Wed, 6 Mar 2002 22:01:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA08468 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 22:02:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08019; Wed, 6 Mar 2002 22:00:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07973 for ; Wed, 6 Mar 2002 22:00:13 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24499 for ; Wed, 6 Mar 2002 22:00:08 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn1-150.cisco.com [10.21.96.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA16365 for ; Wed, 6 Mar 2002 21:59:40 -0500 (EST) Message-Id: <4.3.2.7.2.20020306215847.037abc20@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Mar 2002 21:59:34 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] DHCP_DECLINE question In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org At 10:42 AM 3/6/2002 -0800, Richard Barr Hibbs wrote: > > -----Original Message----- > > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > > Sent: Wednesday, March 06, 2002 15:27 > > > > I don't see what kind of traction you'd expect to get by telling a DHCP > > server that gave you unacceptable parameters on a DHCPACK that you no > > longer want the IP address. > > >...I agree that a client should not arbitrarily change it's mind about a >lease, just observing that we don't seem to have fully specified all of the >cases, and trying to shine a little daylight on one or two.... Yup, that's what I'm trying to get out of this conversation, too. Someone outside the DHC WG asked the question, so it seems worth exploring. - Ralph > > > > So if the server is broken and sends different information in the DHCPACK > > than in the DHCPOFFER, the client can either accept what the server sent, > > or write the server off as broken. Sending a DHCPRELEASE and then > > reconfiguring isn't going to work, and neither is sending a DHCPDECLINE - > > the server is broken, and no protocol action is going to fix it. > > >...I agree, but I've also been trying to think of any cases where a client >might find that an option value sent by a server just doesn't work after >receiving a DHCPACK, and whether or not there is any possible recourse. The >only one I can think of it DNS server addresses: if they are wrong, the >client is effectively useless for many purposes, the client is not likely to >learn of a bad DNS address until after it has received a DHCPACK, and there >isn't a heck of a lot that the client (or protocol) could do about that, so >your summary seems to be the end of the discussion. > >--Barr > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 22:02:39 2002 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 WAA24630 for ; Wed, 6 Mar 2002 22:02:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA08529 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 22:02:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07970; Wed, 6 Mar 2002 22:00:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07946 for ; Wed, 6 Mar 2002 22:00:11 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24481 for ; Wed, 6 Mar 2002 22:00:06 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn1-150.cisco.com [10.21.96.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA16361 for ; Wed, 6 Mar 2002 21:59:38 -0500 (EST) Message-Id: <4.3.2.7.2.20020306215321.0378c290@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Mar 2002 21:58:32 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] DHCP_DECLINE question In-Reply-To: References: <4.3.2.7.2.20020305140546.00b82b20@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org At 03:31 PM 3/6/2002 -0800, Richard Barr Hibbs wrote: >I'll try to clarify the points..... > >--Barr > > > > -----Original Message----- > > From: Ralph Droms > > Sent: Tuesday, March 05, 2002 11:36 > > > > Barr - comments in line... > > > > At 10:09 AM 3/5/2002 -0800, Richard Barr Hibbs wrote: > > > > > > Good point re. potential for looping. This behavior should only > > > > occur when the parameters change between the DHCPOFFER and the > > > > DHCPACK. Presumably, on the retry after the RELEASE, the OFFER > > > > and the ACK will match and the client will accept the parameters > > > > in the ACK. > > > > > > >...while the parameters would likely match, it might be that the client > > >still doesn't like the values and that takes us back to the > > initial question > > >about the meaning of DHCPDECLINE. > > > > Barr - I'm with you here up to the last few words. What do you mean by > > "...the initial question about the meaning of DHCPDECLINE"? > > >...assuming I understood the question properly, it could be restated as "Can >a client use DHCPDECLINE to reject an offered IP address after sending >DHCPREQUEST?" Implied in that is what recourse is there for a client that >doesn't like some or all of a server's offer? The meaning of DHCPDECLINE is pretty well-defined; from the 5th element in the numbered list in section 3.1 of RFC2131: If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server and restarts the configuration process. DHCPDECLINE is intended for use when the assigned address is already in use. In my opinion, a client is within the spec if it sends a DHCPRELEASE immediately after receiving a DHCPACK (for whatever reason). The DHCPRELEASE will terminate the lease and make the address available for reassignment without causing the server to mark the address as "not to be assigned". There is still the open question of whether we want to *recommend* this behavior... ><*Snip!*> > > > I agree that there is no explicit mechanism for rejecting a lease (as > > opposed to releasing it) once the server sends the REQUEST. Is > > there much > > of a difference between the two cases? > > >...only that if a client releases the lease it is likely to get the same >lease the next time it starts the cycle.... I don't think we should be >making a change to the protocol at this point lacking sufficient evidedence >of harm caused by the current behavior, but it does seem a bit of an >oversight.... But the problem isn't the lease/assigned address so much as the other parameters. If the client gets the same (unacceptable) parameters in the subsequent DHCPOFFER, the client will ignore it. >--Barr - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 6 23:42:52 2002 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 XAA00145 for ; Wed, 6 Mar 2002 23:42:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA12587 for dhcwg-archive@odin.ietf.org; Wed, 6 Mar 2002 23:42:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12498; Wed, 6 Mar 2002 23:41:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12469 for ; Wed, 6 Mar 2002 23:41:04 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00057 for ; Wed, 6 Mar 2002 23:40:59 -0500 (EST) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g274acX27546; Wed, 6 Mar 2002 20:36:38 -0800 (PST) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g274f1F00618; Wed, 6 Mar 2002 22:41:01 -0600 (CST) Date: Wed, 6 Mar 2002 22:41:01 -0600 Subject: Re: [dhcwg] DHCP_DECLINE question Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: dhcwg@ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20020306215321.0378c290@funnel.cisco.com> Message-Id: <86CB2DF8-3185-11D6-8B5E-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > In my opinion, a client is within the spec if it sends a DHCPRELEASE > immediately after receiving a DHCPACK (for whatever reason). The > DHCPRELEASE will terminate the lease and make the address available for > reassignment without causing the server to mark the address as "not to be > assigned". True. > There is still the open question of whether we want to *recommend* this > behavior... Right. I'd say we shouldn't, because in all likelihood it's going to result in the client looping behavior about which Barr is concerned. I think that we are trying to fix a nonexistant problem here, and the fix seems much worse than the problem, particularly since I've never observed the problem happening in real life. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 01:08:35 2002 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 BAA02540 for ; Thu, 7 Mar 2002 01:08:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA20874 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 01:08:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16977; Thu, 7 Mar 2002 01:03:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16955 for ; Thu, 7 Mar 2002 01:03:41 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02409 for ; Thu, 7 Mar 2002 01:03:38 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 6 Mar 2002 22:03:10 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Mar 2002 22:03:10 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 22:03:10 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 22:03:09 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 6 Mar 2002 22:00:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: [dhcwg] DHCP_DECLINE question Date: Wed, 6 Mar 2002 22:00:13 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC103C09A39@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [dhcwg] DHCP_DECLINE question Thread-Index: AcHFm2v1/O2P7KF7RXygAS7iS/eKPAAAMvQ8 From: "Thirumalesh Bhat" To: "Ted Lemon" , "Ralph Droms" Cc: X-OriginalArrivalTime: 07 Mar 2002 06:00:14.0002 (UTC) FILETIME=[59313920:01C1C59D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id BAA16956 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit If the client loops by sending a DHCP DECLINE, it can cause a denial of service attack on the server as all the addresses in a subnet can be marked as bad. This behavior might happen in a buggy client implementation. A better way to solve this on the server end is to mark the address as bad for a lease lifetime or a multiple of the lease lifetime. Since an address is marked as bad when there is a conflict, it is reasonable to assume that there is a client who already has obtained a lease from the server and is using the address. So when the original client does a renew, the address state can be switched back to lease in use. If the client does a release after getting an ack because it doesnt like some lease parameter and ends up in the init state, the client may loop for ever. As Ted has mentioned, this is a very unlikely real world scenario. thx -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wed 3/6/2002 8:41 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCP_DECLINE question > In my opinion, a client is within the spec if it sends a DHCPRELEASE > immediately after receiving a DHCPACK (for whatever reason). The > DHCPRELEASE will terminate the lease and make the address available for > reassignment without causing the server to mark the address as "not to be > assigned". True. > There is still the open question of whether we want to *recommend* this > behavior... Right. I'd say we shouldn't, because in all likelihood it's going to result in the client looping behavior about which Barr is concerned. I think that we are trying to fix a nonexistant problem here, and the fix seems much worse than the problem, particularly since I've never observed the problem happening in real life. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 01:40:06 2002 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 BAA03433 for ; Thu, 7 Mar 2002 01:40:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28993 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 01:40:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28774; Thu, 7 Mar 2002 01:35:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28754 for ; Thu, 7 Mar 2002 01:35:14 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03253 for ; Thu, 7 Mar 2002 01:35:10 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01458 for ; Wed, 6 Mar 2002 23:35:13 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.105]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id WAA21183 for ; Wed, 6 Mar 2002 22:35:19 -0800 (PST) Received: from kanawha (kanawha.Eng.Sun.COM [129.146.86.81]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g276ZChh674128 for ; Wed, 6 Mar 2002 22:35:12 -0800 (PST) Message-Id: <200203070635.g276ZChh674128@jurassic.eng.sun.com> To: dhcwg@ietf.org Subject: Re: [dhcwg] Host Name option considerations draft In-reply-to: mail from Richard Barr Hibbs dated Wed, 06 Mar 2002 15:19:25 PST Date: Wed, 06 Mar 2002 22:34:50 -0800 From: Carl Smith Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org OK. This > *corollary one* -- the Domain Name option also SHOULD NOT be > fully-qualified I didn't understand, but this > I meant that we should discourage both the Host and Domain > Name options from containing identical information -- a client > implementation could, of course, deal with it in some consistent way, but it > really would be better practice to avoid confusing duplications of data -- > and the best way really is if the Host Name and Domain Name options do not > contain identical or overlapping information certainly makes sense. > > > So, are you implying that (1) if a client does not request a Host Name > > > option from the server [typical of several widely-deployed > > clients!] but (2) > > > the server returns a Host Name option anyway in a DHCPACK, the > > client should > > > accept the [presumably] unwanted name? I think this will break > > a whole lot > > > of deployed clients. > > > > That's not the intention. First, a clarification: the point is > > that if a client sent the Host Name option, it MUST accept the value that > > the server returns. Upon further reflection, perhaps a bit more should > > be said: if a client requests a Host Name via the Parameter Request List, > > it MUST accept the value the server returns. > > > ...look at what you wrote, again: in the first part you specified the > client sending the Host Name OPTION and in the second, requesting the Host > Name in the Parameter Request List -- the two are not the same thing, which > is where my disagreement arose. Yes, I know they're not the same thing (which is why I wrote that ``perhaps a bit more should be said'' when I extended it to include the Parameter Request List. There are now two questions to consider - if a client sends a Host Name option and the server responds with a different name from the one the client requested, what must the client do? - if a client requests a Host Name option be returned, must it accept the value the server returns, or choose to use its own? The language in the draft addresses only the first of these: if a client sends a Host Name option and the server responds with a Host Name option, the client needs to use the value the server returned, not continue the use of the one it (merely) requested. The second one is more tenuous, but I believe the same argument can be made: by requesting a Host Name option be returned, is the client agreeing to use the value or is it just hoping to get lucky? If it's the latter, then the client should instead simply ask DNS what name corresponds to the address the server leased it. > > Second, on a more general note, there's no intention to break extant > > implementations, only to outline what we believe correct behavior > > is today. > > However, I don't believe we ought to soften the language (e.g. turn MUSTs > > into SHOULDs) simply to cater to those implementations. > > > ...hard to fight a nearly 90% market share, though..... Who's fighting? We're merely writing a document that captures what the WG feels good implementations ought to do. Someone with 90% market share could easily ignore us, but at least we've given vendors a description of what we'd like to see them do. If we don't at least do that, we'll not have those good implementations to choose from when we get the opportunity to do so. > > > A DHCP client MAY send either an unqualified or fully-qualified > > > name in the Host Name option. Clients sending unqualified names > > > are implicitly relying on DHCP servers to associate the clients > > > with the appropriate zone before issuing any updates to DNS. A > > > DHCP client in INIT state SHOULD fill in the requested host name > > > in the DHCPDISCOVER packet. It MUST do so in its subsequent > > > DHCPREQUEST packet. > > > > > > Here, again, I don't know how the server can reliably parse an > > FQDN sent in > > > the Host Name option. > > > > It's assumed that the server has some configuration information > > that will help it make this decision (for example, the value of a client's > > Domain Name option). > > > ...I'm not convinced that having just the Domain Name option is sufficient, > but my major issue is really our expectation of behavior seems to be placing > more of a burden on clients than they can be relied upon to perform.... Yep, I believe that's true. Servers always had to be written to protect themselves from bad clients. In this case the burden is more on the clients to protect themselves from bad servers. > > > I'm inclined to go further and suggest: > > > > > > "If a server receives both the Host Name option and the FQDN > > > option from a client [for whom DNS updates are being proxied] the > > > fully qualified name formed by appending the Domain Name to the > > > client-supplied Host Name MUST be identical to the FQDN option > > > for the server to update DNS on behalf of the client. The server > > > SHOULD return an error to the client if the names do not match." > > > > > > This is something that has always bothered me about the FQDN > > option and the > > > DHCP-DNS update protocol -- is a mismatch an unintentional > > accident or an > > > attempt to confuse and invalidate DNS records? > > > > I'd be interested in hearing how many vendors feel the extra > > checking this would require would have aided in uncovering either client > > confusion or DNS subversives at work. > > > ...good point, although I will assert that if a client uses a different FQDN > in the DNS update from what it would be expected to construct from Host Name > and Domain Name, then that client is seriously broken.... Agreed. The only question I had was whether we had data that would suggest it was worthwhile to insist that servers perform the check. > > | One thing that wasn't clear to me (and perhaps it is specified in > > | RFC 2131?), bu t for a client REQUEST, does (MUST) a client send the > > | Host Name and FQDN options the server sent in the OFFER, or MUST it > > | send what it originally sent in the DISCOVER? From this draft, it > > | would appear it MUST send what was in the DISCOVER and not what the > > | server may have sent back. > > > > The closest I could find in 2131 were these two > > > > 3.5 > > If the client includes a list of parameters in a DHCPDISCOVER > > message, it MUST include that list in any subsequent DHCPREQUEST > > messages. > > > > 4.3.2 > > If the client included a list of requested > > parameters in a DHCPDISCOVER message, it MUST include that list in > > all subsequent messages. > > > > both of which deal with presence, but do not address a change in value > > between DISCOVER and REQUEST. > > > ...and I've also seen instances where clients certainly don't follow these > guidelines, but expect that option values won't change between an offer and > an ack. A reasonable expectation is that certain values (e.g., Host Name > and Domain Name) will not be changed by the server. I'm happy to add something to this draft that says the Host Name's value should not change, but as you suggest the problem is larger than just one or two options. Carl _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 09:12:45 2002 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 JAA25450 for ; Thu, 7 Mar 2002 09:12:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25384 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 09:12:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25221; Thu, 7 Mar 2002 09:08:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25196 for ; Thu, 7 Mar 2002 09:08:22 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25150; Thu, 7 Mar 2002 09:08:19 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA10305; Thu, 7 Mar 2002 09:07:52 -0500 (EST) Message-Id: <4.3.2.7.2.20020307090504.019d66e0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Mar 2002 09:07:48 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DHC wg agenda (rev 2) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org IETF 53 DHC WG agenda (rev 2, 3/7/2002) WEDNESDAY, March 20, 2002 - 0900-1130 (contact Ralph Droms, rdroms@cisco.com for additions, revisions) Agenda bashing WG update - 10 minutes Henrik Levkowetz - 10 minutes DHCP Option for Mobile IP Foreign Agents draft-levkowetz-dhc-mip-fa-00.txt Smith/Lemon - 15 minutes Considerations for the use of the Host Name option draft-ietf-dhc-host-option-considerations-00.txt Josh Tseng - 10 minutes DHCP Options for Internet Storage Name Service draft-tseng-dhc-isnsoption-00.txt Bernie Volz - 10 minutes Load Balancing for DHCPv6 draft-ietf-dhc-dhcpv6-loadb-00.txt Droms/Troan - 15 minutes IPv6 Prefix Options for DHCPv6 draft-troan-dhcpv6-opt-prefix-delegation-00.txt Droms/Schnizlein - 15 minutes RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option draft-ietf-dhc-agentopt-radius-00.txt Droms/Narten/Aboba - 5 minutes Using DHCPv6 for DNS Configuration in Hosts draft-droms-dnsconfig-dhcpv6-01.txt Kim Kinnear - 10 minutes DHCP Lease Query draft-ietf-dhc-leasequery-02.txt Kim Kinnear - 10 minutes Subnet Selection sub-option for the Relay Agent Information Option draft-ietf-dhc-agent-subnet-selection-01.txt Bound/Droms - 10 minutes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) draft-ietf-dhc-dhcpv6-23.txt Vijayabhaskar A K - 30 minutes DHCPv6 (rev -23) Issues _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 10:28:06 2002 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 KAA00116 for ; Thu, 7 Mar 2002 10:28:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01927 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 10:28:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01635; Thu, 7 Mar 2002 10:24:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01604 for ; Thu, 7 Mar 2002 10:24:02 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29766 for ; Thu, 7 Mar 2002 10:23:57 -0500 (EST) Received: from BarrH63p601 ([63.193.193.26]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSM00CEZ040NK@mta5.snfc21.pbi.net> for dhcwg@ietf.org; Thu, 07 Mar 2002 07:24:01 -0800 (PST) Date: Thu, 07 Mar 2002 07:23:34 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] DHCP_DECLINE question In-reply-to: <4.3.2.7.2.20020306215847.037abc20@funnel.cisco.com> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Ralph Droms > Sent: Wednesday, March 06, 2002 19:00 <*Snip!*> > >...I agree that a client should not arbitrarily change it's > >mind about a lease, just observing that we don't seem to have > >fully specified all of the cases, and trying to shine a little > >daylight on one or two.... > > Yup, that's what I'm trying to get out of this conversation, too. > ...I think that while it is clear about the use of DHCPDECLINE to reject an address that the client believes is already in use, the wording of the RFC says nothing at all about other [mis-]uses of DHCPDECLINE, nor about other conditions that might cause a client to decide very late in the message exchange that it does not want to continue with the offered [and requested!] address. For example, what will happen if a client, happily using an address for a long time, reaches a renew point and issues a gratuitous ARP after receiving an ack for its lease: if an address conflict is detected, it could send a decline message and be completely within spec, but will all servers handle the decline message properly at this point in the lease lifetime? What about a client that periodically ARP's for its address without a protocol event to trigger it? Would a server properly handle a decline then? Stateless servers probably will have no trouble with such behavior, but will stateful? --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 10:35:29 2002 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 KAA00668 for ; Thu, 7 Mar 2002 10:35:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02801 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 10:35:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02622; Thu, 7 Mar 2002 10:32:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02591 for ; Thu, 7 Mar 2002 10:32:15 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00443 for ; Thu, 7 Mar 2002 10:32:10 -0500 (EST) Received: from BarrH63p601 ([63.193.193.26]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSM00CYU0HQNK@mta5.snfc21.pbi.net> for dhcwg@ietf.org; Thu, 07 Mar 2002 07:32:14 -0800 (PST) Date: Thu, 07 Mar 2002 07:31:47 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] DHCP_DECLINE question In-reply-to: <2E33960095B58E40A4D3345AB9F65EC103C09A39@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Thirumalesh Bhat > Sent: Wednesday, March 06, 2002 22:00 > <*Snip!*> > > If the client does a release after getting an ack because it > doesnt like some lease parameter and ends up in the init state, > the client may loop for ever. As Ted has mentioned, this is a > very unlikely real world scenario. > ...I disagree: a network with a single DHCP server is not likely to change option values for a specific lease/client pair, so a client that releases an address because of an issue with one or more option values will simply be offered the same lease, with the same option values, repeatedly. Having said that, such behavior on the part of the client, if not broken, is at least ill-conceived: clients should be a bit permissive in the option values they accept, accepting that the network administrator who configured the server has additional or global knowledge that resulted in the option values offered. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 10:58:34 2002 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 KAA02362 for ; Thu, 7 Mar 2002 10:58:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04209 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 10:58:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04140; Thu, 7 Mar 2002 10:56:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04107 for ; Thu, 7 Mar 2002 10:56:47 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02223 for ; Thu, 7 Mar 2002 10:56:42 -0500 (EST) Received: from BarrH63p601 ([63.193.193.26]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GSM00CTJ1MLKS@mta5.snfc21.pbi.net> for dhcwg@ietf.org; Thu, 07 Mar 2002 07:56:46 -0800 (PST) Date: Thu, 07 Mar 2002 07:56:19 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] Host Name option considerations draft In-reply-to: <200203070635.g276ZChh674128@jurassic.eng.sun.com> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: Carl Smith > Sent: Wednesday, March 06, 2002 22:35 > <*Snip!*> > > > That's not the intention. First, a clarification: the point is > > > that if a client sent the Host Name option, it MUST accept > the value that > > > the server returns. Upon further reflection, perhaps a bit > more should > > > be said: if a client requests a Host Name via the Parameter > Request List, > > > it MUST accept the value the server returns. > > > > > ...look at what you wrote, again: in the first part you specified the > > client sending the Host Name OPTION and in the second, > requesting the Host > > Name in the Parameter Request List -- the two are not the same > thing, which > > is where my disagreement arose. > > Yes, I know they're not the same thing (which is why I wrote that > ``perhaps a bit more should be said'' when I extended it to include the > Parameter Request List. There are now two questions to consider > > - if a client sends a Host Name option and the server responds with > a different name from the one the client requested, what must the > client do? > ...this presupposes that (1) the client sent its preferred Host Name to the server, but (2) did not include the Host Name option in the parameter request list. > - if a client requests a Host Name option be returned, > must it accept > the value the server returns, or choose to use its own? > ...this case is that the client (1) did not send its preferred Host Name to the server, but (2) did include the Host Name option in the parameter request list. > The language in the draft addresses only the first of these: if > a client sends > a Host Name option and the server responds with a Host Name > option, the client > needs to use the value the server returned, not continue the use > of the one it > (merely) requested. > ...this begs the question: "Should a server return a value for an option which is neither mandatory nor requested by the client?" as well as "If a client sends the server a suggested value for Host Name, is that equivalent to an entry for Host Name in the Parameter Request List?" and finally "If the server sends an unrequested [and non-mandatory] option, is the client obligated to use the value?" > The second one is more tenuous, but I believe the same > argument can be > made: by requesting a Host Name option be returned, is the > client agreeing to > use the value or is it just hoping to get lucky? If it's the > latter, then the > client should instead simply ask DNS what name corresponds to the > address the > server leased it. > ...I agree: if the client explicitly requests that a Host Name option be returned by including it's option number in the Parameter Request List, then it is obligated to use the returned value if it decides to accept the offered lease. We must answer the question about equivalence of Parameter Request List and suggested Host Name: if a suggested name implies a request for Host Name, then I agree that the client should accept the name offered by the server or decline [Not! Just teasing after the other ongoing discussion...] the offer. <*Snip!*> > > ...and I've also seen instances where clients certainly don't > follow these > > guidelines, but expect that option values won't change between > an offer and > > an ack. A reasonable expectation is that certain values (e.g., > Host Name > > and Domain Name) will not be changed by the server. > > I'm happy to add something to this draft that says the Host Name's > value should not change, but as you suggest the problem is larger > than just > one or two options. > ...that is a good example of a "best practice" with respect to Host Name and yes, this is like opening a can of worms..... --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 12:43:02 2002 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 MAA09907 for ; Thu, 7 Mar 2002 12:43:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16178 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 12:43:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15815; Thu, 7 Mar 2002 12:41:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15782 for ; Thu, 7 Mar 2002 12:40:57 -0500 (EST) Received: from beta.jnpr.net (natint.juniper.net [207.17.136.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09735 for ; Thu, 7 Mar 2002 12:40:49 -0500 (EST) Received: from antiproton.jnpr.net ([172.24.18.101]) by beta.jnpr.net with Microsoft SMTPSVC(5.0.2195.3779); Thu, 7 Mar 2002 09:40:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [dhcwg] DHCP_DECLINE question Date: Thu, 7 Mar 2002 09:40:23 -0800 Message-ID: <5B671CEC7A3CDA40BA4A8B081D7B046CFD782B@antiproton.jnpr.net> Thread-Topic: [dhcwg] DHCP_DECLINE question Thread-Index: AcHFkxABSt/8p1vgTYSIS4Wan93JWwAas1aA From: "Burcak Beser" To: "Ted Lemon" , "Ralph Droms" Cc: X-OriginalArrivalTime: 07 Mar 2002 17:40:23.0951 (UTC) FILETIME=[2912B9F0:01C1C5FF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA15786 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit I believe that right now the DCHP protocol is growing to include more than just the IP address but to fulfill the name 'Dynamic Host Configuration'. As with time the distinction between configuration and provisioning is getting blurred. If you look into the recent DHCP work you can see this happening we have Relay Agent Options (and suboptions), User Class Option, Lease Query. It is my impression is that even though the IP addressing issues are central to the DHCP supplied information the configuration extends beyond just IP. The real issue is that should we start to think about correcting/adding to the RFC such that the protocol would be extended to include more and more configuration/provisioning syntax. In short, even though we do not see any problems today with the DHC protocol, we need to think ahead. -burcak -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, March 06, 2002 8:41 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCP_DECLINE question > In my opinion, a client is within the spec if it sends a DHCPRELEASE > immediately after receiving a DHCPACK (for whatever reason). The > DHCPRELEASE will terminate the lease and make the address available for > reassignment without causing the server to mark the address as "not to be > assigned". True. > There is still the open question of whether we want to *recommend* this > behavior... Right. I'd say we shouldn't, because in all likelihood it's going to result in the client looping behavior about which Barr is concerned. I think that we are trying to fix a nonexistant problem here, and the fix seems much worse than the problem, particularly since I've never observed the problem happening in real life. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 12:46:34 2002 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 MAA10163 for ; Thu, 7 Mar 2002 12:46:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16491 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 12:46:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16292; Thu, 7 Mar 2002 12:44:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16264 for ; Thu, 7 Mar 2002 12:44:41 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10026 for ; Thu, 7 Mar 2002 12:44:37 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA28204 for ; Thu, 7 Mar 2002 12:44:09 -0500 (EST) Message-Id: <4.3.2.7.2.20020307124209.00b6dde8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Mar 2002 12:44:07 -0500 To: From: Ralph Droms Subject: RE: [dhcwg] DHCP_DECLINE question In-Reply-To: <5B671CEC7A3CDA40BA4A8B081D7B046CFD782B@antiproton.jnpr.net > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org So, Burcak - are you volunteering to revise RFC2131 and RFC2132 so we can take DHCP to full Internet Standard? Names of other volunteers will be gladly accepted; as much as I like writing DHCP specs, I'd be *real* happy to give someone else a chance... - Ralph At 09:40 AM 3/7/2002 -0800, Burcak Beser wrote: >I believe that right now the DCHP protocol is growing to include more >than just the IP address but to fulfill the name 'Dynamic Host >Configuration'. As with time the distinction between configuration and >provisioning is getting blurred. If you look into the recent DHCP work >you can see this happening we have Relay Agent Options (and suboptions), >User Class Option, Lease Query. It is my impression is that even though >the IP addressing issues are central to the DHCP supplied information >the configuration extends beyond just IP. The real issue is that should >we start to think about correcting/adding to the RFC such that the >protocol would be extended to include more and more >configuration/provisioning syntax. > >In short, even though we do not see any problems today with the DHC >protocol, we need to think ahead. > >-burcak > >-----Original Message----- >From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >Sent: Wednesday, March 06, 2002 8:41 PM >To: Ralph Droms >Cc: dhcwg@ietf.org >Subject: Re: [dhcwg] DHCP_DECLINE question > > > > In my opinion, a client is within the spec if it sends a DHCPRELEASE > > immediately after receiving a DHCPACK (for whatever reason). The > > DHCPRELEASE will terminate the lease and make the address available >for > > reassignment without causing the server to mark the address as "not to >be > > assigned". > >True. > > > There is still the open question of whether we want to *recommend* >this > > behavior... > >Right. I'd say we shouldn't, because in all likelihood it's going to >result in the client looping behavior about which Barr is concerned. >I >think that we are trying to fix a nonexistant problem here, and the fix >seems much worse than the problem, particularly since I've never >observed >the problem happening in real life. > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 15:37:16 2002 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 PAA22578 for ; Thu, 7 Mar 2002 15:37:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27383 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 15:37:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27103; Thu, 7 Mar 2002 15:31:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27076 for ; Thu, 7 Mar 2002 15:31:57 -0500 (EST) Received: from moutvdomng1.kundenserver.de (moutvdomng1.kundenserver.de [212.227.126.181]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21899 for ; Thu, 7 Mar 2002 15:31:52 -0500 (EST) Received: from [172.19.20.62] (helo=mrvdomng1.kundenserver.de) by moutvdomng1.kundenserver.de with esmtp (Exim 3.22 #2) id 16j4YN-0008CH-00 for dhcwg@ietf.org; Thu, 07 Mar 2002 21:31:55 +0100 Received: from [217.235.97.114] (helo=celeron1000) by mrvdomng1.kundenserver.de with smtp (Exim 3.22 #2) id 16j4YN-0005UW-00 for dhcwg@ietf.org; Thu, 07 Mar 2002 21:31:55 +0100 From: "Hans-Hermann Krost" To: Date: Thu, 7 Mar 2002 21:33:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C1C61F.B6B18E60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [dhcwg] Configuration of SCTP via DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1C61F.B6B18E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, does somebody know if it is possible to configure a SCTP/IP Stack via DHCP? Where can I get the necessary information? Note: SCTP (RFC 2960) is a protocol on a level like TCP or UDP Thanks and regards Hans-Hermann Email: Hans-Hermann@Krost-web.de ------=_NextPart_000_0000_01C1C61F.B6B18E60 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhkUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAwAHABUAIQAAAAQAHQEB A5AGAOgFAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAHwAAAENvbmZpZ3VyYXRpb24gb2YgU0NUUCB2aWEgREhDUAAAAgFxAAEAAAAWAAAAAcHGF1R/ CsVYXjIJEdaQrwCg0qX7ZQAAAgEdDAEAAAAfAAAAU01UUDpIQU5TLUhFUk1BTk5AS1JPU1QtV0VC LkRFAAALAAEOAAAAAEAABg4AZsJFF8bBAQIBCg4BAAAAGAAAAAAAAADqBv/iaRXVEY4mAmCM2z3C woAAAAsAHw4BAAAAAgEJEAEAAABsAQAAaAEAALkBAABMWkZ1SwRNQgMACgByY3BnMTI1FjIA+Atg bg4QMDMxTwH3AqQD4wIAY2gKwHOwZXQwIAcTAoB9CoGSdgiQd2sLgGQ0DGAOYwBQCwMLtSBIZWyd CQAsCqIKhAqAZG8HkQpzA3BlBuBkeSBrfG5vB+AGkBYQBUAEACAUcG8EEGkCYGUgdIRvIAWgbmZp ZwhwBRcgYQYAQ1RQL0nGUAYAAZBjayASIBgQAERIQ1A/ICBXFmgEkBcgYwORSSBnZxEwFzAZ0CBu BZAHkHMvCsAVsAuAAhByAMB0aQUCID8UOk5vdGU6ARgjIChSRkMgMrA5NjApFnIYEHADYLsXQAjh IAIgGAEXEHYT4OkfoGlrFyBUGXAfUAXAeFVEUBQ6CvMgUBDwbtZrHpESgCAJcGcLERCwtRRDSABx LRPQG+FuC5A9FElFAMADEB1gI6pAS6EDYHN0LXcVcC4BAC8K4yGlFDQR4QAogAsAAYAIIAYAAAAA AMAAAAAAAABGAAAAAAOFAAAAAAAAAwAQgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAI5qAQAeABKA CCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAAHgATgAggBgAAAAAAwAAAAAAAAEYA AAAANoUAAAEAAAABAAAAAAAAAB4AFIAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAA AAAeABWACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwAWgAggBgAAAAAAwAAA AAAAAEYAAAAAgoUAAAEAAAALAEOACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMARYAIIAYA AAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwBGgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAAD AEeACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAMAW4AIIAYAAAAAAMAAAAAAAABGAAAAAAGF AAAAAAAACwBsgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAACAfgPAQAAABAAAADqBv/iaRXV EY4mAmCM2z3CAgH6DwEAAAAQAAAA6gb/4mkV1RGOJgJgjNs9wgIB+w8BAAAAlgAAAAAAAAA4obsQ BeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XFdJTk5U XFByb2ZpbGVzXEFkbWluaXN0cmF0b3JcTG9jYWwgU2V0dGluZ3NcQW53ZW5kdW5nc2RhdGVuXE1p Y3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAOQAA ADxORkJCSU9DR09JR0dIRERKRkVOSEFFT01DQUFBLmhhbnMtaGVybWFubkBrcm9zdC13ZWIuZGU+ AAAAAAMABhBT0SUsAwAHENMAAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAASEVMTE8sRE9F U1NPTUVCT0RZS05PV0lGSVRJU1BPU1NJQkxFVE9DT05GSUdVUkVBU0NUUC9JUFNUQUNLVklBREhD UD9XSEVSRUNBTklHRVRUSEVORUNFU1NBUllJTkZPUk1BVAAAAAClLw== ------=_NextPart_000_0000_01C1C61F.B6B18E60-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 16:16:15 2002 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 QAA25076 for ; Thu, 7 Mar 2002 16:16:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29326 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 16:16:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29257; Thu, 7 Mar 2002 16:14:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29238 for ; Thu, 7 Mar 2002 16:14:25 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24961 for ; Thu, 7 Mar 2002 16:14:21 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g27LDsS01734 for ; Thu, 7 Mar 2002 15:13:54 -0600 (CST) 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 g27LDs515043 for ; Thu, 7 Mar 2002 15:13:54 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Mar 07 15:13:53 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 15:13:53 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4D094@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Hans-Hermann Krost'" , dhcwg@ietf.org Subject: RE: [dhcwg] Configuration of SCTP via DHCP Date: Thu, 7 Mar 2002 15:13:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C61C.F8C81290" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1C61C.F8C81290 Content-Type: text/plain; charset="iso-8859-1" I assume you want to configure values such as in section 14, Suggested SCTP Protocol Parameter Values? The answer is no ... noone has written an internet draft to specify parameters specific to SCTP. If you want this, please feel free to write a draft. Note that as DHCP(v4) option numbers are rather limited, perhaps a SCTP option should be defined with suboptions for each configurable parameter. That uses only 1 option out of the scarce DHCPv4 option space. I don't know much about the details of SCTP, but given the list in Section 14, you could have the suboption values be: SCTP Sub-Option Description Data Type ---------- ----------- --------- 1 RTO.Initial 16-bit integer (seconds) 2 RTO.Min 16-bit integer (seconds) 3 RTO.Max 16-bit integer (seconds) 4 RTO.Alpha 8-bit integer (1/value) 5 RTO.Beta 8-bit integer (1/value) 6 Valid.Cookie.Life 16-bit integer (seconds) 7 Association.Max.Retrans 16-bit integer (attempts) 8 Path.Max.Retrans 16-bit integer (attempts) 9 Max.Init.Retransmits 16-bit integer (attempts) 10 HB.interval 16-bit integer (seconds) - Bernie Volz Ericsson > -----Original Message----- > From: Hans-Hermann Krost [mailto:hans-hermann@krost-web.de] > Sent: Thursday, March 07, 2002 3:33 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Configuration of SCTP via DHCP > > Hello, > > does somebody know if it is possible to configure a SCTP/IP Stack via DHCP? Where can I get the necessary information? > > Note: SCTP (RFC 2960) is a protocol on a level like TCP or UDP > > Thanks and regards > Hans-Hermann > > Email: Hans-Hermann@Krost-web.de > ------_=_NextPart_001_01C1C61C.F8C81290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Configuration of SCTP via DHCP

I assume you = want to configure values such as in section 14, Suggested SCTP Protocol = Parameter Values? The answer is no ... noone has written an internet = draft to specify parameters specific to SCTP. If you want this, please = feel free to write a draft. Note that as DHCP(v4) option numbers are = rather limited, perhaps a SCTP option should be defined with suboptions = for each configurable parameter. That uses only 1 option out of the = scarce DHCPv4 option space.

I don't know = much about the details of SCTP, but given the list in Section 14, you = could have the suboption values be:

  = SCTP
Sub-Option   = Description          &= nbsp;  Data Type
----------   = -----------          &= nbsp;  ---------
  = 1          = RTO.Initial          &= nbsp;  16-bit integer (seconds)
  = 2          = RTO.Min           = ;      16-bit integer (seconds)
  = 3          = RTO.Max           = ;      16-bit integer (seconds)
  = 4          = RTO.Alpha          &nb= sp;    8-bit integer (1/value)
  = 5          = RTO.Beta          &nbs= p;     8-bit integer (1/value)
  = 6          = Valid.Cookie.Life       16-bit integer = (seconds)
  = 7          = Association.Max.Retrans 16-bit integer (attempts)
  = 8          = Path.Max.Retrans        16-bit = integer (attempts)
  = 9          = Max.Init.Retransmits    16-bit integer (attempts)
 10          = HB.interval          &= nbsp;  16-bit integer (seconds)

- Bernie = Volz
  = Ericsson

    -----Original Message-----
    From:   Hans-Hermann Krost [mailto:hans-hermann@krost-web.= de]
    Sent:   Thursday, March 07, 2002 3:33 PM
    To:     dhcwg@ietf.org
    Subject:       = [dhcwg] Configuration of SCTP via = DHCP

    Hello,

    does somebody know if it is possible = to configure a SCTP/IP Stack via DHCP?  Where can I get the = necessary information?

    Note: SCTP (RFC 2960) is a protocol on = a level like TCP or UDP

    Thanks and regards
    Hans-Hermann

    Email: Hans-Hermann@Krost-web.de =

------_=_NextPart_001_01C1C61C.F8C81290-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 17:16:26 2002 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 RAA28730 for ; Thu, 7 Mar 2002 17:16:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA02441 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 17:16:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02333; Thu, 7 Mar 2002 17:13:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02308 for ; Thu, 7 Mar 2002 17:13:35 -0500 (EST) Received: from yahoo.com ([211.106.170.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28441 for ; Thu, 7 Mar 2002 17:13:28 -0500 (EST) From: rte294@yahoo.com Message-Id: <200203072213.RAA28441@ietf.org> To: dhcwg@ietf.org Date: 08 Mar 2002 07:13:53 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_BmTorxYR_XbOasrWk_MA" Subject: [dhcwg] =?ISO-8859-1?B?KMirurgpw9awrcirurjHwbfOsde3pSEhyKu6uLDGwaSzoS4=?= Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org ------=_BmTorxYR_XbOasrWk_MA Content-Type: text/plain Content-Transfer-Encoding: 8bit -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- ------=_BmTorxYR_XbOasrWk_MA Content-Type: text/html Content-Transfer-Encoding: 8bit O본메일은정보통신망이용촉진및정보보호등에관한법률제50조에의거한[광고]메일입니다

O 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다
O e-mail주소는 인터넷상에서 취득하였으며, 주소외 어떠한 개인 정보도 가지고 있지 않습니다
수신거부를 원하시면 아래에서 수신거부 해 주세요.정보를 원치 않는 분께는 대단히 죄송 합니다.

♧♧♧ 홍보 때문에 걱정 하셨나요? 이젠 걱정 마세요. ♧♧♧
홍보에 대한 모든것과 노하우 여기 다 있습니다.
무었이든지 물어 보세요.  sejin14859@yahoo.com

▶▶▶ 이번에 홍보대행업 으로 전환함에따라
3년동안  모아놓은 홍보플그램을 염가로  다드림니다.◀◀◀

♥♥♥ 홍보초보용 ♥♥♥

♡이멜추출기2개 ♡이멜편집기1개 ♡이멜발송기2개(정품1,데모1)
♡이멜리스트50만개 ♡게시판등록기1개 ♡게시판디DB2000개

☞ 위의 모든것을 10만원에 다 드립니다. ☜

♥♥♥ 홍보중급용 ♥♥♥

♡이멜추출기3개 ♡이멜편집기1개 ♡이멜발송기3개(정품2개,데모1개)
♡이멜리스트100만개 ♡게시판등록기1개 ♡게시판DB5000개

☞ 위의 모든것을 20만원에 다 드립니다. ☜

♥♥♥ 홍보고급용(1) ♥♥♥

♠♠♠개인 홈페지에 이멜추출,발송기를 직접 설치 해 드립니다.♠♠♠

♡이멜추출기능♡이멜중복삭제기능♡수신거부자동기능♡이멜발송기능
♡수신거부자임시보내기♡임시거부자수신거부자로

☞설치가능한곳=홈페지에MYSQL계정이 있어야함
유료홈이 없는경우는 (200메가,일년호스팅4.4000원별도임)

☞ 위의 설치를 20만원에 해드립니다. ☜

♥♥♥ 홍보고급용(2) ♥♥♥

1000만개 이멜리스트를 올린서버를 몇사람에게만임대함니다.
(기간1년=가격100만원)홍보프로그램과 모든 노하우를 전부 전수 함니다.

◈◈◈ 이멜 광고 대행 ◈◈◈

그동안 홍보의 노하우로 2년에 걸쳐 발송시설을 완비 하고
6000만개의 이멜데이타를 구비하여 이멜홍보를 대행해 드립니다.

♡발송능력= 시간당 1000만통
♡이멜중복 완전제거, 산이멜채크=시간당40만통이상
♡타켓이멜만 분류 (지역,성별,업종,나이등 모든것 가능)

☞ 이멜발송 대행 가격은 10만통 기준 으로 10만원 이며,
살아있는 이멜만 채크해서 보내며, 효과 없으면 100% 환불 합니다.☜


전화폭주로 꼭필요하신분만 아래로 연락 주시면 안내 해드리겠습니다.
 ☞문의메일주실곳 sejin14859@yahoo.com

수신거부

------=_BmTorxYR_XbOasrWk_MA-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 21:35:33 2002 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 VAA09269 for ; Thu, 7 Mar 2002 21:35:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA14662 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 21:35:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14554; Thu, 7 Mar 2002 21:32:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14529 for ; Thu, 7 Mar 2002 21:32:40 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08254 for ; Thu, 7 Mar 2002 21:32:35 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA06026 for ; Thu, 7 Mar 2002 18:32:38 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.83.36]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id SAA25678 for ; Thu, 7 Mar 2002 18:32:45 -0800 (PST) Received: from kanawha (kanawha.Eng.Sun.COM [129.146.86.81]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g282WYhh864382 for ; Thu, 7 Mar 2002 18:32:34 -0800 (PST) Message-Id: <200203080232.g282WYhh864382@jurassic.eng.sun.com> To: dhcwg@ietf.org Subject: Re: [dhcwg] Host Name option considerations draft In-reply-to: mail from Richard Barr Hibbs dated Thu, 07 Mar 2002 07:56:19 PST Date: Thu, 07 Mar 2002 18:32:11 -0800 From: Carl Smith Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > > - if a client sends a Host Name option and the server responds with > > a different name from the one the client requested, what must the > > client do? > > > ...this presupposes that (1) the client sent its preferred Host Name to the > server, but (2) did not include the Host Name option in the parameter > request list. Actually, I wasn't presupposing (1) and (2). Instead, I was assuming I knew the answer to > as well as "If a > client sends the server a suggested value for Host Name, is that equivalent > to an entry for Host Name in the Parameter Request List?" ... but as you point out, > We must answer the question about equivalence of Parameter Request List and > suggested Host Name: if a suggested name implies a request for Host Name, > then I agree that the client should accept the name offered by the server or > decline [Not! Just teasing after the other ongoing discussion...] the > offer. that may have been unwarranted. This is a fine topic to discuss during our slot at the WG meeting. > ...this begs the question: "Should a server return a value for an option > which is neither mandatory nor requested by the client?" Hmm. Mandatory option? :-) If mandatory means anything other than ``the server's configured to do this'', I believe the answer has to be yes in order to cover the ability to satisfy this (2131, section 4.2) Specific DHCP server implementations may incorporate any controls or policies desired by a network administrator. > and finally "If > the server sends an unrequested [and non-mandatory] option, is the client > obligated to use the value?" Now *that* is a can of worms. Carl _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 7 23:32:58 2002 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 XAA13624 for ; Thu, 7 Mar 2002 23:32:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA20067 for dhcwg-archive@odin.ietf.org; Thu, 7 Mar 2002 23:33:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA19631; Thu, 7 Mar 2002 23:30:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA19595 for ; Thu, 7 Mar 2002 23:30:08 -0500 (EST) Received: from lbrout13.listbuilder.com ([204.71.191.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13135 for ; Thu, 7 Mar 2002 23:30:03 -0500 (EST) Received: (qmail 84581 invoked by uid 0); 8 Mar 2002 04:08:51 -0000 Date: 8 Mar 2002 04:08:51 -0000 Message-ID: <1015560531.93607.qmail@ech> To: List Member Reply-To: ResearchNetwork-feedback-1@lb.bcentral.com From: "ResearchNetwork.com" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA19596 Subject: [dhcwg] Research Network Job Site Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Expand Your Universe on the Research Network. Research Network is a job site devoted exclusively to professional Researchers and companies who need Researchers. It doesn't matter what industry you specialize in. Research Network encompasses a broad spectrum of industries and we continue to add more every day. For a comprehensive list of industries we work in like Pharmaceutical Research, Marketing Research, Clinical Research, Financial Research, Health Care Research, (to name a few), log on to http://www.researchnetwork.com and discover the infinite possibilities. If your an Employer, stop wasting your valuable time by posting your jobs on generalized job sites that inundate you with inappropriate candidates. If your looking for Scientists, Project Managers, Analysts, Statisticians, Clinical Researchers, Engineers, Planners, Developers, Upper Level Management within a Research function, (to name a few), go to the source and get your research job posting in front of over 1/2 million researchers on our Network. Click on the link below to find the exact research talent you need. http://www.researchnetwork.com/emplogin.cfm If your a professional Researcher and wish to be considered for positions by employers on our network, click on the link below to join the network. http://www.researchnetwork.com Expand Your Universe _______________________________________________________________________ Powered by List Builder To unsubscribe follow the link: http://lb.bcentral.com/ex/manage/subscriberprefs?customerid=20467&subid=DC3D1AD2877C767F&msgnum=1 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Mar 8 13:43:12 2002 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 NAA23817 for ; Fri, 8 Mar 2002 13:43:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23851 for dhcwg-archive@odin.ietf.org; Fri, 8 Mar 2002 13:43:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23682; Fri, 8 Mar 2002 13:39:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23665 for ; Fri, 8 Mar 2002 13:39:41 -0500 (EST) Received: from n1.groups.yahoo.com (n1.groups.yahoo.com [216.115.96.51]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23453 for ; Fri, 8 Mar 2002 13:39:39 -0500 (EST) X-eGroups-Return: notify-return-dhcwg=ietf.org@yahoogroups.com Received: from [216.115.96.169] by n1.groups.yahoo.com with NNFMP; 08 Mar 2002 18:39:10 -0000 Date: 8 Mar 2002 18:39:07 -0000 Message-ID: <1015612747.6340.14338.w79@yahoogroups.com> From: mplsissues moderator Reply-To: confirm-invite-DKMGLenhdKF7ZklkLYn8NPab=2s-dhcwg=ietf.org@yahoogroups.com To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Invitation to join the mplsissues group Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hello, You've been invited to join the mplsissues group, an email group hosted by Yahoo! Groups, a free, easy-to-use email group service. JOIN NOW, IT'S EASY: 1) REPLY to this email by clicking "Reply" and then "Send" in your email program -OR- 2) Go to the Yahoo! Groups site at http://groups.yahoo.com/invite/mplsissues?email=dhcwg%40ietf%2Eorg&iref=DKMGLenhdKF7ZklkLYn8NPab-2s By joining mplsissues, you will be able to exchange messages with other group members. Yahoo! Groups also makes it easy to store photos and files, coordinate events and more. Here's an introductory message from the group moderator: ------------------------------------------------------------------------ This is a group whereby you can share information and assist others with concern to MPLS/GMPLS technology issues, developments, implementations etc... ------------------------------------------------------------------------ If you do not wish to join the mplsissues group, please ignore this invitation. SPECIAL NOTE FROM Yahoo! Groups: Because Yahoo! Groups values your privacy, it is a violation of our service rules for moderators to abuse this invitation feature. If you feel this has happened, please notify us at abuse@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Mar 11 01:51:48 2002 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 BAA22108 for ; Mon, 11 Mar 2002 01:51:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA16606 for dhcwg-archive@odin.ietf.org; Mon, 11 Mar 2002 01:51:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16532; Mon, 11 Mar 2002 01:50:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16513 for ; Mon, 11 Mar 2002 01:50:00 -0500 (EST) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22060 for ; Mon, 11 Mar 2002 01:49:54 -0500 (EST) Received: from eos (eos.kwangwoon.ac.kr [128.134.65.124]) by explore.kwangwoon.ac.kr (8.11.6/8.11.6) with SMTP id g2B6pxO22278 for ; Mon, 11 Mar 2002 15:51:59 +0900 (KST) Message-ID: <004c01c1c8c8$eb966140$0101a8c0@kwangwoon.ac.kr> From: "want2sky" To: Date: Mon, 11 Mar 2002 15:49:41 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C1C914.5B74E180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [dhcwg] http://www1.ietf.org/mailman/listinfo/dhcwg Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C1C914.5B74E180 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQpodHRwOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo= ------=_NextPart_000_0049_01C1C914.5B74E180 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI2MDAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIHNpemU9 Mz48L0ZPTlQ+PEJSPjxBIA0KaHJlZj0iaHR0cDovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kaGN3ZyI+aHR0cDovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zzwv QT48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0049_01C1C914.5B74E180-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Mar 11 04:15:19 2002 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 EAA02186 for ; Mon, 11 Mar 2002 04:15:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA25736 for dhcwg-archive@odin.ietf.org; Mon, 11 Mar 2002 04:15:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25584; Mon, 11 Mar 2002 04:13:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25554 for ; Mon, 11 Mar 2002 04:13:56 -0500 (EST) Received: from localhost ([211.110.216.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02128 for ; Mon, 11 Mar 2002 04:13:51 -0500 (EST) Message-Id: <200203110913.EAA02128@ietf.org> Reply-To: 발신전용@yahoo.co.kr From: 대출지원<발신전용@yahoo.co.kr> To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Mon, 11 Mar 2002 18:10:43 +0900 Subject: [dhcwg] [광-고] 언제 어느 누구에게나 (카드연체, 창업지원, 일반지원) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 누구나 대출(20세이상)

 

F
                         
        누구나 대출(20세이상)

              060-708-4455

                   필요하신 자금을 원하시는 시간에                        대출해 드립니다 
      본사는 시중은행과 저축은행의 컨소시엄을     구성하여 은행으로 바로 대출 받을수 있습니다

                 전화한통으로 한방에 해결.....!
 
                       카드연체대납, 사업자금, 학자금,              주택구입자금,등등 3일이내 처리
 
                            080-708-4455

 귀하의 메일주소는 웹서핑중, http://www.xxxxxxxx.com/
에서 알게 된것이며, E-Mail 주소 외에, 다른 정보는 갖고 있지 않습니다.
 정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다. 원치 않으면 ,수신거부를 눌러주세요   

 

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Mar 11 05:36:16 2002 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 FAA03693 for ; Mon, 11 Mar 2002 05:36:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA02274 for dhcwg-archive@odin.ietf.org; Mon, 11 Mar 2002 05:36:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02227; Mon, 11 Mar 2002 05:35:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02199 for ; Mon, 11 Mar 2002 05:35:02 -0500 (EST) Received: from eugnpop1.eugn.uswest.net (eugnpop1.eugn.uswest.net [207.109.240.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03657 for ; Mon, 11 Mar 2002 05:34:57 -0500 (EST) Message-Id: <200203111034.FAA03657@ietf.org> Received: (qmail 12574 invoked by uid 0); 11 Mar 2002 10:34:59 -0000 Received: from unknown (HELO SOLTANI) (63.224.205.30) by eugnpop1.eugn.uswest.net with SMTP; 11 Mar 2002 10:34:59 -0000 Date: Mon, 11 Mar 2002 02:46:19 -0800 From: "Jamshid Pashutan" <> To: dhcwg@ietf.org Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: SA-SMTPMail 1.0 (http://www.aspstudio.com) Reply-To: pashutan@qwest.net Content-Transfer-Encoding: 7bit Subject: [dhcwg] Urgent! Iran! Can you help? Please also forward. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit The purpose of my letter is to introduce the Azadegan Foundation and to request your assistance. The Azadegan Foundation is a Not-for-Profit 501c3 organization dedicated to the promotion of democracy, human rights, and the establishment of a secular government in Iran. Our organization has a concrete, measurable strategy for facilitating change, and it is crucial for us at this juncture to secure your financial and moral support in order to accomplish our objectives. The clerical clique in Tehran views the world as a Mosque to be run by clerics who are inspired by the ecumenical revolutionary ideals of Ayatollah Khomeini. As each day passes, The Islamic regime of Tehran is ever increasing its covert political, financial, military and logistical support to a variety of terrorist groups. Citizens who have risen against the tyrannical rule of the clerics have been repressed brutally. Despite the danger they face, they are demanding that the regime put an end to its arbitrary rule, and to free political prisoners. Their struggle will continue and will intensify until the retreat of the ruling clerics to mosques, and the ultimate transfer of power to the people. Today, persecution of religious minorities continues, almost all pro-democracy newspapers have been shut down, and editors and writers have been imprisoned. Student leaders and all nationalist opposition leaders are being arrested and mercilessly tortured in prison, and women (even pregnant women) are stoned to death. Iran's population is now 70 million, with 45 million under 25 years of age. The economic situation and the over all standard of living is rapidly deteriorating. Discontent among the military, and even the Revolutionary Guard created by the regime, is ever increasing. Religious leaders and religious foundations totally control the economy. The Iranian people desire freedom, democracy, and the establishment of a secular Government. Please reply to this Email for more information about volunteering or supporting the Azadegan Foundation. Support the struggle of the Iranian people! Volunteers are always welcome. Contributions and Inquiries should be addressed to: Azadegan Foundation, PO Box 40152, Washington, DC 20016, USA Phone 541-606-3050 Fax 202-363-5985. Email: pashutan@qwest.net Thank you very much for your time and consideration in to this matter. I look forward to speaking with you further. Please forward this letter to your friends and associates. You can help make a difference! Sincerely Yours, Jamshid Pashutan Advocate for the People Please reply by Email, call us, fax, or snail mail us for more information and reference material. Email me at:: pashutan@qwest.net You received this Email because we aquire Email lists of individuals who may be interested in supporting the Iranian people and their struggle for freedom and democracy. If you have received this message in error, or if you do not wish any further communications from our office, Please respond with 'remove' in the subject line. To stop all Emails instantly, Email pashutan@qwest.net with subject of 'remove'. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Mar 11 10:01:04 2002 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 KAA10585 for ; Mon, 11 Mar 2002 10:01:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22032 for dhcwg-archive@odin.ietf.org; Mon, 11 Mar 2002 10:01:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21466; Mon, 11 Mar 2002 09:56:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21438 for ; Mon, 11 Mar 2002 09:56:52 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10332 for ; Mon, 11 Mar 2002 09:56:49 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2BEuMS13721 for ; Mon, 11 Mar 2002 08:56:22 -0600 (CST) Received: from noah.lmc.ericsson.se (noah.lmc.ericsson.se [142.133.1.1]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g2BEuMi17944 for ; Mon, 11 Mar 2002 08:56:22 -0600 (CST) Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134]) by noah.lmc.ericsson.se (8.11.2/8.9.2) with ESMTP id g2BEuLE18135 for ; Mon, 11 Mar 2002 09:56:21 -0500 (EST) Received: by EAMMLEX034.lmc.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 09:56:21 -0500 Message-ID: <7B2A7784F4B7F0409947481F3F3FEF830EE999@eammlnt051.lmc.ericsson.se> From: "Marco De Martin (LMC)" To: "'dhcwg@ietf.org'" Date: Mon, 11 Mar 2002 09:56:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] RE: dhcwg digest, Vol 1 #192 - 1 msg Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] Sent: Saturday, March 09, 2002 12:00 PM To: dhcwg@ietf.org Subject: dhcwg digest, Vol 1 #192 - 1 msg Send dhcwg mailing list submissions to dhcwg@ietf.org To subscribe or unsubscribe via the web, visit https://www1.ietf.org/mailman/listinfo/dhcwg or, via email, send a message with subject or body 'help' to dhcwg-request@ietf.org You can reach the person managing the list at dhcwg-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcwg digest..." Today's Topics: 1. Invitation to join the mplsissues group (mplsissues moderator) --__--__-- Message: 1 Date: 8 Mar 2002 18:39:07 -0000 From: mplsissues moderator Reply-To: confirm-invite-DKMGLenhdKF7ZklkLYn8NPab=2s-dhcwg=ietf.org@yahoogroups.com To: dhcwg@ietf.org Subject: [dhcwg] Invitation to join the mplsissues group Hello, You've been invited to join the mplsissues group, an email group hosted by Yahoo! Groups, a free, easy-to-use email group service. JOIN NOW, IT'S EASY: 1) REPLY to this email by clicking "Reply" and then "Send" in your email program -OR- 2) Go to the Yahoo! Groups site at http://groups.yahoo.com/invite/mplsissues?email=dhcwg%40ietf%2Eorg&iref=DKMG LenhdKF7ZklkLYn8NPab-2s By joining mplsissues, you will be able to exchange messages with other group members. Yahoo! Groups also makes it easy to store photos and files, coordinate events and more. Here's an introductory message from the group moderator: ------------------------------------------------------------------------ This is a group whereby you can share information and assist others with concern to MPLS/GMPLS technology issues, developments, implementations etc... ------------------------------------------------------------------------ If you do not wish to join the mplsissues group, please ignore this invitation. SPECIAL NOTE FROM Yahoo! Groups: Because Yahoo! Groups values your privacy, it is a violation of our service rules for moderators to abuse this invitation feature. If you feel this has happened, please notify us at abuse@yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ --__--__-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg End of dhcwg Digest _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Mar 11 13:49:03 2002 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 NAA19085 for ; Mon, 11 Mar 2002 13:49:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA08402 for dhcwg-archive@odin.ietf.org; Mon, 11 Mar 2002 13:49:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08186; Mon, 11 Mar 2002 13:46:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08167 for ; Mon, 11 Mar 2002 13:46:20 -0500 (EST) Received: from mail.ajusco.upn.mx (mail.ajusco.upn.mx [200.23.113.91]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18978 for ; Mon, 11 Mar 2002 13:46:14 -0500 (EST) Received: from localhost (ivan@localhost) by mail.ajusco.upn.mx (8.11.2/8.11.2) with ESMTP id g2BIuu704541 for ; Mon, 11 Mar 2002 12:56:56 -0600 Date: Mon, 11 Mar 2002 12:56:56 -0600 (CST) From: Ivan Rodriguez Aguilar X-X-Sender: To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] DHCP & VLANS Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hello i have 35 vlans configuration the equipment is a passport8000 and asn the nortel networks, the dhcp-relay agent has been configuration successful show the problem. Mar 11 12:40:36 proxy dhcpd: DHCPDISCOVER from 00:20:af:e1:d4:ed via 10.20.4.254 Mar 11 12:40:37 proxy dhcpd: DHCPOFFER on 10.20.8.67 to 00:20:af:e1:d4:ed via 10.20.4.254 Mar 11 12:40:37 proxy dhcpd: DHCPREQUEST for 10.20.8.67 from 00:20:af:e1:d4:ed via 10.20.4.254 Mar 11 12:40:37 proxy dhcpd: DHCPACK on 10.20.8.67 to 00:20:af:e1:d4:ed via 10.20.4.254 my question is somebody work with vlans and dhcp ?? it works correctly ? please send me the howto my version of the dhcp is dhcp-2.0pl5-4 please help me my dhcpd.conf is growing by each maquina I have add a line in the file dhcpd.conf I am becoming crazy _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 12 12:00:44 2002 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 MAA27464 for ; Tue, 12 Mar 2002 12:00:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25469 for dhcwg-archive@odin.ietf.org; Tue, 12 Mar 2002 12:00:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24317; Tue, 12 Mar 2002 11:57:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28717 for ; Sun, 10 Mar 2002 23:04:46 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20153 for ; Sun, 10 Mar 2002 23:03:53 -0500 (EST) Received: from cyclops.soft.net (www.stpibonline.soft.net [164.164.128.17] (may be forged)) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g2B3RE216681 for ; Sun, 10 Mar 2002 22:27:14 -0500 (EST) Received: from Bhishma.Kshema.com (valmiki.kshema.com [164.164.59.2]) by cyclops.soft.net (Switch-2.0.1/Switch-2.0.1) with SMTP id g2BCVTe11437 for ; Mon, 11 Mar 2002 07:31:31 -0500 (GMT) Received: from SMTP agent by mail gateway Mon, 11 Mar 2002 09:03:00 --5-30 Received: by BHISHMA with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Mar 2002 08:58:52 +0530 Message-ID: <91A7E7FABAF3D511824900B0D0F95D1071DC0B@BHISHMA> From: Prakash P To: dhcp-v4@bucknell.edu Date: Mon, 11 Mar 2002 08:58:44 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] DHCP Client Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi, In Linux operating system, Where the DHCP client stores the information about DNS like DNS server address, domain name etc which it get's from the DHCP server. If the Linux box which is acting like a DHCP client, wants to browse the internet, then the DNS client on the same box from where it will get the DNS server address to resolve the FQDN? Thanks and Regards Prakash P Kshema Technologies Ltd., Kshema Dhama, Bangalore Board No:- 91-80-8603600-10, Extn:- 1200 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue Mar 12 13:52:02 2002 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 NAA01323 for ; Tue, 12 Mar 2002 13:52:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01553 for dhcwg-archive@odin.ietf.org; Tue, 12 Mar 2002 13:52:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01479; Tue, 12 Mar 2002 13:50:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26004 for ; Tue, 12 Mar 2002 12:02:05 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27520 for ; Tue, 12 Mar 2002 12:01:59 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g2CH21230700 for ; Tue, 12 Mar 2002 12:02:02 -0500 (EST) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g2CGv2X20083; Tue, 12 Mar 2002 08:57:02 -0800 (PST) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g2CH1Ys01112; Tue, 12 Mar 2002 11:01:34 -0600 (CST) Date: Tue, 12 Mar 2002 11:01:34 -0600 Subject: Re: [dhcwg] DHCP Client Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: dhcp-v4@bucknell.edu To: Prakash P From: Ted Lemon In-Reply-To: <91A7E7FABAF3D511824900B0D0F95D1071DC0B@BHISHMA> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Normally the Linux dhcp client will write a /etc/resolv.conf file based on the information sent by the DHCP server, and the DNS resolver on Linux will use the information in the /etc/resolv.conf to satisfy DNS lookup requests. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Tue Mar 12 22:40:18 2002 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 WAA18308 for ; Tue, 12 Mar 2002 22:40:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA05236 for dhcwg-archive@odin.ietf.org; Tue, 12 Mar 2002 22:40:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05140; Tue, 12 Mar 2002 22:38:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA05121 for ; Tue, 12 Mar 2002 22:38:27 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18227 for ; Tue, 12 Mar 2002 22:38:21 -0500 (EST) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g2D3XMX21606; Tue, 12 Mar 2002 19:33:23 -0800 (PST) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g2D3bus02075; Tue, 12 Mar 2002 21:37:56 -0600 (CST) Date: Tue, 12 Mar 2002 21:37:56 -0600 Subject: Re: [dhcwg] DHCP Client Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: dhcwg@ietf.org To: Prakash P From: Ted Lemon In-Reply-To: <91A7E7FABAF3D511824900B0D0F95D10764245@BHISHMA> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hm, may I suggest that you read the source code for the DHCP client? The mechanism for the things you're asking about has to be similar, but you haven't even told us which client you're using. You need to determine: - which client you are using. - is it actually doing what you think it is doing? - Where is the source code? - Where in the source code is it doing the things about which you have questions When you have answered these questions, you should be able to figure out the answers to the questions you just asked very easily. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 13 07:18:56 2002 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 HAA03048 for ; Wed, 13 Mar 2002 07:18:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA10842 for dhcwg-archive@odin.ietf.org; Wed, 13 Mar 2002 07:18:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10689; Wed, 13 Mar 2002 07:11:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10664 for ; Wed, 13 Mar 2002 07:11:36 -0500 (EST) Received: from localhost (s210-205-163-222.thrunet.ne.kr [210.205.163.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02940 for ; Wed, 13 Mar 2002 07:11:32 -0500 (EST) Message-Id: <200203131211.HAA02940@ietf.org> Reply-To: sj3589@netian.com From: test To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Wed, 13 Mar 2002 21:11:53 +0900 Subject: [dhcwg] [광고] 네트웍 마케팅 2002년 2월 25일 오픈 , 뉴트리션 포 라이프 관심있으신분보세요 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org

 

귀하의 메일주소는 웹 서핑중 알게된 것이며, E-Mail 주소 외에 다른 정보는 갖고 있지
않습니다. 정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다.
또한 원치 않는 분들을 위해 수신거부 장치를 필히 마련하고 있습니다.

★★★최고의 사업, 최고의 타이밍, 뉴트리션 포 라이프(온라인 무료가입부터 서두르세요)★★★

이글을 끝까지 읽어보시고 저와같이 사업에 동참을 하시는분들은 행운을 잡으셨다고 과감히 말할 수 있습니다.

홈페이지

◆2월25일OPEN (4월달 그랜드 오픈)◆【뉴트리션 포 라이프 최강라인

-★★★온라인 무료가입부터 서두르세요★★★

가입과 동시에 저와 같은 자동홍보용 홈페이지를 무료로 제공합니다.

회원가입을 하시땔 본인이 만드신 아이디를 갖고 바로 홍보가 가능합니다.

http://ebiz7.net/myteam/index.php?id=본인아이디  

위에것이 본인의 홈페이지가 됩니다.

예를 들면 회원가입시 본인의 아이디가  sj3589 이었다면,

본인의 홈페이지는 http://ebiz7.net/myteam/index.php?id=sj3589  이 되는 것입니다.

이것을 눌러보시면 본인의 이름이 홈페이지에 나오는 것을 보실수 있습니다.

함께하기 때문에 모두가 성공할 수 있습니다.

네트워크 마케팅 관련 동영상을 보세요. 동영상1, 동영상2, 동영상3

회사 공식 홈페이지는 www.nflikorea.com 이고 마케팅과 보상플랜을 꼭 보세요.

글로벌 홈은 (세계각국)  www.nutritionforlife.com  입니다. 온라인 쇼핑몰도 둘러보세요.

우리 회사에 관해서

1. http://www.inews.org/Snews/articleshow.php?Domain=mlmch&No=86
   네트워크 마케팅 월간 잡지의 인터뷰입니다.
2. http://www.marketwaveinc.com/top10.htm
     마켓웨이브에 실린 MLM순위 탑10 입니다. (알파벳 순입니다.) 

지금 온라인 가상회원으로 등록부터 하셔서 당신의 아래에 1단계 4명, 2단계 16명 3단계 64명의

예비사업자가 자동 형성되는 것을 직접 확인하세요.

눈으로 보고 싶은가요 ? 본인의 아이디로 가입 후 위와 같이 홈페이지를 생성하면 바로 보입니다.

가만히 있어도 하루에 100명이상의 DOWN이 들어 옵니다.

보너스 플랜에서 보여주듯이 4단계 까지의 사업자만 형성(340명) 되어도 상당한 수입을(매월 최소 400만원이상) 보장 받을 수 있습니다.

현재 하루에 100명이 훨씬넘는 사람들이 가입을 하고 있습니다. 거짓말 같이 느껴지시나요?

한번 가입해보시고, 몇 시간만 기다려보십시요! 최소 10명이상의 사람들이 가입을 할 것이고, 하루가 지나면 100명이 훨씬넘는 사람들이

여러분 밑의 다운으로 들어올 것입니다. 만약 더 의심이 되시는 분은 친구나 주위의 아는분의 이름으로 다시 한번 가입을 해보십시요.

그분이 여러분의 다운으로 생성되는것을 보실수 있을것입니다.

그러니 4단계 까지의 다운을 형성하는 것은 시간문제일것입니다.

지금 서둘러 가상회원등록(무료)부터 하셔서 자신의 위치부터 확보해 두세요.

이렇게 훌륭한 시스템에 빨리 가입하지 않으면 평생 후회합니다.

지금이 당신에게 가장 빠른 시기입니다.

지금 서둘러서 2,3개월 뒤의 모습을 그려보십시요.

바로 행동으로 옮겨 일생일대 최대의 행운을 움켜 잡읍시다. 등록은 계속됩니다.

빨리 가상회원 등록하세요

새로운 님의 미래를 <NFLI>에서 시작하십시요..
NFLI 의비젼은 세계인이 증명하였습니다.

세계20여개국에서 한번의 실패도 없이 85% 재구매율이라는
경이적인 실적으로 성장하고 있습니다.

580여 가지의 다양한 상품군과 70%의 자체생산으로 가격이나
품질경쟁력에서 타회사의 우위를 고수할 수 있는 원인이라 할 수 있습니다.

(제품 : 생활용품, 세재류, 건강식품, 화장품, 주방용품, 허벌제품, 개인용품
다이어트식품, 커피와 차류, 스낵류, 미네랄 케어, 바이오워트 기타)

그런데 회사가 아무리 좋다고 님이 성공을 하는것은 아니겠지요...
4명의 메트릭스방식으로 구성되는 래그에서 님은 어떤 라인에서 사업을
하느냐도 중요한 문제이니 신중하게 결정을 해야겠지요.

우리 클럽은 가상회원이라는 제도를 구축하여 가입회원의 모든 네트웍회사의
비젼을 확인하고 가입을 하게끔 시도하여 엄청난 호응을 불러일으키고 있습니다.

하루 100명 이상의 회원이 새로운 사업을 저희클럽에서 시도하고 있습니다.
님이 동참의사가 있으시다면 첫걸음부터 안내하겠습니다.
님은 최소한의 의지만 있으면 됩니다.
모든 PLAN은 저희가 이미 준비하였습니다.
님은 합류만하면 됩니다.

온라인 무료등록하시고 다운라인 형성되는것 직접
파트너 조회에서 확인하세요...
당신과 당신이 홍보하여 형성되는 파트너까지
모두 홈페이지를 실시간으로 지원합니다.

아래 홈페이지에서 회원가입을 하십시요. 그리고 연락을 주십시요.

메일은 이 주소로 해 주세요  dduckman@korea.com

단 만 20세 이상만 가입가능합니다.

홈페이지

익스플로러6에서는 홈페이지에 가서 너무 오래 있으면 (30분정도)

가상회원등록시 추천인 아이디가 나오지 않는 경우가 있습니다.

추천인이 없으면 가입이 안 될  수도 있으므로 익스플로러를 나갔다가 다시

들어오세요. 꼭 추천인이 있을 경우에 가입하시기 바랍니다. 불이익이 없도록 하세요.

수신거부는 이곳을 눌러주세요.

 

 


 
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 14 21:06:28 2002 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 VAA08125 for ; Thu, 14 Mar 2002 21:06:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA26985 for dhcwg-archive@odin.ietf.org; Thu, 14 Mar 2002 21:06:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26239; Thu, 14 Mar 2002 21:03:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA26136 for ; Thu, 14 Mar 2002 21:03:17 -0500 (EST) Received: from email4.gm20.com (email4.gm20.com [164.109.174.93]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07798 for ; Thu, 14 Mar 2002 21:03:14 -0500 (EST) Message-ID: <2751306.1016157796509.Kada.Kada1(pc-93)@email4.gm20.com> Date: Thu, 14 Mar 2002 21:03:16 -0500 (EST) From: "Northland Systems Training Inc." To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] Two Day MPLS Course Toronto April 8-9 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: quoted-printable
3D""=A0= =A03D""

2 Day Multi-Protocol Label Switching (MPLS)
Course Toro= nto April 8-9



Due to the popularity of this course, Northland, the = leader in complex technical eLearning and instructor-led training, is runni= ng its non-vendor specific MPLS course again in Toronto on April 8-9. Part= icipants need a strong understanding and experience in WANs, LANs, data com= munications, routing, internetworking and communications protocols. Seati= ng is limited to 20, so register immediately to reserve your spot.

This course addresses the challenge of next generatio= n networks and describes MPLS concepts, architecture and components, and pr= actical solutions. For more information and a detailed course outline foll= ow the link below.

Join the thousands of satisfied students who have tak= en Northland's high quality, industry leading courses to increase their ski= lls, and maintain their knowledge in the fast paced telecom market.

Additional course information and registration=

Upon completion of this course you receive 30 days acc= ess to the Northland on-line MPLS course.

Anyone registering two or more people on any of Northl= and=92s instructor-led courses will receive a complimentary Northland denim= shirt.

Please forward the email to any colleagues or clients= who would be interested in this course.


Thank you for your interest.

Sincerely,

Alan P. Daly
Account Manager
Northland Systems Training Inc.
255 Albert Street, Suite 500
Ottawa, Ontario
K1P 6A9

Direct:=09(613) 667-5063
Cell:=09(613) 223-1062
Fax:=09(613) 667-5098

"Changing learning from an event to a life long process"

KNOW YOUR WAY
visit www.northlandeLearning.= com



Click here to unsubscribe from our mailing list. Or reply to th= is message with the word unsubscribe in the subject line.


_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Fri Mar 15 22:29:51 2002 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 WAA17584 for ; Fri, 15 Mar 2002 22:29:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA13696 for dhcwg-archive@odin.ietf.org; Fri, 15 Mar 2002 22:29:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13539; Fri, 15 Mar 2002 22:27:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04393 for ; Tue, 12 Mar 2002 22:26:55 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17184 for ; Tue, 12 Mar 2002 22:26:50 -0500 (EST) Received: from cyclops.soft.net (relay1.soft.net [164.164.128.17]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g2D3Qo203851 for ; Tue, 12 Mar 2002 22:26:51 -0500 (EST) Received: from Bhishma.Kshema.com (valmiki.kshema.com [164.164.59.2]) by cyclops.soft.net (Switch-2.0.1/Switch-2.0.1) with SMTP id g2DCUse10634; Wed, 13 Mar 2002 07:30:55 -0500 (GMT) Received: from SMTP agent by mail gateway Wed, 13 Mar 2002 09:02:27 --5-30 Received: by BHISHMA with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 08:58:16 +0530 Message-ID: <91A7E7FABAF3D511824900B0D0F95D10764245@BHISHMA> From: Prakash P To: Ted Lemon Cc: dhcp-v4@bucknell.edu Subject: RE: [dhcwg] DHCP Client Date: Wed, 13 Mar 2002 08:58:15 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi Ted Thanks for your valuable information. Same way I need some more information. How the DHCP client in Linux pass the network parameters that it get's from the DHCP server to the clients like NFS client, TFTP client and NTP client? 1. DHCP client will get the NFS related information from the DHCP server, like server address and the directory to mount. How this information will be passed on to the NFS client on the Linux box to mount the remote directory from the server? (In a diskless client) 2. DHCP client will get the TFTP related information from the DHCP server like Server address and the path of the image file to boot/load. How this information will be passed on to the TFTP client on the Linux box during the remote booting (In a diskless client) 3. DHCP client will get the NTP related information from the DHCP server like NTP server address. How this information will be passed on to the NTP client on the Linux box to synchronize the Time with the server. Thanks and Regards Prakash P Kshema Technologies Ltd., Kshema Dhama, Bangalore Board No:- 91-80-8603600-10, Extn:- 1200 -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Tuesday, March 12, 2002 10:32 PM To: Prakash P Cc: dhcp-v4@bucknell.edu Subject: Re: [dhcwg] DHCP Client Normally the Linux dhcp client will write a /etc/resolv.conf file based on the information sent by the DHCP server, and the DNS resolver on Linux will use the information in the /etc/resolv.conf to satisfy DNS lookup requests. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Fri Mar 15 22:31:54 2002 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 WAA18518 for ; Fri, 15 Mar 2002 22:31:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA14278 for dhcwg-archive@odin.ietf.org; Fri, 15 Mar 2002 22:31:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13623; Fri, 15 Mar 2002 22:29:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05282 for ; Wed, 13 Mar 2002 05:11:36 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01729 for ; Wed, 13 Mar 2002 05:11:32 -0500 (EST) Received: from hotmail.com (f32.pav2.hotmail.com [64.4.37.32]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g2DABY201024; Wed, 13 Mar 2002 05:11:34 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Mar 2002 02:11:18 -0800 Received: from 62.189.159.253 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 13 Mar 2002 10:11:18 GMT X-Originating-IP: [62.189.159.253] From: "ade a" To: dhcp-v4@bucknell.edu Cc: dhcp-impl@bucknell.edu Date: Wed, 13 Mar 2002 10:11:18 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 13 Mar 2002 10:11:18.0855 (UTC) FILETIME=[6B05DD70:01C1CA77] Subject: [dhcwg] Techincal Question Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Wonder if you can help in anyway. I have a strange question that has just been put to me. Windows 2000 server DHCP. A colleague of mine says that he has set up his DHCP server to grant 1 user a permanent address, all other users are given the usual DHCP released address's, what he wants to know is how can he prove that he assigned this IP address to that certain user, in other words can we prove it is tied to that certain users MAC address. He said he assigned the IP Address in January so can you think of any way I can or we can prove this from the DHCP server, either an audit or command or something. Any help appreciated, urgently. Thankyou in advance. Adrian. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Fri Mar 15 23:26:36 2002 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 WAA18516 for ; Fri, 15 Mar 2002 22:31:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA14279 for dhcwg-archive@odin.ietf.org; Fri, 15 Mar 2002 22:31:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA13662; Fri, 15 Mar 2002 22:29:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA04450 for ; Tue, 12 Mar 2002 22:27:51 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17190 for ; Tue, 12 Mar 2002 22:27:46 -0500 (EST) Received: from cyclops.soft.net (relay1.soft.net [164.164.128.17]) by mail.bucknell.edu (8.11.6/8.11.6) with ESMTP id g2D3Rl201583 for ; Tue, 12 Mar 2002 22:27:47 -0500 (EST) Received: from Bhishma.Kshema.com (valmiki.kshema.com [164.164.59.2]) by cyclops.soft.net (Switch-2.0.1/Switch-2.0.1) with SMTP id g2DCW0e10680 for ; Wed, 13 Mar 2002 07:32:02 -0500 (GMT) Received: from SMTP agent by mail gateway Wed, 13 Mar 2002 09:03:32 --5-30 Received: by BHISHMA with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Mar 2002 08:59:21 +0530 Message-ID: <91A7E7FABAF3D511824900B0D0F95D10764246@BHISHMA> From: Prakash P To: dhcp-v4@bucknell.edu Date: Wed, 13 Mar 2002 08:59:21 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] DHCP Client Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org How the DHCP client in Linux pass the network parameters that it get's from the DHCP server to the clients like NFS client, TFTP client and NTP client? 1. DHCP client will get the NFS related information from the DHCP server, like server address and the directory to mount. How this information will be passed on to the NFS client on the Linux box to mount the remote directory from the server? (In a diskless client) 2. DHCP client will get the TFTP related information from the DHCP server like Server address and the path of the image file to boot/load. How this information will be passed on to the TFTP client on the Linux box during the remote booting (In a diskless client) 3. DHCP client will get the NTP related information from the DHCP server like NTP server address. How this information will be passed on to the NTP client on the Linux box to synchronize the Time with the server. Thanks and Regards Prakash P Kshema Technologies Ltd., Kshema Dhama, Bangalore Board No:- 91-80-8603600-10, Extn:- 1200 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 20 01:48:38 2002 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 BAA16906 for ; Wed, 20 Mar 2002 01:48:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA25740 for dhcwg-archive@odin.ietf.org; Wed, 20 Mar 2002 01:48:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25563; Wed, 20 Mar 2002 01:46:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25542 for ; Wed, 20 Mar 2002 01:46:04 -0500 (EST) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16849 for ; Wed, 20 Mar 2002 01:46:00 -0500 (EST) Received: from tanhl (tanhl.cwc.nus.edu.sg [172.16.2.66]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id OAA22883 for ; Wed, 20 Mar 2002 14:44:43 +0800 (SGT) Message-ID: <010501c1cfdc$020b6320$420210ac@tanhl> From: "Paul Tan" To: References: <8100000.1011889314@elgar> Date: Wed, 20 Mar 2002 14:53:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Question on DHCPv6 Draft 23. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi all, we are currently trying to implement a DHCPv6 client/server (draft 23) in Linux environment. Are there any active implementations working on the latest DHCP draft 23 ? I have a few questions concerning the DHCPv6 draft 23. 1) After a client sends out a SOLICIT with an IA option attached (no IA Addr Opt), the server will basically reply with an ADVERTISE message with some addresses attached in the IA Addr options. - Does the lifetime for this IA starts after the server sends the ADVERTISE message ? How does the server knows whether if the client has decided to use the address advertised by this server, when in fact the client has chosen some other server ? 2) When the client receives the ADVERTISE message, it will attempt to configure its interface with the assigned address from the list of server's ADVERTISE messages. - Does it need to send a REQUEST message immediately after the ADVERTISE message to confirm that the client is using the address from a particular server? - What is the main purpose of the REQUEST message ? Get the configuration info of a particular IA ? 3) I'm a bit confused with the following paragraph in the draft... - ... if the server will not assign any addresses to IAs in a subsequent REQUEST from the client, the server SHOULD either send an ADV message to the client that includes only a status code option (AddrUnavail) for the user or not respond to the SOLICIT message.... Thank you for your kind attention. Regards, Paul Institute for Communications Research _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 20 16:56:32 2002 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 QAA16380 for ; Wed, 20 Mar 2002 16:56:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16175 for dhcwg-archive@odin.ietf.org; Wed, 20 Mar 2002 16:56:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15787; Wed, 20 Mar 2002 16:47:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15758 for ; Wed, 20 Mar 2002 16:47:56 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16041 for ; Wed, 20 Mar 2002 16:47:51 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2KLlOi20352 for ; Wed, 20 Mar 2002 15:47:24 -0600 (CST) 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 g2KLlO614187 for ; Wed, 20 Mar 2002 15:47:24 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Mar 20 15:47:23 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 15:47:23 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69CEC639@EAMBUNT705> From: "Bernie Volz (EUD)" To: Paul Tan , dhcwg@ietf.org Subject: RE: [dhcwg] Question on DHCPv6 Draft 23. Date: Wed, 20 Mar 2002 15:47:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D058.D0909400" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D058.D0909400 Content-Type: text/plain; charset="iso-8859-1" Paul: See comments below, prefixed by BV>. - Bernie -----Original Message----- From: Paul Tan [mailto:tanpaul@cwc.nus.edu.sg] Sent: Wednesday, March 20, 2002 1:54 AM To: dhcwg@ietf.org Subject: [dhcwg] Question on DHCPv6 Draft 23. Hi all, we are currently trying to implement a DHCPv6 client/server (draft 23) in Linux environment. Are there any active implementations working on the latest DHCP draft 23 ? I have a few questions concerning the DHCPv6 draft 23. 1) After a client sends out a SOLICIT with an IA option attached (no IA Addr Opt), the server will basically reply with an ADVERTISE message with some addresses attached in the IA Addr options. - Does the lifetime for this IA starts after the server sends the ADVERTISE message ? How does the server knows whether if the client has decided to use the address advertised by this server, when in fact the client has chosen some other server ? BV> The lifetimes in the Advertise are in one sense meaningless since there BV> is no contract between client and server regarding these. Only after the BV> Request/Reply sequence can a client use the addresses and do the lifetimes BV> apply. The lifetimes in the Advertise, IMHO, should be the ones the server BV> INTENDS to give the client in a future Reply should the client chose the BV> server. If the server does take steps to reserve the addresses for the BV> client, it may actually do this with a much shorter lifetime. But that is BV> not what it sends to the server. BV> BV> The lifetimes apply based on when the client RECEIVES the message, not BV> when the server sent it (since the client has no way of knowing this). BV> This also typically means a server has a small grace period that it BV> applies to "extend" the lifetimes to allow for a small difference in BV> the times between client and server (note also that clock speeds on BV> systems may vary slightly as well). But, the T1/T2 times should also be BV> choosen by servers to allow plenty of time for renewals. 2) When the client receives the ADVERTISE message, it will attempt to configure its interface with the assigned address from the list of server's ADVERTISE messages. BV> NO!!! You can not do this until after the Request/Reply sequence!!!! - Does it need to send a REQUEST message immediately after the ADVERTISE message to confirm that the client is using the address from a particular server? - What is the main purpose of the REQUEST message ? Get the configuration info of a particular IA ? BV> It is to get the actual address assignments and configuration. Information BV> that is received in the Advertise is only an advertisement for service and BV> not an offer for server. BV> The Solicit/Advertise is a way for a client to determine what servers are BV> likely to offer it. BUT, the Requeset/Reply is the actual negotiation of BV> what the client gets. BV> Think of this as advertisements you get in the mail. They are to bring you BV> in to the store. But, you actually have to buy something to take advantage BV> of the advertisements. That is the Request/Reply phase. 3) I'm a bit confused with the following paragraph in the draft... - ... if the server will not assign any addresses to IAs in a subsequent REQUEST from the client, the server SHOULD either send an ADV message to the client that includes only a status code option (AddrUnavail) for the user or not respond to the SOLICIT message.... BV> What's are you confused about regarding this? I think my above comments BV> make it clear that the Request/Reply is the real assignment phase and not the BV> Solicit/Advertise. Hence the text should be clearer with that understanding? BV> NOTE: I am a bit concerned by this misunderstanding - perhaps we're not clear BV> enough in the -23 draft with regard to the entire DHCPv6 sequence (we may BV> often be assuming too much since we know all about it and forget to write it BV> for people who haven't been working on the draft). Thank you for your kind attention. Regards, Paul Institute for Communications Research _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1D058.D0909400 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Question on DHCPv6 Draft 23.

Paul:

See comments below, prefixed by BV>.

- Bernie

-----Original Message-----
From: Paul Tan [mailto:tanpaul@cwc.nus.edu.sg]
Sent: Wednesday, March 20, 2002 1:54 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Question on DHCPv6 Draft 23.


Hi all,

we are currently trying to implement a DHCPv6 client/server (draft 23) in
Linux environment. Are there any active implementations working on the
latest DHCP draft 23 ?

I have a few questions concerning the DHCPv6 draft 23.

1) After a client sends out a SOLICIT with an IA option attached (no IA Addr
Opt), the server will basically reply with an ADVERTISE message with some
addresses attached in the IA Addr options.

- Does the lifetime for this IA starts after the server sends the ADVERTISE
message ? How does the server knows whether if the client has decided to use
the address advertised by this server, when in fact the client has chosen
some other server ?

BV> The lifetimes in the Advertise are in one sense meaningless since there
BV> is no contract between client and server regarding these. Only after the
BV> Request/Reply sequence can a client use the addresses and do the lifetimes
BV> apply. The lifetimes in the Advertise, IMHO, should be the ones the server
BV> INTENDS to give the client in a future Reply should the client chose the
BV> server. If the server does take steps to reserve the addresses for the
BV> client, it may actually do this with a much shorter lifetime. But that is
BV> not what it sends to the server.
BV>
BV> The lifetimes apply based on when the client RECEIVES the message, not
BV> when the server sent it (since the client has no way of knowing this).
BV> This also typically means a server has a small grace period that it
BV> applies to "extend" the lifetimes to allow for a small difference in
BV> the times between client and server (note also that clock speeds on
BV> systems may vary slightly as well). But, the T1/T2 times should also be
BV> choosen by servers to allow plenty of time for renewals.

2) When the client receives the ADVERTISE message, it will attempt to
configure its interface with the assigned address from the list of server's
ADVERTISE messages.
BV> NO!!! You can not do this until after the Request/Reply sequence!!!!
- Does it need to send a REQUEST message immediately after the ADVERTISE
message to confirm that the client is using the address from a particular
server?
- What is the main purpose of the REQUEST message ? Get the configuration
info of a particular IA ?
BV> It is to get the actual address assignments and configuration. Information
BV> that is received in the Advertise is only an advertisement for service and
BV> not an offer for server.
BV> The Solicit/Advertise is a way for a client to determine what servers are
BV> likely to offer it. BUT, the Requeset/Reply is the actual negotiation of
BV> what the client gets.
BV> Think of this as advertisements you get in the mail. They are to bring you
BV> in to the store. But, you actually have to buy something to take advantage
BV> of the advertisements. That is the Request/Reply phase.

3) I'm a bit confused with the following paragraph in the draft...
- ... if the server will not assign any addresses to IAs in a subsequent
REQUEST from the client, the server SHOULD either send an ADV message to the
client that includes only a status code option (AddrUnavail) for the user or
not respond to the SOLICIT message....
BV> What's are you confused about regarding this? I think my above comments
BV> make it clear that the Request/Reply is the real assignment phase and not the
BV> Solicit/Advertise. Hence the text should be clearer with that understanding?


BV> NOTE: I am a bit concerned by this misunderstanding - perhaps we're not clear
BV> enough in the -23 draft with regard to the entire DHCPv6 sequence (we may
BV> often be assuming too much since we know all about it and forget to write it
BV> for people who haven't been working on the draft).

Thank you for your kind attention.

Regards,
Paul
Institute for Communications Research



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1D058.D0909400-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 20 17:14:51 2002 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 RAA17025 for ; Wed, 20 Mar 2002 17:14:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA17903 for dhcwg-archive@odin.ietf.org; Wed, 20 Mar 2002 17:14:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17614; Wed, 20 Mar 2002 17:10:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17588 for ; Wed, 20 Mar 2002 17:10:09 -0500 (EST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16833 for ; Wed, 20 Mar 2002 17:10:06 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel11.hp.com (Postfix) with ESMTP id F1B8360090C for ; Wed, 20 Mar 2002 14:09:34 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id OAA20028; Wed, 20 Mar 2002 14:09:56 -0800 (PST) Date: Wed, 20 Mar 2002 14:09:54 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: dhcwg@ietf.org Cc: sramam@cup.hp.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] dhc-mip-fa draft Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hello, I am a Mobile IP implementor and am quite a novice in DHC. I missed asking this question during the WG session this morning. Does the information about the FA in the FA Option include any dynamic info, like challenge values (or even busy bit)? If so, then it seems that the DHCP server needs to maintain a dynamic info base for the FA. If this is implicit, then is the mechnism to update the FA info at the DHCP server left as an implementation issue? thanks! Siva ps: I am not part of the DHC mailing list, so please include my email address in your reply! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 20 20:34:33 2002 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 UAA21088 for ; Wed, 20 Mar 2002 20:34:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA27814 for dhcwg-archive@odin.ietf.org; Wed, 20 Mar 2002 20:34:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26910; Wed, 20 Mar 2002 20:21:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26880 for ; Wed, 20 Mar 2002 20:21:06 -0500 (EST) Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20784 for ; Wed, 20 Mar 2002 20:20:57 -0500 (EST) Received: from tanhl (tanhl.cwc.nus.edu.sg [172.16.2.66]) by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with SMTP id JAA16552; Thu, 21 Mar 2002 09:19:24 +0800 (SGT) Message-ID: <01ae01c1d077$b6b18f20$420210ac@tanhl> From: "Paul Tan" To: "Bernie Volz \(EUD\)" Cc: References: <66F66129A77AD411B76200508B65AC69CEC639@EAMBUNT705> Subject: Re: [dhcwg] Question on DHCPv6 Draft 23. Date: Thu, 21 Mar 2002 09:28:27 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AB_01C1D0BA.C1BBCF50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_01AB_01C1D0BA.C1BBCF50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Question on DHCPv6 Draft 23.Hi Bernie, thank you for your prompt reply. I am much clearly now as to the purpose of the SOLICIT/ADVERTISE and = REQUEST/REPLY sequence. Bernie, are there any implementations working towards the latest draft ? = I managed to find some codes (e.g. kame DHCP, isc DHCPv6), but I found = that they don't really support the draft's specificaton. Paul ----- Original Message -----=20 From: Bernie Volz (EUD)=20 To: Paul Tan ; dhcwg@ietf.org=20 Sent: Thursday, March 21, 2002 5:47 AM Subject: RE: [dhcwg] Question on DHCPv6 Draft 23. Paul:=20 See comments below, prefixed by BV>.=20 - Bernie=20 -----Original Message-----=20 From: Paul Tan [mailto:tanpaul@cwc.nus.edu.sg]=20 Sent: Wednesday, March 20, 2002 1:54 AM=20 To: dhcwg@ietf.org=20 Subject: [dhcwg] Question on DHCPv6 Draft 23.=20 Hi all,=20 we are currently trying to implement a DHCPv6 client/server (draft 23) = in=20 Linux environment. Are there any active implementations working on the = latest DHCP draft 23 ?=20 I have a few questions concerning the DHCPv6 draft 23.=20 1) After a client sends out a SOLICIT with an IA option attached (no = IA Addr=20 Opt), the server will basically reply with an ADVERTISE message with = some=20 addresses attached in the IA Addr options.=20 - Does the lifetime for this IA starts after the server sends the = ADVERTISE=20 message ? How does the server knows whether if the client has decided = to use=20 the address advertised by this server, when in fact the client has = chosen=20 some other server ?=20 BV> The lifetimes in the Advertise are in one sense meaningless since = there=20 BV> is no contract between client and server regarding these. Only = after the=20 BV> Request/Reply sequence can a client use the addresses and do the = lifetimes=20 BV> apply. The lifetimes in the Advertise, IMHO, should be the ones = the server=20 BV> INTENDS to give the client in a future Reply should the client = chose the=20 BV> server. If the server does take steps to reserve the addresses for = the=20 BV> client, it may actually do this with a much shorter lifetime. But = that is=20 BV> not what it sends to the server.=20 BV>=20 BV> The lifetimes apply based on when the client RECEIVES the message, = not=20 BV> when the server sent it (since the client has no way of knowing = this).=20 BV> This also typically means a server has a small grace period that = it=20 BV> applies to "extend" the lifetimes to allow for a small difference = in=20 BV> the times between client and server (note also that clock speeds = on=20 BV> systems may vary slightly as well). But, the T1/T2 times should = also be=20 BV> choosen by servers to allow plenty of time for renewals.=20 2) When the client receives the ADVERTISE message, it will attempt to=20 configure its interface with the assigned address from the list of = server's=20 ADVERTISE messages.=20 BV> NO!!! You can not do this until after the Request/Reply = sequence!!!!=20 - Does it need to send a REQUEST message immediately after the = ADVERTISE=20 message to confirm that the client is using the address from a = particular=20 server?=20 - What is the main purpose of the REQUEST message ? Get the = configuration=20 info of a particular IA ?=20 BV> It is to get the actual address assignments and configuration. = Information=20 BV> that is received in the Advertise is only an advertisement for = service and=20 BV> not an offer for server.=20 BV> The Solicit/Advertise is a way for a client to determine what = servers are=20 BV> likely to offer it. BUT, the Requeset/Reply is the actual = negotiation of=20 BV> what the client gets.=20 BV> Think of this as advertisements you get in the mail. They are to = bring you=20 BV> in to the store. But, you actually have to buy something to take = advantage=20 BV> of the advertisements. That is the Request/Reply phase.=20 3) I'm a bit confused with the following paragraph in the draft...=20 - ... if the server will not assign any addresses to IAs in a = subsequent=20 REQUEST from the client, the server SHOULD either send an ADV message = to the=20 client that includes only a status code option (AddrUnavail) for the = user or=20 not respond to the SOLICIT message....=20 BV> What's are you confused about regarding this? I think my above = comments=20 BV> make it clear that the Request/Reply is the real assignment phase = and not the=20 BV> Solicit/Advertise. Hence the text should be clearer with that = understanding?=20 BV> NOTE: I am a bit concerned by this misunderstanding - perhaps = we're not clear=20 BV> enough in the -23 draft with regard to the entire DHCPv6 sequence = (we may=20 BV> often be assuming too much since we know all about it and forget = to write it=20 BV> for people who haven't been working on the draft).=20 Thank you for your kind attention.=20 Regards,=20 Paul=20 Institute for Communications Research=20 _______________________________________________=20 dhcwg mailing list=20 dhcwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/dhcwg=20 ------=_NextPart_000_01AB_01C1D0BA.C1BBCF50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Question on DHCPv6 Draft 23.
Hi Bernie,
 
thank you for your prompt = reply.
 
I am much clearly now as to the purpose = of the=20 SOLICIT/ADVERTISE and REQUEST/REPLY sequence.
 
Bernie, are there any implementations = working=20 towards the latest draft ? I managed to find some codes (e.g. kame DHCP, = isc=20 DHCPv6), but I found that they don't really support the draft's=20 specificaton.
 
Paul
----- Original Message -----
From:=20 Bernie Volz (EUD) =
Sent: Thursday, March 21, 2002 = 5:47=20 AM
Subject: RE: [dhcwg] Question = on DHCPv6=20 Draft 23.

Paul:

See comments below, prefixed by BV>.

- Bernie

-----Original Message-----
From: Paul=20 Tan [mailto:tanpaul@cwc.nus.edu.sg]= =20
Sent: Wednesday, March 20, 2002 1:54 AM =
To: dhcwg@ietf.org
Subject: [dhcwg] Question on DHCPv6 Draft 23.


Hi all,

we are currently trying to implement a DHCPv6 = client/server=20 (draft 23) in
Linux environment. Are there = any active=20 implementations working on the
latest DHCP = draft 23=20 ?

I have a few questions concerning the DHCPv6 draft = 23.=20

1) After a client sends out a SOLICIT with an IA = option=20 attached (no IA Addr
Opt), the server will = basically=20 reply with an ADVERTISE message with some
addresses=20 attached in the IA Addr options.

- Does the lifetime for this IA starts after the = server sends=20 the ADVERTISE
message ? How does the server = knows=20 whether if the client has decided to use
the = address=20 advertised by this server, when in fact the client has chosen =
some other server ?

BV> The lifetimes in the Advertise are in one = sense=20 meaningless since there
BV> is no = contract between=20 client and server regarding these. Only after the
BV> Request/Reply sequence can a client use the addresses = and do the=20 lifetimes
BV> apply. The lifetimes in the = Advertise, IMHO, should be the ones the server
BV>=20 INTENDS to give the client in a future Reply should the client chose=20 the
BV> server. If the server does take = steps to=20 reserve the addresses for the
BV> client, = it may=20 actually do this with a much shorter lifetime. But that is =
BV> not what it sends to the server.
BV>
BV> The lifetimes apply = based on when=20 the client RECEIVES the message, not
BV> = when the=20 server sent it (since the client has no way of knowing this). =
BV> This also typically means a server has a small grace = period that=20 it
BV> applies to "extend" the lifetimes = to allow=20 for a small difference in
BV> the times = between=20 client and server (note also that clock speeds on
BV> systems may vary slightly as well). But, the T1/T2 = times should=20 also be
BV> choosen by servers to allow = plenty of=20 time for renewals.

2) When the client receives the ADVERTISE message, = it will=20 attempt to
configure its interface with the = assigned=20 address from the list of server's
ADVERTISE=20 messages.
BV> NO!!! You can not do this = until after=20 the Request/Reply sequence!!!!
- Does it = need to send=20 a REQUEST message immediately after the ADVERTISE
message to confirm that the client is using the address from = a=20 particular
server?
- What is=20 the main purpose of the REQUEST message ? Get the configuration =
info of a particular IA ?
BV> It=20 is to get the actual address assignments and configuration. = Information=20
BV> that is received in the Advertise is only an = advertisement for service and
BV> not an = offer for=20 server.
BV> The Solicit/Advertise is a = way for a=20 client to determine what servers are
BV> = likely to=20 offer it. BUT, the Requeset/Reply is the actual negotiation of=20
BV> what the client gets.
BV>=20 Think of this as advertisements you get in the mail. They are to bring = you
BV> in to the store. But, you = actually have to=20 buy something to take advantage
BV> of = the=20 advertisements. That is the Request/Reply phase.

3) I'm a bit confused with the following paragraph = in the=20 draft...
- ... if the server will not assign = any=20 addresses to IAs in a subsequent
REQUEST = from the=20 client, the server SHOULD either send an ADV message to the =
client that includes only a status code option (AddrUnavail) = for the=20 user or
not respond to the SOLICIT = message....=20
BV> What's are you confused about regarding = this? I think=20 my above comments
BV> make it clear that = the=20 Request/Reply is the real assignment phase and not the =
BV> Solicit/Advertise. Hence the text should be clearer = with that=20 understanding?


BV> NOTE: I am a bit concerned by this = misunderstanding -=20 perhaps we're not clear
BV> enough in the = -23 draft=20 with regard to the entire DHCPv6 sequence (we may
BV> often be assuming too much since we know all about it = and forget=20 to write it
BV> for people who haven't = been working=20 on the draft).

Thank you for your kind attention.

Regards,
Paul =
Institute for Communications Research



_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20

------=_NextPart_000_01AB_01C1D0BA.C1BBCF50-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 20 20:58:11 2002 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 UAA21451 for ; Wed, 20 Mar 2002 20:58:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28539 for dhcwg-archive@odin.ietf.org; Wed, 20 Mar 2002 20:58:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28401; Wed, 20 Mar 2002 20:53:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28320 for ; Wed, 20 Mar 2002 20:53:21 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21401 for ; Wed, 20 Mar 2002 20:53:18 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2L1rKl06391 for ; Wed, 20 Mar 2002 19:53:20 -0600 (CST) 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 g2L1rKP07385 for ; Wed, 20 Mar 2002 19:53:20 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Mar 20 19:53:19 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 19:53:19 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4D120@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Paul Tan'" , "Bernie Volz (EUD)" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Question on DHCPv6 Draft 23. Date: Wed, 20 Mar 2002 19:53:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D07B.2B8277D0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D07B.2B8277D0 Content-Type: text/plain; charset="iso-8859-1" Paul: I know there are people implementing this draft. I assume if they want to make that public or have an implementation they're willing to make available, they will respond independently. - Bernie -----Original Message----- From: Paul Tan [mailto:tanpaul@cwc.nus.edu.sg] Sent: Wednesday, March 20, 2002 8:28 PM To: Bernie Volz (EUD) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Question on DHCPv6 Draft 23. Hi Bernie, thank you for your prompt reply. I am much clearly now as to the purpose of the SOLICIT/ADVERTISE and REQUEST/REPLY sequence. Bernie, are there any implementations working towards the latest draft ? I managed to find some codes (e.g. kame DHCP, isc DHCPv6), but I found that they don't really support the draft's specificaton. Paul ----- Original Message ----- From: Bernie Volz (EUD) To: Paul Tan ; dhcwg@ietf.org Sent: Thursday, March 21, 2002 5:47 AM Subject: RE: [dhcwg] Question on DHCPv6 Draft 23. Paul: See comments below, prefixed by BV>. - Bernie -----Original Message----- From: Paul Tan [ mailto:tanpaul@cwc.nus.edu.sg ] Sent: Wednesday, March 20, 2002 1:54 AM To: dhcwg@ietf.org Subject: [dhcwg] Question on DHCPv6 Draft 23. Hi all, we are currently trying to implement a DHCPv6 client/server (draft 23) in Linux environment. Are there any active implementations working on the latest DHCP draft 23 ? I have a few questions concerning the DHCPv6 draft 23. 1) After a client sends out a SOLICIT with an IA option attached (no IA Addr Opt), the server will basically reply with an ADVERTISE message with some addresses attached in the IA Addr options. - Does the lifetime for this IA starts after the server sends the ADVERTISE message ? How does the server knows whether if the client has decided to use the address advertised by this server, when in fact the client has chosen some other server ? BV> The lifetimes in the Advertise are in one sense meaningless since there BV> is no contract between client and server regarding these. Only after the BV> Request/Reply sequence can a client use the addresses and do the lifetimes BV> apply. The lifetimes in the Advertise, IMHO, should be the ones the server BV> INTENDS to give the client in a future Reply should the client chose the BV> server. If the server does take steps to reserve the addresses for the BV> client, it may actually do this with a much shorter lifetime. But that is BV> not what it sends to the server. BV> BV> The lifetimes apply based on when the client RECEIVES the message, not BV> when the server sent it (since the client has no way of knowing this). BV> This also typically means a server has a small grace period that it BV> applies to "extend" the lifetimes to allow for a small difference in BV> the times between client and server (note also that clock speeds on BV> systems may vary slightly as well). But, the T1/T2 times should also be BV> choosen by servers to allow plenty of time for renewals. 2) When the client receives the ADVERTISE message, it will attempt to configure its interface with the assigned address from the list of server's ADVERTISE messages. BV> NO!!! You can not do this until after the Request/Reply sequence!!!! - Does it need to send a REQUEST message immediately after the ADVERTISE message to confirm that the client is using the address from a particular server? - What is the main purpose of the REQUEST message ? Get the configuration info of a particular IA ? BV> It is to get the actual address assignments and configuration. Information BV> that is received in the Advertise is only an advertisement for service and BV> not an offer for server. BV> The Solicit/Advertise is a way for a client to determine what servers are BV> likely to offer it. BUT, the Requeset/Reply is the actual negotiation of BV> what the client gets. BV> Think of this as advertisements you get in the mail. They are to bring you BV> in to the store. But, you actually have to buy something to take advantage BV> of the advertisements. That is the Request/Reply phase. 3) I'm a bit confused with the following paragraph in the draft... - ... if the server will not assign any addresses to IAs in a subsequent REQUEST from the client, the server SHOULD either send an ADV message to the client that includes only a status code option (AddrUnavail) for the user or not respond to the SOLICIT message.... BV> What's are you confused about regarding this? I think my above comments BV> make it clear that the Request/Reply is the real assignment phase and not the BV> Solicit/Advertise. Hence the text should be clearer with that understanding? BV> NOTE: I am a bit concerned by this misunderstanding - perhaps we're not clear BV> enough in the -23 draft with regard to the entire DHCPv6 sequence (we may BV> often be assuming too much since we know all about it and forget to write it BV> for people who haven't been working on the draft). Thank you for your kind attention. Regards, Paul Institute for Communications Research _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1D07B.2B8277D0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Question on DHCPv6 Draft 23.
Paul:
 
I know there are people implementing this draft. I assume if they want to make that public or have an implementation they're willing to make available, they will respond independently.
 
- Bernie
-----Original Message-----
From: Paul Tan [mailto:tanpaul@cwc.nus.edu.sg]
Sent: Wednesday, March 20, 2002 8:28 PM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Question on DHCPv6 Draft 23.

Hi Bernie,
 
thank you for your prompt reply.
 
I am much clearly now as to the purpose of the SOLICIT/ADVERTISE and REQUEST/REPLY sequence.
 
Bernie, are there any implementations working towards the latest draft ? I managed to find some codes (e.g. kame DHCP, isc DHCPv6), but I found that they don't really support the draft's specificaton.
 
Paul
----- Original Message -----
Sent: Thursday, March 21, 2002 5:47 AM
Subject: RE: [dhcwg] Question on DHCPv6 Draft 23.

Paul:

See comments below, prefixed by BV>.

- Bernie

-----Original Message-----
From: Paul Tan [mailto:tanpaul@cwc.nus.edu.sg]
Sent: Wednesday, March 20, 2002 1:54 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Question on DHCPv6 Draft 23.


Hi all,

we are currently trying to implement a DHCPv6 client/server (draft 23) in
Linux environment. Are there any active implementations working on the
latest DHCP draft 23 ?

I have a few questions concerning the DHCPv6 draft 23.

1) After a client sends out a SOLICIT with an IA option attached (no IA Addr
Opt), the server will basically reply with an ADVERTISE message with some
addresses attached in the IA Addr options.

- Does the lifetime for this IA starts after the server sends the ADVERTISE
message ? How does the server knows whether if the client has decided to use
the address advertised by this server, when in fact the client has chosen
some other server ?

BV> The lifetimes in the Advertise are in one sense meaningless since there
BV> is no contract between client and server regarding these. Only after the
BV> Request/Reply sequence can a client use the addresses and do the lifetimes
BV> apply. The lifetimes in the Advertise, IMHO, should be the ones the server
BV> INTENDS to give the client in a future Reply should the client chose the
BV> server. If the server does take steps to reserve the addresses for the
BV> client, it may actually do this with a much shorter lifetime. But that is
BV> not what it sends to the server.
BV>
BV> The lifetimes apply based on when the client RECEIVES the message, not
BV> when the server sent it (since the client has no way of knowing this).
BV> This also typically means a server has a small grace period that it
BV> applies to "extend" the lifetimes to allow for a small difference in
BV> the times between client and server (note also that clock speeds on
BV> systems may vary slightly as well). But, the T1/T2 times should also be
BV> choosen by servers to allow plenty of time for renewals.

2) When the client receives the ADVERTISE message, it will attempt to
configure its interface with the assigned address from the list of server's
ADVERTISE messages.
BV> NO!!! You can not do this until after the Request/Reply sequence!!!!
- Does it need to send a REQUEST message immediately after the ADVERTISE
message to confirm that the client is using the address from a particular
server?
- What is the main purpose of the REQUEST message ? Get the configuration
info of a particular IA ?
BV> It is to get the actual address assignments and configuration. Information
BV> that is received in the Advertise is only an advertisement for service and
BV> not an offer for server.
BV> The Solicit/Advertise is a way for a client to determine what servers are
BV> likely to offer it. BUT, the Requeset/Reply is the actual negotiation of
BV> what the client gets.
BV> Think of this as advertisements you get in the mail. They are to bring you
BV> in to the store. But, you actually have to buy something to take advantage
BV> of the advertisements. That is the Request/Reply phase.

3) I'm a bit confused with the following paragraph in the draft...
- ... if the server will not assign any addresses to IAs in a subsequent
REQUEST from the client, the server SHOULD either send an ADV message to the
client that includes only a status code option (AddrUnavail) for the user or
not respond to the SOLICIT message....
BV> What's are you confused about regarding this? I think my above comments
BV> make it clear that the Request/Reply is the real assignment phase and not the
BV> Solicit/Advertise. Hence the text should be clearer with that understanding?


BV> NOTE: I am a bit concerned by this misunderstanding - perhaps we're not clear
BV> enough in the -23 draft with regard to the entire DHCPv6 sequence (we may
BV> often be assuming too much since we know all about it and forget to write it
BV> for people who haven't been working on the draft).

Thank you for your kind attention.

Regards,
Paul
Institute for Communications Research



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C1D07B.2B8277D0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 21 14:24:45 2002 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 OAA22387 for ; Thu, 21 Mar 2002 14:24:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05117 for dhcwg-archive@odin.ietf.org; Thu, 21 Mar 2002 14:24:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04761; Thu, 21 Mar 2002 14:18:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04730 for ; Thu, 21 Mar 2002 14:18:27 -0500 (EST) Received: from AVIANSERVER.aviancommunications.com (avianserver.aviancommunications.com [205.158.157.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22072 for ; Thu, 21 Mar 2002 14:18:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D10D.16ED60C9" Date: Thu, 21 Mar 2002 14:17:49 -0500 Message-ID: Thread-Topic: A Simple Question with respect to relay Thread-Index: AcHMmy5T7bxSQVikQw6jyClcUnNRdwAlaszQAPbkXEA= From: "Umesh Sirsiwal" To: Cc: "Jonathan West" Subject: [dhcwg] FW: A Simple Question with respect to relay Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D10D.16ED60C9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I am working with following network scenario: =20 DHCP Clients -----Relay 1 ----- Relay 2 ------- DHCP Server The second relay is used because, Relay 1 is not accessible from DHCP Server. Furthermore, Relay 1 does not implement subnet selection option. We are wondering if there is a way to use this configuration. By default DHCP Server will send response to giaddr which is Relay 1's IP address and as noted Relay1 is not accessible from server. We can not use subnet selection option starting at Relay 2, because Relay2 does not have information with respect to subnet mask (actually Relay2 handles multiple Relay1). Can Relay2 add the subnet selection option using giaddr without the subnet mask? How should I configure this system? Or is replacing Relay2 with DHCP Server only option? -Umesh ------_=_NextPart_001_01C1D10D.16ED60C9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable FW: A Simple Question with respect to relay

I am working with following network scenario:
     
      DHCP Clients = -----Relay 1  -----   Relay 2 ------- DHCP Server

The second relay is used because, Relay 1 is not = accessible from DHCP Server. Furthermore, Relay 1 does not implement = subnet selection option.

We are wondering if there is a way to use this = configuration. By default DHCP Server will send response to giaddr which = is Relay 1's IP address and as noted Relay1 is not accessible from = server.

We can not use subnet selection option starting at = Relay 2, because Relay2 does not have information with respect to subnet = mask (actually Relay2 handles multiple Relay1).  Can Relay2 add the = subnet selection option using giaddr without the subnet mask?

How should I configure this system? Or is replacing = Relay2 with DHCP Server only option?


-Umesh

------_=_NextPart_001_01C1D10D.16ED60C9-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 21 21:59:51 2002 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 VAA05137 for ; Thu, 21 Mar 2002 21:59:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA03107 for dhcwg-archive@odin.ietf.org; Thu, 21 Mar 2002 21:59:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02979; Thu, 21 Mar 2002 21:58:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA02954 for ; Thu, 21 Mar 2002 21:58:04 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05095 for ; Thu, 21 Mar 2002 21:57:59 -0500 (EST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id DAA02005 for ; Fri, 22 Mar 2002 03:55:13 +0100 From: "Henrik Levkowetz" To: Subject: RE: [dhcwg] dhc-mip-fa draft Date: Fri, 22 Mar 2002 03:57:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi Siva, Good question. The information could contain dynamic information, if the DHCP server had that dynamic information (by being co-located with the FA for instance), but generally I would not expect the information to be dynamic. If a challenge was needed, I'd let that be a stale challenge, and let the FA provide a fresh challenge together with the rejection due to the stale challenge. Not necessarily pretty or optimal, but simple, and it will work. I would not expect a generic DHCP server to provide dynamic information, and do not expect to define any method or protocol to provide dynamic FA information to the DHCP server. Best regards, Henrik Sivasundar wrote: > > Hello, > > I am a Mobile IP implementor and am quite a novice in DHC. I missed > asking this question during the WG session this morning. > > Does the information about the FA in the FA Option include any dynamic > info, like challenge values (or even busy bit)? > > If so, then it seems that the DHCP server needs to maintain a dynamic > info base for the FA. If this is implicit, then is the mechnism to > update the FA info at the DHCP server left as an implementation issue? > > > thanks! > > Siva > > > ps: I am not part of the DHC mailing list, so please include my email > address in your reply! > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Mar 22 18:42:16 2002 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 SAA04381 for ; Fri, 22 Mar 2002 18:42:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29625 for dhcwg-archive@odin.ietf.org; Fri, 22 Mar 2002 18:42:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29458; Fri, 22 Mar 2002 18:39:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29434 for ; Fri, 22 Mar 2002 18:39:52 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04331 for ; Fri, 22 Mar 2002 18:39:50 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA21145 for ; Fri, 22 Mar 2002 16:39:53 -0700 (MST)] Received: [from il06exm05.corp.mot.com (il06exm05.corp.mot.com [199.5.78.57]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id QAA16094 for ; Fri, 22 Mar 2002 16:39:53 -0700 (MST)] Received: by il06exm05.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 22 Mar 2002 17:39:53 -0600 Message-ID: <1B1F9F30D74AD51188C8009027E33B3F26BD3A@il06exm03.corp.mot.com> From: Malek John-AJM240 To: "'dhcwg@ietf.org'" Date: Fri, 22 Mar 2002 17:39:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] Unicast discover? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi, Is it possible to unicast the discover message out and get an offer back from a windows DHCP manager. Thanks in advance. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sat Mar 23 08:13:24 2002 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 IAA21359 for ; Sat, 23 Mar 2002 08:13:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21071 for dhcwg-archive@odin.ietf.org; Sat, 23 Mar 2002 08:13:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20680; Sat, 23 Mar 2002 08:10:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20646 for ; Sat, 23 Mar 2002 08:10:43 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21307 for ; Sat, 23 Mar 2002 08:10:39 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn2-243.cisco.com [10.21.112.243]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA01976; Sat, 23 Mar 2002 08:10:10 -0500 (EST) Message-Id: <4.3.2.7.2.20020323075001.0357f170@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 23 Mar 2002 07:59:11 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Prefix delegation issues from Minneapolis Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org A couple of issues came out of the discussion of the prefix delegation option in Minneapolis: * Disallow reassigning delegated prefix on upstream link (and should this restriction be configurable?) * Allow use of DHCP on NBMA links by reserving a well-known anycast address for client->server messages * Devise a mechanism for prefix delegation through a two-message exchange * Write a specification for a simplified version of DHCP that meets the requirements for prefix delegation; this simplified protocol needs a name that doesn't include the word "Host" I'll kick off discussion on these issues in separate messages on the dhcwg@ietf.org mailing list. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sat Mar 23 08:25:55 2002 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 IAA21498 for ; Sat, 23 Mar 2002 08:25:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22377 for dhcwg-archive@odin.ietf.org; Sat, 23 Mar 2002 08:25:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22094; Sat, 23 Mar 2002 08:23:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22067 for ; Sat, 23 Mar 2002 08:23:25 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21463 for ; Sat, 23 Mar 2002 08:23:19 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn2-243.cisco.com [10.21.112.243]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA02248 for ; Sat, 23 Mar 2002 08:22:51 -0500 (EST) Message-Id: <4.3.2.7.2.20020323075926.035aadc8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 23 Mar 2002 08:22:34 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Restricting reassignment of delegated prefixes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org In Minneapolis, Shin Miyakawa suggested that DHCPv6 prefix delegation include a restriction that a delegated prefix must not be assigned by the requesting router to the upstream link (the link back to the delegating router). Seems like a reasonable restriction to me, as the ISP may consider that it owns the upstream link. I imagine it would be a good idea to allow the delegating router to control this restriction in the requesting router; e.g., through a bit in the prefix delegation option. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sat Mar 23 20:36:41 2002 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 UAA27589 for ; Sat, 23 Mar 2002 20:36:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA09181 for dhcwg-archive@odin.ietf.org; Sat, 23 Mar 2002 20:36:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08095; Sat, 23 Mar 2002 20:32:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08065 for ; Sat, 23 Mar 2002 20:32:47 -0500 (EST) Received: from localhost ([211.186.108.145]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27437 for ; Sat, 23 Mar 2002 20:32:43 -0500 (EST) Message-Id: <200203240132.UAA27437@ietf.org> Reply-To: winwin@insuwel.com From: 인슈웰컴 To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 24 Mar 2002 10:27:31 +0900 Subject: [dhcwg] [광$고]이베트 주인공이 되십시요. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 인슈웰컴


귀하의 메일주소는 웹서핑중에 알게 된것이며, E-Mail 주소 외에, 다른 정보는 갖고 있지 않습니다.
정통부 권고사항에 의거 제목에 [광고]라고 표기한 메일입니다. 원치 않으면 ☞ 수신거부 를 눌러주세요. 본 메일은 한번이상 발송되지 않습니다. 
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Mon Mar 25 19:55:41 2002 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 TAA09637 for ; Mon, 25 Mar 2002 19:55:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA17962 for dhcwg-archive@odin.ietf.org; Mon, 25 Mar 2002 19:55:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16592; Mon, 25 Mar 2002 19:50:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA16554 for ; Mon, 25 Mar 2002 19:50:34 -0500 (EST) Received: from jroad161.bbalgantv.com ([203.231.232.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09482 for ; Mon, 25 Mar 2002 19:50:31 -0500 (EST) Received: from mail.bbalgantv.com (unverified [64.114.18.248]) by jroad161.bbalgantv.com (EMWAC SMTPRS 0.83) with SMTP id ; Tue, 26 Mar 2002 09:48:26 +0900 Message-ID: From: William To: dhcwg@ietf.org Date: 25 Mar 2002 16:50:32 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_wiSedSPe_y9RrkHry_MA" Subject: [dhcwg] =?ISO-8859-1?B?WyoqsaQgKiogsO0gKipdILTrtNzI9yCwqLvnx9W0z7TZLi4uLg==?= Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org ------=_wiSedSPe_y9RrkHry_MA Content-Type: text/plain Content-Transfer-Encoding: 8bit -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- (This safeguard is not inserted when using the registered version) -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- -------------------------------------------------------------------- ------=_wiSedSPe_y9RrkHry_MA Content-Type: text/html Content-Transfer-Encoding: 8bit Casinoever.com

 

 

※ 허락없이 메일 보낸점 사과드립니다. 이 메일은 웹서핑중 무작위로 추출된 주소로서
개인정보에 아무런 영향을 미치질 않습니다. 안심하십시요.
만일 원치 않으시면 수신거부를 해주세요. 차후로 결코 다시 보내지지 않을 것입니다.

수신거부

눈을 크게 뜨십시요!
게임 구경만 하셔도 돈을 드립니다!!

포커게임 구경만 하셔도 돈을 드리겠습니다!

CasinoEver.com 에서는 더이상 기대할 수 없는 최고의 이벤트를 마련했습니다!!


  • Deposit 을 하셨을 경우 Deposit 금액의 5% 를 포인트 로 드립니다!!!



  • 7Poker 에서 한판이 끝났을때 무조건 해당테이블에서 게임을 한 게이머들에게

    5포인트 씩 의 마일리지를 지급!!


  • 회원가입후 7Poker

    테이블에서 구경만하셔도, 한판이 끝났을때 무조건

    1포인트     의 마일리지 지급!!

  • Casinoever.com 에 가입하시는 모든분들께 1000 포인트 의 마일리지를 드립니다!!




  • Royal Straight Flush 가 나온 회원님께 20000포인트 의 마일리지 를 드립니다!!


  • Straight Flush 가 나온 회원님께 10000포인트 의 마일리지 를 드립니다!!


  • 이모든 이벤트는 7Poker 에서만 이루어짐을 미리 말씀드립니다.
  • 환전은 3000포인트 부터 가능합니다.

안녕하십니까? Casinoever.com 입니다.

놀라울 만큼 실게 카지노와 같은 환상의 그래픽!!

환희 와 희열을 느낄 높은 게임승률~!실제 카지노 보다 더욱더 가슴설레이는 정교한 게임들!!

처음 들어오신 분을 위해 준비된 Real(실전)게임 과 똑같은 FUN(연습) 게임,

거기다가 24 시간 어느때나 계속되는 세계인과 의 리얼머니 카지노!!

자! 지금까지 즐기신 카지노 게임들~ 모두 접어두십시요!!

하루의 기본 Pay out 이 $500,000 이상 유지되고 있는 사이트는 Casinoever.com 뿐입니다!

지금! 한국인 들을 배려한 정통 한국식 7Poker 가 새롭운 이벤트로 여러분을 기다리고 있습니다!

최고의 기쁨과 만족을 드리려 항상 노력하고 있습니다.

자! 망설임은 곧 후회로 다가 옵니다!

지금 오셔서 이 모든걸 확인하고 즐겨 주십시요.

세계 최고의 카지노 사이트는 CasinoEver.com 뿐입니다!!


* 본 사이트는 만 18세 이상만 가입이 가능함을 알려드립니다.

 

 

www.Casinoever.com

Copyright Ace On net. ©2002 All Rights Reserved

 

 

------=_wiSedSPe_y9RrkHry_MA-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 27 12:54:59 2002 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 MAA11400 for ; Wed, 27 Mar 2002 12:54:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA23041 for dhcwg-archive@odin.ietf.org; Wed, 27 Mar 2002 12:54:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21658; Wed, 27 Mar 2002 12:49:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21625 for ; Wed, 27 Mar 2002 12:49:02 -0500 (EST) Received: from hotmail.com ([203.238.135.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10956 for ; Wed, 27 Mar 2002 12:49:01 -0500 (EST) Message-Id: <200203271749.MAA10956@ietf.org> Reply-To: hotpoolm93@hotmail.com From: 정보 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 02:52:32 +0900 Subject: [dhcwg] ('광.고') 메가패스를 쓰고 있는 분을 위한 엄청난 혜택! Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 나우누리 회원가입
 
 
- 매주 개봉영화를 미리 보는 시사회 무료 초대!

- 국내 최대, 영화 8,000원 할인(1인 동반 시)
  메가박스 등 전국 260여개 상영관/실시간 예매
  * 멤버쉽카드 발급 시(5월 28일부터 신청 및 발급 가능)
 
 
 
- 만화에선 이들을 따라올 수 없다! 만화사랑(MANSA), 앙끄(ANC),
- 국내 NO.1 게임전략 동호회! 나모모
- 파워 유저들의 활기찬 공간! 파워 유저 동호회 등 엄청난 동호회가 가득!

- 와레즈를 능가하는 나우누리 자료실 무료 이용까지!
 
 
 
- 디지털 카메라, DVD, 명품시계.. 365일 공짜상품이 가득~
  무제한 사이버머니로 게임같이 베팅도 즐기고 푸짐한 경품도 탄다!
 
 
 
- 이상형을 매일매일 10명씩 추천해드립니다.
  원하는 미팅 상대와의 즉석 온라인 미팅!
  확실한 유료회원만의 짜릿한 미팅 서비스가 무료 ~
 
 

 나우누리만의 특별한 혜택, 지금 아래 버튼을 클릭하셔서 기회를 잡으세요!~
 
허락도 없이 메일을 드려 죄송합니다. 귀하의 이메일 주소는 게시판 등 인터넷을 통해 알게 되었습니다.
메일 수신을 원치않으시면 아래에 본인의 이메일 주소를 입력하시고 수신거부버튼을 눌러주세요
   
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 27 13:13:31 2002 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 NAA13047 for ; Wed, 27 Mar 2002 13:13:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25064 for dhcwg-archive@odin.ietf.org; Wed, 27 Mar 2002 13:13:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24866; Wed, 27 Mar 2002 13:10:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24830 for ; Wed, 27 Mar 2002 13:10:20 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12871 for ; Wed, 27 Mar 2002 13:10:19 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g2RI9oi12358 for ; Wed, 27 Mar 2002 12:09:50 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g2RI9ot21510 for ; Wed, 27 Mar 2002 12:09:50 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Mar 27 12:09:39 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 12:09:38 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4D168@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Vijay Bhaskar A K'" , dhcwg@ietf.org Date: Wed, 27 Mar 2002 12:09:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D5BA.8EBB08A0" Subject: [dhcwg] IETF-53 DHC WG Session - Vijay's DHCPv6 Issues Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D5BA.8EBB08A0 Content-Type: text/plain; charset="iso-8859-1" Vijay: Sorry you didn't have enough time to present your issues at the DHC WG meeting in Minneapolis. I hope you'll post them (and/or your slides) to the mailing list. I do feel that at least several of your issues relate to an assumption that the client knows what addresses it wants. This is not an assumption that I think is valid for most clients. In fact, when stateless autoconfiguration is used (RFC 2462), the rules are that any prefix that is advertised in a Routing Advertisement that has the Autonomous Flag set is supposed to result in an address on the client (see RFC 2462, Section 5.5.3). This does not presume that the client knows whether it wants only a site local or global - if both are advertised, both are supposed to be generated. The ONLY cases we presently have where a client "knows" that it needs a particular address are: - Temporary addresses for privacy - DSTM addresses And, DHCPv6 provides a means for a client to request these type of addresses (temporary via the RTA option and DSTM via the DSTM option). However, for "standard" addresses, we presume that the server has been configured with the rules for the clients (just as with stateless where the assumption is that the routers have been configured with this information). I don't disagree that there are circumstances where a client MAY know something about what it needs/wants, but that will be extremely unusual and atypical. Hence, there is no need to build in complex mechanisms for something that isn't likely or is extremely rare. Especially considering that in IPv6 addresses aren't scarce AND a client always as the option of not installing an address that is provided (either via stateful or stateless). And, note that in stateless it is the link identifier that is tested for uniqueness (not the full address). So, whether a client has one or many addresses based on the link identifier doesn't matter. Again, I would be interested in seeing your full list of issues. - Bernie Volz ------_=_NextPart_001_01C1D5BA.8EBB08A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IETF-53 DHC WG Session - Vijay's DHCPv6 Issues

Vijay:

Sorry you didn't have enough time to present your = issues at the DHC WG meeting in Minneapolis. I hope you'll post them = (and/or your slides) to the mailing list.

I do feel that at least several of your issues relate = to an assumption that the client knows what addresses it wants. This is = not an assumption that I think is valid for most clients.

In fact, when stateless autoconfiguration is used = (RFC 2462), the rules are that any prefix that is advertised in a = Routing Advertisement that has the Autonomous Flag set is supposed to = result in an address on the client (see RFC 2462, Section 5.5.3). This = does not presume that the client knows whether it wants only a site = local or global - if both are advertised, both are supposed to be = generated.

The ONLY cases we presently have where a client = "knows" that it needs a particular address are:
- Temporary addresses for privacy
- DSTM addresses

And, DHCPv6 provides a means for a client to request = these type of addresses (temporary via the RTA option and DSTM via the = DSTM option).

However, for "standard" addresses, we = presume that the server has been configured with the rules for the = clients (just as with stateless where the assumption is that the = routers have been configured with this information).

I don't disagree that there are circumstances where a = client MAY know something about what it needs/wants, but that will be = extremely unusual and atypical. Hence, there is no need to build in = complex mechanisms for something that isn't likely or is extremely = rare. Especially considering that in IPv6 addresses aren't scarce AND a = client always as the option of not installing an address that is = provided (either via stateful or stateless). And, note that in = stateless it is the link identifier that is tested for uniqueness (not = the full address). So, whether a client has one or many addresses based = on the link identifier doesn't matter.

Again, I would be interested in seeing your full list = of issues.

- Bernie Volz

------_=_NextPart_001_01C1D5BA.8EBB08A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 27 19:50:48 2002 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 TAA01004 for ; Wed, 27 Mar 2002 19:50:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA29415 for dhcwg-archive@odin.ietf.org; Wed, 27 Mar 2002 19:50:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29219; Wed, 27 Mar 2002 19:49:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29190 for ; Wed, 27 Mar 2002 19:49:05 -0500 (EST) Received: from yahoo.co.kr ([211.106.175.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00912 for ; Wed, 27 Mar 2002 19:49:01 -0500 (EST) Message-Id: <200203280049.TAA00912@ietf.org> Reply-To: wedsnc@yahoo.co.kr From: 주정희 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 09:49:06 +0900 Subject: [dhcwg] 광고 이성을 유혹하는 가장 확실한 밥법! 여자관계 복잡해 집니다. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org

이성을 자극하는 성분!

과학적으로 증명된 페로몬...

이제 여자관계 복잡해 집니다.

http://www.thrumart.com/phero

(남녀공용)

 

 

 

 

 

 

"본 E-mail은 정보통신부 권고안에 따라 인터넷상에서 획득했으며 수신자께서[수신거부]거부하실 주소로 회신 또는 발송하여 의사를 밝힌 후에는 또다시 보내지 않겠습니다."

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed Mar 27 23:17:48 2002 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 XAA06008 for ; Wed, 27 Mar 2002 23:17:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA08162 for dhcwg-archive@odin.ietf.org; Wed, 27 Mar 2002 23:17:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07987; Wed, 27 Mar 2002 23:12:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA07964 for ; Wed, 27 Mar 2002 23:12:17 -0500 (EST) Received: from magicez.com ([61.73.14.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA05918 for ; Wed, 27 Mar 2002 23:12:14 -0500 (EST) Message-ID: <163980-22002342841512440@magicez.com> X-EM-Version: 6, 0, 0, 4 X-EM-Registration: #0010630410721500AB30 Reply-To: return@magicez.com From: "코디마스터" To: dhcwg@ietf.org Date: Thu, 28 Mar 2002 13:15:12 +0900 MIME-Version: 1.0 Content-Type: text/html; charset=KS_C_5601-1987 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] [광 @.@ 고] 요상한 사이트 대발견??? 모든지 공짜!!! Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: quoted-printable =B8=C5=C1=F7=C0=CC=C1=F6 =
=09
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 28 05:01:16 2002 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 FAA20291 for ; Thu, 28 Mar 2002 05:01:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA06393 for dhcwg-archive@odin.ietf.org; Thu, 28 Mar 2002 05:01:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05500; Thu, 28 Mar 2002 04:56:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05428 for ; Thu, 28 Mar 2002 04:56:27 -0500 (EST) Received: from mail.iinet.net.au (symphony-05.iinet.net.au [203.59.3.37]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20190 for ; Thu, 28 Mar 2002 04:56:21 -0500 (EST) Received: (qmail 358 invoked by uid 666); 28 Mar 2002 09:56:16 -0000 Received: from unknown (HELO ADSL) (203.59.33.150) by mail.iinet.net.au with SMTP; 28 Mar 2002 09:56:16 -0000 From: "John L. Bright" To: Date: Thu, 28 Mar 2002 17:54:58 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C1D681.ACE50520" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [dhcwg] Conflict problem with a DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1D681.ACE50520 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C1D681.ACE50520" ------=_NextPart_001_0006_01C1D681.ACE50520 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit I am trying to install MS Internet Connection Sharing onto our LAN but cannot get it to load properly because another program is providing DHCP service for the host computer. (See MS Support Message #Q241255.) How can I identify which of my many installed programs is providing that service? Your assistance would be greatly appreciated. Cheers John Bright Perrington Holdings Pty Ltd 30 Frawley Gardens, Murdoch, W.A. 6150 Australia. Ph: +618 9310 8088 Fx: +618 9310 8080 http://www.perrington.com ------=_NextPart_001_0006_01C1D681.ACE50520 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I am trying to install MS = Internet Connection Sharing onto our LAN but cannot get it to load properly because another = program is providing DHCP service for the host computer. (See MS Support Message #Q241255.)

 

How can I identify which of my = many installed programs is providing that service? =

 

Your assistance would be = greatly appreciated.

 

Cheers

 

John = Bright

 

Perrington Holdings Pty = Ltd

30 Frawley Gardens,

Murdoch, W.A.=A0=A0 = 6150

Australia.

Ph: +618 9310 8088=A0 Fx: +618 9310 8080

http://www.perrington.com

 

------=_NextPart_001_0006_01C1D681.ACE50520-- ------=_NextPart_000_0005_01C1D681.ACE50520 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAoHBwcIBwoICAoPCggKDxINCgoNEhQQEBIQEBQRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/2wBDAQsMDBUTFSIYGCIUDg4OFBQODg4O FBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCADAAMADAREA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1YuSC CM8cE9RWQwGcAkEqCQBnHvQAZX+5+poADgqSq4APJyTQAoUABpOeyqep9P8AgNACbizhicEkcjjG aAAMVJAIIPBHUGgBwwxyuFY5BU8g59PzoAYMDORngjGcYOKAFKgRqepYnnnoKAF3Lj/Vj8S1ABnc CFj5PcZNAB5cgQgrgDkkkDAxQAR5IZe5GQO+Qc0AIQT5eOcjAH0NADjkq6kDIO4Yxj3/AJ0AND7c behHzA8g/hQAMVJBAIGOR6HvQApUqSc7CfurkkmgAO5UwCCrc5HUn+7QAgTLAEjB5J9sZoAVmQks 2ck8AYAAFAACWAVRhs4IHAx70ABwG3KCVUjB9SKAFVeWIJCDgsOpHpQAnzSNgAAAcDOABQApMYAB PmEcAcgCgBoOwgsucjKg9M+tADhlvvkfvOjd8jjmgBoKqSHUk5x1xQIUMhOBHk+mSaAGkEkELgHo OufagY5htXYBkjBc46HsKACQgkKMEKAAe2cf/XoAaoBzjOcDAAyc0APbzQMsxHoCefyoAQICAzfK vcnJJPtQAgZQ4ZVIAxxnJNACjCLuHDMCFHoPWgBPubSDyQSQewNACq2Rsbp2PcE0AGTHlQAGHBPf 8KABVUnOSVAyxxz/ALtACB8E8ZU5yoPGP8mgAYKGHOVPORjOKAAqFGckEn5QeDj+8aAHD5EBx8zj AGegoAYQQowcg84B9PagBzRkKSTgZyFJ5NAACpUBxgHgMBycetAgxs5KhwcYIJxQMN0RxkEY7gjp +NACYTJAz1AUED8c0AKwk4ZsKQByeCfegBQSI2c9XOAeO/LUAIpKZLA7gPkB5xnvQAiAltucbsjO eCT60CGnjr/nFADzI5HBwOmBwKABFJwwAb1GRmgYSCQnLAj65x+FAAiqeSeF5Yeo7CgAUBzgAgk5 9gKBCMQ0hIGQTwBxkCgYrKq5LfeOcKOgz70AIWBUAj5hgA+3pQAF8oFAwByfcmgBy7cNtz9w5zjr mgBqbRlm5xyB6mgAON5MmRnngUAOPl4JCsQODkjA/LNADSVJGF2468k5oACMgHJJOSc56D3oAQAn 5ScYB4OfSgBRuKnB+U9c4xmgBxYhQTyzHJHTgUAIZW6LhR1woxwKBCFTtDE5Jzx16UDHHa2FDAKo 6nqSetACZjAJALHpuPAzjPSgBrNuJOAPYcYoAeTuJxwDgyHHQigBjEHAAwAMAe1AAACDkkEdBjPP 60AKC4GQSADjgkgGgBxUnEakYXJY54yP/ifu0ANBds45wMHA5xmgBSwUYjyCerHgn/4mgAUDDEHP y5ORwDmgBAWCEhQVzjJAPJ6UCFLYwCqnIByBnGfxoGG7gsQAGBUAduc0AM4wc5z26YoAfJgSMCMn oCOxxQAgTcvynJ67ec/hQAmQF245znPfp0oAcZJQSCxBHUf5FABhnG6QnA4HqfYdKAByxCnACn7u OQBmgADqXAYYXG3HXA/yaAEIxlSDvB5NAD3LCRUQ4KgKCOOe9ADS4JIkUE9CQcGgBAxUnAyp7HuA aAFI+UmPJQ43DuCOaAEBJUKuAAMk8DJH+floAFYDgjIzkY6g+oNACsvzAk5Rj94c5oAF5VwBxgEe uAf/AK9ACEnaABhRgH3I55NADQSOR279P8/doAkLKcZGcjk9DmgAGAkhGSPlGTwcZoACNjbcbuPn HY8ZNACEBWBxuU5IzkZ/zmgA3DG7yx1xnJxmgBCQeFUDnjBJJPp+lAClWZiWIBPOSQKAEwAMhuR0 xnH58UAKWDAkj5x3Hce9AATEc/eJPc46/rQAiqHAUE5J/ADFADtyglOTGTwepB/vUAI6kMd55IyD 1BoAUkEJIQSQcNk9SBQA3AYlmOMk8AZJJoAXeq/cHPZm5NAAySk5ILdsjmgBAduCMhgeQemKAAFP 4lJJz0OBz+f+1QAu5R0QfiSf8KAEBYkgAAEZI7AUAGQh+XnIIJPA5oAFPUEEjqccYx3oAUblGY2J XqcdR/vCgBPMkH8R49/T/wDVQA5cs67jnPJHfC+tAAMkFlJ3ckjvg0ANDEKVIBB5HsaAFYL8oJwC oIwAecdTQAhjbGVww7FeeKAEOwEYyR36A59qAHBgASqDAxkkk/4UCDdIVLA4UHBA44IoGEagnaw+ 8CFJ7GgAyFQgH5m4b2A7UAN425yd2enbFAB8xUDB2g8ccAmgBSuEBJ5bkD2oAQhcAgkk5zxxQA5g FABHzHBY9SPagAKFRlTleAWHH5gYoAUyOCRu3D3GQc/WgBgIzkjI7jp/nrQAnBOOgJ6DnFADywBC gfKDkg9z70AIuMMTj7pIz9aAFjGMk8AqSD6jFACKUHzEkkZ4HH60AKXJG0AKpI4HWgAYhXcAY4Kj 2HSgBFOCWBwwxgYznNACsQMlCNrA8Y6A9qACTOE4/hH86ABclCQcFCDkDBOfyoARnLDDAE+uOf0o AMDywe5Yg/lQA6MDIUkEOMfQnpQA05PAyQM4HXFADmw2HIJPRwOORQAnmAfdUD3PJ/WgBeWYb2yA CWGegHtQA1yxYlhgnt6CgBV2A7geFAODjJNACEFiDnLEnIxyPegAOYyCCNw6gHOB6UCAspAIG1h6 dPrQMXzJME78Y4xkZP6UAK3mEbSQRgNzgZFACAeYuOsgHHuAKAAFQGwTyvfjnNACKxUnGeQR+dAA FJUnaTnBDDPFACoBvQbcEHLZ9Ac0ANALN2BYk8njJoAcHfOFAzjHABNACtJIAVJIbPI7YNADWyQp JB4wB6AetACoQzMMABgRgZ7c/wBKABVALHIYKPwJPAoAACYwAMkscDueKAExhQ2TuJOPoP8A9dAC iRyRlyB3OTxQAu1D/wAtB15yCOlACMoOMMvA7ZGcUADDcC38Q+8PUf36AFDuFBJDLnABwcUANJQ4 IBBzzzkY/wAigBS+BiMEDjJ7mgAjAAMhGQOAD3JoAXaVXDgLnkcZbj0oAaSCCFXj1PJ4oAVvmWPn HVTngcf/AK6AAAKpbPzBsAjpxQAjlThgME/eA6ZoEKVGSWwoPIUck0DEQkElTg4wBgknNADnZ1O3 eScEHnOCfegBoMYA+Xc3fPTOfSgBfMO05O3pgKABQAKhHzABgByOePqOKAFLHIChckDAAHBP1oAU sRtY8sCQfTA+lACbSwWNcZxk54ySOn/fNADdzABSCCDnuDkigBXByFAJCjHQ9e9AASpBAUKeMdST zQAMFUYPL8Z/2aBCABsDoeeTk5zQMMFWwTg+vXg//roAXKL90bj2LDj/AL5oAA5LEsN4xz2wKBAy hRkDcrfdJGDkdqBiFiQoHAHAPuT1/WgAG4MCAdxwRxyc+1ADmIUFc5yfnI9v4aAEJHlsoPQ5GeCQ RigAfhEXuQWP4mgBFbGAuATwWPXmgBpHJGcjOM+tADwwVdwPzkHkdhQAIQGQjOQQG9AM4oAC8ikr kYBwBgdvwoAcGYkBTkYySVAAoAazLkbeSDnd0yfpQAjFmTLYIBxuOAaAFPMS56ZOc9jQAhXOWXhR 0JIBNADz82A3EmAVYnGfTNADDuDEEkEnnJI6+tAApCDI+9yAOw96AFQkIzHqflGfU/eoAbt+Xdxj OPfpQA4H5QsgIHVTjpmgBACCVABJ6nggY75oAViMbV5Uck9yR3oACdhwOUYAkHnOaAFB2ruPTJKK ef8AgVADd7Als/Me/ORQAgJGSBnjGD2oAcVHyAYGRknoM5oAXacH51ORjk5OBQAhwowQrZ7gkkUA GYzwykfQjp+NADQCTgAkk8evWgBzkDCLyE5Jx1I70AI3zSEqDySQMHPNAD2GVAUgKOoJwSR/eoAD GSMspJxztIA4+maAGjaBnacZxnIxn8qAD92vzHkHkIDnH+8aADDyHgZx2HAAzQA0qw+8CPqPagBw KnJcliMAD/69ACLuwwUdRggDnFADgC4VVHAyWJ4GSaAEyq/d+Zv7xxgfQUABR2bjLEgEn0BoAcI5 ApAAGcZJIzgfw0AMwVBIYAkYIBGcGgBTyqEAEgkfrx/OgAJOC7ckEAg9OBmgALuvGAvHQAA4x+NA BJv43E4PIBPOKABhkR88EYyfTNADSDgkcqDgkZIoAUbCACSrZ69RQAoVwDt5U8ErgigBEfbkgckc H0z/AProAUKQCWOxT2PUge1AAW2j92No6Fu5P+f7tAAcBFIAOQQc560AIigAueg4A6ZJ/KgBVGAC xIXqB6kf5+9QAmFXKsCCCeQcY496AAhMEhsEdAQQaAF3FcbWIGORzgGgBTuLEOQdoJPSgBg4JJJB AOCOuaAHZVzhuGJ+8BwT/tCgBCHQkZ4YdRyCD70ALL94AdAAOntQAFQMEAMrjAzgEGgAEbDqR15G QP60AK6kA4wBnIAOTz6UAITmIDOSWJPPt9aAAkR9DuYfxdQMf3aADbmQLkMSRkg560AAUYJYnYCQ vqf92gAIaTBGABkKmQCPzoAAjgEbM5GBxnH5UAJhlOcEEdyCKAF+UAMQWyeTnAzigALMWBIBJIOB 6nsfyoAVcYcYB2ncBnIwPlPNACAgxuDjIIIH14/rQApaPAwCQoO0HgH1ZqAGtksdzAkDOR04HSgB T8yZz8yDk+o9f+A0AAAIBICherevtQAhbOAAAOwFAAcBAB1bBJ9PQUAIwO4g8kE5I5oAcAgBxIQC MHKnnJoAQhMHDEnnAwRQIdnKMx5LEAE9gP8AK0DEUp9052kck44PrQA0LgkEZAJzjHQHBoEBU4yA dpPB7UDHYjB5YsfYY6c/xUAAeMfdQH3Yk9KAFTCksDnapPcYJ4xQAikAbiWBXgEYOM0AIQuCdxJz jBGM8/jQAbQEVhwST+lABuJUgsSRjA5IoAULmNVBAyT14AwKAAfKu7+JhgD2PegATaCCckDIbA4w RigBFYLnKhvc9aAHBgQT5a4BAPJzzQAjFRkeWAfUE8ZoADjarDIH3WwcHNACFySCOAMbQOgoAUoT kuQmSevU/wDAaAAKCGGD03KSOTg0AIZGK7cgL/dAAFADvLBAJG0c5J6n6CgBuQAQBkHGCRgjH+Wo AWTgIvoMn6nmgBGQbQRnjAYHqDigBUwCQDnKnIx3HagBIy27C8k8EHoRQAoCt93Ct3XIwTn+E0AI MkFSwUZyc8DIoAcAoBBkGDjIAJ6UAIGCHC5IIAYEYzQAMq7dygFSevccfdNAATiOM4yQTweehoAA o6nALZ2rnAx60ABjkIAxkdhkEUABIJ3MpIP3RnAwDigAJZgM4Ck8AcDr7UCAb1LKMEDk5xjg9aAA KGIG0gkZGOQRigYE5VHIzj5SD046UACYbcuMAgkAdiORQAoZicRgLkE8dT3+8aAIzkkknJPX3oES qPnAY53LjPsRQMYrlQAoAb+91PNAAVck5BLDkjqaAF6RfVv5CgA8thjJCjtk0AKOGPzFieCAM5/7 6xQAmUU8AnGQc98jbQIYASCeOOcdzQA8ooYgtgYBBwTkEUDFCErgFSc5yCQenvtoAYBnPOWGMDBJ J/WgB6kksjZyQAMjnI6UANQkZYYIGAwPcE0AKpywAUkDlV69aAB1bOWI3Mfu55oAQYUkOmT65x2o AUiPOMlSDgggH+VAAqgSLyDkjkUAISuWBHJOBg8daAFkySB2CgH6kUACkFWU4yQCM+ooAFCsABw4 6ehoAFLKQSMBSMnGDz2oARgql1xyDgeg5oAWX/WEAYwAMfQUAJiM45YevANAC/ugDgvkjHQd6AEO NijPIJJH1/8A1UAAjcAEjaOxPHP0oACEXIBJYHGcYAxQAqI5wwXIHc4x+tACFVAJLgnHAHPP1oAV gCEOeowT9DigAzGOMFj78Dr+NAB5jnCrhQSBheOfrQAfvFAHfcTjAySKADMe4kAkHGADjr/+ugAL MVJXCrkDA9T3NACbSACCAGGQc8ZFAhVBDKu3ByMnof6UDEyC5LZwSScdRmgByoRIpHKkjBHtQAAK Q+DnKkkdO9ACFm3MyE46k+1AANjjB+RugwODQA0EAkEA5BA7gGgBxYMpDZ3AcEd8etACEljuIwAQ DjjqKAHEruaQkEZ+UepHSgBGK7QuTlScggcZ60AKSQDkZkcYPGcD6UCGrlQGDbQcjI7ACgYu1M58 wlhzkA8UAAGGGw7yeoI/xoAQhScAhSOxORwexoAFBZTkAAEEsT0zQAHZkbSQO7H/AOtQA8GTBJIK 843AHNADNykEFQOuCCRj+dAC5O1cZzk9PXIoAA4JBbIYHhhjOfcUAGPkYZz8w557g0AKpD5QDGeV APQgf+zUAKGAKngAjgnqp70AMCr/AHwPcAn+lADlCrwG3A/wgHk0AJHgOQeAQQc44yKAGgYG4EcE cHv/AJxQA6RR5h5AB5BPTBGaAFKOQFBBGSQAR6UANC5JBPI6ADOSDQArDEajGMkkj6cUAA2EElSx Ay3IAxigBzlRIWIyCAyjqCTQAxdzSZBwTklvSgBesZwc4Oc4HQjr+lAAinBJO1DwTnGcfw0AGQVI XCqBzkgE0AG5cAn5iAABjA49aAELFiNxAABI4wBx7UCFBAzsAyBnc3Xg9vzoGJh3y3JwOTyeKAHK 2F34AK/KuPU+v+7QAgVwBkhQMkE9ee+KAEYp1Ukk5yTgZoAUR5BCkHplTwwOKAEJIwMYYHOec0AK SQWDDk84GBgmgACYUB8KM5JP3jn/AGaAEYrwFBHueScUAChiSwAIHJyePzoAUqozlgW7BeRn60AD EEIcgnGCB14NACfugOhY9SDgCgBSzFSRhRnBUcZoAMBsYIAUAEnA/wBqgBcRgEjLYxnHA/zxQA0s DjcM4BB5xnrigBWwg2A5Y8uR/wCg0AABO4KMof4jxjB9aAAjByDvVRzgkAZNACsIwSGUqR3BBoAa ApYbScHgEgZz+FACBgcbhwAcEYBoAd5gH3FAx3PJ4oENLuRgkkenb8qAHMwBAU/Kg4I/U0DEYNkt yR/eIIoACBtDAAZOAB3wKAHPy5OCQQCAD3IoACx2DOGDA4yMkYPrQA0EqAwI5zzgEjB96AHYUHeH bIP3tpNADSwAwCWB6hhx/OgBcKwwDtIOcHJFAgVcqcgBc8MeTx2FAxFwHySQB3HWgB+6XGWAI/2g P64oAbvU8lAT6g47/jQAEhRGRwcZzjJ5NAC5VhgnYTycZ2k0CG8MPlBDeg5B5oGOVCASUJI9eAB+ lACZLFS5ypOMdgPoKABVIJHB3ZHXByOf6UANBKnOOowcj2oAVuAnY4yT36//AFqAFYgMTgHcM4PY mgAVAQCrAkYJUjFACFXVslcc5xjIoAVZJScKcYHYADH5UAIwfA3EknoCSTQArZJCKM7RgAc5PU0A IXyFwcHbtb3GaAFYkCMg8hcg9zkmgAxgNGTyPmGORx96gBmTg4OAetACgDBycEdBjOaAFVgBgjKj JC9OTxQAEksDICRjhenBoAcGOCUAUAduTj6mgBpRiCx4HPLHBPHvQA4E7d3UthRx2HWgBdpG1nOw AADuSR/s0ANYoxwABySWJA5oAcPMMgQsfQ4PGKAIwRkkjPpnPFACsAqAEDccEk9QMcCgBSdsgYds HHuRQAGPAJYhSeid+tAAwGIwTgFRk/U0AARsZAEigEDBPGfagAYAorAYOSGOO/agBNzKBtY9MkDP BoAdlVORhn657DNADMhiScknofc0AOBjB6NnvyBz+VACExkHAOT3JB/pQAq8KXPXovscdaAEBwAQ Tuyc0CBQcFgcFcEDrQMUsBwwUgdSvHT6UAC7C23GAwxzg4PagBvcbs4HBHegB28gEooUDHzdTz9a AEYHdyQTxznP60AKxG4DOFXAyPagBhOST15PXqeaAJAVCFgAAWAHsAKAALs3nBBAwufU0AIAAwDD G3kgdT3FAApLMxLBc8HPXn0FADsYB8rBA6uSCR/LbQA0gZwxIbuchgaAFKMnzMQDg7T1zxQAwBhy MjHcZ4/lQA8E4YSZywyM9yP/AK1AhAYyADlT2bqD+FAxCpBABB9COaAHglhlwQQQA+OQeuGFADSA pJkBYnkHPBFAAWKnAUKffk/+PUANAByScHqODyaAFBIADDKkZwfQ0AOQLuAB4bKkHryP/iqAGruB GBy3A4zmgAIHAUEkdWGT+VADmBDccFxyDjgnqOfpQAiA5KHjdx6c9R/KgBFYDIKgnpyDQApbABG0 E5yABx/OgBWLlfmY5PRfbPfpQAjnCoPbP5mgBysCwUZ8scnJz0oAaGQksxIckkEEDrQAERkEgtk+ oGM0AIoGNzZwOAO5xQAK4DZHAJ7c4/OgA3YbcfmIOeR1/wA4oAVUYPjJUgZJHHFABvBHzKCT/EOD /wDE0AIBlSApJJHIzjmgAHI4JDj0zkjNADg0hAxIc9wTjmgBhBBwwII9fY0AOBGdpJZRwCByPp/8 TQAPGUA3EFieFHegBGy2wDk4A/U0ADAKcK2SOpHQGgBxYqAQcqRgkjOPVaAEJZiFBJyBkdAD+FAC MFUbRyw6nsDnoKAAMMAN26N3GKAFBUlg/UnhuwNABjyySwy3bIyOnX9KAA+WxPLA984P8qAABRkk hgeMgnIPrj8KAP/Z ------=_NextPart_000_0005_01C1D681.ACE50520 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhKAAaAPcAABA5jBBClBBKlBg5jBhKlBhKnCE5eyFKlCFKnCFSnCkxeylSnClSpSlapTFa pTFjpTkpYzljrUJrrUopWkopY0o5a0prrUpzrUpztVJztVJ7tVpjlFp7tVqEtWOEvWuEvWuMvXOM vXOUxnuUxoR7nIScxoSczow5UoylzpRSa5StzpSt1pwIEJwxQpxKWpytzpyt1py11qUAAKVKWqWt zqW1zqW11qW91q0AAK0ICK0QEK2Mpa291q293q3G3rUQELUYGLUhIbUpKbXG3r0xMb05Ob1CQr2E lL2crb21zr29zr3G3r3O58ZCQsZKSsZSUsZaWsa9zsbW585aWs5jY85ra85zc86cpc6ttc61vc61 xs69xs7G1s7O3s7W587W787e79Zzc9Z7e9aEhNaMjNaUlNacpdalrdatrdattda1vda9xtbW59be 796MjN6UlN6cnN6cpd6lpd6trd6ttd69xt7O1t7O3t7n7+elpeetree1tee9vefO1ufe5+fv9+/G xu/Ozu/W1u/e3u/v9+/39/fW1vfe3vfn5/fv7/f3///v7//39/////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////yH/C01TT0ZGSUNFOS4wFwAA AAttc09QTVNPRkZJQ0U5LjBCPKT1ACH/C01TT0ZGSUNFOS4wGAAAAAxjbVBQSkNtcDA3MTIAAAAD SABzvAAh+QQBAACNACwAAAAAKAAaAAAI/wAbCRxIMMaDDH8a/UFhAUGAAAguqEhI6MICFAQzaiT4 IgCBACFCfEyQ4cOHCwU8hgyQIECJRoIYbSTICIqOIwQS2HgYwMKQjIqGWOA5xEEAFzKKyJzZSIwM GRAC8ADBkgfTRjwOBPAgJYCBp1aYCsoBJEUADV0HtFg6ExELAwGYiAhAIkgOQTONyLiSgECbBwFO yMDLdI+MGQEc/Ol7JelGOTKMjAiAAkUAEEVkDLoaKPJcFB09PJEBJ2MiIDm0BGjQJmcaGUSuCsx8 ZoFfwFFy6EBEsIoMMRcCDOEQ4EUQGYBkNwqUIwiNABmW9BwjA8pAQDKEPM/Qo6fTKsoFWv+RYSVD gBvEXwiRwUcgERlpbHvpq4VsovCNEtnNktNLTjXZMQKHDE9MVgJxKGSmB34CGUZERxpYNoJvY6xn BwELDNHTHDI4weBAo80R3BC2+UEWbDy4FIJwUCD3oUB6kLcTCnMt8Z4OOqRYgmUojPfGi41QIYMc xC1BHBfNtXhGAQnggUACYwFxH4OdCcFGABJ0JQF1Y2BHRAkgGehUWAxmtkdwPUgQQBI43tdiGYAt IZ9dhCkHmRM7aRDDVkKSIRAiuikRQATdScChEeGdloMdCBAwHwFryBAEW2TIQIUHAahAnA16zaHc mFShsCIKeu1B03pqIFCAFDnZYd9Vg5B91UUAD3TlAIceZmRYER11AOYI44lx1WhwqLmEmkMcVydB xKrJQwMBdIEaFzNhkdROHGBLHXgbxQrErA7cAB1kCjTwgQo39PBCCAtMIEMdfT3q6m5M7TDBBgsE cMFHHFAwAE8Ae1WBmg6o2cAGEyBxlSLQBuzwww87oEhGAQEAOw== ------=_NextPart_000_0005_01C1D681.ACE50520-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 28 06:23:07 2002 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 GAA21287 for ; Thu, 28 Mar 2002 06:23:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA10607 for dhcwg-archive@odin.ietf.org; Thu, 28 Mar 2002 06:23:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10083; Thu, 28 Mar 2002 06:19:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10057 for ; Thu, 28 Mar 2002 06:19:29 -0500 (EST) Received: from localhost ([211.219.142.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21153 for ; Thu, 28 Mar 2002 06:19:22 -0500 (EST) Message-Id: <200203281119.GAA21153@ietf.org> Reply-To: abc@eintech.co.jp.kr From: AVCAFE To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Thu, 28 Mar 2002 20:17:52 +0900 Subject: [dhcwg] [광고]세계 최초 휴대용 디지털 어학기 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Untitled Document




  본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고]메일입니다
  귀하의 E-MAIL은 게시판 등 인터넷 상에서 알게 되었으며, E-mail을 제외한 어떠한 정보도 알지 못함을 밝힙니다.
  메일을 수신하고 싶지 않으시면 [수신 거부]를 클릭해 주십시오.
  전송자 : AV 전문쇼핑몰 AVcafe
  연락처 : mailing@eintech.co.kr
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 28 10:26:40 2002 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 KAA00474 for ; Thu, 28 Mar 2002 10:26:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22388 for dhcwg-archive@odin.ietf.org; Thu, 28 Mar 2002 10:26:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22306; Thu, 28 Mar 2002 10:25:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22280 for ; Thu, 28 Mar 2002 10:25:00 -0500 (EST) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00276 for ; Thu, 28 Mar 2002 10:24:51 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g2SFNfk01530 for ; Thu, 28 Mar 2002 10:23:41 -0500 Message-Id: <200203281523.g2SFNfk01530@cichlid.adsl.duke.edu> To: dhcwg@ietf.org Date: Thu, 28 Mar 2002 10:23:41 -0500 From: Thomas Narten Subject: [dhcwg] stalled (?) dhc WG documents Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The following documents have been submitted to the IESG, but are awaiting revised IDs (per IESG comments sent a while back). draft-ietf-dhc-concat-01.txt (Comments sent Feb 1, 2002) draft-ietf-dhc-csr-05.txt (Comment sent Feb 1, 2002) draft-ietf-dhc-agent-subnet-selection-00.txt (discussed in Minneapolis -- what was the resolution and next steps?) What can I do to help move these documents along? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 28 11:22:36 2002 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 LAA03056 for ; Thu, 28 Mar 2002 11:22:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25247 for dhcwg-archive@odin.ietf.org; Thu, 28 Mar 2002 11:22:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24902; Thu, 28 Mar 2002 11:16:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24877 for ; Thu, 28 Mar 2002 11:16:22 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02611 for ; Thu, 28 Mar 2002 11:16:17 -0500 (EST) Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2SGGBp16264; Thu, 28 Mar 2002 11:16:11 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (dhcp-161-44-149-122.cisco.com [161.44.149.122]) by goblet.cisco.com (Mirapoint) with ESMTP id AAX23996; Thu, 28 Mar 2002 11:15:47 -0500 (EST) Message-Id: <4.3.2.7.2.20020328110945.022740c0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Mar 2002 11:15:47 -0500 To: Thomas Narten , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] stalled (?) dhc WG documents Cc: kkinnear@cisco.com In-Reply-To: <200203281523.g2SFNfk01530@cichlid.adsl.duke.edu> 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: X-BeenThere: dhcwg@ietf.org At 10:23 AM 3/28/2002, Thomas Narten wrote: >The following documents have been submitted to the IESG, but are >awaiting revised IDs (per IESG comments sent a while back). > >draft-ietf-dhc-concat-01.txt (Comments sent Feb 1, 2002) >draft-ietf-dhc-csr-05.txt (Comment sent Feb 1, 2002) >draft-ietf-dhc-agent-subnet-selection-00.txt (discussed in Minneapolis > -- what was the > resolution and next steps?) I was going to revise it based on the comments in MN and based on whatever you told me was feedback from the IESG as far as IETF last call (a title change at least to add IPv4, as well as other comments I haven't yet received from you). As the comments in MN only touched on a relatively minor part of the draft (sending the sub-option back to the client if you used it), then I was assuming that we didn't need to go through WG last call again, but I'm open to suggestion on that. So, I see the following possible approaches: a) I revise the draft based on IESG comments and MN comments and we are done (based of course on the IESG comments and some final review of the result). b) I revise the draft based on MN comments and resubmit it, and then it goes again to IETF last call. c) I review the draft based on MN comments and it starts over again at WG last call. Thomas, Ralph, what do you prefer? I'd prefer (a), but (b) isn't bad. I don't like (c), but I'll do whatever you want. Cheers -- Kim >What can I do to help move these documents along? > >Thomas > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 28 13:23:20 2002 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 NAA09242 for ; Thu, 28 Mar 2002 13:23:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03900 for dhcwg-archive@odin.ietf.org; Thu, 28 Mar 2002 13:23:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03691; Thu, 28 Mar 2002 13:20:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA03660 for ; Thu, 28 Mar 2002 13:20:01 -0500 (EST) Received: from localhost ([61.43.222.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09098 for ; Thu, 28 Mar 2002 13:19:57 -0500 (EST) Message-Id: <200203281819.NAA09098@ietf.org> Reply-To: ponkiphone@hotmail.com From: 드림 To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 29 Mar 2002 03:21:51 +0900 Subject: [dhcwg] [광 고] 무담보,무보증,신속하고 편리한 "대출" 드림론패스가 책임집니다..... Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org

신속하고 편리한 "대출" 드림론패스가 책임집니다......


                           

   

* 가입비, 연회비 평~생~~없습니다.
* 무담보, 무보증, 낮은 이자로 최고 2,000만원까지대출
* 매월 10% 이상만 결제하면 되며, 입금액만큼 한도증가!
* 인터넷, ARS대출시 대출기간(1~10개월) 맘대로 선택!!
- 최저 연 3.9%의 이자율(신용등급에 따른 차등 적용)
- 대출기간이 짧을수록 낮은 이자율
* 편리한 대출 방법
- 전국 은행 현금 지급기는 물론,
- 은행 마감시간과 상관없이 24시간 내내~ 인터넷, ARS, 한네트 현금 인출기 사용가능
* 제시만 하면 푸짐한 혜택이 마구~!! 다양한 제휴 서비스!
- 현대, 기아자동차 정비 할인 등 자동차 관련토탈 서비스, 호텔,콘도 최고 40% 할인 등

 카드를 신청하실 분들은 배너를 클릭해 주세요....

본 메일은 정보통신부 권고사항에 의거,제목에 [광고]란이 표시된 메일입니다.
허락없이 광고메일을 보내드려 죄송하며,정중히 양해 바랍니다.
또한 귀하의 이메일 주소는 게시판이나 동호회등의 공개된 메일주소를 수집한 것 으로 기타 다른 개인 정보는 없음을 알려드리며 수신거부를 원하실 경우 아래의 e-mail주소를 적어주시고 수신거부 버튼을 클릭하여 주시기 바랍니다.
   

                           자동으로 수신거부 되지 않으시면 여기를 누르세요....

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 28 13:47:50 2002 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 NAA10220 for ; Thu, 28 Mar 2002 13:47:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05434 for dhcwg-archive@odin.ietf.org; Thu, 28 Mar 2002 13:47:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05156; Thu, 28 Mar 2002 13:43:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05133 for ; Thu, 28 Mar 2002 13:43:06 -0500 (EST) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10030 for ; Thu, 28 Mar 2002 13:43:03 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g2SIfhd03530; Thu, 28 Mar 2002 13:41:43 -0500 Message-Id: <200203281841.g2SIfhd03530@cichlid.adsl.duke.edu> To: Kim Kinnear cc: dhcwg@ietf.org Subject: Re: [dhcwg] stalled (?) dhc WG documents In-Reply-To: Message from Kim Kinnear of "Thu, 28 Mar 2002 11:15:47 EST." <4.3.2.7.2.20020328110945.022740c0@goblet.cisco.com> Date: Thu, 28 Mar 2002 13:41:22 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Kim Kinnear writes: > >draft-ietf-dhc-agent-subnet-selection-00.txt (discussed in Minneapolis > > -- what was the > > resolution and next steps?) > I was going to revise it based on the comments in MN and > based on whatever you told me was feedback from the IESG > as far as IETF last call (a title change at least to add > IPv4, as well as other comments I haven't yet received from > you). I think I've sent you all the comments I have. But if you point me to a copy of the revised ID before you send it in I will double check. > As the comments in MN only touched on a relatively minor > part of the draft (sending the sub-option back to the > client if you used it), then I was assuming that we > didn't need to go through WG last call again, but I'm > open to suggestion on that. > So, I see the following possible approaches: > a) I revise the draft based on IESG comments and MN > comments and we are done (based of course on the IESG > comments and some final review of the result). This seems fine to me, though I think "some final review of the result" could in practice be a one-week WG last call. Especially if a few folks quickly chime in and say "I've read the new text and its good". Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Thu Mar 28 15:39:16 2002 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 PAA14196 for ; Thu, 28 Mar 2002 15:39:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12626 for dhcwg-archive@odin.ietf.org; Thu, 28 Mar 2002 15:39:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11771; Thu, 28 Mar 2002 15:32:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11717 for ; Thu, 28 Mar 2002 15:32:37 -0500 (EST) Received: from newsweek-event.com ([211.104.43.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13917 for ; Thu, 28 Mar 2002 15:32:28 -0500 (EST) Message-Id: <200203282032.PAA13917@ietf.org> Reply-To: shasha@newsweek-event.com From: 중앙이벤트 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 29 Mar 2002 05:30:54 +0900 Subject: [dhcwg] 환상적인 문화혜택이 (무료 영화,연극,콘서트,뮤지컬,명강의 등) -홍;보 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 안녕하세요? 중앙 테마 이벤트입니다.

본 메일은 발신전용입니다.때문에 송신자 메일주소로는 회신을 보낼 수 없습니다.
죄송하지만 수신을 원하지 않으시면 맨아래의 수신거부 버튼을 클릭해 주십시요.
문의사항은 홈페이지에 오셔서 문의하시면 친절하게 답해드립니다.
귀하의 승락없이 홍보성 메일을 보내게 된 점 정중히 사과드립니다.

 
     
 
지금 신청하시는 분에 한하여 폴라로이드 카메라나 로만손 고급 커플 손목시계를 드립니다 
문의 : 02) 771-9495

담당 : 박    현    주

 

  
     
                 중앙테마이벤트는 중앙일보 뉴스위크지사에서 하는 이벤트 홍보행사입니다

  [월회비 10,500원]

특별 사은품증정 : 폴라로이드 카메라 또는 로만손 고급 커플시계중 택일
국제 시사주간지 뉴스위크 한국판 : 2년간 100부 (매주1권)발송, 영한해설 별지부록 8Page
                                                        포함 
영화로의초대 : 연 8회이상, 무료초대권 (2인 입장)
    주말에 상영하며 시간선택가능, 개봉하는 우수영화 또는 시사회를 선정

                        *이전영화 - 아트어브워,캐스트어웨이,미스에이전트,섬원라이크유,신라의달밤,
                                          혹성탈출,킬러들의수다,달마야놀자,화산고,반지의 제왕 등
라이브콘서트 : 연 4회이상, 무료초대권 (2인 입장)

                        *이전콘서트-이은미,김경호,안치환,김민종,김현정,자우림,윤도현밴드,서문탁 등
명강사 명강의 : 연 6회 이상, 무료초대권 (2인 입장)

                         *이전강의-황수관,이시형,엄길청,정덕희,전여옥,구성애,백지연,표진인,끄레벨박 등
연극, 뮤지컬 : 연 12회이상, 할인우대권 (50%~20% 할인율)

                        *이전공연 - 브로드웨이 42번가,코러스라인,넌센스,아리랑,드라큐라,여로 등
정동극장 : 공연 20% 할인혜택 (중앙 정회원 멤버쉽 카드지참시)
 정회원 멤버쉽 카드발급 : 중앙테마이벤트에서 주관하는 문화행사 초대

 

저희가 회원분들에게 제공해 드리는 회원혜택을 자비로 이용하신다면 월 50,000원 이상 지출될 것입니다.행사기간에 회원가입을 하셔서 월 10,500원에 이 모든 문화생활을 누리세요. 폴라로이드 카메라나 로만손 커플손목시계는 행사기간에 가입하시는 회원분들께 드리는 사은품입니다. 여러분의 질높은 문화생활에 도움이 되고자 하는 중앙테마이벤트입니다.

                                                                       회원가입과 자세한 내용은 홈페이지로
  


본 메일을 거부하시는 분은 [수신거부 ]를 눌러주십시요. 불편하게 해드렸다면 죄송합니다.
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri Mar 29 14:08:38 2002 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 OAA28782 for ; Fri, 29 Mar 2002 14:08:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25740 for dhcwg-archive@odin.ietf.org; Fri, 29 Mar 2002 14:08:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25596; Fri, 29 Mar 2002 14:06:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25574 for ; Fri, 29 Mar 2002 14:06:10 -0500 (EST) Received: from orgio.net (s210-221-102-20.thrunet.ne.kr [210.221.102.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28630 for ; Fri, 29 Mar 2002 14:06:05 -0500 (EST) Message-Id: <200203291906.OAA28630@ietf.org> Reply-To: abnormal@dreamsolution.co.kr From: 박미애 To: Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 30 Mar 2002 04:10:01 +0900 X-Priority: 3 X-Mailer: Mailtouch 1.0 Subject: [dhcwg] [광고] 영화를 보면서 영어를 정복하세요.^^ Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org
mail_main---
-. 본 메일은 정보통신망 이용촉진 및 정보보호 등에 관한 법률 제 50조에 의거한 [광고] 메일입니다.
-. e-mail 주소는 인터넷상에서 취득하였으며, 주소이외 어떠한 개인 정보도 가지고 있지 않습니다.
님께 허락없이 메일을 보내서 죄송합니다.
귀하의 이메일 정보는 인터넷상에서 발췌한것으로 메일수신을 원치 않으시면 수신거부를 해주십시요.
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Sat Mar 30 10:45:28 2002 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 KAA29917 for ; Sat, 30 Mar 2002 10:45:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27199 for dhcwg-archive@odin.ietf.org; Sat, 30 Mar 2002 10:45:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26881; Sat, 30 Mar 2002 10:36:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26861 for ; Sat, 30 Mar 2002 10:36:20 -0500 (EST) Received: from localhost (s211-33-38-154.thrunet.ne.kr [211.33.38.154]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29791 for ; Sat, 30 Mar 2002 10:36:14 -0500 (EST) Message-Id: <200203301536.KAA29791@ietf.org> Reply-To: skck64@hanmail.net From: skck64 To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 31 Mar 2002 00:35:55 +0900 Subject: [dhcwg] 성인만보세요(성인-광고) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 
(성인전용)

*아름다운 음성 색다른 소리!! **              


060-700-7733 를 누르세요.   
(전국시내요금) 가입비 없슴
색다른느낌이  
  060-700-7733



죄송합니다
본 메일은 정보통신망 이용촉진법 규정에 따라 광고메일임을 표시하였으며  수신거부장치를 마련하고 있습니다. 

본메일주소는 인터넷상에서 취득한것이며 메일주소외 어떠한 개인정보도 갖고 있지 않습니다
원치 않은 정보였다면 정중히 사과 드리며, 
수신거부를 해 주시면 다음부터는 메일이 발송되지 않을 것입니다
수신거부
_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg