From mailman-admin@ietf.org Tue Apr 1 11:01:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23556 for ; Tue, 1 Apr 2003 11:01:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GP7K17842 for ; Tue, 1 Apr 2003 11:25:07 -0500 Date: Tue, 01 Apr 2003 11:25:06 -0500 Message-ID: <20030401162506.29326.49607.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for DHC-ARCHIVE@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-admin@ietf.org Fri Apr 4 05:49:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13710; Fri, 4 Apr 2003 05:49:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Aq0K01132; Fri, 4 Apr 2003 05:52:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34AnvK01059 for ; Fri, 4 Apr 2003 05:49:57 -0500 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13649 for ; Fri, 4 Apr 2003 05:46:43 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h34AnBxA019538 for ; Fri, 4 Apr 2003 05:49:12 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-39.cisco.com [10.82.224.39]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA05106 for ; Fri, 4 Apr 2003 05:49:11 -0500 (EST) Message-Id: <4.3.2.7.2.20030404054016.042dd2a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Apr 2003 05:43:43 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: [dhcwg] WG last call on draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "KDC Server Address Sub-option" . The last call will conclude on Friday, 4/18. Note that this is a second last call, because there was insufficient response to the first last call to conclude that the WG supports progressing this document to Proposed Standard. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. There was one comment during the earlier last call, which is archived at https://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01968.html draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt describes a new sub-option of the CableLabs Client Configuration (CCC) DHCP option, which provides the IP address(es) of one or more Key Distribution Center (KDC) servers. This document is being considered for Proposed Standard as an extension to the CCC option, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-03.txt - Ralph Droms _______________________________________________ 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 dhcwg-admin@ietf.org Fri Apr 4 05:49:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13721; Fri, 4 Apr 2003 05:49:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34AqZK01158; Fri, 4 Apr 2003 05:52:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34AnvK01063 for ; Fri, 4 Apr 2003 05:49:57 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13651 for ; Fri, 4 Apr 2003 05:46:44 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h34AnCdo025041 for ; Fri, 4 Apr 2003 05:49:13 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-39.cisco.com [10.82.224.39]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA05109 for ; Fri, 4 Apr 2003 05:49:12 -0500 (EST) Message-Id: <4.3.2.7.2.20030404054730.042dc4c0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Apr 2003 05:48:57 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-loadb-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "Load Balancing for DHCPv6" . The last call will conclude on Friday, 4/18. Note that this is a repeated last call, because there was insufficient response to the first last call to conclude that the WG supports progressing this document to Proposed Standard. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-dhcpv6-loadb-02.txt specifies a load balancing algorithm for use with DHCPv6, which enables multiple cooperating DHCPv6 servers to decide which one should service a client without exchanging any information beyond initial configuration. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-loadb-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Apr 6 09:08:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27125; Sun, 6 Apr 2003 09:08:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36DCL809752; Sun, 6 Apr 2003 09:12:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h36D8P809661 for ; Sun, 6 Apr 2003 09:08:25 -0400 Received: from rtp-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27039 for ; Sun, 6 Apr 2003 09:04:10 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h36D6fxA024341 for ; Sun, 6 Apr 2003 09:06:41 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-15.cisco.com [10.82.224.15]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA20782 for ; Sun, 6 Apr 2003 09:06:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20030406090221.02197ef8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 06 Apr 2003 09:06:41 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Stateless DHCPv6 service Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Now that the DHCPv6 base specification is at PS, and the DNS and time configuration option specs have passed WG last call, I have published "A Guide to Implementing Stateless DHCPv6 Service" as a dhc WG document, draft-ietf-dhc-dhcpv6-stateless-00.txt. This revision of the document has been reviewed by Pekka Savola and Christian Huitema, and includes changes based on their input. Based on the interest in this specification, I would like to progress it quickly. Unless there are objections, I will start a WG last call for the specification in a week or so. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 8 10:15:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12281; Tue, 8 Apr 2003 10:15:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EJQ828686; Tue, 8 Apr 2003 10:19:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38E9F828255 for ; Tue, 8 Apr 2003 10:09:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10590; Tue, 8 Apr 2003 10:04:00 -0400 (EDT) Message-Id: <200304081404.KAA10590@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: Tue, 08 Apr 2003 10:04:00 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-stateless-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : A Guide to Implementing Stateless DHCPv6 Service Author(s) : R. Droms Filename : draft-ietf-dhc-dhcpv6-stateless-00.txt Pages : 7 Date : 2003-4-7 Stateless DHCPv6 service is used by nodes to obtain configuration information such as the addresses of DNS recursive name servers that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document is a guide to the protocol messages and options that must be implemented to provide stateless DHCPv6 service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-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-stateless-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-stateless-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: <2003-4-7125017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-stateless-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-stateless-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-7125017.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 8 12:28:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21016; Tue, 8 Apr 2003 12:28:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GXG808136; Tue, 8 Apr 2003 12:33:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38GUW808037 for ; Tue, 8 Apr 2003 12:30:32 -0400 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20973 for ; Tue, 8 Apr 2003 12:25:14 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h38GRkB0019608 for ; Tue, 8 Apr 2003 12:27:46 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-192.cisco.com [161.44.149.192]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA25059 for ; Tue, 8 Apr 2003 12:27:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20030408121603.00bbb820@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Apr 2003 12:26:50 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-loadb-02.txt (REMINDER!!!) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , (REMINDER!!! There have been no responses to this WG last call to date.) This message announces a WG last call on "Load Balancing for DHCPv6" . The last call will conclude on Friday, 4/18. Note that this is a repeated last call, because there was insufficient response to the first last call to conclude that the WG supports progressing this document to Proposed Standard. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-dhcpv6-loadb-02.txt specifies a load balancing algorithm for use with DHCPv6, which enables multiple cooperating DHCPv6 servers to decide which one should service a client without exchanging any information beyond initial configuration. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-loadb-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 8 22:14:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12172; Tue, 8 Apr 2003 22:14:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h392Id821491; Tue, 8 Apr 2003 22:18:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h392FR821373 for ; Tue, 8 Apr 2003 22:15:27 -0400 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11990 for ; Tue, 8 Apr 2003 22:09:57 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h392CTqj008354; Tue, 8 Apr 2003 21:12:29 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h392CSqp006673; Tue, 8 Apr 2003 21:12:29 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 8 Apr 2003 21:12:29 -0500 Message-ID: From: "Bernie Volz (EUD)" To: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] Stateless DHCPv6 service Date: Tue, 8 Apr 2003 21:10:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FE3D.346EE25C" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C2FE3D.346EE25C Content-Type: text/plain; charset="iso-8859-1" Ralph: The document looks very good. Here are some corrections & nits for you: In 1. Introduction, "through some other mechanism" ... other than what? [DHCP]. In 2. Terminology, add a "[1]" after "DHCP specification"? In 5. Implementation of Stateless DHCP, 2nd paragraph, there is no such thing as a "DUID Option". Replace with Client Identifier Option. In 5.2 Options required for stateless DHCP service, add "Server Identifier" option to the first list of options. The server always returns this in a Reply to identify itself. In 5.3 Options used for configuration information, add the references to the documents. [3], [3], and [4] respectively. In 5.4 Other options used in stateless DHCP, the Vendor-Specific Information can be sent by clients to servers as well (it isn't just for server to client). Also in this section, the Client DUID is Client Identifier. And, it is echoed back by the server if the client supplied it (so the statement "servers never send this option" is wrong - they send it if the client sent it). And, perhaps a warning to implementators that other options may be sent by a server which they may wish to ignore (such as Server Unicast and other configuration data options). In 7. Security Considerations, the 3rd paragraph is wrong. We don't allow a client to send an Information-Request option with anything but its link-local address and the destination is always a multicast. This document is also silent with respect to Reconfigure. As no Reconfigure-Accept is sent, Reconfigure will not be supported. However, clients MAY support this feature if they wish. You probably chose to ignore this to keep it fairly simple. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Sunday, April 06, 2003 9:07 AM To: dhcwg@ietf.org Subject: [dhcwg] Stateless DHCPv6 service Now that the DHCPv6 base specification is at PS, and the DNS and time configuration option specs have passed WG last call, I have published "A Guide to Implementing Stateless DHCPv6 Service" as a dhc WG document, draft-ietf-dhc-dhcpv6-stateless-00.txt. This revision of the document has been reviewed by Pekka Savola and Christian Huitema, and includes changes based on their input. Based on the interest in this specification, I would like to progress it quickly. Unless there are objections, I will start a WG last call for the specification in a week or so. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2FE3D.346EE25C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Stateless DHCPv6 service

Ralph:

The document looks very good. Here are some = corrections & nits for you:

In 1. Introduction, "through some other = mechanism" ... other than what? [DHCP].

In 2. Terminology, add a "[1]" after = "DHCP specification"?

In 5. Implementation of Stateless DHCP, 2nd = paragraph, there is no such thing as
a "DUID Option". Replace with Client = Identifier Option.

In 5.2 Options required for stateless DHCP service, = add "Server Identifier" option
to the first list of options. The server always = returns this in a Reply to identify
itself.

In 5.3 Options used for configuration information, = add the references to the
documents. [3], [3], and [4] respectively.

In 5.4 Other options used in stateless DHCP, the = Vendor-Specific Information can be
sent by clients to servers as well (it isn't just = for server to client).

Also in this section, the Client DUID is Client = Identifier. And, it is echoed back
by the server if the client supplied it (so the = statement "servers never send this
option" is wrong - they send it if the client = sent it).

And, perhaps a warning to implementators that other = options may be sent by a server
which they may wish to ignore (such as Server = Unicast and other configuration data
options).

In 7. Security Considerations, the 3rd paragraph is = wrong. We don't allow a client
to send an Information-Request option with anything = but its link-local address and
the destination is always a multicast.

This document is also silent with respect to = Reconfigure. As no Reconfigure-Accept
is sent, Reconfigure will not be supported. However, = clients MAY support this
feature if they wish. You probably chose to ignore = this to keep it fairly simple.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Sunday, April 06, 2003 9:07 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Stateless DHCPv6 service


Now that the DHCPv6 base specification is at PS, and = the DNS and time configuration option specs have passed WG last call, I = have published "A Guide to Implementing Stateless DHCPv6 = Service" as a dhc WG document, = draft-ietf-dhc-dhcpv6-stateless-00.txt.

This revision of the document has been reviewed by = Pekka Savola and Christian Huitema, and includes changes based on their = input.  Based on the interest in this specification, I would like = to progress it quickly.  Unless there are objections, I will start = a WG last call for the specification in a week or so.

- Ralph

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

------_=_NextPart_001_01C2FE3D.346EE25C-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 8 22:51:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13047; Tue, 8 Apr 2003 22:51:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h392uB823673; Tue, 8 Apr 2003 22:56:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h392rt823586 for ; Tue, 8 Apr 2003 22:53:55 -0400 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12983 for ; Tue, 8 Apr 2003 22:48:23 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h392ovtP010588 for ; Tue, 8 Apr 2003 21:50:57 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h392ouqp013456 for ; Tue, 8 Apr 2003 21:50:56 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 8 Apr 2003 21:50:57 -0500 Message-ID: From: "Bernie Volz (EUD)" To: dhcwg@ietf.org Date: Tue, 8 Apr 2003 21:49:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2FE42.1F710A56" Subject: [dhcwg] FW: I-D ACTION:draft-volz-dhc-dhcpv6-site-options-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_000_01C2FE42.1F710A56 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FE42.1F710A56" ------_=_NextPart_001_01C2FE42.1F710A56 Content-Type: text/plain; charset="iso-8859-1" I've written this new draft to reserve a range of DHCPv6 option numbers for site-specific use. Please take a look at it and comment. It would be good to get this adopted as a DHC WG item - please indicate YES or NO as to whether we should adopt this as a WG item. Thanks in advance. - Bernie -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, April 08, 2003 10:05 AM Subject: I-D ACTION:draft-volz-dhc-dhcpv6-site-options-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Site Specific Options for DHCP for IPv6 Author(s) : B. Volz Filename : draft-volz-dhc-dhcpv6-site-options-00.txt Pages : 4 Date : 2003-4-7 This document specifies that a portion of the DHCP for IPv6 [DHCPv6] 16-bit option space is reserved for site-specific options. Site- specific options are to be used for site specific needs and MUST NOT be used for public (IANA assigned) or vendor specific options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-volz-dhc-dhcpv6-site-options-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-volz-dhc-dhcpv6-site-options-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-volz-dhc-dhcpv6-site-options-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_001_01C2FE42.1F710A56 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: I-D ACTION:draft-volz-dhc-dhcpv6-site-options-00.txt

I've written this new draft to reserve a range of = DHCPv6 option numbers
for site-specific use. Please take a look at it and = comment. It would be
good to get this adopted as a DHC WG item - please = indicate YES or NO as
to whether we should adopt this as a WG item.

Thanks in advance.

- Bernie

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Tuesday, April 08, 2003 10:05 AM
Subject: I-D = ACTION:draft-volz-dhc-dhcpv6-site-options-00.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.


        Title           : = Site Specific Options for DHCP for IPv6
        Author(s)       : B. Volz
        Filename        : = draft-volz-dhc-dhcpv6-site-options-00.txt
        Pages           : = 4
        Date    =         : 2003-4-7
       =20
This document specifies that a portion of the DHCP = for IPv6 [DHCPv6]
16-bit option space is reserved for site-specific = options. Site-
specific options are to be used for site specific = needs and MUST NOT
be used for public (IANA assigned) or vendor = specific options.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-volz-dhc-dhc= pv6-site-options-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-volz-dhc-dhcpv6-site-options-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-volz-dhc-dhcpv6-site-options-00.txt".=
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C2FE42.1F710A56-- ------_=_NextPart_000_01C2FE42.1F710A56 Content-Type: message/rfc822 To: Subject: Date: Tue, 8 Apr 2003 09:31:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C2FE42.1F710A56" ------_=_NextPart_002_01C2FE42.1F710A56 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C2FE42.1F710A56" ------_=_NextPart_003_01C2FE42.1F710A56 Content-Type: text/plain ------_=_NextPart_003_01C2FE42.1F710A56 Content-Type: text/html

  ------_=_NextPart_003_01C2FE42.1F710A56-- ------_=_NextPart_002_01C2FE42.1F710A56 Content-Type: application/octet-stream; name="ATT64732" Content-Disposition: attachment; filename="ATT64732" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-7125154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-volz-dhc-dhcpv6-site-options-00.txt ------_=_NextPart_002_01C2FE42.1F710A56 Content-Type: message/external-body; site="internet-drafts"; dir="draft-volz-dhc-dhcpv6-site-options-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C2FE42.1F710A56-- ------_=_NextPart_000_01C2FE42.1F710A56-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 9 07:18:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21659; Wed, 9 Apr 2003 07:18:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39BMf803145; Wed, 9 Apr 2003 07:22:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39BJU803013 for ; Wed, 9 Apr 2003 07:19:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21438; Wed, 9 Apr 2003 07:13:48 -0400 (EDT) Message-Id: <200304091113.HAA21438@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, 09 Apr 2003 07:13:48 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-interop-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Results from Interoperability Tests of DHCPv6 Implementations Author(s) : R. Droms Filename : draft-ietf-dhc-dhcpv6-interop-01.txt Pages : 12 Date : 2003-4-8 This document publishes issues with the DHCPv6 protocols specifications, based on the results of interoperability testing among several implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-interop-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-dhcpv6-interop-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-dhcpv6-interop-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: <2003-4-8141726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-interop-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-interop-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-8141726.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 10 14:32:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29750; Thu, 10 Apr 2003 14:32:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIbN802258; Thu, 10 Apr 2003 14:37:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIXv801456 for ; Thu, 10 Apr 2003 14:33:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29539 for ; Thu, 10 Apr 2003 14:27:38 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193gVo-0003Kk-00 for dhcwg@ietf.org; Thu, 10 Apr 2003 14:11:00 -0400 Received: from bbmail1-out.unisys.com ([192.63.108.40]) by ietf-mx with esmtp (Exim 4.12) id 193gVo-0003Kh-00 for dhcwg@ietf.org; Thu, 10 Apr 2003 14:11:00 -0400 Received: from us-bb-gtwy-1.bb.unisys.com (us-bb-gtwy-1.bb.unisys.com [192.63.78.151]) by bbmail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id SAA14006 for ; Thu, 10 Apr 2003 18:25:03 GMT Received: by us-bb-gtwy-1.bb.unisys.com with Internet Mail Service (5.5.2655.55) id <234LNXC4>; Thu, 10 Apr 2003 14:29:42 -0400 Message-ID: <3010F4D7BBD5F64C9C2D17B9D17BB377011A5013@USTR-EXCH4.na.uis.unisys.com> From: "Dean, David A" To: DHCP - IETF Date: Thu, 10 Apr 2003 14:28:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] DHCP question Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, I hope this is the appropriate venue for this question, if not, please accept my apologies and please recommend a venue that is appropriate. Here is my question; I need to assign multiple IP addresses (at least two) to a common network interface having one physical MAC address; can this be accomplished using DHCP? If so, how would DHCP handle this? The multiple IP addresses would be in the same logical subnet. Thanks. David A.Dean Unisys 2476 Swedesford Rd Malvern, Pa 19355 EMail: david.dean@unisys.com Notice: The information contained in this message may be privileged, confidential, and protected from disclosure. If the reader of this message is not the intended recipient , you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to this message, and then delete it from your computer. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 10 14:41:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00256; Thu, 10 Apr 2003 14:41:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIjx802968; Thu, 10 Apr 2003 14:45:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIh5802845 for ; Thu, 10 Apr 2003 14:43:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29981 for ; Thu, 10 Apr 2003 14:36:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193gee-0003PJ-00 for dhcwg@ietf.org; Thu, 10 Apr 2003 14:20:08 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 193gee-0003Og-00 for dhcwg@ietf.org; Thu, 10 Apr 2003 14:20:08 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3AIcoRP024353 for ; Thu, 10 Apr 2003 14:38:50 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-192.cisco.com [161.44.149.192]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA26789 for ; Thu, 10 Apr 2003 14:38:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20030410143352.042e9610@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 Apr 2003 14:38:47 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] *DRAFT* minutes from dhc WG meeting, IETF 56 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Included below are *DRAFT* minutes from the dhc WG meeting in SF. Please respond with additions, deletions or corrections before 4PM EDT, Fri 4/11. - Ralph ----- Minute of dhc WG Meeting, IETF 56 ================================= Administrivia, agenda bashing, WG progress report - Ralph Droms --------------------------------------------------------------- Progress report since last WG meeting: RFCs published: The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4, RFC3442 Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration, RFC3495 Accepted as Draft Standard: DHCPv6 Link Selection sub-option for the Relay Agent Information Option for DHCPv4 Passed last call: Security Ticket Control Sub-option for the CableLabs Client Configuration Option DNS Configuration options for DHCPv6 NIS Configuration Options for DHCPv6 Time Configuration Options for DHCPv6 DHCP Options for Internet Storage Name Service IPv6 Prefix Options for DHCPv6 Review of new charter, request for milestones - Ralph Droms ----------------------------------------------------------- Droms announced that charter had been accepted by IESG and posted to www.ietf.org. He noted that draft authors will be asked to supply milestones for posting with the charter. DHCP security review team report - Barr Hibbs --------------------------------------------- Review team has made progress but did not publish draft prior to pre-IETF deadline; team will publish initial draft after IETF blackout. Focus is currently on DHCPv4, but results may be applicable to DHCPv6 as well. Vipul Gupta has agreed to re-publish earlier draft on certificate-based DHCP authentication. Ted Lemon and Michael Richardson have published a draft using SIG(0) keys (see below). 'Securing DHCP with DNSSEC bourne public keys' - Ted Lemon ---------------------------------------------------------- This draft was published just before the IETF deadline and is incomplete. The fundamental idea in this draft is to perform DHCP authentication using DNS SIG(0) keys. The WG accepted the draft as WG work item. Authentication of relay agent options - John Schnizlein ------------------------------------------------------- Schnizlein volunteered at previous IETF to conduct comparison of two proposals for securing communication between a relay agent and server (draft-ietf-dhc-auth-suboption-01.txt, Stapp and Lemon; draft-droms-dhcp-relay-agent-ipsec-00.txt, Droms). His conclusion is that the proposals are each applicable in different situations. Thomas Narten questioned whether the WG should advance two mechanisms that address the same problem. The authors of the two drafts and Schnizlein said the two proposals may be appropriate in different environments, if IPsec is already available on all the participating components, the IPsec-based method may be usable with no additional configuration or software updates; the authentication has better scalability (key management) properties when IPsec is not already deployed. Narten suggested we could flip a coin to choose between the two proposals. Droms observed that, while there is some overlap between the applicability of the two proposals, there are significant cases in which only one of the two is appropriate. The WG will continue to work on both proposals. VPN-ID option and sub-option - Kim Kinnear ------------------------------------------- Narten asked about the requirements for these options - what problem spaces do they apply to? What are the situations in which the server sends the option to the client/relay agent and what are the situations in which the client/relay agent sends the option to the server? Erik Nordmark asked about security considerations. John Schnizlein suggested the use of "VPN" in the name might be confusing - this option is intended to pass a VPN identifier as additional information about a client, rather than use a VPN in any kind of security. These two drafts are ready for WG last call after a name change and addition of an example case. DHCP server MIB - Barr Hibbs ---------------------------------- This draft is ready for WG last call; the MIB doctors who reviewed the draft will be asked to comment during WG last call. Option code recovery - Ralph Droms ------------------------------------------ This draft will be revised to edit out option codes related to PXE standard and to add more words about the plan for the use of draft; the document will then be ready for WG last call. Option code extensions - Bernie Volz -------------------------------------------- This document resurrects an old proposal from Droms about using option codes 126 and 127 for options that would extend the DHCP option code space with 16-bit option codes. Volz proposes redefining option codes in the range 128-223 as DHCP option codes (managed by IANA), leaving option codes 224-254 as site-specific options codes. The WG accepted this document as a WG work item. Review of DHCP RFCs - Barr Hibbs draft-ietf-dhc-implementation-00.txt ------------------------------------ Hibbs is collecting references to text in the DHCP RFCs that is confusing, contradictory, incomplete, conflicted with other RFCs, difficult to implement, or could only be resolved by consensus at connectathons. The objective is to document these issues and suggest clarifications and corrections where necessary. The final document will be used in moving DHCP to full Standard. Rob Stevens is co-editor; the work was started three years ago by Mike Carney. Hibbs asked for more input. Failover protocol - Kinnear draft-ietf-dhc-failover-12.txt ------------------------------ Kinnear reported on changes since last revision and discussion. There was a meeting of failover authors and implementors in Atlanta, IETF 55: Kim Kinnear, Scanner Luce, Bernie Volz, Mark Stapp. Notes from that meeting are available at http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01902.html. Narten suggested publishing as Experimental. There are at least 6 implementations and at least two implementors reported customer interest in failover that will interoperate between DHCP servers from different vendors. One vendor (Lucent) noted that there has never been a request for their implementation. Droms asked if Experimental could be a step towards Standards track. Narten responded that SRV started as Experimental. Kinnear said he had no problem with Experimental; the important issue is to get a stake in the ground for implementors to work toward. WG responded that Proposed Standard is appropriate. Draft is now ready for WG last call. Lease query protocol - Kim Kinnear draft-ietf-dhc-leasequery-05.txt ---------------------------------- Kinnear described changes to draft and noted that there have been questions about the functions provided by the most recent document relative to the problem statement in the introduction. Narten expressed concern about feature creep; that is, using this mechanism to supply information to a network element that wouldn't be available to the network element through DHCP messages. Kinnear will revise draft to provide information retrieval capability identical to what could be obtained through reading DHCP messages. Document will then be ready for WG last call. DHCPv6 status - Ralph Droms draft-ietf-dhc-dhcpv6-28.txt draft-ietf-dhc-dhcpv6-interop-01.txt ------------------------------------ The base protocol specification has been accepted as Proposed Standard. Several options have passed WG last call and are ready to be forwarded to the IESG. Two rounds of interoperability testing have been conducted (TAHI and Connectathon), resulting in identification of several minor editorial and clarification issues. These issues have been published in draft-ietf-dhc-dhcpv6-interop-01.txt and will be announced to IETF. The changes documented with the issues in that draft will be made before publication of the RFC. IPv4 Link Local addressing issue from zeroconf WG - Lemon --------------------------------------------------------- Ted explained that there is a dependency between IPv4LL and DHCP: the current specification for IPv4LL restricts an interface to be configured with either a routable IPv4 address or an IPv4LL address. However, transition from DHCP-assigned address to an IPv4LL address will require a change to RFC2131, to cause a DHCP client to drop its routable address in favor of an IPv4LL address when INIT-REBOOT fails. Ted will publish a summary of the issue to the DHC WG mailing list. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 10 15:00:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01093; Thu, 10 Apr 2003 15:00:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AJ61803980; Thu, 10 Apr 2003 15:06:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AJ3w803886 for ; Thu, 10 Apr 2003 15:03:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00907 for ; Thu, 10 Apr 2003 14:57:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193gys-0003Z5-00 for dhcwg@ietf.org; Thu, 10 Apr 2003 14:41:02 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 193gyr-0003Z2-00 for dhcwg@ietf.org; Thu, 10 Apr 2003 14:41:01 -0400 Received: from nominum.com (az-ben-pm3-2-36.ppp.theriver.com [206.25.50.36]) by toccata.fugue.com (Postfix) with ESMTP id 861991B2003; Thu, 10 Apr 2003 13:04:30 -0500 (CDT) Date: Thu, 10 Apr 2003 14:00:09 -0500 Subject: Re: [dhcwg] DHCP question Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: DHCP - IETF To: "Dean, David A" From: Ted Lemon In-Reply-To: <3010F4D7BBD5F64C9C2D17B9D17BB377011A5013@USTR-EXCH4.na.uis.unisys.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just do two seperate dhcp client state machines that each send different DHCP client identifiers. A conforming DHCP server will treat them as separate devices and assign each one a separate address. You may run into trouble if you try to deploy your DHCP client in an environment where only one IP address is available for it, though (e.g., in a cable modem or DSL environment). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 11 11:11:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16784; Fri, 11 Apr 2003 11:11:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BFHX801913; Fri, 11 Apr 2003 11:17:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BFE4801757 for ; Fri, 11 Apr 2003 11:14:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16683 for ; Fri, 11 Apr 2003 11:07:22 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193zrW-00035G-00 for dhcwg@ietf.org; Fri, 11 Apr 2003 10:50:42 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 193zrV-000357-00 for dhcwg@ietf.org; Fri, 11 Apr 2003 10:50:42 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3BF9OB0015299 for ; Fri, 11 Apr 2003 11:09:25 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-192.cisco.com [161.44.149.192]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA28480 for ; Fri, 11 Apr 2003 11:09:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20030411110825.059382d8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Apr 2003 11:09:24 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] WG last call on Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB" . The last call will conclude on Friday, May 9. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-server-mib-08.txt defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of Dynamic Host Configuration Protocol for IPv4 (DHCPv4) and Bootstrap Protocol (BOOTP) servers. This document is being considered for Proposed Standard, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-08.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 11 11:19:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17054; Fri, 11 Apr 2003 11:19:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BFPw802268; Fri, 11 Apr 2003 11:25:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BFNH802163 for ; Fri, 11 Apr 2003 11:23:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16945 for ; Fri, 11 Apr 2003 11:16:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 19400R-00038k-00 for dhcwg@ietf.org; Fri, 11 Apr 2003 10:59:55 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19400Q-00038F-00 for dhcwg@ietf.org; Fri, 11 Apr 2003 10:59:54 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3BFIbB0018184 for ; Fri, 11 Apr 2003 11:18:37 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-192.cisco.com [161.44.149.192]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA29349 for ; Fri, 11 Apr 2003 11:18:37 -0400 (EDT) Message-Id: <4.3.2.7.2.20030411111738.042c3698@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Apr 2003 11:18:38 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-interop-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "Results from Interoperability Tests of DHCPv6 Implementations" . The last call will conclude on Friday, April 25. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-dhcpv6-interop-01.txt provides a published record of issues discovered through interoperability testing of independent implementations of DHCPv6 , for review and discussion by the appropriate IETF working groups. This document is being considered for Informational status, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-interop-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 11 11:25:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17258; Fri, 11 Apr 2003 11:25:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BFW0802616; Fri, 11 Apr 2003 11:32:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BFT7802449 for ; Fri, 11 Apr 2003 11:29:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17137 for ; Fri, 11 Apr 2003 11:22:24 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194064-0003B6-00 for dhcwg@ietf.org; Fri, 11 Apr 2003 11:05:44 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 194064-0003Al-00 for dhcwg@ietf.org; Fri, 11 Apr 2003 11:05:44 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3BFOQRP027444 for ; Fri, 11 Apr 2003 11:24:27 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-192.cisco.com [161.44.149.192]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA29779 for ; Fri, 11 Apr 2003 11:24:26 -0400 (EDT) Message-Id: <4.3.2.7.2.20030411112340.05517a90@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Apr 2003 11:24:27 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "DHCP Failover Protocol" . The last call will conclude on Friday, May 9. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-failover-12.txt defines a protocol to provide synchronization between two DHCP servers. The DHCP specification [RFC 2131] allows for multiple servers to be operating on a single network. For a deployment with multiple servers to work reliably, cooperating primary and secondary servers must be synchronized to maintain a consistent database of the lease information. This document is being considered for Proposed Standard, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-12.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 11 11:32:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17451; Fri, 11 Apr 2003 11:32:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BFd1803774; Fri, 11 Apr 2003 11:39:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BFaK802831 for ; Fri, 11 Apr 2003 11:36:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17346 for ; Fri, 11 Apr 2003 11:29:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1940D3-0003DU-00 for dhcwg@ietf.org; Fri, 11 Apr 2003 11:12:57 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 1940D3-0003DF-00 for dhcwg@ietf.org; Fri, 11 Apr 2003 11:12:57 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3BFVeB0022347 for ; Fri, 11 Apr 2003 11:31:40 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-192.cisco.com [161.44.149.192]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA00366 for ; Fri, 11 Apr 2003 11:31:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Apr 2003 11:31:33 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "A Guide to Implementing Stateless DHCPv6 Service" . The last call will conclude on Friday, April 25. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. One review of this document has been published, http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01990.html, and will be considered as part of the WG response to this last call. draft-ietf-dhc-dhcpv6-stateless-00.txt is a guide to the protocol messages and options that must be implemented to provide stateless DHCPv6 service. Stateless DHCPv6 service is used by nodes that have obtained IPv6 addresses through some other mechanism to obtain configuration information such as the addresses of DNS recursive name servers that does not require the maintenance of any dynamic state for individual clients. This document is being considered for Proposed Standard, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Apr 13 09:44:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28726; Sun, 13 Apr 2003 09:44:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DDpJ825485; Sun, 13 Apr 2003 09:51:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D44h811918 for ; Sun, 13 Apr 2003 00:04:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10809 for ; Sat, 12 Apr 2003 23:57:14 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194Yej-0003du-00 for dhcwg@ietf.org; Sat, 12 Apr 2003 23:59:49 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 194Yei-0003dr-00 for dhcwg@ietf.org; Sat, 12 Apr 2003 23:59:48 -0400 Received: from localhost (unknown [3ffe:501:4819:2000:200:39ff:fea7:b6e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 52C9D15210; Sun, 13 Apr 2003 13:00:42 +0900 (JST) Date: Sun, 13 Apr 2003 12:59:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-interop-01.txt In-Reply-To: <4.3.2.7.2.20030411111738.042c3698@funnel.cisco.com> References: <4.3.2.7.2.20030411111738.042c3698@funnel.cisco.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 11 Apr 2003 11:18:38 -0400, >>>>> Ralph Droms said: > This message announces a WG last call on "Results from > Interoperability Tests of DHCPv6 Implementations" > . The last call will conclude > on Friday, April 25. > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. I support the document. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 14 07:42:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01243; Mon, 14 Apr 2003 07:42:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EBnU814266; Mon, 14 Apr 2003 07:49:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EBkW814201 for ; Mon, 14 Apr 2003 07:46:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01162 for ; Mon, 14 Apr 2003 07:38:24 -0400 (EDT) From: juha.wiljakka@nokia.com Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1952KY-0001Rt-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 07:40:58 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1952KX-0001Rp-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 07:40:57 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3EBf1H11685 for ; Mon, 14 Apr 2003 14:41:01 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Apr 2003 14:41:01 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 14 Apr 2003 14:41:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] Stateless DHCPv6 service Date: Mon, 14 Apr 2003 14:41:00 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC3890@esebe005.ntc.nokia.com> Thread-Topic: [dhcwg] Stateless DHCPv6 service Thread-Index: AcL8RVIAf7hRT9R/SUGAzjXvrJ545gGNEbUw To: Cc: X-OriginalArrivalTime: 14 Apr 2003 11:41:01.0336 (UTC) FILETIME=[B93A0980:01C3027A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3EBkX814202 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, Ralph! This document looks good, I personally support starting wglc for it. By the way, are you going to mention other options than DNS and Time Configuration Options? I think this would also be useful: http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-01.txt Best Regards, -Juha W.- -----Original Message----- From: ext Ralph Droms [mailto:rdroms@cisco.com] Sent: 06 April, 2003 16:07 To: dhcwg@ietf.org Subject: [dhcwg] Stateless DHCPv6 service Now that the DHCPv6 base specification is at PS, and the DNS and time configuration option specs have passed WG last call, I have published "A Guide to Implementing Stateless DHCPv6 Service" as a dhc WG document, draft-ietf-dhc-dhcpv6-stateless-00.txt. This revision of the document has been reviewed by Pekka Savola and Christian Huitema, and includes changes based on their input. Based on the interest in this specification, I would like to progress it quickly. Unless there are objections, I will start a WG last call for the specification in a week or so. - Ralph _______________________________________________ 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 dhcwg-admin@ietf.org Mon Apr 14 08:22:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02043; Mon, 14 Apr 2003 08:22:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ECU6816512; Mon, 14 Apr 2003 08:30:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ECR2816403 for ; Mon, 14 Apr 2003 08:27:02 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01920; Mon, 14 Apr 2003 08:18:55 -0400 (EDT) Message-Id: <200304141218.IAA01920@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: Mon, 14 Apr 2003 08:18:54 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Unused DHCP Option Codes Author(s) : R. Droms Filename : draft-ietf-dhc-unused-optioncodes-01.txt Pages : 9 Date : 2003-4-11 Prior to the publication of RFC2939 (which was updated by RFC2489), several option codes were assigned to proposed DHCP options that were subsequently never used. This document lists those unused option codes and will be used to confirm that these option codes can be reused for other DHCP options in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-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-unused-optioncodes-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-unused-optioncodes-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: <2003-4-11144202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-unused-optioncodes-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-unused-optioncodes-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-11144202.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 14 08:57:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03566; Mon, 14 Apr 2003 08:57:14 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ED4X818789; Mon, 14 Apr 2003 09:04:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ED19818711 for ; Mon, 14 Apr 2003 09:01:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03465 for ; Mon, 14 Apr 2003 08:53:01 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1953Uj-0001vS-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 08:55:33 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 1953Ui-0001u7-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 08:55:32 -0400 Received: from jschnizl-w2k.cisco.com (rtp-vpn2-1120.cisco.com [10.82.244.96]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3ECt5B1027586 for ; Mon, 14 Apr 2003 08:55:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20030414084754.01f627b0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Apr 2003 08:55:04 -0400 To: dhcwg@ietf.org From: John Schnizlein In-Reply-To: <200304141218.IAA01920@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: draft-ietf-dhc-unused-optioncodes-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 08:18 AM 4/14/2003, Internet-Drafts@ietf.org wrote: > Title : Unused DHCP Option Codes > Author(s) : R. Droms > Filename : draft-ietf-dhc-unused-optioncodes-01.txt I would like to see some mention in item 17 that the extension options, 126 and 127 are under consideration by the WG. This note might reduce eventual confusion when/if these options are specified in an RFC based on draft-volz-dhc-extended-optioncodes-00.txt. If the WG decides not to progress the extended-optioncodes, it would be easy to catch the reference and deleted it at the last editorial review of the RFC based on Unused Option Codes. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 14 11:28:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09246; Mon, 14 Apr 2003 11:28:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFZb830274; Mon, 14 Apr 2003 11:35:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E1LD829605 for ; Sun, 13 Apr 2003 21:21:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09666 for ; Sun, 13 Apr 2003 21:13:19 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194sZb-0006pF-00 for dhcwg@ietf.org; Sun, 13 Apr 2003 21:15:51 -0400 Received: from aste-genev-bois-107-1-4-247.abo.wanadoo.fr ([80.15.112.247] helo=Mail.IPDirections.Net) by ietf-mx with esmtp (Exim 4.12) id 194sZb-0006pC-00 for dhcwg@ietf.org; Sun, 13 Apr 2003 21:15:51 -0400 Received: from portable ([::ffff:195.154.67.125]) (AUTH: LOGIN gb@IPDirections.Net) by Mail.IPDirections.Net with esmtp; Mon, 14 Apr 2003 03:15:54 +0200 From: "Gilles, Philippe Bernard" To: rdroms@cisco.com, Erik.Nordmark@sun.com, Erik.Nordmark@sun.com Cc: "Prakash Jayaraman" , "Erik Nordmark" , "Shankar Agarwal" , rbhibbs@pacbell.net, "Dhcwg" Subject: RE: [dhcwg] DHCP interconnected to RADIUS for AAA Date: Mon, 14 Apr 2003 03:15:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3E1LD829606 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, We have encoutered the same issues and developped a DHCP Relay module for FreeRadius (0.7). # This module is not use for authentication. It is called if # a valid authentication has been done and a check-item of # type Post-Auth is found and as a value of DHCP. # In this case, a DHCP server is called with a ClientID, and # optionnaly (if defined) RelayAgent CircuitID and RemoteID. # On response of the DHCP server, Framed-IP-Address (or # Tunnel-Client-Endpoint and Tunnel-Server-Endpoint if a # Tunnel-Type is found in the request items) are added to the # reply items. # if the DHCP server gives DNS and WINS options, they are added # as MS-Primary-DNS-Server, MS-Secondary-DNS-server, # MS-primary-NBNS-Server and MS-Secondary-NBNS-Server. # DHCP has to be include in authenticate modules group and # optionnaly in accounting modules group for releasing the # DHCP leases. If you dont use accounting, be sure to leave # ping enabled if you are interrested in, I could mail you the patch. One interest in Wireless/multi-tenants (VLAN) environments, is that you could mix old radius users (not 802.1X ready) and new 802.1X ones and share the sames DHCP servers. Regards, Gilles Bernard _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 14 11:30:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09296; Mon, 14 Apr 2003 11:30:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFbe831073; Mon, 14 Apr 2003 11:37:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFGg829210 for ; Mon, 14 Apr 2003 11:16:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08621 for ; Mon, 14 Apr 2003 11:08:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1955br-0002qa-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 11:11:03 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1955bq-0002qX-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 11:11:02 -0400 Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4E9A415210; Tue, 15 Apr 2003 00:12:03 +0900 (JST) Date: Tue, 15 Apr 2003 00:10:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt In-Reply-To: <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> References: <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 63 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 11 Apr 2003 11:31:33 -0400, >>>>> Ralph Droms said: > This message announces a WG last call on "A Guide to Implementing > Stateless DHCPv6 Service" . > The last call will conclude on Friday, April 25. > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. One review of this document > has been published, > http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01990.html, > and will be considered as part of the WG response to this last call. I basically support the document, but I have several general comments. They are not directly related to the content of the draft, but may require a revise of it. 1. address selection of Information-request/Reply exchanges According to the DHCPv6 base spec, the client should send Information Request messages to the All_DHCP_Relay_Agents_and_Servers multicast address (FF02::1:2). However, doesn't it make much sense to allow the client to send the requests to the All_DHCP_Servers multicast address FF05::1:3? Since the stateless usage assumes the client has obtained its IPv6 addresses through some other mechanism, I don't see a reason that the client cannot do so. If we allow this, the client can access an off-link server without relying on a relay agent, which would help the deployment. 2. how to invalidate stale configuration parameters The stateless usage does not have the notion of Renew or Rebind. So, how the client can purge configuration parameters (e.g. DNS addresses) when they become invalidated? I guess we need a some kind of "timeout" parameter, which suggests to the client that it refresh the parameters in a certain period. 3. how to restart the stateless procedure It would be useful if we had a guideline where the client should restart the Information-request/Reply exchanges, particularly when the client is a nomadic host moving link to link. Section 18.1.2 of the base specification can be a good example of this. 4. interaction/consistency with RFC 246[12] How the stateless usage is related to the "Other stateful configuration" of router advertisements defined in RFC 2461 and 2462? Is the client (host) expected to start the stateless DHCPv6 when it receives a router advertisement with the "Other stateful configuration" flag being set? If so, how can we interpret the "inconsistency" between the "stateless" DHCPv6 usage and the "stateful" router advertisement flag? Perhaps this is just a matter of wording. But, if RFC 2461 really intended a "stateful" protocol (i.e., where a server maintains lease state for the other configuration parameters), we may need to consider the gap as a fundamental architecture issue. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 14 11:32:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09386; Mon, 14 Apr 2003 11:32:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFdS831245; Mon, 14 Apr 2003 11:39:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EFSA829851 for ; Mon, 14 Apr 2003 11:28:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09073 for ; Mon, 14 Apr 2003 11:19:58 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1955mx-0002ug-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 11:22:31 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1955mw-0002ud-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 11:22:31 -0400 Received: from localhost (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id EF5EE15210 for ; Tue, 15 Apr 2003 00:23:34 +0900 (JST) Date: Tue, 15 Apr 2003 00:22:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 17 Subject: [dhcwg] what are relay agent options? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , draft-ietf-dhc-dhcpv6-28.txt refers to a terminology "relay agent options" several times. For example, Section 18.1 contains the following sentence: Requiring the client to relay all DHCP messages through a relay agent enables the inclusion of relay agent options in all messages sent by the client. But, what are really they? I cannot find a clear definition of "relay agent options" from the draft. Could anyone clarify this? Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 14 12:26:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10943; Mon, 14 Apr 2003 12:26:38 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGYE802676; Mon, 14 Apr 2003 12:34:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EGVS802571 for ; Mon, 14 Apr 2003 12:31:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10799 for ; Mon, 14 Apr 2003 12:23:14 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1956mB-0003HJ-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 12:25:47 -0400 Received: from imr1.ericy.com ([208.237.135.240]) by ietf-mx with esmtp (Exim 4.12) id 1956mB-0003HG-00 for dhcwg@ietf.org; Mon, 14 Apr 2003 12:25:47 -0400 Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.12.9/8.12.9) with ESMTP id h3EGPpqj016391; Mon, 14 Apr 2003 11:25:52 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h3EGPptK015494; Mon, 14 Apr 2003 11:25:51 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 14 Apr 2003 11:25:52 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'JINMEI Tatuya / ????'" , dhcwg@ietf.org Subject: RE: [dhcwg] what are relay agent options? Date: Mon, 14 Apr 2003 11:23:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C302A2.3E5B28E8" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C302A2.3E5B28E8 Content-Type: text/plain; charset="ISO-2022-JP" There are no specific options yet that convey relay agent options for DHCPv6. However, this is expected to be defined at some point, such as there are relay agent options for DHCPv4. See RFC 3046 as the basic relay agent option. There are several drafts as well that expand this: Link Selection sub-option for the Relay Agent Information Option for DHCPv4 (16918 bytes) VPN Identifier sub-option for the Relay Agent Information Option (15940 bytes) The Authentication Suboption for the DHCP Relay Agent Option (32547 bytes) DHCP Subscriber ID Suboption for the DHCP Relay Agent Option (10570 bytes) - Bernie Volz -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Monday, April 14, 2003 11:22 AM To: dhcwg@ietf.org Subject: [dhcwg] what are relay agent options? draft-ietf-dhc-dhcpv6-28.txt refers to a terminology "relay agent options" several times. For example, Section 18.1 contains the following sentence: Requiring the client to relay all DHCP messages through a relay agent enables the inclusion of relay agent options in all messages sent by the client. But, what are really they? I cannot find a clear definition of "relay agent options" from the draft. Could anyone clarify this? Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C302A2.3E5B28E8 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] what are relay agent options?

There are no specific options yet that convey relay = agent options for DHCPv6.

However, this is expected to be defined at some = point, such as there are relay
agent options for DHCPv4. See RFC 3046 as the basic = relay agent option. There
are several drafts as well that expand this:

Link Selection sub-option for the Relay Agent = Information Option for DHCPv4 (16918 bytes)
VPN Identifier sub-option for the Relay Agent = Information Option (15940 bytes)
The Authentication Suboption for the DHCP Relay = Agent Option (32547 bytes)
DHCP Subscriber ID Suboption for the DHCP Relay = Agent Option (10570 bytes)

- Bernie Volz


-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshi= ba.co.jp]
Sent: Monday, April 14, 2003 11:22 AM
To: dhcwg@ietf.org
Subject: [dhcwg] what are relay agent = options?


draft-ietf-dhc-dhcpv6-28.txt refers to a terminology = "relay agent
options" several times.  For example, = Section 18.1 contains the
following sentence:

      Requiring the client = to relay all DHCP
      messages through a = relay agent enables the inclusion of
      relay agent options = in all messages sent by the client.

But, what are really they?  I cannot find a = clear definition of "relay
agent options" from the draft.

Could anyone clarify this?  Thanks,

        =         =         =         =         JINMEI, = Tatuya
        =         =         =         =         Communication = Platform Lab.
        =         =         =         =         Corporate = R&D Center, Toshiba Corp.
        =         =         =         =         jinmei@isl.rdc.toshiba.co.jp
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C302A2.3E5B28E8-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 15 01:55:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04553; Tue, 15 Apr 2003 01:55:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F62x826247; Tue, 15 Apr 2003 02:03:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F5x2825483 for ; Tue, 15 Apr 2003 01:59:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04474 for ; Tue, 15 Apr 2003 01:50:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195JNQ-00001W-00 for dhcwg@ietf.org; Tue, 15 Apr 2003 01:53:05 -0400 Received: from guri.nttv6.jp ([210.254.137.98]) by ietf-mx with esmtp (Exim 4.12) id 195JNQ-00001L-00 for dhcwg@ietf.org; Tue, 15 Apr 2003 01:53:04 -0400 Received: from nirvana.nttv6.jp (nirvana.nttv6.jp [2001:218:1f01:1::2687]) by guri.nttv6.jp (Postfix) with ESMTP id 95861B162F; Tue, 15 Apr 2003 14:52:39 +0900 (JST) Received: from localhost (localhost [::1]) by nirvana.nttv6.jp (Postfix) with ESMTP id AA31A12612C; Tue, 15 Apr 2003 14:52:38 +0900 (JST) Date: Tue, 15 Apr 2003 14:52:38 +0900 (JST) Message-Id: <20030415.145238.39182831.yasuhiro@nttv6.jp> To: jinmei@isl.rdc.toshiba.co.jp Cc: rdroms@cisco.com, dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt From: SHIRASAKI Yasuhiro In-Reply-To: References: <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > 2. how to invalidate stale configuration parameters > > The stateless usage does not have the notion of Renew or Rebind. So, > how the client can purge configuration parameters (e.g. DNS addresses) > when they become invalidated? I guess we need a some kind of > "timeout" parameter, which suggests to the client that it refresh the > parameters in a certain period. or the server "advertises" when the parameters change? -- SHIRASAKI Yasuhiro @ NTT Communications _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 15 07:17:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22156; Tue, 15 Apr 2003 07:17:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBP4826923; Tue, 15 Apr 2003 07:25:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FBMI826814 for ; Tue, 15 Apr 2003 07:22:18 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21982; Tue, 15 Apr 2003 07:13:41 -0400 (EDT) Message-Id: <200304151113.HAA21982@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: Tue, 15 Apr 2003 07:13:41 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Unused DHCP Option Codes Author(s) : R. Droms Filename : draft-ietf-dhc-unused-optioncodes-01.txt Pages : 9 Date : 2003-4-11 Prior to the publication of RFC2939 (which was updated by RFC2489), several option codes were assigned to proposed DHCP options that were subsequently never used. This document lists those unused option codes and will be used to confirm that these option codes can be reused for other DHCP options in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-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-unused-optioncodes-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-unused-optioncodes-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: <2003-4-11144202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-unused-optioncodes-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-unused-optioncodes-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-11144202.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 15 08:26:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25339; Tue, 15 Apr 2003 08:26:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FCWG831544; Tue, 15 Apr 2003 08:32:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FCTW831442 for ; Tue, 15 Apr 2003 08:29:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25200 for ; Tue, 15 Apr 2003 08:20:54 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195PTC-0002Hw-00 for dhcwg@ietf.org; Tue, 15 Apr 2003 08:23:26 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 195PTB-0002Hp-00 for dhcwg@ietf.org; Tue, 15 Apr 2003 08:23:25 -0400 Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h3FCMotP003143; Tue, 15 Apr 2003 07:22:50 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h3FCMoKG026532; Tue, 15 Apr 2003 07:22:50 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 15 Apr 2003 07:22:51 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'SHIRASAKI Yasuhiro'" , jinmei@isl.rdc.toshiba.co.jp Cc: rdroms@cisco.com, dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-stateless-00.tx t Date: Tue, 15 Apr 2003 07:20:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30349.758E1E90" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C30349.758E1E90 Content-Type: text/plain; charset="iso-8859-1" There are three mechanisms available: a. Whenever the client would normally determine that its stateless addresses are suspect, after confirming them or obtaining new addresses, it can use Information-Request to obtain new parameters. Note that a client may also use triggers such as existing address lifetimes expiring (if a prefix is has expired, it likely means some changes to the networks configuration and hence doing an Information-Request to obtain updated parameters may be in order). b. The server can send a Reconfigure provided the client has communicated it is able/willing to support this in the Information-Request. c. The client is free to do Information-Requests at times of its choosing (there is no prohibition against doing this). Of course, the client should not do this too frequently. If someone feels these mechanisms are insufficient, they could always write a draft that specifies an "Information Lifetime" or "Information Renewal Time" at which point the client could refresh the information. This option could specify T1 and T2 times - at T1 the client renews by including the server identifier option of the server that gave it the configuration parameters, at T2 it removes this option and any server may respond to the Information-Request. - Bernie -----Original Message----- From: SHIRASAKI Yasuhiro [mailto:yasuhiro@nttv6.jp] Sent: Tuesday, April 15, 2003 1:53 AM To: jinmei@isl.rdc.toshiba.co.jp Cc: rdroms@cisco.com; dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt > 2. how to invalidate stale configuration parameters > > The stateless usage does not have the notion of Renew or Rebind. So, > how the client can purge configuration parameters (e.g. DNS addresses) > when they become invalidated? I guess we need a some kind of > "timeout" parameter, which suggests to the client that it refresh the > parameters in a certain period. or the server "advertises" when the parameters change? -- SHIRASAKI Yasuhiro @ NTT Communications _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C30349.758E1E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] WG last call on = draft-ietf-dhc-dhcpv6-stateless-00.txt

There are three mechanisms available:
a. Whenever the client would normally determine that = its stateless addresses
are suspect, after confirming them or obtaining new = addresses, it can use
Information-Request to obtain new parameters. Note = that a client may also
use triggers such as existing address lifetimes = expiring (if a prefix is
has expired, it likely means some changes to the = networks configuration and
hence doing an Information-Request to obtain updated = parameters may be in
order).
b. The server can send a Reconfigure provided the = client has communicated it
is able/willing to support this in the = Information-Request.
c. The client is free to do Information-Requests at = times of its choosing
(there is no prohibition against doing this). Of = course, the client
should not do this too frequently.

If someone feels these mechanisms are insufficient, = they could always write
a draft that specifies an "Information = Lifetime" or "Information Renewal Time"
at which point the client could refresh the = information. This option could
specify T1 and T2 times - at T1 the client renews by = including the server
identifier option of the server that gave it the = configuration parameters, at
T2 it removes this option and any server may respond = to the Information-Request.

- Bernie

-----Original Message-----
From: SHIRASAKI Yasuhiro [mailto:yasuhiro@nttv6.jp]
Sent: Tuesday, April 15, 2003 1:53 AM
To: jinmei@isl.rdc.toshiba.co.jp
Cc: rdroms@cisco.com; dhcwg@ietf.org
Subject: Re: [dhcwg] WG last call on
draft-ietf-dhc-dhcpv6-stateless-00.txt


> 2. how to invalidate stale configuration = parameters
>
> The stateless usage does not have the notion of = Renew or Rebind.  So,
> how the client can purge configuration = parameters (e.g. DNS addresses)
> when they become invalidated?  I guess we = need a some kind of
> "timeout" parameter, which suggests = to the client that it refresh the
> parameters in a certain period.

or the server "advertises" when the = parameters change?

--
SHIRASAKI Yasuhiro @ NTT Communications
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C30349.758E1E90-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 16 07:53:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26231; Wed, 16 Apr 2003 07:53:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GC1v812906; Wed, 16 Apr 2003 08:01:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GBwl812758 for ; Wed, 16 Apr 2003 07:58:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26174 for ; Wed, 16 Apr 2003 07:49:41 -0400 (EDT) From: juha.wiljakka@nokia.com Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195lSV-0000Yh-00 for dhcwg@ietf.org; Wed, 16 Apr 2003 07:52:11 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 195lSU-0000Ye-00 for dhcwg@ietf.org; Wed, 16 Apr 2003 07:52:10 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3GBqI727628 for ; Wed, 16 Apr 2003 14:52:18 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Apr 2003 14:52:03 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 16 Apr 2003 14:52:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt Date: Wed, 16 Apr 2003 14:52:06 +0300 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834FDC389A@esebe005.ntc.nokia.com> Thread-Topic: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt Thread-Index: AcMAR4b811NT+vjZRZuJRKYUWjj+KgDxWa0w To: , X-OriginalArrivalTime: 16 Apr 2003 11:52:06.0737 (UTC) FILETIME=[9AA9AC10:01C3040E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3GBwl812759 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi! (Even though I already sent this message to the list, I repeat it here.) This document looks useful, I recommend forwarding it to the IESG. One comment: Are you going to mention other options than DNS and Time Configuration Options? In my opinion, this option would be useful: http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-01.txt BR, -Juha W.- -----Original Message----- From: ext Ralph Droms [mailto:rdroms@cisco.com] Sent: 11 April, 2003 18:32 To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt This message announces a WG last call on "A Guide to Implementing Stateless DHCPv6 Service" . The last call will conclude on Friday, April 25. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. One review of this document has been published, http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01990.html, and will be considered as part of the WG response to this last call. draft-ietf-dhc-dhcpv6-stateless-00.txt is a guide to the protocol messages and options that must be implemented to provide stateless DHCPv6 service. Stateless DHCPv6 service is used by nodes that have obtained IPv6 addresses through some other mechanism to obtain configuration information such as the addresses of DNS recursive name servers that does not require the maintenance of any dynamic state for individual clients. This document is being considered for Proposed Standard, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-00.txt - Ralph Droms _______________________________________________ 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 dhcwg-admin@ietf.org Wed Apr 16 08:56:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29048; Wed, 16 Apr 2003 08:56:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GD58818085; Wed, 16 Apr 2003 09:05:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GD1p817945 for ; Wed, 16 Apr 2003 09:01:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28747 for ; Wed, 16 Apr 2003 08:52:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195mRU-00014R-00 for dhcwg@ietf.org; Wed, 16 Apr 2003 08:55:12 -0400 Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx with esmtp (Exim 4.12) id 195mRT-00013t-00 for dhcwg@ietf.org; Wed, 16 Apr 2003 08:55:11 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id AC15071A1; Wed, 16 Apr 2003 08:55:16 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 16 Apr 2003 08:55:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt Date: Wed, 16 Apr 2003 08:55:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD27F@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt Thread-Index: AcMAR4b811NT+vjZRZuJRKYUWjj+KgDxWa0wAAKbOIA= From: "Bound, Jim" To: , , X-OriginalArrivalTime: 16 Apr 2003 12:55:15.0953 (UTC) FILETIME=[6D362610:01C30417] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3GD1q817946 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I think we need mechanisms to add other options in general as we do for dhcpv6 in general. Why not use same process? /jim > -----Original Message----- > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Sent: Wednesday, April 16, 2003 7:52 AM > To: rdroms@cisco.com; dhcwg@ietf.org > Subject: RE: [dhcwg] WG last call on > draft-ietf-dhc-dhcpv6-stateless-00.txt > > > > Hi! > > (Even though I already sent this message to the list, I > repeat it here.) > > This document looks useful, I recommend forwarding it to the IESG. > > One comment: Are you going to mention other options than DNS > and Time Configuration Options? In my opinion, this option > would be useful: > http://www.ietf.org/internet-drafts/draft-> ietf-sip-dhcpv6-01.txt > > BR, > -Juha W.- > > -----Original Message----- > From: ext Ralph Droms [mailto:rdroms@cisco.com] > Sent: 11 April, 2003 18:32 > To: dhcwg@ietf.org > Subject: [dhcwg] WG last call on > draft-ietf-dhc-dhcpv6-stateless-00.txt > > > This message announces a WG last call on "A Guide to > Implementing Stateless DHCPv6 Service" > . > The last call will conclude on Friday, April 25. > > Please respond to this WG last call. If you support > acceptance of the document without change, respond with a > simple acknowledgment, so that support for the document can > be assessed. One review of this document has been published, http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01990. html, and will be considered as part of the WG response to this last call. draft-ietf-dhc-dhcpv6-stateless-00.txt is a guide to the protocol messages and options that must be implemented to provide stateless DHCPv6 service. Stateless DHCPv6 service is used by nodes that have obtained IPv6 addresses through some other mechanism to obtain configuration information such as the addresses of DNS recursive name servers that does not require the maintenance of any dynamic state for individual clients. This document is being considered for Proposed Standard, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-00.t xt - Ralph Droms _______________________________________________ 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 dhcwg-admin@ietf.org Thu Apr 17 07:44:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17081; Thu, 17 Apr 2003 07:44:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HBrA827934; Thu, 17 Apr 2003 07:53:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HBaF826235 for ; Thu, 17 Apr 2003 07:36:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15907; Thu, 17 Apr 2003 07:26:40 -0400 (EDT) Message-Id: <200304171126.HAA15907@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: Thu, 17 Apr 2003 07:26:40 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Unused DHCP Option Codes Author(s) : R. Droms Filename : draft-ietf-dhc-unused-optioncodes-02.txt Pages : 9 Date : 2003-4-16 Prior to the publication of RFC2939 (which was updated by RFC2489), several option codes were assigned to proposed DHCP options that were subsequently never used. This document lists those unused option codes and will be used to confirm that these option codes can be reused for other DHCP options in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-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-unused-optioncodes-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-unused-optioncodes-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: <2003-4-16150051.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-unused-optioncodes-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-unused-optioncodes-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16150051.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 22 07:45:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03381; Tue, 22 Apr 2003 07:45:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MBug830651; Tue, 22 Apr 2003 07:56:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MBpF830473 for ; Tue, 22 Apr 2003 07:51:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03130; Tue, 22 Apr 2003 07:39:13 -0400 (EDT) Message-Id: <200304221139.HAA03130@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: Tue, 22 Apr 2003 07:39:12 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-relay-agent-auth-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : The Authentication Suboption for the DHCP Relay Agent Option Author(s) : M. Stapp, T. Lemon, R. Droms Filename : draft-ietf-dhc-relay-agent-auth-00.txt Pages : 16 Date : 2003-4-21 The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP relay agent and a DHCP server. This specification defines two mechanisms for securing the messages exchanged between a relay agent and a server. The first mechanism defines a new authentication suboption for the Relay Agent Information Option that supports source entity authentication and data integrity for relayed DHCP messages. The authentication suboption contains a cryptographic signature in a payload derived from the option used in DHCP Authentication (RFC 3118). The second mechanism uses IPsec (RFC 2041) to protect messages exchanged between relay agents and servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-auth-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-relay-agent-auth-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-relay-agent-auth-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: <2003-4-21143722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-relay-agent-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-relay-agent-auth-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-21143722.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 22 12:45:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15862; Tue, 22 Apr 2003 12:45:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MGv6820816; Tue, 22 Apr 2003 12:57:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MGra820677 for ; Tue, 22 Apr 2003 12:53:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15816 for ; Tue, 22 Apr 2003 12:41:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1980s1-00031C-00 for dhcwg@ietf.org; Tue, 22 Apr 2003 12:43:49 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1980s0-000314-00 for dhcwg@ietf.org; Tue, 22 Apr 2003 12:43:48 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3MGhEuT041744; Tue, 22 Apr 2003 12:43:14 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-244-156.mts.ibm.com [9.65.244.156]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3MGhD98058788; Tue, 22 Apr 2003 10:43:13 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h3MGfMl03743; Tue, 22 Apr 2003 12:41:22 -0400 Message-Id: <200304221641.h3MGfMl03743@cichlid.adsl.duke.edu> To: Paul Duffy cc: dhcwg@ietf.org Date: Tue, 22 Apr 2003 12:41:21 -0400 From: Thomas Narten Subject: [dhcwg] draft-ietf-dhc-pktc-kerb-tckt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've gone ahead and asked for the IETF LC to start for this document. A few small comments: > Code Len TCM > +-----+-----+-----+-----+ > | TBD | 2 | m1 | m2 | > +-----+-----+-----+-----+ It might be better to not have m1/m2, since the text talks about a single 16-bit field rather than two smaller fields. > The length MUST be 2. The TCM field is encoded as an unsigned 16 > bit quantity per network byte-ordering rules. Each bit of the TCM better wording for bit ordering might be: The length MUST be 2. The TCM field is encoded as an unsigned 16 bit quantity in network byte order. Each bit of the TCM > 5. IANA Considerations what about future assignments of bit values? > However, the scenario described above is unlikely to occur. > Within the cable delivery architecture required by the various > CableLabs projects, the DHCP client is connected to a network > through a cable modem and the CMTS (head-end). The CMTS is > explicitly configured with a set of DHCP servers to which DHCP > requests are forwarded. Further, a correctly configured CMTS > will only allow downstream traffic from specific IP > addresses/ranges. Could be more clear. I don't follow the last sentence, for example. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 22 13:37:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17542; Tue, 22 Apr 2003 13:37:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHn7824919; Tue, 22 Apr 2003 13:49:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MHfV824518 for ; Tue, 22 Apr 2003 13:41:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17305 for ; Tue, 22 Apr 2003 13:29:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1981cN-0003Mr-00 for dhcwg@ietf.org; Tue, 22 Apr 2003 13:31:43 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1981cN-0003MO-00 for dhcwg@ietf.org; Tue, 22 Apr 2003 13:31:43 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3MHVXuT067736; Tue, 22 Apr 2003 13:31:33 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-244-156.mts.ibm.com [9.65.244.156]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3MHVT98070020; Tue, 22 Apr 2003 11:31:29 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h3MHTb304661; Tue, 22 Apr 2003 13:29:38 -0400 Message-Id: <200304221729.h3MHTb304661@cichlid.adsl.duke.edu> To: cmonia@nishansystems.com, jtseng@nishansystems.com, kgibbons@nishansystems.com cc: dhcwg@ietf.org Date: Tue, 22 Apr 2003 13:29:37 -0400 From: Thomas Narten Subject: [dhcwg] AD review of draft-ietf-dhc-isnsoption-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , General issues: I'd like to see a justification for the vendor specific fields. I'd like to understand how these can be safely used without leading to interoperability issues. Besides, there are other ways in DHC to do vendor-specific things. Can we just remove them from this option/document? The security considerations section is rather weak. General note: this document is inconsitent about bit ordering. Some picture show bits numbered left-to-right, others right-to-left. Please pick one and be consistent. needs an IANA considerations section. I assume a revision of the document would be in order before starting the IETF LC. Specific comments follow. > DHCP Options for Internet Storage Name Service Would be good for the title to note that this is for DHCP for IPv4. E.g.: The IPv4 DHCP Option for Internet Storage Name Service Abstract doesn't satisfy ID nits; e.g., has unexpanded acronyms. "iSNS" used before being defined. ditto for iSCSI, iFCP, etc. The Dynamic Host Configuration Protocol for Ipv4 provides a s/Ipv4/IPv4/ > Existing DHCP option numbers are not plausible due to the following > reasons: suggested reword: Existing DHCP options cannot be used to find iSNS servers for the following reasons: > Length: the number of bytes that follow the Length field. The > minimum value for the Length field is 6 in order to account > for the iSNS Functions, Discovery Domain Access, and > Administrative Flags fields. From the picture, it seems like the minimum length is more than 6. Are some of the fields optional? > certificates for the use of iSCSI and iFCP devices. The format of > the iSNS Role bit field is shown in Figure 2: > > 1 2 3 > 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Vendor-Specific |RESERVED |S|A|E| > +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Figure 2 -- iSNS Functions I don't see how a vendor-specific portion of this option facilitates interoperability. Remove? Also, caling it the "iSNS Role" field is confusing, since that is not used in the previous figure. SHouldn't this be the "iSNS Functions" field? > Bit field Significance > --------- ------------ > 31 Function Fields Enabled > 30 DD-Based Authorization > 29 Security policy distribution > 28 - 24 Reserved > 23 - 16 Vendor-specific You need a transistion sentence saying what field is being talked about. Presumably, this is "iSNS Server Security Bitmap"? > Enabled: This bit specifies the validity of the Spell out "Function Fields Enabled", as that is the name of the field per the picture. > Security: Indicates whether the iSNS client is to spell out field name. > Vendor- These bits are used to indicate the vendor- > Specific: specific capabilities supported by the > indicated iSNS server. Again, this does not promote interoperability. There are other ways in DHC to communicate vendor specific information. General note: this document is inconsitent about bit ordering. Some picture show bits numbered left-to-right, others right-to-left. Please pick one and be consistent. > 3. Security Considerations > > DHCP currently provides no authentication or security mechanisms. > Potential exposures to attack are discussed in section 7 of the DHCP > protocol specification [DHCP]. What about RFC 3118? > iSNS security considerations are discussed in [iSNS] and [SEC-IPS]. > With regard to security considerations specific to the use of this > DHCP option to discover the location of the iSNS server, exposure to > a "man-in-the-middle" attack by an hostile entity modifying or > replacing the original iSNS option message should be considered a > potential security exposure. To prevent an attacker from weakening > the required security and potentially tricking the iSNS client into > connecting into rogue iSNS servers, reliance on local security > policy configuration is an appropriate countermeasure. This says almost nothing. What can happen if there is a man-in-the middle? Really bad things? or just DOS? And what "local security policy configuration" helps mitigate the threats? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 22 14:03:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18811; Tue, 22 Apr 2003 14:03:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MIFE827635; Tue, 22 Apr 2003 14:15:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MI3O826179 for ; Tue, 22 Apr 2003 14:03:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18190; Tue, 22 Apr 2003 13:51:14 -0400 (EDT) Message-Id: <200304221751.NAA18190@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Tue, 22 Apr 2003 13:51:14 -0400 Subject: [dhcwg] Last Call: Security Ticket Control Sub-option for the CableLabs Client Configuration Option to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Dynamic Host Configuration Working Group to consider Security Ticket Control Sub-option for the CableLabs Client Configuration Option as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-6. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-pktc-kerb-tckt-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 23 15:27:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03009; Wed, 23 Apr 2003 15:27:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJdg822465; Wed, 23 Apr 2003 15:39:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJao821497 for ; Wed, 23 Apr 2003 15:36:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02891 for ; Wed, 23 Apr 2003 15:24:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Pt0-0006fK-00 for dhcwg@ietf.org; Wed, 23 Apr 2003 15:26:30 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 198Psz-0006fA-00 for dhcwg@ietf.org; Wed, 23 Apr 2003 15:26:29 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3NJQNlY017165; Wed, 23 Apr 2003 15:26:24 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-106.cisco.com [161.44.150.106]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA09426; Wed, 23 Apr 2003 15:26:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20030423151100.026384e8@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Apr 2003 15:26:20 -0400 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-pktc-kerb-tckt-01.txt Cc: dhcwg@ietf.org In-Reply-To: <200304221641.h3MGfMl03743@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_105628726==_.ALT" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --=====================_105628726==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks Thomas...inline please... At 12:41 PM 4/22/2003 -0400, Thomas Narten wrote: >I've gone ahead and asked for the IETF LC to start for this document. > >A few small comments: > > > Code Len TCM > > +-----+-----+-----+-----+ > > | TBD | 2 | m1 | m2 | > > +-----+-----+-----+-----+ > >It might be better to not have m1/m2, since the text talks about a >single 16-bit field rather than two smaller fields. The format is consistent with the formats presented in RFC 3495 (sections 8.3, 8.4, etc.). I'm not sure what you are driving at. Suggestions? > > > The length MUST be 2. The TCM field is encoded as an unsigned 16 > > bit quantity per network byte-ordering rules. Each bit of the TCM > >better wording for bit ordering might be: > > The length MUST be 2. The TCM field is encoded as an unsigned 16 > bit quantity in network byte order. Each bit of the TCM OK...will make that change in next draft. > > 5. IANA Considerations > >what about future assignments of bit values? Yes, needs to be added. How about... "IANA is requested to maintain a new number space of "CableLabs Client Configuration Option Ticket Control Mask Bit Definitions", located in the BOOTP-DHCP Parameters Registry. The initial bit definitions are described in section 4 of this document. IANA is requested to register future bit mask definitions via an "IETF Consensus" approval policy as described in RFC 2434 [add ref}." > > However, the scenario described above is unlikely to occur. > > Within the cable delivery architecture required by the various > > CableLabs projects, the DHCP client is connected to a network > > through a cable modem and the CMTS (head-end). The CMTS is > > explicitly configured with a set of DHCP servers to which DHCP > > requests are forwarded. Further, a correctly configured CMTS > > will only allow downstream traffic from specific IP > > addresses/ranges. > >Could be more clear. I don't follow the last sentence, for example. Last sentence change to... "Further, the CMTS is explicitly configured to allow downstream traffic only from specific IP addresses/ranges." OK ? P.S. Should I hold the next draft until after IESG LC ? >Thomas >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com --=====================_105628726==_.ALT Content-Type: text/html; charset="us-ascii" Thanks Thomas...inline please...

At 12:41 PM 4/22/2003 -0400, Thomas Narten wrote:
I've gone ahead and asked for the IETF LC to start for this document.

A few small comments:

>        Code   Len      TCM
>       +-----+-----+-----+-----+ 
>       | TBD |  2  | m1  | m2  |
>       +-----+-----+-----+-----+

It might be better to not have m1/m2, since the text talks about a
single 16-bit field rather than two smaller fields.

The format is consistent with the formats presented in RFC 3495 (sections 8.3, 8.4, etc.).  I'm not sure what you are driving at.  Suggestions?

           
>       The length MUST be 2.  The TCM field is encoded as an unsigned 16
>       bit quantity per network byte-ordering rules.  Each bit of the TCM

better wording for bit ordering might be:

      The length MUST be 2.  The TCM field is encoded as an unsigned 16
      bit quantity in network byte order.  Each bit of the TCM

OK...will make that change in next draft.


>    5.   IANA Considerations

what about future assignments of bit values?

Yes, needs to be added.  How about...

"IANA is requested to maintain a new number space of "CableLabs Client Configuration Option Ticket Control Mask Bit Definitions", located in the BOOTP-DHCP Parameters Registry.  The initial bit definitions are described in section 4 of this document.  IANA is requested to register future bit mask definitions via an "IETF Consensus" approval policy as described in RFC 2434 [add ref}."


>       However, the scenario described above is unlikely to occur. 
>       Within the cable delivery architecture required by the various
>       CableLabs projects, the DHCP client is connected to a network
>       through a cable modem and the CMTS (head-end). The CMTS is
>       explicitly configured with a set of DHCP servers to which DHCP
>       requests are forwarded.  Further, a correctly configured CMTS
>       will only allow downstream traffic from specific IP
>       addresses/ranges.
 
Could be more clear. I don't follow the last sentence, for example.

Last sentence change to...

"Further, the CMTS is explicitly configured to allow downstream traffic only from specific IP addresses/ranges."

OK ?

P.S.  Should I hold the next draft until after IESG LC ?


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

--

Paul Duffy
Cisco Systems, Inc.
paduffy@cisco.com

--=====================_105628726==_.ALT-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 23 15:38:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03873; Wed, 23 Apr 2003 15:38:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJou823078; Wed, 23 Apr 2003 15:50:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NJmN822991 for ; Wed, 23 Apr 2003 15:48:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03749 for ; Wed, 23 Apr 2003 15:35:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Q4A-0006rx-00 for dhcwg@ietf.org; Wed, 23 Apr 2003 15:38:02 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 198Q49-0006rp-00 for dhcwg@ietf.org; Wed, 23 Apr 2003 15:38:01 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h3NJb8uT048950; Wed, 23 Apr 2003 15:37:08 -0400 Received: from rotala.raleigh.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h3NJb7nq357576; Wed, 23 Apr 2003 13:37:08 -0600 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h3NJae15014296; Wed, 23 Apr 2003 15:36:40 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.5/Submit) with ESMTP id h3NJaeDN014292; Wed, 23 Apr 2003 15:36:40 -0400 Message-Id: <200304231936.h3NJaeDN014292@rotala.raleigh.ibm.com> To: Paul Duffy cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-pktc-kerb-tckt-01.txt In-Reply-To: Message from paduffy@cisco.com of "Wed, 23 Apr 2003 15:26:20 EDT." <4.3.2.7.2.20030423151100.026384e8@funnel.cisco.com> Date: Wed, 23 Apr 2003 15:36:40 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Paul. > > > Code Len TCM > > > +-----+-----+-----+-----+ > > > | TBD | 2 | m1 | m2 | > > > +-----+-----+-----+-----+ > > > >It might be better to not have m1/m2, since the text talks about a > >single 16-bit field rather than two smaller fields. > The format is consistent with the formats presented in RFC 3495 (sections > 8.3, 8.4, etc.). I guess we need to revise them and republish. :-) > I'm not sure what you are driving at. Suggestions? THis is relatively minor thing, but since the field is 16-byte field, it seems better to show it that way then to divide it up into individual bytes. Just change the picture to something like: Code Len TCM +-----+-----+-----+-----+ | TBD | 2 | TC Mask | +-----+-----+-----+-----+ > > > 5. IANA Considerations > > > >what about future assignments of bit values? > Yes, needs to be added. How about... > "IANA is requested to maintain a new number space of "CableLabs Client > Configuration Option Ticket Control Mask Bit Definitions", located in the > BOOTP-DHCP Parameters Registry. The initial bit definitions are described > in section 4 of this document. IANA is requested to register future bit > mask definitions via an "IETF Consensus" approval policy as described in > RFC 2434 [add ref}." works for me. > > > However, the scenario described above is unlikely to occur. > > > Within the cable delivery architecture required by the various > > > CableLabs projects, the DHCP client is connected to a network > > > through a cable modem and the CMTS (head-end). The CMTS is > > > explicitly configured with a set of DHCP servers to which DHCP > > > requests are forwarded. Further, a correctly configured CMTS > > > will only allow downstream traffic from specific IP > > > addresses/ranges. > > > >Could be more clear. I don't follow the last sentence, for example. > Last sentence change to... > "Further, the CMTS is explicitly configured to allow downstream traffic > only from specific IP addresses/ranges." I don't follow the overall discussion to be honest. When clients are using DHC, they don't have addresses yet. So what addresses are being filtered? ANd how does this filtering prevent spoofing of DHC responses? Are you saying that the CMTS verifies that all traffic supposedly coming from a DHC server comes from a proper IP address (i.e., one assigned ot a server?). That offers some protection. But what about packets from spoofed addresses that correspond to DHC server addresses? > P.S. Should I hold the next draft until after IESG LC ? Sounds reasonable. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 23 16:01:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04571; Wed, 23 Apr 2003 16:01:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NK2w826120; Wed, 23 Apr 2003 16:02:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NK0T825933 for ; Wed, 23 Apr 2003 16:00:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04429 for ; Wed, 23 Apr 2003 15:57:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198QPS-00070O-00 for dhcwg@ietf.org; Wed, 23 Apr 2003 16:00:02 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 198QPR-00070D-00 for dhcwg@ietf.org; Wed, 23 Apr 2003 16:00:01 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3NJxtlY029283; Wed, 23 Apr 2003 15:59:56 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-106.cisco.com [161.44.150.106]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA12360; Wed, 23 Apr 2003 15:59:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20030423155349.01769d40@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Apr 2003 15:59:54 -0400 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-pktc-kerb-tckt-01.txt Cc: dhcwg@ietf.org In-Reply-To: <200304231936.h3NJaeDN014292@rotala.raleigh.ibm.com> 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-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , ...inline... At 03:36 PM 4/23/2003 -0400, Thomas Narten wrote: >Hi Paul. > > > > > Code Len TCM > > > > +-----+-----+-----+-----+ > > > > | TBD | 2 | m1 | m2 | > > > > +-----+-----+-----+-----+ > > > > > >It might be better to not have m1/m2, since the text talks about a > > >single 16-bit field rather than two smaller fields. > > > The format is consistent with the formats presented in RFC 3495 (sections > > 8.3, 8.4, etc.). > >I guess we need to revise them and republish. :-) > > > I'm not sure what you are driving at. Suggestions? > >THis is relatively minor thing, but since the field is 16-byte field, >it seems better to show it that way then to divide it up into >individual bytes. > >Just change the picture to something like: > > Code Len TCM > +-----+-----+-----+-----+ > | TBD | 2 | TC Mask | > +-----+-----+-----+-----+ I'd much prefer leaving this as it is...its perfectly consistent with its parent RFC (3495). IP addresses are also multi octet quantities...they are handled in a similar manner (not lumped into a single field). OK ? > > > > 5. IANA Considerations > > > > > >what about future assignments of bit values? > > > Yes, needs to be added. How about... > > > "IANA is requested to maintain a new number space of "CableLabs Client > > Configuration Option Ticket Control Mask Bit Definitions", located in the > > BOOTP-DHCP Parameters Registry. The initial bit definitions are described > > in section 4 of this document. IANA is requested to register future bit > > mask definitions via an "IETF Consensus" approval policy as described in > > RFC 2434 [add ref}." > >works for me. OK > > > > However, the scenario described above is unlikely to occur. > > > > Within the cable delivery architecture required by the various > > > > CableLabs projects, the DHCP client is connected to a network > > > > through a cable modem and the CMTS (head-end). The CMTS is > > > > explicitly configured with a set of DHCP servers to which DHCP > > > > requests are forwarded. Further, a correctly configured CMTS > > > > will only allow downstream traffic from specific IP > > > > addresses/ranges. > > > > > >Could be more clear. I don't follow the last sentence, for example. > > > Last sentence change to... > > > "Further, the CMTS is explicitly configured to allow downstream traffic > > only from specific IP addresses/ranges." > >I don't follow the overall discussion to be honest. When clients are >using DHC, they don't have addresses yet. So what addresses are being >filtered? ANd how does this filtering prevent spoofing of DHC >responses? > >Are you saying that the CMTS verifies that all traffic supposedly >coming from a DHC server comes from a proper IP address (i.e., one >assigned ot a server?). That offers some protection. Yes >But what about >packets from spoofed addresses that correspond to DHC server >addresses? AFAIK, we are vulnerable. > > P.S. Should I hold the next draft until after IESG LC ? > >Sounds reasonable. OK >Thomas -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 24 17:25:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04440; Thu, 24 Apr 2003 17:25:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OLRn813191; Thu, 24 Apr 2003 17:27:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OLOG813077 for ; Thu, 24 Apr 2003 17:24:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04342 for ; Thu, 24 Apr 2003 17:20:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198oBY-0001dq-00 for dhcwg@ietf.org; Thu, 24 Apr 2003 17:23:16 -0400 Received: from ultrex.nishansystems.com ([12.36.127.195] helo=ariel.nishansystems.com) by ietf-mx with esmtp (Exim 4.12) id 198oBY-0001dG-00 for dhcwg@ietf.org; Thu, 24 Apr 2003 17:23:16 -0400 Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Apr 2003 14:23:08 -0700 Message-ID: From: Charles Monia To: "Thomas Narten (E-mail)" Cc: "'dhcwg@ietf.org'" , Joshua Tseng , Kevin Gibbons , "Ips (E-mail)" , "David Black (E-mail)" , "Elizabeth Rodriguez (E-mail)" Date: Thu, 24 Apr 2003 14:23:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] RE: AD review of draft-ietf-dhc-isnsoption-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Thomas: Thanks for your input. I will be making the changes to fix the editorial problems you've pointed out along with adding the section on IANA considerations. I have asked for input from the other co-authors on the technical issues, including vendor specific fields and security and will post responses to those issues when available. -- Charles ----------------------------------------- Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Tuesday, April 22, 2003 10:30 AM > To: cmonia@nishansystems.com; jtseng@nishansystems.com; > kgibbons@nishansystems.com > Cc: dhcwg@ietf.org > Subject: AD review of draft-ietf-dhc-isnsoption-05.txt > > General issues: > > I'd like to see a justification for the vendor specific fields. I'd > like to understand how these can be safely used without leading to > interoperability issues. Besides, there are other ways in DHC to do > vendor-specific things. Can we just remove them from this > option/document? > > The security considerations section is rather weak. > > General note: this document is inconsitent about bit ordering. Some > picture show bits numbered left-to-right, others right-to-left. Please > pick one and be consistent. > > needs an IANA considerations section. > > I assume a revision of the document would be in order before starting > the IETF LC. > > Specific comments follow. > > > DHCP Options for Internet Storage Name Service > > Would be good for the title to note that this is for DHCP for > IPv4. E.g.: > > The IPv4 DHCP Option for Internet Storage Name Service > > Abstract doesn't satisfy ID nits; e.g., has unexpanded acronyms. > > "iSNS" used before being defined. > > ditto for iSCSI, iFCP, etc. > > The Dynamic Host Configuration Protocol for Ipv4 provides a > > s/Ipv4/IPv4/ > > > Existing DHCP option numbers are not plausible due > to the following > > reasons: > > suggested reword: > > Existing DHCP options cannot be used to find iSNS servers for > the following reasons: > > > Length: the number of bytes that follow the Length > field. The > > minimum value for the Length field is 6 in > order to account > > for the iSNS Functions, Discovery Domain Access, and > > Administrative Flags fields. > > From the picture, it seems like the minimum length is more than > 6. Are some of the fields optional? > > > certificates for the use of iSCSI and iFCP devices. > The format of > > the iSNS Role bit field is shown in Figure 2: > > > > 1 2 3 > > 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Vendor-Specific |RESERVED |S|A|E| > > +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2 -- iSNS Functions > > I don't see how a vendor-specific portion of this option facilitates > interoperability. Remove? > > Also, caling it the "iSNS Role" field is confusing, since that is not > used in the previous figure. SHouldn't this be the "iSNS Functions" > field? > > > > Bit field Significance > > --------- ------------ > > 31 Function Fields Enabled > > 30 DD-Based Authorization > > 29 Security policy distribution > > 28 - 24 Reserved > > 23 - 16 Vendor-specific > > You need a transistion sentence saying what field is being talked > about. Presumably, this is "iSNS Server Security Bitmap"? > > > Enabled: This bit specifies the > validity of the > > Spell out "Function Fields Enabled", as that is the name of the field > per the picture. > > > Security: Indicates whether the iSNS > client is to > > spell out field name. > > > Vendor- These bits are used to > indicate the vendor- > > Specific: specific capabilities > supported by the > > indicated iSNS server. > > Again, this does not promote interoperability. There are other ways in > DHC to communicate vendor specific information. > > General note: this document is inconsitent about bit ordering. Some > picture show bits numbered left-to-right, others right-to-left. Please > pick one and be consistent. > > > 3. Security Considerations > > > > DHCP currently provides no authentication or > security mechanisms. > > Potential exposures to attack are discussed in > section 7 of the DHCP > > protocol specification [DHCP]. > > What about RFC 3118? > > > > iSNS security considerations are discussed in > [iSNS] and [SEC-IPS]. > > With regard to security considerations specific to > the use of this > > DHCP option to discover the location of the iSNS > server, exposure to > > a "man-in-the-middle" attack by an hostile entity > modifying or > > replacing the original iSNS option message should > be considered a > > potential security exposure. To prevent an > attacker from weakening > > the required security and potentially tricking the > iSNS client into > > connecting into rogue iSNS servers, reliance on > local security > > policy configuration is an appropriate countermeasure. > > This says almost nothing. What can happen if there is a man-in-the > middle? Really bad things? or just DOS? And what "local security > policy configuration" helps mitigate the threats? > > Thomas > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Apr 24 17:31:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04837; Thu, 24 Apr 2003 17:31:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OLXq813570; Thu, 24 Apr 2003 17:33:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OLV6813426 for ; Thu, 24 Apr 2003 17:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04565; Thu, 24 Apr 2003 17:27:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198oIB-0001gj-00; Thu, 24 Apr 2003 17:30:07 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 198oIA-0001gg-00; Thu, 24 Apr 2003 17:30:06 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3OLUX024155; Thu, 24 Apr 2003 14:30:33 -0700 (PDT) Message-Id: <200304242130.h3OLUX024155@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 24 Apr 2003 14:30:33 -0700 Subject: [dhcwg] RFC 3527 on Link Selection sub-option for the Relay Agent Information Option for DHCPv4 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3527 Title: Link Selection sub-option for the Relay Agent Information Option for DHCPv4 Author(s): K. Kinnear, M. Stapp, R. Johnson, J. Kumarasamy Status: Standards Track Date: April 2003 Mailbox: kkinnear@cisco.com, mjs@cisco.com, jayk@cisco.com, raj@cisco.com Pages: 9 Characters: 16831 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-agent-subnet-selection-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3527.txt This document describes the link selection sub-option of the relay-agent-information option for the Dynamic Host Configuration Protocol (DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host Configuration Protocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with the DHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent. This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030424142744.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3527 --OtherAccess Content-Type: Message/External-body; name="rfc3527.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030424142744.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Apr 25 07:24:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02946; Fri, 25 Apr 2003 07:24:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PBRI815894; Fri, 25 Apr 2003 07:27:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PBMU815777 for ; Fri, 25 Apr 2003 07:22:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02872 for ; Fri, 25 Apr 2003 07:18:54 -0400 (EDT) From: bozena.erdmann@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1991GT-0006rH-00 for dhcwg@ietf.org; Fri, 25 Apr 2003 07:21:13 -0400 Received: from [212.153.235.109] (helo=gw-nl5.philips.com ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1991GS-0006rE-00 for dhcwg@ietf.org; Fri, 25 Apr 2003 07:21:12 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 84CE62B250 for ; Fri, 25 Apr 2003 13:21:40 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id NAA19939 for ; Fri, 25 Apr 2003 13:21:40 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id NAA13470 for ; Fri, 25 Apr 2003 13:21:39 +0200 (MET DST) To: dhcwg@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 25 Apr 2003 13:21:35 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 25/04/2003 13:22:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [dhcwg] dhclient forbids mp3 over 802.11b???? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, I got stuck. When the client address is configured manually, everything is alright. I see the content of the server, I can play mp3 from it. When the client gets its IP address (the same address!, the same subnet and mask) configured with dhclient (3.0pl2), I cannot play mp3 files from server (the same machine as dhcp server), although mpeg starts properly. I still can see the server mp3 content. I seems not to matter if dhclient still runs or is closed. ???? I will appreciate every hint! Best regards! BE _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Apr 27 22:20:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06860; Sun, 27 Apr 2003 22:20:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S2P4816416; Sun, 27 Apr 2003 22:25:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S2Lc816348 for ; Sun, 27 Apr 2003 22:21:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06835 for ; Sun, 27 Apr 2003 22:16:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199yEP-0007RY-00 for dhcwg@ietf.org; Sun, 27 Apr 2003 22:19:01 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 199yEP-0007RT-00 for dhcwg@ietf.org; Sun, 27 Apr 2003 22:19:01 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3S2J3lY022792 for ; Sun, 27 Apr 2003 22:19:04 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-1046.cisco.com [10.21.100.22]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA12757 for ; Sun, 27 Apr 2003 22:19:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20030427193745.03fcdeb8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 27 Apr 2003 19:38:30 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] dhc WG meeting at IETF 57, Vienna Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here's the list of WGs I asked to avoid conflicts with: dnsext, dnsops, geopriv, ipcdn, ipv6, nemo, netconf, v6ops, zeroconf, zerouter Any others to add to the list? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 28 04:54:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24416; Mon, 28 Apr 2003 04:54:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S8wZ821955; Mon, 28 Apr 2003 04:58:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S8tn821867 for ; Mon, 28 Apr 2003 04:55:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24354 for ; Mon, 28 Apr 2003 04:50:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A4Nj-0001VG-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 04:53:03 -0400 Received: from webmail.mail.se.dataphone.net ([212.37.1.50] helo=intermail.se.dataphone.net) by ietf-mx with esmtp (Exim 4.12) id 19A4Ni-0001V4-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 04:53:03 -0400 Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.0.5) with ESMTP id 1153188; Mon, 28 Apr 2003 10:53:29 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: Thomas Narten , Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-pktc-kerb-tckt-01.txt Date: Mon, 28 Apr 2003 10:55:05 +0200 User-Agent: KMail/1.4.3 Cc: dhcwg@ietf.org References: <200304231936.h3NJaeDN014292@rotala.raleigh.ibm.com> In-Reply-To: <200304231936.h3NJaeDN014292@rotala.raleigh.ibm.com> MIME-Version: 1.0 Message-Id: <200304281055.05202.budm@weird-solutions.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3S8tn821868 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Wednesday 23 April 2003 21.36, Thomas Narten wrote: > > > > Code Len TCM > > > > +-----+-----+-----+-----+ > > > > > > > > | TBD | 2 | m1 | m2 | > > > > > > > > +-----+-----+-----+-----+ > > > > > >It might be better to not have m1/m2, since the text talks about a > > >single 16-bit field rather than two smaller fields. FWIW, I agree with Thomas. I think it's just misleading to have it split if it's a 16 bit field. The picture above implies a struct with two bytes, and some need to work with the bytes separately. Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 28 10:18:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02652; Mon, 28 Apr 2003 10:18:59 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SENR813888; Mon, 28 Apr 2003 10:23:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEKF813755 for ; Mon, 28 Apr 2003 10:20:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02485 for ; Mon, 28 Apr 2003 10:15:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A9Rb-0003BJ-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 10:17:23 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19A9Ra-0003BF-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 10:17:23 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3SEHJlY024269; Mon, 28 Apr 2003 10:17:20 -0400 (EDT) Received: from paduffy-w2k.cisco.com (ch2-dhcp150-106.cisco.com [161.44.150.106]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA15837; Mon, 28 Apr 2003 10:17:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20030428100250.0254a608@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 28 Apr 2003 10:17:18 -0400 To: Bud Millwood From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-pktc-kerb-tckt-01.txt Cc: Thomas Narten , dhcwg@ietf.org In-Reply-To: <200304281055.05202.budm@weird-solutions.com> References: <200304231936.h3NJaeDN014292@rotala.raleigh.ibm.com> <200304231936.h3NJaeDN014292@rotala.raleigh.ibm.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-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bud and all, Am I missing something here? If so, please set me straight... 1. RFC 2132 (options 24, 26, 35, 51, etc.) uses the same convention. 2. RFC 3495, which was approved by this group not two months ago, is using this same convention (in multiple locations). How did this convention fall out of favor in the last two months? 3. Given that RFC 3495 employs this convention, and given that this draft is a follow-on addition to 3495 (i.e. it will be implemented by all who are currently implementing 3495), I do not want to change conventions unless absolutely necessary. ??? At 10:55 AM 4/28/2003 +0200, Bud Millwood wrote: >On Wednesday 23 April 2003 21.36, Thomas Narten wrote: > > > > > > Code Len TCM > > > > > +-----+-----+-----+-----+ > > > > > > > > > > | TBD | 2 | m1 | m2 | > > > > > > > > > > +-----+-----+-----+-----+ > > > > > > > >It might be better to not have m1/m2, since the text talks about a > > > >single 16-bit field rather than two smaller fields. > >FWIW, I agree with Thomas. I think it's just misleading to have it split if >it's a 16 bit field. The picture above implies a struct with two bytes, and >some need to work with the bytes separately. > >Bud Millwood >Weird Solutions, Inc. >http://www.weird-solutions.com >tel: +46 8 758 3700 >fax: +46 8 758 3687 >mailto:budm@weird-solutions.com -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 28 13:19:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07499; Mon, 28 Apr 2003 13:19:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SHO2827799; Mon, 28 Apr 2003 13:24:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SHKI827422 for ; Mon, 28 Apr 2003 13:20:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07334 for ; Mon, 28 Apr 2003 13:15:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AC2g-0003x0-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 13:03:50 -0400 Received: from webmail.mail.se.dataphone.net ([212.37.1.50] helo=intermail.se.dataphone.net) by ietf-mx with esmtp (Exim 4.12) id 19AC2g-0003wx-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 13:03:50 -0400 Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.0.5) with ESMTP id 1163266; Mon, 28 Apr 2003 19:04:17 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: Christopher Zydel Subject: Re: [dhcwg] draft-ietf-dhc-pktc-kerb-tckt-01.txt Date: Mon, 28 Apr 2003 19:05:49 +0200 User-Agent: KMail/1.4.3 References: <200304231936.h3NJaeDN014292@rotala.raleigh.ibm.com> <200304281055.05202.budm@weird-solutions.com> <3EAD3CCB.50800@cv.net> In-Reply-To: <3EAD3CCB.50800@cv.net> Cc: dhcwg@ietf.org MIME-Version: 1.0 Message-Id: <200304281905.49931.budm@weird-solutions.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3SHKI827423 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Monday 28 April 2003 16.38, you wrote: > >>>>It might be better to not have m1/m2, since the text talks about a > >>>>single 16-bit field rather than two smaller fields. > > > >FWIW, I agree with Thomas. I think it's just misleading to have it split > > if it's a 16 bit field. The picture above implies a struct with two > > bytes, and some need to work with the bytes separately > > RFC 2132 uses the format used above repeatedly. Maybe that is worth > revisiting, but I don't think this draft should wait for such a debate > to reach concensus. Agreed. I never reflected on it in 2132. And I can't say I expected the discussion about it to last this long. :) - Bud Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Apr 28 20:22:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19950; Mon, 28 Apr 2003 20:22:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T0RP829070; Mon, 28 Apr 2003 20:27:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T0Nx829022 for ; Mon, 28 Apr 2003 20:23:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19906 for ; Mon, 28 Apr 2003 20:18:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AIre-0006YX-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 20:20:54 -0400 Received: from ultrex.nishansystems.com ([12.36.127.195] helo=ariel.nishansystems.com) by ietf-mx with esmtp (Exim 4.12) id 19AIrd-0006YU-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 20:20:53 -0400 Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Apr 2003 17:20:46 -0700 Message-ID: From: Charles Monia To: "Thomas Narten (E-mail)" Cc: Charles Monia , Joshua Tseng , Kevin Gibbons , "'dhcwg@ietf.org'" , "Ips (E-mail)" , "David Black (E-mail)" , "Elizabeth Rodriguez (E-mail)" Date: Mon, 28 Apr 2003 17:20:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] RE: AD review of draft-ietf-dhc-isnsoption-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Thomas: The following are changes proposed in response to your review comments raising non-editorial issues for the iSNS DHCP option. > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Tuesday, April 22, 2003 10:30 AM > To: cmonia@nishansystems.com; jtseng@nishansystems.com; > kgibbons@nishansystems.com > Cc: dhcwg@ietf.org > Subject: AD review of draft-ietf-dhc-isnsoption-05.txt > > General issues: > > I'd like to see a justification for the vendor specific fields. I'd > like to understand how these can be safely used without leading to > interoperability issues. Besides, there are other ways in DHC to do > vendor-specific things. Can we just remove them from this > option/document? > The vendor-specific fields will be redefined as "reserved" fields. > > 3. Security Considerations > > > > DHCP currently provides no authentication or > security mechanisms. > > Potential exposures to attack are discussed in > section 7 of the DHCP > > protocol specification [DHCP]. > > What about RFC 3118? > > > > iSNS security considerations are discussed in > [iSNS] and [SEC-IPS]. > > With regard to security considerations specific to > the use of this > > DHCP option to discover the location of the iSNS > server, exposure to > > a "man-in-the-middle" attack by an hostile entity > modifying or > > replacing the original iSNS option message should > be considered a > > potential security exposure. To prevent an > attacker from weakening > > the required security and potentially tricking the > iSNS client into > > connecting into rogue iSNS servers, reliance on > local security > > policy configuration is an appropriate countermeasure. > > This says almost nothing. What can happen if there is a man-in-the > middle? Really bad things? or just DOS? And what "local security > policy configuration" helps mitigate the threats? > We propose the following replacement text. Section 3.0 -- Security "[RFC3118] should be consulted to determine the requirements for additional security measures to verify the authenticity of the iSNS option message received by the DHCP client. If necessary, the authentication option described in [RFC3118] should be utilized. With regard to security considerations specific to the use of this DHCP option to discover the location of the iSNS server, exposure to a "man-in-the-middle" attack by a hostile entity modifying or replacing the original iSNS option message should be considered a potential security exposure. If the authentication option in [RFC3118] is not implemented, then an attacker may trick the iSNS client into connecting into rogue iSNS servers. If the authentication option for DHCP is not implemented and it is determined that the potential exists for a "man-in-the-middle" attack, then the DHCP option message for iSNS SHOULD NOT be utilized. iSNS security considerations are discussed in [iSNS] and [SEC-IPS]." -- Charles ----------------------------------------- Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 29 10:31:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24029; Tue, 29 Apr 2003 10:31:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEaL816135; Tue, 29 Apr 2003 10:36:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEW2815660 for ; Tue, 29 Apr 2003 10:32:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23452 for ; Tue, 29 Apr 2003 10:26:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AW64-0004Jp-00 for dhcwg@ietf.org; Tue, 29 Apr 2003 10:28:40 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19AW63-0004Jb-00 for dhcwg@ietf.org; Tue, 29 Apr 2003 10:28:39 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3TESdHo022105; Tue, 29 Apr 2003 10:28:44 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn4-514.cisco.com [10.21.82.2]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA13846; Tue, 29 Apr 2003 10:28:37 -0400 (EDT) Message-Id: <4.3.2.7.2.20030429083118.0404fd20@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Apr 2003 08:34:01 -0400 To: Paul Duffy From: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-pktc-kerb-tckt-01.txt Cc: Bud Millwood , Thomas Narten , dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20030428100250.0254a608@funnel.cisco.com> References: <200304281055.05202.budm@weird-solutions.com> <200304231936.h3NJaeDN014292@rotala.raleigh.ibm.com> <200304231936.h3NJaeDN014292@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I agree with Paul, here. The current diagram is consistent in format with the earlier RFCs Paul cites. - Ralph At 10:17 AM 4/28/2003 -0400, Paul Duffy wrote: >Bud and all, > >Am I missing something here? If so, please set me straight... > >1. RFC 2132 (options 24, 26, 35, 51, etc.) uses the same convention. > >2. RFC 3495, which was approved by this group not two months ago, is using this same convention (in multiple locations). How did this convention fall out of favor in the last two months? > >3. Given that RFC 3495 employs this convention, and given that this draft is a follow-on addition to 3495 (i.e. it will be implemented by all who are currently implementing 3495), I do not want to change conventions unless absolutely necessary. > >??? > >At 10:55 AM 4/28/2003 +0200, Bud Millwood wrote: >>On Wednesday 23 April 2003 21.36, Thomas Narten wrote: >> >>> > > > Code Len TCM >>> > > > +-----+-----+-----+-----+ >>> > > > >>> > > > | TBD | 2 | m1 | m2 | >>> > > > >>> > > > +-----+-----+-----+-----+ >>> > > >>> > >It might be better to not have m1/m2, since the text talks about a >>> > >single 16-bit field rather than two smaller fields. >> >>FWIW, I agree with Thomas. I think it's just misleading to have it split if >>it's a 16 bit field. The picture above implies a struct with two bytes, and >>some need to work with the bytes separately. >> >>Bud Millwood >>Weird Solutions, Inc. >>http://www.weird-solutions.com >>tel: +46 8 758 3700 >>fax: +46 8 758 3687 >>mailto:budm@weird-solutions.com > >-- > >Paul Duffy >Cisco Systems, Inc. >paduffy@cisco.com > > >_______________________________________________ >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 dhcwg-admin@ietf.org Tue Apr 29 10:33:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24233; Tue, 29 Apr 2003 10:33:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEcr817236; Tue, 29 Apr 2003 10:38:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SEek815615 for ; Mon, 28 Apr 2003 10:40:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03120 for ; Mon, 28 Apr 2003 10:35:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A9lR-0003H1-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 10:37:53 -0400 Received: from srv1.mail.cv.net ([167.206.112.40]) by ietf-mx with esmtp (Exim 4.12) id 19A9lR-0003Gy-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 10:37:53 -0400 Received: from cv.net (landsraad.eng.cv.net [167.206.9.45]) by srv1.mail.cv.net (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <0HE200F7Z5YWP4@srv1.mail.cv.net> for dhcwg@ietf.org; Mon, 28 Apr 2003 10:37:44 -0400 (EDT) Date: Mon, 28 Apr 2003 10:38:03 -0400 From: Christopher Zydel Subject: Re: [dhcwg] draft-ietf-dhc-pktc-kerb-tckt-01.txt In-reply-to: <200304281055.05202.budm@weird-solutions.com> To: Bud Millwood Cc: Thomas Narten , Paul Duffy , dhcwg@ietf.org Message-id: <3EAD3CCB.50800@cv.net> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401 References: <200304231936.h3NJaeDN014292@rotala.raleigh.ibm.com> <200304281055.05202.budm@weird-solutions.com> Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Bud Millwood wrote: >On Wednesday 23 April 2003 21.36, Thomas Narten wrote: > > > >>>>> Code Len TCM >>>>> +-----+-----+-----+-----+ >>>>> >>>>> | TBD | 2 | m1 | m2 | >>>>> >>>>> +-----+-----+-----+-----+ >>>>> >>>>> >>>>It might be better to not have m1/m2, since the text talks about a >>>>single 16-bit field rather than two smaller fields. >>>> >>>> > >FWIW, I agree with Thomas. I think it's just misleading to have it split if >it's a 16 bit field. The picture above implies a struct with two bytes, and >some need to work with the bytes separately > RFC 2132 uses the format used above repeatedly. Maybe that is worth revisiting, but I don't think this draft should wait for such a debate to reach concensus. Chris _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 29 10:35:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24433; Tue, 29 Apr 2003 10:35:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEeg817379; Tue, 29 Apr 2003 10:40:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SHsI830323 for ; Mon, 28 Apr 2003 13:54:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08349 for ; Mon, 28 Apr 2003 13:49:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ACmg-0004Jy-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 13:51:22 -0400 Received: from cyphermail.sandelman.ottawa.on.ca ([192.139.46.78] helo=noxmail.sandelman.ottawa.on.ca) by ietf-mx with esmtp (Exim 4.12) id 19ACmf-0004Jv-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 13:51:21 -0400 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id h3SHpsC14720 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 28 Apr 2003 13:51:55 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1] (may be forged)) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h3SHpr64006065 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 28 Apr 2003 13:51:54 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-5) with ESMTP id h3SHpqbn006061 for ; Mon, 28 Apr 2003 13:51:52 -0400 Message-Id: <200304281751.h3SHpqbn006061@marajade.sandelman.ottawa.on.ca> To: dhcwg@ietf.org Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Mon, 28 Apr 2003 13:51:51 -0400 From: Michael Richardson Subject: [dhcwg] DHCP over IKE Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , -----BEGIN PGP SIGNED MESSAGE----- A number of documents are being proposed in the IPSEC WG. The IPSRA WG produced a protocol that runs DHCP over an IPsec tunnel, RFC 3456. Other vendors used a protocol called "Configuration Payload" There is a third option being discussed, called "DHCP-over-IKE". The documents are draft-ietf-ipsec-dhcp-over-ike-00, as well as dhcp-over-ike-dhcpd-00.txt and dhcp-over-ike-radius-00.txt A discussion thread: http://www.sandelman.ottawa.on.ca/ipsec/2003/04/msg00053.html ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPq1qNoqHRg3pndX9AQGVUAQAw8O+hQWQyYpE71zLk945ARn046B73081 SYn3pmjYA2O4884w6dtEYJdgo+3yNdiORp2THWip0W0raqn9rrYkgMkRCipAv5qo fVZqsx5FILzMXz6ZCLnV6Wwxod2cby99zqA1qw3MbPMsIc1KhsXG16VK0Ei6OObX vbM+43ZdVg4= =5aYT -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Apr 29 10:37:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24690; Tue, 29 Apr 2003 10:37:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEgf817532; Tue, 29 Apr 2003 10:42:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKdH811703 for ; Mon, 28 Apr 2003 16:39:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13786 for ; Mon, 28 Apr 2003 16:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AFMH-0005F2-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 16:36:17 -0400 Received: from [200.72.208.170] (helo=mail.trilogy.cl) by ietf-mx with esmtp (Exim 4.12) id 19AFMF-0005Ey-00 for dhcwg@ietf.org; Mon, 28 Apr 2003 16:36:15 -0400 Received: from mail.trilogy.cl ([172.16.1.21]) by mail.trilogy.cl with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Apr 2003 16:38:21 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30DC4.11D59C0E" Date: Mon, 28 Apr 2003 16:23:46 -0400 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: question from chile Thread-Index: AcMNl5VQ9A0oNsONSzuQHWw4ruvj7gAAH1ogAADNEEAAAAhzcAAKEbyw From: "Vicente Furnaro" To: X-OriginalArrivalTime: 28 Apr 2003 20:38:21.0361 (UTC) FILETIME=[1B8FF210:01C30DC6] Subject: [dhcwg] question from chile Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C30DC4.11D59C0E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear friends: =20 I want to know if exist a tool that allow to administrador to can = validate by authentication when the DHCP server give them an IP address, = and when the user don=B4t be validate, don=B4t give the IP. =20 Send us technical papers to our study from our engineers, and you = suggest for brands. =20 Regards =20 Vicente Furnaro General manager Trilogy Inc. Limitada www.trilogy.cl =20 Chile =20 =20 ------_=_NextPart_001_01C30DC4.11D59C0E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mensaje

Dear friends:

 

=

I want to know if exist a tool that allow to administrador to can validate by authentication when the DHCP server give them an IP address, = and when the user don=B4t be validate, don=B4t give the IP.

 

Send us technical papers to = our study from our engineers, and you suggest for = brands.

 

Regards

 

Vicente Furnaro

General manager

Trilogy Inc. Limitada

www.trilogy.cl

Chile

 

=

 

=
------_=_NextPart_001_01C30DC4.11D59C0E-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 30 14:33:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16318; Wed, 30 Apr 2003 14:33:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UIa6816975; Wed, 30 Apr 2003 14:36:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UISV830302 for ; Wed, 30 Apr 2003 14:28:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15778 for ; Wed, 30 Apr 2003 14:22:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AwFt-0002I8-00 for dhcwg@ietf.org; Wed, 30 Apr 2003 14:24:33 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19AwFt-0002HQ-00 for dhcwg@ietf.org; Wed, 30 Apr 2003 14:24:33 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3UIOdWS023393 for ; Wed, 30 Apr 2003 14:24:40 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn4-42.cisco.com [10.21.80.42]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA08615 for ; Wed, 30 Apr 2003 14:24:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20030430110023.03f6c840@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Apr 2003 11:03:38 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] WG last call on draft-ietf-dhc-unused-optioncodes-02 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "Unused DHCP Option Codes" . The last call will conclude on Friday, May 16. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Prior to the publication of RFC2489 (which was updated by RFC2939), several option codes were assigned to proposed DHCP options that were subsequently never used. This document lists those unused option codes and will be used to confirm that these option codes can be reused for other DHCP options in the future. This document is being considered for publication as Informational, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 30 14:39:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16491; Wed, 30 Apr 2003 14:39:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UIj5819648; Wed, 30 Apr 2003 14:45:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UISX830306 for ; Wed, 30 Apr 2003 14:28:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15781 for ; Wed, 30 Apr 2003 14:22:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AwFv-0002IE-00 for dhcwg@ietf.org; Wed, 30 Apr 2003 14:24:35 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19AwFu-0002HR-00 for dhcwg@ietf.org; Wed, 30 Apr 2003 14:24:35 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3UIOgWS023420 for ; Wed, 30 Apr 2003 14:24:43 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn4-42.cisco.com [10.21.80.42]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA08625 for ; Wed, 30 Apr 2003 14:24:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20030430115524.03f56a98@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Apr 2003 12:02:43 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] WG last call on draft-ietf-dhc-relay-agent-auth-00 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "The Authentication Suboption for the DHCP Relay Agent Option" . The last call will conclude on Friday, May 16. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. This specification defines two mechanisms for securing the messages exchanged between a relay agent and a server. The first mechanism defines a new authentication suboption for the Relay Agent Information Option that supports source entity authentication and data integrity for relayed DHCP messages. The authentication suboption contains a cryptographic signature in a payload derived from the option used in DHCP Authentication (RFC 3118). The second mechanism uses IPsec (RFC 2041) to protect messages exchanged between relay agents and servers. This document is being considered for publication as Informational, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-auth-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 30 15:02:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19302; Wed, 30 Apr 2003 15:02:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UJ81812432; Wed, 30 Apr 2003 15:08:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UJ1a829985 for ; Wed, 30 Apr 2003 15:01:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18124 for ; Wed, 30 Apr 2003 14:55:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Awlt-0002ez-00 for dhcwg@ietf.org; Wed, 30 Apr 2003 14:57:37 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 19Awls-0002ev-00 for dhcwg@ietf.org; Wed, 30 Apr 2003 14:57:36 -0400 Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h3UIvQnZ023498; Wed, 30 Apr 2003 13:57:26 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h3UIvQht010183; Wed, 30 Apr 2003 13:57:26 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 30 Apr 2003 13:57:26 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-unused-optioncodes-02 Date: Wed, 30 Apr 2003 13:55:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30F4A.0DEDC06C" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C30F4A.0DEDC06C Content-Type: text/plain; charset="ISO-8859-1" Ralph, et al: I support this work and would like to see it move forward. However, I do have a few questions that should be resolved before doing so: 1. It is not clear what the action for the PXE options should be. I believe it is to recover them, but what impact does that have to the PXE specification which mentions them? Perhaps they are not widely used by PXE implementations? If so, would it not be worth saying a bit more under the "Reason to recover". Just because they are NOT documented as Internet-Drafts does not mean we should automatically recover them. If they are in wide use, we need to keep them. 2. The above comment also applies to a few other options (such as #80). Change 'reason to recover' to "Never published as standard and not in general use"? 3. In section 4: Reason to recover: Never published as standard; note that these option codes are mentioned as should be: Reason to recover: Never published as standard; note that these option codes are mentioned in [6]. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, April 30, 2003 11:04 AM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-unused-optioncodes-02 This message announces a WG last call on "Unused DHCP Option Codes" . The last call will conclude on Friday, May 16. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Prior to the publication of RFC2489 (which was updated by RFC2939), several option codes were assigned to proposed DHCP options that were subsequently never used. This document lists those unused option codes and will be used to confirm that these option codes can be reused for other DHCP options in the future. This document is being considered for publication as Informational, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-02.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C30F4A.0DEDC06C Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] WG last call on = draft-ietf-dhc-unused-optioncodes-02

Ralph, et al:

I support this work and would like to see it move = forward.

However, I do have a few questions that should be = resolved before doing so:

1. It is not clear what the action for the PXE = options should be. I believe it
is to recover them, but what impact does that have = to the PXE specification
which mentions them? Perhaps they are not widely = used by PXE implementations?
If so, would it not be worth saying a bit more under = the "Reason to recover".
Just because they are NOT documented as = Internet-Drafts does not mean we should
automatically recover them. If they are in wide use, = we need to keep them.

2. The above comment also applies to a few other = options (such as #80). Change
'reason to recover' to "Never published as = standard and not in general use"?

3. In section 4:

   Reason to recover: Never published as = standard; note that these
      option codes are = mentioned as

should be:

   Reason to recover: Never published as = standard; note that these
      option codes are = mentioned in [6].

- Bernie


-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, April 30, 2003 11:04 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WG last call on = draft-ietf-dhc-unused-optioncodes-02


This message announces a WG last call on "Unused = DHCP Option
Codes" = <draft-ietf-dhc-unused-optioncodes-02>.  The last = call
will conclude on Friday, May 16.

Please respond to this WG last call.  If you = support acceptance of the
document without change, respond with a simple = acknowledgment, so that
support for the document can be assessed.

Prior to the publication of RFC2489 (which was = updated by RFC2939),
several option codes were assigned to proposed DHCP = options that
were subsequently never used. This document lists = those unused
option codes and will be used to confirm that these = option codes
can be reused for other DHCP options in the = future.  This document
is being considered for publication as = Informational, and is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-unu= sed-optioncodes-02.txt

- Ralph Droms

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

------_=_NextPart_001_01C30F4A.0DEDC06C-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Apr 30 15:08:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19815; Wed, 30 Apr 2003 15:08:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UJDe813512; Wed, 30 Apr 2003 15:13:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UJ1u801759 for ; Wed, 30 Apr 2003 15:01:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18133 for ; Wed, 30 Apr 2003 14:55:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AwmD-0002fG-00 for dhcwg@ietf.org; Wed, 30 Apr 2003 14:57:57 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19AwmC-0002ew-00 for dhcwg@ietf.org; Wed, 30 Apr 2003 14:57:56 -0400 Received: from jschnizl-w2k.cisco.com (rtp-vpn2-479.cisco.com [10.82.241.223]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3UIw3WT004151; Wed, 30 Apr 2003 14:58:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20030430145605.01f236a8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Apr 2003 14:58:02 -0400 To: Ralph Droms From: John Schnizlein Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-relay-agent-auth-00 Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20030430115524.03f56a98@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Simple acknowledgement of support. At 12:02 PM 4/30/2003, Ralph Droms wrote: >Please respond to this WG last call. If you support acceptance of the >document without change, respond with a simple acknowledgment, so that >support for the document can be assessed. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg