From dhcwg-admin@ietf.org Wed Oct 1 12:41:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22713; Wed, 1 Oct 2003 12:41:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4k2B-0004mT-2D; Wed, 01 Oct 2003 12:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4k1J-0004lA-Le for dhcwg@optimus.ietf.org; Wed, 01 Oct 2003 12:40:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22640 for ; Wed, 1 Oct 2003 12:40:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4k1G-0001ug-00 for dhcwg@ietf.org; Wed, 01 Oct 2003 12:40:06 -0400 Received: from cs180094.pp.htv.fi ([213.243.180.94] helo=hades.pp.htv.fi) by ietf-mx with esmtp (Exim 4.12) id 1A4k1F-0001uc-00 for dhcwg@ietf.org; Wed, 01 Oct 2003 12:40:05 -0400 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h91GfI9H008307; Wed, 1 Oct 2003 19:41:18 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h91GfGD9008306; Wed, 1 Oct 2003 19:41:16 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP From: Mika Liljeberg To: Erik Guttman Cc: Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu In-Reply-To: <3F7A9189.2090709@sun.com> References: <3F79B93E.6030601@sun.com> <1064944549.4769.5.camel@hades> <3F7A9189.2090709@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1065026476.4768.95.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 01 Oct 2003 19:41:16 +0300 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Nice state machine, although it does not address the case where it is uncertain whether a configured address is not working or not. In this case a node must be able to configure a LL address, advertise it, and allow applications to fall back on it. There are two very common ad-hoc cases where this can happen: 1) manually configured address in an invalid context, and 2) valid DHCP lease in an invalid context. MikaL On Wed, 2003-10-01 at 11:34, Erik Guttman wrote: > Mika Liljeberg wrote: > > On Tue, 2003-09-30 at 20:11, Erik Guttman wrote: > > > >>I do agree with you. The DHCP client should not be broken or effected > >>by IPv4LL. The host stack which uses both will of course be more > >>complex than one which does not. > > > > > > Are you saying it is ok to run the DHCP and v4LL state machines > > independently of each other? I just want to be absolutely clear on this. > > The DHCP client state machine is not effected by IPv4LL state machine. > The IPv4LL state machine *is* effected by the DHCP client state machine. > > Note that according to section 1.7: > > Where a Link-Local IPv4 address has been configured on an interface, > and a routable address is later configured on the same interface, the > host MUST always use the routable address when initiating new > communications, and MUST cease advertising the availability of the > Link-Local IPv4 address through whatever mechanisms that address had > been made known to others. > > This means that the DHCP state machine has succeeded in configuring > an interface, it has implications for the IPv4 link-local interface. > > We do not have a diagram of a state machine for IPv4LL, but perhaps > that would be very useful. I think it would look something like > this: > > Interface is active and has no <---------------------+ > IPv4 address configured | > | | > v interface has IPv4 addr configured? | > +--> INIT ---------------------------------------> EXIT > | | 2.2 1.7 ^ ^ > | v <-------------------+ | | > | SELECT <---+ | | | > | | 2.1 | ARP with | | | > | v | claimed | | | > | CLAIM | address ADAGIO | | > | ^ | 2.2.1| received ^ | | > | 2.2.1 | v --+ |2.2.1 | | > | CLAIM-WAIT ------------------+ | | > | | 2.2.1 -----------------------------------+ | > 2.5 | v interface has IPv4 addr configured? | > > DOUBT ANNOUNCE 1.7 | > > ^| | 2.4 | > |+-> v interface has IPv4 addr configured? | > +-- CONFIGURED ------------------------------> DEPRECATED > 2.5 ^ | 2.5 1.7 > conflict! | | > +-----+ > defend > > State Behavior > ========== ============================================= > INIT Host has no configured IPv4 address on an > interface. INIT waits before entering SELECT > state. If INIT detects it has been configured > during this time, INIT goes to EXIT state. See > Section 2.2. > > SELECT Select a suitable address. See Section 2.1. The > only possible transition is to CLAIM state. > > A special case of SELECT is where the host has > woken up and previously had a link-local address > configured. In this case, the previously configured > is selected. See Section 2.2. > > CLAIM Send a probe as per Section 2.2. > > CLAIM-WAIT Wait for any ARP messages with the claimed > address originating from a different sender. > > If interface is configured during this wait > period enter EXIT state, do not configure an > IPv4 LL address. See Section 1.7. > > If an ARP message indicates that the selected > address is in use, and this is the first through > nineth retry, enter SELECT state. If this is > the tenth or more retry, enter ADAGIO state. > See Section 2.2.1. > > If no ARP message is detected as the result of > the probe after the wait duration ends, and this > is the first or second try, return to CLAIM state. > If this is the third try, enter the CONFIGURED > state. See Section 2.2.1. > > ADDAGIO Wait at least a minute then enter SELECT state. > > ANNOUNCE Send ARP announcements the enter CONFIGURED > state. > > CONFIGURED The link-local address has been configured for > the interface and is now usable. The host must > respond to three events. > > If a claim is detected, respond with a defending > ARP. Stay in CONFIGURED state. > > If an ARP with a conflicting assignment of the > configured address is detected, defense may be > undertaken once (enter the state of DOUBT) or > go directly to INIT state, surrendering the > configured address. > > DOUBT If an ARP with a source address is detecting > which conflicts with the configured address > during 10 seconds, proceed to INIT state. > See Section 2.5. > > Otherwise, the conflicting use of the address > has been defended against. Return to the > CONFIGURED state. See Section 2.5. > > DEPRECATED This state is entered when a link-local address > has been autoconfigured for an interface, then > subsequently the interface receives a configured > address (as from DHCP). In this state, new > connections are established with the configured > address and the link-local address is not advertised. > Eventually, one SHOULD transition to EXIT state. > See Section 1.7. > > EXIT Cease using the IPv4 link-local address, do not > attempt to configure another such address unless > an interface exists for which there is no IPv4 > link-local address configured. > > > > I hope that this makes it clear: In each case where there is > a transition marked "interface has IPv4 addr configured? 1.7" > this could be caused by the DHCP state machine entering BOUND > state. It is also possible to transition from EXIT to INIT > in the case where a configured address is no longer available. > We do not enter into a full discussion of this transition in > this specification. It is considered in more detail in > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt > > Erik > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 1 15:43:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01326; Wed, 1 Oct 2003 15:43:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4msG-00065J-U2; Wed, 01 Oct 2003 15:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ms1-000650-1C for dhcwg@optimus.ietf.org; Wed, 01 Oct 2003 15:42:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01297 for ; Wed, 1 Oct 2003 15:42:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4mrz-0004H6-00 for dhcwg@ietf.org; Wed, 01 Oct 2003 15:42:43 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4mrz-0004Gn-00 for dhcwg@ietf.org; Wed, 01 Oct 2003 15:42:43 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 01 Oct 2003 12:42:00 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h91JgA5g008431 for ; Wed, 1 Oct 2003 15:42:10 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.247]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACV10271; Wed, 1 Oct 2003 15:42:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20031001154136.01e15f00@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Oct 2003 15:42:07 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] dhc WG meeting in Minneapolis Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The dhc WG meeting is now on the agenda: THURSDAY, November 13, 2003 0900-1130 Morning Sessions INT dhc Dynamic Host Configuration WG OPS grow Global Routing Operations WG SUB tewg Internet Traffic Engineering WG - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 1 20:31:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11917; Wed, 1 Oct 2003 20:31:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4rMz-0006z5-LA; Wed, 01 Oct 2003 20:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4rMd-0006y7-LZ for dhcwg@optimus.ietf.org; Wed, 01 Oct 2003 20:30:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11871 for ; Wed, 1 Oct 2003 20:30:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4rMb-0007Xu-00 for dhcwg@ietf.org; Wed, 01 Oct 2003 20:30:37 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1A4rMa-0007Xr-00 for dhcwg@ietf.org; Wed, 01 Oct 2003 20:30:36 -0400 Received: from localhost.0.0.127.in-addr.arpa (hover.redback.com [155.53.42.186]) by prattle.redback.com (Postfix) with ESMTP id E585B7ADEA2 for ; Wed, 1 Oct 2003 17:28:45 -0700 (PDT) From: Greg Kilfoyle To: dhcwg@ietf.org Content-Type: text/plain Message-Id: <1065054532.19081.51.camel@gar.kilfoyle.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-2) Date: 01 Oct 2003 17:28:52 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Lease Query Draft Status/Comments Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I was wondering about the status of this draft since it expired yesterday. Is there more work that needs to be done, or does it need to be moved forward in some way (maybe both)? Also, I was wondering if there could be a reduction in the number of messages between relay and server in certain situations... Upon reboot of the relay, I could see the need to gather all information from the server(s) for subnets under the control of the relay. It may also be that the relay is only interested in active leases. With the current draft, this means 'walking' all relevant subnets that are configured on the relay. For example, the relay is configured to act as a relay for a class C (/24) subnet. The server is configured to hand out only 100 addresses from this subnet (for whatever reason). The server has handed out 50 addresses from the 100 allocated. In addition, the relay is only interested in knowing about active leases. With the current method, the relay will need to send 254 lease-query messages (ignoring network and broadcast addresses) to the server, to find out that there are 50 active leases. To minimise relay<->server interaction, the relay could start with the lowest IP address in the subnet and use a special flag or new option to pass back the next in-use (i.e. with active lease) IP address. This option/flag could also indicate that there are no more active leases. Using this technique, the relay would only have to send 50 or 51 lease-query messages to the server to obtain all the information it requires. Cheers, Greg. -- Greg Kilfoyle _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 2 10:17:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21436; Thu, 2 Oct 2003 10:17:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54GM-0001Lm-Fk; Thu, 02 Oct 2003 10:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54G9-0001Kz-Ir for dhcwg@optimus.ietf.org; Thu, 02 Oct 2003 10:16:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21305 for ; Thu, 2 Oct 2003 10:16:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54G6-00016u-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 10:16:46 -0400 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1A54G6-00016r-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 10:16:46 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h92EGbYp099969; Thu, 2 Oct 2003 10:16:45 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Greg Kilfoyle'" , Subject: RE: [dhcwg] Lease Query Draft Status/Comments Date: Thu, 2 Oct 2003 10:16:46 -0400 Message-ID: <000001c388ef$d3911d90$6701a8c0@BVolz> 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.4510 Importance: Normal In-Reply-To: <1065054532.19081.51.camel@gar.kilfoyle.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Or, the relay could just query when it was necessary for a particular address? If the relay sees a packet for an IP address it does not know anything about, it can query the server for the address (to reduce delays, the relay could allow the packet through until it learns what it needs from the server or until some timeout expires). While this increases the logic needed on the relay, it does avoid unnecessary queries (such as scanning an entire subnet when perhaps only a few addresses are actually active). - Bernie Volz -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Greg Kilfoyle Sent: Wednesday, October 01, 2003 8:29 PM To: dhcwg@ietf.org Subject: [dhcwg] Lease Query Draft Status/Comments Hi, I was wondering about the status of this draft since it expired yesterday. Is there more work that needs to be done, or does it need to be moved forward in some way (maybe both)? Also, I was wondering if there could be a reduction in the number of messages between relay and server in certain situations... Upon reboot of the relay, I could see the need to gather all information from the server(s) for subnets under the control of the relay. It may also be that the relay is only interested in active leases. With the current draft, this means 'walking' all relevant subnets that are configured on the relay. For example, the relay is configured to act as a relay for a class C (/24) subnet. The server is configured to hand out only 100 addresses from this subnet (for whatever reason). The server has handed out 50 addresses from the 100 allocated. In addition, the relay is only interested in knowing about active leases. With the current method, the relay will need to send 254 lease-query messages (ignoring network and broadcast addresses) to the server, to find out that there are 50 active leases. To minimise relay<->server interaction, the relay could start with the lowest IP address in the subnet and use a special flag or new option to pass back the next in-use (i.e. with active lease) IP address. This option/flag could also indicate that there are no more active leases. Using this technique, the relay would only have to send 50 or 51 lease-query messages to the server to obtain all the information it requires. Cheers, Greg. -- Greg Kilfoyle _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 2 10:48:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22683; Thu, 2 Oct 2003 10:48:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54kL-0003Ae-V3; Thu, 02 Oct 2003 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54kH-0003AD-JB for dhcwg@optimus.ietf.org; Thu, 02 Oct 2003 10:47:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22662 for ; Thu, 2 Oct 2003 10:47:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54kF-0001Rb-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 10:47:55 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1A54kE-0001RT-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 10:47:54 -0400 Received: from localhost.0.0.127.in-addr.arpa (hover.redback.com [155.53.42.186]) by prattle.redback.com (Postfix) with ESMTP id A38F059C9C0; Thu, 2 Oct 2003 07:47:52 -0700 (PDT) Subject: RE: [dhcwg] Lease Query Draft Status/Comments From: Greg Kilfoyle To: Bernie Volz Cc: dhcwg@ietf.org In-Reply-To: <000001c388ef$d3911d90$6701a8c0@BVolz> References: <000001c388ef$d3911d90$6701a8c0@BVolz> Content-Type: text/plain Message-Id: <1065106071.4047.59.camel@gandalf.kilfoyle.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Oct 2003 07:47:52 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Bernie, Not all environments can use the 'wait-for-traffic' approach. Consider a situation where no traffic will pass unless various host/routing tables are populated and/or virtual circuits are created. In this case the full set of lease information must be obtained immediately after reboot to correctly 'provision' all the circuits on the access concentrator. I can see that the draft has been written with a mind to the approach you are talking about, but that's just one scenario. Cheers, Greg. On Thu, 2003-10-02 at 07:16, Bernie Volz wrote: > Or, the relay could just query when it was necessary for a particular > address? If the relay sees a packet for an IP address it does not know > anything about, it can query the server for the address (to reduce delays, > the relay could allow the packet through until it learns what it needs from > the server or until some timeout expires). While this increases the logic > needed on the relay, it does avoid unnecessary queries (such as scanning an > entire subnet when perhaps only a few addresses are actually active). > > - Bernie Volz > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Greg > Kilfoyle > Sent: Wednesday, October 01, 2003 8:29 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Lease Query Draft Status/Comments > > Hi, > > I was wondering about the status of this draft since it expired > yesterday. Is there more work that needs to be done, or does it need to > be moved forward in some way (maybe both)? > > Also, I was wondering if there could be a reduction in the number of > messages between relay and server in certain situations... > > Upon reboot of the relay, I could see the need to gather all information > from the server(s) for subnets under the control of the relay. It may > also be that the relay is only interested in active leases. With the > current draft, this means 'walking' all relevant subnets that are > configured on the relay. > > For example, the relay is configured to act as a relay for a class C > (/24) subnet. The server is configured to hand out only 100 addresses > from this subnet (for whatever reason). The server has handed out 50 > addresses from the 100 allocated. In addition, the relay is only > interested in knowing about active leases. > > With the current method, the relay will need to send 254 lease-query > messages (ignoring network and broadcast addresses) to the server, to > find out that there are 50 active leases. > > To minimise relay<->server interaction, the relay could start with the > lowest IP address in the subnet and use a special flag or new option to > pass back the next in-use (i.e. with active lease) IP address. This > option/flag could also indicate that there are no more active leases. > Using this technique, the relay would only have to send 50 or 51 > lease-query messages to the server to obtain all the information it > requires. > > Cheers, Greg. -- Greg Kilfoyle _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 2 11:42:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27399; Thu, 2 Oct 2003 11:42:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55aa-0007Du-6W; Thu, 02 Oct 2003 11:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55aV-0007Di-QE for dhcwg@optimus.ietf.org; Thu, 02 Oct 2003 11:41:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27356 for ; Thu, 2 Oct 2003 11:41:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55aU-0002Vy-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 11:41:54 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A55aT-0002Vt-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 11:41:53 -0400 Received: from fugue.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 0B3101B227F for ; Thu, 2 Oct 2003 10:41:27 -0500 (CDT) Date: Thu, 2 Oct 2003 10:41:49 -0500 Subject: Re: [dhcwg] Lease Query Draft Status/Comments Content-Type: multipart/alternative; boundary=Apple-Mail-22-902763294 Mime-Version: 1.0 (Apple Message framework v552) From: Ted Lemon To: dhcwg@ietf.org In-Reply-To: <1065106071.4047.59.camel@gandalf.kilfoyle.com> Message-Id: X-Mailer: Apple Mail (2.552) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Apple-Mail-22-902763294 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Thursday, October 2, 2003, at 09:47 AM, Greg Kilfoyle wrote: > I can see that the draft has been written with a mind to the approach > you are talking about, but that's just one scenario. Greg, I see your point, but this draft needs to get kicked out the door. We could propose updates to it until the sun freezes, and indeed that's been what's happened to it quite a bit over the past five years. What you need is related to leasequery, but does not need to be in this draft. The right solution to your problem is to write up a new draft that describes a protocol that provides the functionality you need. The protocol could easily be based on leasequery, or it might make sense for it to be a tcp protocol, given that you want to stuff a lot of data down the wire. You might want to look at how failover does things. --Apple-Mail-22-902763294 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thursday, October 2, 2003, at 09:47 AM, Greg Kilfoyle wrote: I can see that the draft has been written with a mind to the approach you are talking about, but that's just one scenario. Greg, I see your point, but this draft needs to get kicked out the door. We could propose updates to it until the sun freezes, and indeed that's been what's happened to it quite a bit over the past five years. What you need is related to leasequery, but does not need to be in this draft. The right solution to your problem is to write up a new draft that describes a protocol that provides the functionality you need. The protocol could easily be based on leasequery, or it might make sense for it to be a tcp protocol, given that you want to stuff a lot of data down the wire. You might want to look at how failover does things. --Apple-Mail-22-902763294-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 2 12:05:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28428; Thu, 2 Oct 2003 12:05:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55ws-0000Wn-F4; Thu, 02 Oct 2003 12:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55w5-0000To-QL for dhcwg@optimus.ietf.org; Thu, 02 Oct 2003 12:04:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28343 for ; Thu, 2 Oct 2003 12:04:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55w4-0002pM-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 12:04:12 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 1A55w2-0002p9-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 12:04:11 -0400 Received: from localhost.0.0.127.in-addr.arpa (hover.redback.com [155.53.42.186]) by prattle.redback.com (Postfix) with ESMTP id 3C8A93B7D75; Thu, 2 Oct 2003 09:01:25 -0700 (PDT) Subject: Re: [dhcwg] Lease Query Draft Status/Comments From: Greg Kilfoyle To: Ted Lemon Cc: dhcwg@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1065110485.4049.80.camel@gandalf.kilfoyle.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Oct 2003 09:01:25 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Agreed...I came in late in the game; and I can work with the existing specification. What's needed to get the current draft moving then? Cheers, Greg. On Thu, 2003-10-02 at 08:41, Ted Lemon wrote: > On Thursday, October 2, 2003, at 09:47 AM, Greg Kilfoyle wrote: > > I can see that the draft has been written with a mind > to the approach > > you are talking about, but that's just one scenario. > > > > Greg, I see your point, but this draft needs to get kicked out > the door. We could propose updates to it until the sun freezes, and > indeed that's been what's happened to it quite a bit over the past > five years. What you need is related to leasequery, but does not > need to be in this draft. The right solution to your problem is to > write up a new draft that describes a protocol that provides the > functionality you need. The protocol could easily be based on > leasequery, or it might make sense for it to be a tcp protocol, given > that you want to stuff a lot of data down the wire. You might want > to look at how failover does things. -- Greg Kilfoyle _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 2 17:43:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26809; Thu, 2 Oct 2003 17:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5BDx-0004H3-MR; Thu, 02 Oct 2003 17:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5BDp-0004GM-G9 for dhcwg@optimus.ietf.org; Thu, 02 Oct 2003 17:42:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26795 for ; Thu, 2 Oct 2003 17:42:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5BDm-00078r-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 17:42:51 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A5BDm-00078o-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 17:42:50 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Oct 2003 14:48:03 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h92LgHJs012459; Thu, 2 Oct 2003 14:42:18 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.244]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACW06934; Thu, 2 Oct 2003 17:42:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20031002164256.02705aa8@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 02 Oct 2003 17:42:15 -0400 To: Greg Kilfoyle , Ted Lemon From: Kim Kinnear Subject: Re: [dhcwg] Lease Query Draft Status/Comments Cc: dhcwg@ietf.org, kkinnear@cisco.com In-Reply-To: <1065110485.4049.80.camel@gandalf.kilfoyle.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 12:01 PM 10/2/2003, Greg Kilfoyle wrote: >Agreed...I came in late in the game; and I can work with the existing >specification. Thanks Greg. Ted said it better than I would have. We need to move this draft along. That said, Rich Woundy and I have several times explored approaches to extending leasequery to allow an access concentrator to receive information concerning all currently "interesting" or even "active" leases in a concise way (i.e., not based on reacting to current traffic through the concentrator). I would be happy to discuss the ideas that we have had with you, and to work with you (in any of several possible ways) to incorporate them into another draft extending leasequery (if that appears to be a reasonable approach to meeting your needs). But we need to get this existing draft turned into an RFC ASAP. >What's needed to get the current draft moving then? Darn fine question, and it was already on my list of things to sort out with Ralph as the deadline for the need meeting approaches. I'll do so soon, and let you (all of you) know. Cheers -- Kim >Cheers, Greg. > > >On Thu, 2003-10-02 at 08:41, Ted Lemon wrote: >> On Thursday, October 2, 2003, at 09:47 AM, Greg Kilfoyle wrote: >> >> I can see that the draft has been written with a mind >> to the approach >> >> you are talking about, but that's just one scenario. >> >> >> >> Greg, I see your point, but this draft needs to get kicked out >> the door. We could propose updates to it until the sun freezes, and >> indeed that's been what's happened to it quite a bit over the past >> five years. What you need is related to leasequery, but does not >> need to be in this draft. The right solution to your problem is to >> write up a new draft that describes a protocol that provides the >> functionality you need. The protocol could easily be based on >> leasequery, or it might make sense for it to be a tcp protocol, given >> that you want to stuff a lot of data down the wire. You might want >> to look at how failover does things. >-- >Greg Kilfoyle > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 2 21:12:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03278; Thu, 2 Oct 2003 21:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5EUC-0005tT-Kl; Thu, 02 Oct 2003 21:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4cS6-000187-4n for dhcwg@optimus.ietf.org; Wed, 01 Oct 2003 04:35:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03165 for ; Wed, 1 Oct 2003 04:35:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4cS3-00040u-00 for dhcwg@ietf.org; Wed, 01 Oct 2003 04:35:15 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1A4cS2-0003zl-00 for dhcwg@ietf.org; Wed, 01 Oct 2003 04:35:14 -0400 Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h918Ygis008315; Wed, 1 Oct 2003 01:34:43 -0700 (PDT) Received: from sun.com (vpn-129-156-96-193.EMEA.Sun.COM [129.156.96.193]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h918Ybk13286; Wed, 1 Oct 2003 10:34:37 +0200 (MEST) Message-ID: <3F7A9189.2090709@sun.com> Date: Wed, 01 Oct 2003 10:34:17 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Mika Liljeberg CC: Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP References: <3F79B93E.6030601@sun.com> <1064944549.4769.5.camel@hades> In-Reply-To: <1064944549.4769.5.camel@hades> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mika Liljeberg wrote: > On Tue, 2003-09-30 at 20:11, Erik Guttman wrote: > >>I do agree with you. The DHCP client should not be broken or effected >>by IPv4LL. The host stack which uses both will of course be more >>complex than one which does not. > > > Are you saying it is ok to run the DHCP and v4LL state machines > independently of each other? I just want to be absolutely clear on this. The DHCP client state machine is not effected by IPv4LL state machine. The IPv4LL state machine *is* effected by the DHCP client state machine. Note that according to section 1.7: Where a Link-Local IPv4 address has been configured on an interface, and a routable address is later configured on the same interface, the host MUST always use the routable address when initiating new communications, and MUST cease advertising the availability of the Link-Local IPv4 address through whatever mechanisms that address had been made known to others. This means that the DHCP state machine has succeeded in configuring an interface, it has implications for the IPv4 link-local interface. We do not have a diagram of a state machine for IPv4LL, but perhaps that would be very useful. I think it would look something like this: Interface is active and has no <---------------------+ IPv4 address configured | | | v interface has IPv4 addr configured? | +--> INIT ---------------------------------------> EXIT | | 2.2 1.7 ^ ^ | v <-------------------+ | | | SELECT <---+ | | | | | 2.1 | ARP with | | | | v | claimed | | | | CLAIM | address ADAGIO | | | ^ | 2.2.1| received ^ | | | 2.2.1 | v --+ |2.2.1 | | | CLAIM-WAIT ------------------+ | | | | 2.2.1 -----------------------------------+ | 2.5 | v interface has IPv4 addr configured? | DOUBT ANNOUNCE 1.7 | ^| | 2.4 | |+-> v interface has IPv4 addr configured? | +-- CONFIGURED ------------------------------> DEPRECATED 2.5 ^ | 2.5 1.7 conflict! | | +-----+ defend State Behavior ========== ============================================= INIT Host has no configured IPv4 address on an interface. INIT waits before entering SELECT state. If INIT detects it has been configured during this time, INIT goes to EXIT state. See Section 2.2. SELECT Select a suitable address. See Section 2.1. The only possible transition is to CLAIM state. A special case of SELECT is where the host has woken up and previously had a link-local address configured. In this case, the previously configured is selected. See Section 2.2. CLAIM Send a probe as per Section 2.2. CLAIM-WAIT Wait for any ARP messages with the claimed address originating from a different sender. If interface is configured during this wait period enter EXIT state, do not configure an IPv4 LL address. See Section 1.7. If an ARP message indicates that the selected address is in use, and this is the first through nineth retry, enter SELECT state. If this is the tenth or more retry, enter ADAGIO state. See Section 2.2.1. If no ARP message is detected as the result of the probe after the wait duration ends, and this is the first or second try, return to CLAIM state. If this is the third try, enter the CONFIGURED state. See Section 2.2.1. ADDAGIO Wait at least a minute then enter SELECT state. ANNOUNCE Send ARP announcements the enter CONFIGURED state. CONFIGURED The link-local address has been configured for the interface and is now usable. The host must respond to three events. If a claim is detected, respond with a defending ARP. Stay in CONFIGURED state. If an ARP with a conflicting assignment of the configured address is detected, defense may be undertaken once (enter the state of DOUBT) or go directly to INIT state, surrendering the configured address. DOUBT If an ARP with a source address is detecting which conflicts with the configured address during 10 seconds, proceed to INIT state. See Section 2.5. Otherwise, the conflicting use of the address has been defended against. Return to the CONFIGURED state. See Section 2.5. DEPRECATED This state is entered when a link-local address has been autoconfigured for an interface, then subsequently the interface receives a configured address (as from DHCP). In this state, new connections are established with the configured address and the link-local address is not advertised. Eventually, one SHOULD transition to EXIT state. See Section 1.7. EXIT Cease using the IPv4 link-local address, do not attempt to configure another such address unless an interface exists for which there is no IPv4 link-local address configured. I hope that this makes it clear: In each case where there is a transition marked "interface has IPv4 addr configured? 1.7" this could be caused by the DHCP state machine entering BOUND state. It is also possible to transition from EXIT to INIT in the case where a configured address is no longer available. We do not enter into a full discussion of this transition in this specification. It is considered in more detail in http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 2 21:12:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03277; Thu, 2 Oct 2003 21:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5EUC-0005tL-7f; Thu, 02 Oct 2003 21:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4O2R-0004Jp-BW for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 13:11:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02587 for ; Tue, 30 Sep 2003 13:11:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4O2P-0001r0-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 13:11:49 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1A4O2O-0001qx-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 13:11:48 -0400 Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h8UHBlkv024584; Tue, 30 Sep 2003 11:11:47 -0600 (MDT) Received: from sun.com (vpn-129-156-96-200.EMEA.Sun.COM [129.156.96.200]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h8UHBgk17147; Tue, 30 Sep 2003 19:11:43 +0200 (MEST) Message-ID: <3F79B93E.6030601@sun.com> Date: Tue, 30 Sep 2003 19:11:26 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Ted Lemon CC: dhcwg@ietf.org, zeroconf@merit.edu Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ted Lemon wrote: > > On Tuesday, September 23, 2003, at 05:14 AM, Erik Guttman wrote: > >> The text supplied by Bernard has the property that it does not >> specify any new behavior for DHCP. The new text makes it clear >> that an implementation of IPv4LL must attempt to obtain configuration >> via DHCP according to the DHCP specification, even if it has failed >> to in the past. I think this satisfies Ted's concern: >> >> Ted Lemon wrote: >> > The correct fix is to make sure that the DHCP client does not in fact >> > modify its behaviour to make IPv4ll work, but rather to modify IPv4ll >> > so that it doesn't interfere with the operation of the DHCP client. > > > The new text that Bernard has supplied, at least as specified in your > proposed resolution for LL34, does not seem to address the problem at > all. The problem is that right now the IPv4ll protocol specification > creates a situation in which there is an incentive to break the DHCP > client in order to get correct IPv4ll behavior. I do not follow you. Please see my assessment of the current draft, below. I see nowhere, except where it is stated that DHCP SHOULD NOT configure from the IPv4 LL prefix, that we introduce direct or indirect requirements on DHCP or DHCP client behavior. > My goal is not to > break the DHCP client less. It is to not break it at all. If you > don't agree with this goal, can you please try to build consensus by > explaining why you don't agree with it? I do agree with you. The DHCP client should not be broken or effected by IPv4LL. The host stack which uses both will of course be more complex than one which does not. > Also, I think that you should withdraw the statement that your proposed > solution to LL34 has been accepted, since there was no discussion on it, > and thus no opportunity for consensus. There was plenty of discussion about it both here and on the zeroconf list, but that is neither here nor there. I want to satisfy your technical concern even if I can't respond to your liking about the process by which we've been demanding decision points in otherwise circular ZEROCONF discussions. > I certainly do not agree that > it solves the stated problem. Possibly I am reading too much into the > problem statement, but if so, I think we need a new discussion item: > "IPv4LL state machine must not place requirements on DHCPv4 state machine." What if we add this sentence, verbatim, to the end of section 2.11? This specification places no requirements on the DHCPv4 state machine. ----------- Let's be 100% clear what the requirements that ZEROCONF is placing on DHCP. The current text in http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-10.txt regarding DHCP is as follows (an exhaustive excerpt). I add emphasis to aid those who follow the DHC list but not the zeroconf list. Abstract To participate in wide-area IP networking, a host needs to be configured, either manually by the user or automatically from a source on the network such as a DHCP server. Unfortunately, such ******************* external configuration information may not always be available. It *************************************************************** is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. => no requirements on dhcp 1. Introduction As the Internet Protocol continues to grow in popularity, it becomes increasingly valuable to be able to use familiar IP tools such as FTP not only for global communication, but for local communication as well. For example, two people with laptop computers supporting IEEE 802.11 Wireless LANs [802.11] may meet and wish to exchange files. It is desirable for these people to be able to use IP application ***************************************************** software without the inconvenience of having to manually configure ******* ********* static IP addresses or set up a DHCP server [RFC2131]. ****************************** => no requirements on dhcp 1.6. Alternate Use Prohibition Note that addresses in the 169.254/16 prefix SHOULD NOT be configured *********************************************************** manually or by a DHCP server. Manual or DHCP configuration may cause **************** a host to use an address in the 169.254/16 prefix without following the special rules regarding duplicate detection and automatic configuration that pertain to addresses in this prefix. While [RFC2131] indicates that a DHCP client SHOULD probe a newly received address with ARP, this is not mandatory. Similarly, while [RFC2131] recommends that a DHCP server SHOULD probe an address using an ICMP Echo Request before allocating it, this is also not mandatory, and even if the server does this, Link-Local IPv4 addresses are not routable, so a DHCP server not directly connected to a link cannot detect whether a host on that link is already using the desired Link- Local IPv4 address. Administrators wishing to configure their own local addresses (using manual configuration, a DHCP server, or any other mechanism not described in this document) should use one of the existing private address prefixes [RFC1918], not the 169.254/16 prefix. => SHOULD requirement placed on DHCP administration 2.6.1. Source Address Usage Since each interface on a host may have a Link-Local IPv4 address in ********************************* addition to zero or more other addresses configured by other means ************ ********************* (e.g. manually or via a DHCP server), a host may have to make a **** ***************** choice about what source address to use when it sends a packet or initiates a TCP connection. => no requirements placed on DHCP 2.8. Link-Local Packets are Local It should be understood that this mediated communication is not mandatory; it is an option afforded to designers of extremely simple devices. Any designer of a device desiring unmediated communication ********************************************************** outside the local link need only implement today's conventional IP ****************************************************************** host software (e.g. a DHCP client) in order to enjoy the same degree ********************************** of global addressability available to other conventional IPv4 hosts. Such networked devices should of course implement a degree of security appropriate to being connected to a global public network. => no requirements on DHCP 2.11. Transition from Link-Local to Routable Address As discussed in Section 1.7, use of a routable address is preferred to assignment of a Link-Local IPv4 address. A Link-Local IPv4 address ************************* can be configured due to transient failures, such as incomplete link- ***************** layer authentication, spanning tree convergence issues, or because a ********* DHCP server failed to respond to an initial query, or is inoperative ***************************** for some time. Where a Link-Local IPv4 address is assigned due to a transient failure, experience has shown that five minutes (see Appendix A.2) ********************************************************* may be too long an interval to wait prior to attempting to configure ******************************************************************** with DHCP. This document does not specify a strategy for quickly ***************************************************************** recovering a routable address in situations where a Link-Local IPv4 ******************************************************************* address is assigned due to a transient failure. In situations where ******************************************************************* many hosts are present on a single subnet, frequent attempts to *************************************************************** contact the DHCP server could result in a heavy traffic load. Further ************************************************************ discussion of this issue is provided in [DNAv4]. => no requirements on DHCP. The current text states what existing implementations do, and that this has problems. Apparently they are ignoring the DHCP recommendations, which I hope I get right: RFC2131, section 3 subsection 5 which suggests that The client should choose to retransmit the DHCPREQUEST enough times to give adequate probability of contacting the server without causing the client (and the user of that client) to wait overly long before giving up; e.g., a client retransmitting as described in section 4.1 might retransmit the DHCPREQUEST message four times, for a total delay of 60 seconds, before restarting the initialization procedure. If the client receives neither a DHCPACK or a DHCPNAK message after employing the retransmission algorithm, the client reverts to INIT state and restarts the initialization process. and RFC2131, section 4.4.1 which requires (SHOULD) that a random delay of 1-10 seconds elapse before a DHCPDISCOVER packet is sent while in INIT state. The Microsoft and Apple software which implements the '5 minute' delay before initiating DHCP configuration lengthened the suggested 1-10 second wait before reentering INIT state. The appendices describe current practice and do not place any requirements on DHCP. ======================================================================== Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 2 21:59:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03279; Thu, 2 Oct 2003 21:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5EUD-0005tb-4K; Thu, 02 Oct 2003 21:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4zYp-0001N4-8c for dhcwg@optimus.ietf.org; Thu, 02 Oct 2003 05:15:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08716 for ; Thu, 2 Oct 2003 05:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4zYl-00057F-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 05:15:43 -0400 Received: from server21.ukservers.net ([217.10.138.198]) by ietf-mx with esmtp (Exim 4.12) id 1A4zYl-00057B-00 for dhcwg@ietf.org; Thu, 02 Oct 2003 05:15:43 -0400 Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id 4343A39C0B2; Thu, 2 Oct 2003 10:15:38 +0100 (BST) Message-ID: <02e801c388c5$c0ba1020$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , "Mika Liljeberg" Cc: "Ted Lemon" , , References: <3F79B93E.6030601@sun.com> <1064944549.4769.5.camel@hades> <3F7A9189.2090709@sun.com> Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP Date: Thu, 2 Oct 2003 10:15:41 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > From: "Erik Guttman" > > The DHCP client state machine is not effected by IPv4LL state machine. > The IPv4LL state machine *is* effected by the DHCP client state machine. The IPv4LL state machine is affected by the configuration state or the interface. That state may be affected by DHCP state machine in certain circumstances. However, the question the IPv4LL state machine has to ask, is "Does the interface have a working routable address configured" and that is not asked of the DHCP state machine. I think your state diagram captures this well. However, in my phrasing of the question above "working" is a weasle word which allows for configured but inappropriate addresses to be ignored. How this is determined is an issue we should avoid, but the DNA draft helps by providing a pointer. I do not see any serious difference in opinion among recent posts, but the level of discussion confirms that the wording has to be chosen carefully - the state machine helps. Philip _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 3 12:22:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14571; Fri, 3 Oct 2003 12:22:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Sgq-0006h5-QF; Fri, 03 Oct 2003 12:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5SgD-0006e3-33 for dhcwg@optimus.ietf.org; Fri, 03 Oct 2003 12:21:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14473 for ; Fri, 3 Oct 2003 12:21:11 -0400 (EDT) From: Stephane.Antoine@panasonicmobile.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5SgB-0002vy-00 for dhcwg@ietf.org; Fri, 03 Oct 2003 12:21:19 -0400 Received: from laurel.mci.co.uk ([195.144.128.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5SgA-0002vZ-00 for dhcwg@ietf.org; Fri, 03 Oct 2003 12:21:18 -0400 Date: Fri, 3 Oct 2003 17:21:05 +0100 Message-ID: MIME-Version: 1.0 To: dhcwg@ietf.org X-WSS-ID: 13637E6E115183-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; Creation-Date="Fri, 3 Oct 2003 17:21:05 +0100" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] keeping the same IP address Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I would like to know: When a Mobile node (Mobile Client) obtains an IPv6 address by a DHCPv6 server on a link and moves to a different link, the Mobile Client will send a confirm message message to its DHCPv6 server to check the validity of that address. I presume then, the DHCPv6 server would reply with a code NotOnLink. Will the DHCPv6 server force the Mobile Client to stop using that adress? by sending a Lifetime of zero back to the client? Would it be possible for a DHCPv6 server to allow a Mobile Client to use the same DHCPv6 address across several links (provided a routing protocol ensure routability of that address) across several links after the DHCPv6 server has notified NotOnLink? Stephane ============================================================================== Confidentiality Notice The information contained in this E-mail, and any attachments, is intended for the named recipients only. It may contain confidential and/or privileged information. If you are not the intended recipient, you must not copy, distribute, or take any action in reliance on it. Any views expressed do not necessarily reflect the views of Panasonic Mobile Communications Development of Europe Limited. Please note that whilst the company takes steps to protect against viruses it cannot accept any liability for any damage, whether direct or indirect, sustained as a result of any software viruses being transmitted. If you receive this E-mail by mistake, please advise the sender by using the reply facility in your E-mail software and then delete it. ============================================================================== _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 3 16:27:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25540; Fri, 3 Oct 2003 16:27:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WVw-0001xC-S0; Fri, 03 Oct 2003 16:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5WVG-0001nc-Ou for dhcwg@optimus.ietf.org; Fri, 03 Oct 2003 16:26:18 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25465; Fri, 3 Oct 2003 16:26:09 -0400 (EDT) Message-Id: <200310032026.QAA25465@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 03 Oct 2003 16:26:09 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-07.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Unused DHCP Option Codes Author(s) : R. Droms Filename : draft-ietf-dhc-unused-optioncodes-07.txt Pages : 11 Date : 2003-10-3 Prior to the publication of RFC2489 (which was updated by RFC2939), several option codes were assigned to proposed DHCP options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future. The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-unused-optioncodes-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-unused-optioncodes-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: <2003-10-3164102.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-unused-optioncodes-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-unused-optioncodes-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-3164102.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 6 11:03:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05288; Mon, 6 Oct 2003 11:03:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Wt2-0001fs-O6; Mon, 06 Oct 2003 11:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6WsP-0001fY-Aa for dhcwg@optimus.ietf.org; Mon, 06 Oct 2003 11:02:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05251 for ; Mon, 6 Oct 2003 11:02:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6WsJ-0006Wh-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 11:02:15 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A6WsI-0006WN-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 11:02:15 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 06 Oct 2003 08:09:02 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h96F1g5g015855 for ; Mon, 6 Oct 2003 11:01:43 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn2-428.cisco.com [10.21.113.172]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACX57769; Mon, 6 Oct 2003 11:01:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20031006105628.01fafc60@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Oct 2003 11:01:38 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Status of draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , We have two questions on the table concerning draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt: * Is there a need for this option yet? Is NIS/NIS+ currently IPv6-capable or are there plans to extend NIS/NIS+ for IPv6? Is NIS/NIS+ used with IPv6 today? * Is there a need for an DHCPv6 version of RFC 2937, "The Name Service Search Option for DHCP"? If there is no discussion on these questions, we will put draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt on hold until there is a firm requirement for it. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 6 11:26:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07378; Mon, 6 Oct 2003 11:26:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6XFJ-0002ed-KR; Mon, 06 Oct 2003 11:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6XET-0002cX-6P for dhcwg@optimus.ietf.org; Mon, 06 Oct 2003 11:25:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07326 for ; Mon, 6 Oct 2003 11:24:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6XES-0007A3-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 11:25:08 -0400 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1A6XER-00079y-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 11:25:07 -0400 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id 83E721C01E67; Mon, 6 Oct 2003 08:25:04 -0700 (PDT) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id UAA16738; Mon, 6 Oct 2003 20:53:55 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Status of draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt Date: Mon, 6 Oct 2003 20:55:02 +0530 Organization: HP ISO Message-ID: <004b01c38c1e$030f0790$38e62a0f@nt23056> 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.4024 In-Reply-To: <4.3.2.7.2.20031006105628.01fafc60@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ralph, My reply inline.. Thanks Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Ralph Droms > Sent: Monday, October 06, 2003 8:32 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Status of draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt > > > We have two questions on the table concerning > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt: > > * Is there a need for this option yet? Is NIS/NIS+ currently > IPv6-capable > or are there plans to extend NIS/NIS+ for IPv6? Is > NIS/NIS+ used with > IPv6 today? > Yes, Currently NIS/NIS+ is used with IPv6. NIS/NIS+ for IPv6 is supported in Solaris and some versions of linux. HPUX is working on it. > * Is there a need for an DHCPv6 version of RFC 2937, "The Name Service > Search Option for DHCP"? Yes. It is needed. When we have mutliple ways to resolve a name, we need a precedence list to do it. > > If there is no discussion on these questions, we will put > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt on hold until > there is a firm requirement for it. > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 6 13:07:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12499; Mon, 6 Oct 2003 13:07:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Yp3-0008J8-Ae; Mon, 06 Oct 2003 13:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Yo8-0008GV-Or for dhcwg@optimus.ietf.org; Mon, 06 Oct 2003 13:06:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12395 for ; Mon, 6 Oct 2003 13:05:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6Yo6-00014f-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 13:06:02 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A6Yo6-00014N-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 13:06:02 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h96H5UcZ004656 for ; Mon, 6 Oct 2003 10:05:30 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-570.cisco.com [10.82.242.58]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACX70143; Mon, 6 Oct 2003 13:05:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20031006130314.058220b8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Oct 2003 13:05:25 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] draft-ietf-dhc-dhcpv6-interop-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The issues documented in draft-ietf-dhc-dhcpv6-interop-01.txt, "Results from Interoperability Tests of DHCPv6 Implementations", were all addressed in the DHCPv6 spec prior to its publication as RFC3315. draft-ietf-dhc-dhcpv6-interop-01.txt is about to expire; does anyone have an argument for publishing it as Informational or otherwise archiving it? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 6 13:33:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13868; Mon, 6 Oct 2003 13:33:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ZED-0000xA-41; Mon, 06 Oct 2003 13:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ZDT-0000wV-Sy for dhcwg@optimus.ietf.org; Mon, 06 Oct 2003 13:32:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13818 for ; Mon, 6 Oct 2003 13:32:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6ZDR-0001RS-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 13:32:13 -0400 Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx with esmtp (Exim 4.12) id 1A6ZDR-0001RP-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 13:32:13 -0400 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id 33D621C067EB; Mon, 6 Oct 2003 10:32:11 -0700 (PDT) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id XAA26855; Mon, 6 Oct 2003 23:00:50 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: , "'Thomas Narten'" , "'Ralph Droms'" Cc: Subject: Re: [dhcwg] AD Review: draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Date: Mon, 6 Oct 2003 23:01:57 +0530 Organization: HP ISO Message-ID: <005601c38c2f$c58d28e0$38e62a0f@nt23056> 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.4024 In-Reply-To: <001a01c37b8c$0f540bb0$38e62a0f@nt23056> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Margaret, Thanks for your thorough review. I am sorry for replying bit late. See my reply inline.... ~ Vijay > > General question on this document: We recently deprecated > the option code allocation for the IPv4 version of this > option. Why do we think that there is a greater need for > this in IPv4 than in IPv6? Has anyone implemented these options? NTP version 4.0 available in www.ntp.org supports IPv6. Most of the vendors provide this version and support NTP on IPv6. So, it is really needed. > > >Abstract > > > > This document describes the options for Time related configuration > > information in DHCPv6: NTP Servers and Timezone specifier. > > This is a very weak abstract. I will elaborate it bit more. > > >3. Terminology > > > > This document uses terminology specific to IPv6 and DHCPv6 as > defined > > in section "Terminology" of the DHCP specification. > > s/section "Terminology"/"Terminology" section > > ...and/or include a section number. Fine.. I will change it. > > >4. Network Time Protocol (NTP) Servers option > > > >[...] > > > > NTP server: IP address of NTP server > > Is it expected that this option will only contain the > addresses of IPv6 NTP servers? If so, you should make that > clear. If not, how > would an IPv4 address be indicated? Yes. This option is for IPv6 addresses only. I will make it clear. > > It is also my understand that we haven't (yet) specified how > NTP would run over IPv6, so this option may be premature. Since, there is actually no protocol changes are needed in existing RFC for NTP, there is no specification for NTP on IPv6. Its just like another application migration to IPv6. But, IPv6 version of NTP are available in various platforms. I don't think this option is a premature one. > > >5. Timezone option > > > > The Timezone option is used by the server to convey client's > timezone > > information to the client. > > Is it assumed that the server will always be in the same > timezone as all of its clients? Or is there some other way > that the server will determine what timezone information to > send to each client (config'ed on a per-prefix basis, perhaps?). Server is not needed to be in the same timezone. Basically, the timezone is allocated based on the prefix. The assumption is, the nodes in the same network will be in the same timezone. > > > time-zone: Time zone of the client in the format as explained > below. > > > > Std[Offset[Dst[Offset],[Start[/Time],End[/Time]]]] > > > > where '[' and ']' enclose optional fields, '|' indicates choice > > of exactly one of the alternatives, ',' and '/' represent literal > > characters present in the string. > > > > If "Offset" is specified, then the time-zone is represented in the > > IEEE 1003.1 POSIX timezone format [3]. > > What is the reason for specifying a timezone format in this > document, instead of relying completely on another establish > standard for > timezone representation? This flexibility is provided to help the vendors to use some other vendor specific database for timezone information. This is needed, if they feel that their databases can convey more information than POSIX time string. > > > iii) Representing ii) in the non POSIX standard way is: > > > > America/New-York > > > > It says that the locale belongs to New-York timezone in America, > which > > will be used as the index in to a timezone database to get more > > information of the timezone. > > What is a "timezone database"? Is this a standard concept, > or something you are assuming will be specific to each host? > If the latter, why do we need this flexibility? Its not a standard concept. Its something specific to the OS. For the last question, you refer the prev answer. > > >7. Security Considerations > > > > The NTP servers option may be used by an intruder DHCP server to > > cause DHCP clients to contact an intruder NTP server, > resulting in > > invalid synchronization of time in client and finally leading to > > time critical applications running inaccurately in client machine. > > The time accuracy can be crucial to some security algorithms. For > > example, it may cause expired certificates to gain a new life, > making > > the application less secured. > > s/less secured/less secure Ok. Will update it. > > > The Timezone option may be used by an intruder DHCP > server to assign > > > invalid time zones, leading to timing issues for the applications > running > > on the client machine. > > I think that there is potential for a denial of service > attack. Given that time synchronization is required for some types of > secure access, giving wrong time information to a client could > result in the client being unable to access some services. > Is that what you are talking about in the above paragraph? > If so, I think you should be more explicit. Whatever you have explained is one of the scenarios. There could be many. For example, because of wrongly configured timezone, there is a possibility that some applications which are supposed to start at a particular time don't get started at that time. Since there could be many issues like this, I was not more explicit. Probably, I could add some examples to the text. > > > To avoid attacks through these options, the DHCP client > SHOULD use > > authenticated DHCP (see section "Authentication of DHCP messages" > > in the DHCPv6 specification [1]). > > Why only a "SHOULD"? Given the critical nature of time > infromation to some security protocols, I would prefer a > statement that this option MUST only be used when the DHCP > messages are authenticated. Is there a reason not to say that? As such authentication is not mandatory in the DHCPv6 specification (RFC 3315) except for reconfiguration. That's the reason why "MUST" is not used here. > > >8. IANA Considerations > > > > IANA is requested to assign an option code to these > options from the > > option-code space defined in section "DHCPv6 Options" of > the DHCPv6 > > specification [1]. > > Based on earlier experience, you need to explicitly list the > option codes to be assigned by IANA in this section. Yes, I will do.. > > >10. Informative References > > > > [2] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for > > IPv4, IPv6 and OSI. Request for Comments > (Informational) 2030, > > Internet Engineering Task Force, October 1996. > > This should be a reference to NTP, not to SNTP. Basically, the NTP servers I am referring are SNTP servers. I believe, I could change the "NTP server option" to "SNTP server option". Thanks once again for your thorough review. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 6 13:54:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14680; Mon, 6 Oct 2003 13:54:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ZYX-0001p1-Nk; Mon, 06 Oct 2003 13:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ZXj-0001oM-7c for dhcwg@optimus.ietf.org; Mon, 06 Oct 2003 13:53:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14649 for ; Mon, 6 Oct 2003 13:53:01 -0400 (EDT) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6ZXg-0001dA-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 13:53:08 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A6ZXg-0001d7-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 13:53:08 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h96Hr7614649 for ; Mon, 6 Oct 2003 20:53:07 +0300 (EET DST) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 6 Oct 2003 20:53:05 +0300 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 6 Oct 2003 10:53:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] AD Review: draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Date: Mon, 6 Oct 2003 13:53:01 -0400 Message-ID: Thread-Topic: [dhcwg] AD Review: draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Thread-Index: AcOML/sQoS9X+1/TSOmTruBjjfd6aAAAFzQw To: , , , Cc: X-OriginalArrivalTime: 06 Oct 2003 17:53:03.0166 (UTC) FILETIME=[B05D3DE0:01C38C32] Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Vijay, Thanks for your response. > > General question on this document: We recently deprecated > > the option code allocation for the IPv4 version of this=20 > > option. Why do we think that there is a greater need for=20 > > this in IPv4 than in IPv6? Has anyone implemented these options? =20 > =20 > NTP version 4.0 available in www.ntp.org supports IPv6. Most of the > vendors provide this version and support NTP on IPv6. So, it is really > needed. Your response answers my concern about whether or not NTP is available for IPv6, but it doesn't answer my larger concern. We just deprecated the corresponding configuration options for IPv4, because they weren't implemented. Do we have some reason to believe that people will implement this option for DHCPv6 when no one = implemented the same option for IPv4? If so, why?=20 > > It is also my understand that we haven't (yet) specified how > > NTP would run over IPv6, so this option may be premature. >=20 > Since, there is actually no protocol changes are needed in=20 > existing RFC for NTP, there is no specification for NTP on IPv6. Its=20 > just like another application migration to IPv6. But, IPv6 version of=20 > NTP are available in various platforms. I don't think this option is=20 > a premature one. Actually, there are several IPv4 dependencies in the NTP specification, as document in: =20 http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-apps-02.t= xt The folks who have implemented NTP for IPv6 must have worked around those dependencies, but I don't believe that their changes have been document in an IETF specification (yet). > > What is the reason for specifying a timezone format in this > > document, instead of relying completely on another establish=20 > > standard for timezone representation?=20 >=20 > This flexibility is provided to help the vendors to use some other > vendor specific database for timezone information. This is needed, if > they feel that their databases can convey more information than POSIX > time string. [...] > > What is a "timezone database"? Is this a standard concept, > > or something you are assuming will be specific to each host? =20 > > If the latter, why do we need this flexibility? >=20 > Its not a standard concept. Its something specific to the OS. For the > last question, you refer the prev answer. How do you maintain interoperability between the DHCP server and clients from multiple vendors, if the server may return the timezone in an OS-proprietary format? You mentioned earlier that this timezone information is set on a per-subnet basis, with the assumption that all clients on the same subnet are in the same timezone. Do you also=20 assume that all clients on the same subnet are running the same OS? > > > To avoid attacks through these options, the DHCP client > > > SHOULD use authenticated DHCP (see section "Authentication of DHCP = > > > messages" in the DHCPv6 specification [1]). > >=20 > > Why only a "SHOULD"? Given the critical nature of time > > information to some security protocols, I would prefer a=20 > > statement that this option MUST only be used when the DHCP=20 > > messages are authenticated. Is there a reason not to say that? >=20 > As such authentication is not mandatory in the DHCPv6=20 > specification (RFC 3315) except for reconfiguration. That's the=20 > reason why "MUST" is not used here. True, although we could require that DHCP security be implemented and used whenever certain sensitive options are in use... I'm not sure what sort of policy has been used for deciding this in the=20 past, though. > > > [2] D. Mills. Simple Network Time Protocol (SNTP)=20 > > > Version 4 for IPv4, IPv6 and OSI. Request for Comments > > > (Informational) 2030, Internet Engineering Task Force,=20 > > > October 1996. > >=20 > > This should be a reference to NTP, not to SNTP. >=20 > Basically, the NTP servers I am referring are SNTP servers. I=20 > believe, I could change the "NTP server option" to "SNTP server=20 > option". If that is more accurate, then I think it would make sense to=20 make that change.=20 =20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 6 15:39:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19011; Mon, 6 Oct 2003 15:39:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6bCA-00069O-9m; Mon, 06 Oct 2003 15:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6bBI-00066n-0b for dhcwg@optimus.ietf.org; Mon, 06 Oct 2003 15:38:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18874 for ; Mon, 6 Oct 2003 15:37:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6bBG-0002Zl-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 15:38:06 -0400 Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx with esmtp (Exim 4.12) id 1A6b3T-0002XH-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 15:30:03 -0400 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel11.hp.com (Postfix) with ESMTP id 45A5D1C01178; Mon, 6 Oct 2003 12:30:00 -0700 (PDT) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id AAA04878; Tue, 7 Oct 2003 00:58:50 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: , , , Cc: Subject: RE: [dhcwg] AD Review: draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Date: Tue, 7 Oct 2003 00:59:57 +0530 Organization: HP ISO Message-ID: <000401c38c40$3af4e770$38e62a0f@nt23056> 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.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Margaret Thanks for your very quick reply. My reply inline ~ Vijay > > Hi Vijay, > > Thanks for your response. > > > > General question on this document: We recently deprecated the > > > option code allocation for the IPv4 version of this > option. Why do > > > we think that there is a greater need for this in IPv4 > than in IPv6? > > > Has anyone implemented these options? > > > > NTP version 4.0 available in www.ntp.org supports IPv6. Most of the > > vendors provide this version and support NTP on IPv6. So, > it is really > > needed. > > Your response answers my concern about whether or not NTP is > available for IPv6, but it doesn't answer my larger concern. > > We just deprecated the corresponding configuration options > for IPv4, because they weren't implemented. Do we have some > reason to believe that people will implement this option for > DHCPv6 when no one implemented the same option for IPv4? If so, why? One of the two options specified in the draft has been already standardized for IPv4. Refer RFC 2132, option code : 42, Network Time Protocol Servers Option. There is an option called "Time offset" (option code: 2) defined in RFC 2132. But, it could not convey enough information like day light savings. Only to provide more information about the timezone, the draft for "POSIX time zone option for DHCPv4" was written. Meanwhile, There were few implementations providing this support in the vendor specific options. One such example is Solaris's "SUNW.posix-timezone-string" option. Hence, certainly there are few users. Unfortunately, this draft was not advanced and got expired. As most of the platforms provided this option in the form of vendor specific options, nobody really bothered to restart the work and advance it to the standard. Moreover, I could see alteast 2 implementation of DHCPv6, which have the support for POSIX time zone option. (1) HPUX (2) KAME FreeBSD. What I am trying to say is, Certainly keeping this as an vendor specific option may cause issues while switching between the servers. Since, this option is used as vendor specific option in few implementations of DHCPv4 and there are implementations of DHCPv6 which support this option, its better to standardize it. > > > > It is also my understand that we haven't (yet) specified how NTP > > > would run over IPv6, so this option may be premature. > > > > Since, there is actually no protocol changes are needed in > > existing RFC for NTP, there is no specification for NTP on > IPv6. Its > > just like another application migration to IPv6. But, IPv6 > version of > > NTP are available in various platforms. I don't think this > option is > > a premature one. > > Actually, there are several IPv4 dependencies in the NTP > specification, as document in: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surve > y-apps-02.txt > > The folks who have implemented NTP for IPv6 must have worked > around those dependencies, but I don't believe that their > changes have been document in an IETF specification (yet). The RFC it refers is version 3 of the SNTP protocol. The next version deals with IPv6 also. D. Mills. Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. Request for Comments (Informational) 2030, Internet Engineering Task Force, October 1996. > > > > What is the reason for specifying a timezone format in this > > > document, instead of relying completely on another establish > > > standard for timezone representation? > > > > This flexibility is provided to help the vendors to use some other > > vendor specific database for timezone information. This is > needed, if > > they feel that their databases can convey more information > than POSIX > > time string. > [...] > > > What is a "timezone database"? Is this a standard concept, or > > > something you are assuming will be specific to each host? > > > If the latter, why do we need this flexibility? > > > > Its not a standard concept. Its something specific to the > OS. For the > > last question, you refer the prev answer. > > How do you maintain interoperability between the DHCP server > and clients from multiple vendors, if the server may return > the timezone in an OS-proprietary format? Its basically through vendor-options/class ids. Based on the class-ids the server can provide different information for the same entity to the different clients. This is the conventional methodology done from DHCPv4 onwards. > You mentioned > earlier that this timezone information is set on a per-subnet > basis, with the assumption that all clients on the same > subnet are in the same timezone. Do you also > assume that all clients on the same subnet are running the same OS? No, certainly not. There can be clients running different OS. But, they will be differentiated by the server. > > > > > To avoid attacks through these options, the DHCP client > SHOULD use > > > > authenticated DHCP (see section "Authentication of DHCP > messages" > > > > in the DHCPv6 specification [1]). > > > > > > Why only a "SHOULD"? Given the critical nature of time > information > > > to some security protocols, I would prefer a statement that this > > > option MUST only be used when the DHCP messages are > authenticated. > > > Is there a reason not to say that? > > > > As such authentication is not mandatory in the DHCPv6 > > specification (RFC 3315) except for reconfiguration. That's the > > reason why "MUST" is not used here. > > True, although we could require that DHCP security be > implemented and used whenever certain sensitive options are > in use... I'm not sure what sort of policy has been used for > deciding this in the > past, though. > > > > > [2] D. Mills. Simple Network Time Protocol (SNTP) > > > > Version 4 for IPv4, IPv6 and OSI. Request for Comments > > > > (Informational) 2030, Internet Engineering Task Force, > > > > October 1996. > > > > > > This should be a reference to NTP, not to SNTP. > > > > Basically, the NTP servers I am referring are SNTP servers. I > > believe, I could change the "NTP server option" to "SNTP server > > option". > > If that is more accurate, then I think it would make sense to > make that change. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 6 16:06:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20248; Mon, 6 Oct 2003 16:06:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6bcH-00074N-2F; Mon, 06 Oct 2003 16:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6bbc-00072U-WC for dhcwg@optimus.ietf.org; Mon, 06 Oct 2003 16:05:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20181 for ; Mon, 6 Oct 2003 16:05:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6bba-00033D-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 16:05:18 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A6bba-00032r-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 16:05:18 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 06 Oct 2003 13:12:09 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h96K4j5g029016 for ; Mon, 6 Oct 2003 16:04:45 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-201.cisco.com [10.82.240.201]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACX89274; Mon, 6 Oct 2003 16:04:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20031006155851.048a9f60@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Oct 2003 16:04:42 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Extending the DHCPv4 option codes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , By my rough count, once the option codes list in draft-ietf-dhc-unused-optioncodes-07 are returned to the list of available DHCP option codes, there will be about 20 option codes available for assignment to new options. We currently have fewer than five documents specifying new options in the dhc WG document queue, leaving us about 15 option codes for future assignment. draft-ietf-dhc-extended-optioncodes-00 proposes a couple of ways to extend the list of available option codes. At least one of the proposed mechanisms would take some time to implement, so we should start a decision process now to give us enough time to implement whatever mechanism we eventually settle on. Please review draft-ietf-dhc-extended-optioncodes-00 and comment on the proposed mechanisms. Feel free to suggest an atlernative if you have a better idea... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 6 18:43:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26723; Mon, 6 Oct 2003 18:43:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6e4D-0005L8-9r; Mon, 06 Oct 2003 18:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6e3x-0005Ks-6x for dhcwg@optimus.ietf.org; Mon, 06 Oct 2003 18:42:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26705 for ; Mon, 6 Oct 2003 18:42:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6e3u-0005EW-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 18:42:42 -0400 Received: from [206.80.111.140] (helo=quiet-like-a-panther.org) by ietf-mx with smtp (Exim 4.12) id 1A6e3t-0005ES-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 18:42:41 -0400 Received: (qmail 2308 invoked by uid 511); 6 Oct 2003 22:42:10 -0000 Message-ID: <20031006224210.2307.qmail@quiet-like-a-panther.org> References: <4.3.2.7.2.20031006155851.048a9f60@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20031006155851.048a9f60@flask.cisco.com> From: Michael Johnston To: Ralph Droms Cc: dhcwg@ietf.org Date: Mon, 06 Oct 2003 22:42:10 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: Extending the DHCPv4 option codes Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A few comments on three of the proposals outlined in the introduction. From a DHCP client boot ROM point of view, this list is in my order of preference. 1.1: Extending DHCP option codes using options 126 and 127. Easy to implement and parse additional options with very little code overhead. 1.2: Using site-specific options. Most of the additional options from 136 through 223 can be used without too many issues with large installations. Options 128 through 135 are requested by all PXE (and many non-PXE) boot ROMs (including boot ROMs built into BIOSes) and are expected to be used by site specific pre-boot applications. If this route is taken, my suggestion would be to leave 128 through 135 and 224 through 254 as site specific options. 1.4: New magik cookie with 16-bit options. My biggest concern would be with operation with existing relay agents. Has there been any testing in this area? My next concern is with small boot ROM limitations. It is tough enough to implement an IP stack + DHCP client + site features into 8kB through 32kB boot ROMs. (Yes, I know that NICs with larger FLASH chips are available, but using the larger chips on a NIC or motherboard is usually not acceptable.) Adding another layer of packet building and parsing code in some of the cases I have come across would not be possible. %%michael Ralph Droms writes: > By my rough count, once the option codes list in > draft-ietf-dhc-unused-optioncodes-07 are returned to the list of available > DHCP option codes, there will be about 20 option codes available for > assignment to new options. We currently have fewer than five documents > specifying new options in the dhc WG document queue, leaving us about 15 > option codes for future assignment. > > draft-ietf-dhc-extended-optioncodes-00 proposes a couple of ways to extend > the list of available option codes. At least one of the proposed > mechanisms > would take some time to implement, so we should start a decision process > now > to give us enough time to implement whatever mechanism we eventually > settle on. > > Please review draft-ietf-dhc-extended-optioncodes-00 and comment on the > proposed mechanisms. Feel free to suggest an atlernative if you have a > better idea... > > - Ralph > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 6 19:57:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28622; Mon, 6 Oct 2003 19:57:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6fDo-00081O-Ov; Mon, 06 Oct 2003 19:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6fDG-000813-N2 for dhcwg@optimus.ietf.org; Mon, 06 Oct 2003 19:56:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28590 for ; Mon, 6 Oct 2003 19:56:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6fDE-0005tZ-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 19:56:24 -0400 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1A6fDE-0005tW-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 19:56:24 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h96NuFYp079853; Mon, 6 Oct 2003 19:56:23 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Michael Johnston'" Cc: Subject: RE: [dhcwg] Re: Extending the DHCPv4 option codes Date: Mon, 6 Oct 2003 19:56:20 -0400 Message-ID: <000001c38c65$73e6b1b0$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <20031006224210.2307.qmail@quiet-like-a-panther.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Michael: Thanks much for the comments. I'll let a few days go by and then work on updating the I-D with your comments. Personally, I like using the site-specific options range because it puts = all options on an equal footing (using the extended options requires a more significant implementation effort for the first option that makes use of this extended space; though once done, additional options aren't = significant work). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Michael Johnston Sent: Monday, October 06, 2003 6:42 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: [dhcwg] Re: Extending the DHCPv4 option codes A few comments on three of the proposals outlined in the introduction. = From a DHCP client boot ROM point of view, this list is in my order of=20 preference. 1.1: Extending DHCP option codes using options 126 and 127. Easy to implement and parse additional options with very little code=20 overhead.=20 1.2: Using site-specific options. Most of the additional options from 136 through 223 can be used without = too=20 many issues with large installations. Options 128 through 135 are = requested by all PXE (and many non-PXE) boot ROMs (including boot ROMs built into=20 BIOSes) and are expected to be used by site specific pre-boot = applications. If this route is taken, my suggestion would be to leave 128 through 135 = and=20 224 through 254 as site specific options.=20 1.4: New magik cookie with 16-bit options. My biggest concern would be with operation with existing relay agents. = Has=20 there been any testing in this area? My next concern is with small boot ROM limitations. It is tough enough = to=20 implement an IP stack + DHCP client + site features into 8kB through = 32kB=20 boot ROMs. (Yes, I know that NICs with larger FLASH chips are = available,=20 but using the larger chips on a NIC or motherboard is usually not=20 acceptable.) Adding another layer of packet building and parsing code = in=20 some of the cases I have come across would not be possible.=20 %%michael=20 =20 Ralph Droms writes:=20 > By my rough count, once the option codes list in > draft-ietf-dhc-unused-optioncodes-07 are returned to the list of = available > DHCP option codes, there will be about 20 option codes available for > assignment to new options. We currently have fewer than five = documents > specifying new options in the dhc WG document queue, leaving us about = 15 > option codes for future assignment.=20 >=20 > draft-ietf-dhc-extended-optioncodes-00 proposes a couple of ways to = extend > the list of available option codes. At least one of the proposed=20 > mechanisms > would take some time to implement, so we should start a decision = process=20 > now > to give us enough time to implement whatever mechanism we eventually=20 > settle on.=20 >=20 > Please review draft-ietf-dhc-extended-optioncodes-00 and comment on = the > proposed mechanisms. Feel free to suggest an atlernative if you have = a > better idea...=20 >=20 > - Ralph=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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 7 10:52:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04964; Tue, 7 Oct 2003 10:52:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tBx-0004fQ-5B; Tue, 07 Oct 2003 10:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tBW-0004ee-FX for dhcwg@optimus.ietf.org; Tue, 07 Oct 2003 10:51:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04924; Tue, 7 Oct 2003 10:51:23 -0400 (EDT) Message-Id: <200310071451.KAA04924@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 07 Oct 2003 10:51:22 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-mipadvert-opt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Option for Mobile IP Mobility Agents Author(s) : H. Levkowetz Filename : draft-ietf-dhc-mipadvert-opt-01.txt Pages : 9 Date : 2003-10-7 This document defines a new Dynamic Host Configuration Protocol (DHCP) option with suboptions. One suboption is passed from the DHCP Server to the DHCP Client to announce the presence of one or more Mobile IP Mobility Agents. For each announced Mobility Agent, information is provided which is the same as that of the Mobile IP Agent Advertisement extension to ICMP Router Advertisements. There is also one suboption which may be used by a DHCP client to provide identity information to the DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-mipadvert-opt-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-mipadvert-opt-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-7110626.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-mipadvert-opt-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-7110626.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 7 11:40:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04963; Tue, 7 Oct 2003 10:52:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tBw-0004fI-NS; Tue, 07 Oct 2003 10:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tB5-0004e3-EX for dhcwg@optimus.ietf.org; Tue, 07 Oct 2003 10:51:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04890; Tue, 7 Oct 2003 10:50:56 -0400 (EDT) Message-Id: <200310071450.KAA04890@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 07 Oct 2003 10:50:56 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-stateless-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : A Guide to Implementing Stateless DHCPv6 Service Author(s) : R. Droms Filename : draft-ietf-dhc-dhcpv6-stateless-01.txt Pages : 8 Date : 2003-10-7 Stateless DHCPv6 service is used by nodes to obtain configuration information such as the addresses of DNS recursive name servers that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document is a guide to the protocol messages and options that must be implemented to provide stateless DHCPv6 service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-stateless-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-stateless-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-7110540.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-stateless-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-stateless-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-7110540.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 7 13:54:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13618; Tue, 7 Oct 2003 13:54:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w25-000607-Hc; Tue, 07 Oct 2003 13:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6w1e-0005zM-Mj for dhcwg@optimus.ietf.org; Tue, 07 Oct 2003 13:53:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13591 for ; Tue, 7 Oct 2003 13:53:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6w1J-0001OF-00 for dhcwg@ietf.org; Tue, 07 Oct 2003 13:53:13 -0400 Received: from cs180094.pp.htv.fi ([213.243.180.94] helo=hades.pp.htv.fi) by ietf-mx with esmtp (Exim 4.12) id 1A6w1H-0001OB-00 for dhcwg@ietf.org; Tue, 07 Oct 2003 13:53:11 -0400 Received: from hades.pp.htv.fi (localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-4) with ESMTP id h97Hs0Ym006999; Tue, 7 Oct 2003 20:54:01 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-4) id h97Hrw6C006998; Tue, 7 Oct 2003 20:53:58 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP From: Mika Liljeberg To: Erik Guttman Cc: Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu In-Reply-To: <3F82A7CA.2030200@sun.com> References: <3F79B93E.6030601@sun.com> <1064944549.4769.5.camel@hades> <3F7A9189.2090709@sun.com> <1065026476.4768.95.camel@hades> <3F82A7CA.2030200@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1065549238.6682.26.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 07 Oct 2003 20:53:58 +0300 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Erik, I know we have a (more than rough) WG consensus to not configure a link-local at the same time with a routable address but we should not take that contraint beyond the point where it stops being useful. Remember that we made this decision to protect a small class of applications that may fail, because they are unaware that they are not supposed to pass LLs around. If it is not possible to verify that a routable address is working we're faced with a situation where nearly ALL applications will break (due to having no connectivity at all) if we make the wrong choise. In this situation, having BOTH the routable address and the LL configured at the same time is simply the least desctructive option. So what I'm trying to say is, if we have a valid DHCP lease and we can't get a response from the DHCP server, there is absolutely no reason why we should discard that lease prior to configuring a LL. In this case it is acceptable to configure both. I'm not proposing that an implementation SHOULD configure both, merely that it MAY do so. In any case the LL can and should be deprecated as soon as the DHCP server comes back online. As for a manually configured addresses, there is absolutely no reason to prevent a manually configured address from coexisting with a LL address, since the admin can also manually disable the LL if it is not desired. If the admin wants to have both why should be care? MikaL On Tue, 2003-10-07 at 14:47, Erik Guttman wrote: > Mika Liljeberg wrote: > > Nice state machine, although it does not address the case where it is > > uncertain whether a configured address is not working or not. In this > > case a node must be able to configure a LL address, advertise it, and > > allow applications to fall back on it. There are two very common ad-hoc > > cases where this can happen: 1) manually configured address in an > > invalid context, and 2) valid DHCP lease in an invalid context. > > Mika, > > You are not satisfied with the arcs in the state machine which > lead to 'EXIT' since they do not spell out the exact conditions > in which an interface 'has been configured'. > > I remind (as wg chair) > > - We have already ruled out the formal application of IPv4LL > 'in all cases' or 'to provide IP configuration in the case > of *misconfiguration*' to provide robustness, etc. > > I believe (as wg participant, not as wg chair) > > - We must rule out the case where the IPv4LL spec 'overrules' > manually configured addresses. > > - We must cautiously state what it means to be configured with > a DHCP - as we may 'wake up' with a valid lease in a context > other than that which DHCP configured the host. > > We have already had this discussion. It hinges upon a passage > in RFC 2131: > > 3.7 When clients should use DHCP > > A client SHOULD use DHCP to reacquire or verify its IP address and > network parameters whenever the local network parameters may have > changed; e.g., at system boot time or after a disconnection from the > local network, as the local network configuration may change without > the client's or user's knowledge. > > If a client has knowledge of a previous network address and is unable > to contact a local DHCP server, the client may continue to use the > previous network address until the lease for that address expires. > > Note the word >>may<<. > > Thus, the implementor of IPv4LL has discretion. I suggest that we > > 1) add a new section: > > 2.12 Transition from Routable Address to Link-Local > > A host may 'wake up' (see Section 2.2) with a valid DHCP > lease. According to RFC 2131, Section 3.7: > > A client SHOULD use DHCP to reacquire or verify its > IP address and network parameters whenever the local > network parameters may have changed; e.g., at system > boot time or after a disconnection from the local > network, as the local network configuration may change > without the client's or user's knowledge. > > If a client has knowledge of a previous network address > and is unable to contact a local DHCP server, the client > may continue to use the previous network address until > the lease for that address expires. > > Before a host with a valid DHCP address configures an IPv4 > LL address it MUST use DHCP to attempt to reacquire or > verify its IP address and network parameters. In the case > where the the DHCP client is unable to contact a local DHCP > server, the behavior of the IPv4 link-local configuration > implementation is not specified. The implementor has a > choice: Either abandon the DHCP lease and configure a > link-local address or retain the previous network address. > > Implementors are faced with a trade-off: 'Robustness to > DHCP Server Unresponsiveness' versus 'Rapid Transition to > Autoconfigured State'. > > If DHCP configuration parameters continue to be used > despite the DHCP server's lack of response, the client > will be more robust to transient DHCP server inavailability. > The disadvantage is that a mobile host removed from the > context in which it received a long-duration lease will not > autoconfigure. This means, for example, that a laptop > computer may continue to use the configuration it received > 'at work' even though the owner is currently 'at home.' > > If autoconfiguration occurs as soon as it has been determined > that the DHCP client is unable to contact a local DHCP server, > the host will respond to 'waking up' in a new network > environment. This will allow the host to communicate with > other hosts which implement this specification on the link > as soon as possible. The disadvantage of this strategy is > that it will encourage unneeded and disruptive interface > configuration changes in the case where a DHCP server is > unresponsive for a short period of time. > > Retaining the configuration supplied by DHCP emphasizes > stability of service for hosts on centrally configured > networks. This is the most prevalent networking context > today. Users are easily annoyed if their hosts become > reconfigured and unusable for several minutes at a time, > which is the likely outcome if a spurious configured to > link-local transition is undertaken. Obtaining > autoconfiguration parameters as quickly as possible > (according to the protocol timers defined by RFC 2131 and > this specification) benefits the mobile user whose host > finds itself in different networking contexts and wishes > to gain access to their resources immediately. > > 2) add the state machine below to the IPv4 LL specification in a > new section: > > 2.13 IPv4 Linklocal Configuration State Machine > > > > I think that this addresses your concerns and would greatly improve > the draft. This gets to the heart of Ted's concerns, too, I think. > > Erik > > > On Wed, 2003-10-01 at 11:34, Erik Guttman wrote: > >>We do not have a diagram of a state machine for IPv4LL, but perhaps > >>that would be very useful. I think it would look something like > >>this: > >> > >> Interface is active and has no <---------------------+ > >> IPv4 address configured | > >> | | > >> v interface has IPv4 addr configured? | > >> +--> INIT ---------------------------------------> EXIT > >> | | 2.2 1.7 ^ ^ > >> | v <-------------------+ | | > >> | SELECT <---+ | | | > >> | | 2.1 | ARP with | | | > >> | v | claimed | | | > >> | CLAIM | address ADAGIO | | > >> | ^ | 2.2.1| received ^ | | > >> | 2.2.1 | v --+ |2.2.1 | | > >> | CLAIM-WAIT ------------------+ | | > >> | | 2.2.1 -----------------------------------+ | > >> 2.5 | v interface has IPv4 addr configured? | > >> > >> DOUBT ANNOUNCE 1.7 | > >> > >> ^| | 2.4 | > >> |+-> v interface has IPv4 addr configured? | > >> +-- CONFIGURED ------------------------------> DEPRECATED > >> 2.5 ^ | 2.5 1.7 > >>conflict! | | > >> +-----+ > >> defend > >> > >> State Behavior > >> ========== ============================================= > >> INIT Host has no configured IPv4 address on an > >> interface. INIT waits before entering SELECT > >> state. If INIT detects it has been configured > >> during this time, INIT goes to EXIT state. See > >> Section 2.2. > >> > >> SELECT Select a suitable address. See Section 2.1. The > >> only possible transition is to CLAIM state. > >> > >> A special case of SELECT is where the host has > >> woken up and previously had a link-local address > >> configured. In this case, the previously configured > >> is selected. See Section 2.2. > >> > >> CLAIM Send a probe as per Section 2.2. > >> > >> CLAIM-WAIT Wait for any ARP messages with the claimed > >> address originating from a different sender. > >> > >> If interface is configured during this wait > >> period enter EXIT state, do not configure an > >> IPv4 LL address. See Section 1.7. > >> > >> If an ARP message indicates that the selected > >> address is in use, and this is the first through > >> nineth retry, enter SELECT state. If this is > >> the tenth or more retry, enter ADAGIO state. > >> See Section 2.2.1. > >> > >> If no ARP message is detected as the result of > >> the probe after the wait duration ends, and this > >> is the first or second try, return to CLAIM state. > >> If this is the third try, enter the CONFIGURED > >> state. See Section 2.2.1. > >> > >> ADDAGIO Wait at least a minute then enter SELECT state. > >> > >> ANNOUNCE Send ARP announcements the enter CONFIGURED > >> state. > >> > >> CONFIGURED The link-local address has been configured for > >> the interface and is now usable. The host must > >> respond to three events. > >> > >> If a claim is detected, respond with a defending > >> ARP. Stay in CONFIGURED state. > >> > >> If an ARP with a conflicting assignment of the > >> configured address is detected, defense may be > >> undertaken once (enter the state of DOUBT) or > >> go directly to INIT state, surrendering the > >> configured address. > >> > >> DOUBT If an ARP with a source address is detecting > >> which conflicts with the configured address > >> during 10 seconds, proceed to INIT state. > >> See Section 2.5. > >> > >> Otherwise, the conflicting use of the address > >> has been defended against. Return to the > >> CONFIGURED state. See Section 2.5. > >> > >> DEPRECATED This state is entered when a link-local address > >> has been autoconfigured for an interface, then > >> subsequently the interface receives a configured > >> address (as from DHCP). In this state, new > >> connections are established with the configured > >> address and the link-local address is not advertised. > >> Eventually, one SHOULD transition to EXIT state. > >> See Section 1.7. > >> > >> EXIT Cease using the IPv4 link-local address, do not > >> attempt to configure another such address unless > >> an interface exists for which there is no IPv4 > >> link-local address configured. > >> > >> > >> > >>I hope that this makes it clear: In each case where there is > >>a transition marked "interface has IPv4 addr configured? 1.7" > >>this could be caused by the DHCP state machine entering BOUND > >>state. It is also possible to transition from EXIT to INIT > >>in the case where a configured address is no longer available. > >>We do not enter into a full discussion of this transition in > >>this specification. It is considered in more detail in > >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt > >> > >>Erik > >> > > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 7 18:05:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24435; Tue, 7 Oct 2003 18:05:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6zwz-0001rC-Ng; Tue, 07 Oct 2003 18:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6ZTv-0001kV-Hq for dhcwg@optimus.ietf.org; Mon, 06 Oct 2003 13:49:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14540 for ; Mon, 6 Oct 2003 13:49:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6ZTt-0001bT-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 13:49:13 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1A6ZTs-0001bQ-00 for dhcwg@ietf.org; Mon, 06 Oct 2003 13:49:12 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:21a9:cd3a:6004:17fc]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 2D48B152E1 for ; Tue, 7 Oct 2003 02:49:10 +0900 (JST) Date: Tue, 07 Oct 2003 02:49:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-interop-01.txt In-Reply-To: <4.3.2.7.2.20031006130314.058220b8@flask.cisco.com> References: <4.3.2.7.2.20031006130314.058220b8@flask.cisco.com> User-Agent: Wanderlust/2.10.0 (Venus) 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Mon, 06 Oct 2003 13:05:25 -0400, >>>>> Ralph Droms said: > The issues documented in draft-ietf-dhc-dhcpv6-interop-01.txt, "Results from > Interoperability Tests of DHCPv6 Implementations", were all addressed in the > DHCPv6 spec prior to its publication as RFC3315. > draft-ietf-dhc-dhcpv6-interop-01.txt is about to expire; does anyone have an > argument for publishing it as Informational or otherwise archiving it? Please let me check, do you want to let the draft expire, or do you want to publish (archive) it in some way? (or are you just asking?) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 7 18:55:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24434; Tue, 7 Oct 2003 18:05:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6zx0-0001rK-Am; Tue, 07 Oct 2003 18:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6qK2-0004pa-0o for dhcwg@optimus.ietf.org; Tue, 07 Oct 2003 07:48:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27780 for ; Tue, 7 Oct 2003 07:48:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6qK1-0004Op-00 for dhcwg@ietf.org; Tue, 07 Oct 2003 07:48:09 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1A6qK0-0004Om-00 for dhcwg@ietf.org; Tue, 07 Oct 2003 07:48:08 -0400 Received: from jurassic.eng.sun.com ([129.146.81.144]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h97Bm7kv024105; Tue, 7 Oct 2003 05:48:07 -0600 (MDT) Received: from sun.com (vpn-129-156-97-54.EMEA.Sun.COM [129.156.97.54]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h97Bm3KS335151; Tue, 7 Oct 2003 04:48:04 -0700 (PDT) Message-ID: <3F82A7CA.2030200@sun.com> Date: Tue, 07 Oct 2003 13:47:22 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Mika Liljeberg CC: Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP References: <3F79B93E.6030601@sun.com> <1064944549.4769.5.camel@hades> <3F7A9189.2090709@sun.com> <1065026476.4768.95.camel@hades> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mika Liljeberg wrote: > Nice state machine, although it does not address the case where it is > uncertain whether a configured address is not working or not. In this > case a node must be able to configure a LL address, advertise it, and > allow applications to fall back on it. There are two very common ad-hoc > cases where this can happen: 1) manually configured address in an > invalid context, and 2) valid DHCP lease in an invalid context. Mika, You are not satisfied with the arcs in the state machine which lead to 'EXIT' since they do not spell out the exact conditions in which an interface 'has been configured'. I remind (as wg chair) - We have already ruled out the formal application of IPv4LL 'in all cases' or 'to provide IP configuration in the case of *misconfiguration*' to provide robustness, etc. I believe (as wg participant, not as wg chair) - We must rule out the case where the IPv4LL spec 'overrules' manually configured addresses. - We must cautiously state what it means to be configured with a DHCP - as we may 'wake up' with a valid lease in a context other than that which DHCP configured the host. We have already had this discussion. It hinges upon a passage in RFC 2131: 3.7 When clients should use DHCP A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network, as the local network configuration may change without the client's or user's knowledge. If a client has knowledge of a previous network address and is unable to contact a local DHCP server, the client may continue to use the previous network address until the lease for that address expires. Note the word >>may<<. Thus, the implementor of IPv4LL has discretion. I suggest that we 1) add a new section: 2.12 Transition from Routable Address to Link-Local A host may 'wake up' (see Section 2.2) with a valid DHCP lease. According to RFC 2131, Section 3.7: A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network, as the local network configuration may change without the client's or user's knowledge. If a client has knowledge of a previous network address and is unable to contact a local DHCP server, the client may continue to use the previous network address until the lease for that address expires. Before a host with a valid DHCP address configures an IPv4 LL address it MUST use DHCP to attempt to reacquire or verify its IP address and network parameters. In the case where the the DHCP client is unable to contact a local DHCP server, the behavior of the IPv4 link-local configuration implementation is not specified. The implementor has a choice: Either abandon the DHCP lease and configure a link-local address or retain the previous network address. Implementors are faced with a trade-off: 'Robustness to DHCP Server Unresponsiveness' versus 'Rapid Transition to Autoconfigured State'. If DHCP configuration parameters continue to be used despite the DHCP server's lack of response, the client will be more robust to transient DHCP server inavailability. The disadvantage is that a mobile host removed from the context in which it received a long-duration lease will not autoconfigure. This means, for example, that a laptop computer may continue to use the configuration it received 'at work' even though the owner is currently 'at home.' If autoconfiguration occurs as soon as it has been determined that the DHCP client is unable to contact a local DHCP server, the host will respond to 'waking up' in a new network environment. This will allow the host to communicate with other hosts which implement this specification on the link as soon as possible. The disadvantage of this strategy is that it will encourage unneeded and disruptive interface configuration changes in the case where a DHCP server is unresponsive for a short period of time. Retaining the configuration supplied by DHCP emphasizes stability of service for hosts on centrally configured networks. This is the most prevalent networking context today. Users are easily annoyed if their hosts become reconfigured and unusable for several minutes at a time, which is the likely outcome if a spurious configured to link-local transition is undertaken. Obtaining autoconfiguration parameters as quickly as possible (according to the protocol timers defined by RFC 2131 and this specification) benefits the mobile user whose host finds itself in different networking contexts and wishes to gain access to their resources immediately. 2) add the state machine below to the IPv4 LL specification in a new section: 2.13 IPv4 Linklocal Configuration State Machine I think that this addresses your concerns and would greatly improve the draft. This gets to the heart of Ted's concerns, too, I think. Erik > On Wed, 2003-10-01 at 11:34, Erik Guttman wrote: >>We do not have a diagram of a state machine for IPv4LL, but perhaps >>that would be very useful. I think it would look something like >>this: >> >> Interface is active and has no <---------------------+ >> IPv4 address configured | >> | | >> v interface has IPv4 addr configured? | >> +--> INIT ---------------------------------------> EXIT >> | | 2.2 1.7 ^ ^ >> | v <-------------------+ | | >> | SELECT <---+ | | | >> | | 2.1 | ARP with | | | >> | v | claimed | | | >> | CLAIM | address ADAGIO | | >> | ^ | 2.2.1| received ^ | | >> | 2.2.1 | v --+ |2.2.1 | | >> | CLAIM-WAIT ------------------+ | | >> | | 2.2.1 -----------------------------------+ | >> 2.5 | v interface has IPv4 addr configured? | >> >> DOUBT ANNOUNCE 1.7 | >> >> ^| | 2.4 | >> |+-> v interface has IPv4 addr configured? | >> +-- CONFIGURED ------------------------------> DEPRECATED >> 2.5 ^ | 2.5 1.7 >>conflict! | | >> +-----+ >> defend >> >> State Behavior >> ========== ============================================= >> INIT Host has no configured IPv4 address on an >> interface. INIT waits before entering SELECT >> state. If INIT detects it has been configured >> during this time, INIT goes to EXIT state. See >> Section 2.2. >> >> SELECT Select a suitable address. See Section 2.1. The >> only possible transition is to CLAIM state. >> >> A special case of SELECT is where the host has >> woken up and previously had a link-local address >> configured. In this case, the previously configured >> is selected. See Section 2.2. >> >> CLAIM Send a probe as per Section 2.2. >> >> CLAIM-WAIT Wait for any ARP messages with the claimed >> address originating from a different sender. >> >> If interface is configured during this wait >> period enter EXIT state, do not configure an >> IPv4 LL address. See Section 1.7. >> >> If an ARP message indicates that the selected >> address is in use, and this is the first through >> nineth retry, enter SELECT state. If this is >> the tenth or more retry, enter ADAGIO state. >> See Section 2.2.1. >> >> If no ARP message is detected as the result of >> the probe after the wait duration ends, and this >> is the first or second try, return to CLAIM state. >> If this is the third try, enter the CONFIGURED >> state. See Section 2.2.1. >> >> ADDAGIO Wait at least a minute then enter SELECT state. >> >> ANNOUNCE Send ARP announcements the enter CONFIGURED >> state. >> >> CONFIGURED The link-local address has been configured for >> the interface and is now usable. The host must >> respond to three events. >> >> If a claim is detected, respond with a defending >> ARP. Stay in CONFIGURED state. >> >> If an ARP with a conflicting assignment of the >> configured address is detected, defense may be >> undertaken once (enter the state of DOUBT) or >> go directly to INIT state, surrendering the >> configured address. >> >> DOUBT If an ARP with a source address is detecting >> which conflicts with the configured address >> during 10 seconds, proceed to INIT state. >> See Section 2.5. >> >> Otherwise, the conflicting use of the address >> has been defended against. Return to the >> CONFIGURED state. See Section 2.5. >> >> DEPRECATED This state is entered when a link-local address >> has been autoconfigured for an interface, then >> subsequently the interface receives a configured >> address (as from DHCP). In this state, new >> connections are established with the configured >> address and the link-local address is not advertised. >> Eventually, one SHOULD transition to EXIT state. >> See Section 1.7. >> >> EXIT Cease using the IPv4 link-local address, do not >> attempt to configure another such address unless >> an interface exists for which there is no IPv4 >> link-local address configured. >> >> >> >>I hope that this makes it clear: In each case where there is >>a transition marked "interface has IPv4 addr configured? 1.7" >>this could be caused by the DHCP state machine entering BOUND >>state. It is also possible to transition from EXIT to INIT >>in the case where a configured address is no longer available. >>We do not enter into a full discussion of this transition in >>this specification. It is considered in more detail in >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt >> >>Erik >> > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 7 21:05:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00215; Tue, 7 Oct 2003 21:05:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A72lC-0001wn-Fs; Tue, 07 Oct 2003 21:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A72kP-0001w3-P9 for dhcwg@optimus.ietf.org; Tue, 07 Oct 2003 21:04:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00171 for ; Tue, 7 Oct 2003 21:04:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A72kN-000676-00 for dhcwg@ietf.org; Tue, 07 Oct 2003 21:04:11 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A72kM-000673-00 for dhcwg@ietf.org; Tue, 07 Oct 2003 21:04:10 -0400 Received: from fugue.com (dialup-171.75.232.59.Dial1.SaintLouis1.Level3.net [171.75.232.59]) by toccata.fugue.com (Postfix) with ESMTP id 2B4101B200C; Tue, 7 Oct 2003 20:02:50 -0500 (CDT) Date: Tue, 7 Oct 2003 20:04:06 -0500 Subject: Re: [dhcwg] Re: Extending the DHCPv4 option codes Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org To: Michael Johnston From: Ted Lemon In-Reply-To: <20031006224210.2307.qmail@quiet-like-a-panther.org> Message-Id: <5112EB78-F92B-11D7-9773-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > My biggest concern would be with operation with existing relay agents. > Has there been any testing in this area? If we extend option codes by using options 126 and 127, it's no problem, because we just put the option extension code *after* the length, and then anything that doesn't know about these options skips them. A simple relay agent would do fine with a different magic cookie too. It would not do well with relay agents that implement option 82. However, I think the simplest choice is to steal some of the site-specific options, which at this point are never used. > My next concern is with small boot ROM limitations. It is tough > enough to implement an IP stack + DHCP client + site features into 8kB > through 32kB boot ROMs. (Yes, I know that NICs with larger FLASH > chips are available, but using the larger chips on a NIC or > motherboard is usually not acceptable.) Adding another layer of > packet building and parsing code in some of the cases I have come > across would not be possible. > %%michael This also argues for just stealing some of the site-specific options. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 8 01:42:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05854; Wed, 8 Oct 2003 01:42:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A775E-0005JM-IB; Wed, 08 Oct 2003 01:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A774b-0005DB-Ed for dhcwg@optimus.ietf.org; Wed, 08 Oct 2003 01:41:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05787 for ; Wed, 8 Oct 2003 01:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A774Y-0000V7-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 01:41:18 -0400 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1A774X-0000Uh-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 01:41:17 -0400 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h985f3v22169; Wed, 8 Oct 2003 12:41:05 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h985ecP22325; Wed, 8 Oct 2003 12:40:47 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: Michael Johnston , dhcwg@ietf.org Subject: Re: [dhcwg] Re: Extending the DHCPv4 option codes In-Reply-To: <5112EB78-F92B-11D7-9773-000A95D9C74C@fugue.com> References: <5112EB78-F92B-11D7-9773-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Oct 2003 12:40:38 +0700 Message-ID: <18395.1065591638@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Tue, 7 Oct 2003 20:04:06 -0500 From: Ted Lemon Message-ID: <5112EB78-F92B-11D7-9773-000A95D9C74C@fugue.com> | However, I think the simplest choice is to steal some of | the site-specific options, which at this point are never used. I'd agree with that, but I'd expect the right answer, rather than necessarily the simplest, will depend upon how long people expect there to remain serious interest in extending DHCP (for v4). That is, if you believe that people will still be inventing new options for DHCP 10 years from now, the site specific option space will probably run out as well, and there'd need to be yet another method invented to add new options. In that case, it would be better to simply add lots more options now (using the 126/127 technique - and make the new option numbers allocated out there 16 bits). On the other hand, if the general belief is that while DHCP for IPv4 might still be in use 10 years from now, no-one will care enough about it to still be inventing new options, then all that's needed is enough option codes to last that long - and in that case, the site specific option space is quite likely the right way to go (there are only a few new options defined a year it seems). kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 8 10:41:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18156; Wed, 8 Oct 2003 10:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7FUr-0001Tk-3E; Wed, 08 Oct 2003 10:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7FUE-0001SN-4f for dhcwg@optimus.ietf.org; Wed, 08 Oct 2003 10:40:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18004; Wed, 8 Oct 2003 10:40:11 -0400 (EDT) Message-Id: <200310081440.KAA18004@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 08 Oct 2003 10:40:10 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : IPv6 Prefix Options for DHCPv6 Author(s) : O. Troan, R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05.txt Pages : 20 Date : 2003-10-8 The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This mechanism is intended for delegating long-lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-8102251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-8102251.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 8 12:54:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27219; Wed, 8 Oct 2003 12:54:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HZZ-0002Hf-19; Wed, 08 Oct 2003 12:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HZS-0002H9-U2 for dhcwg@optimus.ietf.org; Wed, 08 Oct 2003 12:53:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27183 for ; Wed, 8 Oct 2003 12:53:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7HZR-00015N-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 12:53:53 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7HZP-00014z-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 12:53:52 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Oct 2003 09:54:16 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h98GrIcZ018456 for ; Wed, 8 Oct 2003 09:53:19 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACZ40352; Wed, 8 Oct 2003 12:53:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20031008124352.01f4e0c8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Oct 2003 12:53:12 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Re: Extending the DHCPv4 option codes In-Reply-To: <18395.1065591638@munnari.OZ.AU> References: <5112EB78-F92B-11D7-9773-000A95D9C74C@fugue.com> <5112EB78-F92B-11D7-9773-000A95D9C74C@fugue.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Since the publication of RFC 2132, there have been 17 new options added to DHCP (not counting the PXE options and the options in use by Apple; for details, see draft-ietf-dhc-unused-optioncodes-07). Here's the breakdown of number of new options defined per year: 1996 0 1997 5 (RFC 2241, RFC 2242) 1998 0 1999 4 (RFC 2485, RFC 2563, RFC 2610) 2000 3 (RFC 2937, RFC 3004, RFC 3011) 2001 1 (RFC 3118) 2002 3 (RFC 3361, RFC 3397, RFC 3442) 2003 1 (RFC 3495) (note that some RFCs define more than one option) Seems to me the current option space might be good for five years and using even as few as options 128-159 might be enough to last us "forever".... - Ralph At 12:40 PM 10/8/2003 +0700, Robert Elz wrote: > Date: Tue, 7 Oct 2003 20:04:06 -0500 > From: Ted Lemon > Message-ID: <5112EB78-F92B-11D7-9773-000A95D9C74C@fugue.com> > > | However, I think the simplest choice is to steal some of > | the site-specific options, which at this point are never used. > >I'd agree with that, but I'd expect the right answer, rather than >necessarily the simplest, will depend upon how long people expect >there to remain serious interest in extending DHCP (for v4). > >That is, if you believe that people will still be inventing new options >for DHCP 10 years from now, the site specific option space will probably >run out as well, and there'd need to be yet another method invented to >add new options. In that case, it would be better to simply add lots >more options now (using the 126/127 technique - and make the new option >numbers allocated out there 16 bits). > >On the other hand, if the general belief is that while DHCP for IPv4 might >still be in use 10 years from now, no-one will care enough about it to >still be inventing new options, then all that's needed is enough option >codes to last that long - and in that case, the site specific option space >is quite likely the right way to go (there are only a few new options >defined a year it seems). > >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-admin@ietf.org Wed Oct 8 12:58:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27450; Wed, 8 Oct 2003 12:58:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HdR-0002Yn-Rx; Wed, 08 Oct 2003 12:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Hch-0002WC-VS for dhcwg@optimus.ietf.org; Wed, 08 Oct 2003 12:57:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27391 for ; Wed, 8 Oct 2003 12:57:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Hcg-00019V-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 12:57:14 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7Hcf-00018m-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 12:57:13 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Oct 2003 09:57:39 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h98GudJu006905; Wed, 8 Oct 2003 09:56:41 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACZ40704; Wed, 8 Oct 2003 12:56:38 -0400 (EDT) Message-Id: <4.3.2.7.2.20031008125513.02085720@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Oct 2003 12:56:35 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-interop-01.txt Cc: dhcwg@ietf.org In-Reply-To: References: <4.3.2.7.2.20031006130314.058220b8@flask.cisco.com> <4.3.2.7.2.20031006130314.058220b8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Jinmei-san - yes, I'm trying to assess interest in publishing the draft as, for example, an Informational RFC or letting it expire. - Ralph At 02:49 AM 10/7/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Mon, 06 Oct 2003 13:05:25 -0400, > >>>>> Ralph Droms said: > > > The issues documented in draft-ietf-dhc-dhcpv6-interop-01.txt, "Results > from > > Interoperability Tests of DHCPv6 Implementations", were all addressed > in the > > DHCPv6 spec prior to its publication as RFC3315. > > draft-ietf-dhc-dhcpv6-interop-01.txt is about to expire; does anyone > have an > > argument for publishing it as Informational or otherwise archiving it? > >Please let me check, do you want to let the draft expire, or do you >want to publish (archive) it in some way? (or are you just asking?) > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 8 13:04:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27667; Wed, 8 Oct 2003 13:04:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HjE-0002rI-V7; Wed, 08 Oct 2003 13:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7HiQ-0002qb-Tw for dhcwg@optimus.ietf.org; Wed, 08 Oct 2003 13:03:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27618 for ; Wed, 8 Oct 2003 13:03:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7HiP-0001E6-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 13:03:09 -0400 Received: from cs180094.pp.htv.fi ([213.243.180.94] helo=hades.pp.htv.fi) by ietf-mx with esmtp (Exim 4.12) id 1A7HiN-0001E1-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 13:03:08 -0400 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-4) with ESMTP id h98H3HwK002208; Wed, 8 Oct 2003 20:03:17 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-4) id h98H3FIj002207; Wed, 8 Oct 2003 20:03:15 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP From: Mika Liljeberg To: Erik Guttman Cc: Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu In-Reply-To: <3F83DB41.3020408@sun.com> References: <3F79B93E.6030601@sun.com> <1064944549.4769.5.camel@hades> <3F7A9189.2090709@sun.com> <1065026476.4768.95.camel@hades> <3F82A7CA.2030200@sun.com> <1065549238.6682.26.camel@hades> <3F83DB41.3020408@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1065632595.807.53.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 08 Oct 2003 20:03:15 +0300 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wed, 2003-10-08 at 12:39, Erik Guttman wrote: > In the case of the transition from unconfigured to configured there > is clear consensus that one should 'give up' (that is: stop advertising, > stop initiating new connections from and eventually stop accepting > communication from) a link-local configured address. [I presume you're using the terms configured and unconfigured to refer to the routable address. The usage in the v4LL state machine description is inverted.] Agreed. > In the case of the transition from configured to unconfigured there > is no clear consensus yet. > > Choices are > - give up dhcp configuration and configure link-local > - hold onto dhcp configuration and don't configure link-local > > These I discussed in the text I suggested. (Does that text make sense?) > > - hold onto dhcp configuration and configure link-local > > This is a problematic situation in that the host is now 'multihomed', > with all the attendant problems we have discussed ad nauseum. One > way to address this is to mention that this implementation is in no > way ruled out, but neither is it specified, and refer anyone > interested in pursuing this option to section 3. The really difficult problem here is *when* to transition, a problem which we have been unable to solve. Having both addresses configured during the transition period actually makes a lot of sense. While a reference to section 3 is appropriate, the text should not actively steer implementors away from what may be the only robust way implement this thing. I second Philip's suggestion that the v4LL implementation needs to determine whether there is a "*working* routable address" or not. This should be reflected in the state machine and also discussed in the descriptive text. The state transition from INIT to SELECT is logically triggered by the signal that the validity of the routable address can no longer be confirmed. Similarly, the state transition from CONFIGURED to DEPRECATED is triggered by the signal that a routable address has been configured and validated. > > As for a manually configured addresses, there is absolutely no reason to > > prevent a manually configured address from coexisting with a LL address, > > since the admin can also manually disable the LL if it is not desired. > > If the admin wants to have both why should be care? > > Manual intervention of host configuration is not always possible (to > deconfigure a link-local address, for example). That's purely an implementation issue. It can be done. > The point is, the sensible default policy is that when the host is > configured manually, link-local addresses do not get configured. Yes, I agree this is the sensible default policy as long as the policy is not hardcoded into the state machine. If v4LL is administratively enabled on the interface, the v4LL state machine should be able to proceed from INIT to SELECT when the manually configured address stops working (by whatever criteria the implementation uses to detect such things). > If an implementor wishes to venture into multihoming-territory, we > do not forbid it, but we do list a set of issues of which the > implementor must consider and address. The specification and its > state machine assume the implementor will not go this way. Sadly, I think this is a false assumption. The reality simply is that most implementations are multihomed (even if most deployed hosts are not) and the implementors are faced with having to work out how to accommodate v4LL in their multihomed code. It will be interesting to see how people deal with this dilemma. > ps. please comment on suggested text (from previous message): I'll refrain until I see how the third option gets worked into the text. MikaL _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 8 17:21:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09777; Wed, 8 Oct 2003 17:21:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Ljy-0002lf-N0; Wed, 08 Oct 2003 17:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A71bc-0006mt-5y for dhcwg@optimus.ietf.org; Tue, 07 Oct 2003 19:51:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28260 for ; Tue, 7 Oct 2003 19:50:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A71ba-0005RI-00 for dhcwg@ietf.org; Tue, 07 Oct 2003 19:51:02 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1A71bZ-0005RE-00 for dhcwg@ietf.org; Tue, 07 Oct 2003 19:51:01 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h97NG9j22651; Tue, 7 Oct 2003 16:16:09 -0700 Date: Tue, 7 Oct 2003 16:16:09 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org, zeroconf@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Re: WG consensus action: ACCEPT LL34 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , If a host has an IP address with a valid lifetime, DHCP (or RS/RA for that matter) is not required to confirm it. All that is necessary is a reachability test to the default gateway, confirming that the host is on the network in which the address is valid. The text below makes it seem like it is necessary for the host to send a DHCPREQUEST whenever it wakes up. This is not the case. I'd rather see text relating to transition routable to IPv4LL addresses, like the text relating to transition from LLv4 to routable addresses, handled outside of the IPv4LL specification, such as in the DNAv4 specification. Erik Guttman spoke thusly: Before a host with a valid DHCP address configures an IPv4 LL address it MUST use DHCP to attempt to reacquire or verify its IP address and network parameters. In the case where the the DHCP client is unable to contact a local DHCP server, the behavior of the IPv4 link-local configuration implementation is not specified. The implementor has a choice: Either abandon the DHCP lease and configure a link-local address or retain the previous network address. Implementors are faced with a trade-off: 'Robustness to DHCP Server Unresponsiveness' versus 'Rapid Transition to Autoconfigured State'. If DHCP configuration parameters continue to be used despite the DHCP server's lack of response, the client will be more robust to transient DHCP server inavailability. The disadvantage is that a mobile host removed from the context in which it received a long-duration lease will not autoconfigure. This means, for example, that a laptop computer may continue to use the configuration it received 'at work' even though the owner is currently 'at home.' If autoconfiguration occurs as soon as it has been determined that the DHCP client is unable to contact a local DHCP server, the host will respond to 'waking up' in a new network environment. This will allow the host to communicate with other hosts which implement this specification on the link as soon as possible. The disadvantage of this strategy is that it will encourage unneeded and disruptive interface configuration changes in the case where a DHCP server is unresponsive for a short period of time. Retaining the configuration supplied by DHCP emphasizes stability of service for hosts on centrally configured networks. This is the most prevalent networking context today. Users are easily annoyed if their hosts become reconfigured and unusable for several minutes at a time, which is the likely outcome if a spurious configured to link-local transition is undertaken. Obtaining autoconfiguration parameters as quickly as possible (according to the protocol timers defined by RFC 2131 and this specification) benefits the mobile user whose host finds itself in different networking contexts and wishes to gain access to their resources immediately. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 8 17:21:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09778; Wed, 8 Oct 2003 17:21:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Ljz-0002lr-8q; Wed, 08 Oct 2003 17:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7AnY-0002s0-7S for dhcwg@optimus.ietf.org; Wed, 08 Oct 2003 05:40:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07874 for ; Wed, 8 Oct 2003 05:39:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7AnU-0002nC-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 05:39:56 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1A7AnT-0002n2-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 05:39:56 -0400 Received: from jurassic.eng.sun.com ([129.146.87.130]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h989dvaV004692; Wed, 8 Oct 2003 03:39:57 -0600 (MDT) Received: from sun.com (vpn-129-156-96-207.EMEA.Sun.COM [129.156.96.207]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h989drKS872561; Wed, 8 Oct 2003 02:39:54 -0700 (PDT) Message-ID: <3F83DB41.3020408@sun.com> Date: Wed, 08 Oct 2003 11:39:13 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Mika Liljeberg CC: Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP References: <3F79B93E.6030601@sun.com> <1064944549.4769.5.camel@hades> <3F7A9189.2090709@sun.com> <1065026476.4768.95.camel@hades> <3F82A7CA.2030200@sun.com> <1065549238.6682.26.camel@hades> In-Reply-To: <1065549238.6682.26.camel@hades> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Mika Liljeberg wrote: > I know we have a (more than rough) WG consensus to not configure a > link-local at the same time with a routable address but we should not > take that contraint beyond the point where it stops being useful. > Remember that we made this decision to protect a small class of > applications that may fail, because they are unaware that they are not > supposed to pass LLs around. > > If it is not possible to verify that a routable address is working we're > faced with a situation where nearly ALL applications will break (due to > having no connectivity at all) if we make the wrong choise. In this > situation, having BOTH the routable address and the LL configured at the > same time is simply the least desctructive option. In the case of the transition from unconfigured to configured there is clear consensus that one should 'give up' (that is: stop advertising, stop initiating new connections from and eventually stop accepting communication from) a link-local configured address. In the case of the transition from configured to unconfigured there is no clear consensus yet. Choices are - give up dhcp configuration and configure link-local - hold onto dhcp configuration and don't configure link-local These I discussed in the text I suggested. (Does that text make sense?) - hold onto dhcp configuration and configure link-local This is a problematic situation in that the host is now 'multihomed', with all the attendant problems we have discussed ad nauseum. One way to address this is to mention that this implementation is in no way ruled out, but neither is it specified, and refer anyone interested in pursuing this option to section 3. > So what I'm trying to say is, if we have a valid DHCP lease and we can't > get a response from the DHCP server, there is absolutely no reason why > we should discard that lease prior to configuring a LL. In this case it > is acceptable to configure both. I'm not proposing that an > implementation SHOULD configure both, merely that it MAY do so. In any > case the LL can and should be deprecated as soon as the DHCP server > comes back online. > > As for a manually configured addresses, there is absolutely no reason to > prevent a manually configured address from coexisting with a LL address, > since the admin can also manually disable the LL if it is not desired. > If the admin wants to have both why should be care? Manual intervention of host configuration is not always possible (to deconfigure a link-local address, for example). The point is, the sensible default policy is that when the host is configured manually, link-local addresses do not get configured. If an implementor wishes to venture into multihoming-territory, we do not forbid it, but we do list a set of issues of which the implementor must consider and address. The specification and its state machine assume the implementor will not go this way. In the case of an interface configured with more than one addresses, the state machine is more complex since it needs to take into account such things as changes to the host's routing table. Erik ----------- ps. please comment on suggested text (from previous message): > 2.12 Transition from Routable Address to Link-Local > > A host may 'wake up' (see Section 2.2) with a valid DHCP > lease. According to RFC 2131, Section 3.7: > > A client SHOULD use DHCP to reacquire or verify its > IP address and network parameters whenever the local > network parameters may have changed; e.g., at system > boot time or after a disconnection from the local > network, as the local network configuration may change > without the client's or user's knowledge. > > If a client has knowledge of a previous network address > and is unable to contact a local DHCP server, the client > may continue to use the previous network address until > the lease for that address expires. > > Before a host with a valid DHCP address configures an IPv4 > LL address it MUST use DHCP to attempt to reacquire or > verify its IP address and network parameters. In the case > where the the DHCP client is unable to contact a local DHCP > server, the behavior of the IPv4 link-local configuration > implementation is not specified. The implementor has a > choice: Either abandon the DHCP lease and configure a > link-local address or retain the previous network address. > > Implementors are faced with a trade-off: 'Robustness to > DHCP Server Unresponsiveness' versus 'Rapid Transition to > Autoconfigured State'. > > If DHCP configuration parameters continue to be used > despite the DHCP server's lack of response, the client > will be more robust to transient DHCP server inavailability. > The disadvantage is that a mobile host removed from the > context in which it received a long-duration lease will not > autoconfigure. This means, for example, that a laptop > computer may continue to use the configuration it received > 'at work' even though the owner is currently 'at home.' > > If autoconfiguration occurs as soon as it has been determined > that the DHCP client is unable to contact a local DHCP server, > the host will respond to 'waking up' in a new network > environment. This will allow the host to communicate with > other hosts which implement this specification on the link > as soon as possible. The disadvantage of this strategy is > that it will encourage unneeded and disruptive interface > configuration changes in the case where a DHCP server is > unresponsive for a short period of time. > > Retaining the configuration supplied by DHCP emphasizes > stability of service for hosts on centrally configured > networks. This is the most prevalent networking context > today. Users are easily annoyed if their hosts become > reconfigured and unusable for several minutes at a time, > which is the likely outcome if a spurious configured to > link-local transition is undertaken. Obtaining > autoconfiguration parameters as quickly as possible > (according to the protocol timers defined by RFC 2131 and > this specification) benefits the mobile user whose host > finds itself in different networking contexts and wishes > to gain access to their resources immediately. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 8 17:34:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10331; Wed, 8 Oct 2003 17:34:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7LwY-0003el-Gd; Wed, 08 Oct 2003 17:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Lvt-0003eM-Fh for dhcwg@optimus.ietf.org; Wed, 08 Oct 2003 17:33:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10292 for ; Wed, 8 Oct 2003 17:33:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Lvq-0004lR-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 17:33:18 -0400 Received: from smtp013.mail.yahoo.com ([216.136.173.57]) by ietf-mx with smtp (Exim 4.12) id 1A7Lvp-0004lO-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 17:33:17 -0400 Received: from adsl-67-115-132-186.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@67.115.132.186 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 8 Oct 2003 19:22:24 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Subject: Re: [dhcwg] Re: Extending the DHCPv4 option codes Date: Wed, 8 Oct 2003 12:20:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I wasn't part of the initial discussion that reserved option codes 128-254 for site-specific uses, but can easily imagine that it seemed at the time as if a network administrator might indeed have enough control over which DHCP clients were deployed to specify a client that did request organization or site-specific options. I know of very few DHCP clients in wide use (other than the ISC client) that will easily support client requests for site-specific options, so it may be the right moment now to eliminate the designation of this range as reserved -- besides which, PXE, Cisco IP phones, and a few "thin clients" use options from this range already, hardly site-specific. My opinion about the likely remaining lifetime of IPv4 is that I don't believe it will be likely to go away until ubiquitous implementations are available for network devices, and equipment vendors whole-heartedly embrace it. I suspect that what we're more likely to have is IPv6 between islands of IPv4. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 8 18:10:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09776; Wed, 8 Oct 2003 17:21:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Ljy-0002lW-9W; Wed, 08 Oct 2003 17:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A71T6-0006bC-Pe for dhcwg@optimus.ietf.org; Tue, 07 Oct 2003 19:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27999 for ; Tue, 7 Oct 2003 19:42:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A71T4-0005M0-00 for dhcwg@ietf.org; Tue, 07 Oct 2003 19:42:14 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1A71T4-0005Le-00 for dhcwg@ietf.org; Tue, 07 Oct 2003 19:42:14 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h97N7LI22082 for ; Tue, 7 Oct 2003 16:07:22 -0700 Date: Tue, 7 Oct 2003 16:07:21 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] DNA Issue 7: ARP contents Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Issue 7: ARP contents Submitter: Dieter Siegmund Submitter email address: dieter@apple.com Date first submitted: October 2, 2003 Reference: Document: DNAv4-02 Comment type: T Priority: S Section: 2.2 Rationale/Explanation of issue: I have a comment regarding the spec: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt In section "2.2. Packet Format", it suggests sending an ARP probe (sender IP 0.0.0.0) to check the router MAC address against a known value. One problem I've run into in the past (and still do today) is that some routers refuse to answer ARP probe's. In particular, the Cisco router here at Apple, and a FlowPoint DSL router I have at home only respond to an ARP Request with a "legitimate" sender IP address. Have you also encountered this? Regards, Dieter Siegmund Core OS Networking _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 8 20:56:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17439; Wed, 8 Oct 2003 20:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7P62-0005GP-0N; Wed, 08 Oct 2003 20:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7P5C-0005EQ-S1 for dhcwg@optimus.ietf.org; Wed, 08 Oct 2003 20:55:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17390 for ; Wed, 8 Oct 2003 20:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7P5A-0006oe-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 20:55:08 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1A7P59-0006oY-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 20:55:07 -0400 Received: from localhost ([130.194.13.85]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L1MD9HLVKG8WXW5R@vaxh.its.monash.edu.au> for dhcwg@ietf.org; Thu, 9 Oct 2003 10:04:00 +1000 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id C1ACA158002; Thu, 09 Oct 2003 10:03:59 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by broink.its.monash.edu.au (Postfix) with ESMTP id A146C120007; Thu, 09 Oct 2003 10:03:59 +1000 (EST) Date: Thu, 09 Oct 2003 10:03:59 +1000 From: Greg Daley Subject: Re: [dhcwg] DNA Issue 7: ARP contents To: Bernard Aboba Cc: dhcwg@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F84A5EF.8070108@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Bernard, For issue seven, I think that what's trying to be achieved with the ARP probe is reachability confirmation. We don't expect a response in the case of the IP subnet changing (or the router's IP address going away). In the case where we have a globally unique address, there is no harm (because we own and have checked the address) in sending the arp packet with an (ar$spa) value which matches the currently configured address. If we are on the same subnet, then this will be responded to appropriately. If we are not on the same subnet, we won't get a response anyway. Of course, in IPv4, the big issue is the potential presence of rfc 1918 addresses on the link (which may readily be determined in the case that the router, or the currently configured IP address belongs to a non-unique class of addresses). In these cases, it may be worth setting the (ar$spa) to 0.0.0.0, but as mentioned by Dieter, this may mean that function is impaired on some subnets, where routers do not support unspecified sources. I don't have a solution to this case, except to fall back to DHC. It may also be reasonable to suggest that if reachability checks to the current router have failed before, one shouldn't do them and instead rely on DHC, until subnet change occurs. Please tell me if I'm just being thick headed about this. Greg Daley Bernard Aboba wrote: > Issue 7: ARP contents > Submitter: Dieter Siegmund > Submitter email address: dieter@apple.com > Date first submitted: October 2, 2003 > Reference: > Document: DNAv4-02 > Comment type: T > Priority: S > Section: 2.2 > Rationale/Explanation of issue: > > I have a comment regarding the spec: > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt > > In section "2.2. Packet Format", it suggests sending an ARP probe > (sender IP 0.0.0.0) to check the router MAC address against a known value. > > One problem I've run into in the past (and still do today) is that some > routers refuse to answer ARP probe's. In particular, the Cisco router here > at Apple, and a FlowPoint DSL router I have at home only respond to an ARP > Request with a "legitimate" sender IP address. > > Have you also encountered this? > > Regards, > Dieter Siegmund > Core OS Networking > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 9 03:58:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10429; Thu, 9 Oct 2003 03:58:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7VgP-0001lo-9Z; Thu, 09 Oct 2003 03:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vfy-0001l9-T8 for dhcwg@optimus.ietf.org; Thu, 09 Oct 2003 03:57:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10397 for ; Thu, 9 Oct 2003 03:57:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vfw-000330-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 03:57:32 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vfv-00032w-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 03:57:31 -0400 Received: from localhost ([130.194.13.83]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L1MME5EV428ZLGCQ@vaxh.its.monash.edu.au> for dhcwg@ietf.org; Thu, 9 Oct 2003 14:25:04 +1000 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id AB8E623C004; Thu, 09 Oct 2003 14:25:03 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id 9532C16400B; Thu, 09 Oct 2003 14:25:03 +1000 (EST) Date: Thu, 09 Oct 2003 14:25:03 +1000 From: Greg Daley Subject: Re: [dhcwg] DNA Issue 7: ARP contents To: Bernard Aboba Cc: dhcwg@ietf.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F84E31F.7060004@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3F84A5EF.8070108@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Bernard, Bernard Aboba wrote: >>We don't expect a response in the case of the IP subnet >>changing (or the router's IP address going away). >> >>In the case where we have a globally unique address, >>there is no harm (because we own and have checked >>the address) in sending the arp packet with >>an (ar$spa) value which matches the currently >>configured address. If we are on the same subnet, >>then this will be responded to appropriately. >>If we are not on the same subnet, we won't get a >>response anyway. > > > That was more or less my reaction as well. Using the valid DHCP lease > address appears to do no harm in this case. I hope I wasn't just saying what you'd already fixed (I hadn't seen the issues list since you posted the issue). > >>Of course, in IPv4, the big issue is the potential >>presence of rfc 1918 addresses on the link >>(which may readily be determined in the case >>that the router, or the currently configured IP address >>belongs to a non-unique class of addresses). >> >>In these cases, it may be worth setting the (ar$spa) >>to 0.0.0.0, but as mentioned by Dieter, this may mean that >>function is impaired on some subnets, where routers >>do not support unspecified sources. > > > For an RFC 1918 address the potential downside is that the host has moved > to an alternative point of attachment using the same RFC 1918 prefix. > Sending an ARP probe including the allocated address could result in an > address conflict unless the host could confirm that it was in fact on the > expected network. So I think that using 0.0.0.0 for this case is > necessary, but it may not work. If not, then the host will need to send a > DHCPREQUEST. I think that's what I was trying to express, but your mechanism is clearly more well explained (looks like text for a draft...) >>I don't have a solution to this case, except to fall >>back to DHC. It may also be reasonable to suggest that >>if reachability checks to the current router have failed >>before, one shouldn't do them and instead rely on DHC, >>until subnet change occurs. > > > In practice the reachability checks are done because it is possible that > the point of attachment may have changed. In practice one would probably > only want to deprecate the particular RFC 1918 prefix that has failed and > perhaps only for a short period of time. On the whole I'm not sure that > the added complexity is worth it. Indeed. It would only be while that particular IP Router was detected as faulty. Thus it would only have to fail once to be put into a "don't check" state. Once the subnet or router changed, this state would be irrelevant. > >>Please tell me if I'm just being thick headed about this. > > > I think you're more or less on target. Good. When I first read your issue post, I thought we had a show stopper. Greg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 9 09:11:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18394; Thu, 9 Oct 2003 09:11:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7aZJ-0002HQ-Hg; Thu, 09 Oct 2003 09:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7aYg-0002GX-1x for dhcwg@optimus.ietf.org; Thu, 09 Oct 2003 09:10:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18344 for ; Thu, 9 Oct 2003 09:10:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7aYe-00065J-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 09:10:20 -0400 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1A7aYe-00065G-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 09:10:20 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h99DA7Yp050631; Thu, 9 Oct 2003 09:10:16 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-interop-01.txt Date: Thu, 9 Oct 2003 09:10:17 -0400 Message-ID: <000001c38e66$b28e3b60$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <4.3.2.7.2.20031006130314.058220b8@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ralph: If published as a RFC, I think it has the potential to create more = confusion as it references a draft (-28) which would not exist. So, I think the document, as written, would create more harm than good. It is too bad that the discussion and resolution sections will be lost = since these do provide useful information that was lost when the changes were incorporated into the DHCPv6 RFC. So, my recommendation is to let it expire (perhaps it is available in = some sort of expired I-D archive?). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ralph Droms Sent: Monday, October 06, 2003 1:05 PM To: dhcwg@ietf.org Subject: [dhcwg] draft-ietf-dhc-dhcpv6-interop-01.txt The issues documented in draft-ietf-dhc-dhcpv6-interop-01.txt, "Results = from Interoperability Tests of DHCPv6 Implementations", were all addressed in = the DHCPv6 spec prior to its publication as RFC3315. draft-ietf-dhc-dhcpv6-interop-01.txt is about to expire; does anyone = have an argument for publishing it as Informational or otherwise archiving it? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 9 13:43:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01037; Thu, 9 Oct 2003 13:43:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7eoX-00039k-Ho; Thu, 09 Oct 2003 13:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7eoL-00039Z-Gf for dhcwg@optimus.ietf.org; Thu, 09 Oct 2003 13:42:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01007 for ; Thu, 9 Oct 2003 13:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7eoJ-0001sf-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 13:42:47 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7eoI-0001sa-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 13:42:46 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 09 Oct 2003 10:50:31 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h99HgE5g015302; Thu, 9 Oct 2003 13:42:14 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-16.cisco.com [10.82.224.16]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADA30816; Thu, 9 Oct 2003 13:42:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20031009133414.0477a1a8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Oct 2003 13:40:41 -0400 To: "Bernie Volz" From: Ralph Droms Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-interop-01.txt Cc: dhcwg@ietf.org In-Reply-To: <000401c38e88$f1a16ad0$6701a8c0@BVolz> References: <4.3.2.7.2.20031009104522.00b5bac0@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , So, if anyone is interested in capturing the discussions and resolutions in draft-ietf-dhc-dhcpv6-interop-01.txt, I would be willing to do a little editing and publish a revised version as an Informational RFC. If I don't hear from anyone else, I'll just let the draft expire... - Ralph At 01:15 PM 10/9/2003 -0400, you wrote: >Ralph: > >That certainly is an option and a good way to correct the document, given >the DHCPv6 specification RFC. However, it also a bit of work and may not be >worth the effort? I do think that it is a good alternative - you can >probably cut down the size of the document as well since several of the >minor items can be removed. > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, October 09, 2003 10:49 AM >To: Bernie Volz >Subject: RE: [dhcwg] draft-ietf-dhc-dhcpv6-interop-01.txt > >Bernie - suppose I edit the doc before publication, to make the document >self-contained and remove most references to the -28 draft rev of the spec? >Would the discussion and resolution be worth archiving as an Informational >RFC? > >The IETF doesn't maintain an I-D archive. There are archives in which >expired I-Ds appear, but I don't think we want to rely on those archives for >long-term access to draft-ietf-dhc-dhcpv6-interop-01.txt > >- Ralph > >At 09:10 AM 10/9/2003 -0400, you wrote: > >Ralph: > > > >If published as a RFC, I think it has the potential to create more >confusion > >as it references a draft (-28) which would not exist. So, I think the > >document, as written, would create more harm than good. > > > >It is too bad that the discussion and resolution sections will be lost >since > >these do provide useful information that was lost when the changes were > >incorporated into the DHCPv6 RFC. > > > >So, my recommendation is to let it expire (perhaps it is available in some > >sort of expired I-D archive?). > > > >- Bernie > > > >-----Original Message----- > >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph > >Droms > >Sent: Monday, October 06, 2003 1:05 PM > >To: dhcwg@ietf.org > >Subject: [dhcwg] draft-ietf-dhc-dhcpv6-interop-01.txt > > > >The issues documented in draft-ietf-dhc-dhcpv6-interop-01.txt, "Results >from > >Interoperability Tests of DHCPv6 Implementations", were all addressed in >the > >DHCPv6 spec prior to its publication as RFC3315. > >draft-ietf-dhc-dhcpv6-interop-01.txt is about to expire; does anyone have >an > >argument for publishing it as Informational or otherwise archiving it? > > > >- Ralph > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 9 15:36:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06564; Thu, 9 Oct 2003 15:36:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gZu-0002II-6p; Thu, 09 Oct 2003 15:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gZn-0002Ho-Qe for dhcwg@optimus.ietf.org; Thu, 09 Oct 2003 15:35:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06453; Thu, 9 Oct 2003 15:35:47 -0400 (EDT) Message-Id: <200310091935.PAA06453@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 09 Oct 2003 15:35:47 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-03.txt Pages : 13 Date : 2003-10-9 The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This specification synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link-Local addresses, in order to optimize detection of network attachment by mobile hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dna-ipv4-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-9142245.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-9142245.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 9 15:46:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07112; Thu, 9 Oct 2003 15:46:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gja-0003JB-5d; Thu, 09 Oct 2003 15:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gjB-0003IP-Af for dhcwg@optimus.ietf.org; Thu, 09 Oct 2003 15:45:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07048 for ; Thu, 9 Oct 2003 15:45:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7gj9-0003Q8-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 15:45:35 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A7gj9-0003Q5-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 15:45:35 -0400 Received: from fugue.com (twc161.vtc.net [206.169.46.161]) by toccata.fugue.com (Postfix) with ESMTP id 3ACBA1B20E0; Thu, 9 Oct 2003 14:43:55 -0500 (CDT) Date: Tue, 7 Oct 2003 20:12:19 -0500 Content-Type: text/plain; charset=US-ASCII; format=flowed Resent-Date: Thu, 9 Oct 2003 14:45:18 -0500 Content-Transfer-Encoding: 7bit Resent-Message-Id: <76856506-F92C-11D7-9773-000A95D9C74C@fugue.com> Resent-To: dhcwg@ietf.org, zeroconf@merit.edu Mime-Version: 1.0 (Apple Message framework v552) Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP From: Ted Lemon To: Mika Liljeberg Message-Id: <1C5077A8-FA91-11D7-97EE-000A95D9C74C@fugue.com> Resent-From: Ted Lemon X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Lest my silence be construed as disagreement, I would like to register my agreement with Mika on the points he has just made. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 9 16:41:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10086; Thu, 9 Oct 2003 16:41:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ham-0006Ok-ND; Thu, 09 Oct 2003 16:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7haA-0006O7-CS for dhcwg@optimus.ietf.org; Thu, 09 Oct 2003 16:40:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10065 for ; Thu, 9 Oct 2003 16:40:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7ha8-0004Gz-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 16:40:20 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A7ha7-0004Gv-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 16:40:19 -0400 Received: from fugue.com (twc161.vtc.net [206.169.46.161]) by toccata.fugue.com (Postfix) with ESMTP id 4F5181B2001; Thu, 9 Oct 2003 15:38:38 -0500 (CDT) Date: Thu, 9 Oct 2003 15:40:12 -0500 Subject: Re: [dhcwg] Re: WG consensus action: ACCEPT LL34 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: zeroconf@ietf.org, dhcwg@ietf.org To: Bernard Aboba From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit That's basically right, but remember that there are cases where bad timing can result in a network link that is in fact correctly configured looking like it's got a stale configuration - if you are at the edge of an 802.11 network, you will fade in and out, and if you are moving around in an 802.11 network that has multiple access points, as you wander from one coverage area to the next you may experience outages that would trigger a configuration re-check that would fail, even though the same check thirty seconds later would succeed. In this situation, we do not want to toss the IP address on the interface, because it means that every active TCP connection is going to be shot in the head. On Tuesday, October 7, 2003, at 06:16 PM, Bernard Aboba wrote: > If a host has an IP address with a valid lifetime, DHCP (or RS/RA for > that > matter) is not required to confirm it. All that is necessary is a > reachability test to the default gateway, confirming that the host is > on > the network in which the address is valid. > > The text below makes it seem like it is necessary for the host to send > a > DHCPREQUEST whenever it wakes up. This is not the case. > > I'd rather see text relating to transition routable to IPv4LL > addresses, like the text relating to transition from LLv4 > to routable addresses, handled outside of the IPv4LL specification, > such as in the DNAv4 specification. > > Erik Guttman spoke thusly: > > Before a host with a valid DHCP address configures an IPv4 > LL address it MUST use DHCP to attempt to reacquire or > verify its IP address and network parameters. In the case > where the the DHCP client is unable to contact a local DHCP > server, the behavior of the IPv4 link-local configuration > implementation is not specified. The implementor has a > choice: Either abandon the DHCP lease and configure a > link-local address or retain the previous network address. > > Implementors are faced with a trade-off: 'Robustness to > DHCP Server Unresponsiveness' versus 'Rapid Transition to > Autoconfigured State'. > > If DHCP configuration parameters continue to be used > despite the DHCP server's lack of response, the client > will be more robust to transient DHCP server inavailability. > The disadvantage is that a mobile host removed from the > context in which it received a long-duration lease will not > autoconfigure. This means, for example, that a laptop > computer may continue to use the configuration it received > 'at work' even though the owner is currently 'at home.' > > If autoconfiguration occurs as soon as it has been determined > that the DHCP client is unable to contact a local DHCP server, > the host will respond to 'waking up' in a new network > environment. This will allow the host to communicate with > other hosts which implement this specification on the link > as soon as possible. The disadvantage of this strategy is > that it will encourage unneeded and disruptive interface > configuration changes in the case where a DHCP server is > unresponsive for a short period of time. > > Retaining the configuration supplied by DHCP emphasizes > stability of service for hosts on centrally configured > networks. This is the most prevalent networking context > today. Users are easily annoyed if their hosts become > reconfigured and unusable for several minutes at a time, > which is the likely outcome if a spurious configured to > link-local transition is undertaken. Obtaining > autoconfiguration parameters as quickly as possible > (according to the protocol timers defined by RFC 2131 and > this specification) benefits the mobile user whose host > finds itself in different networking contexts and wishes > to gain access to their resources immediately. > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 9 18:09:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13592; Thu, 9 Oct 2003 18:09:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ixx-0003U8-S8; Thu, 09 Oct 2003 18:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7diK-0006Op-QY for dhcwg@optimus.ietf.org; Thu, 09 Oct 2003 12:32:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27135 for ; Thu, 9 Oct 2003 12:32:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7diJ-0000l7-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 12:32:31 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1A7diI-0000l2-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 12:32:30 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h99FvPi02741; Thu, 9 Oct 2003 08:57:26 -0700 Date: Thu, 9 Oct 2003 08:57:25 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu cc: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] LL34: Comments on the state diagram and proposed text Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Some comments on the state diagram: "INIT waits before entering SELECT state." How long? "A special case of SELECT is where the host has woken up and previously had a link-local address configured. In this case, the previously configured is selected. See Section 2.2." The IPv4LL address can be claimed while the host is asleep, and so it is necessary to rerun claim and defend rather than just configuring the address, as specified in Section 2.2. Also, it is possible that the DHCP server is now available so that an argument can be made that if the host was previously assigned routable IP addresses that are still valid, that it should test whether it is connected to any of those points of attachment before assigning an IPv4 LL address. In fact, I think the proposed text suggests this as well. My recommendation is to delete the above paragraph. "ANNOUNCE Send ARP announcements the enter CONFIGURED state." Think you mean "then enter" Here are some comments on the proposed text for 2.12: 2.12 Transition from Routable Address to Link-Local A host may 'wake up' (see Section 2.2) with a valid DHCP lease. [BA] It may also change its point of attachment. So would change to: "On changing its point of attachment, or awaking from sleep mode, a host with a still valid routable IP address (e.g. DHCP lease not expired) will typically prefer to use this address if it can confirm attachment to the network on which the address was assigned." According to RFC 2131, Section 3.7: A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network, as the local network configuration may change without the client's or user's knowledge. If a client has knowledge of a previous network address and is unable to contact a local DHCP server, the client may continue to use the previous network address until the lease for that address expires. Before a host with a valid DHCP address configures an IPv4 LL address it MUST use DHCP to attempt to reacquire or verify its IP address and network parameters. In the case where the the DHCP client is unable to contact a local DHCP server, the behavior of the IPv4 link-local configuration implementation is not specified. The implementor has a choice: Either abandon the DHCP lease and configure a link-local address or retain the previous network address. [BA] The MUST is inappropriate because there is no need to use DHCP to confirm attachment to a network on which a still valid IP address was assigned. A simple reachability test will suffice. Suggest changing to: "Before a host with a valid routable IP address configures a Link-Local IPv4 address it SHOULD first attempt to confirm the usability of the routable address, using mechanisms such as those specified in [DNAv4]. If the usability of an existing valid routable IPv4 address cannot be confirmed, then the host MUST attempt to acquire an IPv4 address, using a mechanism such as DHCPv4. In the case where the DHCPv4 client is unable to contact a DHCPv4 server, the implementor has a choice: either abandon the DHCPv4 lease and configure an IPv4 Link-Local address or configure the address previously assigned by DHCPv4 " Implementors are faced with a trade-off: 'Robustness to DHCP Server Unresponsiveness' versus 'Rapid Transition to Autoconfigured State'. [BA] In fact, the DNA-specified procedure does not require this tradeoff; if reachability to the default gateway can be confirmed then the host can reuse a valid routable address even if the DHCP server does not respond. I suggest that the above paragraph be deleted. If DHCP configuration parameters continue to be used despite the DHCP server's lack of response, the client will be more robust to transient DHCP server inavailability. The disadvantage is that a mobile host removed from the context in which it received a long-duration lease will not autoconfigure. This means, for example, that a laptop computer may continue to use the configuration it received 'at work' even though the owner is currently 'at home.' If autoconfiguration occurs as soon as it has been determined that the DHCP client is unable to contact a local DHCP server, the host will respond to 'waking up' in a new network environment. This will allow the host to communicate with other hosts which implement this specification on the link as soon as possible. The disadvantage of this strategy is that it will encourage unneeded and disruptive interface configuration changes in the case where a DHCP server is unresponsive for a short period of time. [BA] Again, these paragraphs seem to imply that the issue is DHCP server reachability; the issue is the ability of the host to confirm its point of attachment. If the host is unable to confirm reachability of the default gateway then configuring a routable address will not help much since the host will be unable to reach hosts off-link anyway. My advice would be to delete the above paragraphs. Retaining the configuration supplied by DHCP emphasizes stability of service for hosts on centrally configured networks. This is the most prevalent networking context today. Users are easily annoyed if their hosts become reconfigured and unusable for several minutes at a time, which is the likely outcome if a spurious configured to link-local transition is undertaken. [BA] I thought we agreed that the 5 minute wait time is a bad idea. The maximum DHCP RTO is 64 seconds. So I'd delete "for several minutes at a time," Obtaining autoconfiguration parameters as quickly as possible (according to the protocol timers defined by RFC 2131 and this specification) benefits the mobile user whose host finds itself in different networking contexts and wishes to gain access to their resources immediately. [BA] This paragraph is ok. > > I am concerned if we simply say 'refer to DNAv4' we will > make DNAv4 a normative reference. Perhaps this is the > right thing to do, but it sure won't grease the rails for > IPv4LL to come out. Every month this spec is delayed there > are more implementations that Stuart is coaching toward > poor behavior. > > Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 9 18:09:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13591; Thu, 9 Oct 2003 18:09:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ixw-0003Tk-IA; Thu, 09 Oct 2003 18:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7QiZ-00016I-NB for dhcwg@optimus.ietf.org; Wed, 08 Oct 2003 22:39:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19749 for ; Wed, 8 Oct 2003 22:39:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7QiW-0007hC-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 22:39:52 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1A7QiV-0007h9-00 for dhcwg@ietf.org; Wed, 08 Oct 2003 22:39:51 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9924oF18934; Wed, 8 Oct 2003 19:04:50 -0700 Date: Wed, 8 Oct 2003 19:04:50 -0700 (PDT) From: Bernard Aboba To: Greg Daley cc: dhcwg@ietf.org Subject: Re: [dhcwg] DNA Issue 7: ARP contents In-Reply-To: <3F84A5EF.8070108@eng.monash.edu.au> Message-ID: References: <3F84A5EF.8070108@eng.monash.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > We don't expect a response in the case of the IP subnet > changing (or the router's IP address going away). > > In the case where we have a globally unique address, > there is no harm (because we own and have checked > the address) in sending the arp packet with > an (ar$spa) value which matches the currently > configured address. If we are on the same subnet, > then this will be responded to appropriately. > If we are not on the same subnet, we won't get a > response anyway. That was more or less my reaction as well. Using the valid DHCP lease address appears to do no harm in this case. > Of course, in IPv4, the big issue is the potential > presence of rfc 1918 addresses on the link > (which may readily be determined in the case > that the router, or the currently configured IP address > belongs to a non-unique class of addresses). > > In these cases, it may be worth setting the (ar$spa) > to 0.0.0.0, but as mentioned by Dieter, this may mean that > function is impaired on some subnets, where routers > do not support unspecified sources. For an RFC 1918 address the potential downside is that the host has moved to an alternative point of attachment using the same RFC 1918 prefix. Sending an ARP probe including the allocated address could result in an address conflict unless the host could confirm that it was in fact on the expected network. So I think that using 0.0.0.0 for this case is necessary, but it may not work. If not, then the host will need to send a DHCPREQUEST. > I don't have a solution to this case, except to fall > back to DHC. It may also be reasonable to suggest that > if reachability checks to the current router have failed > before, one shouldn't do them and instead rely on DHC, > until subnet change occurs. In practice the reachability checks are done because it is possible that the point of attachment may have changed. In practice one would probably only want to deprecate the particular RFC 1918 prefix that has failed and perhaps only for a short period of time. On the whole I'm not sure that the added complexity is worth it. > Please tell me if I'm just being thick headed about this. I think you're more or less on target. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 9 18:55:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13590; Thu, 9 Oct 2003 18:09:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ixw-0003Ts-VS; Thu, 09 Oct 2003 18:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7YX6-0004Rt-9X for dhcwg@optimus.ietf.org; Thu, 09 Oct 2003 07:00:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15420 for ; Thu, 9 Oct 2003 07:00:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7YX1-000503-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 07:00:31 -0400 Received: from web11508.mail.yahoo.com ([216.136.172.40]) by ietf-mx with smtp (Exim 4.12) id 1A7YX1-000500-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 07:00:31 -0400 Message-ID: <20031009110032.11356.qmail@web11508.mail.yahoo.com> Received: from [152.105.30.219] by web11508.mail.yahoo.com via HTTP; Thu, 09 Oct 2003 12:00:32 BST Date: Thu, 9 Oct 2003 12:00:32 +0100 (BST) From: =?iso-8859-1?q?Mike=20Graham?= To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [dhcwg] DHCP Server advice Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, I am after some advice regarding using dhcp server. In my current work place (predominantly Netware 5.1, with approx. 50 Netware servers), we are looking to implement a new centralised dhcp service to replace the existing Netware dhcp servers, i.e.moving away from Netware dhcp. We have considered a Microsoft based solution (Server 2003 dhcp), be are not convinced it will provide the flexibility or feature set of the existing Netware solution (imanager and edirectory). We are now looking for a generic 'blackbox' dhcp solution, one with a java interface that could provide the new dhcp service. Extra info: the site currently has around 4000 user machines on-site. The network is submitted. If anyone has any information regarding past experience of any similar dchp migration, or any products to recommend please mail me back on this email address. Your advice would be very gratefully received. Thanks Mike ________________________________________________________________________ Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 9 18:55:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13589; Thu, 9 Oct 2003 18:09:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7ixx-0003U0-Bo; Thu, 09 Oct 2003 18:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7cSX-0000tx-QM for dhcwg@optimus.ietf.org; Thu, 09 Oct 2003 11:12:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23794 for ; Thu, 9 Oct 2003 11:12:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7cSW-0007Q5-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 11:12:08 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1A7cSW-0007Po-00 for dhcwg@ietf.org; Thu, 09 Oct 2003 11:12:08 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h99Eb5e30474; Thu, 9 Oct 2003 07:37:05 -0700 Date: Thu, 9 Oct 2003 07:37:05 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org cc: greg.daley@eng.monash.edu.au In-Reply-To: <3F84E31F.7060004@eng.monash.edu.au> Message-ID: References: <3F84A5EF.8070108@eng.monash.edu.au> <3F84E31F.7060004@eng.monash.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Proposed Resolution to DNA Issue 7: ARP contents Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The text of DNA Issue 7 is enclosed below. The proposed fix is as follows: In Section 2.2, change: "Since the host has not yet confirmed the subnet on which it is attached, it MUST set the sender protocol address field (ar$spa) to 0.0.0.0. This prevents poisoning of the ARP cache with a (potentially invalid) sender IPv4 address. Since the ARP Response is sent to the sender hardware address, the contents of the sender protocol address field do not affect delivery of the ARP Response. Since existing implementations do not create an ARP cache entry for 0.0.0.0, using this as the sender protocol address is harmless." To: "If the host has a valid globally routable IP address on the most likely point of attachment, then it SHOULD set the sender protocol address field (ar$spa) to that address. It is assumed that the host had previously done duplicate address detection so that an address conflict is unlikely. However if the host has a private address as defined in [RFC1918], then it SHOULD set the protocol address field (ar$spa) to 0.0.0.0. This is to avoid an address conflict in the case where the host has changed its point of attachment from one private network to another. Note that some routers will refuse to answer an ARP Request sent with the protocol address field (ar$spa) set to the unspecified address. In this case the reachability test will fail and the host will need to attempt to obtain an address." ------------------------------------------------------------------ Issue 7: ARP contents Submitter: Dieter Siegmund Submitter email address: dieter@apple.com Date first submitted: October 2, 2003 Reference: Document: DNAv4-02 Comment type: T Priority: S Section: 2.2 Rationale/Explanation of issue: I have a comment regarding the spec: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt In section "2.2. Packet Format", it suggests sending an ARP probe (sender IP 0.0.0.0) to check the router MAC address against a known value. One problem I've run into in the past (and still do today) is that some routers refuse to answer ARP probe's. In particular, the Cisco router here at Apple, and a FlowPoint DSL router I have at home only respond to an ARP Request with a "legitimate" sender IP address. Have you also encountered this? Regards, Dieter Siegmund Core OS Networking _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 10 08:08:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22972; Fri, 10 Oct 2003 08:08:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7w3t-0005u4-24; Fri, 10 Oct 2003 08:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7w3D-0005gQ-FL for dhcwg@optimus.ietf.org; Fri, 10 Oct 2003 08:07:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22873 for ; Fri, 10 Oct 2003 08:07:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7w3C-0001qf-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 08:07:18 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7w3B-0001pa-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 08:07:18 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 10 Oct 2003 05:15:14 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9AC6i01006688 for ; Fri, 10 Oct 2003 08:06:45 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-338.cisco.com [10.82.241.82]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADA86303; Fri, 10 Oct 2003 08:06:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20031010080205.046ac318@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Oct 2003 08:06:40 -0400 To: From: Ralph Droms Subject: RE: [dhcwg] Status of draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt In-Reply-To: <004b01c38c1e$030f0790$38e62a0f@nt23056> References: <4.3.2.7.2.20031006105628.01fafc60@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Vijay - thanks for your response. Seems like we should proceed with IESG review of draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt. Please update the draft with a revised reference to RFC 3315 (the current draft has expired anayway). Is there a volunteer to write an equivalent to RFC 2937, "The Name Service Search Option for DHCP", for DHCPv6? - Ralph At 08:55 PM 10/6/2003 +0530, Vijayabhaskar A K wrote: >Ralph, > >My reply inline.. > >Thanks >Vijay > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > > Behalf Of Ralph Droms > > Sent: Monday, October 06, 2003 8:32 PM > > To: dhcwg@ietf.org > > Subject: [dhcwg] Status of draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt > > > > > > We have two questions on the table concerning > > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt: > > > > * Is there a need for this option yet? Is NIS/NIS+ currently > > IPv6-capable > > or are there plans to extend NIS/NIS+ for IPv6? Is > > NIS/NIS+ used with > > IPv6 today? > > >Yes, Currently NIS/NIS+ is used with IPv6. NIS/NIS+ for IPv6 is >supported in Solaris and some versions of linux. HPUX is working on it. > > > * Is there a need for an DHCPv6 version of RFC 2937, "The Name Service > > Search Option for DHCP"? > >Yes. It is needed. When we have mutliple ways to resolve a name, we need >a precedence list to do it. > > > > > If there is no discussion on these questions, we will put > > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt on hold until > > there is a firm requirement for it. > > > > - Ralph > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 10 08:14:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23419; Fri, 10 Oct 2003 08:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7w9g-0006IN-Ou; Fri, 10 Oct 2003 08:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7w9A-0006HU-Cx for dhcwg@optimus.ietf.org; Fri, 10 Oct 2003 08:13:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23329 for ; Fri, 10 Oct 2003 08:13:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7w99-000221-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 08:13:27 -0400 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx with esmtp (Exim 4.12) id 1A7w98-00021t-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 08:13:26 -0400 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel7.hp.com (Postfix) with ESMTP id AFBC51C023C1; Fri, 10 Oct 2003 08:13:22 -0400 (EDT) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id RAA12898; Fri, 10 Oct 2003 17:42:12 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Status of draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt Date: Fri, 10 Oct 2003 17:43:19 +0530 Organization: HP ISO Message-ID: <003b01c38f27$e4901450$38e62a0f@nt23056> 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.4024 In-Reply-To: <4.3.2.7.2.20031010080205.046ac318@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ralph I will update the draft with DHCPv6 RFC number and send the updated version in one or two weeks. I can work on the DHCPv6 quivalent of RFC 2937 and send it by next week ~ Vijay > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > Behalf Of Ralph Droms > Sent: Friday, October 10, 2003 5:37 PM > To: dhcwg@ietf.org > Subject: RE: [dhcwg] Status of > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt > > > Vijay - thanks for your response. Seems like we should > proceed with IESG review of > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt. Please update > the draft with a revised reference to RFC 3315 (the current > draft has expired anayway). > > Is there a volunteer to write an equivalent to RFC 2937, "The > Name Service Search Option for DHCP", for DHCPv6? > > - Ralph > > > At 08:55 PM 10/6/2003 +0530, Vijayabhaskar A K wrote: > >Ralph, > > > >My reply inline.. > > > >Thanks > >Vijay > > > > > -----Original Message----- > > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] > On Behalf > > > Of Ralph Droms > > > Sent: Monday, October 06, 2003 8:32 PM > > > To: dhcwg@ietf.org > > > Subject: [dhcwg] Status of > > > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt > > > > > > > > > We have two questions on the table concerning > > > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt: > > > > > > * Is there a need for this option yet? Is NIS/NIS+ currently > > > IPv6-capable > > > or are there plans to extend NIS/NIS+ for IPv6? Is > NIS/NIS+ used > > > with > > > IPv6 today? > > > > >Yes, Currently NIS/NIS+ is used with IPv6. NIS/NIS+ for IPv6 is > >supported in Solaris and some versions of linux. HPUX is > working on it. > > > > > * Is there a need for an DHCPv6 version of RFC 2937, "The > Name Service > > > Search Option for DHCP"? > > > >Yes. It is needed. When we have mutliple ways to resolve a name, we > >need a precedence list to do it. > > > > > > > > If there is no discussion on these questions, we will put > > > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt on hold until > there is a > > > firm requirement for it. > > > > > > - Ralph > > > > > > > > > _______________________________________________ > > > dhcwg mailing list > > > dhcwg@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 10 08:18:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23666; Fri, 10 Oct 2003 08:18:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wDZ-0006bH-Gv; Fri, 10 Oct 2003 08:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7wDJ-0006aE-Fl for dhcwg@optimus.ietf.org; Fri, 10 Oct 2003 08:17:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23596 for ; Fri, 10 Oct 2003 08:17:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7wDI-00027W-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 08:17:44 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A7wDH-00026n-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 08:17:43 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9ACH95g020377; Fri, 10 Oct 2003 08:17:10 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-338.cisco.com [10.82.241.82]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADA86846; Fri, 10 Oct 2003 08:17:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20031010081500.046c4738@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Oct 2003 08:15:14 -0400 To: From: Ralph Droms Subject: RE: [dhcwg] Status of draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt Cc: In-Reply-To: <003b01c38f27$e4901450$38e62a0f@nt23056> References: <4.3.2.7.2.20031010080205.046ac318@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Great ... thanks, Vijay. - Ralph At 05:43 PM 10/10/2003 +0530, Vijayabhaskar A K wrote: >Ralph > >I will update the draft with DHCPv6 RFC number and send the updated >version in one or two weeks. I can work on the DHCPv6 quivalent of RFC >2937 and send it by next week > >~ Vijay > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On > > Behalf Of Ralph Droms > > Sent: Friday, October 10, 2003 5:37 PM > > To: dhcwg@ietf.org > > Subject: RE: [dhcwg] Status of > > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt > > > > > > Vijay - thanks for your response. Seems like we should > > proceed with IESG review of > > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt. Please update > > the draft with a revised reference to RFC 3315 (the current > > draft has expired anayway). > > > > Is there a volunteer to write an equivalent to RFC 2937, "The > > Name Service Search Option for DHCP", for DHCPv6? > > > > - Ralph > > > > > > At 08:55 PM 10/6/2003 +0530, Vijayabhaskar A K wrote: > > >Ralph, > > > > > >My reply inline.. > > > > > >Thanks > > >Vijay > > > > > > > -----Original Message----- > > > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] > > On Behalf > > > > Of Ralph Droms > > > > Sent: Monday, October 06, 2003 8:32 PM > > > > To: dhcwg@ietf.org > > > > Subject: [dhcwg] Status of > > > > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt > > > > > > > > > > > > We have two questions on the table concerning > > > > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt: > > > > > > > > * Is there a need for this option yet? Is NIS/NIS+ currently > > > > IPv6-capable > > > > or are there plans to extend NIS/NIS+ for IPv6? Is > > NIS/NIS+ used > > > > with > > > > IPv6 today? > > > > > > >Yes, Currently NIS/NIS+ is used with IPv6. NIS/NIS+ for IPv6 is > > >supported in Solaris and some versions of linux. HPUX is > > working on it. > > > > > > > * Is there a need for an DHCPv6 version of RFC 2937, "The > > Name Service > > > > Search Option for DHCP"? > > > > > >Yes. It is needed. When we have mutliple ways to resolve a name, we > > >need a precedence list to do it. > > > > > > > > > > > If there is no discussion on these questions, we will put > > > > draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt on hold until > > there is a > > > > firm requirement for it. > > > > > > > > - Ralph > > > > > > > > > > > > _______________________________________________ > > > > dhcwg mailing list > > > > dhcwg@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > > > > > > > >_______________________________________________ > > >dhcwg mailing list > > >dhcwg@ietf.org > > >https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 10 12:29:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05917; Fri, 10 Oct 2003 12:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A808T-0007ZB-Sy; Fri, 10 Oct 2003 12:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A807h-0007VF-6V for dhcwg@optimus.ietf.org; Fri, 10 Oct 2003 12:28:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05868 for ; Fri, 10 Oct 2003 12:28:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A807f-0005sQ-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 12:28:11 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A807e-0005s2-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 12:28:10 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9AGRYXg008333 for ; Fri, 10 Oct 2003 09:27:34 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-338.cisco.com [10.82.241.82]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADB09462; Fri, 10 Oct 2003 12:27:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20031010122612.01e89f00@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 Oct 2003 12:27:30 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Agenda and scheduling for dhc WG during IETF 58 (SECOND REQUEST) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Please contact me if you have items you want to get on the meeting agenda. I have a request from Ted Lemon for time to discuss a couple of drafts. The dhc WG meeting is currently scheduled as follows: THURSDAY, November 13, 2003 0900-1130 Morning Sessions INT dhc Dynamic Host Configuration WG OPS grow Global Routing Operations WG SUB tewg Internet Traffic Engineering WG _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 10 13:05:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07641; Fri, 10 Oct 2003 13:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80hK-0001yo-90; Fri, 10 Oct 2003 13:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80eM-0001qF-OF for dhcwg@optimus.ietf.org; Fri, 10 Oct 2003 13:01:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07474 for ; Fri, 10 Oct 2003 13:01:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A80eK-0006HJ-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 13:01:56 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx with esmtp (Exim 4.12) id 1A80eJ-0006H6-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 13:01:55 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9AH1NUN215780; Fri, 10 Oct 2003 13:01:23 -0400 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9AH1MCx226848; Fri, 10 Oct 2003 13:01:22 -0400 Importance: Normal MIME-Version: 1.0 To: Ralph Droms , volz@metrocast.net, rbhibbs@pacbell.net, "'Vipul. Gupta'" , "'Carl Smith'" Cc: dhcwg@ietf.org X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 Message-ID: From: Mimi Zohar Date: Fri, 10 Oct 2003 13:01:19 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.5|September 18, 2003) at 10/10/2003 13:01:23, Serialize complete at 10/10/2003 13:01:23 Content-Type: multipart/alternative; boundary="=_alternative 005D81D885256DBB_=" Subject: [dhcwg] *DRAFT* Minutes from dhc WG meeting at IETF 57 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 005D81D885256DBB_= Content-Type: text/plain; charset="US-ASCII" As IETF is just around the corner, we really need to start/continue a discussion on the draft-gupta-dhcp-auth-02.txt, which btw expired in August. Are there any comments/suggestions, which would prevent this proposal from being pushed forward? If not, could we do so at the next IETF meeting? Mimi Zohar --=_alternative 005D81D885256DBB_= Content-Type: text/html; charset="US-ASCII"
As IETF is just around the corner,  we really need to start/continue a discussion on the draft-gupta-dhcp-auth-02.txt, which btw expired in August.   Are there any comments/suggestions, which would prevent this proposal from being pushed forward?   If not, could we do so at the next IETF meeting?

Mimi Zohar --=_alternative 005D81D885256DBB_=-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 10 13:05:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07639; Fri, 10 Oct 2003 13:05:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80hI-0001yV-Na; Fri, 10 Oct 2003 13:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7x98-0002Kg-Si for dhcwg@optimus.ietf.org; Fri, 10 Oct 2003 09:17:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26917 for ; Fri, 10 Oct 2003 09:17:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7x96-0003Hw-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 09:17:28 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1A7x96-0003Ho-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 09:17:28 -0400 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9ADGuxA026705; Fri, 10 Oct 2003 06:16:56 -0700 (PDT) Received: from sun.com (vpn-129-156-97-84.EMEA.Sun.COM [129.156.97.84]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9ADGriE383461; Fri, 10 Oct 2003 06:16:54 -0700 (PDT) Message-ID: <3F86B118.5040303@sun.com> Date: Fri, 10 Oct 2003 15:16:08 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Bernard Aboba CC: zeroconf@merit.edu, dhcwg@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: LL34: Comments on the state diagram and proposed text Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bernard, Bernard Aboba wrote: > Some comments on the state diagram: The basic questions I have are: o Does the diagram clarify things or make them more difficult to understand? o Is it late in the game to add such a diagram, as it will require quite a bit of work to get it right? > "INIT waits before entering SELECT state." > > How long? This is specified in section 2.2.1: A random time between PROBE_MIN and PROBE_MAX. > "A special case of SELECT is where the host has > woken up and previously had a link-local address > configured. In this case, the previously configured > is selected. See Section 2.2." > > The IPv4LL address can be claimed while the host is asleep, > and so it is necessary to rerun claim and defend > rather than just configuring the address, as specified in > Section 2.2. That is what I said. That's what the SELECT state means. > Also, it is possible that the DHCP server is > now available so that an argument can be made that if the > host was previously assigned routable IP addresses that are still valid, > that it should test whether it is connected to any of those points of > attachment before assigning an IPv4 LL address. In fact, I think > the proposed text suggests this as well. > > My recommendation is to delete the above paragraph. Or - add an ARC from SELECT to EXIT, so that if there is an IPv4 address selected we will go to EXIT. > "ANNOUNCE Send ARP announcements the enter CONFIGURED > state." > > Think you mean "then enter" Yes. > Here are some comments on the proposed text for 2.12: > > 2.12 Transition from Routable Address to Link-Local > > A host may 'wake up' (see Section 2.2) with a valid DHCP > lease. > > [BA] It may also change its point of attachment. So would change to: > "On changing its point of attachment, or awaking from sleep mode, > a host with a still valid routable IP address (e.g. DHCP lease not > expired) will typically prefer to use this address if it can confirm > attachment to the network on which the address was assigned." OK. > According to RFC 2131, Section 3.7: > > A client SHOULD use DHCP to reacquire or verify its > IP address and network parameters whenever the local > network parameters may have changed; e.g., at system > boot time or after a disconnection from the local > network, as the local network configuration may change > without the client's or user's knowledge. > > If a client has knowledge of a previous network address > and is unable to contact a local DHCP server, the client > may continue to use the previous network address until > the lease for that address expires. > > Before a host with a valid DHCP address configures an IPv4 > LL address it MUST use DHCP to attempt to reacquire or > verify its IP address and network parameters. In the case > where the the DHCP client is unable to contact a local DHCP > server, the behavior of the IPv4 link-local configuration > implementation is not specified. The implementor has a > choice: Either abandon the DHCP lease and configure a > link-local address or retain the previous network address. > > [BA] The MUST is inappropriate because there is no need to use DHCP to > confirm attachment to a network on which a still valid IP address was > assigned. A simple reachability test will suffice. Suggest changing to: > > "Before a host with a valid routable IP address configures a > Link-Local IPv4 address it SHOULD first attempt to confirm the usability > of the routable address, using mechanisms such as those specified in > [DNAv4]. If the usability of an existing valid routable IPv4 address cannot be > confirmed, then the host MUST attempt to acquire an IPv4 address, > using a mechanism such as DHCPv4. In the case where the DHCPv4 client is > unable to contact a DHCPv4 server, the implementor has a choice: > either abandon the DHCPv4 lease and configure an IPv4 Link-Local > address or configure the address previously assigned by DHCPv4 " OK. > Implementors are faced with a trade-off: 'Robustness to > DHCP Server Unresponsiveness' versus 'Rapid Transition to > Autoconfigured State'. > > [BA] In fact, the DNA-specified procedure does not require this tradeoff; > if reachability to the default gateway can be confirmed then the host can > reuse a valid routable address even if the DHCP server does not respond. > I suggest that the above paragraph be deleted. > > If DHCP configuration parameters continue to be used > despite the DHCP server's lack of response, the client > will be more robust to transient DHCP server inavailability. > The disadvantage is that a mobile host removed from the > context in which it received a long-duration lease will not > autoconfigure. This means, for example, that a laptop > computer may continue to use the configuration it received > 'at work' even though the owner is currently 'at home.' > > If autoconfiguration occurs as soon as it has been determined > that the DHCP client is unable to contact a local DHCP server, > the host will respond to 'waking up' in a new network > environment. This will allow the host to communicate with > other hosts which implement this specification on the link > as soon as possible. The disadvantage of this strategy is > that it will encourage unneeded and disruptive interface > configuration changes in the case where a DHCP server is > unresponsive for a short period of time. > > [BA] Again, these paragraphs seem to imply that the issue is DHCP server > reachability; the issue is the ability of the host to > confirm its point of attachment. If the host is unable to confirm > reachability of the default gateway then configuring a routable address > will not help much since the host will be unable to reach hosts off-link > anyway. My advice would be to delete the above paragraphs. > > Retaining the configuration supplied by DHCP emphasizes > stability of service for hosts on centrally configured > networks. This is the most prevalent networking context > today. Users are easily annoyed if their hosts become > reconfigured and unusable for several minutes at a time, > which is the likely outcome if a spurious configured to > link-local transition is undertaken. > > [BA] I thought we agreed that the 5 minute wait time is a bad idea. The > maximum DHCP RTO is 64 seconds. So I'd delete "for several minutes at a > time," > > Obtaining > autoconfiguration parameters as quickly as possible > (according to the protocol timers defined by RFC 2131 and > this specification) benefits the mobile user whose host > finds itself in different networking contexts and wishes > to gain access to their resources immediately. > > > [BA] This paragraph is ok. I am OK with these changes. Are others? Thanks, Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 10 13:51:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07640; Fri, 10 Oct 2003 13:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A80hJ-0001ye-E2; Fri, 10 Oct 2003 13:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A803h-0007DX-5e for dhcwg@optimus.ietf.org; Fri, 10 Oct 2003 12:24:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05694 for ; Fri, 10 Oct 2003 12:23:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A803f-0005pb-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 12:24:03 -0400 Received: from mail.flarion.com ([63.103.94.23] helo=ftmail.lab.flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1A803e-0005pI-00 for dhcwg@ietf.org; Fri, 10 Oct 2003 12:24:03 -0400 Received: by ftmail.lab.flarion.com with Internet Mail Service (5.5.2656.59) id <4D6JVN2F>; Fri, 10 Oct 2003 12:23:27 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A02553DCE@ftmail.lab.flarion.com> From: Sevy Jonathan To: dhcwg@ietf.org Date: Fri, 10 Oct 2003 12:23:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] RFC 3203/FORCERENEW implementations? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Does anyone know if the FORCERENEW extension described in RFC 3203 has been implemented in any widely-used systems' DHCP clients (e.g., Windows 2000/XP, MacOS, Linux)? Since the WG home page states that the security measures in RFC 3118 haven't been implemented or deployed, and RFC 3203 mandates the use of these security mechanisms, I'm guessing that FORCERENEW isn't widely used, but I've been unable to find concrete info, particularly in the Windows world. Thanks, \ Jon Jonathan Sevy Flarion Technologies Inc. Bedminster One 135 Route 202/206 South Bedminster, NJ 07921 Phone: (908) 997-2084 Fax: (908) 947-7090 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 11 01:00:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08681; Sat, 11 Oct 2003 01:00:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8BrI-0004Vx-17; Sat, 11 Oct 2003 01:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Bqa-0004Ul-I8 for dhcwg@optimus.ietf.org; Sat, 11 Oct 2003 00:59:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08631 for ; Sat, 11 Oct 2003 00:59:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8BqX-00003A-00 for dhcwg@ietf.org; Sat, 11 Oct 2003 00:59:17 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A8BqW-000037-00 for dhcwg@ietf.org; Sat, 11 Oct 2003 00:59:17 -0400 Received: from fugue.com (m698e36d0.tmodns.net [208.54.142.105]) by toccata.fugue.com (Postfix) with ESMTP id 30A9B1B2B8E; Fri, 10 Oct 2003 23:57:26 -0500 (CDT) Date: Fri, 10 Oct 2003 21:59:17 -0700 Subject: Re: [dhcwg] Re: LL34: Comments on the state diagram and proposed text Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org, zeroconf@merit.edu, Bernard Aboba To: Erik Guttman From: Ted Lemon In-Reply-To: <3F86B118.5040303@sun.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm allergic to diagrams. It's easy to get them wrong, and if they differ, or can be interpreted to differ from the text, which is authoritative? How do we make sure that the implementor notices that they conflict, given that we didn't? So I think it's a good idea in theory, and a bad idea in practice. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 11 01:00:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08680; Sat, 11 Oct 2003 01:00:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8BrH-0004Vn-IC; Sat, 11 Oct 2003 01:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8BqW-0004Ug-Bz for dhcwg@optimus.ietf.org; Sat, 11 Oct 2003 00:59:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08628 for ; Sat, 11 Oct 2003 00:59:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8BqT-000034-00 for dhcwg@ietf.org; Sat, 11 Oct 2003 00:59:13 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A8BqS-000031-00 for dhcwg@ietf.org; Sat, 11 Oct 2003 00:59:12 -0400 Received: from fugue.com (m698e36d0.tmodns.net [208.54.142.105]) by toccata.fugue.com (Postfix) with ESMTP id 3865C1B2BBB; Fri, 10 Oct 2003 23:57:20 -0500 (CDT) Date: Fri, 10 Oct 2003 21:59:11 -0700 Subject: Re: [dhcwg] Re: LL34: Comments on the state diagram and proposed text Content-Type: multipart/alternative; boundary=Apple-Mail-7--505678340 Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org, zeroconf@merit.edu To: Erik Guttman From: Ted Lemon In-Reply-To: <3F86B118.5040303@sun.com> Message-Id: X-Mailer: Apple Mail (2.552) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Apple-Mail-7--505678340 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I commented on Bernard's statements. I do not feel that the proposed changes fully address the problem, no. On Friday, October 10, 2003, at 06:16 AM, Erik Guttman wrote: > I am OK with these changes. Are others? --Apple-Mail-7--505678340 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit I commented on Bernard's statements. I do not feel that the proposed changes fully address the problem, no. On Friday, October 10, 2003, at 06:16 AM, Erik Guttman wrote: I am OK with these changes. Are others? --Apple-Mail-7--505678340-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 12 07:30:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15107; Sun, 12 Oct 2003 07:30:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8eQE-0008VT-Ju; Sun, 12 Oct 2003 07:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8ePc-0008QA-PK for dhcwg@optimus.ietf.org; Sun, 12 Oct 2003 07:29:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15071; Sun, 12 Oct 2003 07:29:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8ePb-0006pE-00; Sun, 12 Oct 2003 07:29:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A8ePb-0006ou-00; Sun, 12 Oct 2003 07:29:23 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9CBSnUt010965; Sun, 12 Oct 2003 04:28:50 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-113.cisco.com [10.82.224.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADB78179; Sun, 12 Oct 2003 07:28:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20031012064433.00b420a0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 12 Oct 2003 07:28:43 -0400 To: narten@us.ibm.com, Margaret.Wasserman@nokia.com From: Ralph Droms Cc: ietf-secretary@ietf.org, dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Publication of draft-ietf-dhc-dhcpv6-stateless-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , As chair of the dhc working group, on behalf of the working group, I request that the following document be published as a Proposed Standard: Title : A Guide to Implementing Stateless DHCPv6 Service Author(s) : R. Droms Filename : draft-ietf-dhc-dhcpv6-stateless-01.txt Pages : 8 Date : 2003-10-7 A dhc WG last call on this document was initiated in http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01999.html and terminated on 4/25/2003. There was some discussion about the draft, which can be read through the thread index following the original announcement. There was also a short discussion following an earlier announcement in: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01987.html There were several responses in support of publishing the document. Jinmei-san raised several issues in http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02005.html All of these issues, with one exception, have been addressed in draft-ietf-dhc-dhcpv6-stateless-01.txt Note that, although I said I would make a clarification to the draft based on Jinmei-san's comment: 4. interaction/consistency with RFC 246[12] How the stateless usage is related to the "Other stateful configuration" of router advertisements defined in RFC 2461 and 2462? I changed my mind and did not make the change. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 12 07:49:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15375; Sun, 12 Oct 2003 07:49:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8eia-0000nj-Uh; Sun, 12 Oct 2003 07:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8eiJ-0000nP-JW for dhcwg@optimus.ietf.org; Sun, 12 Oct 2003 07:48:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15342 for ; Sun, 12 Oct 2003 07:48:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8eiI-0006ua-00 for dhcwg@ietf.org; Sun, 12 Oct 2003 07:48:42 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A8eiI-0006uP-00 for dhcwg@ietf.org; Sun, 12 Oct 2003 07:48:42 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9CBmAUt016033 for ; Sun, 12 Oct 2003 04:48:10 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-113.cisco.com [10.82.224.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADB78319; Sun, 12 Oct 2003 07:48:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20031012074035.02099a50@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 12 Oct 2003 07:48:05 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-agentopt-radius-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option" . The last call will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-agentopt-radius-03.txt provides a way through which network elements can pass information obtained through layer 2 authentication to a DHCP server. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access that would be used with draft-ietf-dhc-agentopt-radius-03.txt. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-03.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 12 08:18:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16178; Sun, 12 Oct 2003 08:18:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8fAf-00021D-Tu; Sun, 12 Oct 2003 08:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8f9i-00020V-KF for dhcwg@optimus.ietf.org; Sun, 12 Oct 2003 08:17:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16124 for ; Sun, 12 Oct 2003 08:16:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8f9h-0007B6-00 for dhcwg@ietf.org; Sun, 12 Oct 2003 08:17:01 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A8f9g-0007Ao-00 for dhcwg@ietf.org; Sun, 12 Oct 2003 08:17:01 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9CCGS7E023579 for ; Sun, 12 Oct 2003 05:16:28 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-113.cisco.com [10.82.224.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADB78642; Sun, 12 Oct 2003 08:16:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20031012074035.02099a50@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 12 Oct 2003 07:51:09 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-agentopt-radius-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option" . The last call will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-agentopt-radius-03.txt provides a way through which network elements can pass information obtained through layer 2 authentication to a DHCP server. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access that would be used with draft-ietf-dhc-agentopt-radius-03.txt. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-03.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 12 11:18:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20590; Sun, 12 Oct 2003 11:18:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8hyr-00088y-7m; Sun, 12 Oct 2003 11:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8hyR-00088C-Qb for dhcwg@optimus.ietf.org; Sun, 12 Oct 2003 11:17:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20539 for ; Sun, 12 Oct 2003 11:17:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8hyQ-0000Xn-00 for dhcwg@ietf.org; Sun, 12 Oct 2003 11:17:34 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A8hyQ-0000XD-00 for dhcwg@ietf.org; Sun, 12 Oct 2003 11:17:34 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9CFH27E017432 for ; Sun, 12 Oct 2003 08:17:03 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-113.cisco.com [10.82.224.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADB80823; Sun, 12 Oct 2003 11:17:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20031012080851.04ca5f00@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 12 Oct 2003 11:17:00 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "DHCP Option for Mobile IP Mobility Agents" . The last call will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the Mobility Agent Option, and two sub-options of the Mobility Agent Option: the Network Access Identifier Sub-Option, which provides identifying information about a DHCP client to the DHCP server and the Mobility Agent Announcement sub-option, which announces the address of one or more mobility agents available to a host. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 12 13:22:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23609; Sun, 12 Oct 2003 13:22:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8jus-0004IT-4X; Sun, 12 Oct 2003 13:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8jue-0004Hn-GX for dhcwg@optimus.ietf.org; Sun, 12 Oct 2003 13:21:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23577; Sun, 12 Oct 2003 13:21:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8juc-0001ad-00; Sun, 12 Oct 2003 13:21:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A8jub-0001aP-00; Sun, 12 Oct 2003 13:21:45 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 12 Oct 2003 10:30:17 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9CHLCWS015351; Sun, 12 Oct 2003 13:21:13 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-113.cisco.com [10.82.224.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADB82223; Sun, 12 Oct 2003 13:21:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20031012130921.04931f00@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 12 Oct 2003 13:20:06 -0400 To: narten@us.ibm.com, Margaret.Wasserman@nokia.com From: Ralph Droms Cc: ietf-secretary@ietf.org, dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Publication of draft-ietf-dhc-relay-agent-ipsec-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , As chair of the dhc working group, on behalf of the working group, I request that the following document be published as a Proposed Standard: Title : Authentication of DHCP Relay Agent Options Using IPsec Author(s) : R. Droms Filename : draft-ietf-dhc-relay-agent-ipsec-00.txt Pages : 8 Date : 2003-9-2 Following up on the conversation started in http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02126.html, the two mechanisms for securing messages between relay agents and DHCP servers originally published in draft-ietf-dhc-relay-agent-auth-01.txt are to be published as separate documents. This document gives the specification for one of those two mechanisms, which uses IPsec to provide message security. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Oct 12 14:01:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24221; Sun, 12 Oct 2003 14:01:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8kWc-0005it-F3; Sun, 12 Oct 2003 14:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8kWI-0005iK-4f for dhcwg@optimus.ietf.org; Sun, 12 Oct 2003 14:00:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24196; Sun, 12 Oct 2003 14:00:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8kWF-0001nD-00; Sun, 12 Oct 2003 14:00:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A8kWE-0001mz-00; Sun, 12 Oct 2003 14:00:38 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9CI05lR003549; Sun, 12 Oct 2003 11:00:05 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-113.cisco.com [10.82.224.113]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADB82633; Sun, 12 Oct 2003 14:00:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20031012083416.00b427a0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 12 Oct 2003 14:00:00 -0400 To: narten@us.ibm.com, Margaret.Wasserman@nokia.com From: Ralph Droms Cc: ietf-secretary@ietf.org, dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Publication of draft-ietf-dhc-server-mib-08.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , As chair of the dhc working group, on behalf of the working group, I request that the following document be published as a Proposed Standard: Title : Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB Author(s) : R. Hibbs, G. Waters Filename : draft-ietf-dhc-server-mib-08.txt Pages : 51 Date : 2003-3-6 A dhc WG last call on this document was initiated in http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg01996.html After one extension in http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02066.html, the last call terminated on July 7. There was some discussion about the draft, which can be read through the thread index following the original announcement. There were additional positive responses in: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02093.html http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02129.html http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02174.html - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 13 07:11:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00219; Mon, 13 Oct 2003 07:11:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A90bO-0003qh-BF; Mon, 13 Oct 2003 07:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A90an-0003pM-UI for dhcwg@optimus.ietf.org; Mon, 13 Oct 2003 07:10:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00184 for ; Mon, 13 Oct 2003 07:10:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A90aj-0001XN-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 07:10:21 -0400 Received: from alijku01.edvz.uni-linz.ac.at ([140.78.2.62]) by ietf-mx with esmtp (Exim 4.12) id 1A90ai-0001XG-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 07:10:21 -0400 Received: from soft.uni-linz.ac.at (wall4.soft.uni-linz.ac.at [140.78.95.234]) by alijku01.edvz.uni-linz.ac.at (8.12.9/8.12.9) with ESMTP id h9DBA2rF105164; Mon, 13 Oct 2003 13:10:03 +0200 Message-ID: <3F8A880A.4010206@soft.uni-linz.ac.at> Date: Mon, 13 Oct 2003 13:10:02 +0200 From: Simon Vogl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org, Ralph Droms Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by alijku01.edvz.uni-linz.ac.at id h9DBA2rF105164 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] rfc 2131 details Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, I want to asynchronously transmit data from the dhcp server to interested clients. The state diagram in rfc2131(Fig.5) indicates potentially arriving DHCPACKs in BOUND state, which I could use for transmitting the option values. Unfortunately, appropriate handling is not defined (or I could not find it) in this document - is this defined in a newer rfc? If nothing else is proposed, I'd set the xid to the client ip address to transmit my dhcp options to be compatible with the handling of acks in REBINDING state. Is this an acceptable solution? Cheers Simon --=20 ------------------------------------------------ Dr. Simon Vogl Department of Computer Science Johannes Kepler University of Linz Altenberger Stra=C3=9Fe 69 A-4040 Linz - Austria Tel: +43 70 2468 8517 vogl@soft.uni-linz.ac.at Fax: +43 70 2468 8426 www.soft.uni-linz.ac.at _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 13 08:06:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01489; Mon, 13 Oct 2003 08:06:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A91Sb-0005dV-CP; Mon, 13 Oct 2003 08:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A91Rs-0005bv-1A for dhcwg@optimus.ietf.org; Mon, 13 Oct 2003 08:05:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01449 for ; Mon, 13 Oct 2003 08:05:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A91Rr-0001t5-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 08:05:15 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A91Rq-0001sz-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 08:05:14 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9DC4fWS005600 for ; Mon, 13 Oct 2003 08:04:41 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-261.cisco.com [10.82.225.5]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADC00738; Mon, 13 Oct 2003 08:04:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20031012085130.01e1bc80@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Oct 2003 07:58:52 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-v4-threat-analysis-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis" . The last call will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-v4-threat-analysis-00.txt provides a comprehensive threat analysis of the Dynamic Host Configuration Protocol for use both as RFC 2131 advances from Draft Standard to Full Standard and to support the dhc WG chartered work improving the acceptance and deployment of RFC 3118. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 13 08:24:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01780; Mon, 13 Oct 2003 08:24:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A91k1-0006Uk-BX; Mon, 13 Oct 2003 08:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A91j9-0006Sf-9T for dhcwg@optimus.ietf.org; Mon, 13 Oct 2003 08:23:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01758 for ; Mon, 13 Oct 2003 08:22:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A91j8-0001zk-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 08:23:06 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1A91j7-0001zb-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 08:23:05 -0400 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1A91hv-0007kU-00; Mon, 13 Oct 2003 05:21:51 -0700 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Oct 2003 05:21:27 -0700 Message-ID: From: "Kostur, Andre" To: "'Simon Vogl '" , "'dhcwg@ietf.org '" Subject: RE: [dhcwg] rfc 2131 details Date: Mon, 13 Oct 2003 05:21:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39184.8479A0E0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C39184.8479A0E0 Content-Type: text/plain; charset="utf-8" Sounds like there's two possible solutions: 1) DHCPINFORM (RFC 2131). Useful if the client is trying to solicit configuration information 2) FORCERENEW (RFC 3202). Useful for the server to instruct certain clients that it is time to renew (to get new config info). The problem with #2 is that it depends on RFC 3118 (of which I don't know anybody who supports it yet), and client-side support (same problem.. I don't know any client which supports it). And... according to the state diagram it seems to show that "unsolicited" ACKs, NAKs, and OFFERs are ignored while in the bound state. -----Original Message-----From: Simon Vogl To: dhcwg@ietf.org; Ralph Droms Sent: 10/13/2003 4:10 AM Subject: [dhcwg] rfc 2131 details Hi, I want to asynchronously transmit data from the dhcp server to interested clients. The state diagram in rfc2131(Fig.5) indicates potentially arriving DHCPACKs in BOUND state, which I could use for transmitting the option values. Unfortunately, appropriate handling is not defined (or I could not find it) in this document - is this defined in a newer rfc? If nothing else is proposed, I'd set the xid to the client ip address to transmit my dhcp options to be compatible with the handling of acks in REBINDING state. Is this an acceptable solution? ------_=_NextPart_001_01C39184.8479A0E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] rfc 2131 details

Sounds like there's two possible solutions:

1) DHCPINFORM (RFC 2131).  Useful if the client = is trying to solicit configuration information

2) FORCERENEW (RFC 3202).  Useful for the server = to instruct certain clients that it is time to renew (to get new config = info).

The problem with #2 is that it depends on RFC 3118 = (of which I don't know anybody who supports it yet), and client-side = support (same problem.. I don't know any client which supports = it).


And... according to the state diagram it seems to = show that "unsolicited" ACKs, NAKs, and OFFERs are ignored = while in the bound state.

-----Original Message-----From: Simon Vogl
To: dhcwg@ietf.org; Ralph Droms
Sent: 10/13/2003 4:10 AM
Subject: [dhcwg] rfc 2131 details

Hi,
I want to asynchronously transmit data from the dhcp = server
to interested clients. The state diagram in = rfc2131(Fig.5)
indicates potentially arriving DHCPACKs in BOUND = state, which
I could use for transmitting the option = values.

Unfortunately, appropriate handling is not defined = (or I could
not find it) in this document - is this defined in a = newer rfc?

If nothing else is proposed, I'd set the xid to the = client ip
address to transmit my dhcp options to be compatible = with the
handling of acks in REBINDING state. Is this an = acceptable solution?

------_=_NextPart_001_01C39184.8479A0E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 13 08:37:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02136; Mon, 13 Oct 2003 08:37:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A91wc-0006sq-8a; Mon, 13 Oct 2003 08:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A91wD-0006s9-To for dhcwg@optimus.ietf.org; Mon, 13 Oct 2003 08:36:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01997 for ; Mon, 13 Oct 2003 08:36:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A91wC-00023d-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 08:36:36 -0400 Received: from alijku01.edvz.uni-linz.ac.at ([140.78.2.62]) by ietf-mx with esmtp (Exim 4.12) id 1A91wB-00023a-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 08:36:35 -0400 Received: from soft.uni-linz.ac.at (wall4.soft.uni-linz.ac.at [140.78.95.234]) by alijku01.edvz.uni-linz.ac.at (8.12.9/8.12.9) with ESMTP id h9DCaUrF033920; Mon, 13 Oct 2003 14:36:31 +0200 Message-ID: <3F8A9C4E.8080500@soft.uni-linz.ac.at> Date: Mon, 13 Oct 2003 14:36:30 +0200 From: Simon Vogl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "Kostur, Andre" CC: "'dhcwg@ietf.org '" Subject: Re: [dhcwg] rfc 2131 details References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by alijku01.edvz.uni-linz.ac.at id h9DCaUrF033920 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Kostur, Andre wrote: > Sounds like there's two possible solutions: >=20 > 1) DHCPINFORM (RFC 2131). Useful if the client is trying to solicit=20 > configuration information >=20 Right, I would use this to get information to the server. Unfortunately, I need the other direction as well. > 2) FORCERENEW (RFC 3202). Useful for the server to instruct certain=20 > clients that it is time to renew (to get new config info). >=20 > The problem with #2 is that it depends on RFC 3118 (of which I don't=20 > know anybody who supports it yet), and client-side support (same=20 > problem.. I don't know any client which supports it). >=20 >=20 Yet another: I don't want to change the IP settings on the client, but only transmit additional data. Forcing the client into Renewing results i= n more overhead (# of packets xmited) than simply sending an ACK. > And... according to the state diagram it seems to show that=20 > "unsolicited" ACKs, NAKs, and OFFERs are ignored while in the bound sta= te. >=20 Right, but all I want is a specific option value. So I could go ahead and parse the options anyway, maybe with the limitation that all other parame= ters must match the values the client agreed on earlier. The sending of packets from server to client depends on a parameter value (235 in my local setting), so only 'enabled' clients would get additional packets anyway. If the default is to ignore them, all other implementatio= ns should be able to live with this solution even if they got such a packet. Simon > -----Original Message-----From: Simon Vogl > To: dhcwg@ietf.org; Ralph Droms > Sent: 10/13/2003 4:10 AM > Subject: [dhcwg] rfc 2131 details >=20 > Hi, > I want to asynchronously transmit data from the dhcp server > to interested clients. The state diagram in rfc2131(Fig.5) > indicates potentially arriving DHCPACKs in BOUND state, which > I could use for transmitting the option values. >=20 > Unfortunately, appropriate handling is not defined (or I could > not find it) in this document - is this defined in a newer rfc? >=20 > If nothing else is proposed, I'd set the xid to the client ip > address to transmit my dhcp options to be compatible with the > handling of acks in REBINDING state. Is this an acceptable solution? >=20 --=20 ------------------------------------------------ Dr. Simon Vogl Department of Computer Science Johannes Kepler University of Linz Altenberger Stra=C3=9Fe 69 A-4040 Linz - Austria Tel: +43 70 2468 8517 vogl@soft.uni-linz.ac.at Fax: +43 70 2468 8426 www.soft.uni-linz.ac.at _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 13 08:51:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02375; Mon, 13 Oct 2003 08:51:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92A8-0007Vx-Kw; Mon, 13 Oct 2003 08:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A929M-0007U0-9C for dhcwg@optimus.ietf.org; Mon, 13 Oct 2003 08:50:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02340 for ; Mon, 13 Oct 2003 08:50:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A929K-00027k-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 08:50:10 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A929K-00027a-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 08:50:10 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9DCncIR009134 for ; Mon, 13 Oct 2003 05:49:38 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-261.cisco.com [10.82.225.5]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADC02680; Mon, 13 Oct 2003 08:49:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20031012090550.048f5a38@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Oct 2003 08:46:04 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-pxe-options-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "DHCP Preboot eXecution Environment (PXE) Suboptions" . The last call will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-pxe-options-00.txt documents three DHCP options that are in common use by PXE. These options uniquely identify booting client machines and their pre-OS runtime environment so the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-pxe-options-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 13 09:01:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02655; Mon, 13 Oct 2003 09:01:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92Jq-0007oP-M7; Mon, 13 Oct 2003 09:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A92JP-0007nF-7F for dhcwg@optimus.ietf.org; Mon, 13 Oct 2003 09:00:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02602 for ; Mon, 13 Oct 2003 09:00:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A92JN-0002Bc-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 09:00:33 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A92JN-0002BP-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 09:00:33 -0400 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id h9DD020m008181; Mon, 13 Oct 2003 15:00:02 +0200 Date: Mon, 13 Oct 2003 15:00:01 +0200 From: Henrik Levkowetz Cc: dhcwg@ietf.org Subject: Re: [Mip4] Fw: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt Message-Id: <20031013150001.64bd9a4c.henrik@levkowetz.com> In-Reply-To: <3F8A6D3F.6000505@iqmail.net> References: <20031013092834.14db8925.henrik@levkowetz.com> <3F8A6D3F.6000505@iqmail.net> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Mon__13_Oct_2003_15_00_01_+0200_RaxwWoTWagtOhzTW" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Signature=_Mon__13_Oct_2003_15_00_01_+0200_RaxwWoTWagtOhzTW Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Thanks Kuntal. You're right with respect to the 'B' bit. In general, the fields would be static, but this bit potentially won't be, so the draft should mention that. In the usage we (ipUnplugged) see for this option, the dhcp server would be co-located with one of the mobility-agents, and know about the dynamic information, but that can't be assumed to always be the case. There are also the case of differentiation of services, and hot-spot co-location of different service providers to consider; in those cases the information also can be assumed to be static, I believe. Henrik On Monday, 13 Oct 2003, Kuntal wrote: > An high level comment: > > The draft talks about load sharing among Agents with this DHCP option. It is not > apparent how the DHCP server comes to know about the actual load each Agent has > at the time of sending a response to a client. > > The draft replicates the Agent Advertisement fields in the Mobility Agent > Announcements. This may be too static i.e. requires pre-configuration in the > DHCP server. I don't think it is a wise idea to proactively set some or all of > the fields on behalf of the Mobility Agents e.g. The Agent may be busy and would > like to set the B bit in AA. > > IMHO, the DHCP server should only include the Agent's IP address in the > response. Let the client send an AS unicast to the Agent and let the Agent > respond with an appropriate AA. Let Mobile IPv4 procedure take it's normal course. > > -Kuntal > > Henrik Levkowetz wrote: > > > The message below (hereby forwarded from the dhcwg list to the mip4 > > list) announces a dhc WG last call on "DHCP Option for Mobile IP > > Mobility Agents", . Although this > > is a dhc WG work item, is highly relevant to the Mip4 working group. > > > > Please respond to this WG last call, on the dhcwg mailing list > > (dhcwg@ietf.org), with copies to the mip4 list. If you support > > acceptance of the document without change, respond with a simple > > acknowledgment, so that support for the document can be assessed. > > > > Henrik > > > > ---- Begin forwarded message: ---- > > > > > >>Date: Sun, 12 Oct 2003 11:17:00 -0400 > >>From: Ralph Droms > >>To: dhcwg@ietf.org > >>Subject: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt > > > > > >> > >>This message announces a WG last call on "DHCP Option for Mobile IP Mobility > >>Agents" . The last call will conclude > >>at 5PM ET on Friday, 10/24/2003. > >> > >>Please respond to this WG last call. If you support acceptance of the > >>document without change, respond with a simple acknowledgment, so that > >>support for the document can be assessed. > >> > >>draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the > >>Mobility Agent Option, and two sub-options of the Mobility Agent Option: the > >>Network Access Identifier Sub-Option, which provides > >>identifying information about a DHCP client to the DHCP server and the > >>Mobility Agent Announcement sub-option, which announces the address of one > >>or more mobility agents available to a host. This draft is available as > >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt > >> > >>- Ralph Droms > >> > >> > >>_______________________________________________ > >>dhcwg mailing list > >>dhcwg@ietf.org > >>https://www1.ietf.org/mailman/listinfo/dhcwg > >> > > > > Henrik -- Survive. Socialize. Have fun. That's the progression -- Linus Torvalds --Signature=_Mon__13_Oct_2003_15_00_01_+0200_RaxwWoTWagtOhzTW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/iqHReVhrtTJkXCMRAsceAKDOF2t3/jCRVZRYAoBytR0j1TKnTACffL3S 1AsMekdFVD08ENdpqZ2E6bU= =KsU4 -----END PGP SIGNATURE----- --Signature=_Mon__13_Oct_2003_15_00_01_+0200_RaxwWoTWagtOhzTW-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 13 13:11:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15882; Mon, 13 Oct 2003 13:11:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96Co-0004t4-20; Mon, 13 Oct 2003 13:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96CP-0004sG-OX for dhcwg@optimus.ietf.org; Mon, 13 Oct 2003 13:09:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15735 for ; Mon, 13 Oct 2003 13:09:22 -0400 (EDT) From: Patrick.Guelat@imp.ch Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A96CI-0005bB-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 13:09:30 -0400 Received: from mail.imp.ch ([157.161.1.2]) by ietf-mx with esmtp (Exim 4.12) id 1A96CI-0005al-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 13:09:30 -0400 Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id h9DH9L5M027544 for ; Mon, 13 Oct 2003 19:09:22 +0200 (CEST) (envelope-from Patrick.Guelat@imp.ch) Date: Mon, 13 Oct 2003 19:09:21 +0200 X-X-Sender: patg@nbs.imp.ch To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.imp.ch id h9DH9L5M027544 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] Minimum size of a dhcp message Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I recently experienced some problems with our dhcp implementation in combination with some clients which didn't accept our OFFERs. In this special case it was a relatively old COM21 cablemodem with VXworks OS. As it turned out, the dhcp client of the modem insisted on a minimum dhcp message size of 300 bytes, which is in fact the size of the 'old' bootp-packet (with it's 64 bytes of vendor specific informations) It looks like ISC-DHCPD is respecting this minimum size (padding the remaining bytes after the end option with zeroes). I fixed our server to ensure this minimum size in responses, unfortunately I couldn't find where this minmum mis specified in the DHCP RFCs (it is spefified in the bootp rfc 1497) Is this client behaving correctly ? -Patrick -- Patrick Gu=E9lat, ImproWare AG Network Services, CH-4133 Pratteln Mail: Patrick.Guelat@imp.ch - Phone: +41 61 826 93 00 (ext: 13) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 13 20:32:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07012; Mon, 13 Oct 2003 20:32:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9D6X-0001EW-CU; Mon, 13 Oct 2003 20:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9D5q-0001Cd-Jl for dhcwg@optimus.ietf.org; Mon, 13 Oct 2003 20:31:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06969 for ; Mon, 13 Oct 2003 20:31:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9D5o-0003ev-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 20:31:16 -0400 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1A9D5n-0003es-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 20:31:15 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9E0V4QU047967; Mon, 13 Oct 2003 20:31:12 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: , "'Ralph Droms'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-pxe-options-00.txt Date: Mon, 13 Oct 2003 20:31:08 -0400 Message-ID: <000a01c391ea$79915bd0$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <4.3.2.7.2.20031012090550.048f5a38@flask.cisco.com> Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable While I otherwise support this draft and would like to see it advance, I would request that the use of "suboption" be changed to "option". In = common usage within DHCP, if an option can carry multiple tuples of data, these = are referred to as suboptions and it would be good not to confuse this terminology (this draft talks of options, not suboptions). Thus, all instances of 'suboption' / 'suboptions' in the draft should be replaced = with 'option' / 'options'. Do we also need some language in the introduction section that clearly indicates that these options are in wide use as defined by the PXE specification [reference 4 in the draft] and are being documented in = this draft for completeness within the IETF? - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ralph Droms Sent: Monday, October 13, 2003 8:46 AM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-pxe-options-00.txt This message announces a WG last call on "DHCP Preboot eXecution = Environment (PXE) Suboptions" . The last call = will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-pxe-options-00.txt documents three DHCP options that are = in common use by PXE. These options uniquely identify booting client = machines and their pre-OS runtime environment so the DHCP and/or PXE boot server = can return the correct OS bootstrap image (or pre-boot application) name and server to the client. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-pxe-options-00.txt - Ralph Droms=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 13 21:53:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09268; Mon, 13 Oct 2003 21:53:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9EMv-0004rJ-1q; Mon, 13 Oct 2003 21:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9EMb-0004qe-Fb for dhcwg@optimus.ietf.org; Mon, 13 Oct 2003 21:52:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09207 for ; Mon, 13 Oct 2003 21:52:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9EMY-0004PP-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 21:52:38 -0400 Received: from smtp013.mail.yahoo.com ([216.136.173.57]) by ietf-mx with smtp (Exim 4.12) id 1A9EMX-0004PM-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 21:52:37 -0400 Received: from adsl-67-115-132-186.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@67.115.132.186 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Oct 2003 01:52:37 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] rfc 2131 details Date: Mon, 13 Oct 2003 18:50:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: <3F8A9C4E.8080500@soft.uni-linz.ac.at> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable comments in-line --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Simon Vogl > Sent: Monday, October 13, 2003 05:36 > To: Kostur, Andre > Cc: 'dhcwg@ietf.org ' >=20 > Kostur, Andre wrote: > > Sounds like there's two possible solutions: > >=20 > > 1) DHCPINFORM (RFC 2131). Useful if the client is trying to solicit = > > configuration information > >=20 > Right, I would use this to get information to the server. = Unfortunately, > I need the other direction as well. >=20 ...DHCPINFORM is a "request" by the client to the server to supply = additional option data -- the parameter request list is explicitly = allowed so that the client may request a specific set of parameters. = The DHCP server is NOT REQUIRED to process arbitrary options sent by the = client as part of the DHCPINFORM message, so your statement "...to get = information to the server" isn't quite correct -- the specific behavior = of a particular server depends on its implementation, which is not = specified by RFC 2131. The DHCPACK message, returned from the server to = the client, does precisely what you wish, that is, sends data from the = server to the client. *Snip!* > Yet another: I don't want to change the IP settings on the client, but > only transmit additional data. Forcing the client into Renewing = results in > more overhead (# of packets xmited) than simply sending an ACK. >=20 ...not necessary: the pair of messages DHCPINFORM and DHCPACK occurs = while the client is in the BOUND state. > > And... according to the state diagram it seems to show that=20 > > "unsolicited" ACKs, NAKs, and OFFERs are ignored while in the=20 > bound state. > >=20 ...yes, discarding DHCPOFFERs, DHCPNAKs, and "unsolicited" DHCPACKs is = the correct behavior for a DHCP client -- the DHCPACK message received = in response to a DHCPINFORM message is NOT an unsolicited message, and = SHOULD be processed by the client. > Right, but all I want is a specific option value. So I could go ahead = and > parse the options anyway, maybe with the limitation that all=20 > other parameters > must match the values the client agreed on earlier. >=20 ...precisely! There has been a great deal of discussion about what to = do if options differ between DHCPOFFER and DHCPACK messages, though that = discussion did not specifically consider a DHCPACK received in response = to a DHCPINFORM message -- if the parameter request list in the = DHCPINFORM message only requests the options of interest (note that it = CANNOT request a new IP address) then your client implementation is = probably generally interoperable. *Snip!* _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 14 01:04:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13531; Tue, 14 Oct 2003 01:04:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9HLl-0004Jg-0T; Tue, 14 Oct 2003 01:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9HLc-0004J9-7G for dhcwg@optimus.ietf.org; Tue, 14 Oct 2003 01:03:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13505 for ; Tue, 14 Oct 2003 01:03:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9HLZ-0005oT-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 01:03:49 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A9HLY-0005oQ-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 01:03:48 -0400 Received: from fugue.com (m698e36d0.tmodns.net [208.54.142.105]) by toccata.fugue.com (Postfix) with ESMTP id 0E0AD1B2BCE; Tue, 14 Oct 2003 00:01:27 -0500 (CDT) Date: Mon, 13 Oct 2003 22:03:49 -0700 Subject: Re: [dhcwg] rfc 2131 details Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just to stick my two cents in here, you really don't want a DHCP client that listens to a DHCPACK when it's not expecting one, since this makes it really easy to attack the client and inject a bogus configuration. So unfortunately, if you want to do what you want to do, DHCPFORCERENEW is probably the way to do it. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 14 02:46:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27881; Tue, 14 Oct 2003 02:46:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9IwV-0001c4-An; Tue, 14 Oct 2003 02:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Iw2-0001b9-At for dhcwg@optimus.ietf.org; Tue, 14 Oct 2003 02:45:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27862 for ; Tue, 14 Oct 2003 02:45:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Ivy-0006bE-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 02:45:30 -0400 Received: from alijku01.edvz.uni-linz.ac.at ([140.78.2.62]) by ietf-mx with esmtp (Exim 4.12) id 1A9Ivx-0006bA-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 02:45:29 -0400 Received: from soft.uni-linz.ac.at (wall4.soft.uni-linz.ac.at [140.78.95.234]) by alijku01.edvz.uni-linz.ac.at (8.12.9/8.12.9) with ESMTP id h9E6jPDi104398; Tue, 14 Oct 2003 08:45:26 +0200 Message-ID: <3F8B9B85.8030502@soft.uni-linz.ac.at> Date: Tue, 14 Oct 2003 08:45:25 +0200 From: Simon Vogl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: rbhibbs@pacbell.net CC: dhcwg@ietf.org Subject: Re: [dhcwg] rfc 2131 details References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by alijku01.edvz.uni-linz.ac.at id h9E6jPDi104398 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi and thanks for your insightful comments. To clear things up a bit: My application is a location based service, tha= t feeds data to different services on the client depending where he is (loc= ation detected, for example, by moving from one WLAN access point to another). As the client (program/device) does not know in advance when this locatio= n change occurs, I am looking for a way to submit information to it without implem= enting another protocol stack, so simpler devices can be incorporated as well. Barr Hibbs wrote: > comments in-line >=20 > --Barr >=20 <.../> >=20 > ...DHCPINFORM is a "request" by the client to the server to supply addi= tional option data -- the parameter request list is explicitly allowed so= that the client may request a specific set of parameters. The DHCP serr= ver is NOT REQUIRED to process arbitrary options sent by the client as pa= rt of the DHCPINFORM message, so your statement "...to get information to= the server" isn't quite correct -- the specific behavior of a particular= server depends on its implementation, which is not specified by RFC 2131= . The DHCPACK message, returned from the server to the client, does prec= isely what you wish, that is, sends data from the server to the client. >=20 > *Snip!* >=20 >=20 >=20 >>Yet another: I don't want to change the IP settings on the client, but >>only transmit additional data. Forcing the client into Renewing results= in >>more overhead (# of packets xmited) than simply sending an ACK. >> >=20 > ...not necessary: the pair of messages DHCPINFORM and DHCPACK occurs w= hile the client is in the BOUND state. >=20 right in this case, but as stated above: there is no inform msg prior to = the ack... Oh, another idea arises: There is no timeout specified, if I read the rfc= right, between the sending and the reception of the ack to an inform message - s= o the client could 'register' for the next location change message that would arrive e= ventually in the corresponding ack. The downside of this idea: It has an inherent race condition as location = changes may be lost as they go by unnoticed when the server has not yet received the nex= t INFORM (a problem I encountered often when dealing with tuple spaces, but thats = a different story). >=20 >=20 >>>And... according to the state diagram it seems to show that=20 >>>"unsolicited" ACKs, NAKs, and OFFERs are ignored while in the=20 >> >>bound state. >> > ...yes, discarding DHCPOFFERs, DHCPNAKs, and "unsolicited" DHCPACKs is = the correct behavior for a DHCP client -- the DHCPACK message received in= response to a DHCPINFORM message is NOT an unsolicited message, and SHOU= LD be processed by the client. >=20 >=20 >=20 >>Right, but all I want is a specific option value. So I could go ahead a= nd >>parse the options anyway, maybe with the limitation that all=20 >>other parameters >>must match the values the client agreed on earlier. >> >=20 > ...precisely! There has been a great deal of discussion about what to = do if options differ between DHCPOFFER and DHCPACK messages, though that = discussion did not specifically consider a DHCPACK received in response t= o a DHCPINFORM message -- if the parameter request list in the DHCPINFORM= message only requests the options of interest (note that it CANNOT reque= st a new IP address) then your client implementation is probably general= ly interoperable. >=20 Yes, I feared that I would bring up old flamewars with this proposal. My = client code would react like this: It ignores any IP settings but searches only for t= he location- information option. If this information is found, it is extracted and pas= sed on to the service management scripts. The code explicitely blocks any other information found in the dhcp messa= ge, if not, there would not only be severe security problems but also race conditions= when there is more than one dhcp server in the net, I fear. Thanks for your comments, Simon --=20 ------------------------------------------------ Dr. Simon Vogl Department of Computer Science Johannes Kepler University of Linz Altenberger Stra=C3=9Fe 69 A-4040 Linz - Austria Tel: +43 70 2468 8517 vogl@soft.uni-linz.ac.at Fax: +43 70 2468 8426 www.soft.uni-linz.ac.at _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 14 03:55:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29262; Tue, 14 Oct 2003 03:55:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9K1G-0005N4-Lb; Tue, 14 Oct 2003 03:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9K0J-0005Lt-KW for dhcwg@optimus.ietf.org; Tue, 14 Oct 2003 03:54:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29213 for ; Tue, 14 Oct 2003 03:53:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9K0G-00071x-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 03:54:00 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1A9K0F-00071s-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 03:54:00 -0400 Received: (qmail 6643 invoked from network); 14 Oct 2003 07:53:58 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 14 Oct 2003 07:53:58 -0000 Date: Tue, 14 Oct 2003 09:53:56 +0200 From: Henrik Levkowetz To: Kuntal Chowdhury Cc: mip4@ietf.org, dhcwg@ietf.org Subject: Re: [Mip4] Fw: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt Message-Id: <20031014095356.23a2f458.henrik@levkowetz.com> In-Reply-To: <3F8B5C19.9010208@iqmail.net> References: <20031013092834.14db8925.henrik@levkowetz.com> <3F8A6D3F.6000505@iqmail.net> <20031013145831.43dc971d.henrik@levkowetz.com> <3F8B5C19.9010208@iqmail.net> X-Mailer: Sylpheed version 0.9.5claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Multipart_Tue__14_Oct_2003_09_53_56_+0200_=.7rntCXoRWgh)jh" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Multipart_Tue__14_Oct_2003_09_53_56_+0200_=.7rntCXoRWgh)jh Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Kuntal, (Snipping Ralph's personal address and adding the dhcwg list) Monday 13 October 2003, Kuntal wrote: > Henrik, > > Please see comments inline... > > Henrik Levkowetz wrote: [snip] > > In the usage we (ipUnplugged) see for this option, the dhcp server would > > be co-located with one of the mobility-agents, and know about the dynamic > > information, but that can't be assumed to always be the case. > > > > A collocated DHCP server with a Mobility Agent may be able to know the load of > that Mobility Agent. However my understanding from the draft is that the DHCP > server can include more than on Agent Announcements in the DHCP response. How > does the DHCP server know the status of the other Mobility Agents that it is not > collocated with? As you said it cannot be always assumed. Therefore, why are we > doing this (proxy-) static announcement from the DHCP server on behalf of the > Mobility Agents? No, we see the co-located mobility agent being informed of the state also of the other agents, so this would not be a problem. > > There are also the case of differentiation of services, and hot-spot > > co-location of different service providers to consider; in those cases > > the information also can be assumed to be static, I believe. > > > > I think, DHCP server should only include Agent IP address(es) (1+) in a network > that the mobile can choose from. We should let the MN to send an AS to the > chosen FA and let the FA to respond with an AA. This should suffice. We should > stay away from static provisioning of Mobile IP specific parameters in the DHCP > server, IMHO. You realize that this adds a round trip in a handover situation which is already less than optimal? We could add a suboption wich only provided FA addresses, so you have the possibility of doing it the way you desire, too. But as I see it, almost all of the fields of the full advertisement are valuable in choosing which agent to go with if more than one is offered, so I'd not want to make your alternative the only one. Henrik --Multipart_Tue__14_Oct_2003_09_53_56_+0200_=.7rntCXoRWgh)jh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/i6uVeVhrtTJkXCMRAs5tAKCl2NWHIo+uTiHLgFWTDYz3pvLiaQCfUrAS Kvv2exjV8Suq6IrJjI6OJIc= =fZnc -----END PGP SIGNATURE----- --Multipart_Tue__14_Oct_2003_09_53_56_+0200_=.7rntCXoRWgh)jh-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 14 03:57:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29346; Tue, 14 Oct 2003 03:57:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9K3C-0005cL-Bc; Tue, 14 Oct 2003 03:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9K2w-0005bw-VK for dhcwg@optimus.ietf.org; Tue, 14 Oct 2003 03:56:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29327 for ; Tue, 14 Oct 2003 03:56:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9K2u-00073N-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 03:56:44 -0400 Received: from webmail.mail.se.dataphone.net ([212.37.1.50] helo=intermail.se.dataphone.net) by ietf-mx with esmtp (Exim 4.12) id 1A9K2t-00073K-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 03:56:43 -0400 Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.0.5) with ESMTP id 2197242; Tue, 14 Oct 2003 09:56:41 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: Patrick.Guelat@imp.ch, dhcwg@ietf.org Subject: Re: [dhcwg] Minimum size of a dhcp message Date: Tue, 14 Oct 2003 09:59:00 +0200 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200310140959.00062.budm@weird-solutions.com> Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable On Monday 13 October 2003 19.09, Patrick.Guelat@imp.ch wrote: > I recently experienced some problems with our dhcp implementation > in combination with some clients which didn't accept our OFFERs. > In this special case it was a relatively old COM21 cablemodem with > VXworks OS. > > As it turned out, the dhcp client of the modem insisted on a minimum > dhcp message size of 300 bytes, which is in fact the size of the 'old' > bootp-packet (with it's 64 bytes of vendor specific informations) > > It looks like ISC-DHCPD is respecting this minimum size (padding the > remaining bytes after the end option with zeroes). I fixed our server > to ensure this minimum size in responses, unfortunately I couldn't > find where this minmum mis specified in the DHCP RFCs (it is spefified > in the bootp rfc 1497) > > Is this client behaving correctly ? To my knowledge the DHCP packet can be smaller than 300 bytes, and in the= =20 deployment of our DHCP server the only client I was aware of that had=20 problems working with our server was vxWorks. That said, we changed it to be a minimum to be 300 bytes quite a while ba= ck,=20 and have not had any problems. RFC 2131, section 2, par. 7 (after Table 2= )=20 says: "A DHCP client must be prepared to receive DHCP messages with an 'options' field of at least length 312 octets." We haven't had any problems that I am aware of after extending the minimu= m=20 message size to 300 bytes. Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 14 07:23:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04021; Tue, 14 Oct 2003 07:23:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9NGX-0006Uz-NE; Tue, 14 Oct 2003 07:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A99dr-0008IN-TH for dhcwg@optimus.ietf.org; Mon, 13 Oct 2003 16:50:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28380 for ; Mon, 13 Oct 2003 16:50:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A99dp-00010E-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 16:50:09 -0400 Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx with esmtp (Exim 4.12) id 1A99dp-0000yl-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 16:50:09 -0400 Received: from yomiko.ddns.nominum.com (dhcp-146.engr.nominum.com [128.177.194.146]) by shell-ng.nominum.com (Postfix) with ESMTP id 15DDB5683D for ; Mon, 13 Oct 2003 13:49:38 -0700 (PDT) Received: from yomiko.ddns.nominum.com (localhost [127.0.0.1]) by yomiko.ddns.nominum.com (8.12.9/8.12.9) with ESMTP id h9DKpUlB096629; Mon, 13 Oct 2003 13:51:30 -0700 (PDT) (envelope-from scanner@yomiko.ddns.nominum.com) Message-Id: <200310132051.h9DKpUlB096629@yomiko.ddns.nominum.com> To: Erik Guttman Cc: Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu, Bernard Aboba Subject: Re: [dhcwg] Re: LL34: Comments on the state diagram and proposed text In-reply-to: Your message of "Mon, 13 Oct 2003 16:37:59 +0200." <3F8AB8C7.7070405@sun.com> X-URI: http://www.nominum.com/ X-Face: 6K2.ZvQgQ.NDQLIx.1pW(xRu*">:}&PX-Ad_!!?wU7H4L"wF"0xEwYu=8Or0V+=5?-eO1XL 7-0Hom/|]B2C7Uznyol-NVnvEk:+sod^MyB4v4qVpPDemr;b@pZdRSXu.'Gm^t0?2l,j[&t.kbc[UW x6Lz^e$K$W Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII X-Mailer: MH-E 7.3; nmh 1.0.4; XEmacs 21.4 (patch 14) Date: Mon, 13 Oct 2003 13:51:30 -0700 From: Eric Scanner Luce Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> "EG" == Erik Guttman >>>>> wrote the following on Mon, 13 Oct 2003 16:37:59 +0200 EG> Does anyone support including the state diagram in the document? EG> I'm now thinking that it will be hard to get right & its late in EG> the game. I actually like state diagrams but I have to admit Ted is right after having been burned by other state diagrams in other drafts and rfc's that were not updated and did not depict the actual protocol anymore. EG> Should we simply refer to DNAv4 instead of discussing when a EG> host might transition from DHCP configured to IPv4 LL configured EG> state? I would prefer to refer to DNAv4, but have a relatively short in-line comment indicating why this is relevant. In my experience this is nice for implementors because it gives a hint without forcing you to go read another document. EG> It sounds like you agree that there should be text which allows EG> for a host to hold onto DHCP configuration with an unexpired EG> lease even when the network configuration does not work - and at EG> the same time configure an IPv4LL address. I also want to add my voice agreeing with this. I get hit with this on my wireless laptop when signal is marginal for a short while - but still good enough to work for the most part. The continual lossage of my DHCP address because of the appearence of a link local address causes frustration. -- Scanner (scanner@nominum.com) Nominum, Inc. | www.nominum.com | +1.650.779.6035 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 14 08:11:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04020; Tue, 14 Oct 2003 07:23:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9NGX-0006Ur-AG; Tue, 14 Oct 2003 07:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A93rU-0005Yp-U5 for dhcwg@optimus.ietf.org; Mon, 13 Oct 2003 10:39:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08620 for ; Mon, 13 Oct 2003 10:39:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A93rG-0003YU-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 10:39:38 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1A93r6-0003Wx-00 for dhcwg@ietf.org; Mon, 13 Oct 2003 10:39:28 -0400 Received: from jurassic.eng.sun.com ([129.146.83.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9DEcuUP001653; Mon, 13 Oct 2003 07:38:56 -0700 (PDT) Received: from sun.com (vpn-129-156-96-112.EMEA.Sun.COM [129.156.96.112]) by jurassic.eng.sun.com (8.12.10+Sun/8.12.10) with ESMTP id h9DEcriE657962; Mon, 13 Oct 2003 07:38:54 -0700 (PDT) Message-ID: <3F8AB8C7.7070405@sun.com> Date: Mon, 13 Oct 2003 16:37:59 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Ted Lemon CC: dhcwg@ietf.org, zeroconf@merit.edu, Bernard Aboba Subject: Re: [dhcwg] Re: LL34: Comments on the state diagram and proposed text References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Everybody, Does anyone support including the state diagram in the document? I'm now thinking that it will be hard to get right & its late in the game. Should we simply refer to DNAv4 instead of discussing when a host might transition from DHCP configured to IPv4 LL configured state? Ted, Mika, It sounds like you agree that there should be text which allows for a host to hold onto DHCP configuration with an unexpired lease even when the network configuration does not work - and at the same time configure an IPv4LL address. Please suggest text. Until I see what you propose specifically, it is difficult to discuss it. Thanks, Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 14 13:48:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21128; Tue, 14 Oct 2003 13:48:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TH7-0005Kd-9a; Tue, 14 Oct 2003 13:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TGE-0005JU-GV for dhcwg@optimus.ietf.org; Tue, 14 Oct 2003 13:47:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21100 for ; Tue, 14 Oct 2003 13:46:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TGC-0005tE-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 13:47:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1A9TGB-0005sw-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 13:47:03 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 14 Oct 2003 10:46:42 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9EHkTlb002009; Tue, 14 Oct 2003 13:46:30 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADD11985; Tue, 14 Oct 2003 13:46:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20031014125942.048c0400@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Oct 2003 13:46:26 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-interop-01.txt Cc: "Bernie Volz" , dhcwg@ietf.org In-Reply-To: References: <4.3.2.7.2.20031009133414.0477a1a8@flask.cisco.com> <4.3.2.7.2.20031009104522.00b5bac0@flask.cisco.com> <000401c38e88$f1a16ad0$6701a8c0@BVolz> <4.3.2.7.2.20031009133414.0477a1a8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I haven't heard any strong opinions in favor of publishing draft-ietf-dhc-dhcpv6-interop-01.txt as Informational, so I'll let the draft expire. Just to be clear, the resolutions in draft-ietf-dhc-dhcpv6-interop-01.txt have all been incorporated into RFC 3315 (DHCPv6 PS), during the final RFC editing... - Ralph At 01:51 AM 10/15/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Thu, 09 Oct 2003 13:40:41 -0400, > >>>>> Ralph Droms said: > > > So, if anyone is interested in capturing the discussions and resolutions in > > draft-ietf-dhc-dhcpv6-interop-01.txt, I would be willing to do a little > > editing and publish a revised version as an Informational RFC. > > > If I don't hear from anyone else, I'll just let the draft expire... > >I see and agree on the points Bernie made. Regarding the publication, >I do not oppose to editing the draft to an info. RFC, but I don't see >a strong reason to take the edit/standardization process for this >purpose. > >I guess a reasonable approach is to let it expire for now and merge >important parts of it to the main RFC when the RFC is going to DS. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 14 15:39:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26726; Tue, 14 Oct 2003 15:39:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9V0a-0004mM-M3; Tue, 14 Oct 2003 15:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9V0M-0004jl-AS for dhcwg@optimus.ietf.org; Tue, 14 Oct 2003 15:38:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26649 for ; Tue, 14 Oct 2003 15:38:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9V0K-00070H-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 15:38:48 -0400 Received: from mail.cruzio.com ([63.249.95.37]) by ietf-mx with esmtp (Exim 4.12) id 1A9V0J-0006yp-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 15:38:48 -0400 Received: from akhnaten (dsl3-63-249-88-56.cruzio.com [63.249.88.56]) by mail.cruzio.com with ESMTP id h9EJbTrh018003 for ; Tue, 14 Oct 2003 12:37:29 -0700 (PDT) Reply-To: From: "Rob Stevens" To: Subject: RE: [dhcwg] Minimum size of a dhcp message Date: Tue, 14 Oct 2003 19:37:19 -0700 Message-ID: <000001c392c5$41a9de50$3858f93f@akhnaten> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <200310140959.00062.budm@weird-solutions.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Barr Hibbs and I are working on an update to RFC2131 and many of the issues will be described in the draft "draft-ietf-dhc-implementation-01" (forthcoming). Our recommendation there is that the minimum size of a DHCP packet MUST be 300 octets. This is based solely on the stated design goal that DHCP be largely compatible with BOOTP, and this requirement was imposed on BOOTP (RFC951). Why the original BOOTP stipulated this requirement is hard to say, but in the past certain routers were known to drop BOOTP packets with a smaller size. I have no idea whether this is true today, but I think we should stick with the historical requirement. Rob Stevens _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 14 23:00:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14918; Tue, 14 Oct 2003 23:00:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9btK-00076g-CP; Tue, 14 Oct 2003 23:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9SOv-0002Kh-OU for dhcwg@optimus.ietf.org; Tue, 14 Oct 2003 12:52:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19056 for ; Tue, 14 Oct 2003 12:51:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9SOt-0005G4-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 12:52:00 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1A9SOt-0005Fw-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 12:51:59 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D09F515210; Wed, 15 Oct 2003 01:51:56 +0900 (JST) Date: Wed, 15 Oct 2003 01:51:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: "Bernie Volz" , dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-interop-01.txt In-Reply-To: <4.3.2.7.2.20031009133414.0477a1a8@flask.cisco.com> References: <4.3.2.7.2.20031009104522.00b5bac0@flask.cisco.com> <000401c38e88$f1a16ad0$6701a8c0@BVolz> <4.3.2.7.2.20031009133414.0477a1a8@flask.cisco.com> User-Agent: Wanderlust/2.10.0 (Venus) 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Thu, 09 Oct 2003 13:40:41 -0400, >>>>> Ralph Droms said: > So, if anyone is interested in capturing the discussions and resolutions in > draft-ietf-dhc-dhcpv6-interop-01.txt, I would be willing to do a little > editing and publish a revised version as an Informational RFC. > If I don't hear from anyone else, I'll just let the draft expire... I see and agree on the points Bernie made. Regarding the publication, I do not oppose to editing the draft to an info. RFC, but I don't see a strong reason to take the edit/standardization process for this purpose. I guess a reasonable approach is to let it expire for now and merge important parts of it to the main RFC when the RFC is going to DS. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 14 23:00:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14919; Tue, 14 Oct 2003 23:00:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9btN-00076x-KG; Tue, 14 Oct 2003 23:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Tnt-0007mB-NQ for dhcwg@optimus.ietf.org; Tue, 14 Oct 2003 14:21:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22679 for ; Tue, 14 Oct 2003 14:21:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Tnr-0006H0-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 14:21:51 -0400 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1A9Tnq-0006Gx-00 for dhcwg@ietf.org; Tue, 14 Oct 2003 14:21:50 -0400 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D671515289; Wed, 15 Oct 2003 03:21:48 +0900 (JST) Date: Wed, 15 Oct 2003 03:21:46 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-interop-01.txt In-Reply-To: <4.3.2.7.2.20031014125942.048c0400@flask.cisco.com> References: <4.3.2.7.2.20031009133414.0477a1a8@flask.cisco.com> <4.3.2.7.2.20031009104522.00b5bac0@flask.cisco.com> <000401c38e88$f1a16ad0$6701a8c0@BVolz> <4.3.2.7.2.20031014125942.048c0400@flask.cisco.com> User-Agent: Wanderlust/2.10.0 (Venus) 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 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Tue, 14 Oct 2003 13:46:26 -0400, >>>>> Ralph Droms said: > I haven't heard any strong opinions in favor of publishing > draft-ietf-dhc-dhcpv6-interop-01.txt as Informational, so I'll let the draft > expire. > Just to be clear, the resolutions in draft-ietf-dhc-dhcpv6-interop-01.txt > have all been incorporated into RFC 3315 (DHCPv6 PS), during the final RFC > editing... Yes, I know that. I meant the 'discussion' part of the interop draft that might contain a useful background for implementors and has not yet been merged to the main RFC. (But from a quick re-read of the draft, the only example seems to be the background discussion of Issue 1...) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 15 11:46:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05548; Wed, 15 Oct 2003 11:46:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nqb-00079D-E9; Wed, 15 Oct 2003 11:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9npq-000764-FS for dhcwg@optimus.ietf.org; Wed, 15 Oct 2003 11:45:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05461 for ; Wed, 15 Oct 2003 11:45:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9npp-0006DH-00 for dhcwg@ietf.org; Wed, 15 Oct 2003 11:45:13 -0400 Received: from mail.cruzio.com ([63.249.95.37]) by ietf-mx with esmtp (Exim 4.12) id 1A9npo-0006DE-00 for dhcwg@ietf.org; Wed, 15 Oct 2003 11:45:12 -0400 Received: from akhnaten (dsl3-63-249-88-56.cruzio.com [63.249.88.56]) by mail.cruzio.com with ESMTP id h9FFjArh079289 for ; Wed, 15 Oct 2003 08:45:11 -0700 (PDT) Reply-To: From: "Rob Stevens" To: Date: Wed, 15 Oct 2003 15:45:00 -0700 Message-ID: <000c01c3936d$f7baaaf0$3858f93f@akhnaten> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-reply-to: <4.3.2.7.2.20031012080851.04ca5f00@flask.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] Bit in "flags" field indicating option overflow? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I think it's fair to say that the question of which options to return to a client remains an area of confusion in the protocol. The language of 2131 is convoluted. And I don't believe there is a clear consensus on the question of whether servers should only return what clients ask for, or whether they should return everything they know. The latter is potentially a problem due to packet overflow; a problem that is likely to become worse as vendors define their own options. Is there any interest in the idea of using another bit in the "flags" field that servers can use to tell clients that there was more data than could fit in the packet? Another idea is to use option 55 (parameter request option) in messages from servers to clients which could contain a list of all options which could not be included due to space considerations. Rob Stevens _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 15 14:31:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14933; Wed, 15 Oct 2003 14:31:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9qQH-0000zA-NY; Wed, 15 Oct 2003 14:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9qQ7-0000yJ-KG for dhcwg@optimus.ietf.org; Wed, 15 Oct 2003 14:30:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14893 for ; Wed, 15 Oct 2003 14:30:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9qQ4-0001Tc-00 for dhcwg@ietf.org; Wed, 15 Oct 2003 14:30:48 -0400 Received: from smtp011.mail.yahoo.com ([216.136.173.31]) by ietf-mx with smtp (Exim 4.12) id 1A9qQ3-0001TZ-00 for dhcwg@ietf.org; Wed, 15 Oct 2003 14:30:48 -0400 Received: from adsl-67-115-132-186.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@67.115.132.186 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 Oct 2003 18:29:45 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Date: Wed, 15 Oct 2003 11:28:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Solicitation for Implementation Issues with RFC 2131 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The DHC Working Group is attempting to identify all known implementation issues with RFC 2131 as a basis for a final discussion and review of RFC 2131 before it is published as an Internet Standard. This work grew from a discussion item during the DHC Working Group meeting at IETF-55 in Atlanta during November 2002. The DHC Working Group solicits comments about RFC 2131 in the following areas: o typographical errors: misspelled words, poor grammar, etc. o contradictions between sections of RFC 2131 o contradictions between RFC 2131 and other RFCs o any functionality given in RFC 2131 that was not described clearly and unambiguously o errors, omissions, and incomplete specification o obsolete behavior, or reference to obsolete RFCs and other documents o any functionality that is covered [better] by another RFC o any behavior or functionality that was difficult to implement or debug o any behavior or functionality that contradicted or interfered with any other functionality or behavior specified by another RFC or implementation platform o any behavior or functionality that generated dissent or questions from your user(s) An initial list of implementation issues was published as an Internet-Draft (draft-ietf-dhc-implementation-00.txt) prior to IETF-56 and has received some comments, either direct to the editors or to the mailing list. The editors are attempting to update the draft prior to the Minneapolis Working Groups meeting. Please reply to the mailing list with any implementation issues that you wish to have discussed or clarified, so that they may be included in our review. Thanks in advance, --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 15 20:01:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00182; Wed, 15 Oct 2003 20:01:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9vZe-0008O4-DR; Wed, 15 Oct 2003 20:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9vYl-0008Iz-F8 for dhcwg@optimus.ietf.org; Wed, 15 Oct 2003 20:00:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00125 for ; Wed, 15 Oct 2003 19:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9vYj-0005Zd-00 for dhcwg@ietf.org; Wed, 15 Oct 2003 20:00:05 -0400 Received: from smtp011.mail.yahoo.com ([216.136.173.31]) by ietf-mx with smtp (Exim 4.12) id 1A9vYi-0005ZR-00 for dhcwg@ietf.org; Wed, 15 Oct 2003 20:00:04 -0400 Received: from adsl-67-115-132-186.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@67.115.132.186 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Oct 2003 00:00:04 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? Date: Wed, 15 Oct 2003 16:58:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: <000c01c3936d$f7baaaf0$3858f93f@akhnaten> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rob, glad you introduced this topic. Given that a server sends a flag meaning "I have more options for you than would fit in the DHCPACK packet," how would a client receive the remaining data? Possibilities include: (1) Server uses the "parameter request list" option to specify which options ARE included in the DHCPACK packet -- the client would use a DHCPINFORM message to request any from its (the client's) original parameter list that weren't included by the server. (2) Server uses the "parameter request list" option to specify which options ARE NOT included in the DHCPACK packet -- the client would use a DHCPINFORM message to request any of interest. (3) Server does not indicate which options have or have not been returned (using the "parameter request list" option), leaving the determination of which additional options to request in a DHCPINFORM message entirely to the client, comparing the options requested to the options returned in the DHCPACK message. (4) Server uses some server-specific mechanism to determine which options to return if they all do NOT fit in the DHCPACK message. Subsequent DHCPINFORM request messages are answered with any remaining options from the DHCPREQUEST message, plus those requested in the DHCPINFORM message, until the packet is filled. This process could be repeated several times before all [default or requested] options are given to the client. Alternative (4) opens up a whole new discussion topic: what options SHOULD be returned. --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Rob > Stevens > Sent: Wednesday, October 15, 2003 15:45 > To: dhcwg@ietf.org > Subject: [dhcwg] Bit in "flags" field indicating option overflow? > > > I think it's fair to say that the question of which options to return > to a client remains an area of confusion in the protocol. The language > of 2131 is convoluted. And I don't believe there is a clear consensus > on the question of whether servers should only return what clients ask > for, or whether they should return everything they know. The latter is > potentially a problem due to packet overflow; a problem that is likely > to become worse as vendors define their own options. > > Is there any interest in the idea of using another bit in the "flags" > field that servers can use to tell clients that there was more data > than could fit in the packet? > > Another idea is to use option 55 (parameter request option) in > messages from servers to clients which could contain a list of all > options which could not be included due to space considerations. > > Rob Stevens > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 00:28:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06657; Thu, 16 Oct 2003 00:28:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9zk1-0002KH-CS; Thu, 16 Oct 2003 00:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9zjl-0002Jo-8r for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 00:27:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06637 for ; Thu, 16 Oct 2003 00:27:35 -0400 (EDT) From: narasimha.nelakuditi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9zji-00008O-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 00:27:42 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1A9zjh-00008L-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 00:27:42 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9G4RaX15609 for ; Thu, 16 Oct 2003 07:27:36 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 16 Oct 2003 07:27:34 +0300 Received: from siebh002.NOE.Nokia.com ([172.30.195.17]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 07:27:34 +0300 Received: from siebe002.NOE.Nokia.com ([172.30.195.13]) by siebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 16 Oct 2003 12:27:13 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Solicitation for Implementation Issues with RFC 2131 Date: Thu, 16 Oct 2003 12:27:13 +0800 Message-ID: <79A2DB53BC51BD448F0D19A86FB1DB637F2020@siebe002.apac.nokia.com> Thread-Topic: [dhcwg] Solicitation for Implementation Issues with RFC 2131 Thread-Index: AcOTSs0+56kl1OuoQJ2GIy2nJz3yAgAUkSaA To: , X-OriginalArrivalTime: 16 Oct 2003 04:27:13.0928 (UTC) FILETIME=[C61A8080:01C3939D] Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, I came up with a draft sometime back addressing an issue with using = of "client identifier". Following is the link to the draft. Please = include this also in your review: http://www.ietf.org/internet-drafts/draft-swamy-dhc-client-id-00.txt regards, swamy. > -----Original Message----- > From: ext Barr Hibbs [mailto:rbhibbs@pacbell.net] > Sent: Wednesday, October 15, 2003 11:58 PM > To: Dhcwg > Subject: [dhcwg] Solicitation for Implementation Issues with RFC 2131 >=20 >=20 >=20 > The DHC Working Group is attempting to identify all known=20 > implementation > issues with RFC 2131 as a basis for a final discussion and=20 > review of RFC > 2131 before it is published as an Internet Standard. >=20 > This work grew from a discussion item during the DHC Working=20 > Group meeting > at IETF-55 in Atlanta during November 2002. >=20 > The DHC Working Group solicits comments about RFC 2131 in the=20 > following > areas: >=20 > o typographical errors: misspelled words, poor grammar, etc. >=20 > o contradictions between sections of RFC 2131 >=20 > o contradictions between RFC 2131 and other RFCs >=20 > o any functionality given in RFC 2131 that was not=20 > described clearly > and unambiguously >=20 > o errors, omissions, and incomplete specification >=20 > o obsolete behavior, or reference to obsolete RFCs and=20 > other documents >=20 > o any functionality that is covered [better] by another RFC >=20 > o any behavior or functionality that was difficult to=20 > implement or debug >=20 > o any behavior or functionality that contradicted or=20 > interfered with any > other functionality or behavior specified by another RFC or > implementation platform >=20 > o any behavior or functionality that generated dissent or=20 > questions from > your user(s) >=20 > An initial list of implementation issues was published as an=20 > Internet-Draft > (draft-ietf-dhc-implementation-00.txt) prior to IETF-56 and=20 > has received > some comments, either direct to the editors or to the mailing=20 > list. The > editors are attempting to update the draft prior to the=20 > Minneapolis Working > Groups meeting. >=20 > Please reply to the mailing list with any implementation=20 > issues that you > wish to have discussed or clarified, so that they may be=20 > included in our > review. >=20 > Thanks in advance, >=20 > --Barr >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 01:38:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07944; Thu, 16 Oct 2003 01:38:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA0pl-0005Tq-DE; Thu, 16 Oct 2003 01:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA0pE-0005Ld-2A for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 01:37:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07918 for ; Thu, 16 Oct 2003 01:37:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA0pA-0000bO-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 01:37:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AA0pA-0000ay-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 01:37:24 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9G5arH7012593; Wed, 15 Oct 2003 22:36:53 -0700 (PDT) Received: from cisco.com (stealth-10-32-254-99.cisco.com [10.32.254.99]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMO53714; Wed, 15 Oct 2003 22:31:47 -0700 (PDT) Date: Wed, 15 Oct 2003 22:36:51 -0700 Subject: Re: [dhcwg] Minimum size of a dhcp message Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: From: Richard Johnson In-Reply-To: <000001c392c5$41a9de50$3858f93f@akhnaten> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Interesting! I just finished taking care of an incompatibility between our DHCP client and one particular ISP and (after trying various changes to get it to work) found the change which finally fixed the problem was to *remove* the additional padding of the packets to a minimum of 312 bytes. If I padded the DISCOVER packets, I never got any responses. They were showing me packet traces of a Windows system which did *not* do this padding and which got responses just fine. Removing our padding got a response as well. I guess you can take this as proof that there exists at least one ISP with a configuration which will NOT work if the packets are padded. /raj On Tuesday, October 14, 2003, at 07:37 PM, Rob Stevens wrote: > Barr Hibbs and I are working on an update to RFC2131 and many of the > issues will be described in the draft > "draft-ietf-dhc-implementation-01" (forthcoming). > > Our recommendation there is that the minimum size of a DHCP packet > MUST be 300 octets. > This is based solely on the stated design goal that DHCP be largely > compatible with BOOTP, and this requirement was imposed on BOOTP > (RFC951). > > Why the original BOOTP stipulated this requirement is hard to say, but > in the past certain routers were known to drop BOOTP packets with a > smaller size. I have no idea whether this is true today, but I think > we should stick with the historical requirement. > > Rob Stevens > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 01:55:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08446; Thu, 16 Oct 2003 01:55:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA16E-0005zh-3V; Thu, 16 Oct 2003 01:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA15t-0005zN-8M for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 01:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08413 for ; Thu, 16 Oct 2003 01:54:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA15p-0000iN-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 01:54:37 -0400 Received: from soft.uni-linz.ac.at ([140.78.95.99] helo=zeus.soft.uni-linz.ac.at) by ietf-mx with esmtp (Exim 4.12) id 1AA15p-0000iF-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 01:54:37 -0400 Received: from soft.uni-linz.ac.at (wall4.soft.uni-linz.ac.at [140.78.95.234]) by zeus.soft.uni-linz.ac.at (8.11.7+Sun/8.11.1) with ESMTP id h9G5j4B06318; Thu, 16 Oct 2003 07:45:04 +0200 (MEST) Message-ID: <3F8E3060.8080609@soft.uni-linz.ac.at> Date: Thu, 16 Oct 2003 07:45:04 +0200 From: Simon Vogl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: rbhibbs@pacbell.net CC: dhcwg@ietf.org Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zeus.soft.uni-linz.ac.at id h9G5j4B06318 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Just as a suggestion (which would also suit my needs of getting asynchron= ous information to the client), would it help to set a sort of 'more to come' option, indicating that more options will follow in a consecutive DHCPACK= ? This second (or nth) DHCPACK would have a 'additional information' option set as first option, indicating that only the options are of interest, no= t the ip settings. So long, Simon Barr Hibbs wrote: > Rob, >=20 > glad you introduced this topic. >=20 > Given that a server sends a flag meaning "I have more options for you t= han > would fit in the DHCPACK packet," how would a client receive the remain= ing > data? >=20 > Possibilities include: >=20 > (1) Server uses the "parameter request list" option to specify which op= tions > ARE included in the DHCPACK packet -- the client would use a DHCPINFORM > message to request any from its (the client's) original parameter list = that > weren't included by the server. >=20 > (2) Server uses the "parameter request list" option to specify which op= tions > ARE NOT included in the DHCPACK packet -- the client would use a DHCPIN= FORM > message to request any of interest. >=20 > (3) Server does not indicate which options have or have not been return= ed > (using the "parameter request list" option), leaving the determination = of > which additional options to request in a DHCPINFORM message entirely to= the > client, comparing the options requested to the options returned in the > DHCPACK message. >=20 > (4) Server uses some server-specific mechanism to determine which optio= ns to > return if they all do NOT fit in the DHCPACK message. Subsequent DHCPI= NFORM > request messages are answered with any remaining options from the > DHCPREQUEST message, plus those requested in the DHCPINFORM message, un= til > the packet is filled. This process could be repeated several times bef= ore > all [default or requested] options are given to the client. >=20 > Alternative (4) opens up a whole new discussion topic: what options SH= OULD > be returned. >=20 > --Barr >=20 >=20 >=20 >>-----Original Message----- >>From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ro= b >>Stevens >>Sent: Wednesday, October 15, 2003 15:45 >>To: dhcwg@ietf.org >>Subject: [dhcwg] Bit in "flags" field indicating option overflow? >> >> >>I think it's fair to say that the question of which options to return >>to a client remains an area of confusion in the protocol. The language >>of 2131 is convoluted. And I don't believe there is a clear consensus >>on the question of whether servers should only return what clients ask >>for, or whether they should return everything they know. The latter is >>potentially a problem due to packet overflow; a problem that is likely >>to become worse as vendors define their own options. >> >>Is there any interest in the idea of using another bit in the "flags" >>field that servers can use to tell clients that there was more data >>than could fit in the packet? >> >>Another idea is to use option 55 (parameter request option) in >>messages from servers to clients which could contain a list of all >>options which could not be included due to space considerations. >> >>Rob Stevens >> >> >>_______________________________________________ >>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 ------------------------------------------------ Dr. Simon Vogl Department of Computer Science Johannes Kepler University of Linz Altenberger Stra=DFe 69 A-4040 Linz - Austria Tel: +43 70 2468 8517 vogl@soft.uni-linz.ac.at Fax: +43 70 2468 8426 www.soft.uni-linz.ac.at _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 02:01:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09600; Thu, 16 Oct 2003 02:01:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA1C3-0006GH-DT; Thu, 16 Oct 2003 02:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA1BV-0006Ci-Ag for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 02:00:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08715 for ; Thu, 16 Oct 2003 02:00:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA1BR-0000lQ-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 02:00:25 -0400 Received: from soft.uni-linz.ac.at ([140.78.95.99] helo=zeus.soft.uni-linz.ac.at) by ietf-mx with esmtp (Exim 4.12) id 1AA1BP-0000lN-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 02:00:24 -0400 Received: from soft.uni-linz.ac.at (wall4.soft.uni-linz.ac.at [140.78.95.234]) by zeus.soft.uni-linz.ac.at (8.11.7+Sun/8.11.1) with ESMTP id h9G60NB06542 for ; Thu, 16 Oct 2003 08:00:23 +0200 (MEST) Message-ID: <3F8E33F7.7050600@soft.uni-linz.ac.at> Date: Thu, 16 Oct 2003 08:00:23 +0200 From: Simon Vogl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk X-Accept-Language: en MIME-Version: 1.0 To: "'dhcwg@ietf.org '" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zeus.soft.uni-linz.ac.at id h9G60NB06542 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] Windows DHCP Api Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, a slightly OT question, but posting in a microsoft newsgroup got me nothing but ~10 viri/hour: I am having troubles with the DHCP client API that comes with Windows 200/Xp, resp. the platform sdk. Besides the fact that the documentation in the platform sdk does not match the header files (esp. the code examples are plain wrong), all I get from DhcpRequestParams are different error codes however I permutate parameter values. Anyone had any positive experience with this API? Is there any alternative under windows? Thanks, Simon --=20 ------------------------------------------------ Dr. Simon Vogl Department of Computer Science Johannes Kepler University of Linz Altenberger Stra=C3=9Fe 69 A-4040 Linz - Austria Tel: +43 70 2468 8517 vogl@soft.uni-linz.ac.at Fax: +43 70 2468 8426 www.soft.uni-linz.ac.at _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 09:11:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01841; Thu, 16 Oct 2003 09:11:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7uA-0006Ui-86; Thu, 16 Oct 2003 09:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7tH-0006Rh-NX for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 09:10:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01782 for ; Thu, 16 Oct 2003 09:09:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7tG-0004cI-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 09:10:06 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AA7tF-0004bo-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 09:10:05 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9GD9WvA016927 for ; Thu, 16 Oct 2003 06:09:33 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADE55545; Thu, 16 Oct 2003 09:09:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20031016090709.01e5bdf8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 16 Oct 2003 09:09:28 -0400 To: From: Ralph Droms Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? In-Reply-To: References: <000c01c3936d$f7baaaf0$3858f93f@akhnaten> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Another potential solution would be for the client to increase its maximum DHCP message size to accommodate all of the options. - Ralph At 04:58 PM 10/15/2003 -0700, Barr Hibbs wrote: >Rob, > >glad you introduced this topic. > >Given that a server sends a flag meaning "I have more options for you than >would fit in the DHCPACK packet," how would a client receive the remaining >data? > >Possibilities include: > >(1) Server uses the "parameter request list" option to specify which options >ARE included in the DHCPACK packet -- the client would use a DHCPINFORM >message to request any from its (the client's) original parameter list that >weren't included by the server. > >(2) Server uses the "parameter request list" option to specify which options >ARE NOT included in the DHCPACK packet -- the client would use a DHCPINFORM >message to request any of interest. > >(3) Server does not indicate which options have or have not been returned >(using the "parameter request list" option), leaving the determination of >which additional options to request in a DHCPINFORM message entirely to the >client, comparing the options requested to the options returned in the >DHCPACK message. > >(4) Server uses some server-specific mechanism to determine which options to >return if they all do NOT fit in the DHCPACK message. Subsequent DHCPINFORM >request messages are answered with any remaining options from the >DHCPREQUEST message, plus those requested in the DHCPINFORM message, until >the packet is filled. This process could be repeated several times before >all [default or requested] options are given to the client. > >Alternative (4) opens up a whole new discussion topic: what options SHOULD >be returned. > >--Barr > > > > -----Original Message----- > > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Rob > > Stevens > > Sent: Wednesday, October 15, 2003 15:45 > > To: dhcwg@ietf.org > > Subject: [dhcwg] Bit in "flags" field indicating option overflow? > > > > > > I think it's fair to say that the question of which options to return > > to a client remains an area of confusion in the protocol. The language > > of 2131 is convoluted. And I don't believe there is a clear consensus > > on the question of whether servers should only return what clients ask > > for, or whether they should return everything they know. The latter is > > potentially a problem due to packet overflow; a problem that is likely > > to become worse as vendors define their own options. > > > > Is there any interest in the idea of using another bit in the "flags" > > field that servers can use to tell clients that there was more data > > than could fit in the packet? > > > > Another idea is to use option 55 (parameter request option) in > > messages from servers to clients which could contain a list of all > > options which could not be included due to space considerations. > > > > Rob Stevens > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 12:30:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09783; Thu, 16 Oct 2003 12:30:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAB0l-0003tP-5U; Thu, 16 Oct 2003 12:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAB09-0003sa-Gh for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 12:29:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09666 for ; Thu, 16 Oct 2003 12:29:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAB08-0006eu-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 12:29:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AAB07-0006e2-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 12:29:23 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9GGSp1b016651 for ; Thu, 16 Oct 2003 09:28:51 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADE74362; Thu, 16 Oct 2003 12:28:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20031016121859.04808c58@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 16 Oct 2003 12:28:48 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DNAv4 issue 8: Definition of "most likely" point of attachment Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Description of issue Submitter name: Ralph Droms Submitter email address: rdroms@cisco.com Date first submitted: 10/16/2003 Reference: Document: DNA-03 Comment type: E Priority: 1 Section: 1.2 Terminology Rationale/Explanation of issue: The phrase '"most likely" point of attachment' is used throughout the document but is never defined. Other, similar phrases are occasionally used, such as '"most likely" network' in the fourth paragraph of section 2.3. Requested change: Add a definition for '"most likely" point of attachment' to the terminology section. Define an acronym MLPA for the phrase. Use the acronym throughout the document. Note that, as much as I dislike the proliferation of acronyms in IETF documents, in this case I think an acronym, suitably defined in the Terminology section, would add clarity. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 13:45:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13166; Thu, 16 Oct 2003 13:45:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AACBK-0007uc-2z; Thu, 16 Oct 2003 13:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AACAr-0007tA-A6 for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 13:44:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13084 for ; Thu, 16 Oct 2003 13:44:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AACAp-0007cA-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 13:44:31 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AACAo-0007bE-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 13:44:30 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9GHhrFJ015695; Thu, 16 Oct 2003 13:43:56 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADE82260; Thu, 16 Oct 2003 13:43:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20031016133158.0481eaf8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 16 Oct 2003 13:43:50 -0400 To: dhcwg@ietf.org From: Ralph Droms Cc: baboba@internaut.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DNAv4 issue 9: Use of ARP in reachability test Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Description of issue Submitter name: Ralph Droms Submitter email address: rdroms@cisco.com Date first submitted: 10/16/2003 Reference: Document: DNA-03 Comment type: T Priority: S Section: 2 Packet Format Rationale/Explanation of issue: In the fourth paragraph of section 2, the host performing the reachability test is instructed to look in the ARP response for the default gateway's MAC address and IPv4 address in ar$tha and ar$tpa, respectively. However, according to section "Packet Reception" of RFC 826, the default gateway (the target of the ARP probe) will return its MAC address and IPv4 address in ar$sha and ar$spa. There is also a minor editorial nit - the text in the first three paragraphs of section 2.2 doesn't explicitly describe what value should be used for ar$tha (should be 0) in the ARP probe message. Requested change: Change ar$tha and ar$tpa to ar$sha and ar$tha, respectively, in the fourth paragraph of section 2.2 Add the following sentence to the end of the first paragraph in section 2.2: The host sets the target hardware address field (ar$tha) to 0. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 14:54:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16266; Thu, 16 Oct 2003 14:54:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AADG5-00037u-54; Thu, 16 Oct 2003 14:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AADFo-00036y-Nk for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 14:53:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16210 for ; Thu, 16 Oct 2003 14:53:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AADFm-0000fW-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 14:53:42 -0400 Received: from smtp018.mail.yahoo.com ([216.136.174.115]) by ietf-mx with smtp (Exim 4.12) id 1AADFl-0000fT-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 14:53:41 -0400 Received: from adsl-67-115-132-186.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@67.115.132.186 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Oct 2003 18:53:37 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? Date: Thu, 16 Oct 2003 11:52:01 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <4.3.2.7.2.20031016090709.01e5bdf8@flask.cisco.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ralph-- of course this works, but I inferred from Rob's original note that either (a) the client had not indicated it could accept a buffer large enough to accommodate all of the options to be returned, or (b) that the client had specified a larger packet size, but for some reason the server wasn't able to accommodate that and had "fallen back" to a default value which was too small. Your point raises other issues as well: 1. should the server respond at all if it can't fit the requested options in the [specified or default] packet size? 2. should the server try to fill the packet in any particular order? For example, the order of entries in the "parameter request list" if it appears, the order [implied by] RFC 1122, server implementation default choice, or order implied by RFC 2131 itself? "Isn't this a fine kettle of fish?" -- Oliver Hardy --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Ralph Droms > Sent: Thursday, October 16, 2003 06:09 > > Another potential solution would be for the client to increase > its maximum > DHCP message size to accommodate all of the options. > > - Ralph > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 15:30:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18992; Thu, 16 Oct 2003 15:30:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AADou-00054K-Pj; Thu, 16 Oct 2003 15:30:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AADoL-00053T-Ay for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 15:29:25 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18772; Thu, 16 Oct 2003 15:29:15 -0400 (EDT) Message-Id: <200310161929.PAA18772@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 16 Oct 2003 15:29:14 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subscriber-id-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Subscriber ID Suboption for the DHCP Relay Agent Option Author(s) : R. Johnson, R. Droms Filename : draft-ietf-dhc-subscriber-id-02.txt Pages : 6 Date : 2003-10-16 This memo defines a new DHCP Relay Suboption for passing an arbitrary number of bytes defining what will be called the 'Subscriber ID'. This value is simply defined as an array of bytes and can be interpreted in any form by the DHCP server. Its intended purpose is to give additional information which the DHCP server can use in address allocation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-subscriber-id-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-subscriber-id-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-16143512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subscriber-id-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subscriber-id-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-16143512.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 15:30:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18993; Thu, 16 Oct 2003 15:30:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AADov-00054S-Hu; Thu, 16 Oct 2003 15:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AADoR-00053b-Cl for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 15:29:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18786; Thu, 16 Oct 2003 15:29:21 -0400 (EDT) Message-Id: <200310161929.PAA18786@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 16 Oct 2003 15:29:21 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-nisconfig-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : NIS Configuration Options for DHCPv6 Author(s) : A. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-nisconfig-03.txt Pages : 6 Date : 2003-10-16 This document describes four options for NIS-related configuration information in DHCPv6: NIS Servers [3], NIS+ Servers [3], NIS Client Domain Name [3], NIS+ Client Domain name [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-nisconfig-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-16143522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-nisconfig-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-16143522.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 16:54:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24395; Thu, 16 Oct 2003 16:54:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAF8D-00024q-35; Thu, 16 Oct 2003 16:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAF7c-00021q-Pi for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 16:53:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24327 for ; Thu, 16 Oct 2003 16:53:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAF7a-0002cR-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 16:53:22 -0400 Received: from mail.cruzio.com ([63.249.95.37]) by ietf-mx with esmtp (Exim 4.12) id 1AAF7Z-0002cG-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 16:53:22 -0400 Received: from akhnaten (dsl3-63-249-88-56.cruzio.com [63.249.88.56]) by mail.cruzio.com with ESMTP id h9GKrDvb006843 for ; Thu, 16 Oct 2003 13:53:14 -0700 (PDT) Reply-To: From: "Rob Stevens" To: Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? Date: Thu, 16 Oct 2003 20:53:04 -0700 Message-ID: <000001c39462$2b68cc20$3858f93f@akhnaten> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable We should be careful not to imply that all the client has to do is merely to suggest to the server a larger packet size, even if the client could accept something almost arbitrarily large (up to the UDP limit).=20 Many arguments have been made to the effect that IP fragmentation is not allowed on BOOTP/DHCP packets. Many (most?) implementations of both clients and servers are using link level interfaces which follow this dictum and will only accept an unfragmented packet. Quite possibly routers implementing relay agents are doing the same. Clients quite probably don't know the largest packet size that would avoid fragmentation. -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Barr Hibbs Sent: Thursday, October 16, 2003 11:52 AM To: dhcwg@ietf.org Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? Ralph-- of course this works, but I inferred from Rob's original note that either (a) the client had not indicated it could accept a buffer large enough to accommodate all of the options to be returned, or (b) that the client had specified a larger packet size, but for some reason the server wasn't able to accommodate that and had "fallen back" to a default value which was too small. Your point raises other issues as well: 1. should the server respond at all if it can't fit the requested options in the [specified or default] packet size? 2. should the server try to fill the packet in any particular order? For example, the order of entries in the "parameter request list" if it appears, the order [implied by] RFC 1122, server implementation default choice, or order implied by RFC 2131 itself? "Isn't this a fine kettle of fish?" -- Oliver Hardy --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Ralph Droms > Sent: Thursday, October 16, 2003 06:09 > > Another potential solution would be for the client to increase its=20 > maximum DHCP message size to accommodate all of the options. > > - Ralph > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 16 17:47:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26467; Thu, 16 Oct 2003 17:47:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFxU-0005H1-7f; Thu, 16 Oct 2003 17:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAFwz-0005FK-Cf for dhcwg@optimus.ietf.org; Thu, 16 Oct 2003 17:46:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26422 for ; Thu, 16 Oct 2003 17:46:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAFwv-0003Hh-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 17:46:25 -0400 Received: from smtp018.mail.yahoo.com ([216.136.174.115]) by ietf-mx with smtp (Exim 4.12) id 1AAFwv-0003He-00 for dhcwg@ietf.org; Thu, 16 Oct 2003 17:46:25 -0400 Received: from adsl-67-115-132-186.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@67.115.132.186 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Oct 2003 21:46:24 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? Date: Thu, 16 Oct 2003 14:44:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <000001c39462$2b68cc20$3858f93f@akhnaten> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Good point, Rob, so how do we determine the largest packet that will pass without fragmentation? That's really a rhetorical question, possibly one without a definitive answer. The practical issue you raise is that even if the client supplies a maximum packet size, the server might format a response packet and STILL not be able to get it to the client. --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Rob > Stevens > Sent: Thursday, October 16, 2003 20:53 > > We should be careful not to imply that all the client has to do is > merely to suggest to the server a larger packet size, even if the > client could accept something almost arbitrarily large (up to the UDP > limit). > > Many arguments have been made to the effect that IP fragmentation is > not allowed on BOOTP/DHCP packets. Many (most?) implementations of > both clients and servers are using link level interfaces which follow > this dictum and will only accept an unfragmented packet. Quite > possibly routers implementing relay agents are doing the same. > > Clients quite probably don't know the largest packet size that would > avoid fragmentation. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 00:55:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06577; Fri, 17 Oct 2003 00:55:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMdi-0005Dp-Tx; Fri, 17 Oct 2003 00:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMcu-0005D7-Vs for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 00:54:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06541 for ; Fri, 17 Oct 2003 00:54:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAMcr-0006SB-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 00:54:09 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AAMcq-0006S8-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 00:54:09 -0400 Received: from fugue.com (m698e36d0.tmodns.net [208.54.142.105]) by toccata.fugue.com (Postfix) with ESMTP id F41D01B234F; Thu, 16 Oct 2003 23:51:15 -0500 (CDT) Date: Thu, 16 Oct 2003 21:54:06 -0700 Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow? Content-Type: multipart/alternative; boundary=Apple-Mail-2-12416952 Mime-Version: 1.0 (Apple Message framework v552) Cc: To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20031016090709.01e5bdf8@flask.cisco.com> Message-Id: X-Mailer: Apple Mail (2.552) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Apple-Mail-2-12416952 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit In general, clients really should send max-message-size options every time. It is unfortunate that they don't. I think that if RFC2131 were updated, it would be worthwhile to *require* (SHOULD) that the client send this option, and that they send a message size that is the MTU of the network interface being configured. --Apple-Mail-2-12416952 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit In general, clients really should send max-message-size options every time. It is unfortunate that they don't. I think that if RFC2131 were updated, it would be worthwhile to *require* (SHOULD) that the client send this option, and that they send a message size that is the MTU of the network interface being configured. --Apple-Mail-2-12416952-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 00:59:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06704; Fri, 17 Oct 2003 00:59:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMhY-0005Xw-7s; Fri, 17 Oct 2003 00:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAMgl-0005R5-5P for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 00:58:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06659 for ; Fri, 17 Oct 2003 00:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAMgi-0006Tr-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 00:58:08 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AAMgh-0006To-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 00:58:07 -0400 Received: from fugue.com (m698e36d0.tmodns.net [208.54.142.105]) by toccata.fugue.com (Postfix) with ESMTP id 041FF1B23B7; Thu, 16 Oct 2003 23:55:16 -0500 (CDT) Date: Thu, 16 Oct 2003 21:58:07 -0700 Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow? Content-Type: multipart/alternative; boundary=Apple-Mail-4-12658095 Mime-Version: 1.0 (Apple Message framework v552) Cc: To: From: Ted Lemon In-Reply-To: Message-Id: <7FAA557D-005E-11D8-92F5-000A95D9C74C@fugue.com> X-Mailer: Apple Mail (2.552) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Apple-Mail-4-12658095 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Reassembling fragments really isn't very hard. If a client knows it can't reassemble, it should specify the lowest legal value for MTU, but I think this is a very rare case. These clients are likely the ones that need the fewest options. And in answer to Rob's earlier question, except in cases where the parameter request list is stupid (i.e., doesn't request subnet mask), I think the DHCP server should honor it and not send options not listed in it. This is how I read RFC2131 to begin with, although I know others have read it differently. On Thursday, October 16, 2003, at 02:44 PM, Barr Hibbs wrote: > The practical issue you raise is that even if the client supplies a > maximum > packet size, the server might format a response packet and STILL not > be able > to get it to the client. --Apple-Mail-4-12658095 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Reassembling fragments really isn't very hard. If a client knows it can't reassemble, it should specify the lowest legal value for MTU, but I think this is a very rare case. These clients are likely the ones that need the fewest options. And in answer to Rob's earlier question, except in cases where the parameter request list is stupid (i.e., doesn't request subnet mask), I think the DHCP server should honor it and not send options not listed in it. This is how I read RFC2131 to begin with, although I know others have read it differently. On Thursday, October 16, 2003, at 02:44 PM, Barr Hibbs wrote: The practical issue you raise is that even if the client supplies a maximum packet size, the server might format a response packet and STILL not be able to get it to the client. --Apple-Mail-4-12658095-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 02:35:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21054; Fri, 17 Oct 2003 02:35:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAOCU-0001sQ-3Y; Fri, 17 Oct 2003 02:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAOBh-0001qU-OZ for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 02:34:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20981 for ; Fri, 17 Oct 2003 02:34:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAOBd-0007Ii-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 02:34:09 -0400 Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx with esmtp (Exim 4.12) id 1AAOBd-0007Ie-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 02:34:09 -0400 Received: from localhost ([130.194.13.83]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L1XOPRABF48ZMG4X@vaxh.its.monash.edu.au> for dhcwg@ietf.org; Fri, 17 Oct 2003 12:30:24 +1000 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id F1F7823C003; Fri, 17 Oct 2003 12:30:23 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id D356716400A; Fri, 17 Oct 2003 12:30:23 +1000 (EST) Date: Fri, 17 Oct 2003 12:30:23 +1000 From: Greg Daley Subject: Re: [dhcwg] DNAv4 issue 8: Definition of "most likely" point of attachment To: Ralph Droms Cc: dhcwg@ietf.org, spencer@mcsr-labs.org, carlw@mcsr-labs.org Reply-to: greg.daley@eng.monash.edu.au Message-id: <3F8F543F.5070405@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <4.3.2.7.2.20031016121859.04808c58@flask.cisco.com> Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Ralph, Ralph Droms wrote: > Description of issue > Submitter name: Ralph Droms > Submitter email address: rdroms@cisco.com > Date first submitted: 10/16/2003 > Reference: > Document: DNA-03 > Comment type: E > Priority: 1 > Section: 1.2 Terminology > Rationale/Explanation of issue: The phrase '"most likely" > point of attachment' is used throughout the document but > is never defined. > Other, similar phrases are occasionally used, such as '"most likely" > network' in the fourth paragraph of section 2.3. > > Requested change: Add a definition for '"most likely" point of > attachment' to the terminology section. Define an acronym > MLPA for the phrase. Use the acronym throughout the document. > Note that, as much as I dislike the proliferation of acronyms > in IETF documents, in this case I think an acronym, suitably > defined in the Terminology section, would add clarity. In DNA BoF, we're obviously interested in having common terminology across the set of techniques (v4/v6) to detect network attachment. There's currently some work in the BoF on getting terminology worked out. So that we don't slow anything down in DHC-WG, maybe we can help contribute to the terms here, and clone them into DNA. Does that sound reasonable? In this case, is it sufficient to define the most likely point of attachment, or do we also need to define "point of attachment"? I myself am clear what a point of attachment is. Is the meaning unambiguous to others, or would it simplify the definition of the MLPA to have a definition of the point of attachment? Here are some initial attempts at both options: -- Most Likely Point of Attachment (MLPA): The IP subnet and router combination the host is most likely to be connected to the network through. This is heuristically determined by the host itself by hints from the network. -- Alternatively: -- Point of Attachment: A location within the network, where a host may be connected. This attachment point can be characterized by its address prefix and next hop routing information. Most Likely Point of Attachment (MLPA): The point of attachment heuristically determined by the host to be most likely, based on hints from the network. -- Greg Daley _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 07:30:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28090; Fri, 17 Oct 2003 07:30:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASny-00074M-DP; Fri, 17 Oct 2003 07:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AASne-000741-Pr for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 07:29:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28074 for ; Fri, 17 Oct 2003 07:29:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AASne-0002PI-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 07:29:42 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AASnc-0002Oe-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 07:29:41 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2003 04:39:14 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9HBT7eA009298 for ; Fri, 17 Oct 2003 04:29:08 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-298.cisco.com [10.82.225.42]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADF32665; Fri, 17 Oct 2003 07:29:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20031017072454.04702670@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 17 Oct 2003 07:25:49 -0400 To: From: Ralph Droms Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow? In-Reply-To: References: <4.3.2.7.2.20031016090709.01e5bdf8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Any reason not to allow a message size > MTU (with a strong admonition not to do so unless really, really necessary)? - Ralph At 09:54 PM 10/16/2003 -0700, Ted Lemon wrote: >In general, clients really should send max-message-size options every >time. It is unfortunate that they don't. I think that if RFC2131 were >updated, it would be worthwhile to *require* (SHOULD) that the client send >this option, and that they send a message size that is the MTU of the >network interface being configured. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 09:08:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00602; Fri, 17 Oct 2003 09:08:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUKn-0003b9-Jq; Fri, 17 Oct 2003 09:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUKl-0003aK-G2 for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 09:07:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00579 for ; Fri, 17 Oct 2003 09:07:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUKj-0003Cq-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 09:07:57 -0400 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AAUKj-0003Cn-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 09:07:57 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9HD7jAr005160; Fri, 17 Oct 2003 09:07:53 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? Date: Fri, 17 Oct 2003 09:07:55 -0400 Message-ID: <000001c394af$b13230b0$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <4.3.2.7.2.20031017072454.04702670@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Personally, I think that if no max-message-size option is sent, the = default maximum message size should be used (512 if I recall). I believe Rob Stevens mentioned that some routers (relays) may not = support reassembly - though I personally find that hard to believe today. Though = I can more easily believe the relay function may limit the packet size it = is capable of supporting. So we really have three parties involved: 1. What can the client support? 2. What can the server support? 3. What can the relay support? The current max-message-size option addresses the first two. There is nothing that addresses the third issue and a client/server may fail to communicate if the relay doesn't support the larger messages. Perhaps we need a "relay-max-message-size" option that can override a client's max-message-size option if the relay isn't able to support the client's maximum? - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ralph Droms Sent: Friday, October 17, 2003 7:26 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow? Any reason not to allow a message size > MTU (with a strong admonition = not=20 to do so unless really, really necessary)? - Ralph At 09:54 PM 10/16/2003 -0700, Ted Lemon wrote: >In general, clients really should send max-message-size options every=20 >time. It is unfortunate that they don't. I think that if RFC2131 = were=20 >updated, it would be worthwhile to *require* (SHOULD) that the client = send=20 >this option, and that they send a message size that is the MTU of the=20 >network interface being configured. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 11:41:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07249; Fri, 17 Oct 2003 11:41:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWir-0002xq-8D; Fri, 17 Oct 2003 11:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWi8-0002wF-0K for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 11:40:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07191 for ; Fri, 17 Oct 2003 11:40:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWi6-0004jb-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 11:40:14 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AAWi6-0004jX-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 11:40:14 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9HFeA4t008142 for ; Fri, 17 Oct 2003 08:40:10 -0700 (PDT) Received: from NAEXFE01.na.qualcomm.com (naexfe01.qualcomm.com [172.30.32.17]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9HFe7Tx024463 for ; Fri, 17 Oct 2003 08:40:08 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE01.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Oct 2003 08:40:07 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 Date: Fri, 17 Oct 2003 08:40:07 -0700 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F33D1A4@NAEX01.na.qualcomm.com> Thread-Topic: DHCPv6 server and usage of link-local address of DHCPv6 client Thread-Index: AcOUxPENYju6WLGeTCO9eFfQul1Z3g== From: "Barany, Pete" To: X-OriginalArrivalTime: 17 Oct 2003 15:40:07.0687 (UTC) FILETIME=[F126F970:01C394C4] Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] DHCPv6 server and usage of link-local address of DHCPv6 client Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, Question: When a DHCPv6 server receives a request for an IA (specifically, a non-temporary IA or IA_NA) is there a default procedure in RFC 3315 such that the DHCPv6 will use the 64-bit Interface ID from the link-local address found in either the: (1) source address field of the SOLICIT message if the DHCPv6 server is on the same link as the requesting DHCPv6 client; or (2) peer-address field of the RELY-FORW message if the DHCPv6 server is on a link different from the requesting DHCPv6 client and consequently a Relay Agent is used? to construct the address(es) in response to the IA request? Regards, Pete=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 11:47:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07641; Fri, 17 Oct 2003 11:47:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWoe-0003C0-P6; Fri, 17 Oct 2003 11:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWo1-0003AY-Sl for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 11:46:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07552 for ; Fri, 17 Oct 2003 11:46:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWnz-0004pl-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 11:46:19 -0400 Received: from mail.cruzio.com ([63.249.95.37]) by ietf-mx with esmtp (Exim 4.12) id 1AAWnz-0004pf-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 11:46:19 -0400 Received: from akhnaten (dsl3-63-249-88-56.cruzio.com [63.249.88.56]) by mail.cruzio.com with ESMTP id h9HFk5O0096053; Fri, 17 Oct 2003 08:46:06 -0700 (PDT) Reply-To: From: "Rob Stevens" To: "'Ted Lemon'" , Cc: Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? Date: Fri, 17 Oct 2003 15:45:54 -0700 Message-ID: <000601c39500$6e7e3790$3858f93f@akhnaten> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C394C5.C228D570" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <7FAA557D-005E-11D8-92F5-000A95D9C74C@fugue.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C394C5.C228D570 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable No, reassembling fragments isn't at all hard. But it would require quite a few implementations to be modified (or so I believe). =20 As far as the options go, I agree with Ted. We used to do similarly. This whole question though is one where the language of 2131 is at its most contorted. I can see arguments on both sides (i.e. for only sending what a client requested, or for sending everything the server knows). Barr and I will try, in our draft, to focus the minds of the WG on that issue (among others). -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, October 16, 2003 9:58 PM To: rbhibbs@pacbell.net Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow? Reassembling fragments really isn't very hard. If a client knows it can't reassemble, it should specify the lowest legal value for MTU, but I think this is a very rare case. These clients are likely the ones that need the fewest options. And in answer to Rob's earlier question, except in cases where the parameter request list is stupid (i.e., doesn't request subnet mask), I think the DHCP server should honor it and not send options not listed in it. This is how I read RFC2131 to begin with, although I know others have read it differently. On Thursday, October 16, 2003, at 02:44 PM, Barr Hibbs wrote: The practical issue you raise is that even if the client supplies a maximum packet size, the server might format a response packet and STILL not be able to get it to the client. ------=_NextPart_000_0007_01C394C5.C228D570 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
No,=20 reassembling fragments isn't at all hard. But it would require quite a = few=20 implementations to be modified (or so I believe).
 
As far=20 as the options go, I agree with Ted. We used to do similarly. This whole = question though is one where the language of 2131 is at its most = contorted. I=20 can see arguments on both sides (i.e. for only sending what a client = requested,=20 or for sending everything the server knows). Barr and I  will try, = in our=20 draft, to focus the minds of the WG on that issue (among=20 others).
-----Original Message-----
From:=20 dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ted=20 Lemon
Sent: Thursday, October 16, 2003 9:58 PM
To: = rbhibbs@pacbell.net
Cc: dhcwg@ietf.org
Subject: = Re:=20 [dhcwg] Bit in "flags" field indicating option=20 overflow?

Reassembling fragments really isn't very = hard.=20 If a client knows it can't reassemble, it should specify the lowest = legal=20 value for MTU, but I think this is a very rare case. These clients are = likely=20 the ones that need the fewest options.

And in answer to Rob's = earlier=20 question, except in cases where the parameter request list is stupid = (i.e.,=20 doesn't request subnet mask), I think the DHCP server should honor it = and not=20 send options not listed in it. This is how I read RFC2131 to begin = with,=20 although I know others have read it differently.

On Thursday, = October=20 16, 2003, at 02:44 PM, Barr Hibbs wrote:

The practical issue you raise is that even if the = client=20 supplies a maximum
packet size, the server might format a = response packet=20 and STILL not be able
to get it to the=20 client.
------=_NextPart_000_0007_01C394C5.C228D570-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 13:20:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11215; Fri, 17 Oct 2003 13:20:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYGg-0007wu-Mz; Fri, 17 Oct 2003 13:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYGF-0007w3-3F for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 13:19:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11201 for ; Fri, 17 Oct 2003 13:19:23 -0400 (EDT) From: Patrick.Guelat@imp.ch Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYGD-0005sw-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 13:19:33 -0400 Received: from mail.imp.ch ([157.161.1.2]) by ietf-mx with esmtp (Exim 4.12) id 1AAYGC-0005st-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 13:19:32 -0400 Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id h9HHJJln001325; Fri, 17 Oct 2003 19:19:20 +0200 (CEST) (envelope-from Patrick.Guelat@imp.ch) Date: Fri, 17 Oct 2003 19:19:19 +0200 X-X-Sender: patg@nbs.imp.ch To: Bernie Volz cc: "'Ralph Droms'" , Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? In-Reply-To: <000001c394af$b13230b0$6701a8c0@BVolz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , On Fri, 17 Oct 2003, Bernie Volz wrote: > So we really have three parties involved: > 1. What can the client support? > 2. What can the server support? > 3. What can the relay support? > > The current max-message-size option addresses the first two. There is > nothing that addresses the third issue and a client/server may fail to > communicate if the relay doesn't support the larger messages. Perhaps we > need a "relay-max-message-size" option that can override a client's > max-message-size option if the relay isn't able to support the client's > maximum? Why have a special option for case 3 ? The relay may check if the client's max-message-size option is there and modify it in transit if the value is too high for the relay to handle. This option is usually not stored in the server, so the server will use the 'real' client max-message-size value in ACKs sent directly to the client and the modified one when responding through the relay. -Patrick _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 13:25:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11401; Fri, 17 Oct 2003 13:25:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYLW-0008E9-81; Fri, 17 Oct 2003 13:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYL2-0008DV-8l for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 13:24:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11346 for ; Fri, 17 Oct 2003 13:24:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYL0-0005vI-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 13:24:30 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AAYKz-0005uX-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 13:24:29 -0400 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AAYJM-0002Qt-00; Fri, 17 Oct 2003 10:22:48 -0700 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5VBFX>; Fri, 17 Oct 2003 10:22:28 -0700 Message-ID: From: "Kostur, Andre" To: "'Patrick.Guelat@imp.ch'" , Bernie Volz Cc: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? Date: Fri, 17 Oct 2003 10:22:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C394D3.38041DB0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C394D3.38041DB0 Content-Type: text/plain; charset="iso-8859-1" A relay isn't allowed to modify the packet other than the GIADDR, and possible addition of option 82 > -----Original Message----- > From: Patrick.Guelat@imp.ch [mailto:Patrick.Guelat@imp.ch] > Sent: Friday, October 17, 2003 10:19 AM > To: Bernie Volz > Cc: 'Ralph Droms'; dhcwg@ietf.org > Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? > > > On Fri, 17 Oct 2003, Bernie Volz wrote: > > > So we really have three parties involved: > > 1. What can the client support? > > 2. What can the server support? > > 3. What can the relay support? > > > > The current max-message-size option addresses the first > two. There is > > nothing that addresses the third issue and a client/server > may fail to > > communicate if the relay doesn't support the larger > messages. Perhaps we > > need a "relay-max-message-size" option that can override a client's > > max-message-size option if the relay isn't able to support > the client's > > maximum? > > Why have a special option for case 3 ? The relay may check if > the client's > max-message-size option is there and modify it in transit if the value > is too high for the relay to handle. This option is usually not stored > in the server, so the server will use the 'real' client > max-message-size > value in ACKs sent directly to the client and the modified > one when responding > through the relay. > > -Patrick > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C394D3.38041DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Bit in "flags" field indicating option = overflow?

A relay isn't allowed to modify the packet other than = the GIADDR, and possible addition of option 82

> -----Original Message-----
> From: Patrick.Guelat@imp.ch [mailto:Patrick.Guelat@imp.ch]<= /FONT>
> Sent: Friday, October 17, 2003 10:19 AM
> To: Bernie Volz
> Cc: 'Ralph Droms'; dhcwg@ietf.org
> Subject: RE: [dhcwg] Bit in "flags" = field indicating option overflow?
>
>
> On Fri, 17 Oct 2003, Bernie Volz wrote:
>
> > So we really have three parties = involved:
> > 1. What can the client support?
> > 2. What can the server support?
> > 3. What can the relay support?
> >
> > The current max-message-size option = addresses the first
> two. There is
> > nothing that addresses the third issue and = a client/server
> may fail to
> > communicate if the relay doesn't support = the larger
> messages. Perhaps we
> > need a "relay-max-message-size" = option that can override a client's
> > max-message-size option if the relay isn't = able to support
> the client's
> > maximum?
>
> Why have a special option for case 3 ? The = relay may check if
> the client's
> max-message-size option is there and modify it = in transit if the value
> is too high for the relay to handle. This = option is usually not stored
> in the server, so the server will use the = 'real' client
> max-message-size
> value in ACKs sent directly to the client and = the modified
> one when responding
> through the relay.
>
>       -Patrick
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C394D3.38041DB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 13:48:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12611; Fri, 17 Oct 2003 13:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYhl-0001Fk-6s; Fri, 17 Oct 2003 13:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYhd-0001FW-9J for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 13:47:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12589 for ; Fri, 17 Oct 2003 13:47:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYhb-0006Hv-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 13:47:51 -0400 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AAYha-0006Hs-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 13:47:50 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9HHlbGn021774; Fri, 17 Oct 2003 13:47:46 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: , "'Ted Lemon'" , Cc: Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? Date: Fri, 17 Oct 2003 13:47:48 -0400 Message-ID: <000601c394d6$cb1b44e0$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C394B5.4409A4E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <000601c39500$6e7e3790$3858f93f@akhnaten> Importance: Normal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C394B5.4409A4E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What we went for with DHCPv6 (if I recall correctly) was that the server MUST send those options that it supports from the parameter list and MAY send other options (if they fit into the packet, etc.). The only tough = case you have is what happens if the parameter list options don't fit into = the packet - which to drop or how to tell the client to use a larger packet (though I would think that if the client supported larger packets, it = should have just sent an appropriate max-message size). =20 - Bernie =20 -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Rob Stevens Sent: Friday, October 17, 2003 6:46 PM To: 'Ted Lemon'; rbhibbs@pacbell.net Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? =20 No, reassembling fragments isn't at all hard. But it would require quite = a few implementations to be modified (or so I believe). =20 As far as the options go, I agree with Ted. We used to do similarly. = This whole question though is one where the language of 2131 is at its most contorted. I can see arguments on both sides (i.e. for only sending what = a client requested, or for sending everything the server knows). Barr and = I will try, in our draft, to focus the minds of the WG on that issue = (among others). -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ted Lemon Sent: Thursday, October 16, 2003 9:58 PM To: rbhibbs@pacbell.net Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow? Reassembling fragments really isn't very hard. If a client knows it = can't reassemble, it should specify the lowest legal value for MTU, but I = think this is a very rare case. These clients are likely the ones that need = the fewest options. And in answer to Rob's earlier question, except in cases where the = parameter request list is stupid (i.e., doesn't request subnet mask), I think the = DHCP server should honor it and not send options not listed in it. This is = how I read RFC2131 to begin with, although I know others have read it = differently. On Thursday, October 16, 2003, at 02:44 PM, Barr Hibbs wrote: The practical issue you raise is that even if the client supplies a = maximum packet size, the server might format a response packet and STILL not be = able to get it to the client. ------=_NextPart_000_0007_01C394B5.4409A4E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

What we went for with DHCPv6 (if I = recall correctly) was that the server MUST send those options that it supports = from the parameter list and MAY send other options (if they fit into the = packet, etc.). The only tough case you have is what happens if the parameter = list options don’t fit into the packet – which to drop or how to = tell the client to use a larger packet (though I would think that if the = client supported larger packets, it should have just sent an appropriate = max-message size).

 

- Bernie

 

-----Original = Message-----
From: = dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On = Behalf Of Rob Stevens
Sent: Friday, October 17, = 2003 6:46 PM
To: 'Ted Lemon'; rbhibbs@pacbell.net
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Bit = in "flags" field indicating option overflow?

 

No, reassembling fragments isn't at all hard. But it would require quite a few = implementations to be modified (or so I believe).

 

As far as the = options go, I agree with Ted. We used to do similarly. This whole question though is = one where the language of 2131 is at its most contorted. I can see arguments = on both sides (i.e. for only sending what a client requested, or for = sending everything the server knows). Barr and I  will try, in our = draft, to focus the minds of the WG on that issue (among = others).

-----Original Message-----
From: = dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On = Behalf Of Ted Lemon
Sent: Thursday, October = 16, 2003 9:58 PM
To: = rbhibbs@pacbell.net
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Bit = in "flags" field indicating option overflow?

Reassembling fragments really isn't very hard. If a client knows it can't reassemble, = it should specify the lowest legal value for MTU, but I think this is a = very rare case. These clients are likely the ones that need the fewest = options.

And in answer to Rob's earlier question, except in cases where the = parameter request list is stupid (i.e., doesn't request subnet mask), I think the = DHCP server should honor it and not send options not listed in it. This is = how I read RFC2131 to begin with, although I know others have read it = differently.

On Thursday, October 16, 2003, at 02:44 PM, Barr Hibbs = wrote:

The practical issue you raise is that even if = the client supplies a maximum
packet size, the server might format a = response packet and STILL not be able
to get it to the = client.

------=_NextPart_000_0007_01C394B5.4409A4E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 13:54:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13112; Fri, 17 Oct 2003 13:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYnY-0001fR-KG; Fri, 17 Oct 2003 13:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYmr-0001bj-0p for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 13:53:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13011 for ; Fri, 17 Oct 2003 13:53:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYmo-0006Oy-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 13:53:14 -0400 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AAYmn-0006Oo-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 13:53:13 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9HHqwGn022378; Fri, 17 Oct 2003 13:53:06 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Barany, Pete'" , Subject: RE: [dhcwg] DHCPv6 server and usage of link-local address of DHCPv6 client Date: Fri, 17 Oct 2003 13:53:09 -0400 Message-ID: <000c01c394d7$89d2d100$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <17D8F6DF3ED94D40BD607380866D9B7F33D1A4@NAEX01.na.qualcomm.com> Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable How the DHCPv6 server generates the addresses it gives to clients is not addressed in the specification and is up to the DHCPv6 server. = Sequentially, random, etc can all be used (sequential probably isn't good as it is = easy to guess?). Note that the server is not specifically given the 64-bit = interface ID so it likely can not use that method. The client identifier may have information that could be used to construct the 64-bit interface ID but = that may not be for that interface (remember, a client can have many = interfaces but has ONE client identifier). The server could pull the information = from the source address (or relayed information), but that's not recommended either. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Barany, Pete Sent: Friday, October 17, 2003 11:40 AM To: dhcwg@ietf.org Subject: [dhcwg] DHCPv6 server and usage of link-local address of DHCPv6 client Hi, Question: When a DHCPv6 server receives a request for an IA (specifically, a non-temporary IA or IA_NA) is there a default procedure in RFC 3315 such that the DHCPv6 will use the 64-bit Interface ID from the link-local address found in either the: (1) source address field of the SOLICIT message if the DHCPv6 server is on the same link as the requesting DHCPv6 client; or (2) peer-address field of the RELY-FORW message if the DHCPv6 server is on a link different from the requesting DHCPv6 client and consequently a Relay Agent is used? to construct the address(es) in response to the IA request? Regards, Pete=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 13:57:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13286; Fri, 17 Oct 2003 13:57:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYqS-0001o6-J4; Fri, 17 Oct 2003 13:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAYqJ-0001ni-6S for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 13:56:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13211 for ; Fri, 17 Oct 2003 13:56:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAYqG-0006RW-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 13:56:48 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1AAYqF-0006RT-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 13:56:48 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9HHujVY011733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Oct 2003 10:56:45 -0700 (PDT) Received: from NAEXFE01.na.qualcomm.com (naexfe01.qualcomm.com [172.30.32.17]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9HHugFA001989; Fri, 17 Oct 2003 10:56:42 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE01.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 17 Oct 2003 10:56:42 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 Subject: RE: [dhcwg] DHCPv6 server and usage of link-local address of DHCPv6 client Date: Fri, 17 Oct 2003 10:56:42 -0700 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327BF7@NAEX01.na.qualcomm.com> Thread-Topic: [dhcwg] DHCPv6 server and usage of link-local address of DHCPv6 client Thread-Index: AcOU147G2gc79v+ARr+popMB9eqz4QAACT0w From: "Barany, Pete" To: "Bernie Volz" , X-OriginalArrivalTime: 17 Oct 2003 17:56:42.0671 (UTC) FILETIME=[05BE4BF0:01C394D8] Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks for the reply. I suspected as much. When a Relay Agent is used the link-address field can be used to glean the prefix. I then assume that the DHCPv6 can only assign /64 prefixes (without delving into the IPv6 architecture for global unicast addresses with 001 prefix where n+m =3D 64, see RFC 3513). In other words, the DHCPv6 server could not = assign a /70 if it wanted to? Regards, Pete -----Original Message----- From: Bernie Volz [mailto:volz@metrocast.net]=20 Sent: Friday, October 17, 2003 10:53 AM To: Barany, Pete; dhcwg@ietf.org Subject: RE: [dhcwg] DHCPv6 server and usage of link-local address of DHCPv6 client How the DHCPv6 server generates the addresses it gives to clients is not addressed in the specification and is up to the DHCPv6 server. Sequentially, random, etc can all be used (sequential probably isn't good as it is easy to guess?). Note that the server is not specifically given the 64-bit interface ID so it likely can not use that method. The client identifier may have information that could be used to construct the 64-bit interface ID but that may not be for that interface (remember, a client can have many interfaces but has ONE client identifier). The server could pull the information from the source address (or relayed information), but that's not recommended either. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Barany, Pete Sent: Friday, October 17, 2003 11:40 AM To: dhcwg@ietf.org Subject: [dhcwg] DHCPv6 server and usage of link-local address of DHCPv6 client Hi, Question: When a DHCPv6 server receives a request for an IA (specifically, a non-temporary IA or IA_NA) is there a default procedure in RFC 3315 such that the DHCPv6 will use the 64-bit Interface ID from the link-local address found in either the: (1) source address field of the SOLICIT message if the DHCPv6 server is on the same link as the requesting DHCPv6 client; or (2) peer-address field of the RELY-FORW message if the DHCPv6 server is on a link different from the requesting DHCPv6 client and consequently a Relay Agent is used? to construct the address(es) in response to the IA request? Regards, Pete=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 14:21:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14627; Fri, 17 Oct 2003 14:21:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZDh-00039i-9G; Fri, 17 Oct 2003 14:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZDH-000387-Sf for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 14:20:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14459 for ; Fri, 17 Oct 2003 14:20:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZDF-0006ou-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 14:20:33 -0400 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AAZDE-0006or-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 14:20:32 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9HIKOGn026223; Fri, 17 Oct 2003 14:20:32 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Barany, Pete'" , Subject: RE: [dhcwg] DHCPv6 server and usage of link-local address of DHCPv6 client Date: Fri, 17 Oct 2003 14:20:35 -0400 Message-ID: <000501c394db$5f0a11f0$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <17D8F6DF3ED94D40BD607380866D9B7F327BF7@NAEX01.na.qualcomm.com> Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The DHCPv6 server only assigns addresses and not prefixes (though there = is work on doing prefix delegation, see http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-prefix-dele= gat ion-05.txt). But, yes the DHCPv6 server could be given a /70 prefix from which to allocate addresses. Or, other techniques could be used, for example, if multiple servers are assigning addresses to clients from a single /64 prefix. - Bernie -----Original Message----- From: Barany, Pete [mailto:pbarany@qualcomm.com]=20 Sent: Friday, October 17, 2003 1:57 PM To: Bernie Volz; dhcwg@ietf.org Subject: RE: [dhcwg] DHCPv6 server and usage of link-local address of = DHCPv6 client Thanks for the reply. I suspected as much. When a Relay Agent is used the link-address field can be used to glean the prefix. I then assume that the DHCPv6 can only assign /64 prefixes (without delving into the IPv6 architecture for global unicast addresses with 001 prefix where n+m =3D 64, see RFC 3513). In other words, the DHCPv6 server could not = assign a /70 if it wanted to? Regards, Pete -----Original Message----- From: Bernie Volz [mailto:volz@metrocast.net]=20 Sent: Friday, October 17, 2003 10:53 AM To: Barany, Pete; dhcwg@ietf.org Subject: RE: [dhcwg] DHCPv6 server and usage of link-local address of DHCPv6 client How the DHCPv6 server generates the addresses it gives to clients is not addressed in the specification and is up to the DHCPv6 server. Sequentially, random, etc can all be used (sequential probably isn't good as it is easy to guess?). Note that the server is not specifically given the 64-bit interface ID so it likely can not use that method. The client identifier may have information that could be used to construct the 64-bit interface ID but that may not be for that interface (remember, a client can have many interfaces but has ONE client identifier). The server could pull the information from the source address (or relayed information), but that's not recommended either. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Barany, Pete Sent: Friday, October 17, 2003 11:40 AM To: dhcwg@ietf.org Subject: [dhcwg] DHCPv6 server and usage of link-local address of DHCPv6 client Hi, Question: When a DHCPv6 server receives a request for an IA (specifically, a non-temporary IA or IA_NA) is there a default procedure in RFC 3315 such that the DHCPv6 will use the 64-bit Interface ID from the link-local address found in either the: (1) source address field of the SOLICIT message if the DHCPv6 server is on the same link as the requesting DHCPv6 client; or (2) peer-address field of the RELY-FORW message if the DHCPv6 server is on a link different from the requesting DHCPv6 client and consequently a Relay Agent is used? to construct the address(es) in response to the IA request? Regards, Pete=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 15:06:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16324; Fri, 17 Oct 2003 15:06:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZvF-0004tq-VP; Fri, 17 Oct 2003 15:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAZuL-0004p6-AD for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 15:05:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16171 for ; Fri, 17 Oct 2003 15:04:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAZuI-0007CQ-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 15:05:02 -0400 Received: from mail.cruzio.com ([63.249.95.37]) by ietf-mx with esmtp (Exim 4.12) id 1AAZuH-0007CN-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 15:05:01 -0400 Received: from akhnaten (dsl3-63-249-88-56.cruzio.com [63.249.88.56]) by mail.cruzio.com with ESMTP id h9HJ4xO0047827 for ; Fri, 17 Oct 2003 12:05:00 -0700 (PDT) Reply-To: From: "Rob Stevens" To: Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? Date: Fri, 17 Oct 2003 19:04:50 -0700 Message-ID: <000001c3951c$36e90690$3858f93f@akhnaten> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <000001c394af$b13230b0$6701a8c0@BVolz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable This question about packet fragmentation goes back a long way. I think more than 6 years; Mike Carney (and it may have been made way before that by unknown others) made the point that routers are not able to simply forward the second and subsequent fragments of BOOTP/DHCP packets because those fragments don't have the destination address (yiaddr, chaddr, ciaddr whatever..) - those were in the first fragment only. Thus routers are not simply doing IP forwarding. But... we knew this already because BOOTP/DHCP relay agents are the destination IP for packets coming back from servers. So IP forwarding was never an issue. It is more like proxying. The relay agent itself is the destination for the IP unicast, so why wouldn't it do assembly? So the question is did routers, for reasons of incremental improvements in efficiency, not bother to re-assemble datagrams to port 67, and was that why this whole issue about not permitting fragmentation got started. And regardless of what as done in ancient history, what are people doing today? Possibly the concern was the fragmentation of broadcast datagrams from the client. They all have the source IP address of 0.0.0.0. So I suppose there is some (minimal) chance of collisions involving the IP datagram identification. But since clients never need to send large packets this also seems moot. Not being in the mainstream just now, I haven't the remotest idea which vendors are doing what. I wish we had a forum where we could get specific, timely answers from vendors (whatever they manufacture). -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Bernie Volz Sent: Friday, October 17, 2003 6:08 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? Personally, I think that if no max-message-size option is sent, the default maximum message size should be used (512 if I recall). I believe Rob Stevens mentioned that some routers (relays) may not support reassembly - though I personally find that hard to believe today. Though I can more easily believe the relay function may limit the packet size it is capable of supporting. So we really have three parties involved: 1. What can the client support? 2. What can the server support? 3. What can the relay support? The current max-message-size option addresses the first two. There is nothing that addresses the third issue and a client/server may fail to communicate if the relay doesn't support the larger messages. Perhaps we need a "relay-max-message-size" option that can override a client's max-message-size option if the relay isn't able to support the client's maximum? - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Friday, October 17, 2003 7:26 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow? Any reason not to allow a message size > MTU (with a strong admonition not=20 to do so unless really, really necessary)? - Ralph At 09:54 PM 10/16/2003 -0700, Ted Lemon wrote: >In general, clients really should send max-message-size options every >time. It is unfortunate that they don't. I think that if RFC2131 were=20 >updated, it would be worthwhile to *require* (SHOULD) that the client >send >this option, and that they send a message size that is the MTU of the >network interface being configured. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 17 15:34:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18169; Fri, 17 Oct 2003 15:34:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAaMK-00065Y-WA; Fri, 17 Oct 2003 15:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAaLj-000651-PG for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 15:33:23 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18071; Fri, 17 Oct 2003 15:33:14 -0400 (EDT) Message-Id: <200310171933.PAA18071@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 17 Oct 2003 15:33:13 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-subscriber-id-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Subscriber ID Suboption for the DHCP Relay Agent Option Author(s) : R. Johnson, R. Droms Filename : draft-ietf-dhc-subscriber-id-03.txt Pages : 6 Date : 2003-10-17 This memo defines a new DHCP Relay Suboption for passing an arbitrary number of bytes defining what will be called the 'Subscriber ID'. This value is simply defined as an array of bytes and can be interpreted in any form by the DHCP server. Its intended purpose is to give additional information which the DHCP server can use in address allocation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-subscriber-id-03.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-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-17123839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-subscriber-id-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-subscriber-id-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-17123839.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 18 00:01:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05518; Sat, 18 Oct 2003 00:01:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAiG2-0003dm-Ux; Sat, 18 Oct 2003 00:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAiF4-0003co-TJ for dhcwg@optimus.ietf.org; Fri, 17 Oct 2003 23:59:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05325 for ; Fri, 17 Oct 2003 23:58:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAiEy-00053x-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 23:58:56 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AAiEy-00053u-00 for dhcwg@ietf.org; Fri, 17 Oct 2003 23:58:56 -0400 Received: from fugue.com (m698e36d0.tmodns.net [208.54.142.105]) by toccata.fugue.com (Postfix) with ESMTP id EE83E1B2010; Fri, 17 Oct 2003 22:55:53 -0500 (CDT) Date: Fri, 17 Oct 2003 20:58:56 -0700 Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow? Content-Type: multipart/alternative; boundary=Apple-Mail-2-95506546 Mime-Version: 1.0 (Apple Message framework v552) Cc: , "'Ralph Droms'" To: "Bernie Volz" From: Ted Lemon In-Reply-To: <000001c394af$b13230b0$6701a8c0@BVolz> Message-Id: <6530AECA-011F-11D8-B14E-000A95D9C74C@fugue.com> X-Mailer: Apple Mail (2.552) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Apple-Mail-2-95506546 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Friday, October 17, 2003, at 06:07 AM, Bernie Volz wrote: > The current max-message-size option addresses the first two. There is > nothing that addresses the third issue and a client/server may fail to > communicate if the relay doesn't support the larger messages. Perhaps > we > need a "relay-max-message-size" option that can override a client's > max-message-size option if the relay isn't able to support the client's > maximum? Good point. Unfortunately, relay agents that support this option would be new relay agents, which could probably also support packet reassembly. --Apple-Mail-2-95506546 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Friday, October 17, 2003, at 06:07 AM, Bernie Volz wrote: The current max-message-size option addresses the first two. There is nothing that addresses the third issue and a client/server may fail to communicate if the relay doesn't support the larger messages. Perhaps we need a "relay-max-message-size" option that can override a client's max-message-size option if the relay isn't able to support the client's maximum? Good point. Unfortunately, relay agents that support this option would be new relay agents, which could probably also support packet reassembly. --Apple-Mail-2-95506546-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 18 00:07:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05943; Sat, 18 Oct 2003 00:07:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAiMr-0003vU-Tr; Sat, 18 Oct 2003 00:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAiLv-0003t5-0M for dhcwg@optimus.ietf.org; Sat, 18 Oct 2003 00:06:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05857 for ; Sat, 18 Oct 2003 00:05:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAiLs-0005Ao-00 for dhcwg@ietf.org; Sat, 18 Oct 2003 00:06:04 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AAiLr-0005Aj-00 for dhcwg@ietf.org; Sat, 18 Oct 2003 00:06:03 -0400 Received: from fugue.com (m698e36d0.tmodns.net [208.54.142.105]) by toccata.fugue.com (Postfix) with ESMTP id 2C8D21B2134; Fri, 17 Oct 2003 23:03:01 -0500 (CDT) Date: Fri, 17 Oct 2003 21:06:03 -0700 Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow? Content-Type: multipart/alternative; boundary=Apple-Mail-4-95933948 Mime-Version: 1.0 (Apple Message framework v552) Cc: To: From: Ted Lemon In-Reply-To: <000001c3951c$36e90690$3858f93f@akhnaten> Message-Id: <63F107AA-0120-11D8-B14E-000A95D9C74C@fugue.com> X-Mailer: Apple Mail (2.552) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Apple-Mail-4-95933948 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Friday, October 17, 2003, at 07:04 PM, Rob Stevens wrote: > Not being in the mainstream just now, I haven't the remotest idea > which vendors are doing what. I wish we had a forum where we could get > specific, timely answers from vendors (whatever they manufacture). I seem to recall that Cisco had a weird way of doing relay that looked like a layering violation, but I don't know if it actually was a layering violation or just looked like it might be one. Unfortunately, I think it is likely that many relay agents have a layering violation in this case. And yes, we all wish there was such a forum. And if wishes were horses, there'd be a lot of pollution in the streets... :'} --Apple-Mail-4-95933948 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Friday, October 17, 2003, at 07:04 PM, Rob Stevens wrote: Not being in the mainstream just now, I haven't the remotest idea which vendors are doing what. I wish we had a forum where we could get specific, timely answers from vendors (whatever they manufacture). I seem to recall that Cisco had a weird way of doing relay that looked like a layering violation, but I don't know if it actually was a layering violation or just looked like it might be one. Unfortunately, I think it is likely that many relay agents have a layering violation in this case. And yes, we all wish there was such a forum. And if wishes were horses, there'd be a lot of pollution in the streets... :'} --Apple-Mail-4-95933948-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 06:27:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20131; Mon, 20 Oct 2003 06:27:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXFd-0003Tp-QH; Mon, 20 Oct 2003 06:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABXFb-0003TY-M8 for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 06:26:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20066 for ; Mon, 20 Oct 2003 06:26:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABXFX-0006Su-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 06:26:55 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ABXFW-0006Sf-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 06:26:55 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9KAQNeu017161 for ; Mon, 20 Oct 2003 03:26:23 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn1-152.cisco.com [10.82.224.152]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADH16388; Mon, 20 Oct 2003 06:26:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20031020060751.04764c40@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Oct 2003 06:26:18 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-mipadvert-opt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Comment on draft-ietf-dhc-mipadvert-opt-01.txt: What are the precise rules for sending and receiving these options? In which messages does a client or a server send these options? For example: * The client MAY include the Network Access Identifier sub-option in a DHCPDISCOVER message * The server MUST include the Network Access Identifier sub-option from the client in a DHCPDISCOVER message (always? only if the server used the sub-option in selecting client parameters?) * The client MUST include thje Network Access Identifier sub-option in a DHCPREQUEST message if it included it in the DHCPDISCOVER message * The server MUST include the Network Access Identifier sub-option in a DHCPACK message Can these sub-options be used in DHCPINFORM messages? In section 6, add a request to IANA to maintain a registry for the sub-options in this option. See the IANA considerations of RFC 3315 for an example of such a request. Nits: In the first sentence of the section "Status of this Memo", change "in full conformance with" to "subject to", in accordance with "Guidelines to Authors of Internet-Drafts" (1id-guidelines.txt). In the fourth paragraph of the section "Status of this Memo", reformat to avoid breaking "http://www.ietf.org/ietf/1id-abstracts.txt" across two lines. In the Abstract, delete "new" in the first sentence. If this option applies only to IPv4, mention it in the "Introdcution". It might be good to mention RFC 2131 in the "Introduction", too. Separate section "2 Terminology" into "2.1 Requirements Terminology" and "2.2 Mobile IP Terminology". A reference to terminology in RFC 2131 might be appropriate, too. In section 3.3, under the format of the Mobility Agent Accouncement sub-option, in list entry "Agent IP Address", change "trough" to "through". In the same list, is the entry "Reserved-0" needed? I don't see a field labeled "Reserved-0". Mention somewhere in the draft that discussion about the draft should be sent to dhcwg@ietf.org. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 08:34:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23504; Mon, 20 Oct 2003 08:34:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZEZ-0002vN-U6; Mon, 20 Oct 2003 08:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZEF-0002rY-3v for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 08:33:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23445 for ; Mon, 20 Oct 2003 08:33:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABZED-0007US-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 08:33:41 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ABZED-0007UM-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 08:33:41 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9KCX8FH018396; Mon, 20 Oct 2003 08:33:08 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADH25173; Mon, 20 Oct 2003 08:33:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20031020082227.01e81638@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Oct 2003 08:33:02 -0400 To: dhcwg@ietf.org From: Ralph Droms Cc: michael.johnston@intel.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-pxe-options-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Comments on draft-ietf-dhc-pxe-options-00.txt: I agree with Bernie Volz - the title should be changed to "DHCP Preboot eXecution Environment (PXE) Options", and the "suboption" should be replaced with "option" throughout the document. The document needs an "IANA Considerations" section, asking IANA to record the subtypes for options 93, 94 and 97. There should also be a description of how new subtypes will be defined in the future. In which messages do clients and servers send these options? Nits: I don't think it's necessary to make section 2.1.1. "Client System Architecture Types" into a separate subsection; the list could simply be merged with section 2.1. The document needs a Security Considerations section. Add a sentence: "Comments about this Internet Draft should be sent to the dhcwg@ietf.org mailing list." _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 08:48:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23945; Mon, 20 Oct 2003 08:48:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZS6-0006cT-GQ; Mon, 20 Oct 2003 08:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZRY-0006M1-UQ for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 08:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23879 for ; Mon, 20 Oct 2003 08:47:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABZRX-0007ak-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 08:47:27 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ABZRX-0007aW-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 08:47:27 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2003 05:47:27 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9KCksjP005713 for ; Mon, 20 Oct 2003 05:46:54 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADH26423; Mon, 20 Oct 2003 08:46:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20031020060751.04764c40@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Oct 2003 06:28:12 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-mipadvert-opt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Comment on draft-ietf-dhc-mipadvert-opt-01.txt: What are the precise rules for sending and receiving these options? In which messages does a client or a server send these options? For example: * The client MAY include the Network Access Identifier sub-option in a DHCPDISCOVER message * The server MUST include the Network Access Identifier sub-option from the client in a DHCPDISCOVER message (always? only if the server used the sub-option in selecting client parameters?) * The client MUST include thje Network Access Identifier sub-option in a DHCPREQUEST message if it included it in the DHCPDISCOVER message * The server MUST include the Network Access Identifier sub-option in a DHCPACK message Can these sub-options be used in DHCPINFORM messages? In section 6, add a request to IANA to maintain a registry for the sub-options in this option. See the IANA considerations of RFC 3315 for an example of such a request. Nits: In the first sentence of the section "Status of this Memo", change "in full conformance with" to "subject to", in accordance with "Guidelines to Authors of Internet-Drafts" (1id-guidelines.txt). In the fourth paragraph of the section "Status of this Memo", reformat to avoid breaking "http://www.ietf.org/ietf/1id-abstracts.txt" across two lines. In the Abstract, delete "new" in the first sentence. If this option applies only to IPv4, mention it in the "Introdcution". It might be good to mention RFC 2131 in the "Introduction", too. Separate section "2 Terminology" into "2.1 Requirements Terminology" and "2.2 Mobile IP Terminology". A reference to terminology in RFC 2131 might be appropriate, too. In section 3.3, under the format of the Mobility Agent Accouncement sub-option, in list entry "Agent IP Address", change "trough" to "through". In the same list, is the entry "Reserved-0" needed? I don't see a field labeled "Reserved-0". Mention somewhere in the draft that discussion about the draft should be sent to dhcwg@ietf.org. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 08:48:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23944; Mon, 20 Oct 2003 08:48:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZS7-0006dA-Rw; Mon, 20 Oct 2003 08:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABZRZ-0006Mq-Ju for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 08:47:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23882 for ; Mon, 20 Oct 2003 08:47:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABZRY-0007ap-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 08:47:28 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ABZRX-0007aW-01 for dhcwg@ietf.org; Mon, 20 Oct 2003 08:47:27 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2003 05:47:29 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9KCktjP005720; Mon, 20 Oct 2003 05:46:55 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADH26424; Mon, 20 Oct 2003 08:46:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20031020082227.01e81638@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Oct 2003 08:33:12 -0400 To: dhcwg@ietf.org From: Ralph Droms Cc: michael.johnston@intel.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-pxe-options-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Comments on draft-ietf-dhc-pxe-options-00.txt: I agree with Bernie Volz - the title should be changed to "DHCP Preboot eXecution Environment (PXE) Options", and the "suboption" should be replaced with "option" throughout the document. The document needs an "IANA Considerations" section, asking IANA to record the subtypes for options 93, 94 and 97. There should also be a description of how new subtypes will be defined in the future. In which messages do clients and servers send these options? Nits: I don't think it's necessary to make section 2.1.1. "Client System Architecture Types" into a separate subsection; the list could simply be merged with section 2.1. The document needs a Security Considerations section. Add a sentence: "Comments about this Internet Draft should be sent to the dhcwg@ietf.org mailing list." _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 13:22:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04463; Mon, 20 Oct 2003 13:22:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdjF-0000sX-9Z; Mon, 20 Oct 2003 13:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdiZ-0000kz-Uq for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 13:21:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04443 for ; Mon, 20 Oct 2003 13:21:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdiU-0002Tf-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 13:21:14 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ABdiU-0002TF-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 13:21:14 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9KHKfjP000061 for ; Mon, 20 Oct 2003 10:20:42 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADH56841; Mon, 20 Oct 2003 13:20:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20031020131148.01e7eb38@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Oct 2003 13:20:38 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-agentopt-radius-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , In the interests of due diligence, here are my comments on draft-ietf-dhc-agentopt-radius-03.txt (which I co-authored with John Schnizlein): Question: Does the server return the RADIUS Attributes Sub-option (containing the contents originally sent by the relay agent) in its response message? Nits: In section "Status of this Memo", avoid breaking URLs across lines (anyone got a fix for this problem in xml2rfc?) In the Introduction, the labels (and there should only be one label) on Figure 1 is at the top of page 3. In section 2.3, fix formatting of RADIUS terminology list. In section 3, first sentence, delete "new". In section 5, first sentence, replace "an relay" with "a relay". Add a sentence before the References giving dhcwg@ietf.org as mailing list for comments. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 13:37:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05122; Mon, 20 Oct 2003 13:37:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdxl-00042s-EZ; Mon, 20 Oct 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdx7-0003pa-Nz for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 13:36:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05052 for ; Mon, 20 Oct 2003 13:36:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdx5-0002fe-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 13:36:19 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ABdx5-0002f9-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 13:36:19 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2003 10:36:22 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9KHZkQY028737 for ; Mon, 20 Oct 2003 10:35:46 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADH58565; Mon, 20 Oct 2003 13:35:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20031020133241.00b52fb8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Oct 2003 13:35:43 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-v4-threat-analysis-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I don't have any substantive comments about draft-ietf-dhc-v4-threat-analysis-00.txt. There have been no other comments about the document posted to the mailing list. If you have any comments, post them by the end of the last call (Friday, Oct. 24). If you approve of the document without change, respond with a simple acknowledgment so I can gauge the amount of review and approval for this document. If there are too few responses to this last call, the document *will not* be submitted to the IESG for publication. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 15:19:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14561; Mon, 20 Oct 2003 15:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfYT-0001KV-CF; Mon, 20 Oct 2003 15:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfXm-0001Cf-Th for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 15:18:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14126 for ; Mon, 20 Oct 2003 15:18:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfXl-0004HO-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 15:18:17 -0400 Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx with esmtp (Exim 4.12) id 1ABfXk-0004FX-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 15:18:16 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9KJHkIl497086 for ; Mon, 20 Oct 2003 15:17:46 -0400 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9KJHiRk078610 for ; Mon, 20 Oct 2003 13:17:44 -0600 Received: from login-2.austin.ibm.com (login-2.austin.ibm.com [9.41.248.166]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id h9KJHhEs039220 for ; Mon, 20 Oct 2003 14:17:43 -0500 Received: from austin.ibm.com (vallab.austin.ibm.com [9.41.86.83]) by login-2.austin.ibm.com (AIX4.3/8.9.3p2/8.7-client1.01) with ESMTP id OAA38998 for ; Mon, 20 Oct 2003 14:12:56 -0500 Message-ID: <3F9434BB.3819109C@austin.ibm.com> Date: Mon, 20 Oct 2003 14:17:15 -0500 From: "Vasu, Vallabhaneni" Organization: IBM X-Mailer: Mozilla 4.79 [en] (X11; U; AIX 5.1) X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] RFC 3315 DUID-EN Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As per the RFC 3315 Sec 9.3 DUID-EN is defined as below [ Type (16bits)][ Enterprise-Number (32 bits)][ identifier (variable length)] How will server code know what is the length of identifier field ? Thanks Vasu Vallabhaneni _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 15:29:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17379; Mon, 20 Oct 2003 15:29:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfi9-0004kJ-IK; Mon, 20 Oct 2003 15:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfha-0004Yt-OC for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 15:28:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17050 for ; Mon, 20 Oct 2003 15:28:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfhZ-0004kn-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 15:28:25 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1ABfhY-0004kg-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 15:28:24 -0400 Received: (qmail 31294 invoked from network); 20 Oct 2003 19:28:22 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 20 Oct 2003 19:28:22 -0000 Date: Mon, 20 Oct 2003 21:28:20 +0200 From: Henrik Levkowetz To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: WG last call on draft-ietf-dhc-mipadvert-opt-01.txt Message-Id: <20031020212820.2395bbb4.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20031020060751.04764c40@flask.cisco.com> References: <4.3.2.7.2.20031020060751.04764c40@flask.cisco.com> X-Mailer: Sylpheed version 0.9.5claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Multipart_Mon__20_Oct_2003_21_28_21_+0200_JL=.nGqHtU+MuX(+" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Multipart_Mon__20_Oct_2003_21_28_21_+0200_JL=.nGqHtU+MuX(+ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Thanks for the review, Ralph. These seems to be good points, all of them. I'm aiming to have a new draft version fixing these and the points mentioned by Kuntal out by the end of the week. Comments to the individual points below. Henrik Monday 20 October 2003, Ralph wrote: > Comment on draft-ietf-dhc-mipadvert-opt-01.txt: > > What are the precise rules for sending and receiving these options? In > which messages does a client or a server send these options? For example: > > * The client MAY include the Network Access Identifier sub-option in a > DHCPDISCOVER message > * The server MUST include the Network Access Identifier sub-option from > the client in a DHCPDISCOVER message (always? only if the server used > the sub-option in selecting client parameters?) > * The client MUST include the Network Access Identifier sub-option in a > DHCPREQUEST message if it included it in the DHCPDISCOVER message > * The server MUST include the Network Access Identifier sub-option in a > DHCPACK message Right. This should be covered, and not only for the Network Access Identifier sub-option, but for all of them. For the NAI sub-option, I think that for the above four sample points, the appropriate choices are a - spot on b - only if nai used by server (though I think you mean DHCPOFFER here, not DHCPDISCOVER) c - spot on d - don't know; I'd say yes but I'm not sure about tradeoffs and practice > > Can these sub-options be used in DHCPINFORM messages? NAI sub-option yes, advertisement sub-options no. Will clarify. > In section 6, add a request to IANA to maintain a registry for the > sub-options in this option. See the IANA considerations of RFC 3315 for an > example of such a request. Right. > > Nits: > > In the first sentence of the section "Status of this Memo", change "in full > conformance with" to "subject to", in accordance with "Guidelines to Authors > of Internet-Drafts" (1id-guidelines.txt). Ok. Should be fixed automatically when I use the most recent xml2rfc version to generate the text file, but I'll check it. > In the fourth paragraph of the section "Status of this Memo", reformat to > avoid breaking "http://www.ietf.org/ietf/1id-abstracts.txt" across two lines. Ok. > In the Abstract, delete "new" in the first sentence. Ok. > If this option applies only to IPv4, mention it in the "Introdcution". It > might be good to mention RFC 2131 in the "Introduction", too. Although no MIPv6 suboptions are defined here, I think it would make sense to permit that. I'll add a note about that. > Separate section "2 Terminology" into "2.1 Requirements Terminology" and > "2.2 Mobile IP Terminology". A reference to terminology in RFC 2131 might > be appropriate, too. Ok. > In section 3.3, under the format of the Mobility Agent Accouncement > sub-option, in list entry "Agent IP Address", change "trough" to "through". (Blush) One of my recurring misspellings. And the spellcheckers don't catch it. > In the same list, is the entry "Reserved-0" needed? I don't see a field > labeled "Reserved-0". Right. > Mention somewhere in the draft that discussion about the draft should be > sent to dhcwg@ietf.org. Ok. I'll add chair address too. Henrik --Multipart_Mon__20_Oct_2003_21_28_21_+0200_JL=.nGqHtU+MuX(+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/lDdWeVhrtTJkXCMRAis+AJ43HNpr3TLHv2hcr2Nb2l/dmnPnTQCglRog EWWY7TZOkq6E1QQWpFqkfSk= =SA5p -----END PGP SIGNATURE----- --Multipart_Mon__20_Oct_2003_21_28_21_+0200_JL=.nGqHtU+MuX(+-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 17:02:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05085; Mon, 20 Oct 2003 17:02:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABhA9-0003CH-Q8; Mon, 20 Oct 2003 17:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABh9D-0002qT-NP for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 17:01:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04995 for ; Mon, 20 Oct 2003 17:00:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABh9B-0000UL-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 17:01:01 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ABh9A-0000Te-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 17:01:01 -0400 Received: from fugue.com (m698e36d0.tmodns.net [208.54.142.105]) by toccata.fugue.com (Postfix) with ESMTP id C49781B226F; Mon, 20 Oct 2003 15:57:17 -0500 (CDT) Date: Mon, 20 Oct 2003 14:00:50 -0700 Subject: Re: [dhcwg] RFC 3315 DUID-EN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org To: "Vasu, Vallabhaneni" From: Ted Lemon In-Reply-To: <3F9434BB.3819109C@austin.ibm.com> Message-Id: <7C1C0D29-0340-11D8-BAD4-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Monday, October 20, 2003, at 12:17 PM, Vasu, Vallabhaneni wrote: > How will server code know what is the length of identifier field ? RFC3315 says specifically that the server shouldn't be poking around in the guts of the DUID. The length is just what's left over in the buffer after the DUID type and Enterprise Number fields have been accounted for. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 17:18:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05811; Mon, 20 Oct 2003 17:18:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABhPd-000823-9T; Mon, 20 Oct 2003 17:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABhP3-0007pq-Ku for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 17:17:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05787 for ; Mon, 20 Oct 2003 17:17:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABhP1-0000n6-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 17:17:23 -0400 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1ABhP0-0000mz-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 17:17:22 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9KLG0Ar035352; Mon, 20 Oct 2003 17:16:08 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Vasu, Vallabhaneni'" , Subject: RE: [dhcwg] RFC 3315 DUID-EN Date: Mon, 20 Oct 2003 17:16:16 -0400 Message-ID: <000701c3974f$68ded370$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3F9434BB.3819109C@austin.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The length is determined by the length of the client identifier or = server identifier option. Since this is the only variable piece of the DUID-EN, = the length of the identifier is the option length - 2 - 4. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Vasu, Vallabhaneni Sent: Monday, October 20, 2003 3:17 PM To: dhcwg@ietf.org Subject: [dhcwg] RFC 3315 DUID-EN As per the RFC 3315 Sec 9.3 DUID-EN is defined as below [ Type (16bits)][ Enterprise-Number (32 bits)][ identifier (variable length)] How will server code know what is the length of identifier field ? Thanks Vasu Vallabhaneni _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 17:21:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05938; Mon, 20 Oct 2003 17:21:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABhSX-0000kQ-VF; Mon, 20 Oct 2003 17:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABhRy-0000W2-U7 for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 17:20:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05918 for ; Mon, 20 Oct 2003 17:20:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABhRw-0000p6-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 17:20:24 -0400 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1ABhRv-0000p3-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 17:20:24 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9KLJuGn092383; Mon, 20 Oct 2003 17:19:59 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Re: WG last call on draft-ietf-dhc-v4-threat-analysis-00.txt Date: Mon, 20 Oct 2003 17:20:12 -0400 Message-ID: <000f01c3974f$f26d5d50$6701a8c0@BVolz> 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.4510 In-Reply-To: <4.3.2.7.2.20031020133241.00b52fb8@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I would like to see this document move forward (though as one of the authors, I'm not sure how much weight this carries and whether it even counts). - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Monday, October 20, 2003 1:36 PM To: dhcwg@ietf.org Subject: [dhcwg] Re: WG last call on draft-ietf-dhc-v4-threat-analysis-00.txt I don't have any substantive comments about draft-ietf-dhc-v4-threat-analysis-00.txt. There have been no other comments about the document posted to the mailing list. If you have any comments, post them by the end of the last call (Friday, Oct. 24). If you approve of the document without change, respond with a simple acknowledgment so I can gauge the amount of review and approval for this document. If there are too few responses to this last call, the document *will not* be submitted to the IESG for publication. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 19:50:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14893; Mon, 20 Oct 2003 19:50:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABjmk-0003Mf-70; Mon, 20 Oct 2003 19:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABjmS-0003Ed-C0 for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 19:49:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14866 for ; Mon, 20 Oct 2003 19:49:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABjmQ-0003jF-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 19:49:42 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1ABjmP-0003j6-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 19:49:41 -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 <0HN200169Y5Y3Z@mailout2.samsung.com> for dhcwg@ietf.org; Tue, 21 Oct 2003 08:49:10 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HN2000W5Y48KP@mailout2.samsung.com> for dhcwg@ietf.org; Tue, 21 Oct 2003 08:48:08 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HN2000AKY47X7@mmp2.samsung.com> for dhcwg@ietf.org; Tue, 21 Oct 2003 08:48:07 +0900 (KST) Date: Tue, 21 Oct 2003 08:48:24 +0900 From: Soohong Daniel Park To: dhcwg@ietf.org Message-id: <011601c39764$a6e9cd90$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/mixed; boundary="Boundary_(ID_nIj6HkKxZiZCS2iuUjh7Lw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_nIj6HkKxZiZCS2iuUjh7Lw) Content-type: multipart/alternative; boundary="Boundary_(ID_mrGUiYNou5SmgZKjvf+oAg)" --Boundary_(ID_mrGUiYNou5SmgZKjvf+oAg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hello dhc Please see the "Rapid Reply Option for DHCPv4" I-D announcement below... Abstract This document defines a new option, modeled on the IPv6 option for getting IP address and configuration information rapidly which can be used for detecting network attachment when client moves to a new link. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: owner-ietf-announce@ietf.org > [mailto:owner-ietf-announce@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Tuesday, October 21, 2003 4:43 AM > To: IETF-Announce: > Subject: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Rapid Reply Option for DHCPv4 > Author(s) : S. Park, et. al. > Filename : draft-volz-dhc-rapidreply-opt-00.txt > Pages : 7 > Date : 2003-10-20 > > This document defines a new option, modeled on the IPv6 option for > getting IP address and configuration information rapidly which can > be used for detecting network attachment when client moves to a new > link. > > A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-volz-dhc-rapidreply-opt-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-volz-dhc-rapidreply-opt-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-volz-dhc-rapidreply-opt-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. --Boundary_(ID_mrGUiYNou5SmgZKjvf+oAg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT 메시지

Hello dhc

Please see the "Rapid Reply Option for DHCPv4" I-D
announcement below...

Abstract
  
This document defines a new option, modeled on the IPv6 option for
getting IP address and configuration information rapidly which can
be used for detecting network attachment when client moves to a new
link.




Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics

> -----Original Message-----
> From: owner-ietf-announce@ietf.org
> [mailto:owner-ietf-announce@ietf.org] On Behalf Of
> Internet-Drafts@ietf.org
> Sent: Tuesday, October 21, 2003 4:43 AM
> To: IETF-Announce:
> Subject: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt
>
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
>       Title           : Rapid Reply Option for DHCPv4
>       Author(s)       : S. Park, et. al.
>       Filename        : draft-volz-dhc-rapidreply-opt-00.txt
>       Pages           : 7
>       Date            : 2003-10-20
>      
> This document defines a new option, modeled on the IPv6 option for
> getting IP address and configuration information rapidly which can
> be used for detecting network attachment when client moves to a new
> link.
>
> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-volz-dhc-rapidreply-opt-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then
        "get draft-volz-dhc-rapidreply-opt-00.txt".

A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-volz-dhc-rapidreply-opt-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.

--Boundary_(ID_mrGUiYNou5SmgZKjvf+oAg)-- --Boundary_(ID_nIj6HkKxZiZCS2iuUjh7Lw) Content-type: Message/External-body; name=ATT00156.dat Content-transfer-encoding: 7bit Content-disposition: attachment; filename=ATT00156.dat Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-20144943.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-volz-dhc-rapidreply-opt-00.txt --Boundary_(ID_nIj6HkKxZiZCS2iuUjh7Lw) Content-type: Message/External-body; name=draft-volz-dhc-rapidreply-opt-00.txt Content-transfer-encoding: 7bit Content-disposition: attachment; filename=draft-volz-dhc-rapidreply-opt-00.txt Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2003-10-20144943.I-D@ietf.org> --Boundary_(ID_nIj6HkKxZiZCS2iuUjh7Lw)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 21:30:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18272; Mon, 20 Oct 2003 21:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABlLX-0001vZ-Pj; Mon, 20 Oct 2003 21:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcl1-0004WW-GA for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 12:19:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02563 for ; Mon, 20 Oct 2003 12:19:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABckz-0001yi-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 12:19:45 -0400 Received: from bay1-f97.bay1.hotmail.com ([65.54.245.97] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ABckz-0001yQ-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 12:19:45 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 20 Oct 2003 09:19:14 -0700 Received: from 12.153.34.50 by by1fd.bay1.hotmail.msn.com with HTTP; Mon, 20 Oct 2003 16:19:13 GMT X-Originating-IP: [12.153.34.50] X-Originating-Email: [huma_hakim@hotmail.com] From: "Huma Hakim" To: dhcwg@ietf.org Date: Mon, 20 Oct 2003 16:19:13 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Oct 2003 16:19:14.0382 (UTC) FILETIME=[E72176E0:01C39725] Subject: [dhcwg] Realy Agent Response to Client Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hello, In sending a response message back to the client, if the broadcast flag is not set the message needs to be sent as a unicast to the yiaddr IP and the chaddr link layer address. How can one specify the MAc address in an outgoing message? In my system all I can specify is the IP layer Destination Address. Also which process in the Client looks at each message and compares the MAC address with its own to realise that this yiaddr is meant for it? Would apprciate your response to my questions. Thank You Huma _________________________________________________________________ Surf and talk on the phone at the same time with broadband Internet access. Get high-speed for as low as $29.95/month (depending on the local service providers in your area). https://broadband.msn.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 20 21:30:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18270; Mon, 20 Oct 2003 21:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABlLW-0001us-Q1; Mon, 20 Oct 2003 21:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABbL5-0006XA-Oy for dhcwg@optimus.ietf.org; Mon, 20 Oct 2003 10:48:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29381 for ; Mon, 20 Oct 2003 10:48:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABbL1-00010r-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 10:48:51 -0400 Received: from bay1-f81.bay1.hotmail.com ([65.54.245.81] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ABbL1-00010Y-00 for dhcwg@ietf.org; Mon, 20 Oct 2003 10:48:51 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 20 Oct 2003 07:48:14 -0700 Received: from 12.153.34.50 by by1fd.bay1.hotmail.msn.com with HTTP; Mon, 20 Oct 2003 14:48:12 GMT X-Originating-IP: [12.153.34.50] X-Originating-Email: [huma_hakim@hotmail.com] From: "Huma Hakim" To: dhcwg@ietf.org Date: Mon, 20 Oct 2003 14:48:12 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Oct 2003 14:48:14.0781 (UTC) FILETIME=[30F476D0:01C39719] Subject: [dhcwg] Realy Agent Response to Client Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hello, In sending a response message back to the client, if the broadcast flag is not set the message needs to be sent as a unicast to the yiaddr IP and the chaddr link layer address. How can one specify the MAc address in an outgoing message? In my system all I can specify is the IP layer Destination Address. Also which process in the Client looks at each message and compares the MAC address with its own to realise that this yiaddr is meant for it? Would apprciate your response to my questions. Thank You Huma _________________________________________________________________ Get a FREE computer virus scan online from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 21 08:36:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15559; Tue, 21 Oct 2003 08:36:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvk8-0004w7-4K; Tue, 21 Oct 2003 08:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABvjU-0004nK-Qu for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 08:35:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15520 for ; Tue, 21 Oct 2003 08:35:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABvjT-00030Z-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 08:35:27 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ABvjS-00030F-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 08:35:27 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Oct 2003 05:35:39 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9LCYrQY025283 for ; Tue, 21 Oct 2003 05:34:54 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-232.cisco.com [10.82.240.232]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADI18593; Tue, 21 Oct 2003 08:34:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20031021083132.04816730@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Oct 2003 08:34:42 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "DHCP Lease Query" . The last call will conclude at 5PM ET on Friday, 10/31/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. This document defines new messages through which devices can communicate with a DHCP server. A DHCP server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Other processes and devices, many that already send and receive DHCP format packets, sometimes need to access this information. The leasequery protocol is designed to give these processes and devices a lightweight way to access information that may be critical to their operation. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-05.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 21 09:37:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16992; Tue, 21 Oct 2003 09:37:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwh4-00048c-Ii; Tue, 21 Oct 2003 09:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABwh2-00047r-Aw for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 09:37:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16978 for ; Tue, 21 Oct 2003 09:36:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABwh0-0003RD-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 09:36:58 -0400 Received: from mail.hirschmann.de ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1ABwgu-0003Qw-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 09:36:52 -0400 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119051>; Tue, 21 Oct 2003 15:30:54 +0200 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Tue, 21 Oct 2003 15:33:28 +0200 Message-ID: From: "Rentschler, Markus" To: dhcwg@ietf.org Cc: Soohong Daniel Park Subject: AW: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Tue, 21 Oct 2003 15:33:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello, wouldn't it be better to reserve a bit in the "flags" field for that = purpose ? Regards, Markus Rentschler Hirschmann Electronics GmbH & Co. KG =20 > -----Urspr=FCngliche Nachricht----- > Von: Soohong Daniel Park [SMTP:soohong.park@samsung.com] > Gesendet am: Dienstag, 21. Oktober 2003 01:48 > An: dhcwg@ietf.org > Betreff: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt >=20 > Hello dhc >=20 > Please see the "Rapid Reply Option for DHCPv4" I-D > announcement below... >=20 > Abstract > =20 > This document defines a new option, modeled on the IPv6 option for > getting IP address and configuration information rapidly which can > be used for detecting network attachment when client moves to a new > link. >=20 >=20 >=20 >=20 > Regards >=20 > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics >=20 > > -----Original Message----- > > From: owner-ietf-announce@ietf.org > > [ ] On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Tuesday, October 21, 2003 4:43 AM > > To: IETF-Announce: > > Subject: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Rapid Reply Option for DHCPv4 > > Author(s) : S. Park, et. al. > > Filename : draft-volz-dhc-rapidreply-opt-00.txt > > Pages : 7 > > Date : 2003-10-20 > > =20 > > This document defines a new option, modeled on the IPv6 option for > > getting IP address and configuration information rapidly which can > > be used for detecting network attachment when client moves to a new > > link. > > > > A URL for this Internet-Draft is: > = >=20 > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After = logging > in, type "cd internet-drafts" and then > "get draft-volz-dhc-rapidreply-opt-00.txt". >=20 > A list of Internet-Drafts directories can be found in > > or >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-volz-dhc-rapidreply-opt-00.txt". > =20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" = or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been = split > up into multiple messages), so check your local documentation = on > how to manipulate these messages. > =20 > =20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > << Datei: ATT00156.txt >> << Datei: = draft-volz-dhc-rapidreply-opt-00.txt > >>=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 21 12:21:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25193; Tue, 21 Oct 2003 12:21:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABzFm-0006wo-3T; Tue, 21 Oct 2003 12:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABzFi-0006w2-LH for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 12:20:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25157 for ; Tue, 21 Oct 2003 12:20:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABzFh-0005cM-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 12:20:57 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ABzFg-0005c8-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 12:20:56 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2003 09:17:24 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9LGKMjP027499; Tue, 21 Oct 2003 09:20:23 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-232.cisco.com [10.82.240.232]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADI40719; Tue, 21 Oct 2003 12:20:20 -0400 (EDT) Message-Id: <4.3.2.7.2.20031021121740.048735d0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Oct 2003 12:20:17 -0400 To: From: Ralph Droms Subject: RE: [dhcwg] AD Review: draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Cc: , , In-Reply-To: <000401c38c40$3af4e770$38e62a0f@nt23056> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Seems to me we are closer to consensus on publishing the option for (S)NTP servers than we are for the timezone configuration option. Vijay, I suggest you split your current draft into two drafts, one for the (S)NTP servers option (call it draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt if you can publish it this week) and a new draft for the timezone option. With two documents, we can let each option proceed at its own pace... - Ralph At 12:59 AM 10/7/2003 +0530, Vijayabhaskar A K wrote: >Hi Margaret > >Thanks for your very quick reply. My reply inline > >~ Vijay > > > > > Hi Vijay, > > > > Thanks for your response. > > > > > > General question on this document: We recently deprecated the > > > > option code allocation for the IPv4 version of this > > option. Why do > > > > we think that there is a greater need for this in IPv4 > > than in IPv6? > > > > Has anyone implemented these options? > > > > > > NTP version 4.0 available in www.ntp.org supports IPv6. Most of the > > > vendors provide this version and support NTP on IPv6. So, > > it is really > > > needed. > > > > Your response answers my concern about whether or not NTP is > > available for IPv6, but it doesn't answer my larger concern. > > > > We just deprecated the corresponding configuration options > > for IPv4, because they weren't implemented. Do we have some > > reason to believe that people will implement this option for > > DHCPv6 when no one implemented the same option for IPv4? If so, why? > >One of the two options specified in the draft has been already >standardized for IPv4. Refer RFC 2132, option code : 42, Network Time >Protocol Servers Option. > >There is an option called "Time offset" (option code: 2) defined in RFC >2132. But, it could not convey enough information like day light >savings. Only to provide more information about the timezone, the draft >for "POSIX time zone option for DHCPv4" was written. Meanwhile, There >were few implementations providing this support in the vendor specific >options. One such example is Solaris's "SUNW.posix-timezone-string" >option. Hence, certainly there are few users. Unfortunately, this draft >was not advanced and got expired. As most of the platforms provided this >option in the form of vendor specific options, nobody really bothered to >restart the work and advance it to the standard. Moreover, I could see >alteast 2 implementation of DHCPv6, which have the support for POSIX >time zone option. (1) HPUX (2) KAME FreeBSD. What I am trying to say is, >Certainly keeping this as an vendor specific option may cause issues >while switching between the servers. Since, this option is used as >vendor specific option in few implementations of DHCPv4 and there are >implementations of DHCPv6 which support this option, its better to >standardize it. > > > > > > > It is also my understand that we haven't (yet) specified how NTP > > > > would run over IPv6, so this option may be premature. > > > > > > Since, there is actually no protocol changes are needed in > > > existing RFC for NTP, there is no specification for NTP on > > IPv6. Its > > > just like another application migration to IPv6. But, IPv6 > > version of > > > NTP are available in various platforms. I don't think this > > option is > > > a premature one. > > > > Actually, there are several IPv4 dependencies in the NTP > > specification, as document in: > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surve > > y-apps-02.txt > > > > The folks who have implemented NTP for IPv6 must have worked > > around those dependencies, but I don't believe that their > > changes have been document in an IETF specification (yet). > >The RFC it refers is version 3 of the SNTP protocol. The next version >deals with IPv6 also. > > D. Mills. Simple Network Time Protocol (SNTP) Version 4 for > IPv4, IPv6 and OSI. Request for Comments (Informational) 2030, > Internet Engineering Task Force, October 1996. > > > > > > > What is the reason for specifying a timezone format in this > > > > document, instead of relying completely on another establish > > > > standard for timezone representation? > > > > > > This flexibility is provided to help the vendors to use some other > > > vendor specific database for timezone information. This is > > needed, if > > > they feel that their databases can convey more information > > than POSIX > > > time string. > > [...] > > > > What is a "timezone database"? Is this a standard concept, or > > > > something you are assuming will be specific to each host? > > > > If the latter, why do we need this flexibility? > > > > > > Its not a standard concept. Its something specific to the > > OS. For the > > > last question, you refer the prev answer. > > > > How do you maintain interoperability between the DHCP server > > and clients from multiple vendors, if the server may return > > the timezone in an OS-proprietary format? > >Its basically through vendor-options/class ids. Based on the class-ids >the server can provide different information for the same entity to the >different clients. This is the conventional methodology done from DHCPv4 >onwards. > > > You mentioned > > earlier that this timezone information is set on a per-subnet > > basis, with the assumption that all clients on the same > > subnet are in the same timezone. Do you also > > assume that all clients on the same subnet are running the same OS? > >No, certainly not. There can be clients running different OS. But, they >will be differentiated by the server. > > > > > > > > To avoid attacks through these options, the DHCP client > > SHOULD use > > > > > authenticated DHCP (see section "Authentication of DHCP > > messages" > > > > > in the DHCPv6 specification [1]). > > > > > > > > Why only a "SHOULD"? Given the critical nature of time > > information > > > > to some security protocols, I would prefer a statement that this > > > > option MUST only be used when the DHCP messages are > > authenticated. > > > > Is there a reason not to say that? > > > > > > As such authentication is not mandatory in the DHCPv6 > > > specification (RFC 3315) except for reconfiguration. That's the > > > reason why "MUST" is not used here. > > > > True, although we could require that DHCP security be > > implemented and used whenever certain sensitive options are > > in use... I'm not sure what sort of policy has been used for > > deciding this in the > > past, though. > > > > > > > [2] D. Mills. Simple Network Time Protocol (SNTP) > > > > > Version 4 for IPv4, IPv6 and OSI. Request for Comments > > > > > (Informational) 2030, Internet Engineering Task Force, > > > > > October 1996. > > > > > > > > This should be a reference to NTP, not to SNTP. > > > > > > Basically, the NTP servers I am referring are SNTP servers. I > > > believe, I could change the "NTP server option" to "SNTP server > > > option". > > > > If that is more accurate, then I think it would make sense to > > make that change. > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 21 12:33:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25513; Tue, 21 Oct 2003 12:33:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABzRN-0001mK-Oa; Tue, 21 Oct 2003 12:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABzQO-0001PM-T2 for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 12:32:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25456 for ; Tue, 21 Oct 2003 12:31:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABzQN-0005j2-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 12:31:59 -0400 Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx with esmtp (Exim 4.12) id 1ABzQL-0005iz-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 12:31:58 -0400 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel13.hp.com (Postfix) with ESMTP id C7B7B1C0146E; Tue, 21 Oct 2003 09:31:53 -0700 (PDT) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id WAA21991; Tue, 21 Oct 2003 22:00:41 +0530 (IST) From: "Vijayabhaskar A K" To: "'Ralph Droms'" Cc: , , Subject: RE: [dhcwg] AD Review: draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Date: Tue, 21 Oct 2003 22:01:43 +0530 Message-ID: <004a01c397f0$d04824c0$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004B_01C3981E.EA0060C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <4.3.2.7.2.20031021121740.048735d0@flask.cisco.com> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C3981E.EA0060C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ralph, I have submitted the draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt last week. Still, it is not published, though I submitted nisconfig-03 and timeconfig-03 together. Shall I proceed with the splitting up of the drafts (or) shall I wait for timeconfig-03 to get published? I am attaching the draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt along with this mail. ~ Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ralph Droms Sent: Tuesday, October 21, 2003 9:50 PM To: vijayak@india.hp.com Cc: Margaret.Wasserman@nokia.com; narten@us.ibm.com; dhcwg@ietf.org Subject: RE: [dhcwg] AD Review: draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt Seems to me we are closer to consensus on publishing the option for (S)NTP servers than we are for the timezone configuration option. Vijay, I suggest you split your current draft into two drafts, one for the (S)NTP servers option (call it draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt if you can publish it this week) and a new draft for the timezone option. With two documents, we can let each option proceed at its own pace... - Ralph At 12:59 AM 10/7/2003 +0530, Vijayabhaskar A K wrote: >Hi Margaret > >Thanks for your very quick reply. My reply inline > >~ Vijay > > > > > Hi Vijay, > > > > Thanks for your response. > > > > > > General question on this document: We recently deprecated the > > > > option code allocation for the IPv4 version of this > > option. Why do > > > > we think that there is a greater need for this in IPv4 > > than in IPv6? > > > > Has anyone implemented these options? > > > > > > NTP version 4.0 available in www.ntp.org supports IPv6. Most of > > > the vendors provide this version and support NTP on IPv6. So, > > it is really > > > needed. > > > > Your response answers my concern about whether or not NTP is > > available for IPv6, but it doesn't answer my larger concern. > > > > We just deprecated the corresponding configuration options for IPv4, > > because they weren't implemented. Do we have some reason to believe > > that people will implement this option for DHCPv6 when no one > > implemented the same option for IPv4? If so, why? > >One of the two options specified in the draft has been already >standardized for IPv4. Refer RFC 2132, option code : 42, Network Time >Protocol Servers Option. > >There is an option called "Time offset" (option code: 2) defined in RFC >2132. But, it could not convey enough information like day light >savings. Only to provide more information about the timezone, the >draft for "POSIX time zone option for DHCPv4" was written. Meanwhile, >There were few implementations providing this support in the vendor >specific options. One such example is Solaris's >"SUNW.posix-timezone-string" option. Hence, certainly there are few >users. Unfortunately, this draft was not advanced and got expired. As >most of the platforms provided this option in the form of vendor >specific options, nobody really bothered to restart the work and >advance it to the standard. Moreover, I could see alteast 2 >implementation of DHCPv6, which have the support for POSIX time zone >option. (1) HPUX (2) KAME FreeBSD. What I am trying to say is, >Certainly keeping this as an vendor specific option may cause issues >while switching between the servers. Since, this option is used as >vendor specific option in few implementations of DHCPv4 and there are >implementations of DHCPv6 which support this option, its better to >standardize it. > > > > > > > It is also my understand that we haven't (yet) specified how NTP > > > > would run over IPv6, so this option may be premature. > > > > > > Since, there is actually no protocol changes are needed in > > > existing RFC for NTP, there is no specification for NTP on > > IPv6. Its > > > just like another application migration to IPv6. But, IPv6 > > version of > > > NTP are available in various platforms. I don't think this > > option is > > > a premature one. > > > > Actually, there are several IPv4 dependencies in the NTP > > specification, as document in: > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4surve > > y-apps-02.txt > > > > The folks who have implemented NTP for IPv6 must have worked around > > those dependencies, but I don't believe that their changes have been > > document in an IETF specification (yet). > >The RFC it refers is version 3 of the SNTP protocol. The next version >deals with IPv6 also. > > D. Mills. Simple Network Time Protocol (SNTP) Version 4 for > IPv4, IPv6 and OSI. Request for Comments (Informational) 2030, > Internet Engineering Task Force, October 1996. > > > > > > > What is the reason for specifying a timezone format in this > > > > document, instead of relying completely on another establish > > > > standard for timezone representation? > > > > > > This flexibility is provided to help the vendors to use some other > > > vendor specific database for timezone information. This is > > needed, if > > > they feel that their databases can convey more information > > than POSIX > > > time string. > > [...] > > > > What is a "timezone database"? Is this a standard concept, or > > > > something you are assuming will be specific to each host? If the > > > > latter, why do we need this flexibility? > > > > > > Its not a standard concept. Its something specific to the > > OS. For the > > > last question, you refer the prev answer. > > > > How do you maintain interoperability between the DHCP server and > > clients from multiple vendors, if the server may return the timezone > > in an OS-proprietary format? > >Its basically through vendor-options/class ids. Based on the class-ids >the server can provide different information for the same entity to the >different clients. This is the conventional methodology done from >DHCPv4 onwards. > > > You mentioned > > earlier that this timezone information is set on a per-subnet basis, > > with the assumption that all clients on the same subnet are in the > > same timezone. Do you also assume that all clients on the same > > subnet are running the same OS? > >No, certainly not. There can be clients running different OS. But, they >will be differentiated by the server. > > > > > > > > To avoid attacks through these options, the DHCP client > > SHOULD use > > > > > authenticated DHCP (see section "Authentication of DHCP > > messages" > > > > > in the DHCPv6 specification [1]). > > > > > > > > Why only a "SHOULD"? Given the critical nature of time > > information > > > > to some security protocols, I would prefer a statement that this > > > > option MUST only be used when the DHCP messages are > > authenticated. > > > > Is there a reason not to say that? > > > > > > As such authentication is not mandatory in the DHCPv6 > > > specification (RFC 3315) except for reconfiguration. That's the > > > reason why "MUST" is not used here. > > > > True, although we could require that DHCP security be implemented > > and used whenever certain sensitive options are in use... I'm not > > sure what sort of policy has been used for deciding this in the > > past, though. > > > > > > > [2] D. Mills. Simple Network Time Protocol (SNTP) Version 4 > > > > > for IPv4, IPv6 and OSI. Request for Comments > > > > > (Informational) 2030, Internet Engineering Task Force, October > > > > > 1996. > > > > > > > > This should be a reference to NTP, not to SNTP. > > > > > > Basically, the NTP servers I am referring are SNTP servers. I > > > believe, I could change the "NTP server option" to "SNTP server > > > option". > > > > If that is more accurate, then I think it would make sense to make > > that change. > > > > > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------=_NextPart_000_004B_01C3981E.EA0060C0 Content-Type: text/plain; name="draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt" Content-Disposition: attachment; filename="draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt" Content-Transfer-Encoding: quoted-printable =0A= Network Working Group A.K. Vijayabhaskar=0A= Internet-Draft Hewlett-Packard=0A= Expires: April 16, 2004 15 Oct 2003=0A= =0A= =0A= Time Configuration Options for DHCPv6=0A= draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt=0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance with=0A= all provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on April 16, 2004.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= Abstract=0A= =0A= This document describes the options for Time related configuration=0A= information in DHCPv6: SNTP Server addresses - using which the clients=0A= can synchronize their system time to that of the standard time =0A= servers; Timezone specifier - used to set the timezone of the clients.=0A= =0A= 1. Introduction=0A= =0A= This document describes the options for time related configuration =0A= information in DHCPv6 [1].=0A= =0A= 2. Requirements=0A= =0A= The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,=0A= SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this=0A= document, are to be interpreted as described in RFC 2119 [4]=0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires April 16, 2004 [Page 1]=0A= =0C=0A= Internet-Draft Time Configuration Options for DHCPv6 Oct 2003=0A= =0A= 3. Terminology=0A= =0A= This document uses terminology specific to IPv6 and DHCPv6 as defined=0A= in "Terminology" section of the DHCPv6 specification.=0A= =0A= 4. Simple Network Time Protocol (SNTP) Servers option=0A= =0A= The Simple Network Time Protocol Servers option provides a list of =0A= one or more IPv6 addresses of SNTP [2] servers available to the =0A= client for synchronization. The SNTP servers SHOULD be listed in =0A= the order of preference.=0A= =0A= The format of the Simple Network Time Protocol Servers option is as =0A= shown below:=0A= =0A= 0 1 2 3=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | OPTION_SNTP_SERVERS | option-len |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | |=0A= | SNTP server (IPv6 address) |=0A= | |=0A= | |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | |=0A= | SNTP server (IPv6 address) |=0A= | |=0A= | |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | ... |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= =0A= option-code: OPTION_SNTP_SERVERS (tbd)=0A= =0A= option-len: Length of the 'SNTP server' fields in octets; It must be=0A= a multiple of 16=0A= =0A= SNTP server: IPv6 address of SNTP server=0A= =0A= 5. Timezone option=0A= =0A= The Timezone option is used by the server to convey the timezone =0A= in which the client resides. The client is expected to set the =0A= timezone in its system on receiving this option from the server.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires April 16, 2004 [Page 2]=0A= =0C=0A= Internet-Draft Time Configuration Options for DHCPv6 Oct 2003=0A= =0A= The format of the Timezone option is:=0A= =0A= 0 1 2 3=0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | OPTION_TIME_ZONE | option-len |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | time-zone |=0A= | ... |=0A= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= option-code: OPTION_TIME_ZONE (tbd)=0A= =0A= option-len: Length of the 'time-zone' field in octets=0A= =0A= time-zone: Time zone of the client in the NVT-ASCII string format. =0A= The format of this string is explained below:=0A= =0A= Std[Offset[Dst[Offset],[Start[/Time],End[/Time]]]]=0A= =0A= where '[' and ']' enclose optional fields, '|' indicates choice=0A= of exactly one of the alternatives, ',' and '/' represent literal=0A= characters present in the string.=0A= =0A= If "Offset" is specified, then the time-zone is represented in the=0A= IEEE 1003.1 POSIX timezone format [3].=0A= =0A= Std Three or more octets for the standard timezone (Std).=0A= Any character (or case) except a leading colon, digits,=0A= comma, minus or plus sign is allowed. If there is no =0A= Offset followed by the Std, then the timezone is not=0A= represented in IEEE 1003.1 format. In this case, the=0A= Std is treated as the index to the timezone database, for =0A= example, a file name, from where additional information =0A= about the timezone may be obtained.=0A= =0A= Offset Indicates the value one must add to local time to=0A= arrive at UTC, of the form: [+|-]hh[:mm[:ss]]. Offset=0A= following Std is required, if the timezone is represented=0A= in IEEE 1003.1 POSIX timezone format. Digits are always =0A= interpreted as decimal number. If preceded by a '-', the =0A= timezone is east of the Prime Meridian, otherwise it is =0A= west ('+' is optional) The permissible values for =0A= hh[:mm[:ss]] are as follows:=0A= =0A= hh 0 <=3D hh <=3D 23=0A= =0A= mm 0 <=3D mm <=3D 60=0A= =0A= ss 0 <=3D ss <=3D 60=0A= =0A= Dst Three or more octets for the daylight savings timezone.=0A= If Dst is missing, then daylight savings time does not=0A= apply in this locale. If no Offset follows Dst, then=0A= Dst is assumed to be one hour ahead of standard time.=0A= =0A= =0A= Vijayabhaskar A K Expires April 16, 2004 [Page 3]=0A= =0C=0A= Internet-Draft Time Configuration Options for DHCPv6 Oct 2003=0A= =0A= Any character (or case) except a leading colon, digits,=0A= comma, minus or plus sign is allowed.=0A= =0A= Start Indicates the day of the year, in one of the formats=0A= indicated below, when to change to daylight savings time.=0A= The ``Time'' field (which follows immediately after a=0A= ``/'' character, if present) indicates when the change is=0A= made, in local time.=0A= =0A= End Indicates the day of the year, in one of the formats=0A= indicated below, when to change back from daylight=0A= savings time. The ``Time'' field (which follows=0A= immediately after a ``/'' character, if present)=0A= indicates when the change is made, in local time.=0A= =0A= Time Time has the same format as Offset, except that no=0A= leading ``-'' or ``+'' is permitted. The default is=0A= 02:00:00.=0A= =0A= The day of the year needs to be given in any of the following =0A= formats:=0A= =0A= Jn The julian day n, (1 <=3D n <=3D 365). Leap days are not=0A= counted.=0A= =0A= n Zero-based julian day, (0 <=3D n <=3D 365). Leap days are=0A= counted so it is possible to refer to Feb 29.=0A= =0A= Mm.n.d The ``d''th day, (0 <=3D d <=3D 6) of week ``n'' of month=0A= ``m'' of the year (1 <=3D n <=3D 5, 1 <=3D m <=3D 12, = where week=0A= 5 means last ``d'' day in month ``m'' which may occur in=0A= either the fourth or the fifth week. Week ``1'' is the=0A= first week in which the ``d'' day occurs. Day ``0'' refers=0A= Sunday, day ``1'' refers Monday and so on.=0A= =0A= Examples:=0A= =0A= i) Indian Standard Time zone is represented as:=0A= =0A= IST-5:30=0A= =0A= Here, ``IST'' refers the standard timezone and ``-5:30'' is the =0A= offset. `-' sign in the offset says that the timezone is 5 hours and =0A= 30 minutes ahead of UTC. Absence of ``Dst'' says that daylight savings=0A= doesn't apply to this locale.=0A= =0A= ii) For Eastern USA time zone, 1986, the timezone string is as shown =0A= below:=0A= =0A= EST5EDT4,116/02:00:00,298/02:00:00=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires April 16, 2004 [Page 4]=0A= =0C=0A= Internet-Draft Time Configuration Options for DHCPv6 Oct 2003=0A= =0A= It says:=0A= =0A= The standard time zone is in 5 hours behind UTC. The Daylight Savings =0A= Timezone is 4 hours behind UTC. Day light savings starts at 116 day, =0A= i.e., April 27 02:00 AM standard time and ends at 298th day, i.e., =0A= October 26 02:00 AM daylight time.=0A= =0A= It can also represented as:=0A= =0A= EST5EDT,116/02:00:00,298/02:00:00=0A= =0A= Since no offset follows the ``Dst'', daylight savings time is 1 hour =0A= ahead of standard time, thus, it is 4 hours behind UTC.=0A= =0A= iii) Representing ii) in the non POSIX standard way is:=0A= =0A= America/New-York=0A= =0A= It says that the locale belongs to New-York timezone in America, =0A= which will be used as the index in to a timezone database to get =0A= more information of the timezone.=0A= =0A= 6. Usage of Timezone option=0A= =0A= The Timezone option has the flexibility of providing timezone =0A= information in formats other than POSIX timezone, because =0A= some vendor specific databases can provide more information than =0A= POSIX Timezone string. The server SHOULD be configurable to send = any =0A= of the format specified in Section 5.=0A= =0A= The timezone option can be used along with the Vendor Class =0A= Option [1] to make sure that the client and server agree upon the =0A= meaning of the string. For example, the clients running in different=0A= OS expect the string in different formats. Here, the Vendor Class =0A= Option [1] sent by clients can be used by the server to distinguish =0A= between the clients to return the proper timezone string.=0A= =0A= If the client is not able to interpret the timezone option sent =0A= by the server, then it SHOULD ignore the option. It MAY contact =0A= alternative DHCPv6 servers to obtain the timezone information.=0A= =0A= =0A= 7. Appearance of these options=0A= =0A= The SNTP servers and Timezone options MUST NOT appear in other than=0A= the following messages: Solicit, Advertise, Request, Renew, Rebind,=0A= Information-Request and Reply.=0A= =0A= The option number for these options MAY appear in the Option Request=0A= Option [1] in the following messages: Solicit, Request, Renew, Rebind,=0A= Information-Request and Reconfigure.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires April 16, 2004 [Page 5]=0A= =0C=0A= Internet-Draft Time Configuration Options for DHCPv6 Oct 2003=0A= =0A= 8. Security Considerations=0A= =0A= The SNTP servers option may be used by an intruder DHCPv6 server to=0A= cause DHCPv6 clients to contact a rogue SNTP server, resulting in =0A= invalid synchronization of time in client and finally leading to=0A= time critical applications running inaccurately in client machine.=0A= The time accuracy can be crucial to some security algorithms. For =0A= example, it may cause expired certificates to gain a new life, making=0A= the applications running on the client machine less secure. It can =0A= even cause clients to set their time incorrectly, making them =0A= vulnerable to replay attacks in protocols that use time stamps to =0A= detect replays.=0A= =0A= The Timezone option may be used by an intruder DHCPv6 server to =0A= assign invalid time zones, leading to timing issues for the =0A= applications running on the client machine. For example, because of =0A= wrongly configured timezone, there is a possibility that some critical=0A= applications, which are supposed to start at a particular time don't =0A= get started at that time. A delayed start of OS security update will=0A= leave the client's machine vulnerable to security attacks.=0A= =0A= To avoid attacks through these options, the DHCPv6 client SHOULD use =0A= authenticated DHCPv6 (see "Authentication of DHCP messages" section=0A= in the DHCPv6 specification [1]).=0A= =0A= 9. IANA Considerations=0A= =0A= IANA is requested to assign an option code to the following options =0A= from the option-code space defined in "DHCPv6 Options" section of the=0A= DHCPv6 specification [1].=0A= =0A= Option Name Value Described in=0A= OPTION_SNTP_SERVERS tbd Section 4.=0A= OPTION_TIME_ZONE tbd Section 5.=0A= =0A= =0A= =0A= 10. Normative References=0A= =0A= [1] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R.=0A= Droms (ed.), "Dynamic Host Configuration Protocol for IPv6=0A= (DHCPv6)", RFC 3315, July 2003.=0A= =0A= 11. Informative References=0A= =0A= [2] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for=0A= IPv4, IPv6 and OSI. Request for Comments (Informational) 2030,=0A= Internet Engineering Task Force, October 1996.=0A= =0A= [3] IEEE, "1003.1 POSIX Timezone Specification", 1988.=0A= =0A= [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement=0A= Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires April 16, 2004 [Page 6]=0A= =0C=0A= Internet-Draft Time Configuration Options for DHCPv6 Oct 2003=0A= =0A= =0A= Author's Addresses=0A= =0A= Vijayabhaskar A K=0A= Hewlett-Packard STSD-I=0A= 29, Cunningham Road=0A= Bangalore - 560052=0A= India=0A= =0A= Phone: +91-80-2053085=0A= E-Mail: vijayak@india.hp.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires April 16, 2004 [Page 7]=0A= =0C=0A= Internet-Draft Time Configuration Options for DHCPv6 Oct 2003=0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it=0A= or assist in its implementation may be prepared, copied, published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by removing=0A= the copyright notice or references to the Internet Society or other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Acknowledgement=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society. Thanks to the DHC Working Group for their time and =0A= input into the specification. In particular, thanks to (in =0A= alphabetical order) Bernie Volz, Jim Bound, Margaret Wasserman, Ralph=0A= Droms, Robert Elz and Thomas Narten for their thorough review. Special=0A= thanks to Robert Elz for his suggestions and help in making this =0A= document more readable. Thanks to Mike Carney for his abstract =0A= on Timezone option.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Vijayabhaskar A K Expires April 16, 2004 [Page 8]=0A= =0C=0A= ------=_NextPart_000_004B_01C3981E.EA0060C0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 21 16:19:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05703; Tue, 21 Oct 2003 16:19:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2y5-0005yn-SO; Tue, 21 Oct 2003 16:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC2xW-0005rt-4U for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 16:18:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05682 for ; Tue, 21 Oct 2003 16:18:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC2xU-0000ud-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 16:18:24 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AC2xT-0000uR-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 16:18:23 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 21 Oct 2003 13:14:54 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9LKHojP023111; Tue, 21 Oct 2003 13:17:51 -0700 (PDT) Received: from cisco.com (stealth-10-32-254-99.cisco.com [10.32.254.99]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AMS87171; Tue, 21 Oct 2003 13:16:55 -0700 (PDT) Date: Tue, 21 Oct 2003 13:17:47 -0700 Subject: Re: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org To: Ted Lemon From: Richard Johnson In-Reply-To: <200309161403.53065.mellon@fugue.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've recently encountered a related issue w.r.t. the Pad option. Some customers have been stating that it is incorrect for a DHCP relay to simply insert Pad option bytes over the Relay option when returning a reply to a client. They say that since this results in Pad option bytes *before* the End option, this is wrong and their client systems do not accept the OFFERs they receive in this format. My understanding that a Pad option is simply to be skipped over in option processing *wherever* it's encountered. RFC2131 says: > the > options in the 'options' field MUST be terminated by an 'end' > option, > and MAY contain one or more 'pad' options to fill the options field. and: > The options in the 'sname' and 'file' fields (if in use as indicated > by the 'options overload' option) MUST begin with the first octet of > the field, MUST be terminated by an 'end' option, and MUST be > followed by 'pad' options to fill the remainder of the field. (These being the only mentions of the Pad option). However, RFC2132 says: > The pad option can be used to cause subsequent fields to align on > word boundaries. /raj On Tuesday, September 16, 2003, at 12:03 PM, Ted Lemon wrote: > We have encountered in the field a relay agent that does something > interesting. RFC3046 says that the relay agent is supposed to insert > the > Relay Agent Information option into the packet at the point where the > End > option in the packet was found, or at the end of the options. This > client > ignores RFC3046 and stores the Relay Agent Information option _after_ > the > packet's End option, followed by its own End option. > > Our first reaction was to think that the relay agent was just buggy, > but I > went and looked at the RFCs and discovered a problem, which this relay > agent > actually doesn't hit because of its weird way of storing the option. > > The problem is that what RFC3046 says about the End option is > ambiguous with > respect to figuring out what the packet looked like when the RFC3118 > signature was computed. Consider the following scenarios: > > 1. The packet has an End option after the last informative option (by > which I > mean an option that conveys information, as opposed to an End or Pad > option). > > 2. The packet has no End option, and has some number of bytes of Pad > options > after the last informative option. > > 3. The packet has no End option, and no Pad options after the last > informative > option. > > It could be argued that (2) and (3) violate section 4.1 of RFC2131, > which says > "The last option must always be the 'end' option." However, people > have > interpreted this in different ways - does this mean that the packet > MUST have > an End option, or does it mean that if the packet has an End option, > it MUST > be the last option in the packet? What should the sending agent do > when it > has exactly enough options to fill the option buffer, and no room for > an End > option? Does it send the End option, or not? > > So although cases (2) and (3) are technically out of spec, I would say > that we > should account for them. Even in case (1), it's not clear what to > do. Is > the End option included in the signature, or no? > > I think we need some language to explicitly say what relay agents > should do in > all of these cases, and also what sending agents should do in these > cases. > > Comments? > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 21 16:34:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06324; Tue, 21 Oct 2003 16:34:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC3Ca-0000ze-91; Tue, 21 Oct 2003 16:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC3CX-0000zH-OR for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 16:33:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06310 for ; Tue, 21 Oct 2003 16:33:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC3CV-0001Ah-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 16:33:55 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AC3CU-0001AU-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 16:33:55 -0400 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AC3Bo-0007as-00; Tue, 21 Oct 2003 13:33:12 -0700 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5VN4G>; Tue, 21 Oct 2003 13:32:51 -0700 Message-ID: From: "Kostur, Andre" To: "'Richard Johnson'" , Ted Lemon Cc: dhcwg@ietf.org Subject: RE: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... Date: Tue, 21 Oct 2003 13:32:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39812.7EC6FFF0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C39812.7EC6FFF0 Content-Type: text/plain; charset="iso-8859-1" > I've recently encountered a related issue w.r.t. the Pad > option. Some > customers have been stating that it is incorrect for a DHCP relay to > simply insert Pad option bytes over the Relay option when returning a > reply to a client. They say that since this results in Pad option > bytes *before* the End option, this is wrong and their client systems > do not accept the OFFERs they receive in this format. This is actually wrong (the behaviour). According to 3046, the device which originally added the option 82 must _remove_ the option, not overwrite it (section 2.2, RFC 3046). This is further reinforced by RFC 3118 where it talks about creating the hash on a DHCP message, and if option 82 is present, it is to be calculated as if the option wasn't present (section 2, RFC 3118). > My understanding that a Pad option is simply to be skipped over in > option processing *wherever* it's encountered. RFC2131 says: Not entirely correct. See RFC 3118. DHCP Authentication will calculate the hash with the pad options present. > > the > > options in the 'options' field MUST be terminated by an 'end' > > option, > > and MAY contain one or more 'pad' options to fill the > options field. > > and: > > > The options in the 'sname' and 'file' fields (if in use as indicated > > by the 'options overload' option) MUST begin with the > first octet of > > the field, MUST be terminated by an 'end' option, and MUST be > > followed by 'pad' options to fill the remainder of the field. > > (These being the only mentions of the Pad option). > > However, RFC2132 says: > > > The pad option can be used to cause subsequent fields to align on > > word boundaries. From a DHCP decoding standpoint, the pad option should effectively be skipped. In my opinion, both devices have a broken (or perhaps incomplete) DHCP implementation: The relay because it is simply overwriting option 82, and not removing it (I guess that could be dependant on the interpretation of "remove"), and the client for not being able to process pad options. ------_=_NextPart_001_01C39812.7EC6FFF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] An unfortunate ambiguity in = RFC3118/RFC3046...

> I've recently encountered a related issue w.r.t. = the Pad
> option.  Some
> customers have been stating that it is = incorrect for a DHCP relay to
> simply insert Pad option bytes over the Relay = option when returning a
> reply to a client.  They say that since = this results in Pad option
> bytes *before* the End option, this is wrong = and their client systems
> do not accept the OFFERs they receive in this = format.

This is actually wrong (the behaviour).  = According to 3046, the device which originally added the option 82 must = _remove_ the option, not overwrite it (section 2.2, RFC 3046).  = This is further reinforced by RFC 3118 where it talks about creating = the hash on a DHCP message, and if option 82 is present, it is to be = calculated as if the option wasn't present (section 2, RFC = 3118).

 
> My understanding that a Pad option is simply to = be skipped over in
> option processing *wherever* it's = encountered.  RFC2131 says:

Not entirely correct.  See RFC 3118.  DHCP = Authentication will calculate the hash with the pad options = present.
 
> > the
> >    options in the 'options' = field MUST be terminated by an 'end'
> > option,
> >    and MAY contain one or = more 'pad' options to fill the
> options field.
>
> and:
>
> > The options in the 'sname' and 'file' = fields (if in use as indicated
> >    by the 'options = overload' option) MUST begin with the
> first octet of
> >    the field, MUST be = terminated by an 'end' option, and MUST be
> >    followed by 'pad' = options to fill the remainder of the field.
>
> (These being the only mentions of the Pad = option).
>
> However, RFC2132 says:
>
> >    The pad option can be = used to cause subsequent fields to align on
> >    word boundaries.

From a DHCP decoding standpoint, the pad option = should effectively be skipped.

In my opinion, both devices have a broken (or perhaps = incomplete) DHCP implementation: The relay because it is simply = overwriting option 82, and not removing it (I guess that could be = dependant on the interpretation of "remove"), and the client = for not being able to process pad options.

------_=_NextPart_001_01C39812.7EC6FFF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 21 20:19:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21007; Tue, 21 Oct 2003 20:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6iL-00069J-4w; Tue, 21 Oct 2003 20:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6hf-00060T-T9 for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 20:18:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20964 for ; Tue, 21 Oct 2003 20:18:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6hd-0005ZX-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 20:18:17 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AC6hd-0005ZU-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 20:18:17 -0400 Received: from fugue.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id B1FC41B2234; Tue, 21 Oct 2003 19:14:34 -0500 (CDT) Date: Tue, 21 Oct 2003 17:18:19 -0700 Subject: Re: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org, "'Richard Johnson'" To: "Kostur, Andre" From: Ted Lemon In-Reply-To: Message-Id: <3D3A3CEC-0425-11D8-9907-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, October 21, 2003, at 01:32 PM, Kostur, Andre wrote: > In my opinion, both devices have a broken (or perhaps incomplete) DHCP > implementation: The relay because it is simply overwriting option 82, > and not removing it (I guess that could be dependant on the > interpretation of "remove"), and the client for not being able to > process pad options. That's right. However, the fact that the relay is potentially breaking the signature on the packet is a big bad nono that will completely prevent communication if we ever start signing DHCP packets. The client bug, while definitely a bug, is something that's comparatively easy to work around, unless the relay agent does the wrong thing. That is, if you find that your DHCP server is sending extra pads, it's easy to install a new version of the DHCP server. Installing new relay agents is hard, but installing new clients is beyond hard - by and large, it simply isn't possible. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 21 20:55:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21863; Tue, 21 Oct 2003 20:55:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7HB-00008Y-T9; Tue, 21 Oct 2003 20:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7Gj-0008R1-DZ for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 20:54:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21840 for ; Tue, 21 Oct 2003 20:54:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC7Gg-0005qR-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 20:54:30 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AC7Gg-0005q4-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 20:54:30 -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 <0HN400LHRVTYDO@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 22 Oct 2003 09:53:58 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HN4005B8VR9SD@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 22 Oct 2003 09:52:21 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HN4009X0VR9K2@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 22 Oct 2003 09:52:21 +0900 (KST) Date: Wed, 22 Oct 2003 09:52:39 +0900 From: Soohong Daniel Park Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt In-reply-to: To: "'Rentschler, Markus'" , dhcwg@ietf.org Cc: "'Bernie Volz'" Message-id: <015701c39836$ca9c4240$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Markus For the flags, we have to modify the current messages.=20 To avoid this modification, I thought the new option would=20 be better to support this function. =20 Am I missing anything ? Comments welcome..! Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics=20 > -----Original Message----- > From: Rentschler, Markus [mailto:mrentsch@nt.hirschmann.de]=20 > Sent: Tuesday, October 21, 2003 10:33 PM > To: dhcwg@ietf.org > Cc: Soohong Daniel Park > Subject: AW: [dhcwg] FW: I-D=20 > ACTION:draft-volz-dhc-rapidreply-opt-00.txt >=20 >=20 > Hello, >=20 > wouldn't it be better to reserve a bit in the "flags" field=20 > for that purpose ? >=20 >=20 > Regards, >=20 > Markus Rentschler > Hirschmann Electronics GmbH & Co. KG > =20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Soohong Daniel Park [SMTP:soohong.park@samsung.com] > > Gesendet am: Dienstag, 21. Oktober 2003 01:48 > > An: dhcwg@ietf.org > > Betreff: [dhcwg] FW: I-D=20 > ACTION:draft-volz-dhc-rapidreply-opt-00.txt > >=20 > > Hello dhc > >=20 > > Please see the "Rapid Reply Option for DHCPv4" I-D announcement=20 > > below... > >=20 > > Abstract > > =20 > > This document defines a new option, modeled on the IPv6 option for=20 > > getting IP address and configuration information rapidly=20 > which can be=20 > > used for detecting network attachment when client moves to=20 > a new link. > >=20 > >=20 > >=20 > >=20 > > Regards > >=20 > > Daniel (Soohong Daniel Park) > > Mobile Platform Laboratory, SAMSUNG Electronics > >=20 > > > -----Original Message----- > > > From: owner-ietf-announce@ietf.org > > > [ ] On Behalf Of=20 > > > Internet-Drafts@ietf.org > > > Sent: Tuesday, October 21, 2003 4:43 AM > > > To: IETF-Announce: > > > Subject: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > > directories. > > > > > > > > > Title : Rapid Reply Option for DHCPv4 > > > Author(s) : S. Park, et. al. > > > Filename : draft-volz-dhc-rapidreply-opt-00.txt > > > Pages : 7 > > > Date : 2003-10-20 > > > =20 > > > This document defines a new option, modeled on the IPv6=20 > option for=20 > > > getting IP address and configuration information rapidly=20 > which can=20 > > > be used for detecting network attachment when client=20 > moves to a new=20 > > > link. > > > > > > A URL for this Internet-Draft is: > >=20 txt> >=20 > To remove yourself from the IETF Announcement list, send a message to=20 > ietf-announce-request with the word unsubscribe in the body of the=20 > message. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then > "get draft-volz-dhc-rapidreply-opt-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > or=20 > >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-volz-dhc-rapidreply-opt-00.txt". > =20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail=20 > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =20 > =20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. >=20 > << Datei: ATT00156.txt >> << Datei:=20 > draft-volz-dhc-rapidreply-opt-00.txt > >>=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 21 21:11:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22350; Tue, 21 Oct 2003 21:11:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7Wf-0004Yt-TT; Tue, 21 Oct 2003 21:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7W8-0004Px-3y for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 21:10:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22280 for ; Tue, 21 Oct 2003 21:10:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC7W5-0005zd-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 21:10:25 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AC7W4-0005zO-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 21:10:24 -0400 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AC7VV-0003u5-00; Tue, 21 Oct 2003 18:09:49 -0700 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5V3SP>; Tue, 21 Oct 2003 18:09:28 -0700 Message-ID: From: "Kostur, Andre" To: "'Ted Lemon'" Cc: dhcwg@ietf.org, "'Richard Johnson'" Subject: RE: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... Date: Tue, 21 Oct 2003 18:09:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39839.24222080" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C39839.24222080 Content-Type: text/plain; charset="iso-8859-1" Come to think of it... the relay is very broken, because technically speaking it is adding a bunch of extra options that didn't exist in the original packet. Specifically a number of instances of option 0 :) And the only option that relays are allowed to add is option 82. > -----Original Message----- > From: Ted Lemon [mailto:mellon@fugue.com] > Sent: Tuesday, October 21, 2003 5:18 PM > To: Kostur, Andre > Cc: dhcwg@ietf.org; 'Richard Johnson' > Subject: Re: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... > > > On Tuesday, October 21, 2003, at 01:32 PM, Kostur, Andre wrote: > > In my opinion, both devices have a broken (or perhaps > incomplete) DHCP > > implementation: The relay because it is simply overwriting > option 82, > > and not removing it (I guess that could be dependant on the > > interpretation of "remove"), and the client for not being able to > > process pad options. > > That's right. However, the fact that the relay is potentially > breaking the signature on the packet is a big bad nono that will > completely prevent communication if we ever start signing > DHCP packets. > The client bug, while definitely a bug, is something that's > comparatively easy to work around, unless the relay agent does the > wrong thing. That is, if you find that your DHCP server is sending > extra pads, it's easy to install a new version of the DHCP server. > Installing new relay agents is hard, but installing new clients is > beyond hard - by and large, it simply isn't possible. > > > ------_=_NextPart_001_01C39839.24222080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] An unfortunate ambiguity in = RFC3118/RFC3046...

Come to think of it... the relay is very broken, = because technically speaking it is adding a bunch of extra options that = didn't exist in the original packet.  Specifically a number of = instances of option 0 :)  And the only option that relays are = allowed to add is option 82.

> -----Original Message-----
> From: Ted Lemon [mailto:mellon@fugue.com]
> Sent: Tuesday, October 21, 2003 5:18 PM
> To: Kostur, Andre
> Cc: dhcwg@ietf.org; 'Richard Johnson'
> Subject: Re: [dhcwg] An unfortunate ambiguity = in RFC3118/RFC3046...
>
>
> On Tuesday, October 21, 2003, at 01:32  = PM, Kostur, Andre wrote:
> > In my opinion, both devices have a broken = (or perhaps
> incomplete) DHCP
> > implementation: The relay because it is = simply overwriting
> option 82,
> > and not removing it (I guess that could be = dependant on the
> > interpretation of "remove"), and = the client for not being able to
> > process pad options.
>
> That's right.   However, the fact = that the relay is potentially
> breaking the signature on the packet is a big = bad nono that will
> completely prevent communication if we ever = start signing
> DHCP packets.
>    The client bug, while = definitely a bug, is something that's
> comparatively easy to work around, unless the = relay agent does the
> wrong thing.   That is, if you find = that your DHCP server is sending
> extra pads, it's easy to install a new version = of the DHCP server.  
> Installing new relay agents is hard, but = installing new clients is
> beyond hard - by and large, it simply isn't = possible.
>
>
>

------_=_NextPart_001_01C39839.24222080-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 21 21:39:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22862; Tue, 21 Oct 2003 21:39:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7xk-0004x8-5r; Tue, 21 Oct 2003 21:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7wv-0004qT-RH for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 21:38:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22829 for ; Tue, 21 Oct 2003 21:37:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC7ws-0006Bp-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 21:38:06 -0400 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AC7ws-0006Bl-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 21:38:06 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9M1baAr009413; Tue, 21 Oct 2003 21:38:01 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Soohong Daniel Park'" , "'Rentschler, Markus'" , Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Tue, 21 Oct 2003 21:37:54 -0400 Message-ID: <000201c3983d$2a66c0f0$6701a8c0@BVolz> 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.4510 In-Reply-To: <015701c39836$ca9c4240$b7cbdba8@daniel> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Yes, options are a much better way to go. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Soohong Daniel Park Sent: Tuesday, October 21, 2003 8:53 PM To: 'Rentschler, Markus'; dhcwg@ietf.org Cc: 'Bernie Volz' Subject: RE: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Hello Markus For the flags, we have to modify the current messages.=20 To avoid this modification, I thought the new option would=20 be better to support this function. =20 Am I missing anything ? Comments welcome..! Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics=20 > -----Original Message----- > From: Rentschler, Markus [mailto:mrentsch@nt.hirschmann.de]=20 > Sent: Tuesday, October 21, 2003 10:33 PM > To: dhcwg@ietf.org > Cc: Soohong Daniel Park > Subject: AW: [dhcwg] FW: I-D=20 > ACTION:draft-volz-dhc-rapidreply-opt-00.txt >=20 >=20 > Hello, >=20 > wouldn't it be better to reserve a bit in the "flags" field=20 > for that purpose ? >=20 >=20 > Regards, >=20 > Markus Rentschler > Hirschmann Electronics GmbH & Co. KG > =20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Soohong Daniel Park [SMTP:soohong.park@samsung.com] > > Gesendet am: Dienstag, 21. Oktober 2003 01:48 > > An: dhcwg@ietf.org > > Betreff: [dhcwg] FW: I-D=20 > ACTION:draft-volz-dhc-rapidreply-opt-00.txt > >=20 > > Hello dhc > >=20 > > Please see the "Rapid Reply Option for DHCPv4" I-D announcement=20 > > below... > >=20 > > Abstract > > =20 > > This document defines a new option, modeled on the IPv6 option for=20 > > getting IP address and configuration information rapidly=20 > which can be=20 > > used for detecting network attachment when client moves to=20 > a new link. > >=20 > >=20 > >=20 > >=20 > > Regards > >=20 > > Daniel (Soohong Daniel Park) > > Mobile Platform Laboratory, SAMSUNG Electronics > >=20 > > > -----Original Message----- > > > From: owner-ietf-announce@ietf.org > > > [ ] On Behalf Of=20 > > > Internet-Drafts@ietf.org > > > Sent: Tuesday, October 21, 2003 4:43 AM > > > To: IETF-Announce: > > > Subject: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts=20 > > > directories. > > > > > > > > > Title : Rapid Reply Option for DHCPv4 > > > Author(s) : S. Park, et. al. > > > Filename : draft-volz-dhc-rapidreply-opt-00.txt > > > Pages : 7 > > > Date : 2003-10-20 > > > =20 > > > This document defines a new option, modeled on the IPv6=20 > option for=20 > > > getting IP address and configuration information rapidly=20 > which can=20 > > > be used for detecting network attachment when client=20 > moves to a new=20 > > > link. > > > > > > A URL for this Internet-Draft is: > >=20 txt> >=20 > To remove yourself from the IETF Announcement list, send a message to=20 > ietf-announce-request with the word unsubscribe in the body of the=20 > message. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then > "get draft-volz-dhc-rapidreply-opt-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > or=20 > >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-volz-dhc-rapidreply-opt-00.txt". > =20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail=20 > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =20 > =20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. >=20 > << Datei: ATT00156.txt >> << Datei:=20 > draft-volz-dhc-rapidreply-opt-00.txt > >>=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 21 21:40:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22936; Tue, 21 Oct 2003 21:40:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7yl-0005B7-Rz; Tue, 21 Oct 2003 21:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC7xq-0004xc-S4 for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 21:39:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22848 for ; Tue, 21 Oct 2003 21:38:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC7xn-0006By-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 21:39:03 -0400 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AC7xn-0006Bv-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 21:39:03 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9M1cvAr009677; Tue, 21 Oct 2003 21:39:00 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt Date: Tue, 21 Oct 2003 21:39:15 -0400 Message-ID: <000301c3983d$4d615fc0$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <4.3.2.7.2.20031021083132.04816730@flask.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I support this document moving forward. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ralph Droms Sent: Tuesday, October 21, 2003 8:35 AM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt This message announces a WG last call on "DHCP Lease Query" . The last call will conclude at 5PM = ET on Friday, 10/31/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. This document defines new messages through which devices can communicate with a DHCP server. A DHCP server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Other processes and devices, many that already send and receive DHCP = format packets, sometimes need to access this information. The leasequery = protocol is designed to give these processes and devices a lightweight way to = access information that may be critical to their operation. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-05.txt - Ralph Droms=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 02:25:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21266; Wed, 22 Oct 2003 02:25:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCQY-0002u4-NR; Wed, 22 Oct 2003 02:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCQ7-0002oj-DM for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 02:24:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20120 for ; Wed, 22 Oct 2003 02:24:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACCQ3-0000nc-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 02:24:31 -0400 Received: from ns.hirschmann.ch ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1ACCQ2-0000nW-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 02:24:30 -0400 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119059>; Wed, 22 Oct 2003 08:18:36 +0200 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Wed, 22 Oct 2003 08:21:14 +0200 Message-ID: From: "Rentschler, Markus" To: Soohong Daniel Park , dhcwg@ietf.org Cc: "'Bernie Volz'" Subject: AW: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Date: Wed, 22 Oct 2003 08:21:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Daniel, I dont't see the need to modify the current messages.=20 It's just to use one of the currently unused bits in the "flags" field, = as it is done for example in the dhc-leasequery-draft with the = "RESERVATION FLAG". Since the rapidreply feature does in fact determine a different = protocol to be run (two message instead of four message exchange), IMHO the better = place for such an important thing is at the beginning of the packet, not = somewhere at the end. From my understanding, the options should rather be used to transport configuration information, not to determine the type of protocol that = should be run.=20 And it would save space in the DHCP packet itself... Comments welcome! Regards, =20 Markus Rentschler Hirschmann Electronics GmbH & Co. KG > -----Urspr=FCngliche Nachricht----- > Von: Soohong Daniel Park [SMTP:soohong.park@samsung.com] > Gesendet am: Mittwoch, 22. Oktober 2003 02:53 > An: 'Rentschler, Markus'; dhcwg@ietf.org > Cc: 'Bernie Volz' > Betreff: RE: [dhcwg] FW: I-D > ACTION:draft-volz-dhc-rapidreply-opt-00.txt >=20 > Hello Markus >=20 > For the flags, we have to modify the current messages.=20 > To avoid this modification, I thought the new option would=20 > be better to support this function. =20 >=20 > Am I missing anything ? >=20 > Comments welcome..! >=20 >=20 > Regards >=20 > Daniel (Soohong Daniel Park) > Mobile Platform Laboratory, SAMSUNG Electronics=20 >=20 > > -----Original Message----- > > From: Rentschler, Markus [mailto:mrentsch@nt.hirschmann.de]=20 > > Sent: Tuesday, October 21, 2003 10:33 PM > > To: dhcwg@ietf.org > > Cc: Soohong Daniel Park > > Subject: AW: [dhcwg] FW: I-D=20 > > ACTION:draft-volz-dhc-rapidreply-opt-00.txt > >=20 > >=20 > > Hello, > >=20 > > wouldn't it be better to reserve a bit in the "flags" field=20 > > for that purpose ? > >=20 > >=20 > > Regards, > >=20 > > Markus Rentschler > > Hirschmann Electronics GmbH & Co. KG > > =20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Soohong Daniel Park [SMTP:soohong.park@samsung.com] > > > Gesendet am: Dienstag, 21. Oktober 2003 01:48 > > > An: dhcwg@ietf.org > > > Betreff: [dhcwg] FW: I-D=20 > > ACTION:draft-volz-dhc-rapidreply-opt-00.txt > > >=20 > > > Hello dhc > > >=20 > > > Please see the "Rapid Reply Option for DHCPv4" I-D announcement=20 > > > below... > > >=20 > > > Abstract > > > =20 > > > This document defines a new option, modeled on the IPv6 option = for=20 > > > getting IP address and configuration information rapidly=20 > > which can be=20 > > > used for detecting network attachment when client moves to=20 > > a new link. > > >=20 > > >=20 > > >=20 > > >=20 > > > Regards > > >=20 > > > Daniel (Soohong Daniel Park) > > > Mobile Platform Laboratory, SAMSUNG Electronics > > >=20 > > > > -----Original Message----- > > > > From: owner-ietf-announce@ietf.org > > > > [ ] On Behalf Of=20 > > > > Internet-Drafts@ietf.org > > > > Sent: Tuesday, October 21, 2003 4:43 AM > > > > To: IETF-Announce: > > > > Subject: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line=20 > > Internet-Drafts=20 > > > > directories. > > > > > > > > > > > > Title : Rapid Reply Option for DHCPv4 > > > > Author(s) : S. Park, et. al. > > > > Filename : draft-volz-dhc-rapidreply-opt-00.txt > > > > Pages : 7 > > > > Date : 2003-10-20 > > > > =20 > > > > This document defines a new option, modeled on the IPv6=20 > > option for=20 > > > > getting IP address and configuration information rapidly=20 > > which can=20 > > > > be used for detecting network attachment when client=20 > > moves to a new=20 > > > > link. > > > > > > > > A URL for this Internet-Draft is: > > >=20 > = > txt> > >=20 > > To remove yourself from the IETF Announcement list, send a message = to=20 > > ietf-announce-request with the word unsubscribe in the body of the=20 > > message. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the = > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then > > "get draft-volz-dhc-rapidreply-opt-00.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > or=20 > > > >=20 > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE = /internet-drafts/draft-volz-dhc-rapidreply-opt-00.txt". > > =20 > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use = this > > feature, insert the command "ENCODING mime" before the = "FILE" > > command. To decode the response(s), you will need = "munpack" > or > > a MIME-compliant mail reader. Different MIME-compliant = mail=20 > > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been > split > > up into multiple messages), so check your local = documentation > on > > how to manipulate these messages. > > =20 > > =20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 > > << Datei: ATT00156.txt >> << Datei:=20 > > draft-volz-dhc-rapidreply-opt-00.txt > > >>=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 02:36:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26114; Wed, 22 Oct 2003 02:36:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCbB-0006Wf-HH; Wed, 22 Oct 2003 02:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACCb9-0006Vg-GX for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 02:35:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26097 for ; Wed, 22 Oct 2003 02:35:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACCb5-000108-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 02:35:55 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ACCb5-000105-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 02:35:55 -0400 Received: from fugue.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id CA83B1B215C; Wed, 22 Oct 2003 01:32:11 -0500 (CDT) Date: Tue, 21 Oct 2003 23:36:00 -0700 Subject: Re: AW: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org To: "Rentschler, Markus" From: Ted Lemon In-Reply-To: Message-Id: <000B367E-045A-11D8-9907-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, October 21, 2003, at 11:21 PM, Rentschler, Markus wrote: > Since the rapidreply feature does in fact determine a different > protocol to > be run (two message instead of four message exchange), IMHO the better > place > for such an important thing is at the beginning of the packet, not > somewhere > at the end. This isn't a meaningful distinction. You already have to decode the option buffer to figure out what kind of DHCP packet it is, so there's no extra cost associated with this - by the time you make the kind of decision you're talking about, the option buffer has already been decoded. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 04:00:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28149; Wed, 22 Oct 2003 04:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACDuS-0004bC-Uw; Wed, 22 Oct 2003 04:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACDu1-0004Ww-GM for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 03:59:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28113 for ; Wed, 22 Oct 2003 03:59:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACDty-0001iW-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 03:59:30 -0400 Received: from ns.hirschmann.ch ([149.218.112.4] helo=hirschmann.de) by ietf-mx with esmtp (Exim 4.12) id 1ACDtx-0001hr-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 03:59:30 -0400 Received: from merkur.hirschmann.de ([149.218.20.87]) by gw.hirschmann.de with ESMTP id <119046>; Wed, 22 Oct 2003 09:53:35 +0200 Received: by merkur.hirschmann.de with Internet Mail Service (5.5.2655.55) id ; Wed, 22 Oct 2003 09:56:13 +0200 Message-ID: From: "Rentschler, Markus" To: Ted Lemon Cc: dhcwg@ietf.org Subject: AW: AW: [dhcwg] FW: I-D ACTION:draft-volz-dhc-rapidreply-opt-00.t xt Date: Wed, 22 Oct 2003 09:56:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I agree with that. Regards, Markus Rentschler > -----Urspr=FCngliche Nachricht----- > Von: Ted Lemon [SMTP:mellon@fugue.com] > Gesendet am: Mittwoch, 22. Oktober 2003 08:36 > An: Rentschler, Markus > Cc: dhcwg@ietf.org > Betreff: Re: AW: [dhcwg] FW: I-D > ACTION:draft-volz-dhc-rapidreply-opt-00.txt >=20 > On Tuesday, October 21, 2003, at 11:21 PM, Rentschler, Markus wrote: > > Since the rapidreply feature does in fact determine a different=20 > > protocol to > > be run (two message instead of four message exchange), IMHO the = better=20 > > place > > for such an important thing is at the beginning of the packet, not=20 > > somewhere > > at the end. >=20 > This isn't a meaningful distinction. You already have to decode the=20 > option buffer to figure out what kind of DHCP packet it is, so = there's=20 > no extra cost associated with this - by the time you make the kind of = > decision you're talking about, the option buffer has already been=20 > decoded. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 08:59:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06958; Wed, 22 Oct 2003 08:59:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIZp-0000lQ-04; Wed, 22 Oct 2003 08:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACIZQ-0000h7-JW for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 08:58:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06915 for ; Wed, 22 Oct 2003 08:58:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACIZP-0004oO-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 08:58:35 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ACIZO-0004nv-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 08:58:34 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 22 Oct 2003 06:00:01 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9MCw1FH000296 for ; Wed, 22 Oct 2003 08:58:01 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ10799; Wed, 22 Oct 2003 08:58:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022070345.049bb0b8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 08:58:00 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-agentopt-radius-03.txt (SECOND REQUEST) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , SECOND REQUEST - To date, the only response to this WG last call has been the chair's review of the document. If enough responses are not received to support the acceptance of this document, it *will not* be submitted to the IESG for publication. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. ----- This message announces a WG last call on "RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option" . The last call will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-agentopt-radius-03.txt provides a way through which network elements can pass information obtained through layer 2 authentication to a DHCP server. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access that would be used with draft-ietf-dhc-agentopt-radius-03.txt. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-03.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 09:59:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09310; Wed, 22 Oct 2003 09:59:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJVt-0006WK-08; Wed, 22 Oct 2003 09:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJVa-0006Td-QL for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 09:58:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09247 for ; Wed, 22 Oct 2003 09:58:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJVY-0005Yh-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 09:58:40 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ACJVY-0005Y9-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 09:58:40 -0400 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2003 15:56:10 +0200 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9MDw1j0016796 for ; Wed, 22 Oct 2003 06:58:06 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ15495; Wed, 22 Oct 2003 09:58:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022070715.00ba7ee8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 09:58:00 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , SECOND REQUEST - To date, the only response to this WG last call has been the chair's review of the document. If enough responses are not received to support the acceptance of this document, it *will not* be submitted to the IESG for publication. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. ----- This message announces a WG last call on "DHCP Option for Mobile IP Mobility Agents" . The last call will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the Mobility Agent Option, and two sub-options of the Mobility Agent Option: the Network Access Identifier Sub-Option, which provides identifying information about a DHCP client to the DHCP server and the Mobility Agent Announcement sub-option, which announces the address of one or more mobility agents available to a host. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 10:07:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09994; Wed, 22 Oct 2003 10:07:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJdd-0008Cq-3e; Wed, 22 Oct 2003 10:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJdZ-0008BX-LK for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 10:06:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09908 for ; Wed, 22 Oct 2003 10:06:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJdX-0005g3-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:06:55 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ACJdX-0005fq-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:06:55 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 22 Oct 2003 07:07:19 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9ME6IjR008148; Wed, 22 Oct 2003 07:06:22 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.180]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ16240; Wed, 22 Oct 2003 10:06:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022100510.025829d8@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 10:06:16 -0400 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-agentopt-radius-03.txt (SECOND REQUEST) Cc: kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20031022070345.049bb0b8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ralph, I support this document moving forward. Kim At 08:58 AM 10/22/2003, Ralph Droms wrote: >SECOND REQUEST - To date, the only response to this WG last call has been >the chair's review of the document. If enough responses are not received to >support the acceptance of this document, it *will not* be submitted to the >IESG for publication. Please respond to this WG last call. If you support >acceptance of the document without change, respond with a simple >acknowledgment, so that support for the document can be assessed. > >----- >This message announces a WG last call on "RADIUS Attributes Sub-option for >the DHCP Relay Agent Information Option" >. The >last call will conclude at 5PM ET on Friday, 10/24/2003. > >Please respond to this WG last call. If you support acceptance of the >document without change, respond with a simple acknowledgment, so that >support for the document can be assessed. > >draft-ietf-dhc-agentopt-radius-03.txt provides a way through which network >elements can pass information obtained through layer 2 authentication to a >DHCP server. The IEEE 802.1X protocol is an example of a mechanism for >providing authenticated layer 2 network access that would be used with >draft-ietf-dhc-agentopt-radius-03.txt. This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-03.txt > >- Ralph Droms > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 10:18:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11252; Wed, 22 Oct 2003 10:18:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJoH-0002LS-2L; Wed, 22 Oct 2003 10:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJoG-0002LD-1d for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 10:18:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11213 for ; Wed, 22 Oct 2003 10:17:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJoD-0005nC-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:17:57 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ACJoD-0005n1-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:17:57 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9MEHNFH015628; Wed, 22 Oct 2003 10:17:23 -0400 (EDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.180]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ17187; Wed, 22 Oct 2003 10:17:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022101400.0257fdb8@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 10:17:21 -0400 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) In-Reply-To: <4.3.2.7.2.20031022070715.00ba7ee8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ralph, I support this document moving forward, with one small reservation. I don't see the value in having zero length suboptions. I don't think we generally allow them (though someone will doubtless correct me if I'm wrong). If there is some valid, semantically interesting reason for allowing zero length suboptions, then I think the meaning should be spelled out, otherwise I think they should be disallowed. Kim At 09:58 AM 10/22/2003, Ralph Droms wrote: >SECOND REQUEST - To date, the only response to this WG last call has been >the chair's review of the document. If enough responses are not received to >support the acceptance of this document, it *will not* be submitted to the >IESG for publication. Please respond to this WG last call. If you support >acceptance of the document without change, respond with a simple >acknowledgment, so that support for the document can be assessed. > >----- >This message announces a WG last call on "DHCP Option for Mobile IP Mobility >Agents" . The last call will conclude >at 5PM ET on Friday, 10/24/2003. > >Please respond to this WG last call. If you support acceptance of the >document without change, respond with a simple acknowledgment, so that >support for the document can be assessed. > >draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the >Mobility Agent Option, and two sub-options of the Mobility Agent Option: the >Network Access Identifier Sub-Option, which provides >identifying information about a DHCP client to the DHCP server and the >Mobility Agent Announcement sub-option, which announces the address of one >or more mobility agents available to a host. This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt > >- Ralph Droms > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 10:24:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11501; Wed, 22 Oct 2003 10:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJu5-0003pw-Dk; Wed, 22 Oct 2003 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACJtb-0003mT-Pk for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 10:23:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11469 for ; Wed, 22 Oct 2003 10:23:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACJtZ-0005rn-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:23:29 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ACJtY-0005r7-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:23:29 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Oct 2003 07:20:08 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9MEMrQY001473; Wed, 22 Oct 2003 07:22:53 -0700 (PDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.180]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ17762; Wed, 22 Oct 2003 10:22:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022101754.02585ec0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 10:22:51 -0400 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt Cc: kkinnear@cisco.com, andre@incognito.com In-Reply-To: <4.3.2.7.2.20031021083132.04816730@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ralph, I think this document should move forward. But that's no surprise. I do want to mention an issue which was raised by Andre Kostur which we will want to fix along with any other issues raised in last call. In email to this list on 22 Sept 2003, Andre pointed out that it the draft says that T1 and T2 (renewal and rebinding times) are supposed to be handled the same as the lease time -- but that while the lease time can't have passed if there is an active lease, the renewal and rebinding times can certainly be in the past, even though the lease has not yet expired. I propose that we say that these options will not be returned if they are already passed. He also points out a typo which needs to be fixed. Other than that, I think the document is ready to go. Cheers -- Kim At 08:34 AM 10/21/2003, Ralph Droms wrote: >This message announces a WG last call on "DHCP Lease Query" >. The last call will conclude at 5PM ET >on Friday, 10/31/2003. > >Please respond to this WG last call. If you support acceptance of the >document without change, respond with a simple acknowledgment, so that >support for the document can be assessed. > >This document defines new messages through which devices can communicate with >a DHCP server. A DHCP server contains considerable authoritative >information concerning the IP addresses it has leased to DHCP clients. >Other processes and devices, many that already send and receive DHCP format >packets, sometimes need to access this information. The leasequery protocol >is designed to give these processes and devices a lightweight way to access >information that may be critical to their operation. This >draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-05.txt > >- Ralph Droms > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 10:33:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12083; Wed, 22 Oct 2003 10:33:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACK2m-00069r-VA; Wed, 22 Oct 2003 10:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACK2L-00064Z-Ld for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 10:32:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12052 for ; Wed, 22 Oct 2003 10:32:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACK2J-000640-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:32:31 -0400 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1ACK2I-00063s-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:32:30 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9MEWFAr008608; Wed, 22 Oct 2003 10:32:24 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Kim Kinnear'" , "'Ralph Droms'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Date: Wed, 22 Oct 2003 10:32:32 -0400 Message-ID: <000601c398a9$57d297a0$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4.3.2.7.2.20031022101400.0257fdb8@goblet.cisco.com> Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Kim, et al: 1. I too support this document moving forward. 2. I do believe that zero length suboptions should be allowed. For = example, we're using a zero length option to request Rapid Reply (see new draft) = and if a similar request was to be used for mobile agents, why prohibit it = or require a meaningless value to be passed (such as a flag). If a new suboption is defined in the future that requests an alternative behavior = if the option is present, why require it to carry an extra meaningless = "flag" byte. In some cases having a flag byte is important since there are really = three implied settings: - Disable feature - Enable feature - Use your configured default (no option/suboption) But in others, just having the option/sub-option present is sufficient = (such as in the DHCPv6 Rapid Commit case). So, I'm in favor of leaving this in the draft. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Kim Kinnear Sent: Wednesday, October 22, 2003 10:17 AM To: Ralph Droms; dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Ralph, I support this document moving forward, with one small reservation. I don't see the value in having zero length suboptions. I don't think we generally allow them (though someone will doubtless correct me if I'm wrong). If there is some valid, semantically interesting reason for allowing zero length suboptions, then I think the meaning should be spelled out, otherwise I think they should be disallowed. Kim At 09:58 AM 10/22/2003, Ralph Droms wrote: >SECOND REQUEST - To date, the only response to this WG last call has = been >the chair's review of the document. If enough responses are not = received to >support the acceptance of this document, it *will not* be submitted to = the >IESG for publication. Please respond to this WG last call. If you = support >acceptance of the document without change, respond with a simple >acknowledgment, so that support for the document can be assessed. > >----- >This message announces a WG last call on "DHCP Option for Mobile IP Mobility >Agents" . The last call will = conclude >at 5PM ET on Friday, 10/24/2003. > >Please respond to this WG last call. If you support acceptance of the >document without change, respond with a simple acknowledgment, so that >support for the document can be assessed. > >draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called = the >Mobility Agent Option, and two sub-options of the Mobility Agent = Option: the >Network Access Identifier Sub-Option, which provides >identifying information about a DHCP client to the DHCP server and the >Mobility Agent Announcement sub-option, which announces the address of = one >or more mobility agents available to a host. This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt > >- Ralph Droms=20 > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 10:43:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12506; Wed, 22 Oct 2003 10:43:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKCS-0000Bi-NV; Wed, 22 Oct 2003 10:43:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKCG-00009H-UV for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 10:42:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12485 for ; Wed, 22 Oct 2003 10:42:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKCE-0006Cy-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:42:46 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ACKCD-0006Cj-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:42:46 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 22 Oct 2003 07:44:13 -0700 Received: from jschnizl-w2k.cisco.com (rtp-vpn2-670.cisco.com [10.82.242.158]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9MEgCFI021282; Wed, 22 Oct 2003 10:42:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022104102.02736d40@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 10:41:54 -0400 To: Ralph Droms From: John Schnizlein Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20031021083132.04816730@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 08:34 AM 10/21/2003, Ralph Droms wrote: >This message announces a WG last call on "DHCP Lease Query" >. The last call will conclude at 5PM ET >on Friday, 10/31/2003. I support this document going forward to RFC. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 10:49:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12717; Wed, 22 Oct 2003 10:49:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKIH-0001KB-4Q; Wed, 22 Oct 2003 10:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKHi-0001Dz-4n for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 10:48:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12651 for ; Wed, 22 Oct 2003 10:48:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKHf-0006HX-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:48:23 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1ACKHf-0006HI-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:48:23 -0400 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1ACKH2-0007Rc-00; Wed, 22 Oct 2003 07:47:44 -0700 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5VQCM>; Wed, 22 Oct 2003 07:47:23 -0700 Message-ID: From: "Kostur, Andre" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt Date: Wed, 22 Oct 2003 07:47:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C398AB.667132B0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C398AB.667132B0 Content-Type: text/plain; charset="iso-8859-1" > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. Other than my aforementioned two changes, I support the document moving forward. ------_=_NextPart_001_01C398AB.667132B0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt

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

Other than my aforementioned two changes, I support the document moving forward.

------_=_NextPart_001_01C398AB.667132B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 10:52:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12909; Wed, 22 Oct 2003 10:52:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKLB-0001tt-2m; Wed, 22 Oct 2003 10:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKKD-0001gQ-Ox for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 10:51:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12821 for ; Wed, 22 Oct 2003 10:50:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKKB-0006Ju-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:50:59 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ACKKA-0006JW-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:50:58 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 22 Oct 2003 07:52:26 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9MEoPN0016681; Wed, 22 Oct 2003 10:50:25 -0400 (EDT) Received: from mjs-xp.cisco.com ([161.44.65.119]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ20588; Wed, 22 Oct 2003 10:50:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022105001.01d8b640@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 10:50:45 -0400 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-agentopt-radius-03.txt (SECOND REQUEST) Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20031022070345.049bb0b8@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I would like to see this draft progress on the standards track. At 08:58 AM 10/22/2003 -0400, Ralph Droms wrote: >SECOND REQUEST - To date, the only response to this WG last call has been >the chair's review of the document. If enough responses are not received to >support the acceptance of this document, it *will not* be submitted to the >IESG for publication. Please respond to this WG last call. If you support >acceptance of the document without change, respond with a simple >acknowledgment, so that support for the document can be assessed. > >----- >This message announces a WG last call on "RADIUS Attributes Sub-option for >the DHCP Relay Agent Information Option" >. The >last call will conclude at 5PM ET on Friday, 10/24/2003. > >Please respond to this WG last call. If you support acceptance of the >document without change, respond with a simple acknowledgment, so that >support for the document can be assessed. > >draft-ietf-dhc-agentopt-radius-03.txt provides a way through which network >elements can pass information obtained through layer 2 authentication to a >DHCP server. The IEEE 802.1X protocol is an example of a mechanism for >providing authenticated layer 2 network access that would be used with >draft-ietf-dhc-agentopt-radius-03.txt. This draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-03.txt > >- Ralph Droms > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 10:53:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13076; Wed, 22 Oct 2003 10:53:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKM9-0002BS-Po; Wed, 22 Oct 2003 10:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKM0-00028H-Vl for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 10:52:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13006 for ; Wed, 22 Oct 2003 10:52:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKLx-0006NG-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:52:50 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ACKLx-0006MG-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:52:49 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 22 Oct 2003 07:53:14 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9MEqDQa005957; Wed, 22 Oct 2003 07:52:16 -0700 (PDT) Received: from mjs-xp.cisco.com ([161.44.65.119]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ20766; Wed, 22 Oct 2003 10:52:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022105217.01cd59e0@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 10:52:33 -0400 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20031021083132.04816730@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I support this draft and would like to see it progress. -- Mark At 08:34 AM 10/21/2003 -0400, Ralph Droms wrote: >This message announces a WG last call on "DHCP Lease Query" >. The last call will conclude at 5PM ET >on Friday, 10/31/2003. > >Please respond to this WG last call. If you support acceptance of the >document without change, respond with a simple acknowledgment, so that >support for the document can be assessed. > >This document defines new messages through which devices can communicate with >a DHCP server. A DHCP server contains considerable authoritative >information concerning the IP addresses it has leased to DHCP clients. >Other processes and devices, many that already send and receive DHCP format >packets, sometimes need to access this information. The leasequery protocol >is designed to give these processes and devices a lightweight way to access >information that may be critical to their operation. This >draft is available as >http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-05.txt > >- Ralph Droms > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 10:55:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13206; Wed, 22 Oct 2003 10:55:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKO6-0002gi-L9; Wed, 22 Oct 2003 10:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKNs-0002dC-UZ for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 10:54:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13176 for ; Wed, 22 Oct 2003 10:54:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKNq-0006Pg-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:54:46 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1ACKNp-0006Ox-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 10:54:45 -0400 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id h9MEsD0m020121; Wed, 22 Oct 2003 16:54:13 +0200 Date: Wed, 22 Oct 2003 16:54:14 +0200 From: Henrik Levkowetz Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Message-Id: <20031022165414.0c004210.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20031022070715.00ba7ee8@flask.cisco.com> References: <4.3.2.7.2.20031022070715.00ba7ee8@flask.cisco.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I don't know how much weight it carries (as I'm the author) but I do support this document moving forward. Henrik On Wednesday, 22 Oct 2003, Ralph wrote: > SECOND REQUEST - To date, the only response to this WG last call has been > the chair's review of the document. If enough responses are not received to > support the acceptance of this document, it *will not* be submitted to the > IESG for publication. Please respond to this WG last call. If you support > acceptance of the document without change, respond with a simple > acknowledgment, so that support for the document can be assessed. > > ----- > This message announces a WG last call on "DHCP Option for Mobile IP Mobility > Agents" . The last call will conclude > at 5PM ET on Friday, 10/24/2003. > > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. > > draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the > Mobility Agent Option, and two sub-options of the Mobility Agent Option: the > Network Access Identifier Sub-Option, which provides > identifying information about a DHCP client to the DHCP server and the > Mobility Agent Announcement sub-option, which announces the address of one > or more mobility agents available to a host. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt > > - Ralph Droms > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg Henrik -- What a wonderful world it is that has girls in it! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 11:08:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13714; Wed, 22 Oct 2003 11:08:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKaf-000532-IT; Wed, 22 Oct 2003 11:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKZz-0004mV-OK for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 11:07:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13686 for ; Wed, 22 Oct 2003 11:07:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKZx-0006YM-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:07:17 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ACKZw-0006YE-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:07:16 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9MF6gFH027054; Wed, 22 Oct 2003 11:06:43 -0400 (EDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.180]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ22570; Wed, 22 Oct 2003 11:06:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022104618.024115b0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 11:06:41 -0400 To: "Bernie Volz" , "'Kim Kinnear'" , "'Ralph Droms'" , From: Kim Kinnear Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) In-Reply-To: <000601c398a9$57d297a0$6601a8c0@BVolz> References: <4.3.2.7.2.20031022101400.0257fdb8@goblet.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 10:32 AM 10/22/2003, Bernie Volz wrote: >Kim, et al: > >1. I too support this document moving forward. > >2. I do believe that zero length suboptions should be allowed. For example, >we're using a zero length option to request Rapid Reply (see new draft) and >if a similar request was to be used for mobile agents, why prohibit it or >require a meaningless value to be passed (such as a flag). If a new >suboption is defined in the future that requests an alternative behavior if >the option is present, why require it to carry an extra meaningless "flag" >byte. > >In some cases having a flag byte is important since there are really three >implied settings: >- Disable feature >- Enable feature >- Use your configured default (no option/suboption) > >But in others, just having the option/sub-option present is sufficient (such >as in the DHCPv6 Rapid Commit case). > >So, I'm in favor of leaving this in the draft. Well ... I didn't say that I think zero length options (or in this case, suboptions) are terrible. Just a little confusing. My more thoughtful position (which I don't believe conflicts with Bernie's, but he may have a different response) is as follows: -------------- If there is some semantic content to a zero length (in this case sub-option), then I believe that it should be spelled out in the draft as specifically allowed, and the semantic content of the zero length suboption should be explicitly defined. Otherwise, I believe that zero length suboptions should not be allowed. To put this another way -- if you want to allow a zero length suboption (or option, in another draft), I think that you should be required to explicitly state that it *is* allowed, and you should be required to state what it means if it shows up with zero length. ------------------- The rapid response draft follows these guidelines, since it explicitly says what to do with a zero length option. My (small) quarrel with the mipadvert draft is that it says: The Mobility Agent Information field shall NOT be terminated with a 255 sub-option. The length N of the DHCP Mobility Agent Information Option shall include all bytes of the sub-option code/length/value tuples. Since at least one sub-option must be defined, the minimum Mobility Agent Information length is two (2). The length N of the sub-options shall be the number of octets in only that sub-option's value field. A sub-option length may be zero. The sub-options need not appear in sub-option code order. I think that the sentence: "A sub-option length may be zero." should be replaced with the following: "A sub-option length may not be zero unless the specification of the sub-option explicitly allows a zero length sub-option, and in this case the meaning of the zero length sub-option MUST be made explicit." That's all -- still kind of a nit. Cheers -- Kim >- Bernie > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Kim >Kinnear >Sent: Wednesday, October 22, 2003 10:17 AM >To: Ralph Droms; dhcwg@ietf.org >Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt >(SECOND REQUEST) > > >Ralph, > >I support this document moving forward, with one small >reservation. > >I don't see the value in having zero length suboptions. I don't >think we generally allow them (though someone will doubtless >correct me if I'm wrong). If there is some valid, semantically >interesting reason for allowing zero length suboptions, then I >think the meaning should be spelled out, otherwise I think they >should be disallowed. > > >Kim > > >At 09:58 AM 10/22/2003, Ralph Droms wrote: >>SECOND REQUEST - To date, the only response to this WG last call has been >>the chair's review of the document. If enough responses are not received >to >>support the acceptance of this document, it *will not* be submitted to the >>IESG for publication. Please respond to this WG last call. If you support >>acceptance of the document without change, respond with a simple >>acknowledgment, so that support for the document can be assessed. >> >>----- >>This message announces a WG last call on "DHCP Option for Mobile IP >Mobility >>Agents" . The last call will conclude >>at 5PM ET on Friday, 10/24/2003. >> >>Please respond to this WG last call. If you support acceptance of the >>document without change, respond with a simple acknowledgment, so that >>support for the document can be assessed. >> >>draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the >>Mobility Agent Option, and two sub-options of the Mobility Agent Option: >the >>Network Access Identifier Sub-Option, which provides >>identifying information about a DHCP client to the DHCP server and the >>Mobility Agent Announcement sub-option, which announces the address of one >>or more mobility agents available to a host. This draft is available as >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt >> >>- Ralph Droms >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/dhcwg > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 11:11:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13807; Wed, 22 Oct 2003 11:11:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKda-0005XE-K7; Wed, 22 Oct 2003 11:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKdC-0005U0-Kl for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 11:10:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13792 for ; Wed, 22 Oct 2003 11:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKd9-0006a8-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:10:36 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ACKd9-0006Zz-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:10:35 -0400 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 22 Oct 2003 17:08:02 +0200 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9MF9tj0004773 for ; Wed, 22 Oct 2003 08:09:58 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ22919; Wed, 22 Oct 2003 11:09:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022070808.049ed6c8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 11:09:00 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-pxe-options-00.txt (SECOND REQUEST) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , SECOND REQUEST - To date, the only responses to this WG last call have been the chair's review of the document and a response in support of submitting the document for publication. If enough responses are not received to support the acceptance of this document, it *will not* be submitted to the IESG for publication. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. ----- This message announces a WG last call on "DHCP Preboot eXecution Environment (PXE) Suboptions" . The last call will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-pxe-options-00.txt documents three DHCP options that are in common use by PXE. These options uniquely identify booting client machines and their pre-OS runtime environment so the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-pxe-options-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 11:17:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13997; Wed, 22 Oct 2003 11:17:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKjN-0006E6-L5; Wed, 22 Oct 2003 11:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKj7-0006Co-BB for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 11:16:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13982 for ; Wed, 22 Oct 2003 11:16:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKj6-0006eA-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:16:44 -0400 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1ACKj5-0006e7-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:16:43 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9MFGXGn087716; Wed, 22 Oct 2003 11:16:36 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ralph Droms'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-pxe-options-00.txt (SECOND REQUEST) Date: Wed, 22 Oct 2003 11:16:52 -0400 Message-ID: <000601c398af$85b44af0$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <4.3.2.7.2.20031022070808.049ed6c8@flask.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Other than my earlier comments, mostly on changing "suboption" to = "option" in the draft (which Ralph also agreed with), I would like to see this = draft advance. There are apparently also options in the site-specific options space = being used by PXE (128-133 if I recall the numbers correctly) and perhaps = these should be documented as well. Perhaps in another draft since they are outside the scope of the "IETF" options space - though if the extended options draft is advanced and goes with the idea of reclaiming some of = the site-specific options space, these other PXE options may also be part of = the IETF options space. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ralph Droms Sent: Wednesday, October 22, 2003 11:09 AM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-pxe-options-00.txt = (SECOND REQUEST) SECOND REQUEST - To date, the only responses to this WG last call have = been the chair's review of the document and a response in support of = submitting the document for publication. If enough responses are not received to support the acceptance of this document, it *will not* be submitted to = the IESG for publication. Please respond to this WG last call. If you = support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. ----- This message announces a WG last call on "DHCP Preboot eXecution = Environment (PXE) Suboptions" . The last call = will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-pxe-options-00.txt documents three DHCP options that are = in common use by PXE. These options uniquely identify booting client = machines and their pre-OS runtime environment so the DHCP and/or PXE boot server = can return the correct OS bootstrap image (or pre-boot application) name and server to the client. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-pxe-options-00.txt - Ralph Droms=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 11:19:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14097; Wed, 22 Oct 2003 11:19:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKlJ-0006Vb-GU; Wed, 22 Oct 2003 11:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKkg-0006Rd-R8 for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 11:18:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14071 for ; Wed, 22 Oct 2003 11:18:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKkf-0006fc-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:18:21 -0400 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1ACKkf-0006fZ-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:18:21 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9MFHiAr018898; Wed, 22 Oct 2003 11:17:52 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Kim Kinnear'" , "'Ralph Droms'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Date: Wed, 22 Oct 2003 11:18:03 -0400 Message-ID: <000701c398af$b32e98a0$6601a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <4.3.2.7.2.20031022104618.024115b0@goblet.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sorry for the misunderstanding. I have no issue with clarifying the language. - Bernie -----Original Message----- From: Kim Kinnear [mailto:kkinnear@cisco.com]=20 Sent: Wednesday, October 22, 2003 11:07 AM To: Bernie Volz; 'Kim Kinnear'; 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) At 10:32 AM 10/22/2003, Bernie Volz wrote: >Kim, et al: > >1. I too support this document moving forward. > >2. I do believe that zero length suboptions should be allowed. For = example, >we're using a zero length option to request Rapid Reply (see new draft) = and >if a similar request was to be used for mobile agents, why prohibit it = or >require a meaningless value to be passed (such as a flag). If a new >suboption is defined in the future that requests an alternative = behavior if >the option is present, why require it to carry an extra meaningless = "flag" >byte. > >In some cases having a flag byte is important since there are really = three >implied settings: >- Disable feature >- Enable feature >- Use your configured default (no option/suboption) > >But in others, just having the option/sub-option present is sufficient (such >as in the DHCPv6 Rapid Commit case). > >So, I'm in favor of leaving this in the draft. Well ... I didn't say that I think zero length options (or in this case, suboptions) are terrible. Just a little confusing. My more thoughtful position (which I don't believe conflicts with Bernie's, but he may have a different response) is as follows: -------------- If there is some semantic content to a zero length (in this case sub-option), then I believe that it should be spelled out in the draft as specifically allowed, and the semantic content of the zero length suboption should be explicitly defined. Otherwise, I believe that zero length suboptions should not be allowed. To put this another way -- if you want to allow a zero length suboption (or option, in another draft), I think that you should be required to explicitly state that it *is* allowed, and you should be required to state what it means if it shows up with zero length. ------------------- The rapid response draft follows these guidelines, since it explicitly says what to do with a zero length option. My (small) quarrel with the mipadvert draft is that it says: The Mobility Agent Information field shall NOT be terminated with a 255 sub-option. The length N of the DHCP Mobility Agent Information Option shall include all bytes of the sub-option code/length/value tuples. Since at least one sub-option must be defined, the minimum Mobility Agent Information length is two (2). The length N of the sub-options shall be the number of octets in only that sub-option's value field. A sub-option length may be zero. The sub-options need not appear in sub-option code order. I think that the sentence: "A sub-option length may be zero." should be replaced with the following: "A sub-option length may not be zero unless the specification of the sub-option explicitly allows a zero length sub-option, and in this case the meaning of the zero length sub-option MUST be made explicit." That's all -- still kind of a nit. Cheers -- Kim >- Bernie > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Kim >Kinnear >Sent: Wednesday, October 22, 2003 10:17 AM >To: Ralph Droms; dhcwg@ietf.org >Subject: Re: [dhcwg] WG last call on = draft-ietf-dhc-mipadvert-opt-01.txt >(SECOND REQUEST) > > >Ralph, > >I support this document moving forward, with one small >reservation. > >I don't see the value in having zero length suboptions. I don't >think we generally allow them (though someone will doubtless >correct me if I'm wrong). If there is some valid, semantically >interesting reason for allowing zero length suboptions, then I >think the meaning should be spelled out, otherwise I think they >should be disallowed. > > >Kim > > >At 09:58 AM 10/22/2003, Ralph Droms wrote: >>SECOND REQUEST - To date, the only response to this WG last call has = been >>the chair's review of the document. If enough responses are not = received >to >>support the acceptance of this document, it *will not* be submitted to = the >>IESG for publication. Please respond to this WG last call. If you support >>acceptance of the document without change, respond with a simple >>acknowledgment, so that support for the document can be assessed. >> >>----- >>This message announces a WG last call on "DHCP Option for Mobile IP >Mobility >>Agents" . The last call will conclude >>at 5PM ET on Friday, 10/24/2003. >> >>Please respond to this WG last call. If you support acceptance of the >>document without change, respond with a simple acknowledgment, so that >>support for the document can be assessed. >> >>draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called = the >>Mobility Agent Option, and two sub-options of the Mobility Agent = Option: >the >>Network Access Identifier Sub-Option, which provides >>identifying information about a DHCP client to the DHCP server and the >>Mobility Agent Announcement sub-option, which announces the address of = one >>or more mobility agents available to a host. This draft is available = as >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt= >> >>- Ralph Droms=20 >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/dhcwg > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 11:28:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14384; Wed, 22 Oct 2003 11:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKu1-0007bx-Gw; Wed, 22 Oct 2003 11:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACKtl-0007Zh-AB for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 11:27:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14349 for ; Wed, 22 Oct 2003 11:27:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACKtk-0006k2-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:27:44 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1ACKtj-0006jw-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:27:43 -0400 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id h9MFR30m020814; Wed, 22 Oct 2003 17:27:03 +0200 Date: Wed, 22 Oct 2003 17:27:02 +0200 From: Henrik Levkowetz To: Kim Kinnear Cc: "Bernie Volz" , "'Ralph Droms'" , Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Message-Id: <20031022172702.6f2d27c4.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20031022104618.024115b0@goblet.cisco.com> References: <4.3.2.7.2.20031022101400.0257fdb8@goblet.cisco.com> <4.3.2.7.2.20031022104618.024115b0@goblet.cisco.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, 22 Oct 2003, Kim wrote: > My (small) quarrel with the mipadvert draft is that it > says: > > The Mobility Agent Information field shall NOT be terminated with a > 255 sub-option. The length N of the DHCP Mobility Agent Information > Option shall include all bytes of the sub-option code/length/value > tuples. Since at least one sub-option must be defined, the minimum > Mobility Agent Information length is two (2). The length N of the > sub-options shall be the number of octets in only that sub-option's > value field. A sub-option length may be zero. The sub-options need > not appear in sub-option code order. > > I think that the sentence: "A sub-option length may be > zero." should be replaced with the following: > > "A sub-option length may not be zero unless the > specification of the sub-option explicitly allows a zero > length sub-option, and in this case the meaning of the > zero length sub-option MUST be made explicit." This makes sense to me, and (supposing it is deemed that the draft can go forward) I'll update it accordingly. Henrik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 11:51:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15257; Wed, 22 Oct 2003 11:51:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLGH-0002DU-2Q; Wed, 22 Oct 2003 11:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACLFv-0002Az-A5 for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 11:50:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15246 for ; Wed, 22 Oct 2003 11:50:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACLFu-00070s-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:50:38 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ACLFt-00070J-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 11:50:37 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9MFo1N4029620 for ; Wed, 22 Oct 2003 11:50:04 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ27439; Wed, 22 Oct 2003 11:50:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022070847.049bb0b8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 11:50:00 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-v4-threat-analysis-00.txt (SECOND REQUEST) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , SECOND REQUEST - To date, the only responses to this WG last call have been the chair's review of the document and a response in support of submitting the document for publication (from one of the authors of the document). If enough responses are not received to support the acceptance of this document, it *will not* be submitted to the IESG for publication. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. ----- This message announces a WG last call on "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis" . The last call will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-v4-threat-analysis-00.txt provides a comprehensive threat analysis of the Dynamic Host Configuration Protocol for use both as RFC 2131 advances from Draft Standard to Full Standard and to support the dhc WG chartered work improving the acceptance and deployment of RFC 3118. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-00.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 13:35:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18876; Wed, 22 Oct 2003 13:35:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMsw-0007eu-0f; Wed, 22 Oct 2003 13:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACMsK-0007ao-Vw for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 13:34:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18810 for ; Wed, 22 Oct 2003 13:34:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACMsI-0000IH-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 13:34:22 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ACMsI-0000ID-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 13:34:22 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 22 Oct 2003 10:31:06 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9MHXnjP012599 for ; Wed, 22 Oct 2003 10:33:50 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ38458; Wed, 22 Oct 2003 13:33:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022113355.048ba290@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 13:33:42 -0400 To: From: Ralph Droms Subject: Re: [dhcwg] Bit in "flags" field indicating option overflow? In-Reply-To: <63F107AA-0120-11D8-B14E-000A95D9C74C@fugue.com> References: <000001c3951c$36e90690$3858f93f@akhnaten> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , (written with WG chair hat on, not my employer's hat) It is inappropriate to make unsubstantiated claims about the behavior, capabilities or operational inadequacies of specific vendors' products - such as implying that Cisco's relay agent was guilty of a layering violation - on an IETF mailing list. List contributors should refrain from making such statements... - Ralph At 09:06 PM 10/17/2003 -0700, Ted Lemon wrote: >On Friday, October 17, 2003, at 07:04 PM, Rob Stevens wrote: > > > Not being in the mainstream just now, I haven't the remotest idea > > which vendors are doing what. I wish we had a forum where we could get > > specific, timely answers from vendors (whatever they manufacture). > >I seem to recall that Cisco had a weird way of doing relay that looked >like a layering violation, but I don't know if it actually was a >layering violation or just looked like it might be one. >Unfortunately, I think it is likely that many relay agents have a >layering violation in this case. > >And yes, we all wish there was such a forum. And if wishes were >horses, there'd be a lot of pollution in the streets... :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 14:00:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19949; Wed, 22 Oct 2003 14:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNH7-0003A2-QN; Wed, 22 Oct 2003 14:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNGZ-00035j-PW for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 13:59:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19876 for ; Wed, 22 Oct 2003 13:59:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNGX-0000ek-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 13:59:25 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ACNGW-0000eh-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 13:59:25 -0400 Received: from fugue.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 741C51B2099; Wed, 22 Oct 2003 12:55:34 -0500 (CDT) Date: Wed, 22 Oct 2003 12:59:27 -0500 Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-agentopt-radius-03.txt (SECOND REQUEST) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20031022070345.049bb0b8@flask.cisco.com> Message-Id: <7A5A0118-04B9-11D8-AE3E-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Urk. Sorry. I support advancing this draft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 14:03:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20144; Wed, 22 Oct 2003 14:03:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNK0-0003hL-FY; Wed, 22 Oct 2003 14:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNJJ-0003c9-Bu for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 14:02:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20099 for ; Wed, 22 Oct 2003 14:02:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNJG-0000hd-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 14:02:14 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ACNJG-0000ha-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 14:02:14 -0400 Received: from fugue.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 1192C1B2099; Wed, 22 Oct 2003 12:58:25 -0500 (CDT) Date: Wed, 22 Oct 2003 13:02:11 -0500 Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org, Ralph Droms To: Kim Kinnear From: Ted Lemon In-Reply-To: <4.3.2.7.2.20031022101400.0257fdb8@goblet.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, October 22, 2003, at 09:17 AM, Kim Kinnear wrote: > I don't see the value in having zero length suboptions. I don't > think we generally allow them (though someone will doubtless > correct me if I'm wrong). If there is some valid, semantically > interesting reason for allowing zero length suboptions, then I > think the meaning should be spelled out, otherwise I think they > should be disallowed. I agree with this. There is a precedent, but it's a big hassle to support this - it's better for the suboption to just have a boolean value. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 14:04:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20230; Wed, 22 Oct 2003 14:04:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNKz-00041V-7p; Wed, 22 Oct 2003 14:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNKJ-0003q9-QB for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 14:03:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20142 for ; Wed, 22 Oct 2003 14:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNKH-0000iP-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 14:03:17 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ACNKG-0000hv-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 14:03:17 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9MI2hN0023678 for ; Wed, 22 Oct 2003 14:02:44 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ41698; Wed, 22 Oct 2003 14:02:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022134827.048cf1a8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 14:02:39 -0400 To: From: Ralph Droms Subject: RE: [dhcwg] Bit in "flags" field indicating option overflow? In-Reply-To: <000001c3951c$36e90690$3858f93f@akhnaten> References: <000001c394af$b13230b0$6701a8c0@BVolz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , A couple of parts of this conversation aren't making any sense to me; comments in line: At 07:04 PM 10/17/2003 -0700, Rob Stevens wrote: >This question about packet fragmentation goes back a long way. >I think more than 6 years; Mike Carney (and it may have been made way >before that by unknown others) made the point that routers are not >able to simply forward the second and subsequent fragments of >BOOTP/DHCP packets because those fragments don't have the destination >address (yiaddr, chaddr, ciaddr whatever..) - those were in the first >fragment only. I don't remember ever hearing any discussion of this issue. That's not to say it didn't take place ... it's quite likely I just don't remember. But, as Rob points out, unless the router is trying to gain some small incremental performance advantage (or perhaps implementation simplicity?) by simply forwarding DHCP messages without sending them up through the stack to a forwarding daemon, a fragmented message from a client will be reassembled in the router stack, transparent to the relay agent. I do seem to remember that there was some concern that the relay agent might not have an internal buffer large enough to hold a fragmented datagram. I also remember that, as we worked on RFC 1541, we anticipated minimal DHCP client implementations that might have a small internal message buffer. >Thus routers are not simply doing IP forwarding. > >But... we knew this already because BOOTP/DHCP relay agents are the >destination IP for packets coming back from servers. So IP forwarding >was never an issue. It is more like proxying. The relay agent itself >is the destination for the IP unicast, so why wouldn't it do assembly? > >So the question is did routers, for reasons of incremental >improvements in efficiency, not bother to re-assemble datagrams to >port 67, and was that why this whole issue about not permitting >fragmentation got started. And regardless of what as done in ancient >history, what are people doing today? In fact, I don't think there is an issue about not permitting fragmentation, per se, in DHCPv4. Fragmentation is not mentioned anywhere in RFC 2131. I don't remember, in our work on DHCPv4 prior to the publication of RFC 1541, that fragmentation was ever an issue (except in the generic "fragmentation is a bad idea" sense). We did need to take some care in backward compatibility with BOOTP relay agents. We also explicitly decided against building a protocol in which a message might be carried in multiple UDP datagrams, not wanting to go down the sequencing-retransmission-congestion "reinvent TCP" rathole (anticipating the current IESG position on UDP by several years). Perhaps this avoidance of sequential UDP messages is what Mike was referring to? >Possibly the concern was the fragmentation of broadcast datagrams from >the client. They all have the source IP address of 0.0.0.0. So I >suppose there is some (minimal) chance of collisions involving the IP >datagram identification. But since clients never need to send large >packets this also seems moot. > >Not being in the mainstream just now, I haven't the remotest idea >which vendors are doing what. I wish we had a forum where we could get >specific, timely answers from vendors (whatever they manufacture). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 14:18:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20724; Wed, 22 Oct 2003 14:18:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNYX-0007QA-5f; Wed, 22 Oct 2003 14:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACNXa-000745-2o for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 14:17:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20644 for ; Wed, 22 Oct 2003 14:16:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACNXX-0000rS-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 14:16:59 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1ACNXX-0000rP-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 14:16:59 -0400 Received: from fugue.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id C6F811B2099; Wed, 22 Oct 2003 13:13:09 -0500 (CDT) Date: Wed, 22 Oct 2003 13:17:03 -0500 Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20031021083132.04816730@flask.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I support acceptance of the leasequery draft without change. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 15:14:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23193; Wed, 22 Oct 2003 15:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOQj-0004Yu-2j; Wed, 22 Oct 2003 15:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOQ6-0004KK-EP for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 15:13:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23043 for ; Wed, 22 Oct 2003 15:13:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACOQ5-0001NV-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 15:13:21 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ACOQ4-0001NL-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 15:13:20 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h9MJCleu013659 for ; Wed, 22 Oct 2003 12:12:48 -0700 (PDT) Received: from cisco.com ([161.44.65.126]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ49952; Wed, 22 Oct 2003 15:12:46 -0400 (EDT) Message-ID: <3F96D6AE.7010109@cisco.com> Date: Wed, 22 Oct 2003 15:12:46 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; 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] WG last call on draft-ietf-dhc-pxe-options-00.txt (SECOND REQUEST) References: <4.3.2.7.2.20031022070808.049ed6c8@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20031022070808.049ed6c8@flask.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I support publishing this draft, if the suboption terminology is changed to "option", to reflect common usage. I also think the number space management within the options should be addressed. Assuming this will not be managed by IANA, it should be explicitly stated. I also believe the references should be separated into normative and informative references. On that last point, I observe that the "Preboot Execution Environment (PXE) Specification" contains a great deal of DHC protocol detail, in terms of flows and packet contents. While I don't believe that text is at odds with the base DHCP RFCs, and there are sections in the PXE specification clearly describing the relationship to DHCP in terms of employing the standard where applicable, I'm concerned with an IETF document having a normative reference to another specification that restates an IETF standard. I assume this document to be published as an Informational RFC, simply documenting the use of specific options in a vendor/consortium specification? If so, then I suppose there should be no confusion as to whether the DHCP standard is in any way modified by statements in the PXE standard, in which case I don't think there is an issue. But I wanted to raise this point for WG discussion. -josh Ralph Droms wrote: > This message announces a WG last call on "DHCP Preboot eXecution > Environment > (PXE) Suboptions" . The last call will > conclude at 5PM ET on Friday, 10/24/2003. -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 15:47:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24786; Wed, 22 Oct 2003 15:47:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOwe-0005Eh-QI; Wed, 22 Oct 2003 15:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACOwW-0005Am-1e for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 15:46:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24746 for ; Wed, 22 Oct 2003 15:46:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACOwU-0001mC-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 15:46:50 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ACOwU-0001m2-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 15:46:50 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9MJkHN0013712 for ; Wed, 22 Oct 2003 15:46:17 -0400 (EDT) Received: from cisco.com ([161.44.65.126]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ53366; Wed, 22 Oct 2003 15:46:16 -0400 (EDT) Message-ID: <3F96DE87.9090105@cisco.com> Date: Wed, 22 Oct 2003 15:46:15 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; 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] WG last call on draft-ietf-dhc-agentopt-radius-03.txt (SECOND REQUEST) References: <4.3.2.7.2.20031022100510.025829d8@goblet.cisco.com> In-Reply-To: <4.3.2.7.2.20031022100510.025829d8@goblet.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I support this draft as written, and would like to see it progress. At 08:58 AM 10/22/2003, Ralph Droms wrote: > >This message announces a WG last call on "RADIUS Attributes Sub-option for >the DHCP Relay Agent Information Option" >. The >last call will conclude at 5PM ET on Friday, 10/24/2003. > -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 16:04:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25360; Wed, 22 Oct 2003 16:04:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPD7-0000yh-IK; Wed, 22 Oct 2003 16:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPCY-0000pq-SO for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 16:03:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25272 for ; Wed, 22 Oct 2003 16:03:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPCX-0001w1-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 16:03:25 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ACPCW-0001vc-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 16:03:24 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9MK2qN0017245 for ; Wed, 22 Oct 2003 16:02:52 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (dhcp-10-86-160-84.cisco.com [10.86.160.84]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADJ55168; Wed, 22 Oct 2003 16:02:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20031022152344.048fb2d8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Oct 2003 16:02:48 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Authentication of DHCP messages Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Vipul Gupta has submitted a specification for an authentication mechanism (as an extension to RFC 3118). As of the last dhc WG meeting, draft-gupta-dhcp-auth-02.txt had not received wide review within the WG. Please read Vipul's document, as part of our discussion of extensions to facilitate the deployment of DHCp message authentication. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 17:18:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28435; Wed, 22 Oct 2003 17:18:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACQMj-0002fT-H3; Wed, 22 Oct 2003 17:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACQ2F-0006ZH-NQ for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 16:56:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27681 for ; Wed, 22 Oct 2003 16:56:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACQ2D-0002XZ-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 16:56:49 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.106]) by ietf-mx with esmtp (Exim 4.12) id 1ACQ2C-0002XM-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 16:56:49 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9MKu8xc341920; Wed, 22 Oct 2003 16:56:08 -0400 Received: from d01ml604.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9MKu6ZK059850; Wed, 22 Oct 2003 16:56:06 -0400 Importance: Normal Subject: Re: [dhcwg] Authentication of DHCP messages To: Ralph Droms Cc: dhcwg@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Mimi Zohar Date: Wed, 22 Oct 2003 16:56:06 -0400 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 6.5|September 18, 2003) at 10/22/2003 16:56:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Since I'm the one that originally recommended resurrecting Vipul Gupta's draft with minor changes, I obviously support certificate based DHCP authentication and recommend accepting the proposed extensions to RFC3118 - Authentication for DHCP messages. Mimi Zohar Ralph Droms @ietf.org on 10/22/2003 04:02:48 PM Sent by: dhcwg-admin@ietf.org To: dhcwg@ietf.org cc: Subject: [dhcwg] Authentication of DHCP messages Vipul Gupta has submitted a specification for an authentication mechanism (as an extension to RFC 3118). As of the last dhc WG meeting, draft-gupta-dhcp-auth-02.txt had not received wide review within the WG. Please read Vipul's document, as part of our discussion of extensions to facilitate the deployment of DHCp message authentication. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 17:45:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29116; Wed, 22 Oct 2003 17:45:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACQms-0007qb-QC; Wed, 22 Oct 2003 17:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6nR-0007vN-O9 for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 20:24:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21158 for ; Tue, 21 Oct 2003 20:24:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6nP-0005cF-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 20:24:15 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1AC6nO-0005c8-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 20:24:14 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9LNm4506405 for ; Tue, 21 Oct 2003 16:48:04 -0700 Date: Tue, 21 Oct 2003 16:48:04 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Proposed Resolution of DNA Issue 8: DNA-02 Review Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The text of DNA Issue 8 is enclosed below. The proposed resolution is to accept all proposed changes. -------------------------------------------------------------------------- Issue 8: DNA-02 Review Submitter: Henrik Levkowetz Submitter email address: henrik@levkowetz.com Date first submitted: October 15, 2003 Reference: http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=../ietf/reviews/review-ietf-dhc-dna-ipv4-03.txt&comments=HENRIK Document: DNAv4-02 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: In Section 1.2. Terminology: To ease the readibility for people not familiar with the ARP rfc (RFC 826) it might be good to mention that names of the form ar$xxx.. are names of fields in the Address Resolution ethernet packet data, as described in the ARP RFC [RFC826]. Alternatively give definitions for ar$tpa, ar$sha, ar$spa, ar$tha, something like this: "ar$sha ARP packet field: Source Hardware Address [RFC826]. The hardware (MAC) address of the originator of an ARP packet. ar$spa ARP packet field: Source Protocol Address [RFC826]. For IP Address Resolution this is the IP Address of the sender of the ARP packet. If the sender address is unknown, this is set to 0.0.0.0. ar$tha ARP packet field: Target Hardware Address [RFC826]. The hardware (MAC) address of the target of an ARP packet, or the broadcast address if the target hardware address is unknown. ar$tpa ARP packet field: Target Protocol Address [RFC826]. For IP Address Resolution, the IP address for which one desires to know the hardware address." In Section 2.1. Reachability Test: "[b] If the host does not have a valid routable IPv4 address on the network. Since Link-Local IPv4 addresses are a last resort, these addresses do not count as a valid routable IPv4 address." Link-Local addresses are excluded from valid routable IPv4 addresses by the definition in Section 1.2 "Terminology", so I suggest rewriting as follows: [b] If the host does not have a valid routable IPv4 address on the network. (A Link-Local IPv4 address do not count as a valid routable IPv4 address.) In Section 2.2. Packet Format "If the initial ARP Request does not elicit a Response, the host waits 200ms and then sends another ARP Request. If no ARP Response is received in response to this second Request, the host proceeds to the IPv4 address acquisition phase. If a valid ARP Response is received, but cannot be matched against known networks, the host assumes it has moved subnets and moves on to the address acquisition phase." A motivation for the choice of 200ms would be good, both for immediate understanding, and for later evaluation of possible alternative values. In Section 2.3. IPv4 Address Acquisition: "....the DHCPREQUEST needs to be forwarded to and from the DHCP server by a DHCP Relay so that the response can be broadcast." - I don't seem able to quite understand what is meant by this. (Anyway, RFC2131 indicates clearly in 4.3.6, with no exceptions given elsewhere, that in INIT-REBOOT the client sends messages by broadcast.) In Section 3. IANA Considerations: "Guidelines for IANA considerations are specified in [RFC2434]. This specification does not request the creation of any new parameter registries, nor does it require any other IANA assignments." Maybe skip the first sentence? In Section 4. Security Considerations: Detection of Network Attachment (DNA) is typically insecure, so that it is inadvisable for a host to adjust its security based on which network it believes it is attached to. For example, it would be inappropriate for a host to disable its personal firewall based on the believe that it had connected to a home network. s/believe/belief/ In Section 5.1. Normative References: RFCs 792 and 2132 does not seem to be referenced in the document text. RFC 2434 is hardly normative as seen by the readers of the document. In Appendix A: "On IEEE 802 [IEEE802] wired networks, hints include link-layer discovery traffic as well as information exchanged as part of IEEE 802.1X authentication [IEEE8021X]. Link-layer discovery traffic includes Link Layer Discovery Protocol [IEEE8021AB] traffic as well as network identification information passed in the EAP- Request/Identity or within an EAP method exchange, as defined in EAP [RFC2284]." I suggest adding the abbreviation LLDP: "... Link Layer Discovery Protocol (LLDP)" so it's known when it's used in the next paragraph. In Appendix A: "Thus, associating to the same SSID is a necessary, but not necessarily a sufficient condition, for remaining within the same subnet. While a Station associating to the same SSID may not necessarily remain within the same subnet; on the other hand, a Station associating to a different SSID is likely to have changed subnets." Maybe rewrite for easier reading: "Thus, associating to the same SSID is a necessary, but not necessarily a sufficient condition, for remaining within the same subnet: while a Station associating to the same SSID may not necessarily remain within the same subnet, a Station associating to a different SSID is likely to have changed subnets." _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 22 18:39:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29117; Wed, 22 Oct 2003 17:45:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACQmt-0007qj-CN; Wed, 22 Oct 2003 17:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC6pb-0008To-Ol for dhcwg@optimus.ietf.org; Tue, 21 Oct 2003 20:26:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21193 for ; Tue, 21 Oct 2003 20:26:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC6pZ-0005dG-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 20:26:29 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1AC6pY-0005dD-00 for dhcwg@ietf.org; Tue, 21 Oct 2003 20:26:29 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h9LNoIP06511 for ; Tue, 21 Oct 2003 16:50:18 -0700 Date: Tue, 21 Oct 2003 16:50:18 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Proposed Resolution to DNA Issue 9: Use of ARP in Reachability Test Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The text of DNA Issue 9 is enclosed below. The proposed resolution is to accept the proposed changes. A new version of the spec including the resolutions to Issues 8 and 9 is available here: http://www.drizzle.com/~aboba/DNA/draft-ietf-dhc-dna-ipv4-04.txt ------------------------------------------------------------------------ Issue 9: Use of ARP in Reachability Test Submitter name: Ralph Droms Submitter email address: rdroms@cisco.com Date first submitted: 10/16/2003 Reference: Document: DNA-03 Comment type: T Priority: S Section: 2 Packet Format Rationale/Explanation of issue: In the fourth paragraph of section 2, the host performing the reachability test is instructed to look in the ARP response for the default gateway's MAC address and IPv4 address in ar$tha and ar$tpa, respectively. However, according to section "Packet Reception" of RFC 826, the default gateway (the target of the ARP probe) will return its MAC address and IPv4 address in ar$sha and ar$spa. There is also a minor editorial nit - the text in the first three paragraphs of section 2.2 doesn't explicitly describe what value should be used for ar$tha (should be 0) in the ARP probe message. Requested change: Change ar$tha and ar$tpa to ar$sha and ar$tha, respectively, in the fourth paragraph of section 2.2 Add the following sentence to the end of the first paragraph in section 2.2: "The host sets the target hardware address field (ar$tha) to 0." _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 23 11:10:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28067; Thu, 23 Oct 2003 11:10:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACh6A-0002xj-LK; Thu, 23 Oct 2003 11:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACh5D-0002fD-Jy for dhcwg@optimus.ietf.org; Thu, 23 Oct 2003 11:09:03 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27983 for ; Thu, 23 Oct 2003 11:08:51 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ACh0q-0007K8-SU; Thu, 23 Oct 2003 11:04:32 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Thu, 23 Oct 2003 11:04:32 -0400 Subject: [dhcwg] Protocol Action: 'IPv6 Prefix Options for DHCPv6' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has approved following document: - 'IPv6 Prefix Options for DHCPv6 ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using DHCP. This mechanism is intended for delegating a long-lived prefix from a delegating router (e.g., at an ISP) to a requesting router (e.g., at a customer site), across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned. The Prefix Delegation option makes it possible for an ISP to dynamically assign a prefix of arbitraty size (e.g., a /64 or /48) to an end site, with the end site taking responsibility for further sub-dividing the prefix and assigning subnet numbers to its internal links. Working Group Summary There was WG consensus for this document in both the DHC and IPv6 WGs. Protocol Quality This protocol has been reviewed for the IESG by Thomas Narten. The option has been implemented (e.g., it is being tested at interoperability events) and some ISPs in Japan have started using it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 23 12:25:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05339; Thu, 23 Oct 2003 12:25:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiGk-0001dC-T0; Thu, 23 Oct 2003 12:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACiGA-0001Xr-Mb for dhcwg@optimus.ietf.org; Thu, 23 Oct 2003 12:24:26 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05272 for ; Thu, 23 Oct 2003 12:24:03 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ACiBx-0006VD-8K; Thu, 23 Oct 2003 12:20:05 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Thu, 23 Oct 2003 12:20:05 -0400 Subject: [dhcwg] Protocol Action: 'KDC Server Address Sub-option' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has approved following document: - 'KDC Server Address Sub-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 document describes a sub-option of the "DHCP Option for CableLabs Client Configuration", RFC 3495. A certain class of CableHome devices require the configuration of a "Key Distribution Center" server as an IP address rather than as a domain name. The new sub-option provides KDC configuration as an IPv4 address. Working Group Summary The -04 revision of the draft addresses comments received during the WG last call. Note that there were few responses to the WG last call; all of these response supported acceptance of the doc and a couple of responses suggested edits. The important changes in the -04 rev are additional text in the Security Considerations section and a new reference to the CableHome 1.1 specification. Protocol Quality This document has been reviewed for the IESG by Margaret Wasserman. RFC Editor Note Please change the title of the document as follows: OLD: KDC Server Address Sub-option NEW: KDC Server Address Sub-option for the DHCP CableLabs Client Configuration (CCC) Option Please change the following section, in order to define the acronym "PS" in Section 1: OLD: A CCC DHCP Option code providing the KDC server address will be needed for CableHome-compliant residential gateways configured to use Kerberos for authentication as the first step in establishing a secure SNMPv3 link between the PS and the SNMP entity in the cable operator's data network. NEW: A CCC DHCP Option code providing the KDC server address will be needed for CableHome-compliant residential gateways configured to use Kerberos for authentication as the first step in establishing a secure SNMPv3 link between the Portal Services logical element [1, 2] in the residential gateways, and the SNMP entity in the cable operator's data network. Also please change the word "insure" to "ensure" in Section 3: OLD It is assumed that all service providers permitted onto an access providers network are trusted entities that will cooperate to insure peaceful coexistence. NEW It is assumed that all service providers permitted onto an access providers network are trusted entities that will cooperate to ensure peaceful coexistence. Thank you! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 23 19:02:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23397; Thu, 23 Oct 2003 19:02:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACoSw-0007JJ-0q; Thu, 23 Oct 2003 19:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACoSM-00075F-Eg for dhcwg@optimus.ietf.org; Thu, 23 Oct 2003 19:01:26 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23347 for ; Thu, 23 Oct 2003 19:01:13 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1ACoRx-0008Sq-5e; Thu, 23 Oct 2003 19:01:01 -0400 X-test-idtracker: no To: IETF-Announce :; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 23 Oct 2003 19:01:01 -0400 Subject: [dhcwg] Last Call: 'NIS Configuration Options for DHCPv6' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'NIS Configuration Options for DHCPv6' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-06. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-03.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 24 08:24:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27599; Fri, 24 Oct 2003 08:24:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD0zF-0000l7-V2; Fri, 24 Oct 2003 08:24:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD0k8-0005Xp-Ss for dhcwg@optimus.ietf.org; Fri, 24 Oct 2003 08:08:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27129 for ; Fri, 24 Oct 2003 08:08:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD0k7-0002Ir-00 for dhcwg@ietf.org; Fri, 24 Oct 2003 08:08:35 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1AD0k7-0002IX-00 for dhcwg@ietf.org; Fri, 24 Oct 2003 08:08:35 -0400 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 24 Oct 2003 14:06:03 +0200 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9OC7xj0009059 for ; Fri, 24 Oct 2003 05:08:01 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-210.cisco.com [10.82.240.210]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADK89758; Fri, 24 Oct 2003 08:07:58 -0400 (EDT) Message-Id: <4.3.2.7.2.20031024080653.04123c80@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Oct 2003 08:07:51 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-leasequery-05.txt In-Reply-To: References: <4.3.2.7.2.20031021083132.04816730@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I read from the specification that the device using DHCPLEASEQUERY must be aware if the DHCP failover protocol is being used. This requirement implies that devices must be configured to know about failover, when they need not be so configured today, and (potentially) that the leasequery spec should be delayed until the failover spec is published. I think it's important to avoid both of those conditions. In particular, a device may be in a situation in which multiple DHCP servers are in use regardless of whether failover is in use. The important issue from the device's point of view is that it may be configured with the addresses of more than one DHCP server, and it may receive multiple, potentially conflicting, responses from those DHCP servers. I suggest that the reference to failover in section 3 can be left as is, perhaps striking the phrase about where to send the DHCPLEASEQUERY messages when failover is in use. The reference to failover in section 4 should be replaced by instructions to the device about how to behave if it is configured with a list of DHCP servers. The reference in section 6.4.2 looks OK (instructions on how to configure failover). The reference in section 6.7 should be extended to something like "If the device receives multiple responses, it must use some information in the responses to choose which to use. For example, the client-last-transaction-time can be used." (Is client-last-transaction-time restricted to use by servers that are using failover?) I'm not quite sure I understand the relationship between the 'R' bit and the IP Address Lease Time. Are they mutually exclusive? That is, if a server receives a DHCPLEASEQUERY for a client with a reservation and an active lease, does the server just return the IP Address Lease Time in a DHCPLEASEACTIVE message, *without* setting the 'R' bit? Or, is it not possible to have a reservation with an active lease? Nits: Hyphenation of words at line breaks (for example, "operation" at the end of the first paragraph of section 1) is not allowed in an Internet Draft or RFC (see http://www.ietf.org/ID-nits.html for a checklist of formatting instructions) The references need to be split into Normative and Informative references. Section 1, second paragraph: delete "new lightweight" in last sentence. Section 1, second paragraph after Figure 2, replace "due to reboot" with "because the access concentrator has rebooted". Section 6.1, numbered list, change "three" to "four". Also, the second phrase is a sentence fragment, and should be edited to be a complete sentence. Section 6.4, bullet list item "DHCPLEASEUNKOWN", second paragraph, replace DHCPLEASEKNOWN with DHCPLEASEUNKNOWN and replace "response" with "respond". Section 6.4.1, 5th paragraph seems redundant ('R' bit is described elsewhere) and out of context; can it be deleted? Section 6.4.2, is the last paragraph redundant with the next to last paragraph in section 3? Can the paragraph in section 3 be deleted (probably not appropriate for the Background?) Section 6.6, last two paragraphs, the exponential backoff algorithm needs more detail: what are the initial and incremental timeout values? I suggest reusing the backoff algorithm from RFC 2131. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 24 09:21:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29290; Fri, 24 Oct 2003 09:21:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1sC-0007Mm-T0; Fri, 24 Oct 2003 09:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD1rf-0007F1-Fu for dhcwg@optimus.ietf.org; Fri, 24 Oct 2003 09:20:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29246 for ; Fri, 24 Oct 2003 09:20:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD1rd-000395-00 for dhcwg@ietf.org; Fri, 24 Oct 2003 09:20:25 -0400 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AD1rd-000392-00 for dhcwg@ietf.org; Fri, 24 Oct 2003 09:20:25 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9ODKCAr075511; Fri, 24 Oct 2003 09:20:20 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ralph Droms'" , , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-agentopt-radius-03.txt (SECOND REQUEST) Date: Fri, 24 Oct 2003 09:20:12 -0400 Message-ID: <000001c39a31$91086f70$6401a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <4.3.2.7.2.20031022070345.049bb0b8@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Ralph: I support this draft moving forward. A few nits are: There is an inconsistency in section 2 (terminology). In some cases you define the terms (even when they come from another document) and in = others you don't. I'm especially concerned that the 802.1X definitions are not defined in the draft as the document they are defined in is not an IETF document - so repeating these definitions has the most value. Also, in section 6 (DHCP Client Behavior) shouldn't it state that this option (Relay Agent Information) should never be added or seen by the = client as this option is only for use between a relay agent and DHCP server? = The current wording doesn't make it clear that the client should never see = these options (or the specific sub-option). I'm also not clear why in section 4 the User-Name and Class are SHOULD whereas in section 7 these are a MUST. Neither attribute is a MUST in = RFC 2865. I would think both sections are a SHOULD? - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ralph Droms Sent: Wednesday, October 22, 2003 8:58 AM To: dhcwg@ietf.org Subject: [dhcwg] WG last call on draft-ietf-dhc-agentopt-radius-03.txt (SECOND REQUEST) SECOND REQUEST - To date, the only response to this WG last call has = been the chair's review of the document. If enough responses are not = received to support the acceptance of this document, it *will not* be submitted to = the IESG for publication. Please respond to this WG last call. If you = support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. ----- This message announces a WG last call on "RADIUS Attributes Sub-option = for the DHCP Relay Agent Information Option" . The last call will conclude at 5PM ET on Friday, 10/24/2003. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-agentopt-radius-03.txt provides a way through which = network elements can pass information obtained through layer 2 authentication to = a DHCP server. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access that would be used with draft-ietf-dhc-agentopt-radius-03.txt. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-03.txt= - Ralph Droms=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 24 10:24:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02679; Fri, 24 Oct 2003 10:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD2rC-0007Rj-EZ; Fri, 24 Oct 2003 10:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD2r6-0007Qh-DF for dhcwg@optimus.ietf.org; Fri, 24 Oct 2003 10:23:56 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02627; Fri, 24 Oct 2003 10:23:43 -0400 (EDT) Message-Id: <200310241423.KAA02627@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 24 Oct 2003 10:23:43 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Node-Specific Client Identifiers for DHCPv4 Author(s) : T. Lemon Filename : draft-ietf-dhc-3315id-for-v4-00.txt Pages : 6 Date : 2003-10-23 This document specifies the format that is to be used for encoding DHCPv4 (RFC2131/RFC2132) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol (RFC3315). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-3315id-for-v4-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-3315id-for-v4-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24095654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-3315id-for-v4-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-3315id-for-v4-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24095654.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 24 10:26:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02952; Fri, 24 Oct 2003 10:26:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD2t8-0007qJ-Cz; Fri, 24 Oct 2003 10:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD2sJ-0007jQ-3d for dhcwg@optimus.ietf.org; Fri, 24 Oct 2003 10:25: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 KAA02806; Fri, 24 Oct 2003 10:24:59 -0400 (EDT) Message-Id: <200310241424.KAA02806@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 24 Oct 2003 10:24:58 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-nss-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Name Service Search Option for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-nss-00.txt Pages : 6 Date : 2003-10-23 This document describes a new option called Name Service Search Option to specify the order in which name services should be consulted by the client when resolving host names and other information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nss-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-nss-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-opt-nss-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24095706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-nss-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-nss-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24095706.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 24 11:13:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02678; Fri, 24 Oct 2003 10:24:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD2rB-0007RR-IP; Fri, 24 Oct 2003 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD2qf-0007JQ-4G for dhcwg@optimus.ietf.org; Fri, 24 Oct 2003 10:23: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 KAA02599; Fri, 24 Oct 2003 10:23:16 -0400 (EDT) Message-Id: <200310241423.KAA02599@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 24 Oct 2003 10:23:16 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-04.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-04.txt Pages : 14 Date : 2003-10-23 The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This specification synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link-Local addresses, in order to optimize detection of network attachment by mobile hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dna-ipv4-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24095640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24095640.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 24 17:09:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29868; Fri, 24 Oct 2003 17:09:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9B8-0002Gp-0y; Fri, 24 Oct 2003 17:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9AI-00028c-34 for dhcwg@optimus.ietf.org; Fri, 24 Oct 2003 17:08:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29845 for ; Fri, 24 Oct 2003 17:07:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD9AF-0004Rs-00 for dhcwg@ietf.org; Fri, 24 Oct 2003 17:08:07 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AD9AF-0004Rj-00 for dhcwg@ietf.org; Fri, 24 Oct 2003 17:08:07 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9OL7YN0002165; Fri, 24 Oct 2003 17:07:34 -0400 (EDT) Received: from kkinnear-w2k03.cisco.com ([161.44.65.180]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADL39225; Fri, 24 Oct 2003 17:07:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20031024163951.0263fc98@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Oct 2003 17:07:32 -0400 To: dhcwg@ietf.org From: Kim Kinnear Cc: kkinnear@cisco.com, rdroms@cisco.com, Richard_Woundy@cable.comcast.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Leasequery draft update Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, I have submitted a new update to the leasequery draft: draft-ietf-dhc-leasequery-06.txt This updates the current -05 version at ietf.org. This draft contains minor changes previously requested and approved at an IETF meeting as well as all of the comments currently outstanding from the WG last call of the draft. All of the changes are listed below. The first three items are previously outstanding comments that were requested and approved at an IETF WG meeting, and that I said were included in the draft in email discussing changes, but which were omitted in the -05 version of the draft due to a clerical error on my part. You could consider these early responses to the last call. 1. Removed R bit and all reservations information. 2. Removed ability to get information about existing clients which don't have active leases. Changed the DHCPLEASEKNOWN message to return only information that this server knows about this IP address (so that the relay agent doesn't have to ask other servers). 3. Updated front matter to ensure it is about gleaning. 4. Fixed section 6.4.2 to say that the T1 and T2 times would not be returned if they were in the past. 5. Changed DHCPLEASEKNOWN to DHCPLEASEACTIVE in the paragraph two before the one in section 4. 6. Generalized discussion of how to handle failover servers to how to handle multiple servers, with failover as an example of this situation. 7. Removed hyphenation of words at line breaks. 8. Split references into Normative and Informative. 9. Section 1, second paragraph: deleted "new lightweight" in last sentence. 10. Section 1, second paragraph after Figure 2, replaced "due to reboot" with "because the access concentrator has rebooted". 11. Fixed Section 6.1, numbered list to have correct numbers and grammar. 12. Section 6.4, bullet list item "DHCPLEASEUNKOWN", second paragraph, replaced DHCPLEASEKNOWN with DHCPLEASEUNKNOWN and replaced "response" with "respond". 13. Section 6.4.2, last paragraph was redundant with the next to last paragraph in section 3. The paragraph in section 3 was deleted (not appropriate for the Background). 14. Section 6.6, last two paragraphs, replaced the exponential backoff algorithm for individual packets with that from RFC 2131 by reference. Enhanced the clarity of the discussion of per-server timer (which really isn't a backoff algorithm in any case). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 24 23:37:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10752; Fri, 24 Oct 2003 23:37:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADFEd-0002eQ-8o; Fri, 24 Oct 2003 23:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACbX9-0006aA-VC for dhcwg@optimus.ietf.org; Thu, 23 Oct 2003 05:13:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09653 for ; Thu, 23 Oct 2003 05:13:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACbX6-00044w-00 for dhcwg@ietf.org; Thu, 23 Oct 2003 05:13:28 -0400 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1ACbX5-00044t-00 for dhcwg@ietf.org; Thu, 23 Oct 2003 05:13:27 -0400 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id h9N9DF4W023916; Thu, 23 Oct 2003 11:13:15 +0200 Received: from alcatel.fr ([172.25.73.96]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2003102311131398:2819 ; Thu, 23 Oct 2003 11:13:13 +0200 Message-ID: <3F979BAA.3FFB88D6@alcatel.fr> Date: Thu, 23 Oct 2003 11:13:14 +0200 From: Bertrand.Lapraye@alcatel.fr Reply-To: bertrand.lapraye@alcatel.fr Organization: Alcatel R&I/ALCATEL CIT X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org CC: henrik@levkowetz.com References: <20031022165138.513d01cc.henrik@levkowetz.com> X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/23/2003 11:13:14, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 10/23/2003 11:13:15, Serialize complete at 10/23/2003 11:13:15 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: 7bit Subject: [dhcwg] acknowledgment : draft-ietf-dhc-mipadvert-opt-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henrik Levkowetz wrote: > > Forwarded from the DHCP workgroup list, dhcwg@ietf.org: > > -------- Begin forwarded message: -------- > > Date: Wed, 22 Oct 2003 09:58:00 -0400 > From: Ralph Droms > To: dhcwg@ietf.org > Subject: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) > > SECOND REQUEST - To date, the only response to this WG last call has been > the chair's review of the document. If enough responses are not received to > support the acceptance of this document, it *will not* be submitted to the > IESG for publication. Please respond to this WG last call. If you support > acceptance of the document without change, respond with a simple > acknowledgment, so that support for the document can be assessed. > > ----- > This message announces a WG last call on "DHCP Option for Mobile IP Mobility > Agents" . The last call will conclude > at 5PM ET on Friday, 10/24/2003. > > Please respond to this WG last call. If you support acceptance of the > document without change, respond with a simple acknowledgment, so that > support for the document can be assessed. > > draft-ietf-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the > Mobility Agent Option, and two sub-options of the Mobility Agent Option: the > Network Access Identifier Sub-Option, which provides > identifying information about a DHCP client to the DHCP server and the > Mobility Agent Announcement sub-option, which announces the address of one > or more mobility agents available to a host. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt > > - Ralph Droms > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > Henrik > > -- > Error message in Haiku form: > > The code was willing, > It considered your request, > But the chips were weak. > > -- Barry L. Brumitt > > -- > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 -- Bertrand Lapraye _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 25 00:28:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10751; Fri, 24 Oct 2003 23:37:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADFEc-0002eG-Gu; Fri, 24 Oct 2003 23:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACR8C-0003fH-8h for dhcwg@optimus.ietf.org; Wed, 22 Oct 2003 18:07:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00326 for ; Wed, 22 Oct 2003 18:06:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACR85-0003Gt-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 18:06:57 -0400 Received: from bay1-f152.bay1.hotmail.com ([65.54.245.152] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ACR84-0003Ge-00 for dhcwg@ietf.org; Wed, 22 Oct 2003 18:06:57 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 Oct 2003 15:06:25 -0700 Received: from 12.153.34.50 by by1fd.bay1.hotmail.msn.com with HTTP; Wed, 22 Oct 2003 22:06:24 GMT X-Originating-IP: [12.153.34.50] X-Originating-Email: [huma_hakim@hotmail.com] From: "Huma Hakim" To: dhcwg@ietf.org Date: Wed, 22 Oct 2003 22:06:24 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Oct 2003 22:06:25.0768 (UTC) FILETIME=[BC6E3680:01C398E8] Subject: [dhcwg] Existing giaddr and Relay Agent Information option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Could someone kindly tell me what is the suggested behavior when a relay agent receives DHCP packets with existing giaddr and/or relay agent information option? Thanks Huma Hakim _________________________________________________________________ Add MSN 8 Internet Software to your current Internet access and enjoy patented spam control and more. Get two months FREE! http://join.msn.com/?page=dept/byoa _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 25 14:31:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11763; Sat, 25 Oct 2003 14:31:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADTBl-0006CW-9v; Sat, 25 Oct 2003 14:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADTBE-00069S-Cp for dhcwg@optimus.ietf.org; Sat, 25 Oct 2003 14:30:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11702 for ; Sat, 25 Oct 2003 14:30:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADTBB-0000uU-00 for dhcwg@ietf.org; Sat, 25 Oct 2003 14:30:25 -0400 Received: from smtp017.mail.yahoo.com ([216.136.174.114]) by ietf-mx with smtp (Exim 4.12) id 1ADTBA-0000uQ-00 for dhcwg@ietf.org; Sat, 25 Oct 2003 14:30:24 -0400 Received: from adsl-64-170-118-75.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.118.75 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Oct 2003 18:30:23 -0000 Reply-To: From: "Barr Hibbs" To: "Dhcwg" Date: Sat, 25 Oct 2003 11:29:15 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Review of RFC 2131 prior to advancement Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A year ago, at the Atlanta Working Groups meeting, I accepted the task of preparing a critical review of RFC 2131 as the last step before advancing it to a full Internet-Standard. First step was to solicit input from the DHC community, which I did in January of this year with, sadly, few respondents. An initial ("-00") Informational Internet-Draft was submitted in February containing the first collection of criticism of the RFC. That draft was summarized at the San Francisco Working Groups meeting, and Rob Stevens joined me as editor for the effort. Now, a second ("-01") draft has been accepted by the Internet-Drafts Editor and will be an agenda item for discussion at the Minneapolis Working Groups meeting. Many of the recommendations made in this draft are non-controversial, such as typographical and spelling errors. Other recommendations follow current guidelines for all documents, including the use of standardized boilerplate, organization of references, and intellectual property notices. The majority of recommendations involve clarification of items that had conflicting or confusing descriptions in two or more sections of RFC 2131 or conflicted with other RFCs. Please take the time to review the new draft (http://www.ietf.org/internet-drafts/draft-ietf-dhc-implementation-01.txt) and be prepared to discuss it during the Working Groups meeting AND on the DHC mailing list. Thanks in advance, --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 25 17:59:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16713; Sat, 25 Oct 2003 17:59:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWR4-0004ld-2V; Sat, 25 Oct 2003 17:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWQu-0004iP-Qn for dhcwg@optimus.ietf.org; Sat, 25 Oct 2003 17:58:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16677 for ; Sat, 25 Oct 2003 17:58:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADWQs-00030A-00 for dhcwg@ietf.org; Sat, 25 Oct 2003 17:58:50 -0400 Received: from smtp012.mail.yahoo.com ([216.136.173.32]) by ietf-mx with smtp (Exim 4.12) id 1ADWQr-000307-00 for dhcwg@ietf.org; Sat, 25 Oct 2003 17:58:49 -0400 Received: from adsl-64-170-118-75.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.118.75 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Oct 2003 21:58:49 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-agentopt-radius-03.txt Date: Sat, 25 Oct 2003 14:57:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4.3.2.7.2.20031012074035.02099a50@flask.cisco.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sorry for the late reply. I support advancing this draft. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 25 18:16:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18086; Sat, 25 Oct 2003 18:16:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWhW-0006HI-Ce; Sat, 25 Oct 2003 18:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWh0-0006Er-1Z for dhcwg@optimus.ietf.org; Sat, 25 Oct 2003 18:15:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17974 for ; Sat, 25 Oct 2003 18:15:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADWgx-0003Fb-00 for dhcwg@ietf.org; Sat, 25 Oct 2003 18:15:27 -0400 Received: from smtp018.mail.yahoo.com ([216.136.174.115]) by ietf-mx with smtp (Exim 4.12) id 1ADWgw-0003FY-00 for dhcwg@ietf.org; Sat, 25 Oct 2003 18:15:26 -0400 Received: from adsl-64-170-118-75.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.118.75 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Oct 2003 22:15:26 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt Date: Sat, 25 Oct 2003 15:14:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4.3.2.7.2.20031012080851.04ca5f00@flask.cisco.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Again, sorry to be so late in responding. I support the advancement of this draft with what I summarize as "suboptions SHOULD NOT have a zero length, unless there is a semantically appropriate reason to do so," and noting the following nit: (page 4, section 3.1, last paragraph of the section) contains the sentence, "The Mobility Agent Information field shall NOT be terminated with a 255 sub-option." This should be changed to be "SHOULD NOT," "MUST NOT," or "MAY NOT" to conform with standard terminology. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 25 18:27:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18599; Sat, 25 Oct 2003 18:27:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWs9-0007Q4-JO; Sat, 25 Oct 2003 18:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWrp-0007PL-KI for dhcwg@optimus.ietf.org; Sat, 25 Oct 2003 18:26:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18566 for ; Sat, 25 Oct 2003 18:26:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADWrm-0003WS-00 for dhcwg@ietf.org; Sat, 25 Oct 2003 18:26:38 -0400 Received: from smtp102.mail.sc5.yahoo.com ([216.136.174.140]) by ietf-mx with smtp (Exim 4.12) id 1ADWrl-0003WO-00 for dhcwg@ietf.org; Sat, 25 Oct 2003 18:26:38 -0400 Received: from adsl-64-170-118-75.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.118.75 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Oct 2003 22:26:33 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-pxe-options-00.txt Date: Sat, 25 Oct 2003 15:25:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4.3.2.7.2.20031012090550.048f5a38@flask.cisco.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit So busy getting my own draft out this week that I missed these last call deadlines... *sigh* I support advancing this draft subject to Bernie's recommended alignment of terminology, Josh's suggestion that the Intel PXE specifications be published as an informational RFC, Bernie's recommendation that any option(s) used for PXE in the range 128-254 be adequately documented, and my one nit: o this draft should be categorized as "standards-track" or "informational" --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Oct 25 18:29:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18676; Sat, 25 Oct 2003 18:29:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWu5-0007ea-L0; Sat, 25 Oct 2003 18:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADWtY-0007cV-1b for dhcwg@optimus.ietf.org; Sat, 25 Oct 2003 18:28:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18650 for ; Sat, 25 Oct 2003 18:28:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADWtV-0003Yq-00 for dhcwg@ietf.org; Sat, 25 Oct 2003 18:28:25 -0400 Received: from smtp102.mail.sc5.yahoo.com ([216.136.174.140]) by ietf-mx with smtp (Exim 4.12) id 1ADWtU-0003Ym-00 for dhcwg@ietf.org; Sat, 25 Oct 2003 18:28:24 -0400 Received: from adsl-64-170-118-75.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.118.75 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Oct 2003 22:28:24 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-v4-threat-analysis-00.txt Date: Sat, 25 Oct 2003 15:27:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4.3.2.7.2.20031012085130.01e1bc80@flask.cisco.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dang! Blew past this date as well! I support advancing this draft, but believe it needs classification as an "informational" or "standards-track" document. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 06:25:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07257; Mon, 27 Oct 2003 06:25:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5Uc-0006Be-8D; Mon, 27 Oct 2003 06:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE5UI-00069l-9m for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 06:24:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07198 for ; Mon, 27 Oct 2003 06:24:29 -0500 (EST) From: Stephane.Antoine@panasonicmobile.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE5UE-0003Cs-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 06:24:38 -0500 Received: from hardy.mci.co.uk ([195.144.128.51]) by ietf-mx with esmtp (Exim 4.12) id 1AE5UD-0003Cl-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 06:24:37 -0500 Date: Mon, 27 Oct 2003 11:24:31 +0000 Message-ID: MIME-Version: 1.0 To: dhcwg@ietf.org X-WSS-ID: 1383DFE0240873-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; Creation-Date="Mon, 27 Oct 2003 11:24:31 +0000" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Vijay, About the processing of the list of preferred prefix option (scenario 3 alike), how would the server decide which prefix to assign its client if it receives several prefixes from it? If a Client sends a preferred prefix list, It will be easier if the prefixes were listed in order of decreasing value with a preference value associated with each prefix. A default preference value of 0 if only one prefix had been advertised for example. The client policy would decide how to order the prefixes with the preference value accordingly to its most preferred choice(s) stephane ============================================================================== Confidentiality Notice The information contained in this E-mail, and any attachments, is intended for the named recipients only. It may contain confidential and/or privileged information. If you are not the intended recipient, you must not copy, distribute, or take any action in reliance on it. Any views expressed do not necessarily reflect the views of Panasonic Mobile Communications Development of Europe Limited. Please note that whilst the company takes steps to protect against viruses it cannot accept any liability for any damage, whether direct or indirect, sustained as a result of any software viruses being transmitted. If you receive this E-mail by mistake, please advise the sender by using the reply facility in your E-mail software and then delete it. ============================================================================== _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 08:42:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12167; Mon, 27 Oct 2003 08:42:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE7dB-0002oK-Pv; Mon, 27 Oct 2003 08:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE7cr-0002lz-Ry for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 08:41:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12126 for ; Mon, 27 Oct 2003 08:41:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE7cq-0004zk-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 08:41:40 -0500 Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx with esmtp (Exim 4.12) id 1AE7cq-0004zh-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 08:41:40 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel9.hp.com (Postfix) with ESMTP id E402F1C00D3A; Tue, 28 Oct 2003 18:54:48 -0500 (EST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id TAA05555; Mon, 27 Oct 2003 19:10:17 +0530 (IST) From: "Vijayabhaskar A K" To: , Subject: RE: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix Date: Mon, 27 Oct 2003 19:11:22 +0530 Message-ID: <000401c39c90$06e265b0$38e62a0f@nt23056> 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.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Stephane The client is supposed to send the list of ALL the preferred prefixes on which it wishes the server to allocate addresses. There is actually no preference on the any of the prefixes. If the server's policy supports this option and one or more prefixes are not known by the server (or) doesn't belong to the client's link, then the server MUST send NotOnLink error code. Otherwise, the server is expected to allocate addresses on ALL the prefixes sent by the client. Hope this clarifies. Do getback to me, if you need any further clarification ~ Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Stephane.Antoine@panasonicmobile.co.uk Sent: Monday, October 27, 2003 4:55 PM To: dhcwg@ietf.org Subject: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix Dear Vijay, About the processing of the list of preferred prefix option (scenario 3 alike), how would the server decide which prefix to assign its client if it receives several prefixes from it? If a Client sends a preferred prefix list, It will be easier if the prefixes were listed in order of decreasing value with a preference value associated with each prefix. A default preference value of 0 if only one prefix had been advertised for example. The client policy would decide how to order the prefixes with the preference value accordingly to its most preferred choice(s) stephane ======================================================================== ====== Confidentiality Notice The information contained in this E-mail, and any attachments, is intended for the named recipients only. It may contain confidential and/or privileged information. If you are not the intended recipient, you must not copy, distribute, or take any action in reliance on it. Any views expressed do not necessarily reflect the views of Panasonic Mobile Communications Development of Europe Limited. Please note that whilst the company takes steps to protect against viruses it cannot accept any liability for any damage, whether direct or indirect, sustained as a result of any software viruses being transmitted. If you receive this E-mail by mistake, please advise the sender by using the reply facility in your E-mail software and then delete it. ======================================================================== ====== _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 09:16:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14203; Mon, 27 Oct 2003 09:16:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8A6-0005ow-07; Mon, 27 Oct 2003 09:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE89A-0005ki-60 for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 09:15:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13880; Mon, 27 Oct 2003 09:14:51 -0500 (EST) Message-Id: <200310271414.JAA13880@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 09:14:51 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-implementation-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Implementation Issues with RFC 2131, 'Dynamic Host Configuration Protocol' Author(s) : R. Hibbs Filename : draft-ietf-dhc-implementation-01.txt Pages : 33 Date : 2003-10-24 This memo identifies implementation issues with RFC 2131, 'Dynamic Host Configuration Protocol,' reported by a number of implementors, assesses the severity of the problem, then proposes changes to RFC 2131 intended to overcome the issues. This is intended for use as the basis for discussion of RFC 2131 before it is proposed for Internet Standard status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-implementation-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-implementation-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-implementation-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24160233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-implementation-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-implementation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24160233.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 09:20:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14925; Mon, 27 Oct 2003 09:20:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8E6-0006fB-MJ; Mon, 27 Oct 2003 09:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8DR-0006Qs-HS for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 09:19:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14690; Mon, 27 Oct 2003 09:19:17 -0500 (EST) Message-Id: <200310271419.JAA14690@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 09:19:16 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Lease Query Author(s) : R. Woundy, K. Kinnear Filename : draft-ietf-dhc-leasequery-06.txt Pages : 25 Date : 2003-10-24 A DHCP server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Other processes and devices, many that already send and receive DHCP format packets, sometimes need to access this information. The leasequery protocol is designed to give these processes and devices a lightweight way to access information that may be critical to their operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-leasequery-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-leasequery-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24172121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-leasequery-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-leasequery-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24172121.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 09:20:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14924; Mon, 27 Oct 2003 09:20:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8E5-0006eL-1x; Mon, 27 Oct 2003 09:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8DD-0006JB-Fw for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 09:19:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14626; Mon, 27 Oct 2003 09:19:03 -0500 (EST) Message-Id: <200310271419.JAA14626@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 09:19:03 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-auth-suboption-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Authentication Suboption for the DHCP Relay Agent Option Author(s) : M. Stapp, T. Lemon, R. Droms Filename : draft-ietf-dhc-auth-suboption-02.txt Pages : 14 Date : 2003-10-24 The DHCP Relay Agent Information Option (RFC3046[1]) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines a new 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 a payload derived from the option used in DHCP Authentication (RFC3118[2]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-auth-suboption-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-auth-suboption-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-24163020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-auth-suboption-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-auth-suboption-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24163020.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 09:37:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16150; Mon, 27 Oct 2003 09:37:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8UO-0000Qo-VU; Mon, 27 Oct 2003 09:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8Tm-0000Lf-TK for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 09:36:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16046 for ; Mon, 27 Oct 2003 09:36:10 -0500 (EST) From: Stephane.Antoine@panasonicmobile.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8Tl-0005qi-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 09:36:21 -0500 Received: from hardy.mci.co.uk ([195.144.128.51]) by ietf-mx with esmtp (Exim 4.12) id 1AE8Tk-0005qa-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 09:36:20 -0500 Date: Mon, 27 Oct 2003 14:36:22 +0000 Message-ID: Subject: RE: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix MIME-Version: 1.0 To: dhcwg@ietf.org, vijayak@india.hp.com X-WSS-ID: 1383F2D7242836-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; Creation-Date="Mon, 27 Oct 2003 14:36:21 +0000" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Vijay, So if the server allocates addresses on ALL the prefixes sent by the client and if the client did send several prefixes, then there will be a big number of addresses alocated and un-used since the client only needs one valid address on link to communicate. I think that this technique will result in a waist of commited addresses. Stephane -----Original Message----- From: vijayak@india.hp.com [mailto:vijayak@india.hp.com] Sent: 27 October 2003 13:41 To: Stephane Antoine; dhcwg@ietf.org Subject: RE: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix Hi Stephane The client is supposed to send the list of ALL the preferred prefixes on which it wishes the server to allocate addresses. There is actually no preference on the any of the prefixes. If the server's policy supports this option and one or more prefixes are not known by the server (or) doesn't belong to the client's link, then the server MUST send NotOnLink error code. Otherwise, the server is expected to allocate addresses on ALL the prefixes sent by the client. Hope this clarifies. Do getback to me, if you need any further clarification ~ Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Stephane.Antoine@panasonicmobile.co.uk Sent: Monday, October 27, 2003 4:55 PM To: dhcwg@ietf.org Subject: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix Dear Vijay, About the processing of the list of preferred prefix option (scenario 3 alike), how would the server decide which prefix to assign its client if it receives several prefixes from it? If a Client sends a preferred prefix list, It will be easier if the prefixes were listed in order of decreasing value with a preference value associated with each prefix. A default preference value of 0 if only one prefix had been advertised for example. The client policy would decide how to order the prefixes with the preference value accordingly to its most preferred choice(s) stephane ======================================================================== ====== Confidentiality Notice The information contained in this E-mail, and any attachments, is intended for the named recipients only. It may contain confidential and/or privileged information. If you are not the intended recipient, you must not copy, distribute, or take any action in reliance on it. Any views expressed do not necessarily reflect the views of Panasonic Mobile Communications Development of Europe Limited. Please note that whilst the company takes steps to protect against viruses it cannot accept any liability for any damage, whether direct or indirect, sustained as a result of any software viruses being transmitted. If you receive this E-mail by mistake, please advise the sender by using the reply facility in your E-mail software and then delete it. ======================================================================== ====== _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 09:46:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16647; Mon, 27 Oct 2003 09:46:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8d8-0001RX-GZ; Mon, 27 Oct 2003 09:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8co-0001PQ-4M for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 09:45:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16562 for ; Mon, 27 Oct 2003 09:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8cm-000603-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 09:45:40 -0500 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx with esmtp (Exim 4.12) id 1AE8cl-000600-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 09:45:39 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by palrel12.hp.com (Postfix) with ESMTP id 03F671C02806; Mon, 27 Oct 2003 06:45:35 -0800 (PST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id UAA10494; Mon, 27 Oct 2003 20:14:23 +0530 (IST) From: "Vijayabhaskar A K" To: , Subject: RE: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix Date: Mon, 27 Oct 2003 20:15:28 +0530 Message-ID: <001901c39c98$f6a5aa00$38e62a0f@nt23056> 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.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Stephane, You got my point wrong.. Client chooses 'n' number of preferred prefixes from the available 'm' valid prefixes in the link.. here 1 <= n <= m.. The server is expected to allocate addresses from 'm' prefixes by default.. Instead, the client can choose 'n' prefixes and send it in this option, so that, the server can allocate addresses only from these 'n' prefixes.. This prevents wastage of m-n addresses which the client doesn't want.. ~ Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Stephane.Antoine@panasonicmobile.co.uk Sent: Monday, October 27, 2003 8:06 PM To: dhcwg@ietf.org; vijayak@india.hp.com Subject: RE: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix Hi Vijay, So if the server allocates addresses on ALL the prefixes sent by the client and if the client did send several prefixes, then there will be a big number of addresses alocated and un-used since the client only needs one valid address on link to communicate. I think that this technique will result in a waist of commited addresses. Stephane -----Original Message----- From: vijayak@india.hp.com [mailto:vijayak@india.hp.com] Sent: 27 October 2003 13:41 To: Stephane Antoine; dhcwg@ietf.org Subject: RE: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix Hi Stephane The client is supposed to send the list of ALL the preferred prefixes on which it wishes the server to allocate addresses. There is actually no preference on the any of the prefixes. If the server's policy supports this option and one or more prefixes are not known by the server (or) doesn't belong to the client's link, then the server MUST send NotOnLink error code. Otherwise, the server is expected to allocate addresses on ALL the prefixes sent by the client. Hope this clarifies. Do getback to me, if you need any further clarification ~ Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Stephane.Antoine@panasonicmobile.co.uk Sent: Monday, October 27, 2003 4:55 PM To: dhcwg@ietf.org Subject: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix Dear Vijay, About the processing of the list of preferred prefix option (scenario 3 alike), how would the server decide which prefix to assign its client if it receives several prefixes from it? If a Client sends a preferred prefix list, It will be easier if the prefixes were listed in order of decreasing value with a preference value associated with each prefix. A default preference value of 0 if only one prefix had been advertised for example. The client policy would decide how to order the prefixes with the preference value accordingly to its most preferred choice(s) stephane ======================================================================== ====== Confidentiality Notice The information contained in this E-mail, and any attachments, is intended for the named recipients only. It may contain confidential and/or privileged information. If you are not the intended recipient, you must not copy, distribute, or take any action in reliance on it. Any views expressed do not necessarily reflect the views of Panasonic Mobile Communications Development of Europe Limited. Please note that whilst the company takes steps to protect against viruses it cannot accept any liability for any damage, whether direct or indirect, sustained as a result of any software viruses being transmitted. If you receive this E-mail by mistake, please advise the sender by using the reply facility in your E-mail software and then delete it. ======================================================================== ====== _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 10:09:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18458; Mon, 27 Oct 2003 10:09:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8zM-0004Lc-SW; Mon, 27 Oct 2003 10:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8yk-0004FK-16 for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 10:08:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18256 for ; Mon, 27 Oct 2003 10:08:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8yh-0006Js-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 10:08:19 -0500 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1AE8yg-0006JS-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 10:08:18 -0500 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h9REofe25414; Mon, 27 Oct 2003 21:50:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h9REhsj11080; Mon, 27 Oct 2003 21:43:59 +0700 (ICT) From: Robert Elz To: Stephane.Antoine@panasonicmobile.co.uk cc: dhcwg@ietf.org, vijayak@india.hp.com Subject: Re: [dhcwg] question on draft-ietf-dhc-dhcpv6-opt-cliprefprefix In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Oct 2003 21:43:54 +0700 Message-ID: <26013.1067265834@munnari.OZ.AU> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Date: Mon, 27 Oct 2003 14:36:22 +0000 From: Stephane.Antoine@panasonicmobile.co.uk Message-ID: | I think that this technique will result in a waist of commited | addresses. Why would anyone care about a waste of IPv6 addresses on a link? There are 2^64 available. Your client might only need one address (in which case it can send only one prefix, if it gets a NotOnLink, it can try again with a different prefix). Other clients wants lots of addresses - this allows the current state of the art in multihoming (something approaching the stone age, maybe) to be effective. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 13:31:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28725; Mon, 27 Oct 2003 13:31:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEC8q-00081k-QW; Mon, 27 Oct 2003 13:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEC8F-0007yQ-SJ for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 13:30:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28642 for ; Mon, 27 Oct 2003 13:30:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEC8D-0001b9-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 13:30:21 -0500 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1AEC8D-0001ae-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 13:30:21 -0500 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1AEC7j-0000Ui-00 for ; Mon, 27 Oct 2003 10:29:51 -0800 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id <46N5V0RJ>; Mon, 27 Oct 2003 10:29:29 -0800 Message-ID: From: "Kostur, Andre" To: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt Date: Mon, 27 Oct 2003 10:29:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C39CB8.3F0762B0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C39CB8.3F0762B0 Content-Type: text/plain; charset="iso-8859-1" > 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 Lease Query > Author(s) : R. Woundy, K. Kinnear > Filename : draft-ietf-dhc-leasequery-06.txt > Pages : 25 > Date : 2003-10-24 A question/clarification on section 6.3. At the end of this section it states: The giaddr is used only for the destination address of any generated response and, while required, is not otherwise used in generating the response to the DHCPLEASEQUERY message. It MUST NOT be used to restrict the processing of the query in any way, and MUST NOT be used locate a subnet to which the ciaddr (if any) must belong. What is this staement defending against when it says "It MUST NOT be used to restrict the processing of the query in any way"? Does this mean that a DHCP server implementation may not use the giaddr to determine whether or not to answer the query? Does this conflict with the statement later on in section 7: In some environments it may be appropriate to configure a DHCP server with the IP addresses of the relay agents for which it may respond to DHCPLEASEQUERY messages, thereby allowing it to respond only to to requests from only a handful of relay agents. This does not provide any true security, but may be useful to thwart unsophisticated attacks of various sorts. Or is section 7 expecting the service to look at the source IP of the incoming packet vs. the reported giaddr? ------_=_NextPart_001_01C39CB8.3F0762B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt

> 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 = Lease Query
>       = Author(s)       : R. Woundy, K. = Kinnear
>       = Filename        : = draft-ietf-dhc-leasequery-06.txt
>       = Pages           : = 25
>       = Date            : = 2003-10-24

A question/clarification on section 6.3.  At the = end of this section it states:

   The giaddr is used only for the = destination address of any generated
   response and, while required, is not = otherwise used in generating the
   response to the DHCPLEASEQUERY = message.  It MUST NOT be used to
   restrict the processing of the query in = any way, and MUST NOT be used
   locate a subnet to which the ciaddr (if = any) must belong.

What is this staement defending against when it says = "It MUST NOT be used to restrict the processing of the query in = any way"?  Does this mean that a DHCP server implementation = may not use the giaddr to determine whether or not to answer the = query?  Does this conflict with the statement later on in section = 7:

   In some environments it may be = appropriate to configure a DHCP server
   with the IP addresses of the relay = agents for which it may respond to
   DHCPLEASEQUERY messages, thereby = allowing it to respond only to to
   requests from only a handful of relay = agents.  This does not provide
   any true security, but may be useful to = thwart unsophisticated
   attacks of various sorts.

Or is section 7 expecting the service to look at the = source IP of the incoming packet vs. the reported giaddr?

------_=_NextPart_001_01C39CB8.3F0762B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 15:09:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05144; Mon, 27 Oct 2003 15:09:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDfh-0002eb-Hp; Mon, 27 Oct 2003 15:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDfE-0002Pe-AP for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 15:08:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04857 for ; Mon, 27 Oct 2003 15:08:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEDfB-0003Q5-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 15:08:29 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AEDfA-0003PX-00 for dhcwg@ietf.org; Mon, 27 Oct 2003 15:08:28 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9RK7ujP021089; Mon, 27 Oct 2003 12:07:56 -0800 (PST) Received: from kkinnear-w2k03.cisco.com ([161.44.65.180]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADM50752; Mon, 27 Oct 2003 15:07:54 -0500 (EST) Message-Id: <4.3.2.7.2.20031027145803.0259e3d0@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Oct 2003 15:07:53 -0500 To: "Kostur, Andre" , dhcwg@ietf.org From: Kim Kinnear Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt Cc: kkinnear@cisco.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 01:29 PM 10/27/2003, Kostur, Andre 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 : DHCP Lease Query >> Author(s) : R. Woundy, K. Kinnear >> Filename : draft-ietf-dhc-leasequery-06.txt >> Pages : 25 >> Date : 2003-10-24 > >A question/clarification on section 6.3. At the end of this section it states: > > The giaddr is used only for the destination address of any generated > response and, while required, is not otherwise used in generating the > response to the DHCPLEASEQUERY message. It MUST NOT be used to > restrict the processing of the query in any way, and MUST NOT be used > locate a subnet to which the ciaddr (if any) must belong. > >What is this staement defending against when it says "It MUST NOT be used to restrict the processing of the query in any way"? Does this mean that a DHCP server implementation may not use the giaddr to determine whether or not to answer the query? This statement was placed in the draft to clarify the use of the giaddr as *only* the return address of the leasequery message. Note that in standard DHCP packet, the giaddr is *both* the return address as well as the determiner of the network segment on which an IP address should be appear (or be allocated). FOr instance, in a DHCPREQUEST/INIT-REBOOT, the giaddr and the requested-ip are compared to see if they are compatible, and if they aren't, then the DHCPREQUEST/INIT-REBOOT will be NAKed. A DHCPREQUEST/REBINDING has much the same processing with the giaddr and the ciaddr. The idea is that a DHCPLEASEQUERY with an IP address in the ciaddr and the return address for the packet in the giaddr should not be rejected because the IP address in the ciaddr isn't on the network segment pointed to by the giaddr. Given that the giaddr is the return address of the packet, if the DHCP server doesn't want to send a response to that IP address, then it is perfectly free to not send it to that IP address. It just shouldn't try to compare the ciaddr and giaddr in the "normal" way, and get upset if the don't appear compatible. I'll note this as a last call comment, since I could certainly clean that paragraph up with another sentence or two. > Does this conflict with the statement later on in section 7: > > In some environments it may be appropriate to configure a DHCP server > with the IP addresses of the relay agents for which it may respond to > DHCPLEASEQUERY messages, thereby allowing it to respond only to to > requests from only a handful of relay agents. This does not provide > any true security, but may be useful to thwart unsophisticated > attacks of various sorts. > >Or is section 7 expecting the service to look at the source IP of the incoming packet vs. the reported giaddr? Doesn't really matter. I'd think the giaddr would be fine, since this is where you are going to send the packet. Cheers -- Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 15:38:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08294; Mon, 27 Oct 2003 15:38:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEE7l-0007IG-6g; Mon, 27 Oct 2003 15:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEE7N-0007B3-8r for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 15:37:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08164; Mon, 27 Oct 2003 15:37:25 -0500 (EST) Message-Id: <200310272037.PAA08164@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 15:37:25 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-ddns-resolution-06.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Resolution of DNS Name Conflicts Among DHCP Clients Author(s) : M. Stapp Filename : draft-ietf-dhc-ddns-resolution-06.txt Pages : 12 Date : 2003-10-27 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document describes techniques for the resolution of DNS name conflicts among DHCP clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-ddns-resolution-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27155422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-ddns-resolution-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27155422.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 15:38:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08296; Mon, 27 Oct 2003 15:38:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEE7m-0007Iv-LU; Mon, 27 Oct 2003 15:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEE7b-0007GB-GP for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 15:37:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08200; Mon, 27 Oct 2003 15:37:39 -0500 (EST) Message-Id: <200310272037.PAA08200@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 15:37:39 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Time Configuration Options for DHCPv6 Author(s) : a. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt Pages : 8 Date : 2003-10-27 This document describes the options for Time related configuration information in DHCPv6: NTP Servers and Timezone specifier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27155448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27155448.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 16:24:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08295; Mon, 27 Oct 2003 15:38:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEE7l-0007Ie-UZ; Mon, 27 Oct 2003 15:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEE7V-0007Do-8a for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 15:37:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08187; Mon, 27 Oct 2003 15:37:33 -0500 (EST) Message-Id: <200310272037.PAA08187@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 15:37:33 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-fqdn-option-06.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The DHCP Client FQDN Option Author(s) : M. Stapp, Y. Rekhter Filename : draft-ietf-dhc-fqdn-option-06.txt Pages : 15 Date : 2003-10-27 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document specifies a DHCP option which can be used to exchange information about a DHCP client's fully-qualified domain name, and about responsibility for updating DNS RRs related to the client's DHCP lease. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-fqdn-option-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-fqdn-option-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27155435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-fqdn-option-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-fqdn-option-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27155435.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 17:10:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19366; Mon, 27 Oct 2003 17:10:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFYo-0007UF-8h; Mon, 27 Oct 2003 17:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFXv-0007P3-1d for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 17:09:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18852; Mon, 27 Oct 2003 17:08:54 -0500 (EST) Message-Id: <200310272208.RAA18852@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 17:08:53 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-implementation-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Implementation Issues with RFC 2131, 'Dynamic Host Configuration Protocol' Author(s) : R. Hibbs Filename : draft-ietf-dhc-implementation-01.txt Pages : 33 Date : 2003-10-24 This memo identifies implementation issues with RFC 2131, 'Dynamic Host Configuration Protocol,' reported by a number of implementors, assesses the severity of the problem, then proposes changes to RFC 2131 intended to overcome the issues. This is intended for use as the basis for discussion of RFC 2131 before it is proposed for Internet Standard status. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-implementation-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-implementation-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-implementation-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27170944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-implementation-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-implementation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27170944.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 17:10:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19365; Mon, 27 Oct 2003 17:10:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFYo-0007UT-Tx; Mon, 27 Oct 2003 17:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFXy-0007PD-T0 for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 17:09:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18865; Mon, 27 Oct 2003 17:08:58 -0500 (EST) Message-Id: <200310272208.RAA18865@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 17:08:57 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-auth-suboption-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Authentication Suboption for the DHCP Relay Agent Option Author(s) : M. Stapp, T. Lemon, R. Droms Filename : draft-ietf-dhc-auth-suboption-02.txt Pages : 14 Date : 2003-10-24 The DHCP Relay Agent Information Option (RFC3046[1]) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines a new 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 a payload derived from the option used in DHCP Authentication (RFC3118[2]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-auth-suboption-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-auth-suboption-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27170954.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-auth-suboption-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-auth-suboption-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27170954.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Oct 27 17:59:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19367; Mon, 27 Oct 2003 17:10:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFYn-0007U0-GR; Mon, 27 Oct 2003 17:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFXs-0007Oc-6X for dhcwg@optimus.ietf.org; Mon, 27 Oct 2003 17:09:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18832; Mon, 27 Oct 2003 17:08:51 -0500 (EST) Message-Id: <200310272208.RAA18832@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 17:08:51 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Lease Query Author(s) : R. Woundy, K. Kinnear Filename : draft-ietf-dhc-leasequery-06.txt Pages : 25 Date : 2003-10-24 A DHCP server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Other processes and devices, many that already send and receive DHCP format packets, sometimes need to access this information. The leasequery protocol is designed to give these processes and devices a lightweight way to access information that may be critical to their operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-leasequery-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-leasequery-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27170928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-leasequery-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-leasequery-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27170928.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Oct 28 17:28:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01775; Tue, 28 Oct 2003 17:28:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEcIn-0007FX-S6; Tue, 28 Oct 2003 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEcHu-00075h-LW for dhcwg@optimus.ietf.org; Tue, 28 Oct 2003 17:26:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01679 for ; Tue, 28 Oct 2003 17:25:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEcHs-00016R-00 for dhcwg@ietf.org; Tue, 28 Oct 2003 17:26:04 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AEcHr-00016L-00 for dhcwg@ietf.org; Tue, 28 Oct 2003 17:26:03 -0500 Date: Tue, 28 Oct 2003 14:26:50 -0800 From: Alper Yegin To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Comments on dhc-auth-sigzero Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Here are some comments on the draft-ietf-dhc-auth-sigzero-00.txt... - First of all, the solution is lacking the authorization aspect. As such, it is just providing "authentication to hold accountable", not "authentication to authorize." Imho, while the former is useful to some extent, it is not sufficient for solving the DHCP security problem. - The "envisioned second use" (see introduction section) would generally require interaction with the AAA protocols for the roaming scenarios. Without this, how will the authorization parameters be available to the DHCP server? - " If no preferred offer is seen, then the client MUST select among the offers in a non-deterministic manner (ideally, random). This step is important so that a client that has once been deceived into binding to the wrong DHCP server will have a chance to select a different server." The chances might be still low, as the attacker can send too many DHCPOFFER messages. (Can the client look at the link-layer address and discard them??) - The client configures the IP stack and DNS server IP address during the PROVISIONALLY-BOUND state. These parameters are obtained from potentially malicious nodes, and configuring them even for a brief period of time (what is the timeout value?) opens up a window for abuse. Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 29 08:09:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06012; Wed, 29 Oct 2003 08:09:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEq4N-00016o-0h; Wed, 29 Oct 2003 08:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEq3y-00013P-Jv for dhcwg@optimus.ietf.org; Wed, 29 Oct 2003 08:08:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05932; Wed, 29 Oct 2003 08:08:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEq3x-0000KJ-00; Wed, 29 Oct 2003 08:08:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AEq3x-0000JY-00; Wed, 29 Oct 2003 08:08:37 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 29 Oct 2003 05:08:02 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9TD7sbd002660; Wed, 29 Oct 2003 05:07:55 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-428.cisco.com [10.82.241.172]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADN86390; Wed, 29 Oct 2003 08:07:53 -0500 (EST) Message-Id: <4.3.2.7.2.20031029080546.01f0d690@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Oct 2003 08:07:50 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Agenda for dhc WG meeting in Minneapolis Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Included below is a first draft agenda for the dhc WG meeting in Minneapolis. If you have additional agenda items, or if I've missed an agenda item you've already requested, please contact me *immediately* to get on the agenda. - Ralph DHC WG agenda - IETF 58 Thu 11/13/2003 0900 (tentative) (Last revised 10/29/2003 08:05 AM) ---------------------------------- Administrivia; agenda bashing Ralph Droms 05 minutes Implementation Issues with RFC 2131 Ralph Droms 30 minutes Discussion; next steps; other work related to advancing RFC 2131 Extending DHCP Options Codes Ralph Droms 10 minutes DHCPv4 Threat Analysis Carl Smith (?) 10 minutes DHCP Authentication using DNS KEY records Ted Lemon (?) 10 minutes RFC3118 Delayed authentication using PANA H. Tschofenig (?) 10 minutes Flexible Authentication for DHCP Messages Vipul Gupta 10 minutes Node-Specific Client Identifiers for DHCPv4 Ted Lemon 10 minutes Site Specific Options for DHCP for IPv6 Ralph Droms 05 minutes Rapid Reply Option for DHCPv4 S. D. Park (?) 10 minutes Client Identifier option in server replies N. Swamy 10 minutes ----------- Total 120 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 29 10:08:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10857; Wed, 29 Oct 2003 10:08:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AErvV-0001fj-DQ; Wed, 29 Oct 2003 10:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AErup-0001Oe-6E for dhcwg@optimus.ietf.org; Wed, 29 Oct 2003 10:07:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10655 for ; Wed, 29 Oct 2003 10:07:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AErun-00025h-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 10:07:17 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AErum-00025N-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 10:07:16 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h9TF6ibd010352 for ; Wed, 29 Oct 2003 07:06:44 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADN95067; Wed, 29 Oct 2003 10:06:42 -0500 (EST) Message-Id: <4.3.2.7.2.20031029095850.01ef8f70@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Oct 2003 10:06:41 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] dhc WG document status report Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Included below is a report of dhc WG activity since the last WG meeting. I won't discuss these events at the WG meeting in Minneapolis but we will have time for specific questions at the beginning of the meeting. - Ralph dhc WG activity report ====================== RFCs published: --------------- 3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 3594: PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option RFC Editor Queue: ----------------- IPv6 Prefix Options for DHCPv6 KDC Server Address Sub-option Approved by IESG: ----------------- DNS Configuration options for DHCPv6 Submitted to IESG: ------------------ A Guide to Implementing Stateless DHCPv6 Service Authentication of DHCP Relay Agent Options Using IPsec Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Server MIB Time Configuration Options for DHCPv6 NIS Configuration Options for DHCPv6 Unused DHCP Option Codes The IPv4 DHCP Option for the Internet Storage Name Service dhc WG last calls (completed): ------------------------------ RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option : passed; ready for submission to IESG DHCP Option for Mobile IP Mobility Agents : passed; author will revise prior to submission to IESG DHCP Preboot eXecution Environment (PXE) Suboptions : passed; revision required prior to submission to IESG Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis : insufficient response to determine consensus; new WG last call will be announced dhc WG last calls (in progress): -------------------------------- DHCP Lease Query : ends 10/31/2003 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 29 15:10:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02946; Wed, 29 Oct 2003 15:10:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwdm-0006D4-4k; Wed, 29 Oct 2003 15:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwdL-0006A3-I5 for dhcwg@optimus.ietf.org; Wed, 29 Oct 2003 15:09:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02762; Wed, 29 Oct 2003 15:09:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwdI-0002Cb-00; Wed, 29 Oct 2003 15:09:32 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AEwdH-0002BA-00; Wed, 29 Oct 2003 15:09:31 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Oct 2003 12:11:25 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9TK8wjP022203; Wed, 29 Oct 2003 12:08:59 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-515.cisco.com [10.82.242.3]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADO28321; Wed, 29 Oct 2003 15:08:57 -0500 (EST) Message-Id: <4.3.2.7.2.20031029150420.01f218f0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Oct 2003 15:08:54 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Agenda for dhc WG meeting in Minneapolis (revised) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Included below is a revised draft agenda for the dhc WG meeting in Minneapolis. If you have additional agenda items, or if I've missed an agenda item you've already requested, please contact me *immediately* to get on the agenda. - Ralph DHC WG agenda - IETF 58 Thu 11/13/2003 0900 (tentative) (Last revised 10/29/2003 03:01 PM) ---------------------------------- Administrivia; agenda bashing Ralph Droms 05 minutes Implementation Issues with RFC 2131 Ralph Droms 20 minutes Discussion; next steps; other work related to advancing RFC 2131 Extending DHCP Options Codes Ralph Droms 10 minutes Discussion; which extension plan to accept; next steps/roadmap DHCPv4 Threat Analysis Carl Smith (?) 10 minutes Final discussion; solicit WG last call review DHCP Authentication using DNS KEY records Ted Lemon (?) 10 minutes RFC3118 Delayed authentication using PANA H. Tschofenig (?) 10 minutes Accept as WG work item? Flexible Authentication for DHCP Messages Vipul Gupta 10 minutes Discussion of DHCP authentication Ralph Droms 20 minutes Review three authentication proposals; next steps/roadmap Configuration of dual-stack hosts with DHCP Ralph Droms 20 minutes Node-Specific Client Identifiers for DHCPv4 Ted Lemon 10 minutes Initial discussion Rapid Reply Option for DHCPv4 S. D. Park (?) 10 minutes Accept as WG work item? Client Identifier option in server replies N. Swamy 10 minutes Accept as WG work item? ----------- Total 145 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 29 15:51:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05515; Wed, 29 Oct 2003 15:51:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AExHR-0002aB-VV; Wed, 29 Oct 2003 15:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AExGc-0002Xk-Lk for dhcwg@optimus.ietf.org; Wed, 29 Oct 2003 15:50:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05498 for ; Wed, 29 Oct 2003 15:50:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AExGb-0003A0-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 15:50:09 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AExGZ-00039Z-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 15:50:08 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Oct 2003 12:48:33 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9TKnZjP005417 for ; Wed, 29 Oct 2003 12:49:35 -0800 (PST) Received: from cisco.com ([161.44.65.126]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADO32692; Wed, 29 Oct 2003 15:49:33 -0500 (EST) Message-ID: <3FA027DD.8060105@cisco.com> Date: Wed, 29 Oct 2003 15:49:33 -0500 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; 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] I-D ACTION:draft-ietf-dhc-leasequery-06.txt References: <200310271419.JAA14690@ietf.org> In-Reply-To: <200310271419.JAA14690@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit With the new draft available, and the last call ongoing in the prior version, I wanted to make clear my support for moving this document forward with the edits contained in -06. I do believe the references to FAILOVER, and perhaps DHCPMIB, will need to be adjusted, since an RFC cannot refer to an Internet-Draft, but I have no other comments. 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 : DHCP Lease Query > Author(s) : R. Woundy, K. Kinnear > Filename : draft-ietf-dhc-leasequery-06.txt > Pages : 25 > Date : 2003-10-24 > -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 29 16:01:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05902; Wed, 29 Oct 2003 16:01:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AExR9-0003VQ-6u; Wed, 29 Oct 2003 16:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AExQu-0003Tu-Uw for dhcwg@optimus.ietf.org; Wed, 29 Oct 2003 16:00:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05834 for ; Wed, 29 Oct 2003 16:00:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AExQt-0003Hr-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 16:00:47 -0500 Received: from [206.80.111.140] (helo=quiet-like-a-panther.org) by ietf-mx with smtp (Exim 4.12) id 1AExQr-0003Hl-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 16:00:46 -0500 Received: (qmail 12300 invoked by uid 511); 29 Oct 2003 21:00:15 -0000 Message-ID: <20031029210015.12299.qmail@quiet-like-a-panther.org> References: <4.3.2.7.2.20031012090550.048f5a38@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20031012090550.048f5a38@flask.cisco.com> From: Michael Johnston To: Ralph Droms Cc: dhcwg@ietf.org;, michael.johnston@intel.com Date: Wed, 29 Oct 2003 20:59:37 GMT Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_0_12296_1067461207"; charset="us-ascii" Subject: [dhcwg] Update: draft-ietf-dhc-pxe-options-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a MIME-formatted message. If you see this text it means that your mail software cannot handle MIME-formatted messages. --=_0_12296_1067461207 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Here is the updated DHCP PXE options draft. I hope I got in all of the requested changes. %%michael --=_0_12296_1067461207 Content-Type: text/plain; name="draft-ietf-dhc-pxe-options-01.txt" Content-Disposition: attachment; filename="draft-ietf-dhc-pxe-options-01.txt" Content-Transfer-Encoding: base64 CgoKCgpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTS4gSm9obnN0b24gCmRyYWZ0LWlldGYtZGhjLXB4ZS1vcHRpb25zLTAxLnR4dCAg ICAgICAgICAgICAgICAgICAgICBJbnRlbCBDb3Jwb3JhdGlvbiAKRXhwaXJlczogQXByaWwgMjAw NCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjkgT2N0b2JlciAyMDAzIAog CiAKIAogICAgICAgICAgREhDUCBQcmVib290IGVYZWN1dGlvbiBFbnZpcm9ubWVudCAoUFhFKSBP cHRpb25zIAogICAgICAgICAgICAgICA8ZHJhZnQtaWV0Zi1kaGMtcHhlLW9wdGlvbnMtMDEudHh0 PiAKIAogClN0YXR1cyBvZiB0aGlzIE1lbW8gCiAgICAKICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJ bnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIAogICBhbGwgcHJv dmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuIAogICAgCiAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIAogICBU YXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90 ZSB0aGF0IAogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3Vt ZW50cyBhcyBJbnRlcm5ldC0KICAgRHJhZnRzLiAKICAgIAogICBJbnRlcm5ldC1EcmFmdHMgYXJl IGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCAKICAgbW9udGhzIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgCiAgIGF0IGFueSB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQt RHJhZnRzIGFzIAogICByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRo YW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIiAKIAogICAgICBUaGUgbGlzdCBvZiBjdXJyZW50IElu dGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQgCiAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dCAKICAgICAgIAogICAgICBUaGUgbGlzdCBvZiBJbnRl cm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0IAogICAgICBo dHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIAogICAgICAgCiAgIFRoaXMgSW50ZXJuZXQt RHJhZnQgd2lsbCBleHBpcmUgb24gQXByaWwgMSwgMjAwNC4gCiAKIApDb3B5cmlnaHQgTm90aWNl IAogCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDMpLiAgQWxsIFJp Z2h0cyBSZXNlcnZlZC4gCiAKIApBYnN0cmFjdCAgIAogICAgCiAgIERlZmluZSBESENQIG9wdGlv bnMgYmVpbmcgdXNlZCBieSBQWEUgYW5kIEVGSSBjbGllbnRzLiAKICAgIAogICAgCgoKCgoKCgoK CgoKCgpKb2huc3RvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgMV0gCiAMCgoKCgpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICBE SENQIFBYRSBTdWJvcHRpb25zICAgICAgICAgICAgIE9jdG9iZXIsIDIwMDMgCiAKIApUYWJsZSBv ZiBDb250ZW50cyAKICAgIAogU3RhdHVzIG9mIHRoaXMgTWVtby4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xIAogQ29weXJpZ2h0IE5vdGljZS4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xIAogQWJzdHJhY3QuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xIAogVGFi bGUgb2YgQ29udGVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4yIAogSW50cm9kdWN0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4yIAogMS4xLiAgQ29udmVudGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yIAogMS4yLiAgRG9jdW1lbnQgUmV2aXNpb24g Q2hhbmdlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zIAogMi4gIE9wdGlvbiBE ZWZpbml0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zIAog Mi4xLiAgQ2xpZW50IFN5c3RlbSBBcmNoaXRlY3R1cmUgVHlwZSBPcHRpb24gRGVmaW5pdGlvbi4u Li4uLi4uLi4zIAogMi4yLiAgQ2xpZW50IE5ldHdvcmsgSW50ZXJmYWNlIElkZW50aWZpZXIgT3B0 aW9uIERlZmluaXRpb24uLi4uLi40IAogMi4zLiAgQ2xpZW50IE1hY2hpbmUgSWRlbnRpZmllciBP cHRpb24gRGVmaW5pdGlvbi4uLi4uLi4uLi4uLi4uLi41IAogMi40LiAgU2l0ZSBTcGVjaWZpYyBP cHRpb25zIEJlaW5nIFJlcXVlc3RlZCBCeSBQWEUgQ2xpZW50cy4uLi4uLi41IAogMy4gIElBTkEg Q29uc2lkZXJhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41 IAogUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi41CiBBdXRob3IgSW5mb3JtYXRpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgCiBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgCiAgICAKICAgIApJbnRyb2R1Y3Rp b24gCiAgICAKICAgVGhlc2UgREhDUCBvcHRpb25zIGFyZSBiZWluZyB3aWRlbHkgdXNlZCBieSBQ WEUgY29tcGxpYW50IGNsaWVudHMgdG8gCiAgIHVuaXF1ZWx5IGlkZW50aWZ5IGJvb3RpbmcgdGhl bXNlbHZlcyBhbmQgdGhlaXIgcHJlLU9TIHJ1bnRpbWUgCiAgIGVudmlyb25tZW50IHNvIHRoZSBE SENQIGFuZC9vciBQWEUgYm9vdCBzZXJ2ZXIgY2FuIHJldHVybiB0aGUgCiAgIGNvcnJlY3QgT1Mg Ym9vdHN0cmFwIGltYWdlIChvciBwcmUtYm9vdCBhcHBsaWNhdGlvbikgbmFtZSBhbmQgc2VydmVy IAogICB0byB0aGUgY2xpZW50LiAKICAgIAogICBJbiB0aGUgcGFzdCwgdGhpcyB3b3JrIHdhcyBk b25lIGJ5IGV4YW1pbmluZyB0aGUgbmV0d29yayBNQUMgYWRkcmVzcyAKICAgaW4gdGhlICJjaGFk ZHIiIGZpZWxkIGluIHRoZSBCT09UUC9ESENQIGhlYWRlciBhbmQga2VlcGluZyBhIAogICBkYXRh YmFzZSBvZiBNQUMgYWRkcmVzc2VzIG9uIHRoZSBCT09UUC9ESENQIHNlcnZlci4gIFRoaXMgd2Fz IGRlZW1lZCAKICAgaW5zdWZmaWNpZW50IGZvciBsYXJnZSBhbmQgY29tcGxleCBuZXR3b3JrcyBm b3IgdHdvIG1haW4gcmVhc29ucy4gIAogICAxKSBNdWx0aXBsZSBsYXB0b3BzIGNvdWxkIGVuZCB1 cCB3aXRoIHRoZSBzYW1lIE1BQyBhZGRyZXNzIGlmIHRoZSAKICAgTklDIHdhcyBpbiBhIHNoYXJl ZCBkb2NraW5nIHN0YXRpb24uICAyKSBNdWx0aXBsZSBuZXR3b3JrIGRldmljZXMgCiAgIGFuZCBN QUMgYWRkcmVzc2VzIGNvdWxkIGJlIHVzZWQgYnkgb25lIG1hY2hpbmUgZm9yIHJlZHVuZGFuY3kg b3IgCiAgIGJlY2F1c2Ugb2YgcmVwYWlycy4gCiAgICAKICAgQW5vdGhlciBpc3N1ZSB0aGF0IGNh bWUgdXAgd2FzIHRoZSBtYWNoaW5lIHRoYXQgY291bGQgY2hhbmdlIGl0cyAKICAgcHJlLU9TIHJ1 bnRpbWUgZW52aXJvbm1lbnQuICBUaGlzIGlzc3VlIGNhdXNlZCB0aGUgY3JlYXRpb24gb2YgCiAg IGFub3RoZXIgbmV3IG9wdGlvbiB0byBpZGVudGlmeSB0aGUgcnVudGltZSBlbnZpcm9ubWVudCBz byB0aGUgCiAgIGNvcnJlY3QgYmluYXJ5IGltYWdlIGNvdWxkIGJlIG1hdGNoZWQgdXAgd2l0aCB0 aGUgYm9vdGluZyBtYWNoaW5lLiAKICAgIAogICBUaGVzZSBvcHRpb25zIGFyZSBkZWZpbmVkIGlu IHRoZSBQWEUgW3B4ZV0gYW5kIEVGSSBbZWZpXSAKICAgc3BlY2lmaWNhdGlvbnMgYW5kIGFyZSBi ZWluZyBkb2N1bWVudGVkIGluIHRoaXMgZHJhZnQgZm9yIAogICBjb21wbGV0ZW5lc3Mgd2l0aGlu IHRoZSBJRVRGLiAKICAgIAogICBDb21tZW50cyBhYm91dCB0aGlzIEludGVybmV0IERyYWZ0IHNo b3VsZCBiZSBzZW50IHRvIHRoZSAKICAgZGhjd2dAaWV0Zi5vcmcgbWFpbGluZyBsaXN0LiAKICAg IAogICAgCjEuMS4gQ29udmVudGlvbnMgCiAgICAKCgoKSm9obnN0b24gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdIAogDAoKCgoK SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgREhDUCBQWEUgU3Vib3B0aW9ucyAgICAgICAgICAg ICBPY3RvYmVyLCAyMDAzIAogCiAKICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIs ICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCAKICAgIlNIT1VMRCIsICJTSE9VTEQg Tk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMgCiAgIGRv Y3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDLTIxMTkgW3Jm YzIxMTldLiAKICAgIAoxLjIuIERvY3VtZW50IFJldmlzaW9uIENoYW5nZXMgCiAgICAKICAgUmV2 LiAwMCBUbyBSZXYuIDAxIAogICAgCiAgICAgbyBDaGFuZ2VkIGFsbCBvY2N1cmFuY2VzIG9mICJz dWJvcHRpb24iIHRvICJvcHRpb24iLiAKICAgICBvIFJlLXdvcmRlZCBmaXJzdCBzZW50ZW5jZSBv ZiBJbnRyb2R1Y3Rpb24gdG8gY2xhcmlmeSB0aGF0IHRoZXNlIAogICAgICAgIG9wdGlvbnMgYXJl IGluIHdpZGUgdXNlIGJ5IFBYRSBjbGllbnRzLiAKICAgICBvIENsYXJpZmllZCBleHRlcm5hbCBk b2N1bWVudCByZWZlcmVuY2VzLiAKICAgICBvIEFkZGVkIGRlc2NyaXB0aW9uIG9mIHNpdGUgc3Bl Y2lmaWMgb3B0aW9ucyAxMjggdGhyb3VnaCAxMzUuIAogICAgIG8gQWRkZWQgSUFOQSBDb25zaWRl cmF0aW9ucyBhbmQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgCiAgICAgICAgc2VjdGlvbnMuIAog ICAgCiAgICAKMi4gT3B0aW9uIERlZmluaXRpb25zIAogICAgCiAgICAKMi4xLiBDbGllbnQgU3lz dGVtIEFyY2hpdGVjdHVyZSBUeXBlIE9wdGlvbiBEZWZpbml0aW9uIAogICAgCiAgIFRoZSBmb3Jt YXQgb2YgdGhlIG9wdGlvbiBpczogCiAgICAKICAgICAgIENvZGUgIExlbiAgMTYtYml0IFR5cGUg CiAgICAgICstLS0tKy0tLS0tKy0tLS0tKy0tLS0tKyAKICAgICAgfCA5MyB8ICBuICB8IG4xICB8 IG4yICB8IAogICAgICArLS0tLSstLS0tLSstLS0tLSstLS0tLSsgCiAgICAKICAgT2N0ZXQgIm4i IE1VU1QgYmUgYW4gZXZlbiBudW1iZXIgZ3JlYXRlciB0aGFuIHplcm8uICBDbGllbnRzIHRoYXQg CiAgIHN1cHBvcnQgbW9yZSB0aGFuIG9uZSBhcmNoaXRlY3R1cmUgdHlwZSBNQVkgaW5jbHVkZSBh IGxpc3Qgb2YgdGhlc2UgCiAgIHR5cGVzIGluIHRoZWlyIGluaXRpYWwgREhDUCBhbmQgUFhFIGJv b3Qgc2VydmVyIHBhY2tldHMuICBUaGUgbGlzdCAKICAgb2Ygc3VwcG9ydGVkIGFyY2hpdGVjdHVy ZSB0eXBlcyBNQVkgYmUgcmVkdWNlZCBpbiBhbnkgcGFja2V0IAogICBleGNoYW5nZSBiZXR3ZWVu IHRoZSBjbGllbnQgYW5kIHNlcnZlcihzKS4gCiAgICAKICAgT2N0ZXRzICJuMSIgYW5kICJuMiIg ZW5jb2RlIGEgMTYtYml0IGFyY2hpdGVjdHVyZSB0eXBlIGlkZW50aWZpZXIgCiAgIHRoYXQgZGVz Y3JpYmVzIHRoZSBwcmUtYm9vdCBydW50aW1lIGVudmlyb25tZW50KHMpIG9mIHRoZSBjbGllbnQg CiAgIG1hY2hpbmUuIAogICAgCiAgICAKICAgQ2xpZW50IFN5c3RlbSBBcmNoaXRlY3R1cmUgVHlw ZXMgCiAgICAKICAgQXMgb2YgdGhlIHdyaXRpbmcgb2YgdGhpcyBkb2N1bWVudCB0aGUgZm9sbG93 aW5nIHByZS1ib290IAogICBhcmNoaXRlY3R1cmUgdHlwZXMgaGF2ZSBiZWVuIHJlcXVlc3RlZC4g CiAgICAKICAgVHlwZSAgIEFyY2hpdGVjdHVyZSBOYW1lIAogICAtLS0tICAgLS0tLS0tLS0tLS0t LS0tLS0gCiAgICAgMCAgICBJbnRlbCB4ODZQQyAgCiAgICAgMSAgICBORUMvUEM5OCAKICAgICAy ICAgIEVGSSBJdGFuaXVtICAKICAgICAzICAgIERFQyBBbHBoYSAKICAgICA0ICAgIEFyYyB4ODYg CiAgICAgNSAgICBJbnRlbCBMZWFuIENsaWVudCAKICAgICA2ICAgIEVGSSBJQTMyICAKCkpvaG5z dG9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSAzXSAKIAwKCgoKCklOVEVSTkVULURSQUZUICAgICAgICAgICAgIERIQ1AgUFhFIFN1 Ym9wdGlvbnMgICAgICAgICAgICAgT2N0b2JlciwgMjAwMyAKIAogCiAgICAgNyAgICBFRkkgQnl0 ZSBDb2RlIChFQkMpIAogICAgIDggICAgRUZJIFhzY2FsZSAKICAgIAogICBUaGlzIG9wdGlvbiBt dXN0IGJlIHByZXNlbnQgaW4gYWxsIERIQ1AgYW5kIFBYRSBwYWNrZXRzIHNlbnQgYnkgUFhFIAog ICBjb21wbGlhbnQgY2xpZW50cyBhbmQgc2VydmVycy4gCiAgICAKICAgIAoyLjIuIENsaWVudCBO ZXR3b3JrIEludGVyZmFjZSBJZGVudGlmaWVyIE9wdGlvbiBEZWZpbml0aW9uIAogICAgCiAgIFRo ZSBmb3JtYXQgb2YgdGhlIG9wdGlvbiBpczogCiAgICAKICAgICAgIENvZGUgIExlbiAgVHlwZSBN YWpvciBNaW5vciAKICAgICAgKy0tLS0rLS0tLS0rLS0tLSstLS0tLSstLS0tLSsgCiAgICAgIHwg OTQgfCAgMyAgfCAgdCB8ICBNICB8ICBtICB8IAogICAgICArLS0tLSstLS0tLSstLS0tKy0tLS0t Ky0tLS0tKyAKICAgIAogICBPY3RldCAidCIgZW5jb2RlcyBhIG5ldHdvcmsgaW50ZXJmYWNlIHR5 cGUuICBGb3Igbm93IHRoZSBvbmx5IAogICBzdXBwb3J0ZWQgdmFsdWUgaXMgMSBmb3IgVU5ESSAo VW5pdmVyc2FsIE5ldHdvcmsgRGV2aWNlIEludGVyZmFjZSkuIAogICAgCiAgIE9jdGV0cyAiTSIg YW5kICJtIiBkZXNjcmliZSB0aGUgaW50ZXJmYWNlIHJldmlzaW9uLiAgVG8gZW5jb2RlIHRoZSAK ICAgVU5ESSByZXZpc2lvbiBvZiAyLjExLCAiTSIgd291bGQgc2V0IHRvIDIgYW5kICJtIiB3b3Vs ZCBiZSBzZXQgdG8gMTEgCiAgICgweDBCKS4gCiAgICAKICAgUmV2aXNpb24gIERlc2NyaXB0aW9u IAogICAtLS0tLS0tLSAgLS0tLS0tLS0tLS0gCiAgIDwgMi4wMCAgICBMQU5EZXNrIHNlcnZpY2Ug YWdlbnQgYm9vdCBST01zLiAgTm8gUFhFIEFQSXMuIAogICAgCiAgICAgMi4wMCAgICBGaXJzdCBn ZW5lcmF0aW9uIFBYRSBib290IFJPTXMuICAoUFhFTlYrKSAgW3B4ZV0gCiAgICAKICAgICAyLjAx ICAgIFNlY29uZCBnZW5lcmF0aW9uIFBYRSBib290IFJPTXMuICAoIVBYRSkgICBbcHhlXSAKICAg IAogICAgIDMuMDAgICAgMzIvNjQtYml0IFVOREkgc3BlY2lmaWNhdGlvbi4gIChBbHBoYSkgIFtl ZmldIAogICAgICAgICAgICAgRUZJIGJvb3Qgc2VydmljZXMgZHJpdmVyIG9ubHkuICBObyBFRkkg cnVudGltZSBzdXBwb3J0LiAKICAgIAogICAgIDMuMTAgICAgMzIvNjQtYml0IFVOREkgc3BlY2lm aWNhdGlvbi4gIChCZXRhKSAgW2VmaV0gCiAgICAgICAgICAgICBGaXJzdCBnZW5lcmF0aW9uIEVG SSBydW50aW1lIGRyaXZlciBzdXBwb3J0LiAKICAgIAogICAgIDMuMjAgICAgMzIvNjQtYml0IFVO REkgc3BlY2lmaWNhdGlvbi4gIChSZWxlYXNlKSAgW2VmaV0gCiAgICAgICAgICAgICBTZWNvbmQg Z2VuZXJhdGlvbiBFRkkgcnVudGltZSBkcml2ZXIgc3VwcG9ydC4gCiAgICAKICAgVGhpcyBvcHRp b24gbXVzdCBiZSBwcmVzZW50IGluIGFsbCBESENQIGFuZCBQWEUgcGFja2V0cyBzZW50IGJ5IFBY RSAKICAgY29tcGxpYW50IGNsaWVudHMgYW5kIHNlcnZlcnMuIAogICAgCiAgICAKCgoKCgoKCgoK CkpvaG5zdG9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSA0XSAKIAwKCgoKCklOVEVSTkVULURSQUZUICAgICAgICAgICAgIERIQ1Ag UFhFIFN1Ym9wdGlvbnMgICAgICAgICAgICAgT2N0b2JlciwgMjAwMyAKIAogCjIuMy4gQ2xpZW50 IE1hY2hpbmUgSWRlbnRpZmllciBPcHRpb24gRGVmaW5pdGlvbiAKICAgIAogICBUaGUgZm9ybWF0 IG9mIHRoZSBvcHRpb24gaXM6IAogICAgCiAgICAgICBDb2RlICBMZW4gIFR5cGUgIE1hY2hpbmUg SWRlbnRpZmllciAKICAgICAgKy0tLS0rLS0tLS0rLS0tLSstLS0tLSsgLiAuIC4gKy0tLS0tKyAK ICAgICAgfCA5NyB8ICBuICB8ICB0IHwgICAgIHwgLiAuIC4gfCAgICAgfCAKICAgICAgKy0tLS0r LS0tLS0rLS0tLSstLS0tLSsgLiAuIC4gKy0tLS0tKyAKIAogICBPY3RldCAidCIgZGVzY3JpYmVz IHRoZSB0eXBlIG9mIHRoZSBtYWNoaW5lIGlkZW50aWZpZXIgaW4gdGhlIAogICByZW1haW5pbmcg b2N0ZXRzIGluIHRoaXMgb3B0aW9uLiAgMCAoemVybykgaXMgdGhlIG9ubHkgZGVmaW5lZCB2YWx1 ZSAKICAgZm9yIHRoaXMgb2N0ZXQgYXQgdGhlIHByZXNlbnQgdGltZSBhbmQgaXQgZGVzY3JpYmVz IHRoZSByZW1haW5pbmcgCiAgIG9jdGV0cyBhcyBhIDE2LW9jdGV0IEdVSUQuICBPY3RldCAibiIg aXMgMTcgZm9yIHR5cGUgMC4gCiAgIChPbmUgZGVmaW5pdGlvbiBvZiBHVUlEIGNhbiBiZSBmb3Vu ZCBpbiBBcHBlbmRpeCBBIGluIHRoZSBFRkkgCiAgIHNwZWNpZmljYXRpb24gW2VmaV0uKSAKICAg IAogICBUaGlzIG9wdGlvbiBtdXN0IGJlIHByZXNlbnQgaW4gYWxsIERIQ1AgYW5kIFBYRSBwYWNr ZXRzIHNlbnQgYnkgUFhFIAogICBjb21wbGlhbnQgY2xpZW50cyBhbmQgc2VydmVycy4gCiAgICAK ICAgIAoyLjQuIFNpdGUgU3BlY2lmaWMgT3B0aW9ucyBCZWluZyBSZXF1ZXN0ZWQgQnkgUFhFIENs aWVudHMgCiAgICAKICAgQWxsIGNvbXBsaWFudCBQWEUgY2xpZW50cyBNVVNUIGluY2x1ZGUgYSBy ZXF1ZXN0IGZvciBESENQIG9wdGlvbnMgCiAgIDEyOCB0aHJvdWdoIDEzNSBpbiBhbGwgREhDUCBh bmQgUFhFIHBhY2tldHMuICBUaGUgZm9ybWF0IGFuZCAKICAgY29udGVudHMgb2YgdGhlc2Ugb3B0 aW9ucyBhcmUgTk9UIGRlZmluZWQgYnkgdGhlIFBYRSBzcGVjaWZpY2F0aW9uLiAgCiAgIFRoZXNl IG9wdGlvbnMgTUFZIGJlIHByZXNlbnQgaW4gdGhlIERIQ1AgYW5kIFBYRSBib290IHNlcnZlciBy ZXBsaWVzIAogICBhbmQgYXJlIG1lYW50IGZvciB1c2UgYnkgdGhlIGRvd25sb2FkZWQgbmV0d29y ayBib290c3RyYXAgcHJvZ3JhbXMuIAogICBUaGVzZSBvcHRpb25zIGFyZSBOT1QgdXNlZCBieSB0 aGUgUFhFIGJvb3QgUk9Ncy4gCiAgICAKIAozLiBJQU5BIENvbnNpZGVyYXRpb25zIAogICAgCiAg IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0d28gbmV3IG5hbWUgc3BhY2VzIGFzc29jaWF0ZWQgd2l0 aCBQWEUgCiAgIGNvbXBsaWFudCBjbGllbnQgbWFjaGluZXM6IENsaWVudCBTeXN0ZW0gQXJjaGl0 ZWN0dXJlIFR5cGUgYW5kIAogICBDbGllbnQgTmV0d29yayBJbnRlcmZhY2UgSWRlbnRpZmllci4g CiAgICAKICAgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gbWFuYWdlIGEgcmVnaXN0cnkgb2YgdmFsdWVz IGZvciB0aGVzZSBuZXcgbmFtZSAKICAgc3BhY2VzLCB3aGljaCBhcmUgZGVzY3JpYmVkIGluIHNl Y3Rpb25zIDIuMSBhbmQgMi4yLiAKICAgIAogICAgCjQuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z IAogICAgCiAgIFRoaXMgZG9jdW1lbnQgaW4gYW5kIGJ5IGl0c2VsZiBwcm92aWRlcyBubyBzZWN1 cml0eSwgbm9yIGRvZXMgaXQgCiAgIGltcGFjdCBleGlzdGluZyBzZWN1cml0eS4gCiAgICAKICAg IApSZWZlcmVuY2VzIAogICAgCiAgIFtyZmMyMTE5XSBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBm b3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgCiAgIFJlcXVpcmVtZW50IExldmVscyIsIFJGQyAy MTE5LCBCQ1AgMTQsIE1hcmNoIDE5OTcuIAogICAgCiAgIFtyZmMyMTMxXSBEcm9tcywgUi4gIkR5 bmFtaWMgSG9zdCBDb25maWd1cmF0aW9uIFByb3RvY29sIiwgUkZDIDIxMzEsIAogICBNYXJjaCAx OTk3LiAKICAgIAoKSm9obnN0b24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDVdIAogDAoKCgoKSU5URVJORVQtRFJBRlQgICAgICAg ICAgICAgREhDUCBQWEUgU3Vib3B0aW9ucyAgICAgICAgICAgICBPY3RvYmVyLCAyMDAzIAogCiAK ICAgW3JmYzIxMzJdIEFsZXhhbmRlciwgUy4gYW5kIERyb21zLCBSLiwgIkRIQ1AgT3B0aW9ucyBh bmQgQk9PVFAgCiAgIFZlbmRvciBFeHRlbnNpb25zIiwgUkZDIDIxMzIsIE1hcmNoIDE5OTcuIAog ICAgCiAgIFtweGVdIEhlbnJ5LCBNLiBhbmQgSm9obnN0b24sIE0uLCAiUHJlYm9vdCBFeGVjdXRp b24gRW52aXJvbm1lbnQgCiAgIChQWEUpIFNwZWNpZmljYXRpb24iLCBTZXB0ZW1iZXIgMTk5OS4g ICAKICAgZnRwOi8vZG93bmxvYWQuaW50ZWwuY29tL2xhYnMvbWFuYWdlL3dmbS9kb3dubG9hZC9w eGVzcGVjLnBkZiAKICAgIAogICBbZWZpXSBJbnRlbCBDb3JwLiwgIkV4dGVuc2libGUgRmlybXdh cmUgSW50ZXJmYWNlIFNwZWNpZmljYXRpb24iLCAKICAgRGVjZW1iZXIgMjAwMi4gCiAgIGh0dHA6 Ly9kZXZlbG9wZXIuaW50ZWwuY29tL3RlY2hub2xvZ3kvZWZpL21haW5fc3BlY2lmaWNhdGlvbi5o dG0gCiAgICAKICAgIApBdXRob3IgSW5mb3JtYXRpb24gCiAKICAgTWljaGFlbCBKb2huc3RvbiAK ICAgSW50ZWwgQ29ycG9yYXRpb24gCiAgIE1TLiBKRjEtMjM5IAogICAyMTExIE5FIDI1dGggQXZl LiAKICAgSGlsbHNib3JvLCBPUiA5NzEyNCAKICAgIAogICBQaG9uZTogICsxIDUwMy0yNjQtOTcw MyAKICAgRW1haWw6ICBtaWNoYWVsLmpvaG5zdG9uQGludGVsLmNvbSAKICAgIAogICAgCkZ1bGwg Q29weXJpZ2h0IFN0YXRlbWVudCAKICAgIAogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBT b2NpZXR5ICgyMDAzKS4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIAogICAgCiAgIFRoaXMgZG9jdW1l bnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8g CiAgIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVy d2lzZSBleHBsYWluIGl0IAogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBi ZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQgCiAgIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hv bGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkgCiAgIGtpbmQsIHByb3Zp ZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIAog ICBhcmUgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiAg SG93ZXZlciwgdGhpcyAKICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4g YW55IHdheSwgc3VjaCBhcyBieSByZW1vdmluZyAKICAgdGhlIGNvcHlyaWdodCBub3RpY2Ugb3Ig cmVmZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBvdGhlciAKICAgSW50ZXJuZXQg b3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgCiAgIGRl dmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMg Zm9yIAogICBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBwcm9j ZXNzIG11c3QgYmUgCiAgIGZvbGxvd2VkLCBvciBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQg aW50byBsYW5ndWFnZXMgb3RoZXIgdGhhbiAKICAgRW5nbGlzaC4gCiAgICAKICAgVGhlIGxpbWl0 ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBhcmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBi ZSAKICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBv ciBhc3NpZ25zLiAKICAgIAogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29u dGFpbmVkIGhlcmVpbiBpcyBwcm92aWRlZCBvbiBhbiAKICAgIkFTIElTIiBiYXNpcyBhbmQgVEhF IElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyAKICAgVEFTSyBGT1JD RSwgVEhFIEFVVEhPUiBBTkQgVEhFIEFVVEhPUpJTIEVNUExPWUVSIERJU0NMQUlNIEFMTCAKICAg V0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVE IFRPIEFOWSAKICAgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTiBIRVJF SU4gV0lMTCBOT1QgSU5GUklOR0UgCiAgIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFO VElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyAKICAgRk9SIEEgUEFSVElDVUxBUiBQ VVJQT1NFLiAKICAgIAoKCkpvaG5zdG9uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA2XSAKIAo= --=_0_12296_1067461207-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 29 17:17:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10579; Wed, 29 Oct 2003 17:17:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEycf-0002lq-2V; Wed, 29 Oct 2003 17:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEyby-0002jq-Sy for dhcwg@optimus.ietf.org; Wed, 29 Oct 2003 17:16:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10485 for ; Wed, 29 Oct 2003 17:16:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEybw-00054z-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 17:16:16 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AEybw-00054w-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 17:16:16 -0500 Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id BD0081B2097; Wed, 29 Oct 2003 16:11:13 -0600 (CST) Date: Wed, 29 Oct 2003 16:16:22 -0600 Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org To: Josh Littlefield From: Ted Lemon In-Reply-To: <3FA027DD.8060105@cisco.com> Message-Id: <872E5AB0-0A5D-11D8-86F4-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Wednesday, October 29, 2003, at 02:49 PM, Josh Littlefield wrote: > With the new draft available, and the last call ongoing in the prior > version, I wanted to make clear my support for moving this document > forward with the edits contained in -06. I'm also in favor of advancing the -06 version of the draft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 29 17:25:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10967; Wed, 29 Oct 2003 17:25:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEykP-0003HK-9t; Wed, 29 Oct 2003 17:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEyk2-0003G4-K0 for dhcwg@optimus.ietf.org; Wed, 29 Oct 2003 17:24:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10900 for ; Wed, 29 Oct 2003 17:24:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEyk0-0005G5-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 17:24:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AEyjz-0005Ez-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 17:24:35 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 29 Oct 2003 14:24:18 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9TMO3FH024224 for ; Wed, 29 Oct 2003 17:24:04 -0500 (EST) Received: from mjs-xp.cisco.com ([161.44.65.248]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADO42719; Wed, 29 Oct 2003 17:24:02 -0500 (EST) Message-Id: <4.3.2.7.2.20031029172337.01cf9008@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Oct 2003 17:24:21 -0500 To: dhcwg@ietf.org From: Mark Stapp Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt In-Reply-To: <200310272208.RAA18832@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I support this -06 version of the draft, and would like to see it advance. -- Mark At 05:08 PM 10/27/2003 -0500, 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 : DHCP Lease Query > Author(s) : R. Woundy, K. Kinnear > Filename : draft-ietf-dhc-leasequery-06.txt > Pages : 25 > Date : 2003-10-24 > >A DHCP server contains considerable authoritative information >concerning the IP addresses it has leased to DHCP clients. Other >processes and devices, many that already send and receive DHCP format >packets, sometimes need to access this information. The leasequery >protocol is designed to give these processes and devices a >lightweight way to access information that may be critical to their >operation. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-06.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-dhc-leasequery-06.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-dhc-leasequery-06.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-10-27170928.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-dhc-leasequery-06.txt > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 29 22:45:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23123; Wed, 29 Oct 2003 22:45:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF3k6-0008Q2-7C; Wed, 29 Oct 2003 22:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF3jZ-0008OQ-Vq for dhcwg@optimus.ietf.org; Wed, 29 Oct 2003 22:44:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23089 for ; Wed, 29 Oct 2003 22:44:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF3jW-0003m4-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 22:44:26 -0500 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1AF3jV-0003m1-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 22:44:25 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9U3iHAr080377 for ; Wed, 29 Oct 2003 22:44:26 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt Date: Wed, 29 Oct 2003 22:44:24 -0500 Message-ID: <000801c39e98$20383d00$6401a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <200310272208.RAA18832@ietf.org> Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I fully support this draft moving forward. Thanks. - Bernie Volz -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 27, 2003 5:09 PM To: IETF-Announce: Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt 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 Lease Query Author(s) : R. Woundy, K. Kinnear Filename : draft-ietf-dhc-leasequery-06.txt Pages : 25 Date : 2003-10-24 =09 A DHCP server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Other processes and devices, many that already send and receive DHCP format packets, sometimes need to access this information. The leasequery protocol is designed to give these processes and devices a lightweight way to access information that may be critical to their operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-06.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-leasequery-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-leasequery-06.txt". =09 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. =09 =09 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 From dhcwg-admin@ietf.org Wed Oct 29 23:13:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23840; Wed, 29 Oct 2003 23:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF4B9-00024D-0v; Wed, 29 Oct 2003 23:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEbxc-0003kJ-QS for dhcwg@optimus.ietf.org; Tue, 28 Oct 2003 17:05:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29944 for ; Tue, 28 Oct 2003 17:04:56 -0500 (EST) From: Eric.Luce@nominum.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEbxa-0000U3-00 for dhcwg@ietf.org; Tue, 28 Oct 2003 17:05:06 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEbxa-0000U0-00 for dhcwg@ietf.org; Tue, 28 Oct 2003 17:05:06 -0500 Received: from shell-ng.nominum.com ([81.200.64.181]) by manatick with esmtp (Exim 4.24) id 1AEbxa-0007hg-JK for dhcwg@ietf.org; Tue, 28 Oct 2003 17:05:06 -0500 Received: from yomiko.ddns.nominum.com (dhcp-146.engr.nominum.com [128.177.194.146]) by shell-ng.nominum.com (Postfix) with ESMTP id CC2D35683E for ; Tue, 28 Oct 2003 14:00:02 -0800 (PST) Received: from yomiko.ddns.nominum.com (localhost [127.0.0.1]) by yomiko.ddns.nominum.com (8.12.9p2/8.12.9) with ESMTP id h9SM10KW011823 for ; Tue, 28 Oct 2003 14:01:00 -0800 (PST) (envelope-from scanner@yomiko.ddns.nominum.com) Message-Id: <200310282201.h9SM10KW011823@yomiko.ddns.nominum.com> To: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) X-URI: http://www.nominum.com/ X-Face: 6K2.ZvQgQ.NDQLIx.1pW(xRu*">:}&PX-Ad_!!?wU7H4L"wF"0xEwYu=8Or0V+=5?-eO1XL 7-0Hom/|]B2C7Uznyol-NVnvEk:+sod^MyB4v4qVpPDemr;b@pZdRSXu.'Gm^t0?2l,j[&t.kbc[UW x6Lz^e$K$W Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII X-Mailer: MH-E 7.3; nmh 1.0.4; XEmacs 21.4 (patch 14) Date: Tue, 28 Oct 2003 14:01:00 -0800 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , TL> On Wednesday, October 22, 2003, at 09:17 AM, Kim Kinnear wrote: >> I don't see the value in having zero length suboptions. I don't >> think we generally allow them (though someone will doubtless >> correct me if I'm wrong). If there is some valid, semantically >> interesting reason for allowing zero length suboptions, then I >> think the meaning should be spelled out, otherwise I think they >> should be disallowed. TL> I agree with this. There is a precedent, but it's a big hassle TL> to support this - it's better for the suboption to just have a TL> boolean value. I have been following this and was feeling uncomfortable about zero length options. Yes, we have to support it for the nwip sub-options but I really do not like how it continues to break what was a nice paradigm on dhcp options: code, length, data. I know dhcp packets are small and there are times when we want to be as space efficient as possible. However I am not sure this tradeoff is worth the cost of saving two bytes. I agree with Ted. I think it is better for this suboption to just have a boolean value. -- Scanner (scanner@nominum.com) Nominum, Inc. | www.nominum.com | +1.650.779.6035 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Oct 29 23:49:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24966; Wed, 29 Oct 2003 23:49:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF4k0-0005bf-KX; Wed, 29 Oct 2003 23:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF4j7-0005U4-8d for dhcwg@optimus.ietf.org; Wed, 29 Oct 2003 23:48:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24923 for ; Wed, 29 Oct 2003 23:47:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF4j5-0004d9-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 23:48:03 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AF4j4-0004d6-00 for dhcwg@ietf.org; Wed, 29 Oct 2003 23:48:02 -0500 Received: from fugue.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 22B7E1B2CDD; Wed, 29 Oct 2003 22:43:00 -0600 (CST) Date: Wed, 29 Oct 2003 22:48:08 -0600 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org To: Eric.Luce@nominum.com From: Ted Lemon In-Reply-To: <200310282201.h9SM10KW011823@yomiko.ddns.nominum.com> Message-Id: <42144008-0A94-11D8-86F4-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [dhcwg] Zero-length nwip suboptions... Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Tuesday, October 28, 2003, at 04:01 PM, Eric.Luce@nominum.com wrote: > I have been following this and was feeling uncomfortable about zero > length options. Yes, we have to support it for the nwip sub-options but > I really do not like how it continues to break what was a nice > paradigm on dhcp options: code, length, data. Actually, the four nwip suboptions that are zero-length are very odd - they're options that require the server to do special handling in order to generate them correctly. I am curious if anybody here has actually implemented these options as specified, and if they are aware of any clients that take advantage of these options if sent. I am tempted to write a draft that deprecates these options, since I am skeptical that there is anybody who uses them. Comments? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 00:04:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25670; Thu, 30 Oct 2003 00:04:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF4yW-0007JL-UO; Thu, 30 Oct 2003 00:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF4yS-0007Ip-Ky for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 00:03:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25624; Thu, 30 Oct 2003 00:03:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF4yQ-0004tJ-00; Thu, 30 Oct 2003 00:03:54 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AF4yP-0004sP-00; Thu, 30 Oct 2003 00:03:53 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9U53MjP018632; Wed, 29 Oct 2003 21:03:22 -0800 (PST) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-580.cisco.com [10.82.242.68]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADO62405; Thu, 30 Oct 2003 00:03:20 -0500 (EST) Message-Id: <4.3.2.7.2.20031030000226.01fbee90@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Oct 2003 00:03:18 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: agenda@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Agenda for dhc WG meeting in Minneapolis (revised) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Included below is a revised draft agenda for the dhc WG meeting in Minneapolis. If you have additional agenda items, or if I've missed an agenda item you've already requested, please contact me *immediately* to get on the agenda. - Ralph DHC WG agenda - IETF 58 Thu 11/13/2003 0900 (tentative) (Last revised 10/30/2003 12:00 AM) ---------------------------------- Administrivia; agenda bashing Ralph Droms 05 minutes Node-Specific Client Identifiers for DHCPv4 Ted Lemon 10 minutes Initial discussion Rapid Reply Option for DHCPv4 S. D. Park 10 minutes Accept as WG work item? Client Identifier option in server replies N. Swamy 10 minutes Accept as WG work item? Extending DHCP Options Codes Ralph Droms 10 minutes Discussion; which extension plan to accept; next steps/roadmap Implementation Issues with RFC 2131 Ralph Droms 20 minutes Discussion; next steps; other work related to advancing RFC 2131 DHCPv4 Threat Analysis Carl Smith (?) 10 minutes Final discussion; solicit WG last call review DHCP Authentication using DNS KEY records Ted Lemon (?) 10 minutes RFC3118 Delayed authentication using PANA H. Tschofenig (?) 10 minutes Accept as WG work item? Flexible Authentication for DHCP Messages Vipul Gupta 10 minutes Discussion of DHCP authentication Ralph Droms 20 minutes Review three authentication proposals; next steps/roadmap Configuration of dual-stack hosts with DHCP Ralph Droms 20 minutes ----------- Total 145 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 01:41:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28265; Thu, 30 Oct 2003 01:41:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6UO-0002on-VL; Thu, 30 Oct 2003 01:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6UG-0002oQ-CT for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 01:40:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28205 for ; Thu, 30 Oct 2003 01:40:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF6UC-00061c-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 01:40:49 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1AF6UC-00061Z-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 01:40:48 -0500 Received: (qmail 31514 invoked from network); 30 Oct 2003 06:40:47 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 30 Oct 2003 06:40:47 -0000 Date: Thu, 30 Oct 2003 07:40:46 +0100 From: Henrik Levkowetz To: Eric.Luce@nominum.com Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Message-Id: <20031030074046.4d5ded79.henrik@levkowetz.com> In-Reply-To: <200310282201.h9SM10KW011823@yomiko.ddns.nominum.com> References: <200310282201.h9SM10KW011823@yomiko.ddns.nominum.com> X-Mailer: Sylpheed version 0.9.5claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Multipart_Thu__30_Oct_2003_07_40_46_+0100_=.'hOpHs2F5uWvm7" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Multipart_Thu__30_Oct_2003_07_40_46_+0100_=.'hOpHs2F5uWvm7 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Tuesday 28 October 2003, Eric.Luce@nominum.com wrote: > TL> On Wednesday, October 22, 2003, at 09:17 AM, Kim Kinnear wrote: > >> I don't see the value in having zero length suboptions. I don't > >> think we generally allow them (though someone will doubtless > >> correct me if I'm wrong). If there is some valid, semantically > >> interesting reason for allowing zero length suboptions, then I > >> think the meaning should be spelled out, otherwise I think they > >> should be disallowed. > > TL> I agree with this. There is a precedent, but it's a big hassle > TL> to support this - it's better for the suboption to just have a > TL> boolean value. > > I have been following this and was feeling uncomfortable about zero > length options. Yes, we have to support it for the nwip sub-options but > I really do not like how it continues to break what was a nice > paradigm on dhcp options: code, length, data. > > I know dhcp packets are small and there are times when we want to be as > space efficient as possible. However I am not sure this tradeoff is > worth the cost of saving two bytes. I agree with Ted. I think it is > better for this suboption to just have a boolean value. Ok, I've taken this to heart and will do the draft update accordingly. Thanks, Henrik --Multipart_Thu__30_Oct_2003_07_40_46_+0100_=.'hOpHs2F5uWvm7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/oLJveVhrtTJkXCMRAk8TAKCjYLFandG95mbDrGF3D47SxIpujACgu4xJ JajALAOe7dunE7AluJzPluI= =Cmie -----END PGP SIGNATURE----- --Multipart_Thu__30_Oct_2003_07_40_46_+0100_=.'hOpHs2F5uWvm7-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 09:09:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22686; Thu, 30 Oct 2003 09:09:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFDTx-0000Dw-8Z; Thu, 30 Oct 2003 09:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFDTu-0000Di-Ji for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 09:08:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22672 for ; Thu, 30 Oct 2003 09:08:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFDTs-0003hG-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 09:08:56 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AFDTs-0003hD-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 09:08:56 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9UE8lGn095010; Thu, 30 Oct 2003 09:08:55 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Henrik Levkowetz'" , Cc: Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Date: Thu, 30 Oct 2003 09:08:55 -0500 Message-ID: <000b01c39eef$5e5e0c20$6401a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-reply-to: <20031030074046.4d5ded79.henrik@levkowetz.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Personally, I think this is a mistake. You should leave the ability in. We're using it in the Rapid Reply option for DHCPv4 (based on the Rapid Commit option for DHCPv6) and that has a zero length. There is no reason = why this would need a flag byte. And, a zero length option does NOT invalidate the standard paradigm of = DHCP options - code, length, data. The null set is always a member of every = set. A zero length data field is fine. I previously wrote that having a flag byte in some instances is = important and those options should be defined with a flag byte. For example, a = flag byte is important when the following three possibilities are important: 1. Option present with flag set to true - turn on the feature. 2. Option present with flag set to false - turn off the feature. 3. Option not present - use locally configured default. Whereas an option with no data (no flag) only has two settings: 1. Option present - do it. 2. Option not present - do not do it. So, for the Rapid Reply draft, it would make little sense in having a = flag byte since implementations that want to do it only need to include the option without data. Those that do not want to make use of Rapid Reply should simply not include the option. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Henrik Levkowetz Sent: Thursday, October 30, 2003 1:41 AM To: Eric.Luce@nominum.com Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Tuesday 28 October 2003, Eric.Luce@nominum.com wrote: > TL> On Wednesday, October 22, 2003, at 09:17 AM, Kim Kinnear = wrote: > >> I don't see the value in having zero length suboptions. I = don't > >> think we generally allow them (though someone will doubtless > >> correct me if I'm wrong). If there is some valid, semantically > >> interesting reason for allowing zero length suboptions, then I > >> think the meaning should be spelled out, otherwise I think they > >> should be disallowed. >=20 > TL> I agree with this. There is a precedent, but it's a big = hassle > TL> to support this - it's better for the suboption to just have a > TL> boolean value. >=20 > I have been following this and was feeling uncomfortable about zero > length options. Yes, we have to support it for the nwip sub-options = but > I really do not like how it continues to break what was a nice=20 > paradigm on dhcp options: code, length, data. >=20 > I know dhcp packets are small and there are times when we want to be = as > space efficient as possible. However I am not sure this tradeoff is > worth the cost of saving two bytes. I agree with Ted. I think it is=20 > better for this suboption to just have a boolean value. Ok, I've taken this to heart and will do the draft update accordingly. Thanks, Henrik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 12:13:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01137; Thu, 30 Oct 2003 12:13:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGM0-0005hO-Md; Thu, 30 Oct 2003 12:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGLj-0005em-Vy for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 12:12:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01109 for ; Thu, 30 Oct 2003 12:12:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGLi-0006Yf-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 12:12:42 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AFGLi-0006Yb-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 12:12:42 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9UHC6Qa006130 for ; Thu, 30 Oct 2003 09:12:09 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADO98921; Thu, 30 Oct 2003 12:12:05 -0500 (EST) Message-Id: <4.3.2.7.2.20031030120630.04624c18@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Oct 2003 12:12:04 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Request for scribes and interest in Jabber at WG meeting Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , To minimize overhead during our WG meeting in Minneapolis, I need to identify two scribes who will take notes during the meeting. Let me know if you're willing to perform that service... Is there anyone who can't attend the meeting in person who would like to participate via a Jabber session? If so, speak up and I'll find someone to do the Jabber transcription. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 12:31:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01831; Thu, 30 Oct 2003 12:31:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGdS-0007wr-IO; Thu, 30 Oct 2003 12:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFGcl-0007s1-CO for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 12:30:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01773 for ; Thu, 30 Oct 2003 12:30:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFGcj-0006q0-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 12:30:17 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AFGcj-0006pp-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 12:30:17 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 30 Oct 2003 09:32:20 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9UHThjP026830 for ; Thu, 30 Oct 2003 09:29:43 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADP00479; Thu, 30 Oct 2003 12:29:42 -0500 (EST) Message-Id: <4.3.2.7.2.20031030122836.0463cdd0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Oct 2003 12:29:41 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Request for Jabber scribe at WG meeting Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've heard an expression of interest in a Jabber session from the WG meeting. So, now I need a volunteer to act as Jabber scribe. Any takers? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 15:37:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10220; Thu, 30 Oct 2003 15:37:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJXQ-0008NA-JZ; Thu, 30 Oct 2003 15:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJX0-0008KJ-P2 for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 15:36:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10199 for ; Thu, 30 Oct 2003 15:36:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFJWz-0001ix-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 15:36:33 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AFJWy-0001iu-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 15:36:32 -0500 Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 921441B200B for ; Thu, 30 Oct 2003 14:31:23 -0600 (CST) Date: Thu, 30 Oct 2003 14:36:38 -0600 Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Ted Lemon To: Content-Transfer-Encoding: 7bit In-Reply-To: <000b01c39eef$5e5e0c20$6401a8c0@BVolz> Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, October 30, 2003, at 08:08 AM, Bernie Volz wrote: > Personally, I think this is a mistake. You should leave the ability in. > We're using it in the Rapid Reply option for DHCPv4 (based on the Rapid > Commit option for DHCPv6) and that has a zero length. There is no > reason why > this would need a flag byte. The thing is, every boolean option in rfc2131 includes a flag byte, even though it's unnecessary (and I agree that it is, technically, not necessary). So I think that you should use a flag byte in the Rapid Reply option. And Henrik should use a flag byte in the mipadvert option. Because otherwise, the protocol defines two ways of representing the same kind of information in virtually identical contexts, which means that implementations have to be needlessly complicated. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 16:33:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13608; Thu, 30 Oct 2003 16:33:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFKPe-0004wd-2u; Thu, 30 Oct 2003 16:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFKP7-0004sY-E9 for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 16:32:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13254 for ; Thu, 30 Oct 2003 16:32:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFKP5-0002i4-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 16:32:27 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AFKP4-0002hw-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 16:32:26 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9ULWHGn072829; Thu, 30 Oct 2003 16:32:26 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Date: Thu, 30 Oct 2003 16:32:24 -0500 Message-ID: <000001c39f2d$52608db0$6401a8c0@BVolz> 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.4510 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit But, what's the point of sending a Rapid Reply option with a flag byte of False? It really is no different than sending no option. For Boolean options, there is a difference in saying don't do this vs. saying nothing at all and hence the flag is important (lack of the option does not necessarily mean don't do it). I guess this is just one of those areas were we disagree. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted Lemon Sent: Thursday, October 30, 2003 3:37 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) On Thursday, October 30, 2003, at 08:08 AM, Bernie Volz wrote: > Personally, I think this is a mistake. You should leave the ability in. > We're using it in the Rapid Reply option for DHCPv4 (based on the Rapid > Commit option for DHCPv6) and that has a zero length. There is no > reason why > this would need a flag byte. The thing is, every boolean option in rfc2131 includes a flag byte, even though it's unnecessary (and I agree that it is, technically, not necessary). So I think that you should use a flag byte in the Rapid Reply option. And Henrik should use a flag byte in the mipadvert option. Because otherwise, the protocol defines two ways of representing the same kind of information in virtually identical contexts, which means that implementations have to be needlessly complicated. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 16:46:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15300; Thu, 30 Oct 2003 16:46:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFKcE-0006XS-9d; Thu, 30 Oct 2003 16:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFKbl-0006Uz-U7 for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 16:45:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15198 for ; Thu, 30 Oct 2003 16:45:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFKbj-00035t-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 16:45:31 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AFKbj-00035q-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 16:45:31 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9ULjMGn076049; Thu, 30 Oct 2003 16:45:30 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ted Lemon'" , Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Date: Thu, 30 Oct 2003 16:45:29 -0500 Message-ID: <000101c39f2f$25d65a70$6401a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Are you afraid we might break some implementations if a zero length = option is sent to them? Does the ISC DHCP Server process zero-length options correctly or does it consider these to be malformed (even if it = otherwise would ignore that option)? RFC 2132 specially allows zero-length options (see section 2): Any options defined subsequent to this document MUST contain a length octet even if the length is fixed or zero. If you really think the prohibition is needed, shouldn't it be included = in the draft-ietf-dhc-implementation-xx.txt work? Note that the document that started all this (the mipadvert-opt one) is really about suboptions and not options, so RFC 2132 and the = compatibility issue likely do not apply (since any implementation supporting the = mipadvert option could be explicitly designed to support zero length suboptions). = But, working this out for options is important since I'd like to use a zero length option for the Rapid Reply option. - Bernie -----Original Message----- From: Bernie Volz [mailto:volz@metrocast.net]=20 Sent: Thursday, October 30, 2003 4:32 PM To: 'Ted Lemon'; 'dhcwg@ietf.org' Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) But, what's the point of sending a Rapid Reply option with a flag byte = of False? It really is no different than sending no option. For Boolean options, there is a difference in saying don't do this vs. saying nothing at all and hence the flag is important (lack of the = option does not necessarily mean don't do it). I guess this is just one of those areas were we disagree. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ted Lemon Sent: Thursday, October 30, 2003 3:37 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) On Thursday, October 30, 2003, at 08:08 AM, Bernie Volz wrote: > Personally, I think this is a mistake. You should leave the ability = in. > We're using it in the Rapid Reply option for DHCPv4 (based on the = Rapid > Commit option for DHCPv6) and that has a zero length. There is no=20 > reason why > this would need a flag byte. The thing is, every boolean option in rfc2131 includes a flag byte,=20 even though it's unnecessary (and I agree that it is, technically, not=20 necessary). So I think that you should use a flag byte in the Rapid Reply option. =20 And Henrik should use a flag byte in the mipadvert option. Because=20 otherwise, the protocol defines two ways of representing the same kind=20 of information in virtually identical contexts, which means that=20 implementations have to be needlessly complicated. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 16:53:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15828; Thu, 30 Oct 2003 16:53:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFKiz-0007Sl-Qn; Thu, 30 Oct 2003 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFKi5-0007K0-82 for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 16:52:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15734 for ; Thu, 30 Oct 2003 16:51:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFKi3-0003E8-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 16:52:03 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AFKi2-0003Do-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 16:52:02 -0500 Received: from [10.0.1.4] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 45FAF1B2001; Thu, 30 Oct 2003 15:46:36 -0600 (CST) In-Reply-To: <000001c39f2d$52608db0$6401a8c0@BVolz> References: <000001c39f2d$52608db0$6401a8c0@BVolz> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3AB84DEA-0B23-11D8-A8A6-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: , "'Ted Lemon'" From: Ted Lemon Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Date: Thu, 30 Oct 2003 15:51:34 -0600 To: "Bernie Volz" X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Oct 30, 2003, at 3:32 PM, Bernie Volz wrote: > But, what's the point of sending a Rapid Reply option with a flag byte > of > False? It really is no different than sending no option. That's true. I don't expect you to send the Rapid Reply option if the value is false. And I agree that in the other cases, a flag byte value of zero might be meaningful, and in this case it is not. But using a flag byte in all cases is consistent, and in a case like this I think consistency is worth a small sacrifice in space, because it makes implementations easier. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 17:11:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16730; Thu, 30 Oct 2003 17:11:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFL0Q-0001SC-GF; Thu, 30 Oct 2003 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFKzv-0001Ou-RP for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 17:10:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16697 for ; Thu, 30 Oct 2003 17:10:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFKzt-0003ZT-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 17:10:29 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AFKzo-0003ZQ-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 17:10:24 -0500 Received: from [10.0.1.4] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 71E221B200B for ; Thu, 30 Oct 2003 16:05:15 -0600 (CST) Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <000101c39f2f$25d65a70$6401a8c0@BVolz> References: <000101c39f2f$25d65a70$6401a8c0@BVolz> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Date: Thu, 30 Oct 2003 16:08:47 -0600 To: "" X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Oct 30, 2003, at 3:45 PM, Bernie Volz wrote: > Are you afraid we might break some implementations if a zero length > option > is sent to them? No, it just adds needless complexity to the option data parser. Any DHCP implementation should already know how to skip over unknown options, so I don't expect a zero-length option to break it, although it's by no means out of the question. AFAIK the ISC server would not have a problem with a client-supplied zero-length option. > RFC 2132 specially allows zero-length options (see section 2): > > Any options defined subsequent to this document MUST contain a > length > octet even if the length is fixed or zero. Sure. But that's not the point. The point is that having two ways to represent a boolean isn't as good as having one way. > If you really think the prohibition is needed, shouldn't it be > included in > the draft-ietf-dhc-implementation-xx.txt work? Yes, we should probably have some language in this draft that talks about defining new option data types. I thought we'd done something similar to this in the past, but don't find it in the rfc index. The idea is that we have already defined various data formats, and that options that use these formats should be consistent - there shouldn't be two data formats that represent the same kind of data. Right now this is not agreed upon nor is it enforced other than by pedants like me complaining when people come out with new options that define new data types that do the same thing as old data types. In the case of the nwip suboptions, I think that was during the 6-month period when I accidentally got unsubscribed from the mailing list, so I didn't have the opportunity to object. :'/ > Note that the document that started all this (the mipadvert-opt one) is > really about suboptions and not options Although it is not required, I would expect any DHCP server implementation of suboptions and options to share the option parsing code, so it makes sense to me that if something is valid for a suboption, it's valid for an option, and vice versa. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 17:34:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15299; Thu, 30 Oct 2003 16:46:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFKcD-0006XK-Oo; Thu, 30 Oct 2003 16:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFKbX-0006Te-FN for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 16:45:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15161 for ; Thu, 30 Oct 2003 16:45:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFKbV-00035R-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 16:45:17 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AFKbU-00034e-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 16:45:16 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9ULifjR025158 for ; Thu, 30 Oct 2003 13:44:44 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADP29359; Thu, 30 Oct 2003 16:44:40 -0500 (EST) Message-Id: <4.3.2.7.2.20031030163327.04624c18@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Oct 2003 16:44:38 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Request for Jabber scribe at WG meeting Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , BTW, for those of you who may not be familiar with Jabber at the IETF - Jabber is an IM implementation for which an ongoing service has been set up to provide IM for IETF WG meetings. The idea is that the Jabber scribe at the WG meeting will transcribe the events at the meeting into a Jabber session. Remote participants can then keep up with the meeting. Remote participants can also ask questions in the WG meeting through the scribe via the IM session. So, we do have interest in setting up a Jabber session for remote participants - now we need to identify a scribe who will be in the WG meeting. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 18:17:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19947; Thu, 30 Oct 2003 18:17:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFM2G-00089q-J9; Thu, 30 Oct 2003 18:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFM1I-00083m-5I for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 18:16:00 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19789 for ; Thu, 30 Oct 2003 18:15:47 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AFLj4-0003Pq-Or; Thu, 30 Oct 2003 17:57:10 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 30 Oct 2003 17:57:10 -0500 Subject: [dhcwg] Last Call: 'A Guide to Implementing Stateless DHCPv6 Service' to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'A Guide to Implementing Stateless DHCPv6 Service' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-11-13. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateless-01.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 23:41:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28610; Thu, 30 Oct 2003 23:41:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFR5p-0003h1-Vq; Thu, 30 Oct 2003 23:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFR5i-0003gf-33 for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 23:40:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28571 for ; Thu, 30 Oct 2003 23:40:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFR5f-0000gS-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 23:40:51 -0500 Received: from smtp016.mail.yahoo.com ([216.136.174.113]) by ietf-mx with smtp (Exim 4.12) id 1AFR5f-0000gP-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 23:40:51 -0500 Received: from adsl-64-170-118-75.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.118.75 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 31 Oct 2003 04:40:50 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST) Date: Thu, 30 Oct 2003 20:40:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <000101c39f2f$25d65a70$6401a8c0@BVolz> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bernie-- I'll make a note of this point for inclusion in the next revision of the 2131 implementation issues draft. --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Bernie Volz > Sent: Thursday, October 30, 2003 13:45 > To: 'Ted Lemon'; dhcwg@ietf.org > Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt > (SECOND REQUEST) > > > Are you afraid we might break some implementations if a zero length option > is sent to them? Does the ISC DHCP Server process zero-length options > correctly or does it consider these to be malformed (even if it otherwise > would ignore that option)? > > RFC 2132 specially allows zero-length options (see section 2): > > Any options defined subsequent to this document MUST contain a length > octet even if the length is fixed or zero. > > If you really think the prohibition is needed, shouldn't it be included in > the draft-ietf-dhc-implementation-xx.txt work? > > Note that the document that started all this (the mipadvert-opt one) is > really about suboptions and not options, so RFC 2132 and the compatibility > issue likely do not apply (since any implementation supporting > the mipadvert > option could be explicitly designed to support zero length > suboptions). But, > working this out for options is important since I'd like to use a zero > length option for the Rapid Reply option. > > - Bernie > > -----Original Message----- > From: Bernie Volz [mailto:volz@metrocast.net] > Sent: Thursday, October 30, 2003 4:32 PM > To: 'Ted Lemon'; 'dhcwg@ietf.org' > Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt > (SECOND REQUEST) > > But, what's the point of sending a Rapid Reply option with a flag byte of > False? It really is no different than sending no option. > > For Boolean options, there is a difference in saying don't do this vs. > saying nothing at all and hence the flag is important (lack of the option > does not necessarily mean don't do it). > > I guess this is just one of those areas were we disagree. > > - Bernie > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted > Lemon > Sent: Thursday, October 30, 2003 3:37 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt > (SECOND REQUEST) > > On Thursday, October 30, 2003, at 08:08 AM, Bernie Volz wrote: > > Personally, I think this is a mistake. You should leave the ability in. > > We're using it in the Rapid Reply option for DHCPv4 (based on the Rapid > > Commit option for DHCPv6) and that has a zero length. There is no > > reason why > > this would need a flag byte. > > The thing is, every boolean option in rfc2131 includes a flag byte, > even though it's unnecessary (and I agree that it is, technically, not > necessary). > > So I think that you should use a flag byte in the Rapid Reply option. > And Henrik should use a flag byte in the mipadvert option. Because > otherwise, the protocol defines two ways of representing the same kind > of information in virtually identical contexts, which means that > implementations have to be needlessly complicated. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Oct 30 23:43:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28705; Thu, 30 Oct 2003 23:43:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFR7k-0003rX-RG; Thu, 30 Oct 2003 23:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFR6v-0003mB-5a for dhcwg@optimus.ietf.org; Thu, 30 Oct 2003 23:42:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28667 for ; Thu, 30 Oct 2003 23:41:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFR6s-0000hI-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 23:42:06 -0500 Received: from smtp011.mail.yahoo.com ([216.136.173.31]) by ietf-mx with smtp (Exim 4.12) id 1AFR6s-0000hE-00 for dhcwg@ietf.org; Thu, 30 Oct 2003 23:42:06 -0500 Received: from adsl-64-170-118-75.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.118.75 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 31 Oct 2003 04:42:06 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] Request for Jabber scribe at WG meeting Date: Thu, 30 Oct 2003 20:41:15 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <4.3.2.7.2.20031030163327.04624c18@flask.cisco.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I for one would like to observe the WG meeting on Jabber: obvious questions include URL and any other information necessary to connect. --Barr > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Ralph Droms > Sent: Thursday, October 30, 2003 13:45 > To: dhcwg@ietf.org > Subject: [dhcwg] Request for Jabber scribe at WG meeting > > > BTW, for those of you who may not be familiar with Jabber at the IETF - > Jabber is an IM implementation for which an ongoing service has > been set up > to provide IM for IETF WG meetings. The idea is that the Jabber scribe at > the WG meeting will transcribe the events at the meeting into a Jabber > session. Remote participants can then keep up with the meeting. Remote > participants can also ask questions in the WG meeting through the > scribe via > the IM session. > > So, we do have interest in setting up a Jabber session for remote > participants - now we need to identify a scribe who will be in > the WG meeting. > > - Ralph > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 08:33:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27559; Fri, 31 Oct 2003 08:33:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZOf-0004tN-Vb; Fri, 31 Oct 2003 08:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZOL-0004ps-NI for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 08:32:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27521 for ; Fri, 31 Oct 2003 08:32:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFZOK-00000z-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 08:32:40 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 1AFZOJ-00000n-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 08:32:40 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9VDW7S1016960 for ; Fri, 31 Oct 2003 05:32:08 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADP69076; Fri, 31 Oct 2003 08:32:06 -0500 (EST) Message-Id: <4.3.2.7.2.20031031082030.01f29928@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Oct 2003 08:31:01 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-pxe-options-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "DHCP Preboot eXecution Environment (PXE) Options" . The last call will conclude at 5PM ET on Monday, 11/17/2003. Note that this is a new call on the -01 revision of this document. There was insufficient response to the first last call to determine WG consensus on acceptance of the document. In addition, the following changes have been made in draft-ietf-dhc-pxe-options-01.txt: o Changed all occurrences of "suboption" to "option". o Re-worded first sentence of Introduction to clarify that these options are in wide use by PXE clients. o Clarified external document references. o Clarfified and extended definitions of options based on external references. o Added description of site specific options 128 through 135. o Added IANA Considerations and Security Considerations sections. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-pxe-options-01.txt documents three DHCP options that are in common use by PXE. These options uniquely identify booting client machines and their pre-OS runtime environment so the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-pxe-options-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 08:38:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27775; Fri, 31 Oct 2003 08:38:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZTV-0006cd-14; Fri, 31 Oct 2003 08:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZTG-0006US-4y for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 08:37:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27730 for ; Fri, 31 Oct 2003 08:37:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFZTE-00005y-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 08:37:44 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 1AFZTE-00005c-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 08:37:44 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9VDb5RV017752 for ; Fri, 31 Oct 2003 05:37:06 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADP69382; Fri, 31 Oct 2003 08:37:04 -0500 (EST) Message-Id: <4.3.2.7.2.20031031083338.01f2a810@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Oct 2003 08:37:03 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] POSTPONED: WG last call on draft-ietf-dhc-pxe-options-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The previous message about the last call on draft-ietf-dhc-pxe-options-01.txt was sent in error (it was supposed to be queued until after IETF58 in Minneapolis). The WG last call on draft-ietf-dhc-pxe-options-01.txt will begin as soon as the new revision is published, after the I-D moratorium is lifted. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 08:45:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28060; Fri, 31 Oct 2003 08:45:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZaH-0007QL-T3; Fri, 31 Oct 2003 08:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZZV-0007Nc-JZ for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 08:44:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27979 for ; Fri, 31 Oct 2003 08:44:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFZZU-00009h-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 08:44:12 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 1AFZZT-00009M-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 08:44:11 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9VDhcGl025672 for ; Fri, 31 Oct 2003 05:43:40 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADP69891; Fri, 31 Oct 2003 08:43:37 -0500 (EST) Message-Id: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Oct 2003 08:43:32 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "DHCP Failover Protocol" . The last call will conclude at 5PM ET on Monday, 11/17/2003. This WG last call is a second last call on draft-ietf-dhc-failover-12.txt. There was insufficient response to the earlier WG last call to determine consensus on WG acceptance of the document. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of response does *not* represent acceptance of the document. If there is insufficient response to this WG last call, the document will not be submitted to the IESG for publication. Because of the unusual overlap between the set of authors of this document and the set of implementors interested in the specification, authors are encouraged to respond to this WG last call. draft-ietf-dhc-failover-12.txt defines a protocol to provide synchronization between two DHCP servers. The DHCP specification [RFC 2131] allows for multiple servers to be operating on a single network. For a deployment with multiple servers to work reliably, cooperating primary and secondary servers must be synchronized to maintain a consistent database of the lease information. This document is being considered for Proposed Standard, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-12.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 08:57:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28392; Fri, 31 Oct 2003 08:57:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZlu-0008TN-5u; Fri, 31 Oct 2003 08:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZky-0008NM-IL for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 08:56:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28329 for ; Fri, 31 Oct 2003 08:55:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFZkx-0000It-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 08:56:03 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 1AFZkw-0000Ib-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 08:56:02 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9VDtSRX013302 for ; Fri, 31 Oct 2003 05:55:30 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADP70768; Fri, 31 Oct 2003 08:55:27 -0500 (EST) Message-Id: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Oct 2003 08:49:02 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message announces a WG last call on "DHCP Failover Protocol" . The last call will conclude at 5PM ET on Monday, 11/17/2003. This WG last call is a second last call on draft-ietf-dhc-failover-12.txt. There was insufficient response to the earlier WG last call to determine consensus on WG acceptance of the document. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Lack of response does *not* represent acceptance of the document. If there is insufficient response to this WG last call, the document will not be submitted to the IESG for publication. Because of the unusual overlap between the set of authors of this document and the set of implementors interested in the specification, authors are encouraged to respond to this WG last call. draft-ietf-dhc-failover-12.txt defines a protocol to provide synchronization between two DHCP servers. The DHCP specification [RFC 2131] allows for multiple servers to be operating on a single network. For a deployment with multiple servers to work reliably, cooperating primary and secondary servers must be synchronized to maintain a consistent database of the lease information. This document is being considered for Proposed Standard, and is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-12.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 09:41:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29872; Fri, 31 Oct 2003 09:41:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFaSS-0005yu-QH; Fri, 31 Oct 2003 09:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFaRZ-0005r2-FL for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 09:40:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29752 for ; Fri, 31 Oct 2003 09:39:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFaRX-0000r9-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 09:40:03 -0500 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1AFaRX-0000r6-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 09:40:03 -0500 Received: from [10.0.1.4] (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id A2C511B2016; Fri, 31 Oct 2003 08:34:45 -0600 (CST) In-Reply-To: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> References: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1AB94312-0BB0-11D8-A8A6-000A95D9C74C@fugue.com> Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org From: Ted Lemon Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt Date: Fri, 31 Oct 2003 08:39:59 -0600 To: Ralph Droms X-Mailer: Apple Mail (2.606) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm very much in favor of advancing the failover draft. A lot of work has gone into it, and it's in very good shape - the authors should be proud of what they've done with this draft. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 09:45:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28391; Fri, 31 Oct 2003 08:57:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZlt-0008T7-Ku; Fri, 31 Oct 2003 08:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFZkw-0008NG-Rz for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 08:56:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28326 for ; Fri, 31 Oct 2003 08:55:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFZkv-0000Im-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 08:56:01 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 1AFZku-0000Ia-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 08:56:00 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9VDtSRV013302 for ; Fri, 31 Oct 2003 05:55:29 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.208]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADP70766; Fri, 31 Oct 2003 08:55:27 -0500 (EST) Message-Id: <4.3.2.7.2.20031031083338.01f2a810@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Oct 2003 08:55:25 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] POSTPONED: WG last call on draft-ietf-dhc-pxe-options-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The previous message about the last call on draft-ietf-dhc-pxe-options-01.txt was sent in error (it was supposed to be queued until after IETF58 in Minneapolis). The WG last call on draft-ietf-dhc-pxe-options-01.txt will begin as soon as the new revision is published, after the I-D moratorium is lifted. Also, note that this new last call represents a change in the previously reported status of this document. After reviewing the response to the previous last call, and reviewing the changes in the -01 revision of the document, I concluded that a new WG last call was appropriate. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 10:17:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02926; Fri, 31 Oct 2003 10:17:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFb1J-0002E8-Gr; Fri, 31 Oct 2003 10:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFb0T-00028g-1K for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 10:16:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02696 for ; Fri, 31 Oct 2003 10:15:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFb0P-0001Wc-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 10:16:05 -0500 Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx with esmtp (Exim 4.12) id 1AFb0P-0001WZ-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 10:16:05 -0500 Received: from iconsrv5.india.hp.com (iconsrv5.india.hp.com [15.42.229.13]) by atlrel7.hp.com (Postfix) with ESMTP id 649A51C01F24 for ; Fri, 31 Oct 2003 10:15:59 -0500 (EST) Received: from nt23056 (nt23056.india.hp.com [15.42.230.56]) by iconsrv5.india.hp.com (8.9.3 (PHNE_28810)/8.9.3 SMKit7.02) with ESMTP id UAA00569 for ; Fri, 31 Oct 2003 20:44:46 +0530 (IST) From: "Vijayabhaskar A K" To: Date: Fri, 31 Oct 2003 20:45:44 +0530 Message-ID: <000b01c39fc1$db186760$38e62a0f@nt23056> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000C_01C39FEF.F4D0A360" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [dhcwg] IDs on remote boot support for DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C39FEF.F4D0A360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All I am attaching two new drafts dealing with remote boot support for DHCP. I could not submit the draft to ID queue, as the deadline has crossed. Please go through these drafts and let me know your comments. The abstract of these drafts are given below * The Extended Remote Boot Option for DHCPv4 Single TFTP server for huge number of diskless clients is prone to single point of failure. So, Multiple TFTP servers are needed for high availability. Moreover, some of the clients need multiple bootfiles for boot up. This document provides a new DHCPv4 option for clients to obtain information about multiple TFTP servers and bootfiles. * DHCPv6 Support for Remote Boot This document provides new DHCPv6 (Dynamic Host Configuration protocol version 6) options for clients, to obtain information about TFTP servers and bootfiles needed for booting. Vijay ------=_NextPart_000_000C_01C39FEF.F4D0A360 Content-Type: text/plain; name="draft-ietf-dhc-opt-extrboot-00.txt" Content-Disposition: attachment; filename="draft-ietf-dhc-opt-extrboot-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A.K. Vijayabhaskar Internet-Draft B. Senthil Kumar Expires: April 31, 2004 Hewlett-Packard 30 Oct 2003 The Extended Remote Boot Option for DHCPv4 draft-ietf-dhc-opt-extrboot-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Single TFTP [2] server for huge number of diskless clients is prone to single point of failure. So, Multiple TFTP servers are needed for high availability. Moreover, some of the clients need multiple bootfiles for boot up. This document provides a new DHCPv4 option for clients to obtain information about multiple TFTP [2] servers and bootfiles. 1. Introduction DHCPv4 (Dynamic Host Configuration Protocol Version for IPv4) provides a framework for passing configuration information to hosts on an IPv4 network. However, DHCPv4 does not provide a way to send more than one TFTP server address and bootfile names. This document defines a new option to provide more than one TFTP server and bootfile names. This option is required for clients, which are booting over a network and require more than one file to be Vijay, Senthil Expires April 31, 2004 [Page 1] Internet-Draft The Extended Remote Boot Option for DHCPv4 Oct 2003 downloaded and executed. The multiple TFTP servers are needed for high availability. Network booting is widely used mechanism for booting up of the clients, because of their advantages; softwares will be in central server and requires maintenance at only one location rather than maintaining individual systems separately. Also, switching between different operating systems becomes easy when network booting is being used. The additional boot files may be used as supporting software for the boot image. Different Operating System vendors use different way of handling this. 2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [7] 3. Terminology This document uses terminology specific to DHCPv4 as defined in=20 "Terminology" section of the DHCPv4 specification [1]. 4. Extended Remote Boot Option The Extended Remote Boot Option is used to carry the parameters needed for remote boot of the DHCPv4 [1] clients. Using the information provided by this option, the clients will be able to bootp up. The format of the Remote Boot Option is as shown below: Code Len Extended Remote Boot Information Field +-------+------+------+------+------+------+--...-+------+ | TBD | N | r1 | r2 | r3 | r4 | | rN | +-------+------+------+------+------+------+--...-+------+ The length N gives the total number of octets in the Extended Remote=20 Boot Information Field. The length N should be at least 4 bytes. r1, r2 .. rN are Remote Boot Information suboptions which contain=20 information needed for boot up of the clients. They should be=20 listed in the increasing order of preferences. The Remote Boot Information suboption is explained in the Section 5. 5. Remote Boot Information suboption The DHCP server uses the Remote Boot Information suboption to convey = the =20 client about the TFTP Server [3] names and list of boot files needed = for=20 booting of the clients. The clients are supposed to contact the TFTP = Server, obtain the boot files one by one and boot up using these = files. Vijay, Senthil Expires April 31, 2004 [Page 2] Internet-Draft The Extended Remote Boot Option for DHCPv4 Oct 2003 The format of the Remote Boot Information suboption is as shown = below: Code Len Remote Boot Information Field +-------+------+------+------+------+------+--...-+------+ | 1 | N | ts | f1 | f2 | f3 | | fN | +-------+------+------+------+------+------+--...-+------+ The length N gives the total number of octets in the Remote=20 Boot Information Field. The length N should be at least 2 bytes. 'ts' field consists of TFTP server name (option 66) [4] represented in the Opt/Length/Value tuples.=20 f1, f2 ... fN are sequence of Bootfile name (option 67) [4] represented in the Opt/Length/Value tuples. Thus, TFTP server name and Bootfile name are sent as suboption to Remote Boot Information option here. If multiple boot files are provided by the server, then, they should appear in the order of their execution in the client. The first appearing Bootfile name should be downloaded and executed first for=20 boot up, then the next and so on. 6 Server behavior If the server receives the request for TFTP server name and/or Bootfile name along with the Extended Remote Boot Option, the server SHOULD ignore the TFTP server name and/or Bootfile name option and reply back with Extended Remote Boot Option. When the DHCP server is replying back with Extended Remote Boot Option, the 'sname' and 'file' field SHOULD be used to overload the options. If the length of any of these options exceed the maximum permissible within a single option (254 octets), then they MUST be represented in the DHCP message as specified in [2]. 7 Client behavior The client MUST NOT request for TFTP server name and/or Bootfile name along with the Extended Remote Boot Option. If TFTP server name and/or Bootfile name are received in the reply the server, along with the Extended Remote Boot Option, then, the client MUST ignore TFTP server name and/or Bootfile name options. =20 If Extended Remote Boot Option is received and 'sname' and 'file' fields are not overloaded, the client MUST ignore the 'sname' and=20 'file' fields. Vijay, Senthil Expires April 31, 2004 [Page 3] Internet-Draft The Extended Remote Boot Option for DHCPv4 Oct 2003 8. Security Considerations The Remote Boot Option may be used by an intruder DHCPv4 server to=20 provide to cause DHCPv4 clients to contact rogue TFTP server (or) to send invalid file names. This will make booting up of DHCP clients to fail. =20 To avoid attacks through this option, the DHCP client SHOULD use=20 authentication mechanism for DHCP [5]. 9. IANA Considerations IANA is requested to assign an option code to the following options from the option-code space defined for public DHCP Options in=20 RFC 2939 [6]. Option Name Value Described in Extended Remote Boot Option tbd Section 4 10. Normative References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [2] T. Lemon, S. Cheshire, Encoding Long Options in the Dynamic Host=20 Configuration Protocol (DHCPv4), RFC 3396, November 2002. 11. Informative References [3] K. Sollins, The TFTP Protocol (Revision 2), RFC 1350, July 1992. =20 [4] Alexander, S. and R. Droms, "DHCP options and BOOTP Vendor Extensions", RFC 2132, March 1997. [5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [6] R. Droms, Procedures and IANA Guidelines for Definition of New=20 DHCP Options and Message Types, RFC 2939, September 2000.=20 =20 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Vijayabhaskar A K Hewlett-Packard STSD-I 29, Cunningham Road Bangalore - 560052 India Phone: +91-80-2053085 E-Mail: vijayak@india.hp.com Vijay, Senthil Expires April 31, 2004 [Page 4] Internet-Draft The Extended Remote Boot Option for DHCPv4 Oct 2003 Senthil Kumar B Hewlett-Packard STSD-I 29, Cunningham Road Bangalore - 560052 India Phone: +91-80-2053103 E-Mail: ksenthil@india.hp.com Vijay, Senthil Expires April 31, 2004 [Page 5] Internet-Draft The Extended Remote Boot Option for DHCPv4 Oct 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.=20 Vijay, Senthil Expires April 31, 2004 [Page 6] ------=_NextPart_000_000C_01C39FEF.F4D0A360 Content-Type: text/plain; name="draft-ietf-dhc-dhcpv6-opt-rboot-00.txt" Content-Disposition: attachment; filename="draft-ietf-dhc-dhcpv6-opt-rboot-00.txt" Content-Transfer-Encoding: 7bit Network Working Group A.K. Vijayabhaskar Internet-Draft B. Senthil Kumar Expires: April 31, 2004 Hewlett-Packard 30 Oct 2003 DHCPv6 Support for Remote Boot draft-ietf-dhc-dhcpv6-opt-rboot-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 31, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document provides new DHCPv6 (Dynamic Host Configuration protocol version 6) options for clients, to obtain information about TFTP [2] servers and bootfiles needed for booting. 1. Introduction Network booting is widely used mechanism for booting up of the clients. The clients contact the TFTP [2] server to download the bootfiles for bootup. The advantages of using network booting are; softwares will be in central server and requires maintenance at only one location rather than maintaining individual systems separately. Also, switching between different operating systems becomes easy when network booting is being used. In some cases, the nodes may need multiple bootfiles also. The additional boot files may be used as supporting software for the boot image. Different Operating System vendors use different way of handling this. Single TFTP server for Vijay, Senthil Expires April 31, 2004 [Page 1] Internet-Draft DHCPv6 Support for Remote Boot Oct 2003 huge number of diskless clients is prone to single point of failure. So, Multiple TFTP servers are needed for high availability. DHCPv6 (Dynamic Host Configuration Protocol Version 6) provides a framework for passing configuration information for hosts on an IPv6 network. However, DHCPv6 does not provide a way to send information about TFTP server address and bootfile names. This document defines two options, Remote boot option and Remote Boot parameter option to provide information about TFTP servers and bootfile names to the clients. These options are required for the clients, which are booting over a network. 2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [3] 3. Terminology This document uses terminology specific to IPv6 and DHCPv6 as defined in "Terminology" section of the DHCPv6 specification [1]. 4. Remote Boot Option The Remote Boot Option is used to carry the parameters needed for remote boot of the DHCPv6 clients. Using the information provided by this option, the DHCPv6 clients will bootp up. This will be mainly used by the clients, which are booting using remote boot server. The format of the Remote Boot Option is as shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_REMOTE_BOOT | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Remote-Boot-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_REMOTE_BOOT (tbd) option-len: Length of the 'Remote-Boot-options' fields in octets; Remote_Boot-options: Options associated with the Remote Boot Option. The Remote Boot option encapsulates those options that are specific to remote boot. This document defines one such option called Remote Boot Parameters Option. Multiple Remote Boot Parameters Options can appear in this option. This option is defined in the Section 5. Vijay, Senthil Expires April 31, 2004 [Page 2] Internet-Draft DHCPv6 Support for Remote Boot Oct 2003 5. Remote Boot Parameters Option The Remote Boot Parameters Option is used by the server to convey the client about the TFTP [2] Server IPv6 address and list of boot files needed for booting of the clients. The clients are supposed to contact the TFTP Server, obtain the boot files one by one and boot up using these files. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_REMOTE_BOOT_PARAMS | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | TFTP Server (IPv6 address) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Boot Files . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_REMOTE_BOOT_PARAMS (tbd) option-len: Length of the 'TFTP Server' (16 bytes) + 'Boot Files' in Octets; Boot Files: One or more Boot File names in the NVT-ASCII string format. Each file name should be NULL terminated. They should be represented as fully qualified directory-path name. If multiple boot files are provided by the server, then, they should appear in the order of their execution in the client. The first appearing boot file name should be downloaded and executed first for boot up, then the next and so on. This option can only appear in the OPTION_REMOTE_BOOT. If multiple Remote Boot Parameters Options are present in OPTION_REMOTE_BOOT, then they should be listed in the increasing order of preferences. 6. Appearance of these options The Remote Boot Option MUST NOT appear in other than the following messages: Solicit, Advertise, Request, Renew, Rebind, Information-Request and Reply. The option number of Remote Boot option MAY appear in the Option Request Option [1] in the following messages: Solicit, Request, Renew, Rebind, Information-Request and Reconfigure. The Remote Boot Parameters Option MUST appear only in the Remote Boot Option. Vijay, Senthil Expires April 31, 2004 [Page 3] Internet-Draft DHCPv6 Support for Remote Boot Oct 2003 7. Security Considerations The Remote Boot Option may be used by an intruder DHCPv6 server to provide to cause DHCPv6 clients to contact rogue TFTP server (or) to send invalid file names. This will make booting up of DHCPv6 clients to fail. To avoid attacks through this option, the DHCP client SHOULD use authenticated DHCP (see section "Authentication of DHCP messages" in the DHCPv6 specification [1]). 8. IANA Considerations IANA is requested to assign an option code to the following options from the option-code space defined in "DHCPv6 Options" section of the DHCPv6 specification [1]. Option Name Value Described in OPTION_REMOTE_BOOT tbd Section 4 OPTION_REMOTE_BOOT_PARAMS tbd Section 5 9. Normative References [1] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 10. Informative References [2] K. Sollins, The TFTP Protocol (Revision 2), RFC 1350, July 1992. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Vijayabhaskar A K Hewlett-Packard STSD-I 29, Cunningham Road Bangalore - 560052 India Phone: +91-80-2053085 E-Mail: vijayak@india.hp.com Vijay, Senthil Expires April 31, 2004 [Page 4] Internet-Draft DHCPv6 Support for Remote Boot Oct 2003 Senthil Kumar B Hewlett-Packard STSD-I 29, Cunningham Road Bangalore - 560052 India Phone: +91-80-2053103 E-Mail: ksenthil@india.hp.com Vijay, Senthil Expires April 31, 2004 [Page 5] Internet-Draft DHCPv6 Support for Remote Boot Oct 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Vijay, Senthil Expires April 31, 2004 [Page 6] ------=_NextPart_000_000C_01C39FEF.F4D0A360-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 11:42:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07223; Fri, 31 Oct 2003 11:42:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFcLZ-00039d-Re; Fri, 31 Oct 2003 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFcLK-00038U-Sy for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 11:41:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07169 for ; Fri, 31 Oct 2003 11:41:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFcLJ-00030Y-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 11:41:45 -0500 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1AFcLJ-00030U-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 11:41:45 -0500 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id h9VGdKGn010313; Fri, 31 Oct 2003 11:39:33 -0500 (EST) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Ralph Droms'" Cc: Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt Date: Fri, 31 Oct 2003 11:39:20 -0500 Message-ID: <000001c39fcd$8bebbbe0$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <1AB94312-0BB0-11D8-A8A6-000A95D9C74C@fugue.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I too support this draft (though it is not clear how much co-authors = count towards the last call process). Failover has had a long road (while there have only been 12 revisions of this draft, recall that there were initially two drafts that were merged = and they had several revisions each). This work has been supported by the WG throughout and we now need your support to assure it passes last call. Please speak up now (hopefully in favor). Being silent does the = community no good as it is unclear what it means - lack of interest, support, or = dissent. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of = Ted Lemon Sent: Friday, October 31, 2003 9:40 AM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt I'm very much in favor of advancing the failover draft. A lot of work=20 has gone into it, and it's in very good shape - the authors should be=20 proud of what they've done with this 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-admin@ietf.org Fri Oct 31 11:43:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07378; Fri, 31 Oct 2003 11:43:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFcMW-0003KN-IY; Fri, 31 Oct 2003 11:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFcML-0003IU-DM for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 11:42:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07304 for ; Fri, 31 Oct 2003 11:42:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFcMK-000321-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 11:42:48 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 1AFcMJ-00031L-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 11:42:47 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9VGgFfH002952 for ; Fri, 31 Oct 2003 08:42:16 -0800 (PST) Received: from mjs-xp.cisco.com ([161.44.65.248]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADP88603; Fri, 31 Oct 2003 11:42:14 -0500 (EST) Message-Id: <4.3.2.7.2.20031031112243.0250bf08@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Oct 2003 11:42:32 -0500 To: dhcwg@ietf.org From: Mark Stapp Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt In-Reply-To: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I am in favor of advancing this draft to Proposed Standard. -- Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 12:12:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08794; Fri, 31 Oct 2003 12:12:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFcob-0007XN-A3; Fri, 31 Oct 2003 12:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFco1-0007U0-Ve for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 12:11:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08736 for ; Fri, 31 Oct 2003 12:11:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFco0-0003Vn-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 12:11:24 -0500 Received: from h005.c015.snv.cp.net ([209.228.35.120] helo=c015.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 1AFcnz-0003Vk-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 12:11:23 -0500 Received: (cpmta 24101 invoked from network); 31 Oct 2003 09:11:18 -0800 Received: from 4.36.57.222 (HELO STEVEPC) by smtp.relicore.com (209.228.35.120) with SMTP; 31 Oct 2003 09:11:18 -0800 X-Sent: 31 Oct 2003 17:11:18 GMT From: "Steve Gonczi" To: Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt Date: Fri, 31 Oct 2003 12:11:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I am in favor of advancing this draft. Steve Gonczi _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 12:23:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09218; Fri, 31 Oct 2003 12:23:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFczF-0000Fa-97; Fri, 31 Oct 2003 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFcyo-0000Cz-QY for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 12:22:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09172 for ; Fri, 31 Oct 2003 12:22:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFcyn-0003g1-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 12:22:33 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 1AFcym-0003fi-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 12:22:32 -0500 Received: from jschnizl-w2k.cisco.com (rtp-vpn1-598.cisco.com [10.82.226.86]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9VHM0Rh012770; Fri, 31 Oct 2003 12:22:01 -0500 (EST) Message-Id: <4.3.2.7.2.20031031122037.0200eb60@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Oct 2003 12:21:59 -0500 To: Ralph Droms From: John Schnizlein Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 08:49 AM 10/31/2003, Ralph Droms wrote: >This message announces a WG last call on "DHCP Failover Protocol" >. > >This WG last call is a second last call on draft-ietf-dhc-failover-12.txt. >There was insufficient response to the earlier WG last call to determine >consensus on WG acceptance of the document. > >Please respond to this WG last call. I support advancing this draft. I am sorry I did not respond earlier. John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 12:38:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09754; Fri, 31 Oct 2003 12:38:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdDl-0002Lp-K3; Fri, 31 Oct 2003 12:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFdD0-00022v-Sn for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 12:37:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09683 for ; Fri, 31 Oct 2003 12:37:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFdCz-0003tI-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 12:37:13 -0500 Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx with esmtp (Exim 4.12) id 1AFdCy-0003rw-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 12:37:12 -0500 Received: from conversion-daemon.endeavor.poss.com by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <0HNM00M01U7ABI@endeavor.poss.com> for dhcwg@ietf.org; Fri, 31 Oct 2003 12:36:42 -0500 (EST) Received: from kan1 (pat-cap1.pahousegop.com [192.216.120.25]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HNM0052VU95FA@endeavor.poss.com> for dhcwg@ietf.org; Fri, 31 Oct 2003 12:36:42 -0500 (EST) Date: Fri, 31 Oct 2003 12:38:58 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt In-reply-to: <4.3.2.7.2.20031031122037.0200eb60@wells.cisco.com> To: dhcwg@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT I support this draft. --kan-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 14:29:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14786; Fri, 31 Oct 2003 14:29:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFexA-0006bN-QR; Fri, 31 Oct 2003 14:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFewi-0006Zv-Je for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 14:28:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14774 for ; Fri, 31 Oct 2003 14:28:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFewf-0005ig-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 14:28:30 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AFewf-0005iO-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 14:28:29 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9VJRvZq021389; Fri, 31 Oct 2003 11:27:57 -0800 (PST) Received: from kkinnear-w2k03.cisco.com ([161.44.65.180]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADQ06799; Fri, 31 Oct 2003 14:27:55 -0500 (EST) Message-Id: <4.3.2.7.2.20031031142513.024ab168@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Oct 2003 14:27:54 -0500 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt Cc: kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I support the movement of this draft forward to a successful WG last call. At 08:43 AM 10/31/2003, Ralph Droms wrote: >This message announces a WG last call on "DHCP Failover Protocol" >. The last call will conclude at 5PM ET on >Monday, 11/17/2003. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 14:32:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15046; Fri, 31 Oct 2003 14:32:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFf05-0006qa-VE; Fri, 31 Oct 2003 14:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFezh-0006p0-12 for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 14:31:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14957 for ; Fri, 31 Oct 2003 14:31:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFeze-0005mQ-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 14:31:34 -0500 Received: from smtp102.mail.sc5.yahoo.com ([216.136.174.140]) by ietf-mx with smtp (Exim 4.12) id 1AFezd-0005mN-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 14:31:33 -0500 Received: from adsl-64-170-118-75.dsl.snfc21.pacbell.net (HELO BarrH63p601) (rbhibbs@pacbell.net@64.170.118.75 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 31 Oct 2003 19:31:31 -0000 Reply-To: From: "Barr Hibbs" To: Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt Date: Fri, 31 Oct 2003 11:30:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I support advancing this draft. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 15:11:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17608; Fri, 31 Oct 2003 15:11:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfbp-0002qy-Dm; Fri, 31 Oct 2003 15:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfbn-0002qd-18 for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 15:10:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17537 for ; Fri, 31 Oct 2003 15:10:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFfbj-0006VZ-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 15:10:56 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AFfbj-0006VI-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 15:10:55 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h9VKAMbO021560; Fri, 31 Oct 2003 15:10:22 -0500 (EST) Received: from cisco.com ([161.44.65.126]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADQ12862; Fri, 31 Oct 2003 15:10:21 -0500 (EST) Message-ID: <3FA2C1AD.3080508@cisco.com> Date: Fri, 31 Oct 2003 15:10:21 -0500 From: Josh Littlefield Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralph Droms CC: dhcwg@ietf.org Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt References: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20031031083814.01f53720@flask.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I support moving this document forward. Ralph Droms wrote: > This message announces a WG last call on "DHCP Failover Protocol" > . The last call will conclude at 5PM ET on > Monday, 11/17/2003. > -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: same Boxborough, MA 01719-2205 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 17:27:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22800; Fri, 31 Oct 2003 17:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFhjQ-0006v3-QU; Fri, 31 Oct 2003 17:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfnF-0003qc-VF for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 15:22:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18538 for ; Fri, 31 Oct 2003 15:22:38 -0500 (EST) From: Eric.Luce@nominum.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFfnE-0006eX-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 15:22:48 -0500 Received: from shell.nominum.com ([128.177.192.160]) by ietf-mx with esmtp (Exim 4.12) id 1AFfnE-0006eH-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 15:22:48 -0500 Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id D333F137F0B for ; Fri, 31 Oct 2003 12:22:17 -0800 (PST) To: dhcwg@ietf.org Subject: re: [dhcwg] WG last call on draft-ietf-dhc-failover-12.txt X-URI: http://www.nominum.com/ X-Face: 6K2.ZvQgQ.NDQLIx.1pW(xRu*">:}&PX-Ad_!!?wU7H4L"wF"0xEwYu=8Or0V+=5?-eO1XL 7-0Hom/|]B2C7Uznyol-NVnvEk:+sod^MyB4v4qVpPDemr;b@pZdRSXu.'Gm^t0?2l,j[&t.kbc[UW x6Lz^e$K$W Date: Fri, 31 Oct 2003 12:22:17 -0800 Message-Id: <20031031202217.D333F137F0B@shell.nominum.com> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , RD> This WG last call is a second last call on RD> draft-ietf-dhc-failover-12.txt. There was insufficient RD> response to the earlier WG last call to determine consensus on RD> WG acceptance of the document. RD> Please respond to this WG last call. If you support RD> acceptance of the document without change, respond with a RD> simple acknowledgment, so that support for the document can be RD> assessed. I support acceptance of this draft as it is. -- Scanner (scanner@nominum.com) Nominum, Inc. | www.nominum.com | +1.650.779.6035 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Oct 31 20:09:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27447; Fri, 31 Oct 2003 20:09:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFkGE-0007dQ-9Z; Fri, 31 Oct 2003 20:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFkFe-0007bq-CF for dhcwg@optimus.ietf.org; Fri, 31 Oct 2003 20:08:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27406 for ; Fri, 31 Oct 2003 20:08:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFkFc-0002Gc-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 20:08:24 -0500 Received: from [202.97.224.98] (helo=mail.hl.cn) by ietf-mx with smtp (Exim 4.12) id 1AFkFa-0002GY-00 for dhcwg@ietf.org; Fri, 31 Oct 2003 20:08:23 -0500 Received: from mail.hl.cn([127.0.0.1]) by mail.hl.cn(AIMC 2.9.5.6) with SMTP id jmc3fa36276; Sat, 01 Nov 2003 08:57:02 +0800 Received: from asgard.ietf.org([132.151.6.40]) by mail.hl.cn(AIMC 2.9.5.6) with SMTP id jm503f9e2392; Tue, 28 Oct 2003 14:56:37 +0800 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AEJrk-0003uZ-Ih for ietf-announce-list@asgard.ietf.org; Mon, 27 Oct 2003 21:45:52 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AEFXr-00086K-0F for all-ietf@asgard.ietf.org; Mon, 27 Oct 2003 17:09:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18832; Mon, 27 Oct 2003 17:08:51 -0500 (EST) Message-Id: <200310272208.RAA18832@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 27 Oct 2003 17:08:51 -0500 Precedence: bulk X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-announce@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-06.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 Lease Query Author(s) : R. Woundy, K. Kinnear Filename : draft-ietf-dhc-leasequery-06.txt Pages : 25 Date : 2003-10-24 A DHCP server contains considerable authoritative information concerning the IP addresses it has leased to DHCP clients. Other processes and devices, many that already send and receive DHCP format packets, sometimes need to access this information. The leasequery protocol is designed to give these processes and devices a lightweight way to access information that may be critical to their operation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-leasequery-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-leasequery-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-27170928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-leasequery-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-leasequery-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27170928.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg