RE: RFC Remove classful causing incorrect routing behavior

[Mroczek, Joseph T]

> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden On
> Behalf Of Mroczek, Joseph T
> Sent: Monday, April 28, 2014 5:07 PM
> To: Andrey Borzenkov
> Cc: The development of GNU GRUB
> Subject: RE: RFC Remove classful causing incorrect routing behavior
> 
> 
> 
> > From: Andrey Borzenkov [mailto:address@hidden
> > Sent: Monday, April 21, 2014 7:36 PM
> >
> > В Tue, 22 Apr 2014 00:13:15 +0000
> > "Mroczek, Joseph T" <address@hidden> пишет:
> >
> > > > From: Andrey Borzenkov [mailto:address@hidden
> > > > Sent: Monday, April 21, 2014 10:42 AM
> > > >
> > > > В Mon, 21 Apr 2014 15:56:07 +0000
> > > > "Mroczek, Joseph T" <address@hidden> пишет:
> > > > >
> > > > > > 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.
> >
> 
> I saw this. I did not remove all of the use of giaddr field because of 
> regression
> concerns.
> 
> > > > > 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.
> 

I don't see this in the list of commits. Is there anything I can do to help 
this change along?

~joe