RE: RFC Remove classful causing incorrect routing behavior

[Mroczek, Joseph T]

> 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.

Great. Thanks!