On 20/04/2024 12:54, Marc Haber wrote:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> I don’t personally care how DHCP gets across routers but from a quick
>> skim it looks like it relies some kind of relay agent. Table 1 or
>> section 3.1 might be reasonable references.
>
> DHCP uses both broadcast and unicast communication. Broadcast is
> mainly used in stages where the client system does not yet have a
> valid IP address and thus cannot use unicast.
>
> For the broadcast part of the protocol, a relay agent is needed when
> the DHCP server does not have access to the broadcast domain the
> client is connected to.
>
> As soon as the client can speak proper IP, it communicates directly
> with the DHCP server, this part of communication relys on regular IP
> routing and does not need the relay agent any more.
>
> Greetings
> Marc

The so called 'relay agent' is simply part of what high end routers DO.
A router is itself a 'relay agent'

--
“People believe certain stories because everyone important tells them,
and people tell those stories because everyone important believes them.
Indeed, when a conventional wisdom is at its fullest strength, one’s
agreement with that conventional wisdom becomes almost a litmus test of
one’s suitability to be taken seriously.”

Paul Krugman

On 20.04.2024 um 13:28 Uhr The Natural Philosopher wrote:

> On 20/04/2024 12:54, Marc Haber wrote:
> > Richard Kettlewell <invalid@invalid.invalid> wrote:
> >> I don’t personally care how DHCP gets across routers but from a
> >> quick skim it looks like it relies some kind of relay agent. Table
> >> 1 or section 3.1 might be reasonable references.
> >
> > DHCP uses both broadcast and unicast communication. Broadcast is
> > mainly used in stages where the client system does not yet have a
> > valid IP address and thus cannot use unicast.
> >
> > For the broadcast part of the protocol, a relay agent is needed when
> > the DHCP server does not have access to the broadcast domain the
> > client is connected to.
> >
> > As soon as the client can speak proper IP, it communicates directly
> > with the DHCP server, this part of communication relys on regular IP
> > routing and does not need the relay agent any more.
> >
> > Greetings
> > Marc
>
> The so called 'relay agent' is simply part of what high end routers
> DO. A router is itself a 'relay agent'

It is completely independent of routing. A normal computer can act as
an DHCP relay agent.
Professional routers simply include that because there is often a need
for it and the amount of performance and work needed for the relay
agent is small.

--
kind regards
Marco

Send spam to 1713612490muell@cartoonies.org

On 4/20/24 05:37, D wrote:
> I'm no DHCP ninja, so please forgive my ignorance, but wouldn't it be
> possible to just setup a test to prove who the winner is?

I thought about doing that very thing. Then I decided that it wasn't
worth my time to do so. And that even if it was, there's no way that I
could convince people that my results are genuine. So I'm not wasting
my time.

> Or is it the case that different DHCP server/client software is
> implemented differently so it might work with some and not others,
> and that that is the heart of the conflict?

No, I don't think that this would matter enough in different
implementations. Assuming that it's a standard compliant
implementation. Thus eliding incomplete implementations / early
implementations.

--
Grant. . . .

On 17.04.2024 um 03:17 Uhr Lawrence D'Oliveiro wrote:

> No, I didn’t miss it at all. It’s listed under “design goals”, not
> actually under how the spec works.
>
> By definition such a protocol cannot work across routers, because
> clients don’t know what routers are available until a DHCP server
> tells them.

It can't work across routers without helpers because the client knows
nothing about the network, so the discover message will got to the
non-directed broadcast 255.255.255.255. Traffic to that address is by
design not being routed because that would mean forward it to the
entire world. Another problem is to get the answer back because the src
address is 0.0.0.0 at this stage. That is why the relay agent is needed
and forward all that with src and dst being unicast addresses.

Even with DHCPv6 a helper is needed if the DHCP server resides on
another link (also called broadcast domain).

--
kind regards
Marco

Send spam to 1713316679muell@cartoonies.org

On 4/20/24 01:18, Marc Haber wrote:
> The don't need to be if a DHCP agent is available. DHCP agents are
> considerably easier to implement AND don't need persistent state. They
> can just be implemented in "less intellgent" network devices. This
> also considerably eases exchange of defective devices since you don't
> lose state unless it's the DHCP server itself that is exchanged.

I agree that they don't /need/ to be. But they /can/ be. ;-)

> That is unneccesarily confusing, DHCP has nothing to do with browse
> master elections. I surely hope that Windows doesn't do those any more.

It was a reference to how a DHCP server can serve a /remote/ subnet and
thus avoid undesirable traffic inherently local to the (remote) subnet.

DHCP can provide node type and NBNS settings which influence if and when
SMB broadcasts are sent.

--
Grant. . . .

On 4/20/24 10:12, Marco Moock wrote:
> It is completely independent of routing. A normal computer can act
> as an DHCP relay agent.

+1

> Professional routers simply include that because there is often a
> need for it and the amount of performance and work needed for the
> relay agent is small.

+1

--
Grant. . . .

Richard Kettlewell <invalid@invalid.invalid> wrote:
> Rich <rich@example.invalid> writes:
>> And, the protocol "must" be routable:
>>
>> RFC2131: https://www.rfc-editor.org/rfc/rfc2131 - page 6:
>>
>> DHCP should not require a server on each subnet. To allow for
>> scale and economy, DHCP must work across routers or through the
>> intervention of BOOTP relay agents.
>>
>> Note they use "must" above in the statement "DHCP must work across
>> routers". Page 4 defines "must" as:
>>
>> o "MUST"
>>
>> This word or the adjective "REQUIRED" means that the item is an
>> absolute requirement of this specification.
>
> You missed a bit:
>
> Throughout this document, the words that are used to define the
> significance of particular requirements are capitalized. These words
> ^^^^^^^^^^^
> are:
>
>
> The ‘must’ in the design goals is not capitalized.

Indeed, I did miss that.

>> Therefore the RFC explicitly allows for DHCP to be routed.
>
> A protocol is not its design goals. You can’t conclude that a protocol
> actually achieves a goal just by looking at the what the goals were. A
> good recent example would be SIKE, which totally failed to meet its
> design goals.

Fair enough, however, given:

1) no explicit statement requiring non-routability in the RFC (if the
designers had wanted it to be "non-routable" as Lawrence continues to
asssert, they would have said so);

2) an explicit statement in the design goals of "working across
routers"

it therefore becomes reasonable to presume that "routability" was
at a minimum, not excluded, and was likely intended.

> I don’t personally care how DHCP gets across routers but from a quick
> skim it looks like it relies some kind of relay agent. Table 1 or
> section 3.1 might be reasonable references.

It relies on a BOOTP Relay agent only for the initial, unconfigured, no
IP address state, of the client. Once the client has an IP, other DHCP
protocol interactions happen using the client IP, and no BOOTP Relay
agents are involved.

DHCP is also not a "transport layer" protocol. Instead, it uses UDP
for its transport layer (see RFC url above, page 22):

"DHCP uses UDP as its transport protocol."

Since UDP is itself routable, DHCP is also routable, because DHCP is
simply a protocol definition for sending particular "messages" inside
of UDP packets.

On 20.04.2024 um 18:07 Uhr Rich wrote:

> Richard Kettlewell <invalid@invalid.invalid> wrote:
> > Rich <rich@example.invalid> writes:
> >> And, the protocol "must" be routable:
> >>
> >> RFC2131: https://www.rfc-editor.org/rfc/rfc2131 - page 6:
> >>
> >> DHCP should not require a server on each subnet. To allow
> >> for scale and economy, DHCP must work across routers or through the
> >> intervention of BOOTP relay agents.
> >>
> >> Note they use "must" above in the statement "DHCP must work across
> >> routers". Page 4 defines "must" as:
> >>
> >> o "MUST"
> >>
> >> This word or the adjective "REQUIRED" means that the item
> >> is an absolute requirement of this specification.
> >
> > You missed a bit:
> >
> > Throughout this document, the words that are used to define the
> > significance of particular requirements are capitalized. These
> > words ^^^^^^^^^^^
> > are:
> >
> >
> > The ‘must’ in the design goals is not capitalized.
>
> Indeed, I did miss that.

Does that change the meaning?

> >> Therefore the RFC explicitly allows for DHCP to be routed.
> >
> > A protocol is not its design goals. You can’t conclude that a
> > protocol actually achieves a goal just by looking at the what the
> > goals were. A good recent example would be SIKE, which totally
> > failed to meet its design goals.
>
> Fair enough, however, given:
>
> 1) no explicit statement requiring non-routability in the RFC (if the
> designers had wanted it to be "non-routable" as Lawrence continues to
> asssert, they would have said so);

I don't know how that should work because a DHCP machine doesn't know
anything. ICMP address configuration exists (now deprecated) and Router
advertisements for IPv4 are specified too.
https://datatracker.ietf.org/doc/html/rfc6918
https://www.rfc-editor.org/rfc/rfc1256
But I don't know any implementation for that.

That means an DHCPv4 host doesn't know anything and can only use a "all
machines" address. Such addresses can't be reasonably used to contact
really all machines in the world.
The packet must also go back to the DHCP client and sending it to
everybody in the internet isn't reasonable too.
The solution is to stay on the same link or use Unicast for
transporting that through routers.

> 2) an explicit statement in the design goals of "working across
> routers"
>
> it therefore becomes reasonable to presume that "routability" was
> at a minimum, not excluded, and was likely intended.

True, but I doubt there would be a solution for that. Even DHCPv6 needs
a relay agent. DHCPv6 over multicast is only for communication between
DHCPv6 servers.

> > I don’t personally care how DHCP gets across routers but from a
> > quick skim it looks like it relies some kind of relay agent. Table
> > 1 or section 3.1 might be reasonable references.
>
> It relies on a BOOTP Relay agent only for the initial, unconfigured,
> no IP address state, of the client. Once the client has an IP, other
> DHCP protocol interactions happen using the client IP, and no BOOTP
> Relay agents are involved.
>
> DHCP is also not a "transport layer" protocol. Instead, it uses UDP
> for its transport layer (see RFC url above, page 22):
>
> "DHCP uses UDP as its transport protocol."
>
> Since UDP is itself routable, DHCP is also routable, because DHCP is
> simply a protocol definition for sending particular "messages" inside
> of UDP packets.

That depends on the addresses being used. When being used on
non-directed broadcast, link-local unicast or link-local multicast, UDP
can't be routed because the IP layer forbids routing of those packages.

--
kind regards
Marco

Send spam to 1713629228muell@cartoonies.org

On Sat, 20 Apr 2024, Grant Taylor wrote:

> On 4/20/24 05:37, D wrote:
>> I'm no DHCP ninja, so please forgive my ignorance, but wouldn't it be
>> possible to just setup a test to prove who the winner is?
>
> I thought about doing that very thing. Then I decided that it wasn't worth
> my time to do so. And that even if it was, there's no way that I could
> convince people that my results are genuine. So I'm not wasting my time.

Yes, that makes perfect sense.

>> Or is it the case that different DHCP server/client software is implemented
>> differently so it might work with some and not others, and that that is the
>> heart of the conflict?
>
> No, I don't think that this would matter enough in different implementations.
> Assuming that it's a standard compliant implementation. Thus eliding
> incomplete implementations / early implementations.

Thank you for the information. =)

Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
> On 20.04.2024 um 18:07 Uhr Rich wrote:
>> DHCP is also not a "transport layer" protocol. Instead, it uses UDP
>> for its transport layer (see RFC url above, page 22):
>>
>> "DHCP uses UDP as its transport protocol."
>>
>> Since UDP is itself routable, DHCP is also routable, because DHCP is
>> simply a protocol definition for sending particular "messages"
>> inside of UDP packets.
>
> That depends on the addresses being used. When being used on
> non-directed broadcast, link-local unicast or link-local multicast,
> UDP can't be routed because the IP layer forbids routing of those
> packages.

Yes, correct. However, that is not "DHCP" the protocol itself
specifying such. That is the IP layer specifying that certian
addresses used in UDP packets are not routed.

The reason it impacts DHCP is that the "bootstrap an IP address
configuration" portion of DHCP means that those addresses are all the
client can make use of until after it has been configured with a valid
IP address for the local subnet.

The Natural Philosopher <tnp@invalid.invalid> wrote:
>The
>fact that someone calls that a 'relay agent' is as weird as saying a
>router is an IP 'relay agent'.

That is exactly correct terminology. You can have a router that is not
a DHCP relay agent, and you can have a DHCP relay agent not run on a
router.

>I am not really interested in a willy waving competiton with someone who
>knows the world always conforms to their conception of it, never the
>other way round.

Procotols usually don't have a conception, they have a specification.
And for DHCP, the specification is open for everyone to read. The
problem is that too many people want to talk about the protocol
without having read the specs.

--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Rich <rich@example.invalid> wrote:
> Marco Moock <mm+usenet-es@dorfdsl.de> wrote:
>> On 20.04.2024 um 18:07 Uhr Rich wrote:
>>> DHCP is also not a "transport layer" protocol. Instead, it uses UDP
>>> for its transport layer (see RFC url above, page 22):
>>>
>>> "DHCP uses UDP as its transport protocol."
>>>
>>> Since UDP is itself routable, DHCP is also routable, because DHCP is
>>> simply a protocol definition for sending particular "messages"
>>> inside of UDP packets.
>>
>> That depends on the addresses being used. When being used on
>> non-directed broadcast, link-local unicast or link-local multicast,
>> UDP can't be routed because the IP layer forbids routing of those
>> packages.
>
> Yes, correct. However, that is not "DHCP" the protocol itself
> specifying such. That is the IP layer specifying that certian
> addresses used in UDP packets are not routed.
>
> The reason it impacts DHCP is that the "bootstrap an IP address
> configuration" portion of DHCP means that those addresses are all the
> client can make use of until after it has been configured with a valid
> IP address for the local subnet.

Which, thinking about this just now, ironically, makes Lawrence's
statement correct.

DHCP the protocol is itself is not routable -- because DHCP the
protocol is not a transport layer protocol. It relies upon UDP for its
transport.

And whether a given DHCP message is routed or not is wholly dependent
upon whether the UDP packet carrying the DHCP message is itself
routable.

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>DHCP can provide node type and NBNS settings which influence if and when
>SMB broadcasts are sent.

Yes. And it can provide DNS and NTP servers, information about network
boot and tens of other things.

Greetings
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

The Natural Philosopher <tnp@invalid.invalid> wrote:
>A router *is* "a special tunnelling mechanism", not part of the actual
>protocol" for IP.

IP was designed to be a routable protocol from the very first second.

--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

On 4/20/24 13:58, D wrote:
> Yes, that makes perfect sense.

:-)

> Thank you for the information. =)

You're welcome.

--
Grant. . . .

On 4/20/24 14:21, Marc Haber wrote:
> Yes. And it can provide DNS and NTP servers, information about network
> boot and tens of other things.

I dare say that it can provide hundreds of other things.

I /think/ that the option is an 8-bit field and I've seen options near 200.

--
Grant. . . .

On 4/20/24 14:07, Rich wrote:
> Yes, correct. However, that is not "DHCP" the protocol itself
> specifying such. That is the IP layer specifying that certian
> addresses used in UDP packets are not routed.

Nit-pick: That's the IP layer saying that certain addresses can't be
routed. It doesn't matter what transport is on top of those IP packets.

> The reason it impacts DHCP is that the "bootstrap an IP address
> configuration" portion of DHCP means that those addresses are all
> the client can make use of until after it has been configured with
> a valid IP address for the local subnet.

Nit-pick: I believe I've read about DHCP implementations that remember
what they used last time and will start to use them instead of 0.0.0.0.
If that remembered IP fails / is rejected for some reason then it falls
back to a discover.

RFC 951 - Bootstrap Protocol - the precursor to DHCP - section 3
paragraph 2 says: "In the IP header of a bootrequest, the client fills
in its own IP source address if known, otherwise zero. When the server
address is unknown, the IP destination address will be the 'broadcast
address' 255.255.255.255."

So I'm not sure that a client /must/ use 0.0.0.0 -> 255.255.255.255 when
doing a BOOTP / DHCP request.

--
Grant. . . .

On 4/20/24 14:19, Rich wrote:
> DHCP the protocol is itself is not routable -- because DHCP the
> protocol is not a transport layer protocol. It relies upon UDP for
> its transport.

Given that logic, HTTP(S) and NNTP(S), both of which are dependent on
TCP, which is dependent on IP, aren't routable either.

> And whether a given DHCP message is routed or not is wholly dependent
> upon whether the UDP packet carrying the DHCP message is itself
> routable.

I believe you want to go another layer and say that the UDP datagram is
dependent on the IP packet carrying it. And the IP packet's routability
is dependent on it's source IP and if there is a route to the
destination IP or not.

}:-)

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
> On 4/20/24 14:19, Rich wrote:
>> DHCP the protocol is itself is not routable -- because DHCP the
>> protocol is not a transport layer protocol. It relies upon UDP for
>> its transport.
>
> Given that logic, HTTP(S) and NNTP(S), both of which are dependent on
> TCP, which is dependent on IP, aren't routable either.

In a way, yes, given that HTTP/NNTP are also not "transport layer
protocols". Their routability is determined by the routability of the
transport layer packet carrying them (which would be IP for both).

It is a somewhat atypical way of viewing the definition of "routing",
but it does match what is actually happening in routers. Exclusive of
"deep packet inspection" a router is routing packets by looking at the
IP header of that packet, not looking inside the IP packet's payload
for HTTP/NNTP/DHCP/etc. contents and routing based on those contents.

>> And whether a given DHCP message is routed or not is wholly dependent
>> upon whether the UDP packet carrying the DHCP message is itself
>> routable.
>
> I believe you want to go another layer and say that the UDP datagram
> is dependent on the IP packet carrying it. And the IP packet's
> routability is dependent on it's source IP and if there is a route to
> the destination IP or not.

True, that is actually where the "routing" decision is made.

On 20.04.2024 um 15:13 Uhr Grant Taylor wrote:

> On 4/20/24 14:07, Rich wrote:
> > Yes, correct. However, that is not "DHCP" the protocol itself
> > specifying such. That is the IP layer specifying that certian
> > addresses used in UDP packets are not routed.
>
> Nit-pick: That's the IP layer saying that certain addresses can't be
> routed. It doesn't matter what transport is on top of those IP
> packets.
>
> > The reason it impacts DHCP is that the "bootstrap an IP address
> > configuration" portion of DHCP means that those addresses are all
> > the client can make use of until after it has been configured with
> > a valid IP address for the local subnet.
>
> Nit-pick: I believe I've read about DHCP implementations that
> remember what they used last time and will start to use them instead
> of 0.0.0.0. If that remembered IP fails / is rejected for some reason
> then it falls back to a discover.
>
> RFC 951 - Bootstrap Protocol - the precursor to DHCP - section 3
> paragraph 2 says: "In the IP header of a bootrequest, the client
> fills in its own IP source address if known, otherwise zero. When
> the server address is unknown, the IP destination address will be the
> 'broadcast address' 255.255.255.255."
>
> So I'm not sure that a client /must/ use 0.0.0.0 -> 255.255.255.255
> when doing a BOOTP / DHCP request.

How can a DHCP client assume that a remembered address can be still
used?
If the lease is still valid, it can use it and contact the server via
unicast, if there is no valid lease, it must not use the IP anymore
because it could be assigned to some other node.

IIRC IP unicast src addr can only be used if the lease is still valid
and the client wants to extend the lease.
Of course asking the DHCP for additional information after the IP has
been assigned is another situation where unicast can be used.

Does anybody know other situations?

--
kind regards
Marco

Send spam to 1713618799muell@cartoonies.org

On 4/20/24 15:33, Marco Moock wrote:
> How can a DHCP client assume that a remembered address can be still
> used?

It can't assume.

But I believe that it can test for duplicate and ask the DHCP server via
DHCP Request.

> If the lease is still valid, it can use it and contact the server via
> unicast, if there is no valid lease, it must not use the IP anymore
> because it could be assigned to some other node.

I think it SHOULDN'T use would be the proper nomenclature.

> IIRC IP unicast src addr can only be used if the lease is still valid
> and the client wants to extend the lease.

Maybe.

> Of course asking the DHCP for additional information after the IP
> has been assigned is another situation where unicast can be used.

Yep.

> Does anybody know other situations?

I assume that a release would also be unicast.

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>On 4/20/24 14:21, Marc Haber wrote:
>> Yes. And it can provide DNS and NTP servers, information about network
>> boot and tens of other things.
>
>I dare say that it can provide hundreds of other things.
>
>I /think/ that the option is an 8-bit field and I've seen options near 200.

I was not sure how sparse the option number allocation is and too lazy
to look it up.

Greetings
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

On 20/04/2024 21:16, Grant Taylor wrote:
> On 4/20/24 14:19, Rich wrote:
>> DHCP the protocol is itself is not routable -- because DHCP the
>> protocol is not a transport layer protocol.  It relies upon UDP for
>> its transport.
>
> Given that logic, HTTP(S) and NNTP(S), both of which are dependent on
> TCP, which is dependent on IP, aren't routable either.
>
>> And whether a given DHCP message is routed or not is wholly dependent
>> upon whether the UDP packet carrying the DHCP message is itself routable.
>
> I believe you want to go another layer and say that the UDP datagram is
> dependent on the IP packet carrying it.  And the IP packet's routability
> is dependent on it's source IP and if there is a route to the
> destination IP or not.
>
> }:-)
>
Is a destination address of 255.255.255.255 routable?
Of course it is, if a router is configured to do an 'all stations
broadcast' across the internet!

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. When the
router receives a response it has to translate that back to the MAC
address of the sender on its local port.

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.

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.

The rest is semantics

--
"What do you think about Gay Marriage?"
"I don't."
"Don't what?"
"Think about Gay Marriage."

On 20/04/2024 21:31, Rich wrote:
> Exclusive of
> "deep packet inspection" a router is routing packets by looking at the
> IP header of that packet, not looking inside the IP packet's payload
> for HTTP/NNTP/DHCP/etc. contents and routing based on those contents.

Not at all true in the case of address translation, routing protocols,
traffic shaping and the like.

The only thing that caries is how *much* of the packet you inspect.

DHCP is similar in that the on;y thing a router has to do is determine
its a UDP broadcast, and if it is, work out where to send it, and what
return address to give it if any..

One would expect the router to simply spoof a MAC address on its
interface, and relay responses to that MAC address back to the client
network.
In short its acting like an ethernet switch or bridge

I am more curious as to how the DHCP server 'knows' which network
address to give the client, but not interested enough to look it up. :-)

--
Climate is what you expect but weather is what you get.
Mark Twain

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