RFC Remove classful causing incorrect routing behavior

RFC Remove classful causing incorrect routing behavior

[Mroczek, Joseph T]

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?

Thank you for any attention you can pay this matter.

~joe


diff -Naur grub-2.02~beta2/grub-core/net/bootp.c grub-2.02~beta2-jtm-clean/grub-core/net/bootp.c
--- grub-2.02~beta2/grub-core/net/bootp.c	2013-12-24 11:40:31.000000000 -0500
+++ grub-2.02~beta2-jtm-clean/grub-core/net/bootp.c	2014-04-18 20:38:05.858208600 -0400
@@ -191,18 +227,6 @@
   if (bp->gateway_ip)
     {
       grub_net_network_level_netaddress_t target;
-      grub_net_network_level_address_t gw;
-      char *rname;
-	  
-      target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
-      target.ipv4.base = bp->server_ip;
-      target.ipv4.masksize = 32;
-      gw.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
-      gw.ipv4 = bp->gateway_ip;
-      rname = grub_xasprintf ("%s:gw", name);
-      if (rname)
-	grub_net_add_route_gw (rname, target, gw);
-      grub_free (rname);
 
       target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
       target.ipv4.base = bp->gateway_ip;

Re: RFC Remove classful causing incorrect routing behavior

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

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.
> Thank you for any attention you can pay this matter.
> 
> ~joe
> 
> 
> diff -Naur grub-2.02~beta2/grub-core/net/bootp.c grub-2.02~beta2-jtm-clean/grub-core/net/bootp.c
> --- grub-2.02~beta2/grub-core/net/bootp.c	2013-12-24 11:40:31.000000000 -0500
> +++ grub-2.02~beta2-jtm-clean/grub-core/net/bootp.c	2014-04-18 20:38:05.858208600 -0400
> @@ -191,18 +227,6 @@
>    if (bp->gateway_ip)
>      {
>        grub_net_network_level_netaddress_t target;
> -      grub_net_network_level_address_t gw;
> -      char *rname;
> -	  
> -      target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> -      target.ipv4.base = bp->server_ip;
> -      target.ipv4.masksize = 32;
> -      gw.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> -      gw.ipv4 = bp->gateway_ip;
> -      rname = grub_xasprintf ("%s:gw", name);
> -      if (rname)
> -	grub_net_add_route_gw (rname, target, gw);
> -      grub_free (rname);
>  
>        target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
>        target.ipv4.base = bp->gateway_ip;
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 274 bytes --]

RE: RFC Remove classful causing incorrect routing behavior

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

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, with the additional condition that the gateway and boot server are on different hosts. There may be some routers that will forward the traffic back on the local subnet, but most routers do not do this. The net result is grub fails to contact the boot server. I am not sure what you mean by standard behavior. Mulitple Intel option ROMs (i386 & EFI), broadcom option ROMs, gPXE, Microsoft WDS, and syslinux/pxelinux all route properly for local boot servers when both netmask and gateway are set. 

The only use cases I could see breaking with this change require two conditions, one of which I would be very surprised to see. The two conditions are that the boot server is on a remote network (not-common but does happen), and the DHCP server does not send a subnet mask in options (rare to non-existent.) Not sending a subnet mask in this day and age is arguably broken behavior. 

~joe


> > Thank you for any attention you can pay this matter.
> >
> > ~joe
> >
> >
> > diff -Naur grub-2.02~beta2/grub-core/net/bootp.c grub-2.02~beta2-jtm-
> clean/grub-core/net/bootp.c
> > --- grub-2.02~beta2/grub-core/net/bootp.c	2013-12-24
> 11:40:31.000000000 -0500
> > +++ grub-2.02~beta2-jtm-clean/grub-core/net/bootp.c	2014-04-18
> 20:38:05.858208600 -0400
> > @@ -191,18 +227,6 @@
> >    if (bp->gateway_ip)
> >      {
> >        grub_net_network_level_netaddress_t target;
> > -      grub_net_network_level_address_t gw;
> > -      char *rname;
> > -
> > -      target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> > -      target.ipv4.base = bp->server_ip;
> > -      target.ipv4.masksize = 32;
> > -      gw.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> > -      gw.ipv4 = bp->gateway_ip;
> > -      rname = grub_xasprintf ("%s:gw", name);
> > -      if (rname)
> > -	grub_net_add_route_gw (rname, target, gw);
> > -      grub_free (rname);
> >
> >        target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> >        target.ipv4.base = bp->gateway_ip;
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> 

Re: RFC Remove classful causing incorrect routing behavior

[Andrey Borzenkov]

В Mon, 21 Apr 2014 15:56:07 +0000
"Mroczek, Joseph T" <joseph.t.mroczek@intel.com> пишет:

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

PXE spec indeed mentions giaddr as possible source for gateway to
connect to TFTP server, without going into much details how stack
selects between multiple gateways if present. But grub does not call
PXE TFTP, right?

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

>  with the additional condition that the gateway and boot server are on
>  different hosts. There may be some routers that will forward the
>  traffic back on the local subnet, but most routers do not do this. The
>  net result is grub fails to contact the boot server. I am not sure
>  what you mean by standard behavior. Mulitple Intel option ROMs (i386 &
>  EFI), broadcom option ROMs, gPXE, Microsoft WDS, and syslinux/pxelinux
>  all route properly for local boot servers when both netmask and
>  gateway are set. 

> 



> The only use cases I could see breaking with this change require two conditions, one of which I would be very surprised to see. The two conditions are that the boot server is on a remote network (not-common but does happen), and the DHCP server does not send a subnet mask in options (rare to non-existent.) Not sending a subnet mask in this day and age is arguably broken behavior. 
> 
> ~joe
> 
> 
> > > Thank you for any attention you can pay this matter.
> > >
> > > ~joe
> > >
> > >
> > > diff -Naur grub-2.02~beta2/grub-core/net/bootp.c grub-2.02~beta2-jtm-
> > clean/grub-core/net/bootp.c
> > > --- grub-2.02~beta2/grub-core/net/bootp.c	2013-12-24
> > 11:40:31.000000000 -0500
> > > +++ grub-2.02~beta2-jtm-clean/grub-core/net/bootp.c	2014-04-18
> > 20:38:05.858208600 -0400
> > > @@ -191,18 +227,6 @@
> > >    if (bp->gateway_ip)
> > >      {
> > >        grub_net_network_level_netaddress_t target;
> > > -      grub_net_network_level_address_t gw;
> > > -      char *rname;
> > > -
> > > -      target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> > > -      target.ipv4.base = bp->server_ip;
> > > -      target.ipv4.masksize = 32;
> > > -      gw.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> > > -      gw.ipv4 = bp->gateway_ip;
> > > -      rname = grub_xasprintf ("%s:gw", name);
> > > -      if (rname)
> > > -	grub_net_add_route_gw (rname, target, gw);
> > > -      grub_free (rname);
> > >
> > >        target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> > >        target.ipv4.base = bp->gateway_ip;
> > >
> > > _______________________________________________
> > > Grub-devel mailing list
> > > Grub-devel@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/grub-devel
> > >
> > 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel

RE: RFC Remove classful causing incorrect routing behavior

[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" <joseph.t.mroczek@intel.com> пишет:
> >
> > > 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.

> PXE spec indeed mentions giaddr as possible source for gateway to connect
> to TFTP server, without going into much details how stack selects between	 
> multiple gateways if present. But grub does not call PXE TFTP, right?

I have not seen any instances of it. All the tftp code I have seen uses tftp.c, which does not seem to leverage PXE TFTP functions. Just packet send/receive.
 
> > 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.

> >  with the additional condition that the gateway and boot server are on
> > different hosts. There may be some routers that will forward the
> > traffic back on the local subnet, but most routers do not do this. The
> > net result is grub fails to contact the boot server. I am not sure
> > what you mean by standard behavior. Mulitple Intel option ROMs (i386 &
> > EFI), broadcom option ROMs, gPXE, Microsoft WDS, and syslinux/pxelinux
> > all route properly for local boot servers when both netmask and
> > gateway are set.
> 
> >
> 
> 
> 
> > The only use cases I could see breaking with this change require two
> conditions, one of which I would be very surprised to see. The two conditions
> are that the boot server is on a remote network (not-common but does
> happen), and the DHCP server does not send a subnet mask in options (rare
> to non-existent.) Not sending a subnet mask in this day and age is arguably
> broken behavior.
> >
> > ~joe
> >
> >
> > > > Thank you for any attention you can pay this matter.
> > > >
> > > > ~joe
> > > >
> > > >
> > > > diff -Naur grub-2.02~beta2/grub-core/net/bootp.c
> > > > grub-2.02~beta2-jtm-
> > > clean/grub-core/net/bootp.c
> > > > --- grub-2.02~beta2/grub-core/net/bootp.c	2013-12-24
> > > 11:40:31.000000000 -0500
> > > > +++ grub-2.02~beta2-jtm-clean/grub-core/net/bootp.c	2014-04-18
> > > 20:38:05.858208600 -0400
> > > > @@ -191,18 +227,6 @@
> > > >    if (bp->gateway_ip)
> > > >      {
> > > >        grub_net_network_level_netaddress_t target;
> > > > -      grub_net_network_level_address_t gw;
> > > > -      char *rname;
> > > > -
> > > > -      target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> > > > -      target.ipv4.base = bp->server_ip;
> > > > -      target.ipv4.masksize = 32;
> > > > -      gw.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> > > > -      gw.ipv4 = bp->gateway_ip;
> > > > -      rname = grub_xasprintf ("%s:gw", name);
> > > > -      if (rname)
> > > > -	grub_net_add_route_gw (rname, target, gw);
> > > > -      grub_free (rname);
> > > >
> > > >        target.type = GRUB_NET_NETWORK_LEVEL_PROTOCOL_IPV4;
> > > >        target.ipv4.base = bp->gateway_ip;
> > > >

Re: RFC Remove classful causing incorrect routing behavior

[Andrey Borzenkov]

В Tue, 22 Apr 2014 00:13:15 +0000
"Mroczek, Joseph T" <joseph.t.mroczek@intel.com> пишет:

> > 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" <joseph.t.mroczek@intel.com> пишет:
> > >
> > > > 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.

RE: RFC Remove classful causing incorrect routing behavior

[Mroczek, Joseph T]

> From: Andrey Borzenkov [mailto:arvidjaar@gmail.com]
> Sent: Monday, April 21, 2014 7:36 PM
> 
> В Tue, 22 Apr 2014 00:13:15 +0000
> "Mroczek, Joseph T" <joseph.t.mroczek@intel.com> пишет:
> 
> > > 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" <joseph.t.mroczek@intel.com> пишет:
> > > >
> > > > > 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!

RE: RFC Remove classful causing incorrect routing behavior

[Mroczek, Joseph T]

> -----Original Message-----
> From: grub-devel-bounces+joseph.t.mroczek=intel.com@gnu.org
> [mailto:grub-devel-bounces+joseph.t.mroczek=intel.com@gnu.org] 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:arvidjaar@gmail.com]
> > Sent: Monday, April 21, 2014 7:36 PM
> >
> > В Tue, 22 Apr 2014 00:13:15 +0000
> > "Mroczek, Joseph T" <joseph.t.mroczek@intel.com> пишет:
> >
> > > > 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" <joseph.t.mroczek@intel.com> пишет:
> > > > >
> > > > > > 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