* Posts by Nanashi

352 publicly visible posts • joined 19 Sep 2016

Page:

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

Nanashi

Re: Won't happen in my lifetime

The same way you do it in v4? You put a firewall on the router that rejects inbound connections by default. It's the exact same firewall you already need on v4 to be secure, so you already know how to do it.

If you're using iptables, it looks something like this:

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

-A FORWARD -m state --state INVALID -j DROP

-A FORWARD -i lo -j ACCEPT

-A FORWARD -i lan0 -j ACCEPT

-A FORWARD -j DROP

Nanashi

Re: Won't happen in my lifetime

Perhaps you should first explain why you think you'd need to set locks on every single device for v6.

That's not necessary. You just set the locks on the router like you do in v4.

Nanashi

Re: NAT won't block it.

Wrong. What NAT does is make your entire LAN appear to be a single host to the WAN.

No, it's right. Your description is more of a high level "here's a rough idea of what it does", not a low-level description of how it actually goes about doing it. Those low-level details matter.

* Private IP address - Dropped immediately. Least-wise I doubt anyone has ever implemented a NAT system that did anything other than immediately drop the packet since by definition it is invalid.

You should test! Linux accepts the packet. So does every other NAT that I'm aware of the behavior of (I haven't tested everything).

* Public IP address - if it doesn't match the router's, drop it.

That's not accurate. It'll go through the router's routing tables like normal.

* Public IP address - if it matches the router's then look in the connection mapping table for a match. If found change the destination address to be the private address of the initiating host and send the packet onto the LAN. If no match found in the table, give up and drop the packet.

Also not accurate. If there's no match in the table, it doesn't drop the packet, it just... doesn't change the address. The packet then gets delivered to whatever IP it was already addressed to.

To be clear, it's extremely common to deploy a firewall that does do the various drops you're describing here. It's common precisely because NAT won't do it. The CPE you're running in your house almost certainly does drop this stuff, because it has both NAT (for v4) and a firewall.

I'm simply pointing out that it's not NAT that's doing the dropping.

Nanashi

Re: People do not want it

you now acknowledge that the router must check the nat table for a corresponding entry to know which internal host to forward the traffic to.

Not quite. The router has to check the NAT table to see if the dst header on an incoming packet needs rewriting. If it does, it's rewritten, otherwise it's not rewritten. Actually routing the packet is done separately, by the not NAT parts of the router.

Now, the final hurdle for you, how can the router forward the packet to an internal host if it has no corresponding nat entry that matches the src-ip, src-port, dst-ip, dst-port details in the packet......

Easy: it looks at the dst IP header of the packet. Same way any router does it.

to save on gears grinding, the answer is that it can't forward something it has corresponding entry for as it won't know which internal host to rewrite the dst-ip & dst-port details to.

It can, because rewriting isn't necessary to forward a packet.

If the dst IP header of an incoming packet contains an IP from the network range on your LAN after NAT has rewritten the header, your router will route it onto the LAN.

If the dst IP header of an incoming packet already contains an IP from the network range on your LAN when it arrives at the router... your router will still route it to the LAN. It doesn't care whether the NAT stage rewrote the header or not.

Nanashi

Re: People do not want it

Neither of those articles are relevant. They're talking about how packets go over the internet, whereas I'm talking about NAT. The question isn't "how do I get a packet to your router", it's "what does NAT on your router do to the packets that arrive at it".

The answer to that question is that the destination address (for a packet coming in from the WAN) is looked up in the NAT state tables, and if an entry exists then the address is rewritten per the state entry, and if no entry exists then it's not rewritten.

Notice that nowhere in the answer is "the packet is dropped". That's because NAT won't drop the packet. Again, this is something that I've tested on real networks, and it works like I'm saying it does, not like you're saying it does. And, again, you can test it yourself if you don't believe me.

The fact that we can get this deep into a reply chain and people still can't get their heads around "NAT doesn't drop packets" just goes to show how badly people understand its behavior.

Nanashi

Re: Scary!

It shouldn't be terrifying. All it means is that no other machine on the internet is using the same IP at the same time.

You'll still be the one to decide whether those devices are reachable or not.

Nanashi

Re: People do not want it

If I want to get to your 10.x address from my public 9.30.1.30 address how do I put that in the ipv4 packet?

You put the 10.x address in the dest field, like I said.

You put the dst-ip in the dst-ip header but how does my isp or any intermediary know to send my ipv4 packet to the public ip of your router and not to literally anyone of millions of other public IP’s of end point routers for onward routing?

They don't. Like I said! You'd need to be on the immediate upstream network to arrange for a packet with an RFC1918 address to arrive at your router's WAN interface.

NAT is exactly like that port forwarding but dynamic [...] and forwards to that machine.

Okay, so, here's the big question: what exactly happens when a packet arrives at the WAN interface and it doesn't match an active NAT state table entry?

I've tested this, multiple times. The answer is that the packet is routed based on whatever IP is already in the packet. If that IP is the router's IP, then the packet is delivered to the router itself. If the IP is from the LAN-side network, then the packet is routed to the LAN network.

To be clear, the packet is not dropped, not unless you also configure a firewall that rejects new inbound connections.

If you think I'm wrong about this, then please explain why I see it happen when I test.

NAT MUST be stateful, it keeps track of connections, removing closed, old, & dead ones.

Stateless forms of NAT do exist, but okay, the form of NAT that we're talking about here is indeed stateful. But...

If you nat then you have a stateful dynamic firewall.

As I've said multiple times, no, you don't. You don't automatically get a firewall along with NAT. It's usually very easy to get one, and they're commonly configured together, but they're still separate things.

You can test this yourself if you want. Just set a test network up in a few VMs and watch the behavior. You'll see it matches what I've been describing the whole time.

Nanashi

Re: But it will happen

Okay, let's consider the SOHO market.

v6 is obviously overkill here, like it is everywhere. That's a good thing -- you don't want underkill, because that's just another way of saying "not sufficient". It doesn't create much network complication though; v6 networks are simple, unlike in v4 where the combination of RFC1918, NAT, split horizon DNS, VPNs and RFC1918 clashes makes a massive mess.

If your DNS is broken, you fix your DNS. Maintaining working DNS is just part of the basic responsibilities for anyone running a network, SOHO or not.

As for your printers, you probably don't need to access them from outside your network, so you could reasonably stick them on a ULA prefix, meaning they could have a static IP like "fd00::10". That's shorter than almost all v4 addresses. It's not like reading a full, unabbreviable v6 address is that difficult (about the length of four v4 addresses), but you don't even have to do that much.

Also! Having v6 doesn't mean you don't have v4, so what's stopping you from connecting to your printers over v4 if it's really such a big deal?

It feels like you're just listing excuses to justify failing to keep up with moving Internet tech.

Nanashi

Re: Won't happen in my lifetime

Ooh, I'm popular!

Nanashi

Re: NAT won't block it.

I'm talking about NAT. I think I've said it enough times to be clear on that.

Nanashi

Re: People do not want it

No, NAT won't block it. NAT doesn't route anything. All it does is rewrite the src or dest headers on packets; any firewalling or routing is handled by the rest of the networking stack. You don't need a state table entry for basic routing to work.

You can’t directly route to rfc1918 addresses across the internet.

Correct.

Of the billions of systems that have 10.x addresses behind nat how do you know which router to send your rfc1918 traffic too?

If I want to access a network behind your router, then I send the traffic to your router.

ISP’s drop traffic with rfc 1918 dst IP’s.

They should do, at least.

Also how do you send something to your router from the internet with an additional dst ip? TCP packets have just 1 dst ip.

You don't. The TCP packet's dst address would be set to 10.0.0.234.

Because that's RFC1918, the only way to get it to your router would be to have a machine on your immediate upstream network, configured with a route for 10.0.0.234 via your router.

When the packet arrives at your router, it won't match a NAT state table entry, so NAT won't touch the dest IP. Your router will then follow its routing table entries and route it to your local network.

Nanashi

Re: NAT won't block it.

No, it knows what to do with inbound packets: it delivers them to whatever IP is in the "dest" header, or perhaps forwards them on to another router to handle. If it's tracking the connection that the packet belongs to, then it'll rewrite the header first and then deliver it, but if it's not tracking the connection it'll just deliver it to whatever IP is already there.

There is simply no way you can launch an attack against my 192.168.1.106 from outside my LAN

Uh, yes there is. I just explained how to do it in a post up this thread.

NAT won't stop connections to 192.168.1.106 from outside your LAN, and if you think it does then that's because you've gotten confused about what NAT does and doesn't do.

NAT rewrites the apparent source address of outbound connections. An inbound connection is not an outbound connection, hence NAT does nothing to it. That means inbound connections will either be possible, or not, depending on the behavior of the parts of your network which aren't NAT.

Nanashi

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

NAT isn't a stateful firewall. Stateful NAT requires state tracking and so do stateful firewalls, so they're often implemented together (e.g. netfilter on Linux), but that doesn't mean that NAT is a firewall.

NAT rewrites the apparent source address of outbound connections. That's all it does; it doesn't decide which packets to drop or not drop.

Nanashi

Re: NAT won't block it.

I'd think a packet bearing a destination address in a private ip block would have trouble getting routed over the internet.

Of course, but we're talking about NAT here, not private IP blocks.

Moreover, any decent NAT implementation is likely to take a dim view on (drop) packets coming in from the WAN interface with a LAN destination address.

That would be a firewall, not NAT. NAT implementations don't drop packets, they just rewrite the src or dest headers.

Nanashi

I'd fire you too with answers like that!

It's measurably faster (https://www.youtube.com/watch?v=76XbdedSrww), it's cheaper (no NAT, no split horizon DNS, no RFC1918 clashes, easier-to-understand network...) and it can be deployed incrementally and without outages.

If you need to replace networking gear at this point, either you're running stuff from 2005 still (so it's due for replacement anyway) or you bought v4-only hardware recently, which is your fault.

It sounds like you just don't know what you're doing. That's not v6's fault.

Nanashi

Re: Won't happen in my lifetime

You don't think going from 0.4% of the Internet’s client base to 38% over those ten years means anything?

At that rate, we'll be at 50% in three years. Predicting 10 years for something that ends up taking 13 years is pretty good going for long-term time estimates like this.

Nanashi

Re: If IPv6 had just been a sensible addressing extension then it would have worked

v6 is 128 bits because 64 isn't enough. EUI-64 addresses are 64 bits, and IP provides hierarchical allocation and aggregation on top of that, so it needs to be bigger than 64 bits. The next power of two up is 128.

Also, you might have noticed that deploying a new IP protocol is an extremely disruptive and expensive operation. We really don't want to have to do it again.

> A sensible alternative would have been to just extend the addressing from 32 bits to 64 bits with a direct map from IPv4 address aaa.bbb.ccc.ddd to IPv6 address 0.0.0.0.aaa.bbb.ccc.ddd

Ah, yes, but... how would this help? Even if you have a direct map, v4 hosts still couldn't talk to v6. In fact v6 already has a block allocated to this -- it's ::/96, allowing for ::aaa.bbb.ccc.ddd, exactly as you suggested. It's just not useful.

> One obvious (to everyone except the IPv6 designers) result is that routing in IPv6 is a nightmare needing far bigger routing tables than IPv4.

How is it a nightmare? v6 routing tables are much smaller than v4, due to the sheer size of the address space, which allows for significant aggregation. It's not hard to find ISPs with 500 v4 announcements and one single v6 announcement, covering the same network.

I'm also not sure about this "kitchen sinks" bit.

I think we should be glad the design of v6 was left to people who understood what they were talking about, not the many people in these comments who have no idea what the technical requirements are or how to meet them.

Nanashi

Re: People do not want it

The actual reality is that NAT does nothing to inbound connections. NAT changes the apparent source address of outbound connections; it does nothing to inbound ones. You can't call that "pretty good protection". It's no protection.

For your printer, it's possible to connect to it from outside your network by creating a v4 packet with the destination address set to "10.0.0.234" and sending it to your router. NAT won't block it.

Nanashi

Re: A fully working DNS...

Sure, and it's not like v6 stops you from doing that.

Put your router at <prefix>::1, DNS at <prefix>::53... that's pretty memorable. You'll remember your prefix easily enough after a while, or you can just look at `ipconfig`/`ifconfig` and copy it from there if you need to.

Also, having v6 doesn't mean you don't have v4, so nothing stops you from connecting over v4 to fix your DNS server -- unless you break your v4 somehow, in which case having v6 as an alternative is handy.

Nanashi

Re: IPv6

> But the biggest problem is the lack of interoperability. If you can't build an IPv6 network and see the whole world of IPv4 content, this means you have to build an IPv4 network as well (i.e. dual stack)

It doesn't lack interoperability. I'm posting from a v6-only machine, to this v4-only site, and it's working fine.

If the biggest problem in v6 is one that doesn't exist, then doesn't that mean it's doing a pretty good job?

Nanashi

Re: in IT for 27 years

> We'll remake the entire address paradigm with colons and hex, because we're engineers!!

They didn't remake the entire address paradigm. The addresses are still a block of binary and they're allocated and routed in the exact same way as v4, they're just 128 bits instead of 32.

Writing them in hex is to make them easier (not harder) to deal with: without it, the addresses would look something like "32.1.13.184.133.163.0.0.0.0.138.46.3.112.115.52", which is even more unwieldy, and subnetting when your numbers are written in decimal is much more of a pain than when they're in hex.

Using colons is to disambiguate v6 addresses from hostnames. Otherwise, an address ending in e.g. ".be" would look like a hostname under Belgium's ccTLD.

> And, especially in today's world, who in their right mind wants their IoT device to be directly addressable on the internet with its own 'front door'? Not anyone in their right mind, thank you very much.

If you're going to use a door analogy, get it right: it's like having a front door inside a gated compound. You've got the front door keeping people out, but they can't even get onto the grounds without going through security at the outer gate.

Note that the security of your house depends on the front door and the gate, not on whether your house has a number on the door. Removing the number just makes it harder for you to use the post system, which is unhelpful (because what's the point in an IoT device that can't communicate anywhere?).

Nanashi

Re: CGNAT is a problem for home servers on IPv4, issues with security on IPv6

What security/privacy implications are you even talking about? The situation is no worse on v6 than it is on v4: prefixes are either dynamic or static (mostly dynamic, like v4) and host IDs are randomized and changed frequently (so you can't track individual hosts on a network, like on v4 behind NAT).

v6 doesn't let people "nail you easily"... or at least, any easier than v4 does, because tracking on the internet is already pervasive on v4, but let's just ignore that part.

Nanashi

Re: People do not want it

v6 is not actually at all complicated; v4 tends to be more complicated in practice since you're stuck with also using NAT with it.

The "home NATing router" might be great protection, but none of that protection comes from NAT -- if you don't understand that, then that's a good demonstration of how complicated it is.

Nanashi

Re: Can't disagree with anything there

That's basically what v6 already did.

Nanashi

That's easy to do with v6 too. All you're saying here is that you're either incompetent or have never used v6 for any length of time.

APNIC: Big Tech's use of carrier-grade NAT is holding back internet innovation

Nanashi

Re: I knew this would hapoen

Yes, and that's the approach v6 takes. The third bit is set to 1 to indicate that clients should look for a v6 address rather than a v4 one. It also has a second mode, used for routing over routers that don't understand the normal mode, where that bit is left at 0, and the "protocol" header is set to 41, which indicates that the v6 address can be found at the start of the payload section.

Your suggestion of squatting on someone's existing, in-use v4 range for this has no benefits over the two locations already being used. Existing v4 software and hosts will be unable to use it, a problem which you offered no means of working around.

Apparently it's not so trivial, huh?

Nanashi

Re: That old chestnut

> it’s like getting excited over smart motorways when actually what’s needed is more real lanes not repurposing an existing lane and adding technology that is continually exposed as flawed.

You've got your analogy backwards. NAT is the thing that's repurposing what we've got, and which is continually exposed as flawed. v6 is the thing that's giving us more real lanes.

Nanashi

NAT isn't a security layer. It's not necessary for security and gives you none; all it does is make your network more complicated, which makes its security properties harder to understand.

You'll still be behind a firewall, which will still be secure.

Nanashi

Re: The real problem with ipv6....

No, site local was dropped because it was awkward and pointless. There was no reasonable way to specify which site an address was in, and site local addresses gave no benefit over ULA, so they were just dropped.

Nothing to do with NAT, which is mostly pointless in v6 because of the vastly increased address space.

Nanashi

Re: I've said it before and I'll say it again

That doesn't help in the slightest. There are already multiple ways to indicate that a packet is a different type, two of which (the "IP version" header and the next protocol header) v6 already uses.

I said that you need to come up with something that v6 doesn't already do.

Nanashi

Re: The real problem with ipv6....

RFC7217 and privacy extensions fix the first problem. The second problem doesn't exist; I'm not sure where you got it from, but the top 16 bits are available for allocations. Link-local addresses are used by everybody as part of bootstrapping a global address.

A redesign to fix these problems that aren't problems wouldn't be a good use of anybody's time.

As for DHCP, v6 was developed before DHCP was common. The DHCP RFC only predates the v6 RFC by two years (1993 vs 1995), plus v6 was in development long before the 1995 RFC date and DHCP wasn't ubiquitous until the late 90s, long after the 1995 date. There were multiple other address autoconfig mechanisms in common use until then.

It's kinda unfair to blame them for being unable to predict the future, don't you think?

Nanashi

Re: I knew this would hapoen

> For a new addressing scheme to be adopted it HAD to be an extension of IPV4. This would have been trivial to do

Can you explain how?

The fundamental problem that needs to be solved is that v4 is limited to 32 bits. After all, if it wasn't, we wouldn't need a new protocol in the first place. Can you explain how to make a new protocol, with addresses longer than 32 bits, that extends v4 in the way you claim is trivial to do?

The reality is that this isn't possible, and all of the possible workarounds are supported by v6 (...meaning it's not 100% incompatible at all). I think it's a bit unfair to describe the people that designed v6 as "either too stupid or to full of hubris to even consider that" just because they couldn't do the impossible.

But perhaps all of them were wrong, and you're right, and it was actually trivially possible, in which case you'll be able to tell us how to do it.

Or was your own post the result of either stupidity or hubris?

Nanashi

Re: Addressing only the problem that v4 has?

This is basically what v6 did.

Nanashi

Re: Thanks, but no thanks

No it doesn't. It'll get an IP from the network's subnet, which is different for each network, so the left-hand half of the address will change when you move between networks. The right-hand half will be randomly generated and change regularly due to privacy extensions, so it'll change even if you don't move between networks.

(Of course your apps etc will still track you by IMEI, UUID or whatever, but that has nothing to do with v6...)

Nanashi

Re: I've said it before and I'll say it again

Those things are the backwards compatibility. How did you expect it to work? Magic?

v4 isn't forwards compatible to address spaces wider than 32 bits. That's not v6's fault; it's v4's fault. There's no way to make it "just work" without some form of backwards compatibility method, and that's what v6 implements -- because it's the only thing that's compatible with v4.

If you think I'm wrong about this, all you need to do is explain how they should've designed it to make it possible for a v4-only device to talk to a v6-only device. If you can describe a way to do it, you'll prove I'm wrong. Just remember that whatever you come up with needs to a) be something that v6 doesn't already do, and b) actually work.

I've asked a lot of "v6 should've been backwards compatible" people to do this, and not one has been able to. Perhaps you will finally be the one to share the secret...?

Nanashi

Re: I've said it before and I'll say it again

You don't need good drugs to see this. Between dual stack, Teredo, 6to4, 6rd, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E and more, v6 has plenty of backwards compatibility.

Why do you think it doesn't?

Nanashi

Re: That old chestnut

> When I'm running out of nails, I don't start thinking about buying a new hammer.

Sure you don't. But when the entire world is out of nails, and nobody can make any more of them, but you still need to nail stuff down, wouldn't you start thinking about using screws instead?

Nanashi

Re: I've said it before and I'll say it again

Why say it repeatedly when it's wrong? v6 is backwards compatible with v4.

Describe a method of backwards compatibility that would actually work with v4, and v6 most likely already has it or something functionally similar. There's at least a dozen different methods available, depending on what your use-case, limitations, goals etc are.

If there's anything v6 lacks, it's not backwards compatibility.

IPv6 still 5-10 years away from mainstream use, but K8s networking and multi-cloud are now real

Nanashi

Re: Is this the most sensible Gardner report ever?

The lack of what now? v6 is backwards compatible in many, many different ways. Describe a method of backwards compatibility that would actually work, and v6 most likely already has it or something functionally similar. There's at least a dozen different methods available, depending on what your use-case, limitations, goals etc are.

If there's anything v6 lacks, it's not backwards compatibility.

UK internet providers told to mind their MANRS and start following Border Gateway Protocol best practices

Nanashi

Re: though nobody noticed because they were IPv6

Actually no, it doesn't. They advertised 2400::/12, which is basically the entire of APNIC's space. Any legitimate users in APNIC are advertising routes that are more specific and thus have higher priority, so the announcement didn't affect them.

So no, the reason they didn't notice wasn't because it was v6.

China showing signs of brewing IPv6 eruption

Nanashi

Re: Privacy anyone?

Not privacy, no. v6 (at least with privacy extensions on, the default in most OSs) is no worse than v4 for privacy.

ISP logging knows who you are either way and it makes no difference whatsoever to account-based tracking (remember this is China where you often have to tie accounts to your real-world identity -- how is v6 supposed to cause any privacy issues compared to that?).

Asia’s internet registry APNIC finds about 50 million unused IPv4 addresses behind the sofa

Nanashi

Not really that many

Back in 2011, before IANA ran out, we were going through more than one /8 per month. Three /8s sounds like a lot, but it's only a few months of global demand... and that's at 2011 levels. The internet has gotten bigger since then, and a lot of people are running low on addresses.

Of course, these addresses are restricted to just the APNIC region rather than being a global pool, but on the other hand it sounds like the majority of them still belong to someone and they'll just be asking politely if those owners would like to give them up, which many might not.

This isn't going to obviate the need to do IPv6.

It could be 'five to ten years' before the world finally drags itself away from IPv4

Nanashi

Re: What has it got in its pocketses?

In practice most of them seem to be doing v6 properly, and even the ones that aren't doing it properly are at least providing one /64 so you can get a single network running. The abuse and charges that you're worried about haven't really materialized.

(Perhaps there might be a "yet" lurking there, since the companies doing v6 first are probably the companies that are more willing to do it right. But so far, remarkably, ISPs seem to have resisted the temptation. Even Comcast are delegating a /60, and they're routinely rated the worst company in America.)

Nanashi

But CLNS had all of the exact same compatibility problems with v4 that v6 has. You'd still be stuck with all of the same excuses that people are providing today for failing to do v6, just with the ISO as the bogeyman rather than the IETF.

On top of that, it also has a different networking model than v4, which probably wouldn't go down well with the people complaining that v6 (with an identical model to v4) changed too much from v4. Then there's the issue of hardware routing when your address length is variable. None of this would help.

We didn't really see much notable deployment of v6 from 4G itself. Many mobile companies rolled out a v4-only service on top of 4G (and many of those are still not doing v6 today). 4G supported v6 before 2013 because it was obvious it would be needed, but that doesn't mean that mobile networks started using it right away.

Nanashi

Re: That's pretty much all it does

If your attempt to fit the internet into 48 bits requires reaching for NAT, then 48 bits is too small. And in any case switching to this 48-bit address internally would involve the same amount of work that switching to v6 internally does.

Address exhaustion is exactly what v6 was designed to solve. "Expanded Addressing Capabilities" from 32 to 128 bits is the very first thing listed in the introduction of RFC 1883. AS numbers are an entirely unrelated issue. In fact your whole second paragraph is so silly that it reads as a deliberate troll.

Excessive is good! We want the address space to be too big, because the alternative is for it to be too small. The costs of the L3 address space being too small far, far outweigh the cost of the extra 32 or so bits in v6 (bits which, I note, are also used to increase security in a few places).

NAT does not itself make your internal machines unaddressable, and even a correct configuration will not prevent access to internal machines. Firewalls prevent access to machines, not NAT. In fact, if you have inbound port forwards configured then it lowers security compared to not having it by reducing the search space for servers -- instead of searching the entire subnet, you only have to search for open ports on the router of the subnet, which makes port scanning substantially easier. In the case of v6 it reduces a port scan of an entire network from requiring exabytes of traffic down to just a few megabytes.

Nanashi

You only have to look around this very thread to find people who argue against doing v6 even when there's a cost benefit to it. Porn sites are unlikely to be any different in that regard.

Nanashi

"small elite of academic's", really? The internet was long outside the control of any single entity by the 90s.

The work on a new version of IP happened too late to make it into Windows 95. Windows 95 was originally scheduled for release in 1993, although it was eventually delayed by two years, and I think it's unlikely they would've done the OS level work so close to the expected release date (and especially unlikely that they would've done it when already 1-2 years delayed). To be clear, there's a lot more work involved in increasing the address length than a single #define.

Even if they had, there would still be the issue of actually getting ISPs to provide the new version and getting people to use it, and getting developers to support it, "even though there's no point and nobody's using it". These are the parts that have taken the most time.

We only really started seeing v6 deployment take off once the RIRs started running out of space in ~2013. That timeframe would've been the same even if v6 had been in Windows 95.

Nanashi

Re: What has it got in its pocketses?

Do you mean a regular home CPE? That would be difficult, as very few of them don't support NAT.

This really should be obvious, but... the fact that NAT support is common in home CPEs does not mean that NAT is free to implement, or that the implementations never have bugs, or that it doesn't introduce additional complexity into networks or software, or that it can't cause problems. To be clear: it costs money to implement, the implementations have bugs, it makes networks more complicated, it adds complexity to software and it causes lots of problems. All of these issues are part of the cost, which you pay for either with money or with time, effort and frustration.

At the ISP side, NAT is done on routers that cost in the £10k-100k range. NAT may be an additional license cost, and it also imposes a performance hit that means you need to buy more of the expensive routers than you do without it. Since internet traffic is increasing over time, the additional costs of NATing that traffic also increase over time. Dual-stack ISPs see over half of their traffic flow over v6, which immediately reduces the cost of the routing hardware needed to NAT the remaining v4 traffic.

Depending on the ISP network, CGNATed traffic may need to be routed out of its way in order to reach one of their CGNAT routers whereas v6 traffic can be handed off early, which increases the latency of v4 traffic. This too is a cost you pay.

So, yes. The cost of NAT.

As for why v4 addresses are in demand, it's a combination of the cost of the workarounds required when you don't have enough address space (including but not limited to the stuff I just wrote three paragraphs about), and the fact that there are a large number of v4-only clients out there that you still want to provide service to. To be clear again: these are reasons to be doing v6, since the address shortage in v4 isn't going away.

Nanashi

The fact that you can continue to run v4 when you're also running v6 does not mean that v6 is broken.

I did wonder if I should include that part, because I suspected that people would zero in on it and ignore everything else I said. It seems my suspicion was on the mark.

Nanashi

Re: What has it got in its pocketses?

De-anonymization is about identifying the end user, not about the details of how traffic is tunnelled inside an ISP.

Page: