From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1WcQZU-0002zg-MD for mharc-grub-devel@gnu.org; Mon, 21 Apr 2014 22:36:32 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcQZM-0002z8-Gj for grub-devel@gnu.org; Mon, 21 Apr 2014 22:36:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WcQZG-0001qa-HK for grub-devel@gnu.org; Mon, 21 Apr 2014 22:36:24 -0400 Received: from mail-la0-x231.google.com ([2a00:1450:4010:c03::231]:33614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WcQZG-0001pp-8k for grub-devel@gnu.org; Mon, 21 Apr 2014 22:36:18 -0400 Received: by mail-la0-f49.google.com with SMTP id mc6so3742749lab.22 for ; Mon, 21 Apr 2014 19:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=PB10mmEdIkciw5/fK/HFzlE2GiiCcFxeKXa4VCpFdIc=; b=TNAlTHhHT38/LekxCcalxaezShFoFXwqjra8gET1Rxl80XtkBnBSUoc0iGaNo3I3Z+ JdvuDlriFK4NJL4WOodguWj75MYwsYmIS2Ob9EkQ6SzTZptgyxQu3XT0v34bRhmcxsSx IPkLUEaYD0KENRxoPCz0VPJCu0HP3EyhdL/z36LksnSDMKynp5T6PSoFLu2dsNQWLBdF qgCZ1yie6HrG6ub5/QtJ1PRl2GYfTXfMIXJjpewv+/BfxtURA9BOiW9r9YqXdi+ytQCY 2BpHeSysH17UmHUYL0Y7TUpBjt4BqEmRyk4RiIL/R4+pFcw76lKZirIr/XJP/kCQfzEX 5vhA== X-Received: by 10.152.29.40 with SMTP id g8mr146411lah.65.1398134176857; Mon, 21 Apr 2014 19:36:16 -0700 (PDT) Received: from opensuse.site (ppp37-190-15-130.pppoe.spdop.ru. [37.190.15.130]) by mx.google.com with ESMTPSA id zx3sm814451lbc.2.2014.04.21.19.36.15 for (version=SSLv3 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 19:36:15 -0700 (PDT) Date: Tue, 22 Apr 2014 06:36:14 +0400 From: Andrey Borzenkov To: "Mroczek, Joseph T" Subject: Re: RFC Remove classful causing incorrect routing behavior Message-ID: <20140422063614.4970abfe@opensuse.site> In-Reply-To: <6D165E863E048E4D86C25F15CEA532979767843D@ORSMSX109.amr.corp.intel.com> References: <6D165E863E048E4D86C25F15CEA5329797665E90@ORSMSX109.amr.corp.intel.com> <5353D667.5040600@gmail.com> <6D165E863E048E4D86C25F15CEA532979766FD0E@ORSMSX109.amr.corp.intel.com> <20140421214134.22a5efdf@opensuse.site> <6D165E863E048E4D86C25F15CEA532979767843D@ORSMSX109.amr.corp.intel.com> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::231 Cc: The development of GNU GRUB X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 02:36:31 -0000 В Tue, 22 Apr 2014 00:13:15 +0000 "Mroczek, Joseph T" пишет: > > From: Andrey Borzenkov [mailto:arvidjaar@gmail.com] > > Sent: Monday, April 21, 2014 10:42 AM > > > > В Mon, 21 Apr 2014 15:56:07 +0000 > > "Mroczek, Joseph T" пишет: > > > > > > > From: Behalf Of Vladimir 'f-coder/phcoder' Serbinenko On 19.04.2014 > > > > 02:48, Mroczek, Joseph T wrote: > > > > > Hello: > > > > > > > > > > Currently, the DHCP logic assumes that if a gateway is received in > > > > > the DHCP > > > > packet the boot server is on a remote network. Given that CIDR is > > > > now over > > > > 20 years old, I think it is a safe assumption that a netmask will be > > > > offered in DHCP options. > > > > > > > > > > Can this be removed? Or is there still a need to cover the classful case? > > > > > > > > > Please detail the failure scenario. > > > > Current code follows standard behaviour for PXE clients and changing > > > > it would break any installation which relies on it. > > > > > > > Hmm ... re-reading RFC2131 I ask myself what are conditions when > > *client* is supposed to use gateway_ip at all. According to RFC, giaddr is set > > by DHCP relay when it forwards request from client so server knows where > > to send reply to. DHCP relay then forwards reply on local subnet according to > > standard rules. RFC does not say anything about client usage of this field. > > Actually there is no requirement that DHCP relay also functions as normal > > router. > > Use of giaddr as a gateway dates back to RFC951. At that point in time we did not have DHCP options, so this was a way to dynamicially learn the gateway. > Oh. Digging further, RFC1542 quite explicitly states the same: A BOOTP client MUST NOT interpret the 'giaddr' field of a BOOTREPLY message to be the IP address of an IP router. A BOOTP client SHOULD completely ignore the contents of the 'giaddr' field in BOOTREPLY messages. ... > > > > The failure will occur in most if not all cases where the DHCP sends a > > > gateway when the boot server is on the same subnet as the client, > > > > In view of the above, how is it possible? DHCP server is not supposed to set > > this field at all - at the most it simply replies back to relay with same value of > > giaddr it got. If giaddr is set it is already indication that server and client are on > > different subnets. > > For my case, DHCP server is on different subnet but boot/TFTP server is on same as client. > I see. I rather agree with your patch, it looks like semantic of giaddr was settled 20 years ago.