From dhcwg-bounces@ietf.org Thu Feb 01 15:51:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCiso-0002fr-RD; Thu, 01 Feb 2007 15:50:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCisi-0002Zx-Pt; Thu, 01 Feb 2007 15:50:08 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCisc-0006qd-Ik; Thu, 01 Feb 2007 15:50:08 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 84DAB32A10; Thu, 1 Feb 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HCisc-00085R-Bx; Thu, 01 Feb 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Feb 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-relay-agent-flags-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv4 Relay Agent Flags Suboption Author(s) : K. Kinnear, et al. Filename : draft-ietf-dhc-relay-agent-flags-02.txt Pages : 8 Date : 2007-2-1 This memo defines a new suboption of the DHCP relay agent information option that allows the DHCP relay to specify flags for the forwarded packet. One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet. This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-flags-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-relay-agent-flags-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-relay-agent-flags-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-2-1113928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-relay-agent-flags-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-relay-agent-flags-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-2-1113928.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Thu Feb 01 17:25:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkLu-0004if-GO; Thu, 01 Feb 2007 17:24:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkLt-0004iX-2o for dhcwg@ietf.org; Thu, 01 Feb 2007 17:24:21 -0500 Received: from scramble.princeton.edu ([128.112.232.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCkLp-0005Yp-LU for dhcwg@ietf.org; Thu, 01 Feb 2007 17:24:21 -0500 Received: from scramble.Princeton.EDU (irwin@localhost) by scramble.Princeton.EDU (8.13.7/8.13.7) with ESMTP id l11MO7Ms021194; Thu, 1 Feb 2007 17:24:07 -0500 (EST) Message-Id: <200702012224.l11MO7Ms021194@scramble.Princeton.EDU> From: Irwin Tillman To: dhcwg@ietf.org Subject: Re: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? In-reply-to: <20070131194714.GD9514@isc.org> References: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> <20070131194714.GD9514@isc.org> Comments: In-reply-to message from "David W. Hankins" dated "Wed, 31 Jan 2007 11:47:15 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 01 Feb 2007 17:24:07 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org David W. Hankins wrote: > Irwin, I'm sorry that it seems we didn't help you to your satisfaction > earlier. We are a group of volunteers, so we often forget that we have > 'customers' with time-sensitive needs. I wasn't dissatisfied. I posted my question to dhcwg, there were replies, and that's it. (Of course, I would have been happier to get responses that agreed with what I wrote, but such is life.) I very much appreciate the time that people (volunteers, no less) have spent to consider what I wrote, and to respond. I wouldn't want you to think I'm dissatisfied with the assistance I received, or don't appreciate the time you've spent responding. > ... DHCPDISCOVER conveys no information to the server > except that the client is 'discover'ing the presence (or lack thereof) > of DHCP servers on the network that it might receive configuration > parameters from, and what those parameters might be. > > It is absolutely a server's violation of RFC2131 to infer that the > client transmitting a DISCOVER has relinquished its lease. > > The only situation I'm aware of according to RFC2131 in which a server > may reasonably understand a client's lease to be relinquished before > the expiration time has elapsed is when the client transmits a > DHCPRELEASE message (or similarly, DHCPDECLINE, but that's different). > > However, I am also aware that many servers (including ISC DHCP) have > also implemented a catch should clients transmit a DHCPREQUEST message > using the same identity as a previous, unexpired binding, but > requesting a different binding. A REQUEST really is a demand for > a given binding, and therefore the client's indication of its > acceptance and intent to use. So this practice has not turned out to > have many pitfalls. > > This is often done in order to free resources the old binding carries > but can not possibly still be used, such as domain names or lease > limitation counts. Yes, I do the same thing (discarding the old lease) in that case, although I do see this situation cause a problem when the reason is that the client is simultaneously running two DHCP client instances on a single network interface (with the same Client Identifier). The server ends up with a single lease for the client (the new lease), while the client believes it has two leases. My take is that the client's behavior is wrong (as a result of the client misconfiguration leading to two DHCP client instances running, not as a result of a problem in the DHCP client implementation). > I am not aware of any other reasonable circumstances where the client's > intent to use a binding it has been given may be inferred. > > I am also curious as to why you think it is necessary to expire a > binding when the client issues a DISCOVER, rather than at the time > they issue some other message. (There's going to be some unavoidable duplication below between this and the parallel discussion in dhcp-users@isc.org.) It's because this server implementation uses a single store for leases and offers. Offers (with all their associated parameters) are stored as leases marked for garbage collection if they aren't claimed in a short time. Since the spec only requires the server to maintain one lease per (Client Identifier, subnet), when a BOUND client sends a DHCPDISCOVER that results in a new offer, the server replaces the old lease in the store. When the client then does not SELECT that offer (e.g. it sends nothing), some time later that offer gets garbage collected. Now the store has no lease for the client. > ... > It is a mistake to think that any action indicated in the state > diagram is a "MUST". Hmm, consider the following: A client is in INIT state. It sends a DHCPDISCOVER. A server responds with a DHCPOFFER. The state diagram says that to accept the offer, the client sends a DHCPREQUEST, then the server sends a DHCPACK. If the client doesn't really have to follow the state diagram, it could receive the offer, then decide to jump to BOUND without sending a DHCPREQUEST and receiving a DHCPACK. To me, the state diagram says that if the client wants to accept the offer, it MUST send a DHCPREQUEST, then await (and receive) a DHCPACK. > > It is also a mistake to think you know what state the client is > operating in based entirely on the message it transmits or the > contents thereof (despite the fact that we do this in at least one > place in DHCPREQUEST to sense RENEW vs REBIND). > (As do I. I see no way around this, as the spec requires the server to respond differently (in some circumstances) to a DHCPREQUEST based on whether the client is in the SELECTING, INIT-REBOOT, RENEWING, or REBINDING state.) > Transmitting a DISCOVER in BOUND state does not make a client fail > to implement RFC2131. The behaviour simply is not in the reference > one way or the other. > | Once a client identified by a unique (client identifier, subnet) > | tuple sends a DHCPDISCOVER, any old lease identified by that (client > | identifier, subnet) tuple is no longer valid. The client's abandoned > | any old lease identified by that tuple. > > This is unequivocally false. > > > Now, you did point out some client bugs in your message that I hope > Apple will fix. But those bugs will only result in servers sending > DHCPNAKs, which hopefully the client processes correctly. Thank you for your detailed response. I appreciate it. Irwin Tillman / OIT Network Systems / Princeton University _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Feb 01 17:55:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkpN-0000ZO-Go; Thu, 01 Feb 2007 17:54:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkpM-0000YS-Kc for dhcwg@ietf.org; Thu, 01 Feb 2007 17:54:48 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCkpH-0003sX-VY for dhcwg@ietf.org; Thu, 01 Feb 2007 17:54:48 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2007 14:54:43 -0800 X-IronPort-AV: i="4.13,269,1167638400"; d="scan'208"; a="384898160:sNHT53069104" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l11MsheX030546; Thu, 1 Feb 2007 14:54:43 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l11Mshho026544; Thu, 1 Feb 2007 14:54:43 -0800 (PST) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 17:54:42 -0500 Received: from kkinnear-wxp.cisco.com ([161.44.65.238]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 17:54:40 -0500 Message-Id: <4.3.2.7.2.20070201173630.033f4b30@email.cisco.com> X-Sender: kkinnear@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 Feb 2007 17:55:01 -0500 To: Irwin Tillman , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? In-Reply-To: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 01 Feb 2007 22:54:41.0062 (UTC) FILETIME=[F5098460:01C74653] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5177; t=1170370483; x=1171234483; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kkinnear@cisco.com; z=From:=20Kim=20Kinnear=20 |Subject:=20Re=3A=20[dhcwg]=20RFC=202131=3A=20can=20a=20DHCPv4=20client=2 0(Mac=20OS=20X)=0A=20=20transition=20directly=20from=20BOUND=20to=20INIT=2 0then=20back=20to=20BOUND? |Sender:=20; bh=i1sHZndz2SSVtTw0PMuv5IEumJM1IWh5WL9o0W7qgOM=; b=ioPUrKZKcUcJt3F6OWTaZlVF6SJ29YIXpTWhdjAkRiHJP3IUSyceZsfSqXNTI43uh1NbPwvt +4Hpl6D4YwaoV8aBr7PNPciEUYtyjfJgflNXIc0ofIi/nfZ0VPoourrT; Authentication-Results: sj-dkim-7; header.From=kkinnear@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: kkinnear@cisco.com X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org At 09:47 AM 1/24/2007, Irwin Tillman wrote: >My reading of RFC 2131 (especially Figure 5) is that a DHCPv4 client cannot >transition directly from the INIT state to the BOUND state without passing >through the SELECTING state. > >Under some circumstances, Apple Mac OS X 10.4.x will do just that. > >That is, the client was BOUND. The client chooses in some circumstances (e.g. >following certain sleep/wake or link change events) to transition to the INIT state >(rather than INIT-REBOOT). It broadcasts one or more DHCPDISCOVERs. Under some >circumstances, after broadcasting the DHCPDISCOVER(s) the client then returns to the >BOUND state, continuing to use the IP address from the old lease. >Assuming it remains online long enough, it later tries to renew the old lease; >as far as the client is concerned, it's BOUND again. > >My reading of the client state transition diagram (RFC2131 Figure 5) is that >this isn't right. The only state in which a client may send a DHCPDISCOVER message is >INIT. A client in the INIT state can't transition to the BOUND state without >some additional steps that take it through the SELECTING state (e.g. receive >DHCPDISCOVER(s), send a DHCPREQUEST, receive a DHCPACK). > >(I realize that RFC 4039 adds another path from INIT to BOUND using the >DHCP Rapid Commit option, but that's not what's happening here.) > >I've reported this to Apple as a bug (Apple Bug Reporter Problem ID 4904550); >Apple has confirmed that the Mac OS X 10.4.x client behaves this way, but they >believe RFC 2131 permits this behavior. > >Any thoughts as to whether RFC 2131 permits this? I was out of the office last week, and so am just getting updated on this exchange. I have read the thread up to the present, but it was getting so long that I thought I'd reply to this initial message instead of to the replies to the replies ... I have several points to make: 1. I do not believe that RFC2131 permits a client to send a DHCPDISCOVER and continue to use any existing lease. I see the client state transition diagram as part of RFC 2131, and this explicitly indicates that the client is not BOUND if it is in INIT state. In addition to the diagram, I see the following text from section 4.4.5 to be significant (but not, by itself, enough proof): If the lease expires before the client receives a DHCPACK, the client moves to INIT state, MUST immediately stop any other network processing and requests network initialization parameters as if the client were uninitialized. If the client then receives a DHCPACK allocating that client its previous network address, the client SHOULD continue network processing. If the client is given a new network address, it MUST NOT continue using the previous network address and SHOULD notify the local users of the problem. The implication here is that in INIT state you must stop using any lease. Of course I see how you might assume that was only the case if the lease expired, but I think the state transition diagram indicates that is not the only way you can get to INIT state. Another approach to considering this is that a DHCP client generally puts any IP address it has leased in the ciaddr (see Table 5, RFC 2131). 2. Regarding the usage of DHCPDISCOVER and DHCPREQUEST/INIT-REBOOT to probe the existence of an existing lease. Irwin paraphrases the DNAv4 RFC (RFC4436) as follows: In section 2.2 (paragraph 1), it makes this explicit in the case where the client has an "operable routable IPv4" address (which is the case we're dealing with here). It says that the DHCP attempt is to be a broadcast DHCPREQUEST sent from the INIT-REBOOT state. Paragraph 2 says to use broadcast DHCPDISCOVER from the INIT state if the client doesn't have an operable routable IPv4 address on any network, but that's not the case here. In the situation I'm seeing, the DHCP client (Mac OS X 10.4.x) has an unexpired DHCP lease for a globally routable IPv4 address. So it's an operable routable IPv4 address. This to me seems precisely correct -- if you don't have an IP address, you use DHCPDISCOVER to get one, and if you *do* have an IP address, you use DHCPREQUEST/INIT-REBOOT to see if it is still usable. This also follows the ciaddr "rule" I mentioned above. --------------------------- Bottom line: If you send in a DHCPDISCOVER to a DHCP server, I believe that you have declared yourself in INIT state, and therefore relinquished any existing lease. Maybe Irwin and I are the only two folks who believe that, but Irwin is certainly not alone. Cheers - Kim >Irwin Tillman / OIT Network Systems / Princeton University > >_______________________________________________ >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-bounces@ietf.org Thu Feb 01 17:59:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCktn-0007Cx-Bz; Thu, 01 Feb 2007 17:59:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCktl-0007Cs-P0 for dhcwg@ietf.org; Thu, 01 Feb 2007 17:59:21 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCktk-0004nL-AX for dhcwg@ietf.org; Thu, 01 Feb 2007 17:59:21 -0500 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id A17D55685A; Thu, 1 Feb 2007 14:59:05 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=AWL: -0.681,BAYES_99: 3.67,USER_IN_WHITELIST: -30, CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -27.011 X-Spam-Level: Received: from [10.0.0.190] ([66.93.162.128]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Thu, 1 Feb 2007 14:59:03 -0800 In-Reply-To: <200702012224.l11MO7Ms021194@scramble.Princeton.EDU> References: <200701241448.l0OElsE8012219@scramble.Princeton.EDU> <20070131194714.GD9514@isc.org> <200702012224.l11MO7Ms021194@scramble.Princeton.EDU> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? Date: Thu, 1 Feb 2007 15:58:55 -0700 To: Irwin Tillman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Feb 1, 2007, at 3:24 PM, Irwin Tillman wrote: > A client is in INIT state. It sends a DHCPDISCOVER. A server > responds with a > DHCPOFFER. > > The state diagram says that to accept the offer, the client sends a > DHCPREQUEST, > then the server sends a DHCPACK. > > If the client doesn't really have to follow the state diagram, it > could > receive the offer, then decide to jump to BOUND without sending a > DHCPREQUEST > and receiving a DHCPACK. To me, the state diagram says that if the > client > wants to accept the offer, it MUST send a DHCPREQUEST, then await (and > receive) a DHCPACK. This is exactly right. And in case there is any question in anyone's mind about whether the behavior ascribed to the DHCP client in this case is in conformance with RFC2131 or RFC4436, I would say that it clearly is not. Why not? Mr. Tillman has already explained why it's not in conformance with RFC2131 - I see no need to expand on that. RFC4436 very clearly says that if you have an Operable Address, which is defined to be an address for which the client has a valid lease, then you should test that address by going into INIT-REBOOT. It does not say you should go into INIT and test it with a DHCPDISCOVER. Indeed, it says you should go into INIT if you do not have an operable address. And that's clearly not the case in the situation Mr. Tillman is describing. So while the DHCP server Mr. Tillman is using is being more restrictive in its handling of DHCPDISCOVERs than most, its behavior is not out of spec. It is the client that's out of spec, and conformance with RFC4436 doesn't change that, because it isn't conforming to RFC4436. I apologize for being so formal and precise here, but I've been seeing a lot of doubt going by about whether there's a problem here. If there's a client that's behaving in the manner Mr. Tillman describes, it is in fact out of spec, and needs to be fixed. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Feb 02 04:48:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCv0n-0000E3-FS; Fri, 02 Feb 2007 04:47:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCv0m-0000Dh-2h for dhcwg@ietf.org; Fri, 02 Feb 2007 04:47:16 -0500 Received: from zns001-0m9004.yokogawa.co.jp ([203.174.79.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCv0k-0006Ph-HV for dhcwg@ietf.org; Fri, 02 Feb 2007 04:47:16 -0500 Received: from zns001-0m9004.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l129l173014381 for ; Fri, 2 Feb 2007 18:47:01 +0900 (JST) Received: from EXCHANGE03.jp.ykgw.net (zex001-0m9003.jp.ykgw.net [10.0.11.23]) by zns001-0m9004.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id l129kvAU014349 for ; Fri, 2 Feb 2007 18:47:01 +0900 (JST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Feb 2007 18:46:56 +0900 Message-ID: <0260031F55435342859BFB2CCA6773D81B898985@EXCHANGE03.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [DHCPv6]Petty question regarding MRC in RFC3315 Thread-Index: AcdGrxOcgloKlnFqQJ6r4e6b+RkK1w== From: To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Hi all, I'd like to know your thought regarding MRC meaning. RFC3315 section 14 says, ----------- (snip) MRC Maximum retransmission count =20 (snip) MRC specifies an upper bound on the number of times a client may retransmit a message. Unless MRC is zero, the message exchange fails once the client has transmitted the message MRC times. --------- Does this mean that MRC is the number of retransmitted messages? For example, in the case of MRC is 3 and message type is Solicit, which behavior is correct? [Case 1] Client transmit 1st Solicit ----> retransmit(MRC=3D1) 2nd Solicit ----> retransmit(MRC=3D2) 3rd Solict ----> retransmit(MRC=3D3) 4th Solicit ----> no more transmit of Solicit or [Case 2] Client transmit (MRC=3D1) 1st Solicit ----> retransmit(MRC=3D2) 2nd Solicit ----> retransmit(MRC=3D3) 3rd Solict ----> no more transmit of Solicit Could you let me know which behavior is correct, please? Best regards, ....Hideshi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Feb 02 06:34:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCwfy-0008RV-8F; Fri, 02 Feb 2007 06:33:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCwfx-0008RH-BB for dhcwg@ietf.org; Fri, 02 Feb 2007 06:33:53 -0500 Received: from simmts5-qfe0.srvr.bell.ca ([206.47.199.163] helo=simmts5-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCwfw-0005Bz-2F for dhcwg@ietf.org; Fri, 02 Feb 2007 06:33:53 -0500 Received: from winxpmce ([142.167.236.211]) by simmts5-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20070202113351.IKQS4412.simmts5-srv.bellnexxia.net@winxpmce> for ; Fri, 2 Feb 2007 06:33:51 -0500 Message-ID: <000a01c746be$01798460$0b02a8c0@winxpmce> From: "Joseph" To: Date: Fri, 2 Feb 2007 07:33:48 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.6 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [dhcwg] (no subject) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1800864034==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1800864034== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7469C.7A3366E0" This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7469C.7A3366E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable please remove my name from your mailing list ------=_NextPart_000_0007_01C7469C.7A3366E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
please remove my name from your mailing = list=20
------=_NextPart_000_0007_01C7469C.7A3366E0-- --===============1800864034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1800864034==-- From dhcwg-bounces@ietf.org Fri Feb 02 11:33:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1Jl-0002ck-6F; Fri, 02 Feb 2007 11:31:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1Ji-0002cW-Lw for dhcwg@ietf.org; Fri, 02 Feb 2007 11:31:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD1Jh-0003Rl-7p for dhcwg@ietf.org; Fri, 02 Feb 2007 11:31:14 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 02 Feb 2007 08:31:12 -0800 X-IronPort-AV: i="4.13,273,1167638400"; d="scan'208"; a="385174915:sNHT70681984" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l12GV9ie023999; Fri, 2 Feb 2007 08:31:09 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l12GUunX018923; Fri, 2 Feb 2007 08:31:10 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 11:31:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 Date: Fri, 2 Feb 2007 11:30:59 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21032ABC00@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <0260031F55435342859BFB2CCA6773D81B898985@EXCHANGE03.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 Thread-Index: AcdGrxOcgloKlnFqQJ6r4e6b+RkK1wANjqTw From: "Bernie Volz \(volz\)" To: , X-OriginalArrivalTime: 02 Feb 2007 16:31:00.0776 (UTC) FILETIME=[864A6280:01C746E7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2345; t=1170433869; x=1171297869; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20[DHCPv6]Petty=20question=20regarding=20MRC= 20in=20RFC3315 |Sender:=20; bh=LKQHyrwrygotjK39BWXG/BME4wXom04FmTRG73rbJPE=; b=qxWSTaG4UeDTpOAHavJe1eIobI4IYEuSYCuxavLYhX3uOjjr0xdnwq6wy7IWBUCxitYZIzSm EFJbJ/cuXvq6x0pvayMyn4FSLdxijeYImaaCPOJ7gKgejWaspHYwmXHR; Authentication-Results: sj-dkim-7; header.From=volz@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org You do point out an inconsistency as several of the parameters that are used to "set" MRC say retry attempts whereas others say attempts, such as REL_MAX_RC. And, if this was just the retries, there would be no way to configure no retries (since a MRC if 0 means "unlimited"). This is useful to resolve for a RFC 3315-bis. I guess I'd "vote" to make all of these "attempts" as that would allow 1 to mean send it only once (though that likely is of marginal value). Thus, if the value is configured to be 3, it means send the packet 3 times (2 retries). In general I doubt that this will make a significant difference and I'm not sure I'd build the Tahi tests or DHCPv6 ready logo program to provide explicit tests for this -- and as many of these COULD be configurable in various implementations, it may be possible to adjust the settings to mean either interpretation (except of course the no retries setting). - Bernie=20 -----Original Message----- From: Hideshi.Enokihara@jp.yokogawa.com [mailto:Hideshi.Enokihara@jp.yokogawa.com]=20 Sent: Friday, February 02, 2007 4:47 AM To: dhcwg@ietf.org Subject: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 Hi all, I'd like to know your thought regarding MRC meaning. RFC3315 section 14 says, ----------- (snip) MRC Maximum retransmission count =20 (snip) MRC specifies an upper bound on the number of times a client may retransmit a message. Unless MRC is zero, the message exchange fails once the client has transmitted the message MRC times. --------- Does this mean that MRC is the number of retransmitted messages? For example, in the case of MRC is 3 and message type is Solicit, which behavior is correct? [Case 1] Client transmit 1st Solicit ----> retransmit(MRC=3D1) 2nd Solicit ----> retransmit(MRC=3D2) 3rd Solict ----> retransmit(MRC=3D3) 4th Solicit ----> no more transmit of Solicit or [Case 2] Client transmit (MRC=3D1) 1st Solicit ----> retransmit(MRC=3D2) 2nd Solicit ----> retransmit(MRC=3D3) 3rd Solict ----> no more transmit of Solicit Could you let me know which behavior is correct, please? Best regards, ....Hideshi _______________________________________________ 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-bounces@ietf.org Fri Feb 02 12:02:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1mp-0000FI-4z; Fri, 02 Feb 2007 12:01:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD1mo-0000FC-Fp for dhcwg@ietf.org; Fri, 02 Feb 2007 12:01:18 -0500 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD1mo-0008F7-57 for dhcwg@ietf.org; Fri, 02 Feb 2007 12:01:18 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id C53C27D2D; Fri, 2 Feb 2007 09:00:58 -0800 (PST) Date: Fri, 2 Feb 2007 09:00:58 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 Message-ID: <20070202170058.GB27196@isc.org> References: <0260031F55435342859BFB2CCA6773D81B898985@EXCHANGE03.jp.ykgw.net> Mime-Version: 1.0 In-Reply-To: <0260031F55435342859BFB2CCA6773D81B898985@EXCHANGE03.jp.ykgw.net> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0159888573==" Errors-To: dhcwg-bounces@ietf.org --===============0159888573== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 02, 2007 at 06:46:56PM +0900, Hideshi.Enokihara@jp.yokogawa.com wrote: > Does this mean that MRC is the number of retransmitted messages? > For example, in the case of MRC is 3 and message type is Solicit, > which behavior is correct? > [Case 1] > Client > transmit 1st Solicit ----> > retransmit(MRC=1) 2nd Solicit ----> > retransmit(MRC=2) 3rd Solict ----> > retransmit(MRC=3) 4th Solicit ----> > no more transmit of Solicit I don't know the answer, but this is the case I selected for our client. It seemed to me that rfc3315 was talking about retries and not transmissions (taking at least one transmission for granted). I agree with Bernie that case 2 would be more flexible for future protocol development, even if we can't imagine a use for it. It would also be clearer. Since modern implementors are prone to use the same function for the transmission as the retransmission, it's of less use these days to differentiate between the two types of transmission. In hindsight, I think 3315 could have used an all-ones value for 'infinite retries' in the same way all ones values are used for infinite lease times. Thus we'd get MRD=0 for no retries. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFw25KcXeLeWu2vmoRAue2AJ9Ne75rmivN5BxMfTlUcio6uxv3JQCgtf2G PybOQiGVhrNU3ahlcR7KiY4= =ay+M -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- --===============0159888573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0159888573==-- From dhcwg-bounces@ietf.org Fri Feb 02 12:50:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2Wa-000313-Me; Fri, 02 Feb 2007 12:48:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2WZ-00030w-Iu for dhcwg@ietf.org; Fri, 02 Feb 2007 12:48:35 -0500 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD2WY-0007mH-NL for dhcwg@ietf.org; Fri, 02 Feb 2007 12:48:35 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id AC9127D2D; Fri, 2 Feb 2007 09:48:23 -0800 (PST) Date: Fri, 2 Feb 2007 09:48:23 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 Message-ID: <20070202174823.GC27196@isc.org> References: <0260031F55435342859BFB2CCA6773D81B898985@EXCHANGE03.jp.ykgw.net> <8E296595B6471A4689555D5D725EBB21032ABC00@xmb-rtp-20a.amer.cisco.com> Mime-Version: 1.0 In-Reply-To: <8E296595B6471A4689555D5D725EBB21032ABC00@xmb-rtp-20a.amer.cisco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1646960583==" Errors-To: dhcwg-bounces@ietf.org --===============1646960583== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/WwmFnJnmDyWGHa4" Content-Disposition: inline --/WwmFnJnmDyWGHa4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 02, 2007 at 11:30:59AM -0500, Bernie Volz (volz) wrote: > This is useful to resolve for a RFC 3315-bis. While we're on the subject of retransmission state, I have two more petty things, one of which can probably be ignored. The 3315 text says the random factor should be beteen -0.1 and 0.1, which suggests non-inclusive. I'm not sure that was the intent of the authors nor the WG. A simple ", inclusive" suffix to the existing text would make it clearest. Because of the 'between x and y' wording (vs for example "from x to y"), our implementation has chosen to interpret this as 'non-inclusive', which only aggravates my second petty issue. Next, our DHCP software architecture can only schedule events on a second-granular scale. This is a limitation we already despise for a number of reasons...it's something we want to get away from, but the reality is that this is going to be future work. 1 * 0.1 is always going to be zero if you can only schedule second-granular integer times. So for example our Solicit behaviour is always 2, 4, 8, then at what would be 16, it starts to get random. The reason we start at 2 on Solicit is a different section of 3315 that first requires a RAND value strictly greater than zero be selected for the first interval, and a second requirement that the result be greater than IRT. Where IRT=1, and the highest random time difference we can select is zero (0.1 * 1 = 0), the only way to select an RT that is greater than IRT is to add 1. That's where we wound up anyway. I'm not sure what should be done here if anything. It just doesn't sit right. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --/WwmFnJnmDyWGHa4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFw3lncXeLeWu2vmoRAs9ZAJ91XdkcUEmsGBafFtXXZ4uUKMLRlQCfYcmY FXZwPu8u8jtkHc5UXERBnHg= =nRbZ -----END PGP SIGNATURE----- --/WwmFnJnmDyWGHa4-- --===============1646960583== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1646960583==-- From dhcwg-bounces@ietf.org Fri Feb 02 13:07:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2o2-0005DT-Rf; Fri, 02 Feb 2007 13:06:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2o1-0005Bw-98 for dhcwg@ietf.org; Fri, 02 Feb 2007 13:06:37 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD2mk-0002Aa-A3 for dhcwg@ietf.org; Fri, 02 Feb 2007 13:05:22 -0500 Received: from mail.nominum.com (mail.nominum.com [81.200.64.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 8DAA656835; Fri, 2 Feb 2007 10:05:07 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) X-Spam-Status: No, hits=0.0 required=8.4 tests=AWL: -0.667,BAYES_99: 3.67,USER_IN_WHITELIST: -30, CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -26.997 X-Spam-Level: Received: from [66.93.162.135] ([66.93.162.135]) (authenticated user mellon@nominum.com) by mail.nominum.com (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 2 Feb 2007 10:05:06 -0800 In-Reply-To: <20070202174823.GC27196@isc.org> References: <0260031F55435342859BFB2CCA6773D81B898985@EXCHANGE03.jp.ykgw.net> <8E296595B6471A4689555D5D725EBB21032ABC00@xmb-rtp-20a.amer.cisco.com> <20070202174823.GC27196@isc.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58631E86-576D-437C-9529-7B2C50E93053@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 Date: Fri, 2 Feb 2007 11:04:58 -0700 To: David W. Hankins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Feb 2, 2007, at 10:48 AM, David W. Hankins wrote: > I'm not sure what should be done here if anything. It just > doesn't sit right. What you need to do is fix the scheduler. Until you fix it, you aren't conformant. This isn't the end of the world, though - I think it's fine to leave it for future work, as long as you're going to do it. And since the draft doesn't specify the precision, "between 0.1 and -0.1" even if you treat it as exclusive amounts to being inclusive, since you're perfectly justified in saying that the resolution is fifteen decimal places. I think the reason we didn't specify this is that it's just not important. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Feb 02 13:15:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2vs-0003Sk-NV; Fri, 02 Feb 2007 13:14:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD2vr-0003Os-Ao for dhcwg@ietf.org; Fri, 02 Feb 2007 13:14:43 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD2vp-0004Gy-1G for dhcwg@ietf.org; Fri, 02 Feb 2007 13:14:43 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2007 10:14:41 -0800 X-IronPort-AV: i="4.13,273,1167638400"; d="scan'208"; a="52158771:sNHT58459916" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l12IEe4G014260; Fri, 2 Feb 2007 13:14:40 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l12IEeVT029098; Fri, 2 Feb 2007 13:14:40 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 13:14:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 Date: Fri, 2 Feb 2007 13:14:38 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21032ABCC7@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <20070202174823.GC27196@isc.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 Thread-Index: AcdG8w4fZHKR9rzbQB+i668V4YAz5gAAk0Vg From: "Bernie Volz \(volz\)" To: "David W. Hankins" , X-OriginalArrivalTime: 02 Feb 2007 18:14:39.0445 (UTC) FILETIME=[00E7F850:01C746F6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2824; t=1170440080; x=1171304080; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20[DHCPv6]Petty=20question=20regarding=20MRC= 20in=20RFC3315 |Sender:=20 |To:=20=22David=20W.=20Hankins=22=20, =20; bh=2C/B9OpoVSY1O560Ijjs+w0TKDOb/C6CP+4qeFiL7A4=; b=DEYulLGFhgfUxlKDSHdXIm22LwIcxjN2fQ+PV9KmNRLgQGmEOiQJip+5BlW7/H0LGAw8+KfG eSGtMnyE3v+iLzjiE4+UAu4aPonwg9cBM670CaspN3YAvcTPt0GBdubB; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Personally, I don't think some of these issues are that important. I think the basic goals were: - Use randomized values so that if there are lots of the same clients, they won't all hammer on the network and servers at the same time. Whether you err a bit in the actual value is no big deal. (Note the "bit"!) - Retransmit with appropriate delays between attemtps and use a backoff algorithm. However, if you're supposed to randomize between -0.1 and 0.1 (whether inclusive or exclusive), I do think you'll have a problem if you only have timers with 1 second resolution. Since I presume that means you might wait 0 or 1 seconds, which basically only spreads the clients out into two "lots" if they are all the same implementation. - Bernie=20 -----Original Message----- From: David W. Hankins [mailto:David_Hankins@isc.org]=20 Sent: Friday, February 02, 2007 12:48 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 On Fri, Feb 02, 2007 at 11:30:59AM -0500, Bernie Volz (volz) wrote: > This is useful to resolve for a RFC 3315-bis. While we're on the subject of retransmission state, I have two more petty things, one of which can probably be ignored. The 3315 text says the random factor should be beteen -0.1 and 0.1, which suggests non-inclusive. I'm not sure that was the intent of the authors nor the WG. A simple ", inclusive" suffix to the existing text would make it clearest. Because of the 'between x and y' wording (vs for example "from x to y"), our implementation has chosen to interpret this as 'non-inclusive', which only aggravates my second petty issue. Next, our DHCP software architecture can only schedule events on a second-granular scale. This is a limitation we already despise for a number of reasons...it's something we want to get away from, but the reality is that this is going to be future work. 1 * 0.1 is always going to be zero if you can only schedule second-granular integer times. So for example our Solicit behaviour is always 2, 4, 8, then at what would be 16, it starts to get random. The reason we start at 2 on Solicit is a different section of 3315 that first requires a RAND value strictly greater than zero be selected for the first interval, and a second requirement that the result be greater than IRT. Where IRT=3D1, and the highest random time difference we can select is zero (0.1 * 1 =3D 0), the only way to select an RT that is greater than IRT is to add 1. That's where we wound up anyway. I'm not sure what should be done here if anything. It just doesn't sit right. --=20 David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Feb 02 14:04:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD3fr-0005vE-Ql; Fri, 02 Feb 2007 14:02:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD3fq-0005q6-60 for dhcwg@ietf.org; Fri, 02 Feb 2007 14:02:14 -0500 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HD3fp-0002xC-ST for dhcwg@ietf.org; Fri, 02 Feb 2007 14:02:14 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id CCE127D2D; Fri, 2 Feb 2007 11:01:44 -0800 (PST) Date: Fri, 2 Feb 2007 11:01:44 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 Message-ID: <20070202190144.GG27196@isc.org> References: <0260031F55435342859BFB2CCA6773D81B898985@EXCHANGE03.jp.ykgw.net> <8E296595B6471A4689555D5D725EBB21032ABC00@xmb-rtp-20a.amer.cisco.com> <20070202174823.GC27196@isc.org> <58631E86-576D-437C-9529-7B2C50E93053@nominum.com> Mime-Version: 1.0 In-Reply-To: <58631E86-576D-437C-9529-7B2C50E93053@nominum.com> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0073436405==" Errors-To: dhcwg-bounces@ietf.org --===============0073436405== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lkTb+7nhmha7W+c3" Content-Disposition: inline --lkTb+7nhmha7W+c3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 02, 2007 at 11:04:58AM -0700, Ted Lemon wrote: > On Feb 2, 2007, at 10:48 AM, David W. Hankins wrote: > >I'm not sure what should be done here if anything. It just > >doesn't sit right. > > What you need to do is fix the scheduler. I can only rewrite your code so fast. :( > Until you fix it, you > aren't conformant. On a matter of principle and reasonable-ness, I agree. On a matter of strict interpretation of the document, I do not. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --lkTb+7nhmha7W+c3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFw4qYcXeLeWu2vmoRArhrAJ4l8+ri6p47mli9GQJMBlp2hPquxQCgliWu TucoC6CW/tzUgAsgobu1G60= =UZn0 -----END PGP SIGNATURE----- --lkTb+7nhmha7W+c3-- --===============0073436405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0073436405==-- From dhcwg-bounces@ietf.org Fri Feb 02 21:43:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDAru-0002Ev-Al; Fri, 02 Feb 2007 21:43:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDArt-0002Eq-Bx for dhcwg@ietf.org; Fri, 02 Feb 2007 21:43:09 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDArs-0001cY-3L for dhcwg@ietf.org; Fri, 02 Feb 2007 21:43:09 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2007 18:43:08 -0800 X-IronPort-AV: i="4.13,274,1167638400"; d="scan'208"; a="52187356:sNHT46687648" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l132h7Kg026199 for ; Fri, 2 Feb 2007 21:43:07 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l132h7OA007752 for ; Fri, 2 Feb 2007 21:43:07 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 21:43:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Feb 2007 21:43:05 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB21032ABEB5@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DHCPv6 - Experimental Message (& Option) Codes? Thread-Index: AcdHPQfsrb513R1vSy6QmXlRVjnS1Q== From: "Bernie Volz \(volz\)" To: X-OriginalArrivalTime: 03 Feb 2007 02:43:08.0287 (UTC) FILETIME=[0997D0F0:01C7473D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1780; t=1170470587; x=1171334587; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20DHCPv6=20-=20Experimental=20Message=20(&=20Option)=20Codes? |Sender:=20 |To:=20; bh=PlSM5JUom7GGELPkrtLo732/+6t/39Jw2sYorseR3g0=; b=DsbKTUfa1gg1V3nSuKeGF82KmRrw7tdU+KXTwEkdyQigXERKOjpdn3T5RlXLjYD3xreLSAn7 8GCBmNze+3NpS/cQDGMo8XH3gE0xMCpseSfdYAP80/57Njxg2s3o0eQX; Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Before I write up the draft (individual submission), what do folks think about having IANA allocate a number of DHCPv6 message codes for experimental use. Each of these messages would be encoded as <1-octet msg-type><4-octet enterprise-id>. This would allow the same message codes to be used by multiple enterprises (and within an enterprise) without collisions. While technically 1 message code would do (and I'd be happy with that), it might be best to allocate 16 codes? These should be relayed by relay agents. --- A second proposal (part of the same draft) is to also have IANA reserve a number of option codes for experimental use. These could *ONLY* be used within the experimental messages codes mentioned above (never in "normal" DHCPv6 messages). The reason for this is that it would allow the experimental messages to contain both "normal" DHCPv6 options and these experimental options. This would avoid the need for these messages to encode private option codes in Vendor-Specific messages or use other techniques to separate the "official" option space from the private space. With 65,535 option codes available, I can't see that allocating say 1,024 for this purpose would cause much hardship for us down the road. Perhaps 1,024 is way to much and 256 would do. Again, these experimental option codes MUST NOT appear in the "normal" DHCPv6 messages - they may only be used in the experimental messages -- but the important point is that they would never conflict with IANA assigned numbers. So, let me know if you would be strongly opposed to these ideas or whether you might support them (subject to the I-D being acceptable ...). Don't ask for me to give you a use at this time. - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Feb 03 17:58:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDTog-0003kV-5I; Sat, 03 Feb 2007 17:57:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDTof-0003jh-9n for dhcwg@ietf.org; Sat, 03 Feb 2007 17:57:05 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDToe-0006L4-1q for dhcwg@ietf.org; Sat, 03 Feb 2007 17:57:05 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Feb 2007 14:57:04 -0800 X-IronPort-AV: i="4.13,277,1167638400"; d="scan'208"; a="52216051:sNHT44430424" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l13Mv315031245; Sat, 3 Feb 2007 17:57:03 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l13Mv3OA023859; Sat, 3 Feb 2007 17:57:03 -0500 (EST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Feb 2007 17:57:07 -0500 Received: from 10.82.241.58 ([10.82.241.58]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Sat, 3 Feb 2007 22:57:02 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sat, 03 Feb 2007 08:59:31 -0500 Subject: Re: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 From: Ralph Droms To: "David W. Hankins" , Message-ID: Thread-Topic: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 Thread-Index: AcdHm4bGxWv1SLOOEduCyQARJOT6eg== In-Reply-To: <20070202190144.GG27196@isc.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Feb 2007 22:57:08.0001 (UTC) FILETIME=[A1722110:01C747E6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=700; t=1170543423; x=1171407423; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20Re=3A=20[dhcwg]=20[DHCPv6]Petty=20question=20regarding=20MRC= 20in=20RFC3315 |Sender:=20 |To:=20=22David=20W.=20Hankins=22=20, =20; bh=teMB4HgAVjuZTlnTgj9d17sDv65iyH1HnyrqS60fluk=; b=B6v09DJKLr3AZlfWTEZo35leHY4+4n75dHn1D5/OWghcLYlrcaAzrYpnnBxyGwu9esepEvku /pUduK0VdOWNhOdnmZYVaTrDQq+nH77r+9bnVyDeIQcC8sWndNE4Z8Wz; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Unless this seems like something that needs to be resolved quickly, I'll throw this thread in the "RFC3315bis" bin. - Ralph On 2/2/07 2:01 PM, "David W. Hankins" wrote: > On Fri, Feb 02, 2007 at 11:04:58AM -0700, Ted Lemon wrote: >> On Feb 2, 2007, at 10:48 AM, David W. Hankins wrote: >>> I'm not sure what should be done here if anything. It just >>> doesn't sit right. >> >> What you need to do is fix the scheduler. > > I can only rewrite your code so fast. :( > >> Until you fix it, you >> aren't conformant. > > On a matter of principle and reasonable-ness, I agree. > > On a matter of strict interpretation of the document, I do not. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Feb 03 18:38:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDUST-0002Q8-Ga; Sat, 03 Feb 2007 18:38:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDUSS-0002Q3-CK for dhcwg@ietf.org; Sat, 03 Feb 2007 18:38:12 -0500 Received: from mx.isc.org ([2001:4f8:0:2::1c]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDUSQ-0004Gv-RD for dhcwg@ietf.org; Sat, 03 Feb 2007 18:38:12 -0500 Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTP id C7983114025 for ; Sat, 3 Feb 2007 23:37:59 +0000 (UTC) (envelope-from David_Hankins@isc.org) Received: by farside.isc.org (Postfix, from userid 10200) id AA2E9E60C8; Sat, 3 Feb 2007 23:37:59 +0000 (UTC) Date: Sat, 3 Feb 2007 23:37:59 +0000 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] [DHCPv6]Petty question regarding MRC in RFC3315 Message-ID: <20070203233759.GB81174@isc.org> References: <20070202190144.GG27196@isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: -2.8 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Sat, Feb 03, 2007 at 08:59:31AM -0500, Ralph Droms wrote: > Unless this seems like something that needs to be resolved quickly, I'll > throw this thread in the "RFC3315bis" bin. I'm not sure it needs to be solved at all, much less soon. It would be a fine thing for rfc3315bis, so long as we don't take WG bandwidth away from more important issues. Inclusive vs non-inclusive is a trivial thing. Minimum clock resolution is something that has a better tendency to reach logheads. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Feb 05 12:10:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Ln-0005jo-Jz; Mon, 05 Feb 2007 12:09:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Lm-0005jc-6n for dhcwg@ietf.org; Mon, 05 Feb 2007 12:09:54 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7Li-000304-Rf for dhcwg@ietf.org; Mon, 05 Feb 2007 12:09:54 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l15H9ooV025637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 09:09:50 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l15H9nbC014441; Mon, 5 Feb 2007 09:09:49 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l15H9emp014018; Mon, 5 Feb 2007 09:09:45 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 09:09:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Date: Mon, 5 Feb 2007 09:09:42 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177465D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Thread-Index: AcdBYclnCBSMGK1VEdunlQARJOT6egH5p6Ww References: From: "Templin, Fred L" To: "Ralph Droms" , "dhcwg" X-OriginalArrivalTime: 05 Feb 2007 17:09:43.0684 (UTC) FILETIME=[6E174440:01C74948] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I said yes to this one on 1/15/07, and I am still saying yes now. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Friday, January 26, 2007 7:51 AM > To: dhcwg > Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery >=20 > This message announces a WG last call on "DHCPv6 Leasequery" > . The last call will > conclude at 1700EST, Mon, 2007-02-05. >=20 > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Lack of discussion does not > represent positive support. If there is no expression of support for > acceptance during the WG last call, the document will not be advanced > to the IESG. >=20 > draft-ietf-dhc-dhcvp6-leasequery specifies leasequery for the Dynamic > Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a > means to obtain lease information about DHCPv6 clients from a DHCPv6 > server. draft-ietf-dhc-dhcvp6-leasequery specifies the scope of data > that can be retrieved as well as both DHCPv6 leasequery requestor and > server behavior. draft-ietf-dhc-dhcvFrom dhcwg-bounces@ietf.org Mon Feb 05 12:10:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Ln-0005jo-Jz; Mon, 05 Feb 2007 12:09:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7Lm-0005jc-6n for dhcwg@ietf.org; Mon, 05 Feb 2007 12:09:54 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7Li-000304-Rf for dhcwg@ietf.org; Mon, 05 Feb 2007 12:09:54 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l15H9ooV025637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 09:09:50 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l15H9nbC014441; Mon, 5 Feb 2007 09:09:49 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l15H9emp014018; Mon, 5 Feb 2007 09:09:45 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 09:09:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Date: Mon, 5 Feb 2007 09:09:42 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177465D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery Thread-Index: AcdBYclnCBSMGK1VEdunlQARJOT6egH5p6Ww References: From: "Templin, Fred L" To: "Ralph Droms" , "dhcwg" X-OriginalArrivalTime: 05 Feb 2007 17:09:43.0684 (UTC) FILETIME=[6E174440:01C74948] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I said yes to this one on 1/15/07, and I am still saying yes now. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Friday, January 26, 2007 7:51 AM > To: dhcwg > Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcvp6-leasequery >=20 > This message announces a WG last call on "DHCPv6 Leasequery" > . The last call will > conclude at 1700EST, Mon, 2007-02-05. >=20 > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Lack of discussion does not > represent positive support. If there is no expression of support for > acceptance during the WG last call, the document will not be advanced > to the IESG. >=20 > draft-ietf-dhc-dhcvp6-leasequery specifies leasequery for the Dynamic > Host Configuration Protocol for IPv6 (DHCPv6) which can be used as a > means to obtain lease information about DHCPv6 clients from a DHCPv6 > server. draft-ietf-dhc-dhcvp6-leasequery specifies the scope of data > that can be retrieved as well as both DHCPv6 leasequery requestor and > server behavior. draft-ietf-dhc-dhcvp6-leasequery extends DHCPv6. > This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leas > equery-01.txt >=20 > - Stig Venaas, Ralph Droms > dhc WG chairs >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Feb 05 12:10:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7LW-0005hi-1A; Mon, 05 Feb 2007 12:09:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7LT-0005hP-UA for dhcwg@ietf.org; Mon, 05 Feb 2007 12:09:36 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7LP-0002y4-KA for dhcwg@ietf.org; Mon, 05 Feb 2007 12:09:35 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l15H9UsK006260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 11:09:30 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l15H9Ud5001700; Mon, 5 Feb 2007 11:09:30 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l15H9Rr6001561; Mon, 5 Feb 2007 11:09:30 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 09:09:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Date: Mon, 5 Feb 2007 09:09:29 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177465C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Thread-Index: AcdBYLAS7pi8OK1TEdunlQARJOT6egH55UUg References: From: "Templin, Fred L" To: "Ralph Droms" , "dhcwg" X-OriginalArrivalTime: 05 Feb 2007 17:09:29.0903 (UTC) FILETIME=[65E073F0:01C74948] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I said yes to this one on 1/15/07, and I am still saying yes now. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Friday, January 26, 2007 7:43 AM > To: dhcwg > Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero >=20 > This message announces a WG last call on "DHCPv6 Relay Agent Echo > Request Option" . The last call > will conclude at 1700EST, Mon, 2007-02-05. >=20 > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Lack of discussion does not > represent positive support. If there is no expression of support for > acceptance during the WGp6-leasequery extends DHCPv6. > This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leas > equery-01.txt >=20 > - Stig Venaas, Ralph Droms > dhc WG chairs >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Feb 05 12:10:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7LW-0005hi-1A; Mon, 05 Feb 2007 12:09:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7LT-0005hP-UA for dhcwg@ietf.org; Mon, 05 Feb 2007 12:09:36 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7LP-0002y4-KA for dhcwg@ietf.org; Mon, 05 Feb 2007 12:09:35 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l15H9UsK006260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 11:09:30 -0600 (CST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l15H9Ud5001700; Mon, 5 Feb 2007 11:09:30 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l15H9Rr6001561; Mon, 5 Feb 2007 11:09:30 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Feb 2007 09:09:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Date: Mon, 5 Feb 2007 09:09:29 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177465C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero Thread-Index: AcdBYLAS7pi8OK1TEdunlQARJOT6egH55UUg References: From: "Templin, Fred L" To: "Ralph Droms" , "dhcwg" X-OriginalArrivalTime: 05 Feb 2007 17:09:29.0903 (UTC) FILETIME=[65E073F0:01C74948] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I said yes to this one on 1/15/07, and I am still saying yes now. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com]=20 > Sent: Friday, January 26, 2007 7:43 AM > To: dhcwg > Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-dhcpv6-ero >=20 > This message announces a WG last call on "DHCPv6 Relay Agent Echo > Request Option" . The last call > will conclude at 1700EST, Mon, 2007-02-05. >=20 > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Lack of discussion does not > represent positive support. If there is no expression of support for > acceptance during the WG last call, the document will not be advanced > to the IESG. >=20 > draft-ietf-dhc-dhcpv6-ero-00.txt defines a Relay Agent Echo Request > option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). > The option allows a DHCPv6 relay agent to request a list of relay > agent options that the server echoes back to the relay agent.. This > draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ero-00.txt >=20 > - Ralph Droms=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg last call, the document will not be advanced > to the IESG. >=20 > draft-ietf-dhc-dhcpv6-ero-00.txt defines a Relay Agent Echo Request > option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). > The option allows a DHCPv6 relay agent to request a list of relay > agent options that the server echoes back to the relay agent.. This > draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ero-00.txt >=20 > - Ralph Droms=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Feb 08 05:38:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF6f2-0001wA-SS; Thu, 08 Feb 2007 05:37:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF6f1-0001v2-JK for dhcwg@ietf.org; Thu, 08 Feb 2007 05:37:51 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF6ey-0001ed-Vk for dhcwg@ietf.org; Thu, 08 Feb 2007 05:37:51 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 08 Feb 2007 02:37:48 -0800 X-IronPort-AV: i="4.13,300,1167638400"; d="scan'208"; a="38066100:sNHT113993487" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l18AbmKK027719 for ; Thu, 8 Feb 2007 02:37:48 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l18Ablho006421 for ; Thu, 8 Feb 2007 02:37:48 -0800 (PST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 05:37:47 -0500 Received: from 10.86.240.248 ([10.86.240.248]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Feb 2007 10:37:47 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 08 Feb 2007 05:37:52 -0500 From: Ralph Droms To: dhcwg Message-ID: Thread-Topic: Important: Remember to use latest boilerplate in drafts Thread-Index: AcdLbS9GbgyvpLdgEduLywARJOT6eg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Feb 2007 10:37:47.0607 (UTC) FILETIME=[2CA7EE70:01C74B6D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6302; t=1170931068; x=1171795068; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20FW=3A=20Important=3A=20Remember=20to=20use=20latest=20boilerp late=20in=20drafts=20 |Sender:=20; bh=6yTfsB+JP4orYfO04iDMeeeHG7e2vxNjgzNRITpGvN4=; b=D3jG18tYtYyQ2SwKBlx3YW79cRhodNVtMIy8jlQPi8X32HDi4A5w4nWNzdPeRKeTM95CIKKK zd6C/4ZBl++ZT2SfmqRYjPXMWB5r8yj2uQqoBCLdw5LdPkawzbhJ05g2; Authentication-Results: sj-dkim-8; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Subject: [dhcwg] FW: Important: Remember to use latest boilerplate in drafts X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org FYI... - Ralph ------ Forwarded Message From: IETF Chair Date: Thu, 08 Feb 2007 05:15:20 -0500 To: IETF Announcement list Subject: Important: Remember to use latest boilerplate in drafts Hi, With the submission deadlines before the Prague meeting coming up, please remember that all drafts need to use the latest boilerplate text (see below for details). February 26, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 UTC/GMT) March 5, Monday - Internet Draft final submission cut-off by 09:00 ET (14:00 UTC/GMT) Thanks Brian Carpenter -------- Original Message -------- Subject: Internet-Draft Boilerplate Reminder Date: Mon, 15 Jan 2007 11:51:16 -0500 From: IETF Secretariat To: IETF Announcement list CC: iesg@ietf.org This message is to remind you that as of February 1, 2007 the IETF Secretariat will no longer accept Internet-Drafts with the old (i.e. pre RFC 4748) boilerplate. For your convenience, below is the text of the message that was sent to the IETF Announcement List by the IETF Chair on October 26, 2006 with Subject: Update to Internet Draft and RFC Boilerplate. The IETF Secretariat. -------------------------------------------------------------- A small update to BCP 78 was recently approved by the IESG as RFC 4748, to update the boilerplate (i.e., standard legal text) in RFCs and Internet-Drafts to recognize the IETF Trust as a rights holder, instead of ISOC. The actual boilerplate changes are given below this message. Starting as soon as reasonably possible, all authors of Internet-Drafts are requested to use the new boilerplate. The RFC Editor will in any case be inserting it in all RFCs issued from 2006-11-01. (The rights held by ISOC in older RFCs will be administratively transferred to the IETF Trust.) The public ID Nits checker already accepts I-Ds with old or new boilerplate. The Secretariat has started accepting I-Ds with old or new boilerplate. XML2RFC version 1.32 will generate the new boilerplate. Users of I-D templates are requested to update them appropriately. http://www.ietf.org/ID-Checklist.html and http://www.ietf.org/ietf/1id-guidelines.html are being updated. Starting December, the public ID Nits checker will issue warnings for old boilerplate. Starting February 2007, the Secretariat will refuse the old boilerplate in Internet-Drafts. We are sorry for the inconvenience, but this change cannot be avoided. IETF Chair IETF Secretariat TOOLS Team -------- Copyright Notice (required for all IETF Documents) (Normally placed at the end of the IETF Document.) NOTE: by convention, the first line of the copyright statement is usually placed near the beginning of each document. This must also be updated. OLD "Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. NEW "Copyright (C) The IETF Trust (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer (required in all IETF Documents) (Normally placed at the end of the IETF Document after the copyright notice.) OLD "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." NEW "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Exceptions In MIB modules, PIB modules and similar material commonly extracted from IETF Documents, except for material that is being placed under IANA maintenance, the following abbreviated notice shall be included in the body of the material that will be extracted in lieu of the notices otherwise required by Section 5: OLD "Copyright (C) The Internet Society . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." NEW "Copyright (C) The IETF Trust . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." When the MIB or PIB module is the initial version of a module that is to be maintained by the IANA, the following abbreviated notice shall be included: OLD "Copyright (C) The Internet Society . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." NEW "Copyright (C) The IETF Trust . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ------ End of Forwarded Message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Feb 08 06:48:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF7ju-0002ck-Ss; Thu, 08 Feb 2007 06:46:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF7js-0002bY-V8 for dhcwg@ietf.org; Thu, 08 Feb 2007 06:46:57 -0500 Received: from tyholt.uninett.no ([2001:700:1::eecb]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF7jn-0004tv-F1 for dhcwg@ietf.org; Thu, 08 Feb 2007 06:46:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by tyholt.uninett.no (Postfix) with ESMTP id 577EEB5B6C for ; Thu, 8 Feb 2007 12:46:26 +0100 (CET) Received: from tyholt.uninett.no ([127.0.0.1]) by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 11093-01-77 for ; Thu, 8 Feb 2007 12:46:26 +0100 (CET) Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no [IPv6:2001:700:1:7:215:f2ff:fe35:307d]) by tyholt.uninett.no (Postfix) with ESMTP id 24FF2B5B6B for ; Thu, 8 Feb 2007 12:46:26 +0100 (CET) Message-ID: <45CB0D91.2060605@uninett.no> Date: Thu, 08 Feb 2007 12:46:25 +0100 From: Stig Venaas User-Agent: Thunderbird 1.5.0.9 (X11/20070129) MIME-Version: 1.0 To: dhcwg Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-option drafts References: <45950DDB.3040009@uninett.no> <45B91756.3060909@uninett.no> In-Reply-To: <45B91756.3060909@uninett.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no X-Spam-Score: -2.8 (--) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org As I wrote below, these drafts did not pass wglc. Most members of the wg did not respond to the last call. Some of those who responded had technical objections to agentopt-delegate. We now need to find out what to do next. Do people believe that we don't need this, do you believe that snooping is a fine alternative? Or do you believe it can be done in some other way? The main issue is how to inject the necessary routes into the routing system. From a routing point of view it would be reasonable to have the route announced by the router that requested and was assigned the prefix. However this router would often be a customer router where the ISP router would not accept such route advertisements unless it knows they are legitimate. If the ISP router does not know what prefixes the customer has been assigned, some form of authentication would be needed. I don't know if that exists and it sounds complicated. agentopt-delegate would allow the ISP router to know what prefixes to allow routes for, or to announce routes for those itself. Another theoretical possibility would be for the DHCP server to somehow inject the route itself on behalf of the customer. I believe this is generally not possible, and does not sounds like a particularly nice solution. In short, what I would like to ask is, what is the alternative solution, or don't we need one? Or can the agentopt-delegate solution be improved in some way? I would like to get some discussion on this so that we can determine where to go next with these drafts. Stig Stig Venaas wrote: > Stig Venaas wrote: >> This message announces a wg last call on two drafts. They are >> >> DHCPv6 Relay Agent Assignment Notification (RAAN) Option >> >> >> and >> >> DHCPv6 Server Reply Sequence Number Option >> . >> >> The last call will conclude at 1700EST on Mon, 2007-01-15. > > These drafts did not pass wg last call. It appears we need to > further investigate whether there are better approaches, or > maybe even whether snooping is sufficient. In particular, > draft-stenberg-pd-route-maintenance may help us find or > eliminate other approaches. Apart from route injection, there > may be other reasons why the relay agent needs this information, > e.g. access control. > > Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Feb 08 10:08:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFAs0-0002uy-04; Thu, 08 Feb 2007 10:07:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFArx-0002um-Ub for dhcwg@ietf.org; Thu, 08 Feb 2007 10:07:29 -0500 Received: from scramble.princeton.edu ([128.112.232.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFArh-0007x3-HG for dhcwg@ietf.org; Thu, 08 Feb 2007 10:07:29 -0500 Received: from scramble.Princeton.EDU (irwin@localhost) by scramble.Princeton.EDU (8.13.7/8.13.7) with ESMTP id l18F6vAK018604 for ; Thu, 8 Feb 2007 10:06:59 -0500 (EST) Message-Id: <200702081506.l18F6vAK018604@scramble.Princeton.EDU> From: Irwin Tillman To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Feb 2007 10:06:57 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [dhcwg] Re: RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I will try to summarize the outcome of this discussion (which started on dhcwg, and continued on dhcp-users). I apologize in advance if my attempt to summarize leaves out the many valid finer points, or if I have misunderstood anyone. As the discussion developed, there were three "is this compliant with the RFCs?" issues: 1) May a DHCP client send a DHCPDISCOVER message while in the DHCP BOUND state (and remain in the BOUND state)? * Irwin Tillman (myself) believes a client that does so is not compliant with RFC 2131, based on the client state transition diagram. (Irwin also believes that if a server treats receipt of a DHCPDISCOVER message as indication that the client is in the DHCP INIT state, the server is compliant with RFC 2131, but is more restrictive than necessary.) * David Hankins believes a client that does so is compliant with RFC 2131, because this is not specifically disallowed by the RFC, and because the client state transition diagram shouldn't be interpreted as "MUST" behavior. He also believes the server shouldn't discard an existing lease except as a result of receiving a DHCPRELEASE or a DHCPREQUEST message from a client. He believes the server shouldn't infer the state of the client based solely upon the messages received from the client. (David also believes that if a server treats receipt of a DHCPDISCOVER message as indication that the client is in INIT state, the server is not compliant with RFC 2131.) * Keith Neufeld believes a client that does so is compliant with RFC 2131. * Kim Kinnear believes a client that does so is not compliant with RFC 2131, based primarily on the client state transition diagram. * Ted Lemon believes a client that does so is not compliant with RFC 2131. (Ted also believes that if a server treats receipt of a DHCPDISCOVER message as indication that the client is in the DHCP INIT state, the server is compliant with RFC 2131, but is more restrictive than necessary.) 2) May a DHCP client that believes it is RENEWING or REBINDING send DHCPREQUEST messages where the DHCP 'Server IP Address Option' is 0, the DHCP 'Requested IP Address Option' is 0, and the 'ciaddr' field is 0? * Irwin Tillman (myself) believes a client that does so is not compliant with RFC 2131. * David Hankins believes a client that does so is not compliant with RFC 2131. 3) May a client implementing DNAv4 send a DHCPDISCOVER message while carrying out the DNAv4 procedure if it has an "operable address"? * Irwin Tillman (myself) believes a client that does so is not compliant with RFC 4436. * David Hankins generally believes that the client that does so is not compliant with the text of RFC 4436, but believes that this was not the intent of RFC 4436. David feels the term "operable address" in that RFC may need to be updated. * Kim Kinnear believe a client that does so is not compliant with RFC 4436. * Ted Lemon believes a client that does so is not compliant with RFC 2131. FYI, I'd previously reported these issues to Apple as this is the way Apple Mac OS X 10.4.x behaves (at least versions 10.4.2 through 10.4.8). (Apple assigned this Bug Reporter Problem ID 4904550.) I updated my Apple bug report following our discussion. Apple's conclusion was, and remains, that the behavior of their client is correct. So the discussion, I suppose, is moot (at least as far as getting Mac OS X's behavior changed) but I thank you all for your valuable guidance and time. Irwin Tillman / OIT Network Systems / Princeton University _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Feb 08 12:37:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFDCY-0003eC-JB; Thu, 08 Feb 2007 12:36:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFDCX-0003cW-Ce for dhcwg@ietf.org; Thu, 08 Feb 2007 12:36:53 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFDCT-0004uk-3p for dhcwg@ietf.org; Thu, 08 Feb 2007 12:36:53 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l18HafAH001728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2007 11:36:42 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l18HafTX021210; Thu, 8 Feb 2007 09:36:41 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l18HaaHY020950; Thu, 8 Feb 2007 09:36:40 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 09:36:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Date: Thu, 8 Feb 2007 09:36:35 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177468C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <45CB0D91.2060605@uninett.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Thread-Index: AcdLdztfnothJkFvQp6kiw0atLh1OAALeJMg References: <45950DDB.3040009@uninett.no> <45B91756.3060909@uninett.no> <45CB0D91.2060605@uninett.no> From: "Templin, Fred L" To: "Stig Venaas" , "dhcwg" X-OriginalArrivalTime: 08 Feb 2007 17:36:36.0732 (UTC) FILETIME=[AEC81BC0:01C74BA7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Stig, > In short, what I would like to ask is, what is the alternative solution, > or don't we need one? Or can the agentopt-delegate solution be improved > in some way? I would like to get some discussion on this so that we can > determine where to go next with these drafts. As currently documented, the RAAN/SRSN options are piggybacked on DHCP messages that pass *through* the relay on their way to the client, and perhaps some of the concern is that the relay might get confused because it is a middlebox and not the endpoint responsible for reliable exchanges. So, one solution is to *make* the relay be the endpoint responsible for reliable exchanges by having it also configure a client function that can obtain the RAAN/SRSN reliably through out-of-band exchanges with the server. This would allow the same agentopt-delegate and srsn drafts to go forward with minor modifications that talk about the out-of-band exchanges with the relay's client. Note that this does not mean that RAAN/SRSN options could *only* go out-of-band wrt the DHCP exchanges btw the server and the true client; the options could still be included in-band whenever possible and the out-of-band mechanism used only when reliability is of concern. Fred fred.l.templin@boeing.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Feb 08 13:51:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFELj-0002Re-3j; Thu, 08 Feb 2007 13:50:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFELh-0002LP-Iq for dhcwg@ietf.org; Thu, 08 Feb 2007 13:50:25 -0500 Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFELf-000656-Vj for dhcwg@ietf.org; Thu, 08 Feb 2007 13:50:25 -0500 Received: by goliath.isc.org (Postfix, from userid 10200) id D9E985A6ED; Thu, 8 Feb 2007 10:50:00 -0800 (PST) Date: Thu, 8 Feb 2007 10:50:00 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] Re: RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? Message-ID: <20070208185000.GA2538@isc.org> References: <200702081506.l18F6vAK018604@scramble.Princeton.EDU> Mime-Version: 1.0 In-Reply-To: <200702081506.l18F6vAK018604@scramble.Princeton.EDU> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1445899445==" Errors-To: dhcwg-bounces@ietf.org --===============1445899445== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Given the responses of my peers, I probably am going to have to eat some 'unequivocal crow'. But as I've reflected on this further, we're really pitting two opposing non-reference behaviours against each other. "DISCOVER without continuing processing through to BOUND." It's hard to describe a behaviour that is not in RFC2131 as 'compliant', except that the DISCOVER that is emitted is done per the spec. So while I probably wouldn't use the word compliant, I would probably not use the word non-compliant. They're doing their own thing, and probably think of it as "INIT-RECONNECTED" state, or something like that, rather than anything on RFC2131's diagram. The DNAv4 variant of this same issue is absolutely non-compliant. I have reasons for thinking the author intended for 'operable address' to be different from 'unexpired lease.' Not the least of which is the conspicuous choice of words. 'unexpired lease' being used in RFC2131 (so, already well understood). More importantly, I believe the author of RFC4436 was optimizing for time. Transmitting a DISCOVER instead of a "INIT-REBOOT REQUEST" saves you the time it takes to receive a NAK and kick off the next DISCOVER. In either case, DNAv4 lets the client short circuit all other messages if the ARP probe succeeds. It is only to optimize for the ARP probe failure case that any message is transmitted: to optimize on time. At the same time, since DHCP servers do not commit information to persistent storage on DISCOVER, but do on REQUEST, it also represents a lighter-weight speculation. Since that represents what I think is a valid use case, it's my opinion that we should err on the side of permissiveness. In which case RFC4436 would clearly need to be updated, which judging by my peers there may not be consensus for. "Trimming lease-times on DISCOVER." This is more of a penumbra. No matter what the message, anytime a DHCP server elects to shorten a lease time it is taking a risk. On REQUEST/ACK, the response may be lost, and so the client may perfectly reasonably stay on the lease until the original expiration time. Of course we often do so anyway because it's a useful tool for a syadmin to have, but the risk is the same (the difference is that the sysadmin is watching, or has a greater risk to manage). DISCOVER/OFFER is no different. Again in the DISCOVER processing section of RFC2131, there is no explicit mention that the server do anything other than that it SHOULD NOT offer the same lease to a different client. So a server that chooses to shorten the lease time is neither implementing RFC2131 nor are they failing to. What's conspicuously missing from RFC2131 here is the text similar to what is used in REQUEST handling: offer. The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client. The combination of 'client identifier' or The conspicuous absence of similar text regarding DISCOVER processing leads me to believe that no permanent changes must be recorded by receiving a DISCOVER. At any rate, thank you Irwin for bringing this to our attention. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFy3DYcXeLeWu2vmoRAutrAJ42NncyTQj9/GtLmby9f5N1WE1ehwCePxus ywKw7C/KYIqiarRH+jBr1e8= =1doz -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- --===============1445899445== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1445899445==-- From dhcwg-bounces@ietf.org Fri Feb 09 05:20:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFSr4-0002O9-Ry; Fri, 09 Feb 2007 05:19:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFSr3-0002O3-Lm for dhcwg@ietf.org; Fri, 09 Feb 2007 05:19:45 -0500 Received: from intermail.se.dataphone.net ([212.37.1.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFSqz-0007n9-7H for dhcwg@ietf.org; Fri, 09 Feb 2007 05:19:45 -0500 Received: from [213.115.152.226] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.2) with ESMTP id 38378149 for dhcwg@ietf.org; Fri, 09 Feb 2007 11:19:39 +0100 From: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Subject: Re: [dhcwg] Re: RFC 2131: can a DHCPv4 client (Mac OS X) transition directly from BOUND to INIT then back to BOUND? Date: Fri, 9 Feb 2007 11:04:06 +0100 User-Agent: KMail/1.8 References: <200702081506.l18F6vAK018604@scramble.Princeton.EDU> <20070208185000.GA2538@isc.org> In-Reply-To: <20070208185000.GA2538@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702091104.06431.budm@weird-solutions.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bud Millwood List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org On Thursday 08 February 2007 19:50, David W. Hankins wrote: > "DISCOVER without continuing processing through to BOUND." > > It's hard to describe a behaviour that is not in RFC2131 as > 'compliant', except that the DISCOVER that is emitted is done > per the spec. It's done per the syntax of the spec. > So while I probably wouldn't use the word > compliant, I would probably not use the word non-compliant. It's semantically non-compliant with the spec. > They're doing their own thing, and probably think of it > as "INIT-RECONNECTED" state, or something like that, rather > than anything on RFC2131's diagram. Which leads us to: Is the syntax of RFC 2131 independent of the semantics? I don't believe it is. It tries to be, but without the semantics, isn't the syntax moot? It follows that I believe that implementing RFC 2131 syntactically correctly is not enough to make you conformant, regardless of the fact that the RFC strives to make the syntax as independent of the semantics as possible. The protocol is about semantics. - Bud Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Feb 09 16:11:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFd0c-0006Ma-Qw; Fri, 09 Feb 2007 16:10:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFd0b-0006LU-DQ for dhcwg@ietf.org; Fri, 09 Feb 2007 16:10:17 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFd0Z-0007xZ-5D for dhcwg@ietf.org; Fri, 09 Feb 2007 16:10:17 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2007 16:10:15 -0500 X-IronPort-AV: i="4.13,308,1167627600"; d="scan'208"; a="113515263:sNHT46633606" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l19LAFTA012470 for ; Fri, 9 Feb 2007 16:10:15 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l19LAEVT015855 for ; Fri, 9 Feb 2007 16:10:14 -0500 (EST) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 16:10:14 -0500 Received: from 10.86.242.52 ([10.86.242.52]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Feb 2007 21:10:13 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 09 Feb 2007 16:10:12 -0500 From: Ralph Droms To: dhcwg Message-ID: Thread-Topic: dhc WG meeting in Prague Thread-Index: AcdMjq+w7mHm8biBEduLywARJOT6eg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Feb 2007 21:10:14.0412 (UTC) FILETIME=[B1209CC0:01C74C8E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=179; t=1171055415; x=1171919415; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdroms@cisco.com; z=From:=20Ralph=20Droms=20 |Subject:=20dhc=20WG=20meeting=20in=20Prague |Sender:=20 |To:=20dhcwg=20; bh=rPtwsK48jBN9s1xWPq7uTwHWE9Q3N5vDPNlbCMMDDNk=; b=TzlvwR4whejk1oIWmLNwilrHi7ZEJZMGYIgAPyAekmufji1jxHhnQN+iWFd15ZAyEH1/bsoT cEUQju6O8ItS/EPTIESuyHuhucF2i6gYXsAsuqbbdcdG0SB0uYGcqNY7; Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [dhcwg] dhc WG meeting in Prague X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org WEDNESDAY, March 21, 2007 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Session I Karlin I INT dhc Dynamic Host Configuration WG _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Feb 09 19:30:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFg6n-0000IJ-W4; Fri, 09 Feb 2007 19:28:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFg6m-0000AH-NA for dhcwg@ietf.org; Fri, 09 Feb 2007 19:28:52 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFg6l-00089z-AY for dhcwg@ietf.org; Fri, 09 Feb 2007 19:28:52 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2007 19:28:51 -0500 X-IronPort-AV: i="4.13,308,1167627600"; d="scan'208"; a="113527593:sNHT59225252" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1A0SpQq009041; Fri, 9 Feb 2007 19:28:51 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1A0SoVV026583; Fri, 9 Feb 2007 19:28:51 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 19:28:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts Date: Fri, 9 Feb 2007 19:28:47 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210333ECF1@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <45CB0D91.2060605@uninett.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts thread-index: AcdLdz7ztjCWQUvNSAOvK02henem3ABMMsvg From: "Bernie Volz \(volz\)" To: "Stig Venaas" , "dhcwg" X-OriginalArrivalTime: 10 Feb 2007 00:28:50.0773 (UTC) FILETIME=[6FD50050:01C74CAA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4065; t=1171067331; x=1171931331; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele gate=20and=20srsn-optiondrafts |Sender:=20 |To:=20=22Stig=20Venaas=22=20, =20=22dhcwg=22=20; bh=qHMKrNFfBEKkPlh1kgn3cSZhoIDlWcrssUD4Fi1cQ74=; b=NllM3alL6NGa1GkQHHD2m38HizCh/1gDyKsSNKlqCgIdo0aGq1cCHnlca7mh2UjkcPnVVrdQ tj6tqwLYTJz2Q8D+uIiZ5JLAxTnYY/mAufsWSAjapB23upncx5+nU8hd; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I'd also suggest that members read http://www.ietf.org/internet-drafts/draft-stenberg-pd-route-maintenance- 00.txt. Perhaps agentopt-delegate combined with some of the concepts in this other draft (such as Bidirectional Forwarding Detection (BFD)) can be used to provide additional information/feedback loops to address some of the shortcomings. In particular, if a client releases or declines a delegated prefix or stateful address but the router fails to receive the Reply with the updated RAAN information, the router would find out via BFD that the client is no longer using it and could stop announcing the route (and/or perform a leasequery to assure it has updated information). I too do not feel that having the DHCP server handle the route injection is feasible; it comes with its own set of issues since the server has no idea whether the router(s) are up, the full paths (hops) to the routers, the metrics with which to advertise the routes, etc. Snooping has its own set of issues and complexities. Even more so with DHCP authentication as you probably don't want to require the relay also have the keys. Snooping is also subject to the issues that the SRSN option attempted to solve, so if snooping were the desired solution, we still need the SRSN option. - Bernie -----Original Message----- From: Stig Venaas [mailto:stig.venaas@uninett.no]=20 Sent: Thursday, February 08, 2007 6:46 AM To: dhcwg Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-optiondrafts As I wrote below, these drafts did not pass wglc. Most members of the wg did not respond to the last call. Some of those who responded had technical objections to agentopt-delegate. We now need to find out what to do next. Do people believe that we don't need this, do you believe that snooping is a fine alternative? Or do you believe it can be done in some other way? The main issue is how to inject the necessary routes into the routing system. From a routing point of view it would be reasonable to have the route announced by the router that requested and was assigned the prefix. However this router would often be a customer router where the ISP router would not accept such route advertisements unless it knows they are legitimate. If the ISP router does not know what prefixes the customer has been assigned, some form of authentication would be needed. I don't know if that exists and it sounds complicated. agentopt-delegate would allow the ISP router to know what prefixes to allow routes for, or to announce routes for those itself. Another theoretical possibility=20 would be for the DHCP server to somehow inject the route itself on behalf of the customer. I believe this is generally not possible, and does not sounds like a particularly nice solution. In short, what I would like to ask is, what is the alternative solution, or don't we need one? Or can the agentopt-delegate solution be improved in some way? I would like to get some discussion on this so that we can determine where to go next with these drafts. Stig Stig Venaas wrote: > Stig Venaas wrote: >> This message announces a wg last call on two drafts. They are >> >> DHCPv6 Relay Agent Assignment Notification (RAAN) Option >> >> >> and >> >> DHCPv6 Server Reply Sequence Number Option >> . >> >> The last call will conclude at 1700EST on Mon, 2007-01-15. >=20 > These drafts did not pass wg last call. It appears we need to > further investigate whether there are better approaches, or > maybe even whether snooping is sufficient. In particular, > draft-stenberg-pd-route-maintenance may help us find or > eliminate other approaches. Apart from route injection, there > may be other reasons why the relay agent needs this information, > e.g. access control. >=20 > Stig _______________________________________________ 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-bounces@ietf.org Fri Feb 09 19:41:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgIW-0000aC-R2; Fri, 09 Feb 2007 19:41:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgIV-0000Zd-71 for dhcwg@ietf.org; Fri, 09 Feb 2007 19:40:59 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFgIT-0001cV-RC for dhcwg@ietf.org; Fri, 09 Feb 2007 19:40:59 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2007 16:40:57 -0800 X-IronPort-AV: i="4.13,308,1167638400"; d="scan'208"; a="387665624:sNHT55425536" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1A0evHw020596 for ; Fri, 9 Feb 2007 16:40:57 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1A0ebnP003187 for ; Fri, 9 Feb 2007 16:40:57 -0800 (PST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 19:40:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? Date: Fri, 9 Feb 2007 19:40:49 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210333ECF6@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB21032ABEB5@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? thread-index: AcdHPQfsrb513R1vSy6QmXlRVjnS1QFbtUhQ From: "Bernie Volz \(volz\)" To: X-OriginalArrivalTime: 10 Feb 2007 00:40:55.0007 (UTC) FILETIME=[1F8256F0:01C74CAC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2179; t=1171068057; x=1171932057; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20DHCPv6=20-=20Experimental=20Message=20(&=20 Option)=20Codes? |Sender:=20; bh=duOrEkBjZHrdsThThyhs+Z/CIaRoGYvmUGSIQNukizY=; b=bIj/pzi/6RuiW1VSjGrjFAQpGFAYGlg00c2v/HLHlPTn1/ra76QLok4hLN7nV0dfY9Hz0fYF Dn12fpmOxvALO8dn5pIwqbGVh91AQFOfI/QZNffdM+/3a8XZ0LgUN7+g; Authentication-Results: sj-dkim-8; header.From=volz@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org Second try to solicit some feedback ... write draft or bad idea? - Bernie -----Original Message----- From: Bernie Volz (volz)=20 Sent: Friday, February 02, 2007 9:43 PM To: dhcwg@ietf.org Subject: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? Before I write up the draft (individual submission), what do folks think about having IANA allocate a number of DHCPv6 message codes for experimental use. Each of these messages would be encoded as <1-octet msg-type><4-octet enterprise-id>. This would allow the same message codes to be used by multiple enterprises (and within an enterprise) without collisions. While technically 1 message code would do (and I'd be happy with that), it might be best to allocate 16 codes? These should be relayed by relay agents. --- A second proposal (part of the same draft) is to also have IANA reserve a number of option codes for experimental use. These could *ONLY* be used within the experimental messages codes mentioned above (never in "normal" DHCPv6 messages). The reason for this is that it would allow the experimental messages to contain both "normal" DHCPv6 options and these experimental options. This would avoid the need for these messages to encode private option codes in Vendor-Specific messages or use other techniques to separate the "official" option space from the private space. With 65,535 option codes available, I can't see that allocating say 1,024 for this purpose would cause much hardship for us down the road. Perhaps 1,024 is way to much and 256 would do. Again, these experimental option codes MUST NOT appear in the "normal" DHCPv6 messages - they may only be used in the experimental messages -- but the important point is that they would never conflict with IANA assigned numbers. So, let me know if you would be strongly opposed to these ideas or whether you might support them (subject to the I-D being acceptable ...). Don't ask for me to give you a use at this time. - Bernie _______________________________________________ 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-bounces@ietf.org Fri Feb 09 19:53:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgTV-0001A4-Di; Fri, 09 Feb 2007 19:52:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgTU-00019q-9p for dhcwg@ietf.org; Fri, 09 Feb 2007 19:52:20 -0500 Received: from h216-18-16-189.gtcust.grouptelecom.net ([216.18.16.189] helo=zeus.incognito.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFgTR-0003gF-W8 for dhcwg@ietf.org; Fri, 09 Feb 2007 19:52:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? Date: Fri, 9 Feb 2007 16:55:31 -0800 Message-ID: <403B5316AD7A254C9024875BAE481D4E610EE5@zeus.incognito.com> In-Reply-To: <8E296595B6471A4689555D5D725EBB210333ECF6@xmb-rtp-20a.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? Thread-Index: AcdHPQfsrb513R1vSy6QmXlRVjnS1QFbtUhQAAB6jJA= References: <8E296595B6471A4689555D5D725EBB21032ABEB5@xmb-rtp-20a.amer.cisco.com> <8E296595B6471A4689555D5D725EBB210333ECF6@xmb-rtp-20a.amer.cisco.com> From: "Andre Kostur" To: "Bernie Volz \(volz\)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org I'm not sold on the idea yet. Particularly, I'm concerned about "experimental" options that end up getting used in some vendor's products, and they become "standard" options simply because they're used everywhere. Kind of like the PXE (PXElinux?) options. They were defined in the site-local space, but since they have become used in so many different sites, they effectively became standard options. Regards, =20 Andre Kostur Incognito Software Inc. Senior Software Design Engineer T: +1(604)678-2864 F: +1(604)688-4339 E: akostur@incognito.com =20 www.incognito.com -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Friday, February 09, 2007 4:41 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? Second try to solicit some feedback ... write draft or bad idea? - Bernie -----Original Message----- From: Bernie Volz (volz) Sent: Friday, February 02, 2007 9:43 PM To: dhcwg@ietf.org Subject: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? Before I write up the draft (individual submission), what do folks think about having IANA allocate a number of DHCPv6 message codes for experimental use. Each of these messages would be encoded as <1-octet msg-type><4-octet enterprise-id>. This would allow the same message codes to be used by multiple enterprises (and within an enterprise) without collisions. While technically 1 message code would do (and I'd be happy with that), it might be best to allocate 16 codes? These should be relayed by relay agents. --- A second proposal (part of the same draft) is to also have IANA reserve a number of option codes for experimental use. These could *ONLY* be used within the experimental messages codes mentioned above (never in "normal" DHCPv6 messages). The reason for this is that it would allow the experimental messages to contain both "normal" DHCPv6 options and these experimental options. This would avoid the need for these messages to encode private option codes in Vendor-Specific messages or use other techniques to separate the "official" option space from the private space. With 65,535 option codes available, I can't see that allocating say 1,024 for this purpose would cause much hardship for us down the road. Perhaps 1,024 is way to much and 256 would do. Again, these experimental option codes MUST NOT appear in the "normal" DHCPv6 messages - they may only be used in the experimental messages -- but the important point is that they would never conflict with IANA assigned numbers. So, let me know if you would be strongly opposed to these ideas or whether you might support them (subject to the I-D being acceptable ...). Don't ask for me to give you a use at this time. - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Feb 09 20:53:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFhOv-0006Eu-1J; Fri, 09 Feb 2007 20:51:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFhOu-0006E6-2v for dhcwg@ietf.org; Fri, 09 Feb 2007 20:51:40 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFhOp-0005N4-OH for dhcwg@ietf.org; Fri, 09 Feb 2007 20:51:40 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 09 Feb 2007 20:51:35 -0500 X-IronPort-AV: i="4.13,308,1167627600"; d="scan'208"; a="113535994:sNHT77589440" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1A1pZBf015618; Fri, 9 Feb 2007 20:51:35 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1A1pYVT019960; Fri, 9 Feb 2007 20:51:35 -0500 (EST) Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 20:51:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? Date: Fri, 9 Feb 2007 20:51:18 -0500 Message-ID: <8E296595B6471A4689555D5D725EBB210333ED2A@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <403B5316AD7A254C9024875BAE481D4E610EE5@zeus.incognito.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? thread-index: AcdHPQfsrb513R1vSy6QmXlRVjnS1QFbtUhQAAB6jJAAAHajIA== From: "Bernie Volz \(volz\)" To: "Andre Kostur" , X-OriginalArrivalTime: 10 Feb 2007 01:51:34.0804 (UTC) FILETIME=[FEA00540:01C74CB5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3841; t=1171072295; x=1171936295; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=volz@cisco.com; z=From:=20=22Bernie=20Volz=20\(volz\)=22=20 |Subject:=20RE=3A=20[dhcwg]=20DHCPv6=20-=20Experimental=20Message=20(&=20 Option)=20Codes? |Sender:=20 |To:=20=22Andre=20Kostur=22=20,=20; bh=rIwRwHb4QhnflnfoFvPVqTflu0ijPtfnIOdMKa+tqlY=; b=BRuL2v3Xjw+alpYPeKsKiGEICyF8Y1AX6YwgugxgPuCSqqIqW1hOIbhLp9nh/ETRrO4LAavn Zo2kucRq6k7Pm21Tc/xmVj+fdEkNscaxb1bXOFH1Bb4CeHtmQOv+L6zG; Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: dhcwg-bounces@ietf.org That indeed is my biggest concern. And, sadly there is no good way to prevent this from happening and why I too am reluctant to do it. All we can offer is words such as MUST NOT appear in anything but experimental messages. A bigger stick would be to require clients and servers to discard any non-experimental messages with these options in them, but that adds to the burden of clients and servers. On the flip side there's nothing from preventing someone from picking a high option number today and using it. It is unlikely that it will collide for a long time (if ever)! Perhaps we should have IANA use a random number generator to assign option numbers -- that means the risk of a collision is the same as any other number. - Bernie -----Original Message----- From: Andre Kostur [mailto:akostur@incognito.com]=20 Sent: Friday, February 09, 2007 7:56 PM To: Bernie Volz (volz); dhcwg@ietf.org Subject: RE: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? I'm not sold on the idea yet. Particularly, I'm concerned about "experimental" options that end up getting used in some vendor's products, and they become "standard" options simply because they're used everywhere. Kind of like the PXE (PXElinux?) options. They were defined in the site-local space, but since they have become used in so many different sites, they effectively became standard options. Regards, =20 Andre Kostur Incognito Software Inc. Senior Software Design Engineer T: +1(604)678-2864 F: +1(604)688-4339 E: akostur@incognito.com =20 www.incognito.com -----Original Message----- From: Bernie Volz (volz) [mailto:volz@cisco.com]=20 Sent: Friday, February 09, 2007 4:41 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? Second try to solicit some feedback ... write draft or bad idea? - Bernie -----Original Message----- From: Bernie Volz (volz) Sent: Friday, February 02, 2007 9:43 PM To: dhcwg@ietf.org Subject: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes? Before I write up the draft (individual submission), what do folks think about having IANA allocate a number of DHCPv6 message codes for experimental use. Each of these messages would be encoded as <1-octet msg-type><4-octet enterprise-id>. This would allow the same message codes to be used by multiple enterprises (and within an enterprise) without collisions. While technically 1 message code would do (and I'd be happy with that), it might be best to allocate 16 codes? These should be relayed by relay agents. --- A second proposal (part of the same draft) is to also have IANA reserve a number of option codes for experimental use. These could *ONLY* be used within the experimental messages codes mentioned above (never in "normal" DHCPv6 messages). The reason for this is that it would allow the experimental messages to contain both "normal" DHCPv6 options and these experimental options. This would avoid the need for these messages to encode private option codes in Vendor-Specific messages or use other techniques to separate the "official" option space from the private space. With 65,535 option codes available, I can't see that allocating say 1,024 for this purpose would cause much hardship for us down the road. Perhaps 1,024 is way to much and 256 would do. Again, these experimental option codes MUST NOT appear in the "normal" DHCPv6 messages - they may only be used in the experimental messages -- but the important point is that they would never conflict with IANA assigned numbers. So, let me know if you would be strongly opposed to these ideas or whether you might support them (subject to the I-D being acceptable ...). Don't ask for me to give you a use at this time. - Bernie _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Feb 10 08:26:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFsEm-0008Ap-TJ; Sat, 10 Feb 2007 08:25:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvwc-0001R3-8z; Tue, 30 Jan 2007 11:34:54 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvwa-0003jj-Kc; Tue, 30 Jan 2007 11:34:54 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 17:34:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Jan 2007 17:34:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a problem about dhcpv6 using 'dhcp-0.10.tgz' Thread-Index: AcdBL/9ue0+ntLI1TkmlONFpcDjSrgDXGDaw From: "zze-FENG Zhimin RD-CORE-CAE" To: X-OriginalArrivalTime: 30 Jan 2007 16:34:48.0098 (UTC) FILETIME=[8E8BB820:01C7448C] X-Spam-Score: 0.8 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d X-Mailman-Approved-At: Sat, 10 Feb 2007 08:25:52 -0500 Cc: dhcwg@ietf.org Subject: [dhcwg] TR: a problem about dhcpv6 using 'dhcp-0.10.tgz' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0271348562==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0271348562== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7448C.8DDB235A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7448C.8DDB235A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > Dear Sir or Madame, > I am an intern of France Telecom R&D . I am trying to setup a DHCPv6 > server-client system using the 'dhcp-0.10.tgz'. The server end is ok > , however , I meet a problem : in the DHCPv6 client , where I always > get a error message : ' interface eth0 iaid failed to be created' . > And I do not know how to resolve it. Can you give me an advice? > Thank you very much!=20 > I am looking forward to your reply!=20 > Yours sincerely, > =20 > Zhimin FENG=20 >=20 > And there are these configurations in my computers :=20 >=20 > In the HDCPv6 server :=20 > /etc/ dhcp6s.conf=20 > interface eth0 { > server-preference 255; > renew-time 60; > rebind-time 90; > prefer-life-time 130; > valid-life-time 160; > allow rapid-commit; > link BBB { > pool { > prefix 2001:1234:100::/48; > }; > }; > }; > =09 >=20 > And the terminal :=20 > [root@localhost ~]# dhcp6s -dDf eth0 > Jan/26/2007 09:43:59 extracted an existing DUID from > /var/lib/dhcpv6/dhcp6s_duid: 00:01:00:01:0d:48:8c:d8:00:11:09:34:d5:bd > Jan/26/2007 09:43:59 set timer for syncing file ... > Jan/26/2007 09:43:59 interface definition for eth0 is ok=09 >=20 >=20 > In the DHCPv6 Clinet : >=20 > Dhcp6c.conf=20 >=20 > interface eth0 { > # information-only; > send rapid-commit; > request prefix-delegation; > # request temp-address; > }; > =09 >=20 > In the terminal : > [root@localhost dhcp-0.10]# ./dhcp6c -c ./dhcp6c.conf -dDf eth0 >=20 > Jan/26/2007 09:39:57 <3>[interface] (9) > Jan/26/2007 09:39:57 <5>[eth0] (4) > Jan/26/2007 09:39:57 <3>begin of closure [{] (1) > Jan/26/2007 09:39:57 <3>comment [# information-only;] (19) > Jan/26/2007 09:39:57From dhcwg-bounces@ietf.org Sat Feb 10 08:26:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFsEm-0008Ap-TJ; Sat, 10 Feb 2007 08:25:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBvwc-0001R3-8z; Tue, 30 Jan 2007 11:34:54 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBvwa-0003jj-Kc; Tue, 30 Jan 2007 11:34:54 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 17:34:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 30 Jan 2007 17:34:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a problem about dhcpv6 using 'dhcp-0.10.tgz' Thread-Index: AcdBL/9ue0+ntLI1TkmlONFpcDjSrgDXGDaw From: "zze-FENG Zhimin RD-CORE-CAE" To: X-OriginalArrivalTime: 30 Jan 2007 16:34:48.0098 (UTC) FILETIME=[8E8BB820:01C7448C] X-Spam-Score: 0.8 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d X-Mailman-Approved-At: Sat, 10 Feb 2007 08:25:52 -0500 Cc: dhcwg@ietf.org Subject: [dhcwg] TR: a problem about dhcpv6 using 'dhcp-0.10.tgz' X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0271348562==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0271348562== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7448C.8DDB235A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7448C.8DDB235A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > Dear Sir or Madame, > I am an intern of France Telecom R&D . I am trying to setup a DHCPv6 > server-client system using the 'dhcp-0.10.tgz'. The server end is ok > , however , I meet a problem : in the DHCPv6 client , where I always > get a error message : ' interface eth0 iaid failed to be created' . > And I do not know how to resolve it. Can you give me an advice? > Thank you very much!=20 > I am looking forward to your reply!=20 > Yours sincerely, > =20 > Zhimin FENG=20 >=20 > And there are these configurations in my computers :=20 >=20 > In the HDCPv6 server :=20 > /etc/ dhcp6s.conf=20 > interface eth0 { > server-preference 255; > renew-time 60; > rebind-time 90; > prefer-life-time 130; > valid-life-time 160; > allow rapid-commit; > link BBB { > pool { > prefix 2001:1234:100::/48; > }; > }; > }; > =09 >=20 > And the terminal :=20 > [root@localhost ~]# dhcp6s -dDf eth0 > Jan/26/2007 09:43:59 extracted an existing DUID from > /var/lib/dhcpv6/dhcp6s_duid: 00:01:00:01:0d:48:8c:d8:00:11:09:34:d5:bd > Jan/26/2007 09:43:59 set timer for syncing file ... > Jan/26/2007 09:43:59 interface definition for eth0 is ok=09 >=20 >=20 > In the DHCPv6 Clinet : >=20 > Dhcp6c.conf=20 >=20 > interface eth0 { > # information-only; > send rapid-commit; > request prefix-delegation; > # request temp-address; > }; > =09 >=20 > In the terminal : > [root@localhost dhcp-0.10]# ./dhcp6c -c ./dhcp6c.conf -dDf eth0 >=20 > Jan/26/2007 09:39:57 <3>[interface] (9) > Jan/26/2007 09:39:57 <5>[eth0] (4) > Jan/26/2007 09:39:57 <3>begin of closure [{] (1) > Jan/26/2007 09:39:57 <3>comment [# information-only;] (19) > Jan/26/2007 09:39:57 <3>[send] (4) > Jan/26/2007 09:39:57 <3>[rapid-commit] (12) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 <3>[request] (7) > Jan/26/2007 09:39:57 <3>[prefix-delegation] (17) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 <3>comment [# request temp-address;] (23) > Jan/26/2007 09:39:57 <3>end of closure [}] (1) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 extracted an existing DUID from > /var/lib/dhcpv6/dhcp6c_duid: > 00:01:00:01:0d:4b:2e:6d:00:01:02:9d:71:c4 > Jan/26/2007 09:39:57 link local addr is fe80::250:daff:fe47:8ff9 > Jan/26/2007 09:39:57 res addr is fe80::250:daff:fe47:8ff9%eth0/28 > Jan/26/2007 09:39:57 found an interface eth0 harware bfdeed25 > Jan/26/2007 09:39:57 interface eth0 iaid failed to be created=09 >=20 >=20 ------_=_NextPart_001_01C7448C.8DDB235A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable TR: a problem about dhcpv6 using 'dhcp-0.10.tgz'

Dear Sir or = Madame,
I am an intern = of France Telecom R&D . I am trying to setup  a DHCPv6 = server-client system using the 'dhcp-0.10.tgz'.  The server end is = ok , however , I meet a problem : in the DHCPv6 client , where I always = get a error message : ' interface eth0 iaid failed to be created' = . And I do not know how to resolve it. Can you give me an = advice?

Thank you very = much!
I am looking = forward to your reply!
Yours = sincerely,
 
Zhimin FENG =

And there are = these configurations  in my  computers :

In the HDCPv6 = server :
/etc/ = dhcp6s.conf
interface eth0 = {
      server-preference = 255;
     renew-time 60;
     rebind-time 90;
    prefer-life-time 130;
    valid-life-time 160;
    allow rapid-commit;
   = link BBB {
       pool {
           = prefix 2001:1234:100::/48;
       };
          = };
[send] (4) > Jan/26/2007 09:39:57 <3>[rapid-commit] (12) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 <3>[request] (7) > Jan/26/2007 09:39:57 <3>[prefix-delegation] (17) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 <3>comment [# request temp-address;] (23) > Jan/26/2007 09:39:57 <3>end of closure [}] (1) > Jan/26/2007 09:39:57 <3>end of sentence [;] (1) > Jan/26/2007 09:39:57 extracted an existing DUID from > /var/lib/dhcpv6/dhcp6c_duid: > 00:01:00:01:0d:4b:2e:6d:00:01:02:9d:71:c4 > Jan/26/2007 09:39:57 link local addr is fe80::250:daff:fe47:8ff9 > Jan/26/2007 09:39:57 res addr is fe80::250:daff:fe47:8ff9%eth0/28 > Jan/26/2007 09:39:57 found an interface eth0 harware bfdeed25 > Jan/26/2007 09:39:57 interface eth0 iaid failed to be created=09 >=20 >=20 ------_=_NextPart_001_01C7448C.8DDB235A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable TR: a problem about dhcpv6 using 'dhcp-0.10.tgz'

Dear Sir or = Madame,
I am an intern = of France Telecom R&D . I am trying to setup  a DHCPv6 = server-client system using the 'dhcp-0.10.tgz'.  The server end is = ok , however , I meet a problem : in the DHCPv6 client , where I always = get a error message : ' interface eth0 iaid failed to be created' = . And I do not know how to resolve it. Can you give me an = advice?

Thank you very = much!
I am looking = forward to your reply!
Yours = sincerely,
 
Zhimin FENG =

And there are = these configurations  in my  computers :

In the HDCPv6 = server :
/etc/ = dhcp6s.conf
interface eth0 = {
      server-preference = 255;
     renew-time 60;
     rebind-time 90;
    prefer-life-time 130;
    valid-life-time 160;
    allow rapid-commit;
   = link BBB {
       pool {
           = prefix 2001:1234:100::/48;
       };
          = };
};
       
And  the = terminal :
[root@localhost = ~]# dhcp6s -dDf eth0
Jan/26/2007 = 09:43:59 extracted an existing DUID from /var/lib/dhcpv6/dhcp6s_duid: = 00:01:00:01:0d:48:8c:d8:00:11:09:34:d5:bd

Jan/26/2007 = 09:43:59 set timer for syncing file ...
Jan/26/2007 = 09:43:59 interface definition for eth0 is = ok       

In the DHCPv6 = Clinet :

Dhcp6c.conf =

interface eth0 = {
#       = information-only;
           send = rapid-commit;
        = request prefix-delegation;
#       request = temp-address;
};
       
In the terminal = :
[root@localhost = dhcp-0.10]# ./dhcp6c -c ./dhcp6c.conf -dDf eth0

Jan/26/2007 = 09:39:57 <3>[interface] (9)
Jan/26/2007 = 09:39:57 <5>[eth0] (4)
Jan/26/2007 = 09:39:57 <3>begin of closure [{] (1)
Jan/26/2007 = 09:39:57 <3>comment [#      = information-only;] (19)
Jan/26/2007 = 09:39:57 <3>[send] (4)
Jan/26/2007 = 09:39:57 <3>[rapid-commit] (12)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 <3>[request] (7)
Jan/26/2007 = 09:39:57 <3>[prefix-delegation] (17)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 <3>comment [#      request = temp-address;] (23)
Jan/26/2007 = 09:39:57 <3>end of closure [}] (1)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 extracted an existing DUID from = /var/lib/dhcpv6/dhcp6c_duid:
00:01:00:01:0d:4b:2e:6d:00:01:02:9d:71:c4
Jan/26/2007 = 09:39:57 link local addr is fe80::250:daff:fe47:8ff9
Jan/26/2007 = 09:39:57 res addr is fe80::250:daff:fe47:8ff9%eth0/28
Jan/26/2007 = 09:39:57 found an interface eth0 harware bfdeed25
Jan/26/2007 = 09:39:57 interface eth0 iaid failed to be created  

------_=_NextPart_001_01C7448C.8DDB235A-- --===============0271348562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0271348562==-- From dhcwg-bounces@ietf.org Sat Feb 10 08:26:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFsEn-0008Au-7i; Sat, 10 Feb 2007 08:25:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCON0-0007J6-9p for dhcwg@ietf.org; Wed, 31 Jan 2007 17:56:02 -0500 Received: from chip8og51.obsmtp.com ([64.18.15.175]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCOMx-0004Ix-W1 for dhcwg@ietf.org; Wed, 31 Jan 2007 17:56:02 -0500 Received: from source ([151.190.254.200]) by chip8ob51.postini.com ([64.18.7.12]) with SMTP; Wed, 31 Jan 2007 14:55:59 PST Received: from fwetgsmtp1.itt.net ([10.32.77.200]) by ittsmtp1 with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:59:32 -0500 Received: from fwdefsmtp2.de.ittind.com ([10.32.77.203]) by fwetgsmtp1.itt.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:55:46 -0500 Received: from njbridge01.avionics.de.ittind.com ([10.37.1.77]) by fwdefsmtp2.de.ittind.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:55:46 -0500 Received: from ACDNJMAILSRV03.acd.de.ittind.com ([10.37.1.152]) by njbridge01.avionics.de.ittind.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:55:46 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 Jan 2007 17:55:45 -0500 Message-ID: <56D2E48D28DC3B4EA5F2E4B7679D72F7384A1F@ACDNJMAILSRV03.acd.de.ittind.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP and DHCP Thread-Index: AcdFivGWJevlifBRQJeAbIXBBR0Fcw== From: "Gonzalez, Pedro - ACD " To: X-OriginalArrivalTime: 31 Jan 2007 22:55:46.0025 (UTC) FILETIME=[F1585590:01C7458A] X-Spam-Score: 0.4 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-Mailman-Approved-At: Sat, 10 Feb 2007 08:25:54 -0500 Subject: [dhcwg] PPP and DHCP X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0765336403==" Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0765336403== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7458A.F12B6B9C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7458A.F12B6B9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was wondering if there was any information on running DHCP/Ipv4 over PPP links. Is there a way to use DHCP to configure the IP address of a device on its PPP interface instead of using IPCP?=20 I am new to this mailing list. So, please pardon me if this question has been raised before. In that case, I'd appreciate any po=3D"Times New Roman">};
       
And  the = terminal :
[root@localhost = ~]# dhcp6s -dDf eth0
Jan/26/2007 = 09:43:59 extracted an existing DUID from /var/lib/dhcpv6/dhcp6s_duid: = 00:01:00:01:0d:48:8c:d8:00:11:09:34:d5:bd

Jan/26/2007 = 09:43:59 set timer for syncing file ...
Jan/26/2007 = 09:43:59 interface definition for eth0 is = ok       

In the DHCPv6 = Clinet :

Dhcp6c.conf =

interface eth0 = {
#       = information-only;
           send = rapid-commit;
        = request prefix-delegation;
#       request = temp-address;
};
       
In the terminal = :
[root@localhost = dhcp-0.10]# ./dhcp6c -c ./dhcp6c.conf -dDf eth0

Jan/26/2007 = 09:39:57 <3>[interface] (9)
Jan/26/2007 = 09:39:57 <5>[eth0] (4)
Jan/26/2007 = 09:39:57 <3>begin of closure [{] (1)
Jan/26/2007 = 09:39:57 <3>comment [#      = information-only;] (19)
Jan/26/2007 = 09:39:57 <3>[send] (4)
Jan/26/2007 = 09:39:57 <3>[rapid-commit] (12)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 <3>[request] (7)
Jan/26/2007 = 09:39:57 <3>[prefix-delegation] (17)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 <3>comment [#      request = temp-address;] (23)
Jan/26/2007 = 09:39:57 <3>end of closure [}] (1)
Jan/26/2007 = 09:39:57 <3>end of sentence [;] (1)
Jan/26/2007 = 09:39:57 extracted an existing DUID from = /var/lib/dhcpv6/dhcp6c_duid:
00:01:00:01:0d:4b:2e:6d:00:01:02:9d:71:c4
Jan/inters to the discussion. Thanks, Pedro Gonzalez System Test Engineer ITT ACD 77 River Road Clifton, NJ 07014 ************************************ This e-mail and any files transmitted with it are proprietary and intende= d solely for the use of the individual or entity to whom they are addressed. If yo= u have received this e-mail in error please notify the sender. Please note that = any views or opinions presented in this e-mail are solely those of the author and d= o not necessarily represent those of ITT, Inc. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mai= l. ************************************ =0D ------_=_NextPart_001_01C7458A.F12B6B9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PPP and DHCP

Hi,

I was wondering if there was any = information on running DHCP/Ipv4 over PPP links. Is there a way to use = DHCP to configure the IP address of a device on its PPP interface = instead of using IPCP?

I am new to this mailing list. = So, please pardon me if this question has been raised before. In that = case, I'd appreciate any pointers to the discussion.

Thanks,


Pedro Gonzalez
System Test Engineer
ITT ACD
77 River Road
Clifton, NJ 07014 


************************************
This e-mail and any files transmitted with it are proprietary and intende=
d solely
for the use of the individual or entity to whom they are addressed. If yo=
u have
received this e-mail in error please notify the sender. Please note that =
any views
or opinions presented in this e-mail are solely those of the author and d=
o not
necessarily represent those of ITT, Inc. The recipient should check
this e-mail and any attachments for the presence of viruses. ITT accepts
no liability for any damage caused by any virus transmitted by this e-mai=
l.
************************************
=0D
------_=_NextPart_001_01C7458A.F12B6B9C--


--===============0765336403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0765336403==--






26/2007 =
09:39:57 link local addr is fe80::250:daff:fe47:8ff9


Jan/26/2007 =
09:39:57 res addr is fe80::250:daff:fe47:8ff9%eth0/28


Jan/26/2007 =
09:39:57 found an interface eth0 harware bfdeed25


Jan/26/2007 =
09:39:57 interface eth0 iaid failed to be created  







------_=_NextPart_001_01C7448C.8DDB235A--


--===============0271348562==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0271348562==--


From dhcwg-bounces@ietf.org Sat Feb 10 08:26:59 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HFsEn-0008Au-7i; Sat, 10 Feb 2007 08:25:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HCON0-0007J6-9p
	for dhcwg@ietf.org; Wed, 31 Jan 2007 17:56:02 -0500
Received: from chip8og51.obsmtp.com ([64.18.15.175])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HCOMx-0004Ix-W1
	for dhcwg@ietf.org; Wed, 31 Jan 2007 17:56:02 -0500
Received: from source ([151.190.254.200]) by chip8ob51.postini.com
	([64.18.7.12]) with SMTP; Wed, 31 Jan 2007 14:55:59 PST
Received: from fwetgsmtp1.itt.net ([10.32.77.200]) by ittsmtp1 with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:59:32 -0500
Received: from fwdefsmtp2.de.ittind.com ([10.32.77.203]) by fwetgsmtp1.itt.net
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Jan 2007 17:55:46 -0500
Received: from njbridge01.avionics.de.ittind.com ([10.37.1.77]) by
	fwdefsmtp2.de.ittind.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 Jan 2007 17:55:46 -0500
Received: from ACDNJMAILSRV03.acd.de.ittind.com ([10.37.1.152]) by
	njbridge01.avionics.de.ittind.com with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 17:55:46 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 31 Jan 2007 17:55:45 -0500
Message-ID: <56D2E48D28DC3B4EA5F2E4B7679D72F7384A1F@ACDNJMAILSRV03.acd.de.ittind.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PPP and DHCP
Thread-Index: AcdFivGWJevlifBRQJeAbIXBBR0Fcw==
From: "Gonzalez, Pedro - ACD " 
To: 
X-OriginalArrivalTime: 31 Jan 2007 22:55:46.0025 (UTC)
	FILETIME=[F1585590:01C7458A]
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
X-Mailman-Approved-At: Sat, 10 Feb 2007 08:25:54 -0500
Subject: [dhcwg] PPP and DHCP
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0765336403=="
Errors-To: dhcwg-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0765336403==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7458A.F12B6B9C"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7458A.F12B6B9C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I was wondering if there was any information on running DHCP/Ipv4 over
PPP links. Is there a way to use DHCP to configure the IP address of a
device on its PPP interface instead of using IPCP?=20

I am new to this mailing list. So, please pardon me if this question has
been raised before. In that case, I'd appreciate any pointers to the
discussion.

Thanks,


Pedro Gonzalez
System Test Engineer
ITT ACD
77 River Road
Clifton, NJ 07014



************************************
This e-mail and any files transmitted with it are proprietary and intende=
d solely
for the use of the individual or entity to whom they are addressed. If yo=
u have
received this e-mail in error please notify the sender. Please note that =
any views
or opinions presented in this e-mail are solely those of the author and d=
o not
necessarily represent those of ITT, Inc. The recipient should check
this e-mail and any attachments for the presence of viruses. ITT accepts
no liability for any damage caused by any virus transmitted by this e-mai=
l.
************************************
=0D
------_=_NextPart_001_01C7458A.F12B6B9C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






PPP and DHCP





Hi,




I was wondering if there was any =
information on running DHCP/Ipv4 over PPP links. Is there a way to use =
DHCP to configure the IP address of a device on its PPP interface =
instead of using IPCP? 



I am new to this mailing list. =
So, please pardon me if this question has been raised before. In that =
case, I'd appreciate any pointers to the discussion.



Thanks,






Pedro Gonzalez


System Test Engineer


ITT ACD


77 River Road


Clifton, NJ 07014








************************************
This e-mail and any files transmitted with it are proprietary and intende=
d solely
for the use of the individual or entity to whom they are addressed. If yo=
u have
received this e-mail in error please notify the sender. Please note that =
any views
or opinions presented in this e-mail are solely those of the author and d=
o not
necessarily represent those of ITT, Inc. The recipient should check
this e-mail and any attachments for the presence of viruses. ITT accepts
no liability for any damage caused by any virus transmitted by this e-mai=
l.
************************************
=0D
------_=_NextPart_001_01C7458A.F12B6B9C--


--===============0765336403==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0765336403==--






From dhcwg-bounces@ietf.org Sat Feb 10 14:51:03 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HFyEe-0001Xa-T2; Sat, 10 Feb 2007 14:50:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HFyEd-0001X2-0m
	for dhcwg@ietf.org; Sat, 10 Feb 2007 14:50:12 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFyEX-0007R6-Mi
	for dhcwg@ietf.org; Sat, 10 Feb 2007 14:50:11 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id B1BD456821;
	Sat, 10 Feb 2007 11:49:50 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.426,BAYES_99: 3.67,USER_IN_WHITELIST: -30,
	CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -26.756
X-Spam-Level: 
Received: from [10.10.10.127] ([207.114.177.82])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Sat, 10 Feb 2007 11:49:48 -0800
In-Reply-To: <8E296595B6471A4689555D5D725EBB210333ECF6@xmb-rtp-20a.amer.cisco.com>
References: <8E296595B6471A4689555D5D725EBB210333ECF6@xmb-rtp-20a.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes?
Date: Sat, 10 Feb 2007 12:49:30 -0700
To: "Bernie Volz \(volz\)" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 9, 2007, at 5:40 PM, Bernie Volz ((volz)) wrote:
> Second try to solicit some feedback ... write draft or bad idea?

Seems fine.



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



From dhcwg-bounces@ietf.org Sat Feb 10 15:28:41 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HFypN-0003aJ-6o; Sat, 10 Feb 2007 15:28:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HFypL-0003a2-I5
	for dhcwg@ietf.org; Sat, 10 Feb 2007 15:28:07 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFypK-0007JA-9W
	for dhcwg@ietf.org; Sat, 10 Feb 2007 15:28:07 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id ED39C56845;
	Sat, 10 Feb 2007 12:28:05 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.122,BAYES_99: 3.67,USER_IN_WHITELIST: -30,
	CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -26.452
X-Spam-Level: 
Received: from [10.10.10.127] ([207.114.177.82])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Sat, 10 Feb 2007 12:28:05 -0800
In-Reply-To: <45CB0D91.2060605@uninett.no>
References: <45950DDB.3040009@uninett.no> <45B91756.3060909@uninett.no>
	<45CB0D91.2060605@uninett.no>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7C3FE8CF-E67A-4987-AD4B-C1FB549FF512@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-option
	drafts
Date: Sat, 10 Feb 2007 13:27:49 -0700
To: Stig Venaas 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

The way I would prefer to solve this problem is to have the DHCP  
server communicate with the routing system to inject these routes.    
And I would prefer that this *not* be part of the regular DHCP packet  
stream.



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



From dhcwg-bounces@ietf.org Sat Feb 10 15:33:59 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HFyuu-0006QL-Og; Sat, 10 Feb 2007 15:33:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HFyus-0006Py-PA
	for dhcwg@ietf.org; Sat, 10 Feb 2007 15:33:50 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFyur-0008TJ-GC
	for dhcwg@ietf.org; Sat, 10 Feb 2007 15:33:50 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 10 Feb 2007 12:33:49 -0800
X-IronPort-AV: i="4.13,310,1167638400"; 
	d="scan'208"; a="52694665:sNHT43140800"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1AKXnML031257; 
	Sat, 10 Feb 2007 15:33:49 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1AKXmVT028200; 
	Sat, 10 Feb 2007 15:33:49 -0500 (EST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 10 Feb 2007 15:33:48 -0500
Received: from 10.86.242.52 ([10.86.242.52]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Sat, 10 Feb 2007 20:33:47 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Sat, 10 Feb 2007 15:33:47 -0500
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-option
	drafts
From: Ralph Droms 
To: Ted Lemon , Stig Venaas 
Message-ID: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and
	srsn-option drafts
Thread-Index: AcdNUsO9AjEmkrlGEduLywARJOT6eg==
In-Reply-To: <7C3FE8CF-E67A-4987-AD4B-C1FB549FF512@nominum.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 10 Feb 2007 20:33:48.0509 (UTC)
	FILETIME=[C4A408D0:01C74D52]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=596; t=1171139629;
	x=1172003629; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20Re=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele
	gate=20and=20srsn-option=0A=20drafts |Sender:=20
	|To:=20Ted=20Lemon=20,
	=20Stig=20Venaas=20;
	bh=aewJBff72DJZzfUrOyd/kBX79F8zatQZSDicGIgN8FI=;
	b=TxqT08NoQ1SZld3wr9uEwGDv4KuuddjjhXFCSaHjBZLL+sW7D9BgQ6sg0l9nKYj0gpAhPdi9
	mKgElaNX+VZ7sx0bR3z0unHzYLd+HwgZNgNy99ord1biX1nnfkrSrQmG;
Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

How do you propose to arrange for the DHCP server to inject that routing
information, for every possible routing infrastructure deployment?

- Ralph


On 2/10/07 3:27 PM, "Ted Lemon"  wrote:

> The way I would prefer to solve this problem is to have the DHCP
> server communicate with the routing system to inject these routes.
> And I would prefer that this *not* be part of the regular DHCP packet
> stream.
> 
> 
> 
> _______________________________________________
> 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-bounces@ietf.org Sat Feb 10 15:44:59 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HFz51-0006Jo-IK; Sat, 10 Feb 2007 15:44:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HFz4z-0006Jj-Lr
	for dhcwg@ietf.org; Sat, 10 Feb 2007 15:44:17 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFz4y-0001gi-7o
	for dhcwg@ietf.org; Sat, 10 Feb 2007 15:44:17 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id D66AB56845;
	Sat, 10 Feb 2007 12:44:15 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.095,BAYES_99: 3.67,USER_IN_WHITELIST: -30,
	CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -26.425
X-Spam-Level: 
Received: from [10.10.10.127] ([207.114.177.82])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Sat, 10 Feb 2007 12:44:12 -0800
In-Reply-To: <20070208185000.GA2538@isc.org>
References: <200702081506.l18F6vAK018604@scramble.Princeton.EDU>
	<20070208185000.GA2538@isc.org>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <592D02F5-B29A-4596-B0F6-4E6AB6AAF473@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] Re: RFC 2131: can a DHCPv4 client (Mac OS X) transition
	directly from BOUND to INIT then back to BOUND?
Date: Sat, 10 Feb 2007 13:43:54 -0700
To: "David W. Hankins" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 8, 2007, at 11:50 AM, David W. Hankins wrote:
> I have reasons for thinking the author intended for 'operable
> address' to be different from 'unexpired lease.'  Not the least
> of which is the conspicuous choice of words.  'unexpired lease'
> being used in RFC2131 (so, already well understood).

Be careful here.   One issue is that one has leases on IP  
addresses.   The IP address is not a lease.   So you can't say "use  
the lease."   You have to say "use the IP address."   And I think  
that may account for distinction in the wording.   So IMHO you  
shouldn't take the distinction the way you are taking it - to me it  
seems clear that the wording is referring to an IP address on which  
the DHCP client has a valid lease.

Also, bear in mind that before you can send a DHCPOFFER you have to  
ping-test the IP address.   And the expected state is generally that  
the DHCPREQUEST will be ACKed, not ignored.   So in the common case  
it's *faster* to send a DHCPREQUEST, not slower.   It's only if your  
network attachment has *actually* changed that sending the  
DHCPDISCOVER is faster, and even then it's not very fast - many DHCP  
servers wait an entire second for the ping to come back.

I agree that your reading of the RFC casts suspicion on the idea of  
taking a DHCPDISCOVER to mean that the client is no longer holding  
the lease.   However, on the other side, bear in mind that the RFC  
also prohibits the client from responding to an ICMP echo request at  
DHCPDISCOVER time.   Which means that the client *can't* be using the  
IP address.   So while you can say that the DHCP server in question  
is in a grey area, I have a hard time saying its behavior is  
*wrong*.   There are a lot of holes in the draft - a careful  
implementation probably needs to avoid the described behavior, but I  
don't think it's fair to say that the described behavior is actually  
out of compliance.

But what the client is supposedly doing is still definitely not  
correct, at least according to my reading of the two RFCs.   If you  
really think sending a DHCPDISCOVER is faster, you need to do the  
entire handshake.   I suspect that the author of this DHCP client  
didn't account for the echo request delay, and that's why it's timing  
out before it receives a DHCPOFFER.



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



From dhcwg-bounces@ietf.org Sat Feb 10 15:47:31 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HFz81-0000RY-GO; Sat, 10 Feb 2007 15:47:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HFz80-0000RL-8l
	for dhcwg@ietf.org; Sat, 10 Feb 2007 15:47:24 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFz7y-0002Fv-W4
	for dhcwg@ietf.org; Sat, 10 Feb 2007 15:47:24 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id 961EC5682B;
	Sat, 10 Feb 2007 12:47:22 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.077,BAYES_99: 3.67,USER_IN_WHITELIST: -30,
	CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: -26.407
X-Spam-Level: 
Received: from [10.10.10.127] ([207.114.177.82])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Sat, 10 Feb 2007 12:47:20 -0800
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <001EA465-BC43-48EA-86F6-7C7D9EE79C16@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and srsn-option
	drafts
Date: Sat, 10 Feb 2007 13:47:05 -0700
To: Ralph Droms 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 10, 2007, at 1:33 PM, Ralph Droms wrote:
> How do you propose to arrange for the DHCP server to inject that  
> routing
> information, for every possible routing infrastructure deployment?

I don't know enough about routing protocols to say.   But it seems to  
be just as tractable a problem as making sure that edge routers  
inject information into the routing infrastructure, and what I like  
better about it is that it creates a situation where there is only  
one source of routing information that must be trusted, not many.    
If you have all the routers injecting routes, then you have to trust  
them all, and if you have a lot of routers, that creates a security  
and manageability problem.



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



From dhcwg-bounces@ietf.org Sat Feb 10 16:25:03 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HFzhV-0000XM-RO; Sat, 10 Feb 2007 16:24:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HFzhU-0000X6-UY
	for dhcwg@ietf.org; Sat, 10 Feb 2007 16:24:04 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFzhS-0001UP-IW
	for dhcwg@ietf.org; Sat, 10 Feb 2007 16:24:04 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 10 Feb 2007 16:24:02 -0500
X-IronPort-AV: i="4.13,310,1167627600"; 
	d="scan'208"; a="113572485:sNHT60150192"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1ALO20a011620; 
	Sat, 10 Feb 2007 16:24:02 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1ALO4VT005056; 
	Sat, 10 Feb 2007 16:24:05 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 10 Feb 2007 16:24:01 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and
	srsn-optiondrafts
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Sat, 10 Feb 2007 16:23:59 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB210333EDAD@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <001EA465-BC43-48EA-86F6-7C7D9EE79C16@nominum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and
	srsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczg
From: "Bernie Volz \(volz\)" 
To: "Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 10 Feb 2007 21:24:01.0918 (UTC)
	FILETIME=[C8C5C1E0:01C74D59]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3500; t=1171142642;
	x=1172006642; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele
	gate=20and=20srsn-optiondrafts |Sender:=20
	|To:=20=22Ted=20Lemon=22=20,
	=0A=20=20=20=20=20=20=
	20=20=22Ralph=20Droms=20\(rdroms\)=22=20;
	bh=XsTi+rVkEmcJJlsAozU4ZteIiMFdHvAleEW/Hip+69E=;
	b=i9HIul5OcyV+/zpIrFVWJER4/Mm/x9t4AGhRJAZBUccJynM4ER2H/l8A6rHcpsR+FZzYcKfv
	bwntvTzTjpTmYgtbWlPiOQNhKLzfKjjx4CD7OK6uUX8plSNDJWnLfvN6;
Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Ted:

RAAN enables the ability for a trusted router to do the route injection.
For example, in the DOCSIS 3.0 environment you'd have:

HOME NETWORK <--> EROUTER <--> CABLE MODEM <--> CMTS <-+-> DHCP SERVER=20
                                                       |
                                                       |
                                                       +-> Operator
Network/
                                                            Internet

The operator only trusts the CMTS (which is a relay agent) and the DHCP
Server. It can't trust any other components as those are at the
customer's premises.

So, if the EROUTER is delegated prefix, we can't trust it to inject the
routes.

But, the CMTS is trusted. And as it is a relay agent, it can:
- Snoop DHCPv6 packets to gleam the EROUTER's delegated prefix(es).
That's what is presently done for DHCPv4 (this is also done is other
deployments, such as DSL).
- Use RAAN data from the RELAY-REPLY.

The CMTS is already injecting routes into the operator's network. So,
what's wrong with having it inject the additional routes (it after all
is the target router that will deliver packets to the EROUTER).

So, what RAAN does is provide the ability for the server to communicate
to the Relay Agent (CMTS) what to inject.

With RAAN we have one known flaw -- how to handle the case when a
Release's or Decline's Reply (Relay-Reply with RAAN information) fails
to get "back" to the Relay Agent (and client). As the client may not
wait for the Reply, it and the DHCP server may think the delegated
prefix is no longer in use and the DHCP server could assign it to
another client (and perhaps on a completely different relay/router).

With Bidirectional Forwarding Detection (BFD) between the EROUTER and
CMTS, it is possible for the Relay/Router to know when the EROUTER is
down or no longer using a prefix it was delegated. Then, either the
router can stop advertising the route or perform a LeaseQuery to see if
the delegated prefix is still in use by the client.

RAAN is doing what you want -- having the DHCP server inject the routing
information -- but it is doing it through an intermediary; a relay agent
that is a router. If that router is not trusted to inject the
information, that is up to the routing system to handle.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20
Sent: Saturday, February 10, 2007 3:47 PM
To: Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and
srsn-optiondrafts

On Feb 10, 2007, at 1:33 PM, Ralph Droms wrote:
> How do you propose to arrange for the DHCP server to inject that =20
> routing
> information, for every possible routing infrastructure deployment?

I don't know enough about routing protocols to say.   But it seems to =20
be just as tractable a problem as making sure that edge routers =20
inject information into the routing infrastructure, and what I like =20
better about it is that it creates a situation where there is only =20
one source of routing information that must be trusted, not many.   =20
If you have all the routers injecting routes, then you have to trust =20
them all, and if you have a lot of routers, that creates a security =20
and manageability problem.



_______________________________________________
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-bounces@ietf.org Sat Feb 10 21:25:58 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HG4Oc-0001IV-9G; Sat, 10 Feb 2007 21:24:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HG4Ob-0001IP-1U
	for dhcwg@ietf.org; Sat, 10 Feb 2007 21:24:53 -0500
Received: from h216-18-16-189.gtcust.grouptelecom.net ([216.18.16.189]
	helo=zeus.incognito.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HG4OZ-0005Pi-OE
	for dhcwg@ietf.org; Sat, 10 Feb 2007 21:24:53 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate and
	srsn-optiondrafts
Date: Sat, 10 Feb 2007 18:27:49 -0800
Message-ID: <403B5316AD7A254C9024875BAE481D4E610EFF@zeus.incognito.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and
	srsn-optiondrafts
Thread-Index: AcdNUsO9AjEmkrlGEduLywARJOT6egAMWc8g
References: <7C3FE8CF-E67A-4987-AD4B-C1FB549FF512@nominum.com>
	
From: "Andre Kostur" 
To: "Ralph Droms" , "Ted Lemon" ,
	"Stig Venaas" 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Could OSPF/RIP/BGP, or some such similar routing protocol be useful for
this purpose?=20


Regards,
=20
Andre Kostur
Incognito Software Inc.
Senior Software Design Engineer
T: +1(604)678-2864
F: +1(604)688-4339
E: akostur@incognito.com
=20
www.incognito.com

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]=20
Sent: Saturday, February 10, 2007 12:34 PM
To: Ted Lemon; Stig Venaas
Cc: dhcwg
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and
srsn-optiondrafts

How do you propose to arrange for the DHCP server to inject that routing
information, for every possible routing infrastructure deployment?

- Ralph


On 2/10/07 3:27 PM, "Ted Lemon"  wrote:

> The way I would prefer to solve this problem is to have the DHCP=20
> server communicate with the routing system to inject these routes.
> And I would prefer that this *not* be part of the regular DHCP packet=20
> stream.
>=20
>=20
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

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

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



From dhcwg-bounces@ietf.org Sun Feb 11 00:28:48 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HG7FE-0004eW-HZ; Sun, 11 Feb 2007 00:27:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HG7FC-0004eM-Px
	for dhcwg@ietf.org; Sun, 11 Feb 2007 00:27:22 -0500
Received: from mx.isc.org ([2001:4f8:0:2::1c])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG7FC-0000yY-2P
	for dhcwg@ietf.org; Sun, 11 Feb 2007 00:27:22 -0500
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "farside.isc.org", Issuer "ISC CA" (verified OK))
	by mx.isc.org (Postfix) with ESMTP id 96739114025
	for ; Sun, 11 Feb 2007 05:27:01 +0000 (UTC)
	(envelope-from David_Hankins@isc.org)
Received: by farside.isc.org (Postfix, from userid 10200)
	id 434C8E60C8; Sun, 11 Feb 2007 05:27:01 +0000 (UTC)
Date: Sun, 11 Feb 2007 05:27:01 +0000
From: "David W. Hankins" 
To: dhcwg@ietf.org
Subject: Re: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes?
Message-ID: <20070211052701.GB63508@isc.org>
References: <8E296595B6471A4689555D5D725EBB21032ABEB5@xmb-rtp-20a.amer.cisco.com>
	<8E296595B6471A4689555D5D725EBB210333ECF6@xmb-rtp-20a.amer.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8E296595B6471A4689555D5D725EBB210333ECF6@xmb-rtp-20a.amer.cisco.com>
User-Agent: Mutt/1.4.2.1i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Fri, Feb 09, 2007 at 07:40:49PM -0500, Bernie Volz (volz) wrote:
> Second try to solicit some feedback ... write draft or bad idea?

Run the risk of Balkanizing DHCPv6?  Why not.  Might do it some good.

Write the draft, but two comments.  I don't see why it needs
experimental option codes since its uses an enterprise ID in the
packet header...why not just use VSIO?

Second, I don't see why you need a range of experimental message
codes.  We can't predict how many will be neccessary.  Best just
allocate one message, and if a particular enterprise wants multiple
messages, they can do so with their enterprise-id specific
formatting after the break.

Or if some specific use case comes up where multiple message types
are the best way to do it...

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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



From dhcwg-bounces@ietf.org Sun Feb 11 00:49:09 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HG7Zj-0008Nk-NO; Sun, 11 Feb 2007 00:48:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HG7Zi-0008NX-UY
	for dhcwg@ietf.org; Sun, 11 Feb 2007 00:48:34 -0500
Received: from mx.isc.org ([2001:4f8:0:2::1c])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG7Zi-0008LD-2Z
	for dhcwg@ietf.org; Sun, 11 Feb 2007 00:48:34 -0500
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "farside.isc.org", Issuer "ISC CA" (verified OK))
	by mx.isc.org (Postfix) with ESMTP id B24E1114025
	for ; Sun, 11 Feb 2007 05:48:33 +0000 (UTC)
	(envelope-from David_Hankins@isc.org)
Received: by farside.isc.org (Postfix, from userid 10200)
	id 91564E60C7; Sun, 11 Feb 2007 05:48:33 +0000 (UTC)
Date: Sun, 11 Feb 2007 05:48:33 +0000
From: "David W. Hankins" 
To: dhcwg@ietf.org
Subject: Re: [dhcwg] DHCPv6 - Experimental Message (& Option) Codes?
Message-ID: <20070211054833.GC63508@isc.org>
References: <403B5316AD7A254C9024875BAE481D4E610EE5@zeus.incognito.com>
	<8E296595B6471A4689555D5D725EBB210333ED2A@xmb-rtp-20a.amer.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8E296595B6471A4689555D5D725EBB210333ED2A@xmb-rtp-20a.amer.cisco.com>
User-Agent: Mutt/1.4.2.1i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Fri, Feb 09, 2007 at 08:51:18PM -0500, Bernie Volz (volz) wrote:
> Perhaps we should have IANA use a
> random number generator to assign option numbers -- that means the risk
> of a collision is the same as any other number.

In DHCPv4, ISC DHCP used tables of 256 buckets to map option spaces.

So although a lot of DHCPv4 option codes weren't allocated (such as
in the NWIP sub-space, or similar...256 buckets of NWIP sub-options,
of which a dozen were used), we had a lot of "unknown-xxx"'s in
static config in tables in C code.  A frightening number of them.

Quite probably "too many".

Now obviously that doesn't scale for DHCPv6...there are fewer DHCPv6
options than there ever were DHCPv4 options, and the table would be
256 times as large...65536 buckets.  That's just over-the-top waste.

Before we updated software for DHCPv6 (this is in 3.1.0, downloadable
today), we chose to use a method where we only had to enumerate the
codes that were in use, without having to list the gaps inbetween.
The unknown-xxx's became dynamically manufactured upon demand.  This
was somewhat easy for us for the non-intuitive reason that our array
structure already had a field for the option code within each array
bucket (even though the code was also its index into the array), and
existing option-processing software used this field generally.  Without
that field there and in use, I wonder how much we would have had to
rewrite...and hence we might have done this differently.

Because we had another choice, one that we intentionally decided
against.  We could have chosen to simply use a smaller array, merely
adding an upper bounds so that attempts aren't made to check for options
off the end of the array.  For all I know, that might make more sense
in some DHCP software architectures.

In that case, we would have had to make an array that is as big
as the highest numbered option code.  If we assign code 65535
tomorrow...that dooms such an implementation to code rewrites
(or accepting a table that large).


So, random codes work for me, and I'm certainly in favor of giving
people a reason to get their codes allocated properly, but I wonder
if it's too clever...as it may hurt some software implementors.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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



From dhcwg-bounces@ietf.org Sun Feb 11 06:23:12 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGCmt-0004Ou-Ij; Sun, 11 Feb 2007 06:22:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGCms-0004On-Dr
	for dhcwg@ietf.org; Sun, 11 Feb 2007 06:22:30 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGCmb-0006ZB-01
	for dhcwg@ietf.org; Sun, 11 Feb 2007 06:22:30 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2007 06:22:13 -0500
X-IronPort-AV: i="4.13,310,1167627600"; 
	d="scan'208"; a="113594395:sNHT47623596"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1BBMCuP031864; 
	Sun, 11 Feb 2007 06:22:12 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1BBMBOA007018; 
	Sun, 11 Feb 2007 06:22:12 -0500 (EST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sun, 11 Feb 2007 06:22:11 -0500
Received: from 10.61.81.16 ([10.61.81.16]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Sun, 11 Feb 2007 11:22:10 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Sun, 11 Feb 2007 06:22:13 -0500
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and
	srsn-optiondrafts
From: Ralph Droms 
To: Andre Kostur , Ted Lemon ,
	Stig Venaas 
Message-ID: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate and
	srsn-optiondrafts
Thread-Index: AcdNUsO9AjEmkrlGEduLywARJOT6egAMWc8gABKtZyc=
In-Reply-To: <403B5316AD7A254C9024875BAE481D4E610EFF@zeus.incognito.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 11 Feb 2007 11:22:11.0862 (UTC)
	FILETIME=[DFEA3B60:01C74DCE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1774; t=1171192932;
	x=1172056932; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20Re=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele
	gate=20and=0A=20srsn-optiondrafts |Sender:=20
	|To:=20Andre=20Kostur=20,
	=20Ted=20Lemon=20,
	=0A=20=20=20=20=20=20=20=20Stig=20Venaas=20; bh=daXLTx2ixJnaOjulz9/kfzJn9J0TjDzg3o7olvyv1h8=;
	b=NeWznO/XdNSO9i00igfzrbyaWP/AGTDo0Eni7kmh9VGYm5Mifh6O9F4bUN4PHWHWnUcTi9f7
	CzIS6+N/CbNovCXd5Xt4gCzp4aRhMDvzB2oepQHgrnR7MYwFO6rR3Qrl;
Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Sure ... It *might* be useful.  But, I think we would need to show at least
an existence proof for how the DHCP server could inject routing into *any*
routing infrastructure.  We can't expect a network that has ISIS deployed to
also deploy OSPF in parallel with an ISIS-OSPF gayeway if we specify OSPF as
the way for a DHCPv6 server to inject routing information.

- Ralph


On 2/10/07 9:27 PM, "Andre Kostur"  wrote:

> Could OSPF/RIP/BGP, or some such similar routing protocol be useful for
> this purpose? 
> 
> 
> Regards,
>  
> Andre Kostur
> Incognito Software Inc.
> Senior Software Design Engineer
> T: +1(604)678-2864
> F: +1(604)688-4339
> E: akostur@incognito.com
>  
> www.incognito.com
> 
> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Saturday, February 10, 2007 12:34 PM
> To: Ted Lemon; Stig Venaas
> Cc: dhcwg
> Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and
> srsn-optiondrafts
> 
> How do you propose to arrange for the DHCP server to inject that routing
> information, for every possible routing infrastructure deployment?
> 
> - Ralph
> 
> 
> On 2/10/07 3:27 PM, "Ted Lemon"  wrote:
> 
>> The way I would prefer to solve this problem is to have the DHCP
>> server communicate with the routing system to inject these routes.
>> And I would prefer that this *not* be part of the regular DHCP packet
>> stream.
>> 
>> 
>> 
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

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



From dhcwg-bounces@ietf.org Sun Feb 11 06:50:59 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGDE2-0003OO-90; Sun, 11 Feb 2007 06:50:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGDE1-0003L5-AQ
	for dhcwg@ietf.org; Sun, 11 Feb 2007 06:50:33 -0500
Received: from tyholt.uninett.no ([2001:700:1::eecb])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGDDp-0002px-LH
	for dhcwg@ietf.org; Sun, 11 Feb 2007 06:50:33 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tyholt.uninett.no (Postfix) with ESMTP id 392E8B5B1A;
	Sun, 11 Feb 2007 12:50:02 +0100 (CET)
Received: from tyholt.uninett.no ([127.0.0.1])
	by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 14772-02-2; Sun, 11 Feb 2007 12:50:02 +0100 (CET)
Received: from [IPv6?2001?700?1?1100?6046?347d?55f2?23c5] (unknown
	[IPv6:2001:700:1:1100:6046:347d:55f2:23c5])
	by tyholt.uninett.no (Postfix) with ESMTP id A39F3B5B19;
	Sun, 11 Feb 2007 12:50:01 +0100 (CET)
Message-ID: <45CEA585.8090106@uninett.no>
Date: Sun, 11 Feb 2007 06:11:33 +0100
From: Stig Venaas 
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
MIME-Version: 1.0
To: Ralph Droms 
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate
	and	srsn-optiondrafts
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no
X-Spam-Score: -2.6 (--)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: dhcwg , Andre Kostur ,
	Ted Lemon 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Ralph Droms wrote:
> Sure ... It *might* be useful.  But, I think we would need to show at least
> an existence proof for how the DHCP server could inject routing into *any*
> routing infrastructure.  We can't expect a network that has ISIS deployed to
> also deploy OSPF in parallel with an ISIS-OSPF gayeway if we specify OSPF as
> the way for a DHCPv6 server to inject routing information.

You can't generally inject a route into the routing infrastructure
specifying that the next-hop is someone else. Although I believe
OSPF supports this.

Another issue is that the DHCP server won't know whether the link to the
customer is up. If the link is down it may be best not to advertise the
route.

Stig

> 
> - Ralph
> 
> 
> On 2/10/07 9:27 PM, "Andre Kostur"  wrote:
> 
>> Could OSPF/RIP/BGP, or some such similar routing protocol be useful for
>> this purpose? 
>>
>>
>> Regards,
>>  
>> Andre Kostur
>> Incognito Software Inc.
>> Senior Software Design Engineer
>> T: +1(604)678-2864
>> F: +1(604)688-4339
>> E: akostur@incognito.com
>>  
>> www.incognito.com
>>
>> -----Original Message-----
>> From: Ralph Droms [mailto:rdroms@cisco.com]
>> Sent: Saturday, February 10, 2007 12:34 PM
>> To: Ted Lemon; Stig Venaas
>> Cc: dhcwg
>> Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and
>> srsn-optiondrafts
>>
>> How do you propose to arrange for the DHCP server to inject that routing
>> information, for every possible routing infrastructure deployment?
>>
>> - Ralph
>>
>>
>> On 2/10/07 3:27 PM, "Ted Lemon"  wrote:
>>
>>> The way I would prefer to solve this problem is to have the DHCP
>>> server communicate with the routing system to inject these routes.
>>> And I would prefer that this *not* be part of the regular DHCP packet
>>> stream.
>>>
>>>
>>>
>>> _______________________________________________
>>> dhcwg mailing list
>>> dhcwg@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg


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



From dhcwg-bounces@ietf.org Mon Feb 12 09:58:59 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGcd9-0004r9-5b; Mon, 12 Feb 2007 09:58:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGcd7-0004r1-DZ
	for dhcwg@ietf.org; Mon, 12 Feb 2007 09:58:09 -0500
Received: from stl-smtpout-01.boeing.com ([130.76.96.56]
	helo=stl-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGcd1-0006hT-3x
	for dhcwg@ietf.org; Mon, 12 Feb 2007 09:58:09 -0500
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4])
	by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1CEvrEQ001305
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 12 Feb 2007 08:57:54 -0600 (CST)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1CEvr4L001701; Mon, 12 Feb 2007 06:57:53 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1CEvhG9001507; Mon, 12 Feb 2007 06:57:52 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Feb 2007 06:57:48 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-optiondrafts
Date: Mon, 12 Feb 2007 06:57:47 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017746AF@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB210333EDAD@xmb-rtp-20a.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate
	andsrsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczgAFdIJqA=
References: <001EA465-BC43-48EA-86F6-7C7D9EE79C16@nominum.com>
	<8E296595B6471A4689555D5D725EBB210333EDAD@xmb-rtp-20a.amer.cisco.com>
From: "Templin, Fred L" 
To: "Bernie Volz \(volz\)" ,
	"Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 12 Feb 2007 14:57:48.0270 (UTC)
	FILETIME=[290730E0:01C74EB6]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

> The CMTS is already injecting routes into the operator's network. So,
> what's wrong with having it inject the additional routes (it after all
> is the target router that will deliver packets to the EROUTER).
>=20
> So, what RAAN does is provide the ability for the server to=20
> communicate
> to the Relay Agent (CMTS) what to inject.

Right, and another use case is one in which the server informs
the relay about address/prefix delegations but the relay only=20
keeps the knowledge to itself and does *not* inject any routes
(draft-templin-autoconf-netlmm-dhcp).

> With RAAN we have one known flaw -- how to handle the case when a
> Release's or Decline's Reply (Relay-Reply with RAAN information) fails
> to get "back" to the Relay Agent (and client). As the client may not
> wait for the Reply, it and the DHCP server may think the delegated
> prefix is no longer in use and the DHCP server could assign it to
> another client (and perhaps on a completely different relay/router).

And, one solution is to have the server explicitly inform the
relay of addresses/prefixes that have been released. This works
if the relay also configures a client.

> With Bidirectional Forwarding Detection (BFD) between the EROUTER and
> CMTS, it is possible for the Relay/Router to know when the EROUTER is
> down or no longer using a prefix it was delegated. Then, either the
> router can stop advertising the route or perform a LeaseQuery=20
> to see if
> the delegated prefix is still in use by the client.

How would this work if the EROUTER has been delegated multiple
prefixes and only releases a few of them? The EROUTER could
still appear to be up according to BFD, but defunct prefixes
might go unnoticed.=20

Fred
fred.l.templin@boeing.com

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



From dhcwg-bounces@ietf.org Mon Feb 12 10:37:58 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGdEw-0002MF-4g; Mon, 12 Feb 2007 10:37:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGdEu-0002M7-Pv
	for dhcwg@ietf.org; Mon, 12 Feb 2007 10:37:12 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGdEt-0000Oh-Bn
	for dhcwg@ietf.org; Mon, 12 Feb 2007 10:37:12 -0500
Received: from sj-dkim-6.cisco.com ([171.68.10.81])
	by sj-iport-5.cisco.com with ESMTP; 12 Feb 2007 07:37:10 -0800
X-IronPort-AV: i="4.13,314,1167638400"; 
	d="scan'208"; a="388178292:sNHT64582412"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l1CFbA7d010315; 
	Mon, 12 Feb 2007 07:37:10 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1CFaki0019963;
	Mon, 12 Feb 2007 07:37:03 -0800 (PST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Feb 2007 10:36:53 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-optiondrafts
Date: Mon, 12 Feb 2007 10:36:52 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB210333EFE8@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017746AF@XCH-NW-7V2.nw.nos.boeing.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate
	andsrsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczgAFdIJqAAAcquwA==
From: "Bernie Volz \(volz\)" 
To: "Templin, Fred L" ,
	"Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 12 Feb 2007 15:36:53.0326 (UTC)
	FILETIME=[9ECA56E0:01C74EBB]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3475; t=1171294630;
	x=1172158630; c=relaxed/simple; s=sjdkim6002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele
	gate=20andsrsn-optiondrafts |Sender:=20;
	bh=z6GcsoffBeIZ5/+pKK5JuQs5me1TXJea5jQ4f8R2S2E=;
	b=QCo+8cYSaT4HdGeG0rkiftNOs6LWAoqiBIG0qMeTUG03YflMApNcg9tS/bkTb5mj+caCvgR8
	X7cqJGKDi+JFGEgCWJe8G/esovuLsLk3SYR9WcJwsorZL6ugB/X8C1Rp;
Authentication-Results: sj-dkim-6; header.From=volz@cisco.com; dkim=pass (si
	g from cisco.com/sjdkim6002 verified; ); 
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

>And, one solution is to have the server explicitly inform the
>relay of addresses/prefixes that have been released. This works
>if the relay also configures a client.
=20
That was the point of RAAN ... But there is the issue for these
Release/Decline messages as the client may not care about the Reply and
retransmit them; hence the notification is flawed.

Perhaps we could add DHCPv6 messages between server and relay-agent that
would do this communication instead of piggybacking the RAAN data on the
Relay-Reply/Reply. The Server would send a RAAN message and retransmit
until it got a RAAN-Reply. The Relay-Forw could request the RAAN. (There
is still the case of what to do if the server's retransmissions go
unanswered, but at some point it would give up assuming the Relay was
down.)

These RAAN/RAAN-Reply messages could be relayed (to support relay
chaining in case there is another relay between the CMTS and server).
This information comes from the original relayed packet.

>How would this work if the EROUTER has been delegated multiple
>prefixes and only releases a few of them? The EROUTER could
>still appear to be up according to BFD, but defunct prefixes
>might go unnoticed.=20

That is certainly an issue to investigate. I'm not sure how BFD or other
techniques used by routers (or proposed to be used by routers) would
handle this.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
Sent: Monday, February 12, 2007 9:58 AM
To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
andsrsn-optiondrafts

> The CMTS is already injecting routes into the operator's network. So,
> what's wrong with having it inject the additional routes (it after all
> is the target router that will deliver packets to the EROUTER).
>=20
> So, what RAAN does is provide the ability for the server to=20
> communicate
> to the Relay Agent (CMTS) what to inject.

Right, and another use case is one in which the server informs
the relay about address/prefix delegations but the relay only=20
keeps the knowledge to itself and does *not* inject any routes
(draft-templin-autoconf-netlmm-dhcp).

> With RAAN we have one known flaw -- how to handle the case when a
> Release's or Decline's Reply (Relay-Reply with RAAN information) fails
> to get "back" to the Relay Agent (and client). As the client may not
> wait for the Reply, it and the DHCP server may think the delegated
> prefix is no longer in use and the DHCP server could assign it to
> another client (and perhaps on a completely different relay/router).

And, one solution is to have the server explicitly inform the
relay of addresses/prefixes that have been released. This works
if the relay also configures a client.

> With Bidirectional Forwarding Detection (BFD) between the EROUTER and
> CMTS, it is possible for the Relay/Router to know when the EROUTER is
> down or no longer using a prefix it was delegated. Then, either the
> router can stop advertising the route or perform a LeaseQuery=20
> to see if
> the delegated prefix is still in use by the client.

How would this work if the EROUTER has been delegated multiple
prefixes and only releases a few of them? The EROUTER could
still appear to be up according to BFD, but defunct prefixes
might go unnoticed.=20

Fred
fred.l.templin@boeing.com

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



From dhcwg-bounces@ietf.org Mon Feb 12 11:38:35 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGeBR-0002NG-Pt; Mon, 12 Feb 2007 11:37:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGeBQ-0002NA-HQ
	for dhcwg@ietf.org; Mon, 12 Feb 2007 11:37:40 -0500
Received: from slb-smtpout-01.boeing.com ([130.76.64.48]
	helo=slb-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGeBO-0005XV-0t
	for dhcwg@ietf.org; Mon, 12 Feb 2007 11:37:40 -0500
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6])
	by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1CGbaup028640
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 12 Feb 2007 08:37:36 -0800 (PST)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1CGbafC002160; Mon, 12 Feb 2007 10:37:36 -0600 (CST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1CGbUdQ001943; Mon, 12 Feb 2007 10:37:35 -0600 (CST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Feb 2007 08:37:34 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-optiondrafts
Date: Mon, 12 Feb 2007 08:37:33 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017746B0@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB210333EFE8@xmb-rtp-20a.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate
	andsrsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczgAFdIJqAAAcquwAABk6pA
References: <39C363776A4E8C4A94691D2BD9D1C9A1017746AF@XCH-NW-7V2.nw.nos.boeing.com>
	<8E296595B6471A4689555D5D725EBB210333EFE8@xmb-rtp-20a.amer.cisco.com>
From: "Templin, Fred L" 
To: "Bernie Volz \(volz\)" ,
	"Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 12 Feb 2007 16:37:34.0208 (UTC)
	FILETIME=[18ECD800:01C74EC4]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Bernie,=20

> >And, one solution is to have the server explicitly inform the
> >relay of addresses/prefixes that have been released. This works
> >if the relay also configures a client.
> =20
> That was the point of RAAN ... But there is the issue for these
> Release/Decline messages as the client may not care about the=20
> Reply and
> retransmit them; hence the notification is flawed.

Yes, I think I understand the issue. What we are proposing is
that there be *two* clients - client A on the requesting router
(i.e., the "true" client) and client B on the relay agent. RAAN
options are ordinarily passed in-band on the messages from the
server to client A. But, when the server recognizes that
client A might disengate prematurely from its normal reliable
exchange (e.g., for Release and Decline) it sends its normal
replies to client A but also does an out-of-band reliable
exchange with client B so that client B is assured of getting
the RAAN options.

Note that this approach is necessary not only for clients
on requesting routers that don't complete the reliable
exchange, but also for clients that disappear from the link
unbeknownst to the relay agent (but known to the server).=20
=20
> Perhaps we could add DHCPv6 messages between server and=20
> relay-agent that
> would do this communication instead of piggybacking the RAAN=20
> data on the
> Relay-Reply/Reply.

That's what we're saying.

> The Server would send a RAAN message and retransmit
> until it got a RAAN-Reply. The Relay-Forw could request the=20
> RAAN. (There
> is still the case of what to do if the server's retransmissions go
> unanswered, but at some point it would give up assuming the Relay was
> down.)

What we are proposing is:

  1) Server sends Reconfigure to client B
  2) Client B sends Information-Request to server
  3) server sends Information-Reply to client B with RAAN
     options.

> These RAAN/RAAN-Reply messages could be relayed (to support relay
> chaining in case there is another relay between the CMTS and server).
> This information comes from the original relayed packet.

That's fine; it would just mean that client B would have to
reside on the relay furthest from the server, i.e., the one
on the same link as client A.

> >How would this work if the EROUTER has been delegated multiple
> >prefixes and only releases a few of them? The EROUTER could
> >still appear to be up according to BFD, but defunct prefixes
> >might go unnoticed.=20
>=20
> That is certainly an issue to investigate. I'm not sure how=20
> BFD or other
> techniques used by routers (or proposed to be used by routers) would
> handle this.

OK. The other concern is that the BFD exchanges might not be
desireable on bandwidth-constrained links like wireless.
=20
Fred
fred.l.templin@boeing.com

> - Bernie
>=20
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
> Sent: Monday, February 12, 2007 9:58 AM
> To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
> Cc: dhcwg; Stig Venaas
> Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
> andsrsn-optiondrafts
>=20
> > The CMTS is already injecting routes into the operator's=20
> network. So,
> > what's wrong with having it inject the additional routes=20
> (it after all
> > is the target router that will deliver packets to the EROUTER).
> >=20
> > So, what RAAN does is provide the ability for the server to=20
> > communicate
> > to the Relay Agent (CMTS) what to inject.
>=20
> Right, and another use case is one in which the server informs
> the relay about address/prefix delegations but the relay only=20
> keeps the knowledge to itself and does *not* inject any routes
> (draft-templin-autoconf-netlmm-dhcp).
>=20
> > With RAAN we have one known flaw -- how to handle the case when a
> > Release's or Decline's Reply (Relay-Reply with RAAN=20
> information) fails
> > to get "back" to the Relay Agent (and client). As the client may not
> > wait for the Reply, it and the DHCP server may think the delegated
> > prefix is no longer in use and the DHCP server could assign it to
> > another client (and perhaps on a completely different relay/router).
>=20
> And, one solution is to have the server explicitly inform the
> relay of addresses/prefixes that have been released. This works
> if the relay also configures a client.
>=20
> > With Bidirectional Forwarding Detection (BFD) between the=20
> EROUTER and
> > CMTS, it is possible for the Relay/Router to know when the=20
> EROUTER is
> > down or no longer using a prefix it was delegated. Then, either the
> > router can stop advertising the route or perform a LeaseQuery=20
> > to see if
> > the delegated prefix is still in use by the client.
>=20
> How would this work if the EROUTER has been delegated multiple
> prefixes and only releases a few of them? The EROUTER could
> still appear to be up according to BFD, but defunct prefixes
> might go unnoticed.=20
>=20
> Fred
> fred.l.templin@boeing.com
>=20

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



From dhcwg-bounces@ietf.org Mon Feb 12 11:50:46 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGeNr-0001zi-Li; Mon, 12 Feb 2007 11:50:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGeNq-0001zG-02
	for dhcwg@ietf.org; Mon, 12 Feb 2007 11:50:30 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGeNl-0008C7-Kr
	for dhcwg@ietf.org; Mon, 12 Feb 2007 11:50:29 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 12 Feb 2007 11:50:25 -0500
X-IronPort-AV: i="4.13,314,1167627600"; 
	d="scan'208"; a="113669751:sNHT86047436"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1CGoP18026006; 
	Mon, 12 Feb 2007 11:50:25 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1CGoOOA002548; 
	Mon, 12 Feb 2007 11:50:25 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Feb 2007 11:50:24 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-optiondrafts
Date: Mon, 12 Feb 2007 11:50:24 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB21033F054F@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017746B0@XCH-NW-7V2.nw.nos.boeing.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate
	andsrsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczgAFdIJqAAAcquwAABk6pAAADpRgA=
From: "Bernie Volz \(volz\)" 
To: "Templin, Fred L" ,
	"Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 12 Feb 2007 16:50:24.0639 (UTC)
	FILETIME=[E42348F0:01C74EC5]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6300; t=1171299025;
	x=1172163025; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele
	gate=20andsrsn-optiondrafts |Sender:=20
	|To:=20=22Templin, =20Fred=20L=22=20,
	=0A=20=20=
	20=20=20=20=20=20=22Ted=20Lemon=22=20,
	=0A=20=20=20=
	20=20=20=20=20=22Ralph=20Droms=20\(rdroms\)=22=20;
	bh=ysw3+GQfuZV2OhuivBKkaieRoZ2UsspRQMmPPqI71W0=;
	b=blpzi4/wvpW1T8AG6xYSQsQ7MynD4Aa4EhJ2dkPSkjylBgkGgYAVKqbXs2bVlRIOwfveMwi3
	kvRUWAt6luMB9SE6tFYEjktsquwmP1ZBc4ZVmi2Am89YxYMi6e+ik0Qj;
Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Fred:

I think we're proposing completely different things.

If I understand your model, it is (using DOCSIS as a model) that the
relay agent (CMTS) is actually a server to the client (eRouter) and also
a client to the "real" DHCPv6 server. I am NOT propsoing that model.
While that model could be used to solve these issues, it creates a lot
of other issues (such as greater complexity in the relay as it is a
DHCPv6 server and client and Authentication is greatly complicated). I
don't like that model.

What I was suggesting is different. It is that rather than sending the
RAAN data piggybacked in the traffic going back to the client, there be
explicit (and *NEW*) messages between the server and relay to inform the
relay of the client changes. This allows for a more reliable
communication between the server and relay, especially in the case of
Release/Decline messages.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
Sent: Monday, February 12, 2007 11:38 AM
To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
andsrsn-optiondrafts

Bernie,=20

> >And, one solution is to have the server explicitly inform the
> >relay of addresses/prefixes that have been released. This works
> >if the relay also configures a client.
> =20
> That was the point of RAAN ... But there is the issue for these
> Release/Decline messages as the client may not care about the=20
> Reply and
> retransmit them; hence the notification is flawed.

Yes, I think I understand the issue. What we are proposing is
that there be *two* clients - client A on the requesting router
(i.e., the "true" client) and client B on the relay agent. RAAN
options are ordinarily passed in-band on the messages from the
server to client A. But, when the server recognizes that
client A might disengate prematurely from its normal reliable
exchange (e.g., for Release and Decline) it sends its normal
replies to client A but also does an out-of-band reliable
exchange with client B so that client B is assured of getting
the RAAN options.

Note that this approach is necessary not only for clients
on requesting routers that don't complete the reliable
exchange, but also for clients that disappear from the link
unbeknownst to the relay agent (but known to the server).=20
=20
> Perhaps we could add DHCPv6 messages between server and=20
> relay-agent that
> would do this communication instead of piggybacking the RAAN=20
> data on the
> Relay-Reply/Reply.

That's what we're saying.

> The Server would send a RAAN message and retransmit
> until it got a RAAN-Reply. The Relay-Forw could request the=20
> RAAN. (There
> is still the case of what to do if the server's retransmissions go
> unanswered, but at some point it would give up assuming the Relay was
> down.)

What we are proposing is:

  1) Server sends Reconfigure to client B
  2) Client B sends Information-Request to server
  3) server sends Information-Reply to client B with RAAN
     options.

> These RAAN/RAAN-Reply messages could be relayed (to support relay
> chaining in case there is another relay between the CMTS and server).
> This information comes from the original relayed packet.

That's fine; it would just mean that client B would have to
reside on the relay furthest from the server, i.e., the one
on the same link as client A.

> >How would this work if the EROUTER has been delegated multiple
> >prefixes and only releases a few of them? The EROUTER could
> >still appear to be up according to BFD, but defunct prefixes
> >might go unnoticed.=20
>=20
> That is certainly an issue to investigate. I'm not sure how=20
> BFD or other
> techniques used by routers (or proposed to be used by routers) would
> handle this.

OK. The other concern is that the BFD exchanges might not be
desireable on bandwidth-constrained links like wireless.
=20
Fred
fred.l.templin@boeing.com

> - Bernie
>=20
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
> Sent: Monday, February 12, 2007 9:58 AM
> To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
> Cc: dhcwg; Stig Venaas
> Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
> andsrsn-optiondrafts
>=20
> > The CMTS is already injecting routes into the operator's=20
> network. So,
> > what's wrong with having it inject the additional routes=20
> (it after all
> > is the target router that will deliver packets to the EROUTER).
> >=20
> > So, what RAAN does is provide the ability for the server to=20
> > communicate
> > to the Relay Agent (CMTS) what to inject.
>=20
> Right, and another use case is one in which the server informs
> the relay about address/prefix delegations but the relay only=20
> keeps the knowledge to itself and does *not* inject any routes
> (draft-templin-autoconf-netlmm-dhcp).
>=20
> > With RAAN we have one known flaw -- how to handle the case when a
> > Release's or Decline's Reply (Relay-Reply with RAAN=20
> information) fails
> > to get "back" to the Relay Agent (and client). As the client may not
> > wait for the Reply, it and the DHCP server may think the delegated
> > prefix is no longer in use and the DHCP server could assign it to
> > another client (and perhaps on a completely different relay/router).
>=20
> And, one solution is to have the server explicitly inform the
> relay of addresses/prefixes that have been released. This works
> if the relay also configures a client.
>=20
> > With Bidirectional Forwarding Detection (BFD) between the=20
> EROUTER and
> > CMTS, it is possible for the Relay/Router to know when the=20
> EROUTER is
> > down or no longer using a prefix it was delegated. Then, either the
> > router can stop advertising the route or perform a LeaseQuery=20
> > to see if
> > the delegated prefix is still in use by the client.
>=20
> How would this work if the EROUTER has been delegated multiple
> prefixes and only releases a few of them? The EROUTER could
> still appear to be up according to BFD, but defunct prefixes
> might go unnoticed.=20
>=20
> Fred
> fred.l.templin@boeing.com
>=20

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



From dhcwg-bounces@ietf.org Mon Feb 12 12:20:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGeqa-0001sS-MW; Mon, 12 Feb 2007 12:20:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGeqU-0001mT-1t
	for dhcwg@ietf.org; Mon, 12 Feb 2007 12:20:06 -0500
Received: from blv-smtpout-01.boeing.com ([130.76.32.69]
	helo=blv-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGenR-0006Kd-4O
	for dhcwg@ietf.org; Mon, 12 Feb 2007 12:16:59 -0500
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216])
	by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1CHGtj5007993
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Mon, 12 Feb 2007 09:16:56 -0800 (PST)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1CHGtvD005058; Mon, 12 Feb 2007 09:16:55 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1CHGkgu004828; Mon, 12 Feb 2007 09:16:55 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Feb 2007 09:16:54 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-optiondrafts
Date: Mon, 12 Feb 2007 09:16:53 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017746B1@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB21033F054F@xmb-rtp-20a.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate
	andsrsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczgAFdIJqAAAcquwAABk6pAAADpRgAAALyYYA==
References: <39C363776A4E8C4A94691D2BD9D1C9A1017746B0@XCH-NW-7V2.nw.nos.boeing.com>
	<8E296595B6471A4689555D5D725EBB21033F054F@xmb-rtp-20a.amer.cisco.com>
From: "Templin, Fred L" 
To: "Bernie Volz \(volz\)" ,
	"Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 12 Feb 2007 17:16:54.0067 (UTC)
	FILETIME=[9782C030:01C74EC9]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

> I think we're proposing completely different things.
>=20
> If I understand your model, it is (using DOCSIS as a model) that the
> relay agent (CMTS) is actually a server to the client (eRouter)

No!

> and also a client to the "real" DHCPv6 server.

Yes!

> It is that rather than sending the
> RAAN data piggybacked in the traffic going back to the=20
> client, there be
> explicit (and *NEW*) messages between the server and relay to=20
> inform the
> relay of the client changes.

Explicit - yes; *NEW* - no. We already have
Reconfig/Info-Req/Info-Rep that the server can use to tell
a client function running on the same box as the relay agent
about the RAANs that might not otherwise get back to the
client. I have been asking for the relay agent box to also
configure a client for this purpose because it fits with the
current DHCP model in which the client function is responsible
for reliable exchanges - otherwise, I would have asked for the
DHCP model to be altered such that the server could engage in
a reliable exchange with a bare relay agent. (I could dig up
some old e-mails if necessary to show that we already explored
this angle.)

Fred
fred.l.templin@boeing.com

> This allows for a more reliable
> communication between the server and relay, especially in the case of
> Release/Decline messages.
>=20
> - Bernie
>=20
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
> Sent: Monday, February 12, 2007 11:38 AM
> To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
> Cc: dhcwg; Stig Venaas
> Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
> andsrsn-optiondrafts
>=20
> Bernie,=20
>=20
> > >And, one solution is to have the server explicitly inform the
> > >relay of addresses/prefixes that have been released. This works
> > >if the relay also configures a client.
> > =20
> > That was the point of RAAN ... But there is the issue for these
> > Release/Decline messages as the client may not care about the=20
> > Reply and
> > retransmit them; hence the notification is flawed.
>=20
> Yes, I think I understand the issue. What we are proposing is
> that there be *two* clients - client A on the requesting router
> (i.e., the "true" client) and client B on the relay agent. RAAN
> options are ordinarily passed in-band on the messages from the
> server to client A. But, when the server recognizes that
> client A might disengate prematurely from its normal reliable
> exchange (e.g., for Release and Decline) it sends its normal
> replies to client A but also does an out-of-band reliable
> exchange with client B so that client B is assured of getting
> the RAAN options.
>=20
> Note that this approach is necessary not only for clients
> on requesting routers that don't complete the reliable
> exchange, but also for clients that disappear from the link
> unbeknownst to the relay agent (but known to the server).=20
> =20
> > Perhaps we could add DHCPv6 messages between server and=20
> > relay-agent that
> > would do this communication instead of piggybacking the RAAN=20
> > data on the
> > Relay-Reply/Reply.
>=20
> That's what we're saying.
>=20
> > The Server would send a RAAN message and retransmit
> > until it got a RAAN-Reply. The Relay-Forw could request the=20
> > RAAN. (There
> > is still the case of what to do if the server's retransmissions go
> > unanswered, but at some point it would give up assuming the=20
> Relay was
> > down.)
>=20
> What we are proposing is:
>=20
>   1) Server sends Reconfigure to client B
>   2) Client B sends Information-Request to server
>   3) server sends Information-Reply to client B with RAAN
>      options.
>=20
> > These RAAN/RAAN-Reply messages could be relayed (to support relay
> > chaining in case there is another relay between the CMTS=20
> and server).
> > This information comes from the original relayed packet.
>=20
> That's fine; it would just mean that client B would have to
> reside on the relay furthest from the server, i.e., the one
> on the same link as client A.
>=20
> > >How would this work if the EROUTER has been delegated multiple
> > >prefixes and only releases a few of them? The EROUTER could
> > >still appear to be up according to BFD, but defunct prefixes
> > >might go unnoticed.=20
> >=20
> > That is certainly an issue to investigate. I'm not sure how=20
> > BFD or other
> > techniques used by routers (or proposed to be used by routers) would
> > handle this.
>=20
> OK. The other concern is that the BFD exchanges might not be
> desireable on bandwidth-constrained links like wireless.
> =20
> Fred
> fred.l.templin@boeing.com
>=20
> > - Bernie
> >=20
> > -----Original Message-----
> > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
> > Sent: Monday, February 12, 2007 9:58 AM
> > To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
> > Cc: dhcwg; Stig Venaas
> > Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
> > andsrsn-optiondrafts
> >=20
> > > The CMTS is already injecting routes into the operator's=20
> > network. So,
> > > what's wrong with having it inject the additional routes=20
> > (it after all
> > > is the target router that will deliver packets to the EROUTER).
> > >=20
> > > So, what RAAN does is provide the ability for the server to=20
> > > communicate
> > > to the Relay Agent (CMTS) what to inject.
> >=20
> > Right, and another use case is one in which the server informs
> > the relay about address/prefix delegations but the relay only=20
> > keeps the knowledge to itself and does *not* inject any routes
> > (draft-templin-autoconf-netlmm-dhcp).
> >=20
> > > With RAAN we have one known flaw -- how to handle the case when a
> > > Release's or Decline's Reply (Relay-Reply with RAAN=20
> > information) fails
> > > to get "back" to the Relay Agent (and client). As the=20
> client may not
> > > wait for the Reply, it and the DHCP server may think the delegated
> > > prefix is no longer in use and the DHCP server could assign it to
> > > another client (and perhaps on a completely different=20
> relay/router).
> >=20
> > And, one solution is to have the server explicitly inform the
> > relay of addresses/prefixes that have been released. This works
> > if the relay also configures a client.
> >=20
> > > With Bidirectional Forwarding Detection (BFD) between the=20
> > EROUTER and
> > > CMTS, it is possible for the Relay/Router to know when the=20
> > EROUTER is
> > > down or no longer using a prefix it was delegated. Then,=20
> either the
> > > router can stop advertising the route or perform a LeaseQuery=20
> > > to see if
> > > the delegated prefix is still in use by the client.
> >=20
> > How would this work if the EROUTER has been delegated multiple
> > prefixes and only releases a few of them? The EROUTER could
> > still appear to be up according to BFD, but defunct prefixes
> > might go unnoticed.=20
> >=20
> > Fred
> > fred.l.templin@boeing.com
> >=20
>=20

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



From dhcwg-bounces@ietf.org Mon Feb 12 14:27:48 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGgpF-0001Uu-UT; Mon, 12 Feb 2007 14:26:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGgpE-0001Um-U6
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:26:56 -0500
Received: from goliath.isc.org ([2001:4f8:3:bb::72])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGgpE-0000rU-2d
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:26:56 -0500
Received: by goliath.isc.org (Postfix, from userid 10200)
	id 788AB7D2D; Mon, 12 Feb 2007 11:26:39 -0800 (PST)
Date: Mon, 12 Feb 2007 11:26:39 -0800
From: "David W. Hankins" 
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Re: RFC 2131: can a DHCPv4 client (Mac OS X) transition
	directly from BOUND to INIT then back to BOUND?
Message-ID: <20070212192639.GB8408@isc.org>
References: <200702081506.l18F6vAK018604@scramble.Princeton.EDU>
	<20070208185000.GA2538@isc.org>
	<592D02F5-B29A-4596-B0F6-4E6AB6AAF473@nominum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <592D02F5-B29A-4596-B0F6-4E6AB6AAF473@nominum.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Sat, Feb 10, 2007 at 01:43:54PM -0700, Ted Lemon wrote:
> Be careful here.   One issue is that one has leases on IP  
> addresses.   The IP address is not a lease.   So you can't say "use  
> the lease."   You have to say "use the IP address."   And I think  
> that may account for distinction in the wording.   So IMHO you  
> shouldn't take the distinction the way you are taking it - to me it  
> seems clear that the wording is referring to an IP address on which  
> the DHCP client has a valid lease.

Right, an unexpired lease (which in DHCPv4, also has one address).

I don't see any point in pretending there's a difference between
the two things.  All DHCPv4 leases have precisely one IP address.
All DHCPv4'd IP addresses must only be got via leases.

> Also, bear in mind that before you can send a DHCPOFFER you have to  
> ping-test the IP address.   And the expected state is generally that  

s/have to/SHOULD/

> the DHCPREQUEST will be ACKed, not ignored.   So in the common case  
> it's *faster* to send a DHCPREQUEST, not slower.   It's only if your  
> network attachment has *actually* changed that sending the  
> DHCPDISCOVER is faster, and even then it's not very fast - many DHCP  
> servers wait an entire second for the ping to come back.

If you aren't performing an ARP probe, then a DHCPREQUEST/ACK is
faster in the same-network case.

If you are performing an ARP probe, then that will detect
same-network faster than DHCP will (or they wouldn't bother with
it).

So your DHCP-side probe is optimized for the different-network case,
speculating the ARP probe will fail.

If a DHCPREQUEST is NAK'd, then the client must then DISCOVER.

So DISCOVER out of the gate reduces the number of messages by one
exchange.

> I agree that your reading of the RFC casts suspicion on the idea of  
> taking a DHCPDISCOVER to mean that the client is no longer holding  
> the lease.   However, on the other side, bear in mind that the RFC  
> also prohibits the client from responding to an ICMP echo request at  
> DHCPDISCOVER time.

I looked at RFC2131, and could not find the prohibition that DHCPv4
clients MUST NOT respond to an ICMP echo request at any specific
or non-specific time.

I think you mean to say that it's implied since DHCPDISCOVER is
not exampled as something reasonable for use unless the client
has no address (and that servers SHOULD perform an ICMP echo
request is supporting evidence).


I wish it was there.  There has been at least one instance, and I
think actually more than one since, where a client was found to
transmit a DHCPDISCOVER while it was bound to its leased address,
responding to ICMP echo requests.

So a ping-check of a lease that is active is already known to give
false positives.

Given the nature and number of the clients that already behave in
this manner, I think little would be gained by trying to "correct"
the client behaviour.  So the server behaviour should be modified.

My advice is that a server should either elect not to ICMP check
a lease that is already active, or to examine ICMP responses for
source MAC address (obviously made difficult in networks served by
relay agents) and compare it to the lease's active or previous
binding.

> There are a lot of holes in the draft - a careful  
> implementation probably needs to avoid the described behavior, but I  
> don't think it's fair to say that the described behavior is actually  
> out of compliance.

At least we agree on something.  If you recall, I did say I would
use neither the words 'conform' nor 'non-conform' to describe this.

I would advise an implementor heavily against this behaviour,
however.

> But what the client is supposedly doing is still definitely not  
> correct, at least according to my reading of the two RFCs.   If you  
> really think sending a DHCPDISCOVER is faster, you need to do the  
> entire handshake.   I suspect that the author of this DHCP client  
> didn't account for the echo request delay, and that's why it's timing  
> out before it receives a DHCPOFFER.

I thought they're just discarding the entire session if the ARP probe
succeeds, going BOUND, and scheduling renewal.

This is the first time anyone's mentioned ICMP echo timeouts.


Completing the handshake has a nice symmetry to it.  I suspect
that the client implementor did not want to transmit a message
that was "server intensive" as often as its link state changed
(which on a wireless network, may be extremely frequent).  Wether
this is done out of the gate or after a DHCPOFFER, it all amounts
to making the server touch disk.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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



From dhcwg-bounces@ietf.org Mon Feb 12 14:38:32 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGh04-0007zk-SG; Mon, 12 Feb 2007 14:38:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGh01-0007yA-W8
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:38:05 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGh00-0002rP-JU
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:38:05 -0500
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-5.cisco.com with ESMTP; 12 Feb 2007 11:38:03 -0800
X-IronPort-AV: i="4.13,316,1167638400"; 
	d="scan'208"; a="388246903:sNHT86727410"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1CJc305007213; 
	Mon, 12 Feb 2007 11:38:03 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1CJc3hq008446;
	Mon, 12 Feb 2007 11:38:03 -0800 (PST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Feb 2007 14:38:03 -0500
Received: from 171.69.157.60 ([171.69.157.60]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Mon, 12 Feb 2007 19:38:03 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Mon, 12 Feb 2007 12:15:56 -0500
From: Ralph Droms 
To: dhcwg 
Message-ID: 
Thread-Topic: Clarification about receipt of DHCPv6 Reconfigure message
Thread-Index: AcdOyXTms45VE7q8EducqQARJOT6eg==
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 12 Feb 2007 19:38:03.0266 (UTC)
	FILETIME=[4F8BF620:01C74EDD]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1739; t=1171309084;
	x=1172173084; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20Clarification=20about=20receipt=20of=20DHCPv6=20Reconfigure=2
	0message |Sender:=20;
	bh=vKz/BSFPPrMQ5rcoPbeTKy8f4K80EwvqKoM+3jGXoTE=;
	b=Ym2wAUM4ssVbFgvcWN38Iky7MWzg8u5PxhVIMQNB7FHTokmlUMh5j/1kp33yqeoq1cawXefM
	QkduMRS2UTAFjMhrryJHDiTwBX8jbWjbX8SR5GsIUt3YSb5u7gnUnpvM;
Authentication-Results: sj-dkim-5; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 1.6 (+)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: Margo Dolas , 'John McQueen' 
Subject: [dhcwg] Clarification about receipt of DHCPv6 Reconfigure message
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

As part of our work on the CableLabs DOCSIS 3.0 spec, Margo asked about
clarifying the times at which a Reconfigure message must be processed (as
opposed to discarded) by a DHCPv6 client.

The first clarification is how a client should respond to Reconfigure
messages before the initial message exchange is complete.  RFC 3315 includes
the following text:

19.4. Client Behavior

   A client receives Reconfigure messages sent to the UDP port 546 on
   interfaces for which it has acquired configuration information
   through DHCP.  These messages may be sent at any time.

In the abstract, it doesn/t make much sense for the client to respond to a
reeconfigure message before it has completed the initial message exchange,
and, as a practical matter, the client can't respond until it reFrom dhcwg-bounces@ietf.org Mon Feb 12 14:38:32 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGh04-0007zk-SG; Mon, 12 Feb 2007 14:38:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGh01-0007yA-W8
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:38:05 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGh00-0002rP-JU
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:38:05 -0500
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-5.cisco.com with ESMTP; 12 Feb 2007 11:38:03 -0800
X-IronPort-AV: i="4.13,316,1167638400"; 
	d="scan'208"; a="388246903:sNHT86727410"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1CJc305007213; 
	Mon, 12 Feb 2007 11:38:03 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1CJc3hq008446;
	Mon, 12 Feb 2007 11:38:03 -0800 (PST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Feb 2007 14:38:03 -0500
Received: from 171.69.157.60 ([171.69.157.60]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Mon, 12 Feb 2007 19:38:03 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Mon, 12 Feb 2007 12:15:56 -0500
From: Ralph Droms 
To: dhcwg 
Message-ID: 
Thread-Topic: Clarification about receipt of DHCPv6 Reconfigure message
Thread-Index: AcdOyXTms45VE7q8EducqQARJOT6eg==
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 12 Feb 2007 19:38:03.0266 (UTC)
	FILETIME=[4F8BF620:01C74EDD]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1739; t=1171309084;
	x=1172173084; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20Clarification=20about=20receipt=20of=20DHCPv6=20Reconfigure=2
	0message |Sender:=20;
	bh=vKz/BSFPPrMQ5rcoPbeTKy8f4K80EwvqKoM+3jGXoTE=;
	b=Ym2wAUM4ssVbFgvcWN38Iky7MWzg8u5PxhVIMQNB7FHTokmlUMh5j/1kp33yqeoq1cawXefM
	QkduMRS2UTAFjMhrryJHDiTwBX8jbWjbX8SR5GsIUt3YSb5u7gnUnpvM;
Authentication-Results: sj-dkim-5; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 1.6 (+)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: Margo Dolas , 'John McQueen' 
Subject: [dhcwg] Clarification about receipt of DHCPv6 Reconfigure message
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

As part of our work on the CableLabs DOCSIS 3.0 spec, Margo asked about
clarifying the times at which a Reconfigure message must be processed (as
opposed to discarded) by a DHCPv6 client.

The first clarification is how a client should respond to Reconfigure
messages before the initial message exchange is complete.  RFC 3315 includes
the following text:

19.4. Client Behavior

   A client receives Reconfigure messages sent to the UDP port 546 on
   interfaces for which it has acquired configuration information
   through DHCP.  These messages may be sent at any time.

In the abstract, it doesn/t make much sense for the client to respond to a
reeconfigure message before it has completed the initial message exchange,
and, as a practical matter, the client can't respond until it receives a
Reply with the key information.  I think the desired behavior would be for
the client to discard any Reconfigure messages received before the initial
message excahgne is complete.

The second clarification is about client behavior if it receives a
Reconfigure message after T1 and the client has already initiated but not
completed a Renew message exchange.  Because of the parameters for the Renew
message exchange after T1, the client will continue to retransmit the Renew
message until either it receives a Reply or time T2.  Does it make sense for
the client to initiate a parallel Renew message exchange when it is already
waiting for a Reply?  I think the desired behavior would be for the client
to discard any Reconfigure messages it receives if it already has a Renew
message exchange in progress (i.e., any time after T1).  (Note that the
comments above generalize to time T2 and Rebind.)

- Ralph

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

From dhcwg-bounces@ietf.org Mon Feb 12 14:38:32 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGh0A-00084k-5k; Mon, 12 Feb 2007 14:38:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGh08-00082X-AJ
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:38:12 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGh06-0002rh-28
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:38:12 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 12 Feb 2007 14:38:10 -0500
X-IronPort-AV: i="4.13,316,1167627600"; 
	d="scan'208"; a="52819625:sNHT53961770"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1CJc97B008997; 
	Mon, 12 Feb 2007 14:38:09 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1CJc8Vt009559; 
	Mon, 12 Feb 2007 14:38:09 -0500 (EST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Feb 2007 14:38:04 -0500
Received: from 171.69.157.60 ([171.69.157.60]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Mon, 12 Feb 2007 19:38:04 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Mon, 12 Feb 2007 12:24:14 -0500
From: Ralph Droms 
To: dhcwg 
Message-ID: 
Thread-Topic: Clarification about Reconfigure Accept
Thread-Index: AcdOyp273A/1d7q9EducqQARJOT6eg==
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 12 Feb 2007 19:38:05.0011 (UTC)
	FILETIME=[50963A30:01C74EDD]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=739; t=1171309089;
	x=1172173089; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20Clarification=20about=20Reconfigure=20Accept
	|Sender:=20 |To:=20dhcwg=20;
	bh=9zmyoMDjSKNNGQ+Ed2KMeHsLZJ+ORVwmlHE/+wYCSA8=;
	b=MAN05Qf3ZouqWtlTnSlNjbLI7v4nBLvGjIkSUKDJSYNs+r7xY1vbcXFzlOs4aDudpRfq42P7
	VJwTD/PmhbnYOMZoK0wHTCHhDWS1v+firaTVThhYnmMVdE1ke6uBaSiC;
Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: Margo Dolas , 'John McQueen' 
Subject: [dhcwg] Clarification about Reconfigure Accept
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
Lisceives a
Reply with the key information.  I think the desired behavior would be for
the client to discard any Reconfigure messages received before the initial
message excahgne is complete.

The second clarification is about client behavior if it receives a
Reconfigure message after T1 and the client has already initiated but not
completed a Renew message exchange.  Because of the parameters for the Renew
message exchange after T1, the client will continue to retransmit the Renew
message until either it receives a Reply or time T2.  Does it make sense for
the client to initiate a parallel Renew message exchange when it is already
waiting for a Reply?  I think the desired behavior would be for the client
to discard any Reconfigure messages it receives if it already has a Renew
message exchange in progress (i.e., any time after T1).  (Note that the
comments above generalize to time T2 and Rebind.)

- Ralph

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

From dhcwg-bounces@ietf.org Mon Feb 12 14:38:32 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGh0A-00084k-5k; Mon, 12 Feb 2007 14:38:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGh08-00082X-AJ
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:38:12 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGh06-0002rh-28
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:38:12 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 12 Feb 2007 14:38:10 -0500
X-IronPort-AV: i="4.13,316,1167627600"; 
	d="scan'208"; a="52819625:sNHT53961770"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1CJc97B008997; 
	Mon, 12 Feb 2007 14:38:09 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1CJc8Vt009559; 
	Mon, 12 Feb 2007 14:38:09 -0500 (EST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Feb 2007 14:38:04 -0500
Received: from 171.69.157.60 ([171.69.157.60]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Mon, 12 Feb 2007 19:38:04 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Mon, 12 Feb 2007 12:24:14 -0500
From: Ralph Droms 
To: dhcwg 
Message-ID: 
Thread-Topic: Clarification about Reconfigure Accept
Thread-Index: AcdOyp273A/1d7q9EducqQARJOT6eg==
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 12 Feb 2007 19:38:05.0011 (UTC)
	FILETIME=[50963A30:01C74EDD]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=739; t=1171309089;
	x=1172173089; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20Clarification=20about=20Reconfigure=20Accept
	|Sender:=20 |To:=20dhcwg=20;
	bh=9zmyoMDjSKNNGQ+Ed2KMeHsLZJ+ORVwmlHE/+wYCSA8=;
	b=MAN05Qf3ZouqWtlTnSlNjbLI7v4nBLvGjIkSUKDJSYNs+r7xY1vbcXFzlOs4aDudpRfq42P7
	VJwTD/PmhbnYOMZoK0wHTCHhDWS1v+firaTVThhYnmMVdE1ke6uBaSiC;
Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: Margo Dolas , 'John McQueen' 
Subject: [dhcwg] Clarification about Reconfigure Accept
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Margo asked a question about Reconfigure Accept and Authentication options
in a message from the DHCPv6 server:

  If the client includes the Reconfigure Accept option, and the server
  does not include one in the Reply, but it does include the
  Reconfigure Key in an Auth Option, should the client go ahead and
  store the Reconfigure Key and enable Reconfigure support, or should
  it use the absence of the Reconfigure Accept option to disable
  Reconfigure support and ignore the key?

Is there any advantage to storing the Reconfiuger key for later use?  Or
should this scenario be treated as an error condition, with the client
simply ignoring the Authentication option and subsequent Reconfigure
messages?

- Ralph



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





t-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Margo asked a question about Reconfigure Accept and Authentication options
in a message from the DHCPv6 server:

  If the client includes the Reconfigure Accept option, and the server
  does not include one in the Reply, but it does include the
  Reconfigure Key in an Auth Option, should the client go ahead and
  store the Reconfigure Key and enable Reconfigure support, or should
  it use the absence of the Reconfigure Accept option to disable
  Reconfigure support and ignore the key?

Is there any advantage to storing the Reconfiuger key for later use?  Or
should this scenario be treated as an error condition, with the client
simply ignoring the Authentication option and subsequent Reconfigure
messages?

- Ralph



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





From dhcwg-bounces@ietf.org Mon Feb 12 14:42:28 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGh46-0001l4-W0; Mon, 12 Feb 2007 14:42:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGh46-0001ky-Iv
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:42:18 -0500
Received: from goliath.isc.org ([2001:4f8:3:bb::72])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGh46-0003Ku-7m
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:42:18 -0500
Received: by goliath.isc.org (Postfix, from userid 10200)
	id 05F615A6ED; Mon, 12 Feb 2007 11:42:11 -0800 (PST)
Date: Mon, 12 Feb 2007 11:42:11 -0800
From: "David W. Hankins" 
To: dhcwg@ietf.org
Subject: Re: [dhcwg] PPP and DHCP
Message-ID: <20070212194211.GD8408@isc.org>
References: <56D2E48D28DC3B4EA5F2E4B7679D72F7384A1F@ACDNJMAILSRV03.acd.de.ittind.com>
Mime-Version: 1.0
In-Reply-To: <56D2E48D28DC3B4EA5F2E4B7679D72F7384A1F@ACDNJMAILSRV03.acd.de.ittind.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1373391875=="
Errors-To: dhcwg-bounces@ietf.org


--===============1373391875==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM"
Content-Disposition: inline


--cWoXeonUoKmBZSoM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jan 31, 2007 at 05:55:45PM -0500, Gonzalez, Pedro - ACD  wrote:
> I was wondering if there was any information on running DHCP/Ipv4 over
> PPP links. Is there a way to use DHCP to configure the IP address of a
> device on its PPP interface instead of using IPCP? 

I realize this sounds rude, but why would you want to?

DHCP is more tailored to brodcast networks.  Isn't it easier to just
use IPCP?

> I am new to this mailing list. So, please pardon me if this question has
> been raised before. In that case, I'd appreciate any pointers to the
> discussion.

I think there was a query several months ago by someone who wanted
"DHCP option x" via PPP.  Actually I'm not sure that was on this list.

It would be intriguing for there to be a general purpose PPP CP
for containing DHCP options.  But I'm not sure DHCP message
exchanges (and leases) fit.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

--cWoXeonUoKmBZSoM
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFF0MMTcXeLeWu2vmoRAnF1AKC+N4YwGnFEtVuQNbdhZ6nGRfLIvgCePPax
k+QGWXBj+ANCFVwR3TSnhFs=
=NygL
-----END PGP SIGNATURE-----

--cWoXeonUoKmBZSoM--


--===============1373391875==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1373391875==--




From dhcwg-bounces@ietf.org Mon Feb 12 14:44:26 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGh5v-0003Qr-C8; Mon, 12 Feb 2007 14:44:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGh5u-0003Oj-Cb
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:44:10 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGh5s-0003eC-2v
	for dhcwg@ietf.org; Mon, 12 Feb 2007 14:44:10 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 12 Feb 2007 14:44:07 -0500
X-IronPort-AV: i="4.13,316,1167627600"; 
	d="scan'208"; a="113696391:sNHT55177732"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1CJi709012312; 
	Mon, 12 Feb 2007 14:44:07 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1CJi4Vd011585; 
	Mon, 12 Feb 2007 14:44:07 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Feb 2007 14:44:07 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Clarification about Reconfigure Accept
Date: Mon, 12 Feb 2007 14:43:59 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB21033F0690@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Clarification about Reconfigure Accept
Thread-Index: AcdOyp273A/1d7q9EducqQARJOT6egAEwBMA
From: "Bernie Volz \(volz\)" 
To: "Ralph Droms \(rdroms\)" , "dhcwg" 
X-OriginalArrivalTime: 12 Feb 2007 19:44:07.0196 (UTC)
	FILETIME=[287745C0:01C74EDE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1619; t=1171309447;
	x=1172173447; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20Clarification=20about=20Reconfigure=20Accep
	t |Sender:=20
	|To:=20=22Ralph=20Droms=20\(rdroms\)=22=20,
	=20=22dhcwg= 22=20;
	bh=j87+VnNmg230IpS9997AIy9vHhHTbuGsjwap/ISbM6c=;
	b=FKRstvx6mRIA4FsZ6a1VpaNwy7rTAGg1qPr4AhHmiOX8eh1yIPBl2YLaRmLEs3Mayxk/R0t3
	Yfj3hGIP06/XMgdoCQ0fuNQDedXmeqzBK+hhr13vzOSojUEX/uQBUYgm;
Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: Margo Dolas , John McQueen 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

I'd say that the client ignore the Reconfigure Key. There is no point in
storing it because the server hasn't indicated its acceptance of the
client to do Reconfigure.

Note also that if another authentication protocol is in use, the
Reconfigure Accept option is what controls whether the client does
reconfigure.

(We might also ask what happens if the server sends a Reconfigure-Accept
but the client hasn't requested it; I presume that the client would
ignore the request and also ignore the reconfigure key.)

- Bernie

-----Original Message-----
From: Ralph Droms (rdroms)=20
Sent: Monday, February 12, 2007 12:24 PM
To: dhcwg
Cc: Margo Dolas; 'John McQueen'
Subject: [dhcwg] Clarification about Reconfigure Accept

Margo asked a question about Reconfigure Accept and Authentication
options
in a message from the DHCPv6 server:

  If the client includes the Reconfigure Accept option, and the server
  does not include one in the Reply, but it does include the
  Reconfigure Key in an Auth Option, should the client go ahead and
  store the Reconfigure Key and enable Reconfigure support, or should
  it use the absence of the Reconfigure Accept option to disable
  Reconfigure support and ignore the key?

Is there any advantage to storing the Reconfiuger key for later use?  Or
should this scenario be treated as an error condition, with the client
simply ignoring the Authentication option and subsequent Reconfigure
messages?

- Ralph



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

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



From dhcwg-bounces@ietf.org Mon Feb 12 16:32:14 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGill-0007M0-KJ; Mon, 12 Feb 2007 16:31:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGilk-0007Lu-7B
	for dhcwg@ietf.org; Mon, 12 Feb 2007 16:31:28 -0500
Received: from goliath.isc.org ([2001:4f8:3:bb::72])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGilj-00083S-NN
	for dhcwg@ietf.org; Mon, 12 Feb 2007 16:31:28 -0500
Received: by goliath.isc.org (Postfix, from userid 10200)
	id 4D1F55A6ED; Mon, 12 Feb 2007 13:31:07 -0800 (PST)
Date: Mon, 12 Feb 2007 13:31:07 -0800
From: "David W. Hankins" 
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Clarification about receipt of DHCPv6 Reconfigure message
Message-ID: <20070212213107.GF8408@isc.org>
References: 
Mime-Version: 1.0
In-Reply-To: 
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: Margo Dolas , 'John McQueen' 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0821246219=="
Errors-To: dhcwg-bounces@ietf.org


--===============0821246219==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="p2kqVDKq5asng8Dg"
Content-Disposition: inline


--p2kqVDKq5asng8Dg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Feb 12, 2007 at 12:15:56PM -0500, Ralph Droms wrote:
> The first clarification is how a client should respond to Reconfigure

I agree.

> The second clarification is about client behavior if it receives a
> Reconfigure message after T1 and the client has already initiated but not
> completed a Renew message exchange.  Because of the parameters for the Renew

At first blush, I would expect this to be the same as the behaviour
described in section 19.4.1 for multiple Reconfigures.

> message exchange after T1, the client will continue to retransmit the Renew
> message until either it receives a Reply or time T2.  Does it make sense for
> the client to initiate a parallel Renew message exchange when it is already
> waiting for a Reply?  I think the desired behavior would be for the client
> to discard any Reconfigure messages it receives if it already has a Renew
> message exchange in progress (i.e., any time after T1).  (Note that the
> comments above generalize to time T2 and Rebind.)

A client might have been trying to Renew or Rebind for many
iterations already, and consequently its RT may have reached
MRT (10 minutes!).

I would suggest that receiving a reconfigure message in this case
should reset the retransmission state to message-appropriate
settings (be they renew, rebind, or information-request), and the
IRT timeout be scheduled per the transmission time of the previous
packet (immediately if already elapsed).

The server is soliciting traffic, so congestion-avoidance backoffs
are worth resetting, I think, considering the alternative is
waiting up to ten minutes.


But this would only be true of the first Reconfigure message
received since the last Reply.  Section 19.4.1 indicates that
duplicate Reconfigure messages are to be discarded, so it's
important that implementors don't make this a general behaviour.

It may be less effort for a client implementation to simply discard
the Reconfigure than to keep track of wether the current exchange
was Reconfigure-inspired or converted, and that should be allowed.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

--p2kqVDKq5asng8Dg
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFF0NybcXeLeWu2vmoRAggkAJ92NTkG90+ns6TIAe31tXM/OyCqMQCfbQGf
PbEtzdqlt77AHa/NVCaMp4c=
=A1CD
-----END PGP SIGNATURE-----

--p2kqVDKq5asng8Dg--


--===============0821246219==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0821246219==--




From dhcwg-bounces@ietf.org Mon Feb 12 20:01:04 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGm1M-0006qg-Fu; Mon, 12 Feb 2007 19:59:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGm1K-0006mn-Kw
	for dhcwg@ietf.org; Mon, 12 Feb 2007 19:59:46 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGm1J-00079z-9o
	for dhcwg@ietf.org; Mon, 12 Feb 2007 19:59:46 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 12 Feb 2007 19:59:45 -0500
X-IronPort-AV: i="4.14,160,1170651600"; 
	d="scan'208"; a="113729739:sNHT60756486"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1D0xiLn001015; 
	Mon, 12 Feb 2007 19:59:44 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1D0xiVT011675; 
	Mon, 12 Feb 2007 19:59:44 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 12 Feb 2007 19:59:44 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Clarification about receipt of DHCPv6 Reconfigure message
Date: Mon, 12 Feb 2007 19:59:43 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB21033F0869@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Clarification about receipt of DHCPv6 Reconfigure message
Thread-Index: AcdOyXTms45VE7q8EducqQARJOT6egAPt9dQ
From: "Bernie Volz \(volz\)" 
To: "Ralph Droms \(rdroms\)" , "dhcwg" 
X-OriginalArrivalTime: 13 Feb 2007 00:59:44.0783 (UTC)
	FILETIME=[4025B9F0:01C74F0A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3353; t=1171328385;
	x=1172192385; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20Clarification=20about=20receipt=20of=20DHCP
	v6=20Reconfigure=20message |Sender:=20
	|To:=20=22Ralph=20Droms=20\(rdroms\)=22=20,
	=20=22dhcwg= 22=20;
	bh=ajxggXtgs0UcGOWfoeb2pNQQRvu3l3izolExD1eXhhA=;
	b=mmz0v/8/rOw+R+IjXI1uRgdz6Z2HcduT5tJeo4oyIllF5nzdhIzB50B6bKfY52SqOl1zeFEi
	IKgN5zfmDtO/G8NnyhP5xdX6w4GbuvVj6l3WvcS+ASVh9ryHbbBMLe36;
Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: Margo Dolas , John McQueen 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

There are also other interesting questions, such as what should a server
do if it has sent a Reconfigure and receives a Solicit from the client?
RFC 3315 says that only receipt of the message in the
Reconfigure-Message option "cancels" the Reconfigure.

The client/server transactions get very messy because it depends a lot
on which IAs or other options are in each message.

And, it gets more complicated because the Reconfigure isn't clear about
which server the client is to communicate with. Should it communicate
with the server that gave it the information? Or should it communicate
with the server that sent it the Reconfigure (for now, they are most
likely to be the same, but that may not always be the case).
draft-ietf-dhc-dhcpv6-reconfigure-rebind-01 tries to address this.

My own feeling is that the client can discard Reconfigure messages if it
is already doing transactions with the (or a) server on that interface.
If the server continues to retransmit the Reconfigure, eventually the
client will act on it (or the server will give up). And, worst case, the
client and server will do a few extra message exchanges. Not the end of
the world.

This also follows the keep it simple approach?

- Bernie

-----Original Message-----
From: Ralph Droms (rdroms)=20
Sent: Monday, February 12, 2007 12:16 PM
To: dhcwg
Cc: Margo Dolas; 'John McQueen'
Subject: [dhcwg] Clarification about receipt of DHCPv6 Reconfigure
message

As part of our work on the CableLabs DOCSIS 3.0 spec, Margo asked about
clarifying the times at which a Reconfigure message must be processed
(as
opposed to discarded) by a DHCPv6 client.

The first clarification is how a client should respond to Reconfigure
messages before the initial message exchange is complete.  RFC 3315
includes
the following text:

19.4. Client Behavior

   A client receives Reconfigure messages sent to the UDP port 546 on
   interfaces for which it has acquired configuration information
   through DHCP.  These messages may be sent at any time.

In the abstract, it doesn/t make much sense for the client to respond to
a
reeconfigure message before it has completed the initial message
exchange,
and, as a practical matter, the client can't respond until it receives a
Reply with the key information.  I think the desired behavior would be
for
the client to discard any Reconfigure messages received before the
initial
message excahgne is complete.

The second clarification is about client behavior if it receives a
Reconfigure message after T1 and the client has already initiated but
not
completed a Renew message exchange.  Because of the parameters for the
Renew
message exchange after T1, the client will continue to retransmit the
Renew
message until either it receives a Reply or time T2.  Does it make sense
for
the client to initiate a parallel Renew message exchange when it is
already
waiting for a Reply?  I think the desired behavior would be for the
client
to discard any Reconfigure messages it receives if it already has a
Renew
message exchange in progress (i.e., any time after T1).  (Note that the
comments above generalize to time T2 and Rebind.)

- Ralph

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

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



From dhcwg-bounces@ietf.org Mon Feb 12 20:17:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HGmI8-0006Xb-Ts; Mon, 12 Feb 2007 20:17:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HGmI7-0006XV-R1
	for dhcwg@ietf.org; Mon, 12 Feb 2007 20:17:07 -0500
Received: from pacdcimo01.cable.comcast.com ([24.40.8.145])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGmI3-0000al-Cq
	for dhcwg@ietf.org; Mon, 12 Feb 2007 20:17:07 -0500
Received: from ([10.52.116.30])
	by pacdcimo01.cable.comcast.com with ESMTP  id KP-BXT38.463598;
	Mon, 12 Feb 2007 20:16:35 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	PAOAKEXCSMTP01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 20:16:35 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegateand	srsn-optiondrafts
Date: Mon, 12 Feb 2007 20:16:34 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on
	agentopt-delegateand	srsn-optiondrafts
Thread-Index: AcdN0xi6/AJWSqksSJqm+WabP4eDDQBLgBpQ
From: "Woundy, Richard" 
To: "Stig Venaas" ,
	"Ralph Droms" 
X-OriginalArrivalTime: 13 Feb 2007 01:16:35.0362 (UTC)
	FILETIME=[9A7FD820:01C74F0C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Cc: dhcwg , Andre Kostur ,
	Ted Lemon 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

>You can't generally inject a route into the routing infrastructure
specifying that the next-hop is someone else. Although I believe OSPF
supports this.

I believe you are correct. According to RFC 2740 (OSPF for IPv6), an
AS-external-LSA may include a "forwarding address"; see sections 3.4.3.5
and A.4.7.

>If the link is down it may be best not to advertise the route.

Agreed. And I believe it would be a real challenge for a DHCP server to
figure this out.

Let's use the DOCSIS example here, assuming the DHCP server delegated a
prefix to a cable modem. First, the DHCP server has to determine whether
the CMTS is up or down. If the DHCP server is participating in the same
OSPF area as the CMTS, it might examine the flooded Router-LSAs,
Network-LSAs, etc. and deduce whether the CMTS is reachable or not. But
different CMTSs sharing the same DHCP server may be located in distinct
OSPF areas, implying that the DHCP server needs to participate in all
relevant OSPF areas.

If the CMTS is up, then the DHCP server has to determine whether the
DOCSIS blade (used to reach the cable modem) is up or down. Again, if
the DHCP server is participating in the same OSPF area as the CMTS, it
might examine the Intra-Area-Prefix-LSAs to deduce whether the CMTS is
advertising reachability to the prefix associated with the DOCSIS blade.
But it is theoretically possible that a single prefix is shared among
multiple DOCSIS blades (in today's cable world we call this "interface
bundling"), so this deduction may not be totally accurate.

If the CMTS is up and the relevant DOCSIS blade is up, the cable modem
may still be unreachable from the CMTS, for a variety of reasons (e.g.
power down, disconnected coax, local management). I am pretty sure it is
impractical for the CMTS to announce reachability to each individual
cable modem using OSPF or any other routing protocol; each CMTS manages
up to thousands or tens of thousands of cable modems today. I suspect
the DHCP server would have to leverage some other means to determine
cable modem reachability.

Now suppose the DHCP server uses OSPF to announce reachability to the
delegated prefix, but the cable modem is unreachable (e.g. CMTS is down,
DOCSIS blade is down, or cable modem is offline). In the best case,
traffic to the delegated prefix is drawn to the CMTS and is dropped, but
the prefix wasn't reachable from anywhere in the Internet. In the worst
case, the delegated prefix is reachable from the Internet through
another network path (perhaps unknown to the DHCP server), but because
the delegated prefix is advertised by the DHCP server, traffic is drawn
to the CMTS and is blackholed. It might even be possible for a routing
loop to form.

I haven't played with routing protocols many years. I would advise
validating my analysis with a real routing expert / routing AD.

-- Rich

-----Original Message-----
From: Stig Venaas [mailto:stig.venaas@uninett.no]=20
Sent: Sunday, February 11, 2007 12:12 AM
To: Ralph Droms
Cc: dhcwg; Andre Kostur; Ted Lemon
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand
srsn-optiondrafts


Ralph Droms wrote:
> Sure ... It *might* be useful.  But, I think we would need to show at=20
> least an existence proof for how the DHCP server could inject routing=20
> into *any* routing infrastructure.  We can't expect a network that has

> ISIS deployed to also deploy OSPF in parallel with an ISIS-OSPF=20
> gayeway if we specify OSPF as the way for a DHCPv6 server to inject=20
> routing information.

You can't generally inject a route into the routing infrastructure
specifying that the next-hop is someone else. Although I believe OSPF
supports this.

Another issue is that the DHCP server won't know whether the link to the
customer is up. If the link is down it may be best not to advertise the
route.

Stig

>=20
> - Ralph
>=20
>=20
> On 2/10/07 9:27 PM, "Andre Kostur"  wrote:
>=20
>> Could OSPF/RIP/BGP, or some such similar routing protocol be useful=20
>> for this purpose?
>>
>>
>> Regards,
>> =20
>> Andre Kostur
>> Incognito Software Inc.
>> Senior Software Design Engineer
>> T: +1(604)678-2864
>> F: +1(604)688-4339
>> E: akostur@incognito.com
>> =20
>> www.incognito.com
>>
>> -----Original Message-----
>> From: Ralph Droms [mailto:rdroms@cisco.com]
>> Sent: Saturday, February 10, 2007 12:34 PM
>> To: Ted Lemon; Stig Venaas
>> Cc: dhcwg
>> Subject: Re: [dhcwg] dhc wg last call on agentopt-delegate and=20
>> srsn-optiondrafts
>>
>> How do you propose to arrange for the DHCP server to inject that=20
>> routing information, for every possible routing infrastructure=20
>> deployment?
>>
>> - Ralph
>>
>>
>> On 2/10/07 3:27 PM, "Ted Lemon"  wrote:
>>
>>> The way I would prefer to solve this problem is to have the DHCP=20
>>> server communicate with the routing system to inject these routes.=20
>>> And I would prefer that this *not* be part of the regular DHCP=20
>>> packet stream.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg


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

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



From dhcwg-bounces@ietf.org Tue Feb 13 13:22:58 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HH2I3-0005HS-Pp; Tue, 13 Feb 2007 13:22:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2I2-0005HM-Tk
	for dhcwg@ietf.org; Tue, 13 Feb 2007 13:22:06 -0500
Received: from goliath.isc.org ([2001:4f8:3:bb::72])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH2I2-0007zS-JB
	for dhcwg@ietf.org; Tue, 13 Feb 2007 13:22:06 -0500
Received: by goliath.isc.org (Postfix, from userid 10200)
	id 29BAB7D2D; Tue, 13 Feb 2007 10:21:52 -0800 (PST)
Date: Tue, 13 Feb 2007 10:21:52 -0800
From: "David W. Hankins" 
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Clarification about receipt of DHCPv6 Reconfigure message
Message-ID: <20070213182151.GA4999@isc.org>
References: 
	<8E296595B6471A4689555D5D725EBB21033F0869@xmb-rtp-20a.amer.cisco.com>
Mime-Version: 1.0
In-Reply-To: <8E296595B6471A4689555D5D725EBB21033F0869@xmb-rtp-20a.amer.cisco.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: Margo Dolas , John McQueen 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1165593544=="
Errors-To: dhcwg-bounces@ietf.org


--===============1165593544==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB"
Content-Disposition: inline


--DocE+STaALJfprDB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Feb 12, 2007 at 07:59:43PM -0500, Bernie Volz (volz) wrote:
> There are also other interesting questions, such as what should a server
> do if it has sent a Reconfigure and receives a Solicit from the client?
> RFC 3315 says that only receipt of the message in the
> Reconfigure-Message option "cancels" the Reconfigure.

I think 3315 does touch on this actually and expresses that this is
"not optimal, but not broken, and highly unlikely."  Something to
that affect.  I got the distinct impression this was left as-is
intentionally.

> And, it gets more complicated because the Reconfigure isn't clear about
> which server the client is to communicate with. Should it communicate

I think 3315 is clear on this subject.  It says to follow 18.1.3
precisely except to copy any IA option contents from the IA given
in the Reconfigure (eg any IAADDRs).

This means it would use the previous server's DUID in the global
packet space, any unicast options, etc.

I think with a reconfigure-rebind, we'd want to shift that
a bit, but the existing text is clear.

> This also follows the keep it simple approach?

I'm not sure it's beneficial to adopt "keep it simple" when that
means "it may take 10 minutes to converge."

So for Ralph's first case, yes, for Ralph's second case, I think
we need to do better than that, or to at least allow clients the
option to do better than that.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

--DocE+STaALJfprDB
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFF0gG/cXeLeWu2vmoRAgZqAJwKjf8Rs5pn7yu+IWMr45abZequfgCgvIUG
qQh8I/Gnr9oo3nePOz7Hy3s=
=WjKG
-----END PGP SIGNATURE-----

--DocE+STaALJfprDB--


--===============1165593544==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1165593544==--




From dhcwg-bounces@ietf.org Wed Feb 14 06:13:30 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHI3Q-0000BD-6j; Wed, 14 Feb 2007 06:12:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHI3P-0000B7-1Z
	for dhcwg@ietf.org; Wed, 14 Feb 2007 06:12:03 -0500
Received: from sfovwl03.infosys.com ([216.251.50.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHI3N-0004xs-DL
	for dhcwg@ietf.org; Wed, 14 Feb 2007 06:12:02 -0500
Received: from indhubbhs04.ad.infosys.com ([192.168.200.84]) by
	SFOVWL03.infosys.com with InterScan Messaging Security Suite;
	Wed, 14 Feb 2007 02:56:33 -0800
Received: from BLRKECMSG04.ad.infosys.com ([172.25.213.134]) by
	indhubbhs04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Feb 2007 16:41:14 +0530
Received: from BLRKECMSG01.ad.infosys.com ([172.25.213.131]) by
	BLRKECMSG04.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Feb 2007 16:41:09 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Feb 2007 16:41:12 +0530
Message-ID: <0CA51D55A5DC42479FEBFBCEB7D5F183D44D6D@BLRKECMSG01.ad.infosys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Two new drafts on L2RA and Relay Chaining in DHCP v4
Thread-Index: AcdQKNZKtDG0vU3wReGCAJVcxlyd5w==
From: "pavan_kurapati" 
To: 
X-OriginalArrivalTime: 14 Feb 2007 11:11:09.0623 (UTC)
	FILETIME=[D46DD470:01C75028]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Subject: [dhcwg] Two new drafts on L2RA and Relay Chaining in DHCP v4
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org


Hi,
=0D
After presenting the 'Leasequery extension to L2 networks' and=
 'unicast-address sub-option' in the WG meeting held in San Diego and=
 subsequent discussions offline, we decided to combine the two drafts and=
 also define the functionality of Layer 2 Relay Agent in one draft. We have=
 created one new draft which talks about Layer 2 Access networks and the=
 role of Layer 2 Relay Agents in those networks. In the same draft we have=
 covered things like extension of  leasequery and avoiding flooding in L2=
 networks.=0D
=0D
Also, during discussion with Woj we realised that cases where Layer 3 Relay=
 Agents using unnumbered interfaces cannot be handled properly with the=
 existing mechanism of L2RA-L3RA combination. Woj suggested the usage of=
 relay chaining mechanism in DHCP v4. So, we have created a new draft which=
 introduces relay chaining mechanism in DHCP v4. Please review these two=
 drafts and provide your suggestions
=0D
Link and abstract of both are mentioned below:
=0D
        Title           : Layer 2 Relay Agent
        Author(s)       : B. Joshi, et al.
        Filename        : draft-joshi-dhc-layer2-relay-agent-00.txt
        Pages           : 25
        Date            : 2007-2-13
      =0D
   In Layer 2 Access Networks, Access Concentrators are present between
   DHCP Clients and Relay Agent.  In this case, the Relay Agent can not
   uniquely identify the end host and hence can not add unique 'Relay
   Agent Information' option corresponding to the end hosts in DHCP
   messages.  As the Access concentrators are closer to the end hosts,
   they can uniquely identify the end hosts and add the Relay Agent
   Information option in the DHCP message.  Access concentrators do not
   set the 'giaddr' field.  Access Concentrators in this mode are
   typically known as Layer 2 Relay agents.

   This document provides insight to the behavior of the Access
   Concentrators which act as DHCP Layer 2 Relay Agents in Access
   Networks.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-joshi-dhc-layer2-relay-agent-00.t=
xt=
 =0D

=0D

        Title           : Relay Chaining in DHCPv4
        Author(s)       : B. Joshi, P. Kurapati
        Filename        : draft-kurapati-dhc-relay-chaining-dhcpv4-00.txt
        Pages           : 16
        Date            : 2007-2-13
      =0D
   DHCP Relay Agents eliminate the necessity of having a DHCP server on
   each physical network.  DHCPv4 assumes that there is always only one
   Relay Agent between DHCP clients and DHCP server.  In certain network
   configurations, a DHCP server may be multiple subnets away from the
   DHCP client and multiple Relay Agents may be configured to relay DHCP
   messages to and from DHCP client.  Such configuration can be
   supported only when each Relay Agent adds certain Information to DHCP
   messages before relaying them.  This additional information helps in
   relaying the DHCP reply back to the DHCP client through the same
   path.  This mechanism is often referred as Relay Chaining.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kurapati-dhc-relay-chaining-dhcpv=
4-00.txt =0D


Thanks,
Pavan

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended=
 solely for the use of the addressee(s). If you are not the intended=
 recipient, please notify the sender by e-mail and delete the original=
 message. Further, you are not to copy, disclose, or distribute this e-mail=
 or its contents to any other person and any such actions are unlawful.=
 This e-mail may contain viruses. Infosys has taken every reasonable=
 precaution to minimize this risk, but is not liable for any damage you may=
 sustain as a result of any virus in this e-mail. You should carry out your=
 own virus checks before opening the e-mail or attachment. Infosys reserves=
 the right to monitor and review the content of all messages sent to or=
 from this e-mail address. Messages sent to or from this e-mail address may=
 be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

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



From dhcwg-bounces@ietf.org Wed Feb 14 08:13:50 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHJwV-0007LE-LL; Wed, 14 Feb 2007 08:13:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHJwS-0007Kv-PM
	for dhcwg@ietf.org; Wed, 14 Feb 2007 08:13:00 -0500
Received: from tyholt.uninett.no ([158.38.62.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHJwK-0003FJ-3q
	for dhcwg@ietf.org; Wed, 14 Feb 2007 08:13:00 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tyholt.uninett.no (Postfix) with ESMTP id 9EF5EB5A82
	for ; Wed, 14 Feb 2007 14:12:40 +0100 (CET)
Received: from tyholt.uninett.no ([127.0.0.1])
	by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 21751-01-41 for ;
	Wed, 14 Feb 2007 14:12:40 +0100 (CET)
Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no
	[IPv6:2001:700:1:7:215:f2ff:fe35:307d])
	by tyholt.uninett.no (Postfix) with ESMTP id 7C6F8B5A6B
	for ; Wed, 14 Feb 2007 14:12:40 +0100 (CET)
Message-ID: <45D30AC8.5080908@uninett.no>
Date: Wed, 14 Feb 2007 14:12:40 +0100
From: Stig Venaas 
User-Agent: Thunderbird 1.5.0.9 (X11/20070129)
MIME-Version: 1.0
To: dhcwg 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Subject: [dhcwg] Planned wglc for dhcpv6-reconfigure-rebind draft 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

The chairs believe that the draft "Rebind Capability in DHCPv6
Reconfigure Messages" 
is ready for working group last call. We plan to start the last call on
Monday 19th of February. Please let us know by then if you think we are
wrong,

Stig

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



From dhcwg-bounces@ietf.org Wed Feb 14 08:23:35 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHK6D-0002VN-Rq; Wed, 14 Feb 2007 08:23:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHK6B-0002Ql-QB
	for dhcwg@ietf.org; Wed, 14 Feb 2007 08:23:03 -0500
Received: from tyholt.uninett.no ([2001:700:1::eecb])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHK6B-0004k3-Gb
	for dhcwg@ietf.org; Wed, 14 Feb 2007 08:23:03 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tyholt.uninett.no (Postfix) with ESMTP id AF562B5A6B
	for ; Wed, 14 Feb 2007 14:22:56 +0100 (CET)
Received: from tyholt.uninett.no ([127.0.0.1])
	by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 24525-01-65 for ;
	Wed, 14 Feb 2007 14:22:56 +0100 (CET)
Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no
	[IPv6:2001:700:1:7:215:f2ff:fe35:307d])
	by tyholt.uninett.no (Postfix) with ESMTP id 8B6C5B5A6A
	for ; Wed, 14 Feb 2007 14:22:56 +0100 (CET)
Message-ID: <45D30D30.2090604@uninett.no>
Date: Wed, 14 Feb 2007 14:22:56 +0100
From: Stig Venaas 
User-Agent: Thunderbird 1.5.0.9 (X11/20070129)
MIME-Version: 1.0
To: dhcwg 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 6d62ab47271805379d7172ee693a45db
Subject: [dhcwg] Call for agenda items for dhc wg meeting IETF 68 in Prague
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

We need to come up with a draft agenda soon. Please email Ralph
and me if you wish to present at the dhc wg meeting.

Stig


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



From dhcwg-bounces@ietf.org Wed Feb 14 09:02:17 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHKhd-0005CS-VI; Wed, 14 Feb 2007 09:01:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHKhd-0005CK-Ax
	for dhcwg@ietf.org; Wed, 14 Feb 2007 09:01:45 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHKhc-0008WK-0H
	for dhcwg@ietf.org; Wed, 14 Feb 2007 09:01:45 -0500
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-5.cisco.com with ESMTP; 14 Feb 2007 06:01:43 -0800
X-IronPort-AV: i="4.14,169,1170662400"; 
	d="scan'208"; a="389013047:sNHT67058540"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1EE1h54009527
	for ; Wed, 14 Feb 2007 06:01:43 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1EE1IiM011744
	for ; Wed, 14 Feb 2007 06:01:43 -0800 (PST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Feb 2007 09:01:25 -0500
Received: from 10.86.242.208 ([10.86.242.208]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Wed, 14 Feb 2007 14:01:25 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Wed, 14 Feb 2007 09:01:24 -0500
From: Ralph Droms 
To: dhcwg 
Message-ID: 
Thread-Topic: Consensus for WG last call on draft-ietf-dhc-subnet-alloc-04.txt
Thread-Index: AcdQQJys23TmarwzEduK7AARJOT6eg==
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 14 Feb 2007 14:01:25.0282 (UTC)
	FILETIME=[9D6FB020:01C75040]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1266; t=1171461703;
	x=1172325703; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20Consensus=20for=20WG=20last=20call=20on=20draft-ietf-dhc-subn
	et-alloc-04.txt |Sender:=20;
	bh=ZyCd1rKBeLgxvF3iM70kI6GzCdDc1EcdaMsKWkSViuA=;
	b=PeXOsbvcd9qQUSHQQjg0Z2TGm15smKAqoO55FUp2Roo8evgqvqvL5g1yDUlS/ZxSyQVI2HEj
	Hsoih5mpzf33ARelfIThO9BE9Xxlkgk8yZVhrFIxg5m3pN2BJ6JYEnbK;
Authentication-Results: sj-dkim-5; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Subject: [dhcwg] Consensus for WG last call on
	draft-ietf-dhc-subnet-alloc-04.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Stig and I intend to begin a dhc WG last call on
draft-ietf-dhc-subnet-alloc-04.txt, "Subnet Allocation Option" next week.
This WG last call will assess consensus on submitting
draft-ietf-dhc-subnet-alloc-04.txt for publication as a Proposed Standard.

This draft documents the current usage of the option code 220 in agreement
with RFC 3942.  There are no known conflicting uses of option code 220, so
the WG will recommend that IANA assign option code 220 to this option.

Before we initiate the WG last call, we need to clarify exactly how to
proceed with draft-ietf-dhc-subnet-alloc-04.txt.  Stig and I want to submit
the draft for publication as a Proposed Standard.  The dhc WG has discussed
another related draft, draft-shen-dhc-block-alloc-03.txt.  Stig and I
believe that the function described in draft-shen-dhc-block-alloc-03.txt can
be provided by draft-ietf-dhc-subnet-alloc-04.txt.  Therefore, it is
appropriate to proceed with last call review and publication of
draft-ietf-dhc-subnet-alloc-04.txt at this time.

If there is no objection posted on the mailing list to conducting a WG last
call for publishing draft-ietf-dhc-subnet-alloc-04.txt as a Proposed
Standard, we will start the WG last call next week.

- Ralph and Stig


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



From dhcwg-bounces@ietf.org Wed Feb 14 12:07:52 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHNb7-0008Gz-Ps; Wed, 14 Feb 2007 12:07:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHNb5-0008Gt-Sr
	for dhcwg@ietf.org; Wed, 14 Feb 2007 12:07:11 -0500
Received: from stl-smtpout-01.boeing.com ([130.76.96.56]
	helo=stl-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHNb1-00008o-JO
	for dhcwg@ietf.org; Wed, 14 Feb 2007 12:07:11 -0500
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4])
	by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1EH755Y026386
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 14 Feb 2007 11:07:06 -0600 (CST)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1EH75So006819; Wed, 14 Feb 2007 09:07:05 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1EH6uop006453; Wed, 14 Feb 2007 09:07:04 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Feb 2007 09:06:56 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-optiondrafts
Date: Wed, 14 Feb 2007 09:06:56 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017746CF@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB210333EFE8@xmb-rtp-20a.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate
	andsrsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczgAFdIJqAAAcquwABlZErg
References: <39C363776A4E8C4A94691D2BD9D1C9A1017746AF@XCH-NW-7V2.nw.nos.boeing.com>
	<8E296595B6471A4689555D5D725EBB210333EFE8@xmb-rtp-20a.amer.cisco.com>
From: "Templin, Fred L" 
To: "Bernie Volz \(volz\)" ,
	"Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 14 Feb 2007 17:06:56.0551 (UTC)
	FILETIME=[88308B70:01C7505A]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Bernie,

> Perhaps we could add DHCPv6 messages between server and=20
> relay-agent that
> would do this communication instead of piggybacking the RAAN=20
> data on the
> Relay-Reply/Reply. The Server would send a RAAN message and retransmit
> until it got a RAAN-Reply. The Relay-Forw could request the=20
> RAAN. (There
> is still the case of what to do if the server's retransmissions go
> unanswered, but at some point it would give up assuming the Relay was
> down.)

What this implies is a bare relay agent process being able to
accept a request from a server and send a reply back. This
changes the rules of the game laid forth in RFC3315 and (had
we known that this was an option) we would have preferred an
explicit server<->relay messaging exchange over requiring the
relay agent device to also provide client process context for
reconfigure/info-req/info-reply.

As I think you know, the original proposal put forth by my
colleague several months ago was for a DHCP 'ping' message
that a server could use to test whether a relay process was
up, while at the same time conveying RAAN options to the relay.
All that is required is for the server to discover whether/not
the relay agent implements the function so that it wouldn't
try forever to reach a relay that doesn't know how to respond.

So, our preferred solition was (and still is) to specify a
mechanism whereby a DHCP server can 'ping' a DHCP relay, and
also to require that all DHCP relays that accept RAAN options
also be able to accept and respond to the ping's.

Fred
fred.l.templin@boeing.com=20

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



From dhcwg-bounces@ietf.org Wed Feb 14 12:36:29 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHO2p-0000O5-7e; Wed, 14 Feb 2007 12:35:51 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHO2n-0000Nr-Va
	for dhcwg@ietf.org; Wed, 14 Feb 2007 12:35:49 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHO2l-0003uh-Bo
	for dhcwg@ietf.org; Wed, 14 Feb 2007 12:35:49 -0500
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
	by sj-iport-5.cisco.com with ESMTP; 14 Feb 2007 09:35:46 -0800
X-IronPort-AV: i="4.14,170,1170662400"; 
	d="scan'208"; a="389074728:sNHT57371440"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1EHZkqG016166; 
	Wed, 14 Feb 2007 09:35:46 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1EHZehu013797;
	Wed, 14 Feb 2007 09:35:46 -0800 (PST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Feb 2007 12:35:41 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-optiondrafts
Date: Wed, 14 Feb 2007 12:35:40 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB21033F1148@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017746CF@XCH-NW-7V2.nw.nos.boeing.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate
	andsrsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczgAFdIJqAAAcquwABlZErgAAOIDpA=
From: "Bernie Volz \(volz\)" 
To: "Templin, Fred L" ,
	"Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 14 Feb 2007 17:35:41.0954 (UTC)
	FILETIME=[8C9C2620:01C7505E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2156; t=1171474546;
	x=1172338546; c=relaxed/simple; s=sjdkim8002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele
	gate=20andsrsn-optiondrafts |Sender:=20;
	bh=xBwVw3vxv51s2eQsVBWUhJcQl6QuPnxMfqb8IgwDgWc=;
	b=v/JMy4YttrBrA8uSeswg4LqzzJPPtMtSxaMzcsnfx6tVyxEJOcm8lz27flL3Baxr93moNh0h
	nWfYkqGwpnjNk4rUysgRQHvsfLhVpS57DMTV0UYIr+kjhm4iPCJ599H9;
Authentication-Results: sj-dkim-8; header.From=volz@cisco.com; dkim=pass (si
	g from cisco.com/sjdkim8002 verified; ); 
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Fred:

Can you explain the reason for the "ping"? I understand the reason for
sending RAAN information, but not what the ping is about. And is the
ping sometimes independent of RAAN delivery or always part of the RAAN
delivery?

- Bernie=20

-----Original Message-----
From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
Sent: Wednesday, February 14, 2007 12:07 PM
To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
andsrsn-optiondrafts

Bernie,

> Perhaps we could add DHCPv6 messages between server and=20
> relay-agent that
> would do this communication instead of piggybacking the RAAN=20
> data on the
> Relay-Reply/Reply. The Server would send a RAAN message and retransmit
> until it got a RAAN-Reply. The Relay-Forw could request the=20
> RAAN. (There
> is still the case of what to do if the server's retransmissions go
> unanswered, but at some point it would give up assuming the Relay was
> down.)

What this implies is a bare relay agent process being able to
accept a request from a server and send a reply back. This
changes the rules of the game laid forth in RFC3315 and (had
we known that this was an option) we would have preferred an
explicit server<->relay messaging exchange over requiring the
relay agent device to also provide client process context for
reconfigure/info-req/info-reply.

As I think you know, the original proposal put forth by my
colleague several months ago was for a DHCP 'ping' message
that a server could use to test whether a relay process was
up, while at the same time conveying RAAN options to the relay.
All that is required is for the server to discover whether/not
the relay agent implements the function so that it wouldn't
try forever to reach a relay that doesn't know how to respond.

So, our preferred solition was (and still is) to specify a
mechanism whereby a DHCP server can 'ping' a DHCP relay, and
also to require that all DHCP relays that accept RAAN options
also be able to accept and respond to the ping's.

Fred
fred.l.templin@boeing.com=20

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



From dhcwg-bounces@ietf.org Wed Feb 14 12:55:28 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHOLT-0002zz-Sq; Wed, 14 Feb 2007 12:55:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOLT-0002zk-1i
	for dhcwg@ietf.org; Wed, 14 Feb 2007 12:55:07 -0500
Received: from blv-smtpout-01.boeing.com ([130.76.32.69]
	helo=blv-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHOLQ-0006BU-SD
	for dhcwg@ietf.org; Wed, 14 Feb 2007 12:55:07 -0500
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6])
	by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1EHt3xF029769
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 14 Feb 2007 09:55:03 -0800 (PST)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1EHt2XN023086; Wed, 14 Feb 2007 11:55:02 -0600 (CST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1EHshiY022219; Wed, 14 Feb 2007 11:54:56 -0600 (CST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Feb 2007 09:54:53 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-optiondrafts
Date: Wed, 14 Feb 2007 09:54:52 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017746D0@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB21033F1148@xmb-rtp-20a.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate
	andsrsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczgAFdIJqAAAcquwABlZErgAAOIDpAAABK8cA==
References: <39C363776A4E8C4A94691D2BD9D1C9A1017746CF@XCH-NW-7V2.nw.nos.boeing.com>
	<8E296595B6471A4689555D5D725EBB21033F1148@xmb-rtp-20a.amer.cisco.com>
From: "Templin, Fred L" 
To: "Bernie Volz \(volz\)" ,
	"Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 14 Feb 2007 17:54:53.0471 (UTC)
	FILETIME=[3AF7B2F0:01C75061]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

> Can you explain the reason for the "ping"? I understand the reason for
> sending RAAN information, but not what the ping is about. And is the
> ping sometimes independent of RAAN delivery or always part of the RAAN
> delivery?

There can be multiple levels of aspiration, e.g.:

 1) server pings a relay agent only for the purpose of
    reliable delivery of RAAN options
 2) server pings a relay agent for any purpose, e.g. to
    determine whether the relay is still up
 3) server pings any DHCP entity for any purpose
 4) any DHCP entity ping any DHCP entity for any purpose

We didn't get down to specific details in our discussion
several months ago, but I'm pretty sure we weren't arguing
for one approach to the exclusion of others.

Fred
fred.l.tempin@boeing.com

> - Bernie=20
>=20
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
> Sent: Wednesday, February 14, 2007 12:07 PM
> To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
> Cc: dhcwg; Stig Venaas
> Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
> andsrsn-optiondrafts
>=20
> Bernie,
>=20
> > Perhaps we could add DHCPv6 messages between server and=20
> > relay-agent that
> > would do this communication instead of piggybacking the RAAN=20
> > data on the
> > Relay-Reply/Reply. The Server would send a RAAN message and=20
> retransmit
> > until it got a RAAN-Reply. The Relay-Forw could request the=20
> > RAAN. (There
> > is still the case of what to do if the server's retransmissions go
> > unanswered, but at some point it would give up assuming the=20
> Relay was
> > down.)
>=20
> What this implies is a bare relay agent process being able to
> accept a request from a server and send a reply back. This
> changes the rules of the game laid forth in RFC3315 and (had
> we known that this was an option) we would have preferred an
> explicit server<->relay messaging exchange over requiring the
> relay agent device to also provide client process context for
> reconfigure/info-req/info-reply.
>=20
> As I think you know, the original proposal put forth by my
> colleague several months ago was for a DHCP 'ping' message
> that a server could use to test whether a relay process was
> up, while at the same time conveying RAAN options to the relay.
> All that is required is for the server to discover whether/not
> the relay agent implements the function so that it wouldn't
> try forever to reach a relay that doesn't know how to respond.
>=20
> So, our preferred solition was (and still is) to specify a
> mechanism whereby a DHCP server can 'ping' a DHCP relay, and
> also to require that all DHCP relays that accept RAAN options
> also be able to accept and respond to the ping's.
>=20
> Fred
> fred.l.templin@boeing.com=20
>=20

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



From dhcwg-bounces@ietf.org Wed Feb 14 13:09:34 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHOZ5-00020E-PO; Wed, 14 Feb 2007 13:09:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHOZ4-000200-UB
	for dhcwg@ietf.org; Wed, 14 Feb 2007 13:09:10 -0500
Received: from mx.isc.org ([2001:4f8:0:2::1c])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHOZ4-0007zY-Cf
	for dhcwg@ietf.org; Wed, 14 Feb 2007 13:09:10 -0500
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "farside.isc.org", Issuer "ISC CA" (verified OK))
	by mx.isc.org (Postfix) with ESMTP id 051F1114029;
	Wed, 14 Feb 2007 18:09:06 +0000 (UTC)
	(envelope-from David_Hankins@isc.org)
Received: by farside.isc.org (Postfix, from userid 10200)
	id A2FFDE60C7; Wed, 14 Feb 2007 18:08:59 +0000 (UTC)
Date: Wed, 14 Feb 2007 18:08:59 +0000
From: "David W. Hankins" 
To: "Woundy, Richard" 
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand	srsn-optiondrafts
Message-ID: <20070214180859.GF63508@isc.org>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.1i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

I'm not sure why we're talking about dynamic routing protocols.

So bear with me while I nitpick and quibble about the topic I'm
not sure we should be debating.  The real content is after the
'===' break below.

On Mon, Feb 12, 2007 at 08:16:34PM -0500, Woundy, Richard wrote:
> I believe you are correct. According to RFC 2740 (OSPF for IPv6), an
> AS-external-LSA may include a "forwarding address"; see sections 3.4.3.5
> and A.4.7.

Huh, I had no idea OSPF could do that.  I doubt the facility is well
used.

But I'm not sure why a modern network operator would use OSPF for
their "non-connected" IGP, so it's rather strange to postulate that
situation.

The general practice I've engaged in is to use OSPF only to distribute
connected routes (subnets attached to routers' interfaces), and then
to use BGP to distribute any static bindings, which are customer
attachments that lack dynamic impetus, or any redistributed routes
from other routing protocol states (such as a unique OSPF protocol
state declared specifically to carry dynamic routes from a
customer).

In summary, the IGP carries prefixes directly connected to interfaces
on routers, and BGP carries prefixes delivered to their remote ends.

Both OSPF and ISIS have trouble scaling to large numbers of routes
(even with areas there are low ceillings), so this works much better.
Minimizing the size of the IGP, and maximizing the number of routes
carried by BGP, which is more efficient at the task of carrying routes
in bulk.

This is not a different protocol from BGP, but the operational practice
is commonly referred to as "iBGP" to differentiate between the task
of carrying routes internally or externally.


I'd honestly be pretty suprised if there were a single operator today
that used BGP only for the aggregates they advertise externally, and
consequently relied entirely upon OSPF (or even ISIS) for every
more-specific route.

So I'd also be pretty surprised, were I still an operator, if my
IETF representatives came to any conclusions about how a system
would work in my network based upon the principle of OSPF networks
stuffed to the gills.


> OSPF areas, implying that the DHCP server needs to participate in all
> relevant OSPF areas.

IFF you use "i"BGP, you require only one TCP connection over which
to process BGP commands.  Most operators would probably want more
than one, and probably would also want more than one DHCPv6 server
to perform the announcements, preferrably in different geographic
locations.

There are already quite appropriate tools in BGP router
implementations for limiting the number of routes advertised to
neighbors that don't wish to (or can't) carry a full table.

I see no reason why a single generic filter can't be made to
define "routes for CMTS's in facility X".

> In the worst
> case, the delegated prefix is reachable from the Internet through
> another network path (perhaps unknown to the DHCP server), but because
> the delegated prefix is advertised by the DHCP server, traffic is drawn
> to the CMTS and is blackholed. It might even be possible for a routing
> loop to form.

This is the first time I think anyone has suggested that DHCPv6
delegated prefixes in this case would be administratively controlled
by multiple independent entities.

I understood that if the client was using the same prefix, and connected
at a different location, that it would contact the same (or same group
of) DHCPv6 servers.


===  What was the question again?


As I said, I'm not sure why we're talking about dynamic routing
protocols.

In the various discussions we've had about this, it's been stipulated
that one requirement is that the CMTS not be required to participate
in any dynamic routing protocol at all.

So the very notion should be impossible.  We shouldn't even be
able to consider a routing protocol solution to a problem that,
I thought I understood, must span networks that do not implement
any routing protocols.

The implication being that the CMTS would enter only a local
"pseudo-static" route in its table, thanks to this option.  The
"real" router it was connected to (possibly via other similarly
non-dynamically-routing devices) would advertise the prefix's
route dynamically (by also participating as a DHCPv6 relay, and
being delivered similar options).

Basically, to use DHCPv6 relay chaining to reach a router that
does participate in dynamic routing, which either advertises
the delegated prefix or relies upon external routing updates
to direct it to send routes to the nearest non-dynamic router.

This implication is reinforced by reports from various people in
the WG and without, that CMTS operating software does not implement
dynamic routing protocols, is not provisioned with sufficient
processor power or memory (even to manage a "small" local network),
or...since CMTS people are "RF people" and not "IP people"...simply
aren't well suited in their implementation of the protocols.

So I'm pretty confused by looking at a routing protocol centric
view of solutions to this problem (which I thought was an impossible
candidate), and placing upon it criticisms for limitations that are
both the same and measurably worse in this DHCPv6-option centric view
I've been delivered previously.


So I don't get it.  Either I'm dense (probable), the problem hasn't
been explained sufficiently (possible), or there are so many
problems and solutions that no one can keep them straight.


So, may I make a suggestion?

Let's have another look at draft-stenberg-pd-route-maintenance.

I think at least one thing that has caused us to stumble is that
RAAN is intentionally so general-purpose that none of us seem to
agree about what it's going to be used for.  The very first things
I imagined by reading it were counterpositive to the CMTS
environment that's been postulated ever since.

He's already done a lot of great work towards enumerating the problems
and solutions.  If we could all take a moment to make sure they're all
in there, and if Markus and Ole are willing, I'd like to get a handle
on it.


I feel somewhat responsible since my abstention was more vocal than
I would have liked.  I don't know how much time I'll have until Q2
'07, I've probably already spent too much time "away from my desk"
just writing this (unjustifiably long) email this morning.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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



From dhcwg-bounces@ietf.org Wed Feb 14 14:04:24 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHPQ1-0007lo-Dx; Wed, 14 Feb 2007 14:03:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHPPz-0007lb-VX
	for dhcwg@ietf.org; Wed, 14 Feb 2007 14:03:51 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHPPv-0006q6-JR
	for dhcwg@ietf.org; Wed, 14 Feb 2007 14:03:51 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 14 Feb 2007 14:03:47 -0500
X-IronPort-AV: i="4.14,170,1170651600"; 
	d="scan'208"; a="113913090:sNHT60819960"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1EJ3laj013649; 
	Wed, 14 Feb 2007 14:03:47 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1EJ3kOE021466; 
	Wed, 14 Feb 2007 14:03:47 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Feb 2007 14:03:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-optiondrafts
Date: Wed, 14 Feb 2007 14:03:53 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB21033F11CB@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017746D0@XCH-NW-7V2.nw.nos.boeing.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate
	andsrsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczgAFdIJqAAAcquwABlZErgAAOIDpAAABK8cAAC/Z0A
From: "Bernie Volz \(volz\)" 
To: "Templin, Fred L" ,
	"Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 14 Feb 2007 19:03:46.0883 (UTC)
	FILETIME=[DAAC5130:01C7506A]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3518; t=1171479827;
	x=1172343827; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele
	gate=20andsrsn-optiondrafts |Sender:=20
	|To:=20=22Templin, =20Fred=20L=22=20,
	=0A=20=20=
	20=20=20=20=20=20=22Ted=20Lemon=22=20,
	=0A=20=20=20=
	20=20=20=20=20=22Ralph=20Droms=20\(rdroms\)=22=20;
	bh=+eeMlmKCR6w/cfqi0CtNipZgD6NVJSSVubNehyJODB0=;
	b=CfkNxByxgv6t9dlZLKER4+w76mNLEEcwi+01kfdJHqkh3OWh5VxIhxs5HrV2tv0dYTyIhZJu
	tXVLu3Z+KLYDj1MHz1R62hU8vK0mppsZzVC4XpkIzXPhQT1TSuzCxTsF;
Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Fred:

I'm trying to understand why a DHCPv6 specific message needs to be used
to do pings. Why are other techniques (such as ICMPv6 messages) not
possible to use?

And, why does the DHCPv6 server (as a DHCPv6 server) care whether a
specific relay is up or not? (Forgetting for a moment about RAAN
delivery -- ie, (2), (3) and (4) in your list below).

- Bernie
=20

-----Original Message-----
From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
Sent: Wednesday, February 14, 2007 12:55 PM
To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
andsrsn-optiondrafts

> Can you explain the reason for the "ping"? I understand the reason for
> sending RAAN information, but not what the ping is about. And is the
> ping sometimes independent of RAAN delivery or always part of the RAAN
> delivery?

There can be multiple levels of aspiration, e.g.:

 1) server pings a relay agent only for the purpose of
    reliable delivery of RAAN options
 2) server pings a relay agent for any purpose, e.g. to
    determine whether the relay is still up
 3) server pings any DHCP entity for any purpose
 4) any DHCP entity ping any DHCP entity for any purpose

We didn't get down to specific details in our discussion
several months ago, but I'm pretty sure we weren't arguing
for one approach to the exclusion of others.

Fred
fred.l.tempin@boeing.com

> - Bernie=20
>=20
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
> Sent: Wednesday, February 14, 2007 12:07 PM
> To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
> Cc: dhcwg; Stig Venaas
> Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
> andsrsn-optiondrafts
>=20
> Bernie,
>=20
> > Perhaps we could add DHCPv6 messages between server and=20
> > relay-agent that
> > would do this communication instead of piggybacking the RAAN=20
> > data on the
> > Relay-Reply/Reply. The Server would send a RAAN message and=20
> retransmit
> > until it got a RAAN-Reply. The Relay-Forw could request the=20
> > RAAN. (There
> > is still the case of what to do if the server's retransmissions go
> > unanswered, but at some point it would give up assuming the=20
> Relay was
> > down.)
>=20
> What this implies is a bare relay agent process being able to
> accept a request from a server and send a reply back. This
> changes the rules of the game laid forth in RFC3315 and (had
> we known that this was an option) we would have preferred an
> explicit server<->relay messaging exchange over requiring the
> relay agent device to also provide client process context for
> reconfigure/info-req/info-reply.
>=20
> As I think you know, the original proposal put forth by my
> colleague several months ago was for a DHCP 'ping' message
> that a server could use to test whether a relay process was
> up, while at the same time conveying RAAN options to the relay.
> All that is required is for the server to discover whether/not
> the relay agent implements the function so that it wouldn't
> try forever to reach a relay that doesn't know how to respond.
>=20
> So, our preferred solition was (and still is) to specify a
> mechanism whereby a DHCP server can 'ping' a DHCP relay, and
> also to require that all DHCP relays that accept RAAN options
> also be able to accept and respond to the ping's.
>=20
> Fred
> fred.l.templin@boeing.com=20
>=20

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



From dhcwg-bounces@ietf.org Wed Feb 14 14:30:28 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHPot-00034N-PH; Wed, 14 Feb 2007 14:29:35 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHPos-00033s-9k
	for dhcwg@ietf.org; Wed, 14 Feb 2007 14:29:34 -0500
Received: from blv-smtpout-01.boeing.com ([130.76.32.69]
	helo=blv-smtpout-01.ns.cs.boeing.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHPoo-0003wP-OE
	for dhcwg@ietf.org; Wed, 14 Feb 2007 14:29:34 -0500
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6])
	by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1EJTMKg006403
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 14 Feb 2007 11:29:22 -0800 (PST)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1EJTLR0001325; Wed, 14 Feb 2007 13:29:21 -0600 (CST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1EJTKud001241; Wed, 14 Feb 2007 13:29:21 -0600 (CST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Feb 2007 11:29:20 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-optiondrafts
Date: Wed, 14 Feb 2007 11:29:20 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017746D3@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB21033F11CB@xmb-rtp-20a.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate
	andsrsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczgAFdIJqAAAcquwABlZErgAAOIDpAAABK8cAAC/Z0AAACI3OA=
References: <39C363776A4E8C4A94691D2BD9D1C9A1017746D0@XCH-NW-7V2.nw.nos.boeing.com>
	<8E296595B6471A4689555D5D725EBB21033F11CB@xmb-rtp-20a.amer.cisco.com>
From: "Templin, Fred L" 
To: "Bernie Volz \(volz\)" ,
	"Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 14 Feb 2007 19:29:20.0909 (UTC)
	FILETIME=[6D061BD0:01C7506E]
X-Spam-Score: 1.1 (+)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Bernie,

We were not so much seeking a specific *name* (i.e., ping)
as we were a function - in particular, "a reliable exchange
so that the server knows the stale routing state has been
purged on the path to the last-hop relay". Although we did
explore the possibility of a more general-purpose mechanism,
calling it "ping" was more for the purpose of having a
convenient way to describe it.

I don't know about practical implications for a DHCP 'ping'
that satisfies one, some or all of the levels of aspiration
I referred to. One reason to use a DHCP ping instead of an
ICMP ping would be to convey any DHCP options (RAANs and
perhaps other options) and get reachability information
in a single message exchange as opposed to multiple.

I'm having a hard time understanding this splitting of
hairs we seem to be engaged in; I think we made it
abundantly clear what we were asking for.

Fred
fred.l.templin@boeing.com =20

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com]=20
> Sent: Wednesday, February 14, 2007 11:04 AM
> To: Templin, Fred L; Ted Lemon; Ralph Droms (rdroms)
> Cc: dhcwg; Stig Venaas
> Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate=20
> andsrsn-optiondrafts
>=20
> Fred:
>=20
> I'm trying to understand why a DHCPv6 specific message needs=20
> to be used
> to do pings. Why are other techniques (such as ICMPv6 messages) not
> possible to use?
>=20
> And, why does the DHCPv6 server (as a DHCPv6 server) care whether a
> specific relay is up or not? (Forgetting for a moment about RAAN
> delivery -- ie, (2), (3) and (4) in your list below).
>=20
> - Bernie
> =20
>=20
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
> Sent: Wednesday, February 14, 2007 12:55 PM
> To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
> Cc: dhcwg; Stig Venaas
> Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
> andsrsn-optiondrafts
>=20
> > Can you explain the reason for the "ping"? I understand the=20
> reason for
> > sending RAAN information, but not what the ping is about. And is the
> > ping sometimes independent of RAAN delivery or always part=20
> of the RAAN
> > delivery?
>=20
> There can be multiple levels of aspiration, e.g.:
>=20
>  1) server pings a relay agent only for the purpose of
>     reliable delivery of RAAN options
>  2) server pings a relay agent for any purpose, e.g. to
>     determine whether the relay is still up
>  3) server pings any DHCP entity for any purpose
>  4) any DHCP entity ping any DHCP entity for any purpose
>=20
> We didn't get down to specific details in our discussion
> several months ago, but I'm pretty sure we weren't arguing
> for one approach to the exclusion of others.
>=20
> Fred
> fred.l.tempin@boeing.com
>=20
> > - Bernie=20
> >=20
> > -----Original Message-----
> > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
> > Sent: Wednesday, February 14, 2007 12:07 PM
> > To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
> > Cc: dhcwg; Stig Venaas
> > Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
> > andsrsn-optiondrafts
> >=20
> > Bernie,
> >=20
> > > Perhaps we could add DHCPv6 messages between server and=20
> > > relay-agent that
> > > would do this communication instead of piggybacking the RAAN=20
> > > data on the
> > > Relay-Reply/Reply. The Server would send a RAAN message and=20
> > retransmit
> > > until it got a RAAN-Reply. The Relay-Forw could request the=20
> > > RAAN. (There
> > > is still the case of what to do if the server's retransmissions go
> > > unanswered, but at some point it would give up assuming the=20
> > Relay was
> > > down.)
> >=20
> > What this implies is a bare relay agent process being able to
> > accept a request from a server and send a reply back. This
> > changes the rules of the game laid forth in RFC3315 and (had
> > we known that this was an option) we would have preferred an
> > explicit server<->relay messaging exchange over requiring the
> > relay agent device to also provide client process context for
> > reconfigure/info-req/info-reply.
> >=20
> > As I think you know, the original proposal put forth by my
> > colleague several months ago was for a DHCP 'ping' message
> > that a server could use to test whether a relay process was
> > up, while at the same time conveying RAAN options to the relay.
> > All that is required is for the server to discover whether/not
> > the relay agent implements the function so that it wouldn't
> > try forever to reach a relay that doesn't know how to respond.
> >=20
> > So, our preferred solition was (and still is) to specify a
> > mechanism whereby a DHCP server can 'ping' a DHCP relay, and
> > also to require that all DHCP relays that accept RAAN options
> > also be able to accept and respond to the ping's.
> >=20
> > Fred
> > fred.l.templin@boeing.com=20
> >=20
>=20

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



From dhcwg-bounces@ietf.org Wed Feb 14 14:41:56 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHQ0b-0002NN-4B; Wed, 14 Feb 2007 14:41:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQ0a-0002NB-12
	for dhcwg@ietf.org; Wed, 14 Feb 2007 14:41:40 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHQ0X-0002k0-Jb
	for dhcwg@ietf.org; Wed, 14 Feb 2007 14:41:40 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 14 Feb 2007 14:41:37 -0500
X-IronPort-AV: i="4.14,170,1170651600"; 
	d="scan'208"; a="113917378:sNHT66454152"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1EJfbvB027556; 
	Wed, 14 Feb 2007 14:41:37 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1EJfbVT016633; 
	Wed, 14 Feb 2007 14:41:37 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 14 Feb 2007 14:41:36 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate andsrsn-optiondrafts
Date: Wed, 14 Feb 2007 14:41:50 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB21033F1234@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017746D3@XCH-NW-7V2.nw.nos.boeing.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on agentopt-delegate
	andsrsn-optiondrafts
Thread-Index: AcdNVL2G05Ko+YyxTWe15mCdhZon9AAAZczgAFdIJqAAAcquwABlZErgAAOIDpAAABK8cAAC/Z0AAACI3OAAAM3RoA==
From: "Bernie Volz \(volz\)" 
To: "Templin, Fred L" ,
	"Ted Lemon" ,
	"Ralph Droms \(rdroms\)" 
X-OriginalArrivalTime: 14 Feb 2007 19:41:36.0978 (UTC)
	FILETIME=[23C15320:01C75070]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5515; t=1171482097;
	x=1172346097; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele
	gate=20andsrsn-optiondrafts |Sender:=20
	|To:=20=22Templin, =20Fred=20L=22=20,
	=0A=20=20=
	20=20=20=20=20=20=22Ted=20Lemon=22=20,
	=0A=20=20=20=
	20=20=20=20=20=22Ralph=20Droms=20\(rdroms\)=22=20;
	bh=Ga55znJmqm0f5M3ZCznqmav7Sqt5WHSiDvXdMK01cwA=;
	b=dfHyOCNq9pgcjNMOqzU0looB7pIePKbGcG2T/2viXMP+PDfm2nGypykf1tOtjf1O0WTWmd9G
	hQVRzyhd2QhD+jSSdNlV2roccuZ90U9jhqlHbQiyHgLOCtYR3JzuNyEC;
Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a
Cc: dhcwg , Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Fred:

>I'm having a hard time understanding this splitting of
>hairs we seem to be engaged in; I think we made it
>abundantly clear what we were asking for.=20

Sorry, but it isn't clear to me.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
Sent: Wednesday, February 14, 2007 2:29 PM
To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
Cc: dhcwg; Stig Venaas
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
andsrsn-optiondrafts

Bernie,

We were not so much seeking a specific *name* (i.e., ping)
as we were a function - in particular, "a reliable exchange
so that the server knows the stale routing state has been
purged on the path to the last-hop relay". Although we did
explore the possibility of a more general-purpose mechanism,
calling it "ping" was more for the purpose of having a
convenient way to describe it.

I don't know about practical implications for a DHCP 'ping'
that satisfies one, some or all of the levels of aspiration
I referred to. One reason to use a DHCP ping instead of an
ICMP ping would be to convey any DHCP options (RAANs and
perhaps other options) and get reachability information
in a single message exchange as opposed to multiple.

I'm having a hard time understanding this splitting of
hairs we seem to be engaged in; I think we made it
abundantly clear what we were asking for.

Fred
fred.l.templin@boeing.com =20

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com]=20
> Sent: Wednesday, February 14, 2007 11:04 AM
> To: Templin, Fred L; Ted Lemon; Ralph Droms (rdroms)
> Cc: dhcwg; Stig Venaas
> Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate=20
> andsrsn-optiondrafts
>=20
> Fred:
>=20
> I'm trying to understand why a DHCPv6 specific message needs=20
> to be used
> to do pings. Why are other techniques (such as ICMPv6 messages) not
> possible to use?
>=20
> And, why does the DHCPv6 server (as a DHCPv6 server) care whether a
> specific relay is up or not? (Forgetting for a moment about RAAN
> delivery -- ie, (2), (3) and (4) in your list below).
>=20
> - Bernie
> =20
>=20
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
> Sent: Wednesday, February 14, 2007 12:55 PM
> To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
> Cc: dhcwg; Stig Venaas
> Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
> andsrsn-optiondrafts
>=20
> > Can you explain the reason for the "ping"? I understand the=20
> reason for
> > sending RAAN information, but not what the ping is about. And is the
> > ping sometimes independent of RAAN delivery or always part=20
> of the RAAN
> > delivery?
>=20
> There can be multiple levels of aspiration, e.g.:
>=20
>  1) server pings a relay agent only for the purpose of
>     reliable delivery of RAAN options
>  2) server pings a relay agent for any purpose, e.g. to
>     determine whether the relay is still up
>  3) server pings any DHCP entity for any purpose
>  4) any DHCP entity ping any DHCP entity for any purpose
>=20
> We didn't get down to specific details in our discussion
> several months ago, but I'm pretty sure we weren't arguing
> for one approach to the exclusion of others.
>=20
> Fred
> fred.l.tempin@boeing.com
>=20
> > - Bernie=20
> >=20
> > -----Original Message-----
> > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
> > Sent: Wednesday, February 14, 2007 12:07 PM
> > To: Bernie Volz (volz); Ted Lemon; Ralph Droms (rdroms)
> > Cc: dhcwg; Stig Venaas
> > Subject: RE: [dhcwg] dhc wg last call on agentopt-delegate
> > andsrsn-optiondrafts
> >=20
> > Bernie,
> >=20
> > > Perhaps we could add DHCPv6 messages between server and=20
> > > relay-agent that
> > > would do this communication instead of piggybacking the RAAN=20
> > > data on the
> > > Relay-Reply/Reply. The Server would send a RAAN message and=20
> > retransmit
> > > until it got a RAAN-Reply. The Relay-Forw could request the=20
> > > RAAN. (There
> > > is still the case of what to do if the server's retransmissions go
> > > unanswered, but at some point it would give up assuming the=20
> > Relay was
> > > down.)
> >=20
> > What this implies is a bare relay agent process being able to
> > accept a request from a server and send a reply back. This
> > changes the rules of the game laid forth in RFC3315 and (had
> > we known that this was an option) we would have preferred an
> > explicit server<->relay messaging exchange over requiring the
> > relay agent device to also provide client process context for
> > reconfigure/info-req/info-reply.
> >=20
> > As I think you know, the original proposal put forth by my
> > colleague several months ago was for a DHCP 'ping' message
> > that a server could use to test whether a relay process was
> > up, while at the same time conveying RAAN options to the relay.
> > All that is required is for the server to discover whether/not
> > the relay agent implements the function so that it wouldn't
> > try forever to reach a relay that doesn't know how to respond.
> >=20
> > So, our preferred solition was (and still is) to specify a
> > mechanism whereby a DHCP server can 'ping' a DHCP relay, and
> > also to require that all DHCP relays that accept RAAN options
> > also be able to accept and respond to the ping's.
> >=20
> > Fred
> > fred.l.templin@boeing.com=20
> >=20
>=20

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



From dhcwg-bounces@ietf.org Wed Feb 14 23:45:34 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHYU5-00069y-Gj; Wed, 14 Feb 2007 23:44:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHYU3-00069t-Rd
	for dhcwg@ietf.org; Wed, 14 Feb 2007 23:44:39 -0500
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]
	helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HHYU0-0005tS-2O
	for dhcwg@ietf.org; Wed, 14 Feb 2007 23:44:39 -0500
Received: from ([24.40.15.92])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-TDCH7.30402792;
	Wed, 14 Feb 2007 23:44:21 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	PACDCEXCSMTP03.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 23:44:21 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Feb 2007 23:44:20 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Background on CMTSs and routing
Thread-Index: AcdQY3NT6b086CsYSsOe3MtHPVTS4gAN0SWQ
From: "Woundy, Richard" 
To: "dhcwg" 
X-OriginalArrivalTime: 15 Feb 2007 04:44:21.0466 (UTC)
	FILETIME=[F5B3DBA0:01C750BB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d
Subject: [dhcwg] Background on CMTSs and routing
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Folks,

I think it might be worthwhile for the WG to have a common understanding
about CMTSs and routing.

>In the various discussions we've had about this, it's been stipulated
that one requirement is that the CMTS not be required to participate in
any dynamic routing protocol at all.

>So the very notion should be impossible.  We shouldn't even be able to
consider a routing protocol solution to a problem that, I thought I
understood, must span networks that do not implement any routing
protocols.

While the DOCSIS specification allows CMTS implementations to be
"routers" or "bridges", in practice most CMTSs are implemented as
routers, and support multiple routing protocols. Some CMTSs can support
all of the following protocols: RIP, IS-IS, OSPF, BGP, IGRP, PIM, etc.

A typical CMTS today would be configured to use a "good IGP" (OSPF,
IS-IS, iBGP) for routing across the regional backbone (over GigE or OC-x
interfaces), and to use a "poor man's IGP" (RIP routing, or no dynamic
routing at all) with a few customer cable modems across the DOCSIS/HFC
network (to support customer-specific IP subnets). The CMTS would
redistribute (inject) the RIP-learned routes into OSPF/IS-IS/iBGP, as
permitted by local routing policy/configuration. The regional backbone
would leverage OSPF/IS-IS/iBGP routing, and leverage eBGP
peering/transit with one or more national backbones.

I understand that in some cable deployments CMTSs are configured to
participate in the regional backbone iBGP mesh, and in some other
deployments they are not. Since this isn't a routing or cable operator
forum, I ask that we not debate the technical merits of either approach
here. Hopefully the rest of this email will show that this choice is
irrelevant to a "RAAN" comparison discussion.

Note: some CMTS implementations go as far as to support BGP/MPLS VPNs
(RFC 2547), which implies support for Multiprotocol Extensions for BGP4
(RFC 2283).

The CMTS is usually the DHCP relay agent on behalf of the DOCSIS
network(s) it supports.

>The implication being that the CMTS would enter only a local
"pseudo-static" route in its table, thanks to this option.  The "real"
router it was connected to (possibly via other similarly
non-dynamically-routing devices) would advertise the prefix's route
dynamically (by also participating as a DHCPv6 relay, and being
delivered similar options).

>Basically, to use DHCPv6 relay chaining to reach a router that does
participate in dynamic routing, which either advertises the delegated
prefix or relies upon external routing updates to direct it to send
routes to the nearest non-dynamic router.

The CMTS would be able to use the RAAN option to add a (pseudo-)static
local route, and to redistribute this route into the regional backbone
via OSPF/IS-IS/iBGP routing as appropriate. So instead of learning about
a customer-specific route via RIP from a potentially untrusted source
(i.e. a cable modem located in the customer premise), the CMTS would
learn about a customer-specific route via the DHCP RAAN option from a
trusted source (i.e. the service provider's own DHCP server).

A very similar approach is documented for multiple broadband
technologies in RFC 4779, e.g. section 5.2.2.5.4 "If DHCP-PD is used for
address assignment, a static route is automatically installed on the
CMTS/ER for each delegated /48 prefix. The static routes need to be
redistributed into the IGP at the CMTS/ER so there is no need for a
routing protocol between the CMTS/ER and the GWR. If the CMTS is also
acting as an ER, it runs an IGP such as OSPFv3 or IS-IS."

(Note: RFC 4779 requires a lot of updates to synchronize with our
projected cable IPv6 deployments, but this isn't the forum for that
discussion.)

Note that in the RAAN approach, when the CMTS discovers (using local
state) that the CM is unreachable (e.g. DOCSIS network issue) or has
gone offline, the CMTS can remove the prefix from the local forwarding
table, and pull the prefix from IGP routing.

To be fair, Fred Templin has some other use case in mind, in which the
relay agent is NOT a router,
.
Maybe Fred's environment represents a relatively small cable operator --
or perhaps a non-cable operator environment within Boeing? I am pretty
sure this environment does NOT reflect a CMTS deployment in my company,
or in any large cable operator that I can think of.

>This implication is reinforced by reports from various people in the WG
and without, that CMTS operating software does not implement dynamic
routing protocols, is not provisioned with sufficient processor power or
memory (even to manage a "small" local network), or...since CMTS people
are "RF people" and not "IP people"...simply aren't well suited in their
implementation of the protocols.

CMTS operating software typically implements dynamic routing protocols.

CMTSs have sufficient memory for reasonably-sized routing/forwarding
tables (e.g. hundreds and/or thousands of entries), but probably not
enough memory for a full default-free routing/forwarding table (e.g.
hundreds of thousands of entries).

Nowadays, "CMTS people" (engineers and operators) tend to be both "RF
people" and "IP people", pretty smart in general, evem if they don't
attend every IETF meeting. Maybe it isn't a good idea to form opinions
about "CMTS people" based on "reports from various people". I won't
comment on this any further.

>So I'm pretty confused by looking at a routing protocol centric view of
solutions to this problem (which I thought was an impossible candidate),
and placing upon it criticisms for limitations that are both the same
and measurably worse in this DHCPv6-option centric view I've been
delivered previously.

>So I don't get it.  Either I'm dense (probable), the problem hasn't
been explained sufficiently (possible), or there are so many problems
and solutions that no one can keep them straight.

Let me assume that we are on the same page now, technically.

Stig raised the possibility that perhaps the DHCP server could use
dynamic routing protocols (particularly OSPF) to inject routes for
delegated prefixes. I took this idea seriously, thought about the
implications, and raised some concerns about whether "stale routes"
could/would be injected by the DHCP server. While I used an OSPF
example, the same concerns apply to iBGP route injection -- the DHCP
server would not know about the local state of the CMTS network element,
i.e. we cannot guarantee "fate-sharing" between the DHCP server and the
CMTS. In other words, if a DOCSIS network interface on a CMTS goes down,
how would the DHCP server know about it?

The other relevant consideration is that DHCP server experts tend not to
be IGP/routing experts. DHCP isn't trivial, neither is OSPF or BGP. That
is an issue for both software development as well as day-to-day
operations.

-- Rich

P.S. Dave, thanks for the mini-tutorial on iBGP.

Actually, I did a presentation on implementation issues with iBGP to the
IDR working group during the 1996 Montreal IETF,
. At the time,
the operational problem I discovered was that different routing
implementations (specifically Cisco IOS and gated) used a different set
of iBGP tie-breakers, which could cause routing loops if both
implementations co-existed within the same Autonomous System (such as in
the backbone I worked on at the time, where we were replacing
gated-based routers with Ciscos). In fact, tie-breakers for both iBGP
implementations differed from what is documented in RFC 1771. My
work-around at the time was to implement the Cisco iBGP route selection
in gated as an alternate configuration option, mostly because I didn't
have any ability to change the IOS implementation. The response from the
BGP experts at that meeting (e.g. Dennis Ferguson, Tony Li, Yakov
Rekhter) was that the Cisco IOS and gated implementations ought to
conform to the tiebreakers specified in RFC 1771 -- which I don't think
ever happened, because operators relied so heavily on the non-conforming
default tiebreaker rules, e.g. choosing the route with the shortest
AS-PATH.

I stepped away from this issue for almost 10 years, but it looks like
the issue was finally resolved by the latest BGP-4 specification, RFC
4271, where they effectively adopted Cisco IOS's iBGP route selection
algorithm as the new standard. Compare section 9.1.2.2 of RFC 4271 to
section 9.2.1.1 of RFC 1771.

How does that related to this discussion on CMTS routing? I suspect that
if one CMTS vendor implemented BGP-4 per RFC 1771, and another CMTS
vendor implemented BGP-4 per RFC 4271, and they are co-located in the
same BGP AS, there could be potential routing loops on a cable
operator's network. I wonder how many CMTS vendors have implemented RFC
4271 yet?

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



From dhcwg-bounces@ietf.org Wed Feb 14 23:59:55 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHYiB-0006lB-5i; Wed, 14 Feb 2007 23:59:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHYiA-0006l5-2u
	for dhcwg@ietf.org; Wed, 14 Feb 2007 23:59:14 -0500
Received: from ind-iport-1.cisco.com ([64.104.129.195])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHYi6-0007n0-LG
	for dhcwg@ietf.org; Wed, 14 Feb 2007 23:59:14 -0500
Received: from ind-dkim-1.cisco.com ([64.104.140.57])
	by ind-iport-1.cisco.com with ESMTP; 15 Feb 2007 23:16:51 +0530
X-IronPort-AV: i="4.14,173,1170613800"; 
	d="scan'208"; a="75522307:sNHT74945624"
Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94])
	by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1F4x7gK024157; 
	Thu, 15 Feb 2007 10:29:08 +0530
Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com
	[64.104.123.69])
	by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1F4x5U3002886; 
	Thu, 15 Feb 2007 12:59:06 +0800 (CST)
Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by
	xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Feb 2007 12:59:05 +0800
Received: from emakko.cisco.com ([64.104.9.16]) by xfe-hkg-411.apac.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Feb 2007 12:59:04 +0800
Received: from mstenber by emakko.cisco.com with local (Exim 4.62)
	(envelope-from )
	id 1HHYi9-0001Ii-7v; Thu, 15 Feb 2007 13:59:13 +0900
From: Markus Stenberg 
To: "David W. Hankins" 
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand	srsn-optiondrafts
Organization: cisco Systems, Inc.
References: 
	<20070214180859.GF63508@isc.org>
Date: Thu, 15 Feb 2007 13:59:13 +0900
In-Reply-To: <20070214180859.GF63508@isc.org> (David W. Hankins's message of
	"Wed, 14 Feb 2007 18:08:59 +0000")
Message-ID: <87y7n0t3ry.fsf@emakko.cisco.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-OriginalArrivalTime: 15 Feb 2007 04:59:05.0036 (UTC)
	FILETIME=[0459F0C0:01C750BE]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6594; t=1171515548;
	x=1172379548; c=relaxed/simple; s=inddkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mstenber@cisco.com;
	z=From:=20Markus=20Stenberg=20
	|Subject:=20Re=3A=20[dhcwg]=20dhc=20wg=20last=20call=20on=20agentopt-dele
	gateand=09srsn-optiondrafts |Sender:=20;
	bh=f2iBOO7n6t0oSCNMJoHXQ1iNq4Jw2o9hPG0S9zgdh1Y=;
	b=I7oIlTGZy7j4rUJ1ntaRYriQf3nwzMRWT8AFGRRtEOGxFfQs566LQU3Z+c80tq5lBydk9T4S
	vHXrXrN1p9rn0l51p3bp42H8lBw59oM8P1GydWaRTls4K1EO/Q6CIau5;
Authentication-Results: ind-dkim-1; header.From=mstenber@cisco.com; dkim=pass (
	sig from cisco.com/inddkim1002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Cc: dhcwg , "Woundy,
	Richard" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

"David W. Hankins"  writes:

.. snipped OSPF<>BGP discussion; I think the used routing protocol doesn't
have significant impact on the mechanics; only extent (local/global) and
the nature (static/dynamic) of the (aggregated?) prefixes does, and it is
affected more by ISP operating policy than routing protocol choice ..

>> In the worst case, the delegated prefix is reachable from the Internet
>> through another network path (perhaps unknown to the DHCP server), but
>> because the delegated prefix is advertised by the DHCP server, traffic
>> is drawn to the CMTS and is blackholed. It might even be possible for a
>> routing loop to form.
>
> This is the first time I think anyone has suggested that DHCPv6
> delegated prefixes in this case would be administratively controlled
> by multiple independent entities.
>
> I understood that if the client was using the same prefix, and connected
> at a different location, that it would contact the same (or same group
> of) DHCPv6 servers.

Well, in theory, if you are using some sort of multihoming approach from
two ISPs, it could be possible for you to get same prefix from both of
them, with completely different DHCPv6 servers, and have the route
advertised from both ISPs BGP. Then, if one of those ISPs DRs (for example)
went down, you'd want only one route to be globally reachable.

Of course, doing that you're probably acting in the evil PI space and might
as well configure the stuff by hand, and run your own routing protocol, but
I'm not sure if you really need to. If we assume that DR availability
triggers the advertising for that prefix in the AS-land (and beyond), it
would be possible to do reasonable multihoming on the multihomed systems
without anything else than DHCPv6 PD, which would be nice I suppose. 

Although I have sort of bad feeling about that in general; the PD stuff,
from my point of view, is a pseudo routing protocol if it involves route
injection. Purist in me would prefer just doing the things with real
routing protocols (whatever their names are), but DHCPv6 PD + whatever
route injection solution you prefer seems awfully convenient at times.

> In the various discussions we've had about this, it's been stipulated
> that one requirement is that the CMTS not be required to participate
> in any dynamic routing protocol at all.

Oh, so cableland is sort of 'almost IP' land; certainly, it provides
prefixes, but they're not really truly dynamically routable as such, and
aimed only for end user use I suppose. Multihoming example noted above (as
far as I understand the cable requirements) would be impossible with that
sort of system.

I think the contrived multihoming example in and of itself is mostly
academic, as most ISPs wouldn't really _want_ to advertise non-aggregated
PI prefixes for individual customers anyway, but in the real world they
seem to be doing it, albeit with real routing protocols instead of DHCPv6
PD..

> So the very notion should be impossible.  We shouldn't even be
> able to consider a routing protocol solution to a problem that,
> I thought I understood, must span networks that do not implement
> any routing protocols.
>
> The implication being that the CMTS would enter only a local
> "pseudo-static" route in its table, thanks to this option.  The
> "real" router it was connected to (possibly via other similarly
> non-dynamically-routing devices) would advertise the prefix's
> route dynamically (by also participating as a DHCPv6 relay, and
> being delivered similar options).
>
> Basically, to use DHCPv6 relay chaining to reach a router that
> does participate in dynamic routing, which either advertises
> the delegated prefix or relies upon external routing updates
> to direct it to send routes to the nearest non-dynamic router.
>
> This implication is reinforced by reports from various people in
> the WG and without, that CMTS operating software does not implement
> dynamic routing protocols, is not provisioned with sufficient
> processor power or memory (even to manage a "small" local network),
> or...since CMTS people are "RF people" and not "IP people"...simply
> aren't well suited in their implementation of the protocols.
>
> So I'm pretty confused by looking at a routing protocol centric
> view of solutions to this problem (which I thought was an impossible
> candidate), and placing upon it criticisms for limitations that are
> both the same and measurably worse in this DHCPv6-option centric view
> I've been delivered previously.
>
> So I don't get it.  Either I'm dense (probable), the problem hasn't
> been explained sufficiently (possible), or there are so many
> problems and solutions that no one can keep them straight.

I look mostly at the generic problem, and your description of the cableland
is actually interesting for me, as I don't actually know much about it. I
admit it freely, despite number of people actually claiming me to be either
for or against the DOCSIS stuff, while in fact I know little beyond the
acronyms involved :-)

> So, may I make a suggestion?
>
> Let's have another look at draft-stenberg-pd-route-maintenance.
>
> I think at least one thing that has caused us to stumble is that
> RAAN is intentionally so general-purpose that none of us seem to
> agree about what it's going to be used for.  The very first things
> I imagined by reading it were counterpositive to the CMTS
> environment that's been postulated ever since.

I've rewritten some parts of the section 2.1 based on your comments (and
some others'); I accounted for cableland-style approach, although I still
don't consider it desirable as such, but for sake of completeness I rewrote
bunch of it. I'm still soliciting more input though, and I'll post the
draft-delta here most likely tomorrow. 

The -01 version itself will be posted before the meeting deadline and I'm
still considering where, if anywhere, I really want to talk about it :-)

> I feel somewhat responsible since my abstention was more vocal than
> I would have liked.  I don't know how much time I'll have until Q2
> '07, I've probably already spent too much time "away from my desk"
> just writing this (unjustifiably long) email this morning.

Sounds familiar. This feels like a hobby for me too!

Cheers,

-Markus

-- 
"...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning."
	- Matt Welsh

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



From dhcwg-bounces@ietf.org Thu Feb 15 00:02:22 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHYkz-0007Xg-PS; Thu, 15 Feb 2007 00:02:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHYky-0007XY-6A
	for dhcwg@ietf.org; Thu, 15 Feb 2007 00:02:08 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHYkw-0008DT-Oq
	for dhcwg@ietf.org; Thu, 15 Feb 2007 00:02:08 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id 254425684E;
	Wed, 14 Feb 2007 21:01:48 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.819,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.251
X-Spam-Level: 
Received: from [66.93.162.135] ([66.93.162.135])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Wed, 14 Feb 2007 21:01:45 -0800
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <15EF3112-1C42-4565-961A-952484DF8E69@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] Background on CMTSs and routing
Date: Wed, 14 Feb 2007 22:01:43 -0700
To: "Woundy, Richard" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 14, 2007, at 9:44 PM, Woundy, Richard wrote:
> Stig raised the possibility that perhaps the DHCP server could use
> dynamic routing protocols (particularly OSPF) to inject routes for
> delegated prefixes. I took this idea seriously, thought about the
> implications, and raised some concerns about whether "stale routes"
> could/would be injected by the DHCP server. While I used an OSPF
> example, the same concerns apply to iBGP route injection -- the DHCP
> server would not know about the local state of the CMTS network  
> element,
> i.e. we cannot guarantee "fate-sharing" between the DHCP server and  
> the
> CMTS. In other words, if a DOCSIS network interface on a CMTS goes  
> down,
> how would the DHCP server know about it?

Why do we care?   The delegated prefix has a lifetime; when the  
lifetime expires, we nuke the route.   I guess if the lack of a route  
to the CMTS is discovered high in the network hierarchy, that's going  
to save some packets going over that wire, but on a practical level I  
don't see why it makes much difference - if the device is gone, it's  
not going to be doing things that generate traffic anyway.   So I  
don't really see this as a reason to do routing injection at the  
relay agent.

> The other relevant consideration is that DHCP server experts tend  
> not to
> be IGP/routing experts. DHCP isn't trivial, neither is OSPF or BGP.  
> That
> is an issue for both software development as well as day-to-day
> operations.

This is certainly true.

To be honest, the only thing I've heard in this debate that I find at  
all compelling is Ralph's mention of the idea of different  
administrative domains running DHCP servers within the same routing  
infrastructure, as is common in at some ISPs in Asia.   In that case,  
injecting routes from the DHCP server may be somewhat harder to  
arrange than in the case where a single administrative domain  
controls both the DHCP server and the routing infrastructure.

However, what I would really like to see here is some input from  
folks who *are* routing experts.   I would like to see a  
recommendation for how to proceed coming from them, not from us.    
Either way, though, whether the injection happens at the router or at  
the DHCP server, I would really like to not see this protocol  
piggybacked on top of the usual DHCP transaction with the DHCP client.



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



From dhcwg-bounces@ietf.org Thu Feb 15 00:05:38 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHYo9-0008Jc-7u; Thu, 15 Feb 2007 00:05:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHYo7-0008Ha-On
	for dhcwg@ietf.org; Thu, 15 Feb 2007 00:05:23 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHYo6-0000Ms-F5
	for dhcwg@ietf.org; Thu, 15 Feb 2007 00:05:23 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id 2695656836;
	Wed, 14 Feb 2007 21:05:22 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.809,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.261
X-Spam-Level: 
Received: from [66.93.162.135] ([66.93.162.135])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Wed, 14 Feb 2007 21:05:20 -0800
In-Reply-To: <15EF3112-1C42-4565-961A-952484DF8E69@nominum.com>
References: 
	<15EF3112-1C42-4565-961A-952484DF8E69@nominum.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <7E2EDCCE-6335-44A7-8E59-46037969CB69@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] Background on CMTSs and routing
Date: Wed, 14 Feb 2007 22:05:19 -0700
To: Richard Woundy 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 14, 2007, at 10:01 PM, Ted Lemon wrote:
> I guess if the lack of a route to the CMTS is discovered high in  
> the network hierarchy,

This was poorly phrased.   What I meant is that if the lack of a  
route to the customer is discovered by the CMTS and quickly  
propagated into the network, there may be some minor benefits to  
that, but I don't find them particularly compelling.



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



From dhcwg-bounces@ietf.org Thu Feb 15 00:11:37 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHYts-0004Pp-AT; Thu, 15 Feb 2007 00:11:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHYtq-0004HM-BS
	for dhcwg@ietf.org; Thu, 15 Feb 2007 00:11:18 -0500
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]
	helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HHYto-0000qM-U0
	for dhcwg@ietf.org; Thu, 15 Feb 2007 00:11:18 -0500
Received: from ([10.195.246.152])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-TDCH7.30402864;
	Thu, 15 Feb 2007 00:11:01 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	NJMDCEXCRLY01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 00:11:01 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Background on CMTSs and routing
Date: Thu, 15 Feb 2007 00:11:00 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Background on CMTSs and routing
Thread-Index: AcdQvz8Oa4TIfSqDQBWryO3+ET+mcAAAEoEg
From: "Woundy, Richard" 
To: "Ted Lemon" 
X-OriginalArrivalTime: 15 Feb 2007 05:11:01.0020 (UTC)
	FILETIME=[AF1C6DC0:01C750BF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: dhcwg , "Woundy,
	Richard" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

The stale route would break routing to a multihomed customer (cable +
non-cable) using PI addresses, for example.

-- Rich

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20
Sent: Thursday, February 15, 2007 12:05 AM
To: Woundy, Richard
Cc: dhcwg
Subject: Re: [dhcwg] Background on CMTSs and routing


On Feb 14, 2007, at 10:01 PM, Ted Lemon wrote:
> I guess if the lack of a route to the CMTS is discovered high in
> the network hierarchy,

This was poorly phrased.   What I meant is that if the lack of a =20
route to the customer is discovered by the CMTS and quickly =20
propagated into the network, there may be some minor benefits to =20
that, but I don't find them particularly compelling.



_______________________________________________
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-bounces@ietf.org Thu Feb 15 00:33:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHZF6-00034B-US; Thu, 15 Feb 2007 00:33:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHZF5-00033Q-4J
	for dhcwg@ietf.org; Thu, 15 Feb 2007 00:33:15 -0500
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]
	helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HHZEo-0003kG-UA
	for dhcwg@ietf.org; Thu, 15 Feb 2007 00:32:59 -0500
Received: from ([10.52.116.31])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-TDCH7.30402962;
	Thu, 15 Feb 2007 00:32:47 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	PAOAKEXCSMTP02.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 00:32:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 15 Feb 2007 00:32:46 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Delegated prefix managed by multiple entities
Thread-Index: AcdQY3NT6b086CsYSsOe3MtHPVTS4gAWJKhA
From: "Woundy, Richard" 
To: "dhcwg" 
X-OriginalArrivalTime: 15 Feb 2007 05:32:46.0819 (UTC)
	FILETIME=[B96D8B30:01C750C2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e367d58950869b6582535ddf5a673488
Cc: "Woundy, Richard" 
Subject: [dhcwg] Delegated prefix managed by multiple entities
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

>> In the worst
>> case, the delegated prefix is reachable from the Internet through=20
>> another network path (perhaps unknown to the DHCP server), but
because=20
>> the delegated prefix is advertised by the DHCP server, traffic is=20
>> drawn to the CMTS and is blackholed. It might even be possible for a=20
>> routing loop to form.

>This is the first time I think anyone has suggested that DHCPv6
delegated prefixes in this case would be administratively controlled by
multiple independent entities.

Please allow me to use a potentially controversial example in this
reply.

Suppose a business entity/organization approaches both a cable operator
and an alternative broadband provider (e.g. a telco) for multihomed
Internet connectivity, bringing their own Provider Independent prefix
per  and
.

Note: please do not use this example as an endorsement of PI addressing.
The second draft enumerates why PI addressing is difficult for service
providers.

Anyway, suppose the cable operator uses DHCP-PD to send the PI prefix to
the customer's cable modem, for broadband service over DOCSIS. Further
suppose that the PI prefix is injected into the IGP by the DHCP server.
The alternative provider sets up routing as appropriate to their
environment. At this point, traffic to the customer's PI address on the
cable operator's backbone would be forwarded to the CMTS (and to the
CM), traffic on the alternative provider's backbone would be routed over
the alternative broadband network, and general Internet traffic would be
routed to either the cable operator or the alternative provider based on
routing topology and preferences in various national/worldwide
backbones.

Now suppose that the customer's cable modem goes offline. From what I've
seen, we don't have a mechanism for the DHCP server to figure out very
quickly that the cable modem is offline, so the PI prefix remains in the
cable backbone IGP routing tables. That means that cable network traffic
directed to the customer's PI address will still be routed to the CMTS,
where it will be blackholed. Some general Internet traffic to the PI
address will also be blackholed.

If the CMTS is responsible for PI prefix injection into the IGP, then
the CMTS could detect the cable modem going offline in minutes, if not
in seconds, and remove the PI prefix from the IGP routing tables. Then
cable network traffic (and some Internet traffic) that would have
otherwise been blackholed at the CMTS, could be routed to the alternate
broadband provider's network -- thus enabling a highly available network
connection for the multihomed organization.

This is why having a "stale route" in the IGP can be an issue for
multihomed customers.

I think there are some other variations on the multihomed-customer theme
(e.g. multihomed to the same provider using different access networks)
that could be relevant here.

-- Rich

-----Original Message-----
From: David W. Hankins [mailto:David_Hankins@isc.org]=20
Sent: Wednesday, February 14, 2007 1:09 PM
To: Woundy, Richard
Cc: dhcwg
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand
srsn-optiondrafts


I'm not sure why we're talking about dynamic routing protocols.

So bear with me while I nitpick and quibble about the topic I'm not sure
we should be debating.  The real content is after the '=3D=3D=3D' break =
below.

On Mon, Feb 12, 2007 at 08:16:34PM -0500, Woundy, Richard wrote:
> I believe you are correct. According to RFC 2740 (OSPF for IPv6), an=20
> AS-external-LSA may include a "forwarding address"; see sections=20
> 3.4.3.5 and A.4.7.

Huh, I had no idea OSPF could do that.  I doubt the facility is well
used.

But I'm not sure why a modern network operator would use OSPF for their
"non-connected" IGP, so it's rather strange to postulate that situation.

The general practice I've engaged in is to use OSPF only to distribute
connected routes (subnets attached to routers' interfaces), and then to
use BGP to distribute any static bindings, which are customer
attachments that lack dynamic impetus, or any redistributed routes from
other routing protocol states (such as a unique OSPF protocol state
declared specifically to carry dynamic routes from a customer).

In summary, the IGP carries prefixes directly connected to interfaces on
routers, and BGP carries prefixes delivered to their remote ends.

Both OSPF and ISIS have trouble scaling to large numbers of routes (even
with areas there are low ceillings), so this works much better.
Minimizing the size of the IGP, and maximizing the number of routes
carried by BGP, which is more efficient at the task of carrying routes
in bulk.

This is not a different protocol from BGP, but the operational practice
is commonly referred to as "iBGP" to differentiate between the task of
carrying routes internally or externally.


I'd honestly be pretty suprised if there were a single operator today
that used BGP only for the aggregates they advertise externally, and
consequently relied entirely upon OSPF (or even ISIS) for every
more-specific route.

So I'd also be pretty surprised, were I still an operator, if my IETF
representatives came to any conclusions about how a system would work in
my network based upon the principle of OSPF networks stuffed to the
gills.


> OSPF areas, implying that the DHCP server needs to participate in all=20
> relevant OSPF areas.

IFF you use "i"BGP, you require only one TCP connection over which to
process BGP commands.  Most operators would probably want more than one,
and probably would also want more than one DHCPv6 server to perform the
announcements, preferrably in different geographic locations.

There are already quite appropriate tools in BGP router implementations
for limiting the number of routes advertised to neighbors that don't
wish to (or can't) carry a full table.

I see no reason why a single generic filter can't be made to define
"routes for CMTS's in facility X".

> In the worst
> case, the delegated prefix is reachable from the Internet through=20
> another network path (perhaps unknown to the DHCP server), but because

> the delegated prefix is advertised by the DHCP server, traffic is=20
> drawn to the CMTS and is blackholed. It might even be possible for a=20
> routing loop to form.

This is the first time I think anyone has suggested that DHCPv6
delegated prefixes in this case would be administratively controlled by
multiple independent entities.

I understood that if the client was using the same prefix, and connected
at a different location, that it would contact the same (or same group
of) DHCPv6 servers.


=3D=3D=3D  What was the question again?


As I said, I'm not sure why we're talking about dynamic routing
protocols.

In the various discussions we've had about this, it's been stipulated
that one requirement is that the CMTS not be required to participate in
any dynamic routing protocol at all.

So the very notion should be impossible.  We shouldn't even be able to
consider a routing protocol solution to a problem that, I thought I
understood, must span networks that do not implement any routing
protocols.

The implication being that the CMTS would enter only a local
"pseudo-static" route in its table, thanks to this option.  The "real"
router it was connected to (possibly via other similarly
non-dynamically-routing devices) would advertise the prefix's route
dynamically (by also participating as a DHCPv6 relay, and being
delivered similar options).

Basically, to use DHCPv6 relay chaining to reach a router that does
participate in dynamic routing, which either advertises the delegated
prefix or relies upon external routing updates to direct it to send
routes to the nearest non-dynamic router.

This implication is reinforced by reports from various people in the WG
and without, that CMTS operating software does not implement dynamic
routing protocols, is not provisioned with sufficient processor power or
memory (even to manage a "small" local network), or...since CMTS people
are "RF people" and not "IP people"...simply aren't well suited in their
implementation of the protocols.

So I'm pretty confused by looking at a routing protocol centric view of
solutions to this problem (which I thought was an impossible candidate),
and placing upon it criticisms for limitations that are both the same
and measurably worse in this DHCPv6-option centric view I've been
delivered previously.


So I don't get it.  Either I'm dense (probable), the problem hasn't been
explained sufficiently (possible), or there are so many problems and
solutions that no one can keep them straight.


So, may I make a suggestion?

Let's have another look at draft-stenberg-pd-route-maintenance.

I think at least one thing that has caused us to stumble is that RAAN is
intentionally so general-purpose that none of us seem to agree about
what it's going to be used for.  The very first things I imagined by
reading it were counterpositive to the CMTS environment that's been
postulated ever since.

He's already done a lot of great work towards enumerating the problems
and solutions.  If we could all take a moment to make sure they're all
in there, and if Markus and Ole are willing, I'd like to get a handle on
it.


I feel somewhat responsible since my abstention was more vocal than I
would have liked.  I don't know how much time I'll have until Q2 '07,
I've probably already spent too much time "away from my desk" just
writing this (unjustifiably long) email this morning.

--=20
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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



From dhcwg-bounces@ietf.org Thu Feb 15 00:36:23 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHZI3-0004Lk-C8; Thu, 15 Feb 2007 00:36:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHZI1-0004LD-VX
	for dhcwg@ietf.org; Thu, 15 Feb 2007 00:36:17 -0500
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]
	helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HHZI1-0004G1-IU
	for dhcwg@ietf.org; Thu, 15 Feb 2007 00:36:17 -0500
Received: from ([10.52.116.31])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-TDCH7.30402976;
	Thu, 15 Feb 2007 00:36:01 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	PAOAKEXCSMTP02.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 00:36:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc wg last call on agentopt-delegateand	srsn-optiondrafts
Date: Thu, 15 Feb 2007 00:36:00 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc wg last call on
	agentopt-delegateand	srsn-optiondrafts
Thread-Index: AcdQvuPca8hzCadJRWmzMBLEqA36mwAA999A
From: "Woundy, Richard" 
To: "Markus Stenberg" ,
	"David W. Hankins" 
X-OriginalArrivalTime: 15 Feb 2007 05:36:00.0862 (UTC)
	FILETIME=[2D1627E0:01C750C3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Cc: dhcwg , "Woundy,
	Richard" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

>Oh, so cableland is sort of 'almost IP' land

I *beg* you to read my email entitled "Background on CMTSs and routing"
before you draw your final conclusions about what 'cableland' is really
like. :(



-- Rich

-----Original Message-----
From: Markus Stenberg [mailto:mstenber@cisco.com]=20
Sent: Wednesday, February 14, 2007 11:59 PM
To: David W. Hankins
Cc: Woundy, Richard; dhcwg
Subject: Re: [dhcwg] dhc wg last call on agentopt-delegateand
srsn-optiondrafts


"David W. Hankins"  writes:

.. snipped OSPF<>BGP discussion; I think the used routing protocol
doesn't have significant impact on the mechanics; only extent
(local/global) and the nature (static/dynamic) of the (aggregated?)
prefixes does, and it is affected more by ISP operating policy than
routing protocol choice ..

>> In the worst case, the delegated prefix is reachable from the=20
>> Internet through another network path (perhaps unknown to the DHCP=20
>> server), but because the delegated prefix is advertised by the DHCP=20
>> server, traffic is drawn to the CMTS and is blackholed. It might even

>> be possible for a routing loop to form.
>
> This is the first time I think anyone has suggested that DHCPv6=20
> delegated prefixes in this case would be administratively controlled=20
> by multiple independent entities.
>
> I understood that if the client was using the same prefix, and=20
> connected at a different location, that it would contact the same (or=20
> same group
> of) DHCPv6 servers.

Well, in theory, if you are using some sort of multihoming approach from
two ISPs, it could be possible for you to get same prefix from both of
them, with completely different DHCPv6 servers, and have the route
advertised from both ISPs BGP. Then, if one of those ISPs DRs (for
example) went down, you'd want only one route to be globally reachable.

Of course, doing that you're probably acting in the evil PI space and
might as well configure the stuff by hand, and run your own routing
protocol, but I'm not sure if you really need to. If we assume that DR
availability triggers the advertising for that prefix in the AS-land
(and beyond), it would be possible to do reasonable multihoming on the
multihomed systems without anything else than DHCPv6 PD, which would be
nice I suppose.=20

Although I have sort of bad feeling about that in general; the PD stuff,
from my point of view, is a pseudo routing protocol if it involves route
injection. Purist in me would prefer just doing the things with real
routing protocols (whatever their names are), but DHCPv6 PD + whatever
route injection solution you prefer seems awfully convenient at times.

> In the various discussions we've had about this, it's been stipulated=20
> that one requirement is that the CMTS not be required to participate=20
> in any dynamic routing protocol at all.

Oh, so cableland is sort of 'almost IP' land; certainly, it provides
prefixes, but they're not really truly dynamically routable as such, and
aimed only for end user use I suppose. Multihoming example noted above
(as far as I understand the cable requirements) would be impossible with
that sort of system.

I think the contrived multihoming example in and of itself is mostly
academic, as most ISPs wouldn't really _want_ to advertise
non-aggregated PI prefixes for individual customers anyway, but in the
real world they seem to be doing it, albeit with real routing protocols
instead of DHCPv6 PD..

> So the very notion should be impossible.  We shouldn't even be able to

> consider a routing protocol solution to a problem that, I thought I=20
> understood, must span networks that do not implement any routing=20
> protocols.
>
> The implication being that the CMTS would enter only a local=20
> "pseudo-static" route in its table, thanks to this option.  The "real"

> router it was connected to (possibly via other similarly=20
> non-dynamically-routing devices) would advertise the prefix's route=20
> dynamically (by also participating as a DHCPv6 relay, and being=20
> delivered similar options).
>
> Basically, to use DHCPv6 relay chaining to reach a router that does=20
> participate in dynamic routing, which either advertises the delegated=20
> prefix or relies upon external routing updates to direct it to send=20
> routes to the nearest non-dynamic router.
>
> This implication is reinforced by reports from various people in the=20
> WG and without, that CMTS operating software does not implement=20
> dynamic routing protocols, is not provisioned with sufficient=20
> processor power or memory (even to manage a "small" local network),=20
> or...since CMTS people are "RF people" and not "IP people"...simply=20
> aren't well suited in their implementation of the protocols.
>
> So I'm pretty confused by looking at a routing protocol centric view=20
> of solutions to this problem (which I thought was an impossible=20
> candidate), and placing upon it criticisms for limitations that are=20
> both the same and measurably worse in this DHCPv6-option centric view=20
> I've been delivered previously.
>
> So I don't get it.  Either I'm dense (probable), the problem hasn't=20
> been explained sufficiently (possible), or there are so many problems=20
> and solutions that no one can keep them straight.

I look mostly at the generic problem, and your description of the
cableland is actually interesting for me, as I don't actually know much
about it. I admit it freely, despite number of people actually claiming
me to be either for or against the DOCSIS stuff, while in fact I know
little beyond the acronyms involved :-)

> So, may I make a suggestion?
>
> Let's have another look at draft-stenberg-pd-route-maintenance.
>
> I think at least one thing that has caused us to stumble is that RAAN=20
> is intentionally so general-purpose that none of us seem to agree=20
> about what it's going to be used for.  The very first things I=20
> imagined by reading it were counterpositive to the CMTS environment=20
> that's been postulated ever since.

I've rewritten some parts of the section 2.1 based on your comments (and
some others'); I accounted for cableland-style approach, although I
still don't consider it desirable as such, but for sake of completeness
I rewrote bunch of it. I'm still soliciting more input though, and I'll
post the draft-delta here most likely tomorrow.=20

The -01 version itself will be posted before the meeting deadline and
I'm still considering where, if anywhere, I really want to talk about it
:-)

> I feel somewhat responsible since my abstention was more vocal than I=20
> would have liked.  I don't know how much time I'll have until Q2 '07,=20
> I've probably already spent too much time "away from my desk" just=20
> writing this (unjustifiably long) email this morning.

Sounds familiar. This feels like a hobby for me too!

Cheers,

-Markus

--=20
"...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning."
	- Matt Welsh

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



From dhcwg-bounces@ietf.org Thu Feb 15 01:04:45 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHZip-0003so-M1; Thu, 15 Feb 2007 01:03:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHZip-0003sj-72
	for dhcwg@ietf.org; Thu, 15 Feb 2007 01:03:59 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHZim-0007lb-Qp
	for dhcwg@ietf.org; Thu, 15 Feb 2007 01:03:59 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id 5C85B5687F;
	Wed, 14 Feb 2007 22:03:42 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.790,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.280
X-Spam-Level: 
Received: from [66.93.162.135] ([66.93.162.135])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Wed, 14 Feb 2007 22:03:40 -0800
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <10FDCAF5-26CC-4412-9EC6-A65EF837C43B@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities
Date: Wed, 14 Feb 2007 23:03:37 -0700
To: "Woundy, Richard" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 14, 2007, at 10:32 PM, Woundy, Richard wrote:
> Now suppose that the customer's cable modem goes offline. From what  
> I've
> seen, we don't have a mechanism for the DHCP server to figure out very
> quickly that the cable modem is offline, so the PI prefix remains  
> in the
> cable backbone IGP routing tables. That means that cable network  
> traffic
> directed to the customer's PI address will still be routed to the  
> CMTS,
> where it will be blackholed. Some general Internet traffic to the PI
> address will also be blackholed.

Richard, no offense, but this looks like a completely contrived  
example.   Why would you ever do that?   Does the routing  
infrastructure require you to do it?   Is it the easiest, most  
failsafe way to do it?   What if your DHCP server is accidentally  
configured so that it hands your customer the wrong prefix?   Why  
wouldn't the customer simply hard-code their provider-independent  
routes in their border gateways?

Why isn't the routing infrastructure capable of handling this sort of  
problem without the assistance of DHCP on any level?   It seems to  
work okay in IPv4-land.   Or am I just naive about this?



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



From dhcwg-bounces@ietf.org Thu Feb 15 02:09:52 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHajS-0004uF-SA; Thu, 15 Feb 2007 02:08:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHajR-0004u9-QM
	for dhcwg@ietf.org; Thu, 15 Feb 2007 02:08:41 -0500
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHajP-0008Oj-PW
	for dhcwg@ietf.org; Thu, 15 Feb 2007 02:08:41 -0500
Received: from ams-dkim-1.cisco.com ([144.254.224.138])
	by ams-iport-1.cisco.com with ESMTP; 15 Feb 2007 08:08:35 +0100
Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94])
	by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1F78XKu021069; 
	Thu, 15 Feb 2007 08:08:34 +0100
Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com
	[64.104.123.72])
	by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1F78WU5022291; 
	Thu, 15 Feb 2007 15:08:32 +0800 (CST)
Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by
	xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Feb 2007 15:08:31 +0800
Received: from emakko.cisco.com ([64.104.9.16]) by xfe-hkg-412.apac.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Feb 2007 15:08:30 +0800
Received: from mstenber by emakko.cisco.com with local (Exim 4.62)
	(envelope-from )
	id 1HHajP-0001xc-1C; Thu, 15 Feb 2007 16:08:39 +0900
From: Markus Stenberg 
To: Ted Lemon 
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities
Organization: cisco Systems, Inc.
References: 
	<10FDCAF5-26CC-4412-9EC6-A65EF837C43B@nominum.com>
Date: Thu, 15 Feb 2007 16:08:39 +0900
In-Reply-To: <10FDCAF5-26CC-4412-9EC6-A65EF837C43B@nominum.com> (Ted Lemon's
	message of "Wed, 14 Feb 2007 23:03:37 -0700")
Message-ID: <87d54bucco.fsf@emakko.cisco.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-OriginalArrivalTime: 15 Feb 2007 07:08:31.0063 (UTC)
	FILETIME=[19439E70:01C750D0]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1391; t=1171523315;
	x=1172387315; c=relaxed/simple; s=amsdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mstenber@cisco.com;
	z=From:=20Markus=20Stenberg=20
	|Subject:=20Re=3A=20[dhcwg]=20Delegated=20prefix=20managed=20by=20multipl
	e=20entities |Sender:=20;
	bh=UWLvh3FwfnktWDm/LlKjYCJUn6I6CRAwWC21ljC9T3s=;
	b=j9ynjK9Qhu2h25ogLK7Alr8Mp6Xl30TxN9WTq5ogHew2ujm1YvBedjq6Ucq34w91rYycau+O
	2p59qykq+qvLewPXHKdtyMmhN9PgPZ/YKmx7UeaY0h6V//Z6GnbFsM/2;
Authentication-Results: ams-dkim-1; header.From=mstenber@cisco.com; dkim=pass (
	sig from cisco.com/amsdkim1002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: dhcwg , "Woundy,
	Richard" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Ted Lemon  writes:
> Richard, no offense, but this looks like a completely contrived
> example.   Why would you ever do that?   Does the routing
> infrastructure require you to do it?   Is it the easiest, most
> failsafe way to do it?   What if your DHCP server is accidentally
> configured so that it hands your customer the wrong prefix?   Why
> wouldn't the customer simply hard-code their provider-independent
> routes in their border gateways?

I think DHCP-PD based multihoming is not contrived example because it makes
customer life easier; they don't NEED to run routing protocol, nor have
manual configuration for that matter and the stuff 'just works' for some
definition of works (inbound traffic winds up at their RR; how RR sends
stuff out is another matter).

Given RAAN, or DHCPv6 traffic snooping at the first-hop delegating router
(aka DHCPv6 relay), you can also have relay responsible for pushing this
routing information. I find the server pushing routing state for someone
else somewhat distasteful, but possibly it's valid in some cases.

You need routability for the prefixes handed via PD; whether the route is
valid for the lease lifetime, or only when the interface is really
reachable (information not always available, subject to crashes somewhere
on the path, etc) is a matter of preference..

Cheers,

-Markus

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



From dhcwg-bounces@ietf.org Thu Feb 15 02:25:13 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHaz1-0005iC-Tq; Thu, 15 Feb 2007 02:24:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHaz0-0005hi-SU
	for dhcwg@ietf.org; Thu, 15 Feb 2007 02:24:46 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHay7-00022v-Ea
	for dhcwg@ietf.org; Thu, 15 Feb 2007 02:23:52 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id E71ED56860;
	Wed, 14 Feb 2007 23:23:36 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.780,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.290
X-Spam-Level: 
Received: from [66.93.162.135] ([66.93.162.135])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Wed, 14 Feb 2007 23:23:36 -0800
In-Reply-To: <87d54bucco.fsf@emakko.cisco.com>
References: 
	<10FDCAF5-26CC-4412-9EC6-A65EF837C43B@nominum.com>
	<87d54bucco.fsf@emakko.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <620C0B30-209A-4186-9BCA-E494A68ACCE1@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities
Date: Thu, 15 Feb 2007 00:23:33 -0700
To: Markus Stenberg 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: dhcwg , "Woundy,
	Richard" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 15, 2007, at 12:08 AM, Markus Stenberg wrote:
> I think DHCP-PD based multihoming is not contrived example because  
> it makes
> customer life easier; they don't NEED to run routing protocol, nor  
> have
> manual configuration for that matter and the stuff 'just works' for  
> some
> definition of works (inbound traffic winds up at their RR; how RR  
> sends
> stuff out is another matter).

Even the way you say this tells me that it's contrived.   A halfway  
solution with serious reliability concerns (because it would be so  
easy to misconfigure their border router from the DHCP server) is not  
something you can describe as making customer life easier.   I don't  
mean you're wrong, but if we're only talking about half the solution,  
let's talk about the other half before we start using this as a user  
story.

> Given RAAN, or DHCPv6 traffic snooping at the first-hop delegating  
> router
> (aka DHCPv6 relay), you can also have relay responsible for pushing  
> this
> routing information. I find the server pushing routing state for  
> someone
> else somewhat distasteful, but possibly it's valid in some cases.

I am not strongly advocating this position - it's just the one that  
makes the most sense to me as a network engineer, but I am _not_ a  
network engineer at an ISP, so I'm not claiming I'm right about  
this.   I'm just asking you to tell me why I'm wrong, and hoping I'll  
hear something I can believe.   I'm perfectly fine with the DHCP  
server communicating with the relay agent if that's the right thing  
to do, although nobody's said anything so far that makes me think  
that's the case.   I don't care what's distasteful, and indeed I  
think it's an unfortunate choice of words.   I care what is reliable,  
in the sense that it works consistently, that it's clean to  
implement, easy to maintain, and difficult to configure in a way that  
creates heisenbuggy instability (complete malfunction is fine because  
that's quickly noticed and usually easily diagnosed).

> You need routability for the prefixes handed via PD; whether the  
> route is
> valid for the lease lifetime, or only when the interface is really
> reachable (information not always available, subject to crashes  
> somewhere
> on the path, etc) is a matter of preference..

Clearly the latter is preferable to the former, all other factors  
being equal.




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



From dhcwg-bounces@ietf.org Thu Feb 15 02:37:57 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHbBK-0004DV-FZ; Thu, 15 Feb 2007 02:37:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHbBJ-0004DQ-6e
	for dhcwg@ietf.org; Thu, 15 Feb 2007 02:37:29 -0500
Received: from mail1.wpi.edu ([130.215.36.91])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHbBF-0004ih-Tl
	for dhcwg@ietf.org; Thu, 15 Feb 2007 02:37:29 -0500
Received: from mcafee.wpi.edu (MCAFEE.WPI.EDU [130.215.36.86])
	by mail1.wpi.edu (8.14.0/8.14.0) with SMTP id l1F7bORm011718
	for ; Thu, 15 Feb 2007 02:37:25 -0500
Received: from (130.215.36.186) by mcafee.wpi.edu via smtp
	id 387f_60b2d736_bcc7_11db_8ad1_0013725b2d50;
	Thu, 15 Feb 2007 02:37:24 -0500
Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21])
	by SMTP.WPI.EDU (8.13.8/8.13.8) with ESMTP id l1F7bMqL020124
	for ; Thu, 15 Feb 2007 02:37:24 -0500
	(envelope-from cra@WPI.EDU)
Received: from angus.ind.WPI.EDU (localhost [127.0.0.1])
	by angus.ind.WPI.EDU (8.13.8/8.13.8) with ESMTP id l1F7bMjv015343
	for ; Thu, 15 Feb 2007 02:37:22 -0500
Received: (from cra@localhost)
	by angus.ind.WPI.EDU (8.13.8/8.13.8/Submit) id l1F7bMoR015342
	for dhcwg@ietf.org; Thu, 15 Feb 2007 02:37:22 -0500
X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU
	using -f
Date: Thu, 15 Feb 2007 02:37:22 -0500
From: Chuck Anderson 
To: dhcwg 
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities
Message-ID: <20070215073722.GX3334@angus.ind.WPI.EDU>
Mail-Followup-To: dhcwg 
References: 
	<10FDCAF5-26CC-4412-9EC6-A65EF837C43B@nominum.com>
	<87d54bucco.fsf@emakko.cisco.com>
	<620C0B30-209A-4186-9BCA-E494A68ACCE1@nominum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <620C0B30-209A-4186-9BCA-E494A68ACCE1@nominum.com>
User-Agent: Mutt/1.4.2.2i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Thu, Feb 15, 2007 at 12:23:33AM -0700, Ted Lemon wrote:
> >You need routability for the prefixes handed via PD; whether the  
> >route is
> >valid for the lease lifetime, or only when the interface is really
> >reachable (information not always available, subject to crashes  
> >somewhere
> >on the path, etc) is a matter of preference..
> 
> Clearly the latter is preferable to the former, all other factors  
> being equal.

Being a network engineer, I have to agree with Ted here.  Especially 
in the multi-homed case, anything other than the latter solution is 
broken by design.  If you want to multi-home, you have to expect to 
run a real routing protocol on the customer's router.  I would be 
strongly against any attempt to piggyback routing on top of DHCP.


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



From dhcwg-bounces@ietf.org Thu Feb 15 03:03:43 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHbaQ-00055r-GK; Thu, 15 Feb 2007 03:03:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHbaP-00052z-3i
	for dhcwg@ietf.org; Thu, 15 Feb 2007 03:03:25 -0500
Received: from pacdcimo01.cable.comcast.com ([24.40.8.145])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHbaM-0000yz-OR
	for dhcwg@ietf.org; Thu, 15 Feb 2007 03:03:25 -0500
Received: from ([10.52.116.31])
	by pacdcimo01.cable.comcast.com with ESMTP  id KP-BXT38.617915;
	Thu, 15 Feb 2007 03:02:58 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	PAOAKEXCSMTP02.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 03:02:58 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Delegated prefix managed by multiple entities
Date: Thu, 15 Feb 2007 03:02:57 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Delegated prefix managed by multiple entities
Thread-Index: AcdQxxiNi3YS+rDoRBuhy6cWEMY9cgAAY51g
From: "Woundy, Richard" 
To: "Ted Lemon" 
X-OriginalArrivalTime: 15 Feb 2007 08:02:58.0631 (UTC)
	FILETIME=[B4E2ED70:01C750D7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Cc: dhcwg , "Woundy,
	Richard" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

>Richard, no offense, but this looks like a completely contrived
example.

Maybe you can help me understand what part I "contrived"? Business
customers want multihoming? (they do) Cable modem going offline?
(unfortunately they do) The PI prefix remaining as a "stale route" in
the IGP routing table because the DHCP server can't detect the modem
going down? (tell me how *not* to make this happen)

The point of the example is that routing will be "wrong" until something
detects that the cable modem is down. If the DHCP server can detect the
cable modem going offline fairly quickly, then this issue is mitigated.
Maybe someone can explain to me how the DHCP server can detect this?

>What if your DHCP server is accidentally configured so that it hands
your customer the wrong prefix? Why wouldn't the customer simply
hard-code their provider-independent routes in their border gateways?

Why would a customer truly worried about either of these cases be a
candidate for DHCP-PD at all?

I'm talking about intermittent connectivity causing a routing issue, and
you're talking about an operational blunder. This doesn't seem like a
fair comparison, even within this group. For example, if there is a
temporary network outage, I would expect DHCP failover to help us
maintain continuous DHCP operation, right? If I misconfigure a DHCP
server with the wrong subnet information, should I still expect it to
function properly in my network? If I am worried about DHCP server
misconfiguration, shouldn't I just number all of my computers by hand?

Here is my expected (business) customer experience. The customer orders
broadband service from the cable operator, and provides the PI prefix.
The cable operator sends a black box (cable modem) that is supposed to
connect to the customer's network and to the cable/coax network. The
black box is connected and turned on, and now the customer has broadband
IPv6 Internet service.

The customer orders broadband service from an alternate broadband
provider, who provides their own black box for service. Traffic from the
Internet to the customer arrives over both access networks, as
appropriate.

If there is an issue with cable access, then all customer traffic is
routed over the alternate broadband provider. If there is an issue with
alternate access, then all customer traffic is routed over the cable
network.

Why isn't that a reasonable customer expectation?

>Why isn't the routing infrastructure capable of handling this sort of
problem without the assistance of DHCP on any level?   It seems to work
okay in IPv4-land.

In "IPv4-land", routers inject routes into the IGP based on local state
and configuration. They learn about routes originating from other
routers through the IGP. Then they use all of that information to make
traffic forwarding decisions.

Suppose a router in Nominum has an Ethernet interface that has been
turned off, and you turn the Ethernet interface on. What happens? The
local router will detect that the Ethernet is up, and will tell the
other remote Nominum routers via IGP (e.g. by flooding) that the
Ethernet's IP subnet is reachable through it. If the Ethernet cable is
unplugged, the local router will withdraw the Ethernet's IP subnet from
the IGP, and the other remote routers won't forward that Ethernet's
traffic to the local router anymore. The reachability of the Ethernet's
IP subnet is announced by the local router.

If there are two routers attached to the same Ethernet, then they both
independently announce to the IGP that each can reach the Ethernet's IP
subnet. The "magic" of routing is that remote routers will forward that
Ethernet's traffic to the local router that is "closer". If one router's
Ethernet interface goes down, then that router withdraws the Ethernet IP
subnet from the IGP, and all of the remote routers forward that
Ethernet's traffic to the *other* local router, automatically.

Do you agree that this is how routing works in "IPv4-land" today? In
fact, this isn't really different from how routing works in IPv4 cable
networks, either.

Now suppose that someone wanted to change how things work, so that some
"server" (DHCP or otherwise) notifies the remote routers through the IGP
about whether the Ethernet's IP network is reachable through one or both
of the local routers. Is that how you run *your* network today? How
would this "server" know which local router's Ethernet interface is
down, and which is up? If the server gets it wrong, then part of the
Nominum network isn't going to be able to reach the Ethernet network
anymore; some routers will forward traffic to the local router whose
Ethernet interface is down.

The point in the Nominum network example is that the Ethernet edge
router knows whether the Ethernet is reachable or not. Not some "server"
elsewhere in the network.

In the DHCP-PD/cable world, the CMTS knows if the DOCSIS network is
reachable or not. The DHCP server isn't going to know that the DOCSIS
network, or some individual cable modem, is unreachable. It's the same
routing principle.

My root concern is that third-party route injection by the DHCP server
isn't going to work correctly in some pretty reasonable network
impairment cases (and multihoming). Please consider this when proposing
alternative-to-RAAN solutions. That's all I ask.

-- Rich

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20
Sent: Thursday, February 15, 2007 1:04 AM
To: Woundy, Richard
Cc: dhcwg
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities


On Feb 14, 2007, at 10:32 PM, Woundy, Richard wrote:
> Now suppose that the customer's cable modem goes offline. From what
> I've
> seen, we don't have a mechanism for the DHCP server to figure out very
> quickly that the cable modem is offline, so the PI prefix remains =20
> in the
> cable backbone IGP routing tables. That means that cable network =20
> traffic
> directed to the customer's PI address will still be routed to the =20
> CMTS,
> where it will be blackholed. Some general Internet traffic to the PI
> address will also be blackholed.

Richard, no offense, but this looks like a completely contrived =20
example.   Why would you ever do that?   Does the routing =20
infrastructure require you to do it?   Is it the easiest, most =20
failsafe way to do it?   What if your DHCP server is accidentally =20
configured so that it hands your customer the wrong prefix?   Why =20
wouldn't the customer simply hard-code their provider-independent =20
routes in their border gateways?

Why isn't the routing infrastructure capable of handling this sort of =20
problem without the assistance of DHCP on any level?   It seems to =20
work okay in IPv4-land.   Or am I just naive about this?



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



From dhcwg-bounces@ietf.org Thu Feb 15 03:06:41 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHbdO-00077p-CB; Thu, 15 Feb 2007 03:06:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHbdN-00077k-Fo
	for dhcwg@ietf.org; Thu, 15 Feb 2007 03:06:29 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHbdL-0001LO-6L
	for dhcwg@ietf.org; Thu, 15 Feb 2007 03:06:29 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id 8DAA856836;
	Thu, 15 Feb 2007 00:06:26 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.771,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.299
X-Spam-Level: 
Received: from [66.93.162.135] ([66.93.162.135])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Thu, 15 Feb 2007 00:06:24 -0800
In-Reply-To: <7t5sld76e7t.fsf@jdc-xdm1.cisco.com>
References: 
	<15EF3112-1C42-4565-961A-952484DF8E69@nominum.com>
	<7t5sld76e7t.fsf@jdc-xdm1.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <576F7DCB-2D33-492B-8909-D68C3AD5FD14@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] Background on CMTSs and routing
Date: Thu, 15 Feb 2007 01:06:13 -0700
To: Ole Troan 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: dhcwg , "Woundy,
	Richard" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 15, 2007, at 1:02 AM, Ole Troan wrote:
> route injection from the edge does require state in the L3 edge
> device. the act of doing prefix delegation does create this state and
> it is very convenient to take advantage of that so that the edge
> router can inject the route based on PD state.
>
> since a DHCP relay should (at least architecturally) be stateless,  
> then
> a DHCP relay and edge route injection are mutually exclusive.

So do you have any thoughts about how we should actually do this?    
What you're saying implies to me that the DHCP server doing the PD  
should somehow contact the correct router, which might be identified  
by the relay agent, but that the relay agent oughtn't to do anything  
more than identify which router to talk to.   But I am afraid I may  
be reading too much into what you've said.



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



From dhcwg-bounces@ietf.org Thu Feb 15 03:14:01 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHbjn-000260-A3; Thu, 15 Feb 2007 03:13:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHbjm-00025v-13
	for dhcwg@ietf.org; Thu, 15 Feb 2007 03:13:06 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHbjk-0002rh-O6
	for dhcwg@ietf.org; Thu, 15 Feb 2007 03:13:06 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-5.cisco.com with ESMTP; 15 Feb 2007 00:13:05 -0800
X-IronPort-AV: i="4.14,173,1170662400"; 
	d="scan'208"; a="389276025:sNHT44097540"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1F8D42x014851; 
	Thu, 15 Feb 2007 00:13:04 -0800
Received: from jdc-xdm1.cisco.com (jdc-xdm1.cisco.com [10.70.237.12])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1F8D3Dk023076;
	Thu, 15 Feb 2007 00:13:03 -0800 (PST)
Received: (otroan@localhost) by jdc-xdm1.cisco.com (8.11.2/CISCO.WS.1.2) id
	l1F8D2s26124; Thu, 15 Feb 2007 17:13:02 +0900 (JST)
X-Authentication-Warning: jdc-xdm1.cisco.com: otroan set sender to
	ot@cisco.com using -f
From: Ole Troan 
To: Ted Lemon 
Subject: Re: [dhcwg] Background on CMTSs and routing
References: 
	<15EF3112-1C42-4565-961A-952484DF8E69@nominum.com>
	<7t5sld76e7t.fsf@jdc-xdm1.cisco.com>
	<576F7DCB-2D33-492B-8909-D68C3AD5FD14@nominum.com>
Date: Thu, 15 Feb 2007 17:13:02 +0900
In-Reply-To: <576F7DCB-2D33-492B-8909-D68C3AD5FD14@nominum.com> (Ted Lemon's
	message of "Thu, 15 Feb 2007 01:06:13 -0700")
Message-ID: <7t5k5yj6dpt.fsf@jdc-xdm1.cisco.com>
User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.2.95 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1552; t=1171527184;
	x=1172391184; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=ot@cisco.com;
	z=From:=20Ole=20Troan=20
	|Subject:=20Re=3A=20[dhcwg]=20Background=20on=20CMTSs=20and=20routing
	|Sender:=20; bh=aLDKLJYWzL49S/mbwVFSXdJu6OfW2dEUAhky9zNOdGY=;
	b=E6TApGygH1UxWfNVhUFqyNJCTXnW8/gnK7MxEUhfxh24ytAfnHa3VsgdP336FMqbHv60BDa8
	m4RjHIP8vutX14+jOj1g+VroR/S+ldszc76ZS/MUxvP7C5KxdVOkDrV2;
Authentication-Results: sj-dkim-4; header.From=ot@cisco.com; dkim=pass (sig 
	from cisco.com/sjdkim4002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: dhcwg , "Woundy,
	Richard" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

> On Feb 15, 2007, at 1:02 AM, Ole Troan wrote:
>> route injection from the edge does require state in the L3 edge
>> device. the act of doing prefix delegation does create this state and
>> it is very convenient to take advantage of that so that the edge
>> router can inject the route based on PD state.
>>
>> since a DHCP relay should (at least architecturally) be stateless,
>> then
>> a DHCP relay and edge route injection are mutually exclusive.
>
> So do you have any thoughts about how we should actually do this?    
> What you're saying implies to me that the DHCP server doing the PD  
> should somehow contact the correct router, which might be identified  
> by the relay agent, but that the relay agent oughtn't to do anything  
> more than identify which router to talk to.   But I am afraid I may  
> be reading too much into what you've said.

in the edge route injection case (there are many others), which if I
remember correctly is described loosely in RFC3633, the delegating
router must be the first L3 device. so in that case DHCP is kept only
on the edge of the ISP network.

a backend provisioning system can be used. the DHCP server/delegating
router on the edge device can synthesize DHCP replies based on
information from e.g a RADIUS server.

if an "end-to-end" DHCP infrastructure is wanted, I suppose one could
use a DHCP proxy on the edge device. server downstream, client
upstream. that should take care of the state maintenance issues that
came up with the RAAN proposal.

cheers,
Ole

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



From dhcwg-bounces@ietf.org Thu Feb 15 03:15:20 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHbls-00057v-H6; Thu, 15 Feb 2007 03:15:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHblq-000559-Uv
	for dhcwg@ietf.org; Thu, 15 Feb 2007 03:15:14 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHblp-0003Ek-K2
	for dhcwg@ietf.org; Thu, 15 Feb 2007 03:15:14 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id 2AFE156836;
	Thu, 15 Feb 2007 00:15:10 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.762,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.308
X-Spam-Level: 
Received: from [66.93.162.135] ([66.93.162.135])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Thu, 15 Feb 2007 00:15:09 -0800
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <2AFB2BA1-456B-40CA-8A0B-57BCA7C6FB84@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities
Date: Thu, 15 Feb 2007 01:15:06 -0700
To: "Woundy, Richard" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 15, 2007, at 1:02 AM, Woundy, Richard wrote:
> Maybe you can help me understand what part I "contrived"? Business
> customers want multihoming? (they do) Cable modem going offline?
> (unfortunately they do) The PI prefix remaining as a "stale route" in
> the IGP routing table because the DHCP server can't detect the modem
> going down? (tell me how *not* to make this happen)

What seems contrived to me is doing prefix delegation in a case where  
you have a provider-independent prefix.   Why wouldn't you just use  
straightforward border routing protocols in this case?

> Here is my expected (business) customer experience. The customer  
> orders
> broadband service from the cable operator, and provides the PI prefix.
> The cable operator sends a black box (cable modem) that is supposed to
> connect to the customer's network and to the cable/coax network. The
> black box is connected and turned on, and now the customer has  
> broadband
> IPv6 Internet service.

I think this is the crux of why we are thinking about this  
differently.   As a customer, there is no way that I want you  
configuring my router's addressing from a DHCP server if I have a  
provider-independent prefix.   I realize that that seems backwards  
from the perspective of the ISP, but the customer only has one P-I  
prefix, so they don't mind configuring it manually.   Or so I would  
naturally assume, absent some reason to assume differently.

When you say that this is your business customer experience, does  
this mean that you have actual customers (that is, people purchasing  
service from ISPs, not ISPs) doing this right now who asked for and  
are happy with this solution?   Or is this a use case that's still  
theoretical at this stage?

> If there are two routers attached to the same Ethernet, then they both
> independently announce to the IGP that each can reach the  
> Ethernet's IP
> subnet. The "magic" of routing is that remote routers will forward  
> that
> Ethernet's traffic to the local router that is "closer". If one  
> router's
> Ethernet interface goes down, then that router withdraws the  
> Ethernet IP
> subnet from the IGP, and all of the remote routers forward that
> Ethernet's traffic to the *other* local router, automatically.
>
> Do you agree that this is how routing works in "IPv4-land" today? In
> fact, this isn't really different from how routing works in IPv4 cable
> networks, either.

Yes, this is exactly how I think routing works in IPv4-land today.    
That is, there is no DHCP server involved at all.



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



From dhcwg-bounces@ietf.org Thu Feb 15 03:49:03 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHcIC-0008K7-MD; Thu, 15 Feb 2007 03:48:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHcIA-0008IV-Oq
	for dhcwg@ietf.org; Thu, 15 Feb 2007 03:48:38 -0500
Received: from pacdcimo01.cable.comcast.com ([24.40.8.145])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHcI8-0002ND-Cv
	for dhcwg@ietf.org; Thu, 15 Feb 2007 03:48:38 -0500
Received: from ([24.40.15.92])
	by pacdcimo01.cable.comcast.com with ESMTP  id KP-BXT38.618114;
	Thu, 15 Feb 2007 03:48:18 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	PACDCEXCSMTP03.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 03:48:18 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Delegated prefix managed by multiple entities
Date: Thu, 15 Feb 2007 03:48:17 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Delegated prefix managed by multiple entities
Thread-Index: AcdQ2XmklE+hzhXfTDueemmu3PpJ2AAATWFQ
From: "Woundy, Richard" 
To: "Ted Lemon" 
X-OriginalArrivalTime: 15 Feb 2007 08:48:18.0055 (UTC)
	FILETIME=[09CA1970:01C750DE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: dhcwg , "Woundy,
	Richard" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

>When you say that this is your business customer experience, does this
mean that you have actual customers (that is, people purchasing service
from ISPs, not ISPs) doing this right now who asked for and are happy
with this solution?   Or is this a use case that's still theoretical at
this stage?

We have customers with pretty similar IPv4 service today. Let me more
precise about what I mean:

> Here is my expected (business) customer experience. The customer
> orders
> broadband service from the cable operator, and provides the PI prefix.

In today's world, most business customers would get an IPv4 subnet from
us, but some customers might bring their own IPv4 subnets. In the latter
case, we may have to reconfigure our external BGP routers to announce
the customer's subnet to the rest of the world (depending on whether we
use "white lists" or "black lists" for eBGP subnet reachability); this
extra work is part of the reason why customer-owned subnets would be
strongly discouraged (customer-owned subnets also cause route table
growth in the default-free backbone, which also isn't good). In any
case, we would reconfigure the CMTS (manually) to expect the customer
subnet to be announced by the "cable router" at the customer premise via
RIP.

> The cable operator sends a black box (cable modem) that is supposed to
> connect to the customer's network and to the cable/coax network. The

Today, we would install a "cable router" (a cable modem with router
functionality) at the customer's premise, with the customer's IPv4
subnet and RIP routing configured by the cable operator (either manually
in advance, or via TFTP configuration download to the cable router).

> black box is connected and turned on, and now the customer has =20
> broadband IPv6 Internet service.

Well, they would have v4 service today, not v6. :)

The "cable router" at the customer premise would boot on the DOCSIS
network, the CMTS and cable router would exchange RIP messages, and the
CMTS would pass the customer subnet received from RIP (and expected from
the customer according to its configuration) into the IGP, which would
ultimately be advertised to the Internet at large.

A portion of these customers do some form of multi-homing, from
anecdotal evidence, but that's harder for us to know about.

-- Rich

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20
Sent: Thursday, February 15, 2007 3:15 AM
To: Woundy, Richard
Cc: dhcwg
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities


On Feb 15, 2007, at 1:02 AM, Woundy, Richard wrote:
> Maybe you can help me understand what part I "contrived"? Business=20
> customers want multihoming? (they do) Cable modem going offline?=20
> (unfortunately they do) The PI prefix remaining as a "stale route" in=20
> the IGP routing table because the DHCP server can't detect the modem=20
> going down? (tell me how *not* to make this happen)

What seems contrived to me is doing prefix delegation in a case where =20
you have a provider-independent prefix.   Why wouldn't you just use =20
straightforward border routing protocols in this case?

> Here is my expected (business) customer experience. The customer
> orders
> broadband service from the cable operator, and provides the PI prefix.
> The cable operator sends a black box (cable modem) that is supposed to
> connect to the customer's network and to the cable/coax network. The
> black box is connected and turned on, and now the customer has =20
> broadband
> IPv6 Internet service.

I think this is the crux of why we are thinking about this =20
differently.   As a customer, there is no way that I want you =20
configuring my router's addressing from a DHCP server if I have a =20
provider-independent prefix.   I realize that that seems backwards =20
from the perspective of the ISP, but the customer only has one P-I =20
prefix, so they don't mind configuring it manually.   Or so I would =20
naturally assume, absent some reason to assume differently.

When you say that this is your business customer experience, does =20
this mean that you have actual customers (that is, people purchasing =20
service from ISPs, not ISPs) doing this right now who asked for and =20
are happy with this solution?   Or is this a use case that's still =20
theoretical at this stage?

> If there are two routers attached to the same Ethernet, then they both

> independently announce to the IGP that each can reach the
> Ethernet's IP
> subnet. The "magic" of routing is that remote routers will forward =20
> that
> Ethernet's traffic to the local router that is "closer". If one =20
> router's
> Ethernet interface goes down, then that router withdraws the =20
> Ethernet IP
> subnet from the IGP, and all of the remote routers forward that
> Ethernet's traffic to the *other* local router, automatically.
>
> Do you agree that this is how routing works in "IPv4-land" today? In=20
> fact, this isn't really different from how routing works in IPv4 cable

> networks, either.

Yes, this is exactly how I think routing works in IPv4-land today.   =20
That is, there is no DHCP server involved at all.



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



From dhcwg-bounces@ietf.org Thu Feb 15 04:11:25 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHcde-0005fE-Qm; Thu, 15 Feb 2007 04:10:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHcdd-0005en-9h
	for dhcwg@ietf.org; Thu, 15 Feb 2007 04:10:49 -0500
Received: from pacdcimo01.cable.comcast.com ([24.40.8.145])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHcdc-0006Mi-0U
	for dhcwg@ietf.org; Thu, 15 Feb 2007 04:10:49 -0500
Received: from ([10.52.116.30])
	by pacdcimo01.cable.comcast.com with ESMTP  id KP-BXT38.618219;
	Thu, 15 Feb 2007 04:10:34 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	PAOAKEXCSMTP01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 04:10:33 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Delegated prefix managed by multiple entities
Date: Thu, 15 Feb 2007 04:10:33 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Delegated prefix managed by multiple entities
Thread-Index: AcdQ1FLhAgeuJ+1wT9S0d5vtrengBAAA2i5w
From: "Woundy, Richard" 
To: "Chuck Anderson" ,
	"dhcwg" 
X-OriginalArrivalTime: 15 Feb 2007 09:10:33.0738 (UTC)
	FILETIME=[25EB26A0:01C750E1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: "Woundy, Richard" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

>Especially in the multi-homed case, anything other than the latter
solution is broken by design.

Yes, I totally agree, that was my point.

>If you want to multi-home, you have to expect to run a real routing
protocol on the customer's router.

Sigh. If that is required (I'm not sure I totally agree, but I
understand why you make that assertion), then I suspect that (1)
multi-homed customers shouldn't bother using DHCP-PD (they must
configure their edge router manually in all cases - sorry), and/or (2)
the DHCP-PD protocol solution needs to be reworked to configure both
sides of the routing adjacency (RIP, OSPF/IS-IS, or BGP) between the ISP
Edge Router and the customer router.

I think the former choice is giving up. But that's just my opinion.

For the latter choice, I think that Ole just might be on the right
track:

>if an "end-to-end" DHCP infrastructure is wanted, I suppose one could
use a DHCP proxy on the edge device. Server downstream, client upstream.
that should take care of the state maintenance issues that came up with
the RAAN proposal.

-- Rich

-----Original Message-----
From: Chuck Anderson [mailto:cra@WPI.EDU]=20
Sent: Thursday, February 15, 2007 2:37 AM
To: dhcwg
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities


On Thu, Feb 15, 2007 at 12:23:33AM -0700, Ted Lemon wrote:
> >You need routability for the prefixes handed via PD; whether the
> >route is
> >valid for the lease lifetime, or only when the interface is really
> >reachable (information not always available, subject to crashes =20
> >somewhere
> >on the path, etc) is a matter of preference..
>=20
> Clearly the latter is preferable to the former, all other factors
> being equal.

Being a network engineer, I have to agree with Ted here.  Especially=20
in the multi-homed case, anything other than the latter solution is=20
broken by design.  If you want to multi-home, you have to expect to=20
run a real routing protocol on the customer's router.  I would be=20
strongly against any attempt to piggyback routing on top of DHCP.


_______________________________________________
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-bounces@ietf.org Thu Feb 15 04:15:29 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHchJ-00084p-Gf; Thu, 15 Feb 2007 04:14:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHchI-000837-Ip
	for dhcwg@ietf.org; Thu, 15 Feb 2007 04:14:36 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHchH-0006qO-5W
	for dhcwg@ietf.org; Thu, 15 Feb 2007 04:14:36 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id B256B5682B;
	Thu, 15 Feb 2007 01:14:20 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.753,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.317
X-Spam-Level: 
Received: from [66.93.162.135] ([66.93.162.135])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Thu, 15 Feb 2007 01:14:18 -0800
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities
Date: Thu, 15 Feb 2007 02:14:11 -0700
To: "Woundy, Richard" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

What you're saying is actually pretty close to my picture of what was  
going on in an IPv4 network.   Including the grottiness of having to  
deal with the customer's special IP address range that's alien to  
your network.   And clearly we would like the end result of what we  
do to be that the grottiness is eliminated, you can provide them with  
the service they want, they can do multihoming, and it all works with  
no pain, so that there's no disincentive to give the customer what  
they need, and what the customer gets is convenient and reliable.

What I question in the scenario you are describing as your present  
reality, versus the scenario you are proposing for DHCPv6, is whether  
or not what is being proposed actually makes things better, or  
whether it just makes things different.   And that's why I keep  
asking questions.   The reason I call your IPv6 PD scenario  
"contrived" is because it doesn't match my understanding of how  
things are done now, and I don't think it's a natural place to go  
from where we are now.

I think that it would be really good if the interested parties could  
sit down together sometime when we're in Prague and talk about  
this.   Possibly part of the problem is that since I wasn't in San  
Diego, I am missing some state that would make it clearer to me why  
you went down the route that led us to our recent lack of consensus.



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



From dhcwg-bounces@ietf.org Thu Feb 15 04:36:57 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHd2c-00063v-6b; Thu, 15 Feb 2007 04:36:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHd2b-00063q-FB
	for dhcwg@ietf.org; Thu, 15 Feb 2007 04:36:37 -0500
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]
	helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HHd2a-0002XA-4S
	for dhcwg@ietf.org; Thu, 15 Feb 2007 04:36:37 -0500
Received: from ([10.195.246.152])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-TDCH7.30403653;
	Thu, 15 Feb 2007 04:36:19 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	NJMDCEXCRLY01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 04:36:19 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Background on CMTSs and routing
Date: Thu, 15 Feb 2007 04:36:18 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Background on CMTSs and routing
Thread-Index: AcdQ27fU1KRmvQKLREybqag1gg0J3QABVHHA
From: "Woundy, Richard" 
To: "Ole Troan" ,
	"Ted Lemon" 
X-OriginalArrivalTime: 15 Feb 2007 09:36:19.0263 (UTC)
	FILETIME=[BF1F8CF0:01C750E4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

>if an "end-to-end" DHCP infrastructure is wanted, I suppose one could
use a DHCP proxy on the edge device. server downstream, client upstream.
that should take care of the state maintenance issues that came up with
the RAAN proposal.

Ole, please allow me attempt to re-state. And allow me to inject a
"static versus dynamic routing" component as well.

In normal operation, the customer premise router (requesting router)
requests a prefix from the ISP edge router (delegating router), similar
to RFC 3633. If the ISP edge router does not know the prefix / lifetime
for the requesting router, then ISP edge router uses "proxy DHCP-PD" to
request a prefix from the DHCP server on behalf of the customer premise
router. The ISP edge router may already know this information based on a
previous boot cycle of the customer premise router.

Once the ISP edge router knows the prefix / lifetime, then the ISP edge
router could either (1) statically inject the delegated prefix into the
IGP on behalf of the customer premise router, or (2) set up a routing
protocol adjacency (RIP, OSPF/IS-IS, BGP) with the customer premise
router, so that when the ISP edge router learns of the delegated prefix
from the customer premise router, it can redistribute the prefix into
the IGP of the ISP. The ISP edge router then responds to the PD request
of the customer premise router.

The customer premise router behavior would depend on the ISP edge router
behavior, which would be commmnicated in the DHCP-PD message. If the ISP
edge router expects a routing protocol adjacency with the customer
premise router, then the customer premise router needs to set up a
routing protocol adjacency (RIP, OSPF/IS-IS, BGP) with the ISP edge
router that advertises reachability to the delegated prefix.

If the ISP edge router statically injects the delegated prefixes into
the IGP, then the ISP edge router must remove those prefixes whenever it
discovers the associated customer premise router is unreachable.
Otherwise, the ISP edge router will determine this by some dynamic
routing protocol.

Basically, this allows for "static routing" and "dynamic routing",
without using DHCP as a routing protocol in either case.

Based on the email list discussions so far, this leaves a few unanswered
questions, that seem tractable:

1. When would "static routing" be acceptable? Single-homed customers
only? Or according to the decision of the service provider?

2. Should "static routing" versus "dynamic routing" setup be managed at
the ISP edge router, or in the DHCP server?

3. How much effort is required to set up a routing adjacency for the
"dynamic routing" case (e.g. matching routing protocol timers)?

-- Rich

-----Original Message-----
From: Ole Troan [mailto:ot@cisco.com]=20
Sent: Thursday, February 15, 2007 3:13 AM
To: Ted Lemon
Cc: Woundy, Richard; dhcwg
Subject: Re: [dhcwg] Background on CMTSs and routing


> On Feb 15, 2007, at 1:02 AM, Ole Troan wrote:
>> route injection from the edge does require state in the L3 edge=20
>> device. the act of doing prefix delegation does create this state and

>> it is very convenient to take advantage of that so that the edge=20
>> router can inject the route based on PD state.
>>
>> since a DHCP relay should (at least architecturally) be stateless,=20
>> then a DHCP relay and edge route injection are mutually exclusive.
>
> So do you have any thoughts about how we should actually do this?   =20
> What you're saying implies to me that the DHCP server doing the PD
> should somehow contact the correct router, which might be identified =20
> by the relay agent, but that the relay agent oughtn't to do anything =20
> more than identify which router to talk to.   But I am afraid I may =20
> be reading too much into what you've said.

in the edge route injection case (there are many others), which if I
remember correctly is described loosely in RFC3633, the delegating
router must be the first L3 device. so in that case DHCP is kept only on
the edge of the ISP network.

a backend provisioning system can be used. the DHCP server/delegating
router on the edge device can synthesize DHCP replies based on
information from e.g a RADIUS server.

if an "end-to-end" DHCP infrastructure is wanted, I suppose one could
use a DHCP proxy on the edge device. server downstream, client upstream.
that should take care of the state maintenance issues that came up with
the RAAN proposal.

cheers,
Ole

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



From dhcwg-bounces@ietf.org Thu Feb 15 04:56:28 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHdLR-00012n-JU; Thu, 15 Feb 2007 04:56:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHdLP-00012J-F9
	for dhcwg@ietf.org; Thu, 15 Feb 2007 04:56:03 -0500
Received: from nf-out-0910.google.com ([64.233.182.187])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHdLN-0007Al-UW
	for dhcwg@ietf.org; Thu, 15 Feb 2007 04:56:03 -0500
Received: by nf-out-0910.google.com with SMTP id l36so1080738nfa
	for ; Thu, 15 Feb 2007 01:56:01 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=dIp0YNQatPzdfPdXVVJ0tFUtQ6jwRX1KtDtWHYuS+DqIhEoLByXvh+ffZ1kVDwIXSzCkKyZEjKDPFKhR/EJyJQywUno6z7g6oX4+8vmyGBl3EA8WPwC0dWeUgbqDHvMUsLye3UNi+Zvc79PFVWb/oHhX97EBneJQXK6h1hjm0+0=
Received: by 10.82.107.15 with SMTP id f15mr2386070buc.1171533360869;
	Thu, 15 Feb 2007 01:56:00 -0800 (PST)
Received: by 10.82.166.12 with HTTP; Thu, 15 Feb 2007 01:56:00 -0800 (PST)
Message-ID: 
Date: Thu, 15 Feb 2007 15:26:00 +0530
From: Maverick 
To: dhcwg@ietf.org, i-d-announce@ietf.org, 
	"Internet-Drafts@ietf.org" 
MIME-Version: 1.0
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: 
Subject: [dhcwg] Issue related to DHCPv6 Client FQDN Option. RFC 4704
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1197581239=="
Errors-To: dhcwg-bounces@ietf.org

--===============1197581239==
Content-Type: multipart/alternative; 
	boundary="----=_Part_12213_275814.1171533360842"

------=_Part_12213_275814.1171533360842
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi All,
I have a query related to RFC 4704. In section 6.1 the RFC says
"The Server MAY Perform these updates even if the client message did not
carry the Clients FQDN option"

How is it possible for the DHCP server to carry out DNS Updates without the
FQDN as the server will not get the Hostname either.

Can someone tell what should be the server behaviour for DNS updates when
the client does not send the FQDN Option.

Thanks in Advance,
M.

------=_Part_12213_275814.1171533360842
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


Hi All,


I have a query related to RFC 4704. In section 6.1 the RFC says


"The Server MAY Perform these updates even if the client message did not carry the Clients FQDN option"


 


How is it possible for the DHCP server to carry out DNS Updates without the FQDN as the server will not get the Hostname either.


 


Can someone tell what should be the server behaviour for DNS updates when the client does not send the FQDN Option.


 


Thanks in Advance,


M.


------=_Part_12213_275814.1171533360842--


--===============1197581239==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1197581239==--




From dhcwg-bounces@ietf.org Thu Feb 15 04:57:44 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHdN0-0001Jg-D2; Thu, 15 Feb 2007 04:57:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHdMz-0001Ja-9j
	for dhcwg@ietf.org; Thu, 15 Feb 2007 04:57:41 -0500
Received: from nf-out-0910.google.com ([64.233.182.188])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHdMy-0007Ok-0e
	for dhcwg@ietf.org; Thu, 15 Feb 2007 04:57:41 -0500
Received: by nf-out-0910.google.com with SMTP id l36so1081250nfa
	for ; Thu, 15 Feb 2007 01:57:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
	b=Jr0BdOouE+gBCHvjOc6n+Hcx6VTUqz7fylrhERX4ji6nRDHpey4ei8wQVav73gJiCIwudwX6cHG6Uz9ZwDUXTi9gEDtwlPOzulLnJoHB6rHHgGeUCn5rzgH2/p6mTKd0EYfxldu79RBDRtJ47X+4fpmNgA8a0lFRpd7qUB93fPg=
Received: by 10.82.153.5 with SMTP id a5mr2382831bue.1171533459016;
	Thu, 15 Feb 2007 01:57:39 -0800 (PST)
Received: by 10.82.166.12 with HTTP; Thu, 15 Feb 2007 01:57:38 -0800 (PST)
Message-ID: 
Date: Thu, 15 Feb 2007 15:27:38 +0530
From: Maverick 
To: dhcwg@ietf.org
In-Reply-To: 
MIME-Version: 1.0
References: 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Subject: [dhcwg] Re: Issue related to DHCPv6 Client FQDN Option. RFC 4704
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1283021459=="
Errors-To: dhcwg-bounces@ietf.org

--===============1283021459==
Content-Type: multipart/alternative; 
	boundary="----=_Part_12257_29229543.1171533458987"

------=_Part_12257_29229543.1171533458987
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>
> Hi All,
> I have a query related to RFC 4704. In section 6.1 the RFC says
> "The Server MAY Perform these updates even if the client message did not
> carry the Clients FQDN option"
>
> How is it possible for the DHCP server to carry out DNS Updates without
> the FQDN as the server will not get the Hostname either.
>
> Can someone tell what should be the server behaviour for DNS updates when
> the client does not send the FQDN Option.
>
> Thanks in Advance,
> M.
>

------=_Part_12257_29229543.1171533458987
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline






Hi All,


I have a query related to RFC 4704. In section 6.1 the RFC says


"The Server MAY Perform these updates even if the client message did not carry the Clients FQDN option"


 


How is it possible for the DHCP server to carry out DNS Updates without the FQDN as the server will not get the Hostname either.


 


Can someone tell what should be the server behaviour for DNS updates when the client does not send the FQDN Option.


 


Thanks in Advance,


M.



------=_Part_12257_29229543.1171533458987--


--===============1283021459==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1283021459==--




From dhcwg-bounces@ietf.org Thu Feb 15 10:13:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHiHp-0002zO-QU; Thu, 15 Feb 2007 10:12:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHiHo-0002z6-FP
	for dhcwg@ietf.org; Thu, 15 Feb 2007 10:12:40 -0500
Received: from slb-smtpout-01.boeing.com ([130.76.64.48]
	helo=slb-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHiHl-00053K-4U
	for dhcwg@ietf.org; Thu, 15 Feb 2007 10:12:40 -0500
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6])
	by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1FFCYd6005945
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 15 Feb 2007 07:12:35 -0800 (PST)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1FFCYH0014093; Thu, 15 Feb 2007 09:12:34 -0600 (CST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1FFCOTj013669; Thu, 15 Feb 2007 09:12:34 -0600 (CST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Feb 2007 07:12:13 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Background on CMTSs and routing
Date: Thu, 15 Feb 2007 07:12:13 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017746D9@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Background on CMTSs and routing
Thread-Index: AcdQY3NT6b086CsYSsOe3MtHPVTS4gAN0SWQAB4E2CA=
References: 
From: "Templin, Fred L" 
To: "Woundy, Richard" ,
	"dhcwg" 
X-OriginalArrivalTime: 15 Feb 2007 15:12:13.0990 (UTC)
	FILETIME=[AC46D460:01C75113]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

> To be fair, Fred Templin has some other use case in mind, in which the
> relay agent is NOT a router,
> .

No - the relay agent is a router in my use case; it's just
selective about which routes it will inject into the IGP.
But I'll agree that it is a different use case - I didn't
even know what CMTS stood for before seeing some of the
messages on this list.

Fred
fred.l.templin@boeing.com

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



From dhcwg-bounces@ietf.org Thu Feb 15 10:44:38 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHimI-0003PJ-Gv; Thu, 15 Feb 2007 10:44:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHimH-0003NK-Ri
	for dhcwg@ietf.org; Thu, 15 Feb 2007 10:44:09 -0500
Received: from stl-smtpout-01.boeing.com ([130.76.96.56]
	helo=stl-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHimF-0002dv-KT
	for dhcwg@ietf.org; Thu, 15 Feb 2007 10:44:09 -0500
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4])
	by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1FFi6b9010652
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 15 Feb 2007 09:44:06 -0600 (CST)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1FFi565002490; Thu, 15 Feb 2007 07:44:05 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1FFi211002350; Thu, 15 Feb 2007 07:44:05 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Feb 2007 07:44:00 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Background on CMTSs and routing
Date: Thu, 15 Feb 2007 07:44:00 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017746DA@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <7E2EDCCE-6335-44A7-8E59-46037969CB69@nominum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Background on CMTSs and routing
Thread-Index: AcdQvxAWMqdonKwxSiiKsdJ7do+PHAAVmZjQ
References: <15EF3112-1C42-4565-961A-952484DF8E69@nominum.com>
	<7E2EDCCE-6335-44A7-8E59-46037969CB69@nominum.com>
From: "Templin, Fred L" 
To: "Ted Lemon" ,
	"Richard Woundy" 
X-OriginalArrivalTime: 15 Feb 2007 15:44:00.0975 (UTC)
	FILETIME=[1CEDA5F0:01C75118]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

> On Feb 14, 2007, at 10:01 PM, Ted Lemon wrote:
> > I guess if the lack of a route to the CMTS is discovered high in =20
> > the network hierarchy,
>=20
> This was poorly phrased.   What I meant is that if the lack of a =20
> route to the customer is discovered by the CMTS and quickly =20
> propagated into the network, there may be some minor benefits to =20
> that, but I don't find them particularly compelling.

I don't want to muddy the waters with my limited understanding
of the CMTS use case, but it seems to me that if some/all of
the routes pertaining to a particular requesting router become
defunct then prospective correspondent nodes would probably
appreciate getting "unreachable" feedback from the CMTS.

Especially with IPv6, the unreachables could give correspondent
nodes an early indication that they might want to try again with
a different address - and, that might make all the difference
between communication failures and a successful connection.

Fred
fred.l.templin@boeing.com=20

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



From dhcwg-bounces@ietf.org Thu Feb 15 11:29:58 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHjTr-00057E-Q5; Thu, 15 Feb 2007 11:29:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHjTq-00051d-9p
	for dhcwg@ietf.org; Thu, 15 Feb 2007 11:29:10 -0500
Received: from goliath.isc.org ([2001:4f8:3:bb::72])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHjTp-0005v6-VR
	for dhcwg@ietf.org; Thu, 15 Feb 2007 11:29:10 -0500
Received: by goliath.isc.org (Postfix, from userid 10200)
	id 56C8E5A6EB; Thu, 15 Feb 2007 08:28:49 -0800 (PST)
Date: Thu, 15 Feb 2007 08:28:49 -0800
From: "David W. Hankins" 
To: Maverick 
Subject: Re: [dhcwg] Issue related to DHCPv6 Client FQDN Option. RFC 4704
Message-ID: <20070215162849.GA14887@isc.org>
References: 
Mime-Version: 1.0
In-Reply-To: 
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0751818278=="
Errors-To: dhcwg-bounces@ietf.org


--===============0751818278==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf"
Content-Disposition: inline


--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Feb 15, 2007 at 03:26:00PM +0530, Maverick wrote:
> How is it possible for the DHCP server to carry out DNS Updates without the
> FQDN as the server will not get the Hostname either.

In this case, the DHCP server is assigning a name irrespective of
whatever name the client has assigned to itself.

This can be an individual configuration parameter on a client by
client basis - the operator enters an FQDN for each device they
know not to provide the information.  Or it can be created
dynamically from information known about the client.

As an example, it is somewhat common practice among ISC DHCP operators
to construct FQDN's from some information about the client, usually
the hardware address, or more commonly (I think) the last octet(s) of
the leased IP address:

	dhcp-00-0C-76-16-40-40.example.com.	IN A 192.168.0.1
	dhcp-247.example.com.			IN A 10.0.0.247

In this case the operator knows 'example.com' as a given, as it is
their domain and they've configured the neccessary access lists or
keys for dynamic updates.  The hostname prefix is created through
configuration syntax.

> Can someone tell what should be the server behaviour for DNS updates when
> the client does not send the FQDN Option.

The RFCs intentionally leave this entirely up to the server
implementor and/or operator.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

--J2SCkAp4GZ/dPZZf
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFF1IpBcXeLeWu2vmoRAkgmAJ0Wrn5EvY+GQ3SHKGRX88sG7gM++QCgpqr4
/5srEV+EH14aQZzvq4aZ3NU=
=fe4G
-----END PGP SIGNATURE-----

--J2SCkAp4GZ/dPZZf--


--===============0751818278==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0751818278==--




From dhcwg-bounces@ietf.org Thu Feb 15 22:37:07 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHttT-0002FP-78; Thu, 15 Feb 2007 22:36:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHttR-0002E2-ST
	for dhcwg@ietf.org; Thu, 15 Feb 2007 22:36:17 -0500
Received: from ind-iport-1.cisco.com ([64.104.129.195])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHttN-0003o7-9L
	for dhcwg@ietf.org; Thu, 15 Feb 2007 22:36:17 -0500
Received: from ind-dkim-2.cisco.com ([64.104.140.59])
	by ind-iport-1.cisco.com with ESMTP; 16 Feb 2007 21:54:06 +0530
X-IronPort-AV: i="4.14,179,1170613800"; 
	d="scan'208"; a="75580206:sNHT64393748"
Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94])
	by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1G3aAnR009180; 
	Fri, 16 Feb 2007 09:06:10 +0530
Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com
	[64.104.123.72])
	by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1G3a9U3026257; 
	Fri, 16 Feb 2007 11:36:09 +0800 (CST)
Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by
	xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Feb 2007 11:36:08 +0800
Received: from emakko.cisco.com ([64.104.9.16]) by xfe-hkg-412.apac.cisco.com
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Feb 2007 11:36:08 +0800
Received: from mstenber by emakko.cisco.com with local (Exim 4.62)
	(envelope-from )
	id 1HHttO-0006W6-1L; Fri, 16 Feb 2007 12:36:14 +0900
From: Markus Stenberg 
To: "Woundy, Richard" 
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities
Organization: cisco Systems, Inc.
References: 
Date: Fri, 16 Feb 2007 12:36:14 +0900
In-Reply-To: 
	(Richard Woundy's message of "Thu, 15 Feb 2007 04:10:33 -0500")
Message-ID: <87mz3ercy9.fsf@emakko.cisco.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-OriginalArrivalTime: 16 Feb 2007 03:36:08.0319 (UTC)
	FILETIME=[9868F0F0:01C7517B]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=973; t=1171596971;
	x=1172460971; c=relaxed/simple; s=inddkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mstenber@cisco.com;
	z=From:=20Markus=20Stenberg=20
	|Subject:=20Re=3A=20[dhcwg]=20Delegated=20prefix=20managed=20by=20multipl
	e=20entities |Sender:=20;
	bh=u9BKnUFx8i0ifLGRZkSRgpubcC9q2lYogSVHl5/efmE=;
	b=FGxOhjuEidDtTmW2XuySh5Qxmh3j1jTsmVqEx6G3HUZzsMxha4+FOXjqztXL98tdg5bwiLgd
	EF8Lqt2FSmgrvnUpmQBRV2EdNeszYkPC88ZZjKD/QMoOJcjJUXL0nLOZ;
Authentication-Results: ind-dkim-2; header.From=mstenber@cisco.com; dkim=pass (
	sig from cisco.com/inddkim2002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: dhcwg , Chuck Anderson 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

"Woundy, Richard"  writes:
> For the latter choice, I think that Ole just might be on the right
> track:
>
>>if an "end-to-end" DHCP infrastructure is wanted, I suppose one could
>> use a DHCP proxy on the edge device. Server downstream, client upstream.
>> that should take care of the state maintenance issues that came up with
>> the RAAN proposal.

Yes. There's the eternal argument of proxy state machine complexity, but
I'm willing to bet that it isn't orders of magnitude more complex than
'stateful' relay in and of itself. 

And given the choice of 'bit more complex, but well understood and correct'
versus 'simple hack, but mostly works', I'd go for the former.

Of course, it doesn't remove the routing maintenace problems (due to
potential lack of l2 link state knowledge in the first-hop server), but it
makes life considerably easier; all you need is .. love? (not really; BFD
on the client.)

-Markus

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



From dhcwg-bounces@ietf.org Thu Feb 15 23:00:20 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HHuGZ-0004wY-4n; Thu, 15 Feb 2007 23:00:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HHuGY-0004wQ-GB
	for dhcwg@ietf.org; Thu, 15 Feb 2007 23:00:10 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHuGX-00078g-4f
	for dhcwg@ietf.org; Thu, 15 Feb 2007 23:00:10 -0500
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-5.cisco.com with ESMTP; 15 Feb 2007 20:00:09 -0800
X-IronPort-AV: i="4.14,179,1170662400"; 
	d="scan'208,217"; a="389680064:sNHT79319632"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1G408A5007887; 
	Thu, 15 Feb 2007 20:00:08 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1G3wTnb016532;
	Thu, 15 Feb 2007 20:00:08 -0800 (PST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 15 Feb 2007 22:59:07 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [dhcwg] Re: Issue related to DHCPv6 Client FQDN Option. RFC 4704
Date: Thu, 15 Feb 2007 22:59:05 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB210346770C@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Re: Issue related to DHCPv6 Client FQDN Option. RFC 4704
Thread-Index: AcdQ58KF2HwFi51OSUqvswGlnu211wAlvsjA
From: "Bernie Volz \(volz\)" 
To: "Maverick" , 
X-OriginalArrivalTime: 16 Feb 2007 03:59:07.0082 (UTC)
	FILETIME=[CE377AA0:01C7517E]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3146; t=1171598408;
	x=1172462408; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20Re=3A=20Issue=20related=20to=20DHCPv6=20Cli
	ent=20FQDN=20Option.=20RFC=204704 |Sender:=20;
	bh=m/UsdEaSnk2eEM/xj4+D9qRa4frBwgNsUMr5B71S9TA=;
	b=EfL5vXLNp8M2YusqL0wY6+29ofxiXosVcTifx8MWAwQ0gvO4yIoE4g1SudlXKjn5PXr7ufRy
	rRh46MkOMzSUOC+G4Grph5PQ8VJXh9udsryAIUDon6trWNc1Ik+mD13G;
Authentication-Results: sj-dkim-5; header.From=volz@cisco.com; dkim=pass (si
	g from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1
Cc: 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1894616426=="
Errors-To: dhcwg-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1894616426==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7517E.CDA5D1F0"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7517E.CDA5D1F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The DHCP server could be configured to generate a name for the client
(and add it to the DNS).
=20
- Bernie

________________________________

From: Maverick [mailto:maverick.zing@gmail.com]=20
Sent: Thursday, February 15, 2007 4:58 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Re: Issue related to DHCPv6 Client FQDN Option. RFC
4704



	Hi All,
	I have a query related to RFC 4704. In section 6.1 the RFC says
	"The Server MAY Perform these updates even if the client message
did not carry the Clients FQDN option"
	=20
	How is it possible for the DHCP server to carry out DNS Updates
without the FQDN as the server will not get the Hostname either.
	=20
	Can someone tell what should be the server behaviour for DNS
updates when the client does not send the FQDN Option.
	=20
	Thanks in Advance,
=09
	M.



------_=_NextPart_001_01C7517E.CDA5D1F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







The DHCP server could be configured to generate =
a name for=20
the client (and add it to the DNS).


 


- Bernie






From: Maverick =
[mailto:maverick.zing@gmail.com]=20

Sent: Thursday, February 15, 2007 4:58 AM
To:=20
dhcwg@ietf.org
Subject: [dhcwg] Re: Issue related to DHCPv6 =
Client=20
FQDN Option. RFC 4704








  
Hi All,

  
I have a query related to RFC 4704. In section 6.1 the RFC =
says

  
"The Server MAY Perform these updates even if the client message =
did not=20
  carry the Clients FQDN option"

  
 

  
How is it possible for the DHCP server to carry out DNS Updates =
without=20
  the FQDN as the server will not get the Hostname either.

  
 

  
Can someone tell what should be the server behaviour for DNS =
updates when=20
  the client does not send the FQDN Option.

  
 

  
Thanks in Advance,

  
M.



------_=_NextPart_001_01C7517E.CDA5D1F0--


--===============1894616426==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1894616426==--




From dhcwg-bounces@ietf.org Fri Feb 16 15:36:18 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HI9nM-0007JM-OT; Fri, 16 Feb 2007 15:35:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HI9nL-0007JH-6C
	for dhcwg@ietf.org; Fri, 16 Feb 2007 15:35:03 -0500
Received: from e5.ny.us.ibm.com ([32.97.182.145])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HI9nJ-0004jD-TO
	for dhcwg@ietf.org; Fri, 16 Feb 2007 15:35:03 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l1GKZ0o5003003
	for ; Fri, 16 Feb 2007 15:35:00 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id
	l1GKYfIR305442 for ; Fri, 16 Feb 2007 15:34:43 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l1GKYeS5009092 for ; Fri, 16 Feb 2007 15:34:40 -0500
Received: from [9.27.40.30] (brabson.raleigh.ibm.com [9.27.40.30])
	by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l1GKYeLf009074 for ; Fri, 16 Feb 2007 15:34:40 -0500
Message-ID: <45D61560.4080103@us.ibm.com>
Date: Fri, 16 Feb 2007 15:34:40 -0500
From: Roy Brabson 
Organization: IBM Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: dhcwg@ietf.org
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Subject: [dhcwg] DUID on a Virtual Host
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

What is the preferred method to generate a DUID on a virtual host?  We
have a shared hardware platform that allows for multiple virtual hosts
to be started.  Each virtual host may share the same hardware (CPUs,
network interface adapters, etc.).

RFC 3315 defines several methods for generating a DUID (DUID-LLT,
DUID-EN, and DUID-LL).  These seem to assume that there is a globally
unique identifier tied to a hardware platform that may be used as a
DUID, which really isn't the case with virtual hosts.

Because of the shared nature of the hardware, DUID-EN can't be used.
DUID-LL can't use the burned-in MAC address, as each adapter may be used
simultaneously by more than one virtual host.  The same thing applies to
DUID-LLT.  Although the timestamp helps, when starting a large number of
virtual hosts for the first time, there is a chance the hosts will
startup at the same time and select the same timestamp, and there isn't
any algorithm defined to detect the collisions.

Is using a manually-configured MAC address for one of the methods
(DUID-LL or DUID-LLT) OK?  We allow a user to override the MAC address
used for the adapter on a per-host basis, and could use the
manually-configured MAC address in generating the DUID.  However, RFC
3315 seems to imply that the link-layer identifier needs to be globally
unique, which isn't necessarily true when manually configuring the MAC
(it really isn't true even when using the burned-in MAC address, but
that is another story.)

If not, does this mean that operating systems running on virtual hosts
need to have some other method defined?  Does anyone else run in a
similar configuration, and if so what did you do?

Roy

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



From dhcwg-bounces@ietf.org Fri Feb 16 16:18:03 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIASY-0007SV-FZ; Fri, 16 Feb 2007 16:17:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIASX-0007SO-Pf
	for dhcwg@ietf.org; Fri, 16 Feb 2007 16:17:37 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIASW-0007jt-DB
	for dhcwg@ietf.org; Fri, 16 Feb 2007 16:17:37 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id 9BA0256876;
	Fri, 16 Feb 2007 13:17:21 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.745,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.325
X-Spam-Level: 
Received: from [66.93.162.135] ([66.93.162.135])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Fri, 16 Feb 2007 13:17:20 -0800
In-Reply-To: <45D61560.4080103@us.ibm.com>
References: <45D61560.4080103@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] DUID on a Virtual Host
Date: Fri, 16 Feb 2007 14:17:14 -0700
To: Roy Brabson 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

My personal take on this is that you should not form a fake mac  
address, because your chances of collision don't get any better than  
if you just chose random times.   What I would suggest is that you  
give the virtualization software a way to communicate a unique id to  
each host, separate from the mac address.   This could be a one-time  
ID, and you could form a DUID-LLT-like identifier from it, except  
that instead of being (link-layer, time) it would be (link-layer,  
time, uid).   I think this would provide sufficient safety from  
collision.   I can help you to write up a draft for it if you would  
like.   It was never the intention in RFC3315 that the DUID types  
specified be the only ones ever used - it's just that none of us  
thought of the virtualization case.



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



From dhcwg-bounces@ietf.org Fri Feb 16 16:53:47 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIB12-0000Ay-7y; Fri, 16 Feb 2007 16:53:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIB10-00009R-HP
	for dhcwg@ietf.org; Fri, 16 Feb 2007 16:53:14 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HIB0x-0005FP-05
	for dhcwg@ietf.org; Fri, 16 Feb 2007 16:53:14 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by sj-iport-1.cisco.com with ESMTP; 16 Feb 2007 13:53:10 -0800
X-IronPort-AV: i="4.14,182,1170662400"; 
	d="scan'208"; a="763228207:sNHT57958280"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1GLr9FB009488
	for ; Fri, 16 Feb 2007 16:53:09 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1GLr4OM013295
	for ; Fri, 16 Feb 2007 16:53:09 -0500 (EST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 16 Feb 2007 16:53:09 -0500
Received: from 161.44.112.45 ([161.44.112.45]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Fri, 16 Feb 2007 21:53:09 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Fri, 16 Feb 2007 16:53:08 -0500
From: Ralph Droms 
To: dhcwg 
Message-ID: 
Thread-Topic: RFC3315 question
Thread-Index: Acc/Psc6ympXzt39SmqKB5J9mTvDMQS1hDHh
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 16 Feb 2007 21:53:09.0304 (UTC)
	FILETIME=[D8C63380:01C75214]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4617; t=1171662789;
	x=1172526789; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20FW=3A=20RFC3315=20question |Sender:=20
	|To:=20dhcwg=20;
	bh=OCQCxP4N+djrYyvnDDMy1P1DXYdd71YHmXpx9093V5I=;
	b=d2Pk8WEGN9qn5ktIJb/72igHa/ultyYyrpKeUesAJGmctCVRTuIgZLEDAj0LVI8QD/L1icCf
	cNm7fVnXod3IR+KqLyUmLCnn+beRdTC3JbwvQuqA2lI0UGkrYIoJAy+G;
Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 1.6 (+)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Subject: [dhcwg] FW: RFC3315 question
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Alain Durand asked me a couple of questions about the definition of the DUID
formats based on link-layer addresses in RFC 3315.  The first question is
about this text, which appears in both section 9.2, DUID Based on Link-layer
Address Plus Time [DUID-LLT], and section 9.4, DUID Based on Link-layer
Address [DUID-LL]:

   The link-layer
   address is stored in canonical form, as described in RFC 2464.

Alain checked RFC 2464, and he can't find how a link layer address is
supposed to be stored in canonical form. The closest thing he found is:
 
   The Source/Target Link-layer
   Address option has the following form when the link layer is
   Ethernet.

                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |     Type      |    Length     |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                               |
                   +-          Ethernet           -+
                   |                               |
                   +-           Address           -+
                   |                               |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And, RFC 2464 only describes Ethernet and is silent on other link-layer
addresses.

There is also an issue with the text:

   The hardware type MUST be a
   valid hardware type assigned by the IANA, as described in RFC 826.

...but, RFC 826 makes no reference to IANA.

Ted Lemon and I exchanged e-mail about the DUID issue, and I've included
Ted's response below.

Regarding the IANA/RFC 826 issue, I think it can be addressed by an errata:

OLD:

   The hardware type MUST be a valid hardware type
   assigned by the IANA as described in RFC 826 [14].

NEW:

   The hardware type MUST be a valid hardware type from the list of
   ARP hardware types maintained by IANA at 

- Ralph

=====

To be honest, I have no idea where the RFC2464 reference came from.
I'd never read that RFC, and wasn't even aware of its existence.
The word 'canonical' is only used twice in the RFC, and nowhere in
the RFC is the meaning of 'canonical' described.   The point Alain
raises is a really good one, and applies to RFC2464 as well, to some
extent - it should define 'canonical'.

However, RFC2464 does give us some clue about this in section 2.5.1,
Interface Identifiers, on page 8, where it describes in detail how to
construct an interface identifier.   This does tell us what the
author of RFC2464 thought the canonical form is.  But Alain's still
right that the reference to RFC2464 is a mistake in isolation,
because it leaves out all other possible frame header formats.
Having said that, the problem remains - without specifying the
arrangement of bits, you are left guessing.   People seem to have
muddled through with RFC2131/2132, and I think they probably will
with 3315 as well, but it could have been better specified.

I think the correct fix for the RFC2464 problem is to add some text
like what's in RFC2373:

    The details of forming interface identifiers are defined in the
    appropriate "IPv6 over " specification such as "IPv6 over
    Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.

We'd change it to this:

    The details of how the link-layer address is formatted are
defined in the
    appropriate "IPv6 over " specification such as "IPv6 over
    Ethernet" [RFC2464], "IPv6 over FDDI" [RFCnnnn], etc.
Specifically, the
    link-layer address should appear in the DUID-LLT option just as
it does
    in the frame header for that particular link type.  For example the
    link-layer address for an ethernet interface would be formatted
in the
    same way as the Destination Ethernet Address field of the
ethernet frame
    as described in the section of "IPv6 over Ethernet" [RFC2464]
titled "Frame
    Format."

This doesn't really solve the problem, because RFC2464 isn't specific
about it either, but it gets rid of the erroneous reference to
RFC2464 as the _only_ place to go, and it also gives the implementor
a valuable clue for how to format the DUID-LLT - look at a frame you
captured live on the wire.   That way.   That's lame, but it's better
than nothing.   Really, RFC2464 should be more particular about
referencing the document (presumably IEEE) that defines the 802.11
header format.   You can see that the author had access to that
document by reading section 2.5.1, but unfortunately s/he never
references it.

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



From dhcwg-bounces@ietf.org Sat Feb 17 10:15:59 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIRHF-0003ZS-Oc; Sat, 17 Feb 2007 10:15:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIRHF-0003ZN-CW
	for dhcwg@ietf.org; Sat, 17 Feb 2007 10:15:05 -0500
Received: from mx.isc.org ([2001:4f8:0:2::1c])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIRH5-0007Uw-EP
	for dhcwg@ietf.org; Sat, 17 Feb 2007 10:15:05 -0500
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "farside.isc.org", Issuer "ISC CA" (verified OK))
	by mx.isc.org (Postfix) with ESMTP id E85B2114025;
	Sat, 17 Feb 2007 15:14:44 +0000 (UTC)
	(envelope-from Shane_Kerr@isc.org)
Received: from [199.6.1.234] (unknown [199.6.1.234])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by farside.isc.org (Postfix) with ESMTP id 49CADE601F;
	Sat, 17 Feb 2007 15:14:44 +0000 (UTC) (envelope-from shane@isc.org)
Message-ID: <45D71BE2.9050506@isc.org>
Date: Sat, 17 Feb 2007 16:14:42 +0100
From: Shane Kerr 
Organization: ISC
User-Agent: Thunderbird 1.5.0.9 (X11/20061231)
MIME-Version: 1.0
To: Ralph Droms 
Subject: Re: [dhcwg] FW: RFC3315 question
References: 
In-Reply-To: 
X-Enigmail-Version: 0.94.1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: shane_kerr@isc.org
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ralph Droms wrote:
> Regarding the IANA/RFC 826 issue, I think it can be addressed by an errata:
> 
> OLD:
> 
>    The hardware type MUST be a valid hardware type
>    assigned by the IANA as described in RFC 826 [14].
> 
> NEW:
> 
>    The hardware type MUST be a valid hardware type from the list of
>    ARP hardware types maintained by IANA at 

That's this, right:

http://www.iana.org/assignments/arp-parameters

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF1xviMsfZxBO4kbQRAqIbAJ4v9nZO7ndiCxc0gnjnseRTh7aOfgCg5fjw
CHVzXJeAPod7KIp3Ez/t6CU=
=6uRt
-----END PGP SIGNATURE-----

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



From dhcwg-bounces@ietf.org Sat Feb 17 11:28:11 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HISP5-0007Ep-Jg; Sat, 17 Feb 2007 11:27:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HISP4-0007Ef-Dc
	for dhcwg@ietf.org; Sat, 17 Feb 2007 11:27:14 -0500
Received: from simmts5.bellnexxia.net ([206.47.199.163]
	helo=simmts5-srv.bellnexxia.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HISP2-0002pE-Mz
	for dhcwg@ietf.org; Sat, 17 Feb 2007 11:27:14 -0500
Received: from winxpmce ([142.167.242.132]) by simmts5-srv.bellnexxia.net
	(InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP
	id <20070217162707.ICBX4412.simmts5-srv.bellnexxia.net@winxpmce>
	for ; Sat, 17 Feb 2007 11:27:07 -0500
Message-ID: <000e01c752b0$76ec7c40$0b02a8c0@winxpmce>
From: "Joseph" 
To: 
Date: Sat, 17 Feb 2007 12:27:06 -0400
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3028
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Spam-Score: 1.8 (+)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Subject: [dhcwg] (no subject)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0292520441=="
Errors-To: dhcwg-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0292520441==
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C7528E.EFA685D0"

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C7528E.EFA685D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

get the fuck off my computer
------=_NextPart_000_000B_01C7528E.EFA685D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









get the fuck off my=20
computer


------=_NextPart_000_000B_01C7528E.EFA685D0--



--===============0292520441==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0292520441==--





From dhcwg-bounces@ietf.org Sat Feb 17 14:20:33 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIV5G-0004Df-1d; Sat, 17 Feb 2007 14:18:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIV5E-0004DZ-Ne
	for dhcwg@ietf.org; Sat, 17 Feb 2007 14:18:56 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIV5B-0007Kt-7B
	for dhcwg@ietf.org; Sat, 17 Feb 2007 14:18:56 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2007 14:18:51 -0500
X-IronPort-AV: i="4.14,185,1170651600"; 
	d="scan'208"; a="114157508:sNHT88879656"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1HJIoPc023439
	for ; Sat, 17 Feb 2007 14:18:50 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1HJIoVT010841
	for ; Sat, 17 Feb 2007 14:18:50 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 17 Feb 2007 14:18:50 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] FW: RFC3315 question
Date: Sat, 17 Feb 2007 14:18:50 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB2103467C67@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] FW: RFC3315 question
Thread-Index: Acc/Psc6ympXzt39SmqKB5J9mTvDMQS1hDHhACyzlYA=
From: "Bernie Volz \(volz\)" 
To: "Ralph Droms \(rdroms\)" , "dhcwg" 
X-OriginalArrivalTime: 17 Feb 2007 19:18:50.0455 (UTC)
	FILETIME=[747BB670:01C752C8]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5583; t=1171739930;
	x=1172603930; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20FW=3A=20RFC3315=20question
	|Sender:=20
	|To:=20=22Ralph=20Droms=20\(rdroms\)=22=20,
	=20=22dhcwg= 22=20;
	bh=SujcadX6uZED7n08koYf8356K2uIqUd89CkFAYgd2g0=;
	b=wGv43JaoxhxZ0tytRrn0+MhHcuCBXFItF/ddE3D750neT0yDQOHJSO0VydfQS3PUEtR2s0fV
	+fU5o4wbLSRRHP+NW/2QSZxT0b8eQvgmCl8Am7H84HDfHsRCR4U+S5X/;
Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Cc: 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Ah, good that this is finally being cleaned up (I recall there was some
past discussion on this). Reference to RFC 826 was very poor and really
should have referenced the IANA pages (the Number Hardware Type (hrd)
section of http://www.iana.org/assignments/arp-parameters).

Perhaps a reference to http://www.ietf.org/rfc/rfc2469.txt might also
help to address the canonical address issue? At least the describes
canonical addresses.

Link layer also confused one major vendor into thinking they should use
the EUI-64 identifier, so perhaps an example wouldn't hurt as well (we
have an example for DUID-EN, so why not for the others?).

- Bernie=20

-----Original Message-----
From: Ralph Droms (rdroms)=20
Sent: Friday, February 16, 2007 4:53 PM
To: dhcwg
Subject: [dhcwg] FW: RFC3315 question

Alain Durand asked me a couple of questions about the definition of the
DUID
formats based on link-layer addresses in RFC 3315.  The first question
is
about this text, which appears in both section 9.2, DUID Based on
Link-layer
Address Plus Time [DUID-LLT], and section 9.4, DUID Based on Link-layer
Address [DUID-LL]:

   The link-layer
   address is stored in canonical form, as described in RFC 2464.

Alain checked RFC 2464, and he can't find how a link layer address is
supposed to be stored in canonical form. The closest thing he found is:
=20
   The Source/Target Link-layer
   Address option has the following form when the link layer is
   Ethernet.

                    0                   1
                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |     Type      |    Length     |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |                               |
                   +-          Ethernet           -+
                   |                               |
                   +-           Address           -+
                   |                               |
                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And, RFC 2464 only describes Ethernet and is silent on other link-layer
addresses.

There is also an issue with the text:

   The hardware type MUST be a
   valid hardware type assigned by the IANA, as described in RFC 826.

...but, RFC 826 makes no reference to IANA.

Ted Lemon and I exchanged e-mail about the DUID issue, and I've included
Ted's response below.

Regarding the IANA/RFC 826 issue, I think it can be addressed by an
errata:

OLD:

   The hardware type MUST be a valid hardware type
   assigned by the IANA as described in RFC 826 [14].

NEW:

   The hardware type MUST be a valid hardware type from the list of
   ARP hardware types maintained by IANA at 

- Ralph

=3D=3D=3D=3D=3D

To be honest, I have no idea where the RFC2464 reference came from.
I'd never read that RFC, and wasn't even aware of its existence.
The word 'canonical' is only used twice in the RFC, and nowhere in
the RFC is the meaning of 'canonical' described.   The point Alain
raises is a really good one, and applies to RFC2464 as well, to some
extent - it should define 'canonical'.

However, RFC2464 does give us some clue about this in section 2.5.1,
Interface Identifiers, on page 8, where it describes in detail how to
construct an interface identifier.   This does tell us what the
author of RFC2464 thought the canonical form is.  But Alain's still
right that the reference to RFC2464 is a mistake in isolation,
because it leaves out all other possible frame header formats.
Having said that, the problem remains - without specifying the
arrangement of bits, you are left guessing.   People seem to have
muddled through with RFC2131/2132, and I think they probably will
with 3315 as well, but it could have been better specified.

I think the correct fix for the RFC2464 problem is to add some text
like what's in RFC2373:

    The details of forming interface identifiers are defined in the
    appropriate "IPv6 over " specification such as "IPv6 over
    Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.

We'd change it to this:

    The details of how the link-layer address is formatted are
defined in the
    appropriate "IPv6 over " specification such as "IPv6 over
    Ethernet" [RFC2464], "IPv6 over FDDI" [RFCnnnn], etc.
Specifically, the
    link-layer address should appear in the DUID-LLT option just as
it does
    in the frame header for that particular link type.  For example the
    link-layer address for an ethernet interface would be formatted
in the
    same way as the Destination Ethernet Address field of the
ethernet frame
    as described in the section of "IPv6 over Ethernet" [RFC2464]
titled "Frame
    Format."

This doesn't really solve the problem, because RFC2464 isn't specific
about it either, but it gets rid of the erroneous reference to
RFC2464 as the _only_ place to go, and it also gives the implementor
a valuable clue for how to format the DUID-LLT - look at a frame you
captured live on the wire.   That way.   That's lame, but it's better
than nothing.   Really, RFC2464 should be more particular about
referencing the document (presumably IEEE) that defines the 802.11
header format.   You can see that the author had access to that
document by reading section 2.5.1, but unfortunately s/he never
references it.

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

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



From dhcwg-bounces@ietf.org Sat Feb 17 14:38:56 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIVO2-00024s-H6; Sat, 17 Feb 2007 14:38:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIVO1-00024m-IT
	for dhcwg@ietf.org; Sat, 17 Feb 2007 14:38:21 -0500
Received: from slb-smtpout-01.boeing.com ([130.76.64.48]
	helo=slb-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIVNz-0003ZA-0N
	for dhcwg@ietf.org; Sat, 17 Feb 2007 14:38:21 -0500
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6])
	by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1HJcDPN004289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Sat, 17 Feb 2007 11:38:14 -0800 (PST)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1HJcDha023662; Sat, 17 Feb 2007 13:38:13 -0600 (CST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1HJcCUh023648; Sat, 17 Feb 2007 13:38:13 -0600 (CST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 17 Feb 2007 11:38:12 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] FW: RFC3315 question
Date: Sat, 17 Feb 2007 11:38:12 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017746F5@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <8E296595B6471A4689555D5D725EBB2103467C67@xmb-rtp-20a.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] FW: RFC3315 question
Thread-Index: Acc/Psc6ympXzt39SmqKB5J9mTvDMQS1hDHhACyzlYAAAHrgQA==
References: 
	<8E296595B6471A4689555D5D725EBB2103467C67@xmb-rtp-20a.amer.cisco.com>
From: "Templin, Fred L" 
To: , , 
X-OriginalArrivalTime: 17 Feb 2007 19:38:12.0800 (UTC)
	FILETIME=[294B7C00:01C752CB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48
Cc: 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Just to get this idea out, how does one go about getting a new
DUID type defined? In particular, it might be useful to define
a new DUID type that includes a client's public key such as
required by RFC3972. The actual format of the DUID type is for
further study, e.g., in addition to the public key it might be
desireable to include a link-layer address, a timestamp, etc.

Thanks - Fred
fred.l.templin@boeing.com=20

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com]=20
> Sent: Saturday, February 17, 2007 11:19 AM
> To: Ralph Droms (rdroms); dhcwg
> Subject: RE: [dhcwg] FW: RFC3315 question
>=20
> Ah, good that this is finally being cleaned up (I recall=20
> there was some
> past discussion on this). Reference to RFC 826 was very poor=20
> and really
> should have referenced the IANA pages (the Number Hardware Type (hrd)
> section of http://www.iana.org/assignments/arp-parameters).
>=20
> Perhaps a reference to http://www.ietf.org/rfc/rfc2469.txt might also
> help to address the canonical address issue? At least the describes
> canonical addresses.
>=20
> Link layer also confused one major vendor into thinking they=20
> should use
> the EUI-64 identifier, so perhaps an example wouldn't hurt as well (we
> have an example for DUID-EN, so why not for the others?).
>=20
> - Bernie=20
>=20
> -----Original Message-----
> From: Ralph Droms (rdroms)=20
> Sent: Friday, February 16, 2007 4:53 PM
> To: dhcwg
> Subject: [dhcwg] FW: RFC3315 question
>=20
> Alain Durand asked me a couple of questions about the=20
> definition of the
> DUID
> formats based on link-layer addresses in RFC 3315.  The first question
> is
> about this text, which appears in both section 9.2, DUID Based on
> Link-layer
> Address Plus Time [DUID-LLT], and section 9.4, DUID Based on=20
> Link-layer
> Address [DUID-LL]:
>=20
>    The link-layer
>    address is stored in canonical form, as described in RFC 2464.
>=20
> Alain checked RFC 2464, and he can't find how a link layer address is
> supposed to be stored in canonical form. The closest thing he=20
> found is:
> =20
>    The Source/Target Link-layer
>    Address option has the following form when the link layer is
>    Ethernet.
>=20
>                     0                   1
>                     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    |     Type      |    Length     |
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    |                               |
>                    +-          Ethernet           -+
>                    |                               |
>                    +-           Address           -+
>                    |                               |
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> And, RFC 2464 only describes Ethernet and is silent on other=20
> link-layer
> addresses.
>=20
> There is also an issue with the text:
>=20
>    The hardware type MUST be a
>    valid hardware type assigned by the IANA, as described in RFC 826.
>=20
> ...but, RFC 826 makes no reference to IANA.
>=20
> Ted Lemon and I exchanged e-mail about the DUID issue, and=20
> I've included
> Ted's response below.
>=20
> Regarding the IANA/RFC 826 issue, I think it can be addressed by an
> errata:
>=20
> OLD:
>=20
>    The hardware type MUST be a valid hardware type
>    assigned by the IANA as described in RFC 826 [14].
>=20
> NEW:
>=20
>    The hardware type MUST be a valid hardware type from the list of
>    ARP hardware types maintained by IANA at 
>=20
> - Ralph
>=20
> =3D=3D=3D=3D=3D
>=20
> To be honest, I have no idea where the RFC2464 reference came from.
> I'd never read that RFC, and wasn't even aware of its existence.
> The word 'canonical' is only used twice in the RFC, and nowhere in
> the RFC is the meaning of 'canonical' described.   The point Alain
> raises is a really good one, and applies to RFC2464 as well, to some
> extent - it should define 'canonical'.
>=20
> However, RFC2464 does give us some clue about this in section 2.5.1,
> Interface Identifiers, on page 8, where it describes in detail how to
> construct an interface identifier.   This does tell us what the
> author of RFC2464 thought the canonical form is.  But Alain's still
> right that the reference to RFC2464 is a mistake in isolation,
> because it leaves out all other possible frame header formats.
> Having said that, the problem remains - without specifying the
> arrangement of bits, you are left guessing.   People seem to have
> muddled through with RFC2131/2132, and I think they probably will
> with 3315 as well, but it could have been better specified.
>=20
> I think the correct fix for the RFC2464 problem is to add some text
> like what's in RFC2373:
>=20
>     The details of forming interface identifiers are defined in the
>     appropriate "IPv6 over " specification such as "IPv6 over
>     Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
>=20
> We'd change it to this:
>=20
>     The details of how the link-layer address is formatted are
> defined in the
>     appropriate "IPv6 over " specification such as "IPv6 over
>     Ethernet" [RFC2464], "IPv6 over FDDI" [RFCnnnn], etc.
> Specifically, the
>     link-layer address should appear in the DUID-LLT option just as
> it does
>     in the frame header for that particular link type.  For=20
> example the
>     link-layer address for an ethernet interface would be formatted
> in the
>     same way as the Destination Ethernet Address field of the
> ethernet frame
>     as described in the section of "IPv6 over Ethernet" [RFC2464]
> titled "Frame
>     Format."
>=20
> This doesn't really solve the problem, because RFC2464 isn't specific
> about it either, but it gets rid of the erroneous reference to
> RFC2464 as the _only_ place to go, and it also gives the implementor
> a valuable clue for how to format the DUID-LLT - look at a frame you
> captured live on the wire.   That way.   That's lame, but it's better
> than nothing.   Really, RFC2464 should be more particular about
> referencing the document (presumably IEEE) that defines the 802.11
> header format.   You can see that the author had access to that
> document by reading section 2.5.1, but unfortunately s/he never
> references it.
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>=20

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



From dhcwg-bounces@ietf.org Sat Feb 17 17:12:10 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIXlw-0007Gr-AH; Sat, 17 Feb 2007 17:11:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIXlv-0007FB-F1
	for dhcwg@ietf.org; Sat, 17 Feb 2007 17:11:11 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIXlu-0000fy-5x
	for dhcwg@ietf.org; Sat, 17 Feb 2007 17:11:11 -0500
Received: from [192.168.1.12] (dsl092-048-218.sfo4.dsl.speakeasy.net
	[66.92.48.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id E6C445687D
	for ; Sat, 17 Feb 2007 14:10:54 -0800 (PST)
	(envelope-from neild@nominum.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <2AFB2BA1-456B-40CA-8A0B-57BCA7C6FB84@nominum.com>
References: 
	<2AFB2BA1-456B-40CA-8A0B-57BCA7C6FB84@nominum.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3AE95527-AC88-4C26-A961-F170B6B8C7E3@nominum.com>
Content-Transfer-Encoding: 7bit
From: Damien Neil 
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities
Date: Sat, 17 Feb 2007 14:10:50 -0800
To: dhcwg 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 15, 2007, at 12:15 AM, Ted Lemon wrote:
> I think this is the crux of why we are thinking about this  
> differently.   As a customer, there is no way that I want you  
> configuring my router's addressing from a DHCP server if I have a  
> provider-independent prefix.   I realize that that seems backwards  
> from the perspective of the ISP, but the customer only has one P-I  
> prefix, so they don't mind configuring it manually.   Or so I would  
> naturally assume, absent some reason to assume differently.

This doesn't strike me as being different from any other use of  
reservations or fixed-address assignments in DHCP.  Why wouldn't the  
provider want to centralize management of router address  
configuration on their DHCP server?  And why would the user expect to  
have any configuration access to the provider-supplied router?   
There's a DSL modem sitting on the floor by me; I certainly don't  
expect to be able to configure its address, regardless of whether  
that address is statically or dynamically assigned.

           - Damien

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



From dhcwg-bounces@ietf.org Sat Feb 17 17:26:28 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIY0E-0002us-JB; Sat, 17 Feb 2007 17:25:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIY0C-0002ui-GP
	for dhcwg@ietf.org; Sat, 17 Feb 2007 17:25:56 -0500
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIY07-0003ux-Vp
	for dhcwg@ietf.org; Sat, 17 Feb 2007 17:25:56 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2007 17:25:52 -0500
X-IronPort-AV: i="4.14,185,1170651600"; 
	d="scan'208"; a="114161126:sNHT83973880"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1HMPpHL020385; 
	Sat, 17 Feb 2007 17:25:51 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1HMPpOA014638; 
	Sat, 17 Feb 2007 17:25:51 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 17 Feb 2007 17:25:51 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] FW: RFC3315 question
Date: Sat, 17 Feb 2007 17:25:51 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB2103467C84@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017746F5@XCH-NW-7V2.nw.nos.boeing.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] FW: RFC3315 question
Thread-Index: Acc/Psc6ympXzt39SmqKB5J9mTvDMQS1hDHhACyzlYAAAHrgQAAGM0Aw
From: "Bernie Volz \(volz\)" 
To: "Templin, Fred L" ,
	"Ralph Droms \(rdroms\)" , 
X-OriginalArrivalTime: 17 Feb 2007 22:25:51.0337 (UTC)
	FILETIME=[94A66D90:01C752E2]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7377; t=1171751151;
	x=1172615151; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20FW=3A=20RFC3315=20question
	|Sender:=20
	|To:=20=22Templin, =20Fred=20L=22=20,
	=0A=20=20=
	20=20=20=20=20=20=22Ralph=20Droms=20\(rdroms\)=22=20,
	=20 ;
	bh=IESTEGh+HTDgMDA+Pk2p+fP1op5CrUmOFO4+JWIoApc=;
	b=A63hUohDiM796TIoPJ5wxTdtV8+LLfbqzgMs8f5tCOTLcW1LvMUySymfUnGB/OjffRICr1hD
	Us0t34UCz4V5+ACZow5yLEefV625KZSY8cHk0EmiYzs9fBFAK418Twem;
Authentication-Results: rtp-dkim-2; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb
Cc: 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

RFC 3315 indicates how ...

24. IANA Considerations

   ...

   New multicast addresses, message types, status codes, and DUID types
   are assigned via Standards Action [11].=20

   ...

   [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   ...

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
Sent: Saturday, February 17, 2007 2:38 PM
To: Bernie Volz (volz); Ralph Droms (rdroms); dhcwg@ietf.org
Subject: RE: [dhcwg] FW: RFC3315 question

Just to get this idea out, how does one go about getting a new
DUID type defined? In particular, it might be useful to define
a new DUID type that includes a client's public key such as
required by RFC3972. The actual format of the DUID type is for
further study, e.g., in addition to the public key it might be
desireable to include a link-layer address, a timestamp, etc.

Thanks - Fred
fred.l.templin@boeing.com=20

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com]=20
> Sent: Saturday, February 17, 2007 11:19 AM
> To: Ralph Droms (rdroms); dhcwg
> Subject: RE: [dhcwg] FW: RFC3315 question
>=20
> Ah, good that this is finally being cleaned up (I recall=20
> there was some
> past discussion on this). Reference to RFC 826 was very poor=20
> and really
> should have referenced the IANA pages (the Number Hardware Type (hrd)
> section of http://www.iana.org/assignments/arp-parameters).
>=20
> Perhaps a reference to http://www.ietf.org/rfc/rfc2469.txt might also
> help to address the canonical address issue? At least the describes
> canonical addresses.
>=20
> Link layer also confused one major vendor into thinking they=20
> should use
> the EUI-64 identifier, so perhaps an example wouldn't hurt as well (we
> have an example for DUID-EN, so why not for the others?).
>=20
> - Bernie=20
>=20
> -----Original Message-----
> From: Ralph Droms (rdroms)=20
> Sent: Friday, February 16, 2007 4:53 PM
> To: dhcwg
> Subject: [dhcwg] FW: RFC3315 question
>=20
> Alain Durand asked me a couple of questions about the=20
> definition of the
> DUID
> formats based on link-layer addresses in RFC 3315.  The first question
> is
> about this text, which appears in both section 9.2, DUID Based on
> Link-layer
> Address Plus Time [DUID-LLT], and section 9.4, DUID Based on=20
> Link-layer
> Address [DUID-LL]:
>=20
>    The link-layer
>    address is stored in canonical form, as described in RFC 2464.
>=20
> Alain checked RFC 2464, and he can't find how a link layer address is
> supposed to be stored in canonical form. The closest thing he=20
> found is:
> =20
>    The Source/Target Link-layer
>    Address option has the following form when the link layer is
>    Ethernet.
>=20
>                     0                   1
>                     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    |     Type      |    Length     |
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    |                               |
>                    +-          Ethernet           -+
>                    |                               |
>                    +-           Address           -+
>                    |                               |
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> And, RFC 2464 only describes Ethernet and is silent on other=20
> link-layer
> addresses.
>=20
> There is also an issue with the text:
>=20
>    The hardware type MUST be a
>    valid hardware type assigned by the IANA, as described in RFC 826.
>=20
> ...but, RFC 826 makes no reference to IANA.
>=20
> Ted Lemon and I exchanged e-mail about the DUID issue, and=20
> I've included
> Ted's response below.
>=20
> Regarding the IANA/RFC 826 issue, I think it can be addressed by an
> errata:
>=20
> OLD:
>=20
>    The hardware type MUST be a valid hardware type
>    assigned by the IANA as described in RFC 826 [14].
>=20
> NEW:
>=20
>    The hardware type MUST be a valid hardware type from the list of
>    ARP hardware types maintained by IANA at 
>=20
> - Ralph
>=20
> =3D=3D=3D=3D=3D
>=20
> To be honest, I have no idea where the RFC2464 reference came from.
> I'd never read that RFC, and wasn't even aware of its existence.
> The word 'canonical' is only used twice in the RFC, and nowhere in
> the RFC is the meaning of 'canonical' described.   The point Alain
> raises is a really good one, and applies to RFC2464 as well, to some
> extent - it should define 'canonical'.
>=20
> However, RFC2464 does give us some clue about this in section 2.5.1,
> Interface Identifiers, on page 8, where it describes in detail how to
> construct an interface identifier.   This does tell us what the
> author of RFC2464 thought the canonical form is.  But Alain's still
> right that the reference to RFC2464 is a mistake in isolation,
> because it leaves out all other possible frame header formats.
> Having said that, the problem remains - without specifying the
> arrangement of bits, you are left guessing.   People seem to have
> muddled through with RFC2131/2132, and I think they probably will
> with 3315 as well, but it could have been better specified.
>=20
> I think the correct fix for the RFC2464 problem is to add some text
> like what's in RFC2373:
>=20
>     The details of forming interface identifiers are defined in the
>     appropriate "IPv6 over " specification such as "IPv6 over
>     Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
>=20
> We'd change it to this:
>=20
>     The details of how the link-layer address is formatted are
> defined in the
>     appropriate "IPv6 over " specification such as "IPv6 over
>     Ethernet" [RFC2464], "IPv6 over FDDI" [RFCnnnn], etc.
> Specifically, the
>     link-layer address should appear in the DUID-LLT option just as
> it does
>     in the frame header for that particular link type.  For=20
> example the
>     link-layer address for an ethernet interface would be formatted
> in the
>     same way as the Destination Ethernet Address field of the
> ethernet frame
>     as described in the section of "IPv6 over Ethernet" [RFC2464]
> titled "Frame
>     Format."
>=20
> This doesn't really solve the problem, because RFC2464 isn't specific
> about it either, but it gets rid of the erroneous reference to
> RFC2464 as the _only_ place to go, and it also gives the implementor
> a valuable clue for how to format the DUID-LLT - look at a frame you
> captured live on the wire.   That way.   That's lame, but it's better
> than nothing.   Really, RFC2464 should be more particular about
> referencing the document (presumably IEEE) that defines the 802.11
> header format.   You can see that the author had access to that
> document by reading section 2.5.1, but unfortunately s/he never
> references it.
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>=20

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



From dhcwg-bounces@ietf.org Sat Feb 17 17:33:23 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIY72-0007e4-7B; Sat, 17 Feb 2007 17:33:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIY70-0007dw-IL
	for dhcwg@ietf.org; Sat, 17 Feb 2007 17:32:58 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIY6w-0004vy-7o
	for dhcwg@ietf.org; Sat, 17 Feb 2007 17:32:58 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id DA60C5682B
	for ; Sat, 17 Feb 2007 14:32:53 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.266,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.804
X-Spam-Level: 
Received: from [10.10.10.127] ([207.114.177.82])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Sat, 17 Feb 2007 14:32:52 -0800
In-Reply-To: <3AE95527-AC88-4C26-A961-F170B6B8C7E3@nominum.com>
References: 
	<2AFB2BA1-456B-40CA-8A0B-57BCA7C6FB84@nominum.com>
	<3AE95527-AC88-4C26-A961-F170B6B8C7E3@nominum.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities
Date: Sat, 17 Feb 2007 15:32:47 -0700
To: Damien Neil 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 17, 2007, at 3:10 PM, Damien Neil wrote:
> This doesn't strike me as being different from any other use of  
> reservations or fixed-address assignments in DHCP.  Why wouldn't  
> the provider want to centralize management of router address  
> configuration on their DHCP server?  And why would the user expect  
> to have any configuration access to the provider-supplied router?   
> There's a DSL modem sitting on the floor by me; I certainly don't  
> expect to be able to configure its address, regardless of whether  
> that address is statically or dynamically assigned.

Because I think a multihoming customer really wants full  
configuration control of their end of things - relying on someone  
else's DHCP service seems like a variable that you wouldn't want to  
do.  Ask Chris what his attitude about this would be - I'm just  
speculating.



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



From dhcwg-bounces@ietf.org Sat Feb 17 17:34:15 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIY8F-0000KZ-L4; Sat, 17 Feb 2007 17:34:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIY8F-0000KU-B3
	for dhcwg@ietf.org; Sat, 17 Feb 2007 17:34:15 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIY8E-0004zU-2Q
	for dhcwg@ietf.org; Sat, 17 Feb 2007 17:34:15 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id B2FED5688E;
	Sat, 17 Feb 2007 14:34:13 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.230,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.840
X-Spam-Level: 
Received: from [10.10.10.127] ([207.114.177.82])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Sat, 17 Feb 2007 14:34:12 -0800
In-Reply-To: <8E296595B6471A4689555D5D725EBB2103467C84@xmb-rtp-20a.amer.cisco.com>
References: <8E296595B6471A4689555D5D725EBB2103467C84@xmb-rtp-20a.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <53EB64D1-7093-4C62-B063-BCF4571874D4@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] FW: RFC3315 question
Date: Sat, 17 Feb 2007 15:34:09 -0700
To: "Bernie Volz \(volz\)" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: dhcwg@ietf.org, "Templin, Fred L" ,
	"Ralph Droms \(rdroms\)" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 17, 2007, at 3:25 PM, Bernie Volz ((volz)) wrote:
> Just to get this idea out, how does one go about getting a new
> DUID type defined? In particular, it might be useful to define
> a new DUID type that includes a client's public key such as
> required by RFC3972. The actual format of the DUID type is for
> further study, e.g., in addition to the public key it might be
> desireable to include a link-layer address, a timestamp, etc.

How big is this key going to be?   I don't think a 1k identifier is a  
good idea.



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



From dhcwg-bounces@ietf.org Sat Feb 17 17:46:46 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIYJx-0001W3-GP; Sat, 17 Feb 2007 17:46:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIYJw-0001Vt-IQ
	for dhcwg@ietf.org; Sat, 17 Feb 2007 17:46:20 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIYJv-0006uO-8T
	for dhcwg@ietf.org; Sat, 17 Feb 2007 17:46:20 -0500
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
	by sj-iport-5.cisco.com with ESMTP; 17 Feb 2007 14:46:19 -0800
X-IronPort-AV: i="4.14,185,1170662400"; 
	d="scan'208"; a="390198874:sNHT52782860"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1HMkI1q021288; 
	Sat, 17 Feb 2007 14:46:18 -0800
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1HMkFho022279;
	Sat, 17 Feb 2007 14:46:16 -0800 (PST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 17 Feb 2007 17:46:15 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] FW: RFC3315 question
Date: Sat, 17 Feb 2007 17:46:14 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB2103467C88@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <53EB64D1-7093-4C62-B063-BCF4571874D4@nominum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] FW: RFC3315 question
Thread-Index: AcdS48FRGARo4rc5SIaXaeS8+S83TgAAZieg
From: "Bernie Volz \(volz\)" 
To: "Ted Lemon" 
X-OriginalArrivalTime: 17 Feb 2007 22:46:15.0542 (UTC)
	FILETIME=[6E554960:01C752E5]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=846; t=1171752378;
	x=1172616378; c=relaxed/simple; s=sjdkim7002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20FW=3A=20RFC3315=20question
	|Sender:=20; bh=51cafXhHkwblh6nr/8kK8yvOOCaS9pmdkOYIB0VeEok=;
	b=ahOWuD3Ag/GYSM55LrFYpoWMZ2aXI0FY3YQnr5Jq2AWH3HFB6VaJtxwXTmu5BmKIqLoltQQx
	74oGM/6Dh+Tvw+90U6TSKuEvljpm3SdoROiQrvfC8gno0oqTSHxqRl9o;
Authentication-Results: sj-dkim-7; header.From=volz@cisco.com; dkim=pass (si
	g from cisco.com/sjdkim7002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: dhcwg@ietf.org, "Templin, Fred L" ,
	"Ralph Droms \(rdroms\)" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

I didn't write that! Fred wrote that!!

- Bernie=20

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20
Sent: Saturday, February 17, 2007 5:34 PM
To: Bernie Volz (volz)
Cc: Templin, Fred L; Ralph Droms (rdroms); dhcwg@ietf.org
Subject: Re: [dhcwg] FW: RFC3315 question

On Feb 17, 2007, at 3:25 PM, Bernie Volz ((volz)) wrote:
> Just to get this idea out, how does one go about getting a new
> DUID type defined? In particular, it might be useful to define
> a new DUID type that includes a client's public key such as
> required by RFC3972. The actual format of the DUID type is for
> further study, e.g., in addition to the public key it might be
> desireable to include a link-layer address, a timestamp, etc.

How big is this key going to be?   I don't think a 1k identifier is a =20
good idea.

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



From dhcwg-bounces@ietf.org Sat Feb 17 18:01:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIYYL-0004DI-H6; Sat, 17 Feb 2007 18:01:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIYYK-0004Cn-EU
	for dhcwg@ietf.org; Sat, 17 Feb 2007 18:01:12 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIYYJ-0000ZP-5e
	for dhcwg@ietf.org; Sat, 17 Feb 2007 18:01:12 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id C27B65682B;
	Sat, 17 Feb 2007 15:01:10 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,TOTAL_SCORE: 4.070
X-Spam-Level: 
Received: from [192.168.1.42] ([206.169.64.119])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Sat, 17 Feb 2007 15:01:09 -0800
In-Reply-To: <8E296595B6471A4689555D5D725EBB2103467C88@xmb-rtp-20a.amer.cisco.com>
References: <8E296595B6471A4689555D5D725EBB2103467C88@xmb-rtp-20a.amer.cisco.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] FW: RFC3315 question
Date: Sat, 17 Feb 2007 16:01:02 -0700
To: "Bernie Volz \(volz\)" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea
Cc: dhcwg@ietf.org, "Templin, Fred L" ,
	"Ralph Droms \(rdroms\)" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 17, 2007, at 3:46 PM, Bernie Volz ((volz)) wrote:
> I didn't write that! Fred wrote that!!

I know, sorry.   I was just being lazy and not fixing it.



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



From dhcwg-bounces@ietf.org Sat Feb 17 18:12:40 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HIYig-0003QH-IM; Sat, 17 Feb 2007 18:11:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HIYie-0003MI-PG
	for dhcwg@ietf.org; Sat, 17 Feb 2007 18:11:52 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIYid-000202-Fo
	for dhcwg@ietf.org; Sat, 17 Feb 2007 18:11:52 -0500
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-5.cisco.com with ESMTP; 17 Feb 2007 15:11:52 -0800
X-IronPort-AV: i="4.14,185,1170662400"; 
	d="scan'208"; a="390203111:sNHT45657372"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1HNBo6O008901; 
	Sat, 17 Feb 2007 15:11:50 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1HNBonF017440;
	Sat, 17 Feb 2007 15:11:50 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 17 Feb 2007 15:11:50 -0800
Received: from [127.0.0.1] ([10.70.237.16]) by xfe-sjc-211.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Feb 2007 15:11:49 -0800
In-Reply-To: <53EB64D1-7093-4C62-B063-BCF4571874D4@nominum.com>
References: <8E296595B6471A4689555D5D725EBB2103467C84@xmb-rtp-20a.amer.cisco.com>
	<53EB64D1-7093-4C62-B063-BCF4571874D4@nominum.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1A674D40-4BB6-4533-A273-C067B7DF21AD@cisco.com>
Content-Transfer-Encoding: 7bit
From: Markus Stenberg 
Subject: Re: [dhcwg] FW: RFC3315 question
Date: Sun, 18 Feb 2007 08:11:38 +0900
To: Ted Lemon 
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 17 Feb 2007 23:11:49.0995 (UTC)
	FILETIME=[00F03BB0:01C752E9]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=813; t=1171753911;
	x=1172617911; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mstenber@cisco.com;
	z=From:=20Markus=20Stenberg=20
	|Subject:=20Re=3A=20[dhcwg]=20FW=3A=20RFC3315=20question
	|Sender:=20; bh=ZperIcVxXrs3NcsivQxS4H/VEWnutfL18auze+mky3s=;
	b=iCxd2zoRLI6ZVwnPK7NlLeWBCmCS2PbDfQKqOFidSBQw5LFXUKAojcA6UbnzxDXeIOU1hAhG
	BS8ZzTY35n4Wmr1PZ+n7BR6qmAyZ2a+Bpx9l2121Nnj+wjJI9ULkjCw2;
Authentication-Results: sj-dkim-5; header.From=mstenber@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: dhcwg@ietf.org, "Templin, Fred L" ,
	"Bernie Volz \(volz\)" ,
	"Ralph Droms \(rdroms\)" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On 18.2.2007, at 7.34, Ted Lemon wrote:
>> Just to get this idea out, how does one go about getting a new
>> DUID type defined? In particular, it might be useful to define
>> a new DUID type that includes a client's public key such as
>> required by RFC3972. The actual format of the DUID type is for
>> further study, e.g., in addition to the public key it might be
>> desireable to include a link-layer address, a timestamp, etc.
> How big is this key going to be?   I don't think a 1k identifier is  
> a good idea.

Well, 1024bit public key would be 128 bytes for example, which is  
still well within pain threshold of the IPv6 minimum UDP packet  
size.. 2048 bit one would be 'safe' and 256 bytes, and ECC keys would  
be even shorter (but patent encumbered). (think 200-ish bits)

-Markus


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



From dhcwg-bounces@ietf.org Mon Feb 19 07:55:34 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJ82c-0001Rb-Ke; Mon, 19 Feb 2007 07:54:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ82a-0001Qu-FG
	for dhcwg@ietf.org; Mon, 19 Feb 2007 07:54:48 -0500
Received: from tyholt.uninett.no ([2001:700:1::eecb])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ82Z-0005Vy-VW
	for dhcwg@ietf.org; Mon, 19 Feb 2007 07:54:48 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tyholt.uninett.no (Postfix) with ESMTP id A2336B5BE1;
	Mon, 19 Feb 2007 13:54:28 +0100 (CET)
Received: from tyholt.uninett.no ([127.0.0.1])
	by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 10953-01-59; Mon, 19 Feb 2007 13:54:28 +0100 (CET)
Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no
	[IPv6:2001:700:1:7:215:f2ff:fe35:307d])
	by tyholt.uninett.no (Postfix) with ESMTP id 6BE69B5BAB;
	Mon, 19 Feb 2007 13:54:28 +0100 (CET)
Message-ID: <45D99E04.80502@uninett.no>
Date: Mon, 19 Feb 2007 13:54:28 +0100
From: Stig Venaas 
User-Agent: Thunderbird 1.5.0.9 (X11/20070129)
MIME-Version: 1.0
To: "Woundy, Richard" 
Subject: Re: [dhcwg] Background on CMTSs and routing
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Woundy, Richard wrote:
[...]
> Stig raised the possibility that perhaps the DHCP server could use
> dynamic routing protocols (particularly OSPF) to inject routes for
> delegated prefixes. I took this idea seriously, thought about the
> implications, and raised some concerns about whether "stale routes"
> could/would be injected by the DHCP server. While I used an OSPF
> example, the same concerns apply to iBGP route injection -- the DHCP

Just to clarify, I never suggested that this was a way to do things,
rather the contrary. What I said was that route injection by the DHCP
server generally is not possible (as also Ole mentioned later), but
pointed out that there was a theoretical possibility with OSPF. Then
I also pointed out the issue with "stale routes".

I brought this up in response to Ralph and someone else talking about
the possibility of the DHCP server doing injection. My view is that
injection by the DHCP server is not the way to go.

Stig

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



From dhcwg-bounces@ietf.org Mon Feb 19 10:25:00 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJANI-0002Qd-2R; Mon, 19 Feb 2007 10:24:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJANG-0002Nl-P9
	for dhcwg@ietf.org; Mon, 19 Feb 2007 10:24:18 -0500
Received: from e32.co.us.ibm.com ([32.97.110.150])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJANE-0005JI-Eh
	for dhcwg@ietf.org; Mon, 19 Feb 2007 10:24:18 -0500
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com
	[9.17.195.106])
	by e32.co.us.ibm.com (8.12.11.20060308/8.13.8) with ESMTP id
	l1JFNW2q002019 for ; Mon, 19 Feb 2007 10:23:32 -0500
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170])
	by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id
	l1JFOFQF551954 for ; Mon, 19 Feb 2007 08:24:15 -0700
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1])
	by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l1JFOFtH005028 for ; Mon, 19 Feb 2007 08:24:15 -0700
Received: from [9.27.40.30] (brabson.raleigh.ibm.com [9.27.40.30])
	by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l1JFOET5005010; Mon, 19 Feb 2007 08:24:14 -0700
Message-ID: <45D9C11F.6070706@us.ibm.com>
Date: Mon, 19 Feb 2007 10:24:15 -0500
From: Roy Brabson 
Organization: IBM Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Ted Lemon 
Subject: Re: [dhcwg] DUID on a Virtual Host
References: <45D61560.4080103@us.ibm.com>
	
In-Reply-To: 
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Ted Lemon wrote:
> My personal take on this is that you should not form a fake mac address,
> because your chances of collision don't get any better than if you just
> chose random times.   What I would suggest is that you give the
> virtualization software a way to communicate a unique id to each host,
> separate from the mac address.   This could be a one-time ID, and you
> could form a DUID-LLT-like identifier from it, except that instead of
> being (link-layer, time) it would be (link-layer, time, uid).   I think
> this would provide sufficient safety from collision.   I can help you to
> write up a draft for it if you would like.   It was never the intention
> in RFC3315 that the DUID types specified be the only ones ever used -
> it's just that none of us thought of the virtualization case.

Lets get together off-list and get something written up.  It should be
fairly easy for us to implement, as we already have plenty of
configuration parameters that must be unique across the set of virtual
servers.

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



From dhcwg-bounces@ietf.org Mon Feb 19 14:33:33 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJEFf-0002zR-2E; Mon, 19 Feb 2007 14:32:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJEFe-0002zH-8T
	for dhcwg@ietf.org; Mon, 19 Feb 2007 14:32:42 -0500
Received: from pacdcimo01.cable.comcast.com ([24.40.8.145])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJEFa-00009Z-TF
	for dhcwg@ietf.org; Mon, 19 Feb 2007 14:32:42 -0500
Received: from ([10.52.116.30])
	by pacdcimo01.cable.comcast.com with ESMTP  id KP-BXT38.816592;
	Mon, 19 Feb 2007 14:32:22 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	PAOAKEXCSMTP01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 14:32:21 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Background on CMTSs and routing
Date: Mon, 19 Feb 2007 14:32:21 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Background on CMTSs and routing
Thread-Index: AcdUJScv6soj8W75SEqMC8b2ruYmqQANzbOw
From: "Woundy, Richard" 
To: "Stig Venaas" 
X-OriginalArrivalTime: 19 Feb 2007 19:32:21.0900 (UTC)
	FILETIME=[ACF7E4C0:01C7545C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

>Just to clarify, I never suggested that this was a way to do things,
rather the contrary.

Please accept my apologies if I created any confusion about your
positions on this topic.

-- Rich

-----Original Message-----
From: Stig Venaas [mailto:stig.venaas@uninett.no]=20
Sent: Monday, February 19, 2007 7:54 AM
To: Woundy, Richard
Cc: dhcwg
Subject: Re: [dhcwg] Background on CMTSs and routing


Woundy, Richard wrote:
[...]
> Stig raised the possibility that perhaps the DHCP server could use=20
> dynamic routing protocols (particularly OSPF) to inject routes for=20
> delegated prefixes. I took this idea seriously, thought about the=20
> implications, and raised some concerns about whether "stale routes"=20
> could/would be injected by the DHCP server. While I used an OSPF=20
> example, the same concerns apply to iBGP route injection -- the DHCP

Just to clarify, I never suggested that this was a way to do things,
rather the contrary. What I said was that route injection by the DHCP
server generally is not possible (as also Ole mentioned later), but
pointed out that there was a theoretical possibility with OSPF. Then I
also pointed out the issue with "stale routes".

I brought this up in response to Ralph and someone else talking about
the possibility of the DHCP server doing injection. My view is that
injection by the DHCP server is not the way to go.

Stig

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



From dhcwg-bounces@ietf.org Mon Feb 19 14:37:57 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJEKZ-0004Sk-2X; Mon, 19 Feb 2007 14:37:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJEKY-0004Sf-F7
	for dhcwg@ietf.org; Mon, 19 Feb 2007 14:37:46 -0500
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJEKX-00012x-5Z
	for dhcwg@ietf.org; Mon, 19 Feb 2007 14:37:46 -0500
Received: from ([10.195.246.152])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH3.30355495;
	Mon, 19 Feb 2007 14:37:18 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	NJMDCEXCRLY01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 14:37:18 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Delegated prefix managed by multiple entities
Date: Mon, 19 Feb 2007 14:37:17 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Delegated prefix managed by multiple entities
Thread-Index: AcdS479Pqbu9IZfPQiO2/vstpdSdiABcpJSw
From: "Woundy, Richard" 
To: "Ted Lemon" ,
	"Damien Neil" 
X-OriginalArrivalTime: 19 Feb 2007 19:37:18.0197 (UTC)
	FILETIME=[5D933A50:01C7545D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: dhcwg , "Woundy,
	Richard" 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Ted,

>Ask Chris what his attitude about this would be

I suspect we have a different understanding of the expected customer
base for a service provider DHCP-PD solution.

If a service provider customer (e.g. Nominum) has their own IT/network
person (employee or contractor) and is willing to buy their own router,
they are probably not a good prospect for a DHCP-PD solution. The
customer would configure its own router manually, and purchase TDM
circuits (T1, T3, OC3) and/or Ethernet handoffs (10M, 100M) from one or
more service providers.

For the use case for DHCP-PD and potential multi-homing, I am thinking
about customers that want highly available Internet access, but don't
employ an IT/network resource, and don't want to buy a router. Let me
suggest some possible representative examples, that you may or may not
agree with: insurance agents (e.g. Internet access to sell policies and
submit claims), small consulting companies (even if they are tech-savvy,
they can't afford in-house network folks), coffee shops and fast food
franchises (e.g. to support their customer's Internet access), and
home-based businesses.

While we are on this topic, let me also correct an earlier statement I
made, in response to a question from you:

>In today's world, most business customers would get an IPv4 subnet from
us, but some customers might bring their own IPv4 subnets. In the latter
case, we may have to reconfigure our external BGP routers to announce
the customer's subnet to the rest of the world (depending on whether we
use "white lists" or "black lists" for eBGP subnet reachability); this
extra work is part of the reason why customer-owned subnets would be
strongly discouraged (customer-owned subnets also cause route table
growth in the default-free backbone, which also isn't good). In any
case, we would reconfigure the CMTS (manually) to expect the customer
subnet to be announced by the "cable router" at the customer premise via
RIP.

Today, my company (Comcast) would NOT accept a customer-owned IPv4
subnet, because of the difficulty in configuring and supporting this
service in our network. But if it were easier to support this particular
service, we probably would. :)

I have heard reports from time to time that other cable operators have
supported this, sometimes for "special customers".

-- Rich

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]=20
Sent: Saturday, February 17, 2007 5:33 PM
To: Damien Neil
Cc: dhcwg
Subject: Re: [dhcwg] Delegated prefix managed by multiple entities


On Feb 17, 2007, at 3:10 PM, Damien Neil wrote:
> This doesn't strike me as being different from any other use of
> reservations or fixed-address assignments in DHCP.  Why wouldn't =20
> the provider want to centralize management of router address =20
> configuration on their DHCP server?  And why would the user expect =20
> to have any configuration access to the provider-supplied router?  =20
> There's a DSL modem sitting on the floor by me; I certainly don't =20
> expect to be able to configure its address, regardless of whether =20
> that address is statically or dynamically assigned.

Because I think a multihoming customer really wants full =20
configuration control of their end of things - relying on someone =20
else's DHCP service seems like a variable that you wouldn't want to =20
do.  Ask Chris what his attitude about this would be - I'm just =20
speculating.



_______________________________________________
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-bounces@ietf.org Mon Feb 19 14:46:02 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJESM-0001Qd-7u; Mon, 19 Feb 2007 14:45:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJERb-00017W-PU
	for dhcwg@ietf.org; Mon, 19 Feb 2007 14:45:03 -0500
Received: from paoakoavas09.cable.comcast.com ([208.17.35.58]
	helo=cable.comcast.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HJEPU-00027D-9C
	for dhcwg@ietf.org; Mon, 19 Feb 2007 14:42:53 -0500
Received: from ([24.40.15.92])
	by paoakoavas09.cable.comcast.com with ESMTP  id KP-TDCH7.30500416;
	Mon, 19 Feb 2007 14:42:31 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	PACDCEXCSMTP03.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 14:42:32 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] Background on CMTSs and routing
Date: Mon, 19 Feb 2007 14:42:31 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] Background on CMTSs and routing
Thread-Index: AcdQY3NT6b086CsYSsOe3MtHPVTS4gAN0SWQAB4E2CAA0rWPQA==
From: "Woundy, Richard" 
To: "Templin, Fred L" ,
	"dhcwg" 
X-OriginalArrivalTime: 19 Feb 2007 19:42:32.0161 (UTC)
	FILETIME=[18B65510:01C7545E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

My apologies for my error.

I wish I had just said I didn't understand your use case; I thought I
said that in my email, but looking back I see I didn't. :(

-- Rich

-----Original Message-----
From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]=20
Sent: Thursday, February 15, 2007 10:12 AM
To: Woundy, Richard; dhcwg
Subject: RE: [dhcwg] Background on CMTSs and routing


> To be fair, Fred Templin has some other use case in mind, in which the

> relay agent is NOT a router,=20
> .

No - the relay agent is a router in my use case; it's just selective
about which routes it will inject into the IGP. But I'll agree that it
is a different use case - I didn't even know what CMTS stood for before
seeing some of the messages on this list.

Fred
fred.l.templin@boeing.com

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



From dhcwg-bounces@ietf.org Mon Feb 19 18:10:00 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJHdE-0004CG-Cy; Mon, 19 Feb 2007 18:09:16 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJHdD-0004Av-NA
	for dhcwg@ietf.org; Mon, 19 Feb 2007 18:09:15 -0500
Received: from goliath.isc.org ([2001:4f8:3:bb::72])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJHdA-0004xj-7w
	for dhcwg@ietf.org; Mon, 19 Feb 2007 18:09:15 -0500
Received: by goliath.isc.org (Postfix, from userid 10200)
	id 2DB1D5A6ED; Mon, 19 Feb 2007 15:08:51 -0800 (PST)
Date: Mon, 19 Feb 2007 15:08:51 -0800
From: "David W. Hankins" 
To: dhcwg@ietf.org
Subject: Re: [dhcwg] FW: RFC3315 question
Message-ID: <20070219230851.GD2628@isc.org>
References: 
	<8E296595B6471A4689555D5D725EBB2103467C67@xmb-rtp-20a.amer.cisco.com>
	<39C363776A4E8C4A94691D2BD9D1C9A1017746F5@XCH-NW-7V2.nw.nos.boeing.com>
Mime-Version: 1.0
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1017746F5@XCH-NW-7V2.nw.nos.boeing.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0566098214=="
Errors-To: dhcwg-bounces@ietf.org


--===============0566098214==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU"
Content-Disposition: inline


--rS8CxjVDS/+yyDmU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, Feb 17, 2007 at 11:38:12AM -0800, Templin, Fred L wrote:
> In particular, it might be useful to define
> a new DUID type that includes a client's public key such as
> required by RFC3972. The actual format of the DUID type is for
> further study, e.g., in addition to the public key it might be
> desireable to include a link-layer address, a timestamp, etc.

I think it's a fantastic idea.

If servers and clients could identify themselves with a public
key, then we could exchange greater varieties of configuration
information (which may require encryption) over an encapsulated
option.

The trust model for such exchanges would need some careful
thought, but on first inspection I see no reason why the SSH
model can't be adopted here (ask the operator, then cache the
key with link layer hints).


I've long wanted to experiment with public keys in DHCPv4
authentication...due to the size limitations in DHCPv4 payloads,
that's sent me down some ratholes I have vague notions for, but
nothing (yet) I wish to expose to the scrutiny of public review.

Since DHCPv4 now defines RFC3315 DUID's as client-identifier
contents (with the IAID prepended), I think there's a great
deal of good that could come from defining a method to transport
unique indexes to public keys, rather than the keys themselves,
in the DUID so that we could leverage the same mechanism for
both protocols (by writing a draft that lifts the DHCPv4 server
restriction that client identifiers be opaque).


I think there are some non-trivial challenges here, but any
effort down this path is worth our learning something from it.

-- 
ISC Training!  http://www.isc.org/training/  training@isc.org
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

--rS8CxjVDS/+yyDmU
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFF2i4DcXeLeWu2vmoRAstIAJ0afjagahh2BPg3lXMSf+48/CpYYACeN7E3
8VrBJaEMkmBubuS6dggEQJc=
=PIdC
-----END PGP SIGNATURE-----

--rS8CxjVDS/+yyDmU--


--===============0566098214==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0566098214==--




From dhcwg-bounces@ietf.org Tue Feb 20 08:48:17 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJVLC-0008Ek-1B; Tue, 20 Feb 2007 08:47:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJVLA-0008Ef-NV
	for dhcwg@ietf.org; Tue, 20 Feb 2007 08:47:32 -0500
Received: from e4.ny.us.ibm.com ([32.97.182.144])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJVL9-0007OA-Ff
	for dhcwg@ietf.org; Tue, 20 Feb 2007 08:47:32 -0500
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l1KDlT37030079
	for ; Tue, 20 Feb 2007 08:47:29 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id
	l1KDlTMb263406 for ; Tue, 20 Feb 2007 08:47:29 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1])
	by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l1KDlTda021916 for ; Tue, 20 Feb 2007 08:47:29 -0500
Received: from cichlid.raleigh.ibm.com ([9.67.191.202])
	by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l1KDlTro021901; Tue, 20 Feb 2007 08:47:29 -0500
Received: from cichlid (localhost.localdomain [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l1KDlMPX002189;
	Tue, 20 Feb 2007 08:47:23 -0500
Message-Id: <200702201347.l1KDlMPX002189@cichlid.raleigh.ibm.com>
To: Ted Lemon 
Subject: Re: [dhcwg] DUID on a Virtual Host 
In-reply-to:  
References: <45D61560.4080103@us.ibm.com>
	
Comments: In-reply-to Ted Lemon 
	message dated "Fri, 16 Feb 2007 14:17:14 -0700."
Date: Tue, 20 Feb 2007 08:47:22 -0500
From: Thomas Narten 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

> This could be a one-time ID, and you could form a DUID-LLT-like
> identifier from it, except that instead of being (link-layer, time)
> it would be (link-layer, time, uid).

To be clear, Do you think you can reuse the existing DUID-LLT type, or
do you think you need to define a new one?

In looking at the IANA considerations for DUIDs (see RFC3315), it says
new DUIDS are created (only) through Standards Action. I wonder if
that bar is too high. I'd think it would be sufficient to grant them
under other types of RFCs. I.e., is it appropriate/necessary to
_standardize_ all DUID types? I would imagine there will be special
cases that fairly unique to specific scenarios which don't justify
standardization.

That said, in this case (virtualized hosts), I suspect there is
utility/value in having a standardized approach, as it seems the
scenario is somewhat general.

Thomas

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



From dhcwg-bounces@ietf.org Tue Feb 20 09:54:29 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJWMt-0000pL-9k; Tue, 20 Feb 2007 09:53:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWMr-0000om-MK
	for dhcwg@ietf.org; Tue, 20 Feb 2007 09:53:21 -0500
Received: from tyholt.uninett.no ([2001:700:1::eecb])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJWMq-0005Oh-5b
	for dhcwg@ietf.org; Tue, 20 Feb 2007 09:53:21 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tyholt.uninett.no (Postfix) with ESMTP id DE048B5B7F;
	Tue, 20 Feb 2007 15:53:14 +0100 (CET)
Received: from tyholt.uninett.no ([127.0.0.1])
	by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 30968-01-97; Tue, 20 Feb 2007 15:53:14 +0100 (CET)
Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no
	[IPv6:2001:700:1:7:215:f2ff:fe35:307d])
	by tyholt.uninett.no (Postfix) with ESMTP id B4E38B5AE2;
	Tue, 20 Feb 2007 15:53:14 +0100 (CET)
Message-ID: <45DB0B5A.5020302@uninett.no>
Date: Tue, 20 Feb 2007 15:53:14 +0100
From: Stig Venaas 
User-Agent: Thunderbird 1.5.0.9 (X11/20070129)
MIME-Version: 1.0
To: "David W. Hankins" 
Subject: Re: [dhcwg] Adopting draft-dhankins-atomic-dhcp-00 as wg work item
References: <20070126173821.GE3731@isc.org>	<8E296595B6471A4689555D5D725EBB210318EBF8@xmb-rtp-20a.amer.cisco.com>
	<20070127200304.GB22907@isc.org>
In-Reply-To: <20070127200304.GB22907@isc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

David W. Hankins wrote:
> On Sat, Jan 27, 2007 at 01:40:36PM -0500, Bernie Volz (volz) wrote:
>> I recall the same. But, I also see no reason to allow the reworked draft
>> to be published as a DHC WG work item (rather than first as an
>> indidivual submission).
> 
> It does feel like we're pushing the process a little far for
> expedience that isn't necessary.
> 
> I have no problem making the reworked document a new individual
> submission so it can be judged on its new merits.
> 

I agree that is better, there's no need for us to adopt it yet, so
we'll wait for that,

Stig


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



From dhcwg-bounces@ietf.org Tue Feb 20 10:11:55 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJWeP-0001Pa-Kc; Tue, 20 Feb 2007 10:11:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWeO-0001P7-Nm
	for dhcwg@ietf.org; Tue, 20 Feb 2007 10:11:28 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HJWeN-0000J3-Bu
	for dhcwg@ietf.org; Tue, 20 Feb 2007 10:11:28 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by sj-iport-3.cisco.com with ESMTP; 20 Feb 2007 07:11:26 -0800
X-IronPort-AV: i="4.14,196,1170662400"; 
	d="scan'208"; a="465719525:sNHT58774452"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1KFBQ7G004188; 
	Tue, 20 Feb 2007 10:11:26 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1KFAuOU021261; 
	Tue, 20 Feb 2007 10:11:26 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Feb 2007 10:11:05 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] DUID on a Virtual Host 
Date: Tue, 20 Feb 2007 10:11:04 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB21035095C8@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <200702201347.l1KDlMPX002189@cichlid.raleigh.ibm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] DUID on a Virtual Host 
Thread-Index: AcdU9hvkmfweW2B+Tvi98XwvKuIBcwACssNA
From: "Bernie Volz \(volz\)" 
To: "Thomas Narten" , "Ted Lemon" 
X-OriginalArrivalTime: 20 Feb 2007 15:11:05.0735 (UTC)
	FILETIME=[57A8B170:01C75501]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1550; t=1171984286;
	x=1172848286; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20DUID=20on=20a=20Virtual=20Host=20
	|Sender:=20 |To:=20=22Thomas=20Narten=22=20,
	=20=22Ted=20Lemon=22=2 0;
	bh=AHS0mJKOFPZUzU1IvZcKChqgLat7IjWlmLPC5UL3a9Y=;
	b=Nb6YnT6GNUvuEqZre/4HAZJ/HcDuVjAMsp16nxVX5yAbzikuFYUMsL3ieFILHViNnnfEoqag
	uF4n63/Y7mnPM7LpxDF4WOyWw+D/0ri+CMp+SHErqGZIWoe8TFvpy4hH;
Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Thomas:

The DUID-EN is likely a DUID type that can be used by an organization
(or standards body) to define a type of their liking. There may be some
subtle issues with the wording in RFC 3315 (section 9.3) for some uses
(such as when the identifier is assigned and how it is stored).

- Bernie=20

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]=20
Sent: Tuesday, February 20, 2007 8:47 AM
To: Ted Lemon
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] DUID on a Virtual Host=20

> This could be a one-time ID, and you could form a DUID-LLT-like
> identifier from it, except that instead of being (link-layer, time)
> it would be (link-layer, time, uid).

To be clear, Do you think you can reuse the existing DUID-LLT type, or
do you think you need to define a new one?

In looking at the IANA considerations for DUIDs (see RFC3315), it says
new DUIDS are created (only) through Standards Action. I wonder if
that bar is too high. I'd think it would be sufficient to grant them
under other types of RFCs. I.e., is it appropriate/necessary to
_standardize_ all DUID types? I would imagine there will be special
cases that fairly unique to specific scenarios which don't justify
standardization.

That said, in this case (virtualized hosts), I suspect there is
utility/value in having a standardized approach, as it seems the
scenario is somewhat general.

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-bounces@ietf.org Tue Feb 20 10:25:04 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJWrD-00021f-Ns; Tue, 20 Feb 2007 10:24:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWrC-00021Y-FA
	for dhcwg@ietf.org; Tue, 20 Feb 2007 10:24:42 -0500
Received: from e1.ny.us.ibm.com ([32.97.182.141])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJWrB-0003ss-75
	for dhcwg@ietf.org; Tue, 20 Feb 2007 10:24:42 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l1KFOco2016439
	for ; Tue, 20 Feb 2007 10:24:38 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215])
	by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id
	l1KFOcq8301836 for ; Tue, 20 Feb 2007 10:24:38 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1])
	by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l1KFOc4q027620 for ; Tue, 20 Feb 2007 10:24:38 -0500
Received: from cichlid.raleigh.ibm.com ([9.67.191.202])
	by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l1KFObHS027576; Tue, 20 Feb 2007 10:24:37 -0500
Received: from cichlid (localhost.localdomain [127.0.0.1])
	by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l1KFOQO4026527;
	Tue, 20 Feb 2007 10:24:26 -0500
Message-Id: <200702201524.l1KFOQO4026527@cichlid.raleigh.ibm.com>
To: "Bernie Volz \(volz\)" 
Subject: Re: [dhcwg] DUID on a Virtual Host 
In-reply-to: <8E296595B6471A4689555D5D725EBB21035095C8@xmb-rtp-20a.amer.cisco.com>
References: <8E296595B6471A4689555D5D725EBB21035095C8@xmb-rtp-20a.amer.cisco.com>
Comments: In-reply-to "Bernie Volz \(volz\)" 
	message dated "Tue, 20 Feb 2007 10:11:04 -0500."
Date: Tue, 20 Feb 2007 10:24:25 -0500
From: Thomas Narten 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: dhcwg@ietf.org, Ted Lemon 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

> The DUID-EN is likely a DUID type that can be used by an organization
> (or standards body) to define a type of their liking.

Looking at this  more closely, I would tend to agree.

> There may be some subtle issues with the wording in RFC 3315
> (section 9.3) for some uses (such as when the identifier is assigned
> and how it is stored).

Not subtle actually. :-(


>    The source of the identifier is left up to the vendor defining it,
>    but each identifier part of each DUID-EN MUST be unique to the device
>    that is using it, and MUST be assigned to the device at the time it
>    is manufactured and stored in some form of non-volatile storage.  The

the wording above effectively rules out usage for virtual hosts. I'd
also argue that they wording above is too strong, or at least, I don't
understand why the requirement is so strong (in particular "assigned
... at the time it is manufactured..."), which I interpret to mean
assigned by the vendor BEFORE being shipped to the customer.

In the case of virtual hosts, the assignment would effectively be done
by the customer at deployment time.

Thomas

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



From dhcwg-bounces@ietf.org Tue Feb 20 10:33:38 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJWzO-0005T4-KV; Tue, 20 Feb 2007 10:33:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJWzM-0005Su-Li
	for dhcwg@ietf.org; Tue, 20 Feb 2007 10:33:08 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HJWzK-0005az-9t
	for dhcwg@ietf.org; Tue, 20 Feb 2007 10:33:08 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by sj-iport-2.cisco.com with ESMTP; 20 Feb 2007 07:33:05 -0800
X-IronPort-AV: i="4.14,196,1170662400"; 
	d="scan'208"; a="361787973:sNHT55020356"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1KFX3sU013569; 
	Tue, 20 Feb 2007 10:33:03 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1KFX3VT022166; 
	Tue, 20 Feb 2007 10:33:03 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Feb 2007 10:33:03 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] DUID on a Virtual Host 
Date: Tue, 20 Feb 2007 10:33:02 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB21035095E7@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <200702201524.l1KFOQO4026527@cichlid.raleigh.ibm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] DUID on a Virtual Host 
Thread-Index: AcdVA3pvSkvsYr4vQyKkmBcjsIY9UQAALPAg
From: "Bernie Volz \(volz\)" 
To: "Thomas Narten" 
X-OriginalArrivalTime: 20 Feb 2007 15:33:03.0297 (UTC)
	FILETIME=[68FCB310:01C75504]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1580; t=1171985583;
	x=1172849583; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20DUID=20on=20a=20Virtual=20Host=20
	|Sender:=20 |To:=20=22Thomas=20Narten=22=20;
	bh=JEE4OR8ju2k9Ylq0BvmnMEdEKTz0nvH5/9ryI3a1IJ8=;
	b=J3gFw5xYXCp6PhKtmei4ePPwggK6nFMYN8BChOpAzlaUTpC/qSNo0W03mAz94Ykcrw2sC2IT
	a2OHzzWleVwTmk6wYEGhJwlWnLCUhU59O9In6AyPET5ldWS2tzBJzU/E;
Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: dhcwg@ietf.org, Ted Lemon 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Yeah, something to consider rewording for a 3315-bis.

- Bernie=20

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]=20
Sent: Tuesday, February 20, 2007 10:24 AM
To: Bernie Volz (volz)
Cc: dhcwg@ietf.org; Ted Lemon
Subject: Re: [dhcwg] DUID on a Virtual Host=20

> The DUID-EN is likely a DUID type that can be used by an organization
> (or standards body) to define a type of their liking.

Looking at this  more closely, I would tend to agree.

> There may be some subtle issues with the wording in RFC 3315
> (section 9.3) for some uses (such as when the identifier is assigned
> and how it is stored).

Not subtle actually. :-(


>    The source of the identifier is left up to the vendor defining it,
>    but each identifier part of each DUID-EN MUST be unique to the
device
>    that is using it, and MUST be assigned to the device at the time it
>    is manufactured and stored in some form of non-volatile storage.
The

the wording above effectively rules out usage for virtual hosts. I'd
also argue that they wording above is too strong, or at least, I don't
understand why the requirement is so strong (in particular "assigned
... at the time it is manufactured..."), which I interpret to mean
assigned by the vendor BEFORE being shipped to the customer.

In the case of virtual hosts, the assignment would effectively be done
by the customer at deployment time.

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-bounces@ietf.org Tue Feb 20 10:34:56 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJX16-0005qk-5W; Tue, 20 Feb 2007 10:34:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJX15-0005qc-1h
	for dhcwg@ietf.org; Tue, 20 Feb 2007 10:34:55 -0500
Received: from stl-smtpout-01.boeing.com ([130.76.96.56]
	helo=stl-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJX0z-0005zi-Pq
	for dhcwg@ietf.org; Tue, 20 Feb 2007 10:34:55 -0500
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4])
	by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1KFYiJ2026131
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 20 Feb 2007 09:34:44 -0600 (CST)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1KFYhCq009944; Tue, 20 Feb 2007 07:34:43 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1KFYYAL009454; Tue, 20 Feb 2007 07:34:43 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Feb 2007 07:34:42 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] DUID on a Virtual Host 
Date: Tue, 20 Feb 2007 07:34:14 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774702@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <200702201524.l1KFOQO4026527@cichlid.raleigh.ibm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] DUID on a Virtual Host 
Thread-Index: AcdVA3iv6id2ql5sTFGpYz9jZpqIZwAAI5NQ
References: <8E296595B6471A4689555D5D725EBB21035095C8@xmb-rtp-20a.amer.cisco.com>
	<200702201524.l1KFOQO4026527@cichlid.raleigh.ibm.com>
From: "Templin, Fred L" 
To: , 
X-OriginalArrivalTime: 20 Feb 2007 15:34:42.0439 (UTC)
	FILETIME=[A4149170:01C75504]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: dhcwg@ietf.org, Ted.Lemon@nominum.com
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

> In the case of virtual hosts, the assignment would effectively be done
> by the customer at deployment time.

DUID based on public key, maybe? Or, maybe I need to understand
more about virtual hosts, e.g., does each virtual host on a
physical platform get its own public key (or any other kind of
unique identifier) or is it one public key per physical platform?

Fred
fred.l.templin@boeing.com=20

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



From dhcwg-bounces@ietf.org Tue Feb 20 10:36:54 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJX2b-0006Jd-ME; Tue, 20 Feb 2007 10:36:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJX2a-0006JC-Ge
	for dhcwg@ietf.org; Tue, 20 Feb 2007 10:36:28 -0500
Received: from tyholt.uninett.no ([2001:700:1::eecb])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJX2Z-0006Q5-Vy
	for dhcwg@ietf.org; Tue, 20 Feb 2007 10:36:28 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tyholt.uninett.no (Postfix) with ESMTP id AE446B5AD3
	for ; Tue, 20 Feb 2007 16:36:20 +0100 (CET)
Received: from tyholt.uninett.no ([127.0.0.1])
	by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 09853-01-2 for ;
	Tue, 20 Feb 2007 16:36:20 +0100 (CET)
Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no
	[IPv6:2001:700:1:7:215:f2ff:fe35:307d])
	by tyholt.uninett.no (Postfix) with ESMTP id 82A32B5AB0
	for ; Tue, 20 Feb 2007 16:36:20 +0100 (CET)
Message-ID: <45DB1574.5070501@uninett.no>
Date: Tue, 20 Feb 2007 16:36:20 +0100
From: Stig Venaas 
User-Agent: Thunderbird 1.5.0.9 (X11/20070129)
MIME-Version: 1.0
To: dhcwg 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: [dhcwg] dhc wg last call on dhcpv6-reconfigure-rebind
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

This message announces a wg last call on "Rebind Capability in DHCPv6
Reconfigure Messages" 

The last call will conclude at 1700EST on Tue, 2007-03-06.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

As defined in DHCPv6 (RFC 3315), the reconfigure message msg-type can
only be renew or information-request. 
draft-ietf-dhc-dhcpv6-reconfigure-rebind expands the allowed values of
the msg-type field of the reconfigure message to allow the server to
indicate that the client is to attempt to perform a Rebind; since Rebind
messages are multicast, this avoids the necessity of the client 
contacting a particular server.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-reconfigure-rebind-01.txt

Stig

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



From dhcwg-bounces@ietf.org Tue Feb 20 16:19:32 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJcNy-0007sN-KQ; Tue, 20 Feb 2007 16:18:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcNx-0007s5-Nw
	for dhcwg@ietf.org; Tue, 20 Feb 2007 16:18:53 -0500
Received: from e1.ny.us.ibm.com ([32.97.182.141])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJcNv-0007Cx-Fw
	for dhcwg@ietf.org; Tue, 20 Feb 2007 16:18:53 -0500
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l1KLInow010536
	for ; Tue, 20 Feb 2007 16:18:49 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id
	l1KLInGx283888 for ; Tue, 20 Feb 2007 16:18:49 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1])
	by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l1KLImMO016093 for ; Tue, 20 Feb 2007 16:18:48 -0500
Received: from [9.27.40.30] (brabson.raleigh.ibm.com [9.27.40.30])
	by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l1KLImjc016054; Tue, 20 Feb 2007 16:18:48 -0500
Message-ID: <45DB65B8.7080107@us.ibm.com>
Date: Tue, 20 Feb 2007 16:18:48 -0500
From: Roy Brabson 
Organization: IBM Corporation
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "Templin, Fred L" 
Subject: Re: [dhcwg] DUID on a Virtual Host
References: <8E296595B6471A4689555D5D725EBB21035095C8@xmb-rtp-20a.amer.cisco.com>
	<200702201524.l1KFOQO4026527@cichlid.raleigh.ibm.com>
	<39C363776A4E8C4A94691D2BD9D1C9A101774702@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774702@XCH-NW-7V2.nw.nos.boeing.com>
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93238566e09e6e262849b4f805833007
Cc: narten@us.ibm.com, dhcwg@ietf.org, volz@cisco.com, Ted.Lemon@nominum.com
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Templin, Fred L wrote:
> DUID based on public key, maybe? Or, maybe I need to understand
> more about virtual hosts, e.g., does each virtual host on a
> physical platform get its own public key (or any other kind of
> unique identifier) or is it one public key per physical platform?

On our systems, the choice of which certificates to use is left to the
administrator.  In some cases, it makes sense to use the same
certificate across multiple hosts.  For instance, the administrator may
want to use the same certificate across a set of applications running on
 separate hosts.  Or the administrator may want to use the same
certificate for a group of hosts within the same cluster, presenting a
single system image to clients that connect to the cluster.  In other
cases, the administrator may choose to use different certificates at the
various hosts.  Or the administrator may use a mixture of unique and
shared certificates.

But, stepping back for a second, are public keys considered unique,
anyway?  I'm not a security expert, but I  thought public keys were
generated by the end user, and there is nothing that prevents two users
from generating the same public key.  If so, how  does a a DHCP server
differentiate between two hosts that choose to use the same public key.

Roy

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



From dhcwg-bounces@ietf.org Tue Feb 20 16:23:29 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJcSK-0000sC-QW; Tue, 20 Feb 2007 16:23:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcSK-0000rs-1h
	for dhcwg@ietf.org; Tue, 20 Feb 2007 16:23:24 -0500
Received: from stl-smtpout-01.boeing.com ([130.76.96.56]
	helo=stl-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJcSF-0008S6-O5
	for dhcwg@ietf.org; Tue, 20 Feb 2007 16:23:24 -0500
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216])
	by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1KLNIPI004496
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Tue, 20 Feb 2007 15:23:18 -0600 (CST)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1KLNHlR014344; Tue, 20 Feb 2007 13:23:17 -0800 (PST)
Received: from XCH-NWBH-10.nw.nos.boeing.com (xch-nwbh-10.nw.nos.boeing.com
	[130.247.55.83])
	by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1KLNENO014193; Tue, 20 Feb 2007 13:23:16 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Feb 2007 13:23:15 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] DUID on a Virtual Host
Date: Tue, 20 Feb 2007 13:23:04 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177470D@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <45DB65B8.7080107@us.ibm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] DUID on a Virtual Host
Thread-Index: AcdVNLthVPYK0A4VQg6GkUKz8b4+rwAACEnQ
References: <8E296595B6471A4689555D5D725EBB21035095C8@xmb-rtp-20a.amer.cisco.com>
	<200702201524.l1KFOQO4026527@cichlid.raleigh.ibm.com>
	<39C363776A4E8C4A94691D2BD9D1C9A101774702@XCH-NW-7V2.nw.nos.boeing.com>
	<45DB65B8.7080107@us.ibm.com>
From: "Templin, Fred L" 
To: 
X-OriginalArrivalTime: 20 Feb 2007 21:23:15.0462 (UTC)
	FILETIME=[5536A260:01C75535]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: narten@us.ibm.com, dhcwg@ietf.org, volz@cisco.com, Ted.Lemon@nominum.com
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

> But, stepping back for a second, are public keys considered unique,
> anyway?  I'm not a security expert, but I  thought public keys were
> generated by the end user, and there is nothing that prevents=20
> two users
> from generating the same public key.  If so, how  does a a DHCP server
> differentiate between two hosts that choose to use the same=20
> public key.

Yes, I wondered about that too and that was why I suggested
earlier that additional information (e.g., a L2 address, a
timestamp, etc.) might also be needed.

Anyone else know about this?

Fred
fred.l.templin@boeing.com

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



From dhcwg-bounces@ietf.org Tue Feb 20 16:53:30 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJcv3-0004jR-JS; Tue, 20 Feb 2007 16:53:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcv2-0004jL-5K
	for dhcwg@ietf.org; Tue, 20 Feb 2007 16:53:04 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJcv0-0000fn-On
	for dhcwg@ietf.org; Tue, 20 Feb 2007 16:53:04 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id 243795684E;
	Tue, 20 Feb 2007 13:52:48 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.736,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.334
X-Spam-Level: 
Received: from [10.0.0.190] ([66.93.162.128])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Tue, 20 Feb 2007 13:52:45 -0800
In-Reply-To: <45DB65B8.7080107@us.ibm.com>
References: <8E296595B6471A4689555D5D725EBB21035095C8@xmb-rtp-20a.amer.cisco.com>
	<200702201524.l1KFOQO4026527@cichlid.raleigh.ibm.com>
	<39C363776A4E8C4A94691D2BD9D1C9A101774702@XCH-NW-7V2.nw.nos.boeing.com>
	<45DB65B8.7080107@us.ibm.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] DUID on a Virtual Host
Date: Tue, 20 Feb 2007 14:52:38 -0700
To: Roy Brabson 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: narten@us.ibm.com, dhcwg@ietf.org, "Templin,
	Fred L" , volz@cisco.com
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 20, 2007, at 2:18 PM, Roy Brabson wrote:
> But, stepping back for a second, are public keys considered unique,
> anyway?  I'm not a security expert, but I  thought public keys were
> generated by the end user, and there is nothing that prevents two  
> users
> from generating the same public key.  If so, how  does a a DHCP server
> differentiate between two hosts that choose to use the same public  
> key.

In fact, what I would say about this whole conversation is that keys,  
like clients, are *things to be identified*, not *identifiers*.   You  
call a key something.   Every piece of key generation software I've  
ever used has worked that way - whether you're generating an ssh key  
or an SSL key or a DNS key, the key has a name, and you refer to it  
by name.   It may be that for some reason it makes sense to include a  
public key in a DHCP transaction, but including it *as the  
identifier* strikes me as confusing two functions - identification  
and authentication.



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



From dhcwg-bounces@ietf.org Tue Feb 20 16:55:59 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJcxr-0004ST-2B; Tue, 20 Feb 2007 16:55:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJcxp-0004RO-Ae
	for dhcwg@ietf.org; Tue, 20 Feb 2007 16:55:57 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJcxo-0001Fv-0p
	for dhcwg@ietf.org; Tue, 20 Feb 2007 16:55:57 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id A149156821;
	Tue, 20 Feb 2007 13:55:55 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.728,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.342
X-Spam-Level: 
Received: from [10.0.0.190] ([66.93.162.128])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Tue, 20 Feb 2007 13:55:53 -0800
In-Reply-To: <200702201347.l1KDlMPX002189@cichlid.raleigh.ibm.com>
References: <45D61560.4080103@us.ibm.com>
	
	<200702201347.l1KDlMPX002189@cichlid.raleigh.ibm.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3F152A18-E9BE-4B39-9777-57F16089C924@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] DUID on a Virtual Host 
Date: Tue, 20 Feb 2007 14:55:49 -0700
To: Thomas Narten 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 20, 2007, at 6:47 AM, Thomas Narten wrote:
>> This could be a one-time ID, and you could form a DUID-LLT-like
>> identifier from it, except that instead of being (link-layer, time)
>> it would be (link-layer, time, uid).
>
> To be clear, Do you think you can reuse the existing DUID-LLT type, or
> do you think you need to define a new one?

We would have to define a new one.   I don't think it makes sense to  
use the same format, because the documentation doesn't really match  
the proposed new use, and I would expect that to lead to needless  
confusion.

> In looking at the IANA considerations for DUIDs (see RFC3315), it says
> new DUIDS are created (only) through Standards Action. I wonder if
> that bar is too high. I'd think it would be sufficient to grant them
> under other types of RFCs. I.e., is it appropriate/necessary to
> _standardize_ all DUID types? I would imagine there will be special
> cases that fairly unique to specific scenarios which don't justify
> standardization.

I think relaxing it to "documented in an RFC" might be okay - someone  
might define a private use and publish an informational RFC.   I'm  
not sure how important this is, though - it seems like a fairly  
unlikely scenario.

> That said, in this case (virtualized hosts), I suspect there is
> utility/value in having a standardized approach, as it seems the
> scenario is somewhat general.

Agreed.




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



From dhcwg-bounces@ietf.org Tue Feb 20 20:34:15 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJgMB-0006zp-6h; Tue, 20 Feb 2007 20:33:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJgM9-0006xt-BP
	for dhcwg@ietf.org; Tue, 20 Feb 2007 20:33:17 -0500
Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177]
	helo=mail.alcatel-sbell.com.cn)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJgM7-00012M-KY
	for dhcwg@ietf.org; Tue, 20 Feb 2007 20:33:17 -0500
Received: from asbmail4.sbell.com.cn (localhost [127.0.0.1])
	by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id
	l1L1Wp2n002796 for ; Wed, 21 Feb 2007 09:32:51 +0800
Received: from asbmail2.sbell.com.cn ([172.24.208.62]) by 
	asbmail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713);
	Wed, 21 Feb 2007 09:33:01 +0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 21 Feb 2007 09:33:13 +0800
Message-ID: <9570C1261494D54D9D3115BC2C83429A02277D74@asbmail2.sbell.com.cn>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: a question for rfc3993
Thread-Index: AcdVVxKtlCenzBqJQii8JVCfKcROYg==
From: "CTO WEN Haibo" 
To: 
X-OriginalArrivalTime: 21 Feb 2007 01:33:01.0577 (UTC) 
	FILETIME=[39A24F90:01C75558]
X-imss-version: 2.046
X-imss-result: Passed
X-imss-approveListMatch: *@alcatel-sbell.com.cn
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Subject: [dhcwg] a question for rfc3993
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1392133212=="
Errors-To: dhcwg-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1392133212==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C75558.40E994A2"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C75558.40E994A2
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

RGVhciBhbGwsDQogDQpJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCBSRkMzOTkzIChpLmUuLCJTdWJz
Y3JpYmVyLUlEIFN1Ym9wdGlvbiBmb3IgdGhlIER5bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFBy
b3RvY29sIChESENQKSBSZWxheSBBZ2VudCBPcHRpb24iKS4gSG9wZSB5b3UgY291bGQgaGVscCBt
ZS4NCkluIHRoaXMgUkZDLCBpdCBzYXlzOiANCiAgIFN1YnNjcmliZXItSUQgc3Vib3B0aW9uIGNh
cnJpZXMgYSB2YWx1ZSB0aGF0IGNhbiBiZSBpbmRlcGVuZGVudCBvZg0KICAgdGhlIHBoeXNpY2Fs
IG5ldHdvcmsgY29uZmlndXJhdGlvbiB0aHJvdWdoIHdoaWNoIHRoZSBzdWJzY3JpYmVyIGlzDQog
ICBjb25uZWN0ZWQuICAuLi4gIFRoZSAic3Vic2NyaWJlci1pZCIgYXNzaWduZWQgYnkgdGhlIHBy
b3ZpZGVyDQogICBpcyBpbnRlbmRlZCB0byBiZSBzdGFibGUgYXMgY3VzdG9tZXJzIGNvbm5lY3Qg
dGhyb3VnaCBkaWZmZXJlbnQNCiAgIHBhdGhzLCBhbmQgYXMgbmV0d29yayBjaGFuZ2VzIG9jY3Vy
LiANCkkgd2FudCB0byBrbm93IHdobyBpcyByZXNwb25zaWJsZSB0byBpbnNlcnQgdGhpcyBzdWIt
b3B0aW9uPyBJZiBpdCBpcyB0aGUgcmVsYXkgYWdlbnQsIHdoYXQgcG9saWN5IG9yIG1hcHBpbmcg
YXJlIHVzZWQgZm9yIGluc2VydGluZyB0aGlzIHN1Ym9wdGlvbiBpbnRvIHRoZSBESENQIG1lc3Nh
Z2UgZnJvbSB0aGUgc29tZSBESENQIGNsaWVudD8NCkhvcGUgeW91IGNvdWxkIGhlbHAgbWUgcmVt
b3ZlIHRoZXNlIGNvbmZ1c2lvbnMuDQogDQpUaGFuayB5b3UgaW4gYWR2YW5jZS4gDQogDQpCZXN0
IHJlZ2FyZHMsIA0KSGFpYm8gV0VODQo=

------_=_NextPart_001_01C75558.40E994A2
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz
ZXQ9dXRmLTgiPgoKPCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBU
cmFuc2l0aW9uYWwvL0VOIj48SFRNTD48SEVBRD48L0hFQUQ+PEJPRFk+PERJVj5EZWFyIGFsbCw8
L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5JIGhhdmUgYSZuYnNwO3F1ZXN0aW9uIGFib3V0
IFJGQzM5OTMgKGkuZS4sIlN1YnNjcmliZXItSUQgU3Vib3B0aW9uIGZvciB0aGUgCkR5bmFtaWMg
SG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sIChESENQKSBSZWxheSBBZ2VudCBPcHRpb24iKS4g
SG9wZSB5b3UgY291bGQgCmhlbHAgbWUuPC9ESVY+CjxESVY+SW4gdGhpcyBSRkMsIGl0IHNheXM6
IDwvRElWPgo8RElWPiZuYnNwOyZuYnNwOyBTdWJzY3JpYmVyLUlEIHN1Ym9wdGlvbiBjYXJyaWVz
IGEgdmFsdWUgdGhhdCBjYW4gYmUgCmluZGVwZW5kZW50IG9mPEJSPiZuYnNwOyZuYnNwOyB0aGUg
cGh5c2ljYWwgbmV0d29yayBjb25maWd1cmF0aW9uIHRocm91Z2ggd2hpY2ggCnRoZSBzdWJzY3Jp
YmVyIGlzPEJSPiZuYnNwOyZuYnNwOyBjb25uZWN0ZWQuJm5ic3A7IC4uLiZuYnNwOyBUaGUgInN1
YnNjcmliZXItaWQiIAphc3NpZ25lZCBieSB0aGUgcHJvdmlkZXI8QlI+Jm5ic3A7Jm5ic3A7IGlz
IGludGVuZGVkIHRvIGJlIHN0YWJsZSBhcyBjdXN0b21lcnMgCmNvbm5lY3QgdGhyb3VnaCBkaWZm
ZXJlbnQ8QlI+Jm5ic3A7Jm5ic3A7IHBhdGhzLCBhbmQgYXMgbmV0d29yayBjaGFuZ2VzIG9jY3Vy
LiAKPC9ESVY+CjxESVY+ICAgICAgIEkgd2FudCB0byBrbm93IHdobyBpcyAKcmVzcG9uc2libGUg
dG8mbmJzcDtpbnNlcnQgdGhpcyBzdWItb3B0aW9uPyBJZiBpdCBpcyB0aGUgcmVsYXkgYWdlbnQs
IHdoYXQgcG9saWN5IG9yIAptYXBwaW5nIGFyZSB1c2VkIGZvciBpbnNlcnRpbmcgdGhpcyBzdWJv
cHRpb24gaW50byB0aGUgREhDUCBtZXNzYWdlIGZyb20gdGhlIHNvbWUgREhDUCAKY2xpZW50Pzwv
RElWPgo8RElWPkhvcGUgeW91IGNvdWxkIGhlbHAgbWUgcmVtb3ZlIHRoZXNlIGNvbmZ1c2lvbnMu
PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+VGhhbmsgeW91IGluIGFkdmFuY2UuIDwvRElW
Pgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkJlc3QgcmVnYXJkcywgPC9ESVY+CjxESVY+SGFpYm8g
V0VOPC9ESVY+PC9CT0RZPjwvSFRNTD4=

------_=_NextPart_001_01C75558.40E994A2--


--===============1392133212==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1392133212==--




From dhcwg-bounces@ietf.org Tue Feb 20 21:29:41 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJhEM-0001pE-La; Tue, 20 Feb 2007 21:29:18 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJhEK-0001p8-Vr
	for dhcwg@ietf.org; Tue, 20 Feb 2007 21:29:17 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJhEJ-00016z-Ij
	for dhcwg@ietf.org; Tue, 20 Feb 2007 21:29:16 -0500
Received: from sj-dkim-5.cisco.com ([171.68.10.79])
	by sj-iport-6.cisco.com with ESMTP; 20 Feb 2007 18:29:15 -0800
X-IronPort-AV: i="4.14,198,1170662400"; 
	d="scan'208"; a="114657991:sNHT46562751"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1L2TEp0007848; 
	Tue, 20 Feb 2007 18:29:14 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1L2Sgnd024792;
	Tue, 20 Feb 2007 18:29:14 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 20 Feb 2007 18:28:58 -0800
Received: from [127.0.0.1] ([10.70.237.16]) by xfe-sjc-211.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 18:28:57 -0800
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10177470D@XCH-NW-7V2.nw.nos.boeing.com>
References: <8E296595B6471A4689555D5D725EBB21035095C8@xmb-rtp-20a.amer.cisco.com>
	<200702201524.l1KFOQO4026527@cichlid.raleigh.ibm.com>
	<39C363776A4E8C4A94691D2BD9D1C9A101774702@XCH-NW-7V2.nw.nos.boeing.com>
	<45DB65B8.7080107@us.ibm.com>
	<39C363776A4E8C4A94691D2BD9D1C9A10177470D@XCH-NW-7V2.nw.nos.boeing.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <61C42E7D-47A8-4BC8-9A91-BDF474A9C8B0@cisco.com>
Content-Transfer-Encoding: 7bit
From: Markus Stenberg 
Subject: Re: [dhcwg] DUID on a Virtual Host
Date: Wed, 21 Feb 2007 11:28:43 +0900
To: "Templin, Fred L" 
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 21 Feb 2007 02:28:57.0609 (UTC)
	FILETIME=[09FC2790:01C75560]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1967; t=1172024954;
	x=1172888954; c=relaxed/simple; s=sjdkim5002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=mstenber@cisco.com;
	z=From:=20Markus=20Stenberg=20
	|Subject:=20Re=3A=20[dhcwg]=20DUID=20on=20a=20Virtual=20Host
	|Sender:=20; bh=BM4pmNmgE2nGeNJVzQSSW8NmxofXVaSquRgolJL9XqI=;
	b=Hh4yIbVcJwXpoI/kEDEsS2HnTVDi2gwT7NJOox7pjh6T2u0lcvH7n8leKUn0ARUONAeaEEqr
	rZBdovTA7w2FhX1YX+qweKXiwC/RcbMCTGqFofEVp4sTV44kTk1co6bk;
Authentication-Results: sj-dkim-5; header.From=mstenber@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim5002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: narten@us.ibm.com, dhcwg@ietf.org, Ted.Lemon@nominum.com, volz@cisco.com
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On 21.2.2007, at 6.23, Templin, Fred L wrote:
>> But, stepping back for a second, are public keys considered unique,
>> anyway?  I'm not a security expert, but I  thought public keys were
>> generated by the end user, and there is nothing that prevents
>> two users
>> from generating the same public key.  If so, how  does a a DHCP  
>> server
>> differentiate between two hosts that choose to use the same
>> public key.
> Yes, I wondered about that too and that was why I suggested
> earlier that additional information (e.g., a L2 address, a
> timestamp, etc.) might also be needed.

The answer is, it depends.. If you use a public key as-is, then, yes,  
collisions are possible but not probable  (probability of all say,  
1024 or 2048 bits being the same is roughly nil - think 1 in 2^1024  
and you find that it is very unlikely). Even intentionally creating  
same public key is insanely hard, equivalent in terms of effort to  
breaking the encryption itself.

Of course, lacking/broken sources of randomness (think: boxes with  
time that starts at 0, creating their first public keys at first boot  
with clock unset, and so forth) are different beast entirely.  With  
that sort of environment timestamp won't save you either.

I think the correct approach is just to promote semi-reasonable  
sources of randomness, and if that fails, initializing RNG with  
hardware parameters and then using the public keys as-is.

There is of course the question of what we want to accomplish with  
this scheme; raw public keys used like in SSH provide mostly just way  
of making sure that the users cannot easily pretend to be each other  
based on sniffed traffic (assuming you add signature option to the  
packets sent to the server, or alternatively receive encrypted  
subblocks from the server), and provide some protection of the  
content; however, are those desirable characteristics for DHCPv6?

Cheers,

-Markus


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



From dhcwg-bounces@ietf.org Wed Feb 21 08:59:39 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJrzN-0002KD-0R; Wed, 21 Feb 2007 08:58:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJrzM-0002K6-7D
	for dhcwg@ietf.org; Wed, 21 Feb 2007 08:58:32 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HJrzK-00070k-To
	for dhcwg@ietf.org; Wed, 21 Feb 2007 08:58:32 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by sj-iport-1.cisco.com with ESMTP; 21 Feb 2007 05:58:30 -0800
X-IronPort-AV: i="4.14,202,1170662400"; 
	d="scan'208"; a="763735093:sNHT52731966"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1LDwTqR014757
	for ; Wed, 21 Feb 2007 08:58:29 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1LDwJVZ000927
	for ; Wed, 21 Feb 2007 08:58:29 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Feb 2007 08:58:23 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 21 Feb 2007 08:58:22 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB2103509A4C@xmb-rtp-20a.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New draft - draft-volz-dhc-dhcpv6-vendor-message-00.txt
Thread-Index: AcdVwFmWxHPvxlqnS9mVJY/moggMcA==
From: "Bernie Volz \(volz\)" 
To: 
X-OriginalArrivalTime: 21 Feb 2007 13:58:23.0949 (UTC)
	FILETIME=[5A3EB7D0:01C755C0]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=374; t=1172066309;
	x=1172930309; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20New=20draft=20-=20draft-volz-dhc-dhcpv6-vendor-message-00.txt
	|Sender:=20 |To:=20;
	bh=WwQB2ZebxQYr/GwBt+zFJo7w5mKgasCL3VmonOP3R8M=;
	b=YrO+427CWVmSvM13XHOHyXGOPqYv7Qcdj959Gh0y/WTkch1hFMVJ2mzrbwbrkKqFbza3Nw2e
	FClvDhGndTEpiwVIPKjnyhq8VBdOLrBrsjNyighE3qOtYrv1BezaAb7O;
Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Subject: [dhcwg] New draft - draft-volz-dhc-dhcpv6-vendor-message-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

I submitted a new individual submission draft regarding the
"Experimental" message and options assignments. I decided to call these
Vendor-specific.

=20
http://www.ietf.org/internet-drafts/draft-volz-dhc-dhcpv6-vendor-message
-00.txt
  "DHCPv6 Vendor-specific Message", Bernie Volz, 20-Feb-07,=20
   =20
=20
- Bernie

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



From dhcwg-bounces@ietf.org Wed Feb 21 10:05:26 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJt1T-00066q-Tf; Wed, 21 Feb 2007 10:04:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJt1Q-00066j-OB
	for dhcwg@ietf.org; Wed, 21 Feb 2007 10:04:44 -0500
Received: from blv-smtpout-01.boeing.com ([130.76.32.69]
	helo=blv-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJt1M-0003mm-9q
	for dhcwg@ietf.org; Wed, 21 Feb 2007 10:04:44 -0500
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4])
	by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1LF4aAo020034
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 21 Feb 2007 07:04:37 -0800 (PST)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1LF4adx008340; Wed, 21 Feb 2007 07:04:36 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1LF4Ubx008152; Wed, 21 Feb 2007 07:04:35 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 21 Feb 2007 07:04:30 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] DUID on a Virtual Host
Date: Wed, 21 Feb 2007 07:03:58 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177471D@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <61C42E7D-47A8-4BC8-9A91-BDF474A9C8B0@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] DUID on a Virtual Host
Thread-Index: AcdVYBVb7Wa470NjSAyg/1If2i1TRwAZ6F4g
References: <8E296595B6471A4689555D5D725EBB21035095C8@xmb-rtp-20a.amer.cisco.com>
	<200702201524.l1KFOQO4026527@cichlid.raleigh.ibm.com>
	<39C363776A4E8C4A94691D2BD9D1C9A101774702@XCH-NW-7V2.nw.nos.boeing.com>
	<45DB65B8.7080107@us.ibm.com>
	<39C363776A4E8C4A94691D2BD9D1C9A10177470D@XCH-NW-7V2.nw.nos.boeing.com>
	<61C42E7D-47A8-4BC8-9A91-BDF474A9C8B0@cisco.com>
From: "Templin, Fred L" 
To: "Markus Stenberg" 
X-OriginalArrivalTime: 21 Feb 2007 15:04:30.0493 (UTC)
	FILETIME=[967D4CD0:01C755C9]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: narten@us.ibm.com, dhcwg@ietf.org, Ted.Lemon@nominum.com, volz@cisco.com
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Thanks Markus,

I won't pretend to have a deep knowledge of this space, but I
am also being told that public key is considered as a unique
identifier for the SPKI/SDSI framework:

  http://en.wikipedia.org/wiki/Simple_public_key_infrastructure

Fred
fred.l.templin@boeing.com=20

> -----Original Message-----
> From: Markus Stenberg [mailto:mstenber@cisco.com]=20
> Sent: Tuesday, February 20, 2007 6:29 PM
> To: Templin, Fred L
> Cc: rbrabson@us.ibm.com; narten@us.ibm.com; dhcwg@ietf.org;=20
> volz@cisco.com; Ted.Lemon@nominum.com
> Subject: Re: [dhcwg] DUID on a Virtual Host
>=20
> On 21.2.2007, at 6.23, Templin, Fred L wrote:
> >> But, stepping back for a second, are public keys considered unique,
> >> anyway?  I'm not a security expert, but I  thought public keys were
> >> generated by the end user, and there is nothing that prevents
> >> two users
> >> from generating the same public key.  If so, how  does a a DHCP =20
> >> server
> >> differentiate between two hosts that choose to use the same
> >> public key.
> > Yes, I wondered about that too and that was why I suggested
> > earlier that additional information (e.g., a L2 address, a
> > timestamp, etc.) might also be needed.
>=20
> The answer is, it depends.. If you use a public key as-is,=20
> then, yes, =20
> collisions are possible but not probable  (probability of all say, =20
> 1024 or 2048 bits being the same is roughly nil - think 1 in 2^1024 =20
> and you find that it is very unlikely). Even intentionally creating =20
> same public key is insanely hard, equivalent in terms of effort to =20
> breaking the encryption itself.
>=20
> Of course, lacking/broken sources of randomness (think: boxes with =20
> time that starts at 0, creating their first public keys at=20
> first boot =20
> with clock unset, and so forth) are different beast entirely.  With =20
> that sort of environment timestamp won't save you either.
>=20
> I think the correct approach is just to promote semi-reasonable =20
> sources of randomness, and if that fails, initializing RNG with =20
> hardware parameters and then using the public keys as-is.
>=20
> There is of course the question of what we want to accomplish with =20
> this scheme; raw public keys used like in SSH provide mostly=20
> just way =20
> of making sure that the users cannot easily pretend to be each other =20
> based on sniffed traffic (assuming you add signature option to the =20
> packets sent to the server, or alternatively receive encrypted =20
> subblocks from the server), and provide some protection of the =20
> content; however, are those desirable characteristics for DHCPv6?
>=20
> Cheers,
>=20
> -Markus
>=20
>=20

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



From dhcwg-bounces@ietf.org Wed Feb 21 14:10:45 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HJwqg-0001yV-Dn; Wed, 21 Feb 2007 14:09:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwqe-0001uz-V1
	for dhcwg@ietf.org; Wed, 21 Feb 2007 14:09:52 -0500
Received: from e35.co.us.ibm.com ([32.97.110.153])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwqd-0006se-Ft
	for dhcwg@ietf.org; Wed, 21 Feb 2007 14:09:52 -0500
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com
	[9.17.195.11])
	by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l1LJ9kFA010205
	for ; Wed, 21 Feb 2007 14:09:46 -0500
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168])
	by westrelay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id
	l1LJ9jKE268484 for ; Wed, 21 Feb 2007 12:09:45 -0700
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1])
	by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l1LJ9jSA020614 for ; Wed, 21 Feb 2007 12:09:45 -0700
Received: from cichlid ([9.67.191.202])
	by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l1LJ9irW020536; Wed, 21 Feb 2007 12:09:45 -0700
Received: from cichlid (localhost.localdomain [127.0.0.1])
	by cichlid (8.13.8/8.12.5) with ESMTP id l1LJ9gVi011851;
	Wed, 21 Feb 2007 14:09:42 -0500
Message-Id: <200702211909.l1LJ9gVi011851@cichlid>
To: Roy Brabson 
Subject: Re: [dhcwg] DUID on a Virtual Host 
In-reply-to: <45DB65B8.7080107@us.ibm.com> 
References: <8E296595B6471A4689555D5D725EBB21035095C8@xmb-rtp-20a.amer.cisco.com>
	<200702201524.l1KFOQO4026527@cichlid.raleigh.ibm.com>
	<39C363776A4E8C4A94691D2BD9D1C9A101774702@XCH-NW-7V2.nw.nos.boeing.com>
	<45DB65B8.7080107@us.ibm.com>
Comments: In-reply-to Roy Brabson 
	message dated "Tue, 20 Feb 2007 16:18:48 -0500."
Date: Wed, 21 Feb 2007 14:09:42 -0500
From: Thomas Narten 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed
Cc: dhcwg@ietf.org, "Templin, Fred L" ,
	volz@cisco.com, Ted.Lemon@nominum.com
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

> But, stepping back for a second, are public keys considered unique,
> anyway?

They'd better be, or you have even bigger problems. I.e., if two
public keys are the same, well so are the private keys. Oops!

Thomas

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



From dhcwg-bounces@ietf.org Thu Feb 22 01:29:18 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HK7RV-0005zA-Be; Thu, 22 Feb 2007 01:28:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HK7RU-0005yz-96
	for dhcwg@ietf.org; Thu, 22 Feb 2007 01:28:36 -0500
Received: from shuttle.wide.toshiba.co.jp ([2001:200:1b1::35])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK7RS-0005g8-V4
	for dhcwg@ietf.org; Thu, 22 Feb 2007 01:28:36 -0500
Received: from impact.jinmei.org (unknown
	[IPv6:2001:200:1b1:1010:699f:1c5f:fe5f:64c5])
	by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id BBD377301D;
	Thu, 22 Feb 2007 15:28:23 +0900 (JST)
Date: Thu, 22 Feb 2007 15:28:13 +0900
Message-ID: 
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
	
To: Stig Venaas 
Subject: Re: [dhcwg] dhc wg last call on dhcpv6-reconfigure-rebind
In-Reply-To: <45DB1574.5070501@uninett.no>
References: <45DB1574.5070501@uninett.no>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

>>>>> On Tue, 20 Feb 2007 16:36:20 +0100, 
>>>>> Stig Venaas  said:

> Please respond to this WG last call.  If you support acceptance of the
> document without change, respond with a simple acknowledgment, so that
> support for the document can be assessed.  Lack of discussion does not
> represent positive support.  If there is no expression of support for
> acceptance during the WG last call, the document will not be advanced
> to the IESG.

I see the need for this extension and basically support the idea of
the draft; however, I don't think this particular version is ready to
ship.

I have the following concerns on the current version:

- this version does not specify how the client reacts to a Reconfigure
  message specifying Rebind.  it also does not clarify what the client
  should do if it receives a Reconfigure message specifying Renew but
  the server identifier is different from the one for the 'latest'
  server for the client.  I think we should clarify these points.

- similarly, this version does not specify when a server should
  specify Renew in a Reconfigure message and when it should specify
  Rebind.  I believe we should also clarify this point.

- the use of term "multicast" in this document is confusing or is not
  really correct.  I first thought it means that the message is sent
  to an IPv6 multicast destination address (which should be
  ff02::1:2), but then I found this interpretation does not make sence
  in the context of the text.  Next I thought "multicast" means that 
  the DHCPv6 message is (or can be) sent without a Server Identifier
  option, which makes much more sense to me, but then I think the text
  should not use the confusing term of "multicast".

  Besides, the use of "multicast" is not really correct in either
  interpretation.  If it means ff02::1:2, this is not always true
  because a Renew message can be unicasted based on agreement between
  the client and the server.  If it means the lack of Server
  Identifier option, this is also not really true because the
  specification does not prohibit an Information-request message from
  having a Server Identifier option.

Related to the last point, it was diffucult for me to understand the
following paragraph:

   In a network with multiple DHCPv6 servers, the Reconfigure message
   may not be sent by the same server as the one from which the client
   last obtained configuration and/or addressing information.  If the
   Reconfigure message commands the client to perform a Renew, [2] does
   not specify to which server the client should send the Renew.  This
   difficulty is avoided if the server commands the client to perform an
   Information-Request, since such messages are multicast.  However,
   Information-Request messages do not cause addressing configuration to
   be returned.
(section 1, 2nd para)

Part of the source of the difficulty is the unclear meaning of
"multicast".  Also, it was not really clear for me what "such
messages" exactly specify: does this mean Information-request, or
Information-request and Renew?  It was also unclear to me what "this
difficulty" exactly means.  Finally, I didn't understand what the last
sentence actually tries to convey (I could speculate, but I could not
be sure).  I think this paragraph needs a full revision, clarifying
these points.

					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-bounces@ietf.org Thu Feb 22 10:27:06 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKFpO-00012Y-SU; Thu, 22 Feb 2007 10:25:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKFpN-00012P-I5
	for dhcwg@ietf.org; Thu, 22 Feb 2007 10:25:49 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HKFpM-00013f-61
	for dhcwg@ietf.org; Thu, 22 Feb 2007 10:25:49 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by sj-iport-3.cisco.com with ESMTP; 22 Feb 2007 07:25:48 -0800
X-IronPort-AV: i="4.14,205,1170662400"; 
	d="scan'208"; a="466361039:sNHT44415564"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1MFPlsc023615
	for ; Thu, 22 Feb 2007 10:25:47 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1MFPZOM029167
	for ; Thu, 22 Feb 2007 10:25:47 -0500 (EST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 22 Feb 2007 10:25:38 -0500
Received: from 10.86.240.30 ([10.86.240.30]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Thu, 22 Feb 2007 15:25:38 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Thu, 22 Feb 2007 10:25:41 -0500
From: Ralph Droms 
To: dhcwg 
Message-ID: 
Thread-Topic: dhc WG last call on draft-ietf-dhc-subnet-alloc-04
Thread-Index: AcdWlbYv9IF46MKIEduVeQARJOT6eg==
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 22 Feb 2007 15:25:38.0463 (UTC)
	FILETIME=[B4ABEAF0:01C75695]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1500; t=1172157947;
	x=1173021947; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20dhc=20WG=20last=20call=20on=20draft-ietf-dhc-subnet-alloc-04
	|Sender:=20 |To:=20dhcwg=20;
	bh=mfhNDl2Nj1W316Bk4nRK6zN1rPrcP86tTNfz4oc0lmc=;
	b=h7T1jMtisqSllEDTuakMJFyhIu9o7FlLY1la4F73KW0421V7vYX0nKrgjRrlPFzIvX9hxAl3
	iHRXpapU9I03EkvnqGFgeyQ0TG0ELky0idrzk0buQ0X6yCV+OcAaEChS;
Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

This message announces a WG last call on "Subnet Allocation Option"
.  The last call will conclude at
0900EST on March 12, 2007.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

draft-ietf-dhc-subnet-alloc-04 defines a DHCP option that is passed
between the DHCP Client and the DHCP Server to request dynamic
allocation of a subnet, give specifications of subnet(s) allocated,
and report usage statistics.  This memo documents the current
definition of this option (option code 220) in agreement with
RFC-3942, which declares that any pre-existing usages of option
numbers in the range 128 - 223 should be documented and the working
group will try to officially assign those numbers to those options.

Note that the Internet Draft , "DHCP
Proxy Server Micro-block Allocation Scheme For IP Address Pool
Management," defines an address allocation mechanism that is related
to the subnet allocation mechanism in draft-ietf-dhc-subnet-alloc-04.

This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-04.txt

- Stig Venaas, Ralph Droms
  dhc WG chairs


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



From dhcwg-bounces@ietf.org Fri Feb 23 08:46:35 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKakA-0005XW-VQ; Fri, 23 Feb 2007 08:45:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKakA-0005XQ-CO
	for dhcwg@ietf.org; Fri, 23 Feb 2007 08:45:50 -0500
Received: from e2.ny.us.ibm.com ([32.97.182.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKak8-0000dX-4u
	for dhcwg@ietf.org; Fri, 23 Feb 2007 08:45:50 -0500
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236])
	by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l1NDjkdv003814
	for ; Fri, 23 Feb 2007 08:45:46 -0500
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217])
	by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id
	l1NDjkEF245640 for ; Fri, 23 Feb 2007 08:45:46 -0500
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1])
	by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	l1NDjjCj026473 for ; Fri, 23 Feb 2007 08:45:46 -0500
Received: from cichlid ([9.67.191.217])
	by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	l1NDjj2v026456; Fri, 23 Feb 2007 08:45:45 -0500
Received: from cichlid (localhost.localdomain [127.0.0.1])
	by cichlid (8.13.8/8.12.5) with ESMTP id l1NDjdmQ024934;
	Fri, 23 Feb 2007 08:45:40 -0500
Message-Id: <200702231345.l1NDjdmQ024934@cichlid>
To: Ralph Droms 
Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 
In-reply-to:  
References: 
Comments: In-reply-to Ralph Droms 
	message dated "Thu, 22 Feb 2007 10:25:41 -0500."
Date: Fri, 23 Feb 2007 08:45:39 -0500
From: Thomas Narten 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

How would this document be published? Standards Track? Or
Informational?

FWIW, since this is just documenting a vendor-defined existing
practice, one that the IETF presumably can't modify, I'd assume the
document would be published as an informational one, unless the WG
felt fairly strongly that this document really is the right/best way
to address the problem at hand (i.e., with IETF blessing).

Thomas

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



From dhcwg-bounces@ietf.org Fri Feb 23 12:13:21 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKdwr-0001jD-JO; Fri, 23 Feb 2007 12:11:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKdwq-0001i7-FE
	for dhcwg@ietf.org; Fri, 23 Feb 2007 12:11:08 -0500
Received: from stl-smtpout-01.boeing.com ([130.76.96.56]
	helo=stl-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKdvp-0004we-M0
	for dhcwg@ietf.org; Fri, 23 Feb 2007 12:10:10 -0500
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6])
	by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1NH9wRs019024
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Fri, 23 Feb 2007 11:09:59 -0600 (CST)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1NH9wQ3025309; Fri, 23 Feb 2007 11:09:58 -0600 (CST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1NH9pWw025046; Fri, 23 Feb 2007 11:09:58 -0600 (CST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Feb 2007 09:09:57 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 
Date: Fri, 23 Feb 2007 09:09:57 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177473C@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <200702231345.l1NDjdmQ024934@cichlid>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 
Thread-Index: AcdXUVu5YUI/HQAGRaCz3qFSBM11GQAG32YA
References: 
	<200702231345.l1NDjdmQ024934@cichlid>
From: "Templin, Fred L" 
To: "Thomas Narten" , "Ralph Droms" 
X-OriginalArrivalTime: 23 Feb 2007 17:09:57.0415 (UTC)
	FILETIME=[71B5F370:01C7576D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

I have asked in the past about IPR considerations for this document.
If this is indeed just documenting a vendor's proprietary extension,
what are the IPR consideration for its use in other contexts, i.e.,
how much is it going to cost all the rest of us?

Fred
fred.l.templin@boeing.com=20

> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com]=20
> Sent: Friday, February 23, 2007 5:46 AM
> To: Ralph Droms
> Cc: dhcwg
> Subject: Re: [dhcwg] dhc WG last call on=20
> draft-ietf-dhc-subnet-alloc-04=20
>=20
> How would this document be published? Standards Track? Or
> Informational?
>=20
> FWIW, since this is just documenting a vendor-defined existing
> practice, one that the IETF presumably can't modify, I'd assume the
> document would be published as an informational one, unless the WG
> felt fairly strongly that this document really is the right/best way
> to address the problem at hand (i.e., with IETF blessing).
>=20
> Thomas
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>=20

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



From dhcwg-bounces@ietf.org Fri Feb 23 14:24:03 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKg08-0002hT-TM; Fri, 23 Feb 2007 14:22:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKg07-0002hD-4z
	for dhcwg@ietf.org; Fri, 23 Feb 2007 14:22:39 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKfzv-0007XC-G9
	for dhcwg@ietf.org; Fri, 23 Feb 2007 14:22:39 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2007 14:22:28 -0500
X-IronPort-AV: i="4.14,212,1170651600"; 
	d="scan'208"; a="53536302:sNHT47534816"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1NJMRFf002226; 
	Fri, 23 Feb 2007 14:22:27 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1NJMIVb005894; 
	Fri, 23 Feb 2007 14:22:27 -0500 (EST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 23 Feb 2007 14:22:20 -0500
Received: from 161.44.65.204 ([161.44.65.204]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Fri, 23 Feb 2007 19:22:20 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Fri, 23 Feb 2007 14:22:32 -0500
Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 
From: Ralph Droms 
To: "Templin, Fred L" ,
	Thomas Narten 
Message-ID: 
Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 
Thread-Index: AcdXUVu5YUI/HQAGRaCz3qFSBM11GQAG32YAAATHbC0=
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10177473C@XCH-NW-7V2.nw.nos.boeing.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 23 Feb 2007 19:22:20.0936 (UTC)
	FILETIME=[F06B1080:01C7577F]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1980; t=1172258547;
	x=1173122547; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20Re=3A=20[dhcwg]=20dhc=20WG=20last=20call=20on=20draft-ietf-dh
	c-subnet-alloc-04=20 |Sender:=20
	|To:=20=22Templin, =20Fred=20L=22=20,
	=0A=20=20=
	20=20=20=20=20=20Thomas=20Narten=20;
	bh=slx0SUTkSnOfDcNNTM0gck2Iz8nNggkTC6fGuP92Gtw=;
	b=eIaXZpCwO4VCIXarafZMMOiRWoHcR9ORxSB15pzqCNXQdT7q/U5zEBCRujHxc+h/TCd2PB6K
	/mEs4f6zAfR2GdHZnAgh9eCpkCC+NLEPweAbPoZ7sRwR2C1boyEvnT+o;
Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 1.5 (+)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Fred - the IETF manages an IPR Disclosures page at
https://datatracker.ietf.org/public/ipr_disclosure.cgi.  There, you can find
the specific disclosure(s) that apply to a specific Internet Draft.

In general, these IPR disclosures give contact information and the specific
text for the disclosure.  In the case of draft-ietf-dhc-subnet-alloc-04 ,
the disclosure text is at
http://www.ietf.org/ietf/IPR/CISCO-raj-dhc-subnet-alloc.txt

For more information about how this particular disclosure relates to IETF
policies, look at RFC 3979.

I don't mean to dodge the meat of your question: "how much is it going to
cost all the rest of us?"  I don't have responsibility for Cisco's IPR, so I
can't answer that question.

-Ralph


On 2/23/07 12:09 PM, "Templin, Fred L"  wrote:

> I have asked in the past about IPR considerations for this document.
> If this is indeed just documenting a vendor's proprietary extension,
> what are the IPR consideration for its use in other contexts, i.e.,
> how much is it going to cost all the rest of us?
> 
> Fred
> fred.l.templin@boeing.com
> 
>> -----Original Message-----
>> From: Thomas Narten [mailto:narten@us.ibm.com]
>> Sent: Friday, February 23, 2007 5:46 AM
>> To: Ralph Droms
>> Cc: dhcwg
>> Subject: Re: [dhcwg] dhc WG last call on
>> draft-ietf-dhc-subnet-alloc-04
>> 
>> How would this document be published? Standards Track? Or
>> Informational?
>> 
>> FWIW, since this is just documenting a vendor-defined existing
>> practice, one that the IETF presumably can't modify, I'd assume the
>> document would be published as an informational one, unless the WG
>> felt fairly strongly that this document really is the right/best way
>> to address the problem at hand (i.e., with IETF blessing).
>> 
>> 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-bounces@ietf.org Fri Feb 23 19:54:56 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HKlAc-0002Zu-HC; Fri, 23 Feb 2007 19:53:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HKlAb-0002Zo-D5
	for dhcwg@ietf.org; Fri, 23 Feb 2007 19:53:49 -0500
Received: from goliath.isc.org ([2001:4f8:3:bb::72])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKlAY-00013N-14
	for dhcwg@ietf.org; Fri, 23 Feb 2007 19:53:49 -0500
Received: by goliath.isc.org (Postfix, from userid 10200)
	id F03E97D2D; Fri, 23 Feb 2007 16:53:20 -0800 (PST)
Date: Fri, 23 Feb 2007 16:53:20 -0800
From: "David W. Hankins" 
To: CTO WEN Haibo 
Subject: Re: [dhcwg] a question for rfc3993
Message-ID: <20070224005320.GA2533@isc.org>
References: <9570C1261494D54D9D3115BC2C83429A02277D74@asbmail2.sbell.com.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9570C1261494D54D9D3115BC2C83429A02277D74@asbmail2.sbell.com.cn>
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Wed, Feb 21, 2007 at 09:33:13AM +0800, CTO WEN Haibo wrote:
> I want to know who is responsible to insert this sub-option?

As the sub-option is part of the Relay Agent Information Option,
only the relay may apply it to a packet which it is forwarding
to a DHCP server.

DHCP servers place the relay agent option into any replies they
send to the relay (not directly to the client), which is required
to be a copy of what the relay supplied, but it would be more
accurate to say that the relay supplied the contents of this
option in either case.

> If it is the relay agent, what policy or mapping are used for inserting this suboption into the DHCP message from the some DHCP client?

This is left entirely to a combination of the relay software
implementor and the system's administration.

The subscriber-id is intended to be the identity used internally
by a company to describe a relationship to a customer, or a
customer's product.

-- 
ISC Training!  http://www.isc.org/training/  training@isc.org
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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



From dhcwg-bounces@ietf.org Mon Feb 26 07:46:43 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HLfEE-0008G8-RE; Mon, 26 Feb 2007 07:45:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HLfED-00089D-91
	for dhcwg@ietf.org; Mon, 26 Feb 2007 07:45:17 -0500
Received: from paoakoavas10.cable.comcast.com ([208.17.35.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLfEC-0003ss-2v
	for dhcwg@ietf.org; Mon, 26 Feb 2007 07:45:17 -0500
Received: from ([10.195.246.152])
	by paoakoavas10.cable.comcast.com with ESMTP  id KP-TDCH3.30530629;
	Mon, 26 Feb 2007 07:44:51 -0500
Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by
	NJMDCEXCRLY01.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 07:44:51 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Feb 2007 07:44:44 -0500
Message-ID: <2271C950731A734680BA3E2978816F1806DAD7BE@NJCHLEXCMB01.cable.comcast.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: High Availability DHCPv6
thread-index: AcdZo+PXu2nnUxQVSg6bteRjVarm+g==
From: "Brzozowski, John" 
To: "dhcwg" 
X-OriginalArrivalTime: 26 Feb 2007 12:44:51.0153 (UTC)
	FILETIME=[E8143C10:01C759A3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Subject: [dhcwg] High Availability DHCPv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Folks,

I have been doing some research and investigation on HA solutions for
DHCPv6, it seems that this is a topic that we will need to address as
adoption and use of DHCPv6 increases.  I assume that others in the WG
have too given this some thought.  I was hoping that perhaps we could
exchange some email on the dhcwg list to determine where we stand as a
group on this topic.

At this point I have been considering putting together an I-D (probably
informational) to outline what I have done thus far.  In advance of
doing this I wanted to reach out to you all.  Also, if there is
sufficient interest is this topic on the list I was thinking about
requesting a slot at the IETF68 dhcwg meeting so we can discuss in
person.

Comments, questions, and suggestions are most welcome.

Thanks,

John
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:john_brzozowski@cable.comcast.com
m) 609-377-6594
p) 856-324-2671
dc) 168*45683*22
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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



From dhcwg-bounces@ietf.org Mon Feb 26 15:49:01 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HLmlj-0005O7-FG; Mon, 26 Feb 2007 15:48:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmli-0005Ns-Hp
	for dhcwg@ietf.org; Mon, 26 Feb 2007 15:48:22 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HLmlh-0005Tt-5U
	for dhcwg@ietf.org; Mon, 26 Feb 2007 15:48:22 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by sj-iport-2.cisco.com with ESMTP; 26 Feb 2007 12:48:20 -0800
X-IronPort-AV: i="4.14,221,1170662400"; 
	d="scan'208"; a="363000673:sNHT45536416"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QKmKCK009162
	for ; Mon, 26 Feb 2007 15:48:20 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1QKmKVT001004
	for ; Mon, 26 Feb 2007 15:48:20 -0500 (EST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 26 Feb 2007 15:48:19 -0500
Received: from 161.44.65.204 ([161.44.65.204]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Mon, 26 Feb 2007 20:48:19 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Mon, 26 Feb 2007 15:48:38 -0500
From: Ralph Droms 
To: dhcwg 
Message-ID: 
Thread-Topic: dhc WG last call on draft-ietf-dhc-subnet-alloc-04 (resend
	to identify intended publication status)
Thread-Index: AcdZ531tvAKxoMXaEduVeQARJOT6eg==
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 26 Feb 2007 20:48:19.0850 (UTC)
	FILETIME=[729C1EA0:01C759E7]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1557; t=1172522900;
	x=1173386900; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20dhc=20WG=20last=20call=20on=20draft-ietf-dhc-subnet-alloc-04=
	20(resend=20to=0A=20identify=20intended=20publication=20status)
	|Sender:=20 |To:=20dhcwg=20;
	bh=0EJP1BfUN5flklp189tjjXqhm+NH+Re3kD2hb+nl51Y=;
	b=H/K56K/+ZBD3nU819co5OBbxlW2Ab2zgeyytUbwyLJBL0YaJoQ8TU/YwSMc4QqJAvz/97v8W
	I5HFjG18ewH/MtzfCv35tjJPKW1fWPxG7y7Eyo3phKaQfBxIPwe8Pwu3;
Authentication-Results: rtp-dkim-1; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 1.5 (+)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 (resend
 to identify intended publication status)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

This message announces a WG last call for comments on the publication of
"Subnet Allocation Option"  as an
Informational RFC.  The last call will conclude at 0900EST on March 12,
2007.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

draft-ietf-dhc-subnet-alloc-04 defines a DHCP option that is passed
between the DHCP Client and the DHCP Server to request dynamic
allocation of a subnet, give specifications of subnet(s) allocated,
and report usage statistics.  This memo documents the current
definition of this option (option code 220) in agreement with
RFC-3942, which declares that any pre-existing usages of option
numbers in the range 128 - 223 should be documented and the working
group will try to officially assign those numbers to those options.

Note that the Internet Draft , "DHCP
Proxy Server Micro-block Allocation Scheme For IP Address Pool
Management," defines an address allocation mechanism that is related
to the subnet allocation mechanism in draft-ietf-dhc-subnet-alloc-04.

This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-04.txt

- Stig Venaas, Ralph Droms
  dhc WG chairs


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



From dhcwg-bounces@ietf.org Tue Feb 27 08:56:09 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HM2nb-0006cw-GZ; Tue, 27 Feb 2007 08:55:23 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HM2na-0006cr-Ro
	for dhcwg@ietf.org; Tue, 27 Feb 2007 08:55:22 -0500
Received: from tyholt.uninett.no ([2001:700:1::eecb])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM2nY-0001ZO-R2
	for dhcwg@ietf.org; Tue, 27 Feb 2007 08:55:22 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by tyholt.uninett.no (Postfix) with ESMTP id 6B071B5C72;
	Tue, 27 Feb 2007 14:55:07 +0100 (CET)
Received: from tyholt.uninett.no ([127.0.0.1])
	by localhost (tyholt.uninett.no [127.0.0.1]) (amavisd-new, port 10024)
	with LMTP id 03729-01-3; Tue, 27 Feb 2007 14:55:07 +0100 (CET)
Received: from [IPv6?2001?700?1?7?215?f2ff?fe35?307d] (sverresborg.uninett.no
	[IPv6:2001:700:1:7:215:f2ff:fe35:307d])
	by tyholt.uninett.no (Postfix) with ESMTP id 1BE9CB5C4A;
	Tue, 27 Feb 2007 14:55:07 +0100 (CET)
Message-ID: <45E4383A.6080406@uninett.no>
Date: Tue, 27 Feb 2007 14:55:06 +0100
From: Stig Venaas 
User-Agent: Thunderbird 1.5.0.9 (X11/20070129)
MIME-Version: 1.0
To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?=
	
Subject: Re: [dhcwg] dhc wg last call on dhcpv6-reconfigure-rebind
References: <45DB1574.5070501@uninett.no>
	
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at uninett.no
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote:
>>>>>> On Tue, 20 Feb 2007 16:36:20 +0100,=20
>>>>>> Stig Venaas  said:
>=20
>> Please respond to this WG last call.  If you support acceptance of the=

>> document without change, respond with a simple acknowledgment, so that=

>> support for the document can be assessed.  Lack of discussion does not=

>> represent positive support.  If there is no expression of support for
>> acceptance during the WG last call, the document will not be advanced
>> to the IESG.
>=20
> I see the need for this extension and basically support the idea of
> the draft; however, I don't think this particular version is ready to
> ship.
>=20
> I have the following concerns on the current version:
>

I agree, I also believe that some of the text is too vague. It is a
bit underspecified. It could also be explained better under what
circumstances this is needed and how it would be used.

Stig

> - this version does not specify how the client reacts to a Reconfigure
>   message specifying Rebind.  it also does not clarify what the client
>   should do if it receives a Reconfigure message specifying Renew but
>   the server identifier is different from the one for the 'latest'
>   server for the client.  I think we should clarify these points.
>=20
> - similarly, this version does not specify when a server should
>   specify Renew in a Reconfigure message and when it should specify
>   Rebind.  I believe we should also clarify this point.
>=20
> - the use of term "multicast" in this document is confusing or is not
>   really correct.  I first thought it means that the message is sent
>   to an IPv6 multicast destination address (which should be
>   ff02::1:2), but then I found this interpretation does not make sence
>   in the context of the text.  Next I thought "multicast" means that=20
>   the DHCPv6 message is (or can be) sent without a Server Identifier
>   option, which makes much more sense to me, but then I think the text
>   should not use the confusing term of "multicast".
>=20
>   Besides, the use of "multicast" is not really correct in either
>   interpretation.  If it means ff02::1:2, this is not always true
>   because a Renew message can be unicasted based on agreement between
>   the client and the server.  If it means the lack of Server
>   Identifier option, this is also not really true because the
>   specification does not prohibit an Information-request message from
>   having a Server Identifier option.
>=20
> Related to the last point, it was diffucult for me to understand the
> following paragraph:
>=20
>    In a network with multiple DHCPv6 servers, the Reconfigure message
>    may not be sent by the same server as the one from which the client
>    last obtained configuration and/or addressing information.  If the
>    Reconfigure message commands the client to perform a Renew, [2] does=

>    not specify to which server the client should send the Renew.  This
>    difficulty is avoided if the server commands the client to perform a=
n
>    Information-Request, since such messages are multicast.  However,
>    Information-Request messages do not cause addressing configuration t=
o
>    be returned.
> (section 1, 2nd para)
>=20
> Part of the source of the difficulty is the unclear meaning of
> "multicast".  Also, it was not really clear for me what "such
> messages" exactly specify: does this mean Information-request, or
> Information-request and Renew?  It was also unclear to me what "this
> difficulty" exactly means.  Finally, I didn't understand what the last
> sentence actually tries to convey (I could speculate, but I could not
> be sure).  I think this paragraph needs a full revision, clarifying
> these points.
>=20
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, Toshiba Corp.
> 					jinmei@isl.rdc.toshiba.co.jp
>=20
> _______________________________________________
> 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-bounces@ietf.org Tue Feb 27 14:24:24 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HM7vG-0006kf-5T; Tue, 27 Feb 2007 14:23:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HM7vF-0006kW-9j
	for dhcwg@ietf.org; Tue, 27 Feb 2007 14:23:37 -0500
Received: from goliath.isc.org ([2001:4f8:3:bb::72])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM7v2-00034F-Hg
	for dhcwg@ietf.org; Tue, 27 Feb 2007 14:23:37 -0500
Received: by goliath.isc.org (Postfix, from userid 10200)
	id 386C87D2D; Tue, 27 Feb 2007 11:23:03 -0800 (PST)
Date: Tue, 27 Feb 2007 11:23:03 -0800
From: "David W. Hankins" 
To: dhcwg@ietf.org
Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04
	(resend to identify intended publication status)
Message-ID: <20070227192303.GD20765@isc.org>
References: 
Mime-Version: 1.0
In-Reply-To: 
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0367195551=="
Errors-To: dhcwg-bounces@ietf.org


--===============0367195551==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0"
Content-Disposition: inline


--LyciRD1jyfeSSjG0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Feb 26, 2007 at 03:48:38PM -0500, Ralph Droms wrote:
> Please respond to this WG last call.  If you support acceptance of the
> document without change, respond with a simple acknowledgment, so that
> support for the document can be assessed.  Lack of discussion does not

I support acceptance without change.  I am not intimately familiar
with this use of this option so I can't speak to the accuracy of the
document, but I find the definitions contained within this draft
to be more than adequate information.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

--LyciRD1jyfeSSjG0
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFF5IUXcXeLeWu2vmoRAs3NAJ0ZOeabobw64dHnn3jE7PXGzQbgRwCgq+DX
V3QXKpro0jWHsnokt1PrVp4=
=xC2y
-----END PGP SIGNATURE-----

--LyciRD1jyfeSSjG0--


--===============0367195551==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0367195551==--




From dhcwg-bounces@ietf.org Tue Feb 27 15:44:41 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HM9Az-0005hw-CP; Tue, 27 Feb 2007 15:43:57 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HM9Ay-0005hq-Kv
	for dhcwg@ietf.org; Tue, 27 Feb 2007 15:43:56 -0500
Received: from pacdcimo01.cable.comcast.com ([24.40.8.145])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM9Au-0006pU-W6
	for dhcwg@ietf.org; Tue, 27 Feb 2007 15:43:56 -0500
Received: from ([24.40.15.92])
	by pacdcimo01.cable.comcast.com with ESMTP  id KP-BXT38.1203022;
	Tue, 27 Feb 2007 15:43:29 -0500
Received: from PACDCEXCMB05.cable.comcast.com ([24.40.15.116]) by
	PACDCEXCSMTP03.cable.comcast.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 15:43:29 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 27 Feb 2007 15:43:28 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Invitation to a pre-IETF DHCPv6 bake-off
Thread-Index: Acdar+8qPMkAFtuWT6u+tb31mXOXAw==
From: "Durand, Alain" 
To: 
X-OriginalArrivalTime: 27 Feb 2007 20:43:29.0414 (UTC)
	FILETIME=[EFE8DA60:01C75AAF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32604d42645517c44d778f1d111b40a6
Subject: [dhcwg] Invitation to a pre-IETF DHCPv6 bake-off
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0513065274=="
Errors-To: dhcwg-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0513065274==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C75AAF.EF8FE373"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C75AAF.EF8FE373
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear wg members,

I'm posting this message with authorization from the wg chairs.

I'm organizing a DHCPv6 bake-off in Amsterdam on 3/15 and 3/16 in the
RIPE-NCC facilities.
The focus of the bake-off is interoperability, operation impact and
usability.
In that sense, it is different and complementary to the TAHI tests.

This event will be organized by Comcast with the help of ISC and will
operate
under standard connectathon-like rules (ie NDA & no detail published
results).

I have already confirmed participation of 5 majors implementations
of DHCPv6 clients, servers and relay agents and I'd like to extend
the invitation to other participants. Please contact me directly if you
are interested or have any questions.

Regards,

    - Alain.

FAQ about the bake-off:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

* When and where will the bake-off take place?

=3D=3D> March 15th-16th in Amsterdam at the RIPE-NCC facilities

=20

*  What is the goal of the event?

=3D=3D> The goal of the event is to ensure basic inter-operability of =
DHCPv6
       solution in a traditional enterprise type space by focusing on
the
       operational issues of running an heterogeneous network.

       We will focus on making sure that client X work vs server Y as
expected,
       then we will move on to different networking scenario through the
prism
       of operation in a real network rather than pure conformance to
the spec.

=20


*  What problems has Comcast already identified  with the
implementations?

=3D=3D> We ran into problems so far with very first basic tests,
       so we thought that there will be tremendous value to replicate
       those tests in a larger set-up.

       For example, we realized that client implementation all made
different choices with DUID types,
       and the type 1 (MAC+time) was confusing about when exactly to
change the time stamp, and
       it was not clear what the desired behavior of a server should be
(regardless of what the spec says or not).
       We have also seen some different interpretations of what messages
were required or not
       and we have also seen various behavior depending on the mix of
stateless vs statefullautoconf.

       I fully expect to see more of those operation problems showing up
during the bake-off


=20

*  What is the test plan  that will be run? =20

=3D=3D> ISC is currently developing the actual test plan with us, we are
planning to release
       it to the participants before the event.

       As I see it today, it will be articulated on 3 axes:

        a) basic X vs Y, with lease renew etc...
           FQDN option, DDNS update,...
           ops question: how to reconcile on the DHCPv6 server clients
using different DUID types,
        b) same but this time focusing on relay agents, with one or two
level of relaying
        c) same but with different mix of stateless and stateful
autoconfiguration
          - DHCPv6 only, RA with empty prefix list
          - DHCPv6 only, RA with prefix list
          - Mix of stateless autoconf and DHCPv6 address assignment
          - Mix of stateless autoconf and DHCPv6 for other parameters

=20

*  Will the testing include relay agents? =20

=3D=3D> Yes, see above=20

=20

*  Apparently there will be an NDA required for the event, engineers are
often not authorized to sign NDAs.

=3D=3D> Contact me directly ASAP if you plan to participate and do not
already=20
       have an NDA in place with Comcast..=20

=20

*  How will Comcast use the results?=20

=3D=3D> We will not publish any detail results, and certainly not =
anything
including the name of the implementations,
       respective results will be available to the respective
participants.
       We will create a brief executive level summary for the IETF
meeting along the lines of:
       "We had a bake-off with xxx number of client, yyy number of
servers, zzz number of relays,
        we found that kkk of them had an issue on that particular topic,
that the spec covering it might have
        a technical problem or simply be not clear enough..."=20

=20

*  Will the attendees get a copy of the results?=20

=3D=3D> Yes, see above, a copy of their respective results.=20


------_=_NextPart_001_01C75AAF.EF8FE373
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear wg=20
members,


I'm posting=20
this message with authorization from the wg chairs.


I'm organizing=20
a DHCPv6 bake-off in Amsterdam on 3/15 and 3/16 in the RIPE-NCC=20
facilities.
The focus of the bake-off is interoperability, operation=20
impact and usability.
In that sense, it is different and=20
complementary to the TAHI tests.


This event will=20
be organized by Comcast with the help of ISC and will =
operate
under=20
standard connectathon-like rules (ie NDA & no detail published=20
results).


I have already confirmed participation of 5 =
majors=20
implementations
of DHCPv6 clients, servers and relay agents =
and I'd like=20
to extend
the invitation to other =
participants. Please contact me =
directly if=20
you
are interested or have any questions.


Regards,


    - Alain.


FAQ about the=20
bake-off:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


* =
When and=20
where will the bake-off take place?


=3D=3D> March=20
15th-16th in Amsterdam at the RIPE-NCC facilities


 


*  What is the =
goal of =
the=20
event?


=3D=3D> The goal of the event is to ensure =
basic=20
inter-operability of DHCPv6
       =
solution in=20
a traditional enterprise type space by focusing on=20
the
       operational issues of =
running an=20
heterogeneous network.


       We will =
focus on=20
making sure that client X work vs server Y as=20
expected,
       then we will move on =
to=20
different networking scenario through the=20
prism
       of operation in a real =
network=20
rather than pure conformance to the spec.


 




*  What=20
problems has Comcast already identified  with the implementations?


=3D=3D> We =
ran into=20
problems so far with very first basic =
tests,
       =
so we=20
thought that there will be tremendous=20
value to replicate
       those tests in a larger=20
set-up.

       For example, we realized that client=20
implementation all made different choices with DUID=20
types,
      =20
and the type 1 (MAC+time) was confusing about when exactly to =
change the=20
time stamp, and
       it was not clear what the =
desired behavior=20
of a server should be (regardless of what the spec says or=20
not).
      =

 We have also seen some different interpretations of what =
messages=20
were required or not
       and we have also=20
seen various behavior depending on the mix of stateless vs=20
statefullautoconf.


       I fully expect to see more of those =
operation=20
problems showing up during the bake-off



 


*  What is the test plan  that will be run?  


=3D=3D> ISC is =
currently developing=20
the actual test plan with us, we are planning to=20
release
       it to the participants before the =

event.


       As I see =
it today,=20
it will be articulated on 3 axes:


        a) =
basic X=20
vs Y, with lease renew=20
etc...
           =
FQDN=20
option, DDNS update,...
         &nb=
sp; ops=20
question: how to reconcile on the DHCPv6 server clients using different =
DUID=20
types,
        b) =
same but=20
this time focusing on relay agents, with one or two level of=20
relaying
        c) same but with=20
different mix of stateless and stateful=20
autoconfiguration
        &nbs=
p;=20
- DHCPv6 only, RA with empty prefix=20
list
          - DHCPv6 =
only, RA=20
with prefix =
list
          - Mix=20
of stateless autoconf and DHCPv6 address=20
assignment
          - =
Mix of=20
stateless autoconf and DHCPv6 for other =
parameters


 


*  Will the testing include relay =
agents?  


=3D=3D> Yes, see=20
above 


 


*  Apparently there=20
will be an NDA required for the event, engineers are often not authorized to sign=20
NDAs.

=3D=3D> Contact =
me directly=20
ASAP if you plan to participate and do not already=20

       =
have an NDA in place =
with=20
Comcast.. 


 


*  How will Comcast use the=20
results? 

=3D=3D> We will not publish any detail =
results, and certainly=20
not anything including the name of the=20
implementations,
       respective=20
results will be available to the respective=20
participants.
       We will create a =
brief=20
executive level summary for the IETF meeting along the lines=20
of:
       "We had a bake-off with xxx =
number=20
of client, yyy number of servers, zzz number of=20
relays,
        we found that kkk =
of them=20
had an issue on that particular topic, that the spec covering it might=20
have
        a technical =
problem or=20
simply be not clear enough..." 


 


*  Will the attendees get a copy of =
the=20
results? 


=3D=3D> Yes, see =
above, a=20
copy of their respective=20
results. 


------_=_NextPart_001_01C75AAF.EF8FE373--


--===============0513065274==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0513065274==--




From dhcwg-bounces@ietf.org Tue Feb 27 17:10:29 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMAW5-0000dt-0I; Tue, 27 Feb 2007 17:09:49 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMAW1-0000Zb-TF
	for dhcwg@ietf.org; Tue, 27 Feb 2007 17:09:46 -0500
Received: from goliath.isc.org ([2001:4f8:3:bb::72])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMAVy-0008Qr-DN
	for dhcwg@ietf.org; Tue, 27 Feb 2007 17:09:45 -0500
Received: by goliath.isc.org (Postfix, from userid 10200)
	id 179997D2D; Tue, 27 Feb 2007 14:09:19 -0800 (PST)
Date: Tue, 27 Feb 2007 14:09:19 -0800
From: "David W. Hankins" 
To: dhcwg@ietf.org
Subject: Re: [dhcwg] High Availability DHCPv6
Message-ID: <20070227220918.GE20765@isc.org>
References: <2271C950731A734680BA3E2978816F1806DAD7BE@NJCHLEXCMB01.cable.comcast.com>
Mime-Version: 1.0
In-Reply-To: <2271C950731A734680BA3E2978816F1806DAD7BE@NJCHLEXCMB01.cable.comcast.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1016311101=="
Errors-To: dhcwg-bounces@ietf.org


--===============1016311101==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw"
Content-Disposition: inline


--jy6Sn24JjFx/iggw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Feb 26, 2007 at 07:44:44AM -0500, Brzozowski, John wrote:
> At this point I have been considering putting together an I-D (probably
> informational) to outline what I have done thus far.  In advance of
> doing this I wanted to reach out to you all.  Also, if there is
> sufficient interest is this topic on the list I was thinking about
> requesting a slot at the IETF68 dhcwg meeting so we can discuss in
> person.

You could say the problem DHCPv4 solves is resource starvation.
A server presides over a limited resource, of which 80-90% is
consumed...so if you lost 50% of that resource, you're doomed.

Hence, the failover draft.

In IPv6 we've tipped that scale pretty far off into the ludicrous
range in the opposite direction (you could imagine dividing a /64
into 281 trillion server buckets to serve 256 clients!).

So the old model of having N DHCP servers, each presiding
over 1/Nth of the available resource, is realistically possible
in DHCPv6.

So there's already at least one mechanism that fits neatly
inside existing protocol work.

There is potential for other mechanisms, but is there a good
reason for one?  Is limiting address hopping part of the
requirements, if so why?


I think there is at least a good reason for defining a means
where a group of servers can determine one server out of a group
to respond (imagine if all 281 trillion answered in the ludicrous
example...the point at which additional replies become waste is
probably much smaller).

-- 
ISC Training!  http://www.isc.org/training/  training@isc.org
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

--jy6Sn24JjFx/iggw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFF5KwOcXeLeWu2vmoRAksSAJ0QEBtf8SGLuGTm9EgqopnaBHOxCgCgkb52
hm3Smyjr7DiM6tQptrS7GfY=
=vwD6
-----END PGP SIGNATURE-----

--jy6Sn24JjFx/iggw--


--===============1016311101==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1016311101==--




From dhcwg-bounces@ietf.org Tue Feb 27 21:27:24 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMEVG-0001y8-CK; Tue, 27 Feb 2007 21:25:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMEVE-0001xJ-W9
	for dhcwg@ietf.org; Tue, 27 Feb 2007 21:25:12 -0500
Received: from shell-ng.nominum.com ([81.200.64.181])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMEVC-0001EC-Je
	for dhcwg@ietf.org; Tue, 27 Feb 2007 21:25:12 -0500
Received: from mail.nominum.com (mail.nominum.com [81.200.64.186])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by shell-ng.nominum.com (Postfix) with ESMTP id E714F56935;
	Tue, 27 Feb 2007 18:24:55 -0800 (PST)
	(envelope-from Ted.Lemon@nominum.com)
X-Spam-Status: No, hits=0.0 required=8.4
	tests=AWL: -0.701,BAYES_99: 4.07,CUSTOM_RULE_FROM: ALLOW,
	TOTAL_SCORE: 3.369
X-Spam-Level: 
Received: from [10.0.0.190] ([66.93.162.128])
	(authenticated user mellon@nominum.com) by mail.nominum.com
	(using TLSv1/SSLv3 with cipher AES128-SHA (128 bits));
	Tue, 27 Feb 2007 18:24:52 -0800
In-Reply-To: 
References: 
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <8EEE31D7-4F2B-47D6-88B5-CD2B37546483@nominum.com>
Content-Transfer-Encoding: 7bit
From: Ted Lemon 
Subject: Re: [dhcwg] Invitation to a pre-IETF DHCPv6 bake-off
Date: Tue, 27 Feb 2007 19:24:46 -0700
To: "Durand, Alain" 
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

On Feb 27, 2007, at 1:43 PM, Durand, Alain wrote:
>        For example, we realized that client implementation all made  
> different choices with DUID types,
>        and the type 1 (MAC+time) was confusing about when exactly  
> to change the time stamp, and
>        it was not clear what the desired behavior of a server  
> should be (regardless of what the spec says or not).
>        We have also seen some different interpretations of what  
> messages were required or not
>        and we have also seen various behavior depending on the mix  
> of stateless vs statefullautoconf.

I find this statement very disturbing.   The DUID generation process  
happens once, and it never changes after that.   Otherwise you have  
no way to know that it's the same client.   If people are  
interpreting the spec to say that they should regenerate the DUID  
every time (for any value of "every time"), we need to figure out why  
and clarify it.

I'm not sure yet whether I can come - if I do, I'll be bringing  
Nominum's sample client.

Thanks!



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



From dhcwg-bounces@ietf.org Wed Feb 28 08:08:35 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMOWU-0007PH-Oh; Wed, 28 Feb 2007 08:07:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMOWS-0007HC-I1
	for dhcwg@ietf.org; Wed, 28 Feb 2007 08:07:08 -0500
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMOWR-00009j-6P
	for dhcwg@ietf.org; Wed, 28 Feb 2007 08:07:08 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 28 Feb 2007 08:07:08 -0500
X-IronPort-AV: i="4.14,230,1170651600"; 
	d="scan'208"; a="53775849:sNHT49719312"
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1SD77JV010038; 
	Wed, 28 Feb 2007 08:07:07 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1SD76OA008045; 
	Wed, 28 Feb 2007 08:07:06 -0500 (EST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Feb 2007 08:07:06 -0500
Received: from 10.86.241.115 ([10.86.241.115]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Wed, 28 Feb 2007 13:07:06 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Wed, 28 Feb 2007 08:07:22 -0500
Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 
From: Ralph Droms 
To: "Templin, Fred L" 
Message-ID: 
Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 
Thread-Index: AcdXUVu5YUI/HQAGRaCz3qFSBM11GQAG32YAAPMiMEo=
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10177473C@XCH-NW-7V2.nw.nos.boeing.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 28 Feb 2007 13:07:06.0455 (UTC)
	FILETIME=[58CEA670:01C75B39]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3309; t=1172668027;
	x=1173532027; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20Re=3A=20[dhcwg]=20dhc=20WG=20last=20call=20on=20draft-ietf-dh
	c-subnet-alloc-04=20 |Sender:=20
	|To:=20=22Templin,=20Fred=20L=22=20;
	bh=eqaczyITj8u0eB84q4Ay4ovJKm5TqkesXH6ebL9yXHs=;
	b=H8iroxswgCBXzpgH+n3RlGOq6N2Gy53jp83vdz3rWTZTy8qPFfcNzd1WL/mQqF3cLb0bbvK/
	1ZaURJ6ec/YFLgW8Phg4jeqpYRU3CO1bm764huWdg1FtD+A1Qc2jez2w;
Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: Thomas Narten , dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Fred - the IPR disclosure for draft-ietf-dhc-subnet-alloc-04 is very old (it
actually references draft-johnson-dhc-subnet-alloc-00).  A new IPR
disclosure has been submitted to the IETF for "Subnet Allocation Option"
.  This new IPR disclosure, which has
been Cisco's standard IPR disclosure for at least a year and which I've
included below, explicitly describes for draft-ietf-dhc-subnet-alloc-04 what
has been Cisco's unstated policy regarding licensing terms.

- Ralph

  Cisco is the owner of US Patent No. 7,051,089 relating to the
  subject matter of "Subnet Allocation Option"
  .

  If technology in this document is included in a standard adopted by
  IETF and any claims of any Cisco patents are necessary for
  practicing the standard, any party will have the right to use any
  such patent claims under reasonable, non-discriminatory terms, with
  reciprocity, to implement and fully comply with the standard.

  The reasonable non-discriminatory terms are:

  If this standard is adopted, Cisco will not assert any patents owned
  or controlled by Cisco against any party for making, using, selling,
  importing or offering for sale a product that implements the
  standard, provided, however that Cisco retains the right to assert
  its patents (including the right to claim past royalties) against
  any party that asserts a patent it owns or controls (either directly
  or indirectly) against Cisco or any of Cisco's affiliates or
  successors in title or against any products of Cisco or any products
  of any of Cisco's affiliates either alone or in combination with
  other products; and Cisco retains the right to assert its patents
  against any product or portion thereof that is not necessary for
  compliance with the standard.

  Royalty-bearing licenses will be available to anyone who prefers
  that option.

  For information contact:

  Dan Lang
  Senior IP Counsel
  Cisco Systems
  408-526-6672
  standards-ipr@cisco.com


On 2/23/07 12:09 PM, "Templin, Fred L"  wrote:

> I have asked in the past about IPR considerations for this document.
> If this is indeed just documenting a vendor's proprietary extension,
> what are the IPR consideration for its use in other contexts, i.e.,
> how much is it going to cost all the rest of us?
> 
> Fred
> fred.l.templin@boeing.com
> 
>> -----Original Message-----
>> From: Thomas Narten [mailto:narten@us.ibm.com]
>> Sent: Friday, February 23, 2007 5:46 AM
>> To: Ralph Droms
>> Cc: dhcwg
>> Subject: Re: [dhcwg] dhc WG last call on
>> draft-ietf-dhc-subnet-alloc-04
>> 
>> How would this document be published? Standards Track? Or
>> Informational?
>> 
>> FWIW, since this is just documenting a vendor-defined existing
>> practice, one that the IETF presumably can't modify, I'd assume the
>> document would be published as an informational one, unless the WG
>> felt fairly strongly that this document really is the right/best way
>> to address the problem at hand (i.e., with IETF blessing).
>> 
>> 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-bounces@ietf.org Wed Feb 28 09:26:34 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMPkt-00019k-VL; Wed, 28 Feb 2007 09:26:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMPkt-000179-6a
	for dhcwg@ietf.org; Wed, 28 Feb 2007 09:26:07 -0500
Received: from slb-smtpout-01.boeing.com ([130.76.64.48]
	helo=slb-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMPkr-0003O1-L2
	for dhcwg@ietf.org; Wed, 28 Feb 2007 09:26:07 -0500
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4])
	by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1SEQ2iA018644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 28 Feb 2007 06:26:02 -0800 (PST)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1SEQ21x014294; Wed, 28 Feb 2007 06:26:02 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1SEQ04l014220; Wed, 28 Feb 2007 06:26:01 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Feb 2007 06:26:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 
Date: Wed, 28 Feb 2007 06:26:00 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774761@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 
Thread-Index: AcdXUVu5YUI/HQAGRaCz3qFSBM11GQAG32YAAPMiMEoAAnixMA==
References: <39C363776A4E8C4A94691D2BD9D1C9A10177473C@XCH-NW-7V2.nw.nos.boeing.com>
	
From: "Templin, Fred L" 
To: "Ralph Droms" 
X-OriginalArrivalTime: 28 Feb 2007 14:26:01.0343 (UTC)
	FILETIME=[5F0538F0:01C75B44]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: Thomas Narten , dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Ralph,

I'll have to get out my microscope and study the new statement
more carefully, but I have to go back to something Thomas asked
earlier; when cisco says: "in a *standard* adopted by the IETF"
are they meaning to include Informational-track documents, or
only Standards-track? And, if it is the latter, aren't we all in
a "darned-if-you-do and darned-if-you-don't" situation in terms
of voting for this thing as an informational-track document?

I'm already operating well outside the bounds of my understanding
of legal matters here, so I'll relax now...

Fred
fred.l.templin@boeing.com=20

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]=20
> Sent: Wednesday, February 28, 2007 5:07 AM
> To: Templin, Fred L
> Cc: dhcwg; Thomas Narten
> Subject: Re: [dhcwg] dhc WG last call on=20
> draft-ietf-dhc-subnet-alloc-04=20
>=20
> Fred - the IPR disclosure for draft-ietf-dhc-subnet-alloc-04=20
> is very old (it
> actually references draft-johnson-dhc-subnet-alloc-00).  A new IPR
> disclosure has been submitted to the IETF for "Subnet=20
> Allocation Option"
> .  This new IFrom dhcwg-bounces@ietf.org Wed Feb 28 09:26:34 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMPkt-00019k-VL; Wed, 28 Feb 2007 09:26:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMPkt-000179-6a
	for dhcwg@ietf.org; Wed, 28 Feb 2007 09:26:07 -0500
Received: from slb-smtpout-01.boeing.com ([130.76.64.48]
	helo=slb-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMPkr-0003O1-L2
	for dhcwg@ietf.org; Wed, 28 Feb 2007 09:26:07 -0500
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4])
	by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1SEQ2iA018644
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 28 Feb 2007 06:26:02 -0800 (PST)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1SEQ21x014294; Wed, 28 Feb 2007 06:26:02 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1SEQ04l014220; Wed, 28 Feb 2007 06:26:01 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Feb 2007 06:26:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 
Date: Wed, 28 Feb 2007 06:26:00 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774761@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04 
Thread-Index: AcdXUVu5YUI/HQAGRaCz3qFSBM11GQAG32YAAPMiMEoAAnixMA==
References: <39C363776A4E8C4A94691D2BD9D1C9A10177473C@XCH-NW-7V2.nw.nos.boeing.com>
	
From: "Templin, Fred L" 
To: "Ralph Droms" 
X-OriginalArrivalTime: 28 Feb 2007 14:26:01.0343 (UTC)
	FILETIME=[5F0538F0:01C75B44]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Cc: Thomas Narten , dhcwg 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Ralph,

I'll have to get out my microscope and study the new statement
more carefully, but I have to go back to something Thomas asked
earlier; when cisco says: "in a *standard* adopted by the IETF"
are they meaning to include Informational-track documents, or
only Standards-track? And, if it is the latter, aren't we all in
a "darned-if-you-do and darned-if-you-don't" situation in terms
of voting for this thing as an informational-track document?

I'm already operating well outside the bounds of my understanding
of legal matters here, so I'll relax now...

Fred
fred.l.templin@boeing.com=20

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]=20
> Sent: Wednesday, February 28, 2007 5:07 AM
> To: Templin, Fred L
> Cc: dhcwg; Thomas Narten
> Subject: Re: [dhcwg] dhc WG last call on=20
> draft-ietf-dhc-subnet-alloc-04=20
>=20
> Fred - the IPR disclosure for draft-ietf-dhc-subnet-alloc-04=20
> is very old (it
> actually references draft-johnson-dhc-subnet-alloc-00).  A new IPR
> disclosure has been submitted to the IETF for "Subnet=20
> Allocation Option"
> .  This new IPR=20
> disclosure, which has
> been Cisco's standard IPR disclosure for at least a year and=20
> which I've
> included below, explicitly describes for=20
> draft-ietf-dhc-subnet-alloc-04 what
> has been Cisco's unstated policy regarding licensing terms.
>=20
> - Ralph
>=20
>   Cisco is the owner of US Patent No. 7,051,089 relating to the
>   subject matter of "Subnet Allocation Option"
>   .
>=20
>   If technology in this document is included in a standard adopted by
>   IETF and any claims of any Cisco patents are necessary for
>   practicing the standard, any party will have the right to use any
>   such patent claims under reasonable, non-discriminatory terms, with
>   reciprocity, to implement and fully comply with the standard.
>=20
>   The reasonable non-discriminatory terms are:
>=20
>   If this standard is adopted, Cisco will not assert any patents owned
>   or controlled by Cisco against any party for making, using, selling,
>   importing or offering for sale a product that implements the
>   standard, provided, however that Cisco retains the right to assert
>   its patents (including the right to claim past royalties) against
>   any party that asserts a patent it owns or controls (either directly
>   or indirectly) against Cisco or any of Cisco's affiliates or
>   successors in title or against any products of Cisco or any products
>   of any of Cisco's affiliates either alone or in combination with
>   other products; and Cisco retains the right to assert its patents
>   against any product or portion thereof that is not necessary for
>   compliance with the standard.
>=20
>   Royalty-bearing licenses will be available to anyone who prefers
>   that option.
>=20
>   For information contact:
>=20
>   Dan Lang
>   Senior IP Counsel
>   Cisco Systems
>   408-526-6672
>   standards-ipr@cisco.com
>=20
>=20
> On 2/23/07 12:09 PM, "Templin, Fred L"=20
>  wrote:
>=20
> > I have asked in the past about IPR considerations for this document.
> > If this is indeed just documenting a vendor's proprietary extension,
> > what are the IPR consideration for its use in other contexts, i.e.,
> > how much is it going to cost all the rest of us?
> >=20
> > Fred
> > fred.l.templin@boeing.com
> >=20
> >> -----Original Message-----
> >> From: Thomas Narten [mailto:narten@us.ibm.com]
> >> Sent: Friday, February 23, 2007 5:46 AM
> >> To: Ralph Droms
> >> Cc: dhcwg
> >> Subject: Re: [dhcwg] dhc WG last call on
> >> draft-ietf-dhc-subnet-alloc-04
> >>=20
> >> How would this document be published? Standards Track? Or
> >> Informational?
> >>=20
> >> FWIW, since this is just documenting a vendor-defined existing
> >> practice, one that the IETF presumably can't modify, I'd assume the
> >> document would be published as an informational one, unless the WG
> >> felt fairly strongly that this document really is the=20
> right/best way
> >> to address the problem at hand (i.e., with IETF blessing).
> >>=20
> >> Thomas
> >>=20
> >> _______________________________________________
> >> dhcwg mailing list
> >> dhcwg@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/dhcwg
> >>=20
>=20

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

From dhcwg-bounces@ietf.org Wed Feb 28 09:26:34 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMPk7-0000j9-Rg; Wed, 28 Feb 2007 09:25:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMPk5-0000j4-T8
	for dhcwg@ietf.org; Wed, 28 Feb 2007 09:25:17 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMPk2-0003Ji-4K
	for dhcwg@ietf.org; Wed, 28 Feb 2007 09:25:17 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by sj-iport-6.cisco.com with ESMTP; 28 Feb 2007 06:25:13 -0800
X-IronPort-AV: i="4.14,230,1170662400"; 
	d="scan'208"; a="116786775:sNHT58085667"
Received: from rtp-core-1.PR=20
> disclosure, which has
> been Cisco's standard IPR disclosure for at least a year and=20
> which I've
> included below, explicitly describes for=20
> draft-ietf-dhc-subnet-alloc-04 what
> has been Cisco's unstated policy regarding licensing terms.
>=20
> - Ralph
>=20
>   Cisco is the owner of US Patent No. 7,051,089 relating to the
>   subject matter of "Subnet Allocation Option"
>   .
>=20
>   If technology in this document is included in a standard adopted by
>   IETF and any claims of any Cisco patents are necessary for
>   practicing the standard, any party will have the right to use any
>   such patent claims under reasonable, non-discriminatory terms, with
>   reciprocity, to implement and fully comply with the standard.
>=20
>   The reasonable non-discriminatory terms are:
>=20
>   If this standard is adopted, Cisco will not assert any patents owned
>   or controlled by Cisco against any party for making, using, selling,
>   importing or offering for sale a product that implements the
>   standard, provided, however that Cisco retains the right to assert
>   its patents (including the right to claim past royalties) against
>   any party that asserts a patent it owns or controls (either directly
>   or indirectly) against Cisco or any of Cisco's affiliates or
>   successors in title or against any products of Cisco or any products
>   of any of Cisco's affiliates either alone or in combination with
>   other products; and Cisco retains the right to assert its patents
>   against any product or portion thereof that is not necessary for
>   compliance with the standard.
>=20
>   Royalty-bearing licenses will be available to anyone who prefers
>   that option.
>=20
>   For information contact:
>=20
>   Dan Lang
>   Senior IP Counsel
>   Cisco Systems
>   408-526-6672
>   standards-ipr@cisco.com
>=20
>=20
> On 2/23/07 12:09 PM, "Templin, Fred L"=20
>  wrote:
>=20
> > I have asked in the past about IPR considerations for this document.
> > If this is indeed just documenting a vendor's proprietary extension,
> > what are the IPR consideration for its use in other contexts, i.e.,
> > how much is it going to cost all the rest of us?
> >=20
> > Fred
> > fred.l.templin@boeing.com
> >=20
> >> -----Original Message-----
> >> From: Thomas Narten [mailto:narten@us.ibm.com]
> >> Sent: Friday, February 23, 2007 5:46 AM
> >> To: Ralph Droms
> >> Cc: dhcwg
> >> Subject: Re: [dhcwg] dhc WG last call on
> >> draft-ietf-dhc-subnet-alloc-04
> >>=20
> >> How would this document be published? Standards Track? Or
> >> Informational?
> >>=20
> >> FWIW, since this is just documenting a vendor-defined existing
> >> practice, one that the IETF presumably can't modify, I'd assume the
> >> document would be published as an informational one, unless the WG
> >> felt fairly strongly that this document really is the=20
> right/best way
> >> to address the problem at hand (i.e., with IETF blessing).
> >>=20
> >> Thomas
> >>=20
> >> _______________________________________________
> >> dhcwg mailing list
> >> dhcwg@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/dhcwg
> >>=20
>=20

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

From dhcwg-bounces@ietf.org Wed Feb 28 09:26:34 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMPk7-0000j9-Rg; Wed, 28 Feb 2007 09:25:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMPk5-0000j4-T8
	for dhcwg@ietf.org; Wed, 28 Feb 2007 09:25:17 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMPk2-0003Ji-4K
	for dhcwg@ietf.org; Wed, 28 Feb 2007 09:25:17 -0500
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by sj-iport-6.cisco.com with ESMTP; 28 Feb 2007 06:25:13 -0800
X-IronPort-AV: i="4.14,230,1170662400"; 
	d="scan'208"; a="116786775:sNHT58085667"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1SEPDG0013403; 
	Wed, 28 Feb 2007 09:25:13 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1SEP7Vf006152; 
	Wed, 28 Feb 2007 09:25:12 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Feb 2007 09:25:03 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] High Availability DHCPv6
Date: Wed, 28 Feb 2007 09:25:01 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB2103641EF7@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <20070227220918.GE20765@isc.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] High Availability DHCPv6
Thread-Index: AcdavEe0rzpNXIvVQHawy3y+2pp1DAAhp4tw
From: "Bernie Volz \(volz\)" 
To: "David W. Hankins" , 
X-OriginalArrivalTime: 28 Feb 2007 14:25:03.0503 (UTC)
	FILETIME=[3C8B89F0:01C75B44]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3287; t=1172672713;
	x=1173536713; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20High=20Availability=20DHCPv6
	|Sender:=20
	|To:=20=22David=20W.=20Hankins=22=20,
	=20;
	bh=Dfmcf/hZ27ahYaLskJ9SGCYXriEK28bIBcfARYp0syQ=;
	b=cH6dftszEF4M1V7ya0Yy1PoMWYq3buLeGrY2VrNcf4v7JSJwoLAyBTP2G7BUG1MpvwXGq5Te
	iQETOybFrFg4M/Qy3v8Dqn+viKOLcBV4pcHSE7A1A+ptCz/YDO7d6l7T;
Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

David, et al:

Address assignment / resource starvation are only a small part of what
the DHCPv4 failover protocol addresses (sorry, no pun intended).=20

And, while DHCPv6 stateful address assignment is not likely to be an
issue in terms of resource starvation, there are other allocations that
DHCPv6 is being asked to do that will likely be a fairly constrained
resource (i.e., Prefix Delegation).

While the  (where n is > 2) server model is a nice one, it causes the
same complexity issues as it did in DHCPv4 if you go beyond looking at
just the stateful address assignment issue.

>I think there is at least a good reason for defining a means
>where a group of servers can determine one server out of a group
>to respond (imagine if all 281 trillion answered in the ludicrous
>example...the point at which additional replies become waste is
>probably much smaller).

If that's all you want to solve, consider RFC 3074's hashing on the
DHCPv6 Client Identifier option and you're pretty much there. But, I
think if you consider this more carefully with DNS updates, complex
networks with relays (especially when used as access concentrators),
etc., you'll quickly find that this is a rather limited solution.

- Bernie=20

-----Original Message-----
From: David W. Hankins [mailto:David_Hankins@isc.org]=20
Sent: Tuesday, February 27, 2007 5:09 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] High Availability DHCPv6

On Mon, Feb 26, 2007 at 07:44:44AM -0500, Brzozowski, John wrote:
> At this point I have been considering putting together an I-D
(probablycisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1SEPDG0013403; 
	Wed, 28 Feb 2007 09:25:13 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1SEP7Vf006152; 
	Wed, 28 Feb 2007 09:25:12 -0500 (EST)
Received: from xmb-rtp-20a.amer.cisco.com ([64.102.31.15]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Feb 2007 09:25:03 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] High Availability DHCPv6
Date: Wed, 28 Feb 2007 09:25:01 -0500
Message-ID: <8E296595B6471A4689555D5D725EBB2103641EF7@xmb-rtp-20a.amer.cisco.com>
In-Reply-To: <20070227220918.GE20765@isc.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] High Availability DHCPv6
Thread-Index: AcdavEe0rzpNXIvVQHawy3y+2pp1DAAhp4tw
From: "Bernie Volz \(volz\)" 
To: "David W. Hankins" , 
X-OriginalArrivalTime: 28 Feb 2007 14:25:03.0503 (UTC)
	FILETIME=[3C8B89F0:01C75B44]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3287; t=1172672713;
	x=1173536713; c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=volz@cisco.com;
	z=From:=20=22Bernie=20Volz=20\(volz\)=22=20
	|Subject:=20RE=3A=20[dhcwg]=20High=20Availability=20DHCPv6
	|Sender:=20
	|To:=20=22David=20W.=20Hankins=22=20,
	=20;
	bh=Dfmcf/hZ27ahYaLskJ9SGCYXriEK28bIBcfARYp0syQ=;
	b=cH6dftszEF4M1V7ya0Yy1PoMWYq3buLeGrY2VrNcf4v7JSJwoLAyBTP2G7BUG1MpvwXGq5Te
	iQETOybFrFg4M/Qy3v8Dqn+viKOLcBV4pcHSE7A1A+ptCz/YDO7d6l7T;
Authentication-Results: rtp-dkim-1; header.From=volz@cisco.com; dkim=pass (s
	ig from cisco.com/rtpdkim1001 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Cc: 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

David, et al:

Address assignment / resource starvation are only a small part of what
the DHCPv4 failover protocol addresses (sorry, no pun intended).=20

And, while DHCPv6 stateful address assignment is not likely to be an
issue in terms of resource starvation, there are other allocations that
DHCPv6 is being asked to do that will likely be a fairly constrained
resource (i.e., Prefix Delegation).

While the  (where n is > 2) server model is a nice one, it causes the
same complexity issues as it did in DHCPv4 if you go beyond looking at
just the stateful address assignment issue.

>I think there is at least a good reason for defining a means
>where a group of servers can determine one server out of a group
>to respond (imagine if all 281 trillion answered in the ludicrous
>example...the point at which additional replies become waste is
>probably much smaller).

If that's all you want to solve, consider RFC 3074's hashing on the
DHCPv6 Client Identifier option and you're pretty much there. But, I
think if you consider this more carefully with DNS updates, complex
networks with relays (especially when used as access concentrators),
etc., you'll quickly find that this is a rather limited solution.

- Bernie=20

-----Original Message-----
From: David W. Hankins [mailto:David_Hankins@isc.org]=20
Sent: Tuesday, February 27, 2007 5:09 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] High Availability DHCPv6

On Mon, Feb 26, 2007 at 07:44:44AM -0500, Brzozowski, John wrote:
> At this point I have been considering putting together an I-D
(probably
> informational) to outline what I have done thus far.  In advance of
> doing this I wanted to reach out to you all.  Also, if there is
> sufficient interest is this topic on the list I was thinking about
> requesting a slot at the IETF68 dhcwg meeting so we can discuss in
> person.

You could say the problem DHCPv4 solves is resource starvation.
A server presides over a limited resource, of which 80-90% is
consumed...so if you lost 50% of that resource, you're doomed.

Hence, the failover draft.

In IPv6 we've tipped that scale pretty far off into the ludicrous
range in the opposite direction (you could imagine dividing a /64
into 281 trillion server buckets to serve 256 clients!).

So the old model of having N DHCP servers, each presiding
over 1/Nth of the available resource, is realistically possible
in DHCPv6.

So there's already at least one mechanism that fits neatly
inside existing protocol work.

There is potential for other mechanisms, but is there a good
reason for one?  Is limiting address hopping part of the
requirements, if so why?


I think there is at least a good reason for defining a means
where a group of servers can determine one server out of a group
to respond (imagine if all 281 trillion answered in the ludicrous
example...the point at which additional replies become waste is
probably much smaller).

--=20
ISC Training!  http://www.isc.org/training/  training@isc.org
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
--=20
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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






> informational) to outline what I have done thus far.  In advance of
> doing this I wanted to reach out to you all.  Also, if there is
> sufficient interest is this topic on the list I was thinking about
> requesting a slot at the IETF68 dhcwg meeting so we can discuss in
> person.

You could say the problem DHCPv4 solves is resource starvation.
A server presides over a limited resource, of which 80-90% is
consumed...so if you lost 50% of that resource, you're doomed.

Hence, the failover draft.

In IPv6 we've tipped that scale pretty far off into the ludicrous
range in the opposite direction (you could imagine dividing a /64
into 281 trillion server buckets to serve 256 clients!).

So the old model of having N DHCP servers, each presiding
over 1/Nth of the available resource, is realistically possible
in DHCPv6.

So there's already at least one mechanism that fits neatly
inside existing protocol work.

There is potential for other mechanisms, but is there a good
reason for one?  Is limiting address hopping part of the
requirements, if so why?


I think there is at least a good reason for defining a means
where a group of servers can determine one server out of a group
to respond (imagine if all 281 trillion answered in the ludicrous
example...the point at which additional replies become waste is
probably much smaller).

--=20
ISC Training!  http://www.isc.org/training/  training@isc.org
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
--=20
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

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





From dhcwg-bounces@ietf.org Wed Feb 28 10:10:14 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMQQp-0004f3-I8; Wed, 28 Feb 2007 10:09:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMQQd-0004Kd-Vi
	for dhcwg@ietf.org; Wed, 28 Feb 2007 10:09:16 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HMQJA-0008DC-PO
	for dhcwg@ietf.org; Wed, 28 Feb 2007 10:01:34 -0500
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by sj-iport-1.cisco.com with ESMTP; 28 Feb 2007 07:01:32 -0800
X-IronPort-AV: i="4.14,231,1170662400"; 
	d="scan'208"; a="764843583:sNHT44457944"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1SF1V49022961; 
	Wed, 28 Feb 2007 10:01:31 -0500
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1SF12Vt016381; 
	Wed, 28 Feb 2007 10:01:29 -0500 (EST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Feb 2007 10:01:28 -0500
Received: from 161.44.65.204 ([161.44.65.204]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Wed, 28 Feb 2007 15:01:28 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Wed, 28 Feb 2007 10:01:50 -0500
Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04
	(resend to identify intended publication status)
From: Ralph Droms 
To: dhcwg 
Message-ID: 
Thread-Topic: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04
	(resend to identify intended publication status)
Thread-Index: AcdZ531tvAKxoMXaEduVeQARJOT6egBYeJKH
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 28 Feb 2007 15:01:28.0771 (UTC)
	FILETIME=[5310F930:01C75B49]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1027; t=1172674891;
	x=1173538891; c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20Re=3A=20[dhcwg]=20dhc=20WG=20last=20call=20on=20draft-ietf-dh
	c-subnet-alloc-04=0A=20(resend=20to=20identify=20intended=20publication=20
	status) |Sender:=20 |To:=20dhcwg=20;
	bh=/IzUj0P/PcqpYY4Z7pFq48SZ9JYf95Aljqfa4CBp7+M=;
	b=j5wddsCp53t0O2KueM7QlgPImLyMLds3SP3oeNnOwbh2aJPJkcmHBNRrNWvryjzLdUTtbrbG
	X9ItrB2w9DIecBd2/S8NoCbm4bJi+ijvOI24ikFBZpYyGwvo99E+Q+kn;
Authentication-Results: rtp-dkim-2; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/rtpdkim2001 verified; ); 
X-Spam-Score: 1.5 (+)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: "Mark Townsley \(townsley\)" ,
	Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

The WG last call on the document "Subnet Allocation Option"
 indicates the intended publication
status as Informational.  That intended status was a mistake on my part.
This document was originally taken on as a dhc WG work item as a standards
track document and has been reviewed by the WG with that intended status in
mind.  The work predates the initiative defined in RFC 3942 to describe
existing uses of options with option codes in the range 128 to 223;
therefore, draft-ietf-dhc-subnet-alloc-04.txt should continue to be
considered for standards track publication.  Note that RFC 3942 itself is
silent on the publication status of any RFCs related to the initiative to
document the options using option codes in the range 128 to 223.

So, please respond to this WG last call for comments on the publication of
"Subnet Allocation Option"  as a
Proposed Standard.  The last call will conclude at 0900EST on March 12,
2007.

- Ralph


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



From dhcwg-bounces@ietf.org Wed Feb 28 13:16:01 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMTJU-0007nT-Qe; Wed, 28 Feb 2007 13:14:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMTJT-0007n5-4o
	for dhcwg@ietf.org; Wed, 28 Feb 2007 13:14:03 -0500
Received: from slb-smtpout-01.boeing.com ([130.76.64.48]
	helo=slb-smtpout-01.ns.cs.boeing.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMTJO-0001Gt-OE
	for dhcwg@ietf.org; Wed, 28 Feb 2007 13:14:03 -0500
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216])
	by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with
	ESMTP id l1SIDvEG026006
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 28 Feb 2007 10:13:57 -0800 (PST)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id
	l1SIDvQp024399; Wed, 28 Feb 2007 10:13:57 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com
	[130.247.55.84])
	by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id
	l1SIDucx024391; Wed, 28 Feb 2007 10:13:57 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by
	XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Feb 2007 10:13:56 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [dhcwg] dhc WG last call on draft-ietf-dhc-subnet-alloc-04(resend
	to identify intended publication status)
Date: Wed, 28 Feb 2007 10:13:55 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774767@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dhcwg] dhc WG last call on
	draft-ietf-dhc-subnet-alloc-04(resend to identify intended
	publication status)
Thread-Index: AcdZ531tvAKxoMXaEduVeQARJOT6egBYeJKHAAYOu0A=
References:  
From: "Templin, Fred L" 
To: "Ralph Droms" , "dhcwg" 
X-OriginalArrivalTime: 28 Feb 2007 18:13:56.0237 (UTC)
	FILETIME=[35E473D0:01C75B64]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: "Mark Townsley \(townsley\)" ,
	Stig Venaas 
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

Last-call comment for the authors - maybe I missed
something, but in Section 4.1 of this document I see
no provision for the client to suggest to the server
specific IP subnet prefixes that it would prefer to
receive during the DISCOVER/OFFER/REQUEST/ACK exchange.

If the client knows in advance the specific IP subnet
prefixes it would prefer to receive, *and* has reason
to believe that the server would be willing to assign
them, why can't the client include the prefixes in
Subnet Allocation options in the DISCOVER message?

Thanks - Fred
fred.l.templin@boeing.com =20

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]=20
> Sent: Wednesday, February 28, 2007 7:02 AM
> To: dhcwg
> Cc: Mark Townsley (townsley); Stig Venaas
> Subject: Re: [dhcwg] dhc WG last call on=20
> draft-ietf-dhc-subnet-alloc-04(resend to identify intended=20
> publication status)
>=20
> The WG last call on the document "Subnet Allocation Option"
>  indicates the intended=20
> publication
> status as Informational.  That intended status was a mistake=20
> on my part.
> This document was originally taken on as a dhc WG work item=20
> as a standards
> track document and has been reviewed by the WG with that=20
> intended status in
> mind.  The work predates the initiative defined in RFC 3942=20
> to describe
> existing uses of options with option codes in the range 128 to 223;
> therefore, draft-ietf-dhc-subnet-alloc-04.txt should continue to be
> considered for standards track publication.  Note that RFC=20
> 3942 itself is
> silent on the publication status of any RFCs related to the=20
> initiative to
> document the options using option codes in the range 128 to 223.
>=20
> So, please respond to this WG last call for comments on the=20
> publication of
> "Subnet Allocation Option"  as a
> Proposed Standard.  The last call will conclude at 0900EST on=20
> March 12,
> 2007.
>=20
> - Ralph
>=20
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>=20

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



From dhcwg-bounces@ietf.org Wed Feb 28 14:18:19 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMUIS-0002zM-6E; Wed, 28 Feb 2007 14:17:04 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMUIR-0002zE-Az
	for dhcwg@ietf.org; Wed, 28 Feb 2007 14:17:03 -0500
Received: from goliath.isc.org ([204.152.187.72])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMUIP-0002kQ-B2
	for dhcwg@ietf.org; Wed, 28 Feb 2007 14:17:02 -0500
Received: by goliath.isc.org (Postfix, from userid 10200)
	id A00B47D2E; Wed, 28 Feb 2007 11:16:43 -0800 (PST)
Date: Wed, 28 Feb 2007 11:16:43 -0800
From: "David W. Hankins" 
To: dhcwg@ietf.org
Subject: Re: [dhcwg] High Availability DHCPv6
Message-ID: <20070228191643.GC28901@isc.org>
References: <20070227220918.GE20765@isc.org>
	<8E296595B6471A4689555D5D725EBB2103641EF7@xmb-rtp-20a.amer.cisco.com>
Mime-Version: 1.0
In-Reply-To: <8E296595B6471A4689555D5D725EBB2103641EF7@xmb-rtp-20a.amer.cisco.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0888354283=="
Errors-To: dhcwg-bounces@ietf.org


--===============0888354283==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd"
Content-Disposition: inline


--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

My main concern (which I see now I edited out), is that we're
all very easily excited (myself included) at the prospect
of creating a new architecture of high availability.

But complexity is a price that must be justified by demand.

I want to know what the underpinnings of DHCPv6 'HA Demand'
are before we talk about the merits or failings of any one
design.

That's what I set out to say anyway.


I think IA_PD is an unknown, and at least one outcome is
that prefixes will be 'assigned' to customers rather than
dynamically allocated by the DHCP server.  No need for an
HA overlord there.

DDNS is quite possible with multiple servers, not sure what
you're hinting at.  RFC4073's example gives it away for
free.

"stateful relays" are a non-starter already.  We need to
define the way these things will work to start with...leasequery
without bulk updates clearly doesn't cut it...so we don't know
if that method will work well or poorly with existing protocol's
fault tolerance.  In this case, let's hatch the egg before we
fry the chicken?

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

--vkogqOf2sHV7VnPd
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFF5dUbcXeLeWu2vmoRAqhgAJoDwGPHEmggEWj5+vBvZYoaz0hDSQCfQQNP
/eqjaZUkdngTShk5j85yDf0=
=Y599
-----END PGP SIGNATURE-----

--vkogqOf2sHV7VnPd--


--===============0888354283==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0888354283==--




From dhcwg-bounces@ietf.org Wed Feb 28 22:31:02 2007
Return-path: 
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HMbyn-00028w-Pk; Wed, 28 Feb 2007 22:29:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HMbym-00028p-IJ
	for dhcwg@ietf.org; Wed, 28 Feb 2007 22:29:16 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1HMbyl-0001Dg-95
	for dhcwg@ietf.org; Wed, 28 Feb 2007 22:29:16 -0500
Received: from sj-dkim-6.cisco.com ([171.68.10.81])
	by sj-iport-2.cisco.com with ESMTP; 28 Feb 2007 19:29:15 -0800
X-IronPort-AV: i="4.14,233,1170662400"; 
	d="scan'208"; a="363429643:sNHT46384844"
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l213TELM015923; 
	Wed, 28 Feb 2007 19:29:14 -0800
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l213TDnF021204;
	Wed, 28 Feb 2007 19:29:14 -0800 (PST)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 28 Feb 2007 22:29:13 -0500
Received: from 10.86.242.70 ([10.86.242.70]) by xmb-rtp-211.amer.cisco.com
	([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; 
	Thu,  1 Mar 2007 03:29:13 +0000
User-Agent: Microsoft-Entourage/11.3.3.061214
Date: Wed, 28 Feb 2007 22:29:36 -0500
From: Ralph Droms 
To: dhcwg 
Message-ID: 
Thread-Topic: *DRAFT* agenda for IETF-68 dhc WG meeting
Thread-Index: AcdbsdXwFEs2hselEduVeQARJOT6eg==
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 01 Mar 2007 03:29:13.0758 (UTC)
	FILETIME=[C8AEB3E0:01C75BB1]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1311; t=1172719754;
	x=1173583754; c=relaxed/simple; s=sjdkim6002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=rdroms@cisco.com;
	z=From:=20Ralph=20Droms=20
	|Subject:=20*DRAFT*=20agenda=20for=20IETF-68=20dhc=20WG=20meeting
	|Sender:=20; bh=qZtTaIAwsqKcFZnjvOEknzj3tK+vRMyz/t8E2ODD0z8=;
	b=qNHOww8sTcoUDBQnmlvKkuk3pmnJBicspRFAdm4BQhLD2GwJNCC8I/ivXhZou9FVRe6z8TuA
	AHHV8LBVOTtSH0KLxLR2vd5JDV6KeCmOm3GVusEKQHD/2mSCcoU/DpnW;
Authentication-Results: sj-dkim-6; header.From=rdroms@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim6002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: Stig Venaas 
Subject: [dhcwg] *DRAFT* agenda for IETF-68 dhc WG meeting
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dhcwg-bounces@ietf.org

                          DHC WG agenda - IETF 67
                        0900-1130 2007-03-21 (Wed)
                   (Last revised 2007-02-28 10:24 PM ET)
                   -------------------------------------

Administrivia                                   Venaas/Droms     10 minutes
  Agenda bashing; blue sheets; scribe; Jabber scribe

Draft last call and adoption announcements      Venaas/Droms     10 minutes

WG rechartering                                 Venaas/Droms     10 minutes

Container Option for Server Configuration       R. Droms         10 minutes
  
  Initial discussion

Report from DHCPv6 interoperability test event  A. Durand        10 minutes

Authentication Extensions for the DHCP          R. Pruss         10 minutes
  
  Initial discussion

Layer 2 Relay Agent                             P. Kurapati      15 minutes
  
  Initial discussion

Relay Chaining in DHCPv4                        P. Kurapati      15 minutes
  
  Initial discussion
                                                                -----------
                                                                 90 minutes

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