Re: I never thought of this scenario

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