I then restarted a piece of kit I am working on, and it popped up in the first available DHCP slot.
My question is, if that had already been occupied by another piece of
kit, would I have ended up with an IP address clash?
I decided on a quiet breezy Sunday morning, to upgrade my routersThis would not happen. I believe that the DHCP server process does something like an "arp" before it assigns leaases. Also, anything with an "old" (pre-reboot) lease would eventually ask for a lease renewal sooner or later
firmware. Which required a router reboot.
So it lost all its DHCP tables.
However apart from 10 seconds of internet outage, the rest of the
network carried on nicely (nothing uses the router's wifi, as it's in a remote space).
I then restarted a piece of kit I am working on, and it popped up in the first available DHCP slot.
My question is, if that had already been occupied by another piece of
kit, would I have ended up with an IP address clash?
It seems to me that checking for conflicts only happens at lease start
or lease renewal times?
Or does that imply that the router did check the ip address first before allocating the IP?
My question is, if that had already been occupied by another piece ofThis would not happen. I believe that the DHCP server process does something like an "arp" before it assigns leaases.
kit, would I have ended up with an IP address clash?
(pre-reboot) lease would eventually ask for a lease renewal sooner or later (eg when the lease runs out). It would ask for its existing IP address and the
router would likely grant that and create an entry int its lease table.
So, even if the router does not have any persistant lease data (eg saved across reboots), the data would eventually be re-created is pretty shourt order. I suspect the lease time for most od these little routersis fairly should (an hour?),
so the problem you fear is a non-problem.
On 07/04/2024 12:37, Robert Heller wrote:Which is not the *router's* problem, but a mis-configuration problem with the Pi Picos...
My question is, if that had already been occupied by another piece ofThis would not happen. I believe that the DHCP server process does something
kit, would I have ended up with an IP address clash?
like an "arp" before it assigns leaases.
I think it may in fact do a *ping*. In fact this led me to the
realisation that none of my Raspberry PI PICO W widgets were responding
to pings...another 2 hours of my life working out why...:-)
"To prevent a newly allocated IP address conflicting with existing IP addresses, the DHCP server sends an ICMP Echo Request packet before
sending a DHCP Offer message. This ICMP packet contains the IP address
to be allocated in both the source and destination IP address fields.
The server can allocate the IP address if it receives no ICMP Echo Reply packet within the detection period (no client is using this IP address).
If the server receives an ICMP Echo Reply packet within the detection
period, the DHCP server lists this IP address as a conflicting IP
address (as it is in use by another client), and then waits for the next
DHCP Discover message to start the IP address selection process again."
https://support.huawei.com/enterprise/en/doc/EDOC1100126920/5cef90ad/how-a-dhcp-server-allocates-network-parameters-to-new-dhcp-clients
>Also, anything with an "old"
(pre-reboot) lease would eventually ask for a lease renewal sooner or later (eg when the lease runs out). It would ask for its existing IP address and the
router would likely grant that and create an entry int its lease table.
yes.
So, even if the router does not have any persistant lease data (eg saved across reboots), the data would eventually be re-created is pretty shourt order. I suspect the lease time for most od these little routersis fairly should (an hour?),
24 hours...
so the problem you fear is a non-problem.
It was a potential problem when my Pi Picos didnt respond to pings
I decided on a quiet breezy Sunday morning, to upgrade my routers
firmware. Which required a router reboot.
So it lost all its DHCP tables.
I then restarted a piece of kit I am working on, and it popped up in
the first available DHCP slot.
My question is, if that had already been occupied by another piece of
kit, would I have ended up with an IP address clash?
It seems to me that checking for conflicts only happens at lease
start or lease renewal times?
On 07/04/2024 12:37, Robert Heller wrote:
I believe that the DHCP server process does
something like an "arp" before it assigns leaases.
I think it may in fact do a *ping*.
You want it to do an ARP, not a ping. Ping is routable, ARP is not.
On 4/7/24 18:53, Lawrence D'Oliveiro wrote:
You want it to do an ARP, not a ping. Ping is routable, ARP is not.
What is the down side of ping being routable ...
You wouldn’t expect it to be routed.
Nevertheless, better to use a protocol that can never be routed.
There are ways to route ARP. }:-)
You are thinking of proxy ARP, perhaps?
I was thinking more along the lines of bridged routing (brouting) and /
or tunnels.
OpenFlow can really break traditional networking paradigms.
At Sun, 7 Apr 2024 13:24:28 +0100 The Natural Philosopher <tnp@invalid.invalid> wrote:
On 07/04/2024 12:37, Robert Heller wrote:
My question is, if that had already been occupied by another piece ofThis would not happen. I believe that the DHCP server process does something
kit, would I have ended up with an IP address clash?
like an "arp" before it assigns leaases.
I think it may in fact do a *ping*. In fact this led me to the
realisation that none of my Raspberry PI PICO W widgets were responding
to pings...another 2 hours of my life working out why...:-)
"To prevent a newly allocated IP address conflicting with existing IP
addresses, the DHCP server sends an ICMP Echo Request packet before
sending a DHCP Offer message. This ICMP packet contains the IP address
to be allocated in both the source and destination IP address fields.
The server can allocate the IP address if it receives no ICMP Echo Reply
packet within the detection period (no client is using this IP address).
If the server receives an ICMP Echo Reply packet within the detection
period, the DHCP server lists this IP address as a conflicting IP
address (as it is in use by another client), and then waits for the next
DHCP Discover message to start the IP address selection process again."
https://support.huawei.com/enterprise/en/doc/EDOC1100126920/5cef90ad/how-a-dhcp-server-allocates-network-parameters-to-new-dhcp-clients
>Also, anything with an "old"
(pre-reboot) lease would eventually ask for a lease renewal sooner or later >>> (eg when the lease runs out). It would ask for its existing IP address and theyes.
router would likely grant that and create an entry int its lease table.
So, even if the router does not have any persistant lease data (eg saved >>> across reboots), the data would eventually be re-created is pretty shourt >>> order. I suspect the lease time for most od these little routersis fairly >>> should (an hour?),
24 hours...
so the problem you fear is a non-problem.
It was a potential problem when my Pi Picos didnt respond to pings
Which is not the *router's* problem, but a mis-configuration problem with the Pi Picos...
On Sun, 7 Apr 2024 13:24:28 +0100, The Natural Philosopher wrote:What I want to do is not in question, What is (apparently) generally
On 07/04/2024 12:37, Robert Heller wrote:
I believe that the DHCP server process does
something like an "arp" before it assigns leaases.
I think it may in fact do a *ping*.
You want it to do an ARP, not a ping. Ping is routable, ARP is not.
On 08/04/2024 00:53, Lawrence D'Oliveiro wrote:
On Sun, 7 Apr 2024 13:24:28 +0100, The Natural Philosopher wrote:What I want to do is not in question, What is (apparently) generally accepted practice, is.
On 07/04/2024 12:37, Robert Heller wrote:
I believe that the DHCP server process does
something like an "arp" before it assigns leaases.
I think it may in fact do a *ping*.
You want it to do an ARP, not a ping. Ping is routable, ARP is not.
On Sun, 7 Apr 2024 13:24:28 +0100, The Natural Philosopher wrote:
On 07/04/2024 12:37, Robert Heller wrote:
I believe that the DHCP server process does
something like an "arp" before it assigns leaases.
I think it may in fact do a *ping*.
You want it to do an ARP, not a ping. Ping is routable, ARP is not.
The Natural Philosopher wrote:
I think it may in fact do a *ping*.
You want it to do an ARP, not a ping. Ping is routable, ARP is not.
Tunnels/SDN are irrelevant, because they happen at a lower level that
is transparent to the level we are talking about (virtual layer 2).
Remember, we were talking about DHCP, and ARP operates at the same level.
"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...."
(The DHCP client probes the IP address by sending gratuitous ARP
packets)
Apparently the use of ping is preferred because a DHCP server can
operate across various routed subdomains.
Actually, you want the query to be routed in this scenario. You do not
want any machine in the entire network to have the same IP, no matter
how far it is.
ping is blockable, ARP is not.
(if you want a functioning IP stack)
Apparently the use of ping is preferred because a DHCP server *can*
operate across various routed subdomains.
DHCP operates on top of UDP which operates on top of IP.
ARP operates on the same level as and /beside/ IP.
You do not want any machine in the entire network to have the same IP,
no matter how far it is.
There are multiple types of networks that don't even support ARP.
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.
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,
They are both non-routable. You might say that DHCP is technically layer
3, but it is restricted to the domain of layer 2.
It works specifically on 169.254 addresses, because those are the only
kind you can use without a proper IP configuration.
They are both non-routable.
You might say that DHCP is technically layer 3, but it is restricted
to the domain of layer 2.
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?
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.
That sounds very, um ... Novell Netware-ish, for some reason ...
When you use DHCP relay agents, they use the
DHCP protocol to talk to the DHCP server.
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.
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.
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.
I agree that DHCP is almost never routed. But lack of doing something >doesn't mean that it's not possible to do it.
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
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?
DHCP is obviously a more complex protocol than you think it is.+2
If DHCP were routable, you wouldn’t need “relay agents”.
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.
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.
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 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.
What is the point of adding something to make those non-routable uses routable, if the protocol is already supposed to be routable?
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 is the point of handing someone a microphone in conference so that others further away can hear them?
To break out, get RFC2131 and read it.
Remember, the client’s IP stack can not be considered to be fully operational until after all these steps have been completed.
... using the DHCP protocol across a routed network.
Broadcast
If you route broadcasts then all things are possible
I am not sure if the server issues an alternative or not.
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 ...
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.
As in there was a direct algorithmic mapping between them.
It's actually called a Gratuitous ARP, or GARP for short. GARP is a
fairly common thing.
The broadcast used in DHCP is 255.255.255.255, which is by definition not routable.
So how would you run two simultaneous protocol stacks, each requiring its
own “algorithmic mapping” between MAC address and layer-3 address?
DHCP is not routable, otherwise it wouldn’t need a helper to route it.
On Fri, 12 Apr 2024 20:22:33 -0500, Grant Taylor wrote:
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 ...
DHCP is not routable, otherwise it wouldn’t need a helper to route it.
On Tue, 9 Apr 2024 14:01:45 +0100, The Natural Philosopher wrote:
Broadcast
If you route broadcasts then all things are possible
The broadcast used in DHCP is 255.255.255.255, which is by definition not routable.
On 13/04/2024 04:26, Lawrence D'Oliveiro wrote:
The broadcast used in DHCP is 255.255.255.255, which is by definition
not routable.
It is routable.
It's an 'all stations' broadcast.
On 4/12/24 22:26, Lawrence D'Oliveiro wrote:
The broadcast used in DHCP is 255.255.255.255, which is by definition
not routable.
That's not the only (destination) address that DHCP uses.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
DHCP is not routable, otherwise it wouldn’t need a helper to route it.
Repeating this doesnt make it right.
I was referring to the MAC address DECnet uses and the DECnet address.
There is an algorithmic relation ship between the MAC address a DECnet station uses and it's DECnet address.
Notice how the client sends a DHCP renew request to the DHCP server, not
the DHCP relay agent. It does this across a routed network.
The only reason the relay agent is needed is because DHCP itself is not routable.
It can’t use any other, because remember, the client doesn’t have an address that anybody can use, at this point.
On Sat, 13 Apr 2024 09:39:27 +0200, Marc Haber wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
DHCP is not routable, otherwise it wouldn’t need a helper to route it.
Repeating this doesnt make it right.
I went through the details of RFC2131 in another posting. Go read it (the RFC and my posting).
Therefore the RFC explicitly allows for DHCP to be routed.
On Sat, 13 Apr 2024 00:40:12 -0500, Grant Taylor wrote:
On 4/12/24 22:26, Lawrence D'Oliveiro wrote:
The broadcast used in DHCP is 255.255.255.255, which is by definition
not routable.
That's not the only (destination) address that DHCP uses.
It can’t use any other, because remember, the client doesn’t have an >address that anybody can use, at this point.
On Sat, 13 Apr 2024 09:04:55 +0100, The Natural Philosopher wrote:
On 13/04/2024 04:26, Lawrence D'Oliveiro wrote:
The broadcast used in DHCP is 255.255.255.255, which is by definition
not routable.
It is routable.
It's an 'all stations' broadcast.
You need to go read some basic TCP/IP docs. Would you like me to point you at some?
Why does it get called "TCP/IP" so often? What is the origin of
that name?
These are two different protocols for different layers and that name
does not include, say, UDP.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
I went through the details of RFC2131 in another posting. Go read it
(the RFC and my posting).
And, yet, you seem to have missed this statement from the RFC:
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.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 13 Apr 2024 00:40:12 -0500, Grant Taylor wrote:
On 4/12/24 22:26, Lawrence D'Oliveiro wrote:
The broadcast used in DHCP is 255.255.255.255, which is by definition
not routable.
That's not the only (destination) address that DHCP uses.
It can’t use any other, because remember, the client doesn’t have an >>address that anybody can use, at this point.
"This point" being the start of the protocol. You should look beyond
the initial exchange.
The DHCP agent is needed ...
And DHCP is routable ...
.. when a DHCP client /renews/ it's lease,
it has a valid IP address and can use that to talk to the DHCP server on
a remote subnet using standard DHCP protocol.
On Mon, 15 Apr 2024 08:01:12 +0200, Marc Haber wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sat, 13 Apr 2024 00:40:12 -0500, Grant Taylor wrote:
On 4/12/24 22:26, Lawrence D'Oliveiro wrote:
The broadcast used in DHCP is 255.255.255.255, which is by definition >>>>> not routable.
That's not the only (destination) address that DHCP uses.
It can’t use any other, because remember, the client doesn’t have an >>>address that anybody can use, at this point.
"This point" being the start of the protocol. You should look beyond
the initial exchange.
Once the protocol has done its thing, the client can do routable things.
At that point, it can stop worrying about DHCP for now.
At that point, it can stop worrying about DHCP for now.
On Sun, 14 Apr 2024 20:13:58 -0500, Grant Taylor wrote:
The DHCP agent is needed ...
And DHCP is routable ...
Routable protocols get through routers without the help of special >“agents”.
On Sun, 14 Apr 2024 20:15:32 -0500, Grant Taylor wrote:
.. when a DHCP client /renews/ it's lease,
it has a valid IP address and can use that to talk to the DHCP server on
a remote subnet using standard DHCP protocol.
Why would it need to? The DHCP server is on the same subnet, otherwise the >client could not have got that address in the first place.
On Sun, 14 Apr 2024 20:15:32 -0500, Grant Taylor wrote:Sigh. Simply not true.
.. when a DHCP client /renews/ it's lease,
it has a valid IP address and can use that to talk to the DHCP server on
a remote subnet using standard DHCP protocol.
Why would it need to? The DHCP server is on the same subnet, otherwise the client could not have got that address in the first place.
The fact that YOUR DHCP server is on the same subnet of your
residential one-subnet setup does NOT mean that this is the case for
all DHCP deployments.
DHCP servers can serve multiple local subnets
The key is that the routers between each subnet and the DHCP machine
need to be told to route DHCP in some way.
On 4/19/24 00:26, Marc Haber wrote:
The fact that YOUR DHCP server is on the same subnet of your
residential one-subnet setup does NOT mean that this is the case for
all DHCP deployments.
I absolutely agree. Though it is proportionally probably one of the
most common configurations. Considering all of the SOHO networks in the world.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 14 Apr 2024 20:13:58 -0500, Grant Taylor wrote:
The DHCP agent is needed ...
And DHCP is routable ...
Routable protocols get through routers without the help of special >>“agents”.
The unicast part¹ of DHCP gets through a router just fine without agent.
¹ which is about 80 % of the protocol
You don't know enough about DHCP to be a member of a fruitful discussion about that protocol.
The key is that the routers between each subnet and the DHCP machine
need to be told to route DHCP *in some way*.
On Fri, 19 Apr 2024 07:23:27 +0200, Marc Haber wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 14 Apr 2024 20:13:58 -0500, Grant Taylor wrote:
The DHCP agent is needed ...
And DHCP is routable ...
Routable protocols get through routers without the help of special >>>“agents”.
The unicast part¹ of DHCP gets through a router just fine without agent.
Get through to what? What is there on the other side of a router, that didn’t need to be involved in the rest of the exchange?
¹ which is about 80 % of the protocol
Ah, I see now: you are all really talking about this “80% DHCP” or “discount DHCP” or “20%-off DHCP”, aren’t you. While the rest of us were
talking about “proper DHCP” or “fully-implemented DHCP” or “DHCP according
to the spec”.
On Fri, 19 Apr 2024 10:47:44 +0100, The Natural Philosopher wrote:
The key is that the routers between each subnet and the DHCP machine
need to be told to route DHCP *in some way*.
Finally, an admission that routability is something that has to be added
via a special tunnelling mechanism, it is not part of the actual protocol.
Thank you for admitting what some other parties still refuse to say.
On Fri, 19 Apr 2024 07:26:05 +0200, Marc Haber wrote:
You don't know enough about DHCP to be a member of a fruitful discussion
about that protocol.
I have already referred to the actual spec, you have not. So I think that criticism applies more to you than me.
On Fri, 19 Apr 2024 07:23:27 +0200, Marc Haber wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 14 Apr 2024 20:13:58 -0500, Grant Taylor wrote:
The DHCP agent is needed ...
And DHCP is routable ...
Routable protocols get through routers without the help of special >>>“agents”.
The unicast part¹ of DHCP gets through a router just fine without agent.
Get through to what? What is there on the other side of a router, that >didn’t need to be involved in the rest of the exchange?
On Fri, 19 Apr 2024 07:26:05 +0200, Marc Haber wrote:
You don't know enough about DHCP to be a member of a fruitful discussion
about that protocol.
I have already referred to the actual spec, you have not.
So I think that
criticism applies more to you than me.
On 4/19/24 04:47, The Natural Philosopher wrote:
DHCP servers can serve multiple local subnets
Yes, DHCP servers can easily server multiple /locally/ /attached/
subnets. As in multiple physical interfaces and / or multiple logical
VLAN interfaces. Wherein the DHCP server is in the same broadcast
domain as the DHCP client.
The key is that the routers between each subnet and the DHCP machine
need to be told to route DHCP in some way.
I would consider those to be remote subnets as they are not /locally/ >/attached/ to the DHCP server. Meaning the DHCP server is not directly >participating in the broadcast domain.
DHCP servers can easily serve multiple /remote/ subnets.
Being in the layer 2 broadcast domain means that everybody smells it
when somebody farts for a browse maser election on the other side of the >room.
On Fri, 19 Apr 2024 10:47:44 +0100, The Natural Philosopher wrote:
The key is that the routers between each subnet and the DHCP machine
need to be told to route DHCP *in some way*.
Finally, an admission that routability is something that has to be added
via a special tunnelling mechanism, it is not part of the actual protocol.
Thank you for admitting what some other parties still refuse to say.
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.
Therefore the RFC explicitly allows for DHCP to be routed.
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Fri, 19 Apr 2024 07:26:05 +0200, Marc Haber wrote:
You don't know enough about DHCP to be a member of a fruitful discussion >>> about that protocol.
I have already referred to the actual spec, you have not. So I think that
criticism applies more to you than me.
Plural posters on the group here assert that DHCP is routable.
You, alone, assert, that it is not.
I have supplied an actual quote *from RFC2131* that states that DHCP
*must work across routers* (i.e., that it "be routable").
Please supply any quote from RFC2131, or any other RFC, that supports
your assertion.
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.
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? 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?
On Fri, 19 Apr 2024 10:47:44 +0100, The Natural Philosopher wrote:
The key is that the routers between each subnet and the DHCP machine
need to be told to route DHCP *in some way*.
Finally, an admission that routability is something that has to be added
via a special tunnelling mechanism, it is not part of the actual protocol.
Thank you for admitting what some other parties still refuse to say.
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
On 20/04/2024 12:54, Marc Haber wrote:It is completely independent of routing. A normal computer can act as
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'
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?
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 didn’t miss it at all. It’s listed under “design goals”, not actually under how the spec works.It can't work across routers without helpers because the client knows
By definition such a protocol cannot work across routers, because
clients don’t know what routers are available until a DHCP server
tells them.
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.
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 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.
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.
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.
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.
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:
Does that change the meaning?The ‘must’ in the design goals is not capitalized.
Indeed, I did miss that.
I don't know how that should work because a DHCP machine doesn't knowTherefore 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 acrossTrue, but I doubt there would be a solution for that. Even DHCPv6 needs
routers"
it therefore becomes reasonable to presume that "routability" was
at a minimum, not excluded, and was likely intended.
That depends on the addresses being used. When being used onI 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 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.
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.
The
fact that someone calls that a 'relay agent' is as weird as saying a
router is an IP 'relay agent'.
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.
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.
DHCP can provide node type and NBNS settings which influence if and when
SMB broadcasts are sent.
A router *is* "a special tunnelling mechanism", not part of the actual >protocol" for IP.
Yes, that makes perfect sense.
Thank you for the information. =)
Yes. And it can provide DNS and NTP servers, information about network
boot and tens of other things.
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.
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.
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.
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?
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.
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.
}:-)
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.
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
Not at all true in the case of address translation, routing protocols, traffic shaping and the like.
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. :-)
I was not sure how sparse the option number allocation is and too lazy
to look it up.
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. :-)
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.
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.
On 21/04/2024 20:58, Grant Taylor wrote:
On 4/21/24 05:17, The Natural Philosopher wrote:Routing itself *is* network address translation. The router removes the >current next hop address and replaces it with a new one, and it reduces
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.
the TTL field.
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
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.
Please get yourself familiarized with the protocol before you continue talking about it.
Given that logic, HTTP(S) and NNTP(S), both of which are dependent on
TCP, which is dependent on IP, aren't routable either.
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.
You're reasoning is flawed.
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 .
A router *is* "a special tunnelling mechanism", not part of the actual protocol" for IP. And its NOT tunnelling.
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.
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: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 08:18:57 +0200, Marc Haber wrote:
You're reasoning is flawed.
I’m what reasoning is flawed??
Does not parse.
So a “special tunnelling mechanism” is NOT tunnelling? Keep on tying >yourself in knots ...
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
people educate themselves before this discussion can become fruitful
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.
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.
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.
[-- 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.
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
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.
There surely is other documentation available ...
On Sat, 20 Apr 2024 08:15:34 +0200, Marc Haber wrote:
There surely is other documentation available ...
There may or may not be other explanatory documentation, which may be more >or less accurate, doesn’t change the fact that the RFC is the official >spec.
I am sufficiently familiar with the protocol to not need a
communications diagram and I am not aware whether the RFC even contains
one ...
You still didnt understand how it works. Next step would be looking at a packet trace.
Exercise: Outline how a host renews its lease.
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.
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.
On Tue, 23 Apr 2024 09:22:28 +0200, Marc Haber wrote:
Exercise: Outline how a host renews its lease.
Through the same DHCP server it was able to contact without going through
a router? Or does it somehow have to use a different server for this?
Marc Haber wrote:
You still didnt understand how it works. Next step would be looking
at a packet trace.
Go on, then. Show us one, and show us how it gets through a router the
same way a “routable” protocol does.
On 4/15/24 01:50, Nuno Silva wrote:
Why does it get called "TCP/IP" so often? What is the origin of that
name?
That's at lease partially becuase IPv1-3 was a single protocol. There
was lots of debating going on during the development of IPv1-3 for the
raw point to point that IP provides and in order delivery circuit that
TCP provides. It was part way through the development that the
realized that they could split IP into two layers TCP for end-to-end / in-order delivery and IP for point to point connectivity that other
protocols could use.
These are two different protocols for different layers and that name
does not include, say, UDP.
IPv1-3 was split into TCP/IPv4. TCP was the first protocol that ran
on top of IPv4. I think part of the reason for the split name was to emphasize the split protocol design.
I think UDP was officially documented within a year of TCP/IPv4 being documented. But the progenitor of UDP existed before TCP/IPv4 was documented. Experiments were ongoing with the parts of IPv3 that
became UDP/IP. Some of the experiments were for voice transmission.
Thanks for this explanation!
I can't believe I either never came across this information or I
forgot it.
Which probably means I have a lot of interesting reading to do
regarding this area of computing history :-)
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 915 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 23:31:38 |
| Calls: | 12,168 |
| Files: | 186,521 |
| Messages: | 2,234,007 |