You don’t have to have one. My first LAN didn’t. I had no idea what I was doing and picked 17.0.0.0 addresses for local ones and I couldn’t connect to Apples website.
At work I manage a network with two DHCP servers. One is a dnsmasq that assigns the IP address, hostname, and basic network parameters to all network devices, and the other is a LTSP server (https://ltsp.org/) that provides network boot images only for certain devices that require it. It might not look pretty, but it works really well.
What really matters is that there's a coherent policy for assigning addresses, which is absolutely compatible with having multiple DHCP servers on the same subnet (e.g. each server configured to hand out non-overlapping IP ranges).
It's less about the IP ranges they're giving out not overlapping and more about the requests that they respond to not overlapping (or at least that they don't contradict one another). The classic 'someone plugged a consumer wifi router into the office/university network' problem often is made worse because the consumer wifi router gives out different addresses.
Port- or Client-isolation on Ethernet switches and Wi-Fi access points respectively. Often seen in corporate environments and (properly configured) guest networks.
Switches and firewalls can do all kinds of things. Probably the most common case is that public/guest wifi networks often have client isolation set up so that different devices on the network can't contact each other. Same subnet, but only access to the gateway and the internet in practice.
(Also can happen if ARP is not working correctly, which can be a right PITA to debug).
There are recent "client isolation" features that prevent P2P communication. Some hosting providers also block customers on the same LAN from attacking each other.
Most consumer wifi routers I’ve used have a setting to prevent peer-to-peer traffic. Whether this still counts as being on the same subnet is kind of a philosophical question.
An IP subnet is just a block of addresses anyway. Any two addresses both are and are not in the same block, depending on how big of a block you choose.
You're conflating "predictable" with "reproducible".
"Predictable" assumes there is an observer making a guess, but we all live by the knowledge that our assumptions may be wrong. We care less about that, and more about whether the system behaves consistently.
I get the idea, but this isn't necessarily useful as advice and toys with definitions. It's ESPN levels of conversation-baiting. Lots of assumptions can be reasonably made about residential LANs without being true of enterprise LANs/DMZs.
If a residential LAN is RFC1918 and has no NAT, then it is still a LAN... without internet access.
Then the "A & !A" fallacy of "MAC addresses can’t be changed. MAC addresses can be changed."
Just kind of a mess. Would be more interesting to explore the edge cases rather than throw out half-truths and 0.05% instances.
I've never heard of a LAN without IP addresses. Is that a thing? I'd assume that no IP addresses means you can't even use TCP/IP at all, right? Is there something else you'd use instead?
You can send packets over Ethernet, without IP. That's what people did before IP was invented and took over most networked communication. It's less convenient, because you can't reuse the IP stack, so almost nobody does.
Ethernet uses frames, not packets. A falsehood that programmers believe about networking is that everything is a packet. In fact, the "PDU" or protocol data unit for each OSI layer is defined and named differently.
So Ethernet communicates with frames. You can simply send frames across a purely Ethernet network. Or, you can take a PDU from an upper layer, encapsulate it as Ethernet frame, and send it across. Most LAN protocols are flexible like that.
And TFA provides a list of upper-layer protocols that may be encountered on a LAN today: "IP, IPX/SPX, Phase IV, AppleTalk, VINES, NetBEUI, or SNA".
NetBIOS and NetBEUI are particularly interesting here, because NetBIOS Frames did use IEEE 802.2 LLC, while NBT uses TCP/IP for NetBIOS transport.
IP and Ethernet were developed around the same time and also became the dominant standards around the same time. But they were mostly unrelated, so you had token ring networks running TCP/IP and Ethernet networks running IPX and all sorts of other combinations. So it's not quite as simple as that. I don't think there's ever been a time when there was a significant adoption of Ethernet without using it in combination with some L3 protocol.
I'm not sure how much of a "LAN" that would be but some telecom clustering solutions use protocols other than TCP/IP (some don't even care if they run over Ethernet or ATM)
Not sure what a "LAN" is but it happened to me at work that I thought .0 is not a valid host address until I learned about Layer-3 only networks. So also no ARP. I guess this is still a LAN although it's probably an enterprise LAN.
51 comments
[ 1.5 ms ] story [ 8.0 ms ] threadThere'd better be or your network is probably hosed.
Barring "very buggy software," when is this false?
<guy with messy hair>Aliens</guy with messy hair>
(Also can happen if ARP is not working correctly, which can be a right PITA to debug).
Programmers think the models they use are perfect.
"Predictable" assumes there is an observer making a guess, but we all live by the knowledge that our assumptions may be wrong. We care less about that, and more about whether the system behaves consistently.
* two people who say they are on the same LAN agree on what the LAN is
If a residential LAN is RFC1918 and has no NAT, then it is still a LAN... without internet access.
Then the "A & !A" fallacy of "MAC addresses can’t be changed. MAC addresses can be changed."
Just kind of a mess. Would be more interesting to explore the edge cases rather than throw out half-truths and 0.05% instances.
I like the GNOME 2006 era though.
The biggest fallacy here, though, and not stated, is that "LAN" is a meaningful concept.
If one thinks all the assumptions in the article are bogus, then I agree there's no definition of the term.
>99% of the time, being natted and/or having private address space is the definition.
I've never heard of a LAN without IP addresses. Is that a thing? I'd assume that no IP addresses means you can't even use TCP/IP at all, right? Is there something else you'd use instead?
So Ethernet communicates with frames. You can simply send frames across a purely Ethernet network. Or, you can take a PDU from an upper layer, encapsulate it as Ethernet frame, and send it across. Most LAN protocols are flexible like that.
And TFA provides a list of upper-layer protocols that may be encountered on a LAN today: "IP, IPX/SPX, Phase IV, AppleTalk, VINES, NetBEUI, or SNA".
NetBIOS and NetBEUI are particularly interesting here, because NetBIOS Frames did use IEEE 802.2 LLC, while NBT uses TCP/IP for NetBIOS transport.
https://en.wikipedia.org/wiki/NetBIOS