Sujet : Re: I never thought of this scenario
De : gtaylor (at) *nospam* tnetconsulting.net (Grant Taylor)
Groupes : comp.os.linux.miscDate : 21. Apr 2024, 20:51:53
Autres entêtes
Organisation : TNet Consulting
Message-ID : <v03qop$32u$1@tncsrv09.home.tnetconsulting.net>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
User-Agent : Mozilla Thunderbird
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.xhtmlOf 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. . . .