From mailman-admin@ietf.org Fri Aug 1 09:32:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14296 for ; Fri, 1 Aug 2003 09:18:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iZbK-0007lC-S4 for DHC-ARCHIVE@lists.ietf.org; Fri, 01 Aug 2003 09:05:42 -0400 Date: Fri, 01 Aug 2003 09:05:42 -0400 Message-ID: <20030801130542.29120.79623.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 Aug 1 15:28:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06770; Fri, 1 Aug 2003 15:28:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ifZJ-0000cI-4B; Fri, 01 Aug 2003 15:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ifZ6-0000bo-8E for dhcwg@optimus.ietf.org; Fri, 01 Aug 2003 15:27:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06544; Fri, 1 Aug 2003 15:27:44 -0400 (EDT) Message-Id: <200308011927.PAA06544@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Aug 2003 15:27:44 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-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: , --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-05.txt Pages : 11 Date : 2003-8-1 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 directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-05.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-05.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-05.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-8-1153507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-unused-optioncodes-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-unused-optioncodes-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-1153507.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Aug 2 09:04:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12870; Sat, 2 Aug 2003 09:04:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iw3F-0002c3-Ha; Sat, 02 Aug 2003 09:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iw2N-0002br-8Q for dhcwg@optimus.ietf.org; Sat, 02 Aug 2003 09:03: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 JAA12856 for ; Sat, 2 Aug 2003 09:03:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iw2L-0003NZ-00 for dhcwg@ietf.org; Sat, 02 Aug 2003 09:03:05 -0400 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 19iw2L-0003NW-00 for dhcwg@ietf.org; Sat, 02 Aug 2003 09:03:05 -0400 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id F1D6F1C01719; Sat, 2 Aug 2003 06:02:57 -0700 (PDT) Received: from NT23054 (nt23054.india.hp.com [15.42.230.54]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28761)/8.9.3 SMKit7.02) with SMTP id SAA17054; Sat, 2 Aug 2003 18:32:02 +0530 (IST) Reply-To: From: "Jitesh N Verma" To: , Cc: Date: Sat, 2 Aug 2003 18:36:19 +0530 Message-ID: <05b701c358f6$dde81740$36e62a0f@NT23054> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Source address and source port problem in DHCP server 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 Hi all, Please read care fully, since the following text is bit confusing. Background: I have come across a relay agent (CISCO router), which checks the source IP address of the server's reply packet against the destination IP address of the relayed request packet and discards the reply packet if they do not match. If a DHCP relay agent relays a request to an alias IP address (e.g.lan0:1 - 1.1.1.2), HP DHCP server replies with primary IP address (lan0 - 1.1.1.1) as the source IP address. If there is no alias IP address configured for an interface, the DHCP server works fine. Question: Can somebody tell me if checking of the source address of the reply packet with the destination address of the relayed request packet by a DHCP relay agent OK? RFC does not say anything on this issue. I want to know who is not comploying with the RFC? Relay? Or the server? While trying to fix the source address problem in DHCP server, I ran into similar problem with the source port. I want to know if any implemettaion of DHCP relay agent checks for the source port of the reply packet with the destination port of the relayed request packet. If yes, is checking of source port of the reply packet with the destination port of the relayed request packet by the relay agent OK? Again RFC does not say anything about the source port of the reply packet from the server. Can somebody tell me whether such checks on the source port and address of the reply packet is optional (MAY, MIGHT etc.) or mandatory (SHOULD, MUST etc.)? In such case who is breaking the RFC. Regards, Jitesh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Aug 2 13:36:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17512; Sat, 2 Aug 2003 13:36:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19j0IT-0004fs-V2; Sat, 02 Aug 2003 13:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19j0I8-0004fT-Tv for dhcwg@optimus.ietf.org; Sat, 02 Aug 2003 13:35:40 -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 NAA17466 for ; Sat, 2 Aug 2003 13:35:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19j0I6-0004Jp-00 for dhcwg@ietf.org; Sat, 02 Aug 2003 13:35:38 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 19j0I5-0004Je-00 for dhcwg@ietf.org; Sat, 02 Aug 2003 13:35:37 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id CF4531B2003; Sat, 2 Aug 2003 12:26:37 -0500 (CDT) From: Ted Lemon To: Subject: Re: [dhcwg] Source address and source port problem in DHCP server Date: Sat, 2 Aug 2003 12:36:00 -0500 User-Agent: KMail/1.5 Cc: References: <05b701c358f6$dde81740$36e62a0f@NT23054> In-Reply-To: <05b701c358f6$dde81740$36e62a0f@NT23054> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308021236.00737.mellon@nominum.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 On Saturday 02 August 2003 08:06, Jitesh N Verma wrote: > Can somebody tell me if checking of the source address > of the reply packet with the destination address of the > relayed request packet by a DHCP relay agent OK? RFC > does not say anything on this issue. I want to know > who is not comploying with the RFC? Relay? Or the > server? If the RFC doesn't say that the relay agent should do this (and it does not) then the relay agent shouldn't do it. This is a completely wrong to thing do, because it breaks interoperability by imposing a requirement on the server that is not stated in the protocol specification. I suspect it's a bug in some software version that results from some feature they've added, rather than something they have decided they ought to do in general. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 4 02:13:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17066; Mon, 4 Aug 2003 02:13:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jYab-0002F6-UR; Mon, 04 Aug 2003 02:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jYaN-0002D3-NB for dhcwg@optimus.ietf.org; Mon, 04 Aug 2003 02:12:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16964 for ; Mon, 4 Aug 2003 02:12:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jYaK-0006PS-00 for dhcwg@ietf.org; Mon, 04 Aug 2003 02:12:44 -0400 Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx with esmtp (Exim 4.12) id 19jYaJ-0006P3-00 for dhcwg@ietf.org; Mon, 04 Aug 2003 02:12:43 -0400 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel10.hp.com (Postfix) with ESMTP id 0D22B1C00EB0; Sun, 3 Aug 2003 23:12:28 -0700 (PDT) Received: from NT23054 (nt23054.india.hp.com [15.42.230.54]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28761)/8.9.3 SMKit7.02) with SMTP id LAA21895; Mon, 4 Aug 2003 11:41:23 +0530 (IST) Reply-To: From: "Jitesh N Verma" To: "'Ted Lemon'" Cc: Subject: RE: [dhcwg] Source address and source port problem in DHCP server Date: Mon, 4 Aug 2003 11:45:41 +0530 Message-ID: <05c501c35a4f$d5905cb0$36e62a0f@NT23054> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <200308021236.00737.mellon@nominum.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-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 Hi all, Ted, thanks a lot for your reply. I expect some more list members to give their opinion and then we should build a consensus on this kind of issues. Regards, Jitesh -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ted Lemon Sent: Saturday, August 02, 2003 11:06 PM To: jitesh@india.hp.com Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Source address and source port problem in DHCP server On Saturday 02 August 2003 08:06, Jitesh N Verma wrote: > Can somebody tell me if checking of the source address > of the reply packet with the destination address of the > relayed request packet by a DHCP relay agent OK? RFC > does not say anything on this issue. I want to know > who is not comploying with the RFC? Relay? Or the > server? If the RFC doesn't say that the relay agent should do this (and it does not) then the relay agent shouldn't do it. This is a completely wrong to thing do, because it breaks interoperability by imposing a requirement on the server that is not stated in the protocol specification. I suspect it's a bug in some software version that results from some feature they've added, rather than something they have decided they ought to do in general. _______________________________________________ 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 Aug 4 14:09:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06065; Mon, 4 Aug 2003 14:09:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjlU-00089c-WF; Mon, 04 Aug 2003 14:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjka-000892-5K for dhcwg@optimus.ietf.org; Mon, 04 Aug 2003 14:08:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06038 for ; Mon, 4 Aug 2003 14:07:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjkX-0004Qa-00 for dhcwg@ietf.org; Mon, 04 Aug 2003 14:08:01 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19jjkW-0004QX-00 for dhcwg@ietf.org; Mon, 04 Aug 2003 14:08:01 -0400 Received: from redback.com (asia.redback.com [155.53.42.122]) by prattle.redback.com (Postfix) with ESMTP id D4DB183A02B; Mon, 4 Aug 2003 11:05:20 -0700 (PDT) Message-ID: <3F2EA060.9000104@redback.com> Date: Mon, 04 Aug 2003 11:05:20 -0700 From: Sanjeev Verma Organization: Redback networks Inc. User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.1) Gecko/20020829 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Lemon Cc: jitesh@india.hp.com, dhcwg@ietf.org Subject: Re: [dhcwg] Source address and source port problem in DHCP server References: <05b701c358f6$dde81740$36e62a0f@NT23054> <200308021236.00737.mellon@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed 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 Ted Lemon wrote: > On Saturday 02 August 2003 08:06, Jitesh N Verma wrote: > >>Can somebody tell me if checking of the source address >>of the reply packet with the destination address of the >>relayed request packet by a DHCP relay agent OK? RFC >>does not say anything on this issue. I want to know >>who is not comploying with the RFC? Relay? Or the >>server? > > > If the RFC doesn't say that the relay agent should do this (and it does not) > then the relay agent shouldn't do it. This is a completely wrong to thing > do, because it breaks interoperability by imposing a requirement on the > server that is not stated in the protocol specification. I suspect it's a > bug in some software version that results from some feature they've added, > rather than something they have decided they ought to do in general. > > It is an implementation detail - how to match replies to requests. For relay, (xid, mac address, message type)-tuple should be sufficient to match replies to requests. But in this case, the relay appears to be using (server IP address, port sent out on)-tuple to do either matching or additional checking. And that's broken. For the sake of completion - under some circumstances, matching requests to replies using mac address may also not work. And, if the relay is attaching option 82 to relayed requests, that could also effect the matching logic in relay. > _______________________________________________ > 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 Aug 4 14:15:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06434; Mon, 4 Aug 2003 14:15:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjrI-0008TT-NY; Mon, 04 Aug 2003 14:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjqn-0008T2-D6 for dhcwg@optimus.ietf.org; Mon, 04 Aug 2003 14:14:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06407 for ; Mon, 4 Aug 2003 14:14:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjqk-0004XJ-00 for dhcwg@ietf.org; Mon, 04 Aug 2003 14:14:27 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19jjqk-0004Wy-00 for dhcwg@ietf.org; Mon, 04 Aug 2003 14:14:26 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h74IDs7F009840 for ; Mon, 4 Aug 2003 11:13:54 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn3-38.cisco.com [10.21.64.38]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABG01311; Mon, 4 Aug 2003 14:13:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20030804141035.04274648@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Aug 2003 14:13:48 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Source address and source port problem in DHCP server In-Reply-To: <3F2EA060.9000104@redback.com> References: <05b701c358f6$dde81740$36e62a0f@NT23054> <200308021236.00737.mellon@nominum.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: , In general, there is no need to match replies to requests. One of the design principles for DHCP is to avoid the requirement for the relay agent to maintain any state about individual DHCP messages. All of the information required by a relay agent to forward the reply to the DHCP client is contained in the message itself (client MAC and IP address). Even in the case of option 82, the information needed by the relay agent to forward the reply to the correct downstream port is contained in option 82 itself. - Ralph At 11:05 AM 8/4/2003 -0700, Sanjeev Verma wrote: >Ted Lemon wrote: >>On Saturday 02 August 2003 08:06, Jitesh N Verma wrote: >> >>>Can somebody tell me if checking of the source address >>>of the reply packet with the destination address of the >>>relayed request packet by a DHCP relay agent OK? RFC >>>does not say anything on this issue. I want to know >>>who is not comploying with the RFC? Relay? Or the >>>server? >> >>If the RFC doesn't say that the relay agent should do this (and it does >>not) then the relay agent shouldn't do it. This is a completely wrong >>to thing do, because it breaks interoperability by imposing a requirement >>on the server that is not stated in the protocol specification. I >>suspect it's a bug in some software version that results from some >>feature they've added, rather than something they have decided they ought >>to do in general. > >It is an implementation detail - how to match replies to requests. For >relay, (xid, mac address, message type)-tuple should be sufficient to >match replies to requests. But in this case, the relay appears to be using >(server IP address, port sent out on)-tuple to do either matching or >additional checking. And that's broken. > For the sake of completion - under some circumstances, matching > requests to replies using mac address may also not work. And, if the > relay is attaching option 82 to relayed requests, that could also effect > the matching logic in relay. > > >>_______________________________________________ >>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 Mon Aug 4 14:53:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07596; Mon, 4 Aug 2003 14:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkS5-0001PT-Se; Mon, 04 Aug 2003 14:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkRn-0001Od-96 for dhcwg@optimus.ietf.org; Mon, 04 Aug 2003 14:52:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07568 for ; Mon, 4 Aug 2003 14:52:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkRk-0004rz-00 for dhcwg@ietf.org; Mon, 04 Aug 2003 14:52:40 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 19jkRj-0004rs-00 for dhcwg@ietf.org; Mon, 04 Aug 2003 14:52:39 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 1C57A1B2148 for ; Mon, 4 Aug 2003 13:43:21 -0500 (CDT) From: Ted Lemon To: dhcwg@ietf.org Subject: Re: [dhcwg] Source address and source port problem in DHCP server Date: Mon, 4 Aug 2003 13:53:07 -0500 User-Agent: KMail/1.5 References: <05b701c358f6$dde81740$36e62a0f@NT23054> <200308021236.00737.mellon@nominum.com> <4.3.2.7.2.20030804141035.04274648@funnel.cisco.com> In-Reply-To: <4.3.2.7.2.20030804141035.04274648@funnel.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308041353.07337.mellon@nominum.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 On Monday 04 August 2003 13:13, Ralph Droms wrote: > In general, there is no need to match replies to requests. One of the > design principles for DHCP is to avoid the requirement for the relay agent > to maintain any state about individual DHCP messages. All of the > information required by a relay agent to forward the reply to the DHCP > client is contained in the message itself (client MAC and IP > address). Even in the case of option 82, the information needed by the > relay agent to forward the reply to the correct downstream port is > contained in option 82 itself. To expand on this a little, of course there are times when it may be desirable to make the relay agent do more than a dumb relay agent would, and in those cases it may be necessary to match messages, even though the protocol neither needs nor suggests such matching. As Ralph has said, the way to do this is with the relay agent information option. As Ralph has also said, in general the relay agent information option should provide enough of a cache for the relay that it doesn't actually need to do message matching - it should be able to blindly forward the message to the right place based on the information returned by the server in the relay agent information option. At a minimum, any enhancements that are made in the relay agent that are not required by the protocol must do no harm. They must not break interoperability. What the gentleman from HP has described breaks interoperability, so any devices that do this are not in compliance with RFC951 or RFC2131. It would be wrong for the manufacturer of these devices to claim compliance with either of these protocols if the devices fail to deliver relayed messages that are themselves in compliance with the protocols. Of course, as I say, I suspect this is just a bug, so there's probably no need for anybody to go around changing any packaging or documentation - they just need to fix the bug. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 4 21:35:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17441; Mon, 4 Aug 2003 21:35:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqj7-0003dC-E4; Mon, 04 Aug 2003 21:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jqis-0003cu-41 for dhcwg@optimus.ietf.org; Mon, 04 Aug 2003 21:34:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17419 for ; Mon, 4 Aug 2003 21:34:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jqip-0006n3-00 for dhcwg@ietf.org; Mon, 04 Aug 2003 21:34:43 -0400 Received: from bay5-f40.bay5.hotmail.com ([65.54.173.40] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19jqii-0006mc-00 for dhcwg@ietf.org; Mon, 04 Aug 2003 21:34:36 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Aug 2003 18:34:03 -0700 Received: from 218.244.36.158 by by5fd.bay5.hotmail.msn.com with HTTP; Tue, 05 Aug 2003 01:34:02 GMT X-Originating-IP: [218.244.36.158] X-Originating-Email: [hary1125@msn.com] From: "yuan zhang" To: dhcwg@ietf.org Date: Tue, 05 Aug 2003 09:34:02 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Aug 2003 01:34:03.0109 (UTC) FILETIME=[A6F35950:01C35AF1] Subject: [dhcwg] fixed address 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,can use other item to specify a fixed ipaddress to client rather than hardaddress? _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 5 14:35:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22224; Tue, 5 Aug 2003 14:35:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6eD-0002c1-Dw; Tue, 05 Aug 2003 14:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k6dt-0002bO-2i for dhcwg@optimus.ietf.org; Tue, 05 Aug 2003 14:34:41 -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 OAA22118 for ; Tue, 5 Aug 2003 14:34:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k6dq-0004dC-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 14:34:38 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19k6dp-0004d4-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 14:34:37 -0400 Date: Tue, 05 Aug 2003 11:36:20 -0700 From: Alper Yegin To: CC: Tschofenig Hannes , "'Dan.Forsberg@nokia.com'" Message-ID: In-Reply-To: <4.3.2.7.2.20030730062737.04270d38@funnel.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] pana-bootstrap-rfc3118 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 From the DHC WG meeting notes: RFC3118 Delayed Authentication Using PANA H. Tschofenig This document describes a mechanism for establishing a DHCP SA (between client and server) through PANA (assuming PANA is invoked before DHCP). The scenario is: * host establishes SA with PANA * PAA does key distribution to host and DHCP server * host and server use key for authenticated DHCP There was some discussion about the mechanism through which the PAA would get keying information to the DHCP participants. The WG requested that the draft be revised to provide additional detail, and will reconsider the draft after the revisions are published. Before we produce the next rev of the draft, we'd like to fully understand what should go in. So, let's continue the discussions from where we left at the meeting. Here are the points we discussed at the meeting. We are sure we missed some, please add... - How is the DHCP SA key transferred from DHCP relay (PAA) to DHCP server? The DHCP architecture already has the concept of carrying client-specific data from the dhcp relay to dhcp server after the network access AAA (draft-ietf-dhc-agentopt-radius-02.txt). This client-specific key should also be carried along with that data. Our draft is missing the details of this sub-option, we should include this in the next version. Security of the keys can be ensured by using IPsec with ESP as outlined in draft-ietf-dhc-relay-agent-auth-01.txt. - What module is running where? PAA has to be on the same IP-hop as the client. It can be colocated with the DHCP server if the server is on the last hop. If DHCP server is somewhere behind, and there is a DHCP relay on the last hop, then PAA can be colocated with the DHCP relay. PAA module has to communicate with the colocated DHCP module (server or relay) in order to pass the DHCP SA. They don't have to be implemented in the same module, they can be (and would be) separate processes. We shall clarify this better in the next rev. Are there any other concerns/comments/questions? Alper, on behalf of the authors of the draft _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 5 15:05:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23645; Tue, 5 Aug 2003 15:05:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k77E-0003kn-Tc; Tue, 05 Aug 2003 15:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k779-0003kC-5h for dhcwg@optimus.ietf.org; Tue, 05 Aug 2003 15:04:55 -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 PAA23576 for ; Tue, 5 Aug 2003 15:04:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k775-0004xs-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 15:04:51 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19k775-0004xo-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 15:04:51 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 05 Aug 2003 12:04:22 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h75J4Itp015815; Tue, 5 Aug 2003 12:04:18 -0700 (PDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-27.cisco.com [10.82.240.27]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA01406; Tue, 5 Aug 2003 12:04:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20030805144903.00b27790@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Aug 2003 15:04:15 -0400 To: Alper Yegin From: John Schnizlein Subject: Re: [dhcwg] pana-bootstrap-rfc3118 Cc: , Tschofenig Hannes , "'Dan.Forsberg@nokia.com'" In-Reply-To: References: <4.3.2.7.2.20030730062737.04270d38@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: , At 02:36 PM 8/5/2003, Alper Yegin wrote: >Before we produce the next rev of the draft, we'd like to fully understand >what should go in. So, let's continue the discussions from where we left at >the meeting. My impression was that the concerns about this draft went much deeper than editing-in more text could repair. There is the issue that PANA does not have Security Area endorsement to be a key-distribution protocol. There is an irony in that PANA, which was justified as different from IEEE 802.1X by hosts having IP addresses first (not layer 2), is proposed to operate before DHCP, which provides the IP address. There is (at least) intolerable complexity in the cooperation of the DHCP relay agent, which does not participate in the client-server message authentication for which PANA proposes to provide keys. I thought the consensus was that the WG not take on this work. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 5 16:47:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28129; Tue, 5 Aug 2003 16:47:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8hy-0008Bd-0s; Tue, 05 Aug 2003 16:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8h9-0008Ai-BM for dhcwg@optimus.ietf.org; Tue, 05 Aug 2003 16:46:11 -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 QAA28038 for ; Tue, 5 Aug 2003 16:46:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8h7-0005l8-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 16:46:09 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 19k8h6-0005l5-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 16:46:08 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id h75Kk0Vj003975; Wed, 6 Aug 2003 05:46:00 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id h75Kk0EN006665; Wed, 6 Aug 2003 05:46:00 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA06664 ; Wed, 6 Aug 2003 05:46:00 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA12142; Wed, 6 Aug 2003 05:45:59 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA29039; Wed, 6 Aug 2003 05:45:59 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id h75Kjw5H018009; Wed, 6 Aug 2003 05:45:58 +0900 (JST) Received: from localhost ([159.119.168.136]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HJ500BANZ0JI4@tsbpo1.po.toshiba.co.jp>; Wed, 6 Aug 2003 05:45:57 +0900 (JST) Date: Tue, 05 Aug 2003 13:55:36 -0700 From: Yoshihiro Ohba Subject: Re: [dhcwg] pana-bootstrap-rfc3118 In-reply-to: <4.3.2.7.2.20030805144903.00b27790@wells.cisco.com> To: John Schnizlein Cc: Alper Yegin , dhcwg@ietf.org, Tschofenig Hannes , "'Dan.Forsberg@nokia.com'" Message-id: <20030805205536.GB963@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 18 References: <4.3.2.7.2.20030730062737.04270d38@funnel.cisco.com> <4.3.2.7.2.20030805144903.00b27790@wells.cisco.com> 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 Tue, Aug 05, 2003 at 03:04:15PM -0400, John Schnizlein wrote: > There is (at least) intolerable complexity in the cooperation of > the DHCP relay agent, which does not participate in the client-server > message authentication for which PANA proposes to provide keys. > Could you elaborate more on the complexity? This is because I'm interested in implementing the proposed scheme and I am viewing that the complexity is acceptable and reasonable. Bootstrapping DHCP authentication from AAA is useful and needed where PKI (via DNSSEC) is not available (and DNSSEC is not available in many situations). I believe that pana-bootstrap-rfc3118 is a practical solution and would like to see it becoming a WG item. Yoshihiro Ohba _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 5 16:59:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28495; Tue, 5 Aug 2003 16:59:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8tZ-00007P-2d; Tue, 05 Aug 2003 16:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8tS-000074-Ar for dhcwg@optimus.ietf.org; Tue, 05 Aug 2003 16:58:54 -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 QAA28483 for ; Tue, 5 Aug 2003 16:58:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8tQ-0005rK-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 16:58:52 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19k8tO-0005rG-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 16:58:51 -0400 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h75KwItp018173; Tue, 5 Aug 2003 13:58:18 -0700 (PDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-27.cisco.com [10.82.240.27]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA01925; Tue, 5 Aug 2003 13:58:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20030805165226.02451f70@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Aug 2003 16:58:02 -0400 To: Yoshihiro Ohba From: John Schnizlein Subject: Re: [dhcwg] pana-bootstrap-rfc3118 Cc: Alper Yegin , dhcwg@ietf.org, Tschofenig Hannes , "'Dan.Forsberg@nokia.com'" In-Reply-To: <20030805205536.GB963@steelhead> References: <4.3.2.7.2.20030805144903.00b27790@wells.cisco.com> <4.3.2.7.2.20030730062737.04270d38@funnel.cisco.com> <4.3.2.7.2.20030805144903.00b27790@wells.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: , As I understand what was proposed, PANA would provide the keys necessary for DHCP authentication (message integrity) between the DHCP client and DHCP server. The complication is that this does nothing to protect the integrity of the relay-agent information options. To protect those options also, there must be some interaction between PANA components and the relay agent. Nobody has shown how this would work, and entanglements of multiple intermediate parties is known to be a complex problem in networking. John At 04:55 PM 8/5/2003, Yoshihiro Ohba wrote: >On Tue, Aug 05, 2003 at 03:04:15PM -0400, John Schnizlein wrote: > >> There is (at least) intolerable complexity in the cooperation of >> the DHCP relay agent, which does not participate in the client-server >> message authentication for which PANA proposes to provide keys. >> > >Could you elaborate more on the complexity? This is because I'm >interested in implementing the proposed scheme and I am viewing that >the complexity is acceptable and reasonable. > >Bootstrapping DHCP authentication from AAA is useful and needed where >PKI (via DNSSEC) is not available (and DNSSEC is not available in many >situations). I believe that pana-bootstrap-rfc3118 is a practical >solution and would like to see it becoming a WG item. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 5 17:16:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29091; Tue, 5 Aug 2003 17:16:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k9A2-0000w7-6f; Tue, 05 Aug 2003 17:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k99k-0000vm-48 for dhcwg@optimus.ietf.org; Tue, 05 Aug 2003 17:15:44 -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 RAA29056 for ; Tue, 5 Aug 2003 17:15:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k99h-0005yK-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 17:15:41 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 19k99g-0005yD-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 17:15:41 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id h75LFXVj009472; Wed, 6 Aug 2003 06:15:33 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id h75LFXWQ012364; Wed, 6 Aug 2003 06:15:33 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id GAA12363 ; Wed, 6 Aug 2003 06:15:33 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id GAA16762; Wed, 6 Aug 2003 06:15:33 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id GAA02022; Wed, 6 Aug 2003 06:15:32 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id h75LFW5H024106; Wed, 6 Aug 2003 06:15:32 +0900 (JST) Received: from localhost ([159.119.168.136]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HJ600BRW0DSI4@tsbpo1.po.toshiba.co.jp>; Wed, 6 Aug 2003 06:15:31 +0900 (JST) Date: Tue, 05 Aug 2003 14:25:29 -0700 From: Yoshihiro Ohba Subject: Re: [dhcwg] pana-bootstrap-rfc3118 In-reply-to: <4.3.2.7.2.20030805165226.02451f70@wells.cisco.com> To: John Schnizlein Cc: Yoshihiro Ohba , Alper Yegin , dhcwg@ietf.org, Tschofenig Hannes , "'Dan.Forsberg@nokia.com'" Message-id: <20030805212529.GA1604@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 42 References: <4.3.2.7.2.20030805144903.00b27790@wells.cisco.com> <4.3.2.7.2.20030730062737.04270d38@funnel.cisco.com> <4.3.2.7.2.20030805144903.00b27790@wells.cisco.com> <4.3.2.7.2.20030805165226.02451f70@wells.cisco.com> 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 Tue, Aug 05, 2003 at 04:58:02PM -0400, John Schnizlein wrote: > As I understand what was proposed, PANA would provide the keys > necessary for DHCP authentication (message integrity) between > the DHCP client and DHCP server. > > The complication is that this does nothing to protect the > integrity of the relay-agent information options. To protect > those options also, there must be some interaction between > PANA components and the relay agent. Nobody has shown how this > would work, and entanglements of multiple intermediate parties > is known to be a complex problem in networking. As Alper mentioned in the previous mail, draft-ietf-dhc-relay-agent-auth-01.txt can be used for securing the relay agent options and that seems to be enough. Why interaction between PANA components and the relay agent is needed for securing the relay agent options? I believe securing the relay agent options can be independent of PANA. Yoshihiro Ohba > > John > > At 04:55 PM 8/5/2003, Yoshihiro Ohba wrote: > >On Tue, Aug 05, 2003 at 03:04:15PM -0400, John Schnizlein wrote: > > > >> There is (at least) intolerable complexity in the cooperation of > >> the DHCP relay agent, which does not participate in the client-server > >> message authentication for which PANA proposes to provide keys. > >> > > > >Could you elaborate more on the complexity? This is because I'm > >interested in implementing the proposed scheme and I am viewing that > >the complexity is acceptable and reasonable. > > > >Bootstrapping DHCP authentication from AAA is useful and needed where > >PKI (via DNSSEC) is not available (and DNSSEC is not available in many > >situations). I believe that pana-bootstrap-rfc3118 is a practical > >solution and would like to see it becoming a WG item. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 5 17:59:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00040; Tue, 5 Aug 2003 17:59:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k9pd-0002F3-5u; Tue, 05 Aug 2003 17:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k9ov-0002Ek-79 for dhcwg@optimus.ietf.org; Tue, 05 Aug 2003 17:58: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 RAA00026 for ; Tue, 5 Aug 2003 17:58:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k9os-0006GL-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 17:58:14 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19k9or-0006GI-00 for dhcwg@ietf.org; Tue, 05 Aug 2003 17:58:14 -0400 Date: Tue, 05 Aug 2003 14:59:55 -0700 Subject: Re: [dhcwg] pana-bootstrap-rfc3118 From: Alper Yegin To: John Schnizlein CC: , Tschofenig Hannes , "'Dan.Forsberg@nokia.com'" Message-ID: In-Reply-To: <4.3.2.7.2.20030805144903.00b27790@wells.cisco.com> 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 Hi John, >> Before we produce the next rev of the draft, we'd like to fully understand >> what should go in. So, let's continue the discussions from where we left at >> the meeting. > > My impression was that the concerns about this draft went much deeper > than editing-in more text could repair. > > There is the issue that PANA does not have Security Area endorsement > to be a key-distribution protocol. PANA is not "a key distribution protocol", it does not carry keys. It carries EAP. A set of EAP methods are capable of deriving/distributing keys. There is an EAP key framework (draft-aboba-pppext-key-problem-07.tx ) that explains how the EAP SA keys (such as MSK) can be turned into some purpose-specific keys (TSKs). This is what IEEE 802.11i is already using. Creation of a DHCP SA from EAP SA is just another instance of this framework. > > There is an irony in that PANA, which was justified as different from > IEEE 802.1X by hosts having IP addresses first (not layer 2), is > proposed to operate before DHCP, which provides the IP address. Well, we discussed this at least couple of times by now. The relevant question is: Can PANA be used before the client has an IP address? The answer is yes. > > There is (at least) intolerable complexity in the cooperation of > the DHCP relay agent, which does not participate in the client-server > message authentication for which PANA proposes to provide keys. I don't understand where this intolerable complexity is coming from, I'll follow the other thread for this... > > I thought the consensus was that the WG not take on this work. ... yet. The decision was not to reject this work, but to consider it later. I think this was due to the on-going (or, just-started :) discussions and lack of eligible voters. How can that consensus call result be useful anyways, when there were only 7 people's hand raised when the chair asked who read the draft :) Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 6 03:24:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08361; Wed, 6 Aug 2003 03:24:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kIeP-00035Y-Uz; Wed, 06 Aug 2003 03:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kIeO-00035N-O2 for dhcwg@optimus.ietf.org; Wed, 06 Aug 2003 03:24:00 -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 DAA08342 for ; Wed, 6 Aug 2003 03:23:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kIeM-000189-00 for dhcwg@ietf.org; Wed, 06 Aug 2003 03:23:58 -0400 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 19kIeL-00017P-00 for dhcwg@ietf.org; Wed, 06 Aug 2003 03:23:57 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h767MnVI024842; Wed, 6 Aug 2003 09:22:50 +0200 (CEST) Received: from [10.1.1.109] (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 488EFBA8D8; Wed, 6 Aug 2003 09:00:44 +0200 (CEST) Date: Wed, 06 Aug 2003 09:22:49 +0200 From: Martin Stiemerling To: John Schnizlein , Alper Yegin Cc: dhcwg@ietf.org, Tschofenig Hannes , "'Dan.Forsberg@nokia.com'" Subject: Re: [dhcwg] pana-bootstrap-rfc3118 Message-ID: <941974.1060161769@[10.1.1.109]> In-Reply-To: <4.3.2.7.2.20030805144903.00b27790@wells.cisco.com> References: <4.3.2.7.2.20030730062737.04270d38@funnel.cisco.com> <4.3.2.7.2.20030805144903.00b27790@wells.cisco.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 --On Dienstag, 5. August 2003 15:04 -0400 John Schnizlein wrote: [...] | | I thought the consensus was that the WG not take on this work. The consensus was not to take the document as working group draft as this point of time, but to consider it later after a revision. Martin | | John | | | _______________________________________________ | dhcwg mailing list | dhcwg@ietf.org | https://www1.ietf.org/mailman/listinfo/dhcwg Martin Stiemerling NEC Network Laboratories _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 6 10:35:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18691; Wed, 6 Aug 2003 10:35:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPNV-0007zB-7K; Wed, 06 Aug 2003 10:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kPMv-0007yV-OQ for dhcwg@optimus.ietf.org; Wed, 06 Aug 2003 10:34:27 -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 KAA18627 for ; Wed, 6 Aug 2003 10:34:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kPMh-0003Fb-00 for dhcwg@ietf.org; Wed, 06 Aug 2003 10:34:11 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19kPMg-0003FE-00 for dhcwg@ietf.org; Wed, 06 Aug 2003 10:34:10 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h76EXauG027125; Wed, 6 Aug 2003 07:33:37 -0700 (PDT) Received: from mjs-xp.cisco.com ([161.44.65.152]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABH59763; Wed, 6 Aug 2003 10:33:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20030806090831.01c3fe98@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Aug 2003 10:34:16 -0400 To: Alper Yegin From: Mark Stapp Subject: Re: [dhcwg] pana-bootstrap-rfc3118 Cc: John Schnizlein , , Tschofenig Hannes , "'Dan.Forsberg@nokia.com'" In-Reply-To: References: <4.3.2.7.2.20030805144903.00b27790@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 02:59 PM 8/5/2003 -0700, Alper Yegin wrote: >Hi John, > > >> Before we produce the next rev of the draft, we'd like to fully understand > >> what should go in. So, let's continue the discussions from where we > left at > >> the meeting. > > > > My impression was that the concerns about this draft went much deeper > > than editing-in more text could repair. > > > > There is the issue that PANA does not have Security Area endorsement > > to be a key-distribution protocol. John's point about the pana charter is accurate. The ietf has not chartered pana to do key-distribution, nor has it ensured that the appropriate expert review will take place. If pana would like to go through a re-charter, expanding in this way, then that's a process that should take place explicitly, with the iesg, the security directorate, and the pana wg. That would give other groups confidence in pana-centric solutions. It's not appropriate for this expansion to take place implicitly. >PANA is not "a key distribution protocol", it does not carry keys. It >carries EAP. A set of EAP methods are capable of deriving/distributing keys. > >There is an EAP key framework (draft-aboba-pppext-key-problem-07.tx ) that >explains how the EAP SA keys (such as MSK) can be turned into some >purpose-specific keys (TSKs). This is what IEEE 802.11i is already using. >Creation of a DHCP SA from EAP SA is just another instance of this >framework. I'd like to see a draft describing the use of EAP to address the authentication and 3118 issues. This would allow dhcp to leverage any carrier of EAP, which would be much more attractive than tying dhcp to pana. If the EAP-based mechanism could be successfully and convincingly described, various EAP carriers could then propose more specific drafts detailing the use of their protocols within the broader framework. The pana-only draft puts the cart before the horse. The implication - intentional or otherwise - is that the only way to use EAP is to use pana. That is not correct. Since there are many millions of EAP-speakers who are also dhcp clients, a broad EAP-based approach would be more practical and more appropriate to standardization. I would expect us to consider something like 'to leverage the broad deployed base of EAP-capable clients' on any list of dhcp security or authentication requirements. I would not expect to find 'to leverage the world's pana speakers' on that list. It concerns me that the working group will expend security effort on the 'pana-only' approach, when all of the clients are speaking something else. I think that will distract us from the broader effort to make dhcp more secure in practical, deployable ways. And that needs to be the goal of work that the group invests time on, not making dhcp more secure in a world filled with pana speakers. Pana is sort of like esperanto - it's not that it might not work as well as the alternatives one day, and it's not that it doesn't have _any_ merit at all, but it's still entirely marginal. > > > > There is an irony in that PANA, which was justified as different from > > IEEE 802.1X by hosts having IP addresses first (not layer 2), is > > proposed to operate before DHCP, which provides the IP address. > >Well, we discussed this at least couple of times by now. The relevant >question is: Can PANA be used before the client has an IP address? The >answer is yes. But the rest of the world has sort of spoken up here, hasn't it? The fact that people in the ietf can make up more 'me too' EAP carriers doesn't change the situation in the field. > > > > There is (at least) intolerable complexity in the cooperation of > > the DHCP relay agent, which does not participate in the client-server > > message authentication for which PANA proposes to provide keys. > >I don't understand where this intolerable complexity is coming from, I'll >follow the other thread for this... This issue was raised during the wg meeting as well, I believe. What was in the draft that I read did not contain any details about this interaction, except that it would be best if all the dhcp relays were pana agents too. I didn't find that to be convincing. > > > > I thought the consensus was that the WG not take on this work. > >... yet. The decision was not to reject this work, but to consider it later. >I think this was due to the on-going (or, just-started :) discussions and >lack of eligible voters. How can that consensus call result be useful >anyways, when there were only 7 people's hand raised when the chair asked >who read the draft :) Well I read the draft, and if you can tell me why it's pana that I want, I'm all ears. And it's consensus, not a vote. If there isn't interest in a proposal, if there isn't consensus that a draft solves the problem it claims to solve, it goes away. If there were seven people who read the draft that I read, I didn't hear any advocates for it at the working group meeting, and I haven't seen any advocates for it on the list. -- Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 6 12:34:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23202; Wed, 6 Aug 2003 12:34:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kREe-0004tv-MA; Wed, 06 Aug 2003 12:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRE2-0004rw-K9 for dhcwg@optimus.ietf.org; Wed, 06 Aug 2003 12:33: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 MAA23181 for ; Wed, 6 Aug 2003 12:33:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRE1-0004KG-00 for dhcwg@ietf.org; Wed, 06 Aug 2003 12:33:21 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 19kRE0-0004KD-00 for dhcwg@ietf.org; Wed, 06 Aug 2003 12:33:20 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id h76GXBVj010182; Thu, 7 Aug 2003 01:33:11 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id h76GXB0j017020; Thu, 7 Aug 2003 01:33:11 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA17019 ; Thu, 7 Aug 2003 01:33:10 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA24914; Thu, 7 Aug 2003 01:33:10 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA03858; Thu, 7 Aug 2003 01:33:09 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id h76GX95H016606; Thu, 7 Aug 2003 01:33:09 +0900 (JST) Received: from localhost ([159.119.168.119]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HJ7005CGHZ5OP@tsbpo1.po.toshiba.co.jp>; Thu, 7 Aug 2003 01:33:08 +0900 (JST) Date: Wed, 06 Aug 2003 09:33:05 -0700 From: Yoshihiro Ohba Subject: Re: [dhcwg] pana-bootstrap-rfc3118 In-reply-to: <4.3.2.7.2.20030806090831.01c3fe98@goblet.cisco.com> To: Mark Stapp Cc: Alper Yegin , John Schnizlein , dhcwg@ietf.org, Tschofenig Hannes , "'Dan.Forsberg@nokia.com'" Message-id: <20030806163305.GB4418@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i X-Dispatcher: imput version 20030601(IM145) Lines: 122 References: <4.3.2.7.2.20030805144903.00b27790@wells.cisco.com> <4.3.2.7.2.20030806090831.01c3fe98@goblet.cisco.com> 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: , As you mentioned, PANA is not the only way to bootstrap a DHCP SA from an EAP SA. IEEE 802.1X could also be used in the same way if relay agents are co-located with IEEE 802.1X Authenticators. Then one constructive approach might be to work on "Bootstrapping RFC3118 Delayed authentication using EAP" (where s/PANA/EAP/), which can cover broader EAP usage models. Yoshihiro Ohba On Wed, Aug 06, 2003 at 10:34:16AM -0400, Mark Stapp wrote: > > At 02:59 PM 8/5/2003 -0700, Alper Yegin wrote: > >Hi John, > > > >>> Before we produce the next rev of the draft, we'd like to fully > >understand > >>> what should go in. So, let's continue the discussions from where we > >left at > >>> the meeting. > >> > >> My impression was that the concerns about this draft went much deeper > >> than editing-in more text could repair. > >> > >> There is the issue that PANA does not have Security Area endorsement > >> to be a key-distribution protocol. > > John's point about the pana charter is accurate. The ietf has not chartered > pana to do key-distribution, nor has it ensured that the appropriate expert > review will take place. If pana would like to go through a re-charter, > expanding in this way, then that's a process that should take place > explicitly, with the iesg, the security directorate, and the pana wg. That > would give other groups confidence in pana-centric solutions. It's not > appropriate for this expansion to take place implicitly. > > > >PANA is not "a key distribution protocol", it does not carry keys. It > >carries EAP. A set of EAP methods are capable of deriving/distributing > >keys. > > > >There is an EAP key framework (draft-aboba-pppext-key-problem-07.tx ) that > >explains how the EAP SA keys (such as MSK) can be turned into some > >purpose-specific keys (TSKs). This is what IEEE 802.11i is already using. > >Creation of a DHCP SA from EAP SA is just another instance of this > >framework. > > I'd like to see a draft describing the use of EAP to address the > authentication and 3118 issues. This would allow dhcp to leverage any > carrier of EAP, which would be much more attractive than tying dhcp to > pana. If the EAP-based mechanism could be successfully and convincingly > described, various EAP carriers could then propose more specific drafts > detailing the use of their protocols within the broader framework. The > pana-only draft puts the cart before the horse. The implication - > intentional or otherwise - is that the only way to use EAP is to use pana. > That is not correct. > > Since there are many millions of EAP-speakers who are also dhcp clients, a > broad EAP-based approach would be more practical and more appropriate to > standardization. I would expect us to consider something like 'to leverage > the broad deployed base of EAP-capable clients' on any list of dhcp > security or authentication requirements. I would not expect to find 'to > leverage the world's pana speakers' on that list. > > It concerns me that the working group will expend security effort on the > 'pana-only' approach, when all of the clients are speaking something else. > I think that will distract us from the broader effort to make dhcp more > secure in practical, deployable ways. And that needs to be the goal of work > that the group invests time on, not making dhcp more secure in a world > filled with pana speakers. Pana is sort of like esperanto - it's not that > it might not work as well as the alternatives one day, and it's not that it > doesn't have _any_ merit at all, but it's still entirely marginal. > > >> > >> There is an irony in that PANA, which was justified as different from > >> IEEE 802.1X by hosts having IP addresses first (not layer 2), is > >> proposed to operate before DHCP, which provides the IP address. > > > >Well, we discussed this at least couple of times by now. The relevant > >question is: Can PANA be used before the client has an IP address? The > >answer is yes. > > But the rest of the world has sort of spoken up here, hasn't it? The fact > that people in the ietf can make up more 'me too' EAP carriers doesn't > change the situation in the field. > > >> > >> There is (at least) intolerable complexity in the cooperation of > >> the DHCP relay agent, which does not participate in the client-server > >> message authentication for which PANA proposes to provide keys. > > > >I don't understand where this intolerable complexity is coming from, I'll > >follow the other thread for this... > > This issue was raised during the wg meeting as well, I believe. What was in > the draft that I read did not contain any details about this interaction, > except that it would be best if all the dhcp relays were pana agents too. I > didn't find that to be convincing. > > >> > >> I thought the consensus was that the WG not take on this work. > > > >... yet. The decision was not to reject this work, but to consider it > >later. > >I think this was due to the on-going (or, just-started :) discussions and > >lack of eligible voters. How can that consensus call result be useful > >anyways, when there were only 7 people's hand raised when the chair asked > >who read the draft :) > > Well I read the draft, and if you can tell me why it's pana that I want, > I'm all ears. And it's consensus, not a vote. If there isn't interest in a > proposal, if there isn't consensus that a draft solves the problem it > claims to solve, it goes away. If there were seven people who read the > draft that I read, I didn't hear any advocates for it at the working group > meeting, and I haven't seen any advocates for it on the list. > > -- Mark > > > _______________________________________________ > 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 Aug 6 14:41:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28969; Wed, 6 Aug 2003 14:41:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTDa-0003qK-AP; Wed, 06 Aug 2003 14:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTD5-0003ps-89 for dhcwg@optimus.ietf.org; Wed, 06 Aug 2003 14:40: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 OAA28932 for ; Wed, 6 Aug 2003 14:40:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTD2-0005f4-00 for dhcwg@ietf.org; Wed, 06 Aug 2003 14:40:28 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19kTD1-0005f0-00 for dhcwg@ietf.org; Wed, 06 Aug 2003 14:40:27 -0400 Date: Wed, 06 Aug 2003 11:42:13 -0700 Subject: Re: [dhcwg] pana-bootstrap-rfc3118 From: Alper Yegin To: Mark Stapp CC: John Schnizlein , , Tschofenig Hannes , "'Dan.Forsberg@nokia.com'" Message-ID: In-Reply-To: <4.3.2.7.2.20030806090831.01c3fe98@goblet.cisco.com> 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 >>> There is the issue that PANA does not have Security Area endorsement >>> to be a key-distribution protocol. > > John's point about the pana charter is accurate. The ietf has not chartered > pana to do key-distribution, nor has it ensured that the appropriate expert > review will take place. If pana would like to go through a re-charter, > expanding in this way, then that's a process that should take place > explicitly, with the iesg, the security directorate, and the pana wg. That > would give other groups confidence in pana-centric solutions. It's not > appropriate for this expansion to take place implicitly. Please see my response to John. The mechanisms behind your so-called key distribution are EAP methods and EAP keying framework. >> PANA is not "a key distribution protocol", it does not carry keys. It >> carries EAP. A set of EAP methods are capable of deriving/distributing keys. >> >> There is an EAP key framework (draft-aboba-pppext-key-problem-07.tx ) that >> explains how the EAP SA keys (such as MSK) can be turned into some >> purpose-specific keys (TSKs). This is what IEEE 802.11i is already using. >> Creation of a DHCP SA from EAP SA is just another instance of this >> framework. > > I'd like to see a draft describing the use of EAP to address the > authentication and 3118 issues. This would allow dhcp to leverage any > carrier of EAP, which would be much more attractive than tying dhcp to > pana. If the EAP-based mechanism could be successfully and convincingly > described, various EAP carriers could then propose more specific drafts > detailing the use of their protocols within the broader framework. The > pana-only draft puts the cart before the horse. The implication - > intentional or otherwise - is that the only way to use EAP is to use pana. > That is not correct. Well, our draft shows how this is done using PANA and EAP. It is not meant to prove this is the only way possible. Both relevant PANA details and EAP key derivation details are in the draft. As such, this is a complete solution. I don't see a problem with that. If you believe doing the same for 802.1X/PPP/IKEv2 is possible and beneficial, please write a draft and show us the same can be done there. This would be more productive. > > Since there are many millions of EAP-speakers who are also dhcp clients, a > broad EAP-based approach would be more practical and more appropriate to > standardization. I would expect us to consider something like 'to leverage > the broad deployed base of EAP-capable clients' on any list of dhcp > security or authentication requirements. I would not expect to find 'to > leverage the world's pana speakers' on that list. This doesn't seem to point any technical issues with the proposal. > It concerns me that the working group will expend security effort on the > 'pana-only' approach, when all of the clients are speaking something else. > I think that will distract us from the broader effort to make dhcp more > secure in practical, deployable ways. And that needs to be the goal of work > that the group invests time on, not making dhcp more secure in a world > filled with pana speakers. Pana is sort of like esperanto - it's not that > it might not work as well as the alternatives one day, and it's not that it > doesn't have _any_ merit at all, but it's still entirely marginal. A couple of things are confused here. We are showing how you can enable DHCP security by using PANA. This draft does not dictate the world to move away from whatever else they were doing for AAA. If they do, that'd be their choice, but not a requirement of this solution. > >>> >>> There is an irony in that PANA, which was justified as different from >>> IEEE 802.1X by hosts having IP addresses first (not layer 2), is >>> proposed to operate before DHCP, which provides the IP address. >> >> Well, we discussed this at least couple of times by now. The relevant >> question is: Can PANA be used before the client has an IP address? The >> answer is yes. > > But the rest of the world has sort of spoken up here, hasn't it? The fact > that people in the ietf can make up more 'me too' EAP carriers doesn't > change the situation in the field. I don't see the relevance of this to what we are discussing above. > >>> >>> There is (at least) intolerable complexity in the cooperation of >>> the DHCP relay agent, which does not participate in the client-server >>> message authentication for which PANA proposes to provide keys. >> >> I don't understand where this intolerable complexity is coming from, I'll >> follow the other thread for this... > > This issue was raised during the wg meeting as well, I believe. Saying a solution is complex is for-free. We are still waiting for an explanation why some said so. You don't seem to explain either. > What was in > the draft that I read did not contain any details about this interaction, > except that it would be best if all the dhcp relays were pana agents too. I > didn't find that to be convincing. What part is not convincing? Please see my first message on this thread. > >>> >>> I thought the consensus was that the WG not take on this work. >> >> ... yet. The decision was not to reject this work, but to consider it later. >> I think this was due to the on-going (or, just-started :) discussions and >> lack of eligible voters. How can that consensus call result be useful >> anyways, when there were only 7 people's hand raised when the chair asked >> who read the draft :) > > Well I read the draft, and if you can tell me why it's pana that I want, > I'm all ears. And it's consensus, not a vote. If there isn't interest in a > proposal, if there isn't consensus that a draft solves the problem it > claims to solve, it goes away. If there were seven people who read the > draft that I read, I didn't hear any advocates for it at the working group > meeting, and I haven't seen any advocates for it on the list. None of the things you mentioned in this message is about technical problems with our proposed solution. Do you see a technical problem with the solution, do you think it fails to solve the problem? Let's discuss them. On the other hand, the issue you are raising is more like why not do the same with other EAP transports. Well, please write a draft and we can talk about them too. Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 06:32:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06934; Fri, 8 Aug 2003 06:32:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l4XS-0006V3-5O; Fri, 08 Aug 2003 06:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l4X9-0006UW-5D for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 06:31: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 GAA06910 for ; Fri, 8 Aug 2003 06:31:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l4X5-0007cY-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 06:31:39 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19l4X4-0007cJ-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 06:31:38 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h78AV7pp021306; Fri, 8 Aug 2003 03:31:07 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn4-91.cisco.com [10.21.80.91]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABJ32466; Fri, 8 Aug 2003 06:31:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20030808062446.04333de0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Aug 2003 06:31:01 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt Cc: ot@cisco.com, dhcwg@ietf.org In-Reply-To: <200307242059.h6OKxKE02375@cichlid.adsl.duke.edu> 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: , At 04:59 PM 7/24/2003 -0400, Thomas Narten wrote: > > >I misread the above because "requesting router" is almost a proper > > >name for a type of router as used in this document. But when I just > > >read "intruder requesting router", it parses differently... That is > > >what prompted my comment. > > > So, is "malicious requesting router" OK? > >I think it's confusing, but the "fix" of defining "Requesting Router" >more formally and then using the capitalized term throughout may not >be ideal either. But you are using "requesting router" in the formal >sense in that sentence (and elsewhere in the document). > >Any other ideas? Here's the definition from the "Terminology" section: requesting router The router that acts as a DHCP client and is requesting prefix(es) to be assigned. Is the definition sufficiently formal? Would it help to capitalize "Requesting Router" here in the definition and throughout the doc? > > Ah ... the word "assigned" is probably misleading. "Configured" > > might be a better word. > >But again, where is the requirement that they have an address (other >than LL) be configured in order to use the prefix delegation option? >If this is _really_ a requirement, the document should be more clear >about that (and why). The link local addresses are sufficient because the requesting and delegating routers share a link. Would it help to restate that assumption (about a shared link): Because a requesting router and delegating routers are attached to the same link, they may be able to use IPsec with link-local addresses for authentication of DHCPv6 messages. > > We can probably replace the next sentence ("The details...") with: > > > The requesting and delegating routers use IPsec for authentication > > in the same way DHCPv6 servers and relay agents use IPsec as > > described in section 21.1 of the DHCPv6 specification. > >OK with me. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 06:59:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07436; Fri, 8 Aug 2003 06:59:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l4xZ-0007VS-3i; Fri, 08 Aug 2003 06:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l4wn-0007V4-FY for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 06:58: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 GAA07374 for ; Fri, 8 Aug 2003 06:58:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l4wj-0007jG-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 06:58:09 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 19l4wi-0007j7-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 06:58:08 -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 h78AvVc8152998; Fri, 8 Aug 2003 06:57:31 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-202-60.mts.ibm.com [9.65.202.60]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h78AvUB5194596; Fri, 8 Aug 2003 04:57:30 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h78AuCV06448; Fri, 8 Aug 2003 06:56:12 -0400 Message-Id: <200308081056.h78AuCV06448@cichlid.adsl.duke.edu> To: Ralph Droms cc: ot@cisco.com, dhcwg@ietf.org Subject: Re: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt In-Reply-To: Message from rdroms@cisco.com of "Fri, 08 Aug 2003 06:31:01 EDT." <4.3.2.7.2.20030808062446.04333de0@funnel.cisco.com> Date: Fri, 08 Aug 2003 06:56:12 -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: , > Is the definition sufficiently formal? Would it help to capitalize > "Requesting Router" here in the definition and throughout the doc? I think so. > The link local addresses are sufficient because the requesting and > delegating routers share a link. Would it help to restate that assumption > (about a shared link): > Because a requesting router and delegating routers are attached to the > same link, they may be able to use IPsec with link-local addresses for > authentication of DHCPv6 messages. This seems like an unreasonable requirement. I can see this being the case sometimes, but I would not expect it to be required and I don't believe the document ever makes this claim. I would assume that this option be used in all the same situations whenever DHC can be used (in terms of placement of client and server). Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 07:40:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08251; Fri, 8 Aug 2003 07:40:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l5bF-0000gB-JH; Fri, 08 Aug 2003 07:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l5aQ-0000eV-Fb for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 07:39:12 -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 HAA08244 for ; Fri, 8 Aug 2003 07:39:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l5aP-00009Q-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 07:39:09 -0400 Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx with esmtp (Exim 4.12) id 19l5aO-00009A-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 07:39:08 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h78BcSj3303714; Fri, 8 Aug 2003 07:38:29 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-202-60.mts.ibm.com [9.65.202.60]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h78BcQB5152026; Fri, 8 Aug 2003 05:38:26 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h78Bb7W06610; Fri, 8 Aug 2003 07:37:07 -0400 Message-Id: <200308081137.h78Bb7W06610@cichlid.adsl.duke.edu> To: cmonia@nishansystems.com, jtseng@nishansystems.com, kgibbons@nishansystems.com cc: dhcwg@ietf.org, "'David Black'" , "Elizabeth G. Rodriguez" Date: Fri, 08 Aug 2003 07:37:07 -0400 From: Thomas Narten Subject: [dhcwg] IESG comments on draft-ietf-dhc-isnsoption-08.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. The IESG discussed this document yesterday, and the following comments came up. Alex Zinin writes: > [iSNS] is listed as non-normative. How's that possible if the opinion > is supposedly specific for iSNS and doesn't make sense outside of iSNS > context, i.e., iSNS needs to exist for the option to make sense. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 07:44:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08338; Fri, 8 Aug 2003 07:44:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l5f7-0000rS-2Q; Fri, 08 Aug 2003 07:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l5f1-0000rH-JF for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 07:43:55 -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 HAA08327 for ; Fri, 8 Aug 2003 07:43:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l5f0-0000AT-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 07:43:54 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 19l5f0-0000AE-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 07:43:54 -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 h78BhDc8238806; Fri, 8 Aug 2003 07:43:13 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-202-60.mts.ibm.com [9.65.202.60]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h78Bh8B5067624; Fri, 8 Aug 2003 05:43:09 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h78Bfo706633; Fri, 8 Aug 2003 07:41:50 -0400 Message-Id: <200308081141.h78Bfo706633@cichlid.adsl.duke.edu> To: cmonia@nishansystems.com, jtseng@nishansystems.com, kgibbons@nishansystems.com cc: dhcwg@ietf.org, "'David Black'" , "Elizabeth G. Rodriguez" , Allison Mankin Date: Fri, 08 Aug 2003 07:41:49 -0400 From: Thomas Narten Subject: [dhcwg] IESG comments on draft-ietf-dhc-isnsoption-08.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: , [apologies for the earlier truncated note] Hi. The IESG discussed this document yesterday, and the following comments came up. Alex Zinin writes: > [iSNS] is listed as non-normative. How's that possible if the opinion > is supposedly specific for iSNS and doesn't make sense outside of iSNS > context, i.e., iSNS needs to exist for the option to make sense. "Steven M. Bellovin" writes: > Is 3118 mandatory-to-implement or not? I have a hard time > understanding why it should be optional. > What are the semantics if both "Main Mode" and "Aggressive Mode" have > the same value? "Transport Mode" and "Tunnel Mode"? If IKE/IPsec is > disabled, what security should be used? Any? None? > The IANA Considerations section is inadequate. First, it should state > what registry the option code should be taken from. Second, it should > state what what procedure (per 2434) should be used to assign new > values to the assorted bit fields in this option. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 10:40:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13620; Fri, 8 Aug 2003 10:40:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8PS-0007xw-0z; Fri, 08 Aug 2003 10:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8Ox-0007x9-I3 for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 10:39: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 KAA13607 for ; Fri, 8 Aug 2003 10:39:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8Ov-0001D9-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 10:39:29 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19l8Ou-0001D5-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 10:39:28 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Aug 2003 07:38:57 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h78Ecs7F009669; Fri, 8 Aug 2003 07:38:55 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.215]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABJ46852; Fri, 8 Aug 2003 10:38:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20030808103754.044698c8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Aug 2003 10:38:51 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt Cc: ot@cisco.com, dhcwg@ietf.org In-Reply-To: <200308081056.h78AuCV06448@cichlid.adsl.duke.edu> 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: , At 06:56 AM 8/8/2003 -0400, Thomas Narten wrote: > > Is the definition sufficiently formal? Would it help to capitalize > > "Requesting Router" here in the definition and throughout the doc? > >I think so. OK. > > The link local addresses are sufficient because the requesting and > > delegating routers share a link. Would it help to restate that assumption > > (about a shared link): > > > Because a requesting router and delegating routers are attached to the > > same link, they may be able to use IPsec with link-local addresses for > > authentication of DHCPv6 messages. > >This seems like an unreasonable requirement. What requirement does the "this" refer to? >I can see this being the >case sometimes, but I would not expect it to be required and I don't >believe the document ever makes this claim. I would assume that this >option be used in all the same situations whenever DHC can be used (in >terms of placement of client and server). > >Thomas > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 10:45:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13816; Fri, 8 Aug 2003 10:45:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8UI-0008HO-5t; Fri, 08 Aug 2003 10:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8U6-0008Gu-9X for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 10:44: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 KAA13801 for ; Fri, 8 Aug 2003 10:44:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8U3-0001FQ-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 10:44:47 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by ietf-mx with esmtp (Exim 4.12) id 19l8U3-0001En-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 10:44:47 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h78Ei8kh190190; Fri, 8 Aug 2003 10:44:08 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h78Ei6pQ050108; Fri, 8 Aug 2003 10:44:06 -0400 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 h78Ei36l011343; Fri, 8 Aug 2003 10:44:03 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.5/Submit) with ESMTP id h78Ei3cv011338; Fri, 8 Aug 2003 10:44:03 -0400 Message-Id: <200308081444.h78Ei3cv011338@rotala.raleigh.ibm.com> To: Ralph Droms cc: ot@cisco.com, dhcwg@ietf.org Subject: Re: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt In-Reply-To: Message from rdroms@cisco.com of "Fri, 08 Aug 2003 10:38:51 EDT." <4.3.2.7.2.20030808103754.044698c8@funnel.cisco.com> Date: Fri, 08 Aug 2003 10:44:03 -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: , > > > > > Because a requesting router and delegating routers are attached to the > > > same link, they may be able to use IPsec with link-local addresses for > > > authentication of DHCPv6 messages. > > > >This seems like an unreasonable requirement. > What requirement does the "this" refer to? That that requesting and delegating router must share a link. DHCP doesn't require that, and I don't recall the document ever saying or implying this for this option. > >I can see this being the > >case sometimes, but I would not expect it to be required and I don't > >believe the document ever makes this claim. I would assume that this > >option be used in all the same situations whenever DHC can be used (in > >terms of placement of client and server). Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 10:47:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13905; Fri, 8 Aug 2003 10:47:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8WC-0008Ny-Bk; Fri, 08 Aug 2003 10:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8Vu-0008Ni-IY for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 10:46: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 KAA13880 for ; Fri, 8 Aug 2003 10:46:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8Vs-0001GU-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 10:46:40 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19l8Vr-0001GA-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 10:46:39 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h78Ek6pp003416; Fri, 8 Aug 2003 07:46:07 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.215]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABJ47578; Fri, 8 Aug 2003 10:46:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20030808104500.043a2ed8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Aug 2003 10:46:04 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt Cc: ot@cisco.com, dhcwg@ietf.org In-Reply-To: <200308081056.h78AuCV06448@cichlid.adsl.duke.edu> 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: , BTW, the most recent version of this specification is draft-ietf-dhc-dhcpv6-opt-prefix-delegation-04.txt, published on June 6, 2003. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 10:58:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14204; Fri, 8 Aug 2003 10:58:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8gr-0000JP-Jw; Fri, 08 Aug 2003 10:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8gc-0000J0-E6 for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 10:57: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 KAA14185 for ; Fri, 8 Aug 2003 10:57:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8gZ-0001KF-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 10:57:44 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19l8gZ-0001KA-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 10:57:43 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 16:56:45 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h78Esufp017840; Fri, 8 Aug 2003 16:54:56 +0200 (MET DST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA28283; Fri, 8 Aug 2003 15:57:09 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Thomas Narten Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt References: <200308081444.h78Ei3cv011338@rotala.raleigh.ibm.com> From: Ole Troan Date: Fri, 08 Aug 2003 15:57:08 +0100 In-Reply-To: <200308081444.h78Ei3cv011338@rotala.raleigh.ibm.com> (Thomas Narten's message of "Fri, 08 Aug 2003 10:44:03 -0400") Message-ID: <7t5ptjg8aez.fsf@mrwint.cisco.com> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2.95 (usg-unix-v) 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: , Thomas, >> > > Because a requesting router and delegating routers are attached to the >> > > same link, they may be able to use IPsec with link-local addresses for >> > > authentication of DHCPv6 messages. >> > >> >This seems like an unreasonable requirement. > >> What requirement does the "this" refer to? > > That that requesting and delegating router must share a link. DHCP > doesn't require that, and I don't recall the document ever saying or > implying this for this option. you are correct that the document doesn't say that the requesting and delegating routers have to be on the same link. the issue one has to consider is with regards to whom is going to inject a route for the delegated prefix into the delegator's routing system. if the routers are directly connected the delegating router can inject a route on behalf of the requesting router. if you use a relay agent it becomes a bit more tricky. we didn't want to require a dynamic routing protocol between the requesting and delegating routers. one might use a relay but then this issue needs to be resolved, we've defined it out of scope for the document so far, are you all right with that? cheers, Ole _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 11:04:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14427; Fri, 8 Aug 2003 11:04:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8mf-0000Zl-TJ; Fri, 08 Aug 2003 11:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8ly-0000Xk-G6 for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 11:03: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 LAA14398 for ; Fri, 8 Aug 2003 11:03:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8lv-0001MY-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 11:03:16 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.101]) by ietf-mx with esmtp (Exim 4.12) id 19l8lv-0001MJ-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 11:03:15 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h78F2aKb072754; Fri, 8 Aug 2003 11:02:36 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h78F2YpQ043208; Fri, 8 Aug 2003 11:02:34 -0400 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 h78F2a6l011440; Fri, 8 Aug 2003 11:02:36 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.5/Submit) with ESMTP id h78F2aFh011436; Fri, 8 Aug 2003 11:02:36 -0400 Message-Id: <200308081502.h78F2aFh011436@rotala.raleigh.ibm.com> To: Ole Troan cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt In-Reply-To: Message from ot@cisco.com of "Fri, 08 Aug 2003 15:57:08 BST." <7t5ptjg8aez.fsf@mrwint.cisco.com> Date: Fri, 08 Aug 2003 11:02:36 -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: , > you are correct that the document doesn't say that the requesting and > delegating routers have to be on the same link. I would assume that making such a requirement would be not appropriate, because it would effectively restrict DHC itself... > the issue one has to consider is with regards to whom is going to > inject a route for the delegated prefix into the delegator's routing > system. if the routers are directly connected the delegating router > can inject a route on behalf of the requesting router. if you use a > relay agent it becomes a bit more tricky. we didn't want to require a > dynamic routing protocol between the requesting and delegating > routers. Can we be silent on the issue? It might in general be easier to get routes injected properly if the two routers share the same link. But there are other ways of doing this. Since this document doesn't in general even say anything about route injection, saying little or nothing on this seems OK to me. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 11:20:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14812; Fri, 8 Aug 2003 11:20:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l929-0001QZ-LP; Fri, 08 Aug 2003 11:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l91L-0001IB-2a for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 11:19:11 -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 LAA14764 for ; Fri, 8 Aug 2003 11:19:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l91K-0001RX-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 11:19:10 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19l91J-0001RG-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 11:19:09 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 17:18:12 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h78FGO5e022508; Fri, 8 Aug 2003 17:16:25 +0200 (MET DST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA29241; Fri, 8 Aug 2003 16:18:37 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Thomas Narten Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt References: <200308081502.h78F2aFh011436@rotala.raleigh.ibm.com> From: Ole Troan Date: Fri, 08 Aug 2003 16:18:37 +0100 In-Reply-To: <200308081502.h78F2aFh011436@rotala.raleigh.ibm.com> (Thomas Narten's message of "Fri, 08 Aug 2003 11:02:36 -0400") Message-ID: <7t5d6fg89f6.fsf@mrwint.cisco.com> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2.95 (usg-unix-v) 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: , Thomas, >> you are correct that the document doesn't say that the requesting and >> delegating routers have to be on the same link. > > I would assume that making such a requirement would be not > appropriate, because it would effectively restrict DHC itself... it would certainly make these options more of a special case than fit nicely into the DHCP model as they do now. >> the issue one has to consider is with regards to whom is going to >> inject a route for the delegated prefix into the delegator's routing >> system. if the routers are directly connected the delegating router >> can inject a route on behalf of the requesting router. if you use a >> relay agent it becomes a bit more tricky. we didn't want to require a >> dynamic routing protocol between the requesting and delegating >> routers. > > Can we be silent on the issue? It might in general be easier to get > routes injected properly if the two routers share the same link. But > there are other ways of doing this. Since this document doesn't in > general even say anything about route injection, saying little or > nothing on this seems OK to me. agree, there are as you say many ways of doing route injection, and exploring them all in detail doesn't seem feasible for this document. two options, either we remove the below paragraph altogether, and if ever DHCP with IPsec gets defined elsewhere that would also apply to these options, or we change the paragraph to say that if the requesting and delegated routers have configured addresses or are directly connected then IPsec may be used. Because a requesting router and delegating routers must each have at least one assigned IPv6 address, the routers may be able to use IPsec for authentication of DHCPv6 messages. The details of using IPsec for DHCPv6 are under development. cheers, Ole _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 11:27:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15097; Fri, 8 Aug 2003 11:27:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l98v-0001iA-Kz; Fri, 08 Aug 2003 11:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l98k-0001hs-N5 for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 11:26: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 LAA15074 for ; Fri, 8 Aug 2003 11:26:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l98i-0001V6-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 11:26:48 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx with esmtp (Exim 4.12) id 19l98h-0001Ui-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 11:26:47 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h78FQ74X214574; Fri, 8 Aug 2003 11:26:07 -0400 Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h78FQ6pQ042378; Fri, 8 Aug 2003 11:26:06 -0400 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 h78FQ76l011540; Fri, 8 Aug 2003 11:26:07 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.8/8.12.5/Submit) with ESMTP id h78FQ711011535; Fri, 8 Aug 2003 11:26:07 -0400 Message-Id: <200308081526.h78FQ711011535@rotala.raleigh.ibm.com> To: Ole Troan cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt In-Reply-To: Message from ot@cisco.com of "Fri, 08 Aug 2003 16:18:37 BST." <7t5d6fg89f6.fsf@mrwint.cisco.com> Date: Fri, 08 Aug 2003 11:26:07 -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: , > two options, either we remove the below paragraph altogether, and if > ever DHCP with IPsec gets defined elsewhere that would also apply to > these options, or we change the paragraph to say that if the > requesting and delegated routers have configured addresses or are > directly connected then IPsec may be used. IPsec can be used whenever the two nodes have addresses and can set up an SA between each . I don't see why one needs to mention anything beyond that (e.g, saying directly connected) > Because a requesting router and delegating routers must each have > at least one assigned IPv6 address, the routers may be able to use > IPsec for authentication of DHCPv6 messages. The details of using > IPsec for DHCPv6 are under development. I'm OK with the "may". But (as I thought I'd mentioned before), the words "because a RR and DR must each have at least one assigned IPv6 address" make me nervous because I'm not sure what is meant (or if something is meant that I don't think is correct). If they mean addresses other than LL, that is not a requirement. Presumably this option can be used when booting and obtaining addresses, i.e., as DHC is intended to be used. Can you say something like: If the requesting router and delegating routers have addresses configured that allow them to communicate directly with each other, they may be able to use IPsec for authentication of DHCPv6 messages. The details of using IPsec for DHCPv6 are under development. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 8 11:46:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15653; Fri, 8 Aug 2003 11:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l9RJ-0002o3-C5; Fri, 08 Aug 2003 11:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l9Qs-0002ni-Or for dhcwg@optimus.ietf.org; Fri, 08 Aug 2003 11:45: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 LAA15602 for ; Fri, 8 Aug 2003 11:45:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l9Qr-0001cx-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 11:45:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19l9Qq-0001cu-00 for dhcwg@ietf.org; Fri, 08 Aug 2003 11:45:33 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 08 Aug 2003 17:44:35 +0200 Received: from cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h78Fgm4o026850; Fri, 8 Aug 2003 17:42:48 +0200 (MET DST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA00212; Fri, 8 Aug 2003 16:44:59 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Thomas Narten Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] Re: AD review of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt References: <200308081526.h78FQ711011535@rotala.raleigh.ibm.com> From: Ole Troan Date: Fri, 08 Aug 2003 16:44:59 +0100 In-Reply-To: <200308081526.h78FQ711011535@rotala.raleigh.ibm.com> (Thomas Narten's message of "Fri, 08 Aug 2003 11:26:07 -0400") Message-ID: <7t58yq48878.fsf@mrwint.cisco.com> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2.95 (usg-unix-v) 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: , Thomas, >> two options, either we remove the below paragraph altogether, and if >> ever DHCP with IPsec gets defined elsewhere that would also apply to >> these options, or we change the paragraph to say that if the >> requesting and delegated routers have configured addresses or are >> directly connected then IPsec may be used. > > IPsec can be used whenever the two nodes have addresses and can set > up an SA between each . I don't see why one needs to mention anything > beyond that (e.g, saying directly connected) agree. >> Because a requesting router and delegating routers must each have >> at least one assigned IPv6 address, the routers may be able to use >> IPsec for authentication of DHCPv6 messages. The details of using >> IPsec for DHCPv6 are under development. > > I'm OK with the "may". But (as I thought I'd mentioned before), the > words "because a RR and DR must each have at least one assigned IPv6 > address" make me nervous because I'm not sure what is meant (or if > something is meant that I don't think is correct). just trying to say what you've so eloquently said below. > If they mean addresses other than LL, that is not a > requirement. Presumably this option can be used when booting and > obtaining addresses, i.e., as DHC is intended to be used. > > Can you say something like: > > If the requesting router and delegating routers have addresses > configured that allow them to communicate directly with each > other, they may be able to use IPsec for authentication of DHCPv6 > messages. The details of using IPsec for DHCPv6 are under > development. yes, well put. cheers, Ole _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Aug 10 17:39:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16610; Sun, 10 Aug 2003 17:39:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lxu0-0007jd-U8; Sun, 10 Aug 2003 17:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQbY-00037h-QZ for dhcwg@optimus.ietf.org; Wed, 06 Aug 2003 11: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 LAA22104 for ; Wed, 6 Aug 2003 11:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQbX-00044D-00 for dhcwg@ietf.org; Wed, 06 Aug 2003 11:53:35 -0400 Received: from dns1nwc.networkscity.com ([63.237.8.2] helo=dns1nwc) by ietf-mx with esmtp (Exim 4.12) id 19kQbW-00044A-00 for dhcwg@ietf.org; Wed, 06 Aug 2003 11:53:34 -0400 Received: from M1 [63.237.8.53] by dns1nwc (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.3.6)); Wed, 6 Aug 2003 11:53:56 -0400 Reply-To: From: "Jeff Manis" To: Date: Wed, 6 Aug 2003 11:53:21 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Multiple DHCP Servers 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 For redundancy purposes is it possible to have multiple DHCP Servers handing out the same scope of addresses or do I have to give each server it's own fractional portion of the scope? A link to unusual tricks and usage of DHCP would be appreciated. Thank you, Jeff Manis _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Aug 10 17:42:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16690; Sun, 10 Aug 2003 17:42:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lxwv-0007qg-EH; Sun, 10 Aug 2003 17:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ltTv-0000AE-DL for dhcwg@optimus.ietf.org; Sun, 10 Aug 2003 12:55: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 MAA11084 for ; Sun, 10 Aug 2003 12:55:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ltTt-0000S9-00 for dhcwg@ietf.org; Sun, 10 Aug 2003 12:55:45 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19ltTs-0000S5-00 for dhcwg@ietf.org; Sun, 10 Aug 2003 12:55:45 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h7AGQHm12160 for ; Sun, 10 Aug 2003 09:26:18 -0700 Date: Sun, 10 Aug 2003 09:26:17 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] DNAv4 Issues List 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: , In order to capture issues relating to the Detection of Network Attachment for IPv4 (DNAv4) specification, I've created an Issues List web page at: http://www.drizzle.com/~aboba/DNA/dnaissues.html This web page includes a pointer to the latest version of the document. Comments welcome. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 13 08:25:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17153; Wed, 13 Aug 2003 08:25:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mugX-0004rN-Is; Wed, 13 Aug 2003 08:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mug5-0004qP-GA for dhcwg@optimus.ietf.org; Wed, 13 Aug 2003 08:24:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17079; Wed, 13 Aug 2003 08:24:29 -0400 (EDT) Message-Id: <200308131224.IAA17079@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, 13 Aug 2003 08:24:28 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-06.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-06.txt Pages : 10 Date : 2003-8-12 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 directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-06.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-06.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-06.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-8-12141311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-unused-optioncodes-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-unused-optioncodes-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-12141311.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 13 08:49:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18024; Wed, 13 Aug 2003 08:49:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mv3m-0005nt-5i; Wed, 13 Aug 2003 08:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mv3d-0005nZ-Lg for dhcwg@optimus.ietf.org; Wed, 13 Aug 2003 08:48:53 -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 IAA17965 for ; Wed, 13 Aug 2003 08:48:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mv3c-000133-00 for dhcwg@ietf.org; Wed, 13 Aug 2003 08:48:52 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19mv3a-00012y-00 for dhcwg@ietf.org; Wed, 13 Aug 2003 08:48:50 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 331A4206609 for ; Wed, 13 Aug 2003 08:47:18 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19mugD-0007mU-Il for ietf-announce-list@asgard.ietf.org; Wed, 13 Aug 2003 08:24:41 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19mug4-0007kt-RL for all-ietf@asgard.ietf.org; Wed, 13 Aug 2003 08:24:32 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17079; Wed, 13 Aug 2003 08:24:29 -0400 (EDT) Message-Id: <200308131224.IAA17079@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Wed, 13 Aug 2003 08:24:28 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+49230_666479340111047_1759642409" Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-06.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --MIMEStream=_0+49230_666479340111047_1759642409 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-06.txt Pages : 10 Date : 2003-8-12 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 directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-06.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-06.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-06.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. --MIMEStream=_0+49230_666479340111047_1759642409 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+139770_40071995411955_2034185526" --MIMEStream=_1+139770_40071995411955_2034185526 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-12141311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-unused-optioncodes-06.txt --MIMEStream=_1+139770_40071995411955_2034185526 Content-Type: Message/External-body; name="draft-ietf-dhc-unused-optioncodes-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-12141311.I-D@ietf.org> --MIMEStream=_1+139770_40071995411955_2034185526-- --MIMEStream=_0+49230_666479340111047_1759642409-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 14 10:28:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12090; Thu, 14 Aug 2003 10:28:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJ57-0004y0-Oy; Thu, 14 Aug 2003 10:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJ4s-0004x6-04 for dhcwg@optimus.ietf.org; Thu, 14 Aug 2003 10:27:46 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11995; Thu, 14 Aug 2003 10:27:40 -0400 (EDT) Message-Id: <200308141427.KAA11995@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, 14 Aug 2003 10:27:40 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-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 : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-00.txt Pages : 13 Date : 2003-8-14 This specification attempts to synthesize experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link- Local addresses. Given this experience, this document suggests optimizations for detection of network attachment in IPv4 as well as heuristics for determining when assignment of an IPv4 Link-Local address is appropriate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-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-dna-ipv4-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-dna-ipv4-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-8-14092229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-14092229.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 Aug 14 10:51:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13847; Thu, 14 Aug 2003 10:51:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJRN-0006Ir-Ou; Thu, 14 Aug 2003 10:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJRE-0006IO-Dk for dhcwg@optimus.ietf.org; Thu, 14 Aug 2003 10:50:52 -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 KAA13789 for ; Thu, 14 Aug 2003 10:50:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nJRB-00036n-00 for dhcwg@ietf.org; Thu, 14 Aug 2003 10:50:50 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19nJRB-00036k-00 for dhcwg@ietf.org; Thu, 14 Aug 2003 10:50:49 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 2948F206609 for ; Thu, 14 Aug 2003 10:49:15 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19nJ9W-0006v7-Oq for ietf-announce-list@asgard.ietf.org; Thu, 14 Aug 2003 10:32:34 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19nJ4q-0006rP-BL for all-ietf@asgard.ietf.org; Thu, 14 Aug 2003 10:27:44 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11995; Thu, 14 Aug 2003 10:27:40 -0400 (EDT) Message-Id: <200308141427.KAA11995@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Thu, 14 Aug 2003 10:27:40 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+272965_2090226851623_60850080412" Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --MIMEStream=_0+272965_2090226851623_60850080412 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 : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-00.txt Pages : 13 Date : 2003-8-14 This specification attempts to synthesize experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link- Local addresses. Given this experience, this document suggests optimizations for detection of network attachment in IPv4 as well as heuristics for determining when assignment of an IPv4 Link-Local address is appropriate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-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-dna-ipv4-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-dna-ipv4-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. --MIMEStream=_0+272965_2090226851623_60850080412 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+293325_5718115796790_50198556842" --MIMEStream=_1+293325_5718115796790_50198556842 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-14092229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-00.txt --MIMEStream=_1+293325_5718115796790_50198556842 Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-14092229.I-D@ietf.org> --MIMEStream=_1+293325_5718115796790_50198556842-- --MIMEStream=_0+272965_2090226851623_60850080412-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 19 20:07:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17029; Tue, 19 Aug 2003 20:07:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUG-0001vh-RS; Tue, 19 Aug 2003 20:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pF6u-0007jS-4J for dhcwg@optimus.ietf.org; Tue, 19 Aug 2003 18:37:52 -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 SAA13565 for ; Tue, 19 Aug 2003 18:37:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pF6r-000161-00 for dhcwg@ietf.org; Tue, 19 Aug 2003 18:37:49 -0400 Received: from ultrex.nishansystems.com ([12.36.127.195] helo=ariel.nishansystems.com) by ietf-mx with esmtp (Exim 4.12) id 19pF6q-00015q-00 for dhcwg@ietf.org; Tue, 19 Aug 2003 18:37:48 -0400 Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Aug 2003 15:37:09 -0700 Message-ID: From: Charles Monia To: "Thomas Narten (E-mail)" Cc: "DHCP (E-mail)" , "Ips (E-mail)" , "David Black (E-mail)" , "Elizabeth Rodriguez (E-mail)" , "Allison Mankin (E-mail)" , Charles Monia , Joshua Tseng , Kevin Gibbons Date: Tue, 19 Aug 2003 15:37:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoption-08.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: Please see responses embedded below. Charles > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Friday, August 08, 2003 4:42 AM > To: cmonia@nishansystems.com; jtseng@nishansystems.com; > kgibbons@nishansystems.com > Cc: dhcwg@ietf.org; 'David Black'; Elizabeth G. Rodriguez; Allison > Mankin > Subject: IESG comments on draft-ietf-dhc-isnsoption-08.txt > > > [apologies for the earlier truncated note] > > Hi. > > The IESG discussed this document yesterday, and the following comments > came up. > > Alex Zinin writes: > > > [iSNS] is listed as non-normative. How's that possible if > the opinion > > is supposedly specific for iSNS and doesn't make sense > outside of iSNS > > context, i.e., iSNS needs to exist for the option to make sense. > We will change the spec as noted in the comment. > "Steven M. Bellovin" writes: > Is 3118 mandatory-to-implement or not? I have a hard time > understanding why it should be optional. We will revise the spec to make implementation of RFC 3118 mandatory. > What are the semantics if both "Main Mode" and "Aggressive Mode" have > the same value? "Transport Mode" and "Tunnel Mode"? If IKE/IPsec is > disabled, what security should be used? Any? None? > > The following text is proposed for insertion at the end of section 2.4: "If IKE/IPSec is disabled, this indicates that the Internet Key Exchange (IKE) Protocol is not available to configure IPSec keys for iSNS sessions to this iSNS server. It does not necessarily preclude other key exchange methods (e.g., manual keying) from establishing an IPSec security association for the iSNS session." If IKE/IPsec is enabled, only one of Main Mode or Aggressive Mode SHALL be enabled. Similarly, only one of Transport Mode or Tunnel Mode SHALL be enabled. > > The IANA Considerations section is inadequate. First, it > should state > > what registry the option code should be taken from. > Second, it should > > state what what procedure (per 2434) should be used to assign new > > values to the assorted bit fields in this option. > The following replacement text is proposed for this section: "IANA is requested to assign a number for this option is accordance with the policy defined in [DHCP]. "New values for other numeric and bit fields in this document SHALL only be defined in an RFC which supercedes this specification." -- 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 Wed Aug 20 16:44:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09437; Wed, 20 Aug 2003 16:44:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pZoI-0004BQ-7T; Wed, 20 Aug 2003 16:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pZoF-0004Ax-CD for dhcwg@optimus.ietf.org; Wed, 20 Aug 2003 16:43:59 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09236 for ; Wed, 20 Aug 2003 16:43:52 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19pZlh-0002Hk-JK; Wed, 20 Aug 2003 16:41:21 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Wed, 20 Aug 2003 16:41:21 -0400 Subject: [dhcwg] Document Action: 'Unused DHCP Option Codes' to Informational RFC 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 approved the Internet-Draft 'Unused DHCP Option Codes' as an Informational RFC. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 20 17:07:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11370; Wed, 20 Aug 2003 17:07:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19paAW-0005MK-Hj; Wed, 20 Aug 2003 17:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19paAS-0005LV-Ln for dhcwg@optimus.ietf.org; Wed, 20 Aug 2003 17:06: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 RAA11337 for ; Wed, 20 Aug 2003 17:06:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19paAQ-0000Ao-00 for dhcwg@ietf.org; Wed, 20 Aug 2003 17:06:54 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19paAP-0000Ai-00 for dhcwg@ietf.org; Wed, 20 Aug 2003 17:06:53 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 4E879206608 for ; Wed, 20 Aug 2003 17:02:59 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19pZoE-0002gu-A1 for ietf-announce-list@asgard.ietf.org; Wed, 20 Aug 2003 16:43:58 -0400 Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19pZlh-0002Hk-JK; Wed, 20 Aug 2003 16:41:21 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce: ; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Wed, 20 Aug 2003 16:41:21 -0400 Precedence: bulk MIME-Version: 1.0 Subject: [dhcwg] Document Action: 'Unused DHCP Option Codes' to Informational RFC Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'Unused DHCP Option Codes' as an Informational RFC. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 22 07:21:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17587; Fri, 22 Aug 2003 07:21:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q9yW-0005PZ-Bv; Fri, 22 Aug 2003 07:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mtcj-0002aI-HV for dhcwg@optimus.ietf.org; Wed, 13 Aug 2003 07:17:01 -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 HAA15730 for ; Wed, 13 Aug 2003 07:16:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mtci-0000RC-00 for dhcwg@ietf.org; Wed, 13 Aug 2003 07:17:01 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19mtci-0000R9-00 for dhcwg@ietf.org; Wed, 13 Aug 2003 07:17:00 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7DBGxgM025963 for ; Wed, 13 Aug 2003 13:16:59 +0200 (MEST) Received: from ESEALNT444.al.sw.ericsson.se ([153.88.251.48]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id QXY8R6DC; Wed, 13 Aug 2003 13:17:02 +0200 Received: by esealnt444 with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Aug 2003 13:16:56 +0200 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 00000000 From: =?iso-8859-1?Q?Tony_Lindstr=F6m_=28HF/EAB=29?= To: "'dhcwg@ietf.org'" Date: Wed, 13 Aug 2003 13:16:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] Comment from "DHCPv6 Interoperability test in 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: , > Hi, > > During the test there was a discussion what options can exist as an encapsulated option. > > > I have understood that all the following options can be encapsulated in the IA_NA, IA_TA, IA_PD and IAADDR options: > > From draft DNS Configuration Options for DHCPv6 options DNS Resolvers and Domain List. > From draft NIS Configuration Options for DHCPv6 options NIS Servers, NISP Servers, NIS Domain List and NISP Domain List. > From draft Time Configuration Options for DHCPv6 options NTP Servers and Tome Zone > > A proposal is to introduce a new chapter or include in chapter 5 "Appearance of these options" in the three drafts mention above and specify if the option can be encapsulated or not. > I think a general sentence is the best solution: "The option can be encapsulated (by option like IAxxx)". > > > If you find this text confusing I have made an example to hopefully make it easier to understand: > > This is a configuration file including two links with two prefixs on each link: > ----------------------------------------------------------------------------------------------------------- > > option DNS_RESOLVERS 1080::10; > > link "LAN1" { > option DNS_RESOLVERS 1080::20; > > prefix 34fe::0/64 { > } > > prefix 35fe::0/64 { > option DNS_RESOLVERS 1080::30; > } > } > > link "LAN2" { > prefix 44fe::0/64 { > option DNS_RESOLVERS 1080::40; > } > > prefix 45fe::0/64 { > } > } > > > To send this to the client the IA_NA option will include four IAADDR options, > In the IAADDR with an address from prefix 34fe:: the option DNS_RESOLVERS 1080::20 will be included, > in the IAADDR with an address from prefix 35fe:: the option DNS_RESOLVERS 1080::30 will be included, > In the IAADDR with an address from prefix 44fe:: the option DNS_RESOLVERS 1080::40 will be included and > in the IAADDR with an address from prefix 45fe:: the option DNS_RESOLVERS 1080::10 will be included or use the option DNS_RESOLVERS 1080::10 which is included in IA_NA. > > When reading the draft "draft-ietf-dhc-dhcpv6-28.txt" at the end there is a table B, which indicate that only the option Status Code is allowed as an encuspulated option in IA_TA/IA_NA and IAADDR. That table need even to be reflected in other drafts (DNS, NIS Time etc.) . > > Best regards, Tony _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 25 05:35:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06465; Mon, 25 Aug 2003 05:35:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rDkc-0007nh-9D; Mon, 25 Aug 2003 05:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rDk1-0007mU-TA for dhcwg@optimus.ietf.org; Mon, 25 Aug 2003 05:34:26 -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 FAA06318 for ; Mon, 25 Aug 2003 05:34:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rDjy-00066e-00 for dhcwg@ietf.org; Mon, 25 Aug 2003 05:34:22 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19rDjx-00065w-00 for dhcwg@ietf.org; Mon, 25 Aug 2003 05:34:21 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 25 Aug 2003 02:34:01 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7P9Xw8s029136; Mon, 25 Aug 2003 02:33:58 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABU36405; Mon, 25 Aug 2003 05:33:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20030824024247.00ba8118@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 24 Aug 2003 08:54:16 -0400 To: Simon Vogl From: Ralph Droms Subject: Re: [dhcwg] URL option (again)? Cc: dhcwg@ietf.org In-Reply-To: References: <3F1F9306.4090504@soft.uni-linz.ac.at> <3F1F9306.4090504@soft.uni-linz.ac.at> 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: , I don't think any of the existing DHCp options really fit your intended application. Option 114 is unused (see draft-ietf-dhc-unused-optioncodes-06.txt). There are a couple of ways you could proceed. You could define a vendor-specific information option (option 43 in RFC 2132). You'll need to make up your own "vendor class identifier" (option 60) that the client can send to the server, and you'll only be able to use this option if the clients are not already using options 60 and 43. If the new option is to be used for experimentation at your site, you could use one of the site-specific option codes (128-254) and define your own option. If you eventually want to use the option outside your site, you can put the option through the IETF standards process to obtain an IANA-assigned option code. In either case, you'll need access to the client code on the host to add code that can interpret the contents of the vendor-specific info and a server that you can program to return the appropriate option(s) to the client. - Ralph Droms At 01:49 PM 7/24/2003 -0400, Thamer Al-Harbash wrote: >Hello all, >we are investigating location based services for >mobile devices that are connected to our campus network >(and thus the Internet) via WLAN. > >Our intention is to provide users with web-based information >depending on the area they reside in, while consuming as little >resources as possible, and withoud introducing new protocol stacks. > >I found a the document specifying the URL option (#114) but >it seems to be unused as well as too little flexible. > >The only other dhcp option that includes URLs is in the uap option >set (rfc2485) to pass the url of a login page, which is too specific >for our intentions. > >I would like to use an option that codes not only the url itself, but >also a string that identifies the service/application that should >be addressed. The latter lets us route information to different applications >on the mobile client and clarify the intentions/content of the passed >URL. > >URL data can be passed whenever the client asks for a new address, or >could be pushed asynchronously by the server using the reconfigure >extension (a la rfc3203). > >As I have not played around with dhcp implementations yet, I'd >like to know if this is seems feasible and a sound approach. > >Is there a option region reserved for experimental options so I can >start a test implementation without too many side effects? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 25 14:11:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06069; Mon, 25 Aug 2003 14:11:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLnP-0002VR-4P; Mon, 25 Aug 2003 14:10:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rKEM-0005n7-H3 for dhcwg@optimus.ietf.org; Mon, 25 Aug 2003 12:30:10 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26779; Mon, 25 Aug 2003 12:30:03 -0400 (EDT) Message-Id: <200308251630.MAA26779@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, 25 Aug 2003 12:30:03 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.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 : DNS Configuration Options for DHCPv6 Author(s) : R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt Pages : 8 Date : 2003-8-25 This document describes DHCPv6 options for passing a list of available DNS recursive name servers and a domain search list to a client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.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-8-25124029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124029.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 Aug 25 14:25:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07406; Mon, 25 Aug 2003 14:25:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rM1F-0004jm-R7; Mon, 25 Aug 2003 14:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rKvk-00072E-Gw for dhcwg@optimus.ietf.org; Mon, 25 Aug 2003 13:15:00 -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 NAA00764 for ; Mon, 25 Aug 2003 13:14:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rKvi-00043F-00 for dhcwg@ietf.org; Mon, 25 Aug 2003 13:14:58 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19rKvh-00042q-00 for dhcwg@ietf.org; Mon, 25 Aug 2003 13:14:58 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 78C94206612 for ; Mon, 25 Aug 2003 13:13:14 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19rKEZ-0004zw-03 for ietf-announce-list@asgard.ietf.org; Mon, 25 Aug 2003 12:30:23 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19rKEL-0004yK-Q7 for all-ietf@asgard.ietf.org; Mon, 25 Aug 2003 12:30:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26779; Mon, 25 Aug 2003 12:30:03 -0400 (EDT) Message-Id: <200308251630.MAA26779@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Mon, 25 Aug 2003 12:30:03 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+15262_8492878548659_061105235032" Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --MIMEStream=_0+15262_8492878548659_061105235032 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 : DNS Configuration Options for DHCPv6 Author(s) : R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt Pages : 8 Date : 2003-8-25 This document describes DHCPv6 options for passing a list of available DNS recursive name servers and a domain search list to a client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.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. --MIMEStream=_0+15262_8492878548659_061105235032 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+69417_6820496421778_15470404682" --MIMEStream=_1+69417_6820496421778_15470404682 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-25124029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt --MIMEStream=_1+69417_6820496421778_15470404682 Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-dnsconfig-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-25124029.I-D@ietf.org> --MIMEStream=_1+69417_6820496421778_15470404682-- --MIMEStream=_0+15262_8492878548659_061105235032-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 26 21:18:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00615; Tue, 26 Aug 2003 21:18:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rnIR-0006yX-EQ; Tue, 26 Aug 2003 19:32:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19riFs-0001j1-Jp for dhcwg@optimus.ietf.org; Tue, 26 Aug 2003 14:09:20 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17836 for ; Tue, 26 Aug 2003 14:09:15 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19riDq-0003Ph-Uu; Tue, 26 Aug 2003 14:07:14 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Tue, 26 Aug 2003 14:07:14 -0400 Subject: [dhcwg] Document Action **Revised**: 'Unused DHCP Option Codes' to Informational RFC 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 approved the Internet-Draft 'Unused DHCP Option Codes' as an Informational RFC. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 27 19:50:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19939; Wed, 27 Aug 2003 19:50:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4vt-00017p-7f; Wed, 27 Aug 2003 14:22:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ry8l-0006w6-B3 for dhcwg@optimus.ietf.org; Wed, 27 Aug 2003 07:07:03 -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 HAA16477 for ; Wed, 27 Aug 2003 07:06:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ry8h-0003NN-00 for dhcwg@ietf.org; Wed, 27 Aug 2003 07:06:59 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19ry8g-0003MX-00 for dhcwg@ietf.org; Wed, 27 Aug 2003 07:06:58 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7RB5sVr002977; Wed, 27 Aug 2003 04:05:54 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABW25170; Wed, 27 Aug 2003 07:05:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20030827060625.0464f580@localhost> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Aug 2003 06:09:21 -0400 To: Charles Monia From: Ralph Droms Subject: Re: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoption-08.txt Cc: "Thomas Narten (E-mail)" , "DHCP (E-mail)" , "Ips (E-mail)" , "David Black (E-mail)" , "Elizabeth Rodriguez (E-mail)" , "Allison Mankin (E-mail)" , Charles Monia , Joshua Tseng , Kevin Gibbons In-Reply-To: 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: , Note that, because there are no implementations of RFC 3118 today, and no plans by any important vendors to implement RFC 3118 in the future, making RFC 3118 authentication mandatory will effectively disallo any use of this option. Perhaps we can modify this requirement to something like "use of RFC 3118 is mandatory if it is available in the client and server". - Ralph At 03:37 PM 8/19/2003 -0700, Charles Monia wrote: > > "Steven M. Bellovin" writes: > > > Is 3118 mandatory-to-implement or not? I have a hard time > > understanding why it should be optional. > >We will revise the spec to make implementation of RFC 3118 mandatory. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 28 11:37:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24720; Thu, 28 Aug 2003 11:37:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sLUT-0004X1-KD; Thu, 28 Aug 2003 08:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKI2-0007S5-Lj for dhcwg@optimus.ietf.org; Thu, 28 Aug 2003 06:46: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 GAA28558 for ; Thu, 28 Aug 2003 06:45:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sKHy-0002px-00 for dhcwg@ietf.org; Thu, 28 Aug 2003 06:46:02 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19sKHx-0002pJ-00 for dhcwg@ietf.org; Thu, 28 Aug 2003 06:46:01 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 28 Aug 2003 03:55:43 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7SAjUba007855 for ; Thu, 28 Aug 2003 03:45:30 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABX24661; Thu, 28 Aug 2003 06:45:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20030828064105.00b99008@localhost> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Aug 2003 06:45:26 -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-subscriber-id-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 "DHCP Subscriber ID Suboption for the DHCP Relay Agent Option" . The last call will conclude on Friday, 9/12. 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-subscriber-id-01.txt defines a new DHCP Relay Suboption for passing a byte string representing a "Subscriber ID" from a relay agent to the DHCP server. The intended purpose of the subscriber ID is to give additional information which the DHCP server can use in address allocation. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 28 13:02:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00385; Thu, 28 Aug 2003 13:02:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sMZE-00007M-5z; Thu, 28 Aug 2003 09:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sL6p-0003ag-AD for dhcwg@optimus.ietf.org; Thu, 28 Aug 2003 07:38:35 -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 HAA03961 for ; Thu, 28 Aug 2003 07:38:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sL6o-0004Ed-00 for dhcwg@ietf.org; Thu, 28 Aug 2003 07:38:34 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19sL6n-0004Da-00 for dhcwg@ietf.org; Thu, 28 Aug 2003 07:38:33 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7SBc1Eh181408 for ; Thu, 28 Aug 2003 07:38:01 -0400 Received: from cichlid.adsl.duke.edu ([9.65.201.255]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h7SBc1xo367596 for ; Thu, 28 Aug 2003 05:38:01 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h7SBZxx17225 for ; Thu, 28 Aug 2003 07:36:06 -0400 Message-Id: <200308281136.h7SBZxx17225@cichlid.adsl.duke.edu> To: dhcwg@ietf.org Date: Thu, 28 Aug 2003 07:35:59 -0400 From: Thomas Narten Subject: [dhcwg] moving forward on draft-ietf-dhc-dhcpv6-opt-nisconfig-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 document went through IETF LC a few months back, and I'm looking at trying to resolve the LC comments and move forward. (Note: I've include Keith's and Ted's responses to the LC below). Thinking about these comments, I have the following question: Do folks have plans for implementing NIS over IPv6? I.e., how urgently is this needed, and if yes, shouldn't we also pop-up a level and make sure we solve the complete picture? I'm thinking in particular of IPv4 and RFC2937. Don't we also now need an IPv6 versoin of RFC 2937? If so, can we do that and pair the two documents together? Thomas From: Keith Moore To: iesg@ietf.org Cc: moore@cs.utk.edu, iesg-secretary@ietf.org, dhcwg@ietf.org Date: Wed, 14 May 2003 21:18:03 -0400 Subject: Re: Last Call: NIS Configuration Options for DHCPv6 to Proposed Standard I doubt that it's appropriate to bless this as standards-track. Informational would be okay. NIS is kind of a mess. it is neither secure nor robust. there are security problems related to using it to distribute password information, and it causes reliability problems for apps and hosts if not carefully set up and maintained. also, abliity to configure NIS seems fairly useless without also having the ability to configure which NIS services (maps) are used and which are ignored, and the relationship of NIS services to other ways of getting the same information. (e.g. the /etc/nsswitch.conf file or whatever it is on other systems) of course that facility is not specific to NIS, and so it doesn't belong in this document, but it seems like it would be an essential component of anything that was used to configure NIS. (or did I miss the DHCPv6 option that does this?) shouldn't there be at least informative references for NIS and NIS+? also unspecified: what's the interaction between this and the NIS binding discovery protocol? (forget what its called) has the use of that protocol over IPv6 ever been defined? From: Ted Lemon To: Keith Moore Cc: iesg@ietf.org, iesg-secretary@ietf.org, dhcwg@ietf.org Date: Thu, 15 May 2003 00:58:47 -0500 Subject: Re: [dhcwg] Re: Last Call: NIS Configuration Options for DHCPv6 to Proposed Standard > I doubt that it's appropriate to bless this as standards-track. > Informational would be okay. To be clear, this draft is about how to represent NIS+ server information in a DHCPv6 packet, in cases where the application wants to represent this information in this packet. It doesn't recommend that anybody use NIS+. The nsswitch.conf issue should be handled in a separate draft, similar to RFC2937. I don't think this needs to be mentioned in this draft - RFC2937 is about how to choose between different name service classes, not about any one name service class. There is no RFC documenting an NIS binding protocol that I've been able to find - do you have a reference for that? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 29 03:45:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23168; Fri, 29 Aug 2003 03:45:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sdVF-0003y6-Sx; Fri, 29 Aug 2003 03:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sd4P-0002eL-Om for dhcwg@optimus.ietf.org; Fri, 29 Aug 2003 02:49: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 CAA18418 for ; Fri, 29 Aug 2003 02:49:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sd4L-0002Wq-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 02:49:13 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19sd4J-0002Vm-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 02:49:13 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7T6mfCb026341 for ; Thu, 28 Aug 2003 23:48:41 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-133.cisco.com [10.82.224.133]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABY10927; Fri, 29 Aug 2003 02:48:40 -0400 (EDT) Message-Id: <4.3.2.7.2.20030828082336.021c2518@localhost> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Aug 2003 02:48:36 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] RE: WG last call on draft-ietf-dhc-subscriber-id-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: , Issues: 1) The motivation could for this option could be explained more completely. It comes from the observation that, in some scenarios, the relay agent supplying identification information like a circuit ID or remote ID may be in a different administrative domain from the DHCP servers that receive the relay agent option. When the administrator of the relay agent makes a change to the network configuration that changes the circuit ID or remote ID for the subscriber, the MSP must contact each of the administrators of the DHCP servers to update the corresponding entry in the DHCP servers. For example, in a managed service provider (MSP) deployment, the relay agent is in the administrative domain of the MSP while the ISPs using that MSP each control their own independent DHCP server. If the MSP changes the attachment point of a subscriber, the MSP must contact each of the ISPs with the new relay agent option information so that the ISPs can update their DHCP servers. The Subscriber ID suboption isolates changes in the network configuration to the administrative domain of the relay agent. That is, the administrator can change the network configuration and the subscriber ID information simultaneously, so the DHCP servers need not be updated with any new information about the subscriber. 2) The Abstract states that the data value in a Subscriber ID suboption "can be interpreted in any form by the DHCP server" and "its intended purpose is to give additional information which the DHCP server can use in address allocation". The Introduction then gives more detail in defining the contents of the suboption as a subscriber identifier, which seems to me to be a more specific definition than the one in the Abstract. it might be clearer to give the more precise definition in the Abstract, as well. Nits: The data in the Subscriber ID suboption is variously described as "an array of bytes" and a "configurable hexadecimal value". The description of the data would be clarified if a uniform describing phrase were used throughout the document. In the third paragraph of section 2, the last sentence should be changed to reflect that the subscriber ID can be considered in the assignment of other configuration parameters in addition to the assignment of an IP address. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 29 08:04:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15627; Fri, 29 Aug 2003 08:04:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sgU5-0007Pj-Hu; Fri, 29 Aug 2003 06:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19seXu-0008Vp-Jg for dhcwg@optimus.ietf.org; Fri, 29 Aug 2003 04:23: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 EAA26947 for ; Fri, 29 Aug 2003 04:23:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19seXr-0004lb-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 04:23:47 -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 19seXq-0004lY-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 04:23:46 -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 1827265; Fri, 29 Aug 2003 10:23:43 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-subscriber-id-01.txt> Date: Fri, 29 Aug 2003 10:25:51 +0200 User-Agent: KMail/1.4.3 References: <4.3.2.7.2.20030828064105.00b99008@localhost> In-Reply-To: <4.3.2.7.2.20030828064105.00b99008@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200308291025.51415.budm@weird-solutions.com> Content-Transfer-Encoding: quoted-printable 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: quoted-printable On Thursday 28 August 2003 12.45, Ralph Droms wrote: > This message announces a WG last call on "DHCP Subscriber ID Suboption = for > the DHCP Relay Agent Option" . Th= e > last call will conclude on Friday, 9/12. This documents says: The value is simply an array of bytes which can be interpreted by the DHCP server in whatever manner wanted. The value can be a character string giving the name of the subscriber, four bytes interpreted as a big endian unsigned integer giving the number of the subscriber, a string of hex digits giving the subscriber ID, or whatever is needed. The precise definition of the bytes is left to the implementation and field use. We would really like to see this suboption fixed to exactly one data type= =2E The=20 problem with allowing the subscriber id be a sequence of bytes or an asci= i=20 string is that when it comes time for us to report the subscriber id, say= in=20 a log file, we really have no idea how to display it correctly. We may en= d up=20 displaying it as a sequence of bytes, although it is (according to the=20 manufacturer's documentation) a printable string, or vice-versa. - 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 Fri Aug 29 12:15:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08923; Fri, 29 Aug 2003 12:15:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sl1B-0005Pv-Er; Fri, 29 Aug 2003 11:18:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sinD-0005pX-Vk for dhcwg@optimus.ietf.org; Fri, 29 Aug 2003 08:55:55 -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 IAA19837 for ; Fri, 29 Aug 2003 08:55:49 -0400 (EDT) From: rdroms@cisco.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sinC-0002UE-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 08:55:54 -0400 Received: from ool-18b877e5.dyn.optonline.net ([24.184.119.229] helo=ASFSAW680501B) by ietf-mx with esmtp (Exim 4.12) id 19sin9-0002U7-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 08:55:52 -0400 To: Date: Fri, 29 Aug 2003 8:55:35 --0400 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00225137" Message-Id: Subject: [dhcwg] Your details 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 multipart message in MIME format --_NextPart_000_00225137 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_00225137 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: application.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_00225137-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Aug 30 10:14:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14177; Sat, 30 Aug 2003 10:14:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t647-0006Kc-OU; Sat, 30 Aug 2003 09:46:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19smZm-0001LT-Eq for dhcwg@optimus.ietf.org; Fri, 29 Aug 2003 12:58: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 MAA13781 for ; Fri, 29 Aug 2003 12:58:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smZi-0001BS-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 12:58:14 -0400 Received: from smtp001.bizmail.yahoo.com ([216.136.172.125]) by ietf-mx with smtp (Exim 4.12) id 19smZh-0001BP-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 12:58:13 -0400 Received: from unknown (HELO EGRodriguez) (ieee@elizabethrodriguez.net@166.155.191.242 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 29 Aug 2003 16:58:06 -0000 From: "Elizabeth G. Rodriguez" To: "'Charles Monia'" , "'Ralph Droms'" , "'Steven Bellovin'" Cc: "'Thomas Narten \(E-mail\)'" , "'DHCP \(E-mail\)'" , "'Ips \(E-mail\)'" , "'David Black \(E-mail\)'" , "'Allison Mankin \(E-mail\)'" , "'Joshua Tseng'" , "'Kevin Gibbons'" Subject: RE: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoption-08.txt Date: Fri, 29 Aug 2003 09:56:01 -0700 Message-ID: <000201c36e4e$7a3cdf60$f2bf9ba6@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi all, I am struggling with the new wording here. I understand Ralph Droms' concerns, but not sure that this is the right solution. In addition, the current wording is mandating use, something = that in general we try to avoid in IETF documents. I have added Steve Bellovin to the distribution, and hope he will = comment on this proposed change -- he is the AD who questioned making RFC 3118 optional. If he is OK with the proposed change to keep RFC 3118 = optional, then I recommend changes to the effect of: 1) It is RECOMMENDED that RFC 3118 be implemented. =20 2) It is recommended that if RFC 3118 is available on both the client = and server, it be used. Elizabeth Rodriguez -----Original Message----- From: Charles Monia [mailto:cmonia@NishanSystems.com]=20 Sent: Thursday, August 28, 2003 4:31 PM To: 'Ralph Droms'; Charles Monia Cc: Thomas Narten (E-mail); DHCP (E-mail); Ips (E-mail); David Black (E-mail); Elizabeth Rodriguez (E-mail); Allison Mankin (E-mail); Charles Monia; Joshua Tseng; Kevin Gibbons Subject: RE: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoption-08.txt Hi: I have incorporated Ralph's suggestion in revision 9 of the spec, along with changes to reflect the other IESG comments. This new version has = been submitted to the IETF archive. Pending the announcement of document availability from the archive, the = spec can be obtained from ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-09.pdf or ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-09.txt. Markups visible in the PDF version show the text that was added or = deleted. Charles > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Wednesday, August 27, 2003 3:09 AM > To: Charles Monia > Cc: Thomas Narten (E-mail); DHCP (E-mail); Ips (E-mail);=20 > David Black (E-mail); Elizabeth Rodriguez (E-mail); Allison=20 > Mankin (E-mail); Charles Monia; Joshua Tseng; Kevin Gibbons > Subject: Re: [dhcwg] Response to IESG comments on=20 > draft-ietf-dhc-isnsoption-08.txt >=20 >=20 > Note that, because there are no implementations of RFC 3118=20 > today, and no=20 > plans by any important vendors to implement RFC 3118 in the=20 > future, making=20 > RFC 3118 authentication mandatory will effectively disallo=20 > any use of this=20 > option. >=20 > Perhaps we can modify this requirement to something like "use=20 > of RFC 3118=20 > is mandatory if it is available in the client and server". >=20 > - Ralph >=20 > At 03:37 PM 8/19/2003 -0700, Charles Monia wrote: >=20 > > > "Steven M. Bellovin" writes: > > > > > Is 3118 mandatory-to-implement or not? I have a hard time=20 > > > understanding why it should be optional. > > > >We will revise the spec to make implementation of RFC 3118 mandatory. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Aug 30 10:27:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14929; Sat, 30 Aug 2003 10:27:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t648-0006Km-7y; Sat, 30 Aug 2003 09:46:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sqeC-0004za-An for dhcwg@optimus.ietf.org; Fri, 29 Aug 2003 17:19:08 -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 RAA06192 for ; Fri, 29 Aug 2003 17:19:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sqe9-0007j2-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 17:19:05 -0400 Received: from ultrex.nishansystems.com ([12.36.127.195] helo=ariel.nishansystems.com) by ietf-mx with esmtp (Exim 4.12) id 19sqe8-0007fu-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 17:19:04 -0400 Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Aug 2003 14:18:22 -0700 Message-ID: From: Charles Monia To: "'Elizabeth G. Rodriguez'" , Charles Monia , "'Ralph Droms'" , "'Steven Bellovin'" Cc: "'Thomas Narten (E-mail)'" , "'DHCP (E-mail)'" , "'Ips (E-mail)'" , "'David Black (E-mail)'" , "'Allison Mankin (E-mail)'" , Joshua Tseng , Kevin Gibbons Subject: RE: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoptio n-08.txt Date: Fri, 29 Aug 2003 14:18:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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: , See embedded response. > -----Original Message----- > From: Elizabeth G. Rodriguez [mailto:ElizabethRodriguez@ieee.org] > Sent: Friday, August 29, 2003 9:56 AM > To: 'Charles Monia'; 'Ralph Droms'; 'Steven Bellovin' > Cc: 'Thomas Narten (E-mail)'; 'DHCP (E-mail)'; 'Ips > (E-mail)'; 'David Black (E-mail)'; 'Allison Mankin (E-mail)'; > 'Joshua Tseng'; 'Kevin Gibbons' > Subject: RE: [dhcwg] Response to IESG comments on > draft-ietf-dhc-isnsoption-08.txt > > > Hi all, > > I am struggling with the new wording here. > I understand Ralph Droms' concerns, but not sure that this is > the right solution. In addition, the current wording is > mandating use, something that in general we try to avoid in > IETF documents. > > I have added Steve Bellovin to the distribution, and hope he > will comment on this proposed change -- he is the AD who > questioned making RFC 3118 optional. If he is OK with the > proposed change to keep RFC 3118 optional, then I recommend > changes to the effect of: > > 1) It is RECOMMENDED that RFC 3118 be implemented. > > 2) It is recommended that if RFC 3118 is available on both > the client and server, it be used. > > Elizabeth Rodriguez > > Here's the original text from rev 08: =================================== [RFC3118] should be consulted to determine the requirements for additional security measures to authenticate 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 for iSNS server discovery, exposure to a "man-in-themiddle" 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. ====================== What's wrong with that? Charles _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Aug 30 10:27:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14985; Sat, 30 Aug 2003 10:27:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t647-0006KU-Ay; Sat, 30 Aug 2003 09:46:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19smZn-0001Lb-7q for dhcwg@optimus.ietf.org; Fri, 29 Aug 2003 12:58: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 MAA13780 for ; Fri, 29 Aug 2003 12:58:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smZH-0001Ab-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 12:57:47 -0400 Received: from smtp001.bizmail.yahoo.com ([216.136.172.125]) by ietf-mx with smtp (Exim 4.12) id 19smZG-0001AV-00 for dhcwg@ietf.org; Fri, 29 Aug 2003 12:57:46 -0400 Received: from unknown (HELO EGRodriguez) (ieee@elizabethrodriguez.net@166.155.191.242 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 29 Aug 2003 16:57:38 -0000 From: "Elizabeth G. Rodriguez" To: "'Charles Monia'" , "'Ralph Droms'" , "'Steven Bellovin'" Cc: "'Thomas Narten \(E-mail\)'" , "'DHCP \(E-mail\)'" , "'Ips \(E-mail\)'" , "'David Black \(E-mail\)'" , "'Allison Mankin \(E-mail\)'" , "'Joshua Tseng'" , "'Kevin Gibbons'" Subject: RE: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoption-08.txt Date: Fri, 29 Aug 2003 09:56:01 -0700 Message-ID: <000101c36e4e$77967780$f2bf9ba6@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Content-Transfer-Encoding: quoted-printable 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: quoted-printable Hi all, I am struggling with the new wording here. I understand Ralph Droms' concerns, but not sure that this is the right solution. In addition, the current wording is mandating use, something = that in general we try to avoid in IETF documents. I have added Steve Bellovin to the distribution, and hope he will = comment on this proposed change -- he is the AD who questioned making RFC 3118 optional. If he is OK with the proposed change to keep RFC 3118 = optional, then I recommend changes to the effect of: 1) It is RECOMMENDED that RFC 3118 be implemented. =20 2) It is recommended that if RFC 3118 is available on both the client = and server, it be used. Elizabeth Rodriguez -----Original Message----- From: Charles Monia [mailto:cmonia@NishanSystems.com]=20 Sent: Thursday, August 28, 2003 4:31 PM To: 'Ralph Droms'; Charles Monia Cc: Thomas Narten (E-mail); DHCP (E-mail); Ips (E-mail); David Black (E-mail); Elizabeth Rodriguez (E-mail); Allison Mankin (E-mail); Charles Monia; Joshua Tseng; Kevin Gibbons Subject: RE: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoption-08.txt Hi: I have incorporated Ralph's suggestion in revision 9 of the spec, along with changes to reflect the other IESG comments. This new version has = been submitted to the IETF archive. Pending the announcement of document availability from the archive, the = spec can be obtained from ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-09.pdf or ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-09.txt. Markups visible in the PDF version show the text that was added or = deleted. Charles > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Wednesday, August 27, 2003 3:09 AM > To: Charles Monia > Cc: Thomas Narten (E-mail); DHCP (E-mail); Ips (E-mail);=20 > David Black (E-mail); Elizabeth Rodriguez (E-mail); Allison=20 > Mankin (E-mail); Charles Monia; Joshua Tseng; Kevin Gibbons > Subject: Re: [dhcwg] Response to IESG comments on=20 > draft-ietf-dhc-isnsoption-08.txt >=20 >=20 > Note that, because there are no implementations of RFC 3118=20 > today, and no=20 > plans by any important vendors to implement RFC 3118 in the=20 > future, making=20 > RFC 3118 authentication mandatory will effectively disallo=20 > any use of this=20 > option. >=20 > Perhaps we can modify this requirement to something like "use=20 > of RFC 3118=20 > is mandatory if it is available in the client and server". >=20 > - Ralph >=20 > At 03:37 PM 8/19/2003 -0700, Charles Monia wrote: >=20 > > > "Steven M. Bellovin" writes: > > > > > Is 3118 mandatory-to-implement or not? I have a hard time=20 > > > understanding why it should be optional. > > > >We will revise the spec to make implementation of RFC 3118 mandatory. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Aug 30 10:31:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15189; Sat, 30 Aug 2003 10:31:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t646-0006KL-UI; Sat, 30 Aug 2003 09:46:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sWEa-0002dT-O9 for dhcwg@optimus.ietf.org; Thu, 28 Aug 2003 19:31: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 TAA29868 for ; Thu, 28 Aug 2003 19:31:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sWEZ-0001Rm-00 for dhcwg@ietf.org; Thu, 28 Aug 2003 19:31:19 -0400 Received: from ultrex.nishansystems.com ([12.36.127.195] helo=ariel.nishansystems.com) by ietf-mx with esmtp (Exim 4.12) id 19sWEY-0001RV-00 for dhcwg@ietf.org; Thu, 28 Aug 2003 19:31:18 -0400 Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 16:30:43 -0700 Message-ID: From: Charles Monia To: "'Ralph Droms'" , Charles Monia Cc: "Thomas Narten (E-mail)" , "DHCP (E-mail)" , "Ips (E-mail)" , "David Black (E-mail)" , "Elizabeth Rodriguez (E-mail)" , "Allison Mankin (E-mail)" , Charles Monia , Joshua Tseng , Kevin Gibbons Subject: RE: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoptio n-08.txt Date: Thu, 28 Aug 2003 16:30:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain 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 have incorporated Ralph's suggestion in revision 9 of the spec, along with changes to reflect the other IESG comments. This new version has been submitted to the IETF archive. Pending the announcement of document availability from the archive, the spec can be obtained from ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-09.pdf or ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-09.txt. Markups visible in the PDF version show the text that was added or deleted. Charles > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, August 27, 2003 3:09 AM > To: Charles Monia > Cc: Thomas Narten (E-mail); DHCP (E-mail); Ips (E-mail); > David Black (E-mail); Elizabeth Rodriguez (E-mail); Allison > Mankin (E-mail); Charles Monia; Joshua Tseng; Kevin Gibbons > Subject: Re: [dhcwg] Response to IESG comments on > draft-ietf-dhc-isnsoption-08.txt > > > Note that, because there are no implementations of RFC 3118 > today, and no > plans by any important vendors to implement RFC 3118 in the > future, making > RFC 3118 authentication mandatory will effectively disallo > any use of this > option. > > Perhaps we can modify this requirement to something like "use > of RFC 3118 > is mandatory if it is available in the client and server". > > - Ralph > > At 03:37 PM 8/19/2003 -0700, Charles Monia wrote: > > > > "Steven M. Bellovin" writes: > > > > > Is 3118 mandatory-to-implement or not? I have a hard time > > > understanding why it should be optional. > > > >We will revise the spec to make implementation of RFC 3118 mandatory. > > > > > > _______________________________________________ > 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 Sat Aug 30 15:28:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27748; Sat, 30 Aug 2003 15:28:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19tB22-0001xD-I7; Sat, 30 Aug 2003 15:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19tAbR-0001V8-Al for dhcwg@optimus.ietf.org; Sat, 30 Aug 2003 14:37:37 -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 OAA24764 for ; Sat, 30 Aug 2003 14:37:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19tAbO-0004XZ-00 for dhcwg@ietf.org; Sat, 30 Aug 2003 14:37:34 -0400 Received: from mailhost.packetfront.com ([192.121.165.2]) by ietf-mx with esmtp (Exim 4.12) id 19tAbN-0004XV-00 for dhcwg@ietf.org; Sat, 30 Aug 2003 14:37:33 -0400 Received: from brinstar.int.packetfront.com ([192.168.1.21] helo=packetfront.com) by mailhost.packetfront.com with esmtp (Exim 3.35 #1 (Debian)) id 19tAbH-0003KG-00; Sat, 30 Aug 2003 20:37:27 +0200 Message-ID: <3F50EEE7.3030705@packetfront.com> Date: Sat, 30 Aug 2003 20:37:27 +0200 From: =?ISO-8859-1?Q?Andreas_=D6man?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 MIME-Version: 1.0 To: Bud Millwood CC: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-subscriber-id-01.txt> References: <4.3.2.7.2.20030828064105.00b99008@localhost> <200308291025.51415.budm@weird-solutions.com> In-Reply-To: <200308291025.51415.budm@weird-solutions.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA24765 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: quoted-printable Bud Millwood wrote: >=20 > We would really like to see this suboption fixed to exactly one data ty= pe. The=20 > problem with allowing the subscriber id be a sequence of bytes or an as= cii=20 > string is that when it comes time for us to report the subscriber id, s= ay in=20 > a log file, we really have no idea how to display it correctly. We may = end up=20 > displaying it as a sequence of bytes, although it is (according to the=20 > manufacturer's documentation) a printable string, or vice-versa. >=20 I second that. Also, i'd prefer strings. Not only for the reasons above, but for the ability to do wildcard-compares, regexps, etc in the DCHP server when selecting scope. -- Andreas =D6man, Software Engineer Packetfront. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg