From owner-zeroconf@merit.edu Wed Oct 1 04:35:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03172 for ; Wed, 1 Oct 2003 04:35:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0E41291227; Wed, 1 Oct 2003 04:35:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC1B491229; Wed, 1 Oct 2003 04:35:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8515F91227 for ; Wed, 1 Oct 2003 04:35:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6931C5DE19; Wed, 1 Oct 2003 04:35:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id DD3035DE18 for ; Wed, 1 Oct 2003 04:35:16 -0400 (EDT) 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 Sender: owner-zeroconf@merit.edu Precedence: bulk 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 From owner-zeroconf@merit.edu Wed Oct 1 10:28:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15195 for ; Wed, 1 Oct 2003 10:28:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 38BBA91236; Wed, 1 Oct 2003 10:28:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0489291269; Wed, 1 Oct 2003 10:28:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0687091236 for ; Wed, 1 Oct 2003 10:28:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEB8F5DE24; Wed, 1 Oct 2003 10:28:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id C13445DE19 for ; Wed, 1 Oct 2003 10:28:34 -0400 (EDT) Received: from [192.168.2.2] (usr2.Karahalios.org [192.168.2.2]) (authenticated) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id h91ESUi30110; Wed, 1 Oct 2003 07:28:30 -0700 In-Reply-To: <3F7A9189.2090709@sun.com> References: <3F79B93E.6030601@sun.com> <1064944549.4769.5.camel@hades> <3F7A9189.2090709@sun.com> Mime-Version: 1.0 (Apple Message framework v604) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8755A160-F41B-11D7-92DE-00039377AD70@Outersoft.com> Content-Transfer-Encoding: 7bit Cc: Erik Guttman From: Alex Karahalios Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP Date: Wed, 1 Oct 2003 07:28:30 -0700 To: Zeroconf X-Mailer: Apple Mail (2.604) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Does this mean that once a DHCP address is established that the machine will not participate in IPv4LL? If this is the case, then it would be problematic in that if another node is brought online that does not obtain an DHCP address (either it does not want to or DHCP server is down), then that node cannot communicate with the first node using IPv4LL. Alex Karahalios On Oct 1, 2003, at 1:34 AM, Erik Guttman wrote: > 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. From owner-zeroconf@merit.edu Wed Oct 1 11:35:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19649 for ; Wed, 1 Oct 2003 11:35:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 391A091210; Wed, 1 Oct 2003 11:35:25 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08EFB91223; Wed, 1 Oct 2003 11:35:24 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1722E91210 for ; Wed, 1 Oct 2003 11:35:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F075E5DD8C; Wed, 1 Oct 2003 11:35:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 07E1D5DDA1 for ; Wed, 1 Oct 2003 11:35:22 -0400 (EDT) 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 h91FYmw03041; Wed, 1 Oct 2003 22:34:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h91FYNc14291; Wed, 1 Oct 2003 22:34:31 +0700 (ICT) From: Robert Elz To: Alex Karahalios Cc: Zeroconf , Erik Guttman Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP In-Reply-To: <8755A160-F41B-11D7-92DE-00039377AD70@Outersoft.com> References: <8755A160-F41B-11D7-92DE-00039377AD70@Outersoft.com> <3F79B93E.6030601@sun.com> <1064944549.4769.5.camel@hades> <3F7A9189.2090709@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Oct 2003 22:34:23 +0700 Message-ID: <28365.1065022463@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 1 Oct 2003 07:28:30 -0700 From: Alex Karahalios Message-ID: <8755A160-F41B-11D7-92DE-00039377AD70@Outersoft.com> | Does this mean that once a DHCP address is established that the machine | will not participate in IPv4LL? If this is the case, then it would be | problematic in that if another node is brought online that does not | obtain an DHCP address (either it does not want to or DHCP server is | down), then that node cannot communicate with the first node using | IPv4LL. This is simply not true. Go back and read the list archives. kre From owner-zeroconf@merit.edu Wed Oct 1 12:40:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22648 for ; Wed, 1 Oct 2003 12:40:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8C3A291223; Wed, 1 Oct 2003 12:40:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C1D691227; Wed, 1 Oct 2003 12:40:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8ADB91223 for ; Wed, 1 Oct 2003 12:40:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D2B8C5DDDD; Wed, 1 Oct 2003 12:40:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by segue.merit.edu (Postfix) with ESMTP id BC4425DDCE for ; Wed, 1 Oct 2003 12:40:08 -0400 (EDT) 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 Sender: owner-zeroconf@merit.edu Precedence: bulk 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 > From owner-zeroconf@merit.edu Thu Oct 2 05:16:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08737 for ; Thu, 2 Oct 2003 05:16:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E4809126B; Thu, 2 Oct 2003 05:15:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3DDF9126F; Thu, 2 Oct 2003 05:15:44 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D20449126B for ; Thu, 2 Oct 2003 05:15:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B36F95DDA6; Thu, 2 Oct 2003 05:15:43 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id 570D95DDA0 for ; Thu, 2 Oct 2003 05:15:43 -0400 (EDT) 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 Sender: owner-zeroconf@merit.edu Precedence: bulk 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 From owner-zeroconf@merit.edu Tue Oct 7 07:48:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27787 for ; Tue, 7 Oct 2003 07:48:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B8CFD91271; Tue, 7 Oct 2003 07:48:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4405E91320; Tue, 7 Oct 2003 07:48:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C666C91271 for ; Tue, 7 Oct 2003 07:48:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB0F85DDE7; Tue, 7 Oct 2003 07:48:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 4783B5DD9F for ; Tue, 7 Oct 2003 07:48:09 -0400 (EDT) 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 Sender: owner-zeroconf@merit.edu Precedence: bulk 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 >> > From owner-zeroconf@merit.edu Tue Oct 7 13:57:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13938 for ; Tue, 7 Oct 2003 13:57:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 87B7F913A8; Tue, 7 Oct 2003 13:55:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 934AB913A6; Tue, 7 Oct 2003 13:55:51 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AED9291344 for ; Tue, 7 Oct 2003 13:53:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B4D05DDDB; Tue, 7 Oct 2003 13:53:18 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by segue.merit.edu (Postfix) with ESMTP id DB1055DE1A for ; Tue, 7 Oct 2003 13:53:15 -0400 (EDT) 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 Sender: owner-zeroconf@merit.edu Precedence: bulk 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 > >> > > > > From owner-zeroconf@merit.edu Wed Oct 8 05:40:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07880 for ; Wed, 8 Oct 2003 05:40:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7D3991299; Wed, 8 Oct 2003 05:40:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 715FA912A2; Wed, 8 Oct 2003 05:40:00 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5319F91299 for ; Wed, 8 Oct 2003 05:39:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 41B135DE33; Wed, 8 Oct 2003 05:39:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 7487B5DE2B for ; Wed, 8 Oct 2003 05:39:58 -0400 (EDT) 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 Sender: owner-zeroconf@merit.edu Precedence: bulk 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. From owner-zeroconf@merit.edu Wed Oct 8 13:03:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27627 for ; Wed, 8 Oct 2003 13:03:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E97C8912C9; Wed, 8 Oct 2003 13:03:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85F9E912D3; Wed, 8 Oct 2003 13:03:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3DCE4912C9 for ; Wed, 8 Oct 2003 13:03:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 242F65DE49; Wed, 8 Oct 2003 13:03:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from hades.pp.htv.fi (cs180094.pp.htv.fi [213.243.180.94]) by segue.merit.edu (Postfix) with ESMTP id 1F3C75DE33 for ; Wed, 8 Oct 2003 13:03:11 -0400 (EDT) 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 Sender: owner-zeroconf@merit.edu Precedence: bulk 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 From owner-zeroconf@merit.edu Thu Oct 9 12:34:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27236 for ; Thu, 9 Oct 2003 12:34:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7EA51913FA; Thu, 9 Oct 2003 12:33:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7D039140C; Thu, 9 Oct 2003 12:33:03 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BCDF591405 for ; Thu, 9 Oct 2003 12:32:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A02305DE03; Thu, 9 Oct 2003 12:32:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 8EA815DDD3 for ; Thu, 9 Oct 2003 12:32:28 -0400 (EDT) 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 Subject: LL34: Comments on the state diagram and proposed text Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk 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 From owner-zeroconf@merit.edu Fri Oct 10 09:18:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26925 for ; Fri, 10 Oct 2003 09:18:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E238891260; Fri, 10 Oct 2003 09:17:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADDFA9138F; Fri, 10 Oct 2003 09:17:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83F8291260 for ; Fri, 10 Oct 2003 09:17:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39D6C5DEA4; Fri, 10 Oct 2003 09:17:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id ACEE15DDA8 for ; Fri, 10 Oct 2003 09:17:36 -0400 (EDT) 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 Subject: Re: LL34: Comments on the state diagram and proposed text References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk 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 From owner-zeroconf@merit.edu Mon Oct 13 10:39:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08588 for ; Mon, 13 Oct 2003 10:39:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 04D8F91232; Mon, 13 Oct 2003 10:39:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6D1B91256; Mon, 13 Oct 2003 10:39:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD1A991232 for ; Mon, 13 Oct 2003 10:39:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C361F5DE59; Mon, 13 Oct 2003 10:39:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 6B4F85DE52 for ; Mon, 13 Oct 2003 10:39:35 -0400 (EDT) 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 Sender: owner-zeroconf@merit.edu Precedence: bulk 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 From owner-zeroconf@merit.edu Mon Oct 13 16:50:53 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28499 for ; Mon, 13 Oct 2003 16:50:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C9277912AD; Mon, 13 Oct 2003 16:49:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94942912C3; Mon, 13 Oct 2003 16:49:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92DEC912AD for ; Mon, 13 Oct 2003 16:49:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8038D5DF09; Mon, 13 Oct 2003 16:49:44 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from shell-ng.nominum.com (shell-ng.nominum.com [81.200.64.181]) by segue.merit.edu (Postfix) with ESMTP id 336875DECC for ; Mon, 13 Oct 2003 16:49:44 -0400 (EDT) Received: from yomiko.ddns.nominum.com (dhcp-146.engr.nominum.com [128.177.194.146]) by shell-ng.nominum.com (Postfix) with ESMTP id 6886056851 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: owner-zeroconf@merit.edu Precedence: bulk >>>>> "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 From owner-zeroconf@merit.edu Wed Oct 15 12:22:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07595 for ; Wed, 15 Oct 2003 12:22:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 34EEB9125C; Wed, 15 Oct 2003 12:22:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04A4B9125D; Wed, 15 Oct 2003 12:22:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D04D89125C for ; Wed, 15 Oct 2003 12:22:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B7A0C5DE03; Wed, 15 Oct 2003 12:22:10 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by segue.merit.edu (Postfix) with ESMTP id 6A8B95DDB8 for ; Wed, 15 Oct 2003 12:22:10 -0400 (EDT) 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 h9FGM7lb023425 for ; Wed, 15 Oct 2003 12:22:07 -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 ADD88971; Wed, 15 Oct 2003 12:22:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20031015120126.046d7840@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Oct 2003 12:22:01 -0400 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: new issue: LL34 Better transition to routable from v4LL using DHCP In-Reply-To: <3F603CDA.6070906@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Seems to me the underlying issue is the interaction between v4LL and any "working routable address" (a routable address that can be used for off-link communication). That is, I don't think it matters where the routable address comes from - whether it be DHCP, manual configuration, or some other mechanism - rather, the issue is how to get the interface to a state in which it can use a v4LL address when no working routable address is available. The way in which I would describe how a device uses v4LL would be to use the state of the interface itself as the basis for invoking v4LL. If an interface does not have a working routable address, the device invokes v4LL for that interface. When the interface does have a working routable address, v4LL is not used. The issue of when to use v4LL is indirectly addressed in section 1.7 and more directly in 2.11. I suggest combining 1.7 and 2.11 into a single section that: * states the conditions under which v4LL is used (paraphrasing what I wrote in the previous paragraph) - based on state of interface - defines "working routable address" - v4LL used when no working routable address is available * gives pointers to other documents, such as draft-ietf-dhc-dns-ipv4-01.txt, that define how to determine if an interface has a working routable address * points out the it is an implementation detail for the protocol software to monitor the state of the interface and invoke v4LL as appropriate * emphasizes that v4Ll has no effect on the use of other configuration mechanism - Ralph At 11:14 AM 9/11/2003 +0200, Erik Guttman wrote: >Description of Issue: Better transition to routable from v4LL using DHCP >Submitter Name Bernard Aboba >Submitter Email Address aboba@internaut.com >Date first submitted 11 Sep 03 >Reference >Comment Type Technical >Priority S (must change) >Section 2.11 (new section) >Rationale/Explanation of issue: > >(a) We need to ensure an orderly method for recovering a routable > address given LLv4 addressing. Much of the time an LLv4 address > is allocated inappropriately, and so it's important to be able > to obtain a routable address via DHCP if one is available. The > current LLv4 spec doesn't address this, and the current default > retry interval of 5 minutes is way too long. > >(b) Interactions of DHCP with LLv4. The LLv4 specification seems to > imply that an LLv4 address should be allocated when a DHCPREQUEST > or DHCPDISCOVER does not obtain an answer. Existing implementations > show that this behavior is problematic since the lack of response is > most likely a temporary phenomena or the result of a bug of some > kind rather than the lack of a DHCP server on the link. > > 5 minutes is too long. I'd suggest 1 minute or even less (I've > seen a Linux implementation which retries every 30 seconds with > jitter and that works a lot better). > > >Lengthy description of problem: > >Requested change: > >Create a new section: >2.11 Repeatedly Attempt to Obtain A Routable Address > > As per Section 1.7, use a routable address is preferred to use of > a link-local address. In many cases, a link-local address is > configured because a DHCP server failed to respond to an initial > query, or is inoperative for some time. Experience has shown that > five minutes (see Appendix A.2 for example) was too long an > interval to wait and try to configure with DHCP. > > A host which has been configured with an IPv4 link-local address > SHOULD periodically attempt to obtain an IPv4 address via DHCP. > The recommended policy is to attempt to configure using DHCP after > waiting for RECONF_INTERVAL, plus a random number of seconds, > uniformly distributed, between zero to RECONF_JITTER seconds. > >Modify: >9. Constants > >Add: > > RECONF_INTERVAL 25 seconds > RECONF_JITTER 10 seconds From owner-zeroconf@merit.edu Mon Oct 20 08:50:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24114 for ; Mon, 20 Oct 2003 08:50:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 30BE991232; Mon, 20 Oct 2003 08:50:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 038C791234; Mon, 20 Oct 2003 08:50:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2ACC91232 for ; Mon, 20 Oct 2003 08:50:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD3335DDEC; Mon, 20 Oct 2003 08:50:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by segue.merit.edu (Postfix) with ESMTP id 97A815DDBD for ; Mon, 20 Oct 2003 08:50:14 -0400 (EDT) Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 Oct 2003 05:50:46 -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 h9KCoAQY023783 for ; Mon, 20 Oct 2003 05:50:12 -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 ADH26755; Mon, 20 Oct 2003 08:50:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20031015122459.00b4ca10@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Oct 2003 08:50:04 -0400 To: zeroconf@merit.edu From: Ralph Droms Subject: Editorial comment on draft-ietf-zeroconf-linklocal-10.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk While technically the Abstract is correct, I found the initial reference to "configuration" confusing relative to the address assignment provided by v4LL. I suggest editing the Abstract to: To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a DHCP server. Unfortunately, such address 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 address 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. - Ralph From owner-zeroconf@merit.edu Wed Oct 22 05:31:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00822 for ; Wed, 22 Oct 2003 05:31:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B24D49122C; Wed, 22 Oct 2003 05:31:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A06491230; Wed, 22 Oct 2003 05:31:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 28CBE9122C for ; Wed, 22 Oct 2003 05:31:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 136DC5DD9F; Wed, 22 Oct 2003 05:31:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id BAA815DD9E for ; Wed, 22 Oct 2003 05:31:53 -0400 (EDT) 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 h9M9VhxA005873; Wed, 22 Oct 2003 02:31:44 -0700 (PDT) Received: from sun.com (vpn-129-156-96-114.EMEA.Sun.COM [129.156.96.114]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h9M9Vdi21356; Wed, 22 Oct 2003 11:31:40 +0200 (MEST) Message-ID: <3F964E2F.7040908@sun.com> Date: Wed, 22 Oct 2003 11:30:23 +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: Ralph Droms Cc: zeroconf@merit.edu Subject: wrapping up the ipv4LL state change discussion References: <4.3.2.7.2.20031015120126.046d7840@flask.cisco.com> In-Reply-To: <4.3.2.7.2.20031015120126.046d7840@flask.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Folks, The state diagram is a new can of worms for which there is no clear support. Let's drop further discussion of improving it so that it can be included in the draft. There has been the suggestion that we need to modify draft 10 in order to clarify how transitions occur. In particular we need to 1. Make 100% clear that neither the DHCP state machine nor any other address configuration mechanism is changed or effected by the IPv4LL configuration mechanism. Rather the choice of when and how to transition 2. The discussion of the criteria determining when an routable IP address is available should be handled through (normative) citation of DNAv4. 3. Explicit text is needed to make it clear that it is not forbidden to configure an IPv4LL address when one has other address configuration. This is also not recommended. Discussion of use of IPv4LL while a host has other address configuration for a link amounts to support of multihoming. This topic and concerns it raises are discussed in section 3. Is there agreement that these are the three points we need to address? If so, let's draft text. Ralph, I hope I captured your concerns here. Erik Ralph Droms wrote: > Seems to me the underlying issue is the interaction between v4LL and any > "working routable address" (a routable address that can be used for > off-link > communication). That is, I don't think it matters where the routable > address comes from - whether it be DHCP, manual configuration, or some > other > mechanism - rather, the issue is how to get the interface to a state in > which it can use a v4LL address when no working routable address is > available. > > The way in which I would describe how a device uses v4LL would be to use > the > state of the interface itself as the basis for invoking v4LL. If an > interface does not have a working routable address, the device invokes v4LL > for that interface. When the interface does have a working routable > address, v4LL is not used. > > The issue of when to use v4LL is indirectly addressed in section 1.7 and > more directly in 2.11. I suggest combining 1.7 and 2.11 into a single > section that: > > * states the conditions under which v4LL is used (paraphrasing what I wrote > in the previous paragraph) > - based on state of interface > - defines "working routable address" > - v4LL used when no working routable address is available > * gives pointers to other documents, such as > draft-ietf-dhc-dns-ipv4-01.txt, > that define how to determine if an interface has a working routable > address > * points out the it is an implementation detail for the protocol > software to > monitor the state of the interface and invoke v4LL as appropriate > * emphasizes that v4Ll has no effect on the use of other configuration > mechanism > > - Ralph > > At 11:14 AM 9/11/2003 +0200, Erik Guttman wrote: > >> Description of Issue: Better transition to routable from v4LL using DHCP >> Submitter Name Bernard Aboba >> Submitter Email Address aboba@internaut.com >> Date first submitted 11 Sep 03 >> Reference >> Comment Type Technical >> Priority S (must change) >> Section 2.11 (new section) >> Rationale/Explanation of issue: >> >> (a) We need to ensure an orderly method for recovering a routable >> address given LLv4 addressing. Much of the time an LLv4 address >> is allocated inappropriately, and so it's important to be able >> to obtain a routable address via DHCP if one is available. The >> current LLv4 spec doesn't address this, and the current default >> retry interval of 5 minutes is way too long. >> >> (b) Interactions of DHCP with LLv4. The LLv4 specification seems to >> imply that an LLv4 address should be allocated when a DHCPREQUEST >> or DHCPDISCOVER does not obtain an answer. Existing implementations >> show that this behavior is problematic since the lack of response is >> most likely a temporary phenomena or the result of a bug of some >> kind rather than the lack of a DHCP server on the link. >> >> 5 minutes is too long. I'd suggest 1 minute or even less (I've >> seen a Linux implementation which retries every 30 seconds with >> jitter and that works a lot better). >> >> >> Lengthy description of problem: >> >> Requested change: >> >> Create a new section: >> 2.11 Repeatedly Attempt to Obtain A Routable Address >> >> As per Section 1.7, use a routable address is preferred to use of >> a link-local address. In many cases, a link-local address is >> configured because a DHCP server failed to respond to an initial >> query, or is inoperative for some time. Experience has shown that >> five minutes (see Appendix A.2 for example) was too long an >> interval to wait and try to configure with DHCP. >> >> A host which has been configured with an IPv4 link-local address >> SHOULD periodically attempt to obtain an IPv4 address via DHCP. >> The recommended policy is to attempt to configure using DHCP after >> waiting for RECONF_INTERVAL, plus a random number of seconds, >> uniformly distributed, between zero to RECONF_JITTER seconds. >> >> Modify: >> 9. Constants >> >> Add: >> >> RECONF_INTERVAL 25 seconds >> RECONF_JITTER 10 seconds > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- E r i k G u t t m a n cell: +49 172 865 5497 N1 Serviceability & Manageability Time zone: CEST (GMT+1) Sun Microsystems Have you web-enabled viewing your calendar yet? If not, please do! http://namefinder.sfbay.sun.com/nfPermMail.jsp From owner-zeroconf@merit.edu Wed Oct 29 17:33:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11556 for ; Wed, 29 Oct 2003 17:33:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ED94491282; Wed, 29 Oct 2003 17:33:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C12FF9128C; Wed, 29 Oct 2003 17:33:33 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB5C691282 for ; Wed, 29 Oct 2003 17:33:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2FFE5DDF9; Wed, 29 Oct 2003 17:33:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fire.cisco.com (firebird.cisco.com [171.68.227.73]) by segue.merit.edu (Postfix) with ESMTP id 1BF355DDE9 for ; Wed, 29 Oct 2003 17:33:32 -0500 (EST) Received: from REMAKERW2K (remaker-w2k.cisco.com [171.69.103.49]) by fire.cisco.com (8.11.7+Sun/8.8.8) with SMTP id h9TMXVk09416 for ; Wed, 29 Oct 2003 14:33:31 -0800 (PST) Message-ID: <01e101c39e6c$ae1d53c0$82da45ab@amer.cisco.com> From: "Phillip Remaker" To: Subject: A Zeroconf situation? Date: Wed, 29 Oct 2003 14:33:30 -0800 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Will somebody help me walk through this possible zeroconf application I am trying to formulate. I have an appliance. A home gateway, a home router, a Networked Refrigerator, An ethernet connected vacuum cleaner.... whatever.... Unconfigured, out of shrink wrap. I drop it in a static addressed or DHCP-served network, but I *don't* want to to claim a DHCP address (there may be a VERY limited number of IPv4 addresses from the lcoal DHCP server, and I would not want the device to presume that it can have one of them). I want it to come up as IPv4LL, and unable to route, unable to claim a DHCP address. I want it to detect the presence of a DHCP server, but not claim an address. Now, a static/DHCP IPv4 addressed device on the same broadcast domain wants to discover that type of device (or set of devices) in the domain, and configure them, in a uPnP sort of way, or maybe through a web browser. I envision maybe a multicast address for discovery? Effectively, we have two ships-in-the-night V4 subnets on a broadcast domain. Most V4 stacks won't have a link local and globally scoped address on the same interface. Even if I multicast from a non v4LL address to a v4LL address, how would the v4LL device be able to respond to an 'off subnet' address (apparently, it wouldn't?) So in short, is there a 1) Means to communicate between a link local and globally scoped address? Is it allowed? 2) Means to discover the device(s) that have a Link Local address? Sounds like a uPnP meets zeroconf scenario, but I can't grok the best way to get globally and locally scoped hosts to communicate. If it is even possible. The fundamenal idea is that I can drop an unconfigured device onto any network in a non-disruptive way, and then discover and configure it while not having to mess with the stack/addressing of the configuring machine. Is this problem addressed? The devices are on the same broadcast domain yet will not be able to talk since they disagree about the subnet. From owner-zeroconf@merit.edu Wed Oct 29 18:01:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12602 for ; Wed, 29 Oct 2003 18:01:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D33C9128C; Wed, 29 Oct 2003 18:01:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26B7E9129F; Wed, 29 Oct 2003 18:01:47 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16AF59128C for ; Wed, 29 Oct 2003 18:01:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id E98D65DD9A; Wed, 29 Oct 2003 18:01:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by segue.merit.edu (Postfix) with ESMTP id 98F035DD8E for ; Wed, 29 Oct 2003 18:01:45 -0500 (EST) Received: from mail5.microsoft.com ([157.54.6.156]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Wed, 29 Oct 2003 15:03:19 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Wed, 29 Oct 2003 15:01:44 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Oct 2003 15:01:43 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 29 Oct 2003 15:01:43 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 29 Oct 2003 15:02:40 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 29 Oct 2003 15:01:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: A Zeroconf situation? Date: Wed, 29 Oct 2003 15:01:47 -0800 Message-ID: Thread-Topic: A Zeroconf situation? thread-index: AcOebMVqbqTSb/P3RPC8ugAIh91U0AAAeY8w From: "Christian Huitema" To: "Phillip Remaker" , X-OriginalArrivalTime: 29 Oct 2003 23:01:42.0005 (UTC) FILETIME=[9DF41250:01C39E70] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > Now, a static/DHCP IPv4 addressed device on the same broadcast domain > wants > to discover that type of device (or set of devices) in the domain, and > configure them, in a uPnP sort of way, or maybe through a web browser. I > envision maybe a multicast address for discovery? UPNP discovery is implemented using SSDP, which does indeed use multicast. However, since you mention UPNP, you should consider this excerpt from the UPNP architecture specification (http://www.upnp.org/download/UPnPDA10_20000613.htm): The foundation for UPnP networking is IP addressing.=20 Each device must have a Dynamic Host Configuration=20 Protocol (DHCP) client and search for a DHCP server=20 when the device is first connected to the network.=20 If a DHCP server is available, i.e., the network is=20 managed, the device must use the IP addressed assigned=20 to it. If no DHCP server is available, i.e., the network=20 is unmanaged; the device must use automatic IP addressing=20 (Auto-IP) to obtain an address. Auto-IP refers to the automatic address allocation protocol used in versions of Windows since 98, i.e. the protocol that zeroconf is trying to standardize.=20 -- Christian Huitema From owner-zeroconf@merit.edu Thu Oct 30 05:47:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16962 for ; Thu, 30 Oct 2003 05:47:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFF379127C; Thu, 30 Oct 2003 05:47:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1B07912B2; Thu, 30 Oct 2003 05:47:39 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD7DC9127C for ; Thu, 30 Oct 2003 05:47:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9BFD65DDD3; Thu, 30 Oct 2003 05:47:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 46A4A5DDB0 for ; Thu, 30 Oct 2003 05:47:33 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h9UAlAN04309; Thu, 30 Oct 2003 17:47:15 +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 h9UAl4C13214; Thu, 30 Oct 2003 17:47:04 +0700 (ICT) From: Robert Elz To: "Phillip Remaker" Cc: zeroconf@merit.edu Subject: Re: A Zeroconf situation? In-Reply-To: <01e101c39e6c$ae1d53c0$82da45ab@amer.cisco.com> References: <01e101c39e6c$ae1d53c0$82da45ab@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Oct 2003 17:47:04 +0700 Message-ID: <15413.1067510824@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 29 Oct 2003 14:33:30 -0800 From: "Phillip Remaker" Message-ID: <01e101c39e6c$ae1d53c0$82da45ab@amer.cisco.com> | I have an appliance. A home gateway, a home router, a Networked | Refrigerator, An ethernet connected vacuum cleaner.... whatever.... | Unconfigured, out of shrink wrap. I drop it in a static addressed or | DHCP-served network, but I *don't* want to to claim a DHCP address Notice here that it is you who doesn't want it to have a DHCP address, not the appliance itself. If it was in my house instead of yours I can assure you I would want the exact same appliance to get an address from DHCP. Other than getting at the device and configuring it, which is what we're all trying to avoid, there's no way to make the device act differently. The obvious answer here is that the DHCP servers act differently - yours doesn't give the appliance an address (doesn't offer one), mine does. In each case, the appliance tries to get a DHCP address, in your house it fails, in mine it succeeds. Then, as in the note Christian quoted, when yours fails to get a DHCP address, it gives itself a LL one instead. | (there may be a VERY limited number of IPv4 addresses from the lcoal | DHCP server, and I would not want the device to presume that it can | have one of them). The device should be presuming nothing - it should simply take the best that is available to it in the environment into which it happens to have been placed. | I want it to come up as IPv4LL, and unable to route, unable to claim a DHCP | address. I want it to detect the presence of a DHCP server, but not claim | an address. Why on earth would you want to detect the DHCP server in that event? If it has nothing for you, you don't care if it exists or not. If you want to see if there is a DHCP server that will tell you other useful information (like the IP address of your Impress server) then you can try a DHCPINFORM request after a DHCPDISCOVER has revealed nothing. | Effectively, we have two ships-in-the-night V4 subnets on a broadcast | domain. Not quite. | Most V4 stacks won't have a link local and globally scoped address | on the same interface. The idea is that if you're going to have any devices on your net which are using LL addresses, and you want to be able to communicate with them, then those V4 stacks can't be ignorant. They don't need both addresses, but they do need to know how to reach LL addresses (ie: that LL addresses are out there on the LAN, and the device should simply ARP for one). | Even if I multicast from a non v4LL address to a | v4LL address, how would the v4LL device be able to respond to an 'off | subnet' address (apparently, it wouldn't?) It would. The LL spec requires LL using devices to ARP for *everything* they need to reach. If the destination is on the same LAN, it will reply. If it isn't, a device with only LL can't communicate with it, which has all cost one ARP request to discover. | So in short, is there a | | 1) Means to communicate between a link local and globally scoped address? | Is it allowed? yes, it is allowed. What's more it all almost "just works" even with current devices (or most of them) - they may need to be configured with an explicit interface route for LL addresses (and devices with multiple interfaces will probably only be able to talk to LL devices on one of them without code updates) but it does all work. All this has been discussed many times before. | The fundamenal idea is that I can drop an unconfigured device onto any | network in a non-disruptive way, and then discover and configure it while | not having to mess with the stack/addressing of the configuring machine. This you would need to do, currently. Once LL is truly accepted, we can expect systems to simply "know" how to reach them without needing anything special done to them to make it happen (that is, devices will auto-configure themselves with a route to LL destinations, and multi-interface systems will provide a means to choose which interface to use). Short term, things will be a bit messy, but not actually hard. Read the draft. Look back over the list archives. kre From owner-zeroconf@merit.edu Fri Oct 31 11:39:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06669 for ; Fri, 31 Oct 2003 11:39:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1EB3B912D4; Thu, 30 Oct 2003 20:28:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC22B912D5; Thu, 30 Oct 2003 20:28:29 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00C39912D4 for ; Thu, 30 Oct 2003 20:28:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id E058E5DE85; Thu, 30 Oct 2003 20:28:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by segue.merit.edu (Postfix) with ESMTP id 5B49E5DE83 for ; Thu, 30 Oct 2003 20:28:28 -0500 (EST) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.10/8.12.9) with ESMTP id h9V1SRrY004688 for ; Thu, 30 Oct 2003 17:28:27 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 30 Oct 2003 17:27:53 -0800 Received: from [17.219.195.30] ([17.219.195.30]) by scv3.apple.com (8.12.9/8.12.9) with SMTP id h9V1Ru0m009698; Thu, 30 Oct 2003 17:27:56 -0800 (PST) Message-Id: <200310310127.h9V1Ru0m009698@scv3.apple.com> Subject: Re: A Zeroconf situation? Date: Thu, 30 Oct 2003 17:28:26 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Phillip Remaker" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Effectively, we have two ships-in-the-night V4 subnets on a broadcast >domain. Most V4 stacks won't have a link local and globally scoped address >on the same interface. Even if I multicast from a non v4LL address to a >v4LL address, how would the v4LL device be able to respond to an 'off >subnet' address (apparently, it wouldn't?) > >So in short, is there a > >1) Means to communicate between a link local and globally scoped address? >Is it allowed? >2) Means to discover the device(s) that have a Link Local address? Communication between the link-local and routable subnets on the same physical link is allowed, encouraged, and described in >The fundamenal idea is that I can drop an unconfigured device onto any >network in a non-disruptive way, and then discover and configure it while >not having to mess with the stack/addressing of the configuring machine. > >Is this problem addressed? Yes, this is an important issue. When Apple shipped the first AirPort base station all those years ago, the ability to configure it without having to change the network settings on the client machine was very important, and this is why we added route-to-link-local in OS 9, and then later in OS X when OS X launched. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org