This is what happens when you make the fresh college hire, who has only ever seen a /24, write your network interfaces. They just assume .0 and .255 are always special.

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.

.0 and .255 are special.

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.

The problem is a real problem because people have learned about the fake problem and written real bugs and created the real problem.

It is the bug that creates itself.

Wait till you see how people react to /31 and /31 ending with .0

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

His point is that there's a pretty common journey:

- 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 Busybox DHCP server had a special case where it wouldn't ever give out a .0 address, and I submitted a patch to remove that. I didn't even think about the possibility that someone might intentionally want that (to work around misbehavior of other devices). I don't think the person who added it was thinking that way, but I might be wrong.

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

It was probably added during the development of firmware for some cheap switch whose hardware did some unrecoverable nonsense when seeing such addresses in packets.

Not likely a cheap switch. Cheap switches don't even look at IP; they just do ethernet and that's enough.

More likely to be a slightly fancy switch, or terrible CPE for DSL/Cable.

In addition to various problems with UI/validation... a whole lot of networks/devices filtered 0.0.0.0 netmask 0.0.0.255 when ICMP amplification attacks were such a thing (and before we had better mitigations).

It's the complete opposite:

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 think what you're saying is absolutely consistent with what I'm saying-- so I'm not sure what you're trying to say or if you've grokked my point (that people completely new to networking with less formal learning and people with tons of experience are superstitious about .0).

Part of that is /31 being an extension to IP that isn't universally accepted/implemented.

I tend to run /30 as the smallest because of that (no sudden surprises if a piece of gear doesn't support the extension)

"RFC 3021: Using 31-Bit Prefixes on IPv4 Point-to-Point Links" was published in December of 2000. Most systems have supported it for a long time, with Netgear (swearing under my breath) being the biggest outlier and straggler.

_cries in mikrotik_

Mikrotiks will let you use any two IPs on an interface. "ip address add interface=ether1 address=10.0.0.0 network-10.0.0.1 for example, but you could also use address=10.0.0.0 network=192.168.0.0.

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

It was already mentioned but Mikrotik allows /31 just fine

Worked at a large website holster and we didn't treat these addresses differently. Didn't hear anything from customers while I worked here. Maybe it depends of the country (and their majority vendors)

You're completely ignoring the point that the parent was making.

This whole post is about quantifying exactly how different the treatment of .0 is to other addresses. The answer is: not much.

4% failure is much?

I don't agree, especially if those 4% are systems you disproportionately don't care about.

If you think about it in terms of many gigabit/s but also in terms of causing "intermittent" application issues I would say it isn't something that can be considered negligible. .04% sure but 4% is noticable imho. When I was working in networking, I've had a couple of problems I resolved in the lines of "we have 10% packet loss but only to this specific site" which took non-negligible man-hours to resolve. It is significant enough for some sensitive customers (especially gaming servers and such) to require support on it.

I'd say .1 is a bit special too (even more for FHRPs), and there are weirdos who use .254 for their gateways. I've even seen a lunatic or two put it somewhere in the middle of the subnet.

Blindly assuming .1 is your router is a bad idea. I've seen cases when it all started with a single uber-host at .1 which does routing, DNS, DHCP, mail, and internal web server; and later on the routing part was moved to a separate device with its own IP.

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!

Huh. I typically do middle of the subnet. Static addresses below it and dynamic addresses above it. I think it's how the first datacenter I worked at back in the Pleistocene did it and I just kept the habit.

I've had several ISP routers come with .254 as the default IP, this that's the gateway.

FWIW I avoid .1 and .254 as they are too common. If some router-specific malware is going to try target the most common denominator, it'd be these.

I think people might be confused by your post. With an IPv4 /24 subnet, .0 and .255 are special (they are the network and broadcast addresses for a /24, respectively). When you use a different subnet mask, the network (first IP) and broadcast (last IP) addresses will shift.

The problem is that in the common case case those IP addresses are useless and serve no purpose. Broadcasts get broadcast because they are sent to broadcast MAC address. They can have IP packet with all-ones destination inside (which is different from a unicast packet sent to that same address via its unique MAC), they can have IP packet with a specific destination inside (well, maybe your ARP cache is malfunctioning, and you've forgotten the proper MAC address, but not the fact the host exists?), they can have arbitrary data (because you've invented our own protocol). You also need to call a different function or set some flag to make broadcast happen. It is possible that early IP stacks relied on a dedicated high-level broadcast address to prevent the need to handle all kinds of underlying networks in programs, but I'm not sure.

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

It seems you assume, that IP runs on Ethernet. But what IP that runs on a different data link layer that uses different address and doesn't know what a MAC address is?

Then it uses a different broadcast method that also does not depend on higher level IP addresses.

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.

You can get some of properties you describe with the behavior most people would want via a combination of anycast, some route exchange protocol (probably BGP), and ECMP.

And even though, you can still have a /24 with used .0, .255 (for example if injected via BGP on machines that have other IPs)

Most of my small sites are a pair of /24s, they have .255 as a loopback, split up the rest of the network into /26 or /27.

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

Please tell, then. But no, I don't see what is wrong with that. An outsider doesn't know the CIDR of the IP he's talking too, so it wouldn't change. It only matters for the last router in the loop, and if it's taken into account (because it's actually your infra), then it's okay

Long, long ago, SunOS, and possibly other Unixes, considered x.x.x.0 as a broadcast address as well. (Or I should say more properly, an all-zeroes host address.)

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.

In school, I handled the network for students, we had a /22. I was still afraid to use .0 and .255.

It's logical:

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.

I don't think CIDR has anything to do with this. If you had a class B network, were you required to segment it into class C's? no, right? so, same problem, it's not clear what are your network and broadcast addresses without knowing your class, same as not knowing your cidr /n

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.

I think the original expectation was you wouldn't segment it, and that's why each address class has it's own defined range of ipv4 space. See rfc870, MITs /8 was listed as "temporary" (lol) and they had several separate specific class Bs.

The ghost of /etc/networks rattles in the distance..

Just about every sysadmin I worked with thought in /24s. A lot of people are used to deploying the Linksys home routers and can't think about subnets or supernets. It used to blow peoples minds when they would get a .0 or .255 address because I had them on a /22 or /23. Even the last network engineer I replaced had multiple /24s all over the place across our WAN. I couldn't summarize routes because he didn't use sequential subnets, just random ones all over the place. Drove me nuts.

I get this all the time at work... We have somewhat large subnets for clients (I think /22 and /23, and something much larger for our VPN pools) so I'll not-infrequently get "client has wrong IP address" things because they have a .0 or .1 or .255.

> They just assume .0 and .255 are always special.

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.

(2013)

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.

Really love when I get a /30 with one IP from hosting providers. (Oops, /30 not 22. Subtracted two from the wrong number.)

So, if the hosting provider's router supports lowest-address, you'll be able to host two usable addresses on that subnet, at least using Linux, FreeBSD, or OpenBSD (hopefully more OSes in the future).

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

Not sure what you mean, what's wrong with being issued a single IP on a /22?

think he just mistyped /32

Doesn't a /30, like a /31 have two routeable IPs, not one? What am I missing?

Well, network number, gateway, broadcast, one left for host.

we assign /32 to our VMs then add a /32 device route to the router. Not an ISP tho, just inside datacenter.

Can you elaborate? Say you give 1.1.1.1/32 to a VM (Sorry CF). What route do you add to reach internet? Do you somehow configure the router too? What do you put in as a gateway? And what would be router IP in this example, if you had, say 1.1.0.0/16 ?

Wouldn't you need a /0 route for gateway?

What does a subnet mask do? Almost nothing. In case of Ethernet:

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

It’s very nasty, but there are a lot of options. For example you can give the gateway an address in the link local range and add a route pointing at that. I think that’s the best way.

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

see my other answer for a way.

We do actually use proxy-arp for install only as it's hard to inject a route into installer

ah, onlink, indeed that is another way.

    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 

yes you do need a route for gateway, we just add it via CM

> 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

and a route

    10.252.1.20 dev vvmname.0 src 10.252.0.1 uid 0

added in a hook, and then distributed via ospf to rest of devices

So each VM needs 2 IP addresse - 1 GW, another one VM?

What is the advantage here...? Or is this done to prevent VM using another address from 10.252.0.0/x "subnet" ?

I've been summoned by the police because of a "dot-zero" address on one of our servers.

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.

As someone who runs a .0 on a public /24 and who uses net.inet.ip.hostzerobroadcast to not waste IPs needlessly, I thought it was hilarious when someone emailed me to tell me that I shouldn't do it, and that it'll break all sorts of things.

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.

By your own admission, any complaints you can hear are invalid.

It seems like you don't understand :(

What if I called your telephone to tell you that your telephone setup shouldn't work?

It seems you don't understand.

> Naw - we don't need evidence here! Evidence just confuses people.

How are you expecting to receive said evidence?

I can't tell if you're trolling or if you really don't understand.

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?

Real-old-timer's "solution" - start moving major DNS servers, search engine crawlers, Gmail web pages, bank payment system gateways, etc. to those addresses. People fix sh*t fast when the suffering is on their end.

Similarly I've been advocating that a few major routers should simply drop all IPv4 for one minute at noon UTC. Next month, make it two minutes. IPv6 adoption would skyrocket.

Needs to happen during American daytime, the US doesn't care until it affects them (which is exactly why it's taken so long to move off IPv4, the US has plenty of addresses).

You think that’s why it’s taken so long to move off of IPv4? Surely it can’t be _anything_ else, like lagging support for IPv6 in newer network routing protocols, bug related to those implementations with IPv6, or sometimes no support for IPv6 at all. Similarly for systems and applications that just have no concept of IPv6 at all. To single out the US as the reason why we have not moved off of IPv4 is laughable, the US has a pretty significant adoption of IPv6.

> You think that’s why it’s taken so long to move off of IPv4? Surely it can’t be _anything_ else, like lagging support for IPv6 in newer network routing protocols, bug related to those implementations with IPv6, or sometimes no support for IPv6 at all. Similarly for systems and applications that just have no concept of IPv6 at all.

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.

I think what would help is treating IPv6 as the new default. IPv6 is now good enough that can use it for IPv6-only network with NAT64/DNS64 at the edges for IPv4.

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.

> I think what would help is treating IPv6 as the new default. IPv6 is now good enough that can use it for IPv6-only network with NAT64/DNS64 at the edges for IPv4.

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.

But what causes the lagging support, bugs, no support?

A side benefit of inventing the internet, I guess.

(disclosure: I'm a Yankee)

Cloudflare already does it for their reverse proxy service in some instances. One of my subdomains resolves to 188.114.97.0 and 188.114.96.0 on v4.

This reminds of edonkey, a filesharing program launched in the year 2000. A deficiency in the protocol results in clients on a ip with a zero last octet being unable to receive incoming connections, which means clients can exchange data with fewer peers.

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.

From experience running a DHCP server: .255 in the middle of a /23 is allowed, but not accepted by Windows. .0 in the middle of a /23 is allowed, but not accepted by iOS.

What version of iOS is that?

No idea, the user didn't specify at the time. (The range is part of a PI block within former class C space, if it's relevant.)

I would assume iOS uses the same network stack as macOS and would find that surprising, but stranger things have happened.

I run a /23 in my primary "home" VLAN specifically so I could allocate 10.x.y.0.

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!

> 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

So, if you're sufficiently enthusiastic about Pokémon, you can do the DNS and reverse DNS in your head? :-)

> All of my hosts are named after pokémon

Do you have Umbreon in there somewhere~? That'd be meeee :o

The thing I've never managed to get my head around is why the .0 was ever treated specially. It's the simplest human-readable "address" for a network, but if you do a lot of network programming you get used to slapping the CIDR network on all sorts of addresses, and what does a network stack care about the "address" for a network anyways? The .1 of a network isn't routed any differently than the .0. It's either directly connected, or it's going to the next hop router, whether it's the .0 or the .1.

The special treatment broadly predates CIDR and official documentation of general arbitrary-prefix-length subnetting!

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?)

I once had my residential cable provider assign me an address ending in .0 (not /24), which I thought was pretty neat. But I predictably ran into some sites and services that refused me access and eventually forced a change.

How many years ago did that happen?

It was BrightHouse networks so about 8 years ago.

I'd say you know nothing about networking until you get that there is nothing special about those “special” IP addresses. Or non-contiguous subnet masks. Or /32 — on both sides of point-to-point links. Subnets don't really exist, only network cards that apply masks to what they send and receive do exist.

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.

The stories we can tell about getting 1.1.1.1 and 1.0.0.1 to be reliably routable…

Hey, I never checked before, but you seem to have 1.0.0.0 answering pings. That's awesome.

"ping 1.0" works. Now let's introduce floating point support to also ping 0.99999999999999… and 1.00000000000001…

I consider continued support of classful networking to be an inet_aton bug. I certainly don’t pass user input to it without sanitizing.

/31 is equally funny one, confuses so many people that really should know better

Yep, despite the fact being the standard for 22 years.

(For people who are unfamiliar with this, see RFC 3021.)

the microsoft kb mentioned in the article no longer exists. here's a copy hosted by pki.

https://mskb.pkisolutions.com/kb/281579

Here is an archive copy of the KB as of Feb 15, 2015 which I think is the last archive copy in the Wayback Machine before the page is moved/removed:

https://web.archive.org/web/20150215042051/http://support.mi...

edit: year corrected

for me, it was a hard time grasping CIRD and concept of host address tbh. playing with ciso packet tracer and rip, ospf... still not understanding ipv6 and all those huge infrastructures. like ipv4 to ipv6. carrier grade nat. BGP, peering...

Time to move to IPV6.

All IP addresses equal? "Colon-zero" addresses are less equal.

For those that don't know: https://www.rfc-editor.org/rfc/rfc4291#section-2.6.1

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

Has it? 35% and rising. 55% in the US, 75% in India, 30% in China.

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)

Yup, especially for cell phones. Pretty much any time in on Verizon or att in assigned an ipv6 addr

We all know people who go hard on IPv6 has failed. Well.. its true it didn't achieve what we hoped in the concept of IPv6 Transition So failure is in there. But it's a different kind of market failure to DECnet, or X.25, or Novell Netware. It's the kind of "fail" which means "didn't turn out as we expected"

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.

In some countries there's zero IPv6 on mobile despite good progress being made on fixed line IPv6.

interesting!

i tend to regrad ipv6 as the "smartphones + india internet"

I block IPv6 on my home router because everything still works without it and it simplifies my firewall a bit.

I permit IPv6 SSH into my home network precisely because I have a static V6 delegation and can do it, where my IPv4 binding is necessarily mutable because of the use of CGN, and lack of pool addresses. If I want to "phone home" then this is simpler than managing dynamic-DNS to find where my home is right now on v4.

Above the IP layer, TCP/UDP rules should be underlying AFI agnostic. But I can believe the firewall DSL don't make that easier.

Technically, I have a dynamic ipv4 IP address but in practice, it never changes unless I spoof my router's MAC address.

Dan J. Bernstein wrote about the reasons why, and it's quite enlightening.

https://cr.yp.to/djbdns/ipv6mess.html

No it isn't. That page sounds clever to the clueless but to anyone who actually understands that packet-switched networks won out over circuit-switched ones it's deeply stupid, to the point that I wonder if he wrote it as some kind of deep cover trolling.

Also, the article is old. It doesn't mention NAT64 which got rid of the big compatibility issue of IPv6 hosts not being able to talk to IPv4 servers. The other way, IPv4 to IPv6, will never happen and could never happen with larger address space. People talk about extending IPv4 address space but never explain how they would solve the compatibility.

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.

I suppose that you could argue that packet switching won out over circuit switching. I mean, except for the gigantic installed base of landline telephones (analog and ISDN) and the digital switches that support them on copper pairs, still extant and supported, VoIP is incrementally replacing those lines as the decades progress. (How many decades has it been now?)

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.

Because it costs money to maintain both stacks, it costs money to replace the old ass devices/hardware that are IPv4 only (at some level -- there are plenty of situations where the end user can't spend any reasonable amount of money to replace the item because the manufacturers won't fix the problem), and it costs money to have employees spend time to get trained up in IPv6.

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.

My employer's VPN has a bug that breaks ipv6. I've found that most web sites I visit are using IPv6.

They added features that weren't needed, and those new features break compatibility. IPv6 is the Python 3 of the network stack.

In both cases the migration happened eventually. All my devices have and use v6, and I haven't had to touch Python 2.6 in years.

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.

The issue is not NAT as a firewall. Every routers shipped to customers also come with a firewall and replicating what NAT does by default is dead simple. That’s a red herring.

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.

You know what's more dead-simple than using NAT as a firewall?

A basic firewall without NAT.

NAT with IPv6 is a thing, it's trivial to do. I only have a single IPv6 address given to me by my VPN (ISP doesn't support IPv6) and IPv6 masquerading works perfectly fine.

It was developed by the IETF in a working group led by engineers from Cisco and Nokia. It’s approximately as far from an academic solution as you can get.

No. IPv6 is significantly easier to subnet. I can tell you the start and finish of 2a07:ffdd::/29 from the top of my head (it's 2a07:ffd8:: - 2a07:ffdf:ffff.....), because there's a nibble boundary every 4 bits, which makes it trivial.

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.

No it isn't.

Not literally no, but the spirit of the sentiment is true. Have been in some flavor of networking for the past decade, there is a reason it hasn’t been universally adopted despite being ratified 25 years ago.

We can say that IPv6 is universally adopted for mobile networks.

But does it universally go IPv6 to IPv6 or IPv6 to an NAT64 gateway? Isn't CGNAT also popular for mobile networks?

Most of the traffic in mobile operator networks I'm aware of is IPv6 to IPv6, for very obvious reason - people watching youtube, facebook et al, and they are IPv6 enabled for over 10+ years. Of course one need to provide IPv4 reach-ability as well, details are varies from network to network, 464XLAT is being a popular one.

The big reason mobile networks use IPv6 is that they are new and don't have the IPv4 allocations of legacy providers. They could have gone CGNAT, but IPv6 with 464XLAT is better. Mobile networks are easier to use IPv6 than home networks since there is no customer gateway to worry about and 464XLAT software is included on device.

It's "popular" in that it's widely deployed, but I think it's fairly unpopular in that people really don't enjoy operating it. When I worked for a high traffic website, I was told people would occasionally reach out like "hey can we just ipv6-peer with y'all so our users don't have to talk to you over our cgnat. it's putting a ton of load on the cgnat gateway".

No one who operates a CGNAT enjoys it or wants to operate a CGNAT. I'd wager that most mobile network traffic is native IPv6 to IPv6 because all of the super high volume FAANG et al websites are operating IPv6.

CGNAT is a set of hacks on top of another set of hacks. You can keep stacking NAT on top of NAT for near-infinite amount of IP addresses, but what you can't do is you can't multiply the number of ports.

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.