While 3.2.1.0 is a valid IP address, some users might experience problems with IP address ending in 0. It would not be a good idea to use 3.2.1.0 if you want best compatibility with all available hardware/software on the market.
They're a CDN and send out a lot of bits, so every last bit of inbound traffic helps. Or am I totally off base on this?
I vaguely recall a site that that shows approximate throughput for given properties but I can't remember the terms to google for to (re)find it. But 1.1.1.1 might not be listed - or the numbers might only represent valid traffic and be wildly inaccurate.
Traffic breakdowns would thus be very interesting to see (for whatever is shareable, at least - heh, you'd probably have enough fireside stories to drown multiple HNs with :) ). In the case of 1.1.1.1 I'm wondering about what percentage of traffic is coming from valid DNS clients (and I also wonder where the requests are coming from - although that's just trivia to me), versus eg nonsense from horribly misconfigured lightbulbs.
I would have thought that they would go with the simplest measure possible, bytes in vs bytes out.
Most network providers have peering agreements to handle reciprocal traffic flows. In other words, if you're Comcast, you send a shit-ton of traffic to, say, Verizon. But Verizon also sends a shit-ton of traffic to you, as well. Generally, companies will have peering agreements that express the price for which they will route traffic for other network providers, and generally if there's a lot of reciprocal traffic, the peering will be "settlement free" - in other words, neither party charges the other to route traffic. So, in the example above, you as Comcast would agree to route Verizon's traffic across your network for free as long as Verizon did the same.
Cloudflare is a CDN, which means they push a LOT of traffic out across a lot of networks, and it's likely they're not getting as much inbound traffic as they're pushing out. That makes it harder for them to negotiate settlement-free peering, since they're not providing as much reciprocal value to their partners. By owning 1.1.1.1, they can now claim any trafic sent to that IP as "inbound" to Cloudflare's networks for the sake of peering agreements. Since 1.1.1.1 gets a bunch of traffic from either misconfigured equipment or people doing silly tests, routing that traffic helps improve Cloudflare's ability to negotiate better peering agreements.
Which, honestly, is pretty clever, since most of that traffic is garbage.
Nobody expects a residential ISP or a CDN to have balanced flows at part of a settlement-free peering agreement.
Even in 2003, the network I was involved in was handing out .0s out of larger CIDR blocks in DHCP leases with no issues.
I've spent the past two weeks just trying to fix some horribly wrong/invalid data that is absolutely positively guaranteed to always be correct due to certain standards and lots of money and one of the biggest best tech companies in the world stands behind it.
Guess what it's still broken they just refuse to admit it.
"be conservative in what you do, be liberal in what you accept from others"
And there's no takebacks -- once you start permitting something, you can't take it away later, or you'll break things. You're creating more legacy requirements that may cause you problems when you try to evolve in the future.
As a web developer, I can only dream of how clean web standards might be today if the browsers of yore were a bit more conservative.
Many home routers issue IPs using the follow netblock:
Network: 192.168.1.0 Netmask: 255.255.255.0 (/24) Broadcast: 192.168.1.255
Gateway: 192.168.1.1 (the first valid IP in that block) or less often .254 (the last valid IP in that block)
So for the past thirty years, nearly _every_ network block issued by _any_ network admin used /24, to the point that some things simply refuse .0 and .255 as valid IP addresses.
The suggestion upstream is to set up the IP 3.2.1.0, within _any_ network block that can contain it legally. If you adhere to strict netmasking, that'd be (this is from memory, correct me if I'm wrong):
Network: 3.2.0.0 Netmask: 255.255.254.0 (/23) Broadcast: 3.2.1.255
Which would provide a contiguous block of valid IPs from 3.2.0.1 through 3.2.1.254, _including_ the two perfectly valid IPs 3.2.0.255 and 3.2.1.0.
Those valid IPs end in .255 and .0, which is completely legal since they're in the middle of a /23, and the default gateway wouldn't be anywhere near them.
A lot of human-operated networks will blacklist issuing .0, .1, .254, .255 on the theory that it's simpler to just prohibit them and lose 4 IPs per /24 within a block, than deal with what's truly possible for a /23 or wider block.
EDIT:
Public BGP requires /24 or wider, and /24 cannot contain .0 or .255 as a valid IP, so the next widest is /23, which can contain even-numbered .x.255 and .x+1.0. If you're doing this on an internal network that permits narrower subnets, the narrowest available would be a /30, based (irregularly) on either .1.254 or .1.255:
Network: 3.2.0.254 (or .255) Netmask: 255.255.255.252 (/30) Broadcast: 3.2.1.1 (or .2)
With 3.2.1.0 as the live IP and either 3.2.0.255 or 3.2.1.1 as the in-network gateway for that device.
In classful addressing it is a network 3.0.0.0 with a netmask 255.0.0.0 (/8). In a classless, it is whatever has been advertised to me.
> Public BGP requires /24 or wider, and /24 cannot contain .0 or .255 as a valid IP, so the next widest is /23, which can contain even-numbered .x.255 and .x+1.0. If you're doing this on an internal network that permits narrower subnets, the narrowest available would be a /30, based (irregularly) on either .1.254 or .1.255:
It does not. You can advertise whatever the hell you want. What matters is what the other side would accept. It used to be that no one would accept anything less specific than /24 in a class C address space, /16 in a class B address space and /8 in a class A address space because the internet ran on AGS and maybe AGS+ which just did not have enough memory to do real classless. That stopped around the time GlobalCrossing showed up (or maybe around the time Mr V did terrible things while running AS7007). But anyway, ten years ago /27s are definitely accepted routes by those that comprised over 80% of the gloabal internet by the single origin prefixes.
Are there any publicly advertised, unsummarised /31s or /32s in the global BGP tables?
Only /31s could include .0 and .255 and those would end up on router point to point links.
> Are there any publicly advertised, unsummarised /31s or /32s in the global BGP tables?
I filter them out as martians, so I cannot answer this.
That requirement is about how you advertise your routes not how you subnetted the internal network. .0 and .255 of your advertised /24 can work fine as /32s on the server. Using the internet FW to NAT the network and broadcast addresses is another common trick to get more addresses, particularly when you only get an e.g. /29 from a carrier who is just routing that /29 to your specified next hop and 2 more addresses is a big bump.
DHCP giving out a client address of 192.168.1.0 in the middle of a lagre block sure, but a router?