All IP addresses are equal? “Dot-zero” addresses are less equal (2013)
labs.ripe.net
labs.ripe.net
I say this because I was one of those people when I graduated. At our school every network was /24, so 0 and 255 were always reserved. It was a while before I learned about CIDR and how those addresses may not be reserved.
It took a long, long time to shake that assumption out of all code, long after the OS had stopped using .0 that way. So this is yet another domino.
Looking at the BGP table it's just two entries (one for each /24).
I've encountered kit which doesn't like IPs on .0 or .255 in the middle of a /23 or larger, but I've also encountered kit which doesn't like any subnet that isn't a /24. That kit goes back to the supplier as faulty.
I've never seen kit which wont sent to a random x.x.x.255 address that isn't on the local subnet
(Trick question for the exam is whether broadcast traffic received by new host with assigned address of .255 would be a problem.)
HOWEVER, if you want to broadcast something at a remote network, you need to have dedicated network broadcast IP addresses. Unfortunately, even RFC 919 from 1984 thinks it is not a recommended mode of operation. But imagine that we could get "ip/subnet" from DNS, send broadcast to a distant server farm, and receive response from anything that responded. Instead of DNS-based service discovery, we would have a single A record, and finally put that IANA port number database to use in port-based service discovery.
My point is that high level abstractions, like dedicated broadcast IP address that magically alters the behavior of lower level components, complicate things. Say, there is SO_BROADCAST, but it does nothing for TCP (even though we can imagine how broadcast client-to-server connection initiation might work), and there seems to be disagreement whether it allows to use broadcast address, or instructs to use broadcasts with any address. But Berkley sockets are also from mid-'80s, and it is possible that previous alternatives required manual configuration of low level APIs on each individual supported network to use broadcasts, so that was a step forward.
If you choose to use .0, then you have a cosmetic / mental issue ("omg numbering starts at 1, not at 0).
If you choose NOT to use .0 then you potentially save yourself hours of troubleshooting one day, and avoid productivity issues.
Reliability + Productivity > Cosmetic.
Even outside of the context of a /24 I still reserve these addresses because they don't receive equal treatment on the internet. There are still dumb firewalls that treat them as broadcast amplification attacks, OS bugs that treat them as invalid, and a handful of other issues.
This issue tends to be a bell curve of experience. People brand new to networking, and the people who have spent dozens of years seeing the worst of what the internet has to offer both treat them as sacred cows, with the majority just shrugging and mumbling about CIDR.
> and the people who have spent dozens of years seeing the worst of what the internet has to offer both treat them as sacred cows
...a lot of them just didn't update their knowledge over time.
- Newbies see .0 and .255 as special
- We learn about CIDR, and there's nothing special about a .0 in the middle of a large block.
- Then we get zapped by weird connectivity problems or tools that don't let us enter the address because it fails "validation," etc.
Then we think... does our DHCP range really need to cross the boundary when we have a /23? Maybe we should just have two DHCP ranges with a little hole in the middle. It's less than 1% of addresses...
The behavior of arbitrarily rejecting .0 has gotten a lot rarer in the wild lately. (I can confirm that because I've done a whole bunch of connectivity tests to .0 addresses, including using RIPE Atlas.)
More likely to be a slightly fancy switch, or terrible CPE for DSL/Cable.
Experienced engineers understood that .0 and .255 are actually handled differently in the real-world, so they make sure to avoid them.
"Reality sucks, deal with it"
Newbies who just read the specs and learnt from classrooms are tricked into believing that .0 and .255 are the same. Which is true on paper, but not true in reality.
I tend to run /30 as the smallest because of that (no sudden surprises if a piece of gear doesn't support the extension)
I think last time I used it there were a few bugs around redistribution. I tend to use private IPs, certainly for p2ps, so a /30 is fine
Also, well-known IPs, and 192.168.0.1 in particular, should just be avoided. You don't want IP conflict in your network just because someone plugged in unconfigure device!
It is the bug that creates itself.
if you are "inside" your network, you have the mask; if you are outside, you don't know.
yes, if you are inexperienced and have never seen anything but class C, you might not make allowances for class B etc. The real problem with trying to solve these problems is we not allowed to deploy LARTs any more, or clue-by-fours.
The ghost of /etc/networks rattles in the distance..
For me, .0 and .255 were always associated with the first and last address of a block rather than those specific numbers. And thus the network and broadcast address respectively.
You can see quite a lot of these in
http://ec2-reachability.amazonaws.com/
I think the situation has improved with regard to this specific issue since 2013. I did run some of my own RIPE Atlas tests on this more recently (targeting some of the AWS addresses mentioned above), and it didn't look particularly bad at all.
Somewhat relatedly, we've been proposing to explicitly allow the lowest address within a subnet to be used to number a host. (This isn't necessarily dot-zero, and dot-zero isn't necessarily this; they coincide exactly in the specific case of a /24 network.)
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicas...
We've gotten patches in Linux and FreeBSD for this, while OpenBSD and NetBSD each independently adopted this behavior some time ago.
Wouldn't you need a /0 route for gateway?
Another option would be to set the subnet mask to /0 and enable ARP proxy on the gateway (that is truly diabolical).
Another way is to have a private /30 or /31 as the linknet and then add the /32 public ip as an additional one with a /0 route to the routers ip in the private /30 (and the router can have a /32 route to your ip in the private /30).
1:1 NAT is another option (but that’s not quite the question).
We do actually use proxy-arp for install only as it's hard to inject a route into installer
inet 10.252.1.20/32 brd 10.252.1.20 scope global eth0
valid_lft forever preferred_lft forever
# ip r sh
default via 10.252.0.1 dev eth0 onlink
> Do you somehow configure the router too?
interface on the hypervisor (each vm gets their own)
inet 10.252.0.1/32 brd 10.252.0.1 scope global v.vmname.0
10.252.1.20 dev vvmname.0 src 10.252.0.1 uid 0
What is the advantage here...? Or is this done to prevent VM using another address from 10.252.0.0/x "subnet" ?
— If some data is to be delivered to an IP address that belongs to a subnet, send a packet with that destination IP in a frame with corresponding destination MAC. If you don't know that MAC, use ARP to learn it.
— If some data is to be delivered to an IP address that does not belong to a subnet, send a packet with that destination IP in a frame with gateway destination MAC. What happens next is not our problem. If you don't know that MAC, use ARP to learn it.
Therefore, /32 simply makes host relay packets to all other addresses to gateway.
Note that gateway IP address is not included in any packet. We only use it to learn gateway MAC address we actually need. Note that gateway IP address can be anything, inside or outside of local subnet. The only requirement is that host gets an ARP response when asking about it (from actual interface or some other device acting on gateway's behalf). This gets trickier when host have multiple interfaces to multiple networks, and may have to prioritize, or some interfaces depend on others (as with VPN connections), but it's certainly not a problem in case of a single network connection. Note that physical network connection does not imply that only packets from a single subnet get transferred. Anything can be sent or received, the difference is in what gets accepted and what gets rejected.
Maybe we should (be able to) get rid of the broadcast address in this situation too. Cf. RFC 3021 (adding a special case for /31).
(If the hosting provider literally only intends to give you a single address, and insists on giving you a subnet, it should probably give you a /31 instead of a /30, because of the RFC 3021 behavior. Then it's not throwing away addresses for no reason.)
Someone had been buying stuff online with a stolen card and the shop admins provided a list of the IP addresses used, including our server's. All the addresses were dot-zero addresses, so I assume it was just some kind of unfortunate obfuscation.
Then how did he see my web site? How did he send me an email? I asked him these questions and he said there apparently are hidden breakages that I can't possibly know that'll magically come out when I'm least expecting them. Naw - we don't need evidence here! Evidence just confuses people.
What if I called your telephone to tell you that your telephone setup shouldn't work?
> Naw - we don't need evidence here! Evidence just confuses people.
How are you expecting to receive said evidence?
The person who was emailing me got my email address from my web site. Both the email server and the web server are hosted on a public Internet .0, so in spite of my years of evidence which shows I've never seen a problem, he emailed me (and his email was successfully delivered to this same .0 machine) to tell me this wouldn't work, and that I'd see all sorts of problems that he never enumerated.
In other words, he expected his handwaving and I-know-better attitude to carry more weight than my years of actually doing a thing and observing the results. Ironically, the only way for him to find out more about me and email me was to visit a .0 server on the Internet and send an email to a .0 server on the Internet.
I received said evidence, and the supposed evidence both had no content and partly disproved his claim by the act of sending it to me.
Understand now?
(disclosure: I'm a Yankee)
Who do you think is making those poor protocols and buggy implementations? People who are affected by IPv4 address exhaustion - which is most of the non-US world - know how important IPv6 is and prioritise it. People who aren't affected and don't know anyone who's affected - which is people in the US - don't care (and I don't think this is some deep moral failing - it's normal and natural to not care about an issue that doesn't affect you), treat it as an afterthought, and the poor level of support you see is the result of that.
Businesses are the big holdouts in the US. They have existing complicated networks and address allocations, and don't see the need for an upgrade.
That's already happening on new networks that need a lot of addresses (e.g. most big mobile carriers do this). IPv6 is pretty heavily used, but like most infrastructure you don't notice it until it breaks.
> Businesses are the big holdouts in the US. They have existing complicated networks and address allocations, and don't see the need for an upgrade.
"Businesses" is too broad a category. But fundamentally anyone who has plenty of addresses and isn't feeling the squeeze has no real incentive to upgrade, so why would they.
I believe that there is still some use of ed2k protocol by people using eMule. Torrents won but it is still around.
As far as I have noticed it has been rare for ISPs to give out ip addresses ending in zero since the early 2000s.
All of my hosts are named after pokémon, and use their pokédex number as the last byte in their IP addresses -- except for one host, which gets the .0
A /24 on its own holds all of generations 1 and 2!
So, if you're sufficiently enthusiastic about Pokémon, you can do the DNS and reverse DNS in your head? :-)
Do you have Umbreon in there somewhere~? That'd be meeee :o
In terms of why there were two broadcast addresses, this apparently has to do with late standardization plus inadequate communication between different groups of TCP/IP implementers (Berkeley and non-Berkeley), plus an attempt to maintain backwards compatibility with 4.2BSD that was never revisited.
Seriously, the rationale in all the RFCs that mention the lowest address being special is ultimately compatibility with 4.2BSD.
As I mentioned elsewhere in this thread, several OSes no longer enforce this special case. But people on forums are often willing to confabulate justifications for why the special case should have existed, such as the idea that it would be impossible to distinguish the network-as-a-whole from the host at that address. (I guess those people must also believe that array indices have to start at 1, because otherwise it would be impossible to distinguish an array from its first element?)
After that you can gather some experience on why something can go wrong with that.
Then you can discover some networks that only pretend to be a shared ether, like Wi-Fi, where access point captures and analyzes transmissions with multiple destinations to decide which are first class and are worthy of re-transmitting, to answer directly on its own, or even convert one protocol into another.
https://web.archive.org/web/20150215042051/http://support.mi...
edit: year corrected
Before I switched ISPs, my home ISP was using CGNAT with no IPv6. It was trivial to completely screw up the connectivity for myself (and probably a lot of other users) by simply running a BitTorrent client with connection limit disabled.
Popular? Yes. A good solution? Definitely not.
Exactly like we did with telephone numbers.
IPv6 has 31 nibble boundaries. IPv4 has 3.
Do me a 10.15.121.75/19 from the top of your head.
I would choose working with IPv6 addresses over IPv4 any time of day.
Engineers added 12 additional bytes requiring the switch to a hexadecimal notation, because 255.255.255.255.255.255.255.255.255.255.255.255.255.255.255.255 would be a little bit too long.
Linux in particular, if IPv6 forwarding is enabled, will automatically add an anycast route for the 0'th subnet address.
(Unless it's a /127 subnet per https://www.rfc-editor.org/rfc/rfc6164.)
Yes, there are still people stuck with v4 networks and 2.6-era codebases. These are legacy cases that are increasingly buried deep in the long tail of interoperability.
I'd like IPv4 to die, but I've also worked at places where it would have a significant (non-internet) international impact if you suddenly shot it in the back of the head.
But you're comparing apples and oranges. What was the size of the established, installed base of network hosts using circuit-switched networks when packet switching started to compete? Did SRI International and other DARPA research institutions run IMPs that utilized circuit-switching to route network traffic? No, they started with packet switching. So essentially, as the Internet caught on, its style of packet switching "won" over landline telephones because it was a question of capability and supported features.
IPv4 and IPv6 are the same protocol, essentially; you swap one out under the hood, and the upper and lower OSI layers don't even notice that anything's changed. Packet switching and circuit switching are two distinct techniques that are opposed to one another: if you wanted to swap one for the other, you'd be rebuilding your network from the ground up.
So, apples and oranges: IPv6 is, by design, a replacement for IPv4, and djb is discussing the seemingly intractable issues faced by those who attempt to cleanly migrate.
I thought of scheme where could put the original IPv4 address in option header on every NAT transition to make a variable length address. But that would require changing every router (and lots remove options when NAT), every program, and every protocol. All the stuff that needed to happen with IPv6, with the downside of keeping IPv4 allocations and NAT.
It also mentions a lot of problems with IPv6 that have since been fixed. There is a valid complaint that IPv6 changed too many things so it took a long time to get replacements working.
What a huge mistake.
NAT is obviously a huge crutch but everyone uses it because it’s a dead-simple firewall and makes for dead-simple internal networks. There are NAT-inspired IPv6 analogues but they are not the same.
If NAT with IPv6 was a thing, ISPs could have started shipping routers to customers (as they already do) with IPv6 turned on and we would have already been most of the way to IPv6.
But no, they felt NAT was too hacky and did away with it on a matter of principle.
The issue is that migrating to ipv6 meant changing equipments on the backbone and dealing with the change and no operator wanted to bear the cost. It’s getting better now that there is a dearth of ipv4 and people see an immediate benefit.
A basic firewall without NAT.
It hasn't worked out how we thought, sure. But "Failed" is really strong for something that 1/3 of the global Internet can (and does) use every day.
There are more people on IPv6 now, than there are users in the entire US Internet market.
https://stats.labs.apnic.net/ipv6/CN (replace last 2 chars with any ISO3166 code, or XA for the world)
IPv6 has quirks which are a bummer. If we were able to fix the MTU problem by getting people to move to Jumbograms a lot of these go away, because they stem from fragmentation. So it's true, the design of IPv6 end only fragmentation distinct from V4 on the path fragmentation, that was a failure in design. But if you avoid fragmentation (and QUIC does for instance) then the MTU problem isn't a big deal in the end. More packets is faster clock pacing!
I wish people were a bit more pragmatic and a bit less dogmatic about things. Fix MTU. fix links. Fix what you can. Deploy IPv6 because it works. And, it reduces pressure on your CGN.
i tend to regrad ipv6 as the "smartphones + india internet"
Above the IP layer, TCP/UDP rules should be underlying AFI agnostic. But I can believe the firewall DSL don't make that easier.