Posts by Nanashi

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.

Re: Living with NAT became more important

I've been talking about the most basic of networking basics the whole time. You're the one that's been getting them wrong. It doesn't really get much more basic than "If your router receives a packet, it'll forward it according to its routing table".

You can receive inbound packets with an RFC1918 destination without things being badly broken; all it needs is for your ISP or someone else on your immediate upstream network to send them to you. And they won't get blocked by NAT.

Re: Living with NAT became more important

I know how NAT works already. What we're talking about here is unsolicited inbound connections that don't match any port forwards. NAT isn't applied to these connections, so what NAT does when it's applied doesn't matter, because it's not being applied.

> The destination address in the packet header is the EXTERNAL address for the gateway - it is NOT an internal (usually RFC1918) address.

No, it might an internal address. Packets can technically arrive with any IP whatsoever in the dest IP field, which of course includes whatever IPs are being used on the local network. In fact the point of having a gateway is so it can receive packets addressed to the machines behind it.

If a packet comes in addressed to the router, and no NAT state entries or port forwards apply to that packet, the router still knows where to deliver it: it gets delivered to the router itself. But nothing guarantees that an inbound packet will be addressed to the router, and if it happens to be addressed to a machine on the LAN then that's where it'll get delivered.

Re: Living with NAT became more important

With whatever IP was already in the header when the packet arrived.

Re: Living with NAT became more important

There is a way to know where to send it. IP packets have a "destination IP" header that specifies where the packet is meant to go. The router simply looks at that.

You can put in bold and capitalize it all you want, but NAT won't actually do that. This is something I've tested multiple times on a real network - applying NAT to outbound connections and with no state table entries or port forwards, the unsolicited inbound traffic worked just fine. If NATing outbound connections somehow dropped inbound ones, then why weren't my inbound connections dropped when I tried it?

In my last comment I said that it's hard for most people to test this, but your hosting facility with its /24 would make it easy for you if you wanted to try yourself.

> What is annoying is that too many people have jumped on this as meaning a connection cannot be secure without it

Yeah, exactly. That's partly why I try and explain this to people. It should be immediately obvious that a connection can be secure without NAT... not just because there are other ways to secure it but because NAT doesn't secure it in the first place.

Re: Living with NAT became more important

> Packets that do not match will be dropped by the router doing the NAT, meaning that it is pretty much as safe as a firewall rule.

This is the part you're getting wrong. When a packet doesn't match any active NAT translations or static rules, the behavior isn't "drop the packet", it's "don't apply NAT to the packet". The packet will still be processed by the rest of the router, which will be perfectly happy to route it onto your LAN if the firewall doesn't drop it.

This is quite hard to test for most people, because most people don't have the address space to connect their LAN to the Internet in the first place (which is why they're using NAT), so they need to test from a machine connected just upstream of their router, and also because firewalls are very common in routers and can be difficult or impossible to disable.

Re: Natty

>Note that this diffusion occurs out-of-the-box with IPv4+NAT - no configuration, additional software, or expert knowledge required.

It also happens on v6 without NAT, thanks to privacy extensions which are typically enabled without needing configuration, additional software or expert knowledge.

>If you can post the link to the relevant mailing list archive or similar I'll gladly be corrected. My current impression is that IPv6 was designed on a dogmatic "everything should be host to host because that's how the Internet was originally intended" while ignoring the contemporary real world consequences of that architecture.

Of course I don't have a convenient mailing list quote covering this. They didn't sit around having inane conversations about how they weren't doing something that makes no sense in the first place. You're right that v6 was designed to have enough address space for everyone; my correction here was to point out that NAT doesn't provide increased security and that v6 has a thing to obscure which machine is doing a given connection, and therefore that v6's design isn't "myopically ignoring security and privacy". In fact security and privacy are both covered in v6.

>Another example: After connecting to a VPN for privacy I checked online if it was working as intended. While my IPv4 address was detected as that of the VPN server, my original IPv6 address was still leaking. Ah yes, my bad, forgot to disable IPv6 on the new router. Your average home user has no chance.

This is simply an example of you wanting to put your traffic over a VPN but forgetting to do so (and then, apparently, disabling the entire protocol stack for some reason instead of doing what you wanted to do in the first place). It has nothing to do with the design of v6.

Average home users stand no chance with anything. It's up to us to know what we're doing, for their sake, or else to step back and leave things in the hands of people who do know.

>NAT isn't more secure in itself. However it's a lot easier to secure a router (and even that gets fraked up as we know) which has a limited task and fixed hardware compared to securing a general purpose user device.

This is true enough, but why is NAT even being mentioned here? If anything it gets in the way of securing the router, because if you think NAT is giving you security, you're more likely to fail to implement actual security (i.e. a firewall).

Re: Living with NAT became more important

If NAT worked like that then it would indeed be tantamount to blocking, but it doesn't. NAT has no routes, whether you define a port forward or not. Routes live in your routing table, and your routing table still exists and works like normal when you're doing NAT.

Just to be completely clear: inbound connections work both to and over a router that's NATing outbound connections, without needing to configure a port forward. The port forward is used in situations where the inbound connection is addressed to the wrong machine, but connections addressed to the right machine can be left alone and will work. Even if "the right machine" is one that you didn't want to permit a connection to.

Re: Living with NAT became more important

NAT doesn't actually block incoming connections. The need to do that is served by firewalls, not NAT. It's true that before NAT was common firewalls weren't either, but that doesn't mean that NAT blocks connections.

Also the IPs used for outbound connections in v6 generally aren't tied to a specific machine either; machines pick random addresses and cycle them regularly.

Re: Natty

Nah, this wasn't ignored. NAT simply doesn't provide any increased security, and privacy extensions are a thing.

Data-destroying defect found after OpenZFS 2.2.0 release

Re: ZFS here we go again

The bug here is with hole detection, for sparse file support. Userland software asks "is there a hole in this file?" and in some circumstances ZFS has a small window in which it incorrectly claims there's a hole when there isn't. That's the entire extent of the bug; the data is still correct and uncorrupted in memory and is written to disk correctly, and if you issued a read for the data then you'd get the correct data back. But if you were checking for holes in the file so you could skip reading those parts, you're not going to read those parts.

I'd argue that describing this bug as a "data-destroying defect" is clickbait, since it doesn't do that, it just gives you the wrong idea about whether there's any data in a file, and even then the wrong answer is temporary (although I do not mean to claim that this bug causes no problems or that data loss isn't one of the possible eventual outcomes of the incorrect hole detection).

This isn't the sort of problem that checksums in the filesystem can catch. It would be difficult to use checksums to do any validation on a read that doesn't happen.

China requires any new domestic Wi-Fi kit to support IPv6 and run it by default

Re: Big Brother is watching

> IPv6 is a technology for big managed networks. It's now a critical part of the internet backbone. It offers less than nothing to homes and businesses.

Networks like the Internet. The vastly increased network space is useful for homes and businesses wanting to connect their own networks to the Internet; that's not "less than nothing". In fact it's something almost every home and business is doing.

It's also not trivial to scan the active address space, or to identify end points. If you run, let's say, an SSH server on a random v4 address, it's going to get a constant stream of login attempts within minutes of being set up. On v6, a server running on a random address is unlikely to see any at all. And there's no way to identify a given end point unless the end point itself gives you identifying information, which most don't.

(That's not to say there aren't ways of finding active hosts, but exhaustively scanning the space is completely out, unlike on v4 where it's trivial. Probably the biggest issue is certificate transparency logs, which pretty much give you a list of hostnames that are likely to be running servers. But you don't need a TLS cert for SSH, and you don't have to accept SSH traffic on the same hostname/IP as HTTP traffic -- there's no shortage of IPs going around, so you can just accept SSH on a different IP to HTTP. And there will be no easy way to find that IP.)

AWS: IPv4 addresses cost too much, so you’re going to pay

The entire class E range is only 16 /8s, that would also not even be a year of allocations.

Re: Without comment

You don't need to make it a question, that's what I said.

Of course, those people would need to actually get v6 first.

There isn't that much unused address space out there. It's not worth the effort.

We were going through one /8 every three weeks or so before IANA runout, back in 2011, and demand will only have gone up since then. You could reclaim a dozen entire /8s and still not have enough for even a year of allocations. Plus there just plain isn't enough v4 address space out there in total, no matter how it's allocated, so all this is going to achieve is to buy some extra time to deploy v6... which we would just squander, because if you're not doing v6 at this point then it's not due to a lack of time.

Re: Without comment

You're better off with just v6 than with just v4. I get a never-ending stream of hack attempts coming in over v4, but v6 is almost completely quiet (and my v6 subnets are big enough that it's hard to even find working IPs in the first place).

Public websites are mostly stuck with doing v4, but v6 gives a minor performance boost which translates into more users (and therefore more income) so not doing it is often not such a great choice.

How a dispute over IP addresses led to a challenge to internet governance

Re: Time for IPv8

How would that be an easier upgrade than v6 already is?

Making it only 64 bits also seems like the opposite of "more sane" to me. Migrating the L3 protocol on the Internet is extremely difficult and setting ourselves up for needing to do it again is not sane at all.

Re: The issue with V6 is... NAT

What you're describing here isn't really possible on the client side. How would the IPv4-only devices on the LAN specify which IPv6 address to send their packets to?

Re: Time for IPv8

The line you've quoted only applies NAT to outbound connections. The lines that decide whether or not a connection is permitted (aka the actual firewall) are elsewhere in your configuration. The state tracking, which both of these separate functionalities depend on, is done elsewhere in the kernel.

Re: Time for IPv8

You're wrong; NAT doesn't serve as a firewall at all. The problem with your argument is this part:

but because it doesn't know what machine to send it to

which is incorrect. Your router knows where to send each incoming packet, because each incoming packet has a "destination IP" field specifying where it should be sent.

IPv6 for Dummies: NSA pushes security manual on DoD admins

Re: SLAAC on Android

Only if the device isn't using privacy extensions, RFC7217, or randomized MACs.

I don't have any stats on deployed devices, but I suspect most of them have at least one of those turned on, so I doubt this helps Google's tracking much at all. Especially when most of their phones are signed in to a Google account and continuously phone home anyway.

Re: IPv6 on Windows is pretty much an easy hackfest

So, basically no different to DHCP on v4. And the mitigation is the same as it is in v4: layer 2 security via DHCPv6 Guard.

This is mentioned in the very guidelines that are the subject of the article you're replying to. The guidelines that aren't even five pages long.

Re: echo "1" > /proc/sys/net/ipv6/conf/${DEVICE}/disable_ipv6

Hence "don't". At this point you should be using it, not disabling it.

Re: echo "1" > /proc/sys/net/ipv6/conf/${DEVICE}/disable_ipv6

Some "advice" this is. It will break v6 completely. Just don't.

Huawei dangles developer incentives to sell Harmony OS around the world

Researchers have found that Chinese DNS resolvers fail two thirds of the time when handling IPv6 address queries. IPv4 queries fail at a rate of one in eight.

Like I said in the comments to that article, their definition of "fail" included lookups that successfully returned zero addresses. They weren't measuring failing queries, they were mostly measuring how many domains had v4/v6 or not.

Two thirds of DNS queries for IPv6 hosts sent to Chinese resolvers fail, researchers find

Re: What does failed mean?

as if so then it's just modelling the IPv6 takeup rather than any issues with the resolution infrastructure etc...

I wondered that too, and that seems to be exactly what they're doing:

For each response, we extract the requested domain (the QNAME) from the Question portion, and check if the response contains a valid answer (e.g. for an A query, at least one RR in the response is an A record of the requested domain). In this paper, we are interested in failures caused by DNS infrastructures instead of NXDOMAINs (e.g. typos). However, we do not have the response code (e.g. ’NOERROR’, ’NXDOMAIN’ or other status) in our dataset.

If they don't have the error code, they have no way to distinguish between the query failing or it successfully returning zero results, and they're counting both as a failure. And worse:

Moreover, our dataset does not allow us to inspect failed queries that did not trigger a response (e.g. due to packet loss).

...which means they can't even detect most actual failures. They do try to accommodate NXDOMAIN, by filtering out domains that never returned an A or AAAA record, but they don't do any per-record-type filtering:

When limiting to domains whose query frequency exceeds 100, only 7.8% of domains have a success rate exceeding 95% [for AAAA queries], while about 60% of domains have never been successfully resolved. Again, given that we only include domains that have been successfully resolved (considering all query types), this suggests that there are infrastructural limitations in how DNS supports IPv6.

There's no way their results support that. "Hostnames can have A records without having AAAA records" isn't an infrastructural limitation in IPv6 support in DNS.

They also say this:

the failure rate for AAAA queries is as high as 64.2%, almost 3 times of that in 2012 [8].

I checked that reference (https://dl.acm.org/doi/pdf/10.1145/2486001.2486018) and their results are 78% of domains returning NOERROR (successfully returning zero or more results). In other words, the large number of domains that have an A record and no AAAA record are counted as successful by that paper but as failed by this paper, making the numbers incomparable, but they go ahead and compare them anyway.

Either they didn't realize what they were doing there, or they were aiming for a clickbaity paper. Either way, it's not a good sign.

IPv6 is built to be better, but that's not the route to success

Re: Won't happen in my lifetime

v6 isn't forcing you; it's allowing you (compared to v4, which generally forces NAT). You can still do everything you do on v4. v6 also has privacy extensions to mask your IPs without causing the problems NAT causes. They use a different method (masking the IP with a different, random IP+port instead of a different, fixed IP+random port) but it achieves the same general goal.

I think you're worried about something totally unimportant here. Your browser is a far bigger risk to everything than people seeing your IPs (without even being able to connect to them!) is. But v6 has your back anyway.

Re: "I don't always need to look up the address of a bit of kit I need to contact"

It doesn't toss that knowledge out. Most aspects of v6 function exactly the same as v4, just with longer addresses.

The extensive retraining for security shouldn't be that extensive -- if you know how to secure a v4 network, then you already know how to secure a v6 one, so just do that. No retraining needed. Not having to put NAT on top is a simplification that makes everything easier.

As for using 48-bit addresses... it wouldn't be enough. We don't want to be spending all this effort deploying a new protocol that's still so small that we need to continue being stingy. It would also require doing all of the same things that we've needed to do to deploy v6, and would have the same compatibility properties as v6 does, so it wouldn't help on those fronts.

Re: Won't happen in my lifetime

Well... it's worth noting that they don't really have sufficient address space. It's almost impossible to get more than one v4 IP from most ISPs, yet almost everybody has an entire network of devices that they want to attach to the internet, not just one single device.

I imagine larger and larger ISPs are going to end up moving to CGNAT too, since AWS and friends are always in the market for more v4 space, so even getting one single v4 address is going to get harder and harder. This is already happening frequently in Germany and some nearby countries, and I don't see any reason for it to only happen there.

Re: Won't happen in my lifetime

It sounds like you want to use a proxy server to reach the internet, not routing. v6 won't stop you doing that. Even if you route, it has privacy extensions, which masks the number of devices you have.

You can easily set up a private network which a random stranger on the internet can't access. Routers will typically do that by default, so it's no harder than just plugging them in and using them.

You'll be replacing your hardware at some point or another. Just make sure that the replacements support v6 when you do, and you'll get v6 support along with the upgrade that you were paying for anyway.

It seems like most of your issues aren't really an issue.

It's interesting that you think v6 is actively hostile to NAT. The only thing v6 does against NAT is to give you enough address space to not need to use it. Apparently you won't use NAT unless forced into doing so...? But that's inconsistent with the rest of your post.

Re: NAT isn't your first line of defense, the stateful firewall is.

No, it doesn't. All it does to incoming packets is rewrite their dest address header, and only if they match a connection that's being NATed (or a static port forwarding rule); it doesn't decide whether or not to drop incoming packets.

Re: Won't happen in my lifetime

It's not against RFC1918. You're allowed to send packets with RFC1918 destinations through routers.

It would be a bad thing to do, but if you could rely on "nobody ever does bad things" to keep you safe then the world would be a much nicer place.

Re: "I don't always need to look up the address of a bit of kit I need to contact"

It's not really niche when it has almost two billion users. v6 is just hard to scan because it's so huge. Exhaustively scanning one /64 requires something like a million terabytes of traffic. If you're on a regular, slow 10 Gbit/s link that'll max it out for thousands of years.

(Obviously there are methods of finding hosts that aren't exhaustive scans... and people do use them on v6. You just won't see a constant stream of opportunistic scan attempts on every single address for every minute of every day.)

IPv4 addresses aren't exhausted, just their allocation is. a good 90% of them just aren't seen on the internet.

When we say exhausted, we mean that people have to take measures to conserve addresses due to not being able to get enough of them. The beginning stages of exhaustion happen when people start needing to do that. We're deep, deep into it for v4.

Also, due to the way hierarchical aggregation and routing works, most individual IP addresses don't end up assigned to actual end devices, so "I haven't seen any internet traffic from 90% of addresses" doesn't mean that v4 is only 10% used.

I'm also going to point out that there are more individual devices than there are v4 addresses, so there's not going to be enough no matter how you slice them.

TBF if the internet core was run on v6 with BGP and everyone used NAT and RFC1918 addresses internally, there is no need for the added complexity of v6 inside an organisation

You mean the reduced complexity... and you would in fact need it, since v4 doesn't handle more than 32 address bits.

the NHS internally uses the RFC 1918 class A space and it hasn't exhausted it yet.

But the fact that they're using it at all is an indication that v4 is insufficient. Why go to all the added complication otherwise?

IMHO when they designed v6 they went overboard on the address space

Absolutely! Overboard is good. We want to have more address space than we can use, because the alternative is that we'll end up using it and will need to deploy another extension. As you might have noticed, that's a very difficult, expensive, long and drawn-out process that we really only want to do once.

Re: Won't happen in my lifetime

To be more accurate, your ISP can't route anything to that network because they're not connected directly to that network. To get a packet to your network, the ISP has to send it to your router first, and then your router passes it on.

You should realize, however, that your ISP can do that. They can send whatever packets they like to your router, and they can put 10.0.3.19 in the dest header of those packets if they want, and your router will happily route it onto your network. NATing your outbound connections won't stop these inbound connections either, although a firewall configured to block inbound connections will.

Also, this behavior is exactly the same regardless of what network range you're on. It would work the same even if only one machine had 10.0.0.1. It would work in any network range, v4 or v6, not just the RFC1918 ones.

Re: People do not want it

I wasn't overlooking that question. I was asked it multiple times, and answered it each time. It's just not relevant to my point of "your security isn't being provided by NAT".

Re: Won't happen in my lifetime

v6 networks aren't automatically routable. It's the router that does the routing, and the router can choose not to route or to drop whatever traffic it likes.

To be clear, that means you don't need NAT to set up a non-routable network. (And, er, you generally don't want a non-routable network anyway; most people want their network to be connected to the Iinternet. Otherwise you won't be able to reach any websites, services etc that are on it.)

If you want internet connectivity but don't want random people connecting to your machines, a default-deny inbound firewall is the way to go, and has been since forever, including in v4.

I didn't dodge the question in my previous post. Nobody asked about routability, and I did answer the question about "locks" (which I took to mean access control).