From mailman-admin@ietf.org Wed Jan 1 10:46:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07903 for ; Wed, 1 Jan 2003 10:46:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h01FrpJ08498 for ; Wed, 1 Jan 2003 10:53:51 -0500 Date: Wed, 01 Jan 2003 10:53:51 -0500 Message-ID: <20030101155351.32165.88523.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 Thu Jan 2 11:05:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07356; Thu, 2 Jan 2003 11:05:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02GD3J01605; Thu, 2 Jan 2003 11:13:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02GBnJ01519 for ; Thu, 2 Jan 2003 11:11:49 -0500 Received: from e34.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07187 for ; Thu, 2 Jan 2003 11:02:57 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h02G63pS018506; Thu, 2 Jan 2003 11:06:03 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h02G62T7087268; Thu, 2 Jan 2003 09:06:02 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h02G2Ac29848; Thu, 2 Jan 2003 11:02:10 -0500 Message-Id: <200301021602.h02G2Ac29848@rotala.raleigh.ibm.com> To: "Woundy, Richard" cc: "Paul Duffy" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-narten-iana-experimental-allocations-03.txt (was Re: [dhcwg ] draft-ietf-dhc-packetcable-04.txt) In-Reply-To: Message from "Woundy, Richard" of "Mon, 23 Dec 2002 09:42:28 MST." <6732623D2548D61193C90002A5C88DCC01EBD011@entmaexch02.broadband.att.com> Date: Thu, 02 Jan 2003 11:02:10 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Rich. > These comments are really about your draft > ons-03.txt>. > I thought you were advocating the allocation of a few CCC sub-options for > experimentation, not the use of the standard DHCP experimental option space > -- which explains this exchange of comments between us: Yes. If Cablelabs wants to test with some sub options, it would seem to me that a few sub-option values could be assigned for this. > >> Quite frankly, I think Paul could just as easily steal a DHCP option > >> code in the 128-254 space for such experimentation. > > > > And would that not be an acceptable solution? I *really* would like to > > understand what the underlying requirement is here. I still feel like > > perhaps I don't. > So the advice from your draft is to use DHCP experimental options 128-254, > and not set aside space for experimental CCC suboptions, right? Either way would seem to work. Since cablelabs want specifically to test the suboptions, it seems like allocating some for this make sense. But I don't have strong feelings about this. > Now let me consider this exchange: > >> This comment from the draft could be especially tricky for a headless > >> PacketCable brick: "anyone making use of an experimental number should > >> require the user or customer to explicitly configure the value prior to > >> enabling its usage". > > > >Experimental use numbers are not at all intended for mass deployments > >or home users to configure their cable modems. If you are shipping > >modems to home users, you are really not experimenting anymore; you > >are deploying. > I don't think you're seeing my real point about headless devices and DHCP > option experimentation. Let's disregard cable for this discussion. How does > one "explicitly configure the value" on a device without a user interface > (i.e. a brick)? Perhaps some devices will obtain an IPv4 link-local address > for its testing-accessible interface, and then the device can be configured > using an internal web server or SNMP agent -- but that's the ideal (I > think). It is perhaps more likely that the only way that the device will > know about any DHCP experimental options is if the device has downloaded > firmware that understands the option(s). Shouldn't the draft consider this > possibility? OK, I think I see your issue now. The intent of the document is to discourage real deployments, but to allow for experimentation and testing (including what I understand cablelabs testing to involve). The current wording would seem to be too restrictive. Would the following wording address your concern (for the last paragraph?) In many, if not most cases, reserving a single value for experimental use will suffice. While it may be tempting to reserve more in order to make it easy to test many things at once, reserving many may also increase the temptation for someone using a particular value to assume that a specific experimental value can be used for a given purpose exclusively. Values reserved for experimental use are never to be made permanent; permanent assignments should be obtained through standard processes. As described above, experimental numbers are intended for experimentation and testing and are not intended for wide or general deployments. When protocols that use experimental numbers are included in products, the end user of the product should be required to explicitly configure the value prior to enabling its usage. > There's something else that I don't understand: why do you use the term > "customers" in your draft? Apparently according to your comments, this term > does not apply to broadband Internet customers (cable or otherwise). Then > what kinds of customers are "safe"? Why would any "customer" be willing to > stop such an experiment, if the experiment helped them resolve some problem > or added a feature? Customer may not be the best choice of words. Would "end user" be better? The intention is to capture the notion that the owner/user of the device must be able to control the experimentation, as opposed to the manufacturer of the device/product. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 2 12:02:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08524; Thu, 2 Jan 2003 12:02:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02HAFJ05781; Thu, 2 Jan 2003 12:10:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02H9gJ05752 for ; Thu, 2 Jan 2003 12:09:42 -0500 Received: from e32.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08469 for ; Thu, 2 Jan 2003 12:00:49 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h02H3rn0032618; Thu, 2 Jan 2003 12:03:53 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h02H3rT7048048; Thu, 2 Jan 2003 10:03:53 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h02H01S30878; Thu, 2 Jan 2003 12:00:02 -0500 Message-Id: <200301021700.h02H01S30878@rotala.raleigh.ibm.com> To: Paul Duffy cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-05.txt In-Reply-To: Message from Paul Duffy of "Mon, 30 Dec 2002 23:27:00 EST." <4.3.2.7.2.20021230231439.02c085f8@funnel.cisco.com> Date: Thu, 02 Jan 2003 12:00:01 -0500 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: , Paul Duffy writes: > At 06:45 PM 12/30/2002 -0500, Ted Lemon wrote: > >>Future proposed sub-options will be assigned a numeric code chosen by > >>CableLabs immediately following IESG approval of the draft. > > > >What does "IETF approval of the draft" mean? If it means that the draft > >has been adopted by the WG, sounds fine, but if it means that the draft > >has passed the IESG review, then what's the point of the expert review? > > > Hi Ted, > The point I am trying to get across is that the DHC WG, ADs, IESG, etc. > approve the technical content/semantics of the sub-option, then Cablelabs > would assign the sub-option code. Note: "IETF Consensus" as defined by RFC 2434, basically means "IESG approves the document". That implies all of the above reviews. Once the IESG has approved the document, it gets shipped to the RFC editor, and IANA can *immediately* assign any IANA numbers that are needed. I say "immediately" in that IANA is authorized to assign he values as soon as the document is approved. They typically do so long before the RFC is actually published. In cases where there is a really time critical need, this can be done in a day or two (so long as folks are given advance warning that this is coming along). I.e., the IANA just needs to be asked to prioritize the request. This has happened in the past, so getting IANA to assign a number quickly once a document has been approved for publication is not a problem. Hence, the need for cablelabs to actually pick and assign the actual value to be used doesn't seem to buy much time. IMO, its simpler and adequate to let IANA do it. > I'm trying to balance CableLab's need for speed with IETF's review > of the content of the sub-option. The expert review would be only > for the choice of sub-option code assignment(?), not the actual > technical content of the draft. The problem is that if one *really* needs the code assignment in order to put it in a spec, but the technical contents of the spec have not been nailed down, it seems premature to be saying implement option X using code point Y. > So the order of events would be: > 1. CCC sub-option draft submitted to DHC WG. > 2. DHC WG, AD, IESG review/approve sub-option format and content. > 3. Cablelabs assigns sub-option code. > 4. IETF expert reviewer approves code assignment. I don't see the need for 3 & 4 if they don't happen until after the document is approved for publication. > 5a. Cablelabs compliant vendors start implementing sub-option for testing > and shipment to customer. > 5b. Draft is simultaneously submitted to RFC editor Q. > If all goes well, field shipments can commence just about the time the RFC > exits the editor Q. > I'm grasping for a compromise here. Any suggestions? More thoughts. If you are worried about odd situations where you really need a number assignment, but the document isn't quite ready yet, but folks do think it is OK to go ahead and assign a value (because the ID is really close, or ...) include in the IANA considerations that assignment of sub options can (also) be made via "IESG approval" [RFC 2434], i.e., something like: IANA is requested to register codes for future CableLabs Client Configuration Sub-options via "IETF Consensus" or "IESG Approval" [RFC 2434]. IESG approval doesn't require a document or anything. It is really intended as an escape for dealing with exceptional situations, with one of the other approval mechanisms (e.g., "IETF Consensus") handling the vast majority of assignments in practice. Also, note that "IETF Consensus" means "ID is approved to publish RFC". They can be experimental/info as well as standards track. So again, if there is a situation where something just absolutely needs to get done, another option is publish as info. The bar is generally lower for such documents. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 2 12:04:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08594; Thu, 2 Jan 2003 12:04:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02HC6J05965; Thu, 2 Jan 2003 12:12:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h02HBgJ05919 for ; Thu, 2 Jan 2003 12:11:42 -0500 Received: from e34.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08550 for ; Thu, 2 Jan 2003 12:02:49 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h02H5rpS023672; Thu, 2 Jan 2003 12:05:53 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h02H5qT7106232; Thu, 2 Jan 2003 10:05:52 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h02H20P30889; Thu, 2 Jan 2003 12:02:01 -0500 Message-Id: <200301021702.h02H20P30889@rotala.raleigh.ibm.com> To: Ted Lemon cc: Paul Duffy , Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-05.txt In-Reply-To: Message from Ted Lemon of "Mon, 30 Dec 2002 18:45:54 EST." Date: Thu, 02 Jan 2003 12:01:40 -0500 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: , > > Future proposed sub-options will be assigned a numeric code chosen by > > CableLabs immediately following IESG approval of the draft. > What does "IETF approval of the draft" mean? In practice, it means the IESG has approved publication. The IESG review is the final check that the IETF doesn't have a problem with a document. The code word for this (using RFC 2434 terminology) is "IETF Consensus". Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 3 15:06:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17944; Fri, 3 Jan 2003 15:06:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KDrJ21683; Fri, 3 Jan 2003 15:13:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KBxJ21638 for ; Fri, 3 Jan 2003 15:11:59 -0500 Received: from iwantka.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17896 for ; Fri, 3 Jan 2003 15:02:34 -0500 (EST) Received: from NOMAD (unsaniac.4b41.com [209.16.220.12]) by iwantka.com (8.11.3/8.11.3) with SMTP id h03KAhv17794 for ; Fri, 3 Jan 2003 14:10:43 -0600 (CST) (envelope-from nathan@iwantka.com) From: "Nathan Littlepage" To: "Dhcwg" Date: Fri, 3 Jan 2003 14:08:23 -0600 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.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Authentication 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 As per RFC 3118. Has Authentication for DHCP been implemented? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 3 15:34:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18547; Fri, 3 Jan 2003 15:34:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KhPJ23576; Fri, 3 Jan 2003 15:43:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KfrJ23502 for ; Fri, 3 Jan 2003 15:41:53 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18498 for ; Fri, 3 Jan 2003 15:32:26 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h03Ka3E4026620; Fri, 3 Jan 2003 15:36:03 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn3-5.cisco.com [10.21.64.5]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA22474; Fri, 3 Jan 2003 15:35:23 -0500 (EST) Message-Id: <4.3.2.7.2.20030103152709.00b815c8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Jan 2003 15:27:49 -0500 To: "Nathan Littlepage" From: Ralph Droms Subject: Re: [dhcwg] Authentication Cc: "Dhcwg" 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: , I don't know of any commercially or freely available implementations... - Ralph At 02:08 PM 1/3/2003 -0600, Nathan Littlepage wrote: >As per RFC 3118. Has Authentication for DHCP been implemented? >_______________________________________________ >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 Jan 3 15:40:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18651; Fri, 3 Jan 2003 15:40:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03Km6J23713; Fri, 3 Jan 2003 15:48:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03KlaJ23698 for ; Fri, 3 Jan 2003 15:47:36 -0500 Received: from iwantka.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18645 for ; Fri, 3 Jan 2003 15:38:09 -0500 (EST) Received: from NOMAD (unsaniac.4b41.com [209.16.220.12]) by iwantka.com (8.11.3/8.11.3) with SMTP id h03Kk4v17864; Fri, 3 Jan 2003 14:46:04 -0600 (CST) (envelope-from nathan@iwantka.com) From: "Nathan Littlepage" To: "Ralph Droms" Cc: "Dhcwg" Subject: RE: [dhcwg] Authentication Date: Fri, 3 Jan 2003 14:43:44 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 In-Reply-To: <4.3.2.7.2.20030103152709.00b815c8@funnel.cisco.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 Damn. I would assume the implementation of it would be much more attractive and easily deployable than EAP with Radius. Thanks. Nathan -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, January 03, 2003 2:28 PM To: Nathan Littlepage Cc: Dhcwg Subject: Re: [dhcwg] Authentication I don't know of any commercially or freely available implementations... - Ralph At 02:08 PM 1/3/2003 -0600, Nathan Littlepage wrote: >As per RFC 3118. Has Authentication for DHCP been implemented? >_______________________________________________ >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 Jan 3 15:56:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18969; Fri, 3 Jan 2003 15:56:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03L4WJ24199; Fri, 3 Jan 2003 16:04:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h03HAAJ07404 for ; Fri, 3 Jan 2003 12:10:10 -0500 Received: from web8004.mail.in.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13023 for ; Fri, 3 Jan 2003 12:00:48 -0500 (EST) Message-ID: <20030103170358.15366.qmail@web8004.mail.in.yahoo.com> Received: from [203.195.215.254] by web8004.mail.in.yahoo.com via HTTP; Fri, 03 Jan 2003 17:03:58 GMT Date: Fri, 3 Jan 2003 17:03:58 +0000 (GMT) From: =?iso-8859-1?q?prema=20mayudu?= To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1690352785-1041613438=:12080" Content-Transfer-Encoding: 8bit Subject: [dhcwg] reg dhcp 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: , --0-1690352785-1041613438=:12080 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hello jnson goldsch i b.prema mayudu , i am doing ph.d in IISc.,Banagalore ,INDIA i see your doveloping jDHCP source code, it is excelent , but you can place only dhcpclient source code. i wnat dhcpserver source code also ,where i can get the dhcpserver source code. regarding this u please send the information and as well as send any file attatchment to my mail id i am waiting for your main thank u bye prema mayudu Catch all the cricket action. Download Yahoo! Score tracker --0-1690352785-1041613438=:12080 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

hello jnson goldsch

i   b.prema mayudu , i am doing ph.d in IISc.,Banagalore ,INDIA

i see your doveloping jDHCP source code, it is excelent , but you can place only dhcpclient source code.

i wnat dhcpserver source code also ,where i can get the dhcpserver source code.

regarding this u please send the information and as well as send any file attatchment to my mail id

i am waiting for your main

thank u

bye

prema mayudu

Catch all the cricket action. Download Yahoo! Score tracker --0-1690352785-1041613438=:12080-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 3 19:37:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22459; Fri, 3 Jan 2003 19:37:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h040jmJ05007; Fri, 3 Jan 2003 19:45:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h040ibJ04958 for ; Fri, 3 Jan 2003 19:44:37 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22426 for ; Fri, 3 Jan 2003 19:35:06 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h040cu8K019410; Fri, 3 Jan 2003 19:38:57 -0500 (EST) Received: from paduffy-w2k.cisco.com (rtp-vpn2-122.cisco.com [10.82.240.122]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA05106; Fri, 3 Jan 2003 19:38:14 -0500 (EST) Message-Id: <4.3.2.7.2.20030103193411.02c644e8@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Jan 2003 19:38:12 -0500 To: Thomas Narten From: Paul Duffy Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-05.txt Cc: dhcwg@ietf.org In-Reply-To: <200301021700.h02H01S30878@rotala.raleigh.ibm.com> References: <4.3.2.7.2.20021230231439.02c085f8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , ...inline... At 12:00 PM 1/2/2003 -0500, Thomas Narten wrote: >Paul Duffy writes: > > > At 06:45 PM 12/30/2002 -0500, Ted Lemon wrote: > > >>Future proposed sub-options will be assigned a numeric code chosen by > > >>CableLabs immediately following IESG approval of the draft. > > > > > >What does "IETF approval of the draft" mean? If it means that the draft > > >has been adopted by the WG, sounds fine, but if it means that the draft > > >has passed the IESG review, then what's the point of the expert review? > > > > > > Hi Ted, > > > The point I am trying to get across is that the DHC WG, ADs, IESG, etc. > > approve the technical content/semantics of the sub-option, then Cablelabs > > would assign the sub-option code. > >Note: "IETF Consensus" as defined by RFC 2434, basically means "IESG >approves the document". That implies all of the above reviews. > >Once the IESG has approved the document, it gets shipped to the RFC >editor, and IANA can *immediately* assign any IANA numbers that are >needed. I say "immediately" in that IANA is authorized to assign he >values as soon as the document is approved. They typically do so long >before the RFC is actually published. In cases where there is a really >time critical need, this can be done in a day or two (so long as folks >are given advance warning that this is coming along). I.e., the IANA >just needs to be asked to prioritize the request. This has happened in >the past, so getting IANA to assign a number quickly once a document >has been approved for publication is not a problem. > >Hence, the need for cablelabs to actually pick and assign the actual >value to be used doesn't seem to buy much time. IMO, its simpler and >adequate to let IANA do it Please do not forget the second reason for Cablelabs assigning the code....the desire to partition the sub-option code space amongst its various projects. If IANA does the assigning, how will this be possible? > > I'm trying to balance CableLab's need for speed with IETF's review > > of the content of the sub-option. The expert review would be only > > for the choice of sub-option code assignment(?), not the actual > > technical content of the draft. > >The problem is that if one *really* needs the code assignment in order >to put it in a spec, but the technical contents of the spec have not >been nailed down, it seems premature to be saying implement option X >using code point Y. > > > So the order of events would be: > > > 1. CCC sub-option draft submitted to DHC WG. > > 2. DHC WG, AD, IESG review/approve sub-option format and content. > > 3. Cablelabs assigns sub-option code. > > 4. IETF expert reviewer approves code assignment. > >I don't see the need for 3 & 4 if they don't happen until after the >document is approved for publication. > > > 5a. Cablelabs compliant vendors start implementing sub-option for testing > > and shipment to customer. > > 5b. Draft is simultaneously submitted to RFC editor Q. > > > If all goes well, field shipments can commence just about the time the RFC > > exits the editor Q. > > > I'm grasping for a compromise here. Any suggestions? > >More thoughts. > >If you are worried about odd situations where you really need a number >assignment, but the document isn't quite ready yet, but folks do think >it is OK to go ahead and assign a value (because the ID is really >close, or ...) include in the IANA considerations that assignment of >sub options can (also) be made via "IESG approval" [RFC 2434], i.e., >something like: > > IANA is requested to register codes for future CableLabs Client > Configuration Sub-options via "IETF Consensus" or "IESG Approval" > [RFC 2434]. > >IESG approval doesn't require a document or anything. It is really >intended as an escape for dealing with exceptional situations, with >one of the other approval mechanisms (e.g., "IETF Consensus") handling >the vast majority of assignments in practice. > >Also, note that "IETF Consensus" means "ID is approved to publish >RFC". They can be experimental/info as well as standards track. So >again, if there is a situation where something just absolutely needs >to get done, another option is publish as info. The bar is generally >lower for such documents. > >Thomas -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 3 21:08:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23478; Fri, 3 Jan 2003 21:08:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h042GYJ09102; Fri, 3 Jan 2003 21:16:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h042FIJ09066 for ; Fri, 3 Jan 2003 21:15:18 -0500 Received: from e35.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23464 for ; Fri, 3 Jan 2003 21:05:44 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0428nk3013628; Fri, 3 Jan 2003 21:08:49 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-195-35.mts.ibm.com [9.65.195.35]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0428meG070154; Fri, 3 Jan 2003 19:08:48 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h0427Bx04493; Fri, 3 Jan 2003 21:07:11 -0500 Message-Id: <200301040207.h0427Bx04493@cichlid.adsl.duke.edu> To: Paul Duffy cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-05.txt In-Reply-To: Message from Paul Duffy of "Fri, 03 Jan 2003 19:38:12 EST." <4.3.2.7.2.20030103193411.02c644e8@funnel.cisco.com> Date: Fri, 03 Jan 2003 21:07:11 -0500 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: , > Please do not forget the second reason for Cablelabs assigning the > code....the desire to partition the sub-option code space amongst its > various projects. If IANA does the assigning, how will this be > possible? This is doable. In the current document, in the IANA considerations section, state that the option space is to be split into two ranges (and say what the ranges are) and that future documents that need a subcode will indicate from which range the code should be allocated. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 5 18:47:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12189; Sun, 5 Jan 2003 18:47:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05Nu0J27836; Sun, 5 Jan 2003 18:56:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h05NpcJ27759 for ; Sun, 5 Jan 2003 18:51:38 -0500 Received: from emailsvr.snetsystems.co.kr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12161 for ; Sun, 5 Jan 2003 18:41:08 -0500 (EST) Received: by emailsvr.snetsystems.co.kr with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Jan 2003 08:44:22 +0900 Message-ID: <7F4BF38DA84EA347814EA5F756F3D0609FFC65@emailsvr.snetsystems.co.kr> From: =?euc-kr?B?waSw6Ljt?= To: "'dhcwg@ietf.org'" Date: Mon, 6 Jan 2003 08:44:18 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B514.5D4C4C90" Subject: [dhcwg] test Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B514.5D4C4C90 Content-Type: text/plain; charset="KS_C_5601-1987" I'm sorry... test ------_=_NextPart_001_01C2B514.5D4C4C90 Content-Type: text/html; charset="KS_C_5601-1987" test

I'm sorry...
test

------_=_NextPart_001_01C2B514.5D4C4C90-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 7 11:19:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19608; Tue, 7 Jan 2003 11:19:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GShJ32655; Tue, 7 Jan 2003 11:28:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h07GQ9J32572 for ; Tue, 7 Jan 2003 11:26:09 -0500 Received: from e32.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19494 for ; Tue, 7 Jan 2003 11:14:51 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h07GI5DD026284 for ; Tue, 7 Jan 2003 11:18:05 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h07GI5FK059150 for ; Tue, 7 Jan 2003 09:18:05 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h07GDpR25027 for ; Tue, 7 Jan 2003 11:13:51 -0500 Message-Id: <200301071613.h07GDpR25027@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-05.txt In-Reply-To: Message of "Fri, 03 Jan 2003 19:38:12 EST." <4.3.2.7.2.20030103193411.02c644e8@funnel.cisco.com> <4.3.2.7.2.20030103193411.02c644e8@funnel.cisco.com> Date: Tue, 07 Jan 2003 11:13:51 -0500 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: , One more thing. I did go ahead and get this document discussed by the entire IESG during the telechat between xmas and new years. There were no additional comments raised other than what we're discussing now. So, once we get agreement on the last issues, and get a new ID out, I expect the document to be approved by the IESG in short order. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 8 17:37:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10645; Wed, 8 Jan 2003 17:37:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MmGJ28886; Wed, 8 Jan 2003 17:48:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h08MfjJ28572 for ; Wed, 8 Jan 2003 17:41:45 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10137 for ; Wed, 8 Jan 2003 17:29:51 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h08MXkXN012162; Wed, 8 Jan 2003 17:33:47 -0500 (EST) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-90.cisco.com [161.44.149.90]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA07640; Wed, 8 Jan 2003 17:33:04 -0500 (EST) Message-Id: <4.3.2.7.2.20030108170435.05eecd70@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Jan 2003 17:33:04 -0500 To: dhcwg@ietf.org From: Paul Duffy Cc: Thomas Narten , Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] draft-ietf-dhc-packetcable-05.txt ... section 12. 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/Ralph/all, Assuming the following: 1. Cablelabs and the DHC WG/IETF will collaborate to complete simple CCC sub-option extension drafts in 30 - 60 days. 2. The Cablelabs requirement to maintain project ranges within the sub-option number space can be dropped. Please review the following text change... -------------------------- Old text: 12. Procedure for Adding Additional Sub-options IANA is requested to maintain a new number space of "CableLabs Client Configuration Sub-options", located in the BOOTP-DHCP Parameters Registry. The initial sub-option codes are described in sections of this document. IANA is requested to register codes for future CableLabs Client Configuration Sub-options with an "Expert Review" approval policy as described in RFC 2434 [2]. Future proposed sub-options will be assigned a numeric code chosen by CableLabs, which will be documented in the Internet Drafts that describe the sub-options. The code assignment will be reviewed by a designated expert from the IETF prior to publication in an RFC. New Text: 12. Procedure for Adding Additional Sub-options IANA is requested to maintain a new number space of "CableLabs Client Configuration Sub-options", located in the BOOTP-DHCP Parameters Registry. The initial sub-option codes are described in sections of this document. IANA is requested to register codes for future CableLabs Client Configuration Sub-options via an "IETF Consensus" approval policy as described in RFC 2434 [2]. ---------------------------- Is this change satisfactory? Cheers, -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 10 13:39:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10557; Fri, 10 Jan 2003 13:39:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AIowJ21130; Fri, 10 Jan 2003 13:50:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AImvJ21068 for ; Fri, 10 Jan 2003 13:48:57 -0500 Received: from e31.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10273 for ; Fri, 10 Jan 2003 13:36:08 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0AIdLIP069796; Fri, 10 Jan 2003 13:39:21 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0AIdJ4o041780; Fri, 10 Jan 2003 11:39:19 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h0AIcxP11472; Fri, 10 Jan 2003 13:38:59 -0500 Message-Id: <200301101838.h0AIcxP11472@rotala.raleigh.ibm.com> To: Paul Duffy cc: dhcwg@ietf.org, Ralph Droms In-Reply-To: Message from paduffy@cisco.com of "Wed, 08 Jan 2003 17:33:04 EST." <4.3.2.7.2.20030108170435.05eecd70@funnel.cisco.com> Date: Fri, 10 Jan 2003 13:38:59 -0500 From: Thomas Narten Subject: [dhcwg] Re: draft-ietf-dhc-packetcable-05.txt ... section 12. Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Paul. > Assuming the following: > 1. Cablelabs and the DHC WG/IETF will collaborate to complete simple CCC > sub-option extension drafts in 30 - 60 days. I think this is a fine goal, but we need to be clear that there are no guarantees. I'm saying that because different folk may disagree about what a "simple" extension is, for example. And my expectation is that this sort of short time fuse will be for emergencies, not the general way things are done. But we won't be able to resolve this without looking at the specific proposals. I'm saying this mostly because 30 days is really really short between a 00 version of an ID appears and the IESG approves (almost impossible for standards track, more like doable for info document). And if this happens during an IETF meeting, things get difficult. But in principle I think this is doable. I'd also like to get Ralph's take on this, since the DHC WG also has to deliver on this. > 2. The Cablelabs requirement to maintain project ranges within the > sub-option number space can be dropped. OK. > New Text: > 12. Procedure for Adding Additional Sub-options > IANA is requested to maintain a new number space of "CableLabs Client > Configuration Sub-options", located in the BOOTP-DHCP Parameters > Registry. The initial sub-option codes are described in sections of this > document. It would be good to actually list the sub-codes here (e.g., in a table) or mention the specific sections. This is to make IANA's job easier (you don't want them to have to search too hard to figure out what you need). > IANA is requested to register codes for future CableLabs Client > Configuration Sub-options via an "IETF Consensus" approval policy as > described in RFC 2434 [2]. > Is this change satisfactory? Works for me. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 10 14:26:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13239; Fri, 10 Jan 2003 14:26:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AJcLJ24301; Fri, 10 Jan 2003 14:38:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AJbpJ24283 for ; Fri, 10 Jan 2003 14:37:51 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13229 for ; Fri, 10 Jan 2003 14:25:02 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0AJT061022829; Fri, 10 Jan 2003 14:29:00 -0500 (EST) Received: from paduffy-w2k.cisco.com (dhcp-161-44-149-90.cisco.com [161.44.149.90]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA16188; Fri, 10 Jan 2003 14:28:17 -0500 (EST) Message-Id: <4.3.2.7.2.20030110142635.02b37e30@funnel.cisco.com> X-Sender: paduffy@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Jan 2003 14:28:17 -0500 To: Thomas Narten From: Paul Duffy Cc: dhcwg@ietf.org, Ralph Droms In-Reply-To: <200301101838.h0AIcxP11472@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: draft-ietf-dhc-packetcable-05.txt ... section 12. 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: , Great. I'll submit the new draft today. Looks like we're done! Cheers, At 01:38 PM 1/10/2003 -0500, Thomas Narten wrote: >Hi Paul. > > > Assuming the following: > > > 1. Cablelabs and the DHC WG/IETF will collaborate to complete simple CCC > > sub-option extension drafts in 30 - 60 days. > >I think this is a fine goal, but we need to be clear that there are no >guarantees. I'm saying that because different folk may disagree about >what a "simple" extension is, for example. And my expectation is that >this sort of short time fuse will be for emergencies, not the general >way things are done. But we won't be able to resolve this without >looking at the specific proposals. > >I'm saying this mostly because 30 days is really really short between >a 00 version of an ID appears and the IESG approves (almost impossible >for standards track, more like doable for info document). And if this >happens during an IETF meeting, things get difficult. > >But in principle I think this is doable. > >I'd also like to get Ralph's take on this, since the DHC WG also has >to deliver on this. > > > 2. The Cablelabs requirement to maintain project ranges within the > > sub-option number space can be dropped. > >OK. > > > New Text: > > > 12. Procedure for Adding Additional Sub-options > > > IANA is requested to maintain a new number space of "CableLabs Client > > Configuration Sub-options", located in the BOOTP-DHCP Parameters > > Registry. The initial sub-option codes are described in sections of this > > document. > >It would be good to actually list the sub-codes here (e.g., in a >table) or mention the specific sections. This is to make IANA's job >easier (you don't want them to have to search too hard to figure out >what you need). > > > > IANA is requested to register codes for future CableLabs Client > > Configuration Sub-options via an "IETF Consensus" approval policy as > > described in RFC 2434 [2]. > > > Is this change satisfactory? > >Works for me. > >Thomas -- Paul Duffy Cisco Systems, Inc. paduffy@cisco.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 10 15:47:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15729; Fri, 10 Jan 2003 15:47:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AKwtJ28558; Fri, 10 Jan 2003 15:58:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0AKvSJ28498 for ; Fri, 10 Jan 2003 15:57:28 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15609 for ; Fri, 10 Jan 2003 15:44:32 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0AKmWDQ004946; Fri, 10 Jan 2003 15:48:32 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-137.cisco.com [161.44.149.137]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA22689; Fri, 10 Jan 2003 15:47:49 -0500 (EST) Message-Id: <4.3.2.7.2.20030110154152.03c294d0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Jan 2003 15:47:44 -0500 To: Thomas Narten From: Ralph Droms Cc: Paul Duffy , dhcwg@ietf.org In-Reply-To: <200301101838.h0AIcxP11472@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: draft-ietf-dhc-packetcable-05.txt ... section 12. 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: , Paul, Regarding "30-60 days" - 30 days is pretty optimistic, but 30-60 days seems feasible. Of course, anything CableLabs can do to get the WG involved as early as possible will help. For example, if Cablelabs could publish a preliminary descriptions of a new suboption as an Internet-Draft (I-Ds are cheap) as soon as development begins on that new suboption, the WG will have a chance to address DHCP-compatibility issues early on in the process. Then, we could do a WG last call as soon as the final CableLabs spec and Internet-Draft are published. The other proposed changes look fine to me... - Ralph At 01:38 PM 1/10/2003 -0500, Thomas Narten wrote: >Hi Paul. > > > Assuming the following: > > > 1. Cablelabs and the DHC WG/IETF will collaborate to complete simple CCC > > sub-option extension drafts in 30 - 60 days. > >I think this is a fine goal, but we need to be clear that there are no >guarantees. I'm saying that because different folk may disagree about >what a "simple" extension is, for example. And my expectation is that >this sort of short time fuse will be for emergencies, not the general >way things are done. But we won't be able to resolve this without >looking at the specific proposals. > >I'm saying this mostly because 30 days is really really short between >a 00 version of an ID appears and the IESG approves (almost impossible >for standards track, more like doable for info document). And if this >happens during an IETF meeting, things get difficult. > >But in principle I think this is doable. > >I'd also like to get Ralph's take on this, since the DHC WG also has >to deliver on this. > > > 2. The Cablelabs requirement to maintain project ranges within the > > sub-option number space can be dropped. > >OK. > > > New Text: > > > 12. Procedure for Adding Additional Sub-options > > > IANA is requested to maintain a new number space of "CableLabs Client > > Configuration Sub-options", located in the BOOTP-DHCP Parameters > > Registry. The initial sub-option codes are described in sections of this > > document. > >It would be good to actually list the sub-codes here (e.g., in a >table) or mention the specific sections. This is to make IANA's job >easier (you don't want them to have to search too hard to figure out >what you need). > > > > IANA is requested to register codes for future CableLabs Client > > Configuration Sub-options via an "IETF Consensus" approval policy as > > described in RFC 2434 [2]. > > > Is this change satisfactory? > >Works for me. > >Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 13 14:55:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21688; Mon, 13 Jan 2003 14:55:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DK8nJ18689; Mon, 13 Jan 2003 15:08:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DK54J17867 for ; Mon, 13 Jan 2003 15:05:04 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21542 for ; Mon, 13 Jan 2003 14:50:44 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0DJp0P20485; Mon, 13 Jan 2003 13:51:02 -0600 (CST) Date: Mon, 13 Jan 2003 13:53:50 -0600 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Thomas Narten , zeroconf@merit.edu, Stuart Cheshire , dhcwg@ietf.org To: Erik Nordmark From: Ted Lemon In-Reply-To: <27AECC89-2389-11D7-8FB4-00039367340A@nominum.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP 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 >> So were you commenting on the probe or the announcement? > > The announcement. All DHCP clients that I know of do the reply > instead of the request - i.e., they're out of spec. :'} So, just to be clear about my faux pas last week, RFC2131 says to do an ARP *reply* to announce that it has its new IP address, but existing clients send an ARP *request* with the newly-acquired DHCP address in source and destination IP address fields - for example, here's what Win98SE transmits (I have a 10baseT switch that filters unicasts, so I only got the broadcasts): 13:33:08.865011 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] xid:0xea456228 vend-rfc1048 DHCP:REQUEST CID:01:00:03:ff:66:34:0a RQ:10.0.1.5 SID:10.0.1.1 HN:"Windows 98SE^@" FQDN:0.0.0.87.105.110.100.111.119.115.32.57.56.83.69.0 VC:77.83.70.84.32.57.56 PR:SM+DN+DG+NS+WNS+WNT+WSC+VO+CLASS (ttl 128, id 256, len 346) 13:33:08:925932 arp who-has 10.0.1.5 tell 10.0.1.5 This is what is recommended in the Stevens TCP/IP book. I think the reason this is so common is that the ARP announcement is part of the interface configuration process, and is not done by the DHCP client, so the people that read the DHCP spec aren't the ones that write the code that does the announcement. This is certainly the case with the ISC DHCP client. On Unix systems of which I am aware, it's not possible to do ARP processing outside the kernel. Since the ISC DHCP client runs on Unix, it's pretty much stuck with whatever the operating system provides. So in fact all the DHCP clients of which I am aware are technically out of spec with RFC2131. I don't think this is a big problem, or that RFC2131 needs to be immediately updated. The language in RFC2131 is specifying generic behavior that all IP stacks should implement regardless of whether or not they support DHCP, and therefore RFC2131's recommendation is just that - a recommendation. So it's actually very helpful that Stuart is coming out with a document that's not DHCP-specific that states how this should be done, and it's also fine that it contradicts the recommendation stated in RFC2131. I'm not sure we need to say that this draft updates RFC2131 - I leave that up to those more knowledgable about the IETF process to decide. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 13 19:35:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29635; Mon, 13 Jan 2003 19:35:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E0mcJ03657; Mon, 13 Jan 2003 19:48:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0DKZDJ19961 for ; Mon, 13 Jan 2003 15:35:13 -0500 Received: from mta06ps.bigpond.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22661 for ; Mon, 13 Jan 2003 15:20:54 -0500 (EST) Received: from pc-00206 ([144.135.25.69]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15 mta06ps May 23 2002 23:53:28) with SMTP id H8O60A00.6MX; Tue, 14 Jan 2003 06:24:10 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by PSMAM01.mailsvc.email.bigpond.com(MailRouter V3.0n 71/8114252); 14 Jan 2003 06:24:10 From: Brad Hards To: Ted Lemon Date: Tue, 14 Jan 2003 07:10:26 +1100 User-Agent: KMail/1.4.5 Cc: zeroconf@merit.edu, dhcwg@ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200301140710.27162.bhards@bigpond.net.au> Content-Transfer-Encoding: 8bit Subject: [dhcwg] Re: ARP reply vs. ARP request to announce address acquired from DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 14 Jan 2003 06:53, Ted Lemon wrote: > DHCP client. On Unix systems of which I am aware, it's not possible > to do ARP processing outside the kernel. Since the ISC DHCP client > runs on Unix, it's pretty much stuck with whatever the operating system > provides. It may not be possible on all Unix systems, but it _is_ possible to do general ARP processing on many systems. We do this on zcip (http://zeroconf.sf.net), which runs in userspace. It does take some BSD type kernel extensions, but they are provided by the various BSDs ([free, net, open]) and Linux systems. I'm not sure about other unices. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+Ix0yW6pHgIdAuOMRAvpjAJ0WtTiCOg6h07b1uY4z4qjSLDMtnQCfTXJg UFCf4HCrmvF99ceDVMEb7Gs= =LDww -----END PGP SIGNATURE----- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 13 19:36:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29661; Mon, 13 Jan 2003 19:36:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E0nZJ03690; Mon, 13 Jan 2003 19:49:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E0cSJ03290 for ; Mon, 13 Jan 2003 19:38:28 -0500 Received: from helena.whitefang.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29318 for ; Mon, 13 Jan 2003 19:24:03 -0500 (EST) Received: (qmail 91784 invoked from network); 14 Jan 2003 00:27:43 -0000 Received: from helena.whitefang.com (216.254.175.50) by 0 with SMTP; 14 Jan 2003 00:27:43 -0000 Date: Mon, 13 Jan 2003 19:27:43 -0500 (EST) From: Thamer Al-Harbash X-X-Sender: shadows@helena.whitefang.com To: Ted Lemon cc: Erik Nordmark , Thomas Narten , zeroconf@merit.edu, Stuart Cheshire , dhcwg@ietf.org Subject: Re: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP In-Reply-To: Message-ID: References: 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: , On Mon, 13 Jan 2003, Ted Lemon wrote: > This is what is recommended in the Stevens TCP/IP book. I think the > reason this is so common is that the ARP announcement is part of the > interface configuration process, and is not done by the DHCP client, so > the people that read the DHCP spec aren't the ones that write the code > that does the announcement. This is certainly the case with the ISC > DHCP client. On Unix systems of which I am aware, it's not possible > to do ARP processing outside the kernel. Since the ISC DHCP client > runs on Unix, it's pretty much stuck with whatever the operating system > provides. The dhcpcd package specifically fires off an ARP reply after setting its interface up last I checked. My own code, dhcp-agent, has this feature in the old release and in its -current. > So in fact all the DHCP clients of which I am aware are technically out > of spec with RFC2131. I'm surprised you haven't implemented this in the ISC dhcp suite or think others havent for any technical reason. It's actually pretty straight forward under UNIX since with a DHCP program you generally talk to the network rawly and it's literally just a matter of writing the packet to the raw network device and going on with business as usual. It's an entirely different matter if the other operating systems on the LAN will take note of it. -- Thamer Al-Harbash http://www.whitefang.com/ team dresch made me do it _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 13 19:59:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00182; Mon, 13 Jan 2003 19:59:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E1CEJ05256; Mon, 13 Jan 2003 20:12:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E1BxJ05222 for ; Mon, 13 Jan 2003 20:11:59 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00142 for ; Mon, 13 Jan 2003 19:57:30 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18YFRj-0007SI-00 for ; Mon, 13 Jan 2003 17:00:51 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Jan 2003 17:05:53 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A678CE@homer.incognito.com.> From: "Kostur, Andre" To: "'dhcwg@ietf.org'" Date: Mon, 13 Jan 2003 17:05:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BB69.158D57E0" Subject: [dhcwg] Clarification on RFC 2131 and RFC 3046 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BB69.158D57E0 Content-Type: text/plain; charset="iso-8859-1" Regarding the use of the Client Identifier option to identify a specific device: RFC 2131, Section 4.2 suggests that a DHCP server should use the Client Identifier supplied by the client device where possible, and to effectively synthesize one from the client's chaddr if the client does not supply one. (Actually, section 4.2 insists that a server uses the Client Identifier, if supplied). RFC 3046, Section 4.0 seems to downplay the use of the Client Identifier and encourages the combination of RemoteID and CHADDR to distinguish a device. If the use of a Client Identifier is discouraged, how would a device acquire multiple IP addresses from the DHCP server, since the server is encouraged to only use the RemoteID and CHADDR? (Perhaps we're talking about a set-top box that can do VoIP, and digital video. The device may want an IP for Voice, and a second IP for video, but only has 1 MAC address...?) ------_=_NextPart_001_01C2BB69.158D57E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Clarification on RFC 2131 and RFC 3046

Regarding the use of the Client Identifier option to = identify a specific device:

RFC 2131, Section 4.2 suggests that a DHCP server = should use the Client Identifier supplied by the client device where = possible, and to effectively synthesize one from the client's chaddr if = the client does not supply one.  (Actually, section 4.2 insists = that a server uses the Client Identifier, if supplied).

RFC 3046, Section 4.0 seems to downplay the use of = the Client Identifier and encourages the combination of RemoteID and = CHADDR to distinguish a device.  If the use of a Client Identifier = is discouraged, how would a device acquire multiple IP addresses from = the DHCP server, since the server is encouraged to only use the = RemoteID and CHADDR?  (Perhaps we're talking about a set-top box = that can do VoIP, and digital video.  The device may want an IP = for Voice, and a second IP for video, but only has 1 MAC = address...?)

------_=_NextPart_001_01C2BB69.158D57E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 13 22:26:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03020; Mon, 13 Jan 2003 22:26:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3dgJ13620; Mon, 13 Jan 2003 22:39:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3cuJ13586 for ; Mon, 13 Jan 2003 22:38:56 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02958 for ; Mon, 13 Jan 2003 22:24:29 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0E3OrP23230; Mon, 13 Jan 2003 21:24:53 -0600 (CST) Date: Mon, 13 Jan 2003 21:27:46 -0600 Subject: Re: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, Stuart Cheshire , zeroconf@merit.edu, Thomas Narten , Erik Nordmark To: Thamer Al-Harbash From: Ted Lemon In-Reply-To: Message-Id: <2681ABD0-2770-11D7-A7EA-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The thing that is missing on the Unix side is not the ability to *send* an ARP packet, but the ability to see the reply. It didn't work when I looked at it ~five years ago, and I haven't bothered since. I'll bet that when dhcpcd configures the interface, it generates the ARP request anyway, even though dhcpcd is sending an ARP reply. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 13 22:27:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03052; Mon, 13 Jan 2003 22:27:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3f8J13691; Mon, 13 Jan 2003 22:41:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E3dkJ13623 for ; Mon, 13 Jan 2003 22:39:46 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02984 for ; Mon, 13 Jan 2003 22:25:20 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0E3PhP23240; Mon, 13 Jan 2003 21:25:43 -0600 (CST) Date: Mon, 13 Jan 2003 21:28:36 -0600 Subject: Re: [dhcwg] Clarification on RFC 2131 and RFC 3046 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'dhcwg@ietf.org'" To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A678CE@homer.incognito.com.> Message-Id: <441A8D5B-2770-11D7-A7EA-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Remote-id identifies the relay agent, not the DHCP client. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 13 23:01:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04133; Mon, 13 Jan 2003 23:01:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E4EJJ15782; Mon, 13 Jan 2003 23:14:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E41PJ14732 for ; Mon, 13 Jan 2003 23:01:25 -0500 Received: from helena.whitefang.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03958 for ; Mon, 13 Jan 2003 22:46:57 -0500 (EST) Received: (qmail 92576 invoked from network); 14 Jan 2003 03:50:34 -0000 Received: from helena.whitefang.com (216.254.175.50) by 0 with SMTP; 14 Jan 2003 03:50:34 -0000 Date: Mon, 13 Jan 2003 22:50:33 -0500 (EST) From: Thamer Al-Harbash X-X-Sender: shadows@helena.whitefang.com To: Ted Lemon cc: Thamer Al-Harbash , dhcwg@ietf.org, Stuart Cheshire , zeroconf@merit.edu, Thomas Narten , Erik Nordmark Subject: Re: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP In-Reply-To: <2681ABD0-2770-11D7-A7EA-00039367340A@nominum.com> Message-ID: References: <2681ABD0-2770-11D7-A7EA-00039367340A@nominum.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: , On Mon, 13 Jan 2003, Ted Lemon wrote: > The thing that is missing on the Unix side is not the ability to *send* > an ARP packet, but the ability to see the reply. It didn't work when > I looked at it ~five years ago, and I haven't bothered since. I can't think of any packet capturing facility that would not let you see ARP. dhcp-agent happily ARPs. In -current you can find the code in dhcp-arp-discovery.c > I'll bet that when dhcpcd configures the interface, it generates the > ARP request anyway, even though dhcpcd is sending an ARP reply. Linux 2.4 doesn't seem to be generating any ARP requests on toggling and interface up, down, and changing addresses. I've used a tool called arping myself to force other ARP caches to be updated when changing interface addresses. I can test against BSD and Solaris too but serial conning them is too much of a pain right now :-) Were you using a windows box to with your earlier test? I understand preventing the OS from sending an ARP request instead of a reply is impossible short of fiddling with a local firewall facility which is not always available. -- Thamer Al-Harbash http://www.whitefang.com/ team dresch made me do it _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 14 00:23:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05372; Tue, 14 Jan 2003 00:23:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E5aqJ19991; Tue, 14 Jan 2003 00:36:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E5YTJ19932 for ; Tue, 14 Jan 2003 00:34:29 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05303 for ; Tue, 14 Jan 2003 00:19:59 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0E5KJP24802; Mon, 13 Jan 2003 23:20:19 -0600 (CST) Date: Mon, 13 Jan 2003 23:23:12 -0600 Subject: Re: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Erik Nordmark , Thomas Narten , zeroconf@merit.edu, Stuart Cheshire , dhcwg@ietf.org To: Thamer Al-Harbash From: Ted Lemon In-Reply-To: Message-Id: <46C63EDB-2780-11D7-A7EA-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I can't think of any packet capturing facility that would not let > you see ARP. dhcp-agent happily ARPs. In -current you can find > the code in dhcp-arp-discovery.c BPF wasn't passing arp-reply packets at the time. Perhaps it does now, or perhaps it's handled differently in lpf. I thought it was rather odd at the time, but at the time fixing it wasn't my main priority, so I didn't look any further. > I can test against BSD and Solaris too but serial conning them is > too much of a pain right now :-) Were you using a windows box to > with your earlier test? BSD definitely sends the ARP - I've captured it in packet traces when debugging. Dunno for sure about Solaris, but it uses the BSD stack, so it probably does. Linux doesn't use the BSD stack, which perhaps explains the discrepancy - it could be that Stevens was reporting what the BSD stack was already doing, rather than recommending what it *should* do. So the question is, what does this tell us? Are you saying that Stuart's proposal is not the right way to go, or just pointing out new information? I have to say that I find Stuart's rationale for sending an ARP request rather than a reply fairly convincing. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 14 01:01:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06219; Tue, 14 Jan 2003 01:01:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E6FKJ22884; Tue, 14 Jan 2003 01:15:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E6EUJ22839 for ; Tue, 14 Jan 2003 01:14:30 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06146 for ; Tue, 14 Jan 2003 01:00:00 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0E60OP25224; Tue, 14 Jan 2003 00:00:24 -0600 (CST) Date: Tue, 14 Jan 2003 00:03:18 -0600 Subject: Re: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, Stuart Cheshire , zeroconf@merit.edu, Thomas Narten , Erik Nordmark To: Thamer Al-Harbash From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > No need to update the RFC for this. Just send an ARP reply from > the client and let the OS send all the requests it wants :-) That's a fine engineering solution, but it's a lousy protocol solution - we can't specify two broadcasts. A better way to phrase my question would be, "are you objecting to what is specified in Stuart's draft?" _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 14 06:29:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21408; Tue, 14 Jan 2003 06:29:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EBhSJ21753; Tue, 14 Jan 2003 06:43:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E6mIJ24760 for ; Tue, 14 Jan 2003 01:48:18 -0500 Received: from helena.whitefang.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06661 for ; Tue, 14 Jan 2003 01:33:46 -0500 (EST) Received: (qmail 93396 invoked from network); 14 Jan 2003 06:37:25 -0000 Received: from helena.whitefang.com (216.254.175.50) by 0 with SMTP; 14 Jan 2003 06:37:25 -0000 Date: Tue, 14 Jan 2003 01:37:24 -0500 (EST) From: Thamer Al-Harbash X-X-Sender: shadows@helena.whitefang.com To: Ted Lemon cc: dhcwg@ietf.org, Stuart Cheshire , zeroconf@merit.edu, Thomas Narten , Erik Nordmark Subject: Re: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP In-Reply-To: Message-ID: References: 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: , On Tue, 14 Jan 2003, Ted Lemon wrote: > A better way to phrase my question > would be, "are you objecting to what is specified in Stuart's draft?" His definition of an ARP announcement is fine by me -- and as you both mentioned in your postings is in actuality what most systems are doing. I would be remiss if I did not point out again that systems that do not have a BSD derived IP stack may not do this type of announcement on their own (Linux 2.4 being one I know of). The DHCP implementations need to perform one of the two contending types of ARP announcements. The DHCP RFC needs to reflect which one. -- Thamer Al-Harbash http://www.whitefang.com/ team dresch made me do it _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 14 06:29:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21412; Tue, 14 Jan 2003 06:29:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EBhTJ21769; Tue, 14 Jan 2003 06:43:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E7ghJ06599 for ; Tue, 14 Jan 2003 02:42:43 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17557 for ; Tue, 14 Jan 2003 02:28:10 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe10:85d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0E7VTR44862 for ; Tue, 14 Jan 2003 16:31:29 +0900 (JST) Date: Tue, 14 Jan 2003 16:31:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 110 Subject: [dhcwg] questions about dhcpv6-28 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 have several questions on draft-ietf-dhc-dhcpv6-28.txt from my implementation experiences. (It is probably too late to reflect the points to the spec before it becomes an RFC, though.) I'd apologize in advance if some (or all) of them were addressed in the draft, but I could not find the answers. 1. Section 18.1.8 says: When the client receives a NoBinding status in an IA from the server in response to a Renew message or a Rebind message, the client sends a Request to reestablish an IA with the server. does this imply that the client must remove the IA before sending the request? (I guess the answer is YES, but I'm asking this to be sure.) 2. What should a client do if it receives an IA_NA in a reply message where T1 > T2 > 0? a) the client must ignore the option (or the entire reply message) b) the client must treat as if T1 = T2 c) the client must choose appropriate alternatives for T1 and T2. (this cannot be an option, though, because Section 22.4 says the client MUST use T1 and T2 if they are non-0) d) others FYI: Our implementation currently takes the option a). 3. What should a server do when it receives a request message and already has a binding required in the request? (this can happen if the first reply was lost and the client resend the request message.) FYI: Our implementation currently updates parameters (e.g. lifetimes) of the binding and sends a reply with the parameters, just like the server receives a renew message for the binding. 4. Section 18.1.8 says When the client receives a NoAddrsAvail status from the server in response to a Request, the client can either try another server (perhaps restarting the DHCP server discovery process) or use the Information-Request to obtain configuration parameters only. This sentence is not very clear to me. I interpreted this sentence corresponds to the following part of Section 18.2.1: If the server cannot assign any addresses to an IA in the message from the client, the server MUST include the IA in the Reply message with no addresses in the IA and a Status Code option in the IA containing status code NoAddrsAvail. If so, there may be other IAs that do not contain NoAddrsAvail status code. In this case, what should the client do for the other IAs? Or, does Section 18.1.8 mean a NoAddrsAvail code in the DHCPv6 options field (i.e. not in an IA)? 5. Section 18.1.3 says: ...The client includes an IA option with all addresses currently assigned to the IA in its Renew message. and Section 18.2.3 has corresponding sentences: If the server finds that any of the addresses are not appropriate to the link to which the client is attached, the server returns the address to the client with lifetimes of 0. If the server finds the addresses in the IA for the client then the server sends back the IA to the client with new lifetimes and T1/T2 times. The server may choose to change the list of addresses and the lifetimes of addresses in IAs that are returned to the client. That is, (in my understanding) - the client sends all addresses for an IA to be renewed. - (if the binding is still valid) the server returns all the addresses for the IA with 0 or larger lifetimes. Now, what if the client finds a lack of addresses in the reply message for the IA? a) the client should ignore the entire IA (or the entire reply) b) the client should let the dropped address expire (unless there's no more update) c) others FYI: Our implementation currently takes the option b), though we do this for prefixes in an IA_PD option, not for addresses. 6. there seems to be a corner case about handling the Rapid Commit option. Section 17.1.3 says: ... If it does not receive such a Reply message and does receive a valid Advertise message, the client processes the Advertise message as described in section 17.1.3. But what should the client do if it receives a reply message for a solicit message with a Rapid Commit option after receiving an advertise message? Should the client ignore or accept it? In the latter case, what if the client has already sent a request message (then it will receive a different reply)? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 14 07:26:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21409; Tue, 14 Jan 2003 06:29:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EBgrJ21708; Tue, 14 Jan 2003 06:42:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0E5t1J21274 for ; Tue, 14 Jan 2003 00:55:01 -0500 Received: from helena.whitefang.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05759 for ; Tue, 14 Jan 2003 00:40:30 -0500 (EST) Received: (qmail 93091 invoked from network); 14 Jan 2003 05:44:08 -0000 Received: from helena.whitefang.com (216.254.175.50) by 0 with SMTP; 14 Jan 2003 05:44:08 -0000 Date: Tue, 14 Jan 2003 00:44:08 -0500 (EST) From: Thamer Al-Harbash X-X-Sender: shadows@helena.whitefang.com To: Ted Lemon cc: Thamer Al-Harbash , Erik Nordmark , Thomas Narten , zeroconf@merit.edu, Stuart Cheshire , dhcwg@ietf.org Subject: Re: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP In-Reply-To: <46C63EDB-2780-11D7-A7EA-00039367340A@nominum.com> Message-ID: References: <46C63EDB-2780-11D7-A7EA-00039367340A@nominum.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: , On Mon, 13 Jan 2003, Ted Lemon wrote: > BPF wasn't passing arp-reply packets at the time. Perhaps it does > now, or perhaps it's handled differently in lpf. I thought it was > rather odd at the time, but at the time fixing it wasn't my main > priority, so I didn't look any further. Might be that you filtered out ARP by only allowing UDP. Just a thought. > So the question is, what does this tell us? It tells us that we can do either ARP replies or requests in our UNIX dhcp clients and any UNIX-like operating systems (Mac OS X). There's nothing in RFC 2131 which says "don't send an ARP request." It just says: "The client SHOULD broadcast an ARP reply to announce the client's new IP address and clear any outdated ARP cache entries in hosts on the client's subnet." No need to update the RFC for this. Just send an ARP reply from the client and let the OS send all the requests it wants :-) -- Thamer Al-Harbash http://www.whitefang.com/ team dresch made me do it _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 14 09:24:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24889; Tue, 14 Jan 2003 09:24:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EEbnJ00312; Tue, 14 Jan 2003 09:37:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EEZRJ31994 for ; Tue, 14 Jan 2003 09:35:27 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24793 for ; Tue, 14 Jan 2003 09:20:45 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn1-158.cisco.com [10.82.224.158]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0EENOjT008423; Tue, 14 Jan 2003 06:23:24 -0800 (PST) Message-Id: <4.3.2.7.2.20030114083851.01e616a8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Jan 2003 09:23:57 -0500 To: Ted Lemon From: John Schnizlein Cc: Erik Nordmark , Thomas Narten , zeroconf@merit.edu, dhcwg@ietf.org In-Reply-To: References: <27AECC89-2389-11D7-8FB4-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: ARP reply vs. ARP request to announce address acquired from DHCP 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 am uncomfortable with the attribution of out-of-spec for DHCP clients. Since the recommendation (SHOULD) to send an ARP-reply is in the context of the client (excerpt below) checking that the offered address is actually available, the ARP-request, which you say most clients perform, appears perfectly reasonable. Since, without the ARP-request the client cannot send a DHCP-decline, it seems the ARP-request is desirable. In fact, performing both the ARP-request and the ARP-reply avoids the appearance of an unsolicited ARP on a network segment, which could be an attempt to steal an IP address. My opinion is that the ARP-announce, an ARP-reply without an ARP-request, would be questionable, and I was happy to see the ZeroConf specification moving away from it. RFC 2131 [Page 38 & 39] ... The client SHOULD perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the network address appears to be in use, the client MUST send a DHCPDECLINE message to the server. The client SHOULD broadcast an ARP reply to announce the client's new IP address and clear any outdated ARP cache entries in hosts on the client's subnet. John At 02:53 PM 1/13/2003, Ted Lemon wrote: >>>So were you commenting on the probe or the announcement? >> >>The announcement. All DHCP clients that I know of do the reply instead of the request - i.e., they're out of spec. :'} > >So, just to be clear about my faux pas last week, RFC2131 says to do an ARP *reply* to announce that it has its new IP address, but existing clients send an ARP *request* with the newly-acquired DHCP address in source and destination IP address fields ... > >So in fact all the DHCP clients of which I am aware are technically out of spec with RFC2131. I don't think this is a big problem, or that RFC2131 needs to be immediately updated. The language in RFC2131 is specifying generic behavior that all IP stacks should implement regardless of whether or not they support DHCP, and therefore RFC2131's recommendation is just that - a recommendation. So it's actually very helpful that Stuart is coming out with a document that's not DHCP-specific that states how this should be done, and it's also fine that it contradicts the recommendation stated in RFC2131. I'm not sure we need to say that this draft updates RFC2131 - I leave that up to those more knowledgable about the IETF process to decide. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 14 09:32:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25133; Tue, 14 Jan 2003 09:32:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EEkGJ00859; Tue, 14 Jan 2003 09:46:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EEjOJ00797 for ; Tue, 14 Jan 2003 09:45:24 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25046 for ; Tue, 14 Jan 2003 09:30:40 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h0EEY1d24750; Tue, 14 Jan 2003 08:34:01 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h0EEY1j09879; Tue, 14 Jan 2003 08:34:01 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 14 Jan 2003 08:34:01 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'JINMEI Tatuya / ????'" , dhcwg@ietf.org Subject: RE: [dhcwg] questions about dhcpv6-28 Date: Tue, 14 Jan 2003 08:32:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BBD9.C3F97C80" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BBD9.C3F97C80 Content-Type: text/plain; charset="ISO-2022-JP" Here's my take on these questions ... I don't see anything that would require any corrective text in the draft, though as always anything one writes is subject to interpretation! Writing the drafts (RFCs) is really much more complicated then it looks at first! I think your interpretation was correct which is good news! See below, prefixed by "BV>". - Bernie -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Tuesday, January 14, 2003 2:32 AM To: dhcwg@ietf.org Subject: [dhcwg] questions about dhcpv6-28 I have several questions on draft-ietf-dhc-dhcpv6-28.txt from my implementation experiences. (It is probably too late to reflect the points to the spec before it becomes an RFC, though.) I'd apologize in advance if some (or all) of them were addressed in the draft, but I could not find the answers. 1. Section 18.1.8 says: When the client receives a NoBinding status in an IA from the server in response to a Renew message or a Rebind message, the client sends a Request to reestablish an IA with the server. does this imply that the client must remove the IA before sending the request? (I guess the answer is YES, but I'm asking this to be sure.) BV> No. As long as the address has a valid lifetime left, the client BV> should be able to use that address. NoBinding just means that the BV> server has no record of that binding (perhaps it is a new server BV> or a server that losts its stable storage). While this situation BV> is not desireable, it is possible and should work out OK. 2. What should a client do if it receives an IA_NA in a reply message where T1 > T2 > 0? a) the client must ignore the option (or the entire reply message) b) the client must treat as if T1 = T2 c) the client must choose appropriate alternatives for T1 and T2. (this cannot be an option, though, because Section 22.4 says the client MUST use T1 and T2 if they are non-0) d) others FYI: Our implementation currently takes the option a). BV> (a) is probably a fine action as it really is invalid. T1 <= T2. 3. What should a server do when it receives a request message and already has a binding required in the request? (this can happen if the first reply was lost and the client resend the request message.) FYI: Our implementation currently updates parameters (e.g. lifetimes) of the binding and sends a reply with the parameters, just like the server receives a renew message for the binding. BV> A retransmitted Request (because the client failed to receive the BV> Reply) can either be treated as you describe or you can send the BV> current values (if they are still valid). A server might, for BV> example, have a cache of recently sent Replies and in this case it BV> may resend what it sent the first time. 4. Section 18.1.8 says When the client receives a NoAddrsAvail status from the server in response to a Request, the client can either try another server (perhaps restarting the DHCP server discovery process) or use the Information-Request to obtain configuration parameters only. This sentence is not very clear to me. I interpreted this sentence corresponds to the following part of Section 18.2.1: If the server cannot assign any addresses to an IA in the message from the client, the server MUST include the IA in the Reply message with no addresses in the IA and a Status Code option in the IA containing status code NoAddrsAvail. If so, there may be other IAs that do not contain NoAddrsAvail status code. In this case, what should the client do for the other IAs? BV> It should use those addresses or Release them. Or, does Section 18.1.8 mean a NoAddrsAvail code in the DHCPv6 options field (i.e. not in an IA)? BV> It is the status code option in the IA option. 5. Section 18.1.3 says: ...The client includes an IA option with all addresses currently assigned to the IA in its Renew message. and Section 18.2.3 has corresponding sentences: If the server finds that any of the addresses are not appropriate to the link to which the client is attached, the server returns the address to the client with lifetimes of 0. If the server finds the addresses in the IA for the client then the server sends back the IA to the client with new lifetimes and T1/T2 times. The server may choose to change the list of addresses and the lifetimes of addresses in IAs that are returned to the client. That is, (in my understanding) - the client sends all addresses for an IA to be renewed. - (if the binding is still valid) the server returns all the addresses for the IA with 0 or larger lifetimes. Now, what if the client finds a lack of addresses in the reply message for the IA? a) the client should ignore the entire IA (or the entire reply) b) the client should let the dropped address expire (unless there's no more update) c) others FYI: Our implementation currently takes the option b), though we do this for prefixes in an IA_PD option, not for addresses. BV> Option b is correct. The lifetime controls the when addresses on the BV> client expire. Thus, if a server stops Replying with that address, BV> the lifetimes will not be updated and eventually the address expires. 6. there seems to be a corner case about handling the Rapid Commit option. Section 17.1.3 says: ... If it does not receive such a Reply message and does receive a valid Advertise message, the client processes the Advertise message as described in section 17.1.3. But what should the client do if it receives a reply message for a solicit message with a Rapid Commit option after receiving an advertise message? Should the client ignore or accept it? In the latter case, what if the client has already sent a request message (then it will receive a different reply)? BV> The client must wait for a time period after sending a Solicit for BV> replies from servers. I assume you are saying what happens if after BV> this initial wait time (described in 17.1.2) the client receives BV> (or has received) an Advertise and uses it. But then while waiting BV> for the Reply (to the Request), it receives a (much delayed) Reply BV> with Rapid Commit? In that case, I think it is really implementation BV> dependent on what the client does. In my mind, I think it is easier BV> for the client to continue processing the Advertise / Request / Reply BV> procedure that it started. But, the client COULD use the Reply with BV> Rapid Commit if it wanted and it has an acceptable response (ie, BV> addresses). In either case, one set of server assigned addresses will BV> not end up being used by the client and the server will reclaim them BV> once the lifetimes expire. I think dropping the Reply w/Rapid Commit BV> is easier and better from an implementation standpoint (the reason BV> is that the client only needs to remember one thing - the Reply it BV> is waiting for and discards all others). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2BBD9.C3F97C80 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] questions about dhcpv6-28

Here's my take on these questions ... I don't see = anything that would require any
corrective text in the draft, though as always = anything one writes is subject to
interpretation! Writing the drafts (RFCs) is really = much more complicated then it
looks at first! I think your interpretation was = correct which is good news!

See below, prefixed by "BV>".

- Bernie

-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshi= ba.co.jp]
Sent: Tuesday, January 14, 2003 2:32 AM
To: dhcwg@ietf.org
Subject: [dhcwg] questions about dhcpv6-28


I have several questions on = draft-ietf-dhc-dhcpv6-28.txt from my
implementation experiences.  (It is probably = too late to reflect the
points to the spec before it becomes an RFC, = though.)

I'd apologize in advance if some (or all) of them = were addressed in
the draft, but I could not find the answers.

1. Section 18.1.8 says:

   When the client receives a NoBinding = status in an IA from the server
   in response to a Renew message or a = Rebind message, the client sends
   a Request to reestablish an IA with the = server.

does this imply that the client must remove the IA = before sending the
request?  (I guess the answer is YES, but I'm = asking this to be sure.)

BV> No. As long as the address has a valid = lifetime left, the client
BV> should be able to use that address. NoBinding = just means that the
BV> server has no record of that binding (perhaps = it is a new server
BV> or a server that losts its stable storage). = While this situation
BV> is not desireable, it is possible and should = work out OK.

2. What should a client do if it receives an IA_NA in = a reply message
   where T1 > T2 > 0?
   a) the client must ignore the option = (or the entire reply message)
   b) the client must treat as if T1 =3D = T2
   c) the client must choose appropriate = alternatives for T1 and T2.
    (this cannot be an option, = though, because Section 22.4 says the
     client MUST use T1 and T2 = if they are non-0)
   d) others

   FYI: Our implementation currently takes = the option a).

BV> (a) is probably a fine action as it really is = invalid. T1 <=3D T2.

3. What should a server do when it receives a request = message and
   already has a binding required in the = request?  (this can happen if
   the first reply was lost and the client = resend the request
   message.)

  FYI: Our implementation currently updates = parameters
  (e.g. lifetimes) of the binding and sends a = reply with the
  parameters, just like the server receives a = renew message for the
  binding.

BV> A retransmitted Request (because the client = failed to receive the
BV> Reply) can either be treated as you describe = or you can send the
BV> current values (if they are still valid). A = server might, for
BV> example, have a cache of recently sent = Replies and in this case it
BV> may resend what it sent the first = time.

4. Section 18.1.8 says

   When the client receives a NoAddrsAvail = status from the server in
   response to a Request, the client can = either try another server
   (perhaps restarting the DHCP server = discovery process) or use the
   Information-Request to obtain = configuration parameters only.

This sentence is not very clear to me.  I = interpreted this sentence
corresponds to the following part of Section = 18.2.1:

   If the server cannot assign any = addresses to an IA in the message
   from the client, the server MUST = include the IA in the Reply message
   with no addresses in the IA and a = Status Code option in the IA
   containing status code = NoAddrsAvail.

If so, there may be other IAs that do not contain = NoAddrsAvail status
code.  In this case, what should the client do = for the other IAs?

BV> It should use those addresses or Release = them.

Or, does Section 18.1.8 mean a NoAddrsAvail code in = the DHCPv6 options
field (i.e. not in an IA)?

BV> It is the status code option in the IA = option.

5. Section 18.1.3 says:

   ...The
   client includes an IA option with all = addresses currently assigned to
   the IA in its Renew message.

and Section 18.2.3 has corresponding = sentences:

   If the server finds that any of the = addresses are not appropriate
   to the link to which the client is = attached, the server returns the
   address to the client with lifetimes of = 0.

   If the server finds the addresses in the = IA for the client then the
   server sends back the IA to the client = with new lifetimes and T1/T2
   times.  The server may choose to = change the list of addresses and the
   lifetimes of addresses in IAs that are = returned to the client.

That is, (in my understanding)

- the client sends all addresses for an IA to be = renewed.
- (if the binding is still valid) the server returns = all the addresses
  for the IA with 0 or larger lifetimes.

Now, what if the client finds a lack of addresses in = the reply message
for the IA?

  a) the client should ignore the entire IA (or = the entire reply)
  b) the client should let the dropped address = expire (unless there's
     no more update)
  c) others

FYI: Our implementation currently takes the option = b), though we do
this for prefixes in an IA_PD option, not for = addresses.

BV> Option b is correct. The lifetime controls the = when addresses on the
BV> client expire. Thus, if a server stops = Replying with that address,
BV> the lifetimes will not be updated and = eventually the address expires.

6. there seems to be a corner case about handling the = Rapid Commit
   option.  Section 17.1.3 = says:

   ... If it does
   not receive such a Reply message and = does receive a valid Advertise
   message, the client processes the = Advertise message as described in
   section 17.1.3.

But what should the client do if it receives a reply = message for a
solicit message with a Rapid Commit option after = receiving an
advertise message?  Should the client ignore or = accept it?  In the
latter case, what if the client has already sent a = request message
(then it will receive a different reply)?

BV> The client must wait for a time period after = sending a Solicit for
BV> replies from servers. I assume you are saying = what happens if after
BV> this initial wait time (described in 17.1.2) = the client receives
BV> (or has received) an Advertise and uses it. = But then while waiting
BV> for the Reply (to the Request), it receives a = (much delayed) Reply
BV> with Rapid Commit? In that case, I think it = is really implementation
BV> dependent on what the client does. In my = mind, I think it is easier
BV> for the client to continue processing the = Advertise / Request / Reply
BV> procedure that it started. But, the client = COULD use the Reply with
BV> Rapid Commit if it wanted and it has an = acceptable response (ie,
BV> addresses). In either case, one set of server = assigned addresses will
BV> not end up being used by the client and the = server will reclaim them
BV> once the lifetimes expire. I think dropping = the Reply w/Rapid Commit
BV> is easier and better from an implementation = standpoint (the reason
BV> is that the client only needs to remember one = thing - the Reply it
BV> is waiting for and discards all = others).


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

------_=_NextPart_001_01C2BBD9.C3F97C80-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 14 10:14:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26796; Tue, 14 Jan 2003 10:14:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFSBJ03695; Tue, 14 Jan 2003 10:28:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EFR7J03630 for ; Tue, 14 Jan 2003 10:27:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26276; Tue, 14 Jan 2003 10:12:26 -0500 (EST) Message-Id: <200301141512.KAA26276@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 14 Jan 2003 10:12:26 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-packetcable-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 : DHCP Option for CableLabs Client Configuration Author(s) : B. Beser, P. Duffy Filename : draft-ietf-dhc-packetcable-05.txt Pages : 12 Date : 2003-1-13 This document defines a DHCP option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-packetcable-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-packetcable-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-packetcable-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-1-13141902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-packetcable-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-packetcable-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-13141902.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 14 10:52:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29315; Tue, 14 Jan 2003 10:52:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EG5YJ06959; Tue, 14 Jan 2003 11:05:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0EG4IJ06909 for ; Tue, 14 Jan 2003 11:04:18 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28970 for ; Tue, 14 Jan 2003 10:49:35 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18YTMz-0001Uv-00; Tue, 14 Jan 2003 07:52:53 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Jan 2003 07:57:56 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A678DA@homer.incognito.com.> From: "Kostur, Andre" To: "'Ted Lemon'" Cc: "'dhcwg@ietf.org'" Subject: RE: [dhcwg] Clarification on RFC 2131 and RFC 3046 Date: Tue, 14 Jan 2003 07:57:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BBE5.B3077330" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BBE5.B3077330 Content-Type: text/plain; charset="iso-8859-1" Sorry, I don't see how that clarifies. From my original message : Regarding the use of the Client Identifier option to identify a specific device: RFC 2131, Section 4.2 suggests that a DHCP server should use the Client Identifier supplied by the client device where possible, and to effectively synthesize one from the client's chaddr if the client does not supply one. (Actually, section 4.2 insists that a server uses the Client Identifier, if supplied). RFC 3046, Section 4.0 seems to downplay the use of the Client Identifier and encourages the combination of RemoteID and CHADDR to distinguish a device. If the use of a Client Identifier is discouraged, how would a device acquire multiple IP addresses from the DHCP server, since the server is encouraged to only use the RemoteID and CHADDR? (Perhaps we're talking about a set-top box that can do VoIP, and digital video. The device may want an IP for Voice, and a second IP for video, but only has 1 MAC address...?) Let's assume a physical setup of: DHCP <----> Router/Relay <----> Multifunction Device (MFD) And assume that the MFD has 1 ethernet card, but has three "services" each of which want an IP. According to how RFC 3046 reads, the DHCP service should try to distinguish the device by looking at only two things: the Remote ID (since all the requests are passing through the same relay, they're all coming from the same Remote ID), and the CHADDR (since all the requests are originating from the same Ethernet card, they're all coming from the same CHADDR). With only those two criteria, the DHCP server would see the _same_ device requesting 3 times, and would ACK with the same IP address three times. If RFC 3046 allowed (and/or insisted) on the same process as RFC 2131 (using the Client Identifier), the MFD could change the Client Identifier supplied with each request so that the DHCP server would interpret the 3 incoming Discovers as actually being discovers for 3 different addresses (since from DHCP's point of view, it would be 3 distinct devices requesting). > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Monday, January 13, 2003 7:29 PM > To: Kostur, Andre > Cc: 'dhcwg@ietf.org' > Subject: Re: [dhcwg] Clarification on RFC 2131 and RFC 3046 > > > Remote-id identifies the relay agent, not the DHCP client. > ------_=_NextPart_001_01C2BBE5.B3077330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Clarification on RFC 2131 and RFC 3046

Sorry, I don't see how that clarifies.  From my = original message :

Regarding the use of the Client Identifier option to = identify a specific device:

RFC 2131, Section 4.2 suggests that a DHCP server = should use the Client Identifier supplied by the client device where = possible, and to effectively synthesize one from the client's chaddr if = the client does not supply one.  (Actually, section 4.2 insists = that a server uses the Client Identifier, if supplied).

RFC 3046, Section 4.0 seems to downplay the use of = the Client Identifier and encourages the combination of RemoteID and = CHADDR to distinguish a device.  If the use of a Client Identifier = is discouraged, how would a device acquire multiple IP addresses from = the DHCP server, since the server is encouraged to only use the = RemoteID and CHADDR?  (Perhaps we're talking about a set-top box = that can do VoIP, and digital video.  The device may want an IP = for Voice, and a second IP for video, but only has 1 MAC = address...?)


Let's assume a physical setup of:

DHCP <----> Router/Relay <----> = Multifunction Device (MFD)

And assume that the MFD has 1 ethernet card, but has = three "services" each of which want an IP.  According to = how RFC 3046 reads, the DHCP service should try to distinguish the = device by looking at only two things: the Remote ID (since all the = requests are passing through the same relay, they're all coming from = the same Remote ID), and the CHADDR (since all the requests are = originating from the same Ethernet card, they're all coming from the = same CHADDR).  With only those two criteria, the DHCP server would = see the _same_ device requesting 3 times, and would ACK with the same = IP address three times.  If RFC 3046 allowed (and/or insisted) on = the same process as RFC 2131 (using the Client Identifier), the MFD = could change the Client Identifier supplied with each request so that = the DHCP server would interpret the 3 incoming Discovers as actually = being discovers for 3 different addresses (since from DHCP's point of = view, it would be 3 distinct devices requesting).

> -----Original Message-----
> From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
> Sent: Monday, January 13, 2003 7:29 PM
> To: Kostur, Andre
> Cc: 'dhcwg@ietf.org'
> Subject: Re: [dhcwg] Clarification on RFC 2131 = and RFC 3046
>
>
> Remote-id identifies the relay agent, not the = DHCP client.
>

------_=_NextPart_001_01C2BBE5.B3077330-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 14 16:05:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11654; Tue, 14 Jan 2003 16:05:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ELIgJ02371; Tue, 14 Jan 2003 16:18:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ELGlJ02294 for ; Tue, 14 Jan 2003 16:16:47 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11533 for ; Tue, 14 Jan 2003 16:01:57 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0EL61QW008854 for ; Tue, 14 Jan 2003 16:06:01 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-172.cisco.com [10.82.240.172]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA12881 for ; Tue, 14 Jan 2003 16:05:16 -0500 (EST) Message-Id: <4.3.2.7.2.20030114160233.03d896c0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Jan 2003 16:05:08 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Scheduling dhc WG meeting at IETF 56 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've asked that the dhc WG meeting in SF avoid scheduling conflicts with the following WGs: dnsext, dnsop, geopriv, ipcdn, ipv6, nemo, v6ops Please let me know if there are any other WGs you'd like to avoid scehduling conflicts with. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 15 00:57:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23284; Wed, 15 Jan 2003 00:57:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F651J02267; Wed, 15 Jan 2003 01:05:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F63dJ02219 for ; Wed, 15 Jan 2003 01:03:39 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23191 for ; Wed, 15 Jan 2003 00:48:40 -0500 (EST) Received: from nominum.com (cs6625147-195.austin.rr.com [66.25.147.195]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0F5mrP10385; Tue, 14 Jan 2003 23:48:53 -0600 (CST) Date: Tue, 14 Jan 2003 23:51:56 -0600 Subject: Re: [dhcwg] Clarification on RFC 2131 and RFC 3046 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'dhcwg@ietf.org'" To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A678DA@homer.incognito.com.> Message-Id: <74DA3B26-284D-11D7-A3B4-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The remote ID is part of the relay agent information option, which is sent by the *relay agent*, not by the client. The client *never* sends the relay agent information option, and thus *never* sends a remote ID. So if you are trying to identify the client, you absolutely *cannot* use the remote ID to do it, because it didn't come from the client. When RFC3046 talks about using the remote ID to identify a device, it is not talking about the DHCP client - it is talking about the DHCP relay agent. The two RFCs are talking about different things, and thus are not at all in conflict. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 15 01:01:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23414; Wed, 15 Jan 2003 01:01:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F696J03027; Wed, 15 Jan 2003 01:09:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0F684J02979 for ; Wed, 15 Jan 2003 01:08:04 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23231 for ; Wed, 15 Jan 2003 00:53:04 -0500 (EST) Received: from nominum.com (cs6625147-195.austin.rr.com [66.25.147.195]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0F5rFP10417; Tue, 14 Jan 2003 23:53:15 -0600 (CST) Date: Tue, 14 Jan 2003 23:56:19 -0600 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Erik Nordmark , Thomas Narten , zeroconf@merit.edu, dhcwg@ietf.org To: John Schnizlein From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030114083851.01e616a8@wells.cisco.com> Message-Id: <118CA449-284E-11D7-A3B4-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: ARP reply vs. ARP request to announce address acquired from DHCP 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 The text there says that the client should send the ARP *request* to check for a conflict. The ARP request is supposed to use an IP address of 0.0.0.0 as the sending station's IP address, so as to avoid asserting that the sending station has the assigned IP address. Only after this ARP request has failed to identify a conflict does the client send a message asserting that it has the IP address it has been assigned. So the client sends two ARP packets - an ARP request and an ARP reply. What the proposed draft does is to change the recommended behavior for asserting an IP address using ARP so that this is done with an ARP request rather than an ARP reply. You should take a look at the zeroconf mailing list archives to see Stuart's proposed text that explains why this is the right thing to do. I'm sorry that some of this stuff got cross-posted to DHCwg and some didn't, so that you don't have the full context. This whole thing is _very_ confusing, so it's a really good thing that Stuart is trying to clarify it. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 15 07:59:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24541; Wed, 15 Jan 2003 07:59:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDDiJ08037; Wed, 15 Jan 2003 08:13:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FDCmJ07978 for ; Wed, 15 Jan 2003 08:12:48 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24233; Wed, 15 Jan 2003 07:57:39 -0500 (EST) Message-Id: <200301151257.HAA24233@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, 15 Jan 2003 07:57:39 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-packetcable-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 : DHCP Option for CableLabs Client Configuration Author(s) : B. Beser, P. Duffy Filename : draft-ietf-dhc-packetcable-06.txt Pages : 12 Date : 2003-1-14 This document defines a DHCP option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-packetcable-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-packetcable-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-packetcable-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-1-14150902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-packetcable-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-packetcable-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-14150902.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 Jan 15 10:20:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29713; Wed, 15 Jan 2003 10:20:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFYaJ17804; Wed, 15 Jan 2003 10:34:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FFXrJ17678 for ; Wed, 15 Jan 2003 10:33:53 -0500 Received: from e35.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29567 for ; Wed, 15 Jan 2003 10:18:41 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0FFM2eP112086 for ; Wed, 15 Jan 2003 10:22:02 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0FFM189037732 for ; Wed, 15 Jan 2003 08:22:02 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h0FFLJV01631 for ; Wed, 15 Jan 2003 10:21:19 -0500 Message-Id: <200301151521.h0FFLJV01631@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 15 Jan 2003 10:21:19 -0500 From: Thomas Narten Subject: [dhcwg] Root Path and DHCPv6 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: , A set of ISCSI documents are making their way through the IESG. My review of draft-ietf-ips-iscsi-boot-08.txt included the following comment: > > A DHCP server (v4 or v6) MAY instruct an iSCSI client how to reach > > its boot device. This is done using the variable length DHCP option > > named Root Path. The use of the option field is reserved for iSCSI > > boot use by prefacing the string with "iscsi:". > > should reference the Root Path RFC (2132 I believe). And, I don't > think there is a Root Path option in DHCPv6. This should be taken to > the DHC WG for followup, if appropriate... Is the whole topic of using DHCPv6 for booting something the WG needs to think about, or is this an easy add on? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 15 11:15:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01608; Wed, 15 Jan 2003 11:15:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGTGJ22232; Wed, 15 Jan 2003 11:29:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGOWJ21977 for ; Wed, 15 Jan 2003 11:24:32 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01379 for ; Wed, 15 Jan 2003 11:09:19 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h0FGCdW21278; Wed, 15 Jan 2003 10:12:39 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h0FGCdq18515; Wed, 15 Jan 2003 10:12:39 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 15 Jan 2003 10:12:39 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] Root Path and DHCPv6 Date: Wed, 15 Jan 2003 10:11:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BCB0.B83642E8" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BCB0.B83642E8 Content-Type: text/plain; charset="iso-8859-1" Thomas: I believe that the communication of the booting information should be fairly easy and straight forward as a set of option definitions. The WG can work on it when someone submits an I-D? - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, January 15, 2003 10:21 AM To: dhcwg@ietf.org Subject: [dhcwg] Root Path and DHCPv6 A set of ISCSI documents are making their way through the IESG. My review of draft-ietf-ips-iscsi-boot-08.txt included the following comment: > > A DHCP server (v4 or v6) MAY instruct an iSCSI client how to reach > > its boot device. This is done using the variable length DHCP option > > named Root Path. The use of the option field is reserved for iSCSI > > boot use by prefacing the string with "iscsi:". > > should reference the Root Path RFC (2132 I believe). And, I don't > think there is a Root Path option in DHCPv6. This should be taken to > the DHC WG for followup, if appropriate... Is the whole topic of using DHCPv6 for booting something the WG needs to think about, or is this an easy add on? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2BCB0.B83642E8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Root Path and DHCPv6

Thomas:

I believe that the communication of the booting = information should be fairly easy
and straight forward as a set of option definitions. = The WG can work on it when
someone submits an I-D?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, January 15, 2003 10:21 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Root Path and DHCPv6


A set of ISCSI documents are making their way through = the IESG. My
review of draft-ietf-ips-iscsi-boot-08.txt included = the following
comment:

> >    A DHCP server (v4 or v6) = MAY instruct an iSCSI client how to reach
> >    its boot device. This is = done using the variable length DHCP option
> >    named Root Path. The use = of the option field is reserved for iSCSI
> >    boot use by prefacing = the string with "iscsi:".
>
> should reference the Root Path RFC (2132 I = believe). And, I don't
> think there is a Root Path option in DHCPv6. = This should be taken to
> the DHC WG for followup, if = appropriate...

Is the whole topic of using DHCPv6 for booting = something the WG needs
to think about, or is this an easy add on?

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

------_=_NextPart_001_01C2BCB0.B83642E8-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 15 11:26:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02107; Wed, 15 Jan 2003 11:26:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGeTJ23746; Wed, 15 Jan 2003 11:40:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FGd6J23648 for ; Wed, 15 Jan 2003 11:39:06 -0500 Received: from smtp014.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01988 for ; Wed, 15 Jan 2003 11:23:55 -0500 (EST) Received: from adsl-64-170-116-140.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.116.140 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Jan 2003 16:27:14 -0000 Reply-To: From: "rbhibbs" To: Subject: RE: [dhcwg] Root Path and DHCPv6 Date: Wed, 15 Jan 2003 08:26:28 -0800 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.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200301151521.h0FFLJV01631@rotala.raleigh.ibm.com> Importance: Normal 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 Doesn't seem at first glance to hold any major surprises: will the authors of the iSCSI boot draft be submitting a DHCP option draft to cover their needs for a boot path? --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Thomas Narten > Sent: Wednesday, January 15, 2003 07:21 > > A set of ISCSI documents are making their way through the IESG. My > review of draft-ietf-ips-iscsi-boot-08.txt included the following > comment: > > > > A DHCP server (v4 or v6) MAY instruct an iSCSI client how to reach > > > its boot device. This is done using the variable length DHCP option > > > named Root Path. The use of the option field is reserved for iSCSI > > > boot use by prefacing the string with "iscsi:". > > > > should reference the Root Path RFC (2132 I believe). And, I don't > > think there is a Root Path option in DHCPv6. This should be taken to > > the DHC WG for followup, if appropriate... > > Is the whole topic of using DHCPv6 for booting something the WG needs > to think about, or is this an easy add on? > > 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 Wed Jan 15 12:13:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03779; Wed, 15 Jan 2003 12:13:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHRNJ27312; Wed, 15 Jan 2003 12:27:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FHLqJ26912 for ; Wed, 15 Jan 2003 12:21:52 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03401 for ; Wed, 15 Jan 2003 12:06:39 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18Yr38-0007Gt-00; Wed, 15 Jan 2003 09:09:58 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 09:15:03 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A678EF@homer.incognito.com.> From: "Kostur, Andre" To: "'Ted Lemon'" , "Kostur, Andre" Cc: "'dhcwg@ietf.org'" Subject: RE: [dhcwg] Clarification on RFC 2131 and RFC 3046 Date: Wed, 15 Jan 2003 09:14:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BCB9.A1991110" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BCB9.A1991110 Content-Type: text/plain; charset="iso-8859-1" I think you're misunderstanding my question. At no point have I suggested that the DHCP server uses the remote ID as the only piece of information used to distinguish a client. RFC 2131, section 4.2 dictates that a DHCP server must use the Client Identifier (if supplied, CHADDR if it's not) to identify a client. RFC 3046, section 4.0 suggests that the DHCP server uses the CHADDR and Remote ID to identify a client. Both pieces are used to prevent end-users from spoofing CHADDRs, but does not acknowledge that the Client ID must (or should) be used if the client supplied it. My question (rephrased): Let's look at the block diagram in RFC 3046 (so we have a common point of reference): +---------------+ | Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A LAN | | Access | Lan |- Host B | | Unit 1 | |- Host C |-----| |-- | | |(relay agent) |... +---------+ | +---------------+ | DHCP |--| | Server | | +---------+ | | | +---------------+ +---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D | Other | | | Access | Lan | Servers |--|-----| Unit 2 | | (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E | DNS) | | |(relay agent) |... Lan | | +---------------+ +---------+ Again, let's assume that Host D needs to have multiple IP addresses assigned to it. Perhaps that end-user is purchasing VoIP services from one ISP, Digital Video from a second ISP, and WebTV browsing from a third, and the IPs for those services only go to certain IP blocks, so each component would have it's own IP address. When Host D makes the three requests, the packets arriving at the DHCP server would be (other fields are uninteresting for the purposes of discussion): Packet 1: CHADDR == HostD, RemoteID == Modem2, GIADDR == CircuitAccessUnit2, ClientID == HostD+VoIP Packet 2: CHADDR == HostD, RemoteID == Modem2, GIADDR == CircuitAccessUnit2, ClientID == HostD+DTV Packet 3: CHADDR == HostD, RemoteID == Modem2, GIADDR == CircuitAccessUnit2, ClientID == HostD+WebTV Under RFC 2131, these three packets would be treated as three distinct clients since each one has a distinct ClientID. Under RFC 3046, those three packets would be treated as coming from the same client, since it doesn't encourage the use of the ClientID for identifying clients. The reasoning that 3046 uses for ignoring the Client ID: By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifier field need not be used by the DHCP server. Seems to be somewhat weak. The issues of client ID spoofing are the same ones that they touch on in discussing CHADDR spoofing: By associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same MAC address on a different remote ID. If you replace "MAC address" with "Client ID", you would be offering the same protection against ClientID spoofing. By associating the Client ID with the Remote ID, an end-user can only interfere with other devices on his own network. The point I'm trying to understand is why 3046 is downplaying, if not removing the use of the Client Identifier in distinguishing between clients? > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Tuesday, January 14, 2003 9:52 PM > To: Kostur, Andre > Cc: 'dhcwg@ietf.org' > Subject: Re: [dhcwg] Clarification on RFC 2131 and RFC 3046 > > > The remote ID is part of the relay agent information option, which is > sent by the *relay agent*, not by the client. The client *never* > sends the relay agent information option, and thus *never* sends a > remote ID. So if you are trying to identify the client, you > absolutely *cannot* use the remote ID to do it, because it > didn't come > from the client. > > When RFC3046 talks about using the remote ID to identify a device, it > is not talking about the DHCP client - it is talking about the DHCP > relay agent. The two RFCs are talking about different things, and > thus are not at all in conflict. > ------_=_NextPart_001_01C2BCB9.A1991110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Clarification on RFC 2131 and RFC 3046

I think you're misunderstanding my question.  At = no point have I suggested that the DHCP server uses the remote ID as = the only piece of information used to distinguish a client.  =

RFC 2131, section 4.2 dictates that a DHCP server = must use the Client Identifier (if supplied, CHADDR if it's not) to = identify a client.

RFC 3046, section 4.0 suggests that the DHCP server = uses the CHADDR and Remote ID to identify a client.  Both pieces = are used to prevent end-users from spoofing CHADDRs, but does not = acknowledge that the Client ID must (or should) be used if the client = supplied it.

My question (rephrased):

Let's look at the block diagram in RFC 3046 (so we = have a common point of reference):

          &nb= sp;        = +---------------+         &= nbsp;           &= nbsp;    |
     = Central       |   = Circuit     |-- ckt 1--- Modem1-- Host-|- Host = A
     LAN     = |     |   = Access      = |            = ;         Lan  |- Host = B
          &nb= sp;  |     |   Unit = 1      = |            = ;            = ;  |- Host C
          &nb= sp;  = |-----|           = ;    = |--           &nb= sp;            = |
          &nb= sp;  |     |(relay agent)  |...
+---------+  |     = +---------------+
|  DHCP   |--|
| Server  |  |
+---------+  |
          &nb= sp;  |
          &nb= sp;  |     +---------------+
+---------+  |     = |   Circuit     |-- ckt 1--- Modem2-- = Host--- Host D
| Other   |  = |     |   = Access      = |            = ;         Lan
| Servers |--|-----|   Unit = 2      |
|  (Web,  |  = |     = |            = ;   |-- ckt 2--- Modem3-- Host--- Host E
|   DNS)  |  = |     |(relay agent)  = |...           &n= bsp;      Lan
|         = |        +---------------+
+---------+


Again, let's assume that Host D needs to have = multiple IP addresses assigned to it.  Perhaps that end-user is = purchasing VoIP services from one ISP, Digital Video from a second ISP, = and WebTV browsing from a third, and the IPs for those services only go = to certain IP blocks, so each component would have it's own IP = address.

When Host D makes the three requests, the packets = arriving at the DHCP server would be (other fields are uninteresting = for the purposes of discussion):

Packet 1: CHADDR =3D=3D HostD, RemoteID =3D=3D = Modem2, GIADDR =3D=3D CircuitAccessUnit2, ClientID =3D=3D = HostD+VoIP

Packet 2: CHADDR =3D=3D HostD, RemoteID =3D=3D = Modem2, GIADDR =3D=3D CircuitAccessUnit2, ClientID =3D=3D = HostD+DTV

Packet 3: CHADDR =3D=3D HostD, RemoteID =3D=3D = Modem2, GIADDR =3D=3D CircuitAccessUnit2, ClientID =3D=3D = HostD+WebTV

Under RFC 2131, these three packets would be treated = as three distinct clients since each one has a distinct ClientID.  = Under RFC 3046, those three packets would be treated as coming from the = same client, since it doesn't encourage the use of the ClientID for = identifying clients.

The reasoning that 3046 uses for ignoring the Client = ID:

      By using the = agent-supplied Agent Remote ID option, the untrusted
      and as-yet = unstandardized client identifier field need not be used
      by the DHCP = server.

Seems to be somewhat weak.  The issues of client = ID spoofing are the same ones that they touch on in discussing CHADDR = spoofing:

      By associating a MAC = address with an Agent Remote ID, the DHCP
      server can prevent = offering an IP address to an attacker spoofing
      the same MAC address = on a different remote ID.

If you replace "MAC address" with = "Client ID", you would be offering the same protection = against ClientID spoofing.  By associating the Client ID with the = Remote ID, an end-user can only interfere with other devices on his own = network.

The point I'm trying to understand is why 3046 is = downplaying, if not removing the use of the Client Identifier in = distinguishing between clients?

> -----Original Message-----
> From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
> Sent: Tuesday, January 14, 2003 9:52 PM
> To: Kostur, Andre
> Cc: 'dhcwg@ietf.org'
> Subject: Re: [dhcwg] Clarification on RFC 2131 = and RFC 3046
>
>
> The remote ID is part of the relay agent = information option, which is
> sent by the *relay agent*, not by the = client.   The client *never*
> sends the relay agent information option, and = thus *never* sends a
> remote ID.   So if you are trying to = identify the client, you
> absolutely *cannot* use the remote ID to do it, = because it
> didn't come
> from the client.
>
> When RFC3046 talks about using the remote ID to = identify a device, it
> is not talking about the DHCP client - it is = talking about the DHCP
> relay agent.   The two RFCs are = talking about different things, and
> thus are not at all in conflict.
>

------_=_NextPart_001_01C2BCB9.A1991110-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 15 13:35:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06149; Wed, 15 Jan 2003 13:35:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FInYJ00764; Wed, 15 Jan 2003 13:49:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FImXJ00718 for ; Wed, 15 Jan 2003 13:48:33 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06101 for ; Wed, 15 Jan 2003 13:33:18 -0500 (EST) Received: from nominum.com (cs6625147-195.austin.rr.com [66.25.147.195]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0FIXSP19954; Wed, 15 Jan 2003 12:33:28 -0600 (CST) Date: Wed, 15 Jan 2003 12:36:39 -0600 Subject: Re: [dhcwg] Clarification on RFC 2131 and RFC 3046 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'dhcwg@ietf.org'" To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A678EF@homer.incognito.com.> Message-Id: <48D5488E-28B8-11D7-A3B4-00039317663C@nominum.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0FImXJ00719 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit > RFC 3046, section 4.0 suggests that the DHCP server uses the CHADDR > and Remote ID to identify a client.  Both pieces are used to prevent > end-users from spoofing CHADDRs, but does not acknowledge that the > Client ID must (or should) be used if the client supplied it. *Yikes*!!! Now I see what you're talking about. There is some seriously bad language in RFC3046 that we didn't catch. RFC3046 implies that the client identifier option is not what you should use to identify the client. This is completely untrue. In order for this to be true, RFC3046 would have to contain a statement saying that it updates certain aspects of RFC2131, and it does not contain any such statement. I think the WG needs to rev RFC3046 to fix this language. I'm sorry for being so obtuse about this. Ralph? :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 15 17:35:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12701; Wed, 15 Jan 2003 17:35:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMngJ17007; Wed, 15 Jan 2003 17:49:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FMk7J16687 for ; Wed, 15 Jan 2003 17:46:07 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12480 for ; Wed, 15 Jan 2003 17:30:48 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0FMYkGO000890; Wed, 15 Jan 2003 17:34:46 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-316.cisco.com [10.82.241.60]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA14339; Wed, 15 Jan 2003 17:34:00 -0500 (EST) Message-Id: <4.3.2.7.2.20030115161008.03e7c688@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Jan 2003 17:33:52 -0500 To: "Kostur, Andre" From: Ralph Droms Subject: RE: [dhcwg] Clarification on RFC 2131 and RFC 3046 Cc: "'Ted Lemon'" , "Kostur, Andre" , "'dhcwg@ietf.org'" In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A678EF@homer.incognito.com .> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Andre, Thanks for catching this problem, and for your patience in bringing us all up to speed. So, there a discrepancy or conflict between section 4of RFC3046 (specifically text about use of client ID) and RFC2131. I agree that the discrepancy should be addressed formally by the dhc WG. Any objections from the WG? To address the discrepancy, I think that RFC3046 should be brought into line with RFC2131 regarding the use of client id. Agreed? Assuming we've gotten this far without objection, the next step would be to generate the appropriate text or edits for RFC3046. Once we've determined the text, we can determine the strategy for publishing the fix - for example, revving RFC3046. Any volunteers to generate that text? - Ralph At 09:14 AM 1/15/2003 -0800, Kostur, Andre wrote: >I think you're misunderstanding my question. At no point have I suggested >that the DHCP server uses the remote ID as the only piece of information >used to distinguish a client. > >RFC 2131, section 4.2 dictates that a DHCP server must use the Client >Identifier (if supplied, CHADDR if it's not) to identify a client. > >RFC 3046, section 4.0 suggests that the DHCP server uses the CHADDR and >Remote ID to identify a client. Both pieces are used to prevent end-users >from spoofing CHADDRs, but does not acknowledge that the Client ID must >(or should) be used if the client supplied it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 15 17:54:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13447; Wed, 15 Jan 2003 17:54:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FN8MJ18890; Wed, 15 Jan 2003 18:08:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0FN7uJ18854 for ; Wed, 15 Jan 2003 18:07:56 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13384 for ; Wed, 15 Jan 2003 17:52:35 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18YwRk-0000lF-00; Wed, 15 Jan 2003 14:55:44 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Jan 2003 15:00:49 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67900@homer.incognito.com.> From: "Kostur, Andre" To: "'Ralph Droms'" , "Kostur, Andre" Cc: "'Ted Lemon'" , "'dhcwg@ietf.org'" Subject: RE: [dhcwg] Clarification on RFC 2131 and RFC 3046 Date: Wed, 15 Jan 2003 15:00:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BCE9.EF5397B0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BCE9.EF5397B0 Content-Type: text/plain; charset="iso-8859-1" You're welcome :) And, I volunteer to submit the text. > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, January 15, 2003 2:34 PM > To: Kostur, Andre > Cc: 'Ted Lemon'; Kostur, Andre; 'dhcwg@ietf.org' > Subject: RE: [dhcwg] Clarification on RFC 2131 and RFC 3046 > > > Andre, > > Thanks for catching this problem, and for your patience in > bringing us all > up to speed. > > So, there a discrepancy or conflict between section 4of RFC3046 > (specifically text about use of client ID) and RFC2131. I > agree that the > discrepancy should be addressed formally by the dhc WG. Any > objections > from the WG? > > To address the discrepancy, I think that RFC3046 should be > brought into > line with RFC2131 regarding the use of client id. Agreed? > > Assuming we've gotten this far without objection, the next > step would be to > generate the appropriate text or edits for RFC3046. Once > we've determined > the text, we can determine the strategy for publishing the fix - for > example, revving RFC3046. > > Any volunteers to generate that text? > > - Ralph ------_=_NextPart_001_01C2BCE9.EF5397B0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Clarification on RFC 2131 and RFC 3046

You're welcome :)

And, I volunteer to submit the text.

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Wednesday, January 15, 2003 2:34 PM
> To: Kostur, Andre
> Cc: 'Ted Lemon'; Kostur, Andre; 'dhcwg@ietf.org'
> Subject: RE: [dhcwg] Clarification on RFC 2131 and RFC 3046
>
>
> Andre,
>
> Thanks for catching this problem, and for your patience in
> bringing us all
> up to speed.
>
> So, there a discrepancy or conflict between section 4of RFC3046
> (specifically text about use of client ID) and RFC2131.  I
> agree that the
> discrepancy should be addressed formally by the dhc WG.  Any
> objections
> from the WG?
>
> To address the discrepancy, I think that RFC3046 should be
> brought into
> line with RFC2131 regarding the use of client id.  Agreed?
>
> Assuming we've gotten this far without objection, the next
> step would be to
> generate the appropriate text or edits for RFC3046.  Once
> we've determined
> the text, we can determine the strategy for publishing the fix - for
> example, revving RFC3046.
>
> Any volunteers to generate that text?
>
> - Ralph

------_=_NextPart_001_01C2BCE9.EF5397B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 16 17:15:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25308; Thu, 16 Jan 2003 17:15:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMTwJ28653; Thu, 16 Jan 2003 17:29:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GMRTJ28552 for ; Thu, 16 Jan 2003 17:27:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25242; Thu, 16 Jan 2003 17:11:38 -0500 (EST) Message-Id: <200301162211.RAA25242@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , dhcwg@ietf.org From: The IESG Date: Thu, 16 Jan 2003 17:11:38 -0500 Subject: [dhcwg] Protocol Action: DHCP Option for CableLabs Client Configuration to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'DHCP Option for CableLabs Client Configuration' as a Proposed Standard. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Thomas Narten and Erik Nordmark. Technical Summary This document defines a DHCP option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. Working Group Summary There was support for this option in the WG. No issues were raised during IETF Last Call. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 16 19:01:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26973; Thu, 16 Jan 2003 19:01:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0G4J02838; Thu, 16 Jan 2003 19:16:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0CYJ02735 for ; Thu, 16 Jan 2003 19:12:34 -0500 Received: from chimera.incognito.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26891 for ; Thu, 16 Jan 2003 18:56:39 -0500 (EST) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by chimera.incognito.com with smtp (Exim 3.35 #1 (Debian)) id 18ZJvU-0006Jr-00 for ; Thu, 16 Jan 2003 16:00:00 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Jan 2003 16:05:06 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A67915@homer.incognito.com.> From: "Kostur, Andre" To: "'dhcwg@ietf.org'" Date: Thu, 16 Jan 2003 16:04:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BDBC.10D82FE0" Subject: [dhcwg] Clarification proposed for RFC 3046 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2BDBC.10D82FE0 Content-Type: text/plain; charset="iso-8859-1" RFC 3046, as currently written, seems to downplay the use of a Client Identifier in distinguishing between DHCP clients. For example, in section 4.0, RFC 3046 states: "Client Identifier Spoofing By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifier field need not be used by the DHCP server." This is a much different statement than what RFC 2131 has to say about using Client Identifiers in distinguishing between DHCP clients: "If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client." Note that 2131 says "MUST" and 3046 says "need not be used". These two seem to be contrary to each other. So I propose the following changes to RFC 3046. In section 4.0: Change the text: DHCP Address Exhaustion In general, the DHCP server may be extended to maintain a database with the "triplet" of (client IP address, client MAC address, client remote ID) The DHCP server SHOULD implement policies that restrict the number of IP addresses to be assigned to a single remote ID. to the following: DHCP Administrative Controls A DHCP server needs to use some unique identifier to associate a client with its lease. A DHCP server MUST use the same logic as specified in Section 4.2 of RFC 2131 with the addition that the remote ID MUST also be used in the unique identifier. The DHCP server SHOULD implement policies that restrict the number of IP addresses to be assigned to a single remote ID. Also in section 4.0: Change the text: Client Identifier Spoofing By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifier field need not be used by the DHCP server. MAC Address Spoofing By associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same MAC address on a different remote ID. to the following: Client Identifier Spoofing By associating a Client Identifier with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same Client Identifier on a different Agent Remote ID. MAC Address Spoofing Similar to Client Identifier Spoofing, by associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same MAC address on a different Agent Remote ID. And since we're talking about 3046, there's a typo in section 1.2 (DHCP is shown as DCHP in the second line). The current text: DHCP broadcast replies can be routed to only the proper circuit, avoiding, say, the replication of the DCHP reply broadcast onto thousands of access circuits; should be changed to: DHCP broadcast replies can be routed to only the proper circuit, avoiding, say, the replication of the DHCP reply broadcast onto thousands of access circuits; ------_=_NextPart_001_01C2BDBC.10D82FE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Clarification proposed for RFC 3046

RFC 3046, as currently written, seems to downplay the = use of a Client Identifier
in distinguishing between DHCP clients.  For = example, in section 4.0, RFC 3046
states:

   "Client Identifier Spoofing

      By using the = agent-supplied Agent Remote ID option, the untrusted
      and as-yet = unstandardized client identifier field need not be used
      by the DHCP = server."

This is a much different statement than what RFC 2131 = has to say about
using Client Identifiers in distinguishing between = DHCP clients:

   "If the client
   supplies a 'client identifier', the = client MUST use the same 'client
   identifier' in all subsequent messages, = and the server MUST use that
   identifier to identify the = client."

Note that 2131 says "MUST" and 3046 says = "need not be used".  These two
seem to be contrary to each other.  So I = propose the following changes
to RFC 3046.

In section 4.0:

Change the text:

   DHCP Address Exhaustion

      In general, the DHCP = server may be extended to maintain a database
      with the = "triplet" of

          &nb= sp; (client IP address,  client MAC address,  client remote = ID)

      The DHCP server SHOULD = implement policies that restrict the number
      of IP addresses to be = assigned to a single remote ID.

to the following:

   DHCP Administrative Controls

          A = DHCP server needs to use some unique identifier to associate a
          = client with its lease.  A DHCP server MUST use the same logic = as
          = specified in Section 4.2 of RFC 2131 with the addition that the
          = remote ID MUST also be used in the unique identifier. 

        The DHCP = server SHOULD implement policies that restrict the number
          of = IP addresses to be assigned to a single remote ID.


Also in section 4.0:

Change the text:

   Client Identifier Spoofing

      By using the = agent-supplied Agent Remote ID option, the untrusted
      and as-yet = unstandardized client identifier field need not be used
      by the DHCP = server.

   MAC Address Spoofing

      By associating a MAC = address with an Agent Remote ID, the DHCP
      server can prevent = offering an IP address to an attacker spoofing
      the same MAC address = on a different remote ID.

to the following:

   Client Identifier Spoofing

      By associating a = Client Identifier with an Agent Remote ID, the DHCP
      server can prevent = offering an IP address to an attacker spoofing
        the same = Client Identifier on a different Agent Remote ID.

   MAC Address Spoofing

      Similar to Client = Identifier Spoofing, by associating a MAC address
      with an Agent Remote = ID, the DHCP server can prevent offering an IP
      address to an = attacker spoofing the same MAC address on a different
      Agent Remote = ID.



And since we're talking about 3046, there's a typo in = section 1.2 (DHCP is
shown as DCHP in the second line).  The current = text:

   DHCP broadcast replies can be routed to = only the proper circuit,
   avoiding, say, the replication of the = DCHP reply broadcast onto
   thousands of access circuits;

should be changed to:

   DHCP broadcast replies can be routed to = only the proper circuit,
   avoiding, say, the replication of the = DHCP reply broadcast onto
   thousands of access circuits;

------_=_NextPart_001_01C2BDBC.10D82FE0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 16 19:50:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27944; Thu, 16 Jan 2003 19:50:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0hPJ04567; Thu, 16 Jan 2003 19:43:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H0e3J04412 for ; Thu, 16 Jan 2003 19:40:03 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27419 for ; Thu, 16 Jan 2003 19:24:12 -0500 (EST) Received: from nominum.com (cs6625147-195.austin.rr.com [66.25.147.195]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0H0O6P05067; Thu, 16 Jan 2003 18:24:06 -0600 (CST) Date: Thu, 16 Jan 2003 18:27:33 -0600 Subject: Re: [dhcwg] Clarification proposed for RFC 3046 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'dhcwg@ietf.org'" To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198A67915@homer.incognito.com.> Message-Id: <78953053-29B2-11D7-A3B4-00039317663C@nominum.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0H0e3J04413 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit >    DHCP Address Exhaustion > >       In general, the DHCP server may be extended to maintain a > database >       with the "triplet" of > >             (client IP address,  client MAC address,  client remote ID) > >       The DHCP server SHOULD implement policies that restrict the > number >       of IP addresses to be assigned to a single remote ID. > > to the following: > >    DHCP Administrative Controls > >           A DHCP server needs to use some unique identifier to > associate a >           client with its lease.  A DHCP server MUST use the same > logic as >           specified in Section 4.2 of RFC 2131 with the addition that > the >           remote ID MUST also be used in the unique identifier.  > >         The DHCP server SHOULD implement policies that restrict the > number >           of IP addresses to be assigned to a single remote ID. How about this:    DHCP Address Exhaustion       The DHCP server may be extended to maintain a database       with the "triplet" of             (client IP address,  client unique identifier,  client remote ID)       The DHCP server SHOULD implement policies that restrict the number       of IP addresses to be assigned to a single remote ID. A DHCP server MUST use the same logic as specified in Section 4.2 of RFC 2131 to determine the client unique identifier. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 17 09:07:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22696; Fri, 17 Jan 2003 09:07:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEM7J02022; Fri, 17 Jan 2003 09:22:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HEKUJ01881 for ; Fri, 17 Jan 2003 09:20:30 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22614 for ; Fri, 17 Jan 2003 09:04:22 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn1-164.cisco.com [10.82.224.164]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0HE7huW024380 for ; Fri, 17 Jan 2003 06:07:43 -0800 (PST) Message-Id: <4.3.2.7.2.20030117090425.00b28128@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 17 Jan 2003 09:07:41 -0500 To: dhcwg@ietf.org From: John Schnizlein Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Fwd: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-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: , FYI >Date: Fri, 17 Jan 2003 07:23:45 -0500 >From: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-geopriv-dhcp-lo-option-00.txt >Sender: nsyracus@cnri.reston.va.us >To: IETF-Announce:; >Cc: geopriv@mail.apps.ietf.org >Reply-to: Internet-Drafts@ietf.org >List-Owner: >List-Subscribe: > >List-Unsubscribe: > > > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. > > Title : DHC Location Object within GEOPRIV > Author(s) : J. Polk, J. Schnizlein, M. Linsner > Filename : draft-ietf-geopriv-dhcp-lo-option-00.txt > Pages : 12 > Date : 2003-1-16 > >This document specifies a Dynamic Host Configuration Protocol Option for >the geographic location of the client. The location object includes >latitude, longitude, and altitude, with resolution indicators for each. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lo-option-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-geopriv-dhcp-lo-option-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-geopriv-dhcp-lo-option-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. >Content-Type: text/plain >Content-ID: <2003-1-16133730.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-geopriv-dhcp-lo-option-00.txt > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 17 12:34:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29365; Fri, 17 Jan 2003 12:34:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHnjJ17288; Fri, 17 Jan 2003 12:49:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HHmoJ17251 for ; Fri, 17 Jan 2003 12:48:50 -0500 Received: from mail.imp.ch (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29340 for ; Fri, 17 Jan 2003 12:32:36 -0500 (EST) From: Patrick.Guelat@imp.ch Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.6/8.12.3) with ESMTP id h0HHZxO6037554 for ; Fri, 17 Jan 2003 18:35:59 +0100 (CET) (envelope-from Patrick.Guelat@imp.ch) Date: Fri, 17 Jan 2003 18:35:59 +0100 X-X-Sender: patg@nbs.imp.ch To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Transfer-Encoding: 8BIT Subject: [dhcwg] Broken DOCSIS dhcp client implementations Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8BIT Hi I've written the DHCP-Server part for our DOCSIS cablenetwork provisioning suite. It's an implementation from scratch not using ISC code or other available implementations. During testing I noticed that there a are quite a lot of DHCP-clients not accepting offers from my server, i.e. some GE/Motorolla Modems, ELSA and some old firmware versions for E-Tech. I finally figured out that those clients all expect the dhcp-message-type (option 53) to be the first option after the magic cookie, otherwise they won't accept the DHCPOFFER message. I can't find any reference in RFC 2131 defining a specific order of the options. (besides the magic cookie and END option) If fixed our implementation to always start with options 53,54,51; but this is only a 'workaround' in my eyes. Has anyone experienced similar problems with such 'non-conforming' dhcp clients ? Regards Patrick -- Patrick Guélat, ImproWare AG Network Services, CH-4133 Pratteln Mail: Patrick.Guelat@imp.ch - Phone: +41 61 826 93 00 (ext: 13) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 17 14:44:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02759; Fri, 17 Jan 2003 14:44:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJshJ25113; Fri, 17 Jan 2003 14:54:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0HJrqJ25073 for ; Fri, 17 Jan 2003 14:53:52 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02568 for ; Fri, 17 Jan 2003 14:37:38 -0500 (EST) Received: from nominum.com (cs6625147-195.austin.rr.com [66.25.147.195]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0HJbRP14552; Fri, 17 Jan 2003 13:37:28 -0600 (CST) Date: Fri, 17 Jan 2003 13:41:06 -0600 Subject: Re: [dhcwg] Broken DOCSIS dhcp client implementations Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org To: Patrick.Guelat@imp.ch From: Ted Lemon In-Reply-To: Message-Id: <9EC31502-2A53-11D7-A3B4-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit That does sound familiar. A quick examination of the ISC code shows that in fact the DHCP message type option is always sent first. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 17 21:29:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09384; Fri, 17 Jan 2003 21:29:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0I2fWJ15330; Fri, 17 Jan 2003 21:41:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0I2bTJ15196 for ; Fri, 17 Jan 2003 21:37:29 -0500 Received: from intermail.se.dataphone.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09327 for ; Fri, 17 Jan 2003 21:21:07 -0500 (EST) 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.1) with ESMTP id 742580; Sat, 18 Jan 2003 03:24:29 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Subject: Re: [dhcwg] Broken DOCSIS dhcp client implementations Date: Sat, 18 Jan 2003 03:25:41 +0100 User-Agent: KMail/1.4.3 References: <9EC31502-2A53-11D7-A3B4-00039317663C@nominum.com> In-Reply-To: <9EC31502-2A53-11D7-A3B4-00039317663C@nominum.com> Cc: Patrick.Guelat@imp.ch MIME-Version: 1.0 Message-Id: <200301180325.41014.budm@weird-solutions.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0I2bUJ15197 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Friday 17 January 2003 20.41, Ted Lemon wrote: > That does sound familiar. A quick examination of the ISC code shows > that in fact the DHCP message type option is always sent first. I'm almost certain that this was specified in an RFC many years ago, but all trace of it seems to have disappeared. I think the idea was that if "message type" was not first, you could consider the packet to be BOOTP, and the rest of the option area would contain only BOOTP vendor extensions. 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 Sun Jan 19 20:20:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28086; Sun, 19 Jan 2003 20:20:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K1XNJ00358; Sun, 19 Jan 2003 20:33:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K1RrJ32666 for ; Sun, 19 Jan 2003 20:27:53 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28022 for ; Sun, 19 Jan 2003 20:10:32 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0K1EgBa010683 for ; Sun, 19 Jan 2003 20:14:43 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-776.cisco.com [10.82.243.8]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA09416 for ; Sun, 19 Jan 2003 20:13:54 -0500 (EST) Message-Id: <4.3.2.7.2.20030118105756.00b7c6e0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 18 Jan 2003 11:11:27 -0500 To: "'dhcwg@ietf.org'" From: Ralph Droms Subject: Re: [dhcwg] Clarification proposed for RFC 3046 In-Reply-To: <78953053-29B2-11D7-A3B4-00039317663C@nominum.com> References: <4FB49E60CFBA724E88867317DAA3D198A67915@homer.incognito.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Following up on Ted's suggestion, how about the following, which puts the qualifier about the client unique identifier closer to the definition: Client Identification The DHCP server may be extended to maintain a database with the "triplet" of (client IP address, client unique identifier, client remote ID) The "client unique identifier" is defined in section 4.2 of RFC 2131. A DHCP server MUST use the rules specified in Section 4.2 of RFC 2131 to determine the client unique identifier. DHCP Address Exhaustion The DHCP server SHOULD implement policies that restrict the number of IP addresses to be assigned to a single remote ID, independent of the client unique identifiers. Also, I think the following text also needs to be reviewed: Client Identifier Spoofing By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifier field need not be used by the DHCP server. MAC Address Spoofing By associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same MAC address on a different remote ID. The text about "Client Identifier Spoofing" can be deleted. In the text about "MAD Address Spoofing", I suggest replacing "MAC Address" with "Client Unique Identifier" throughout. - Ralph At 06:27 PM 1/16/2003 -0600, Ted Lemon wrote: >> DHCP Address Exhaustion >> >> In general, the DHCP server may be extended to maintain a database >> with the "triplet" of >> >> (client IP address, client MAC address, client remote ID) >> >> The DHCP server SHOULD implement policies that restrict the number >> of IP addresses to be assigned to a single remote ID. >> >>to the following: >> >> DHCP Administrative Controls >> >> A DHCP server needs to use some unique identifier to associate a >> client with its lease. A DHCP server MUST use the same logic as >> specified in Section 4.2 of RFC 2131 with the addition that the >> remote ID MUST also be used in the unique identifier. >> >> The DHCP server SHOULD implement policies that restrict the number >> of IP addresses to be assigned to a single remote ID. > > >How about this: > > DHCP Address Exhaustion > > The DHCP server may be extended to maintain a database > with the "triplet" of > > (client IP address, client unique identifier, client remote ID) > > The DHCP server SHOULD implement policies that restrict the number > of IP addresses to be assigned to a single remote ID. A DHCP server > MUST use the same logic as specified in Section 4.2 of RFC 2131 to > determine the client unique identifier. > >_______________________________________________ >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 Jan 20 03:37:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14034; Mon, 20 Jan 2003 03:37:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K8niJ01557; Mon, 20 Jan 2003 03:49:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0K8ggJ01213 for ; Mon, 20 Jan 2003 03:42:42 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13797 for ; Mon, 20 Jan 2003 03:25:13 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h0K8Sbd23079; Mon, 20 Jan 2003 02:28:37 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h0K8Sbs28467; Mon, 20 Jan 2003 02:28:37 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 20 Jan 2003 02:28:37 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , "'dhcwg@ietf.org'" Subject: RE: [dhcwg] Clarification proposed for RFC 3046 Date: Mon, 20 Jan 2003 02:27:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C05D.B8388AC0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C05D.B8388AC0 Content-Type: text/plain; charset="iso-8859-1" How about some additional clean-up ... what is the "client remote ID". This is not defined in RFC 3046. Shouldn't it be "Remote Agent ID"? And, "a single remote ID" should be "a single remote agent ID"? Perhaps Client Identifier Spoofing should be changed instead of removed? How about: As a client unique identifier (RFC 3046) may easily be spoofed, the use of the remote agent ID and client unique identifier by the server to identify a client make spoofing another client's client unique identifier meaningless unless the spoofed client is also at the same remote agent ID. Otherwise, I agree with the changes discussed so far. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Saturday, January 18, 2003 11:11 AM To: 'dhcwg@ietf.org' Subject: Re: [dhcwg] Clarification proposed for RFC 3046 Following up on Ted's suggestion, how about the following, which puts the qualifier about the client unique identifier closer to the definition: Client Identification The DHCP server may be extended to maintain a database with the "triplet" of (client IP address, client unique identifier, client remote ID) The "client unique identifier" is defined in section 4.2 of RFC 2131. A DHCP server MUST use the rules specified in Section 4.2 of RFC 2131 to determine the client unique identifier. DHCP Address Exhaustion The DHCP server SHOULD implement policies that restrict the number of IP addresses to be assigned to a single remote ID, independent of the client unique identifiers. Also, I think the following text also needs to be reviewed: Client Identifier Spoofing By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifier field need not be used by the DHCP server. MAC Address Spoofing By associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same MAC address on a different remote ID. The text about "Client Identifier Spoofing" can be deleted. In the text about "MAD Address Spoofing", I suggest replacing "MAC Address" with "Client Unique Identifier" throughout. - Ralph At 06:27 PM 1/16/2003 -0600, Ted Lemon wrote: >> DHCP Address Exhaustion >> >> In general, the DHCP server may be extended to maintain a database >> with the "triplet" of >> >> (client IP address, client MAC address, client remote ID) >> >> The DHCP server SHOULD implement policies that restrict the number >> of IP addresses to be assigned to a single remote ID. >> >>to the following: >> >> DHCP Administrative Controls >> >> A DHCP server needs to use some unique identifier to associate a >> client with its lease. A DHCP server MUST use the same logic as >> specified in Section 4.2 of RFC 2131 with the addition that the >> remote ID MUST also be used in the unique identifier. >> >> The DHCP server SHOULD implement policies that restrict the number >> of IP addresses to be assigned to a single remote ID. > > >How about this: > > DHCP Address Exhaustion > > The DHCP server may be extended to maintain a database > with the "triplet" of > > (client IP address, client unique identifier, client remote ID) > > The DHCP server SHOULD implement policies that restrict the number > of IP addresses to be assigned to a single remote ID. A DHCP server > MUST use the same logic as specified in Section 4.2 of RFC 2131 to > determine the client unique identifier. > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2C05D.B8388AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Clarification proposed for RFC 3046

How about some additional clean-up ... what is the = "client remote ID". This is not
defined in RFC 3046. Shouldn't it be "Remote = Agent ID"?

And, "a single remote ID" should be "a = single remote agent ID"?

Perhaps Client Identifier Spoofing should be changed = instead of removed? How about:

      As a client unique = identifier (RFC 3046) may easily be spoofed, the use of
      the remote agent ID = and client unique identifier by the server to identify
      a client make = spoofing another client's client unique identifier meaningless
      unless the spoofed = client is also at the same remote agent ID.

Otherwise, I agree with the changes discussed so = far.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Saturday, January 18, 2003 11:11 AM
To: 'dhcwg@ietf.org'
Subject: Re: [dhcwg] Clarification proposed for RFC = 3046


Following up on Ted's suggestion, how about the = following, which puts the
qualifier about the client unique identifier closer = to the definition:

    Client Identification

       The DHCP server = may be extended to maintain a database
       with the = "triplet" of

          &nb= sp;  (client IP address,  client unique identifier,  = client remote ID)

       The "client = unique identifier" is defined in section 4.2 of RFC 2131.
       A DHCP server = MUST use the rules specified in Section 4.2 of RFC
       2131 to = determine the client unique identifier.

    DHCP Address Exhaustion

       The DHCP server = SHOULD implement policies that restrict the number of
       IP addresses to = be assigned to a single remote ID, independent of the
       client unique = identifiers.

Also, I think the following text also needs to be = reviewed:

    Client Identifier Spoofing

       By using the = agent-supplied Agent Remote ID option, the untrusted
       and as-yet = unstandardized client identifier field need not be used
       by the DHCP = server.

    MAC Address Spoofing

       By associating a = MAC address with an Agent Remote ID, the DHCP
       server can = prevent offering an IP address to an attacker spoofing
       the same MAC = address on a different remote ID.

The text about "Client Identifier Spoofing" = can be deleted.  In the text
about "MAD Address Spoofing", I suggest = replacing "MAC Address" with
"Client Unique Identifier" = throughout.

- Ralph




At 06:27 PM 1/16/2003 -0600, Ted Lemon wrote:
>>    DHCP Address = Exhaustion
>>
>>       In = general, the DHCP server may be extended to maintain a database
>>       with = the "triplet" of
>>
>>         &= nbsp;   (client IP address,  client MAC address,  = client remote ID)
>>
>>       The = DHCP server SHOULD implement policies that restrict the number
>>       of IP = addresses to be assigned to a single remote ID.
>>
>>to the following:
>>
>>    DHCP Administrative = Controls
>>
>>         &= nbsp; A DHCP server needs to use some unique identifier to associate = a
>>         &= nbsp; client with its lease.  A DHCP server MUST use the same = logic as
>>         &= nbsp; specified in Section 4.2 of RFC 2131 with the addition that = the
>>         &= nbsp; remote ID MUST also be used in the unique identifier.
>>
>>         The = DHCP server SHOULD implement policies that restrict the number
>>         &= nbsp; of IP addresses to be assigned to a single remote ID.
>
>
>How about this:
>
>    DHCP Address = Exhaustion
>
>       The DHCP = server may be extended to maintain a database
>       with the = "triplet" of
>
>          = ;   (client IP address,  client unique identifier,  = client remote ID)
>
>       The DHCP = server SHOULD implement policies that restrict the number
>       of IP = addresses to be assigned to a single remote ID.   A DHCP = server
>       MUST use = the same logic as specified in Section 4.2 of RFC 2131 to
>       determine = the client unique identifier.
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.org/mailman/listinfo/dhcwg

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

------_=_NextPart_001_01C2C05D.B8388AC0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 20 22:11:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07956; Mon, 20 Jan 2003 22:11:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L3ScJ03692; Mon, 20 Jan 2003 22:28:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L3QxJ03626 for ; Mon, 20 Jan 2003 22:26:59 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07929 for ; Mon, 20 Jan 2003 22:09:08 -0500 (EST) Received: from nominum.com (dsl081-073-044.sfo1.dsl.speakeasy.net [64.81.73.44]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0L38RP23940; Mon, 20 Jan 2003 21:08:27 -0600 (CST) Date: Mon, 20 Jan 2003 19:12:43 -0800 Subject: Re: [dhcwg] Clarification proposed for RFC 3046 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'dhcwg@ietf.org'" To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030118105756.00b7c6e0@funnel.cisco.com> Message-Id: <34D8E140-2CEE-11D7-AFDA-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Following up on Ted's suggestion, how about the following, which puts > the qualifier about the client unique identifier closer to the > definition: I'm not sure how your text differs from what I suggested, but it looks fine to me, and as you can probably gather I wasn't very attached to what I wrote, so I don't feel the need to know what you changed. :') > The text about "Client Identifier Spoofing" can be deleted. In the > text about "MAD Address Spoofing", I suggest replacing "MAC Address" > with "Client Unique Identifier" throughout. That sounds fine to me. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Jan 20 22:12:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07994; Mon, 20 Jan 2003 22:12:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L3U3J03730; Mon, 20 Jan 2003 22:30:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0L3S9J03676 for ; Mon, 20 Jan 2003 22:28:09 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07939 for ; Mon, 20 Jan 2003 22:10:18 -0500 (EST) Received: from nominum.com (dsl081-073-044.sfo1.dsl.speakeasy.net [64.81.73.44]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0L39XP23952; Mon, 20 Jan 2003 21:09:33 -0600 (CST) Date: Mon, 20 Jan 2003 19:13:49 -0800 Subject: Re: [dhcwg] Clarification proposed for RFC 3046 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Ralph Droms'" , "'dhcwg@ietf.org'" To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: Message-Id: <5C54E8AC-2CEE-11D7-AFDA-00039317663C@nominum.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h0L3S9J03677 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit >       As a client unique identifier (RFC 3046) may easily be spoofed, > the use of >       the remote agent ID and client unique identifier by the server > to identify >       a client make spoofing another client's client unique identifier > meaningless >       unless the spoofed client is also at the same remote agent ID. RFC3046 doesn't define a client unique identifier - I think you mean RFC2131. Otherwise, looks fine. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 21 18:47:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15404; Tue, 21 Jan 2003 18:47:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M04rJ26761; Tue, 21 Jan 2003 19:04:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LLeZJ18482 for ; Tue, 21 Jan 2003 16:40:35 -0500 Received: from panther.cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12354 for ; Tue, 21 Jan 2003 16:22:22 -0500 (EST) Received: from localhost (chussey@localhost) by panther.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id h0LLPj814705; Tue, 21 Jan 2003 13:25:45 -0800 (PST) Date: Tue, 21 Jan 2003 13:25:45 -0800 (PST) From: Cora Hussey To: cc: Roy Shea , Cora Hussey , Glenn Glazer Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] DHCP Authentication Implementation 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: , Hello, We are considering implementing the delayed authentication for DHCP as described in RFC 3118, and were wondering if you could answer some questions. It would be helpful for us and much appreciated. 1. Do you know of any existing implementations? From reading your mail archives, it seems that none exist, but we wanted to confirm that or know what was out there before beginning. 2. Would this help your working group? I believe we would gladly exchange our work on the implementation for advice and clarification on your existing work. 3. Do you know of an open-source version of DHCP that you would recommend extending, or that you are familiar with? We are aware of the java version on dhcp.org, but are looking for perhaps recommendations in C? 4. One alternative direction we are considering is doing implementation work on the Authentication via Kerberos V. We have found a few copies of the Internet Draft as well as mention of it in your meeting minutes, but cannot determine how much work has been or needs to be done on it. Would you recommend working on this instead? Thank you very much for your assistance, and I hope you have a great Tuesday. Cora _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Jan 22 00:32:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22221; Wed, 22 Jan 2003 00:32:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5oJJ14765; Wed, 22 Jan 2003 00:50:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0M5lxJ14708 for ; Wed, 22 Jan 2003 00:47:59 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22169 for ; Wed, 22 Jan 2003 00:29:36 -0500 (EST) Received: from nominum.com (dsl081-073-044.sfo1.dsl.speakeasy.net [64.81.73.44]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0M5ShP10860; Tue, 21 Jan 2003 23:28:44 -0600 (CST) Date: Tue, 21 Jan 2003 21:33:11 -0800 Subject: Re: [dhcwg] DHCP Authentication Implementation Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: , Roy Shea , Glenn Glazer To: Cora Hussey From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit There are quite a few open source DHCP clients - the ISC client, dhcpcd, pumpd and one other that I'm drawing a blank on right now. For open source DHCP servers, I think ISC is the only one out there. I'd be happy to help you to find your way around the source code if you would be willing to contribute the code back to the ISC. Ken Hornstein approached me at the last IETF and asked me if there was interest in the Kerberos draft he worked on. I think he'd be very happy to talk to you about it, and the email address on the draft should still work. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 02:34:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29253; Thu, 23 Jan 2003 02:34:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N7qcJ02419; Thu, 23 Jan 2003 02:52:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N7bOJ01578 for ; Thu, 23 Jan 2003 02:37:24 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29031 for ; Thu, 23 Jan 2003 02:18:27 -0500 (EST) Received: from localhost ([2001:200:182:2000:4852:840e:9722:4156]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0N7LlR56548; Thu, 23 Jan 2003 16:21:48 +0900 (JST) Date: Thu, 23 Jan 2003 16:22:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (EUD)" Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 204 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: , Hello, thanks for the quick response, and sorry for not responding sooner. >>>>> On Tue, 14 Jan 2003 08:32:29 -0600, >>>>> "Bernie Volz (EUD)" said: > I have several questions on draft-ietf-dhc-dhcpv6-28.txt from my > implementation experiences. (It is probably too late to reflect the > points to the spec before it becomes an RFC, though.) > I'd apologize in advance if some (or all) of them were addressed in > the draft, but I could not find the answers. > 1. Section 18.1.8 says: > When the client receives a NoBinding status in an IA from the server > in response to a Renew message or a Rebind message, the client sends > a Request to reestablish an IA with the server. > does this imply that the client must remove the IA before sending the > request? (I guess the answer is YES, but I'm asking this to be sure.) BV> No. As long as the address has a valid lifetime left, the client BV> should be able to use that address. NoBinding just means that the BV> server has no record of that binding (perhaps it is a new server BV> or a server that losts its stable storage). While this situation BV> is not desireable, it is possible and should work out OK. I see. Then I have a related question. Does the client continue or stop sending Renew or Rebind in this case? Also, I happened to have a chance to discuss this case with Ralph, and, according to the discussion, I have an impression that the wording could be a bit clearer. Sections 18.2.3 and 18.2.4 have exactly the same sentence: If the server cannot find a client entry for the IA the server returns the IA containing no addresses with a Status Code option set to NoBinding in the Reply message. according to Ralph, however, the semantics of "the server cannot find a client entry" is slightly different between the case of renew and the case of rebind. For the case of renew, the message is only accepted by the responsible server, so the semantics should have a "relaxed" sense. For the case of rebind, however, the message is accepted by all possible servers. Thus, in this case, the semantics should have a "strict" sense, that is, the server should not send the NoBinding unless it has an explicit knowledge that the binding has been invalidated. So, for example, suppose a server has rebooted and has lost all bindings. When the server receives a Renew or Rebind message after it reboots, the appropriate behavior depends on the message type: - for Renew, the server must reply with a NoBinding code. - for Rebind, the server must ignores the message (not to confuse the recipient). It seems to me the current text does not express the sense, and it could be a source of interoperability problems. (I've actually seen some interoperability issues among several implementations). > 2. What should a client do if it receives an IA_NA in a reply message > where T1 > T2 > 0? > a) the client must ignore the option (or the entire reply message) > b) the client must treat as if T1 = T2 > c) the client must choose appropriate alternatives for T1 and T2. > (this cannot be an option, though, because Section 22.4 says the > client MUST use T1 and T2 if they are non-0) > d) others > FYI: Our implementation currently takes the option a). BV> (a) is probably a fine action as it really is invalid. T1 <= T2. Okay. > 3. What should a server do when it receives a request message and > already has a binding required in the request? (this can happen if > the first reply was lost and the client resend the request > message.) > FYI: Our implementation currently updates parameters > (e.g. lifetimes) of the binding and sends a reply with the > parameters, just like the server receives a renew message for the > binding. BV> A retransmitted Request (because the client failed to receive the BV> Reply) can either be treated as you describe or you can send the BV> current values (if they are still valid). A server might, for BV> example, have a cache of recently sent Replies and in this case it BV> may resend what it sent the first time. Okay. > 4. Section 18.1.8 says > When the client receives a NoAddrsAvail status from the server in > response to a Request, the client can either try another server > (perhaps restarting the DHCP server discovery process) or use the > Information-Request to obtain configuration parameters only. > This sentence is not very clear to me. I interpreted this sentence > corresponds to the following part of Section 18.2.1: > If the server cannot assign any addresses to an IA in the message > from the client, the server MUST include the IA in the Reply message > with no addresses in the IA and a Status Code option in the IA > containing status code NoAddrsAvail. > If so, there may be other IAs that do not contain NoAddrsAvail status > code. In this case, what should the client do for the other IAs? BV> It should use those addresses or Release them. > Or, does Section 18.1.8 mean a NoAddrsAvail code in the DHCPv6 options > field (i.e. not in an IA)? BV> It is the status code option in the IA option. Okay, but it would be good if Section 18.1.8 is more clear on this, like: When the client receives a NoAddrsAvail status for an IA from the server in response to a Request, the client can either try another server (perhaps restarting the DHCP server discovery process) or use the Information-Request to obtain configuration parameters only. > 5. Section 18.1.3 says: > ...The > client includes an IA option with all addresses currently assigned to > the IA in its Renew message. > and Section 18.2.3 has corresponding sentences: > If the server finds that any of the addresses are not appropriate > to the link to which the client is attached, the server returns the > address to the client with lifetimes of 0. > If the server finds the addresses in the IA for the client then the > server sends back the IA to the client with new lifetimes and T1/T2 > times. The server may choose to change the list of addresses and the > lifetimes of addresses in IAs that are returned to the client. > That is, (in my understanding) > - the client sends all addresses for an IA to be renewed. > - (if the binding is still valid) the server returns all the addresses > for the IA with 0 or larger lifetimes. > Now, what if the client finds a lack of addresses in the reply message > for the IA? > a) the client should ignore the entire IA (or the entire reply) > b) the client should let the dropped address expire (unless there's > no more update) > c) others > FYI: Our implementation currently takes the option b), though we do > this for prefixes in an IA_PD option, not for addresses. BV> Option b is correct. The lifetime controls the when addresses on the BV> client expire. Thus, if a server stops Replying with that address, BV> the lifetimes will not be updated and eventually the address expires. Okay. > 6. there seems to be a corner case about handling the Rapid Commit > option. Section 17.1.3 says: > ... If it does > not receive such a Reply message and does receive a valid Advertise > message, the client processes the Advertise message as described in > section 17.1.3. > But what should the client do if it receives a reply message for a > solicit message with a Rapid Commit option after receiving an > advertise message? Should the client ignore or accept it? In the > latter case, what if the client has already sent a request message > (then it will receive a different reply)? BV> The client must wait for a time period after sending a Solicit for BV> replies from servers. I assume you are saying what happens if after BV> this initial wait time (described in 17.1.2) the client receives BV> (or has received) an Advertise and uses it. But then while waiting BV> for the Reply (to the Request), it receives a (much delayed) Reply BV> with Rapid Commit? In that case, I think it is really implementation BV> dependent on what the client does. In my mind, I think it is easier BV> for the client to continue processing the Advertise / Request / Reply BV> procedure that it started. But, the client COULD use the Reply with BV> Rapid Commit if it wanted and it has an acceptable response (ie, BV> addresses). In either case, one set of server assigned addresses will BV> not end up being used by the client and the server will reclaim them BV> once the lifetimes expire. I think dropping the Reply w/Rapid Commit BV> is easier and better from an implementation standpoint (the reason BV> is that the client only needs to remember one thing - the Reply it BV> is waiting for and discards all others). I concur. Thanks for the detailed explanation. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 03:31:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29930; Thu, 23 Jan 2003 03:31:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8oIJ05879; Thu, 23 Jan 2003 03:50:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N8XfJ04542 for ; Thu, 23 Jan 2003 03:33:41 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29713 for ; Thu, 23 Jan 2003 03:14:43 -0500 (EST) Received: from localhost ([2001:200:182:2000:4852:840e:9722:4156]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0N8I9R57171 for ; Thu, 23 Jan 2003 17:18:09 +0900 (JST) Date: Thu, 23 Jan 2003 17:18:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 38 Subject: [dhcwg] additional questions on dhcpv6-28 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: , Hello, I still have a couple of questions (and one tiny comment) of draft-ietf-dhc-dhcpv6-28.txt. This is the comment: In the following line of Section 18.1.6. MRC REL_MAX_MRC should be MRC REL_MAX_RC And the followings are questions: 1. What should the client do if the preferred lifetime is larger than the valid lifetime for an IA address option in a reply message (to request/renew, etc)? I think the address should be ignored, as an analogy to the rule (c) of RFC 2462 Section 5.5.3, but the dhcpv6 draft is silent on this. 2. Does DHCPv6 have a notion of "infinite" lifetimes (and T1/T2 values)? If we apply an analogy to RFC 2461, 0xffffffff should be "infinity." Does this make sense for DHCPv6 as well? I don't have a particular opinion, but the DHCPv6 spec should be clear on this, because an implementation may or may not apply the analogy to RFC 2461, which may cause interoperability issues. BTW: our current implementation applies the analogy, i.e., we treat 0xffffffff as infinity. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 04:09:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00966; Thu, 23 Jan 2003 04:09:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N9RUJ09091; Thu, 23 Jan 2003 04:27:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0N9J9J08675 for ; Thu, 23 Jan 2003 04:19:09 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00720 for ; Thu, 23 Jan 2003 04:00:10 -0500 (EST) Received: from localhost ([2001:200:182:2000:4852:840e:9722:4156]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0N93WR57648; Thu, 23 Jan 2003 18:03:32 +0900 (JST) Date: Thu, 23 Jan 2003 18:03:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ot@cisco.com, rdroms@cisco.com Cc: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 58 Subject: [dhcwg] questions about prefix-delegation-01 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 have several questions about draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt from my implementation experiences. 1. Should the PD (prefix delegation) draft have a similar rule of the NoAddrsAvail case in Section 18.2 of dhcpv6-28? The dhcpv6 spec says: If the server cannot assign any addresses to an IA in the message from the client, the server MUST include the IA in the Reply message with no addresses in the IA and a Status Code option in the IA containing status code NoAddrsAvail. I could not find a corresponding description in Section 11 of the PD draft, but our implementation currently applies the same logic to the PD case. That is, If the delegating router cannot delegate any prefixes to an IA_PD in the message from the requesting router, the delegating router MUST include the IA_PD in the Reply message with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail. (Note that we cannot just copy the dhcpv6 spec, because the status code is different.) 2. A similar question applies to the NoBinding case of Section 18.1.8 of dhcpv6-28. When the client receives a NoBinding status in an IA from the server in response to a Renew message or a Rebind message, the client sends a Request to reestablish an IA with the server. In this case, however, we could say that a natural analogy should apply, since the sentence is quite generic. 3. Section 11 of the PD draft says: In some circumstances the requesting router may need verification that the delegating router still has a valid binding for the requesting router. Examples of times when a requesting router may ask for such verification include: o The requesting router reboots. ... If such verification is needed the requesting router MUST initiate a Renew/Reply message exchange as described in the section "Creation and Transmission of Renew Messages" of the DHCP specification [6]. I don't see why a Renew/Reply exchange is used, instead of a Confirm/Reply exchange. The described situation is very similar to Section 18.1.2 of dhcpv6-28, and I don't see an essential difference to use a Renew/Reply exchange. If there is, the PD draft should be clear on this. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 07:48:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04880; Thu, 23 Jan 2003 07:48:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ND6XJ22218; Thu, 23 Jan 2003 08:06:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0ND5GJ22126 for ; Thu, 23 Jan 2003 08:05:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04657; Thu, 23 Jan 2003 07:46:15 -0500 (EST) Message-Id: <200301231246.HAA04657@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, 23 Jan 2003 07:46:15 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subscriber-id-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 : DHCP Subscriber ID Suboption for the DHCP Relay Agent Option Author(s) : R. Johnson, R. Droms et al. Filename : draft-ietf-dhc-subscriber-id-00.txt Pages : 0 Date : 2003-1-22 This memo defines a new DHCP Relay Suboption for passing an arbitrary number of bytes defining what will be called the 'Subscriber ID'. This value is simply defined as an array of bytes and can be interpreted in any form by the DHCP server. Its intended purpose is to give additional information which the DHCP server can use in address allocation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-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-subscriber-id-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-subscriber-id-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-1-22111339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subscriber-id-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subscriber-id-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-22111339.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 Jan 23 17:26:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22046; Thu, 23 Jan 2003 17:26:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NMiqJ31340; Thu, 23 Jan 2003 17:44:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NMhFJ31243 for ; Thu, 23 Jan 2003 17:43:15 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21995 for ; Thu, 23 Jan 2003 17:24:01 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h0NMRTb08696; Thu, 23 Jan 2003 16:27:29 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h0NMRTv24147; Thu, 23 Jan 2003 16:27:29 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 23 Jan 2003 16:27:29 -0600 Message-ID: From: "Bernie Volz (EUD)" To: JINMEI Tatuya / ???? , dhcwg@ietf.org Subject: RE: [dhcwg] additional questions on dhcpv6-28 Date: Thu, 23 Jan 2003 16:25:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C32E.6658F2D4" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C32E.6658F2D4 Content-Type: text/plain; charset="ISO-2022-JP" Jinmei: Regarding REL_MAX_RC, thanks. We will fix that in the author's review of the RFC. Regarding issue 1 (preferred>valid lifetime), I agree that RFC 2462 behavior is best (ie, ignore address if this happens as it is invalid). Regarding issue 2 (infinite lifetimes), that is something we could discuss but I don't think there is a need for infinite lifetimes (I suppose the authors of RFC 2462 felt that it is warranted and hence perhaps we too should consider it). Perhaps Ralph or another author or WG mailing list subscriber has an opinion? I definitely don't think infinite renewals times are a good idea, so I would not recommend adding this for T1/T2. BTW, please do keep issues coming. As there will hopefully soon be some DHCPv6 interop testing at various events (such as Connectathon, www.connectathon.org), one idea I briefly discussed with Ralph was to publish an internet-draft on any issues that were uncovered that either caused confusion or problems. That way, we'd document any issues early on. So, please keep issues coming as they could be used this draft. Thanks! - Bernie -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Thursday, January 23, 2003 3:19 AM To: dhcwg@ietf.org Subject: [dhcwg] additional questions on dhcpv6-28 Hello, I still have a couple of questions (and one tiny comment) of draft-ietf-dhc-dhcpv6-28.txt. This is the comment: In the following line of Section 18.1.6. MRC REL_MAX_MRC should be MRC REL_MAX_RC And the followings are questions: 1. What should the client do if the preferred lifetime is larger than the valid lifetime for an IA address option in a reply message (to request/renew, etc)? I think the address should be ignored, as an analogy to the rule (c) of RFC 2462 Section 5.5.3, but the dhcpv6 draft is silent on this. 2. Does DHCPv6 have a notion of "infinite" lifetimes (and T1/T2 values)? If we apply an analogy to RFC 2461, 0xffffffff should be "infinity." Does this make sense for DHCPv6 as well? I don't have a particular opinion, but the DHCPv6 spec should be clear on this, because an implementation may or may not apply the analogy to RFC 2461, which may cause interoperability issues. BTW: our current implementation applies the analogy, i.e., we treat 0xffffffff as infinity. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2C32E.6658F2D4 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] additional questions on dhcpv6-28

Jinmei:

Regarding REL_MAX_RC, thanks. We will fix that in the = author's review of the RFC.

Regarding issue 1 (preferred>valid lifetime), I = agree that RFC 2462 behavior is best
(ie, ignore address if this happens as it is = invalid).

Regarding issue 2 (infinite lifetimes), that is = something we could discuss but I
don't think there is a need for infinite lifetimes = (I suppose the authors of RFC
2462 felt that it is warranted and hence perhaps we = too should consider it).
Perhaps Ralph or another author or WG mailing list = subscriber has an opinion?

I definitely don't think infinite renewals times are = a good idea, so I would not
recommend adding this for T1/T2.

BTW, please do keep issues coming. As there will = hopefully soon be some DHCPv6
interop testing at various events (such as = Connectathon, www.connectathon.org),
one idea I briefly discussed with Ralph was to = publish an internet-draft on any
issues that were uncovered that either caused = confusion or problems. That way,
we'd document any issues early on. So, please keep = issues coming as they could
be used this draft.

Thanks!

- Bernie

-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshi= ba.co.jp]
Sent: Thursday, January 23, 2003 3:19 AM
To: dhcwg@ietf.org
Subject: [dhcwg] additional questions on = dhcpv6-28


Hello,

I still have a couple of questions (and one tiny = comment) of
draft-ietf-dhc-dhcpv6-28.txt.

This is the comment:

In the following line of Section 18.1.6.

      MRC   = REL_MAX_MRC

should be

      MRC   = REL_MAX_RC

And the followings are questions:

1. What should the client do if the preferred = lifetime is larger than
   the valid lifetime for an IA address = option in a reply message (to
   request/renew, etc)?

   I think the address should be ignored, = as an analogy to the rule
   (c) of RFC 2462 Section 5.5.3, but the = dhcpv6 draft is silent on
   this.

2. Does DHCPv6 have a notion of "infinite" = lifetimes (and T1/T2
   values)?  If we apply an analogy = to RFC 2461, 0xffffffff should be
   "infinity."  Does this = make sense for DHCPv6 as well?  I don't have
   a particular opinion, but the DHCPv6 = spec should be clear on this,
   because an implementation may or may = not apply the analogy to RFC
   2461, which may cause interoperability = issues.
   BTW: our current implementation applies = the analogy, i.e., we treat
   0xffffffff as infinity.

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

------_=_NextPart_001_01C2C32E.6658F2D4-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 18:11:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23617; Thu, 23 Jan 2003 18:11:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNTUJ01930; Thu, 23 Jan 2003 18:29:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNSiJ01862 for ; Thu, 23 Jan 2003 18:28:44 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23553 for ; Thu, 23 Jan 2003 18:09:30 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NNDiwU026063 for ; Thu, 23 Jan 2003 18:13:44 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA22994 for ; Thu, 23 Jan 2003 18:12:55 -0500 (EST) Message-Id: <4.3.2.7.2.20030123161320.00b69610@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 16:26:19 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] additional questions on dhcpv6-28 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: , Comments in line... - Ralph At 05:18 PM 1/23/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >Hello, > >I still have a couple of questions (and one tiny comment) of >draft-ietf-dhc-dhcpv6-28.txt. > >This is the comment: > >In the following line of Section 18.1.6. > > MRC REL_MAX_MRC > >should be > > MRC REL_MAX_RC Yes, thanks for catching that problem. >And the followings are questions: > >1. What should the client do if the preferred lifetime is larger than > the valid lifetime for an IA address option in a reply message (to > request/renew, etc)? > > I think the address should be ignored, as an analogy to the rule > (c) of RFC 2462 Section 5.5.3, but the dhcpv6 draft is silent on > this. I suggest adding this text to follow the first paragraph of section 18.1.8., Receipt of Reply Messages, in draft-ietf-dhc-dhcpv6-28.txt. The client discards any addresses found in any IAs it receives for which the preferred lifetime is greater than the valid lifetime. Are there other cases of invalid parameters or configuration that should be mentioned here? >2. Does DHCPv6 have a notion of "infinite" lifetimes (and T1/T2 > values)? If we apply an analogy to RFC 2461, 0xffffffff should be > "infinity." Does this make sense for DHCPv6 as well? I don't have > a particular opinion, but the DHCPv6 spec should be clear on this, > because an implementation may or may not apply the analogy to RFC > 2461, which may cause interoperability issues. > BTW: our current implementation applies the analogy, i.e., we treat > 0xffffffff as infinity. I think DHCPv6 should treat 0xffffffff as "infinity" in the case of time values like lifetimes, T1 and T2. As you implemented draft-ietf-dhc-dhcpv6-28.txt, did you find any places where the inclusion of a time value for "infinity" caused a problem with interpretation of the spec? Can we simply add a statement early in the specification, perhaps somewhere in Section 5, "DHCP Constants", defining 0xffffffff as infinity? > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 18:11:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23644; Thu, 23 Jan 2003 18:11:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNU6J01980; Thu, 23 Jan 2003 18:30:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNSnJ01867 for ; Thu, 23 Jan 2003 18:28:49 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23558 for ; Thu, 23 Jan 2003 18:09:35 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NNDjTB026066 for ; Thu, 23 Jan 2003 18:13:46 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA22998 for ; Thu, 23 Jan 2003 18:12:56 -0500 (EST) Message-Id: <4.3.2.7.2.20030123155548.00b6c4f8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 16:28:00 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] questions about prefix-delegation-01 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: , My comments are in line... - Ralph At 06:03 PM 1/23/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >I have several questions about >draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt from my >implementation experiences. > >1. Should the PD (prefix delegation) draft have a similar rule of the > NoAddrsAvail case in Section 18.2 of dhcpv6-28? The dhcpv6 spec > says: > If the server cannot assign any addresses to an IA in the message > from the client, the server MUST include the IA in the Reply message > with no addresses in the IA and a Status Code option in the IA > containing status code NoAddrsAvail. > > I could not find a corresponding description in Section 11 of > the PD draft, but our implementation currently applies the same > logic to the PD case. That is, > > If the delegating router cannot delegate any prefixes to an IA_PD > in the message from the requesting router, the delegating router > MUST include the IA_PD in the Reply message with no prefixes in > the IA_PD and a Status Code option in the IA_PD containing status > code NoPrefixAvail. > > (Note that we cannot just copy the dhcpv6 spec, because the status > code is different.) I suggest Jinmei-san's text should appear following the first paragraph of Section 11.2, "Delegating Router behaviour" of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt. >2. A similar question applies to the NoBinding case of Section 18.1.8 > of dhcpv6-28. > > When the client receives a NoBinding status in an IA from the server > in response to a Renew message or a Rebind message, the client sends > a Request to reestablish an IA with the server. > > In this case, however, we could say that a natural analogy should > apply, since the sentence is quite generic. We could add a copy of the paragraph cited above, following the second paragraph of Section 11.1, "Requesting router behaviour" of draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt. >3. Section 11 of the PD draft says: > > In some circumstances the requesting router may need verification > that the delegating router still has a valid binding for the > requesting router. Examples of times when a requesting router may > ask for such verification include: > > o The requesting router reboots. > ... > If such verification is needed the requesting router MUST initiate a > Renew/Reply message exchange as described in the section "Creation > and Transmission of Renew Messages" of the DHCP specification [6]. > > I don't see why a Renew/Reply exchange is used, instead of a > Confirm/Reply exchange. The described situation is very similar to > Section 18.1.2 of dhcpv6-28, and I don't see an essential difference > to use a Renew/Reply exchange. If there is, the PD draft should be > clear on this. Yes, I think a Confirm message could be used in this case. > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 18:11:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23668; Thu, 23 Jan 2003 18:11:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNU7J02000; Thu, 23 Jan 2003 18:30:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNSrJ01871 for ; Thu, 23 Jan 2003 18:28:53 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23557 for ; Thu, 23 Jan 2003 18:09:33 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NNDlvs026069 for ; Thu, 23 Jan 2003 18:13:47 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA23010 for ; Thu, 23 Jan 2003 18:12:58 -0500 (EST) Message-Id: <4.3.2.7.2.20030123151949.00b6c3f8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 16:29:55 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Comments in line... - Ralph At 04:22 PM 1/23/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >Hello, thanks for the quick response, and sorry for not responding >sooner. > > >>>>> On Tue, 14 Jan 2003 08:32:29 -0600, > >>>>> "Bernie Volz (EUD)" said: > > > I have several questions on draft-ietf-dhc-dhcpv6-28.txt from my > > implementation experiences. (It is probably too late to reflect the > > points to the spec before it becomes an RFC, though.) > > > I'd apologize in advance if some (or all) of them were addressed in > > the draft, but I could not find the answers. > > > 1. Section 18.1.8 says: > > > When the client receives a NoBinding status in an IA from the server > > in response to a Renew message or a Rebind message, the client sends > > a Request to reestablish an IA with the server. > > > does this imply that the client must remove the IA before sending the > > request? (I guess the answer is YES, but I'm asking this to be sure.) > >BV> No. As long as the address has a valid lifetime left, the client >BV> should be able to use that address. NoBinding just means that the >BV> server has no record of that binding (perhaps it is a new server >BV> or a server that losts its stable storage). While this situation >BV> is not desireable, it is possible and should work out OK. > >I see. Then I have a related question. Does the client continue or >stop sending Renew or Rebind in this case? > >Also, I happened to have a chance to discuss this case with Ralph, >and, according to the discussion, I have an impression that the >wording could be a bit clearer. Sections 18.2.3 and 18.2.4 have >exactly the same sentence: > > If the server cannot find a client entry for the IA the server > returns the IA containing no addresses with a Status Code option set > to NoBinding in the Reply message. > >according to Ralph, however, the semantics of "the server cannot find >a client entry" is slightly different between the case of renew and >the case of rebind. For the case of renew, the message is only >accepted by the responsible server, so the semantics should have a >"relaxed" sense. For the case of rebind, however, the message is >accepted by all possible servers. Thus, in this case, the semantics >should have a "strict" sense, that is, the server should not send the >NoBinding unless it has an explicit knowledge that the binding has >been invalidated. > >So, for example, suppose a server has rebooted and has lost all >bindings. When the server receives a Renew or Rebind message after it >reboots, the appropriate behavior depends on the message type: > - for Renew, the server must reply with a NoBinding code. > - for Rebind, the server must ignores the message (not to confuse > the recipient). > >It seems to me the current text does not express the sense, and it >could be a source of interoperability problems. (I've actually seen >some interoperability issues among several implementations). As Jinmei-san and I discussed, the Renew and Rebind cases are different. In the case of Renew, the server from which the client obtained the IA is identified by the Server Identifier option, so the server can authoritatively respond with NoBinding. The specification is ambiguous about the use of the Server Identitifier option. Section 18.1.3, "Creation and Transmission of Renew Messages" of draft-ietf-dhc-dhcpv6-28.txt requires that the client include "the identifier of the destination server in a Server Identifier option." However, section 18.2.3, "Receipt of Renew Messages", does *not* require that a server discard any Renew messages in which the contents of the Server Identifier option does not match the DUID of the receiving server. I think the specification needs to be corrected. The specification may also require clarification in the case of Rebind, when the server should respond with NoBinding only if it has authoritative information that there is no binding for the client. There may be another alternative, which would be to allow the client to ignore Reply messages (ins response to a Rebind message )with NoBinding status, if the client receives another Reply message from a server that does find the binding. > > 2. What should a client do if it receives an IA_NA in a reply message > > where T1 > T2 > 0? > > a) the client must ignore the option (or the entire reply message) > > b) the client must treat as if T1 = T2 > > c) the client must choose appropriate alternatives for T1 and T2. > > (this cannot be an option, though, because Section 22.4 says the > > client MUST use T1 and T2 if they are non-0) > > d) others > > > FYI: Our implementation currently takes the option a). > >BV> (a) is probably a fine action as it really is invalid. T1 <= T2. > >Okay. Jinmei-san, which choice does your implementation make? Ignore the option or the entire message? And, does it ignore the entire IA_NA option? I worry about ignoring just the option, which might lead to unexpected and hard-to-diagnose behavior. Ignoring the entire message would be easier to recognize as incorrect behavior. > > 3. What should a server do when it receives a request message and > > already has a binding required in the request? (this can happen if > > the first reply was lost and the client resend the request > > message.) > > > FYI: Our implementation currently updates parameters > > (e.g. lifetimes) of the binding and sends a reply with the > > parameters, just like the server receives a renew message for the > > binding. > >BV> A retransmitted Request (because the client failed to receive the >BV> Reply) can either be treated as you describe or you can send the >BV> current values (if they are still valid). A server might, for >BV> example, have a cache of recently sent Replies and in this case it >BV> may resend what it sent the first time. > >Okay. Agreed. > > 4. Section 18.1.8 says > > > When the client receives a NoAddrsAvail status from the server in > > response to a Request, the client can either try another server > > (perhaps restarting the DHCP server discovery process) or use the > > Information-Request to obtain configuration parameters only. > > > This sentence is not very clear to me. I interpreted this sentence > > corresponds to the following part of Section 18.2.1: > > > If the server cannot assign any addresses to an IA in the message > > from the client, the server MUST include the IA in the Reply message > > with no addresses in the IA and a Status Code option in the IA > > containing status code NoAddrsAvail. > > > If so, there may be other IAs that do not contain NoAddrsAvail status > > code. In this case, what should the client do for the other IAs? > >BV> It should use those addresses or Release them. > > > Or, does Section 18.1.8 mean a NoAddrsAvail code in the DHCPv6 options > > field (i.e. not in an IA)? > >BV> It is the status code option in the IA option. > >Okay, but it would be good if Section 18.1.8 is more clear on this, like: > > When the client receives a NoAddrsAvail status for an IA from the > server in response to a Request, the client can either try another > server (perhaps restarting the DHCP server discovery process) or > use the Information-Request to obtain configuration parameters > only. Is the situation more complicated in the case when the client sends more than one IA, and receives NoAddrsAvail status in one IA and addresses in another IA? I think the client should make a decision about each IA individually, (potentially) accepting each IA that has been assigned addresses, and (potentially) retrying each IA that has status NoAddrsAvail. So the text should be clarified, perhaps: The client examines the status code in each IA individually. If the status code is NoAddrsAvail, the client has received no usable addresses in the IA and may choose to try obtaining addresses for the IA from another server. The client uses addresses and other information from any IAs that do not contain a Status Code option. If the client receives no addresses in any of the IAs, it may choose to use the Information-request message to obtain other configuration information. > > 5. Section 18.1.3 says: > > > ...The > > client includes an IA option with all addresses currently assigned to > > the IA in its Renew message. > > > and Section 18.2.3 has corresponding sentences: > > > If the server finds that any of the addresses are not appropriate > > to the link to which the client is attached, the server returns the > > address to the client with lifetimes of 0. > > > If the server finds the addresses in the IA for the client then the > > server sends back the IA to the client with new lifetimes and T1/T2 > > times. The server may choose to change the list of addresses and the > > lifetimes of addresses in IAs that are returned to the client. > > > That is, (in my understanding) > > > - the client sends all addresses for an IA to be renewed. > > - (if the binding is still valid) the server returns all the addresses > > for the IA with 0 or larger lifetimes. > > > Now, what if the client finds a lack of addresses in the reply message > > for the IA? > > > a) the client should ignore the entire IA (or the entire reply) > > b) the client should let the dropped address expire (unless there's > > no more update) > > c) others > > > FYI: Our implementation currently takes the option b), though we do > > this for prefixes in an IA_PD option, not for addresses. > >BV> Option b is correct. The lifetime controls the when addresses on the >BV> client expire. Thus, if a server stops Replying with that address, >BV> the lifetimes will not be updated and eventually the address expires. > >Okay. Agreed. > > 6. there seems to be a corner case about handling the Rapid Commit > > option. Section 17.1.3 says: > > > ... If it does > > not receive such a Reply message and does receive a valid Advertise > > message, the client processes the Advertise message as described in > > section 17.1.3. > > > But what should the client do if it receives a reply message for a > > solicit message with a Rapid Commit option after receiving an > > advertise message? Should the client ignore or accept it? In the > > latter case, what if the client has already sent a request message > > (then it will receive a different reply)? > >BV> The client must wait for a time period after sending a Solicit for >BV> replies from servers. I assume you are saying what happens if after >BV> this initial wait time (described in 17.1.2) the client receives >BV> (or has received) an Advertise and uses it. But then while waiting >BV> for the Reply (to the Request), it receives a (much delayed) Reply >BV> with Rapid Commit? In that case, I think it is really implementation >BV> dependent on what the client does. In my mind, I think it is easier >BV> for the client to continue processing the Advertise / Request / Reply >BV> procedure that it started. But, the client COULD use the Reply with >BV> Rapid Commit if it wanted and it has an acceptable response (ie, >BV> addresses). In either case, one set of server assigned addresses will >BV> not end up being used by the client and the server will reclaim them >BV> once the lifetimes expire. I think dropping the Reply w/Rapid Commit >BV> is easier and better from an implementation standpoint (the reason >BV> is that the client only needs to remember one thing - the Reply it >BV> is waiting for and discards all others). > >I concur. Thanks for the detailed explanation. Agreed. > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 18:30:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24267; Thu, 23 Jan 2003 18:30:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NNmcJ03540; Thu, 23 Jan 2003 18:48:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0NAYHJ13227 for ; Thu, 23 Jan 2003 05:34:17 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02124 for ; Thu, 23 Jan 2003 05:15:16 -0500 (EST) Received: from localhost ([2001:200:182:2000:4852:840e:9722:4156]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0NAIbR58674; Thu, 23 Jan 2003 19:18:37 +0900 (JST) Date: Thu, 23 Jan 2003 19:18:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ot@cisco.com, rdroms@cisco.com Cc: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 77 Subject: [dhcwg] PD lifetimes 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 have several comments about lifetimes of prefix delegation (PD). In this message, I'm talking about draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt. 0. (I once discussed this point privately, but I could not help raising this again. Please forgive me for this repetition.) I cannot understand the reason why the prefix has the notion of the preferred lifetime, whose role is not clear. The role of the valid lifetime is very clear; the period that the delegated site can use the prefix. However, the preferred lifetime only controls a loose relationship with the preferred lifetime in router advertisements within the site, and roughly controls the T1/T2 values. It would be much simpler to have a single "lifetime" only, which controls T1 and T2, and loosely affects the RA lifetimes. In the following comments, however, I'll assume the current valid + preferred scheme. 1. Section 9 says In a message sent by a delegating router the preferred and valid lifetimes should be set to the values specified in section "Router Configuration Variables" of RFC2461 [3], unless administratively configured. Technically, the wording 'values specified in section "Router Configuration Variables"' is not clear, because the router configuration variables of RFC 2461 do not contain the valid and preferred lifetimes. The intended variables should probably be AdvValidLifetime and AdvPreferredLifetime, respectively. Even so, however, I still suspect these are appropriate values. AdvXXXLifetimes are for each end host (in a site), but the lifetimes given by PD affect the entire site. In general (and IMO), the latter should be larger than the former. Today, on typical IPv6 links, we see fixed values of the valid and preferred lifetimes in Router Advertisements, i.e., AdvValidLifetime and AdvPreferredLifetime. However, according to the default values of the PD lifetimes and to the specified relationship between the PD lifetimes and RA lifetimes described in the last paragraph of Section 11.1, it is highly possible to see smaller RA lifetimes than the current typical cases. Moreover, if the requesting router simply uses the PD valid (or preferred) lifetime for the RA valid (or preferred) lifetime, we'll see the RA lifetime being decremented. I believe the default values of PD lifetimes should keep the default values of RA lifetimes in the typical configuration. Thus, I would recommend the following values: The default value for the PD preferred lifetime is (5 / 4) * AdvPreferredLifetime. The default value for the PD valid lifetime can be an arbitrary value, but should not be smaller than AdvValidLifetime + PD preferred lifetime. The rationale of the default is that we won't see "abnormal" RA lifetimes unless the requesting router fails renew/reply exchanges and starts rebinding, assuming that "T2" for the prefix is (equal to or smaller than) the PD preferred lifetime * 0.8. 2. Section 9 also says In a message sent by a delegating router to a requesting router, the requesting router MUST use the value in the valid lifetime field and MAY use the value in the preferred lifetime field. This sentence is not clear to me. Where and how does the requesting router "use" the lifetimes? This ambiguity also makes the term "MUST" and "MAY" unclear. Perhaps the sentence intends to specify the relationship between RA lifetimes and PD lifetimes described in Section 11.1, but I cannot be sure without any reference. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 18:58:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24787; Thu, 23 Jan 2003 18:58:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O0GgJ05311; Thu, 23 Jan 2003 19:16:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O0EoJ05226 for ; Thu, 23 Jan 2003 19:14:50 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24758 for ; Thu, 23 Jan 2003 18:55:35 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NNxkH4000690 for ; Thu, 23 Jan 2003 18:59:49 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA25478 for ; Thu, 23 Jan 2003 18:58:57 -0500 (EST) Message-Id: <4.3.2.7.2.20030123185453.00b65908@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 18:58:52 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Discussion of link-local address in IPv4 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: , There's a very heated discussion about link-local addresses in IPv4 going on in the zeroconf mailing list (subscribe with e-mail containing "subscribe zeroconf your_email_address" to zeroconf-request@merit.edu; archive at http://www.merit.edu/mail.archives/zeroconf/). As much of the discussion talks about interaction between LLv4 and DHCP (including draft-droms-rfc2563-deprecate-00.txt), I encourage anyone interested to join the discussion. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 20:14:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26568; Thu, 23 Jan 2003 20:14:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O1WdJ09703; Thu, 23 Jan 2003 20:32:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O1V7J09650 for ; Thu, 23 Jan 2003 20:31:07 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26541 for ; Thu, 23 Jan 2003 20:11:50 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0O1G5qs007111 for ; Thu, 23 Jan 2003 20:16:05 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA29303 for ; Thu, 23 Jan 2003 20:15:15 -0500 (EST) Message-Id: <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 20:15:10 -0500 To: dhcwg@ietf.org From: Ralph Droms In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: PD lifetimes 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: , 0. The preferred lifetime is there for the case in which the DR and RR have agreed to let the DR control the lifetimes on the links downstream from the RR. 1. In response to your first comment, suppose we change the paragraph in question to: In a message sent by a delegating router the preferred and valid lifetimes for each prefix should be set to the values AdvValidLifetime and AdvPreferredLifetime for that prefix, as specified in section "Router Configuration Variables" of RFC2461 [3], unless administratively configured. If I understand your second comment correctly, following the PD spec will result in the valid lifetimes in the RAs on the downstream links from the RR grow smaller over time, so as not to exceed the valid lifetime for the prefix in the IA_PD, until the RR sends a Renew to extend the valid lifetime on the prefix. Did I get that right? Is this situation a problem for the hosts on the downstream links and should we try to fix the problem? 2. Proposed clarification for the sentence in question: The requesting router MUST select the value of AdvValidLifetime assigned to any prefixes subnetted from a delegated prefix to be less than the preferred lifetime in the prefix option for that delegated prefix. The requesting router MAY use the preferred lifetime in the prefix option for a delegated prefix as the value of AdvPreferredLifetime for a prefix subnetted from that delegated prefix, if the requesting router chooses to allow the delegating router to control that value. Otherwise, the requesting router chooses a value of AdvPreferredLifetime for the subnetted prefix that is less than the value of AdvValidLifetime for that prefix. - Ralph At 07:18 PM 1/23/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >I have several comments about lifetimes of prefix delegation (PD). In >this message, I'm talking about >draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt. > >0. (I once discussed this point privately, but I could not help > raising this again. Please forgive me for this repetition.) > >I cannot understand the reason why the prefix has the notion of >the preferred lifetime, whose role is not clear. The role of the >valid lifetime is very clear; the period that the delegated site can >use the prefix. However, the preferred lifetime only controls a loose >relationship with the preferred lifetime in router advertisements >within the site, and roughly controls the T1/T2 values. > >It would be much simpler to have a single "lifetime" only, which >controls T1 and T2, and loosely affects the RA lifetimes. > >In the following comments, however, I'll assume the current valid + >preferred scheme. > >1. Section 9 says > > In a message sent by a delegating router the preferred and valid > lifetimes should be set to the values specified in section "Router > Configuration Variables" of RFC2461 [3], unless administratively > configured. > >Technically, the wording 'values specified in section "Router >Configuration Variables"' is not clear, because the router >configuration variables of RFC 2461 do not contain the valid and >preferred lifetimes. The intended variables should probably be >AdvValidLifetime and AdvPreferredLifetime, respectively. Even so, >however, I still suspect these are appropriate values. >AdvXXXLifetimes are for each end host (in a site), but the lifetimes >given by PD affect the entire site. In general (and IMO), the latter >should be larger than the former. > >Today, on typical IPv6 links, we see fixed values of the valid and >preferred lifetimes in Router Advertisements, i.e., AdvValidLifetime >and AdvPreferredLifetime. However, according to the default values of >the PD lifetimes and to the specified relationship between the PD >lifetimes and RA lifetimes described in the last paragraph of Section >11.1, it is highly possible to see smaller RA lifetimes than the >current typical cases. Moreover, if the requesting router simply uses >the PD valid (or preferred) lifetime for the RA valid (or preferred) >lifetime, we'll see the RA lifetime being decremented. > >I believe the default values of PD lifetimes should keep the default >values of RA lifetimes in the typical configuration. Thus, I would >recommend the following values: > >The default value for the PD preferred lifetime is >(5 / 4) * AdvPreferredLifetime. >The default value for the PD valid lifetime can be an arbitrary value, >but should not be smaller than AdvValidLifetime + PD preferred lifetime. > >The rationale of the default is that we won't see "abnormal" RA >lifetimes unless the requesting router fails renew/reply exchanges and >starts rebinding, assuming that "T2" for the prefix is (equal to or >smaller than) the PD preferred lifetime * 0.8. > >2. Section 9 also says > > In a message sent by a delegating router to a requesting router, the > requesting router MUST use the value in the valid lifetime field and > MAY use the value in the preferred lifetime field. > >This sentence is not clear to me. Where and how does the requesting >router "use" the lifetimes? This ambiguity also makes the term "MUST" >and "MAY" unclear. Perhaps the sentence intends to specify the >relationship between RA lifetimes and PD lifetimes described in >Section 11.1, but I cannot be sure without any reference. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 23:07:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29669; Thu, 23 Jan 2003 23:07:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4PpJ19358; Thu, 23 Jan 2003 23:25:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4N8J19253 for ; Thu, 23 Jan 2003 23:23:08 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29612 for ; Thu, 23 Jan 2003 23:03:47 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0O47BB6019081; Thu, 23 Jan 2003 20:07:11 -0800 (PST) Received: from C1840447-A.cisco.com (sjc-vpn1-280.cisco.com [10.21.97.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADN90101; Thu, 23 Jan 2003 20:04:00 -0800 (PST) Message-Id: <4.3.2.7.2.20030123191127.00ae0bf0@mira-sjcm-2.cisco.com> X-Sender: junxie@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 19:54:41 -0800 To: "Bernie Volz (EUD)" From: Jun Xie Subject: RE: [dhcwg] additional questions on dhcpv6-28 Cc: JINMEI Tatuya / ???? , dhcwg@ietf.org 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: , At 04:25 PM 1/23/03 -0600, Bernie Volz (EUD) wrote: [...] >I definitely don't think infinite renewals times are a good idea, so I >would not >recommend adding this for T1/T2. Infinite T1/T2 may be helpful during network renembering. It tells the client that the server is no longer willing to extend address/prefix lifetimes and that the addresses/prefixes assigned before should expire at a fixed future time. -Jun _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 23:07:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29693; Thu, 23 Jan 2003 23:07:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4QgJ19386; Thu, 23 Jan 2003 23:26:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4NWJ19264 for ; Thu, 23 Jan 2003 23:23:32 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29633 for ; Thu, 23 Jan 2003 23:04:11 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0O47cSQ007861; Thu, 23 Jan 2003 20:07:38 -0800 (PST) Received: from C1840447-A.cisco.com (sjc-vpn1-280.cisco.com [10.21.97.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADN90120; Thu, 23 Jan 2003 20:04:25 -0800 (PST) Message-Id: <4.3.2.7.2.20030123195456.00ade8c0@mira-sjcm-2.cisco.com> X-Sender: junxie@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 20:05:50 -0800 To: Ralph Droms From: Jun Xie Subject: Re: [dhcwg] additional questions on dhcpv6-28 Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20030123161320.00b69610@funnel.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 04:26 PM 1/23/03 -0500, Ralph Droms wrote: [...] >>1. What should the client do if the preferred lifetime is larger than >> the valid lifetime for an IA address option in a reply message (to >> request/renew, etc)? >> >> I think the address should be ignored, as an analogy to the rule >> (c) of RFC 2462 Section 5.5.3, but the dhcpv6 draft is silent on >> this. > >I suggest adding this text to follow the first paragraph of section >18.1.8., Receipt of Reply Messages, in draft-ietf-dhc-dhcpv6-28.txt. > > The client discards any addresses found in any IAs it receives for > which the preferred lifetime is greater than the valid lifetime. > >Are there other cases of invalid parameters or configuration that >should be mentioned here? How about T1/T2 greater than the shortest valid lifetime in an IA? Is it valid or not? Should it explicitly mention that the combination of preferred lifetime = 0 and valid lifetime > 0 is valid? -Jun _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 23:07:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29717; Thu, 23 Jan 2003 23:07:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4QhJ19402; Thu, 23 Jan 2003 23:26:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4NqJ19273 for ; Thu, 23 Jan 2003 23:23:52 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29643 for ; Thu, 23 Jan 2003 23:04:31 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.6) with ESMTP id h0O47tsv008245; Thu, 23 Jan 2003 20:07:55 -0800 (PST) Received: from C1840447-A.cisco.com (sjc-vpn1-280.cisco.com [10.21.97.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADN90126; Thu, 23 Jan 2003 20:04:44 -0800 (PST) Message-Id: <4.3.2.7.2.20030123200358.00ae7b10@mira-sjcm-2.cisco.com> X-Sender: junxie@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 20:09:07 -0800 To: Ralph Droms From: Jun Xie Subject: Re: [dhcwg] Re: PD lifetimes Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 08:15 PM 1/23/03 -0500, Ralph Droms wrote: [...] >2. Proposed clarification for the sentence in question: > > The requesting router MUST select the value of AdvValidLifetime > assigned to any prefixes subnetted from a delegated prefix to be > less than the preferred lifetime in the prefix option for that ^^^^^^^^^^^^^^^ I think you mean valid lifetime here? -Jun > delegated prefix. The requesting router MAY use the preferred > lifetime in the prefix option for a delegated prefix as the value > of AdvPreferredLifetime for a prefix subnetted from that delegated > prefix, if the requesting router chooses to allow the delegating > router to control that value. Otherwise, the requesting router > chooses a value of AdvPreferredLifetime for the subnetted prefix > that is less than the value of AdvValidLifetime for that prefix. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 23 23:39:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00172; Thu, 23 Jan 2003 23:39:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4wHJ20983; Thu, 23 Jan 2003 23:58:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0O4vnJ20967 for ; Thu, 23 Jan 2003 23:57:49 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00164 for ; Thu, 23 Jan 2003 23:38:27 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0O4ghcX021313 for ; Thu, 23 Jan 2003 23:42:43 -0500 (EST) Received: from rdroms-w2k.cisco.com (shinjuku-equant-dynamic100.cisco.com [64.104.42.100]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA07706 for ; Thu, 23 Jan 2003 23:41:51 -0500 (EST) Message-Id: <4.3.2.7.2.20030123233945.00b3bd28@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 23:40:05 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Re: PD lifetimes In-Reply-To: <4.3.2.7.2.20030123200358.00ae7b10@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Yes ... thanks! - Ralph At 08:09 PM 1/23/2003 -0800, Jun Xie wrote: >At 08:15 PM 1/23/03 -0500, Ralph Droms wrote: >[...] >>2. Proposed clarification for the sentence in question: >> >> The requesting router MUST select the value of AdvValidLifetime >> assigned to any prefixes subnetted from a delegated prefix to be >> less than the preferred lifetime in the prefix option for that > ^^^^^^^^^^^^^^^ >I think you mean valid lifetime here? > >-Jun > >> delegated prefix. The requesting router MAY use the preferred >> lifetime in the prefix option for a delegated prefix as the value >> of AdvPreferredLifetime for a prefix subnetted from that delegated >> prefix, if the requesting router chooses to allow the delegating >> router to control that value. Otherwise, the requesting router >> chooses a value of AdvPreferredLifetime for the subnetted prefix >> that is less than the value of AdvValidLifetime for that prefix. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 24 10:02:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21771; Fri, 24 Jan 2003 10:02:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OFLAJ05243; Fri, 24 Jan 2003 10:21:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OFJTJ05125 for ; Fri, 24 Jan 2003 10:19:29 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21571 for ; Fri, 24 Jan 2003 09:59:48 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h0OF2td10407; Fri, 24 Jan 2003 09:03:05 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h0OF2tY27906; Fri, 24 Jan 2003 09:02:55 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Fri, 24 Jan 2003 09:02:55 -0600 Message-ID: From: "Bernie Volz (EUD)" To: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] questions about dhcpv6-28 Date: Fri, 24 Jan 2003 09:01:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C3B9.7699935C" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C3B9.7699935C Content-Type: text/plain; charset="ISO-8859-1" Comments in line (I also deleted the items on which I have no comments) My comments are prefixed by BV2> just to be clear. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, January 23, 2003 4:30 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 Comments in line... - Ralph At 04:22 PM 1/23/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >Hello, thanks for the quick response, and sorry for not responding >sooner. > > >>>>> On Tue, 14 Jan 2003 08:32:29 -0600, > >>>>> "Bernie Volz (EUD)" said: > > > I have several questions on draft-ietf-dhc-dhcpv6-28.txt from my > > implementation experiences. (It is probably too late to reflect the > > points to the spec before it becomes an RFC, though.) > > > I'd apologize in advance if some (or all) of them were addressed in > > the draft, but I could not find the answers. > > > 1. Section 18.1.8 says: > > > When the client receives a NoBinding status in an IA from the server > > in response to a Renew message or a Rebind message, the client sends > > a Request to reestablish an IA with the server. > > > does this imply that the client must remove the IA before sending the > > request? (I guess the answer is YES, but I'm asking this to be sure.) > >BV> No. As long as the address has a valid lifetime left, the client >BV> should be able to use that address. NoBinding just means that the >BV> server has no record of that binding (perhaps it is a new server >BV> or a server that losts its stable storage). While this situation >BV> is not desireable, it is possible and should work out OK. > >I see. Then I have a related question. Does the client continue or >stop sending Renew or Rebind in this case? > >Also, I happened to have a chance to discuss this case with Ralph, >and, according to the discussion, I have an impression that the >wording could be a bit clearer. Sections 18.2.3 and 18.2.4 have >exactly the same sentence: > > If the server cannot find a client entry for the IA the server > returns the IA containing no addresses with a Status Code option set > to NoBinding in the Reply message. > >according to Ralph, however, the semantics of "the server cannot find >a client entry" is slightly different between the case of renew and >the case of rebind. For the case of renew, the message is only >accepted by the responsible server, so the semantics should have a >"relaxed" sense. For the case of rebind, however, the message is >accepted by all possible servers. Thus, in this case, the semantics >should have a "strict" sense, that is, the server should not send the >NoBinding unless it has an explicit knowledge that the binding has >been invalidated. > >So, for example, suppose a server has rebooted and has lost all >bindings. When the server receives a Renew or Rebind message after it >reboots, the appropriate behavior depends on the message type: > - for Renew, the server must reply with a NoBinding code. > - for Rebind, the server must ignores the message (not to confuse > the recipient). > >It seems to me the current text does not express the sense, and it >could be a source of interoperability problems. (I've actually seen >some interoperability issues among several implementations). As Jinmei-san and I discussed, the Renew and Rebind cases are different. In the case of Renew, the server from which the client obtained the IA is identified by the Server Identifier option, so the server can authoritatively respond with NoBinding. The specification is ambiguous about the use of the Server Identitifier option. Section 18.1.3, "Creation and Transmission of Renew Messages" of draft-ietf-dhc-dhcpv6-28.txt requires that the client include "the identifier of the destination server in a Server Identifier option." However, section 18.2.3, "Receipt of Renew Messages", does *not* require that a server discard any Renew messages in which the contents of the Server Identifier option does not match the DUID of the receiving server. I think the specification needs to be corrected. BV2> Yes, agreed we should fix 18.2.3. (Perhaps we should even consider BV2> whether additional rules should be added in section 15.10 on Replies BV2> to specific messages? Such as Server Identifier must match that sent BV2> in any "request".) The specification may also require clarification in the case of Rebind, when the server should respond with NoBinding only if it has authoritative information that there is no binding for the client. There may be another alternative, which would be to allow the client to ignore Reply messages (ins response to a Rebind message )with NoBinding status, if the client receives another Reply message from a server that does find the binding. BV2> What about just requiring all servers to respond but having the BV2> client only take the NoBinding from the Server Identifier it last BV2> used with that binding as being authoritative. I'm not sure how a BV2> server could know whether it has (or had) authoritative information. BV2> Placing this responsibility on the client is reasonable and means BV2> that a complete loss of information at a server does not require BV2> any special server processing to handle this. > > 2. What should a client do if it receives an IA_NA in a reply message > > where T1 > T2 > 0? > > a) the client must ignore the option (or the entire reply message) > > b) the client must treat as if T1 = T2 > > c) the client must choose appropriate alternatives for T1 and T2. > > (this cannot be an option, though, because Section 22.4 says the > > client MUST use T1 and T2 if they are non-0) > > d) others > > > FYI: Our implementation currently takes the option a). > >BV> (a) is probably a fine action as it really is invalid. T1 <= T2. > >Okay. Jinmei-san, which choice does your implementation make? Ignore the option or the entire message? And, does it ignore the entire IA_NA option? I worry about ignoring just the option, which might lead to unexpected and hard-to-diagnose behavior. Ignoring the entire message would be easier to recognize as incorrect behavior. BV2> I agree with Ralph that dropping the entire message might make better BV2> sense. > > 4. Section 18.1.8 says > > > When the client receives a NoAddrsAvail status from the server in > > response to a Request, the client can either try another server > > (perhaps restarting the DHCP server discovery process) or use the > > Information-Request to obtain configuration parameters only. > > > This sentence is not very clear to me. I interpreted this sentence > > corresponds to the following part of Section 18.2.1: > > > If the server cannot assign any addresses to an IA in the message > > from the client, the server MUST include the IA in the Reply message > > with no addresses in the IA and a Status Code option in the IA > > containing status code NoAddrsAvail. > > > If so, there may be other IAs that do not contain NoAddrsAvail status > > code. In this case, what should the client do for the other IAs? > >BV> It should use those addresses or Release them. > > > Or, does Section 18.1.8 mean a NoAddrsAvail code in the DHCPv6 options > > field (i.e. not in an IA)? > >BV> It is the status code option in the IA option. > >Okay, but it would be good if Section 18.1.8 is more clear on this, like: > > When the client receives a NoAddrsAvail status for an IA from the > server in response to a Request, the client can either try another > server (perhaps restarting the DHCP server discovery process) or > use the Information-Request to obtain configuration parameters > only. Is the situation more complicated in the case when the client sends more than one IA, and receives NoAddrsAvail status in one IA and addresses in another IA? I think the client should make a decision about each IA individually, (potentially) accepting each IA that has been assigned addresses, and (potentially) retrying each IA that has status NoAddrsAvail. So the text should be clarified, perhaps: The client examines the status code in each IA individually. If the status code is NoAddrsAvail, the client has received no usable addresses in the IA and may choose to try obtaining addresses for the IA from another server. The client uses addresses and other information from any IAs that do not contain a Status Code option. If the client receives no addresses in any of the IAs, it may choose to use the Information-request message to obtain other configuration information. BV2> Agreed. It is IA specific. > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2C3B9.7699935C Content-Type: text/html; charset="ISO-8859-1" RE: [dhcwg] questions about dhcpv6-28

Comments in line (I also deleted the items on which I have no comments)

My comments are prefixed by BV2> just to be clear.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, January 23, 2003 4:30 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] questions about dhcpv6-28


Comments in line...

- Ralph

At 04:22 PM 1/23/2003 +0900, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>Hello, thanks for the quick response, and sorry for not responding
>sooner.
>
> >>>>> On Tue, 14 Jan 2003 08:32:29 -0600,
> >>>>> "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> said:
>
> > I have several questions on draft-ietf-dhc-dhcpv6-28.txt from my
> > implementation experiences.  (It is probably too late to reflect the
> > points to the spec before it becomes an RFC, though.)
>
> > I'd apologize in advance if some (or all) of them were addressed in
> > the draft, but I could not find the answers.
>
> > 1. Section 18.1.8 says:
>
> >    When the client receives a NoBinding status in an IA from the server
> >    in response to a Renew message or a Rebind message, the client sends
> >    a Request to reestablish an IA with the server.
>
> > does this imply that the client must remove the IA before sending the
> > request?  (I guess the answer is YES, but I'm asking this to be sure.)
>
>BV> No. As long as the address has a valid lifetime left, the client
>BV> should be able to use that address. NoBinding just means that the
>BV> server has no record of that binding (perhaps it is a new server
>BV> or a server that losts its stable storage). While this situation
>BV> is not desireable, it is possible and should work out OK.
>
>I see.  Then I have a related question.  Does the client continue or
>stop sending Renew or Rebind in this case?
>
>Also, I happened to have a chance to discuss this case with Ralph,
>and, according to the discussion, I have an impression that the
>wording could be a bit clearer.  Sections 18.2.3 and 18.2.4 have
>exactly the same sentence:
>
>    If the server cannot find a client entry for the IA the server
>    returns the IA containing no addresses with a Status Code option set
>    to NoBinding in the Reply message.
>
>according to Ralph, however, the semantics of "the server cannot find
>a client entry" is slightly different between the case of renew and
>the case of rebind.  For the case of renew, the message is only
>accepted by the responsible server, so the semantics should have a
>"relaxed" sense.  For the case of rebind, however, the message is
>accepted by all possible servers.  Thus, in this case, the semantics
>should have a "strict" sense, that is, the server should not send the
>NoBinding unless it has an explicit knowledge that the binding has
>been invalidated.
>
>So, for example, suppose a server has rebooted and has lost all
>bindings.  When the server receives a Renew or Rebind message after it
>reboots, the appropriate behavior depends on the message type:
>   - for Renew, the server must reply with a NoBinding code.
>   - for Rebind, the server must ignores the message (not to confuse
>     the recipient).
>
>It seems to me the current text does not express the sense, and it
>could be a source of interoperability problems.  (I've actually seen
>some interoperability issues among several implementations).

As Jinmei-san and I discussed, the Renew and Rebind cases are different.
In the case of Renew, the server from which the client obtained the IA
is identified by the Server Identifier option, so the server can
authoritatively respond with NoBinding.

The specification is ambiguous about the use of the Server
Identitifier option.  Section 18.1.3, "Creation and Transmission of
Renew Messages" of draft-ietf-dhc-dhcpv6-28.txt requires that the
client include "the identifier of the destination server in a Server
Identifier option."  However, section 18.2.3, "Receipt of Renew
Messages", does *not* require that a server discard any Renew messages
in which the contents of the Server Identifier option does not match
the DUID of the receiving server.  I think the specification needs to
be corrected.

BV2> Yes, agreed we should fix 18.2.3. (Perhaps we should even consider
BV2> whether additional rules should be added in section 15.10 on Replies
BV2> to specific messages? Such as Server Identifier must match that sent
BV2> in any "request".)

The specification may also require clarification in the case of Rebind,
when the server should respond with NoBinding only if it has
authoritative information that there is no binding for the client.
There may be another alternative, which would  be to allow the client
to ignore Reply messages (ins response to a Rebind message )with
NoBinding status, if the client receives another Reply message
from a server that does find the binding.

BV2> What about just requiring all servers to respond but having the
BV2> client only take the NoBinding from the Server Identifier it last
BV2> used with that binding as being authoritative. I'm not sure how a
BV2> server could know whether it has (or had) authoritative information.
BV2> Placing this responsibility on the client is reasonable and means
BV2> that a complete loss of information at a server does not require
BV2> any special server processing to handle this.

> > 2. What should a client do if it receives an IA_NA in a reply message
> >    where T1 > T2 > 0?
> >    a) the client must ignore the option (or the entire reply message)
> >    b) the client must treat as if T1 = T2
> >    c) the client must choose appropriate alternatives for T1 and T2.
> >     (this cannot be an option, though, because Section 22.4 says the
> >      client MUST use T1 and T2 if they are non-0)
> >    d) others
>
> >    FYI: Our implementation currently takes the option a).
>
>BV> (a) is probably a fine action as it really is invalid. T1 <= T2.
>
>Okay.

Jinmei-san, which choice does your implementation make?  Ignore the
option or the entire message?  And, does it ignore the entire IA_NA
option?  I worry about ignoring just the option, which might lead
to unexpected and hard-to-diagnose behavior.  Ignoring the entire
message would be easier to recognize as incorrect behavior.

BV2> I agree with Ralph that dropping the entire message might make better
BV2> sense.

> > 4. Section 18.1.8 says
>
> >    When the client receives a NoAddrsAvail status from the server in
> >    response to a Request, the client can either try another server
> >    (perhaps restarting the DHCP server discovery process) or use the
> >    Information-Request to obtain configuration parameters only.
>
> > This sentence is not very clear to me.  I interpreted this sentence
> > corresponds to the following part of Section 18.2.1:
>
> >    If the server cannot assign any addresses to an IA in the message
> >    from the client, the server MUST include the IA in the Reply message
> >    with no addresses in the IA and a Status Code option in the IA
> >    containing status code NoAddrsAvail.
>
> > If so, there may be other IAs that do not contain NoAddrsAvail status
> > code.  In this case, what should the client do for the other IAs?
>
>BV> It should use those addresses or Release them.
>
> > Or, does Section 18.1.8 mean a NoAddrsAvail code in the DHCPv6 options
> > field (i.e. not in an IA)?
>
>BV> It is the status code option in the IA option.
>
>Okay, but it would be good if Section 18.1.8 is more clear on this, like:
>
>     When the client receives a NoAddrsAvail status for an IA from the
>     server in response to a Request, the client can either try another
>     server (perhaps restarting the DHCP server discovery process) or
>     use the Information-Request to obtain configuration parameters
>     only.

Is the situation more complicated in the case when the client sends more
than one IA, and receives NoAddrsAvail status in one IA and addresses
in another IA?  I think the client should make a decision about each IA
individually, (potentially) accepting each IA that has been assigned
addresses, and (potentially) retrying each IA that has status
NoAddrsAvail.  So the text should be clarified, perhaps:

    The client examines the status code in each IA individually.  If
    the status code is NoAddrsAvail, the client has received no usable
    addresses in the IA and may choose to try obtaining addresses for
    the IA from another server.  The client uses addresses and other
    information from any IAs that do not contain a Status Code option.
    If the client receives no addresses in any of the IAs, it may
    choose to use the Information-request message to obtain other
    configuration information.

BV2> Agreed. It is IA specific.

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

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

------_=_NextPart_001_01C2C3B9.7699935C-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 24 13:37:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28042; Fri, 24 Jan 2003 13:37:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OItbJ20365; Fri, 24 Jan 2003 13:55:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OIqTJ20240 for ; Fri, 24 Jan 2003 13:52:29 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27867 for ; Fri, 24 Jan 2003 13:32:51 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0OIVYP19232; Fri, 24 Jan 2003 12:31:34 -0600 (CST) Date: Fri, 24 Jan 2003 10:36:33 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ralph Droms , zeroconf@merit.edu, dhcwg@ietf.org To: Robert Elz From: Ted Lemon In-Reply-To: <23248.1043419456@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [dhcwg] RFC2563: Threat or Danger? 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 > I know that if > I was writing a client, and I got an offer which said "no addresses > for you" > and another that said "here's an address you can use" (or even > "configure > yourself a LL address") then I know which offer would be the one I'd be DHCP cant' say "configure yourself an LL address." I've got a couple of problems with what you've said, and agree with other things you've said. The DoS problem is definitely not the only reason to deprecate RFC2563, and I will give some other reasons to deprecate it. I will also point out some reasons why the DoS attack enabled by RFC2563 is easier to do than the a direct IPv4ll DoS attack. Finally, I will point out why the RFC2563 DoS is a more difficult attack from which to recover. 1. Non-DoS reasons to deprecate RFC2563. - It's voluntary, so it doesn't work - if you really want this, RFC2563 isn't the way to get it. - It requires a change to the DHCP protocol state machine - a response is generated by the server according to RFC2563 in a case where no response would be generated according to RFC2131. This requires significant changes to clients and servers, which I think is one reason why nobody has implemented RFC2563 to date. - Customers are not asking for it, and nobody has implemented it, even though the theoretical need for such a mechanism after almost five years of deployment. - RFC2563 demands that the client operate in conflict with the wishes of the owner of the client. So it is difficult for a client vendor (e.g., Microsoft or Apple) to justify implementing RFC2563 - it is likely to cost them business, or generate support calls that will cost them money. I think this is the main reason RFC2563 has not been implemented. 2. RFC2563 enables off-network attacks Having said that, I think you underestimate the value of the DoS attack that RFC2563 enables. RFC2563 enables off-network DoS attacks, whereas without RFC2563 the only possible attacks require that the attacker be attached to the network. There are two kinds of off-network attacks that it enables: - Speculative attacks, where you guess the MAC address and transaction ID of a device and send it DHCP packets in the hopes that it will be in the right state to be disabled by these attacks. - Relay agent-based attacks, where you listen to the relay agent and supply a bogus response that shuts off IPv4ll. This second attack is quite significant, as some folks have mentioned, because we know of ISPs who perform this kind of attack on their customers already. Currently they do it by providing bogus IP addresses rather than by using the RFC2563 mechanism, but if RFC2563 were widely implemented by clients, we have reason to suspect that it would be used to attack and disable legitimate networks. One reason why ISPs may perform this attack is because when you don't respond to a DHCP client, it keeps asking, and never shuts up. If you can send it a "shut up" response, you eliminate all these clients. So if we give ISPs rfc2563, that is, if it becomes widely implemented, it will be used to shut up clients. The effect of this will be to break networks that ought to work. So in fact the DoS argument against RFC2563 3. It is harder to identify and eliminate an RFC2563 attacker Another problem with RFC2563 is that it's easy to use it to deny service. A client pipes up with a DHCPDISCOVER. You tell it to shut up. End of story. With IPv4ll, in order to shut up a client, you have to be constantly listening for ARPs and defending IP addresses. So a DoS attack of this kind would be very easy to track down. By contrast, an RFC2563 attacker can attack at an opportune moment, disable one or more clients, and then go silent for an extended period of time, so there's no easy way to track it down. 4. No automatic recovery from an RFC2563 DoS attack. Once you have identified an attacker that is using the defend-all-addresses attack, you can unplug attacker from the network, and the network immediately starts working again. In comparison, the RFC2563 DoS requires you to physically manipulate every computer on the network - you either have to power cycle them, or if they can detect link state transitions, disconnect and reconnect each device from the network. This is because once the client has been told to shut up, it shuts up, so there's no automatic recovery mechanism. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 24 15:30:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01558; Fri, 24 Jan 2003 15:30:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKnGJ27741; Fri, 24 Jan 2003 15:49:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OKluJ27702 for ; Fri, 24 Jan 2003 15:47:56 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01518 for ; Fri, 24 Jan 2003 15:28:15 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h0OKVgb20500; Fri, 24 Jan 2003 14:31:42 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h0OKVfq05713; Fri, 24 Jan 2003 14:31:42 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Fri, 24 Jan 2003 14:31:41 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Ted Lemon'" Cc: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] RFC2563: Threat or Danger? Date: Fri, 24 Jan 2003 14:30:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C3E7.292A9174" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C3E7.292A9174 Content-Type: text/plain; charset="iso-8859-1" Ted: This is great analysis and response. Perhaps you and Ralph should update draft-droms-rfc2563-deprecate-00.txt to include this information. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Friday, January 24, 2003 1:37 PM To: Robert Elz Cc: Ralph Droms; zeroconf@merit.edu; dhcwg@ietf.org Subject: [dhcwg] RFC2563: Threat or Danger? > I know that if > I was writing a client, and I got an offer which said "no addresses > for you" > and another that said "here's an address you can use" (or even > "configure > yourself a LL address") then I know which offer would be the one I'd be DHCP cant' say "configure yourself an LL address." I've got a couple of problems with what you've said, and agree with other things you've said. The DoS problem is definitely not the only reason to deprecate RFC2563, and I will give some other reasons to deprecate it. I will also point out some reasons why the DoS attack enabled by RFC2563 is easier to do than the a direct IPv4ll DoS attack. Finally, I will point out why the RFC2563 DoS is a more difficult attack from which to recover. 1. Non-DoS reasons to deprecate RFC2563. - It's voluntary, so it doesn't work - if you really want this, RFC2563 isn't the way to get it. - It requires a change to the DHCP protocol state machine - a response is generated by the server according to RFC2563 in a case where no response would be generated according to RFC2131. This requires significant changes to clients and servers, which I think is one reason why nobody has implemented RFC2563 to date. - Customers are not asking for it, and nobody has implemented it, even though the theoretical need for such a mechanism after almost five years of deployment. - RFC2563 demands that the client operate in conflict with the wishes of the owner of the client. So it is difficult for a client vendor (e.g., Microsoft or Apple) to justify implementing RFC2563 - it is likely to cost them business, or generate support calls that will cost them money. I think this is the main reason RFC2563 has not been implemented. 2. RFC2563 enables off-network attacks Having said that, I think you underestimate the value of the DoS attack that RFC2563 enables. RFC2563 enables off-network DoS attacks, whereas without RFC2563 the only possible attacks require that the attacker be attached to the network. There are two kinds of off-network attacks that it enables: - Speculative attacks, where you guess the MAC address and transaction ID of a device and send it DHCP packets in the hopes that it will be in the right state to be disabled by these attacks. - Relay agent-based attacks, where you listen to the relay agent and supply a bogus response that shuts off IPv4ll. This second attack is quite significant, as some folks have mentioned, because we know of ISPs who perform this kind of attack on their customers already. Currently they do it by providing bogus IP addresses rather than by using the RFC2563 mechanism, but if RFC2563 were widely implemented by clients, we have reason to suspect that it would be used to attack and disable legitimate networks. One reason why ISPs may perform this attack is because when you don't respond to a DHCP client, it keeps asking, and never shuts up. If you can send it a "shut up" response, you eliminate all these clients. So if we give ISPs rfc2563, that is, if it becomes widely implemented, it will be used to shut up clients. The effect of this will be to break networks that ought to work. So in fact the DoS argument against RFC2563 3. It is harder to identify and eliminate an RFC2563 attacker Another problem with RFC2563 is that it's easy to use it to deny service. A client pipes up with a DHCPDISCOVER. You tell it to shut up. End of story. With IPv4ll, in order to shut up a client, you have to be constantly listening for ARPs and defending IP addresses. So a DoS attack of this kind would be very easy to track down. By contrast, an RFC2563 attacker can attack at an opportune moment, disable one or more clients, and then go silent for an extended period of time, so there's no easy way to track it down. 4. No automatic recovery from an RFC2563 DoS attack. Once you have identified an attacker that is using the defend-all-addresses attack, you can unplug attacker from the network, and the network immediately starts working again. In comparison, the RFC2563 DoS requires you to physically manipulate every computer on the network - you either have to power cycle them, or if they can detect link state transitions, disconnect and reconnect each device from the network. This is because once the client has been told to shut up, it shuts up, so there's no automatic recovery mechanism. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2C3E7.292A9174 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] RFC2563: Threat or Danger?

Ted:

This is great analysis and response. Perhaps you and Ralph should update
draft-droms-rfc2563-deprecate-00.txt to include this information.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]
Sent: Friday, January 24, 2003 1:37 PM
To: Robert Elz
Cc: Ralph Droms; zeroconf@merit.edu; dhcwg@ietf.org
Subject: [dhcwg] RFC2563: Threat or Danger?


> I know that if
> I was writing a client, and I got an offer which said "no addresses
> for you"
> and another that said "here's an address you can use" (or even
> "configure
> yourself a LL address") then I know which offer would be the one I'd be

DHCP cant' say "configure yourself an LL address."

I've got a couple of problems with what you've said, and agree with
other things you've said.   The DoS problem is definitely not the only
reason to deprecate RFC2563, and I will give some other reasons to
deprecate it.   I will also point out some reasons why the DoS attack
enabled by RFC2563 is easier to do than the a direct IPv4ll DoS attack.
   Finally, I will point out why the RFC2563 DoS is a more difficult
attack from which to recover.

1. Non-DoS reasons to deprecate RFC2563.

- It's voluntary, so it doesn't work - if you really want this, RFC2563
isn't the way to get it.
- It requires a change to the DHCP protocol state machine - a response
is generated by the server according to RFC2563 in a case where no
response would be generated according to RFC2131.   This requires
significant changes to clients and servers, which I think is one reason
why nobody has implemented RFC2563 to date.
- Customers are not asking for it, and nobody has implemented it, even
though the theoretical need for such a mechanism after almost five
years of deployment.
- RFC2563 demands that the client operate in conflict with the wishes
of the owner of the client.   So it is difficult for a client vendor
(e.g., Microsoft or Apple) to justify implementing RFC2563 - it is
likely to cost them business, or generate support calls that will cost
them money.   I think this is the main reason RFC2563 has not been
implemented.

2. RFC2563 enables off-network attacks

Having said that, I think you underestimate the value of the DoS attack
that RFC2563 enables.   RFC2563 enables off-network DoS attacks,
whereas without RFC2563 the only possible attacks require that the
attacker be attached to the network.   There are two kinds of
off-network attacks that it enables:

- Speculative attacks, where you guess the MAC address and transaction
ID of a device and send it DHCP packets in the hopes that it will be in
the right state to be disabled by these attacks.
- Relay agent-based attacks, where you listen to the relay agent and
supply a bogus response that shuts off IPv4ll.

This second attack is quite significant, as some folks have mentioned,
because we know of ISPs who perform this kind of attack on their
customers already.   Currently they do it by providing bogus IP
addresses rather than by using the RFC2563 mechanism, but if RFC2563
were widely implemented by clients, we have reason to suspect that it
would be used to attack and disable legitimate networks.

One reason why ISPs may perform this attack is because when you don't
respond to a DHCP client, it keeps asking, and never shuts up.   If you
can send it a "shut up" response, you eliminate all these clients.   So
if we give ISPs rfc2563, that is, if it becomes widely implemented, it
will be used to shut up clients.   The effect of this will be to break
networks that ought to work.   So in fact the DoS argument against
RFC2563

3. It is harder to identify and eliminate an RFC2563 attacker

Another problem with RFC2563 is that it's easy to use it to deny
service.   A client pipes up with a DHCPDISCOVER.   You tell it to shut
up.   End of story.   With IPv4ll, in order to shut up a client, you
have to be constantly listening for ARPs and defending IP addresses.  
So a DoS attack of this kind would be very easy to track down.   By
contrast, an RFC2563 attacker can attack at an opportune moment,
disable one or more clients, and then go silent for an extended period
of time, so there's no easy way to track it down.

4. No automatic recovery from an RFC2563 DoS attack.

Once you have identified an attacker that is using the
defend-all-addresses attack, you can unplug  attacker from the network,
and the network immediately starts working again.   In comparison, the
RFC2563 DoS requires you to physically manipulate every computer on the
network - you either have to power cycle them, or if they can detect
link state transitions, disconnect and reconnect each device from the
network.   This is because once the client has been told to shut up, it
shuts up, so there's no automatic recovery mechanism.

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

------_=_NextPart_001_01C2C3E7.292A9174-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Jan 24 15:48:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01889; Fri, 24 Jan 2003 15:48:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OL7NJ28877; Fri, 24 Jan 2003 16:07:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OL6jJ28263 for ; Fri, 24 Jan 2003 16:06:45 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01871 for ; Fri, 24 Jan 2003 15:47:04 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id h0OKoWd14896; Fri, 24 Jan 2003 14:50:32 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h0OKoWI11639; Fri, 24 Jan 2003 14:50:32 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Fri, 24 Jan 2003 14:50:31 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Jun Xie'" , Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] additional questions on dhcpv6-28 Date: Fri, 24 Jan 2003 14:49:01 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C3EA.054C2E7C" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C3EA.054C2E7C Content-Type: text/plain; charset="iso-8859-1" Doesn't this contradict your previous email: Infinite T1/T2 may be helpful during network renumbering. It tells the client that the server is no longer willing to extend address/prefix lifetimes and that the addresses/prefixes assigned before should expire at a fixed future time. And, this is just the case where I would expect T1/T2 to be greater than any lifetime in the IA ... it tells the client that the server is NOT willing to renew the lifetimes on the address. So, it seems like the only time we would need infinite T1/T2 times is if we allowed infinite lifetimes. But I don't have any major objection to having 0xffffffff defined as "infinite" instead of 2^32-1 seconds. We might also want to be clear that T1/T2, valid and preferred lifetimes are all unsigned values. I didn't see that -28 did this. (RFC 2461 says that lifetimes are 32-bit unsigned integers.) - Bernie -----Original Message----- From: Jun Xie [mailto:junxie@cisco.com] Sent: Thursday, January 23, 2003 11:06 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] additional questions on dhcpv6-28 At 04:26 PM 1/23/03 -0500, Ralph Droms wrote: [...] >>1. What should the client do if the preferred lifetime is larger than >> the valid lifetime for an IA address option in a reply message (to >> request/renew, etc)? >> >> I think the address should be ignored, as an analogy to the rule >> (c) of RFC 2462 Section 5.5.3, but the dhcpv6 draft is silent on >> this. > >I suggest adding this text to follow the first paragraph of section >18.1.8., Receipt of Reply Messages, in draft-ietf-dhc-dhcpv6-28.txt. > > The client discards any addresses found in any IAs it receives for > which the preferred lifetime is greater than the valid lifetime. > >Are there other cases of invalid parameters or configuration that >should be mentioned here? How about T1/T2 greater than the shortest valid lifetime in an IA? Is it valid or not? Should it explicitly mention that the combination of preferred lifetime = 0 and valid lifetime > 0 is valid? -Jun _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C2C3EA.054C2E7C Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] additional questions on dhcpv6-28

Doesn't this contradict your previous email:

  Infinite T1/T2 may be helpful during network renumbering. It tells the
  client that the server is no longer willing to extend address/prefix
  lifetimes and that the addresses/prefixes assigned before should
  expire at a fixed future time.

And, this is just the case where I would expect T1/T2 to be greater than
any lifetime in the IA ... it tells the client that the server is NOT
willing to renew the lifetimes on the address.

So, it seems like the only time we would need infinite T1/T2 times is if
we allowed infinite lifetimes. But I don't have any major objection to
having 0xffffffff defined as "infinite" instead of 2^32-1 seconds.

We might also want to be clear that T1/T2, valid and preferred lifetimes
are all unsigned values. I didn't see that -28 did this. (RFC 2461 says
that lifetimes are 32-bit unsigned integers.)

- Bernie

-----Original Message-----
From: Jun Xie [mailto:junxie@cisco.com]
Sent: Thursday, January 23, 2003 11:06 PM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] additional questions on dhcpv6-28


At 04:26 PM 1/23/03 -0500, Ralph Droms wrote:
[...]
>>1. What should the client do if the preferred lifetime is larger than
>>    the valid lifetime for an IA address option in a reply message (to
>>    request/renew, etc)?
>>
>>    I think the address should be ignored, as an analogy to the rule
>>    (c) of RFC 2462 Section 5.5.3, but the dhcpv6 draft is silent on
>>    this.
>
>I suggest adding this text to follow the first paragraph of section
>18.1.8., Receipt of Reply Messages, in draft-ietf-dhc-dhcpv6-28.txt.
>
>    The client discards any addresses found in any IAs it receives for
>    which the preferred lifetime is greater than the valid lifetime.
>
>Are there other cases of invalid parameters or configuration that
>should be mentioned here?

How about T1/T2 greater than the shortest valid lifetime in an IA?
Is it valid or not? Should it explicitly mention that the combination
of preferred lifetime = 0 and valid lifetime > 0 is valid?

-Jun



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

------_=_NextPart_001_01C2C3EA.054C2E7C-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 25 03:10:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21730; Sat, 25 Jan 2003 03:10:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P8RYJ08980; Sat, 25 Jan 2003 03:27:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0P6g6J26864 for ; Sat, 25 Jan 2003 01:42:06 -0500 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11082 for ; Sat, 25 Jan 2003 01:21:42 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00990; Fri, 24 Jan 2003 23:24:51 -0700 (MST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0P6OkP18551; Sat, 25 Jan 2003 07:24:47 +0100 (MET) Date: Sat, 25 Jan 2003 06:46:26 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [dhcwg] Re: PD lifetimes To: Ralph Droms Cc: dhcwg@ietf.org In-Reply-To: "Your message with ID" <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com> Message-ID: 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: , > 0. The preferred lifetime is there for the case in which the DR and RR have > agreed to let the DR control the lifetimes on the links downstream from the > RR. But there are two possible uses of this that need slightly different behavior: 1. The DHCP server is suggesting that the RAs sent by the router have a valid and preferred lifetime of X and Y respectively, that do not decrement over time. This is a useful mode when no renumbering is imminent but you want to control the lifetimes so that you know how quickly you can renumber. 2. The DHCP server is in the process of renumbering the site thus it it telling the router to send RAs with lifetimes that decrement over time so that they will reach zero X and Y seconds, respectively, after the DHCP reply was sent from the server. This is useful when renumbering is in progress - a new prefix has been introduced and the old prefix is counting down its lifetime. Note that RFC 2461 has this ability in its conceptual router variables e.g. AdvValidLifetime The value to be placed in the Valid Lifetime in the Prefix Information option, in seconds. The designated value of all 1's (0xffffffff) represents infinity. Implementations MUST allow AdvValidLifetime to be specified in two ways: - a time that decrements in real time, that is, one that will result in a Lifetime of zero at the specified time in the future, or - a fixed time that stays the same in consecutive advertisements. and similar text for AdvPreferredLifetime. Presumably the PD draft could do this as well by having a bit (or two) indicating wheter the lifetime(s) should decrement in real time or be constant. Would that make sense? Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 25 06:45:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23143; Sat, 25 Jan 2003 06:45:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PC5BJ17777; Sat, 25 Jan 2003 07:05:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PBvPJ17567 for ; Sat, 25 Jan 2003 06:57:25 -0500 Received: from ratree.psu.ac.th (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23017 for ; Sat, 25 Jan 2003 06:37:24 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0PBekR09078; Sat, 25 Jan 2003 18:40:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0PBee828911; Sat, 25 Jan 2003 22:40:41 +1100 (EST) From: Robert Elz To: Ted Lemon cc: Ralph Droms , zeroconf@merit.edu, dhcwg@ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Jan 2003 18:40:40 +0700 Message-ID: <28909.1043494840@munnari.OZ.AU> Subject: [dhcwg] Re: RFC2563: Threat or Danger? 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: , Date: Fri, 24 Jan 2003 10:36:33 -0800 From: Ted Lemon Message-ID: | DHCP cant' say "configure yourself an LL address." That's what 2653 says isn't it - or perhaps more accurately, 2653 assumes that if nothing is said, then not getting an address from DHCP (the DHCP server ignores the DHCPDISCOVER) is implicitly telling the client to go configure a LL address (if it wants to do that of course). | 1. Non-DoS reasons to deprecate RFC2563. | | - It's voluntary, so it doesn't work - if you really want this, RFC2563 | isn't the way to get it. Huh? Everything here is voluntary - I (at the very least) do not mean to imply coercion. It is no different than assuming that clients that are offered an address via DHCP will actually configure the address they're offered, rather that some other address they pick that is on the same network (using the subnet-mask from the DHCPOFFER to work that out). If the client deliberately decides to ignore the advice, that's its choice. If the user has told it to do that, fine. If the vendor has implemented it to always do that, that's their choice, but they wouldn't be able to claim conformance with 2563 obviously, and not with the LL std if that ends up requiring 2563 be implemented (or something like it). | - It requires a change to the DHCP protocol state machine - a response | is generated by the server according to RFC2563 in a case where no | response would be generated according to RFC2131. I am pretty sure that I can make the ISC server generate 2563 responses with no changes at all, but I haven't yet tested it. To work "easily" from the servers point of view, yes, that would require some modifications I suspect. | - RFC2563 demands that the client operate in conflict with the wishes | of the owner of the client. No it doesn't. It can't, nothing the IETF produces can require that. | So it is difficult for a client vendor | (e.g., Microsoft or Apple) to justify implementing RFC2563 - it is | likely to cost them business, or generate support calls that will cost | them money. Only if servers start supplying the option, right? And your thesis above was that none do or ever will. So, how could this possibly cost anything more than the implementation cost (like 50 lines of code, max). On the other hand, if servers do start supplying this option, because their operators want them to, and then the servers are configured to generate the option, and the option says "no LL addresses" when sent, and the clients ignore that, don't you think that would generate support calls ? | 2. RFC2563 enables off-network attacks | | Having said that, I think you underestimate the value of the DoS attack | that RFC2563 enables. RFC2563 enables off-network DoS attacks, | whereas without RFC2563 the only possible attacks require that the | attacker be attached to the network. There are two kinds of | off-network attacks that it enables: | This second attack is quite significant, as some folks have mentioned, | because we know of ISPs who perform this kind of attack on their | customers already. Hmm - this doesn't follow, first you say that 2563 enables these attacks, and then that they're already being carried out, without 2563. | Currently they do it by providing bogus IP | addresses rather than by using the RFC2563 mechanism, but if RFC2563 | were widely implemented by clients, we have reason to suspect that it | would be used to attack and disable legitimate networks. If I were to be subject to such an attack, I'd much rather it was carried out using 2563 than by handing me a bogus IP address. That way at least I could easily see what was happening, my system would tell me (you were refused an IP address), rather than proceeding happily with an IP address that looks to be just fine, but doesn't actually work. So, if this is the threat, then bring on 2563, please! | One reason why ISPs may perform this attack is because when you don't | respond to a DHCP client, it keeps asking, and never shuts up. It doesn't matter why they might choose to do this, if they do it now, and can do it now, and will still be able to do it (in a different way) using 2563 (if clients implemented it) then nothing has really changed, except 2563 makes things more obvious (so if the "attacker"/ISP is trying to be as nice as they can, while keeping down the load on their server, they'd use 2653, if they're really trying to hide what they're doing, they'll keep doing it the way they are now). This is just another aspect of Keith's reply to Ralph's first message on this general thread - the DoS potential of 2563 is really identical to the DoS potential of DHCP without 2563. | 3. It is harder to identify and eliminate an RFC2563 attacker | | Another problem with RFC2563 is that it's easy to use it to deny | service. A client pipes up with a DHCPDISCOVER. You tell it to shut | up. End of story. Until it decides to try again, and assuming there is no other DHCP server that actually offers an address. The story continues... | With IPv4ll, in order to shut up a client, you | have to be constantly listening for ARPs and defending IP addresses. So? You have to keep watching for DHCPDISCOVERS anyway, watching for ARP is not really all that hard to do. | So a DoS attack of this kind would be very easy to track down. By | contrast, an RFC2563 attacker can attack at an opportune moment, | disable one or more clients, and then go silent for an extended period | of time, so there's no easy way to track it down. Huh? You just have the client do a DHCPDISCOVER and watch what happens next time. If the attacker is being silent, then the client goes ahead and gets its LL address after all this time - that's no different from an ARP attack running for a short while, then going silent for a while in the hopes of avoiding detection. You're also assuming that the client is not recording the information about who (mac & IP addr) of the node that sent the "shut down" DHCP message. Why would you assume that? It seems like that would be the obvious thing for a node to record for later analysis. On the other hand, getting a reply to an ARP probe for an address is "normal" - that's what is supposed to happen if you happen to pick an address that is in use already. There's no particular reason for a client to believe it needs to remember anything about where that came from, and without that, it can't tell that all the ARP responses seem to be coming from the same place (even assuming that the ARP attacker isn't just randomising its MAC source address). Once again, the 2563 DoS attack is the one I'd much rather carried out against me, it is the one that is much easier to detect and analyse. | 4. No automatic recovery from an RFC2563 DoS attack. | | Once you have identified an attacker that is using the | defend-all-addresses attack, you can unplug attacker from the network, | and the network immediately starts working again. That's true for any attacker. You have a hidden assumption here that a node wanting a LL address is going to continue ARP'ing (probing) for one, forever, until it eventually is received. I kind of doubt that (and would like the implementors of the current implementations, or those who know about them, to tell us if they just continue forever, or if they give up after a while). | In comparison, the | RFC2563 DoS requires you to physically manipulate every computer on the | network - you either have to power cycle them, or if they can detect | link state transitions, disconnect and reconnect each device from the | network. This is because once the client has been told to shut up, it | shuts up, so there's no automatic recovery mechanism. There's no reason that a client can't try again from time to time, after either of these failures. Explicit try again commands (from some user, perhaps using one of the methods you mention, or something else) might, be required for either of those methods. I see nothing in 2563 that says "never try again without detecting link state changes" or anything like that. In fact, anything of that nature would be very un-DHCP like - it is normal for a DHCP client to re-validate (extend) its lease from time to time, the only control DHCP has over this really is to send back timers that control the max time the address is valid (and the suggested rebind time). There's nothing in 2563 that mentions timers at all, there probably should be. One might assume that the lease validity timer of the yiaddr=0 is intended to be the validity period of the "no autoconfigure", but there's nothing in the doc that says that, nor is there anything anywhere that prevents the client validating its address sooner (as soon as it likes). I use your client Ted (the ISC client that is), and I quite often renew leases very much sooner than the reply from the server would lead me to otherwise do (for all kinds of reasons). Nothing in your message suggests to me that 2563 should be deprecated, nor that the LL doc shouldn't mandate its use in LL clients. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 25 08:37:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24053; Sat, 25 Jan 2003 08:37:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PDuQJ22413; Sat, 25 Jan 2003 08:56:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PDtLJ22391 for ; Sat, 25 Jan 2003 08:55:21 -0500 Received: from ratree.psu.ac.th (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24030 for ; Sat, 25 Jan 2003 08:35:18 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0PDceR12776; Sat, 25 Jan 2003 20:38:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0PDSF829713; Sun, 26 Jan 2003 00:29:36 +1100 (EST) From: Robert Elz To: Ted Lemon , Ralph Droms , zeroconf@merit.edu, dhcwg@ietf.org Subject: Re: [dhcwg] Re: RFC2563: Threat or Danger? In-Reply-To: <28909.1043494840@munnari.OZ.AU> References: <28909.1043494840@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Jan 2003 20:28:15 +0700 Message-ID: <29711.1043501295@munnari.OZ.AU> 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: , Date: Sat, 25 Jan 2003 18:40:40 +0700 From: Robert Elz Message-ID: <28909.1043494840@munnari.OZ.AU> | | DHCP cant' say "configure yourself an LL address." | | That's what 2653 says isn't it I meant 2563 (of course). | | - It's voluntary, so it doesn't work - if you really want this, RFC2563 | | isn't the way to get it. And I missed your meaning there at first reading - you mean that clients don't need to include the option, in which case the server won't include it in its reply (it being one of the few "only supply when asked" options). First, that's one thing I would change in the 2563 - there's no reason I see for the server not to send the option any time it feels inclined. There's no more reason this would cause a problem to a random client than if the server should decide to supply the well known impress printer option. Ignoring unknown/unwanted options is easy. Second, even ignoring that, a client that intends to "play by the rules" (assuming the rules and up as "don't configure yourself a LL address if the DHCP server says not to, even if it hasn't given you an address" will include the option in its DISCOVER (and REQUEST) packets, and so get the response (assuming the server wants to send it). Clients that have decided to take no notice, including clients implemented before the LL staandard (or I-D of what it might be eventually) suggest doing this will obviously not send the option, and if the server obeys 2563 as written now, won't get the "no LL option", and so will go ahead and configure a LL address anyway. Once again, I am not wanting to prohibit LL addresses because I think that LL addresses will magically destroy my network. I want the client to not use one (in some cases where I decide) because I know that the client will be better off with no address, than believing it has an address, which will not then work (at all). I want a way to tell the client that. If the client believes it knows better than I do (or is simply too old to know anything at all) then so be it, it won't get the information that I am trying to convey to it. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Jan 25 13:18:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26576; Sat, 25 Jan 2003 13:18:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PIcAJ02797; Sat, 25 Jan 2003 13:38:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0PIS5J01867 for ; Sat, 25 Jan 2003 13:28:05 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26458 for ; Sat, 25 Jan 2003 13:07:58 -0500 (EST) Received: from nominum.com (dsl081-073-044.sfo1.dsl.speakeasy.net [64.81.73.44]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0PI6ZP28712; Sat, 25 Jan 2003 12:06:35 -0600 (CST) Date: Sat, 25 Jan 2003 10:11:45 -0800 Subject: Re: [dhcwg] Re: RFC2563: Threat or Danger? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, zeroconf@merit.edu, Ralph Droms To: Robert Elz From: Ted Lemon In-Reply-To: <29711.1043501295@munnari.OZ.AU> Message-Id: <7668BE02-3090-11D7-B694-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > First, that's one thing I would change in the 2563 - there's no reason > I > see for the server not to send the option any time it feels inclined. > There's no more reason this would cause a problem to a random client > than > if the server should decide to supply the well known impress printer > option. > Ignoring unknown/unwanted options is easy. The server is generating a bogus DHCPOFFER. Sending this to a non-rfc2563-compliant client would have unpredictable results. q _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 26 03:23:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15181; Sun, 26 Jan 2003 03:22:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q8gZJ18505; Sun, 26 Jan 2003 03:42:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q8caJ18405 for ; Sun, 26 Jan 2003 03:38:36 -0500 Received: from ratree.psu.ac.th (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15134 for ; Sun, 26 Jan 2003 03:18:11 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0Q8ImR15807; Sun, 26 Jan 2003 15:18:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0Q8Ih805899; Sun, 26 Jan 2003 19:18:44 +1100 (EST) From: Robert Elz To: Ted Lemon cc: dhcwg@ietf.org, zeroconf@merit.edu, Ralph Droms Subject: Re: [dhcwg] Re: RFC2563: Threat or Danger? In-Reply-To: <7668BE02-3090-11D7-B694-00039317663C@nominum.com> References: <7668BE02-3090-11D7-B694-00039317663C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Jan 2003 15:18:43 +0700 Message-ID: <5897.1043569123@munnari.OZ.AU> 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: , Date: Sat, 25 Jan 2003 10:11:45 -0800 From: Ted Lemon Message-ID: <7668BE02-3090-11D7-B694-00039317663C@nominum.com> | The server is generating a bogus DHCPOFFER. Sending this to a | non-rfc2563-compliant client would have unpredictable results. If you mean, sending address 0, then yes, but that wasn't what I meant in the text you quoted. All I meant was that it would do no harm to include option 116 in a DHCPOFFER, no more than any other option the server is configured to send (that is, option 116 along with a normal IP address). But even in the case where the server sends a full 2563 response, with addr=0.0.0.0 and option 116, why would I care what the results are in the client? (Anything from crashing, to thinking it owns address 0, to ...) The only point of sending such a response is when it isn't intended to work on the net in the first place, what happens to it (especially if it has a poor dhcp client implementation with no sanity checking) shouldn't bother anyone overly much. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 26 08:40:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17553; Sun, 26 Jan 2003 08:40:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QE0NJ03573; Sun, 26 Jan 2003 09:00:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0OIjjJ19931 for ; Fri, 24 Jan 2003 13:45:45 -0500 Received: from motgate3.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27670 for ; Fri, 24 Jan 2003 13:26:08 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h0OISLFx019440 for ; Fri, 24 Jan 2003 11:28:21 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA05484 for ; Fri, 24 Jan 2003 11:29:34 -0700 (MST)] Received: from pobox.cstl.labs.mot.com (pobox.cstl.labs.mot.com [173.23.1.1]) by il06exr01.mot.com (8.11.6/il06exr01) with ESMTP id h0OITVD02474 for ; Fri, 24 Jan 2003 12:29:31 -0600 Received: from motorola.com ([173.23.166.4]) by pobox.cstl.labs.mot.com (Netscape Messaging Server 4.15) with ESMTP id H98E1800.THS for ; Fri, 24 Jan 2003 12:29:32 -0600 Message-ID: <3E31860C.3D8B145E@motorola.com> Date: Fri, 24 Jan 2003 12:29:32 -0600 From: "Aaron M. Smith" Reply-To: aaron.m.smith@motorola.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] more prefix-delegation-01 questions 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 In draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01, the second paragraph of section 5 says An IA_PD is different from an IA, in that it does not need to be associated with exactly one interface. One IA_PD can be associated with the requesting router, with a set of interfaces or with exactly one interface. A requesting router must create at least one distinct IA_PD. It may associate a distinct IA_PD with each of its downstream network interfaces and use that IA_PD to obtain a prefix for that interface from the delegating router. Then the 3rd to last paragraph in section 11.1 begins Upon the receipt of a valid Reply message, the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which it is attached, ... I think the text in 11.1 is a carryover from before the IA_PD construct was introduced. Should it be updated to reflect the IA_PD interface groupings? Perhaps something along the lines of Upon the receipt of a valid Reply message, for each IA_PD the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which the associated interfaces are attached, ... Also, section 5 has "...obtain a prefix for that interface...", while section 11.1 has "...assigns a subnet from...the...prefixes to... the links...". Does it ever make sense for the requesting router to configure an address on its interface(s) using a delegated prefix? If so, and given that RFC 2462 says routers are not allowed to auto-configure addresses from prefixes received in advertisements (even ones they send), then the address configuration would have to be done explicitly. Does the PD draft need to explain this, or is it considered obvious, or should routers not do this? Thanks, -Aaron -- Aaron M. Smith Networks and Infrastructure Research Motorola Labs aaron.m.smith@motorola.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 26 08:43:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17607; Sun, 26 Jan 2003 08:43:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QE36J03703; Sun, 26 Jan 2003 09:03:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q5ZmJ31507 for ; Sun, 26 Jan 2003 00:35:48 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03459 for ; Sun, 26 Jan 2003 00:15:26 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:9df6:dfaa:6265:5237]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0Q5IdR86427; Sun, 26 Jan 2003 14:18:39 +0900 (JST) Date: Sun, 26 Jan 2003 14:19:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] additional questions on dhcpv6-28 In-Reply-To: <4.3.2.7.2.20030123161320.00b69610@funnel.cisco.com> References: <4.3.2.7.2.20030123161320.00b69610@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 71 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 Thu, 23 Jan 2003 16:26:19 -0500, >>>>> Ralph Droms said: >> 1. What should the client do if the preferred lifetime is larger than >> the valid lifetime for an IA address option in a reply message (to >> request/renew, etc)? >> >> I think the address should be ignored, as an analogy to the rule >> (c) of RFC 2462 Section 5.5.3, but the dhcpv6 draft is silent on >> this. > I suggest adding this text to follow the first paragraph of section > 18.1.8., Receipt of Reply Messages, in draft-ietf-dhc-dhcpv6-28.txt. > The client discards any addresses found in any IAs it receives for > which the preferred lifetime is greater than the valid lifetime. > Are there other cases of invalid parameters or configuration that > should be mentioned here? Regarding the valid and preferred lifetimes, we may have to consider some or all of the following cases: - advertise message (from the server to the client) - solicit, renew, and rebind messages (from the client to the server) If we take the option "all", the simplest clarification (if any) would be to update Section 22.6. (IA Address Option), like The client and the server ignore any IA Address Options found in any IAs they receive for which the preferred lifetime is greater than the valid lifetime. BTW: we may also have to consider the same question you raised for the case of T1 > T2 > 0: which part of the message should the receiving node ignore (discard)? - the invalid IA Address Option only - the entire IA_NA or IA_TA option that contains an invalid IA Address Option - the entire message >> 2. Does DHCPv6 have a notion of "infinite" lifetimes (and T1/T2 >> values)? If we apply an analogy to RFC 2461, 0xffffffff should be >> "infinity." Does this make sense for DHCPv6 as well? I don't have >> a particular opinion, but the DHCPv6 spec should be clear on this, >> because an implementation may or may not apply the analogy to RFC >> 2461, which may cause interoperability issues. >> BTW: our current implementation applies the analogy, i.e., we treat >> 0xffffffff as infinity. > I think DHCPv6 should treat 0xffffffff as "infinity" in the case of > time values like lifetimes, T1 and T2. As you implemented > draft-ietf-dhc-dhcpv6-28.txt, did you find any places where the > inclusion of a time value for "infinity" caused a problem with > interpretation of the spec? Can we simply add a statement early > in the specification, perhaps somewhere in Section 5, "DHCP Constants", > defining 0xffffffff as infinity? You may also want to update the following part of Section 22.4: Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the addresses in the IA, respectively. so that the meaning of ".5 and .8 times" is clear when the "shortest" lifetime is infinity. Our implementation sets T1 and T2 to infinity (0xffffffff) in this case. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 26 08:46:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17665; Sun, 26 Jan 2003 08:46:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QE6FJ03795; Sun, 26 Jan 2003 09:06:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q6NQJ01265 for ; Sun, 26 Jan 2003 01:23:26 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03850 for ; Sun, 26 Jan 2003 01:03:03 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:9df6:dfaa:6265:5237]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0Q66SR86516; Sun, 26 Jan 2003 15:06:28 +0900 (JST) Date: Sun, 26 Jan 2003 15:06:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: <4.3.2.7.2.20030123151949.00b6c3f8@funnel.cisco.com> References: <4.3.2.7.2.20030123151949.00b6c3f8@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 147 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 Thu, 23 Jan 2003 16:29:55 -0500, >>>>> Ralph Droms said: > As Jinmei-san and I discussed, the Renew and Rebind cases are different. > In the case of Renew, the server from which the client obtained the IA > is identified by the Server Identifier option, so the server can > authoritatively respond with NoBinding. > The specification is ambiguous about the use of the Server > Identitifier option. Section 18.1.3, "Creation and Transmission of > Renew Messages" of draft-ietf-dhc-dhcpv6-28.txt requires that the > client include "the identifier of the destination server in a Server > Identifier option." However, section 18.2.3, "Receipt of Renew > Messages", does *not* require that a server discard any Renew messages > in which the contents of the Server Identifier option does not match > the DUID of the receiving server. I think the specification needs to > be corrected. Actually, Section 15.6 *seems to* address the case. It says: Servers MUST discard any received Renew message that meets any of the following conditions: - the message MUST include a Server Identifier option - the contents of the Server Identifier option MUST match the server's identifier ... However, there should be a wording problem. I guess the sentence actually intended to be: Servers MUST discard any received Renew message that fails to meet ^^^^^^^^ any of the following conditions: As for wording, the policy of choosing the word is not consistent throughout Section 15, which may be the source of this kind of error. There are in fact four variations: Sections 15.3 and 15.4 say XXX MUST discard any YYY message that meets any of the following conditions: (conditions of invalid cases) Section 15.16 says: XXX MUST discard any YYY message that meets any of the following conditions: (conditions of valid cases) Section 15.8, 15.9, 15.10 and 15.12 say: XXX MUST discard any YYY message that fails to meet any of the following conditions: (conditions of valid cases) Section 15.11 says: XXX MUST discard any YYY messages that fails any of the following conditions: (conditions of valid cases) Fortunately, all sections except 15.6 look correct (though there may be some grammatical errors.) > The specification may also require clarification in the case of Rebind, > when the server should respond with NoBinding only if it has > authoritative information that there is no binding for the client. > There may be another alternative, which would be to allow the client > to ignore Reply messages (ins response to a Rebind message )with > NoBinding status, if the client receives another Reply message > from a server that does find the binding. I'd like to see clarification for the Rebind case. I personally prefer the first one, because the second one would require additional parameters for the client of how long the client should wait until it receives Reply messages. >> > 2. What should a client do if it receives an IA_NA in a reply message >> > where T1 > T2 > 0? >> > a) the client must ignore the option (or the entire reply message) >> > b) the client must treat as if T1 = T2 >> > c) the client must choose appropriate alternatives for T1 and T2. >> > (this cannot be an option, though, because Section 22.4 says the >> > client MUST use T1 and T2 if they are non-0) >> > d) others >> >> > FYI: Our implementation currently takes the option a). >> BV> (a) is probably a fine action as it really is invalid. T1 <= T2. >> >> Okay. > Jinmei-san, which choice does your implementation make? Ignore the > option or the entire message? And, does it ignore the entire IA_NA > option? I worry about ignoring just the option, which might lead > to unexpected and hard-to-diagnose behavior. Ignoring the entire > message would be easier to recognize as incorrect behavior. Sorry, I was not specific enough. Our implementation ignores the erroneous IA_NA option only, and processes other part of the message just like the normal case. (More precisely, we apply the rule to the IA_PD option, not the IA_NA option, which we have not supported yet. However, we'd apply the same logic to IA_NA if we supported it.) I'm not sure what you meant by "ignore the entire IA_NA option", but our implementation does not use any information of the IA_NA option including sub-options if T1 > T2 > 0. We adopted this approach as an analogy to the case of invalid prefixes described in Section 5.5.3 of RFC 2462. The RFC specifies the host to ignore the invalid prefix, not the entire router advertisement. However, I don't stick to our choice. Since such invalid parameters may indicate a bug of the server or even an attack from a malicious node, it may also make sense to ignore the entire message. >> > 4. Section 18.1.8 says (snip) >> Okay, but it would be good if Section 18.1.8 is more clear on this, like: >> >> When the client receives a NoAddrsAvail status for an IA from the >> server in response to a Request, the client can either try another >> server (perhaps restarting the DHCP server discovery process) or >> use the Information-Request to obtain configuration parameters >> only. > Is the situation more complicated in the case when the client sends more > than one IA, and receives NoAddrsAvail status in one IA and addresses > in another IA? I think the client should make a decision about each IA > individually, (potentially) accepting each IA that has been assigned > addresses, and (potentially) retrying each IA that has status > NoAddrsAvail. So the text should be clarified, perhaps: > The client examines the status code in each IA individually. If > the status code is NoAddrsAvail, the client has received no usable > addresses in the IA and may choose to try obtaining addresses for > the IA from another server. The client uses addresses and other > information from any IAs that do not contain a Status Code option. > If the client receives no addresses in any of the IAs, it may > choose to use the Information-request message to obtain other > configuration information. I agree. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 26 08:48:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17699; Sun, 26 Jan 2003 08:48:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QE8RJ04469; Sun, 26 Jan 2003 09:08:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q6l8J02350 for ; Sun, 26 Jan 2003 01:47:08 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04099 for ; Sun, 26 Jan 2003 01:26:45 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:9df6:dfaa:6265:5237]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0Q6U9R86585; Sun, 26 Jan 2003 15:30:10 +0900 (JST) Date: Sun, 26 Jan 2003 15:30:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (EUD)" Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 44 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 24 Jan 2003 09:01:24 -0600, >>>>> "Bernie Volz (EUD)" said: > The specification is ambiguous about the use of the Server > Identitifier option. Section 18.1.3, "Creation and Transmission of > Renew Messages" of draft-ietf-dhc-dhcpv6-28.txt requires that the > client include "the identifier of the destination server in a Server > Identifier option." However, section 18.2.3, "Receipt of Renew > Messages", does *not* require that a server discard any Renew messages > in which the contents of the Server Identifier option does not match > the DUID of the receiving server. I think the specification needs to > be corrected. BV2> Yes, agreed we should fix 18.2.3. (Perhaps we should even consider BV2> whether additional rules should be added in section 15.10 on Replies BV2> to specific messages? Such as Server Identifier must match that sent BV2> in any "request".) Hmm, I personally don't see the need for additional text in 15.10, but it might be helpful if a client implementation identifies an outstanding request by the pair of "server ID + transaction ID". > The specification may also require clarification in the case of Rebind, > when the server should respond with NoBinding only if it has > authoritative information that there is no binding for the client. > There may be another alternative, which would be to allow the client > to ignore Reply messages (ins response to a Rebind message )with > NoBinding status, if the client receives another Reply message > from a server that does find the binding. BV2> What about just requiring all servers to respond but having the BV2> client only take the NoBinding from the Server Identifier it last BV2> used with that binding as being authoritative. I'm not sure how a BV2> server could know whether it has (or had) authoritative information. Ralph pointed out to me the possibility of some "magic" between a primary server and a backup server, which allows those servers to be synchronized in real time. I'm not sure how this is realistic, either, but I'd personally prefer to keep the possibility. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 26 08:50:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17774; Sun, 26 Jan 2003 08:50:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QEAYJ04573; Sun, 26 Jan 2003 09:10:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q6mrJ02378 for ; Sun, 26 Jan 2003 01:48:53 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04135 for ; Sun, 26 Jan 2003 01:28:30 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:9df6:dfaa:6265:5237]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0Q6VvR86589; Sun, 26 Jan 2003 15:31:57 +0900 (JST) Date: Sun, 26 Jan 2003 15:32:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (EUD)" Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 28 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 Thu, 23 Jan 2003 16:22:07 +0900, >>>>> JINMEI Tatuya said: >> 1. Section 18.1.8 says: >> When the client receives a NoBinding status in an IA from the server >> in response to a Renew message or a Rebind message, the client sends >> a Request to reestablish an IA with the server. >> does this imply that the client must remove the IA before sending the >> request? (I guess the answer is YES, but I'm asking this to be sure.) BV> No. As long as the address has a valid lifetime left, the client BV> should be able to use that address. NoBinding just means that the BV> server has no record of that binding (perhaps it is a new server BV> or a server that losts its stable storage). While this situation BV> is not desireable, it is possible and should work out OK. > I see. Then I have a related question. Does the client continue or > stop sending Renew or Rebind in this case? I may have been asking too many things at one time, but I did not get an answer to this. Could anyone clarify this? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 26 08:52:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17829; Sun, 26 Jan 2003 08:52:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QECgJ04639; Sun, 26 Jan 2003 09:12:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q6reJ02498 for ; Sun, 26 Jan 2003 01:53:40 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04174 for ; Sun, 26 Jan 2003 01:33:01 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:9df6:dfaa:6265:5237]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0Q6aPR86600; Sun, 26 Jan 2003 15:36:25 +0900 (JST) Date: Sun, 26 Jan 2003 15:36:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about prefix-delegation-01 In-Reply-To: <4.3.2.7.2.20030123155548.00b6c4f8@funnel.cisco.com> References: <4.3.2.7.2.20030123155548.00b6c4f8@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 33 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 Thu, 23 Jan 2003 16:28:00 -0500, >>>>> Ralph Droms said: >> 3. Section 11 of the PD draft says: >> >> In some circumstances the requesting router may need verification >> that the delegating router still has a valid binding for the >> requesting router. Examples of times when a requesting router may >> ask for such verification include: >> >> o The requesting router reboots. >> ... >> If such verification is needed the requesting router MUST initiate a >> Renew/Reply message exchange as described in the section "Creation >> and Transmission of Renew Messages" of the DHCP specification [6]. >> >> I don't see why a Renew/Reply exchange is used, instead of a >> Confirm/Reply exchange. The described situation is very similar to >> Section 18.1.2 of dhcpv6-28, and I don't see an essential difference >> to use a Renew/Reply exchange. If there is, the PD draft should be >> clear on this. > Yes, I think a Confirm message could be used in this case. Okay, so do you think the PD draft should be updated by replacing the Renew with Confirm? I personally think it should, because otherwise it would be unclear why we had Confirm in the base DHCPv6 spec in the first place. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 26 08:55:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17880; Sun, 26 Jan 2003 08:55:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QEF7J04716; Sun, 26 Jan 2003 09:15:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q7ANJ07733 for ; Sun, 26 Jan 2003 02:10:23 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04255 for ; Sun, 26 Jan 2003 01:50:00 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:9df6:dfaa:6265:5237]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0Q6rRR86615; Sun, 26 Jan 2003 15:53:27 +0900 (JST) Date: Sun, 26 Jan 2003 15:53:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jun Xie Cc: dhcwg@ietf.org Subject: Re: [dhcwg] additional questions on dhcpv6-28 In-Reply-To: <4.3.2.7.2.20030123191127.00ae0bf0@mira-sjcm-2.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <4.3.2.7.2.20030123191127.00ae0bf0@mira-sjcm-2.cisco.com> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 38 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 Thu, 23 Jan 2003 19:54:41 -0800, >>>>> Jun Xie said: >> I definitely don't think infinite renewals times are a good idea, so I >> would not >> recommend adding this for T1/T2. > Infinite T1/T2 may be helpful during network renembering. It tells the > client that the server is no longer willing to extend address/prefix > lifetimes and that the addresses/prefixes assigned before should > expire at a fixed future time. Again, I don't have a particular opinion on this, but according to the discussion so far, some people think the notion of infinity for lifetimes, T1 and T2 makes sense. If we allow infinity for T1 (and T2), however, we may have to be careful about one thing. When both valid lifetime and T1 are infinity, the assigned address will never be released, unless the client allows reconfigure or the client voluntarily releases the address. The situation is different from stateless address autoconfiguration, because the advertising router can always decrease the lifetime in later advertisements. Thus, we'll at least have to note the possibility of address assignment that never expires. We may also have to consider a stronger requirement, such as: - do not allow infinite T1 (and T2) values - do not allow servers to specify infinite T1 (and T2) unless the client accepts Reconfigure JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 26 08:57:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17926; Sun, 26 Jan 2003 08:57:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QEHWJ04764; Sun, 26 Jan 2003 09:17:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q8ulJ18787 for ; Sun, 26 Jan 2003 03:56:47 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15282 for ; Sun, 26 Jan 2003 03:36:22 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:9df6:dfaa:6265:5237]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0Q8dlR86952; Sun, 26 Jan 2003 17:39:47 +0900 (JST) Date: Sun, 26 Jan 2003 17:40:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: PD lifetimes In-Reply-To: <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com> References: <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 71 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 Thu, 23 Jan 2003 20:15:10 -0500, >>>>> Ralph Droms said: > 1. In response to your first comment, suppose we change the paragraph in > question to: > In a message sent by a delegating router the preferred and valid > lifetimes for each prefix should be set to the values > AdvValidLifetime and AdvPreferredLifetime for that prefix, as > specified in section "Router Configuration Variables" of RFC2461 > [3], unless administratively configured. > If I understand your second comment correctly, following the PD spec will > result in the valid lifetimes in the RAs on the downstream links from the > RR grow smaller over time, so as not to exceed the valid lifetime for the > prefix in the IA_PD, until the RR sends a Renew to extend the valid > lifetime on the prefix. Did I get that right? Yes. > Is this situation a problem > for the hosts on the downstream links and should we try to fix the problem? Honestly, this won't be a "problem" in practice, since AdvValidLifetime and AdvPreferredLifetime are large enough. In theory, however, the current default lifetimes specified in the PD draft changes the condition about stability of prefix lifetimes for downstream hosts. According to the default values of RFC 2461, an autoconfigured address for a host is valid unless the host misses router advertisements for AdvValidLifetime (I ignore the advertisement interval for simplicity). According to the current PD spec, however, a host can receive a prefix with the valid lifetime being L = (AdvValidLifetime - .5 * AdvPreferredLifetime). Thus, if the host misses succeeding router advertisements for L seconds, the corresponding address will be invalidated, even if the renew/reply exchange between RR and DR succeeded (and continued to succeeding). Perhaps I'm a stickler, but I'd like to ensure the same stability from the downstream hosts' point of view, as long as the renew/reply exchange succeeds at the PD side. > 2. Proposed clarification for the sentence in question: > The requesting router MUST select the value of AdvValidLifetime > assigned to any prefixes subnetted from a delegated prefix to be > less than the valid lifetime in the prefix option for that > delegated prefix. The requesting router MAY use the preferred > lifetime in the prefix option for a delegated prefix as the value > of AdvPreferredLifetime for a prefix subnetted from that delegated > prefix, if the requesting router chooses to allow the delegating > router to control that value. Otherwise, the requesting router > chooses a value of AdvPreferredLifetime for the subnetted prefix > that is less than the value of AdvValidLifetime for that prefix. (I corrected a typo in the citation above) Then are you suggesting to keep the constant value of AdvValidLifetime after receiving a Reply (to Request) and before trying a Renew/Reply exchange? If so, I don't think this is a good idea. We must ensure the invariant that the "site" valid lifetime given by PD must be equal to or larger than the valid lifetime (in router advertisements) for the prefix of each downstream link. I'll switch to Erik's message for further discussion. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Jan 26 09:00:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17995; Sun, 26 Jan 2003 09:00:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0QEKHJ04888; Sun, 26 Jan 2003 09:20:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0Q9VHJ25031 for ; Sun, 26 Jan 2003 04:31:17 -0500 Received: from shuttle.wide.toshiba.co.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15452 for ; Sun, 26 Jan 2003 04:10:51 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:9df6:dfaa:6265:5237]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h0Q9EHR86987; Sun, 26 Jan 2003 18:14:17 +0900 (JST) Date: Sun, 26 Jan 2003 18:14:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: PD lifetimes In-Reply-To: References: <4.3.2.7.2.20030123195027.039bfef8@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 59 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 Sat, 25 Jan 2003 06:46:26 +0100 (CET), >>>>> Erik Nordmark said: > Presumably the PD draft could do this as well by having a bit (or two) > indicating wheter the lifetime(s) should decrement in real time or be > constant. > Would that make sense? Yes, *if we want to allow the delegating router to have the ability to control the downstream valid and preferred lifetimes*. Actually, RFC 2894 (Router Renumbering for IPv6) has a similar notation: V A 1-bit flag indicating that the valid lifetime of the New Prefix MUST be effectively decremented in real time. P A 1-bit flag indicating that the preferred lifetime of the New Prefix MUST be effectively decremented in real time. (Section 3.2.1.2) The current PD draft implicitly assumes the (not-yet-introduced) additional flags are on, while these bits are off in the current typical cases. Before going that further, however, I still think it is overkilling for the delegating router to have the ability to control the downstream lifetimes. IMO, the requesting router (and the site's administrator) should be responsible for such parameters, with one trivial constraint: the site lifetimes must not be smaller than the lifetimes of each downstream link. In summary, I first would like to make a consensus if we need to allow the requesting router to have the ability to control the downstream lifetimes. As I said above, I'm negative on this. If our consensus is to allow the delegating router to have the ability, it's okay. Then, 1. the requesting router should also have the additional bits (like P and V above), 2. (this may be controversial) the lifetimes in router advertisement on each downstream link should be the same as the default of RFC 2461 (i.e. AdvValidLifetime and AdvPreferredLifetime, NOT decreasing in real time), as long as Renew/Reply exchanges succeed, and 3. in any case, the valid lifetime of a prefix delegated by PD must not be smaller than the valid lifetime in router advertisements on any downstream link. Note that, as a consequence of 2 and 3, the default value of the valid lifetime in a PD prefix option must be larger than AdvValidLifetime. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Jan 28 13:49:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03493; Tue, 28 Jan 2003 13:49:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJ9XJ10693; Tue, 28 Jan 2003 14:09:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0SJ2rJ09771 for ; Tue, 28 Jan 2003 14:02:53 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03360 for ; Tue, 28 Jan 2003 13:41:15 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id h0SIiFb22959; Tue, 28 Jan 2003 12:44:15 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id h0SIiEQ26264; Tue, 28 Jan 2003 12:44:14 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 28 Jan 2003 12:44:14 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'JINMEI Tatuya / ????'" Cc: dhcwg@ietf.org, "'kkinear@cisco.com'" , "Bernie Volz (EUD)" Subject: RE: [dhcwg] questions about dhcpv6-28 Date: Tue, 28 Jan 2003 12:42:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C6FD.0514AFA4" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2C6FD.0514AFA4 Content-Type: text/plain; charset="ISO-2022-JP" >Ralph pointed out to me the possibility of some "magic" between a >primary server and a backup server, which allows those servers to be >synchronized in real time. I'm not sure how this is realistic, >either, but I'd personally prefer to keep the possibility. For DHCPv6 there seems to me a better way to handle things like failover? The two standard mechanisms would be: 1. Failover like protocol between the two servers 2. Redundant backend database But, with the large IPv6 addresses, there is another way which I think is even better and requires no communication between "redundant" servers (well, there is the configuration issues but there is no need or minimal need for ongoing communication). The idea is as follows: - Use load balancing on the client identifier to determine which "new" clients a server will handle. The one issue here is if a server goes down, a portion of the client population will take a while to get addresses (to allow the Service Delay to pass). This can be resolved by specifying a rather simple means for servers to probe each other to determine whether they are alive. Another option is to abandon load balancing and instead allow all servers to respond to Solicits. Or, to alter how a server handles load balancing - it could simply adjust its server preference based on whether the client is in or out of its hash bucket (in means use 255 as the server preference, whereas out means use a lower value). - Use load balancing when generating new IPv6 addresses to restrict the addresses a server will allocate to a client. This prevents the partner server(s) from generating the same addresses and doesn't require the servers to communicate (this was always an idea Steve Gonczi was pushing when we were designing the DHCPv4 failover algorithm, but the address space wasn't large enough to really allow it to be used). In IPv6, if one "looses" the ability to generate addresses for a large fraction of the address space (such as 1/256th the space), the impact is really not noticeable (2^62 / 256 is 2^54 which still allows plenty of addresses). Note: The input to the load balancing algorithm in this case is the generated IPv6 address. If it is in the server's hash bucket, it can be used. If not, the server generates another until one is found that is in the hash bucket. - Trust clients. For a Renew, this goes to the server that originally assigned the address. For a Rebind, any server that receives it may respond and renew the address. It keeps a record of the binding in this case but it will never reassign the address to another client. This does mean that the server that failed to Renew might expire the address and reassign it to another client while the first is still using it ... to reduce the chance of this, servers should not reuse addresses for "a long while" unless a client has explicitly released the address. Hopefully, in the worst case, DAD will resolve the problem should it happen. - Another option for handling Rebinds is for the other servers to give out new addresses instead of renewing the existing ones. This allows the client to continue using its existing addresses until the lifetime expires and transition to the new addresses. Perhaps this should be configurable action - either servers are allowed to Rebind existing addresses (with the small risk of duplicate addresses) or must give new addresses (from the range they can allocate from). It is not clear to me whether respond to a Rebind with new addresses or first sending a NoBinding and requiring the client to Request is better (I like just assigning new addresses on the Rebind since that is always possible anyway and it is less traffic and work for the client, but if many servers respond, it could result in several addresses going unused since the client only accepts one of the server's responses). I wonder whether the DHC WG might take this on - to specify how redundant DHCPv6 services could or should be built? I think it will be easier than the DHCPv4 failover work and may not require any protocol - just a way of working? But, then perhaps this is simply left to the server implementers to decide how best to work and interoperability between several vendors is not required? - Bernie -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Sunday, January 26, 2003 1:31 AM To: Bernie Volz (EUD) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] questions about dhcpv6-28 >>>>> On Fri, 24 Jan 2003 09:01:24 -0600, >>>>> "Bernie Volz (EUD)" said: > The specification is ambiguous about the use of the Server > Identitifier option. Section 18.1.3, "Creation and Transmission of > Renew Messages" of draft-ietf-dhc-dhcpv6-28.txt requires that the > client include "the identifier of the destination server in a Server > Identifier option." However, section 18.2.3, "Receipt of Renew > Messages", does *not* require that a server discard any Renew messages > in which the contents of the Server Identifier option does not match > the DUID of the receiving server. I think the specification needs to > be corrected. BV2> Yes, agreed we should fix 18.2.3. (Perhaps we should even consider BV2> whether additional rules should be added in section 15.10 on Replies BV2> to specific messages? Such as Server Identifier must match that sent BV2> in any "request".) Hmm, I personally don't see the need for additional text in 15.10, but it might be helpful if a client implementation identifies an outstanding request by the pair of "server ID + transaction ID". > The specification may also require clarification in the case of Rebind, > when the server should respond with NoBinding only if it has > authoritative information that there is no binding for the client. > There may be another alternative, which would be to allow the client > to ignore Reply messages (ins response to a Rebind message )with > NoBinding status, if the client receives another Reply message > from a server that does find the binding. BV2> What about just requiring all servers to respond but having the BV2> client only take the NoBinding from the Server Identifier it last BV2> used with that binding as being authoritative. I'm not sure how a BV2> server could know whether it has (or had) authoritative information. Ralph pointed out to me the possibility of some "magic" between a primary server and a backup server, which allows those servers to be synchronized in real time. I'm not sure how this is realistic, either, but I'd personally prefer to keep the possibility. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp ------_=_NextPart_001_01C2C6FD.0514AFA4 Content-Type: text/html; charset="ISO-2022-JP" RE: [dhcwg] questions about dhcpv6-28

>Ralph pointed out to me the possibility of some "magic" between a
>primary server and a backup server, which allows those servers to be
>synchronized in real time.  I'm not sure how this is realistic,
>either, but I'd personally prefer to keep the possibility.

For DHCPv6 there seems to me a better way to handle things like failover?

The two standard mechanisms would be:
1. Failover like protocol between the two servers
2. Redundant backend database

But, with the large IPv6 addresses, there is another way which I think is even
better and requires no communication between "redundant" servers (well, there is
the configuration issues but there is no need or minimal need for ongoing
communication). The idea is as follows:

- Use load balancing on the client identifier to determine which "new" clients a
server will handle. The one issue here is if a server goes down, a portion of the
client population will take a while to get addresses (to allow the Service Delay
to pass). This can be resolved by specifying a rather simple means for servers
to probe each other to determine whether they are alive. Another option is to
abandon load balancing and instead allow all servers to respond to Solicits. Or,
to alter how a server handles load balancing - it could simply adjust its server
preference based on whether the client is in or out of its hash bucket (in means
use 255 as the server preference, whereas out means use a lower value).
- Use load balancing when generating new IPv6 addresses to restrict the addresses
a server will allocate to a client. This prevents the partner server(s) from
generating the same addresses and doesn't require the servers to communicate (this
was always an idea Steve Gonczi was pushing when we were designing the DHCPv4
failover algorithm, but the address space wasn't large enough to really allow it
to be used). In IPv6, if one "looses" the ability to generate addresses for a large
fraction of the address space (such as 1/256th the space), the impact is really
not noticeable (2^62 / 256 is 2^54 which still allows plenty of addresses).
Note: The input to the load balancing algorithm in this case is the generated
IPv6 address. If it is in the server's hash bucket, it can be used. If not, the
server generates another until one is found that is in the hash bucket.
- Trust clients. For a Renew, this goes to the server that originally assigned
the address. For a Rebind, any server that receives it may respond and renew
the address. It keeps a record of the binding in this case but it will never
reassign the address to another client. This does mean that the server that
failed to Renew might expire the address and reassign it to another client
while the first is still using it ... to reduce the chance of this, servers
should not reuse addresses for "a long while" unless a client has explicitly
released the address. Hopefully, in the worst case, DAD will resolve the problem
should it happen.
- Another option for handling Rebinds is for the other servers to give out
new addresses instead of renewing the existing ones. This allows the client
to continue using its existing addresses until the lifetime expires and
transition to the new addresses. Perhaps this should be configurable action -
either servers are allowed to Rebind existing addresses (with the small risk
of duplicate addresses) or must give new addresses (from the range they can
allocate from). It is not clear to me whether respond to a Rebind with new
addresses or first sending a NoBinding and requiring the client to Request
is better (I like just assigning new addresses on the Rebind since that is
always possible anyway and it is less traffic and work for the client, but
if many servers respond, it could result in several addresses going unused
since the client only accepts one of the server's responses).


I wonder whether the DHC WG might take this on - to specify how redundant DHCPv6
services could or should be built? I think it will be easier than the DHCPv4
failover work and may not require any protocol - just a way of working? But, then
perhaps this is simply left to the server implementers to decide how best to work
and interoperability between several vendors is not required?

- Bernie

-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp]
Sent: Sunday, January 26, 2003 1:31 AM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] questions about dhcpv6-28


>>>>> On Fri, 24 Jan 2003 09:01:24 -0600,
>>>>> "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> said:

> The specification is ambiguous about the use of the Server
> Identitifier option.  Section 18.1.3, "Creation and Transmission of
> Renew Messages" of draft-ietf-dhc-dhcpv6-28.txt requires that the
> client include "the identifier of the destination server in a Server
> Identifier option."  However, section 18.2.3, "Receipt of Renew
> Messages", does *not* require that a server discard any Renew messages
> in which the contents of the Server Identifier option does not match
> the DUID of the receiving server.  I think the specification needs to
> be corrected.

BV2> Yes, agreed we should fix 18.2.3. (Perhaps we should even consider
BV2> whether additional rules should be added in section 15.10 on Replies
BV2> to specific messages? Such as Server Identifier must match that sent
BV2> in any "request".)

Hmm, I personally don't see the need for additional text in 15.10, but
it might be helpful if a client implementation identifies an
outstanding request by the pair of "server ID + transaction ID".

> The specification may also require clarification in the case of Rebind,
> when the server should respond with NoBinding only if it has
> authoritative information that there is no binding for the client.
> There may be another alternative, which would  be to allow the client
> to ignore Reply messages (ins response to a Rebind message )with
> NoBinding status, if the client receives another Reply message
> from a server that does find the binding.

BV2> What about just requiring all servers to respond but having the
BV2> client only take the NoBinding from the Server Identifier it last
BV2> used with that binding as being authoritative. I'm not sure how a
BV2> server could know whether it has (or had) authoritative information.

Ralph pointed out to me the possibility of some "magic" between a
primary server and a backup server, which allows those servers to be
synchronized in real time.  I'm not sure how this is realistic,
either, but I'd personally prefer to keep the possibility.

                                        JINMEI, Tatuya
                                        Communication Platform Lab.
                                        Corporate R&D Center, Toshiba Corp.
                                        jinmei@isl.rdc.toshiba.co.jp

------_=_NextPart_001_01C2C6FD.0514AFA4-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 30 01:58:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10969; Thu, 30 Jan 2003 01:58:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U4b6J19326; Wed, 29 Jan 2003 23:37:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U4YuJ19165 for ; Wed, 29 Jan 2003 23:34:56 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07847 for ; Wed, 29 Jan 2003 23:12:39 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0U4H1Kp020202; Wed, 29 Jan 2003 23:17:02 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-509.cisco.com [10.82.241.253]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA06782; Wed, 29 Jan 2003 23:16:10 -0500 (EST) Message-Id: <4.3.2.7.2.20030129231545.03afba98@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Jan 2003 23:16:04 -0500 To: Ted Lemon From: Ralph Droms Subject: Re: [dhcwg] *DRAFT* agenda, dhc WG meeting at IETF 56 Cc: dhcwg@ietf.org In-Reply-To: <3CBDA7BD-3407-11D7-8D7D-00039367340A@nominum.com> References: <4.3.2.7.2.20030129155154.00b71558@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At least it's 0900 PST (instead of EST) this time... - Ralph At 09:59 PM 1/29/2003 -0600, Ted Lemon wrote: >>0900-1130 Morning Sessions >>INT dhc Dynamic Host Configuration WG > >Gah! They're trying to *kill* us! > >:') > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 30 01:59:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11008; Thu, 30 Jan 2003 01:59:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U4L9J18584; Wed, 29 Jan 2003 23:21:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U4IHJ18485 for ; Wed, 29 Jan 2003 23:18:17 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07631 for ; Wed, 29 Jan 2003 22:56:00 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0U3ruP21956; Wed, 29 Jan 2003 21:53:56 -0600 (CST) Date: Wed, 29 Jan 2003 21:59:31 -0600 Subject: Re: [dhcwg] *DRAFT* agenda, dhc WG meeting at IETF 56 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030129155154.00b71558@funnel.cisco.com> Message-Id: <3CBDA7BD-3407-11D7-8D7D-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > 0900-1130 Morning Sessions > INT dhc Dynamic Host Configuration WG Gah! They're trying to *kill* us! :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 30 01:59:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11033; Thu, 30 Jan 2003 01:59:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U3kJJ16541; Wed, 29 Jan 2003 22:46:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U3fvJ16321 for ; Wed, 29 Jan 2003 22:41:57 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06895 for ; Wed, 29 Jan 2003 22:19:41 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0U3O1c6008674 for ; Wed, 29 Jan 2003 22:24:03 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-509.cisco.com [10.82.241.253]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA04734 for ; Wed, 29 Jan 2003 22:23:10 -0500 (EST) Message-Id: <4.3.2.7.2.20030129155154.00b71558@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Jan 2003 15:53:59 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] *DRAFT* agenda, dhc WG meeting at IETF 56 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The dhc WG is *TENTATIVELY* scheduled to meet: MONDAY, March 17, 2003 0800-1930 IETF Registration - 0800-0900 Continental Breakfast 0900-1130 Morning Sessions APP apparea Applications Open Area Meeting INT dhc Dynamic Host Configuration WG SUB ccamp Common Control and Measurement Plane WG Please contact me if you have an agenda item for the WG meeting. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Jan 30 02:00:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11281; Thu, 30 Jan 2003 02:00:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U3moJ16632; Wed, 29 Jan 2003 22:48:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0U3g2J16367 for ; Wed, 29 Jan 2003 22:42:02 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06898 for ; Wed, 29 Jan 2003 22:19:46 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0U3O2bD008651 for ; Wed, 29 Jan 2003 22:24:03 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-509.cisco.com [10.82.241.253]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA04726 for ; Wed, 29 Jan 2003 22:23:06 -0500 (EST) Message-Id: <4.3.2.7.2.20030129110537.039df768@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Jan 2003 11:23:07 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] questions about dhcpv6-28 In-Reply-To: References: <4.3.2.7.2.20030123151949.00b6c3f8@funnel.cisco.com> <4.3.2.7.2.20030123151949.00b6c3f8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , (responses in line...) At 03:06 PM 1/26/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Thu, 23 Jan 2003 16:29:55 -0500, > >>>>> Ralph Droms said: > > > As Jinmei-san and I discussed, the Renew and Rebind cases are different. > > In the case of Renew, the server from which the client obtained the IA > > is identified by the Server Identifier option, so the server can > > authoritatively respond with NoBinding. > > > The specification is ambiguous about the use of the Server > > Identitifier option. Section 18.1.3, "Creation and Transmission of > > Renew Messages" of draft-ietf-dhc-dhcpv6-28.txt requires that the > > client include "the identifier of the destination server in a Server > > Identifier option." However, section 18.2.3, "Receipt of Renew > > Messages", does *not* require that a server discard any Renew messages > > in which the contents of the Server Identifier option does not match > > the DUID of the receiving server. I think the specification needs to > > be corrected. > >Actually, Section 15.6 *seems to* address the case. It says: > > Servers MUST discard any received Renew message that meets any of the > following conditions: > > - the message MUST include a Server Identifier option > > - the contents of the Server Identifier option MUST match the > server's identifier > ... > >However, there should be a wording problem. I guess the sentence >actually intended to be: > > Servers MUST discard any received Renew message that fails to meet > ^^^^^^^^ > any of the following conditions: Excellent point; thanks for catching that goof. While this check is defined in section 15.6, would it be helpful to add a reference in section 18.1.3 explaining the reason for that constraint? >As for wording, the policy of choosing the word is not consistent >throughout Section 15, which may be the source of this kind of error. > >There are in fact four variations: > >Sections 15.3 and 15.4 say > XXX MUST discard any YYY message that meets any of the following > conditions: > (conditions of invalid cases) >Section 15.16 says: > XXX MUST discard any YYY message that meets any of the following > conditions: > (conditions of valid cases) >Section 15.8, 15.9, 15.10 and 15.12 say: > XXX MUST discard any YYY message that fails to meet any of the > following conditions: > (conditions of valid cases) >Section 15.11 says: > XXX MUST discard any YYY messages that fails any of the following > conditions: > (conditions of valid cases) > >Fortunately, all sections except 15.6 look correct (though there may >be some grammatical errors.) Thanks, again, for reviewing all of section 15. > > The specification may also require clarification in the case of Rebind, > > when the server should respond with NoBinding only if it has > > authoritative information that there is no binding for the client. > > There may be another alternative, which would be to allow the client > > to ignore Reply messages (ins response to a Rebind message )with > > NoBinding status, if the client receives another Reply message > > from a server that does find the binding. > >I'd like to see clarification for the Rebind case. I personally >prefer the first one, because the second one would require additional >parameters for the client of how long the client should wait until it >receives Reply messages. I prefer the first case, as well. Any opposing opinions? > >> > 2. What should a client do if it receives an IA_NA in a reply message > >> > where T1 > T2 > 0? > >> > a) the client must ignore the option (or the entire reply message) > >> > b) the client must treat as if T1 = T2 > >> > c) the client must choose appropriate alternatives for T1 and T2. > >> > (this cannot be an option, though, because Section 22.4 says the > >> > client MUST use T1 and T2 if they are non-0) > >> > d) others > >> > >> > FYI: Our implementation currently takes the option a). > >> >BV> (a) is probably a fine action as it really is invalid. T1 <= T2. > >> > >> Okay. > > > Jinmei-san, which choice does your implementation make? Ignore the > > option or the entire message? And, does it ignore the entire IA_NA > > option? I worry about ignoring just the option, which might lead > > to unexpected and hard-to-diagnose behavior. Ignoring the entire > > message would be easier to recognize as incorrect behavior. > >Sorry, I was not specific enough. Our implementation ignores the >erroneous IA_NA option only, and processes other part of the message >just like the normal case. (More precisely, we apply the rule to the >IA_PD option, not the IA_NA option, which we have not supported yet. >However, we'd apply the same logic to IA_NA if we supported it.) OK. >I'm not sure what you meant by "ignore the entire IA_NA option", but >our implementation does not use any information of the IA_NA option >including sub-options if T1 > T2 > 0. Yes, I was asking if you use any of the information from the IA_NA option. Not using any of the information from the option sounds like the right thing to do. >We adopted this approach as an analogy to the case of invalid prefixes >described in Section 5.5.3 of RFC 2462. The RFC specifies the host to >ignore the invalid prefix, not the entire router advertisement. > >However, I don't stick to our choice. Since such invalid parameters >may indicate a bug of the server or even an attack from a malicious >node, it may also make sense to ignore the entire message. > > >> > 4. Section 18.1.8 says > >(snip) > > >> Okay, but it would be good if Section 18.1.8 is more clear on this, like: > >> > >> When the client receives a NoAddrsAvail status for an IA from the > >> server in response to a Request, the client can either try another > >> server (perhaps restarting the DHCP server discovery process) or > >> use the Information-Request to obtain configuration parameters > >> only. > > > Is the situation more complicated in the case when the client sends more > > than one IA, and receives NoAddrsAvail status in one IA and addresses > > in another IA? I think the client should make a decision about each IA > > individually, (potentially) accepting each IA that has been assigned > > addresses, and (potentially) retrying each IA that has status > > NoAddrsAvail. So the text should be clarified, perhaps: > > > The client examines the status code in each IA individually. If > > the status code is NoAddrsAvail, the client has received no usable > > addresses in the IA and may choose to try obtaining addresses for > > the IA from another server. The client uses addresses and other > > information from any IAs that do not contain a Status Code option. > > If the client receives no addresses in any of the IAs, it may > > choose to use the Information-request message to obtain other > > configuration information. > >I agree. OK.... > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg