On Mon, 8 Apr 2024 18:37:53 -0500, Grant Taylor wrote:

> There are multiple types of networks that don't even support ARP.

Like DECnet? But then you had to have a fixed relationship between your
MAC address and your DECnet address.

So how would you run more than one ARP-less protocol stack on the same set
of machines?

Even humble AppleTalk, back in the day, had its own ARP. All the good
protocol stacks do.

On Mon, 8 Apr 2024 15:22:47 +0100, Andy Burns wrote:

> The oddest device I have doesn't actually respond to ARP requests,
> instead it continually sends out an ARP reply containing its own MAC and
> IP addrs.

That sounds very, um ... Novell Netware-ish, for some reason ...

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Mon, 8 Apr 2024 18:25:07 -0500, Grant Taylor wrote:
>> DHCP operates on top of UDP which operates on top of IP.
>
>It works specifically on 169.254 addresses,

No. Have you ever looked at a tcpdump output of a DHCP transaction?

>They are both non-routable. You might say that DHCP is technically layer
>3, but it is restricted to the domain of layer 2.

Broadcast domain.

Both protocols depend on broadcast. That's about the only thing they
have in common.

And they're both legacy protocols.

Btw, DHCPv6 and IPv6 Neighbor Discovery do have more in comon than
DHCPv4 and ARP. Both DHCPv6 and IPv6 operate based on ICMPv6.

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 4/8/24 22:56, Lawrence D'Oliveiro wrote:
> It works specifically on 169.254 addresses, because those are the only
> kind you can use without a proper IP configuration.

The DHCP protocol doesn't operate any differently for 169.254.0.0/16 vs
192.168.0.0/16 vs 203.0.113.0/24.

169.254.0.0/16 is actually not part of the DHCP protocol.
169.254.0.0/16 is an IPv4 network reserved for link-local addresses,
often called Automatic Private IP Addressing (APIPA). This is a
convention of DHCP /client/ implementations when the DHCP protocol fails
to successfully obtain a lease.

But the DHCP protocol operates the same independent of the prefix it's
being used for.

> They are both non-routable.

Nope. DHCP *IS* routable. When you use DHCP relay agents, they use the
DHCP protocol to talk to the DHCP server. They do so from known /
configured IP addresses and they are PERFECTLY HAPPY to send DHCP
requests through a routed IP network.

> You might say that DHCP is technically layer 3, but it is restricted
> to the domain of layer 2.

No it is not.

The 0.0.0.0 source IP address and 255.255.255.255 destination IP address
are what's supposed to be not routed. The DHCP protocol has no problem
using other IPs and is perfectly happy to be routed.

In fact, I believe that a DHCP client that used a DHCP relay helper to
obtain it's release originally is perfectly capable of communicating
with a remote DHCP server itself w/o the use of the helper.

DHCP uses the UDP protocol which uses the IP protocol and is routable.

I agree that DHCP is almost never routed. But lack of doing something
doesn't mean that it's not possible to do it.

--
Grant. . . .

On 4/8/24 22:54, Lawrence D'Oliveiro wrote:
> No it cannot. How is a client supposed to figure out how routing
> works to get to the DHCP server, if not from info it gets from the
> DHCP server?

DHCP helper receives the request from the client and passes it to the
DHCP server using the DHCP protocol across a routed network.

Subsequently, DHCP clients can renew their lease with the DHCP server
without the involvement of the DHCP relay.

You seem to be focusing on the most common use for DHCP. There are
other less common uses for DHCP that invalidate some of your statements.

--
Grant. . . .

On 4/8/24 23:00, Lawrence D'Oliveiro wrote:
> Like DECnet? But then you had to have a fixed relationship between your
> MAC address and your DECnet address.

Similar, but definitely not the same. DECnet addresses were directly
related to the MAC address. As in there was a direct algorithmic
mapping between them.

Conversely IP can use any MAC address it wants without any algorithmic
relationship.

Static is not the same as algorithmic.

Host1 = 192.0.2.1 = 06:00:00:00:00:01
Host2 = 192.0.2.2 = 06:00:00:00:00:02
Host3 = 192.0.2.1 = 06:00:00:00:00:03
Host4 = 192.0.2.2 = 06:00:00:00:00:04
Host5 = 192.0.2.1 = 06:00:00:00:00:05
Host6 = 192.0.2.2 = 06:00:00:00:00:06

Host1 & Host2 have each other's MAC addresses statically entered in
their ARP cache and can communicate with each other.

Host1: 192.0.2.2 = 06:00:00:00:00:02
Host2: 192.0.2.1 = 06:00:00:00:00:01

Host3 & Host4 have each other's MAC addresses statically entered in
their ARP cache and can communicate with each other.

Host3: 192.0.2.2 = 06:00:00:00:00:03
Host4: 192.0.2.1 = 06:00:00:00:00:04

Host1 & Host2 have each other's MAC addresses statically entered in
their ARP cache and can communicate with each other.

Host5: 192.0.2.2 = 06:00:00:00:00:05
Host6: 192.0.2.1 = 06:00:00:00:00:06

> So how would you run more than one ARP-less protocol stack on the same set
> of machines?

Remember what ARP's sole purpose is; figuring out the MAC address for an
IP address.

If you statically configure the MAC address for IP addresses, there is
no need for ARP.

> Even humble AppleTalk, back in the day, had its own ARP. All the good
> protocol stacks do.

IP over ATM didn't have ARP. Did you like using IPv4 in the '90s?
Many, if not most, smaller ISPs used IPv4 uplinks over ATM to larger
providers. ARP wasn't used.

Have you ever used IPv4 over PPP? It doesn't use ARP.

It's possible to use IPv4 on Ethernet on Linux without ARP. I can add a
route that uses an outgoing device instead of a remote IP and the need
for an ARP cache, be it dynamic or statically pre-configured.

Ethernet being used in a point-to-point configuration with a /31 doesn't
need ARP.

Ever hear of an "unnumbered" interface in Cisco parlance? That's
venerable IPv4 using a device route that doesn't use ARP.

ARP is needed in LANs ONLY when the remote MAC address is not known and
is needed. If you know the remote MAC address or don't need it (e.g.
device route) then ARP isn't needed.

--
Grant. . . .

On 4/8/24 23:01, Lawrence D'Oliveiro wrote:
> That sounds very, um ... Novell Netware-ish, for some reason ...

LOL We're talking TCP/IPv4, not IPX/SPX*.

It's actually called a Gratuitous ARP, or GARP for short. GARP is a
fairly common thing.

GARP works by populating the cache of systems that will want to talk to
the system sending the GARP. This works because systems that would send
to a GARP sender will see the GARP announcement that ${IP} is at ${MAC}
and will (usually, but not always) update their local ARP cache.

A white hat use for GARP is when an IP address fails over from one
router to another router using something like VRRP or HSRP. (I don't
know if CARP uses GARP or not.)

A black hat use for GARP is for something like FireSheep and WiFi Pineapple.

There are LOTS of things that you can do with ARP.

Interestingly enough, almost none of them work when you use static ARP
entries. }:-) -- I don't care how many times you tell me that you are
192.0.2.1 at MAC address 06:00:00:00:06:66 when I happen to know for a
fact -- because I've been statically configured -- that 192.0.2.1 is at
06:00:00:00:00:01. Also, the fact that you keep trying to tell me that
you're someone I know that you aren't, is a really big indicator of
compromise. Don't forget that the GARP that you are sending to try to
hook someone is being heard by all network intrusion sensors on the LAN
segment. }:-)

*Yes, I know that NetWare 3.x onward can use TCP/IP, but it didn't
default to do so until version 5.x.

--
Grant. . . .

On Mon, 8 Apr 2024 23:27:28 -0500, Grant Taylor wrote:

> When you use DHCP relay agents, they use the
> DHCP protocol to talk to the DHCP server.

If DHCP were routable, you wouldn’t need “relay agents”.

On 2024-04-09 01:30, Grant Taylor wrote:
> On 4/8/24 03:19, The Natural Philosopher wrote:
>> "With conflict detection enabled, the DHCP Server will ping the IP
>> address it wants to grant a lease for to make sure no other computers
>> are using that IP address. If the ping request receives a reply, the
>> server will mark the IP as BAD_ADDRESS. If no response is received,
>> the server will assign the IP address to the requesting client...."
>
> This usually works well enough.  But it breaks down when the system
> using the IP the DHCP server is ping testing refuses to send echo reply
> responses to the ping.

If that happens, they deserve the breakage that will happen :-P

--
Cheers, Carlos.

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>Nope. DHCP *IS* routable. When you use DHCP relay agents, they use the
>DHCP protocol to talk to the DHCP server. They do so from known /
>configured IP addresses and they are PERFECTLY HAPPY to send DHCP
>requests through a routed IP network.

Although a DHCP relay agent is something like an application level
gateway. It is true that the communication between the relay agent and
the actual server MAY be Unicast, and is thus routable; the
communication between DHCP client and relay agent relies on broadcast
being available.

>In fact, I believe that a DHCP client that used a DHCP relay helper to
>obtain it's release originally is perfectly capable of communicating
>with a remote DHCP server itself w/o the use of the helper.

DHCPDISCOVER is broadcast and needs a relay agent if the server is not
in the same broadcast domain. I am not sure wether the DHCPREQUEST
that a client uses to renew its lease (even when it's just rebooting)
is broadcast or not, I would not be surprised if it was.

>I agree that DHCP is almost never routed. But lack of doing something
>doesn't mean that it's not possible to do it.

I think that in realistic deployments, the communiation between relay
agent and server is probably almost always routed.

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

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>If DHCP were routable, you wouldn’t need “relay agents”.

DHCP is obviously a more complex protocol than you think it is.

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 09/04/2024 12:30, Carlos E.R. wrote:
> On 2024-04-09 01:30, Grant Taylor wrote:
>> On 4/8/24 03:19, The Natural Philosopher wrote:
>>> "With conflict detection enabled, the DHCP Server will ping the IP
>>> address it wants to grant a lease for to make sure no other computers
>>> are using that IP address. If the ping request receives a reply, the
>>> server will mark the IP as BAD_ADDRESS. If no response is received,
>>> the server will assign the IP address to the requesting client...."
>>
>> This usually works well enough.  But it breaks down when the system
>> using the IP the DHCP server is ping testing refuses to send echo
>> reply responses to the ping.
>
> If that happens, they deserve the breakage that will happen :-P
>
If the client does an ARP and gets a clash, then it should refuse the
DHCP offer.
I am not sure if the server issues an alternative or not.

--
"Fanaticism consists in redoubling your effort when you have
forgotten your aim."

George Santayana

On 09/04/2024 04:54, Lawrence D'Oliveiro wrote:
> On Mon, 8 Apr 2024 09:19:24 +0100, The Natural Philosopher wrote:
>
>> Apparently the use of ping is preferred because a DHCP server *can*
>> operate across various routed subdomains.
>
> No it cannot. How is a client supposed to figure out how routing works to
> get to the DHCP server, if not from info it gets from the DHCP server?

Broadcast

If you route broadcasts then all things are possible

--
WOKE is an acronym... Without Originality, Knowledge or Education.

On 4/9/24 06:53, Marc Haber wrote:
> DHCP is obviously a more complex protocol than you think it is.
+2

--
Grant. . . .

On 4/9/24 04:33, Lawrence D'Oliveiro wrote:
> If DHCP were routable, you wouldn’t need “relay agents”.

DHCP is routable.

Not all uses of DHCP are routable.

There is a big difference.

--
Grant. . . .

On Tue, 09 Apr 2024 13:53:16 +0200, Marc Haber wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>>If DHCP were routable, you wouldn’t need “relay agents”.
>
> DHCP is obviously a more complex protocol than you think it is.

Regardless of passive-aggressive innuendo hints to try to distract from
the discussion at hand, the mere fact that a separate component called
“relay agents” needs to be mentioned when I talk about “routability”
proves my point.

On Tue, 9 Apr 2024 18:36:03 -0500, Grant Taylor wrote:

> On 4/9/24 04:33, Lawrence D'Oliveiro wrote:
>
>> If DHCP were routable, you wouldn’t need “relay agents”.
>
> DHCP is routable.
>
> Not all uses of DHCP are routable.

What is the point of adding something to make those non-routable uses
routable, if the protocol is already supposed to be routable?

On 10.4.2024 10.05, Lawrence D'Oliveiro wrote:
> On Tue, 9 Apr 2024 18:36:03 -0500, Grant Taylor wrote:
>
>> On 4/9/24 04:33, Lawrence D'Oliveiro wrote:
>>
>>> If DHCP were routable, you wouldn’t need “relay agents”.
>>
>> DHCP is routable.
>>
>> Not all uses of DHCP are routable.
>
> What is the point of adding something to make those non-routable uses
> routable, if the protocol is already supposed to be routable?

This discussion is in a loop. To break out, get RFC2131 and read it.
There are plenty of later extensions, findable easily with e.g. Google.

--

-TV

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Tue, 9 Apr 2024 18:36:03 -0500, Grant Taylor wrote:
>
>> On 4/9/24 04:33, Lawrence D'Oliveiro wrote:
>>
>>> If DHCP were routable, you wouldn’t need “relay agents”.
>>
>> DHCP is routable.
>>
>> Not all uses of DHCP are routable.
>
>What is the point of adding something to make those non-routable uses
>routable, if the protocol is already supposed to be routable?

The purpose of DHCP is to bring a new device in the posession of an IP
address, which is necessary to use IP beyond the local broadcast
domain.

Having used DHCP for about 30 years now, and not being a native
speaker of English, I'm having a hard time to explain that on a novice
level. I apologize for that.

What Grant says in <uv4jd3$mj2$2@tncsrv09.home.tnetconsulting.net> is
probably the best explanation of the thing in this thread.

EOD now from my part.

--
----------------------------------------------------------------------------
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 Wed, 10 Apr 2024, Tauno Voipio wrote:

> On 10.4.2024 10.05, Lawrence D'Oliveiro wrote:
>> On Tue, 9 Apr 2024 18:36:03 -0500, Grant Taylor wrote:
>>
>>> On 4/9/24 04:33, Lawrence D'Oliveiro wrote:
>>>
>>>> If DHCP were routable, you wouldn’t need “relay agents”.
>>>
>>> DHCP is routable.
>>>
>>> Not all uses of DHCP are routable.
>>
>> What is the point of adding something to make those non-routable uses
>> routable, if the protocol is already supposed to be routable?
>
>
> This discussion is in a loop. To break out, get RFC2131 and read it.
> There are plenty of later extensions, findable easily with e.g. Google.

Note that a loop in this context, in itself, is not necessarily a bad
thing. It could very well be that the participants enjoy the loop and the
rush of pleasant emotions due to being right until the next message
arrives. In that context, the RFC would be counter productive to the
beautiful dance they are engaged in.

On 4/10/24 02:05, Lawrence D'Oliveiro wrote:
> What is the point of adding something to make those non-routable uses
> routable, if the protocol is already supposed to be routable?

What is the point of handing someone a microphone in conference so that
others further away can hear them? Does handing them a microphone
change what they are saying?

The purpose of DHCP relay / helper agents is to take the DHCP packet
which is using non-routable source (0.0.0.0) and destination
(255.255.255.255.) and send send / proxy them to the DHCP server using
routable source (relay) and destination (remote DHCP server).

The only other modification that I'm aware that a DHCP relay / helper
does is add an additional field to identify the the relay / helper and
the source client's MAC address in the outgoing DHCP packet. The rest
of the contents of the DHCP packet is substantively unmodified.

What's more is that the DHCP packet format (the unit the protocol speaks
in) is the same for both use cases, client <-> relay as well as relay
<-> server.

If a child picks up a basket of toys but can't reach the shelf, does the
basket of toys change when an adult takes the basket and places it on
the shelf for the child? Does adding the child's name to the front of
the basket alter the basket contents? No, and no, tt is still the same
basket of toys.

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> wrote:
>The only other modification that I'm aware that a DHCP relay / helper
>does is add an additional field to identify the the relay / helper and
>the source client's MAC address in the outgoing DHCP packet. The rest
>of the contents of the DHCP packet is substantively unmodified.

The server needs information about the client, to reassign its old
lease or to hand out its reserved IP address, and in which LAN segment
the booting client is connected to choose the correct pool. Yes.

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 Wed, 10 Apr 2024 09:07:33 -0500, Grant Taylor wrote:

> What is the point of handing someone a microphone in conference so that
> others further away can hear them?

It’s certainly not an IQ booster, that’s for sure.

-1 for spurious argument by analogy.

On Wed, 10 Apr 2024 10:28:55 +0300, Tauno Voipio wrote:

> To break out, get RFC2131 and read it.

Here we go <https://datatracker.ietf.org/doc/html/rfc2131>:

* Client sends out DHCPDISCOVER. The only IP address involved is the
local-net broadcast address, 255.255.255.255, which is non-routable.
* Server responds with DHCPOFFER. Since there is no IP address it can
route this response to, it, too, is non-routable.
* The client may send out ARP broadcasts to ensure nobody else has already
claimed the offered address.
* The client accepts an offered address with DHCPREQUEST, which, again, is
sent to the (non-routable) broadcast address.
* The server responds with DHCPACK or DHCPNAK.

Remember, the client’s IP stack can not be considered to be fully
operational until after all these steps have been completed.

On 4/12/24 18:57, Lawrence D'Oliveiro wrote:
> Remember, the client’s IP stack can not be considered to be fully
> operational until after all these steps have been completed.

So what.

What you just described is what I said about using 0.0.0.0 and
255.255.255.255 and the fact that those addresses are not routable.

There are other aspects of DHCP that are routable. Like a DHCP helper /
relay agent using the DHCP protocol to communicate with a remote DHCP
server, or when clients use the IP they previously received via a DHCP
helper / relay agent to communicate directly with said remote DHCP server.

How the DHCP protocol is being used doesn't mean that the DHCP protocol
is unroutable. Especially when the same DHCP protocol is used in a
routed manner other times.

--
Grant. . . .