Path: ...!news.misty.com!weretis.net!feeder6.news.weretis.net!tncsrv06.tnetconsulting.net!tncsrv09.home.tnetconsulting.net!.POSTED.omega.home.tnetconsulting.net!not-for-mail
From: Grant Taylor <gtaylor@tnetconsulting.net>
Newsgroups: comp.os.linux.misc
Subject: Re: I never thought of this scenario
Date: Sun, 21 Apr 2024 14:51:53 -0500
Organization: TNet Consulting
Message-ID: <v03qop$32u$1@tncsrv09.home.tnetconsulting.net>
References: <uv2g3g$39k$1@tncsrv09.home.tnetconsulting.net>
 <uvcu5a$2qdb0$5@dont-email.me>
 <uvd6m3$n3m$1@tncsrv09.home.tnetconsulting.net>
 <uvhtft$3th0n$6@dont-email.me>
 <uvhv0m$kq3$1@tncsrv09.home.tnetconsulting.net>
 <uvs61u$2g9b9$5@dont-email.me> <uvsv4f$3cvv$1@news1.tnib.de>
 <uvv1qf$392q8$2@dont-email.me> <uvve26$3f4ea$1@dont-email.me>
 <wwvh6fwxy7q.fsf@LkoBDZeT.terraraq.uk> <v0108c$3q01h$1@dont-email.me>
 <v0111s$3q1fd$1@dont-email.me> <v013pv$3qmkf$1@dont-email.me>
 <v014gp$3qp0c$1@dont-email.me>
 <v017q3$td0$4@tncsrv09.home.tnetconsulting.net> <v02ona$894n$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Apr 2024 19:51:53 -0000 (UTC)
Injection-Info: tncsrv09.home.tnetconsulting.net; posting-host="omega.home.tnetconsulting.net:198.18.1.140";
	logging-data="3166"; mail-complaints-to="newsmaster@tnetconsulting.net"
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v02ona$894n$1@dont-email.me>
Bytes: 5247
Lines: 102

On 4/21/24 05:10, The Natural Philosopher wrote:
> Is a destination address of 255.255.255.255 routable?

No it is not.

IANA, the keeper of special things like this, has this to say about the 
"Limited Broadcast"

        Address Block:	255.255.255.255/32
                 Name:	Limited Broadcast
                  RFC:	RFC8190 RFC919
      Allocation Date:	1984-10
     Termination Date:	N/A
               Source:	False
          Destination:	True
          Forwardable:	False
   Globally Reachable:	False
Reserved-by-Protocol:	True

Link - IANA IPv4 Special-Purpose Address Registry
  - 
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

> Of course it is, if a router is configured to do an 'all stations 
> broadcast' across the internet!

I disagree.

Even if one device is mis-configured to forward it, the next upstream 
device that is properly configured / default configuration won't forward it.

> What changes is that the client which has no IP address at this stage, 
> instead has to be given one by the first router it encounters.

Nope.  The first router doesn't have to give it one.

The DHCP *server* sends a DHCP /offer/ after receiving a DHCP /discover/ 
and a DHCP /ACK/ after receiving a DHCP /request/.

N.B. the DHCP relay agent can be running on an end system in the network 
that is not a router.

The DHCP /relay/ running on a system in the broadcast domain receives 
the DHCP discover, sends sends the DHCP discover to the remote DHCP 
server's unicast IP using it's own relay IP as the source.  The relay 
also adds information to the DHCP discover message to include the 
client's MAC address / possibly other identifying information; e.g. 
Client-ID.

The DHCP server receives a unicast DHCP discover to it's unicast IP from 
the DHCP relay's unicast IP.  The DHCP discover has information to 
identify the remote client that originally sent the discover and the 
network that it is on.

The DHCP server sends a DHCP offer back to the DHCP relay's unicast IP 
from the DHCP server's unicast IP.

The DHCP relay receives the DHCP offer to it's unicast IP from the DHCP 
server's unicast IP.  --  The DHCP relay the relays the offer back to 
the client on the local network.

The client receives the remote DHCP server's offer, send a DHCP request 
and receives a DHCP ACK through the same channels.

Once the client has an IP address, it can talk to the DHCP server 
directly through the routed network without needing the aid of the DHCP 
relay agent.

> When the router receives a response it has to translate that back to 
> the MAC address of the sender  on its local port.

The DHCP relay agent, not necessarily the router.

> It's not much different from address translation, in that the router 
> needs to exercise intelligence about some packet contents, rather  than 
> juts their source and destination  and next hop addresses.

Nope.

The router doesn't need to be involved in the DHCP relay agent process 
at all.

It's perfectly valid to have a router that knows nothing about DHCP and 
a separate system on the network functioning as the DHCP relay agent.

> AS far as intelligence goes its nothing like as complex as running BGP 
> or OSPF or  other routing protocols.
> 
> Calling this action a 'relay agent' makes it all into something it is 
> not - a separate addition to routers in general.  DHCP can be and is 
> routed by routers.

And yet the RFCs that define this behavior use the phrase "relay agent". 
  And the functionality is not tied to a router.

> The rest is semantics

Not quite.



-- 
Grant. . . .