Posts by Nanashi

AI vastly reduced stress of IPv6 migrations in university experiment

Re: Ok then, what?

Nah, there's no assumption of that. It's just that if you use a single address space for everything, it means that when any two given hosts do need to communicate they can do it easily. Otherwise you end up with those expensive networking problems that you mention at the end of your post.

The reason for organisations moving to IPv6 aren't likely to be the risk of exhausting the 10./8, 172.16./12 and 192.168./16 address spaces

Plenty of organisations are in fact exhausting RFC1918. Even the ones that aren't are often hitting RFC1918 clashes (e.g. when merging networks or making VPNs), which happen because the RFC1918 space is too small.

Re: Some? Some?

I swapped ; and : on my keyboard layout, which took a month or two to get used to but works pretty well unless you happen to be writing a lot of code in a semicolon-heavy programming language.

(I'd also suggest (with e.g. xremap on Linux) making the left and right shift keys generate "(" and ")" when they're pressed and quickly released on their own, and perhaps the same thing on AltGr to generate "_". Really helps make programming less stressful on your pinkie finger.)

Re: Some? Some?

That's purely down to a lack of experience on your part, not because it's actually hard.

Let's say your prefix is 2001:db8:10::/48, and your log server is sitting at <prefix>:5822::122. Why do you think that it's a nightmare to read the "5822" and "122" out of the v6 address? If you can read them out of the v4 address, it's not really any harder to read them out of the v6 address.

IPv6 just turned 30 and still hasn’t taken over the world, but don't call it a failure

Re: Just ratify NAT & let us have at it!!!

...is another post that makes the incorrect claim that packets with no matching state entry are discarded.

That's not what happens. Have you even tried it?

Re: The real reason nobody wants to use it

IPs are required to run the firewall, but there's no reason that you, the human, have to provide those IPs. The firewall (or rather, whatever loads the ruleset into the firewall) should be able to look them up for you.

Re: Backwards compatibility

No, v6 was designed to extend the Internet. It does so as well as is possible with v4. You do in fact have a choice of (IPv6 only), via a wide selection of every transition mechanism that's actually possible with v4. The evidence for this is that if you ask people to come up with a better way of doing it, they either give you some half-baked BS that doesn't work once you think through it, or they start to reinvent v6.

v4 is expensive to run if you're relying on it for every single thing your network does. v6+v4 can easily be cheaper because you can relegate v4 to just backwards compatibility, and don't have to spend time and effort on trying to get it to work for everything.

You don't need a v4 address in your network for NAT64. Only the person running the NAT64 needs that, which doesn't need to be you (and even if it is you it still saves you from needing v4 on the entire rest of your network).

v6 didn't try to replace DHCP. In fact DHCP barely existed when they picked SLAAC, which was modelled after IPX's autoconfig (which was much more common at the time).

I'm going to claim that you need v6 to reach v6-only websites, because you do. They do in fact exist, but they're rare, and they're rare precisely because you need v6 to reach them. If you could reach them without needing v6 then we wouldn't need v6 in the first place!

Re: Just ratify NAT & let us have at it!!!

You're right that it can't forward traffic... because it just changes packet headers. Packet forwarding is done by the routing part of the router, not the NAT part.

If NAT doesn't have active translation information for a packet, all that happens is that the packet gets passed to the routing part of the router with its original headers intact. It doesn't magically get dropped just because its headers were unchanged. And guess what happens if the original headers had a dest IP inside your LAN?

Re: The real reason nobody wants to use it

It couldn't, for the reasons explained in the part you quoted: v4 addresses are treated as fixed length everywhere. At the moment you created a new packet header, you've given up on "just add more numbers to the beginning" and taken your first step down the path of reinventing IPv6. Once you start considering how to get existing software, OSs and devices working, you'll end up taking more steps down that path.

Or maybe you'll just get lost with weird claims. Extension headers aren't kludges for things v6 broke, and you are supposed to fragment packets if they don't fit into the path MTU. v6 is already pretty simple, and there's basically no possibility of making anything more backwards compatible than it already is. It already includes country codes, and v6's method of "read the destination address out of the packet header" is no more bizarre than v4's method is.

Re: Just ratify NAT & let us have at it!!!

Yes. The disconnect is that they're about different topics: me being unable to connect to RFC1918 addresses over the public Internet vs NAT's ability to stop connections. That's why I asked what the point was, because I was asking you to tell me what NAT does to stop an incoming connection.

Re: The real reason nobody wants to use it

Then you can't do it with your suggestion either, because what you're suggesting also requires more than just extending the address space. That's kind of the core problem: you can't just make addresses bigger and be done with it. So much other stuff also has to change to accommodate that.

"You can fit the addresses into a single register" doesn't seem like it could possibly be worth the cost of not having enough address space, considering that a 128-bit address can be loaded into a pair of registers just fine. Especially when almost nobody is working with v6 addresses at the level of loading them into registers. The closest most people get is C, where the register handling is done by the compiler. (Or well, really the closest most people get to working with IP addresses is tapping on search results in their browser.)

Re: Substituting multicast for broadcast…

Of course it serves a useful purpose: dealing with v4's lack of address space. It just doesn't serve a security purpose.

NAT will change your outbound connections to look like they came from your router. Why do you think that protects you from inbound ones?

Re: Just ratify NAT & let us have at it!!!

I can't connect to that from here, obviously. (What was even the point in asking me to?)

No, NAT isn't a poor man's firewall, because it's not a firewall. It doesn't stop connections.

Re: The real reason nobody wants to use it

v6 does integrate the v4 space at e.g. 0.0.0.0.0.0.0.0.0.0.0.0.104.18.4.22, so I don't buy your assertion that you can't do it in v6. The problem is that doing it doesn't actually help at all.

Why can't you just change uint32 to uint128 and increment the protocol version to deal with v6? Or well, I know that expanding the address size is a bit more involved than that, but that extra work would also be needed to move to uint64 too. What are you gaining by making the new protocol too small?

Nah, the problem has been well known and understood for decades now: v4 is too small.

v6 has taken off (with going on 3 billion users), it's just going slower than we'd like because a) deploying a new protocol to every Internet node is a lot of work and b) network effects are really goddamn strong.

Re: Just ratify NAT & let us have at it!!!

Can you describe the mechanism that NAT provides to prevent inbound connectivity? No, you can't, because NAT doesn't have a mechanism to prevent inbound connectivity. NAT has never shielded users from inbound connectivity.

Paying the costs of using NAT in v6 when it's completely unnecessary, just because people misunderstand what NAT does, would be very dumb.

Re: Terrible conclusion

Unfortunately, you need to do a lot more than just "bigger address space" if you actually want anything to be able to use that address space, e.g. DNS needed updating because A records don't handle addresses bigger than 32 bits. If this wasn't the case, we wouldn't have needed v6 in the first place; we could have just used a bigger address space with v4.

The answers to your questions are: because they serve different purposes. Both of them work, for different things. Because the router isn't the computer and so will have a different address. I don't think it's particularly confusing. Because you insisted on DHCP even when you didn't need it. Because people want shorter addresses. The "idiot" that didn't want to write ":0000:0000:0000:" all the time. Anybody who thought about it for a few seconds. Users don't understand IPs at all, or networks, or computers, so having addresses that are easier for netadmins to work with doesn't matter to them.

v6 really isn't a mess. It barely changed anything from v4; almost all parts of it work in exactly the same way. You're just lashing out at it because you're uncomfortable with having to spend a few hours getting familiar with it. There are going on 3 billion people using it, so it's clearly far from an abject failure. You're not being forced into it because it's all we've got, you're being forced into it because we've run out of v4 and v6 has been successful. ISPs aren't doing CGNAT because v6 is broken, they're doing it because we've run out of v4. What did you expect them to do, just tell everyone with v4-only devices and software or who wants to reach v4-only sites to go and pound sand? If they had, you'd just be complaining loudly about that instead.

Re: 32 bits were just right

48 or even 64 wouldn't be enough to avoid running in address conservation mode. Hell, even with v6's 128 bits it's still kind of a struggle to get ISPs to offer the bare minimum /56 allocation that they're supposed to. Vastly cutting the available address space isn't going to help with that.

I do agree that 2^128 addresses is more than we need. But like... isn't that a good thing? We want there to be more IPs than we need, because the only alternative is for there to be fewer IPs than we need, and to me at least it seems obviously less desirable to have too few instead of too many.

Ports are an L4 thing, so they're out of scope for an update to IP.

Re: The real reason nobody wants to use it

fec0::/10 is long deprecated, and it's a bit odd to tell us to avoid fd00::/8 in favor of fc00::/7 when the latter includes the former. fc00::/8 is intended for /48s assigned by some central entity (but none has been set up, since there doesn't seem to be a pressing need for one) and fd00::/8 is for people to select their own random /48s from, so if you want to use ULA then you'll be picking a /48 from fd00::/8.

It's not exactly hard to hand out a new prefix to everything. Your router advertises the new subnet, and every machine across your whole LAN receives it and automatically configures a new IP from it.

Anything that assumes your IPs are never going to change is already broken. Maybe we should focus a teeny bit of the energy we spend complaining about it into fixing the brokenness?

Re: The real reason nobody wants to use it

You already have to firewall the hell out of your v4 addresses to prevent someone that's penetrated your LAN from using them to move laterally almost for free. Needing to do the same thing again for a slightly different address is hardly a "security nightmare".

Most of your first questions can be broadly answered by a mix of "you advertise a /64 from the prefix that the provider gives you" and "you can use multiple addresses". And it doesn't sound like your use of v4 is very flexible if it can't handle your IPs changing sometimes.

Re: The real reason nobody wants to use it

It's not a privacy or a security nightmare. IPs are just numbers; they don't tell you anything about the machine or its user. You gain no security benefit from NAT, and privacy extensions and RFC7217-style addresses prevent people from tracking devices between networks, or over time in a single network.

Just because an address is globally unique doesn't mean that anybody can connect to it. That's a policy decision that you get to make.

Re: The real reason nobody wants to use it

It would fit into a single register, but it wouldn't fit into the 32-bit wide address fields in the v4 packet header, or the 32-bit wide fields in the socket structures, or the 32-bit wide A records in DNS, and so on and so forth. No existing v4 equipment would be able to use it.

It's not possible to implement 64-bit addresses without giving everyone new IPs, for all the same reasons that it's not possible to implement 128-bit addresses without doing so. If it was, v6 would have already done it.

Re: The real reason nobody wants to use it

But v6 already absorbs v4 as a subset! If you're going to talk about high horses, maybe don't complain about the things you think it doesn't do until you know a bit more about what it does do.

The APIs part is relevant, because it limits what sorts of compatibility are possible. For example, there's existing software out there that assumes that all socket addresses are sockaddr_in, or that use gethostbyname(). There's hardware out there that only does v4. Until you get rid of all of this, you'll continue to have v4 working in parallel regardless of how v6 is designed - because the v4 stuff doesn't use v6's design, it uses v4's design. Even if you make a "v4.1", you'll hit the same problem of the existing v4 stuff using v4's design instead of your v4.1's design.

v6 already does pretty much all of the forms of backwards compatibility that are actually possible with v4. I don't think there's anything a "v4.1" could do that v6 isn't already capable of. Feel free to correct me if there is, but if you give me yet another thing that v6 already does, I'm going to call you out on it.

Re: The real reason nobody wants to use it

Yeah, we did that. Every v4 address automatically comes with a /48 tunnelled to it, that can be used basically like you describe. It uses the next-protocol field and puts the additional octets at the beginning of the payload area rather than using an optional header, but that's not a significant technical difference.

But what about DNS? You can't fit extra octets into an A record. What about the BSD socket API? sockaddr_in only has a fixed 32 bits. What about other protocols, databases, software, etc that also use fixed 32-bit fields for addresses? They can't fit more bits either.

We did more or less the exact thing you're suggesting here, and not only is it not enough to give the level of backwards compatibility you're thinking it'll give... it wasn't even enough to stop you from criticizing v6 for not doing it. If this isn't good enough, how could anything ever be?

Re: Backwards compatibility

Except it doesn't actually fix the problem, it just extends life support for v4 to buy us more time to migrate to something that does. I'll grant that it's done a surprisingly decent job of that but it's still just buying time, and at the cost of causing problems of its own.

Re: The real reason nobody wants to use it

But also... they did! How many bits do you think there are in "2001:db8:a:1::2"? Sure, there's room to expand to 128 bits in there but in terms of actual used bits it's about the same as the 64 bits you end up with in v4 from effectively having two v4 addresses for every machine. (Or worse, in the case of CGNAT or businesses that remap RFC1918 because they had clashes, where there are more v4 addresses involved.)

I propose IPv5: an additional dotted quad

Adding any number of bits at all requires doing all the work v6 is doing. If you're going to bother, you might as well add enough to avoid needing to do it all over again immediately afterwards.

Backwards compatibility

And that notional committee made one more critical choice: IPv6 was not backward-compatible with IPv4, meaning users had to choose one or the other – or decide to run both in parallel.

Uh... what? It is backwards compatible with v4.

Did you mean that they made the choice for v4 to not be forwards compatible? Because that was v4's design committee, not v6's. It's a bit unfair to blame them for decisions made twenty years beforehand by a completely different set of people, isn't it?

ISPs more likely to throttle netizens who connect through carrier-grade NAT: Cloudflare

Re: Pitfalls of IPv6

It's not meant to. But also, you're going to have trouble in general if you have an internal host on the same IP as the router, and we're talking about packets where the dst is the LAN so why ask about ones where it's the router? Indeed, none of that makes any sense.

Packets addressed to the router are uninteresting here; they'll just get delivered to the router itself, and I'd like to hope that I don't need to convince anyone that NAT won't protect them from that. It's just the LAN case that really confuses people.

"in 2025, most NAT systems are on a stateful firewall, lets say you are right & the NAT/firewall is in the path to a public ip range, then yes ok if no NAT entry it then checks its stateful firewall & if no rule then the traffic is dropped by the default drop."

The packet still goes through the firewall whether or not a NAT entry matched, and also it doesn't matter what the IP range on the LAN is, but otherwise yes, exactly. But you're describing the firewall dropping the packet, not NAT. Firewalls do provide a security benefit, which is why most NATing routers still have them, but we weren't talking about firewalls.

"typically though NAT devices are used on routers/firewalls that bridge public ip's to private IP's & in this overwhelmingly used use case the original dst IP is the router/firewall so can't be routed internally & ends up null routed & dropped."

This is indeed the overwhelming use case, but nothing about it will restrict inbound packets to only having a dst IP of the router, so you still need to consider what would happen to packets addressed to machines on the LAN behind the router. If NAT doesn't touch them, then it's not providing a security benefit.

Re: Pitfalls of IPv6

Funnily enough, even symmetric NAT provides no security benefit.

The site you linked says "Incoming packets must be part of an established session, enhancing security.", but that's not actually true. The correct version of that statement is that incoming packets must be part of an established session in order for their destination address to be rewritten by the symmetric NAT. If they aren't, that just means that their destination address won't be rewritten.

Not rewriting the destination address of a packet is not the same thing as dropping the packet. The router will process the packet using its original destination address, and if that address is one of the machines on the LAN then that's where the packet goes.

Re: IPv6 solution...

"many users will just stick with v4 for intranets and just allow their ISP to handle the IPv6 question as they see fit. If the problem is being handled invisibly, behind the scenes with no input necessary from you, why worry about the issues of migrating your own intranet system over?"

Well, that's a big "if". How is your ISP supposed to deliver v6 packets to machines over your network? They'll deliver them to your router, but you need to handle the last part.

It's true that things will normally be handled automatically without you needing to do anything, but what that means is that your router picks up a prefix from the ISP via DHCPv6-PD and then uses it to deploy IPv6 on the local network. Short of using proxies, you can't really get around having it on your local network.

Can you load https://ipv6.icanhazip.com/? If not then your ISP/modem aren't handling v6 for you in the way you think they are... and if you can, I think you'll find that you have v6 on your intranet. That, or your browser is proxying everything through Apple/Google or something similar.

Re: IPV6 over my dead salary

You probably couldn't.

v6 doesn't require your hardware address be embedded in your IP address. It increased both the minimum required packet size from 576 bytes to 1280 bytes, and the maximum size up to 4 gigabytes, but the actual packet size of the network is an L2 concern rather than an L3 concern, so v6 can't change it in the first place.

I've seen a lot of people who thought they could do better than v6, but they can usually only suggest things that wouldn't work at all, things that v6 already does, or things that they clearly haven't thought through the details of. Or they refuse to tell anybody what their better ideas are. If you think you can do better then go ahead, but you already hit the first two points.

Starlink tells the world it has over 150 sextillion IPv6 addresses

Re: why not start from scratch and try and design something functionally better?

They didn't even try!

IPv6 is mostly a clone of IPv4 with bigger addresses. There's some amount of difference in the details (like NDP vs ARP) but fundamentally it all functions the same way. The addresses work the same as they do in v4, subnetting works the same, routing works the same, it runs over the same networks, DNS works the same, TCP or UDP work the same. You can't really call it a "from scratch" design.

And having over 2.5 billion users, and growing, is an odd definition of failed.

Re: 2^128 addresses

It's not wasteful. Those bits serve a useful purpose, and a /56 is the same fraction of the v6 address space as one 0.4% of one TCP port of one v4 address is of the v4 space. Would anybody argue that allocating 0.00000006 IPs per customer was wasteful in v4?

They needed the full 4.7 sextillion addresses, apparently.

It's implausible that they needed all of those IPs, but needing more than 4 bits of subnetting space isn't difficult. Especially if you start doing sub-delegations inside your own network (which is ideally done on multiples of 4 bits because that means you can subnet by character in the IP address rather than needing to get your subnetting tables out).

Thinking in terms of number of IPs is v4 thinking. You don't bother doing that in v6, because there's so many of them it just doesn't matter.

Re: A little back of the envelope math

Yes, it's partly that.

The main reason is to reduce the size of routing tables - if you give everybody overly large blocks then they won't need to expand as often, and if you allocate sparsely then expansion doesn't necessitate splitting the block in two. For example, if you get a /32 from RIPE then they leave the next 7 /32s unallocated, allowing you to expand your allocation up to a /29 without needing to deal with a second disjoint block. RIPE can spend the 3 bits on doing this because they themselves have an overly large allocation, and this logic applies at every level.

For that matter, imagine trying to get a second block from your ISP if you ran out of the first one. Getting an overly large block that you can't possibly completely use is surely better than needing to try and get that request through your ISP's support line.

As for the /64 subnet size, SEND (which is an approach to securing neighbor discovery) uses the 64 bits of host IP space to store a cryptographic key. But even if you aren't using SEND, a /64 does indeed serve as a huge sparse space that's impossible to exhaustively scan: it takes something like a million petabytes of traffic to exhaustively scan a /64, per port.

(It's possible to narrow the search space a bit from "every single IP", since people often use addresses like ::2, ::1000 etc, and with SLAAC you can sometimes narrow things a little by scanning addresses that correspond to specific OUIs. But even one single OUI is a gigabyte of traffic per port, or 65 terabytes for all ports. That's a far cry from the setup most people have on v4, where scanning the 65k ports on the router is enough to reveal every publicly accessible server on the entire network. I'd expect that "randomly scan for vulnerable servers" isn't going to be a viable technique in v6, which will improve the overall security of the Internet to some degree. This is backed up by looking at tcpdump for my routers, which see a great deal more scan traffic on v4 than they do on v6, and the vast majority of what I do get on v6 is either to IPs that were scraped from TLS cert transparency logs, or it's to unused addresses.)

Re: A little back of the envelope math

There's no such thing as a "backwards compatible 64-bit deployment", or at least not in any sense that doesn't already apply to v6 - because the core problem is that v4 isn't forwards compatible with addresses bigger than 32 bits. No amount of "use less than 128 bits" will help with that, unless you go all the way down to 32 bits which would be pointless since at that point you can just use v4.

That's kind of the reason we needed a new protocol in the first place.

128 bits isn't particularly stupid either. 64 isn't enough and 128 is the next power of 2 up from that.

Starlink helps eight more nations pass 50 percent IPv6 adoption

Re: List of IPv6 deployments by country

You're not going to get an authoritative list, but https://stats.labs.apnic.net/ipv6/ is your best bet if you want a breakdown by ISP. If you just want by country then there's a few extra options:

https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption

https://radar.cloudflare.com/reports/ipv6

https://www.facebook.com/ipv6/?tab=ipv6_country

IPv6 may already be irrelevant – but so is moving off IPv4, argues APNIC's chief scientist

Re: Hence, IPv6

It could potentially still be retrofitted to v4. Keep the current addressing scheme as the base so all existing routes still work. Append the extended postfix address as header options(*).

v6 already does this. It uses a special next-protocol number (41, like TCP is 6 or UDP is 17) rather than a header option and then puts the address bits at the start of the packet payload, but that's not a significant difference.

They already did more or less exactly the method of backwards compatibility that you're suggesting and it still wasn't enough to stop you from complaining and trashing them for not doing it. Don't you think that's a bit unreasonable?

Re: Opinions do differ

The designers of v6 didn't ignore interoperability, reliability, or security concerns. All of those were considered and handled in v6. Neither does it somehow mandate that all devices have access to every other device; consent is granted in exactly the same way it is in v4 (i.e. by operators granting the level of access they want in firewalls). You're attacking a strawman here, not the protocol that actually exists. That's not a failure on the part of the people involved in v6, it's a failure on your part to understand what they've done.

What would iterative progress even look like for this? It's proving to be hard enough to deploy one new L3 protocol Internet wide, I'm not sure that doing that four times instead would be any better.

Re: Opinions do differ

It's not actually possible to make v6 be the exact size it needs to be, so "overkill" and "underkill" are your only options. Given how long it's taking to deploy v6, I think it's better we aim for overkill rather than underkill, so that we don't need to go through all this again.

Also, it did need to be bigger than 64 bits, and the smallest power of 2 after 64 is 128. Making it a power-of-2 number of bits isn't absolutely necessary, but can you imagine the wailing and teeth gnashing we would have got if it wasn't?

Re: Opinions do differ

"the fact that they are hell when used in clustering keys in databases" is basically the reason. Routing tables are essentially clustered indexes of the IP address space. If you couldn't summarize/aggregate/cluster IPs into networks, you'd have to track where every single in-use IP currently is, instead of just every group of networks.

Re: ipv6 is a mess and ipv4 will not die anytime soon

IOT thingies that don't support v6 do not block you from using v6 on your network. There's no need to drop 1000 euros on a new TV just for that. You're making up problems that don't exist.

Re: Configured IPv6 on my network..

That's not how "IPv6 DNS" works. Clients ask for both A and AAAA simultaneously, and asking for an AAAA record for a domain that's v4-only doesn't return NXDOMAIN, it returns NOERROR. DNS returns the same answers regardless of whether you query it over v4 or v6; "NXDOMAIN" tells you that the hostname simply doesn't exist, so there would be no reason to try asking another server over another address family when you get it.

If your DNS server is returning NXDOMAIN for domains that exist then it's simply broken. Don't blame v6 for that; either fix the server or replace it with one that works. Disabling the entire protocol isn't a necessary or sensible response. Google run a popular public server you can use if you don't have one of your own.

Re: An Alternative reason why IPv6 hasn't been deployed

That has nothing to do with NAT. Every connection can be logged at the carrier with or without NAT.

Re: ipv6 is a mess and ipv4 will not die anytime soon

Where does this "designed by academics" thing come from? The RFCs are credited to people like Xerox, Ipsilon Networks, Cisco, IBM, Nokia, Ericsson, Sun, Hewlett Packard, Microsoft, Google - all major players in the industry (either presently or in the past), not academics. You have to search quite a few v6-related RFCs to find any academic credits at all. It simply does not appear to be true.

> If it had just addressed the core problem, 32-bit addresses, in a way that was directly compatible, by now we might have had 100% support

If it had just done the impossible then yes, perhaps we would have.

v6 mostly does just address the core problem of 32-bit addresses, and in as compatible a way as possible given the design of v4. If you think I'm wrong, feel free to explain how it could have been done in a way that you'd count as "directly compatible". Every time I ask people to do this, they either suggest something that v6 already does, something that wouldn't even work, or they give some half-brained idea where they clearly haven't bothered to think through any of the details. That, or they just refuse to share the method.

If it was so easy to make it directly compatible then someone would have been able to say how to do it by now.

China pushes for network upgrade blitz as IPv6 adoption slows

Re: There's more that you have to be careful of

v4 supports option headers, so you'd have to explain why they haven't done it yet in three decades of the existing protocol.

Or there's TCP out-of-band data, which is harder to filter. Why is it just v6 that gets all of the fear-mongering?

250 million-plus reserved IPv4 addresses could be released – but the internet isn’t built to use them

Basically none of this is accurate. The whole /56 is routable, you only have 8 bits of subnetting but the entire address space is useful. The standard subnet size is /64 for a few reasons, including SEND and the security benefits of being very sparse. Using the MAC to generate an IP isn't _that_ stupid an idea, but I agree it does have some downsides, but not much stuff does that these days.

It's not completely incompatible with v4. It's compatible in plenty of ways, many of which are actively in use. The remaining incompatibilities aren't a design flaw in v6; if they're a design flaw at all then they're a design flaw in v4. v6 might not be at the absolute unbeatable pinnacle of protocol design but it's not a particularly bad design either.

Over 2 billion people are already using v6, so it does appear to be what people are deploying.

None of that stuff is ignored, you're just seeing a serious amount of FUD from people who don't know much about v6, or often networking in general.

The primary security concern I see is "it doesn't have NAT", which is nonsense because NAT doesn't give you any security. The complexity isn't that big, especially compared to v4-in-practice which involves a lot of NAT. The privacy problems are also nonsense given the presence of temporary addresses, RFC7217 and randomized MACs (...and HTTP cookies which are used for the majority of tracking). The addresses are SUPPOSED to be long, that's kind of the point; rather than ignoring it they added AAAA records to DNS and also allowed abbreviating addresses with lots of zeros in them.

All of this has been explained repeatedly, both in comments here and elsewhere.

No it won't. NAT only affects outbound connections, so you'd have to test for it with an outbound connection. You can determine if you're behind NAT by connecting outwards to a remote server, and checking whether the source IP of that connection as seen by the remote server is one of the IPs assigned to your device. (Note that proxying, transparent or explicit, would also change the source IP, but I think/hope that's rare today.)

It's possible to be behind NAT with functioning inbound connections, and also to not be behind NAT but still not have functioning inbound connections. Many mobile networks block inbound connections with a network-level firewall, so the latter is fairly common.

Re: Anyone not heard of IPv6?

Putting some numbers on it, the difference in size between v4 and v6 is the same as between 640 kilobytes and 50 billion yottabytes. 16GB is only 26000x times bigger than 640k, whereas v6 is 80 trillion trillion times bigger than v4. They're just not on the same scale, to the point that it's not reasonable to blindly argue "other things weren't enough so this isn't either".

We certainly can run out if we're stupid (e.g. there's still only 256 /8s in v6), but we can be stupid with any size address space. v6's 128 bits does seem to be large enough to avoid running in maximum-conservation mode if we're not stupid about it, which isn't something you can say about v4.

IPv4 address rentals to mint millions of dollars for AWS

> Just adding digits is something telcos have been doing for decades, and it works

It works for telcos because the phone network uses variable-length addresses. It doesn't work for IP because v4 packets have a fixed width for addresses, as does the socket API, as do important protocols like DHCP and DNS. So yes, the IETF did have to be different - because they were extending something that works differently.

NAT, ATM, decentralized search – and other outrageous opinions from the 1990s

Re: Living with NAT became more important

Of course you shouldn't, but that doesn't mean it's not possible. You can't rely on an attacker being kind and polite enough to not send you packets you think you shouldn't be getting.

It's true that routers can't do anything with packets they don't receive, but if they do receive a packet addressed to your LAN then they can and will route it on to your LAN, even when there's no NAT state table entry or static rule configured. NAT can't prevent your router from receiving such a packet either.