From mailman-bounces@ietf.org Wed Sep 1 09:50:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12791 for ; Wed, 1 Sep 2004 09:50:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2RSE-0008U0-Il for dhc-archive@lists.ietf.org; Wed, 01 Sep 2004 05:30:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: dhc-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Sep 2004 05:08:38 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for dhc-archive@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-bounces@ietf.org Wed Sep 1 10:53:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22218; Wed, 1 Sep 2004 10:53:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2SF1-0006IZ-M0; Wed, 01 Sep 2004 06:21:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2NQ4-0003Ul-Ls for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 01:12:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07133 for ; Wed, 1 Sep 2004 01:12:28 -0400 (EDT) Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2NSB-0000Tu-Sm for dhcwg@ietf.org; Wed, 01 Sep 2004 01:14:40 -0400 Received: from emily (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I3C007M4J3WMG@mta0.huawei.com> for dhcwg@ietf.org; Wed, 01 Sep 2004 12:57:34 +0800 (CST) Date: Wed, 01 Sep 2004 10:25:04 +0530 From: mao shanxiang Subject: Re: [dhcwg] dhcp6 verndor class option To: Bernie Volz , "'Keshava'" , dhcwg@ietf.org Message-id: <000601c48fdf$d93bf240$db04120a@emily> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com References: <000101c48fc3$748d79c0$6401a8c0@amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Wed, 01 Sep 2004 06:21:21 -0400 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Bernie, if relay includes such option, what is the behavior of the server? the server can return information in the Relay-Reply, but what is the usage for server to analyze such option info? give different policy? can you please clarify me? Regards, Emily ----- Original Message ----- From: "Bernie Volz" To: "'Keshava'" ; ; Cc: Sent: Wednesday, September 01, 2004 7:01 AM Subject: RE: [dhcwg] dhcp6 verndor class option If there's relay specific information that could be used by a server (or other relay), there is no reason the relay can't include this in its Relay-Forw message (and the server return information in the Relay-Reply). Note that Appendix A, Appearance of Options in Message Types, indicates that these are valid: Status Rap. User Vendor Vendor Inter. Recon. Recon. Code Comm. Class Class Spec. ID Msg. Accept R-forw. * * * * R-repl. * * * * - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Keshava Sent: Friday, August 27, 2004 10:10 AM To: dhcwg@ietf.org; ipv6@ietf.org Cc: keshavaak@huawei.com; maoshx@huawei.com Subject: [dhcwg] dhcp6 verndor class option Hi, Can you please clarify in he RFC 3315 (DHCP6) "Appearance of Options in Message Types" section mentions that the dhcp6 relay should support vendor class option. But in the message processing in the "Section 22.16 Vendor Class Option" does not mention any thing about this for relay . It only mentions about how the client should process this. Can some one please clarify this what should be done for dhcp6 relay ? regards, keshava _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 1 12:27:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05169; Wed, 1 Sep 2004 12:27:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XMS-0005cG-Rk; Wed, 01 Sep 2004 11:49:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VFi-00046A-9h for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 09:34:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06191 for ; Wed, 1 Sep 2004 09:34:13 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2UJ2-0001JM-6O for dhcwg@ietf.org; Wed, 01 Sep 2004 08:33:41 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i81CUXOK000613; Wed, 1 Sep 2004 14:30:33 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i81CUThF015683; Wed, 1 Sep 2004 14:30:29 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 1 Sep 2004 14:30:29 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040901123029.GI15000@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Wed, Sep 01, 2004 at 01:01:51AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Tue, 24 Aug 2004 11:08:14 -0400, > >>>>> Ted Lemon said: > > > However, let's consider your scenario a little more closely. You > > acquire some information from the DHCP server. Subsequently, for some > > reason, it becomes impossible for the server to respond to the client. > > > I have a couple of observations about this. First, the time at which > > it becomes impossible for the server to respond is not the same as the > > time at which the client attempts to refresh its configuration > > information. The two events are unrelated. > > Okay, I concur on this. I also see that the scenario might differ > based on whether the client moves to a new link or it stays in the > same link. What you write sounds reasonable, but I'm still not sure we should go into the details. The reason is that we don't know in general what the behaviour should be, and it's a generic issue. It's obviously a related issue though. We could as Ted suggests, specify this later when we have more information. That could either be as an update to the lifetime RFC, or IMO perhaps better, add some text if an update to RFC 3315 is done. There seems to be other reasons to update RFC 3315 too (draft-jinmei-dhc-dhcpv6-clarify-auth-00?). In general I agree with your distinction between still and moving clients. What worries me though, is that it might not be possible for a client to distinguish between movement and renumbering. The fact that a new prefix is announced in RAs is not sufficient. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 1 12:32:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05609; Wed, 1 Sep 2004 12:32:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XMd-0005p1-3C; Wed, 01 Sep 2004 11:49:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VGM-0004FR-4R for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 09:35:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06726 for ; Wed, 1 Sep 2004 09:34:54 -0400 (EDT) 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.33) id 1C2Tl0-0000q1-M3 for dhcwg@ietf.org; Wed, 01 Sep 2004 07:58:32 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Sep 2004 05:03:43 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i81BteKX013164; Wed, 1 Sep 2004 04:55:41 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-207.cisco.com [10.86.242.207]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALF80427; Wed, 1 Sep 2004 07:55:39 -0400 (EDT) From: "Bernie Volz" To: "'mao shanxiang'" , "'Keshava'" , Subject: RE: [dhcwg] dhcp6 verndor class option Date: Wed, 1 Sep 2004 07:55:40 -0400 Organization: Cisco Message-ID: <000401c4901a$9a2434b0$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <000601c48fdf$d93bf240$db04120a@emily> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Well, as we have no DHCPv6 option to carry a subscriber ID, perhaps the relay wants to communicate that to the server? So, it could send this in = the vendor-specific option. Or, if the relay is on a switch, it could include the port on which the client is located. There's all sorts of possibilities. - Bernie > -----Original Message----- > From: mao shanxiang [mailto:maoshx@huawei.com]=20 > Sent: Wednesday, September 01, 2004 12:55 AM > To: Bernie Volz; 'Keshava'; dhcwg@ietf.org > Subject: Re: [dhcwg] dhcp6 verndor class option >=20 >=20 > Hi Bernie, >=20 > if relay includes such option, what is the behavior of the=20 > server? the server can return information in the Relay-Reply,=20 > but what is the usage for server to analyze such option info?=20 > give different policy? >=20 > can you please clarify me? >=20 > Regards, > Emily >=20 > ----- Original Message -----=20 > From: "Bernie Volz" > To: "'Keshava'" ; ;=20 > > Cc: > Sent: Wednesday, September 01, 2004 7:01 AM > Subject: RE: [dhcwg] dhcp6 verndor class option >=20 >=20 > If there's relay specific information that could be used by a=20 > server (or other relay), there is no reason the relay can't=20 > include this in its Relay-Forw message (and the server return=20 > information in the Relay-Reply). >=20 > Note that Appendix A, Appearance of Options in Message Types,=20 > indicates that these are valid: >=20 > Status Rap. User Vendor Vendor Inter. Recon. Recon. > Code Comm. Class Class Spec. ID Msg. Accept > R-forw. * * * * > R-repl. * * * * >=20 > - Bernie >=20 > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Keshava > Sent: Friday, August 27, 2004 10:10 AM > To: dhcwg@ietf.org; ipv6@ietf.org > Cc: keshavaak@huawei.com; maoshx@huawei.com > Subject: [dhcwg] dhcp6 verndor class option >=20 >=20 > Hi, > Can you please clarify in he RFC 3315 (DHCP6) >=20 > "Appearance of Options in Message Types" section mentions=20 > that the dhcp6 relay should support > vendor class option. >=20 > But in the message processing in the "Section 22.16=20 > Vendor Class Option" does not mention any > thing about this for relay . It only mentions about how=20 > the client should process this. >=20 > Can some one please clarify this what should be done=20 > for dhcp6 relay ? >=20 >=20 > regards, > keshava >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 1 13:01:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10611; Wed, 1 Sep 2004 13:01:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XTU-0002iP-FR; Wed, 01 Sep 2004 11:56:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2VxY-0004YZ-Si for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 10:19:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17436 for ; Wed, 1 Sep 2004 10:19:34 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Vzk-0002An-1o for dhcwg@ietf.org; Wed, 01 Sep 2004 10:21:53 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:9d66:8cbb:c45e:52c1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A1BFD15265; Wed, 1 Sep 2004 23:19:26 +0900 (JST) Date: Wed, 01 Sep 2004 23:19:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ted Lemon Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt In-Reply-To: <8789608F-FB6B-11D8-8C0B-000D93C4B69A@fugue.com> References: <000e01c486b3$66af02b0$6401a8c0@amer.cisco.com> <6493.1093586912@munnari.OZ.AU> <20040831120208.GM2203@sverresborg.uninett.no> <8789608F-FB6B-11D8-8C0B-000D93C4B69A@fugue.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 31 Aug 2004 09:33:46 -0700, >>>>> Ted Lemon said: >> I don't know what people think, I have no strong feelings myself, but >> we could relax things a bit perhaps. But there is some added complexity >> and it isn't essential. It could also be extended later if necessary. >> >> We could tweak the spec to allow what you say, if there's agreement on >> that. But most of all, I want to come to some conclusion really soon. > I think using the IRT option in a context where there is a lifetime > already doesn't make sense, and should not be allowed. I don't mean > the client should drop the packet if it gets both - just that the > option has no meaning in the context of a stateful DHCP message. I basically agree with this. Regarding complexity, different people may have different image on it, so I suspect we can easily get a consensus. But I think we all at least agreed on the following points: it isn't not that useful to have a separate lifetime when we already have lifetimes (or lease times) for addresses in the stateful case. (almost the same thing what Ted said above) In addition to that, as an implementor, if we explicitly allow this case, it means we'll need to implement it anyway to be compliant to the RFC(-to-be), even though we know we have no practical case where it is useful. Opinions on whether the implementation will be complicated or not may differ among people (see above), but it's a real issue for me as an implementor. If we need a compromise for future possibility, we could explicitly say this case is beyond the scope of the document as I mentioned earlier. 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 Wed Sep 1 13:16:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11971; Wed, 1 Sep 2004 13:16:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2XZE-0000ZR-2r; Wed, 01 Sep 2004 12:02:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2WTS-0003II-KI for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 10:52:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22133 for ; Wed, 1 Sep 2004 10:52:31 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2WVe-0003xy-26 for dhcwg@ietf.org; Wed, 01 Sep 2004 10:54:51 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:9d66:8cbb:c45e:52c1]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5293415265; Wed, 1 Sep 2004 23:52:31 +0900 (JST) Date: Wed, 01 Sep 2004 23:52:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) In-Reply-To: <20040901123029.GI15000@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> <20040901123029.GI15000@sverresborg.uninett.no> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Wed, 1 Sep 2004 14:30:29 +0200, >>>>> Stig Venaas said: > What you write sounds reasonable, but I'm still not sure we should go > into the details. The reason is that we don't know in general what > the behaviour should be, and it's a generic issue. It's obviously a > related issue though. We could as Ted suggests, specify this later > when we have more information. That could either be as an update to > the lifetime RFC, or IMO perhaps better, add some text if an update > to RFC 3315 is done. There seems to be other reasons to update RFC > 3315 too (draft-jinmei-dhc-dhcpv6-clarify-auth-00?). I would first like to note that the suggestion by Ted of leaving it to a later document was followed by his response to me where he agreed (or at least seemed to agree) with my proposal. Secondly, if I understand the sense in this list correctly, I believe my proposal reflects some level of consensus here. Third, I personally think we can reflect the proposal without making the document unnecessarily long. (If you want, I'll try to contribute to some text.) So, I personally think it makes sense to clarify the points at this chance even though the points can be extended to general issues. ...but I don't want to delay this important work due to my pedantic ego. If others still want to leave those points to other documents, I'll obey that decision (but at least I want the "lifetime" document to mention those a bit and to say that those are beyond the scope of the doc). > In general I agree with your distinction between still and moving > clients. What worries me though, is that it might not be possible for > a client to distinguish between movement and renumbering. The fact > that a new prefix is announced in RAs is not sufficient. As I said in my previous message, I basically think we can concentrate on the "still" clients in this document, and do not have to worry too much about miscellaneous subtle cases of moving vs not-actually-moving. Movement detection is itself a difficult challenge (we even have a dedicated wg on this!), so I think it is enough in the scope of dhc wg to show some preliminary considerations on the moving clients (e.g., as shown in Section 18.1.2 of RFC3315.). Besides, I don't see an actual problem in that particular case you raised above, along with my proposed approach. If the client misunderstands that it has moved to a different link while it actually stays in the same link, the client will resend an Information-request message immediately based on the proposed scenario. In this case, however, the legitimate DHCPv6 server should still be there and will respond to the Information-request with valid configuration information. (request storm might be an issue, but confusing events like renumbering should be rare). On the other hand, if the client misunderstands that it stays in the same link while it has actually moved, the client will perhaps have a trouble. Along with the proposed approach, however, I think we don't have to worry about that within the scope of this document; we'll basically note that issues regarding moving clients are difficult and will need future analysis. 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 Wed Sep 1 13:18:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12281; Wed, 1 Sep 2004 13:18:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Xa0-0002sz-0L; Wed, 01 Sep 2004 12:03:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Wk0-0002VQ-7M for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 11:09:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24981 for ; Wed, 1 Sep 2004 11:09:37 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2WmD-00051B-8l for dhcwg@ietf.org; Wed, 01 Sep 2004 11:11:57 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 01 Sep 2004 11:21:37 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i81F91ZQ008187; Wed, 1 Sep 2004 11:09:06 -0400 (EDT) Received: from volzw2k (dhcp-10-86-160-46.cisco.com [10.86.160.46]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALF94279; Wed, 1 Sep 2004 11:09:00 -0400 (EDT) From: "Bernie Volz" To: "'mao shanxiang'" , "'Keshava'" , Subject: RE: [dhcwg] dhcp6 verndor class option Date: Wed, 1 Sep 2004 11:09:00 -0400 Organization: Cisco Message-ID: <000501c49035$9c60ea00$2ea0560a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <000601c48fdf$d93bf240$db04120a@emily> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit This is completely up to the server. See DHCP Relay Agent Information Option (RFC 3046) for more details as to how this is may be used in DHCPv4. This really is no different for DHCPv6, just that the way the information is carried is different and is vendor-specific -- though likely there will be standardized relay agent options to carry information in the future. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of mao shanxiang > Sent: Wednesday, September 01, 2004 12:55 AM > To: Bernie Volz; 'Keshava'; dhcwg@ietf.org > Subject: Re: [dhcwg] dhcp6 verndor class option > > > Hi Bernie, > > if relay includes such option, what is the behavior of the > server? the server can return information in the Relay-Reply, > but what is the usage for server to analyze such option info? > give different policy? > > can you please clarify me? > > Regards, > Emily > > ----- Original Message ----- > From: "Bernie Volz" > To: "'Keshava'" ; ; > > Cc: > Sent: Wednesday, September 01, 2004 7:01 AM > Subject: RE: [dhcwg] dhcp6 verndor class option > > > If there's relay specific information that could be used by a > server (or other relay), there is no reason the relay can't > include this in its Relay-Forw message (and the server return > information in the Relay-Reply). > > Note that Appendix A, Appearance of Options in Message Types, > indicates that these are valid: > > Status Rap. User Vendor Vendor Inter. Recon. Recon. > Code Comm. Class Class Spec. ID Msg. Accept > R-forw. * * * * > R-repl. * * * * > > - Bernie > > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Keshava > Sent: Friday, August 27, 2004 10:10 AM > To: dhcwg@ietf.org; ipv6@ietf.org > Cc: keshavaak@huawei.com; maoshx@huawei.com > Subject: [dhcwg] dhcp6 verndor class option > > > Hi, > Can you please clarify in he RFC 3315 (DHCP6) > > "Appearance of Options in Message Types" section mentions > that the dhcp6 relay should support > vendor class option. > > But in the message processing in the "Section 22.16 > Vendor Class Option" does not mention any > thing about this for relay . It only mentions about how > the client should process this. > > Can some one please clarify this what should be done > for dhcp6 relay ? > > > regards, > keshava > > > _______________________________________________ > 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 Sep 1 14:21:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17964; Wed, 1 Sep 2004 14:21:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2ZIB-0006ki-Am; Wed, 01 Sep 2004 13:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2Yfv-0005r6-41 for dhcwg@megatron.ietf.org; Wed, 01 Sep 2004 13:13:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11674 for ; Wed, 1 Sep 2004 13:13:31 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2Yi8-00062O-76 for dhcwg@ietf.org; Wed, 01 Sep 2004 13:15:53 -0400 Received: from [10.0.2.8] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 125E41B225E for ; Wed, 1 Sep 2004 12:11:50 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20040901123029.GI15000@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> <20040901123029.GI15000@sverresborg.uninett.no> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3EA34C4F-FC3A-11D8-8C0B-000D93C4B69A@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Wed, 1 Sep 2004 10:13:29 -0700 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Sep 1, 2004, at 5:30 AM, Stig Venaas wrote: > What worries me though, is that it might not be possible for > a client to distinguish between movement and renumbering. The fact > that a new prefix is announced in RAs is not sufficient. I would like to point out the work that they're doing in the DNA working group. This is what I had in mind when I spoke earlier about detecting that the client had moved. This work does not depend on noticing differences in RA messages. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 2 05:45:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16753; Thu, 2 Sep 2004 05:45:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2o1G-0000Yo-IW; Thu, 02 Sep 2004 05:36:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2nm7-0001QA-L3 for dhcwg@megatron.ietf.org; Thu, 02 Sep 2004 05:20:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15271 for ; Thu, 2 Sep 2004 05:20:57 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2noT-0000AD-4k for dhcwg@ietf.org; Thu, 02 Sep 2004 05:23:26 -0400 Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:79b7:3eeb:f7f7:b9ee]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 47DA615272; Thu, 2 Sep 2004 18:20:56 +0900 (JST) Date: Thu, 02 Sep 2004 18:20:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Subject: Re: [dhcwg] Re: one more comment about the lifetime option In-Reply-To: <001401c48a3e$2ededf20$6401a8c0@amer.cisco.com> References: <001401c48a3e$2ededf20$6401a8c0@amer.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org (forgot to reply to this...) I've changed the order of the citation below. >>>>> On Tue, 24 Aug 2004 20:55:14 -0400, >>>>> "Bernie Volz" said: >> > We should also restrict the position where the lifetime option can >> > appear: it should only be able to appear at the "top level" >> of option >> > hierarchy. >> >> I think this is a good idea. > If it is restricted to a REPLY to an INFORMATION-REQUEST, there is > no need for this explicit statement as that's all that is currently > possible - there are no IA_NA, IA_TA, or IA_PD options for these > messages. I don't think this is really the case. An authentication option can be used with Information-request and can have sub-options. 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 Sep 2 08:46:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29306; Thu, 2 Sep 2004 08:46:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2qq0-0002hi-Hb; Thu, 02 Sep 2004 08:37:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2qds-0004Wg-3Y for dhcwg@megatron.ietf.org; Thu, 02 Sep 2004 08:24:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27569; Thu, 2 Sep 2004 08:24:39 -0400 (EDT) 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.33) id 1C2qgE-0006nz-Qh; Thu, 02 Sep 2004 08:27:08 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2004 05:31:35 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i82CNK2l021526; Thu, 2 Sep 2004 05:23:21 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-16.cisco.com [10.86.242.16]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALG62578; Thu, 2 Sep 2004 08:23:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20040902082231.0200cbe8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Sep 2004 08:23:17 -0400 To: proceedings@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_54347367==_" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: dhcwg@ietf.org Subject: [dhcwg] Minutes from IETF 60 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --=====================_54347367==_ Content-Type: text/plain; charset="us-ascii"; format=flowed The minutes from the dhc WG meeting at IETF 60 are attached. - Ralph Droms --=====================_54347367==_ Content-Type: text/html; name="IETF_60_dhc_WG_minutes.html" Content-Disposition: attachment; filename="IETF_60_dhc_WG_minutes.html" Content-Transfer-Encoding: base64 PHhtcD4KCQkJICAgTWVldGluZyBTdW1tYXJ5CgkJCSAgIGRoYyBXRywgSUVURiA2MAoJCQkgICAy MDA0LTA4LTAzLCAwOTAwCgkJCSAgIC0tLS0tLS0tLS0tLS0tLS0KCkFkbWluaXN0cml2aWEKLS0t LS0tLS0tLS0tLQoKVGhlIGNoYWlyIGdyYXRlZnVsbHkgYWNrbm93bGVkZ2VzIEtpbSBLaW5uZWFy LCBKb2huIFNjaG5pemxlaW4gZm9yCnByb3ZpZGluZyBub3RlcyBhbmQgVGltIENob3duIGZvciBh Y3RpbmcgYXMgamFiYmVyIHNjcmliZSwgd2hpY2ggdGhlCmNoYWlyIHVzZWQgaW4gcHJlcGFyaW5n IHRoZXNlIG1pbnV0ZXMuCgpUaGUgY2hhaXIgYW5ub3VuY2VkIHRoYXQgU2FtdW5nIGhhcyBwdWJs aXNoZWQgYSB6ZXJvLWNvc3QgbGljZW5zaW5nCklQUiBjbGFpbSBvbiBkcmFmdC1pZXRmLWRoYy1y YXBpZC1jb21taXQtb3B0LTA1LnR4dC4gVGhlcmUgd2FzIG5vCm9iamVjdGlvbiBpbiB0aGUgV0cg dG8gbW92aW5nIHRoZSBkcmFmdCBkcmFmdCBmb3J3YXJkLgoKVGhlIGNoYWlyIGFubm91bmNlZCB0 aGF0IHRoZXJlIHdhcyBubyByZXNwb25zZSBmcm9tIFBhY2tldEZyb250IHRvIGEKcmVxdWVzdCBm cm9tIHRoZSBJRVRGIGZvciBjbGFyaWZpY2F0aW9uIG9mIElQUiBjbGFpbSBhbmQgYSByZXF1ZXN0 CmZyb20gdGhlIGNoYWlyIGZvciBhIHplcm8tY29zdCBsaWNlbnNpbmcgSVBSIGNsYWltIG9uCmRy YWZ0LWlldGYtZGhjLXN1YnNjcmliZXItaWQtMDYudHh0LiAgVGhlIGNvbnNlbnN1cyBvZiB0aGUg V0cgd2FzIHRvCm1vdmUgdGhlIGRyYWZ0IGZvcndhcmQgZGVzcGl0ZSB0aGUgY3VycmVudCBJUFIg Y2xhaW0uCgpUaGUgREhDUHY2IENsaWVudCBGUUROIE9wdGlvbiA8ZHJhZnQtdm9sei1kaGMtZGhj cHY2LWZxZG4+Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KClRoZSBhdXRob3IgZ2F2ZSBhIHNob3J0IHByZXNlbnRhdGlvbiBvbiB0aGUg ZHJhZnQgYW5kIGFza2VkIGZvcgpjb21tZW50cy4KCktpbSBLaW5uZWFyIHN1Z2dlc3RlZCB0aGF0 IHdlIHNwZWxsIG91dCBob3cgdG8gaGFuZGxlIHRoZSBjYXNlKHMpCndoZXJlIHRoZSBjbGllbnQg ZG9lc24ndCBzZW5kIGluIHRoZSBGUUROIG9wdGlvbi4gIE9uZSBpc3N1ZSBpcywgY2FuCnRoZSBz ZXJ2ZXIgcmVwbHkgd2l0aCB0aGUgRlFETiB0byB0aGUgY2xpZW50IGlmIHRoZSBjbGllbnQgZG9l c24ndApzZW5kIGl0IGluPyAgVGhlIGRyYWZ0IGN1cnJlbnRseSBzYXlzIG5vLiAgQW5vdGhlciBp c3N1ZSBpcyB3aGF0IHRvIGRvCmlmIHRoZSBjbGllbnQgc2VuZCBpbiBhbiBGUUROIG9wdGlvbiwg YW5kIHRoZW4gZG9lc24ndCBmb3Igb25lIHRpbWUsCndoYXQgc2hvdWxkIHRoZSBzZXJ2ZXIgZG8/ CgpQZWtrYSBTYXZsb2EgYXNrZWQgd2hhdCBhYm91dCBhIGNsaWVudCB0aGF0IHRyaWVzIHRvIHVw ZGF0ZSBETlMKaXRzZWxmLCBhbmQgd2hhdCBpcyB0aGUgb3BlcmF0aW9uYWwgcmVhc29ucyBmb3Ig dGhlIERIQ1Agc2VydmVyIHRvIGRvCnRoZSB1cGRhdGUgaW5zdGVhZCBvZiB0aGUgREhDUCBjbGll bnQuICBCZXJuaWUgYW5kIE1hcmsgc3VnZ2VzdGVkIHRoYXQKdXNpbmcgdGhlIGNsaWVudCBGUURO IG9wdGlvbiBkb2Vzbid0IGNoYW5nZSB0aGUgZmFjdCB0aGF0IHlvdSBoYXZlCm9wZW5lZCB1cCB0 aGUgRE5TIHNlcnZlciB0byBkeW5hbWljIHVwZGF0ZXMuICBUZWQgc3VnZ2VzdGVkIHRoYXQgdGhp cwpESENQdjYgYXBwcm9hY2ggcGFyYWxsZWxzIHRoZSBESENQdjQgYXBwcm9hY2gsIGFuZCB0aGF0 IHRoZSBxdWVzdGlvbmVyCnNob3VsZCBwZXJoYXBzIHJldmlldyB0aGUgREhDUHY0IGRyYWZ0cyBv biB0aGlzIHN1YmplY3QgdG8gYmV0dGVyCnVuZGVyc3RhbmQgaG93IHRoZSBlbnRpcmUgYXBwcm9h Y2ggb3BlcmF0ZXMuCgpUZWQgTGVtb24gYXNrZWQgaWYgdGhlcmUgaXMgYSBwb3RlbnRpYWwgZXhw bG9zaW9uIG9mIHNlbmRpbmcgbG90cyBvZgpuYW1lcyBiYWNrIHdpdGggYSBzaW5nbGUgcmVxdWVz dD8gIEJlcm5pZSBzYWlkIHllcywgdGhlIHNlcnZlciBtaWdodApvZmZlciBtdWx0aXBsZSBuYW1l cy4KCk1hcmdhcmV0IFdhYXNzZXJtYW4gYXNrZWQgaWYgcmV2aWV3IG9mIHRoaXMgZHJhZnQgd291 bGQgdGhpcyBiZQpjb29yZGluYXRlZCB3aXRoIHRoZSBkbnNleHQgV0c/ICBUaGUgY2hhaXIgYW5z d2VyZWQgeWVzIGFsb25nIHdpdGggdGhlCm90aGVycyBpbiB0aGlzIHBhY2thZ2UgKHNlZSBiZWxv dyBmb3IgbGlzdCkgdGhhdCBhcmUgYmVpbmcgY29vcmRpbmF0ZWQuCgpBZnRlciBzb21lIGRpc2N1 c3Npb24gb2YgdGhlIHRlY2huaWNhbCBkZXRhaWxzLCB0aGUgY29uc2Vuc3VzIG9mIHRoZQpXRyBh dCB0aGUgbWVldGluZyB3YXMgdG8gYWNjZXB0IGRyYWZ0LXZvbHotZGhjLWRoY3B2Ni1mcWRuIGFz IGEgV0cKd29yayBpdGVtLiAgSXQgd2lsbCBiZSBwYXJ0IG9mIGEgcGFja2FnZSBvZiBkcmFmdHMg dG8gYmUgc3VibWl0dGVkIHRvCnRoZSBJRVNHOgoKICBkcmFmdC12b2x6LWRoYy1kaGNwdjYtZnFk bgogIGRyYWZ0LWlldGYtZGhjLWZxZG4tb3B0aW9uCiAgZHJhZnQtaWV0Zi1kbnNleHQtZGhjaWQt cnItMDcudHh0CiAgZHJhZnQtaWV0Zi1kaGMtZGRucy1yZXNvbHV0aW9uLTA3LnR4dAogIGRyYWZ0 LWlldGYtZGhjLTMzMTVpZC1mb3ItdjQtMDMudHh0CgpUaGUgY29uc2Vuc3VzIHRvIGFjY2VwdCB0 aGUgZHJhZnQgd2lsbCBiZSBjb25maXJtZWQgb24gdGhlIFdHIG1haWxpbmcKbGlzdC4KClRoZSBE SENQIENsaWVudCBGUUROIE9wdGlvbiAgPGRyYWZ0LWlldGYtZGhjLWZxZG4tb3B0aW9uPgotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClRo ZSBhdXRob3Igc3VtbWFyaXplZCB0aGUgZWRpdG9yaWFsIGNoYW5nZXMuICBUaGUgV0cgbWVldGlu ZyBjb25zZW5zdXMKd2FzIHRoYXQgdGhpcyBkcmFmdCBpcyByZWFkeSBmb3IgV0cgbGFzdCBjYWxs LiAgSXQgd2lsbCBnbyB0byBsYXN0CmNhbGwgd2hlbiBvdGhlciBkcmFmdHMgaW4gdGhlIHBhY2th Z2UgYXJlIHJlYWR5LiAgVGhlIGNvbnNlbnN1cyB0aGF0CnRoZSBkcmFmdCBpcyByZWFkeSBmb3Ig V0cgbGFzdCBjYWxsIHdpbGwgYmUgY29uZmlybWVkIG9uIHRoZSBXRwptYWlsaW5nIGxpc3QuCgpE SENQIE9wdGlvbiBmb3IgQ29uZmlndXJpbmcgSVB2Ni1vdmVyLUlQdjQgVHVubmVscyA8ZHJhZnQt ZGFuaWVsLWRoYy1pcHY2aW40LW9wdD4KQ29uZmlndXJlZCBUdW5uZWwgRW5kLVBvaW50IENvbmZp Zy4gdXNpbmcgREhDUHY0IDxkcmFmdC1kYW5pZWwtZGhjLWRoY3B2NC10ZXAtY29uZj4KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KCkRpc2N1c3Npb24gZm9jdXNlZCBvbiA8ZHJhZnQtZGFuaWVs LWRoYy1pcHY2aW40LW9wdD4uICBUZWQgTGVtb24Kc3VnZ2VzdGVkIHRoYXQgdGhlIGRyYWZ0IHNw ZWNpZmljYWx5IHJlcXVpcmUgdGhhdCB0aGlzIG9wdGlvbiBvbmx5IGJlCnNlbnQgd2hlbiB0aGUg Y2xpZW50IGhhcyByZXF1ZXN0ZWQgdGhlIG9wdGlvbi4gIFRoZSBXRyBtZWV0aW5nCmNvbmNlbnN1 cyB3YXMgdG8gdGFibGUgZGlzY3Vzc2lvbiB1bnRpbCBkaGMgYW5kIHY2b3BzIFdHIGNoYWlycwpk aXNjdXNzIHdoaWNoIFdHIHNob3VsZCB0YWtlIG9uIHRoZXNlIGRyYWZ0cyBhbmQgaG93IHRoZSBk cmFmdHMgZml0CmludG8gdGhlIHY2b3BzIFdHIGRpc2N1c3Npb24gb2YgdHVubmVsIGRpc2NvdmVy eSBtZXRob2RzLgoKVmVuZG9yLVNwZWNpZmljIEluZm9ybWF0aW9uIFN1Ym9wdGlvbiBmb3IgUkFJ TyA8ZHJhZnQtc3RhcHAtZGhjLXZlbmRvci1zdWJvcHRpb24+Ci0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQoKVGhlIFdHIG1lZXRpbmcgY29uc2Vuc3VzIHdhcyB0byBhY2NlcHQgdGhpcyBkcmFmdCBh cyBhIGRoYyBXRyB3b3JrCml0ZW0uICBUaGUgY29uc2Vuc3VzIHdpbGwgYmUgY29uZmlybWVkIG9u IHRoZSBXRyBtYWlsaW5nIGxpc3QuCgpSZW51bWJlcmluZyBSZXF1aXJlbWVudHMgZm9yIFN0YXRl bGVzcyBESENQdjYgPGRyYWZ0LWlldGYtZGhjLXN0YXRlbGVzcy1kaGNwdjYtcmVudW1iZXJpbmc+ Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KClRoZSBhdXRob3Igc3VtbWFyaXpl ZCB0aGUgY2hhbmdlcyBzaW5jZSB0aGUgZHJhZnQgd2FzIGxhc3QgZGlzY3Vzc2VkCmluIFNlb3Vs LiAgSXQgaXMgcmVsYXRlZCB0byB0aGUgcmVudW1iZXJpbmcgZHJhZnQgYnkgQmFrZXIsIGV0IGFs LiwgaW4KdGhlIHY2b3BzIFdHLiAKClRoZSBXRyBtZWV0aW5nIGNvbnNlbnN1cyB3YXMgdGhhdCB0 aGUgZHJhZnQgaXMgdG8gYmUgc3VibWl0dGVkIHRvIHRoZQpJRVNHIGluZGVwZW5kZW50IG9mIGFu eSBzcGVjaWZpYyBzb2x1dGlvbiwgZm9yIHB1YmxpY2F0aW9uIGFzIGFuCkluZm9ybWF0aW9uYWwg UkZDLiAgVGhlIFdHIG1lZXRpbmcgY29uc2Vuc3VzIHdhcyB0aGF0IGRyYWZ0IGlzIHJlYWR5CmZv ciBXRyBsYXN0IGNhbGwgKHRvIGJlIGNvbmZpcm1lZCBvbiB0aGUgV0cgbWFpbGluZyBsaXN0KS4K CkxpZmV0aW1lIE9wdGlvbiBmb3IgREhDUHY2IDxkcmFmdC1pZXRmLWRoYy1saWZldGltZT4KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhlIGF1 dGhvciBwcmVzZW50ZWQgdGhlIHVwZGF0ZWQgZHJhZnQgYW5kIGFza2VkIHRocmVlIHF1ZXN0aW9u czoKCiAgV2hhdCBpZiB0aGUgY2xpZW50IGFza3MgZm9yIG9wdGlvbiBhbmQgZG9lc24ndCBnZXQg aXQgZnJvbSB0aGUKICBzZXJ2ZXI/ICBTdGlnJ3MgYW5zd2VyIGlzIHRoYXQgaWYgeW91IGdldCBp dCBvbmNlIGFuZCBkb24ndCBnZXQgaXQKICBhZ2FpbiwgaXQgc2hvdWxkIGJlIGxpa2UgaXQgbmV2 ZXIgY2FtZSBpbi4KCiAgV2hhdCBzaG91bGQgaGFwcGVuIGlmIHRoZSBjbGllbnQgY2FuJ3QgcmVu ZXcgaW5mb3JtYXRpb24uICBEb24ndAogIGZvcmdldCB3aGF0IHlvdSd2ZSBnb3Qgd2hpbGUgeW91 IGFyZSB3YWl0aW5nIGZvciB0aGUgdXBkYXRlLgoKICBTaG91bGQgd2Ugc3VwcG9ydCBzdGF0ZWZ1 bCBESENQPyAgSWYgeW91IGdldCB0aGlzIG9wdGlvbiB3aGVuIGRvaW5nCiAgc3RhdGVmdWwgYWxv bmcgd2l0aCBhIGxlYXNlIHRpbWUsIHdoYXQgc2hvdWxkIHlvdSBkbz8gIElmIHRoaXMgdGltZQog IGlzIGRpZmZlcmVudCB0aGFuIHRoZSBsZWFzZSB0aW1lLCBob3cgZG9lcyBhIERIQ1AgY2xpZW50 IGhhbmRsZSBpdC4KClRoZXNlIHF1ZXN0aW9ucyB3aWxsIGJlIHRha2VuIHRvIHRoZSBXRyBtYWls aW5nIGxpc3QuCgpUaGUgV0cgbWVldGluZyBjb25zZW5zdXMgd2FzIHRvIGFjY2VwdCB0aGlzIGRy YWZ0IGFzIHRoZSBzb2x1dGlvbgpjaG9zZW4gYnkgdGhlIFdHIHRvIG1lZXQgdGhlIHJlcXVpcmVt ZW50cyBkZWZpbmVkIGluCmRyYWZ0LWlldGYtZGhjLXN0YXRlbGVzcy1kaGNwdjYtcmVudW1iZXJp bmcuICBUaGUgYXV0aG9yIHdpbGwgcHVibGlzaAphIHJldmlzaW9uIGJhc2VkIG9uIGNvbW1lbnRz IGZyb20gdGhlIG1lZXRpbmcgYW5kIHRoZSBXRyBtYWlsaW5nIGxpc3QKYmVmb3JlIGNvbnNpZGVy YXRpb24gZm9yIFdHIGxhc3QgY2FsbC4KCkRIQ1AgT3B0aW9uIGZvciBIb21lIEFnZW50IERpc2Nv dmVyeSBpbiBNSVB2NiA8ZHJhZnQtamFuZy1kaGMtaGFvcHQ+Ci0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpUaGlzIGRy YWZ0IGFkZHJlc3NlcyB0aGUgTUlQdjYgYm9vdHN0cmFwcGluZyBwcm9ibGVtIC0gaG93IGRvZXMg YQptb2JpbGUgbm9kZSBsZWFybiB0aGUgYWRkcmVzcyBvZiBpdHMgaG9tZSBhZ2VudD8KClRoZSBX RyBzdWdnZXN0ZWQgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIHNwZWNpZmljeSB1c2Ugb2YgUkZDIDEw MzUKZW5jb2Rpbmcgd2hlbiBjYXJyeWluZyBhbiBGUUROLgoKVGhlIGNoYWlyIHdpbGwgaGF2ZSBh IGRpc2N1c3Npb24gd2l0aCB0aGUgbWlwNiBjaGFpcnMgdG8gZGV0ZXJtaW5lCndoaWNoIFdHIHNo b3VsZCB0YWtlIG9uIHRoaXMgZHJhZnQuICBJcyB0aGVyZSBpbnRlcmVzdCBpbiAzR1BQMiB0byB1 c2UKdGhpcyBvcHRpb24gYXMgd2VsbD8KCklzc3VlcyBpbiBESENQdjYgYXV0aGVudGljYXRpb24g PGRyYWZ0LWppbm1laS1kaGMtZGhjcHY2LWNsYXJpZnktYXV0aD4KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhl IGF1dGhvciBwcmVzZW50ZWQgYSBzdW1tYXJ5IG9mIHRoZSBkcmFmdCwgd2hpY2ggY2xhcmlmaWVz IGlzc3VlcyBpbgpESENQdjYgYXV0aGVudGljYXRpb24gYmFzZWQgb24gaW1wbG1lbmV0YXRpb24g ZXhwZXJpZW5jZS4gIAoKVGhlIFdHIG1lZXRpbmcgY29uc2Vuc3VzIHdhcyB0byB0YWtlIG9uIHRo aXMgZHJhZnQgYXMgYSBXRyB3b3JrIGl0ZW0sCnRvIGJlIHB1Ymxpc2hlZCBhcyBQUywgdXBkYXRp bmcgUkZDIDMzMTUuICBUaGUgY29udGVudHMgd2lsbCBiZSBtZXJnZWQKd2l0aCBSRkMgMzMxNSBm b3IgRFMuCgpJUHY2IG11bHRpY2FzdCBhZGRyZXNzIGFzc2lnbm1lbnQgd2l0aCBESENQdjYgPGRy YWZ0LWpkdXJhbmQtYXNzaWduLWFkZHItaXB2Ni1tdWx0aWNhc3QtZGhjcHY2PgotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhpcyBkcmFmdCBkZXNjcmliZXMgbXVsdGlj YXN0IGFkZHJlc3MgbWFuYWdlbWVudCB1c2luZyBESENQdjYsCmJlY2F1c2UgdGhlIGF1dGhvciBj b25zaWRlcnMgTUFEQ0FQIChSRkMgMjk3MCksIFNBUCAoUkZDIDI5NzQpLCByYW5kb20KY2hvaWNl LCBHTE9QIGFuZCBaTUFBUCBpbmFkZXF1YXRlLgoKVGhlIGRyYWZ0IGRlc2NyaWJlcyBhIG5ldyBp ZGVudGl0eSBhc3NvY2lhdGlvbiwgSUFfTUEsIHRoYXQgY2FycmllcwptdWx0aWNhc3QgYWRkcmVz c2VzLiAgVGhlIHNjb3BlIG9wdGlvbiBhbGxvd3MgdGhlIHJlcXVlc3QgdG8gc3BlY2lmaWMKc2Nv cGUgZm9yIHRoZSBhc3NpZ25lZCBhZGRyZXNzZXMuCgpTb21lIG1haWxpbmcgbGlzdCBkaXNjdXNz aW9uIGlzc3VlczoKCjEuIFNob3VsZCBpdCBiZSBzcGxpdCBpbnRvIHR3byBkcmFmdHM/CgoyLiBS YW5nZSBmb3IgZ3JvdXAtaWQgdXNlZnVsbG5lc3MuCgozLiBUaW1lcnMgc3BlY2lmaWVkIHdpdGgg YSBuZXcgREhDUHY2IG9wdGlvbj8KCjQuIFNjb3BlIG9wdGlvbiBtYW5kYXRvcnk/Cgo1LiBESENQ djYgaW4gdXNlcnNwYWNlIC0gbm90IGluIGtlcm5lbD8gIFByb2JsZW1zPwoKNi4gSVB2NCBtdWx0 aWNhc3QgYWRkcmVzcyBhc3NpZ25tZW50PyAgU2hvdWxkIHRoaXMgYmUgY29uc2lkZXJlZD8KCjcu IFByZWZpeCBkZWxlZ2F0aW9uIGZvciBJUHY2IG11bHRpY2FzdCBhZGRyZXNzZXM/CgpEYXZlIFRo YWxlciBzdWdnZXN0ZWQgTUFEQ0FQIHByb3ZpZGVzIG11bHRpY2FzdCBhZGRyZXNzIGFzc2lnbm1l bnQsIGlzCnRoZXJlIGEgbmVlZCBmb3IgYSBuZXcgbWVjaGFuaXNtPyAgVGhlIGF1dGhvciByZXNw b25kZWQgdGhhdCBNQURDQVAKZXhpc3RzLCBidXQgcGVvcGxlIGhhdmVuJ3QgYWN0dWFsbHkgZGVw bG95ZWQgaXQuICBUaGFsZXIgYXNrZWQgaWYgdGhhdAppcyBhIHJlYXNvbiB0byB0cnkgdG8gZG8g dGhpcyB3aXRoIERIQ1B2Niwgb3Igc2hvdWxkIE1BRENBUCBiZQpyZXF1aXJlZD8gIERhdmUgYWxz byBhc2tlZCBpZiB3ZSBkbyB0aGlzIHdpdGggREhDUHY2LCB0aGVuIHdoYXQgZG8gd2UKYWJvdXQg SVB2NCBtdWx0aWNhc3Q/CgoKQ2hhaXIgdG8gZGlzY3VzcyB0aGlzIGRyYWZ0IHdpdGggbWJvbmVk IGNoYWlycyB0byBkZXRlcm1pbmUgd2hlcmUgdGhlCmRyYWZ0IHNob3VsZCBiZSByZXZpZXdlZCBh bmQgaG93IHRvIG1vdmUgZm9yd2FyZC4KCkRIQ1B2NCBPcHRzLiBmb3IgQi1jYXN0IGFuZCBNLWNh c3QgQ29udHJvbCBTZXJ2ZXJzIDxkcmFmdC1jaG93ZGh1cnktZGhjLWJjbWN2NC1vcHRpb24+CkRI Q1B2NiBPcHRzLiBmb3IgQi1jYXN0IGFuZCBNLWNhc3QgQ29udHJvbCBTZXJ2ZXJzIDxkcmFmdC1j aG93ZGh1cnktZGhjLWJjbWN2Ni1vcHRpb24+Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t CgpUaGVzZSB0d28gZHJhZnRzIHdlcmUgZGlzY3Vzc2VkIHRvZ2V0aGVyLiAgVGhlIGNoYWlyIHdp bGwgZGlzY3Vzcwp0aGVzZSBkcmFmdHMgd2l0aCB0aGUgSW50ZXJuZXQgQURzIGFuZCB0aGUgM0dQ UDIgbGlhaXNvbiB0byBkZXRlcm1pbmUKaG93IHRvIG1vdmUgdGhlIGRyYWZ0cyBmb3J3YXJkLgoK SVB2NCBhbmQgSVB2NiBEdWFsLVN0YWNrIElzc3VlcyBmb3IgREhDUHY2IDxkcmFmdC1pZXRmLWRo Yy1kdWFsLXN0YWNrPgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpUaGUgV0cgTWVldGluZyBjb25zZW5zdXMgd2Fz IHRvIGNob29zZSBzZXBhcmF0ZSBzZXJ2ZXJzIGFzIHRoZQpzb2x1dGlvbiB0byBkdWFsLXN0YWNr IERIQ1Agc2VydmljZS4gIERpc2N1c3Npb24gb2Ygb3RoZXIgcXVlc3Rpb25zCndpbGwgbW92ZSB0 byB0aGUgV0cgbWFpbGluZyBsaXN0LgoKPC94bXA+Cg== --=====================_54347367==_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --=====================_54347367==_-- From dhcwg-bounces@ietf.org Thu Sep 2 09:11:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01069; Thu, 2 Sep 2004 09:11:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2rFw-0008Vb-KC; Thu, 02 Sep 2004 09:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2rBC-0005pd-EW for dhcwg@megatron.ietf.org; Thu, 02 Sep 2004 08:59:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00134 for ; Thu, 2 Sep 2004 08:59:05 -0400 (EDT) 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.33) id 1C2rDa-0001CR-93 for dhcwg@ietf.org; Thu, 02 Sep 2004 09:01:35 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2004 06:06:46 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i82CwN2r006723; Thu, 2 Sep 2004 05:58:31 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-79.cisco.com [10.86.242.79]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALG63924; Thu, 2 Sep 2004 08:46:24 -0400 (EDT) From: "Bernie Volz" To: =?iso-8859-1?B?J0pJTk1FSSBUYXR1eWEgLyCQXy2+J0KNxic=?= Subject: RE: [dhcwg] Re: one more comment about the lifetime option Date: Thu, 2 Sep 2004 08:46:24 -0400 Organization: Cisco Message-ID: <000701c490ea$db453770$6501a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > An authentication=20 > option can be used with Information-request and can have sub-options. That's news to me and I don't see where this is possible based on RFC = 3315. But in any case, its no big deal to specify that the option is = restricted to the message level. - Bernie > -----Original Message----- > From: JINMEI Tatuya / =90_=96=BE=92B=8D=C6 = [mailto:jinmei@isl.rdc.toshiba.co.jp]=20 > Sent: Thursday, September 02, 2004 5:21 AM > To: Bernie Volz > Cc: 'Ted Lemon'; dhcwg@ietf.org > Subject: Re: [dhcwg] Re: one more comment about the lifetime option >=20 >=20 > (forgot to reply to this...) >=20 > I've changed the order of the citation below. >=20 > >>>>> On Tue, 24 Aug 2004 20:55:14 -0400, > >>>>> "Bernie Volz" said: >=20 > >> > We should also restrict the position where the lifetime=20 > option can > >> > appear: it should only be able to appear at the "top level" > >> of option > >> > hierarchy. > >>=20 > >> I think this is a good idea. >=20 > > If it is restricted to a REPLY to an INFORMATION-REQUEST,=20 > there is no=20 > > need for this explicit statement as that's all that is currently=20 > > possible - there are no IA_NA, IA_TA, or IA_PD options for these=20 > > messages. >=20 > I don't think this is really the case. An authentication=20 > option can be used with Information-request and can have sub-options. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center,=20 > Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 2 10:31:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07774; Thu, 2 Sep 2004 10:31:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2sPQ-0004d4-3A; Thu, 02 Sep 2004 10:17:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2sEP-0006vw-LM for dhcwg@megatron.ietf.org; Thu, 02 Sep 2004 10:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04889 for ; Thu, 2 Sep 2004 10:06:28 -0400 (EDT) Received: from marseille.netlab.nec.de ([195.37.70.15] helo=venus.office) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2sGm-0006js-3r for dhcwg@ietf.org; Thu, 02 Sep 2004 10:08:59 -0400 Received: from cadar.office (cadar.office [10.1.1.118]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D1ED816B168 for ; Thu, 2 Sep 2004 16:05:54 +0200 (CEST) From: Cristian Cadar Organization: NEC Europe Ltd. To: dhcwg@ietf.org Date: Thu, 2 Sep 2004 16:07:33 +0200 User-Agent: KMail/1.5.4 References: <20040825151559.GJ5677@sverresborg.uninett.no> <000701c48b65$a23c6000$6401a8c0@amer.cisco.com> <20040827083406.GA26829@login.ecs.soton.ac.uk> In-Reply-To: <20040827083406.GA26829@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409021607.33096.Cristian.Cadar@netlab.nec.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 Interop event - last call 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit More details on event: http://www.dhcpv6.org/events.htm Cristian -- ________________________________________________________ | Cristian Cadar cadar@netlab.nec.de | Network Laboratories Heidelberg NEC Europe Ltd. | Kurfuerstenanlage 36 D 69115 Heidelberg | Tel. (+49) 6221 90511-21 Fax: (+49) 6221 90511-55 | URL: http://www.netlab.nec.de/heidelberg/index.html | ________________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 2 17:32:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13520; Thu, 2 Sep 2004 17:32:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2z0d-0004gl-Ej; Thu, 02 Sep 2004 17:20:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2yun-0002Fw-2e for dhcwg@megatron.ietf.org; Thu, 02 Sep 2004 17:14:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12401 for ; Thu, 2 Sep 2004 17:14:38 -0400 (EDT) Received: from [192.150.250.67] (helo=fuchsia.home) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2yx3-0000ZU-1T for dhcwg@ietf.org; Thu, 02 Sep 2004 17:17:14 -0400 Received: from delta.noi.kre.to (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id i82LDV0v020440; Fri, 3 Sep 2004 04:13:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i82LD7a1011954; Fri, 3 Sep 2004 04:13:11 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) In-Reply-To: References: <20040803033357.GA20506@sverresborg.uninett.no> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> <20040901123029.GI15000@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Sep 2004 04:13:07 +0700 Message-ID: <2221.1094159587@munnari.OZ.AU> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: dhcwg@ietf.org, Stig Venaas , 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Date: Wed, 01 Sep 2004 23:52:32 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: | ...but I don't want to delay this important work due to my pedantic | ego. If others still want to leave those points to other documents, | I'll obey that decision (but at least I want the "lifetime" document | to mention those a bit and to say that those are beyond the scope of | the doc). There's no question of ego here. The document is logically incomplete and meaningless if there's no discussion (either in the document, or in a companion) of what happens when a renewal attempt fails to achieve what was expected. It is all obvious what to do when a "renewal" info request gets back the same data as last time - even perhaps when it gives back that data, and more. It may even be fairly obvious (if not quite as obvious) what to do if there's no reply at all (dead dhcp server, or node moved to a location where there is no server). Dealing with replacement data (conceptually anyway) isn't hard to understand (in some cases it might be hard to implement) - ut dealing with getting an answer with some data missing is quite a different thing - it clearly isn't the same case as not getting an answer at all. Once again, the relevance of this to this doc is just that this doc is incomplete without that extra detail specified somewhere. It is however totally irrelevant what causes the new request to be made - whether it is the expiration of one timer or another, or the detection of some kind of "connected to a different link" signal, or even the (let's hope it is defunct) proposal where the server sent out messages to clients telling them to ignore previous timers and renew now. Because of this, having the specification in a different (referenced, and a normative ref at that) doc is an entirely reasonable thing to do. But moving forward with this "explicitly demand refresh" doc without any indication what should be done if it fails is simply not good enough. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From nv33134@yahoo.com Thu Sep 2 18:33:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19023; Thu, 2 Sep 2004 18:33:14 -0400 (EDT) Date: Thu, 2 Sep 2004 18:33:14 -0400 (EDT) Message-Id: <200409022233.SAA19023@ietf.org> Received: from [218.12.34.234] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1C30BI-0006ng-Mh; Thu, 02 Sep 2004 18:35:52 -0400 From: "Brasil 2004 / Informe Exclusivo" To: MapaAtualizado2004@local.cnri.reston.va.us Subject: Mapa atualizado da "esquerda católica" X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html X-Spam-Score: 30.7 (++++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca

InfoGratuitaProximosLancamentos - LinkToFreeAutomaticTranslator (Castellano, English, Français, Deutsche, Português, etc.)

Brasil 2004: reportagem desenha mapa atualizado da "esquerda católica"

* A "esquerda católica", sua influência visível na esfera sociopolítica, e seu poder subterrâneo através de redes capilares e "vasos comunicantes" no Brasil de hoje, é apresentada num livro-reportagem inédito de 56 páginas, de fácil leitura e ampla documentação.

* "Pastoral da Terra e MST incendeiam o País" é ao mesmo tempo um mapa atualizado e um instrumento informativo indispensável para quem deseja conhecer os possíveis rumos sociopolíticos do Brasil de amanhã.

* O autor, o advogado e pesquisador Gregorio Vivanco Lopes, com mais de 30 anos de especialização no tema das comunidades eclesiais de base e da teologia da libertação, mostra a real dimensão da Pastoral da Terra e do MST, duas pontas de um mesmo e gigantesco iceberg que a mídia nem sempre revela e que a opinião pública ignora.

* A força e o talão de Aquiles da "esquerda católica" descritas num informe objetivo, documentado e sereno que todo brasileiro deve ler, ainda que para discordar e debater de maneira invariavelmente respeitosa, em prol da paz social no Brasil.

* O autor do livreto "Pastoral da Terra e MST incendeiam o País" exerce o legítimo direito de informar, e favorece também o direito de cada brasileiro de ser informado, condições ambas indispensáveis para uma autêntica democracia.

* Solicite gratuitamente, por e-mail, o Índice e a Introdução contendo um resumo da reportagem e a capa da edição impressa:

IntroCapaGratuitas

* Envie seu voto eletrônico e, se possível, sua valiosa opinião a respeito do tema abordado, e receberá informação gratuita sobre próximos lançamentos:

- Lopes:Concordo

- Lopes:EmTermos

- Lopes:Discordo

* Para enviar mensagem ou tomar contato com o autor, clique em:

Lopes:MinhaMensagem (ou ligue para 11-38223241 / 11-38281102

* Caso deseje adquirir a versão impressa (R$ 10,00 correio incluído), clique no link: DesejoAdquirirLivro (receberá as instruções do distribuidor, de exclusiva responsabilidade deste).

* Caso deseje receber, por e-mail, o e-Book com o texto completo da reportagem (R$ 1,99), clique no link:

DesejoAdquirirEBook

* Para ser retirado de nosso Address Book, por favor, clique em:

RetirarImediatamente

 

 

 

 From dhcwg-bounces@ietf.org Fri Sep 3 01:32:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12971; Fri, 3 Sep 2004 01:32:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C36bh-0006GW-1o; Fri, 03 Sep 2004 01:27:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C36Vr-0002Fc-Mr for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 01:21:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12332 for ; Fri, 3 Sep 2004 01:21:26 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C36YN-0004yA-Fu for dhcwg@ietf.org; Fri, 03 Sep 2004 01:24:05 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3G006LP9IPX0@mailout3.samsung.com> for dhcwg@ietf.org; Fri, 03 Sep 2004 14:20:49 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3G004RC9I8VH@mailout3.samsung.com> for dhcwg@ietf.org; Fri, 03 Sep 2004 14:20:32 +0900 (KST) Received: from SUMAN ([107.108.71.141]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3G0085U9I5V6@mmp1.samsung.com> for dhcwg@ietf.org; Fri, 03 Sep 2004 14:20:32 +0900 (KST) Date: Fri, 03 Sep 2004 10:50:09 +0530 From: Suman Subject: [dhcwg] Server Unicast Option in DCHPv6 To: dhcwg@ietf.org Message-id: <000601c49175$b2e5eaf0$8d476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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="===============0902264325==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0902264325== Content-type: multipart/alternative; boundary="Boundary_(ID_35gpyzjZTtyySFeg0kAe+Q)" This is a multi-part message in MIME format. --Boundary_(ID_35gpyzjZTtyySFeg0kAe+Q) Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Hi, I need some clarification on the Server Unicast Option, in DHCPv6, RFC 3315. In particular, when the client receives a Server Unicast option in an advertise message and it has to send a request message to that server, it unicasts the message to the server. That apart, should the client include Server Unicast Option in the Request message that it sends? Also, all the subsequent transaction between the client and that server has to be unicast, if I have got it right! Does the client need to include this option in all the subsequent message exchanges, Request message in particular? Any insight into this would be greatly appreciated. Regards, Suman. --Boundary_(ID_35gpyzjZTtyySFeg0kAe+Q) Content-type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7BIT

Hi,

 

      I need some clarification on the Server Unicast Option, in DHCPv6, RFC 3315.

 

In particular, when the client receives a Server Unicast option in an advertise message and it has to send a request message to that server, it unicasts the message to the server. That apart, should the client include Server Unicast Option in the Request message that it sends?

 

Also, all the subsequent transaction between the client and that server has to be unicast, if I have got it right! Does the client need to include this option in all the subsequent message exchanges, Request message in particular?

 

Any insight into this would be greatly appreciated.

 

Regards,

Suman.

 

 

--Boundary_(ID_35gpyzjZTtyySFeg0kAe+Q)-- --===============0902264325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0902264325==-- From dhcwg-bounces@ietf.org Fri Sep 3 02:50:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02118; Fri, 3 Sep 2004 02:50:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C37pi-0004wi-N9; Fri, 03 Sep 2004 02:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C37fD-0000yh-Qz for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 02:35:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00904 for ; Fri, 3 Sep 2004 02:35:10 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C37hl-00021s-1o for dhcwg@ietf.org; Fri, 03 Sep 2004 02:37:50 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:7036:3eab:f2f4:3846]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0B5C81525D; Fri, 3 Sep 2004 15:35:09 +0900 (JST) Date: Fri, 03 Sep 2004 15:35:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz" Subject: Re: [dhcwg] Re: one more comment about the lifetime option In-Reply-To: <000701c490ea$db453770$6501a8c0@amer.cisco.com> References: <000701c490ea$db453770$6501a8c0@amer.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Thu, 2 Sep 2004 08:46:24 -0400, >>>>> "Bernie Volz" said: >> An authentication >> option can be used with Information-request and can have sub-options. > That's news to me and I don't see where this is possible based on RFC 3315. Ah, okay, I was wrong. The authentication option is a variable-length option but does not take a sub-option according to RFC3315. > But in any case, its no big deal to specify that the option is restricted to > the message level. That's correct. But at the same time, I believe we all agree that there is no reason to allow the lifetime (or refresh timer) option appearing as a sub-option. We can prefer the former logic for the reason not to specify this point in the document. We can also prefer the latter logic for the reason to specify this point in the document. I believe this is a matter of taste, and I myself can live with either approach. So, I'd leave the decision to the document author. 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 Fri Sep 3 04:12:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06417; Fri, 3 Sep 2004 04:12:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C397J-0001iG-7d; Fri, 03 Sep 2004 04:08:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C38wR-0005aH-Vs for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 03:57:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05508 for ; Fri, 3 Sep 2004 03:57:02 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C38yz-0008Fi-KG for dhcwg@ietf.org; Fri, 03 Sep 2004 03:59:43 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i837uLOK025822; Fri, 3 Sep 2004 09:56:21 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i837uHO8022058; Fri, 3 Sep 2004 09:56:17 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 3 Sep 2004 09:56:17 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] Re: one more comment about the lifetime option Message-ID: <20040903075617.GA22032@sverresborg.uninett.no> References: <000701c490ea$db453770$6501a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dhcwg@ietf.org, Bernie Volz , "'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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Fri, Sep 03, 2004 at 03:35:10PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Thu, 2 Sep 2004 08:46:24 -0400, > >>>>> "Bernie Volz" said: > > >> An authentication > >> option can be used with Information-request and can have sub-options. > > > That's news to me and I don't see where this is possible based on RFC 3315. > > Ah, okay, I was wrong. The authentication option is a variable-length > option but does not take a sub-option according to RFC3315. > > > But in any case, its no big deal to specify that the option is restricted to > > the message level. > > That's correct. But at the same time, I believe we all agree that > there is no reason to allow the lifetime (or refresh timer) option > appearing as a sub-option. Yes, I don't mind adding some wording to the fact. It's against the whole idea to use it as a sub-option. I must say though that I'm a little bit surprised this came up. I'm not that into the world of DHCP, but I don't recall seeing specs for other options saying this, and I had thought that they should only be used as sub-options if specified as such. Or is the idea that in general, any option could be used as a sub-option? I think though that the IRT (lifetime) option might appear to make sense as a sub-option, while many other options pretty obviously don't make sense. So I'm happy to add the wording, just to avoid possible misuse. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Sep 3 05:17:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09668; Fri, 3 Sep 2004 05:17:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C39ro-0002ci-Bb; Fri, 03 Sep 2004 04:56:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C39XX-0004id-II for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 04:35:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07491 for ; Fri, 3 Sep 2004 04:35:21 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C39a5-0002pg-TD for dhcwg@ietf.org; Fri, 03 Sep 2004 04:38:02 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i838YoOK005520; Fri, 3 Sep 2004 10:34:50 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i838YoQR022124; Fri, 3 Sep 2004 10:34:50 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Fri, 3 Sep 2004 10:34:50 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040903083450.GA22060@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> <20040901123029.GI15000@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Wed, Sep 01, 2004 at 11:52:32PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Wed, 1 Sep 2004 14:30:29 +0200, > >>>>> Stig Venaas said: > > > What you write sounds reasonable, but I'm still not sure we should go > > into the details. The reason is that we don't know in general what > > the behaviour should be, and it's a generic issue. It's obviously a > > related issue though. We could as Ted suggests, specify this later > > when we have more information. That could either be as an update to > > the lifetime RFC, or IMO perhaps better, add some text if an update > > to RFC 3315 is done. There seems to be other reasons to update RFC > > 3315 too (draft-jinmei-dhc-dhcpv6-clarify-auth-00?). > > I would first like to note that the suggestion by Ted of leaving it to > a later document was followed by his response to me where he agreed > (or at least seemed to agree) with my proposal. Yes > Secondly, if I understand the sense in this list correctly, I believe > my proposal reflects some level of consensus here. Yes, my impression too. Note that I'm saying that I don't think we should go into details, I think it's reasonable to write something. I just think that this document isn't the right place to solve that issue. Also, since the issue is present when not implementing this draft, I believe it's good to specify some text in a place where it will be read by those not implementing this option. > Third, I personally think we can reflect the proposal without making > the document unnecessarily long. (If you want, I'll try to contribute > to some text.) > > So, I personally think it makes sense to clarify the points at this > chance even though the points can be extended to general issues. Yes, so I would suggest adding some text, see suggestion below, that raises the issue and gives some general recommendation, without being too strict (no MUSTs). > ...but I don't want to delay this important work due to my pedantic > ego. If others still want to leave those points to other documents, > I'll obey that decision (but at least I want the "lifetime" document > to mention those a bit and to say that those are beyond the scope of > the doc). The latter part I agree with. I really welcome your comments, I don't always agree with them, but you have raised many interesting issues, and helped improve the draft. > > In general I agree with your distinction between still and moving > > clients. What worries me though, is that it might not be possible for > > a client to distinguish between movement and renumbering. The fact > > that a new prefix is announced in RAs is not sufficient. > > As I said in my previous message, I basically think we can concentrate > on the "still" clients in this document, and do not have to worry > too much about miscellaneous subtle cases of moving vs > not-actually-moving. Movement detection is itself a difficult > challenge (we even have a dedicated wg on this!), so I think it is > enough in the scope of dhc wg to show some preliminary considerations > on the moving clients (e.g., as shown in Section 18.1.2 of RFC3315.). Right. [Deleted some text below that I agree with] So how about something like this: When a client receives a Reply to an Information-Request that contains configuration information (i.e., does not contain a Status Code option), it SHOULD install that new configuration information after removing any previously received configuration information. There may be reasons not to always do this. One example might be when client has indication that it has moved to a new link. How a client copes with movement is outside the scope of this document. I'm not not sure if it should be "SHOULD" or "should" there. At least I don't see this as part of the protocol. In my opinion the idea is just to give a general recommendation or some guidance to implementors. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Sep 3 06:10:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14092; Fri, 3 Sep 2004 06:10:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Atb-0002jp-SC; Fri, 03 Sep 2004 06:02:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3AVf-0002Nx-0w for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 05:37:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10904; Fri, 3 Sep 2004 05:37:28 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3AYD-0007PO-5K; Fri, 03 Sep 2004 05:40:10 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3G0060TLD5P3@mailout3.samsung.com>; Fri, 03 Sep 2004 18:36:41 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3G00JF7LD5M3@mailout3.samsung.com>; Fri, 03 Sep 2004 18:36:41 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3G003GOLD428@mmp2.samsung.com>; Fri, 03 Sep 2004 18:36:41 +0900 (KST) Date: Fri, 03 Sep 2004 18:37:53 +0900 From: "S. Daniel Park" Subject: RE: [dhcwg] Minutes from IETF 60 dhc WG meeting In-reply-to: <4.3.2.7.2.20040902082231.0200cbe8@flask.cisco.com> To: Ralph Droms , proceedings@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7BIT 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT One typo for me.. >The chair announced that Samung has published a zero-cost licensing >IPR claim on draft-ietf-dhc-rapid-commit-opt-05.txt. There was no >objection in the WG to moving the draft draft forward. s/Samung/Samsung Thanks - Daniel (Soohong Daniel Park) - Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Sep 3 07:48:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21163; Fri, 3 Sep 2004 07:48:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3CWJ-00051y-Nh; Fri, 03 Sep 2004 07:46:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3CVB-0004gU-Gt for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 07:45:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20994 for ; Fri, 3 Sep 2004 07:45:08 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3CXm-0000Di-JN for dhcwg@ietf.org; Fri, 03 Sep 2004 07:47:50 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 03 Sep 2004 07:44:40 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i83BiZ6r010633; Fri, 3 Sep 2004 07:44:37 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-212.cisco.com [10.86.242.212]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALH42614; Fri, 3 Sep 2004 07:44:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20040903074356.01f618f8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 03 Sep 2004 07:44:32 -0400 To: "S. Daniel Park" From: Ralph Droms Subject: RE: [dhcwg] Minutes from IETF 60 dhc WG meeting In-Reply-To: References: <4.3.2.7.2.20040902082231.0200cbe8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Good catch. Thanks... I just sent off revised minutes with several typo corrections. - Ralph At 06:37 PM 9/3/2004 +0900, S. Daniel Park wrote: >One typo for me.. > > >The chair announced that Samung has published a zero-cost licensing > >IPR claim on draft-ietf-dhc-rapid-commit-opt-05.txt. There was no > >objection in the WG to moving the draft draft forward. > > >s/Samung/Samsung > > >Thanks > > >- Daniel (Soohong Daniel Park) >- Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Sep 3 23:45:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05974; Fri, 3 Sep 2004 23:45:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3RJd-000824-BS; Fri, 03 Sep 2004 23:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3RJ8-0007qp-S8 for dhcwg@megatron.ietf.org; Fri, 03 Sep 2004 23:33:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05417 for ; Fri, 3 Sep 2004 23:33:39 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3RLq-0007rs-UG for dhcwg@ietf.org; Fri, 03 Sep 2004 23:36:32 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:545c:249b:d371:bb2c]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4CEAA15263; Sat, 4 Sep 2004 12:33:35 +0900 (JST) Date: Sat, 04 Sep 2004 12:33:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) In-Reply-To: <20040903083450.GA22060@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> <20040901123029.GI15000@sverresborg.uninett.no> <20040903083450.GA22060@sverresborg.uninett.no> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Fri, 3 Sep 2004 10:34:50 +0200, >>>>> Stig Venaas said: > So how about something like this: > When a client receives a Reply to an Information-Request that > contains configuration information (i.e., does not contain a > Status Code option), it SHOULD install that new configuration > information after removing any previously received configuration > information. There may be reasons not to always do this. One > example might be when client has indication that it has moved to > a new link. How a client copes with movement is outside the scope > of this document. > I'm not not sure if it should be "SHOULD" or "should" there. At > least I don't see this as part of the protocol. In my opinion > the idea is just to give a general recommendation or some guidance > to implementors. The proposed text basically looks fine. But I'd be a bit more specific that the above description means if the new configuration information does not have any update on a particular instance of the old information (e.g., DNS server list) the client will simply remove the old information. As for "SHOULD" vs "should", I don't have a strong opinion. If you prefer "should", please just go for it. 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 Sat Sep 4 02:26:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27832; Sat, 4 Sep 2004 02:26:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3Txu-0007O8-Pn; Sat, 04 Sep 2004 02:23:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3TuY-0005lm-Dw for dhcwg@megatron.ietf.org; Sat, 04 Sep 2004 02:20:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27354 for ; Sat, 4 Sep 2004 02:20:29 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3TxI-0002S9-2j for dhcwg@ietf.org; Sat, 04 Sep 2004 02:23:21 -0400 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:545c:249b:d371:bb2c]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7F7291525D; Sat, 4 Sep 2004 15:20:26 +0900 (JST) Date: Sat, 04 Sep 2004 15:20:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Stig Venaas Subject: Re: [dhcwg] Re: one more comment about the lifetime option In-Reply-To: <20040903075617.GA22032@sverresborg.uninett.no> References: <000701c490ea$db453770$6501a8c0@amer.cisco.com> <20040903075617.GA22032@sverresborg.uninett.no> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: dhcwg@ietf.org, Bernie Volz , "'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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Fri, 3 Sep 2004 09:56:17 +0200, >>>>> Stig Venaas said: >> Ah, okay, I was wrong. The authentication option is a variable-length >> option but does not take a sub-option according to RFC3315. >> >> > But in any case, its no big deal to specify that the option is restricted to >> > the message level. >> >> That's correct. But at the same time, I believe we all agree that >> there is no reason to allow the lifetime (or refresh timer) option >> appearing as a sub-option. > Yes, I don't mind adding some wording to the fact. It's against the > whole idea to use it as a sub-option. > I must say though that I'm a little bit surprised this came up. I'm > not that into the world of DHCP, but I don't recall seeing specs for > other options saying this, and I had thought that they should only > be used as sub-options if specified as such. Or is the idea that in > general, any option could be used as a sub-option? I think your understanding is basically correct. RFC3315 says in Section 22 that: Unless otherwise noted, each option may appear only in the options area of a DHCP message and may appear only once. The term "options area" does not seem to be officially defined in the RFC, but it should be natural to interpret this to mean areas which are not a sub-option of a separate option. But at the same time, the RFC explicitly mentions the default restriction in some places. For example, in Section 22.5 it says: An IA_TA option may only appear in the options area of a DHCP message. And, > I think though that the IRT (lifetime) option might appear to make > sense as a sub-option, while many other options pretty obviously > don't make sense. So I'm happy to add the wording, just to avoid > possible misuse. this is exactly my point. I believe it depends on whether we want to avoid possible misuse explicitly. And then it depends on how we asses the possibility of the misuse. Of course, the sense on this may vary among people (so I won't push my preference). But if we recall that we are talking about this in the context where we are trying to add a note that a single IRT (or lifetime) optin should be common for all possible information resources, I personally think it's reasonable to add an explicit note here. 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 Sat Sep 4 16:38:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06069; Sat, 4 Sep 2004 16:38:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3hGb-0006fx-Bs; Sat, 04 Sep 2004 16:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C3hCr-0006L9-2Q for dhcwg@megatron.ietf.org; Sat, 04 Sep 2004 16:32:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05800 for ; Sat, 4 Sep 2004 16:32:14 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C3hFj-00085W-TW for dhcwg@ietf.org; Sat, 04 Sep 2004 16:35:16 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 04 Sep 2004 13:31:49 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i84KVg8J000480; Sat, 4 Sep 2004 13:31:43 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-171.cisco.com [10.86.242.171]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALI20371; Sat, 4 Sep 2004 16:31:41 -0400 (EDT) From: "Bernie Volz" To: "'Suman'" , Subject: RE: [dhcwg] Server Unicast Option in DCHPv6 Date: Sat, 4 Sep 2004 16:31:43 -0400 Organization: Cisco Message-ID: <000c01c492be$31311bc0$6501a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <000601c49175$b2e5eaf0$8d476c6b@sisodomain.com> x-mimeole: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable The unicast option is only server to client; not client to server. So, = no the client does not send the option. There is no hard requirement for a client to use unicast. From the = option description in RFC 3315: The server specifies the IPv6 address to which the client is to send unicast messages in the server-address field. When a client receives this option, where permissible and appropriate, the client sends ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ messages directly to the server using the IPv6 address specified in the server-address field of the option. When the server sends a Unicast option to the client, some messages from the client will not be relayed by Relay Agents, and will not include Relay Agent options from the Relay Agents. Therefore, a server should only send a Unicast option to a client when Relay Agents are not sending Relay Agent options. A DHCP server rejects any messages sent inappropriately using unicast to ensure that messages are relayed by Relay Agents when Relay Agent options are in use. Details about when the client may send messages to the server using unicast are in section 18. -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Suman Sent: Friday, September 03, 2004 1:20 AM To: dhcwg@ietf.org Subject: [dhcwg] Server Unicast Option in DCHPv6 Hi, =20 I need some clarification on the Server Unicast Option, in DHCPv6, = RFC 3315.=20 =20 In particular, when the client receives a Server Unicast option in an advertise message and it has to send a request message to that server, = it unicasts the message to the server. That apart, should the client = include Server Unicast Option in the Request message that it sends?=20 =20 Also, all the subsequent transaction between the client and that server = has to be unicast, if I have got it right! Does the client need to include = this option in all the subsequent message exchanges, Request message in particular? =20 Any insight into this would be greatly appreciated.=20 =20 Regards, Suman. =20 =20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 6 04:49:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14916; Mon, 6 Sep 2004 04:49:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4F9q-0001bS-DB; Mon, 06 Sep 2004 04:47:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4F6g-0000qm-Mu for dhcwg@megatron.ietf.org; Mon, 06 Sep 2004 04:44:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14665 for ; Mon, 6 Sep 2004 04:44:08 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4F9p-00022g-Mj for dhcwg@ietf.org; Mon, 06 Sep 2004 04:47:29 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i868hVOK025607; Mon, 6 Sep 2004 10:43:32 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i868hRVT008421; Mon, 6 Sep 2004 10:43:27 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Mon, 6 Sep 2004 10:43:27 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040906084327.GA8343@sverresborg.uninett.no> References: <20040803033357.GA20506@sverresborg.uninett.no> <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> <20040901123029.GI15000@sverresborg.uninett.no> <20040903083450.GA22060@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Sat, Sep 04, 2004 at 12:33:37PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> On Fri, 3 Sep 2004 10:34:50 +0200, > >>>>> Stig Venaas said: > > > So how about something like this: > > > When a client receives a Reply to an Information-Request that > > contains configuration information (i.e., does not contain a > > Status Code option), it SHOULD install that new configuration > > information after removing any previously received configuration > > information. There may be reasons not to always do this. One > > example might be when client has indication that it has moved to > > a new link. How a client copes with movement is outside the scope > > of this document. > > > I'm not not sure if it should be "SHOULD" or "should" there. At > > least I don't see this as part of the protocol. In my opinion > > the idea is just to give a general recommendation or some guidance > > to implementors. > > The proposed text basically looks fine. But I'd be a bit more > specific that the above description means if the new configuration > information does not have any update on a particular instance of the > old information (e.g., DNS server list) the client will simply remove > the old information. Note that I say "after removing any previously received configuration information". To me at least, that says that ALL the previously received data is removed when receiving new information. It doesn't in any way say that this is on a per option basis. E.g. if you previously received options A, B and C, and you in the new message receive only a new option D, then you should still remove previous information (A, B and C). But, if you still think this is not clear, I will try to improve it. If it's not clear to you, then it may not be clear to others either. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 7 05:08:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02859; Tue, 7 Sep 2004 05:08:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4bvg-0003LP-PA; Tue, 07 Sep 2004 05:06:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4brb-0002Vr-PX for dhcwg@megatron.ietf.org; Tue, 07 Sep 2004 05:02:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02263 for ; Tue, 7 Sep 2004 05:02:05 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4bv0-00081B-UU for dhcwg@ietf.org; Tue, 07 Sep 2004 05:05:39 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i8790VOK010237; Tue, 7 Sep 2004 11:00:31 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i8790TU2018175; Tue, 7 Sep 2004 11:00:29 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 7 Sep 2004 11:00:29 +0200 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040907090029.GB17934@sverresborg.uninett.no> References: <6C20AA0D-F5DF-11D8-8541-000A95D9C74C@nominum.com> <20040901123029.GI15000@sverresborg.uninett.no> <20040903083450.GA22060@sverresborg.uninett.no> <20040906084327.GA8343@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040906084327.GA8343@sverresborg.uninett.no> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Sep 06, 2004 at 10:43:27AM +0200, Stig Venaas wrote: > On Sat, Sep 04, 2004 at 12:33:37PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > > >>>>> On Fri, 3 Sep 2004 10:34:50 +0200, > > >>>>> Stig Venaas said: > > > > > So how about something like this: > > > > > When a client receives a Reply to an Information-Request that > > > contains configuration information (i.e., does not contain a > > > Status Code option), it SHOULD install that new configuration > > > information after removing any previously received configuration > > > information. There may be reasons not to always do this. One > > > example might be when client has indication that it has moved to > > > a new link. How a client copes with movement is outside the scope > > > of this document. > > > > > I'm not not sure if it should be "SHOULD" or "should" there. At > > > least I don't see this as part of the protocol. In my opinion > > > the idea is just to give a general recommendation or some guidance > > > to implementors. > > > > The proposed text basically looks fine. But I'd be a bit more > > specific that the above description means if the new configuration > > information does not have any update on a particular instance of the > > old information (e.g., DNS server list) the client will simply remove > > the old information. Since I felt the need to explain further what I meant, I should put something in the draft too. I've now changed it to this: When a client receives a Reply to an Information-Request that contains configuration information (i.e., does not contain a Status Code option), it should install that new configuration information after removing any previously received configuration information. Note that it should also remove information that is missing from the new information set, e.g. an option might be left out or contain only a subset of what it did previously. There may be reasons not to always do this. One example might be when client has indication that it has moved to a new link. How a client copes with movement is outside the scope of this document. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 7 09:25:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20676; Tue, 7 Sep 2004 09:25:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4fos-0006OJ-KZ; Tue, 07 Sep 2004 09:15:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4fhx-00055d-33 for dhcwg@megatron.ietf.org; Tue, 07 Sep 2004 09:08:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19414 for ; Tue, 7 Sep 2004 09:08:23 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4flN-0003kM-M6 for dhcwg@ietf.org; Tue, 07 Sep 2004 09:11:58 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i87D82gm014119; Tue, 7 Sep 2004 08:08:13 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i87D80101458; Tue, 7 Sep 2004 09:08:00 -0400 (EDT) From: Joe Quanaim To: JINMEI Tatuya / =?utf-8?q?=E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89=09?=, Stig Venaas Subject: Re: [dhcwg] Re: one more comment about the lifetime option Date: Tue, 7 Sep 2004 09:07:59 -0400 User-Agent: KMail/1.5.4 References: <20040903075617.GA22032@sverresborg.uninett.no> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200409070907.59505.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Bernie Volz , "'Ted Lemon'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > > I think though that the IRT (lifetime) option might appear to make > > sense as a sub-option, while many other options pretty obviously > > don't make sense. So I'm happy to add the wording, just to avoid > > possible misuse. > > this is exactly my point. > > I believe it depends on whether we want to avoid possible misuse > explicitly. And then it depends on how we asses the possibility of > the misuse. Of course, the sense on this may vary among people (so I > won't push my preference). But if we recall that we are talking > about this in the context where we are trying to add a note that a > single IRT (or lifetime) optin should be common for all possible > information resources, I personally think it's reasonable to add an > explicit note here. I also think it is worthwhile to add text limiting this option's position t= o=20 the message options. Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 7 09:29:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20972; Tue, 7 Sep 2004 09:29:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4fov-0006PL-FL; Tue, 07 Sep 2004 09:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4flz-0005ak-Ef for dhcwg@megatron.ietf.org; Tue, 07 Sep 2004 09:12:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19684 for ; Tue, 7 Sep 2004 09:12:33 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4fpR-0003ml-2i for dhcwg@ietf.org; Tue, 07 Sep 2004 09:16:09 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i87DCGNh021602; Tue, 7 Sep 2004 08:12:23 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i87DCD102925; Tue, 7 Sep 2004 09:12:13 -0400 (EDT) From: Joe Quanaim To: Stig Venaas , "JINMEI Tatuya / ?$B?@L@C#:H" Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Date: Tue, 7 Sep 2004 09:12:13 -0400 User-Agent: KMail/1.5.4 References: <20040906084327.GA8343@sverresborg.uninett.no> <20040907090029.GB17934@sverresborg.uninett.no> In-Reply-To: <20040907090029.GB17934@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409070912.13081.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, Ted Lemon X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > When a client receives a Reply to an Information-Request that > contains configuration information (i.e., does not contain a > Status Code option), it should install that new configuration > information after removing any previously received configuration > information. Note that it should also remove information that > is missing from the new information set, e.g. an option might be > left out or contain only a subset of what it did previously. > There may be reasons not to always do this. One example might > be when client has indication that it has moved to a new link. > How a client copes with movement is outside the scope of this > document. Should "does not contain a Status Code option" be replaced with "does not contain a negative Status Code option"? A status code of 0 should be acceptable. Otherwise, this text looks good. Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 7 16:17:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27758; Tue, 7 Sep 2004 16:17:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4mAN-0004a4-HA; Tue, 07 Sep 2004 16:02:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4m4y-0001MQ-I4; Tue, 07 Sep 2004 15:56:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26087; Tue, 7 Sep 2004 15:56:34 -0400 (EDT) Message-Id: <200409071956.PAA26087@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 07 Sep 2004 15:56:33 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subscriber-id-07.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: , Sender: dhcwg-bounces@ietf.org 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 : DHCP Subscriber ID Suboption for the DHCP Relay Agent Option Author(s) : R. Johnson, et al. Filename : draft-ietf-dhc-subscriber-id-07.txt Pages : 10 Date : 2004-9-7 This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable 'Subscriber-ID' with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-07.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-subscriber-id-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-subscriber-id-07.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: <2004-9-7152019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subscriber-id-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subscriber-id-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-7152019.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Tue Sep 7 17:40:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09441; Tue, 7 Sep 2004 17:40:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4nP8-0003zh-EU; Tue, 07 Sep 2004 17:21:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4mqG-0001JF-9w for dhcwg@megatron.ietf.org; Tue, 07 Sep 2004 16:45:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02987 for ; Tue, 7 Sep 2004 16:45:25 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4mtl-0006mB-GY for dhcwg@ietf.org; Tue, 07 Sep 2004 16:49:06 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 07 Sep 2004 13:44:53 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i87Kib6l003692; Tue, 7 Sep 2004 13:44:38 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALJ34976; Tue, 7 Sep 2004 16:44:36 -0400 (EDT) From: "Bernie Volz" To: , "'Ted Lemon'" Subject: RE: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt - NEED INPUT BEFORE REVISING DRAFT! Date: Tue, 7 Sep 2004 16:44:36 -0400 Organization: Cisco Message-ID: <002301c4951b$7d08c980$efa0560a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 x-mimeole: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: <005001c483e9$cd040d70$d0412ca1@amer.cisco.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi again: Before I revise the draft, please let me know if you think it is worth doing. The choices are: 1. Allow only the simple case for now (ie, Client FQDN option in an = IA_NA or IA_TA options field applies to all addresses in the IA). We can always = add the complex case (using a bit) in the future. 2. Allow both the simple and more complex case (latter is as currently documented); we'd use a bit in the flags field to indicate whether the client supports the complex method and wants to use (server can support = it or not). Default (bit not set) is simple-only. 3. Come up with a completely different approach the problem (ideas?). 4. Abandon this work (if there's no interest in it). - Bernie Volz > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Bernie Volz > Sent: Monday, August 16, 2004 7:36 PM > To: 'Ted Lemon' > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt >=20 >=20 > Ted: >=20 > Thanks for your feedback on this issue. >=20 > Others, please chime in with your thoughts/opinions. >=20 > One possibility is to allow both. >=20 > The simple case just has the client FQDN option in the=20 > IA_*-options field for both the client and server and one=20 > name applies to all of the address. >=20 > The complex case (if the server determines that a unique name=20 > is required for each address) it can use the alternate form -=20 > putting the client FQDN option into the IAaddr-options field=20 > (as currently specified). >=20 > Since it requires client (and server) support for the complex=20 > case, we can use a "flag" bit to allow the client to specify=20 > whether it can support the complex case. By default (if the=20 > bit is 0), the client (and server) can only use the simple=20 > case. If the bit is set, it is up to the server to determine=20 > whether to use the simple or complex case, based on the=20 > addresses and the configuration. >=20 > - Bernie >=20 > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > On Behalf Of Ted Lemon > > Sent: Monday, August 16, 2004 2:39 PM > > To: Bernie Volz > > Cc: dhcwg@ietf.org > > Subject: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt > >=20 > >=20 > > Bernie, the problem I have with the complex model for the=20 > DHCPv6 FQDN > > option is that I can't imagine any of the scenarios you=20 > describe ever=20 > > having a meaning in practice. A computer is a computer. =20 > It has a=20 > > name. One name. If you give it multiple names, that=20 > doesn't have=20 > > any meaning, generally speaking. The exception is when you are=20 > > configuring a single computer to present more than one=20 > > identity on the=20 > > network. In this case, it makes sense that each identity=20 > would have=20 > > its own name. > >=20 > > So I think it makes sense to have a one-to-one mapping=20 > between names=20 > > and identity associations. I do not think it makes sense to=20 > > break it=20 > > down below this point. Let's consider some of the=20 > scenarios you've=20 > > proposed. First, let's consider number four, which you say you=20 > > consider most likely. > >=20 > > In this case, the client has a single identity, and gets both a=20 > > globally-scoped address and a locally-scoped address. So=20 > > what does it=20 > > make sense to do here? We have several options: > >=20 > > 1. Publish the name with the global address. > > 2. Publish the name with both the global and site-local > > address. 3. Publish two names, one for the global address and=20 > > one for the local=20 > > address. > >=20 > > So what's going to fail in case 1? Let's say some clients get=20 > > site-local addresses, and some get global _and_ site-local=20 > > addresses. =20 > > If we only publish the global address, can a client with only a > > site-local address exchange packets with the client with the global=20 > > address? I think it can, as long as they are both at the=20 > same site=20 > > (which is the only case that matters). So I think that this=20 > > solution=20 > > works, and we don't need to do anything further. > >=20 > > What fails in case 2? We've published a site-local address in a=20 > > global namespace. If a host outside of the site wants to=20 > > contact the > > host using the name, how does it know that the site-local=20 > address is=20 > > not local? It doesn't. We can't control which address=20 > it tries to=20 > > connect to, and many network clients do not try to connect to every=20 > > address - they just try to connect to the first one, which DNS is=20 > > required to alternate. So what we would get, from the=20 > > perspective of=20 > > a naive user, would be intermittent failures. Not good. > >=20 > > What about case 3? Case 3 works, but now you have to tell people=20 > > about two different names. Why would you want that, when one name=20 > > will do? So I really think that case 1 is how you want to=20 > > do things, > > and this is easy and matches the one name per IAID model=20 > very nicely. > >=20 > > As far as whether temporary and public addresses are part=20 > of the same > > IA or not, why not let it be that if you want for some reason to=20 > > publish your temporary address, the way you do it is under=20 > a separate=20 > > IAID? Why add complexity when there's a way to do it that's less=20 > > complex? > >=20 > > If a site is multihomed and wants to use different names for > > different=20 > > addresses, I'm skeptical that it's something we need to think about=20 > > here and now. While it's true that this is a possible scenario, I=20 > > think the complexity that addressing this problem adds to=20 > the current=20 > > draft is unacceptable. I would like to see this problem actually=20 > > happen in the real world, and have that drive a new standardization=20 > > effort, rather than trying to guess how people are going to want to=20 > > solve this problem when we've never seen it happen in the=20 > real world,=20 > > and really don't have a basis for talking about what need we're=20 > > addressing. > >=20 > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 7 18:31:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14318; Tue, 7 Sep 2004 18:31:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4oBq-0007fX-JS; Tue, 07 Sep 2004 18:11:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C4ny2-00077Z-W2 for dhcwg@megatron.ietf.org; Tue, 07 Sep 2004 17:57:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11155 for ; Tue, 7 Sep 2004 17:57:31 -0400 (EDT) Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C4o1Y-0000wN-7D for dhcwg@ietf.org; Tue, 07 Sep 2004 18:01:13 -0400 Received: from [10.0.2.3] (neubayern.net [66.93.162.100]) by toccata.fugue.com (Postfix) with ESMTP id 661931B2402; Tue, 7 Sep 2004 16:54:46 -0500 (CDT) In-Reply-To: <002301c4951b$7d08c980$efa0560a@amer.cisco.com> References: <002301c4951b$7d08c980$efa0560a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt - NEED INPUT BEFORE REVISING DRAFT! Date: Tue, 7 Sep 2004 14:57:28 -0700 To: "Bernie Volz" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Sep 7, 2004, at 1:44 PM, Bernie Volz wrote: > 1. Allow only the simple case for now (ie, Client FQDN option in an > IA_NA or > IA_TA options field applies to all addresses in the IA). We can always > add > the complex case (using a bit) in the future. This would obviously be my preference. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 8 08:30:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06251; Wed, 8 Sep 2004 08:30:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C51SN-0002SW-8t; Wed, 08 Sep 2004 08:21:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C51QS-00025R-6q for dhcwg@megatron.ietf.org; Wed, 08 Sep 2004 08:19:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05420 for ; Wed, 8 Sep 2004 08:19:46 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C51U5-0007aM-Bz for dhcwg@ietf.org; Wed, 08 Sep 2004 08:23:34 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i88CIULq021816; Wed, 8 Sep 2004 07:18:30 -0500 (CDT) Received: from kraken.mh.lucent.com by homail.ho.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i88CITP01836; Wed, 8 Sep 2004 08:18:29 -0400 (EDT) From: Joe Quanaim To: "Bernie Volz" , , "'Ted Lemon'" Subject: Re: [dhcwg] Re: I-D: draft-volz-dhc-dhcpv6-fqdn-00.txt - NEED INPUT BEFORE REVISING DRAFT! Date: Wed, 8 Sep 2004 08:18:27 -0400 User-Agent: KMail/1.5.4 References: <002301c4951b$7d08c980$efa0560a@amer.cisco.com> In-Reply-To: <002301c4951b$7d08c980$efa0560a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409080818.28071.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Bernie Volz wrote: > Before I revise the draft, please let me know if you think it is worth > doing. The choices are: > 1. Allow only the simple case for now (ie, Client FQDN option in an IA_NA > or IA_TA options field applies to all addresses in the IA). We can always > add the complex case (using a bit) in the future. > 2. Allow both the simple and more complex case (latter is as currently > documented); we'd use a bit in the flags field to indicate whether the > client supports the complex method and wants to use (server can support it > or not). Default (bit not set) is simple-only. > 3. Come up with a completely different approach the problem (ideas?). > 4. Abandon this work (if there's no interest in it). I think 1 is sufficient for now, but I would also accept 2. I think 4 is not a good choice. dns integration is a valuable differentiator between dhcp and slac. Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 8 15:56:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11722; Wed, 8 Sep 2004 15:56:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C58Fj-0006hj-K9; Wed, 08 Sep 2004 15:37:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C58EZ-000612-RL; Wed, 08 Sep 2004 15:35:59 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09720; Wed, 8 Sep 2004 15:35:57 -0400 (EDT) Message-Id: <200409081935.PAA09720@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 08 Sep 2004 15:35:57 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agentopt-radius-08.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: , Sender: dhcwg-bounces@ietf.org 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 : RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option Author(s) : R. Droms, J. Schnizlein Filename : draft-ietf-dhc-agentopt-radius-08.txt Pages : 9 Date : 2004-9-8 A NAS (network access server) may choose to authenticate the identity of a device before granting that device access to the network. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access. A network element using RADIUS as an authentication authority will receive attributes from a RADIUS server that may be used by a DHCP server in the selection of configuration parameters to be delivered to the device through its DHCP client. The RADIUS Attributes sub-option enables a network element to pass along attributes for the user of a device received during RADIUS authentication to a DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-08.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-agentopt-radius-08.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-agentopt-radius-08.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: <2004-9-8154302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agentopt-radius-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-8154302.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Wed Sep 8 19:40:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03015; Wed, 8 Sep 2004 19:40:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5BzO-0001w4-R3; Wed, 08 Sep 2004 19:36:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Bsv-0000iz-RL for dhcwg@megatron.ietf.org; Wed, 08 Sep 2004 19:29:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02427 for ; Wed, 8 Sep 2004 19:29:49 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5BwT-0005jS-ST for dhcwg@ietf.org; Wed, 08 Sep 2004 19:33:45 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3Q00JFOX8KJS@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 09 Sep 2004 08:29:08 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3Q00NKTX1Q3I@mailout1.samsung.com> for dhcwg@ietf.org; Thu, 09 Sep 2004 08:25:02 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3Q00F7EX1POG@mmp1.samsung.com> for dhcwg@ietf.org; Thu, 09 Sep 2004 08:25:02 +0900 (KST) Date: Thu, 09 Sep 2004 08:26:16 +0900 From: Soohong Daniel Park To: Dhcwg Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7BIT Cc: Ralph Droms Subject: [dhcwg] Rapid commit draft is ready for IESG 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT I believe *Rapid commit* draft is now ready to be submitted to the IESG. Above all, the WG Last Call was done by 5PM Fir, 2004-08-13. (final decision is up to the chair of DHC WG of course...:-)) Goals and Milestones: Sep 04 Submit 'Rapid Commit Option for DHCPv4' to IESG (draft-ietf-dhc-rapid-commit-opt) - Daniel (Soohong Daniel Park) - Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 9 01:28:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04583; Thu, 9 Sep 2004 01:28:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5HRi-0008VY-MH; Thu, 09 Sep 2004 01:26:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5HQw-0008Lz-W2 for dhcwg@megatron.ietf.org; Thu, 09 Sep 2004 01:25:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04423 for ; Thu, 9 Sep 2004 01:25:22 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5HUi-0002gD-KS for dhcwg@ietf.org; Thu, 09 Sep 2004 01:29:18 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i895PBEf011108 for ; Thu, 9 Sep 2004 14:25:11 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i895PBDD021872 for ; Thu, 9 Sep 2004 14:25:11 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i895PBWU021864 for ; Thu, 9 Sep 2004 14:25:11 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i895PALJ006879 for ; Thu, 9 Sep 2004 14:25:10 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i895PAO7006876 for ; Thu, 9 Sep 2004 14:25:10 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i895P90W017568 for ; Thu, 9 Sep 2004 14:25:09 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA18043 for ; Thu, 9 Sep 2004 14:25:09 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA28710 for ; Thu, 9 Sep 2004 14:25:09 +0900 (JST) Message-ID: <413FEA08.6030500@lab.ntt.co.jp> Date: Thu, 09 Sep 2004 14:28:40 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Dhcwg Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [dhcwg] Authentication for Information-request 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a question about transmitting Information-request message. In RFC3115, it is not specified clearly that solicit/advertise messages are exchanged between client and server before exchanging Information-request/reply message. On the other hand, it is defined that the client requests authentication in its Solicit message. So, I think that solicit/advertise messaged are exchanged before sending information-request when clients want to use authentication for information-request. Is my understanding right? (I know that Jinmei-san submitted $B!H(BClarifications on DHCPv6 Authentication$B!I(B. But I couldn't find any discussion for above issue on this mailing list.) --Mayumi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 9 05:06:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29485; Thu, 9 Sep 2004 05:06:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Knh-0002gI-G0; Thu, 09 Sep 2004 05:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5KlK-000276-Sm for dhcwg@megatron.ietf.org; Thu, 09 Sep 2004 04:58:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29044 for ; Thu, 9 Sep 2004 04:58:36 -0400 (EDT) Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Kp8-0005pl-Vk for dhcwg@ietf.org; Thu, 09 Sep 2004 05:02:36 -0400 Received: from [128.176.13.5] (OTHERLAND.UNI-MUENSTER.DE [128.176.13.5]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.1/8.12.9) with ESMTP id i898wdLh006182 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 9 Sep 2004 10:58:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <5DAC24BA-023E-11D9-995A-000A95ABEDDA@uni-muenster.de> Content-Type: text/plain; charset=US-ASCII; format=flowed To: " " From: Tina Strauf Date: Thu, 9 Sep 2004 10:58:06 +0200 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 client implementation 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, I am sorry if this has come up before or should be clear from the RFC.... In a recent discussion an issue came up concerning dhcpv6-client behavior upon startup/initialisation. It was unclear whether or not the dhcpv6 client was allowed or even supposed to be doing anything with the previously via manual or stateless autoconfiguration configured addresses. While the RFC doesn't say, that something needs to be done with those addresses, it also doesn't specifically disallow it. IMHO it only makes sense that the dhcpv6 client should/must just leave those addresses alone and don't touch them at all (at least by default). After all there can be valid interests in using both DHCPv6 address configuration and manual/stateless (auto)configuration at the same time and for different address ranges. But there seem to be different opinions around to the point of just deleting any addresses not from the range the DHCPv6 server assigns addresses from. Any comments ? Tina Strauf ---- JOIN - IPv6 Reference Center Tina Strauf A WWU project Westfaelische Wilhelms-Universitaet Muenster http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung Team: join@uni-muenster.de Roentgenstrasse 9-13 Priv: tstrauf@uni-muenster.de D-48149 Muenster / Germany GPG-/PGP-Key-ID: 923F61D0 Fon: +49 251 83 31833, Fax: +49 251 83 31653 "Reality is merely an illusion, albeit a very persistent one." Albert Einstein _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 9 07:32:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08539; Thu, 9 Sep 2004 07:32:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5N27-0003iJ-Mp; Thu, 09 Sep 2004 07:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5N1t-0003Uz-Da for dhcwg@megatron.ietf.org; Thu, 09 Sep 2004 07:23:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08195 for ; Thu, 9 Sep 2004 07:23:52 -0400 (EDT) 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.33) id 1C5N5k-00085m-0Q for dhcwg@ietf.org; Thu, 09 Sep 2004 07:27:52 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 09 Sep 2004 04:26:14 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i89BNJIV008731; Thu, 9 Sep 2004 04:23:19 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-138.cisco.com [10.86.242.138]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALK55457; Thu, 9 Sep 2004 07:23:17 -0400 (EDT) From: "Bernie Volz" To: "'Tina Strauf'" , Subject: RE: [dhcwg] DHCPv6 client implementation Date: Thu, 9 Sep 2004 07:23:17 -0400 Organization: Cisco Message-ID: <000e01c4965f$677ad820$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <5DAC24BA-023E-11D9-995A-000A95ABEDDA@uni-muenster.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit The DHCPv6 client should NOT do anything to any stateful addresses or manually configured addresses. If the DHCPv6 client didn't "add" an address (via stateful / received from the DHCPv6 server in an IAADDR option), it should leave it alone. The various address assignment techniques (stateless, stateful, and manual) can all operate at the same time - a client can have addresses from all three techniques active at one time. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Tina Strauf > Sent: Thursday, September 09, 2004 4:58 AM > To: > Subject: [dhcwg] DHCPv6 client implementation > > > Hello, > > I am sorry if this has come up before or should be clear from the > RFC.... > In a recent discussion an issue came up concerning dhcpv6-client > behavior upon startup/initialisation. It was unclear whether > or not the > dhcpv6 client was allowed or even supposed to be doing anything with > the previously via manual or stateless autoconfiguration configured > addresses. While the RFC doesn't say, that something needs to be done > with those addresses, it also doesn't specifically disallow > it. IMHO it > only makes sense that the dhcpv6 client should/must just leave those > addresses alone and don't touch them at all (at least by default). > After all there can be valid interests in using both DHCPv6 address > configuration and manual/stateless (auto)configuration at the > same time > and for different address ranges. But there seem to be different > opinions around to the point of just deleting any addresses not from > the range the DHCPv6 server assigns addresses from. > > Any comments ? > > Tina Strauf > > ---- > JOIN - IPv6 Reference Center Tina Strauf > A WWU project Westfaelische Wilhelms-Universitaet > Muenster > http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung > Team: join@uni-muenster.de Roentgenstrasse 9-13 > Priv: tstrauf@uni-muenster.de D-48149 Muenster / Germany > GPG-/PGP-Key-ID: 923F61D0 Fon: +49 251 83 31833, Fax: > +49 251 83 > 31653 > > "Reality is merely an illusion, albeit a very persistent one." Albert > Einstein > > > _______________________________________________ > 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 Sep 9 08:18:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12810; Thu, 9 Sep 2004 08:18:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5NlA-0006lR-O5; Thu, 09 Sep 2004 08:10:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Neh-00050V-IZ for dhcwg@megatron.ietf.org; Thu, 09 Sep 2004 08:03:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11387 for ; Thu, 9 Sep 2004 08:03:58 -0400 (EDT) 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.33) id 1C5NiX-0000cm-Eg for dhcwg@ietf.org; Thu, 09 Sep 2004 08:07:58 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Sep 2004 05:11:25 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i89C3L8J016822; Thu, 9 Sep 2004 05:03:22 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-106.cisco.com [10.86.240.106]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALK56847; Thu, 9 Sep 2004 08:03:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20040909075431.021597d0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Sep 2004 08:03:21 -0400 To: Tina Strauf From: Ralph Droms Subject: Re: [dhcwg] DHCPv6 client implementation In-Reply-To: <5DAC24BA-023E-11D9-995A-000A95ABEDDA@uni-muenster.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Tina - Operation of DHCPv6 is entirely independent of stateless address autoconfiguration (SLAAC) and manual address assignment, so the DHCPv6 client should not make any changes to any addresses assigned through SLAAC or manual assignment. RFC 2461 and RFC 2462 address the relationship between DHCPv6 and stateless address autoconfiguration. In summary, SLAAC and the use of DHCPv6 are managed independently, and the protocol standards allow a host to use both SLAAC and DHCPv6 simultaneously. I don't remember if the RFCs explicitly mention that both SLAAC and DHCPv6 are also independent of manual address assignment. - Ralph At 10:58 AM 9/9/2004 +0200, Tina Strauf wrote: >Hello, > >I am sorry if this has come up before or should be clear from the RFC.... >In a recent discussion an issue came up concerning dhcpv6-client behavior >upon startup/initialisation. It was unclear whether or not the dhcpv6 >client was allowed or even supposed to be doing anything with the >previously via manual or stateless autoconfiguration configured addresses. >While the RFC doesn't say, that something needs to be done with those >addresses, it also doesn't specifically disallow it. IMHO it only makes >sense that the dhcpv6 client should/must just leave those addresses alone >and don't touch them at all (at least by default). After all there can be >valid interests in using both DHCPv6 address configuration and >manual/stateless (auto)configuration at the same time and for different >address ranges. But there seem to be different opinions around to the >point of just deleting any addresses not from the range the DHCPv6 server >assigns addresses from. > >Any comments ? > >Tina Strauf > >---- >JOIN - IPv6 Reference Center Tina Strauf >A WWU project Westfaelische Wilhelms-Universitaet Muenster >http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung >Team: join@uni-muenster.de Roentgenstrasse 9-13 >Priv: tstrauf@uni-muenster.de D-48149 Muenster / Germany >GPG-/PGP-Key-ID: 923F61D0 Fon: +49 251 83 31833, Fax: +49 251 83 31653 > >"Reality is merely an illusion, albeit a very persistent one." Albert Einstein > > >_______________________________________________ >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 Sep 9 08:25:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13149; Thu, 9 Sep 2004 08:25:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5NsQ-0000Ph-R3; Thu, 09 Sep 2004 08:18:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Nmh-00074k-Fd for dhcwg@megatron.ietf.org; Thu, 09 Sep 2004 08:12:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12351 for ; Thu, 9 Sep 2004 08:12:14 -0400 (EDT) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5NqV-0000rd-C4 for dhcwg@ietf.org; Thu, 09 Sep 2004 08:16:14 -0400 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id i89CBZOK010725; Thu, 9 Sep 2004 14:11:39 +0200 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id i89CBY94027430; Thu, 9 Sep 2004 14:11:34 +0200 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 9 Sep 2004 14:11:34 +0200 From: Stig Venaas To: Joe Quanaim Subject: Re: [dhcwg] behavior on lifetime expiration (Re: comments on draft-ietf-dhc-lifetime-01.txt) Message-ID: <20040909121134.GH26272@sverresborg.uninett.no> References: <20040906084327.GA8343@sverresborg.uninett.no> <20040907090029.GB17934@sverresborg.uninett.no> <200409070912.13081.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409070912.13081.jdq@lucent.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Sep 07, 2004 at 09:12:13AM -0400, Joe Quanaim wrote: > Stig Venaas wrote: > > When a client receives a Reply to an Information-Request that > > contains configuration information (i.e., does not contain a > > Status Code option), it should install that new configuration > > information after removing any previously received configuration > > information. Note that it should also remove information that > > is missing from the new information set, e.g. an option might be > > left out or contain only a subset of what it did previously. > > There may be reasons not to always do this. One example might > > be when client has indication that it has moved to a new link. > > How a client copes with movement is outside the scope of this > > document. > > Should "does not contain a Status Code option" be replaced with "does not > contain a negative Status Code option"? A status code of 0 should be > acceptable. > > Otherwise, this text looks good. Negative is a bit misleading perhaps since the values are not negative, but I see what you mean. We could say non-zero or that the code is not "success". Or perhaps just remove the "i.e.". Unfortunately I just submitted 02 version of the draft, and forgot to consider this. This is easy to fix later though. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 9 08:39:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14121; Thu, 9 Sep 2004 08:39:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5O3z-0003Ku-M1; Thu, 09 Sep 2004 08:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5O0a-0002Y6-RE for dhcwg@megatron.ietf.org; Thu, 09 Sep 2004 08:26:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13230 for ; Thu, 9 Sep 2004 08:26:35 -0400 (EDT) Received: from ovaron.uni-muenster.de ([128.176.191.5] helo=ovaron.join.uni-muenster.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5O4Q-00018R-NX for dhcwg@ietf.org; Thu, 09 Sep 2004 08:30:36 -0400 Received: from [128.176.184.7] (THORA.UNI-MUENSTER.DE [128.176.184.7]) (authenticated bits=0) by ovaron.join.uni-muenster.de (8.13.1/8.12.9) with ESMTP id i89CPISL010350 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 9 Sep 2004 14:25:19 +0200 (CEST) Subject: Re: [dhcwg] DHCPv6 client implementation From: Tina Strauf To: Ralph Droms In-Reply-To: <4.3.2.7.2.20040909075431.021597d0@flask.cisco.com> References: <4.3.2.7.2.20040909075431.021597d0@flask.cisco.com> Content-Type: text/plain Organization: JOIN Projekt Team Message-Id: <1094732714.7506.3.camel@thora.uni-muenster.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 09 Sep 2004 14:25:15 +0200 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tstrauf@uni-muenster.de List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Bernie, Ralph, thanks for clearing that up. That was exactly my understanding. Tina Am Do, den 09.09.2004 schrieb Ralph Droms um 14:03: > Tina - Operation of DHCPv6 is entirely independent of stateless address > autoconfiguration (SLAAC) and manual address assignment, so the DHCPv6 > client should not make any changes to any addresses assigned through SLAAC > or manual assignment. > > RFC 2461 and RFC 2462 address the relationship between DHCPv6 and stateless > address autoconfiguration. In summary, SLAAC and the use of DHCPv6 are > managed independently, and the protocol standards allow a host to use both > SLAAC and DHCPv6 simultaneously. I don't remember if the RFCs explicitly > mention that both SLAAC and DHCPv6 are also independent of manual address > assignment. > > - Ralph Am Do, den 09.09.2004 schrieb Bernie Volz um 13:23: > The DHCPv6 client should NOT do anything to any stateful addresses or > manually configured addresses. If the DHCPv6 client didn't "add" an address > (via stateful / received from the DHCPv6 server in an IAADDR option), it > should leave it alone. > > The various address assignment techniques (stateless, stateful, and manual) > can all operate at the same time - a client can have addresses from all > three techniques active at one time. > > - Bernie > At 10:58 AM 9/9/2004 +0200, Tina Strauf wrote: > >Hello, > > > >I am sorry if this has come up before or should be clear from the RFC.... > >In a recent discussion an issue came up concerning dhcpv6-client behavior > >upon startup/initialisation. It was unclear whether or not the dhcpv6 > >client was allowed or even supposed to be doing anything with the > >previously via manual or stateless autoconfiguration configured addresses. > >While the RFC doesn't say, that something needs to be done with those > >addresses, it also doesn't specifically disallow it. IMHO it only makes > >sense that the dhcpv6 client should/must just leave those addresses alone > >and don't touch them at all (at least by default). After all there can be > >valid interests in using both DHCPv6 address configuration and > >manual/stateless (auto)configuration at the same time and for different > >address ranges. But there seem to be different opinions around to the > >point of just deleting any addresses not from the range the DHCPv6 server > >assigns addresses from. > > > >Any comments ? > > > >Tina Strauf > > > >---- > >JOIN - IPv6 Reference Center Tina Strauf > >A WWU project Westfaelische Wilhelms-Universitaet Muenster > >http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung > >Team: join@uni-muenster.de Roentgenstrasse 9-13 > >Priv: tstrauf@uni-muenster.de D-48149 Muenster / Germany > >GPG-/PGP-Key-ID: 923F61D0 Fon: +49 251 83 31833, Fax: +49 251 83 31653 > > > >"Reality is merely an illusion, albeit a very persistent one." Albert Einstein > > > > > >_______________________________________________ > >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 Sep 9 13:25:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05806; Thu, 9 Sep 2004 13:25:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5SZ6-0008MR-Q2; Thu, 09 Sep 2004 13:18:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5SQK-0006Lb-4B for dhcwg@megatron.ietf.org; Thu, 09 Sep 2004 13:09:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04741 for ; Thu, 9 Sep 2004 13:09:25 -0400 (EDT) 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.33) id 1C5SUC-0006GR-7p for dhcwg@ietf.org; Thu, 09 Sep 2004 13:13:30 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Sep 2004 10:18:19 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i89H8b8J000051 for ; Thu, 9 Sep 2004 10:08:38 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.118]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALK83219; Thu, 9 Sep 2004 13:08:38 -0400 (EDT) Message-Id: <4.3.2.7.2.20040909120407.0215a1d8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Sep 2004 13:08:36 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [dhcwg] Fwd: WGLC for draft-ietf-dnsop-ipv6-dns-configuration-03.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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org FYI, because of the reference to the DHCPv6 DNS server configuration option discussed in the draft. Please post any comments to the dnsop@lists.uoregon.edu mailing list. - Ralph >Date: Thu, 9 Sep 2004 08:57:54 -0700 >From: David Meyer >To: dnsop@lists.uoregon.edu >Cc: bwijnen@lucent.com, david.kessens@nokia.com, dnsop-v6conf@nominum.com >Subject: WGLC for draft-ietf-dnsop-ipv6-dns-configuration-03.txt > > > > > Folks > > This note starts what I hope is the last WG Last Call for > comments on draft-ietf-dnsop-ipv6-dns-configuration-03.txt, > "IPv6 Host Configuration of DNS Server Information > Approaches". It can be found on > > >ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configuration-03.txt > > Please review the document carefully, and send your > feedback to the list. Please also indicate whether or > not you believe that this document is ready to go to the > IESG. > > Please note that this is a somewhat unusual case as the > IESG requested this document as input to their decision > process regarding IPv6 DNS (host) configuration. That > being the case, please state only substantial comments. > > This Last Call will end on 23 Sep 2004 at 1400 PDT (UTC/GMT-7). > > Thanks, > > Dave _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 9 15:59:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18913; Thu, 9 Sep 2004 15:59:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5UiP-0008UE-Hd; Thu, 09 Sep 2004 15:36:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Ue4-0006Hc-Uw; Thu, 09 Sep 2004 15:31:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16076; Thu, 9 Sep 2004 15:31:46 -0400 (EDT) Message-Id: <200409091931.PAA16076@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 09 Sep 2004 15:31:46 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-lifetime-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: , Sender: dhcwg-bounces@ietf.org 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 : Lifetime Option for DHCPv6 Author(s) : S. Venaas, et al. Filename : draft-ietf-dhc-lifetime-02.txt Pages : 8 Date : 2004-9-9 This document describes an option for specifying a lifetime for other DHCPv6 configuration options. It's mainly intended for the stateless DHCPv6, but also useful when there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCP server to update its configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-lifetime-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-lifetime-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-lifetime-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: <2004-9-9145027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-lifetime-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-lifetime-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-9145027.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Fri Sep 10 09:14:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23553; Fri, 10 Sep 2004 09:14:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5lC0-0001gz-L1; Fri, 10 Sep 2004 09:11:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5l8C-00010t-4s for dhcwg@megatron.ietf.org; Fri, 10 Sep 2004 09:08:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22952 for ; Fri, 10 Sep 2004 09:07:58 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5lCE-0005sa-T6 for dhcwg@ietf.org; Fri, 10 Sep 2004 09:12:12 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8AD7trf027499 for ; Fri, 10 Sep 2004 22:07:55 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8AD7tOr002967 for ; Fri, 10 Sep 2004 22:07:55 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8AD7sVv002964 for ; Fri, 10 Sep 2004 22:07:54 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8AD7sV5019614 for ; Fri, 10 Sep 2004 22:07:54 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8AD7skU019611 for ; Fri, 10 Sep 2004 22:07:54 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8AD7r6j020458 for ; Fri, 10 Sep 2004 22:07:53 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id WAA09439 for ; Fri, 10 Sep 2004 22:07:52 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id WAA14868 for ; Fri, 10 Sep 2004 22:07:52 +0900 (JST) Message-ID: <4141A7FB.8070701@lab.ntt.co.jp> Date: Fri, 10 Sep 2004 22:11:23 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: dhcwg@ietf.org Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-agentopt-radius-08.txt References: <200409081935.PAA09720@ietf.org> In-Reply-To: <200409081935.PAA09720@ietf.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit I have a question. >>4. DHCP Relay Agent Behavior > > >When the DHCP relay agent receives a DHCP message from the client, it >MAY append a DHCP Relay Agent Information option containing the >RADIUS Attributes sub-option, along with any other sub-options it is >configured to supply. The RADIUS Attributes sub-option MUST only >contain the attributes provided in the RADIUS Access/Accept message. >The DHCP relay agent MUST NOT add more than one RADIUS Attributes >sub-option in a message. > >The relay agent MUST include the User-Name and Framed-Pool attributes >in the RADIUS Attributes sub-option if available, and MAY include >other attributes. > >To avoid dependencies between the address allocation and other state >information between the RADIUS server and the DHCP server, the DHCP >relay agent SHOULD include only the attributes in the table below an >instance of the RADIUS Attributes sub-option. The table, based on >the analysis in RFC 3580 [10], lists attributes that MAY be included: I'm not sure what "other state information" is. I can$B!G(Bt understand the reason why dependencies between the address allocation and other state information should be avoided. Will any problem be caused if we define new attribute? --Mayumi Internet-Drafts@ietf.org wrote: > 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 : RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option > Author(s) : R. Droms, J. Schnizlein > Filename : draft-ietf-dhc-agentopt-radius-08.txt > Pages : 9 > Date : 2004-9-8 > > A NAS (network access server) may choose to authenticate the identity > of a device before granting that device access to the network. The > IEEE 802.1X protocol is an example of a mechanism for providing > authenticated layer 2 network access. A network element using RADIUS > as an authentication authority will receive attributes from a RADIUS > server that may be used by a DHCP server in the selection of > configuration parameters to be delivered to the device through its > DHCP client. The RADIUS Attributes sub-option enables a network > element to pass along attributes for the user of a device received > during RADIUS authentication to a DHCP server. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-08.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-agentopt-radius-08.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-agentopt-radius-08.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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Sep 10 09:55:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26651; Fri, 10 Sep 2004 09:55:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5lq0-0002XH-6X; Fri, 10 Sep 2004 09:53:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5lb6-0006ZR-Au for dhcwg@megatron.ietf.org; Fri, 10 Sep 2004 09:37:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25370 for ; Fri, 10 Sep 2004 09:37:49 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5lf9-0006SO-JA for dhcwg@ietf.org; Fri, 10 Sep 2004 09:42:04 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 10 Sep 2004 09:51:22 -0400 X-BrightmailFiltered: true Received: from jschnizl-w2k.cisco.com (rtp-vpn3-280.cisco.com [10.82.217.26]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8ADbGH8029001; Fri, 10 Sep 2004 09:37:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20040910093209.025f1008@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Sep 2004 09:37:15 -0400 To: Mayumi Yanagiya From: John Schnizlein Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-agentopt-radius-08.txt In-Reply-To: <4141A7FB.8070701@lab.ntt.co.jp> References: <200409081935.PAA09720@ietf.org> <200409081935.PAA09720@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org We were told by the AAA experts that the RADIUS model involves keeping state about the remote host regarding some attributes. It would be wrong to attempt to manage this state in both the RADIUS and DHCP servers. The most obvious is the IP address, but they advised us that all but those in the list in agentopt-radius-08 might cause problems for the RADIUS server. John At 09:11 AM 9/10/2004, Mayumi Yanagiya wrote: >I have a question. > >>>4. DHCP Relay Agent Behavior >> >> >>When the DHCP relay agent receives a DHCP message from the client, it >>MAY append a DHCP Relay Agent Information option containing the >>RADIUS Attributes sub-option, along with any other sub-options it is >>configured to supply. The RADIUS Attributes sub-option MUST only >>contain the attributes provided in the RADIUS Access/Accept message. >>The DHCP relay agent MUST NOT add more than one RADIUS Attributes >>sub-option in a message. >> >>The relay agent MUST include the User-Name and Framed-Pool attributes >>in the RADIUS Attributes sub-option if available, and MAY include >>other attributes. >> >>To avoid dependencies between the address allocation and other state >>information between the RADIUS server and the DHCP server, the DHCP >>relay agent SHOULD include only the attributes in the table below an >>instance of the RADIUS Attributes sub-option. The table, based on >>the analysis in RFC 3580 [10], lists attributes that MAY be included: > >I'm not sure what "other state information" is. >I can't understand the reason why dependencies between >the address allocation and other state information should be avoided. >Will any problem be caused if we define new attribute? > >--Mayumi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Sep 10 10:20:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29941; Fri, 10 Sep 2004 10:20:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5m9L-0001ln-Kr; Fri, 10 Sep 2004 10:13:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5lyz-0005t5-CJ for dhcwg@megatron.ietf.org; Fri, 10 Sep 2004 10:02:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27422 for ; Fri, 10 Sep 2004 10:02:30 -0400 (EDT) Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5m33-00072s-BX for dhcwg@ietf.org; Fri, 10 Sep 2004 10:06:46 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel12.hp.com (Postfix) with ESMTP id 9E7124103D5 for ; Fri, 10 Sep 2004 07:02:26 -0700 (PDT) Received: from l609 (icon5103.india.hp.com [15.42.231.103]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id TAA29984 for ; Fri, 10 Sep 2004 19:32:49 +0530 (IST) Message-Id: <200409101402.TAA29984@iconsrv6.india.hp.com> From: "Anil Kumar Reddy" To: Date: Fri, 10 Sep 2004 19:32:22 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcSRd3j5PE5ZAmm5RymTs6mxTD1/gQDP8lPA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <000601c49175$b2e5eaf0$8d476c6b@sisodomain.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Router option, in 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi All, I would like to know your inputs on having the router option in dhcpv6. I feel, having a router configuration option (similar to DNS, SIP, NIS) would help the client's network connectivity in the absence of RA. Are there any reasons, not to consider this ? Let me know if this topic is already discussed and I should refer to that before discussing this, in WG. -- Thanks & Regards, Anil _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Sep 10 16:34:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02098; Fri, 10 Sep 2004 16:34:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5rhi-0002he-6G; Fri, 10 Sep 2004 16:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5rTf-0003Mc-E7; Fri, 10 Sep 2004 15:54:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27624; Fri, 10 Sep 2004 15:54:32 -0400 (EDT) Message-Id: <200409101954.PAA27624@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 10 Sep 2004 15:54:32 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-vendor-suboption-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: , Sender: dhcwg-bounces@ietf.org 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 : Vendor-Specific Information Suboption for the DHCP Relay Agent Option Author(s) : M. Stapp, et al. Filename : draft-ietf-dhc-vendor-suboption-00.txt Pages : 9 Date : 2004-9-10 This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor-specific information in DHCP messages it forwards, as configured by its administrator. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-vendor-suboption-00.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-vendor-suboption-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-vendor-suboption-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-10154207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-vendor-suboption-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-vendor-suboption-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-10154207.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Fri Sep 10 17:23:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10155; Fri, 10 Sep 2004 17:23:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5scG-0006ft-SO; Fri, 10 Sep 2004 17:07:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5rj1-0003tZ-2E for dhcwg@megatron.ietf.org; Fri, 10 Sep 2004 16:10:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29041 for ; Fri, 10 Sep 2004 16:10:24 -0400 (EDT) Received: from [192.150.250.67] (helo=fuchsia.home) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5rn5-00076P-C7 for dhcwg@ietf.org; Fri, 10 Sep 2004 16:14:43 -0400 Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.32]) by fuchsia.home with ESMTP id i8AKAHRN015588; Sat, 11 Sep 2004 03:10:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i8AJ08oH001313; Sat, 11 Sep 2004 02:00:38 +0700 (ICT) From: Robert Elz To: "Anil Kumar Reddy" Subject: Re: [dhcwg] Router option, in DHCPv6 In-Reply-To: <200409101402.TAA29984@iconsrv6.india.hp.com> References: <200409101402.TAA29984@iconsrv6.india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 Sep 2004 02:00:08 +0700 Message-ID: <21501.1094842808@munnari.OZ.AU> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Date: Fri, 10 Sep 2004 19:32:22 +0530 From: "Anil Kumar Reddy" Message-ID: <200409101402.TAA29984@iconsrv6.india.hp.com> | I feel, having a router configuration option (similar to | DNS, SIP, NIS) would help the client's network connectivity | in the absence of RA. As a rationale, that's useless. If there are no RAs, there are no routers, RAs in v6 aren't optional. But, it might be perhaps useful to be able to configure a particular router on a net with several - and perhaps different routers for different hosts, which is something that RAs cannot achieve, so the option shouldn't necessarily simply be discarded as completely useless. Whether the benefit in allowing this is worth the extra complexity I'm not sure I'd like to take a position on at the minute. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Sep 11 10:09:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19452; Sat, 11 Sep 2004 10:09:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C68X2-0006Ja-JX; Sat, 11 Sep 2004 10:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C68WU-0005xT-BU for dhcwg@megatron.ietf.org; Sat, 11 Sep 2004 10:06:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19137 for ; Sat, 11 Sep 2004 10:06:36 -0400 (EDT) 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.33) id 1C68al-0001Bd-BW for dhcwg@ietf.org; Sat, 11 Sep 2004 10:11:04 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 11 Sep 2004 07:14:29 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8BE62wW002270; Sat, 11 Sep 2004 07:06:03 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-2-21.cisco.com [10.86.242.21]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALM11872; Sat, 11 Sep 2004 10:06:01 -0400 (EDT) From: "Bernie Volz" To: "'Robert Elz'" , "'Anil Kumar Reddy'" Subject: RE: [dhcwg] Router option, in DHCPv6 Date: Sat, 11 Sep 2004 10:05:57 -0400 Organization: Cisco Message-ID: <000901c49808$78269010$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-reply-to: <21501.1094842808@munnari.OZ.AU> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I agree. We do not need this option. If someone can demonstrate a solid need for this (either a list of = default routers or list of static routes), we will consider this. But if you = have no solid use case, this should be outside the scope of DHCPv6.=20 In IPv4, there was no basic mechanism for a host to find router(s) and = to discover whether addresses are on or off link (ICMP messages were added later, but I think they've been little used). This is a basic feature of IPv6. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Robert Elz > Sent: Friday, September 10, 2004 3:00 PM > To: Anil Kumar Reddy > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Router option, in DHCPv6=20 >=20 >=20 > Date: Fri, 10 Sep 2004 19:32:22 +0530 > From: "Anil Kumar Reddy" > Message-ID: <200409101402.TAA29984@iconsrv6.india.hp.com> >=20 > | I feel, having a router configuration option (similar to=20 > | DNS, SIP, NIS) would help the client's network connectivity=20 > | in the absence of RA. >=20 > As a rationale, that's useless. If there are no RAs, there are no > routers, RAs in v6 aren't optional. >=20 > But, it might be perhaps useful to be able to configure a=20 > particular router on a net with several - and perhaps=20 > different routers for different hosts, which is something=20 > that RAs cannot achieve, so the option shouldn't necessarily=20 > simply be discarded as completely useless. >=20 > Whether the benefit in allowing this is worth the extra=20 > complexity I'm not sure I'd like to take a position on at the minute. >=20 > kre >=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 Sep 15 02:51:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03341; Wed, 15 Sep 2004 02:51:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7TXt-0004W5-JV; Wed, 15 Sep 2004 02:45:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7TTY-0002i5-No for dhcwg@megatron.ietf.org; Wed, 15 Sep 2004 02:41:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02638 for ; Wed, 15 Sep 2004 02:41:06 -0400 (EDT) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7TYc-0003my-Db for dhcwg@ietf.org; Wed, 15 Sep 2004 02:46:22 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel13.hp.com (Postfix) with ESMTP id 5CE7E1C00531; Tue, 14 Sep 2004 23:41:04 -0700 (PDT) Received: from l609 (icon5103.india.hp.com [15.42.231.103]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id MAA24453; Wed, 15 Sep 2004 12:11:25 +0530 (IST) Message-Id: <200409150641.MAA24453@iconsrv6.india.hp.com> From: "Anil Kumar Reddy" To: "'Bernie Volz'" , "'Robert Elz'" Subject: RE: [dhcwg] Router option, in DHCPv6 Date: Wed, 15 Sep 2004 12:10:56 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <000901c49808$78269010$6401a8c0@amer.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSYCRlPcF7U+t5gS+2NSHi6yYx6pwBlae8w X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Thanks for your responses. Sorry for the delay in my response. I have a question : Take a case of load balancing, where two routers present and we want to manage/configure few set of hosts (address range) to use one router and others to use a different one (two paths), how do we achieve this using RAs ? -- Thanks, Anil : -----Original Message----- : From: Bernie Volz [mailto:volz@cisco.com] : Sent: Saturday, September 11, 2004 7:36 PM : To: 'Robert Elz'; 'Anil Kumar Reddy' : Cc: dhcwg@ietf.org : Subject: RE: [dhcwg] Router option, in DHCPv6 : : I agree. We do not need this option. : : If someone can demonstrate a solid need for this (either a : list of default routers or list of static routes), we will : consider this. But if you have no solid use case, this should : be outside the scope of DHCPv6. : : In IPv4, there was no basic mechanism for a host to find : router(s) and to discover whether addresses are on or off : link (ICMP messages were added later, but I think they've : been little used). This is a basic feature of IPv6. : : - Bernie : : > -----Original Message----- : > From: dhcwg-bounces@ietf.org : [mailto:dhcwg-bounces@ietf.org] On Behalf : > Of Robert Elz : > Sent: Friday, September 10, 2004 3:00 PM : > To: Anil Kumar Reddy : > Cc: dhcwg@ietf.org : > Subject: Re: [dhcwg] Router option, in DHCPv6 : > : > : > Date: Fri, 10 Sep 2004 19:32:22 +0530 : > From: "Anil Kumar Reddy" : > Message-ID: <200409101402.TAA29984@iconsrv6.india.hp.com> : > : > | I feel, having a router configuration option : (similar to : > | DNS, SIP, NIS) would help the client's network : connectivity : > | in the absence of RA. : > : > As a rationale, that's useless. If there are no RAs, there are no : > routers, RAs in v6 aren't optional. : > : > But, it might be perhaps useful to be able to configure a : particular : > router on a net with several - and perhaps different routers for : > different hosts, which is something that RAs cannot achieve, so the : > option shouldn't necessarily simply be discarded as completely : > useless. : > : > Whether the benefit in allowing this is worth the extra : complexity I'm : > not sure I'd like to take a position on at the minute. : > : > kre : > : > : > _______________________________________________ : > 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 Sep 15 04:01:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10302; Wed, 15 Sep 2004 04:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7UZh-00026C-8m; Wed, 15 Sep 2004 03:51:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C6o1M-0006Xx-O9 for dhcwg@megatron.ietf.org; Mon, 13 Sep 2004 06:25:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13125 for ; Mon, 13 Sep 2004 06:25:13 -0400 (EDT) Received: from proxy.ipv6.6wind.com ([194.250.197.211] helo=proxy.6wind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C6o61-0004LF-JD for dhcwg@ietf.org; Mon, 13 Sep 2004 06:30:07 -0400 Received: from eagle.6wind.com (givenchy.6wind.com [212.234.238.114]) by proxy.6wind.com (Postfix) with ESMTP id 2AC4372D for ; Mon, 13 Sep 2004 12:25:13 +0200 (CEST) Received: from 6WIND.com (unknown [10.16.0.134]) by eagle.6wind.com (Postfix) with ESMTP id F40D61E1 for ; Mon, 13 Sep 2004 12:25:12 +0200 (CEST) Message-ID: <4145754F.5060409@6WIND.com> Date: Mon, 13 Sep 2004 12:24:15 +0200 From: Jean-Mickael Guerin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Subject: Re: [dhcwg] Router option, in DHCPv6 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 15 Sep 2004 03:51:29 -0400 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit There is the case when DHCPv6 client is a router that performs prefix delegation, and does not run any routing protocol. This router would just need a default gateway. I think setting this gateway to the delegating router is enough but perhaps some scenario may require an explicit gateway ? Jean-Mickael Bernie Volz wrote: > I agree. We do not need this option. > > If someone can demonstrate a solid need for this (either a list of = > default > routers or list of static routes), we will consider this. But if you = > have no > solid use case, this should be outside the scope of DHCPv6.=20 > > In IPv4, there was no basic mechanism for a host to find router(s) and = > to > discover whether addresses are on or off link (ICMP messages were added > later, but I think they've been little used). This is a basic feature of > IPv6. > > - Bernie > > >>-----Original Message----- >>From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 >>On Behalf Of Robert Elz >>Sent: Friday, September 10, 2004 3:00 PM >>To: Anil Kumar Reddy >>Cc: dhcwg@ietf.org >>Subject: Re: [dhcwg] Router option, in DHCPv6=20 >>=20 >>=20 >> Date: Fri, 10 Sep 2004 19:32:22 +0530 >> From: "Anil Kumar Reddy" >> Message-ID: <200409101402.TAA29984@iconsrv6.india.hp.com> >>=20 >> | I feel, having a router configuration option (similar to=20 >> | DNS, SIP, NIS) would help the client's network connectivity=20 >> | in the absence of RA. >>=20 >>As a rationale, that's useless. If there are no RAs, there are no >>routers, RAs in v6 aren't optional. >>=20 >>But, it might be perhaps useful to be able to configure a=20 >>particular router on a net with several - and perhaps=20 >>different routers for different hosts, which is something=20 >>that RAs cannot achieve, so the option shouldn't necessarily=20 >>simply be discarded as completely useless. >>=20 >>Whether the benefit in allowing this is worth the extra=20 >>complexity I'm not sure I'd like to take a position on at the minute. >>=20 >>kre >>=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 -- Jean-Mickael GUERIN Tel : +33 1 39 30 92 33 Web site : www.6wind.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 15 04:11:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10852; Wed, 15 Sep 2004 04:11:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7UkL-0004vm-JE; Wed, 15 Sep 2004 04:02:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7UiM-0004AS-PB for dhcwg@megatron.ietf.org; Wed, 15 Sep 2004 04:00:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10209 for ; Wed, 15 Sep 2004 04:00:28 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7UnR-0005bG-DF for dhcwg@ietf.org; Wed, 15 Sep 2004 04:05:45 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 15 Sep 2004 04:14:53 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8F7xuO9029386; Wed, 15 Sep 2004 03:59:57 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn4-561.cisco.com [10.21.82.49]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALO04973; Wed, 15 Sep 2004 03:59:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20040915035651.02e5d3b0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Sep 2004 03:59:51 -0400 To: "Anil Kumar Reddy" From: Ralph Droms Subject: RE: [dhcwg] Router option, in DHCPv6 In-Reply-To: <200409150641.MAA24453@iconsrv6.india.hp.com> References: <000901c49808$78269010$6401a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: dhcwg@ietf.org, "'Bernie Volz'" , "'Robert Elz'" 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Anil - the scenario you describe falls, I think, in the class of scenarios kre described: >But, it might be perhaps useful to be able to configure a particular >router on a net with several - and perhaps different routers for >different hosts, which is something that RAs cannot achieve, so the >option shouldn't necessarily simply be discarded as completely useless. Do we have any reason to believe, at this point, that load balancing through explicit default router assignment will be used in practice? - Ralph At 12:10 PM 9/15/2004 +0530, Anil Kumar Reddy wrote: >Thanks for your responses. Sorry for the delay in my response. > >I have a question : >Take a case of load balancing, where two routers present and > we want to manage/configure few set of hosts (address range) > to use one router and others to use a different one (two > paths), how do we achieve this using RAs ? > >-- >Thanks, >Anil > >: -----Original Message----- >: From: Bernie Volz [mailto:volz@cisco.com] >: Sent: Saturday, September 11, 2004 7:36 PM >: To: 'Robert Elz'; 'Anil Kumar Reddy' >: Cc: dhcwg@ietf.org >: Subject: RE: [dhcwg] Router option, in DHCPv6 >: >: I agree. We do not need this option. >: >: If someone can demonstrate a solid need for this (either a >: list of default routers or list of static routes), we will >: consider this. But if you have no solid use case, this should >: be outside the scope of DHCPv6. >: >: In IPv4, there was no basic mechanism for a host to find >: router(s) and to discover whether addresses are on or off >: link (ICMP messages were added later, but I think they've >: been little used). This is a basic feature of IPv6. >: >: - Bernie >: >: > -----Original Message----- >: > From: dhcwg-bounces@ietf.org >: [mailto:dhcwg-bounces@ietf.org] On Behalf >: > Of Robert Elz >: > Sent: Friday, September 10, 2004 3:00 PM >: > To: Anil Kumar Reddy >: > Cc: dhcwg@ietf.org >: > Subject: Re: [dhcwg] Router option, in DHCPv6 >: > >: > >: > Date: Fri, 10 Sep 2004 19:32:22 +0530 >: > From: "Anil Kumar Reddy" >: > Message-ID: <200409101402.TAA29984@iconsrv6.india.hp.com> >: > >: > | I feel, having a router configuration option >: (similar to >: > | DNS, SIP, NIS) would help the client's network >: connectivity >: > | in the absence of RA. >: > >: > As a rationale, that's useless. If there are no RAs, there are no >: > routers, RAs in v6 aren't optional. >: > >: > But, it might be perhaps useful to be able to configure a >: particular >: > router on a net with several - and perhaps different routers for >: > different hosts, which is something that RAs cannot achieve, so the >: > option shouldn't necessarily simply be discarded as completely >: > useless. >: > >: > Whether the benefit in allowing this is worth the extra >: complexity I'm >: > not sure I'd like to take a position on at the minute. >: > >: > kre >: > >: > >: > _______________________________________________ >: > 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 Wed Sep 15 06:54:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21071; Wed, 15 Sep 2004 06:54:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7XMr-0004IA-W5; Wed, 15 Sep 2004 06:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7XJ9-0003lK-Lf for dhcwg@megatron.ietf.org; Wed, 15 Sep 2004 06:46:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20725 for ; Wed, 15 Sep 2004 06:46:36 -0400 (EDT) Received: from mailout.zma.compaq.com ([161.114.64.104] helo=zmamail04.zma.compaq.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7XOF-0000Gz-GJ for dhcwg@ietf.org; Wed, 15 Sep 2004 06:51:55 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 67423502F; Wed, 15 Sep 2004 06:46:02 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Sep 2004 06:46:02 -0400 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 Subject: RE: [dhcwg] Router option, in DHCPv6 Date: Wed, 15 Sep 2004 06:46:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0746451A@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] Router option, in DHCPv6 Thread-Index: AcSa+4x/vCc5HCqISR23GfIDhNgN3AAFBjyw From: "Bound, Jim" To: "Ralph Droms" , "Anil Kumar Reddy" X-OriginalArrivalTime: 15 Sep 2004 10:46:02.0217 (UTC) FILETIME=[319A6D90:01C49B11] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Bernie Volz , Robert Elz 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable IPv6 was designed to support router failover and avoid putting this state in a stateful server. This was extensively discussed back in 1996 and then again in 1998. Here is why and the reason why such idea(s) have been rejected in the past. A host can receive multiple RAs from two different routers. How the host defines its default or preferred route from two routes is implementation defined. Yes there is work for router preferences I realize that, but that is not an issue, as whether that is done or not implicit failover is achieved from the IPv6 link and Neighbor Discovery architecture and protocol messaging. Adding more superferlous state to a stateless link is not congruent with the IPv6 architecture or with existing practice for IPv6 deployment and use cases. I suggest we leave RAs/RSs to routers and stateless, and stateful to DHCPv6 which could be on a platform that can support holding light state or serious heavy weight state like bzillions of records and data. So not only do I not see a compelling reason for this option or thought process, but now after thinking about it believe it is in conflict with the IPv6 architecture principals that are imperative to the proper functioning of nodes for IPv6 deployment in practice. Thanks /jim > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ralph Droms > Sent: Wednesday, September 15, 2004 4:00 AM > To: Anil Kumar Reddy > Cc: dhcwg@ietf.org; 'Bernie Volz'; 'Robert Elz' > Subject: RE: [dhcwg] Router option, in DHCPv6=20 >=20 > Anil - the scenario you describe falls, I think, in the class=20 > of scenarios kre described: >=20 > >But, it might be perhaps useful to be able to configure a particular=20 > >router on a net with several - and perhaps different routers for=20 > >different hosts, which is something that RAs cannot achieve, so the=20 > >option shouldn't necessarily simply be discarded as=20 > completely useless. >=20 > Do we have any reason to believe, at this point, that load=20 > balancing through explicit default router assignment will be=20 > used in practice? >=20 > - Ralph >=20 > At 12:10 PM 9/15/2004 +0530, Anil Kumar Reddy wrote: >=20 > >Thanks for your responses. Sorry for the delay in my response. > > > >I have a question : > >Take a case of load balancing, where two routers present and > > we want to manage/configure few set of hosts (address range) > > to use one router and others to use a different one (two > > paths), how do we achieve this using RAs ? > > > >-- > >Thanks, > >Anil > > > >: -----Original Message----- > >: From: Bernie Volz [mailto:volz@cisco.com] > >: Sent: Saturday, September 11, 2004 7:36 PM > >: To: 'Robert Elz'; 'Anil Kumar Reddy' > >: Cc: dhcwg@ietf.org > >: Subject: RE: [dhcwg] Router option, in DHCPv6 > >: > >: I agree. We do not need this option. > >: > >: If someone can demonstrate a solid need for this (either a > >: list of default routers or list of static routes), we will > >: consider this. But if you have no solid use case, this should > >: be outside the scope of DHCPv6. > >: > >: In IPv4, there was no basic mechanism for a host to find > >: router(s) and to discover whether addresses are on or off > >: link (ICMP messages were added later, but I think they've > >: been little used). This is a basic feature of IPv6. > >: > >: - Bernie > >: > >: > -----Original Message----- > >: > From: dhcwg-bounces@ietf.org > >: [mailto:dhcwg-bounces@ietf.org] On Behalf > >: > Of Robert Elz > >: > Sent: Friday, September 10, 2004 3:00 PM > >: > To: Anil Kumar Reddy > >: > Cc: dhcwg@ietf.org > >: > Subject: Re: [dhcwg] Router option, in DHCPv6 > >: > > >: > > >: > Date: Fri, 10 Sep 2004 19:32:22 +0530 > >: > From: "Anil Kumar Reddy" > >: > Message-ID: <200409101402.TAA29984@iconsrv6.india.hp.com> > >: > > >: > | I feel, having a router configuration option > >: (similar to > >: > | DNS, SIP, NIS) would help the client's network > >: connectivity > >: > | in the absence of RA. > >: > > >: > As a rationale, that's useless. If there are no RAs,=20 > there are no > >: > routers, RAs in v6 aren't optional. > >: > > >: > But, it might be perhaps useful to be able to configure a > >: particular > >: > router on a net with several - and perhaps different routers for > >: > different hosts, which is something that RAs cannot=20 > achieve, so the > >: > option shouldn't necessarily simply be discarded as completely > >: > useless. > >: > > >: > Whether the benefit in allowing this is worth the extra > >: complexity I'm > >: > not sure I'd like to take a position on at the minute. > >: > > >: > kre > >: > > >: > > >: > _______________________________________________ > >: > 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 >=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 Sep 15 09:36:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03084; Wed, 15 Sep 2004 09:36:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Zmn-0001dQ-7a; Wed, 15 Sep 2004 09:25:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Zcy-0007oY-CT for dhcwg@megatron.ietf.org; Wed, 15 Sep 2004 09:15:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01533 for ; Wed, 15 Sep 2004 09:15:14 -0400 (EDT) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7Zi5-0003BS-NN for dhcwg@ietf.org; Wed, 15 Sep 2004 09:20:34 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel11.hp.com (Postfix) with ESMTP id 30C7127C77; Wed, 15 Sep 2004 06:15:11 -0700 (PDT) Received: from l609 (icon5103.india.hp.com [15.42.231.103]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id SAA22666; Wed, 15 Sep 2004 18:45:33 +0530 (IST) Message-Id: <200409151315.SAA22666@iconsrv6.india.hp.com> From: "Anil Kumar Reddy" To: "'Bound, Jim'" , "'Ralph Droms'" Subject: RE: [dhcwg] Router option, in DHCPv6 Date: Wed, 15 Sep 2004 18:45:06 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0746451A@tayexc13.americas.cpqcorp.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSa+4x/vCc5HCqISR23GfIDhNgN3AAFBjywAAPugjA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "'Bernie Volz'" , "'Robert Elz'" 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Jim et. al, : A host can receive multiple RAs from two different : routers. How the host defines its default or preferred route : from two routes is implementation defined. Yes there is work : for router preferences I realize that, but that is not an : issue, as whether that is done or not implicit failover is : achieved from the IPv6 link and Neighbor Discovery : architecture and protocol messaging. This leaves hosts to decide which path to take, so I feel, there is no control over "managing the network". This also makes me to ask one basic question: why do we need stateful, dhcpv6, mechanism ? And, just to be clear from my side, here the case is not with respect to failover mechanism and it is with respect to load balancing/distribution over two paths. Please clarify if I am wrong on any point. -- Thanks, Anil : Adding more : superferlous state to a stateless link is not congruent with : the IPv6 architecture or with existing practice for IPv6 : deployment and use cases. I suggest we leave RAs/RSs to : routers and stateless, and stateful to DHCPv6 which could be : on a platform that can support holding light state or serious : heavy weight state like bzillions of records and data. So : not only do I not see a compelling reason for this option or : thought process, but now after thinking about it believe it : is in conflict with the IPv6 architecture principals that are : imperative to the proper functioning of nodes for IPv6 : deployment in practice. : : Thanks : /jim : : > -----Original Message----- : > From: dhcwg-bounces@ietf.org : [mailto:dhcwg-bounces@ietf.org] On Behalf : > Of Ralph Droms : > Sent: Wednesday, September 15, 2004 4:00 AM : > To: Anil Kumar Reddy : > Cc: dhcwg@ietf.org; 'Bernie Volz'; 'Robert Elz' : > Subject: RE: [dhcwg] Router option, in DHCPv6 : > : > Anil - the scenario you describe falls, I think, in the class of : > scenarios kre described: : > : > >But, it might be perhaps useful to be able to configure a : particular : > >router on a net with several - and perhaps different routers for : > >different hosts, which is something that RAs cannot : achieve, so the : > >option shouldn't necessarily simply be discarded as : > completely useless. : > : > Do we have any reason to believe, at this point, that load : balancing : > through explicit default router assignment will be used in practice? : > : > - Ralph : > : > At 12:10 PM 9/15/2004 +0530, Anil Kumar Reddy wrote: : > : > >Thanks for your responses. Sorry for the delay in my response. : > > : > >I have a question : : > >Take a case of load balancing, where two routers present and : > > we want to manage/configure few set of hosts (address range) : > > to use one router and others to use a different one (two : > > paths), how do we achieve this using RAs ? : > > : > >-- : > >Thanks, : > >Anil : > > : > >: -----Original Message----- : > >: From: Bernie Volz [mailto:volz@cisco.com] : > >: Sent: Saturday, September 11, 2004 7:36 PM : > >: To: 'Robert Elz'; 'Anil Kumar Reddy' : > >: Cc: dhcwg@ietf.org : > >: Subject: RE: [dhcwg] Router option, in DHCPv6 : > >: : > >: I agree. We do not need this option. : > >: : > >: If someone can demonstrate a solid need for this (either a : > >: list of default routers or list of static routes), we will : > >: consider this. But if you have no solid use case, this should : > >: be outside the scope of DHCPv6. : > >: : > >: In IPv4, there was no basic mechanism for a host to find : > >: router(s) and to discover whether addresses are on or off : > >: link (ICMP messages were added later, but I think they've : > >: been little used). This is a basic feature of IPv6. : > >: : > >: - Bernie : > >: : > >: > -----Original Message----- : > >: > From: dhcwg-bounces@ietf.org : > >: [mailto:dhcwg-bounces@ietf.org] On Behalf : > >: > Of Robert Elz : > >: > Sent: Friday, September 10, 2004 3:00 PM : > >: > To: Anil Kumar Reddy : > >: > Cc: dhcwg@ietf.org : > >: > Subject: Re: [dhcwg] Router option, in DHCPv6 : > >: > : > >: > : > >: > Date: Fri, 10 Sep 2004 19:32:22 +0530 : > >: > From: "Anil Kumar Reddy" : > >: > Message-ID: <200409101402.TAA29984@iconsrv6.india.hp.com> : > >: > : > >: > | I feel, having a router configuration option : > >: (similar to : > >: > | DNS, SIP, NIS) would help the client's network : > >: connectivity : > >: > | in the absence of RA. : > >: > : > >: > As a rationale, that's useless. If there are no RAs, : > there are no : > >: > routers, RAs in v6 aren't optional. : > >: > : > >: > But, it might be perhaps useful to be able to configure a : > >: particular : > >: > router on a net with several - and perhaps different : routers for : > >: > different hosts, which is something that RAs cannot : > achieve, so the : > >: > option shouldn't necessarily simply be discarded as completely : > >: > useless. : > >: > : > >: > Whether the benefit in allowing this is worth the extra : > >: complexity I'm : > >: > not sure I'd like to take a position on at the minute. : > >: > : > >: > kre : > >: > : > >: > : > >: > _______________________________________________ : > >: > 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 Wed Sep 15 09:55:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04539; Wed, 15 Sep 2004 09:55:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7a3G-0006CT-Ue; Wed, 15 Sep 2004 09:42:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7Zxy-0004Kn-C0 for dhcwg@megatron.ietf.org; Wed, 15 Sep 2004 09:36:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03126 for ; Wed, 15 Sep 2004 09:36:56 -0400 (EDT) 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.33) id 1C7a35-0003bD-Nm for dhcwg@ietf.org; Wed, 15 Sep 2004 09:42:16 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2004 06:47:12 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i8FDaKwY002344; Wed, 15 Sep 2004 06:36:23 -0700 (PDT) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALO16642; Wed, 15 Sep 2004 09:36:19 -0400 (EDT) From: "Bernie Volz" To: "'Anil Kumar Reddy'" , "'Bound, Jim'" , "'Ralph Droms'" Subject: RE: [dhcwg] Router option, in DHCPv6 Date: Wed, 15 Sep 2004 09:36:18 -0400 Organization: Cisco Message-ID: <000201c49b28$fb68c100$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <200409151315.SAA22666@iconsrv6.india.hp.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "'Robert Elz'" 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit How about this: Inbound load balancing - Nodes with replicated interfaces may want to load balance the reception of incoming packets across multiple network interfaces on the same link. Such nodes have multiple link-layer addresses assigned to the same interface. For example, a single network driver could represent multiple network interface cards as a single logical interface having multiple link-layer addresses. --> Load balancing is handled by allowing routers to omit the --> source link-layer address from Router Advertisement packets, --> thereby forcing neighbors to use Neighbor Solicitation --> messages to learn link-layer addresses of routers. Returned --> Neighbor Advertisement messages can then contain link-layer --> addresses that differ depending on who issued the --> solicitation. See http://www.ietf.org/internet-drafts/draft-ietf-ipv6-2461bis-00.txt. There is no need to duplicate functionality that already exists elsewhere. - Bernie Volz > -----Original Message----- > From: Anil Kumar Reddy [mailto:sakreddy@india.hp.com] > Sent: Wednesday, September 15, 2004 9:15 AM > To: 'Bound, Jim'; 'Ralph Droms' > Cc: dhcwg@ietf.org; 'Bernie Volz'; 'Robert Elz' > Subject: RE: [dhcwg] Router option, in DHCPv6 > > > Jim et. al, > > : A host can receive multiple RAs from two different > : routers. How the host defines its default or preferred route > : from two routes is implementation defined. Yes there is work > : for router preferences I realize that, but that is not an > : issue, as whether that is done or not implicit failover is > : achieved from the IPv6 link and Neighbor Discovery > : architecture and protocol messaging. > > This leaves hosts to decide which path to take, so I feel, > there is no control over "managing the network". This also > makes me to ask one basic question: why do we need stateful, > dhcpv6, mechanism ? > > And, just to be clear from my side, here the case is not with > respect to failover mechanism and it is with respect to load > balancing/distribution over two paths. > > Please clarify if I am wrong on any point. > > -- > Thanks, > Anil > > : Adding more > : superferlous state to a stateless link is not congruent with > : the IPv6 architecture or with existing practice for IPv6 > : deployment and use cases. I suggest we leave RAs/RSs to > : routers and stateless, and stateful to DHCPv6 which could be > : on a platform that can support holding light state or serious > : heavy weight state like bzillions of records and data. So > : not only do I not see a compelling reason for this option or > : thought process, but now after thinking about it believe it > : is in conflict with the IPv6 architecture principals that are > : imperative to the proper functioning of nodes for IPv6 > : deployment in practice. > : > : Thanks > : /jim > : > : > -----Original Message----- > : > From: dhcwg-bounces@ietf.org > : [mailto:dhcwg-bounces@ietf.org] On Behalf > : > Of Ralph Droms > : > Sent: Wednesday, September 15, 2004 4:00 AM > : > To: Anil Kumar Reddy > : > Cc: dhcwg@ietf.org; 'Bernie Volz'; 'Robert Elz' > : > Subject: RE: [dhcwg] Router option, in DHCPv6 > : > > : > Anil - the scenario you describe falls, I think, in the class of > : > scenarios kre described: > : > > : > >But, it might be perhaps useful to be able to configure a > : particular > : > >router on a net with several - and perhaps different routers for > : > >different hosts, which is something that RAs cannot > : achieve, so the > : > >option shouldn't necessarily simply be discarded as > : > completely useless. > : > > : > Do we have any reason to believe, at this point, that load > : balancing > : > through explicit default router assignment will be used > in practice? > : > > : > - Ralph > : > > : > At 12:10 PM 9/15/2004 +0530, Anil Kumar Reddy wrote: > : > > : > >Thanks for your responses. Sorry for the delay in my response. > : > > > : > >I have a question : > : > >Take a case of load balancing, where two routers present and > : > > we want to manage/configure few set of hosts (address range) > : > > to use one router and others to use a different one (two > : > > paths), how do we achieve this using RAs ? > : > > > : > >-- > : > >Thanks, > : > >Anil > : > > > : > >: -----Original Message----- > : > >: From: Bernie Volz [mailto:volz@cisco.com] > : > >: Sent: Saturday, September 11, 2004 7:36 PM > : > >: To: 'Robert Elz'; 'Anil Kumar Reddy' > : > >: Cc: dhcwg@ietf.org > : > >: Subject: RE: [dhcwg] Router option, in DHCPv6 > : > >: > : > >: I agree. We do not need this option. > : > >: > : > >: If someone can demonstrate a solid need for this (either a > : > >: list of default routers or list of static routes), we will > : > >: consider this. But if you have no solid use case, this should > : > >: be outside the scope of DHCPv6. > : > >: > : > >: In IPv4, there was no basic mechanism for a host to find > : > >: router(s) and to discover whether addresses are on or off > : > >: link (ICMP messages were added later, but I think they've > : > >: been little used). This is a basic feature of IPv6. > : > >: > : > >: - Bernie > : > >: > : > >: > -----Original Message----- > : > >: > From: dhcwg-bounces@ietf.org > : > >: [mailto:dhcwg-bounces@ietf.org] On Behalf > : > >: > Of Robert Elz > : > >: > Sent: Friday, September 10, 2004 3:00 PM > : > >: > To: Anil Kumar Reddy > : > >: > Cc: dhcwg@ietf.org > : > >: > Subject: Re: [dhcwg] Router option, in DHCPv6 > : > >: > > : > >: > > : > >: > Date: Fri, 10 Sep 2004 19:32:22 +0530 > : > >: > From: "Anil Kumar Reddy" > : > >: > Message-ID: > <200409101402.TAA29984@iconsrv6.india.hp.com> > : > >: > > : > >: > | I feel, having a router configuration option > : > >: (similar to > : > >: > | DNS, SIP, NIS) would help the client's network > : > >: connectivity > : > >: > | in the absence of RA. > : > >: > > : > >: > As a rationale, that's useless. If there are no RAs, > : > there are no > : > >: > routers, RAs in v6 aren't optional. > : > >: > > : > >: > But, it might be perhaps useful to be able to configure a > : > >: particular > : > >: > router on a net with several - and perhaps different > : routers for > : > >: > different hosts, which is something that RAs cannot > : > achieve, so the > : > >: > option shouldn't necessarily simply be discarded as > completely > : > >: > useless. > : > >: > > : > >: > Whether the benefit in allowing this is worth the extra > : > >: complexity I'm > : > >: > not sure I'd like to take a position on at the minute. > : > >: > > : > >: > kre > : > >: > > : > >: > > : > >: > _______________________________________________ > : > >: > 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 Wed Sep 15 10:54:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10367; Wed, 15 Sep 2004 10:54:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7awA-0007Yp-Li; Wed, 15 Sep 2004 10:39:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7at3-0006mU-WC for dhcwg@megatron.ietf.org; Wed, 15 Sep 2004 10:35:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09120 for ; Wed, 15 Sep 2004 10:35:55 -0400 (EDT) Received: from zmamail04.zma.compaq.com ([161.114.64.104]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7ayA-0004p0-C1 for dhcwg@ietf.org; Wed, 15 Sep 2004 10:41:16 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 415F45CEE; Wed, 15 Sep 2004 10:35:23 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Sep 2004 10:35:22 -0400 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 Subject: RE: [dhcwg] Router option, in DHCPv6 Date: Wed, 15 Sep 2004 10:35:21 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0746459E@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] Router option, in DHCPv6 Thread-Index: AcSa+4x/vCc5HCqISR23GfIDhNgN3AAFBjywAAPugjAABDw8AA== From: "Bound, Jim" To: "Anil Kumar Reddy" , "Ralph Droms" X-OriginalArrivalTime: 15 Sep 2004 14:35:22.0943 (UTC) FILETIME=[3BA294F0:01C49B31] X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org, Bernie Volz , Robert Elz 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Anil, In addition to what Bernie provided.=20 > : A host can receive multiple RAs from two different > : routers. How the host defines its default or preferred route > : from two routes is implementation defined. Yes there is work > : for router preferences I realize that, but that is not an > : issue, as whether that is done or not implicit failover is > : achieved from the IPv6 link and Neighbor Discovery > : architecture and protocol messaging. >=20 > This leaves hosts to decide which path to take, so I feel,=20 > there is no control over "managing the network". This also=20 > makes me to ask one basic question: why do we need stateful,=20 > dhcpv6, mechanism ? Only in the sense to select a default route which is correct for the host to do. If it does no want to do that it will use last-in-first-default method. But route preference and default route as I said is in discussion. Statful is in my humble opinion for managers who will not permit stateless to be used for address assignment and only for neighbor discovery processing. Many IT net admin/managers do not want routers to give out nodes addresses we are finding in deployment. I will not discuss there reasons its none of my business its their networks and they are in charge of their networks so lets not go there. Stateful also provides support for other configuration parameters for the network not in neighbor discovery and now prefix delegation. So DHCPv6 has many benefits for IPv6. >=20 > And, just to be clear from my side, here the case is not with=20 > respect to failover mechanism and it is with respect to load=20 > balancing/distribution over two paths. Bernie answered that. >=20 > Please clarify if I am wrong on any point. Not wrong just maybe do not have all views of IPv6 efforts. Also DHCPv6 WG should not be altering the base connectivity and interoperability of the link on this list this is for IPv6 WG and would have to approve. But don't go there if you loose the battle here and give up, without DHCPv6 support for your idea your not on solid ground and this is good place to run the idea don't get my view wrong. Thanks /jim >=20 > -- > Thanks, > Anil >=20 > : Adding more > : superferlous state to a stateless link is not congruent with > : the IPv6 architecture or with existing practice for IPv6 > : deployment and use cases. I suggest we leave RAs/RSs to > : routers and stateless, and stateful to DHCPv6 which could be > : on a platform that can support holding light state or serious > : heavy weight state like bzillions of records and data. So > : not only do I not see a compelling reason for this option or > : thought process, but now after thinking about it believe it > : is in conflict with the IPv6 architecture principals that are > : imperative to the proper functioning of nodes for IPv6 > : deployment in practice. > :=20 > : Thanks > : /jim > :=20 > : > -----Original Message----- > : > From: dhcwg-bounces@ietf.org > : [mailto:dhcwg-bounces@ietf.org] On Behalf > : > Of Ralph Droms > : > Sent: Wednesday, September 15, 2004 4:00 AM > : > To: Anil Kumar Reddy > : > Cc: dhcwg@ietf.org; 'Bernie Volz'; 'Robert Elz' > : > Subject: RE: [dhcwg] Router option, in DHCPv6 > : > > : > Anil - the scenario you describe falls, I think, in the class of > : > scenarios kre described: > : > > : > >But, it might be perhaps useful to be able to configure a > : particular > : > >router on a net with several - and perhaps different routers for > : > >different hosts, which is something that RAs cannot > : achieve, so the > : > >option shouldn't necessarily simply be discarded as > : > completely useless. > : > > : > Do we have any reason to believe, at this point, that load > : balancing > : > through explicit default router assignment will be used=20 > in practice? > : > > : > - Ralph > : > > : > At 12:10 PM 9/15/2004 +0530, Anil Kumar Reddy wrote: > : > > : > >Thanks for your responses. Sorry for the delay in my response. > : > > > : > >I have a question : > : > >Take a case of load balancing, where two routers present and > : > > we want to manage/configure few set of hosts (address range) > : > > to use one router and others to use a different one (two > : > > paths), how do we achieve this using RAs ? > : > > > : > >-- > : > >Thanks, > : > >Anil > : > > > : > >: -----Original Message----- > : > >: From: Bernie Volz [mailto:volz@cisco.com] > : > >: Sent: Saturday, September 11, 2004 7:36 PM > : > >: To: 'Robert Elz'; 'Anil Kumar Reddy' > : > >: Cc: dhcwg@ietf.org > : > >: Subject: RE: [dhcwg] Router option, in DHCPv6 > : > >: > : > >: I agree. We do not need this option. > : > >: > : > >: If someone can demonstrate a solid need for this (either a > : > >: list of default routers or list of static routes), we will > : > >: consider this. But if you have no solid use case, this should > : > >: be outside the scope of DHCPv6. > : > >: > : > >: In IPv4, there was no basic mechanism for a host to find > : > >: router(s) and to discover whether addresses are on or off > : > >: link (ICMP messages were added later, but I think they've > : > >: been little used). This is a basic feature of IPv6. > : > >: > : > >: - Bernie > : > >: > : > >: > -----Original Message----- > : > >: > From: dhcwg-bounces@ietf.org > : > >: [mailto:dhcwg-bounces@ietf.org] On Behalf > : > >: > Of Robert Elz > : > >: > Sent: Friday, September 10, 2004 3:00 PM > : > >: > To: Anil Kumar Reddy > : > >: > Cc: dhcwg@ietf.org > : > >: > Subject: Re: [dhcwg] Router option, in DHCPv6 > : > >: > > : > >: > > : > >: > Date: Fri, 10 Sep 2004 19:32:22 +0530 > : > >: > From: "Anil Kumar Reddy" > : > >: > Message-ID: =20 > <200409101402.TAA29984@iconsrv6.india.hp.com> > : > >: > > : > >: > | I feel, having a router configuration option > : > >: (similar to > : > >: > | DNS, SIP, NIS) would help the client's network > : > >: connectivity > : > >: > | in the absence of RA. > : > >: > > : > >: > As a rationale, that's useless. If there are no RAs,=20 > : > there are no > : > >: > routers, RAs in v6 aren't optional. > : > >: > > : > >: > But, it might be perhaps useful to be able to configure a > : > >: particular > : > >: > router on a net with several - and perhaps different > : routers for > : > >: > different hosts, which is something that RAs cannot > : > achieve, so the > : > >: > option shouldn't necessarily simply be discarded as=20 > completely > : > >: > useless. > : > >: > > : > >: > Whether the benefit in allowing this is worth the extra > : > >: complexity I'm > : > >: > not sure I'd like to take a position on at the minute. > : > >: > > : > >: > kre > : > >: > > : > >: > > : > >: > _______________________________________________ > : > >: > 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 > : > > :=20 > :=20 >=20 >=20 >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Sep 24 15:58:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10460; Fri, 24 Sep 2004 15:58:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAvz1-0006bM-Az; Fri, 24 Sep 2004 15:43:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAvsV-0003eg-QM; Fri, 24 Sep 2004 15:37:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08740; Fri, 24 Sep 2004 15:37:10 -0400 (EDT) Message-Id: <200409241937.PAA08740@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 24 Sep 2004 15:37:10 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-fqdn-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: , Sender: dhcwg-bounces@ietf.org 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 : The DHCPv6 Client FQDN Option Author(s) : B. Volz Filename : draft-ietf-dhc-dhcpv6-fqdn-00.txt Pages : 12 Date : 2004-9-24 This document specifies a new DHCP for IPv6, DHCPv6, option which can be used to exchange information about a DHCPv6 client's fully-qualified domain name and about responsibility for updating DNS RRs related to the client's address assignments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-00.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-dhcpv6-fqdn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-24145732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-fqdn-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-24145732.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Sat Sep 25 09:36:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26853; Sat, 25 Sep 2004 09:36:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBCek-0005fO-Na; Sat, 25 Sep 2004 09:32:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7bba-0005TB-Rr; Wed, 15 Sep 2004 11:21:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11804; Wed, 15 Sep 2004 11:21:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7bgj-0005ar-Jq; Wed, 15 Sep 2004 11:27:17 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1C7bXW-0004qZ-Hv; Wed, 15 Sep 2004 11:17:46 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Wed, 15 Sep 2004 11:17:46 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Sat, 25 Sep 2004 09:32:05 -0400 Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Protocol Action: 'DHCP Subscriber ID Suboption for the DHCP Relay Agent Option' to Proposed Standard 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'DHCP Subscriber ID Suboption for the DHCP Relay Agent Option ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary This memo defines a new Subscriber-ID suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable "Subscriber-ID" with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure. Working Group Summary This document is the work output of the DHC WG. The WG has consensus to advance this document. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Sep 25 09:37:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26989; Sat, 25 Sep 2004 09:37:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBCel-0005fT-0z; Sat, 25 Sep 2004 09:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9VLZ-0002hu-V1; Mon, 20 Sep 2004 17:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20547; Mon, 20 Sep 2004 17:05:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9VRo-0001ov-JJ; Mon, 20 Sep 2004 17:11:44 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1C9UI1-0004st-0g; Mon, 20 Sep 2004 15:57:33 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 20 Sep 2004 15:57:33 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Sat, 25 Sep 2004 09:32:05 -0400 Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Protocol Action: 'The Authentication Suboption for the DHCP Relay Agent Option' to Proposed Standard 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'The Authentication Suboption for the DHCP Relay Agent Option ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option which supports source entity authentication and data integrity for relayed DHCP messages. The authentication suboption contains a cryptographic signature in its payload. Working Group Summary This is a work item of the DHCP WG. There was WG consensus to advance this work. While working on this draft and the related draft draft-ietf-dhc-relay-agent-ipsec, there was extensive discussion in the WG regarding which should be "mandatory to implement". The WG reached a conclusion that there are valid reasons to prefer either choice, and they have chosen to proceed with to draft, both optional to implement (since relay agents are widely deployed today with no authentication). We are working on wording that will explain this choice in response to Allison's discuss on the relay-agent-ipsec document, and will include corresponding wording here when that issue is resolved. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sat Sep 25 09:41:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27139; Sat, 25 Sep 2004 09:41:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CBCel-0005fY-Af; Sat, 25 Sep 2004 09:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CAu5v-0003Ws-EC; Fri, 24 Sep 2004 13:42:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00999; Fri, 24 Sep 2004 13:42:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CAuCx-0007gH-Ri; Fri, 24 Sep 2004 13:50:12 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CAtz7-0000dv-OG; Fri, 24 Sep 2004 13:35:53 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 24 Sep 2004 13:35:53 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Sat, 25 Sep 2004 09:32:05 -0400 Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Protocol Action: 'RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option' to Proposed Standard 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary A NAS (network access server) may choose to authenticate the identity of a device before granting that device access to the network. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access. A network element using RADIUS as an authentication authority will receive attributes from a RADIUS server that may be used by a DHCP server in the selection of configuration parameters to be delivered to sub-option enables a network element to pass along attributes for the user of a device received during RADIUS authentication to a DHCP server. Working Group Summary This document is the work of the DHCP WG. It was reviewed extesively by Bernard Aboba during AD review and IETF Last Call. Protocol Quality This document was reviews for the IESG by Margaret Wasserman. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Sep 27 16:18:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28153; Mon, 27 Sep 2004 16:18:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1lY-000748-DQ; Mon, 27 Sep 2004 16:06:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC1hd-0004ws-Mz; Mon, 27 Sep 2004 16:02:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26923; Mon, 27 Sep 2004 16:02:27 -0400 (EDT) Message-Id: <200409272002.QAA26923@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 27 Sep 2004 16:02:27 -0400 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subnet-alloc-01.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: , Sender: dhcwg-bounces@ietf.org 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 : Subnet Allocation using DHCP Author(s) : R. Johnson, et al. Filename : draft-ietf-dhc-subnet-alloc-01.txt Pages : 24 Date : 2004-9-27 This document defines a new DHCP option which is passed between the DHCP Client to the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subnet-alloc-01.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-subnet-alloc-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-subnet-alloc-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-9-27151414.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subnet-alloc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subnet-alloc-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-9-27151414.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Tue Sep 28 01:42:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13912; Tue, 28 Sep 2004 01:42:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCAj3-0001cQ-UK; Tue, 28 Sep 2004 01:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCAhS-0001Pk-0K for dhcwg@megatron.ietf.org; Tue, 28 Sep 2004 01:38:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13677 for ; Tue, 28 Sep 2004 01:38:52 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCAos-0001ld-62 for dhcwg@ietf.org; Tue, 28 Sep 2004 01:46:56 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8S5cSWL026789 for ; Tue, 28 Sep 2004 14:38:28 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8S5cS0g006741 for ; Tue, 28 Sep 2004 14:38:28 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8S5cRmY006736 for ; Tue, 28 Sep 2004 14:38:27 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8S5cR1l012237 for ; Tue, 28 Sep 2004 14:38:27 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8S5cQw8012230 for ; Tue, 28 Sep 2004 14:38:26 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8S5cQ1N012284 for ; Tue, 28 Sep 2004 14:38:26 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8S5cP47007944 for ; Tue, 28 Sep 2004 14:38:26 +0900 (JST) Received: from imk.m.ecl.ntt.co.jp (imk0.m.ecl.ntt.co.jp [129.60.5.149]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8S5cPL7007940 for ; Tue, 28 Sep 2004 14:38:25 +0900 (JST) Received: from [129.60.10.235] by imk.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id OAA15682 for ; Tue, 28 Sep 2004 14:38:25 +0900 (JST) Date: Tue, 28 Sep 2004 14:38:24 +0900 From: "OTA Masazumi" To: dhcwg@ietf.org Message-Id: <20040928141444.114A.OOTA.MASAZUMI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.04 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Relay Agent Behavior 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, Could you please answer my question about Relay Agent Behavior? The 2nd paragraph of section 20 in RFC3315 is: "If the relay agent relays messages to the All_DHCP_Servers multicast address or other multicast addresses, it sets the Hop Limit field to 32." I think that a relay agent cannot receive the relay message transmitted by the All_DHCP_Servers multicast address because the relay agent does not belong to the All_DHCP_SERVERS multicast address. What might situation be relay the message to the All_DHCP_SERVERS multicast address by the relay agent? Masazumi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Sep 28 08:25:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17436; Tue, 28 Sep 2004 08:25:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCGsD-0003t7-TX; Tue, 28 Sep 2004 08:14:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCGmg-0003CD-GY for dhcwg@megatron.ietf.org; Tue, 28 Sep 2004 08:08:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16305 for ; Tue, 28 Sep 2004 08:08:41 -0400 (EDT) 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.33) id 1CCGuU-00085j-Mq for dhcwg@ietf.org; Tue, 28 Sep 2004 08:16:48 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Sep 2004 05:21:29 +0000 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8SC81wp007967; Tue, 28 Sep 2004 05:08:02 -0700 (PDT) Received: from volzw2k (che-vpn-cluster-1-189.cisco.com [10.86.240.189]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALW54973; Tue, 28 Sep 2004 08:08:05 -0400 (EDT) From: "Bernie Volz" To: "'OTA Masazumi'" , Subject: RE: [dhcwg] Relay Agent Behavior Date: Tue, 28 Sep 2004 08:08:05 -0400 Organization: Cisco Message-ID: <000a01c4a553$cfce9f30$6401a8c0@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <20040928141444.114A.OOTA.MASAZUMI@lab.ntt.co.jp> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I believe this is referring to the Hop Limit at the IPv6 layer, not = anything in the DHCPv6 packet itself. This allows DHCPv6 servers that may be several (up to 32) routing hops = away to receive the multicast message. You are correct that the All_DHCP_Servers does not include relays. And, = this is important since we don't want a multicast storm! - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of OTA Masazumi > Sent: Tuesday, September 28, 2004 1:38 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Relay Agent Behavior >=20 >=20 > Hello, >=20 > Could you please answer my question about Relay Agent Behavior? >=20 > The 2nd paragraph of section 20 in RFC3315 is: >=20 > "If the relay agent relays messages to the All_DHCP_Servers=20 > multicast address or other multicast addresses, it sets the=20 > Hop Limit field to 32." >=20 > I think that a relay agent cannot receive the relay message=20 > transmitted by the All_DHCP_Servers multicast address because=20 > the relay agent does not belong to the All_DHCP_SERVERS=20 > multicast address. What might situation be relay the message=20 > to the All_DHCP_SERVERS multicast address by the relay agent?=20 >=20 > Masazumi >=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 Tue Sep 28 08:40:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18210; Tue, 28 Sep 2004 08:40:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCH8r-0006u1-M4; Tue, 28 Sep 2004 08:31:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCH40-0006GY-LN for dhcwg@megatron.ietf.org; Tue, 28 Sep 2004 08:26:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17540 for ; Tue, 28 Sep 2004 08:26:35 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCHBo-0008VK-5p for dhcwg@ietf.org; Tue, 28 Sep 2004 08:34:42 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8SCQV05019414 for ; Tue, 28 Sep 2004 21:26:31 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8SCQUXs022448 for ; Tue, 28 Sep 2004 21:26:30 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8SCQUbu022443 for ; Tue, 28 Sep 2004 21:26:30 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8SCQTJI028881 for ; Tue, 28 Sep 2004 21:26:29 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8SCQToI028878 for ; Tue, 28 Sep 2004 21:26:29 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8SCQT7w008632 for ; Tue, 28 Sep 2004 21:26:29 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8SCQSac015753 for ; Tue, 28 Sep 2004 21:26:28 +0900 (JST) Received: from imk.m.ecl.ntt.co.jp (imk0.m.ecl.ntt.co.jp [129.60.5.149]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i8SCQSsQ015743 for ; Tue, 28 Sep 2004 21:26:28 +0900 (JST) Received: from [129.60.10.235] by imk.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id VAA17417 for ; Tue, 28 Sep 2004 21:26:28 +0900 (JST) Date: Tue, 28 Sep 2004 21:26:27 +0900 From: =?ISO-2022-JP?B?Ik9UQSBNYXNhenVtaS8bJEJCQEVEQDU9YxsoQg==?= =?ISO-2022-JP?B?Ig==?= To: Subject: Re: [dhcwg] Relay Agent Behavior In-Reply-To: <000a01c4a553$cfce9f30$6401a8c0@amer.cisco.com> References: <20040928141444.114A.OOTA.MASAZUMI@lab.ntt.co.jp> <000a01c4a553$cfce9f30$6401a8c0@amer.cisco.com> Message-Id: <20040928212254.047F.OOTA.MASAZUMI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.07.04 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit I understood this context very well. Thank you very much. -Masazumi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 29 08:49:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29027; Wed, 29 Sep 2004 08:49:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdje-0006QF-Re; Wed, 29 Sep 2004 08:39:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdZN-0004KF-C3 for dhcwg@megatron.ietf.org; Wed, 29 Sep 2004 08:28:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27181; Wed, 29 Sep 2004 08:28:27 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCdhO-0005Bx-6v; Wed, 29 Sep 2004 08:36:47 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 29 Sep 2004 05:28:33 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i8TCRm3c026435; Wed, 29 Sep 2004 05:27:48 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn2-1000.cisco.com [10.21.115.232]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALX41097; Wed, 29 Sep 2004 08:27:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20040929082535.0208b558@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Sep 2004 08:27:42 -0400 To: agenda@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: margaret@thingmagic.com, narten@us.ibm.com, dhcwg@ietf.org Subject: [dhcwg] dhc WG agenda request for IETF 61 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I request one 2.5 hour slot for the dhc WG during IETF 61. 4. You MUST provide the following information before the meeting will be scheduled: a. Working Group or BOF full name with acronym in brackets: Dynamic Host Configuration WG [dhc] b. AREA under which Working Group or BOF appears: Internet c. CONFLICTS you wish to avoid, please be as specific as possible: dna, dnsext, dnsop, geopriv, ipcdn, ipv6, manet, mip6, nemo, netconf, v6ops d. Expected Attendance: 100 e. Special requests (i.e. multicast): Multicast f. Number of slots: 1 g. Length of slot: - 1 hour - 2 hours X - 2 1/2 hours _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 29 09:02:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29836; Wed, 29 Sep 2004 09:02:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdoX-0008MD-Iz; Wed, 29 Sep 2004 08:44:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdgW-0005nu-4B for dhcwg@megatron.ietf.org; Wed, 29 Sep 2004 08:35:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27955 for ; Wed, 29 Sep 2004 08:35:50 -0400 (EDT) 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.33) id 1CCdoX-0005LJ-Ay for dhcwg@ietf.org; Wed, 29 Sep 2004 08:44:10 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Sep 2004 05:38:53 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8TCZFwp004382 for ; Wed, 29 Sep 2004 05:35:16 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn2-1000.cisco.com [10.21.115.232]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALX41413; Wed, 29 Sep 2004 08:35:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20040929083444.0209aa10@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Sep 2004 08:35:10 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [dhcwg] Agenda for dhc WG meeting at IETF 61 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org It's time to start thinking about our agenda for the WG meeting in Washington, DC. Please let me know if you have an item you would like to see on the agenda. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 29 09:15:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01035; Wed, 29 Sep 2004 09:15:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCeAj-0004O2-6N; Wed, 29 Sep 2004 09:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCdsF-0000mK-OL for dhcwg@megatron.ietf.org; Wed, 29 Sep 2004 08:47:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28789 for ; Wed, 29 Sep 2004 08:47:58 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCe0H-0005cE-8k for dhcwg@ietf.org; Wed, 29 Sep 2004 08:56:18 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 29 Sep 2004 08:47:27 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8TClP7A019783 for ; Wed, 29 Sep 2004 08:47:26 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn2-1000.cisco.com [10.21.115.232]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALX42029; Wed, 29 Sep 2004 08:47:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20040929084505.01f60d48@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Sep 2004 08:47:21 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [dhcwg] Important dates for IETF 61 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org October 11, Monday - WG Chair approval for initial WG document (Version -00) submission due by 09:00 ET October 18, Monday - Internet Draft Cut-off for initial document (-00) submission at 09:00 ET October 25, Monday - Working Group and BOF scheduling closes at 17:00 ET October 25, Monday - Internet Draft final submission cut-off at 09:00 ET October 27, Wednesday - Pre-Registration and Pre-payment cut-off at 12:00 noon ET _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Sep 29 10:41:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09658; Wed, 29 Sep 2004 10:41:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCfKe-0007Db-Tj; Wed, 29 Sep 2004 10:21:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCe3A-0002TX-OM for dhcwg@megatron.ietf.org; Wed, 29 Sep 2004 08:59:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29619 for ; Wed, 29 Sep 2004 08:59:14 -0400 (EDT) Received: from [61.135.132.105] (helo=smtp119.sohu.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCeBC-0005rg-Fh for dhcwg@ietf.org; Wed, 29 Sep 2004 09:07:35 -0400 Received: from exp (unknown [219.236.35.78]) by smtp119.sohu.com (Postfix) with ESMTP id 41696060BBC for ; Wed, 29 Sep 2004 20:58:37 +0800 (CST) Message-ID: <000701c4a624$35b19340$4e23ecdb@exp> From: "Xu Peng" To: Date: Wed, 29 Sep 2004 20:59:44 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.6 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Wed, 29 Sep 2004 10:21:23 -0400 Subject: [dhcwg] A 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: , Content-Type: multipart/mixed; boundary="===============1446836027==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1446836027== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGmjrA0KDQpJIGhhdmUgYSBxdWVzdGlvbiBhYm91dCB0aGUgY29uZmlndXJhdGlvbiBvbiBTb2xh cmlzLg0KDQpUaGUgZm9sbG93aW5nIGlzIHRoZSByZXF1aXJlbWVudC4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoZXJlIGlzIGEgREhDUCBzZXJ2ZXIoMTcyLjEuMS4x KSBpbiB0aGUgbmV0d29yayBhbmQgdGhlIE9TIGlzIFNvbGFyaXMgOC4gQW5kIHRoZXJlIGFyZSAz IHByb3h5KG9yIHN3aXRjaCB3aXRoIGEgSVAgMTcyLjIuMS4xKS4gQSBsb3Qgb2YgUEMgY29ubmVj dCB0byB0aGUgREhDUCBzZXJ2ZXIgdGhyb3VnaCBhIGNlcnRhaW4gcHJveHkuIEFuZCBJIHdhbnQg dG8gc2V0IGEgSVAgcG9vbCBhcyAxMC4xMC4xMC4wLDEwLjEwLjIwLjAsMTAuMTAuMzAuMCBzZXBh cmF0ZWx5LiBOYW1lZCB0aGUgMyBwcm94eSBhcyBBLEIsQy4gVGhlbiB0aG9zZSBQQ3MgY29ubmVj dGVkIHRvIERIQ1AgdGhyb3VnaCBBIGNhbiBvYnRhaW4gdGhlIElQIGluIHRoZSByYW5nZSBvZiBu ZXR3b3JrIDEwLjEwLjEwLjAsIHRob3NlIGNvbm5lY3RlZCB0byB0aGUgREhDUCB0aHJvdWdoIEIg Y2FuIG9idGFpbiB0aGUgSVAgYWRkcmVzcyBsaWtlIDEwLjEwLjIwLjYuDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpIb3cgdG8gcmVhbGl6ZSB0aGF0Pw0KDQpM b29raW5nIGZvcndhcmQgdG8geW91ciBmZWVkYmFjay4NClRoYW5rcyBhIGxvdC4NCg0KWHUgUGVu Zw== --===============1446836027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1446836027==-- From dhcwg-bounces@ietf.org Wed Sep 29 14:00:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23677; Wed, 29 Sep 2004 14:00:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCiZF-0007pp-SA; Wed, 29 Sep 2004 13:48:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCiPC-0002mr-7v for dhcwg@megatron.ietf.org; Wed, 29 Sep 2004 13:38:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21933 for ; Wed, 29 Sep 2004 13:38:14 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCiXD-0003LL-Ap for dhcwg@ietf.org; Wed, 29 Sep 2004 13:46:39 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2004 13:55:10 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i8THbc7C016561 for ; Wed, 29 Sep 2004 13:37:40 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.249]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALX68736; Wed, 29 Sep 2004 13:37:37 -0400 (EDT) Message-Id: <4.3.2.7.2.20040929133644.020c8358@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Sep 2004 13:37:35 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [dhcwg] dhc WG meeting in DC 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Looks like we're back to our traditional Mon AM slot: DHC is currently scheduled on Monday, November 8 at 0900-1130 - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 30 10:52:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27835; Thu, 30 Sep 2004 10:52:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD2AQ-0002dZ-NN; Thu, 30 Sep 2004 10:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD1tf-0007Ed-2H for dhcwg@megatron.ietf.org; Thu, 30 Sep 2004 10:27:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25868 for ; Thu, 30 Sep 2004 10:27:00 -0400 (EDT) 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.33) id 1CD21u-0000vW-4s for dhcwg@ietf.org; Thu, 30 Sep 2004 10:35:35 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 30 Sep 2004 07:33:07 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8UEQAm5020602 for ; Thu, 30 Sep 2004 07:26:26 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.249]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALY31511; Thu, 30 Sep 2004 10:22:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20040930101848.022c2128@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Sep 2004 10:22:46 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [dhcwg] Fwd: [dnsop] new WGLC on "IPv6 Host Configuration of DNS Server Information Approaches" 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org FYI ... this dnsop WG last call may be of interest to dhc WG members as it discusses issues related to configuration of DNS recursive name servers and the DHCPv6 DNS configuration options defined in RFC 3646. Please direct any comments to the dnsop@lists.uoregon.edu mailing list - Ralph ===== To: dnsop@lists.uoregon.edu Subject: [dnsop] new WGLC on "IPv6 Host Configuration of DNS Server Information Approaches" Folks This note starts the (hopefully last) WG Last Call for comments on draft-ietf-dnsop-ipv6-dns-configuration-04.txt, "IPv6 Host Configuration of DNS Server Information Approaches". It can be found on ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-configuration-04.txt Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. Note that this is a somewhat unusal case as the IESG requested this document. This Last Call will end on 14 Oct 2004 at 1400 PDT (UTC/GMT-7). Thanks, Dave dh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 30 11:38:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01354; Thu, 30 Sep 2004 11:38:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD2cZ-0002Ar-U1; Thu, 30 Sep 2004 11:13:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD2Q6-0007GE-Q6 for dhcwg@megatron.ietf.org; Thu, 30 Sep 2004 11:00:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28588 for ; Thu, 30 Sep 2004 11:00:32 -0400 (EDT) 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.33) id 1CD2YM-0001oa-Aa for dhcwg@ietf.org; Thu, 30 Sep 2004 11:09:07 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 30 Sep 2004 08:03:51 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8UExvlr028261 for ; Thu, 30 Sep 2004 07:59:58 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.249]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALY34949; Thu, 30 Sep 2004 10:59:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20040930102330.0209e8f0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Sep 2004 10:59:55 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [dhcwg] IPv6 tunnelling options for IPv4 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I've been reviewing draft-daniel-dhc-ipv6in4-opt-04.txt - does draft-daniel-dhc-ipv6in4-opt-04.txt specify "configured IPv6-over-IPv4 tunneling", as described in section 4 of RFC 2893? If so, it would be helpful to include a specific reference, as there are numerous tunneling and "IPv6-xxx-IPv4" transition mechanisms... I can imagine the mechanism in draft-daniel-dhc-ipv6in4-opt-04.txt as being useful in the following scenario: <---IPv6---->|<-------------IPv4 only----------->|<--IPv6--... +-------+ +------+ +--------+ | CPE | | Edge | ISP | Tunnel | |gateway+-----+Router+-----core-----+endpoint| +-------+ +------+ | +--------+ +---+--+ | DHCP | |server| +------+ In this scenario, the CPE gateway uses DHCPv4 to obtain its IPv4 address and other configuration information. The DHCPv4 configured tunnel endpoint option would provide the IPv4 address of the ISP tunnel endpoint as part of the DHCPv4 configuration process to the CPE gateway, which would then use that IPv4 address as the destination to tunnel IPv6 traffic from the customer network through the IPv4-only portion of the ISP network. If I have this scenario right, it would help to include a description of it in draft-daniel-dhc-ipv6in4-opt-04.txt, both to clarify the use of the option and motivate the requirements for its definition. Is the expectation in draft-daniel-dhc-ipv6in4-opt-04.txt that the tunnel, once established, looks like a simple link to the IPv6 stack? That is, will RAs be exchanged and ND be run across the link? Will the tunnel endpoints use a routing protocol? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 30 15:59:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24747; Thu, 30 Sep 2004 15:59:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD6xe-0002JL-0w; Thu, 30 Sep 2004 15:51:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CD6co-0000YV-5y for dhcwg@megatron.ietf.org; Thu, 30 Sep 2004 15:29:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22329 for ; Thu, 30 Sep 2004 15:29:55 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CD6l5-0000On-VO for dhcwg@ietf.org; Thu, 30 Sep 2004 15:38:33 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 30 Sep 2004 15:47:04 -0400 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i8UJTNbx003176 for ; Thu, 30 Sep 2004 15:29:24 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.249]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ALY62468; Thu, 30 Sep 2004 15:29:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20040930151721.0209e038@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Sep 2004 15:29:20 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [dhcwg] draft-daniel-dhc-dhcpv4-tep-conf-01 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org If I understand the protocol specified in this document correctly, it defines a sequence of DHCP message exchanges and semantics for those message exchanges that is somewhat different from the message exchanges defined in RFC 2131. Specifically, I understand section 5 to define that a new tunnel server (TS3 in the figure) would conduct a DHCP message exchange with each of the tunnel servers that respond to a DHCPDISCOVER message from TS3 (TS1 and TS2 in the figure). This definition differs from that in RFC 2131, which specifies that the client conduct just a single message exchange with one DHCP server. The multiple message exchange would be problematic in that TS3 wants, at most, only one IPv4 address while requesting tunnel end point information from all of the other tunnel servers, so the specification would have to further amend the DHCP message exchange sequence to allow for the use of the Tunnel End Point Request option without the assignment of an IPv4 address. Also, if I understand section 5 correctly, any relay agents would have to be configured to forward DHCPDISCOVER messages from the tunnel servers to all of the other tunnel servers, as well as any other DHCP servers that might be deployed in the cetnral IPv4 cloud. Section 1 cites RFC 3053 in conjunction with "configured tunnels". SHould this be a citation for RFC 2893? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Sep 30 20:36:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18062; Thu, 30 Sep 2004 20:36:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDBBT-0006JS-Ms; Thu, 30 Sep 2004 20:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDAzS-00026Q-Of for dhcwg@megatron.ietf.org; Thu, 30 Sep 2004 20:09:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16358 for ; Thu, 30 Sep 2004 20:09:36 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDB7d-0007hW-1f for dhcwg@ietf.org; Thu, 30 Sep 2004 20:18:16 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I4V000PLPQUMW@mailout2.samsung.com> for dhcwg@ietf.org; Fri, 01 Oct 2004 09:08:54 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I4V005AUPOF3P@mailout2.samsung.com> for dhcwg@ietf.org; Fri, 01 Oct 2004 09:07:28 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I4V0061YPOFQI@mmp2.samsung.com> for dhcwg@ietf.org; Fri, 01 Oct 2004 09:07:27 +0900 (KST) Date: Fri, 01 Oct 2004 09:08:49 +0900 From: Soohong Daniel Park Subject: RE: [dhcwg] IPv6 tunnelling options for IPv4 In-reply-to: <4.3.2.7.2.20040930102330.0209e8f0@flask.cisco.com> To: Ralph Droms , dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7BIT 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: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT > I've been reviewing draft-daniel-dhc-ipv6in4-opt-04.txt - does > draft-daniel-dhc-ipv6in4-opt-04.txt specify "configured IPv6-over-IPv4 > tunneling", as described in section 4 of RFC 2893? If so, it would be > helpful to include a specific reference, as there are numerous > tunneling and > "IPv6-xxx-IPv4" transition mechanisms... So, I've added this concern into the revised version. > > I can imagine the mechanism in > draft-daniel-dhc-ipv6in4-opt-04.txt as being > useful in the following scenario: > > <---IPv6---->|<-------------IPv4 only----------->|<--IPv6--... > > +-------+ +------+ +--------+ > | CPE | | Edge | ISP | Tunnel | > |gateway+-----+Router+-----core-----+endpoint| > +-------+ +------+ | +--------+ > +---+--+ > | DHCP | > |server| > +------+ > > In this scenario, the CPE gateway uses DHCPv4 to obtain its IPv4 > address and > other configuration information. The DHCPv4 configured tunnel endpoint > option would provide the IPv4 address of the ISP tunnel endpoint > as part of > the DHCPv4 configuration process to the CPE gateway, which would then use > that IPv4 address as the destination to tunnel IPv6 traffic from the > customer network through the IPv4-only portion of the ISP network. > Also, this option is useful for dual stack user to obtain its IPv6 connectivity via IPv6-over-IPv4 tunnel within its IPv4 network. [DHCP server] | | <-----IPv4--------------------+------------------------>IPv6 [IPv4/6 user]==IPv6-over-IPv4 Tunnel===> > If I have this scenario right, it would help to include a > description of it > in draft-daniel-dhc-ipv6in4-opt-04.txt, both to clarify the use of the > option and motivate the requirements for its definition. Originally, I thought of this point as out of scope of the draft because several similar draft were proposed in this WG without specific description of use case like mine. If needed, it can be done simply. > Is the expectation in draft-daniel-dhc-ipv6in4-opt-04.txt that the tunnel, > once established, looks like a simple link to the IPv6 stack? > That is, will > RAs be exchanged and ND be run across the link? Will the tunnel endpoints > use a routing protocol? It was also tested and added into the new version. RA runs well via this configured tunnel. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg