Re: RFC Remove classful causing incorrect routing behavior

[Andrey Borzenkov]

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

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