On 4/21/24 05:17, The Natural Philosopher wrote:
> Not at all true in the case of address translation, routing protocols,
> traffic shaping and the like.

Network address translation isn't routing. NAT happens /after/ routing
happens.

Routing protocols aren't routing. They exchange route information to
program routing tables. Routing uses said information to do the
routing. Routing protocols aren't required for routing. Manually
entered static routes work perfectly fine.

Traffic shaping isn't routing. It's altering how fast traffic is sent out.

Routing is deciding which interface to send the packet out and doing so.
Other things may be done before and / or after routing. But routing
is it's own independent thing.

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

Nope.

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

Nope.

> In short its acting like an ethernet switch or bridge

That's proxy ARP, which is a form of routing in it's own way.

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

See my most recent reply for a description of how DHCP relay agents
interact with DHCP clients and DHCP servers. Hint: It populates a
field in the DHCP packet, changes the source to be it's own unicast IP,
and changes the destination to be the remote DHCP server's unicast IP.

--
Grant. . . .

On 4/21/24 01:52, Marc Haber wrote:
> I was not sure how sparse the option number allocation is and too lazy
> to look it up.

There are a LOT of options specified. I think something like 150
commonly known. Though few of them are used.

You can even use DHCP as a quasi routing protocol in and of itself in
that it can provide routes (destination prefixes and gateways thereto)
via DHCP. I've done this and it works well. It's just not nearly as
dynamic as most dynamic routing protocols in that it only changes at
lease / renew time which could be hours / days. Conversely most dynamic
routing protocols update at least every few minutes.

--
Grant. . . .

The Natural Philosopher <tnp@invalid.invalid> wrote:
>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. :-)

That's because the DHCP relay agent does not simply "route" the
broadcast packet, it generates a new packet with the client message,
adds information about itself (such as, for example, the IP address of
the Interface where the DHCP broadcast was received on) and forwards
the resulting NEW message as routable unicast to the DHCP server.

--
----------------------------------------------------------------------------
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 21/04/2024 20:58, Grant Taylor wrote:
> On 4/21/24 05:17, The Natural Philosopher wrote:
>> Not at all true in the case of address translation, routing protocols,
>> traffic shaping and the like.
>
> Network address translation isn't routing.  NAT happens /after/ routing
> happens.
>
Routing itself *is* network address translation. The router removes the
current next hop address and replaces it with a new one, and it reduces
the TTL field. All NAT does is replace the *source* destination/port as
well, and store the originating port/ip address ready for return packets.

Where that happens in time is purely implementation dependent. It might
even happen simultaneously with a multicore CPU

Rest of semantic arguments about all the things a router does that are
not 'routing' according to one persons ideal definition of it, removed.

As an engineer all that a router does is modify some or all of the
information in a packet header, look up where the next hop is in its
routing tables, and receive dynamic updates to those routing tables
where appropriate. And forward the *modified* packet to the next hop.

If you want to take some academic position that defines some of those
modifications as routing and others as not, I cant stop you.

But I can avoid further argument

--
"The great thing about Glasgow is that if there's a nuclear attack it'll
look exactly the same afterwards."

Billy Connolly

On 22/04/2024 09:30, Marc Haber wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> 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. :-)
>
> That's because the DHCP relay agent does not simply "route" the
> broadcast packet, it generates a new packet with the client message,
> adds information about itself (such as, for example, the IP address of
> the Interface where the DHCP broadcast was received on) and forwards
> the resulting NEW message as routable unicast to the DHCP server.
>
I.e it does a bit of address translation, like NAT. It messes with the
return address as well as the destination addrress

--
How fortunate for governments that the people they administer don't think.

Adolf Hitler

Tell me, once you've argued it out - how many angels do dance on the
head of a pin?

The Natural Philosopher <tnp@invalid.invalid> wrote:
>On 21/04/2024 20:58, Grant Taylor wrote:
>> On 4/21/24 05:17, The Natural Philosopher wrote:
>>> Not at all true in the case of address translation, routing protocols,
>>> traffic shaping and the like.
>>
>> Network address translation isn't routing.  NAT happens /after/ routing
>> happens.
>>
>Routing itself *is* network address translation. The router removes the
>current next hop address and replaces it with a new one, and it reduces
>the TTL field.

The current next hop address is not part of the datagram.

You're obviously speaking a different language than the experts in the
field. It is not possible to have academic discourse with you.

I rest my case. End of Discussion 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 4/22/24 05:35, The Natural Philosopher wrote:
> Routing itself *is* network address translation.

Nope.

> The router removes the current next hop address and replaces it with
> a new one, and it reduces the TTL field.

Nope.

Run a sniffer on your Internet traffic and you will see that traffic is
being sent to the destination IP address of the remote server, not your
local router.

In the spirit of the benefit of doubt / nomenclature type problem, I
believe that you may be conflating what happens with MAC addresses and
what happens with IP addresses on Ethernet (or probably any 802 network).

Routing between Ethernet networks wholesale replaces the source and
destination MAC address of the Ethernet frame. But without NAT, the
source and destination IP address do not change.

> All NAT does is replace the *source* destination/port as well, and
> store the originating port/ip address ready for return packets.

Source NAT replaces the source IP and possibly, but no guarantee, the
source port.

Destination NAT replaces the destination IP and possibly, but no
guarantee, the destination port.

Most, but not all, SOHO routers do source NAT to replace the private
unrouted LAN IP with the public Internet IP of the SOHO router. But
that is a very special configuration.

All the routers at the ISP, the core of the Internet, and the server's
hosting provider don't modify either the source nor destination IP address.

> Where that happens in time  is purely implementation dependent. It might
> even happen simultaneously with a multicore CPU

There is a logical sequence of events. You have to choose where the IP
packet is going to go before you can do anything else to it as that
decision may influence what is done to it.

> As an engineer all  that a router does is modify some or all of the
> information in a packet header, look up where the next hop is in its
> routing tables, and receive dynamic updates to those routing tables
> where appropriate. And forward the *modified* packet to the next hop.

The IP packet isn't modified save for a TTL decremnt

The outgoing Ethernet frame is brand new and using different information
than the incoming Ethernet frame.

--
Grant. . . .

On Sat, 20 Apr 2024 08:12:31 +0200, Marc Haber wrote:

> Please get yourself familiarized with the protocol before you continue
> talking about it.

I already went through the protocol RFC elsewhere--go read my posting on
it.

On Sat, 20 Apr 2024 15:16:03 -0500, Grant Taylor wrote:

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

You said it, none of us rational people did.

On Sun, 21 Apr 2024 11:10:49 +0100, The Natural Philosopher wrote:

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

Not without these separate “relay agents”, as even those who try to keep
insisting that “DHCP is routable” have already admitted.

Routable protocols can make it through routers without the help of special
protocol-specific agents. Routers forward layer-3 packets, and whatever is
embedded within them is taken along for the ride, transparently.

But that requires a properly configured layer 3 in order to work. And that
is what DHCP provides. Therefore, since DHCP’s function is to set up layer
3 in the first place (without the requirement for individual node
configuration), it cannot rely on the existence of a fully-functioning
layer 3 to begin with. Therefore it cannot be routed. QED.

On Sat, 20 Apr 2024 08:18:57 +0200, Marc Haber wrote:

> You're reasoning is flawed.

I’m what reasoning is flawed??

Does not parse.

On Sat, 20 Apr 2024 13:26:15 +0100, The Natural Philosopher wrote:

> On 20/04/2024 01:24, Lawrence D'Oliveiro wrote:
>>
>> Thank you for admitting what some other parties still refuse to say.
>
> I habvent admitted anything .

Then you need to retract the incriminating phrase: “need to be told to
route DHCP *in some way*”. The fact that routers “need to be told” is what
makes it “special”. Routable protocols don’t need this “special
treatment”. Routers carry them as a matter of course.

So go on, deny that routers “need to be told” anything about DHCP in
particular.

> A router *is* "a special tunnelling mechanism", not part of the actual
> protocol" for IP. And its NOT tunnelling.

So a “special tunnelling mechanism” is NOT tunnelling? Keep on tying
yourself in knots ...

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sun, 21 Apr 2024 11:10:49 +0100, The Natural Philosopher wrote:
>
>> 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.
>
>Not without these separate “relay agents”, as even those who try to keep
>insisting that “DHCP is routable” have already admitted.

You should not only read what we explain, you should also at least try
to understand. Or, maybe, bother to read a packet trace.

>But that requires a properly configured layer 3 in order to work. And that
>is what DHCP provides. Therefore, since DHCP’s function is to set up layer
>3 in the first place (without the requirement for individual node
>configuration), it cannot rely on the existence of a fully-functioning
>layer 3 to begin with. Therefore it cannot be routed. QED.

Exercise: Outline how a host renews its lease.

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:
>On Sat, 20 Apr 2024 08:12:31 +0200, Marc Haber wrote:
>
>> Please get yourself familiarized with the protocol before you continue
>> talking about it.
>
>I already went through the protocol RFC elsewhere--go read my posting on
>it.

You still didnt understand how it works. Next step would be looking at
a packet trace.

--
----------------------------------------------------------------------------
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:
>On Sat, 20 Apr 2024 08:18:57 +0200, Marc Haber wrote:
>
>> You're reasoning is flawed.
>
>I’m what reasoning is flawed??
>
>Does not parse.

Biting on someone else's typos is a sure sign of running out of
factual arguments.

I am sure that, as a native speaker, you're able to understand what I
wanted to say while having my fingers type something different.

--
----------------------------------------------------------------------------
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:
>So a “special tunnelling mechanism” is NOT tunnelling? Keep on tying
>yourself in knots ...

Nothing that we are discussing in this thread is tunneling. DHCP needs
something that vaguely resembles an applicaiton level gateway in the
client's broadcast domain to forward the broadcast part of DHCP to the
server; the rest of the exchange is routed IP unicast.

I understand that it might be hard to comprehend that a protocol might
change its transport method in mid-exchange, but DHCP does that.

It took me a while to understand how a certain software distribution
software can work without interacting with the DHCP server, so I have
gone through the learning curve to grok DHCP myself, but it is time
that people educate themselves before this discussion can become
fruitful.

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

In <v07o1h$106h3$1@news1.tnib.de> Marc Haber:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

[Snip...]

> people educate themselves before this discussion can become fruitful

Indeed, but it's a troll. It's here for an argument, not info.

Classic Monty Python skit:

https://www.youtube.com/watch?v=uLlv_aZjHXc

HTH, YMMV, yadayada ...

--
Regards, Weird (Harold Stevens) * IMPORTANT EMAIL INFO FOLLOWS *
Pardon any bogus email addresses (wookie) in place for spambots.
Really, it's (wyrd) at att, dotted with net. * DO NOT SPAM IT. *
I toss GoogleGroup (http://twovoyagers.com/improve-usenet.org/).

On 23/04/2024 00:00, Grant Taylor wrote:
> There is a logical sequence of events.  You have to choose where the IP
> packet is going to go before you can do anything else to it as that
> decision may influence what is done to it.

Why?

--
"Socialist governments traditionally do make a financial mess. They
always run out of other people's money. It's quite a characteristic of them"

Margaret Thatcher

On Mon, 22 Apr 2024, Jim Jackson wrote:

>
> Tell me, once you've argued it out - how many angels do dance on the
> head of a pin?
>
>

Well, that's easy! 456.32!

On Tue, 23 Apr 2024, Marc Haber wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 20 Apr 2024 08:18:57 +0200, Marc Haber wrote:
>>
>>> You're reasoning is flawed.
>>
>> I’m what reasoning is flawed??
>>
>> Does not parse.
>
> Biting on someone else's typos is a sure sign of running out of
> factual arguments.
>
> I am sure that, as a native speaker, you're able to understand what I
> wanted to say while having my fingers type something different.
>
>

Sorry Lawrence but I have to go with Marc on this one. Your position is
starting to look very weak here.

Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>On Sun, 21 Apr 2024 11:10:49 +0100, The Natural Philosopher wrote:
>>
>>> 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.
>>
>>Not without these separate “relay agents”, as even those who try to keep
>>insisting that “DHCP is routable” have already admitted.
>
> You should not only read what we explain, you should also at least try
> to understand. Or, maybe, bother to read a packet trace.
>
>>But that requires a properly configured layer 3 in order to work. And that
>>is what DHCP provides. Therefore, since DHCP’s function is to set up layer
>>3 in the first place (without the requirement for individual node
>>configuration), it cannot rely on the existence of a fully-functioning
>>layer 3 to begin with. Therefore it cannot be routed. QED.
>
> Exercise: Outline how a host renews its lease.

Prediction: he will not do so.

Why?: Because doing so would pierce his carefully crafted bubble that
DHCP is only ever used to provide an IP address to a device which does
not yet have one, and so the UDP packets used for carrying those
initial DHCP messages from the client that provide that initial setup
have to use the link local broadcast IP address (which is itself what
is defined as non-routable for the IP layer).

If he were to pierce that bubble he'd have to admit his blanket
assertions of non-routability were wrong, and cognitive dissonance
won't let him do that.

D <nospam@example.net> wrote:
> [-- text/plain, encoding 8bit, charset: utf-8, 23 lines --]
>
>
>
> On Tue, 23 Apr 2024, Marc Haber wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Sat, 20 Apr 2024 08:18:57 +0200, Marc Haber wrote:
>>>
>>>> You're reasoning is flawed.
>>>
>>> I’m what reasoning is flawed??
>>>
>>> Does not parse.
>>
>> Biting on someone else's typos is a sure sign of running out of
>> factual arguments.
>>
>> I am sure that, as a native speaker, you're able to understand what I
>> wanted to say while having my fingers type something different.
>>
>>
>
> Sorry Lawrence but I have to go with Marc on this one. Your position is
> starting to look very weak here.

He's been lost from the beginning. DHCP the protocol is not itself
routable, because it is not a network layer protocol. DHCP messages
are carried in UDP packets, themselves carried in IP packets, and
whether a DHCP message is routable or not depends wholly on the
routability of the IP packet it resides within. If that IP packet uses
a routable address, then the DHCP message is routable. If it uses a
non-routable address (such as the network link broadcast address), the
then IP packet is not routable.

But routability depends only upon the address(s) used in the IP packet,
not whether the UDP datagram is carrying a DHCP message.

Lawrence has appeared to believe during this entire long thread that
the only use of DHCP is for initial IP setup (and it is possible this
is the only use he has ever seen and he may not know better, but if
true that indicates he has not understood the RFC he claims to have
read and relies on as his 'source').

But there is a whole other portion of DHCP that is used *after* the
initial IP address setup where the messages are fully routable because
the client now has an actual assigned IP address. But for some reason
Lawrence seems unaware of, or unwilling to understand, that there is
that part of the DHCP protocol that is carried in routable UDP/IP
packets.

Harold Stevens <wookie@aspen.localdomain> wrote:
> In <v07o1h$106h3$1@news1.tnib.de> Marc Haber:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
> [Snip...]
>
>> people educate themselves before this discussion can become fruitful
>
> Indeed, but it's a troll. It's here for an argument, not info.

+100

> Classic Monty Python skit:
>
> https://www.youtube.com/watch?v=uLlv_aZjHXc

Yep, that seems to be it to a T.

On Wed, 24 Apr 2024, Rich wrote:

> D <nospam@example.net> wrote:
>> [-- text/plain, encoding 8bit, charset: utf-8, 23 lines --]
>>
>>
>>
>> On Tue, 23 Apr 2024, Marc Haber wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> On Sat, 20 Apr 2024 08:18:57 +0200, Marc Haber wrote:
>>>>
>>>>> You're reasoning is flawed.
>>>>
>>>> I’m what reasoning is flawed??
>>>>
>>>> Does not parse.
>>>
>>> Biting on someone else's typos is a sure sign of running out of
>>> factual arguments.
>>>
>>> I am sure that, as a native speaker, you're able to understand what I
>>> wanted to say while having my fingers type something different.
>>>
>>>
>>
>> Sorry Lawrence but I have to go with Marc on this one. Your position is
>> starting to look very weak here.
>
> He's been lost from the beginning. DHCP the protocol is not itself
> routable, because it is not a network layer protocol. DHCP messages
> are carried in UDP packets, themselves carried in IP packets, and
> whether a DHCP message is routable or not depends wholly on the
> routability of the IP packet it resides within. If that IP packet uses
> a routable address, then the DHCP message is routable. If it uses a
> non-routable address (such as the network link broadcast address), the
> then IP packet is not routable.
>
> But routability depends only upon the address(s) used in the IP packet,
> not whether the UDP datagram is carrying a DHCP message.
>
> Lawrence has appeared to believe during this entire long thread that
> the only use of DHCP is for initial IP setup (and it is possible this
> is the only use he has ever seen and he may not know better, but if
> true that indicates he has not understood the RFC he claims to have
> read and relies on as his 'source').
>
> But there is a whole other portion of DHCP that is used *after* the
> initial IP address setup where the messages are fully routable because
> the client now has an actual assigned IP address. But for some reason
> Lawrence seems unaware of, or unwilling to understand, that there is
> that part of the DHCP protocol that is carried in routable UDP/IP
> packets.
>
>
I am humbled by the level of knowledge of some people in this group. =)