* Posts by Nanashi

352 publicly visible posts • joined 19 Sep 2016

Page:

Stern Vint Cerf blasts techies for lackluster worldwide IPv6 adoption

Nanashi

Re: There Might Be An Alternative

Okay, you really need to familiarize yourself with v6. You have no reason not to be familiar with it already, especially if you're trying to make something like this.

It's already possible to deal with v4-only devices in a v6 world with NAT64/NAT46, and to deal with communicating over a v4-only internet with 6to4. What you've come up with more or less replicates features that are already available in v6, and you haven't managed to avoid any of the backwards compatibility issues that v6 has. That's the main technical issue I have with it.

If you want to do better, you need to know what's already possible.

Nanashi

Re: There Might Be An Alternative

I spent some time ingesting that draft, and I have a silly question... how is it different to running 6to4+NAT64?

To explain, I'm going to describe a network setup using Figure 1 as a basis, but using 6to4 and NAT64 instead of EzIP.

First, convert the WAN IPs of the SPRs into hex (4529be6e/4529be94), and set up 6to4 on each of them. SPR1 gets 2002:4529:be6e:/48 and SPR4 gets 2002:4529:be94::/48. Now set up NAT64 on SPR1 and SPR4, such that the 240/4 addresses behind SPR1 are mapped into 2002:4529:be6e:64::/96 and the 240/4 addresses behind SPR4 are mapped into 2002:4529:be94:64::/96.

It's also necessary to put /64s from the 6to4 allocation on each network. Let's say that T1a/T1z's network gets 2002:4529:be6e:1::/64 and T4a/T4z's network gets 2002:4529:be94:1::/64. T1z now has two IPs (192.168.1.9 and 2002:4529:be6e:1::9) and so does T4z (246.1.6.40 and 2002:4529:be94:1::1640/64). T1a and T4a still only have one address each (192.168.1.3 and 240.0.0.10), since they only support v4 -- but they are also reachable by 2002:4529:be6e:64::192.168.1.3 and 2002:4529:be94:64::240.0.0.10 due to the NAT64 running on SPR1 and SPR4.

The DNS records for T4a are now 69.41.190.148 and 2002:4529:be94:64::240.0.0.10. The DNS records for T4z are now 69.41.190.148 and 2002:4529:be94:1::1640.

Now consider the example in A.1 (a connection from T1a to T4a). How does it work with this 6to4+NAT64 setup? Basically nothing changes here; T1a sends a plain v4 packet from 192.168.1.3 to 69.41.190.148 and SPR4 needs to DNAT or DMZ it somewhere. A.3.1's scenario (T1a->T4z) is also essentially the same as this.

Next, consider A.2 (T1z->T4z). T1z sends a v6 packet from 2002:4529:be6e:1::9 to 2002:4529:be94:1::1640. The packet is routed through RG1 and reaches SPR1. SPR1 extracts the address of SPR4 from the dest IP (2002:4529:be94:1::1640 -> 4529:be94 -> 69.41.190.148), wraps the v6 packet in a 6in4 packet, and transmits it over the internet to 69.41.190.148. SPR4 receives the packet, unwraps the original v6 packet and forwards it to T4z.

Finally, A.3.2 (T1z->T4a). A.3.2 is weird in your draft, because it says that T1z should send a native v4 packet, and that the packet will be treated the same as the A.3.1 case... but that would mean that T1z has no way of addressing the packet to T4a. It has to resort to talking native v4 to SPR4 and then relying on port mapping or DMZ on SPR4. Doesn't this completely invalidate the point of the draft? It would make more sense for T1z to send an EzIP packet addressed to T4a (that is, 192.168.1.9 to 69.41.190.148 with extension headers that specify 69.41.190.148-240.0.0.10), and have SPR4 convert it to a native v4 packet for delivery over Premises 4's network to T4a.

I'm just gonna assume that's what A.3.2 supposed to say. The 6to4+NAT64 equivalent is for T1z to send a packet from 2002:4529:be6e:1::9 to 2002:4529:be94:64::240.0.0.10. The packet reaches SPR1, which sends it inside 6in4 to 69.41.190.148. SPR4 again unwraps the packet, but this time it spots that the destination is in 2002:4529:be94:64::/96, so it converts the packet to a native v4 packet with a dest IP of 240.0.0.10 and sends it to T4a. The reply packets get detected by SPR4's state tracking and converted back.

That's pretty much how things would work with 6to4+NAT64, and it seems to me that it largely has the same properties as your draft does. but with the added benefit of already being supported by existing software and hardware.

There are some other weird parts in the draft; for instance it says that RG1 is EzIP unaware, yet appendix A says that RG1 needs to insert "TCP ports" in the forwarded packet, which is an operation that routers don't currently do. There are other mentions of TCP ports elsewhere too which I kinda glossed over a bit, because TCP happens at a higher layer than IP and so should be irrelevant here. It's not supposed to be TCP-only, right? That would be called out right in the abstract, or better the title, if so. If not, then those "TCP ports" are actually weirdly-named extra option headers... but that's inconsistent with the IHL field which is explicitly 5 in the example packets shown with them.

The primary difference between the 6to4+NAT64 setup above and the setup described in Figure 1 seems to be the network behind RG1, which is described as being v4-only with an EzIP-unaware router in front of it (but, as I say, there's some disagreement about whether it's actually unaware or not). If RG1 is indeed unaware then nobody will be able to address T1a and T1z from outside their network, because they're hidden from SPR1 by NAT. Inbound connections to them aren't possible without relying on port forwarding rules.

In the 6to4+NAT64 setup, RG1 is definitely aware and inbound connections work fine. It's possible to set up a network where it's not aware, and if you do that then inbound connectivity ends up looking the same as it would with an unaware RG1 in the Figure 1 case. The problem is that T1z will lose its ability to directly address T4a and T4z, since it was relying on v6's dest IP field for that and it can't use that when on a v4-only network. You'd need some mechanism for T1z to communicate its desired dest IP to SPR1, and I don't think that's actually something we have yet. (Perhaps Teredo would do the job, if both SPR1 and SPR4 were Teredo relays. If they're not relays then you end up relying on both Teredo and 6to4's native IPv6 interop, which ought to work but doesn't always.)

If this is really the main difference, then wouldn't you be better served by focusing on this specific aspect (of T1z-on-unaware-network) and relying on technology that already exists for everything else? What advantage are you getting from reinventing those things rather than reusing them? At the moment it just seems like you're unnecessarily raising the implementation and deployment hurdles for yourself.

[This was a bit of an epic post for a comments section, but at least nobody can accuse me of not thinking about their suggestions -- when the suggestion is more substantial than the typical "just add an extra 0-255 to the beginning of the address", at any rate...]

Nanashi

Re: But ...

So long as you like spending money on life support, relying on third-party relay servers for everything and enjoy NAT, CGNAT and RFC1918 clashes and networks that are hard to reason about and require workarounds everywhere to deal with address space shortage, then sure, no incentive.

...in other words, no, there's quite a lot of incentive. Why would you deliberately ignore it all?

Nanashi

Re: But ...

It is slowly breaking, however. We're spending a lot of money shoring it up and trying to work around the parts that are creaking and groaning, sometimes with more success and sometimes with less success.

Just because it hasn't actually snapped into two yet doesn't mean there aren't problems.

Nanashi

Re: 128 bits is too many

Better too many than too few. It'd be really stupid to go through all this effort, only to need to go through it again in the future just because people hadn't heard of DNS the first time around.

Nanashi

Re: Sure..

Sure, a lot of IoT stuff is made by sleezy companies that'll do that anyway. But if you want to have any hope of ever avoiding the relays, then "just NAT behind CGNAT" is not the way to go.

We need to create and maintain an environment in which companies can do the right thing, before we get to complain that they're not doing it.

Nanashi

Re: You have to admit...

I don't think "inconsistent notation" is a problem for v6. I sat down and worked out sixty-six different ways to write a single v4 address, without even relying on padding zeros. If having multiple ways to write a single address was a problem then it's a problem that v6 actually improves on.

"But," you're thinking, "we never write v4 addresses like that.". Yeah, well, you don't ever write v6 addresses with leading zeros either; people who write them like that don't have much, if any, operational experience with v6. It's seriously not a problem in practice.

Here's the full list of v4 variations, for the interested. Sorry the list is a bit ugly, but I don't really have any way to make it look better in an El Reg comment. Every single one of these represents the same address, and they all work perfectly, at least on Linux with any program that uses getaddrinfo(). If we can handle v4 supporting all of these, then we can handle v6 supporting a few leading zeros in each field.

10.24.42, 10.24.0.42, 10.24.052, 10.24.0.052, 10.24.0x2a, 10.24.0.0x2a, 10.030.42, 10.030.0.42, 10.030.052, 10.030.0.052, 10.030.0x2a, 10.030.0.0x2a, 10.0x1a.42, 10.0x1a.0.42, 10.0x1a.052, 10.0x1a.0.052, 10.0x1a.0x2a, 10.0x1a.0.0x2a, 10.1572906, 10.06000052, 10.0x18002A, 012.24.42, 012.24.0.42, 012.24.052, 012.24.0.052, 012.24.0x2a, 012.24.0.0x2a, 012.030.42, 012.030.0.42, 012.030.052, 012.030.0.052, 012.030.0x2a, 012.030.0.0x2a, 012.0x1a.42, 012.0x1a.0.42, 012.0x1a.052, 012.0x1a.0.052, 012.0x1a.0x2a, 012.0x1a.0.0x2a, 012.1572906, 012.06000052, 012.0x18002A, 0xa.24.42, 0xa.24.0.42, 0xa.24.052, 0xa.24.0.052, 0xa.24.0x2a, 0xa.24.0.0x2a, 0xa.030.42, 0xa.030.0.42, 0xa.030.052, 0xa.030.0.052, 0xa.030.0x2a, 0xa.030.0.0x2a, 0xa.0x1a.42, 0xa.0x1a.0.42, 0xa.0x1a.052, 0xa.0x1a.0.052, 0xa.0x1a.0x2a, 0xa.0x1a.0.0x2a, 0xa.1572906, 0xa.06000052, 0xa.0x18002A, 169345066, 01206000052, 0xA18002A

Nanashi

Re: Why?

"IPv6 has no business benefit." -- I take it you've never been through a company merger or split, and have never had to deal with RFC1918 clashes.

Those are a massive, ongoing headache. Not having to deal with them absolutely should be considered to be a benefit.

Nanashi

Re: Meh

Actually, using privacy addresses doesn't stop you from using static addresses too. You can have multiple addresses at the same time.

I agree the privacy gains aren't fantastic, but that's because most privacy issues are a result of cookies in browsers, or of mobile apps sponging every piece of data they can off of your phone. Obfuscating the right-hand 64 bits of your address, however you do it, is never going to give you fantastic privacy gains in a world where most privacy breaches come via a different vector.

Nanashi

Re: Analogy Units

Also, even with /48s there are 2^45/7 billion = ~5000 per human. With /56s there are 2^53/7 billion = 1.3 million. Per human. And this is all out of 2000::/3 only; we still have five unused /3s that we can expand into with tighter allocation policies if it turns out to be necessary. These allocation sizes are fine, and we have an escape hatch if it somehow turns out that they aren't fine.

It's the same with that /19 mentioned above. France Telecom have 256 million customers, which is 3.7% of humanity. By that metric, their "fair share of the v6 space" (if we pretend for a moment that the concept makes sense) would be 2,360 /19s. One /19 barely even registers, and there's no reason to force them to conserve address space when we have enough available (plus an escape hatch just in case we're wrong). We made v6 overly huge precisely to avoid doing that.

Nanashi

Re: Sure..

You only have to look as far as all the people asking for help with port forwarding or with closed NAT on their Xboxes to realize that it does affect at least some consumers.

(Then there are the indirect effects, like forcing all IoT stuff to go through a relay server because it's just too difficult to avoid it when everybody is behind three layers of NAT.)

Nanashi

Re: You have to admit...

Have you worked with v4 and v6 networks? v6 networks are way easier to work with than v4 networks (which are inevitably NATed).

Even v6 addressing is easier, because hex lines up with subnetting boundaries better than decimal does. It's also possible to arrange for your v6 addresses to be more memorable than your v4 ones (compare 2001:db8:42::1 with 203.0.113.42+192.168.0.1 -- which of those is shorter?), although you don't need to most of the time because you generally work with hostnames, not IPs.

Nanashi

Re: They should never have cried wolf

What do you mean by "seeks to replace instead of coexist"? Dual stack is very much coexistence, and there's a whole bunch of transition techs (6to4, Teredo, NAT64+DNS64/464XLAT, ISATAP...) to help them coexist even better.

Perhaps you mean "unmodified v4 hosts can't talk to v6 hosts", but it doesn't make sense to pin the blame for that on v6 when it's a direct result of v4's design. v4's dest IP field is only 32 bits, it can't address anything more than that and any attempt to work around that is going to end up looking like one of the transition techs that we already have for v6. So why do you blame that on v6, when it already has the design that's as close as possible to the one you're suggesting it should have?

Time to dump dual-stack networks and get on the IPv6 train – with LW4o6

Nanashi

Re: Throw caution to the wind and it will fall upon someone else

Then you aren't using NAT. The harder to manage part is a necessary consequence of rewriting addresses on packets mid-flight.

That, or you've been using it for so long that you see the difficulty as normal. Security is hard enough as it is without making life unnecessarily harder for yourself.

Nanashi

Re: Big advantage

NAT64 works nicely for getting a v6 client to talk to a v4 server. It's the other way around that's a problem.

I assume by HE you're referring to their 6in4 tunnels, but those don't help here because a) you need a public v4 address for those, b) the suggestion was to avoid deploying v6 to your machines, but deploying v6 to your machines over a tunnel is still deploying v6 to your machines, and if you're going to do that then why not just do it natively?

Nanashi

Re: Big advantage

Because the suggestion was to get v6 to the router and not to the machines behind it. The machines behind the router would fall into the situation in your last paragraph.

Nanashi

Re: Throw caution to the wind and it will fall upon someone else

Privacy addresses also obfuscate which machine is doing what.

If you're trying to secure your machines, you should focus your time and energy on things that will be actually useful (like say, browser cookies, which are way more effective for tracking you than a randomly-generated IP address that changes every day). The only thing NAT will do for you is make your network harder to manage and reason about, which will consume effort that could've been better spent on something helpful.

Nanashi

Re: Big advantage

Yes, you get handed a big block of addresses. That's by design. Aggregation and routing efficiency directly lead to high wastage; the reason v6 is 128 bits instead of 64 is to allow space for that. Wastage isn't bad, it's just a consequence of how we get the internet to run at scale without falling over.

There are ~1.3 million /56s available per person on the planet. If ISPs gave out /56s, then to use all of those in 25 years we'd need every human (not household; human) on the planet to sign up for a new ISP 140 times per day, and never cancel the old ISPs. When was the last time you signed up for a new ISP? Was it ten minutes ago? Did you keep the old service? And the 1 million services before that too? Probably not.

/48s changes it to once per week, and I completely ignored non-end-user networks as well as wastage inside ISP networks. Even so, it's hard to imagine how we could be looking at running out in 25 years. If you think we will, then you haven't got your head around just how big v6 is.

And even if we do somehow run out, those numbers above were for 2000::/3. There are still 5 unused /3s we could start over in with tighter allocation policies, if we needed to.

Nanashi

Re: Big advantage

Uh, you can still subnet v6, you don't need NAT for that. You're expected to get a /48 (or at minimum at least a /56) which you split into 65k (or 256) /64s. You're not going to lose your network segmentation.

As an example:

2001:db8:42:1::/64, 2001:db8:42:2::/64, and 2001:db8:42:3::/64

And these are more readily memorized than the v4 equivalents:

203.0.113.42+192.168.1.0/24, 203.0.113.42+192.168.2.0/24 and 203.0.113.42+192.168.3.0/24

as you can see by the fact that one list takes up 50% more space.

Nanashi

Re: Throw caution to the wind and it will fall upon someone else

Other than privacy extensions, and 64 bits of address space per network, you mean? You can't exactly just enumerate a v6 network to count the number of hosts in it.

Also, do I really need to point out that knowing the number of hosts on the network does sod all to the security of it? If it's secure then it's secure, and if it's not then obfuscating the number of hosts isn't going to help. You should spend that time and effort on making it secure.

Nanashi

Re: Big advantage

> All your major services are now proxied through the 4&6 machine at the boundary. All your external connections, webmail, remote, VPN, etc.

Well, yes, that would do the job subject to the usual limitations of proxies, but you said "bang, job done and no more internal changes required", yet migrating your entire network to using a proxy is actually a pretty big disruption -- far, far bigger than just adding v6 to it.

> Your internal workings, IP's, etc. literally don't matter. That's the beauty of NAT.

The NAT which you're abandoning in favor of proxying?

> But what you were telling people was "You have to give every machine, server, printer, phone, etc. a world-routable IPv6 address, from day one

I don't think I said this. Like I said, the first step in a transition is to get v6 to your border router. But you cannot just sprinkle NAT around like magic pixie dust and have everything somehow work right -- there is no room in the v4 packet header to fit a v6 address, so a v4-only machine on your network is only going to be able to reach v4 hosts, regardless of any other hosts the router itself can reach. That's why the next step in the transition is generally to give your machines v6 addresses (and I note that this doesn't need to be done to every machine at once -- it's perfectly okay to have a mix of v4-only, v6-only and dual stack machines on your network, if that satisfies your desires).

> IPv6 the gateway, leave everything else on IPv4 NAT and then everything else is done at your leisure.

This is roughly a good description of how deploying v6 already works. You do, in fact, control when each step in the deployment happens. It's just that the first step is not the only step that is necessary to get v6 connectivity to your end machines -- and if you don't like that, then you need to complain to the people who designed v4, because it's v4's lack of forward compatibility that prevents it from reaching v6 hosts.

> What's wrong with proxying? It can be done in a way that is transparent to everyone behind the router.

I didn't say it was wrong, it's just that people seem to strongly prefer routed network connectivity over proxying. As a side note, I don't see how you can transparently get a v4-only host to pack 128 bits into v4's 32-bit destination IP field.

Nanashi

Re: Big advantage

> Only stupid people thought that NAT wasn't the ideal way to transition - convert your NAT gateway to IPv6, bang, job done and no more internal changes required until you wanted to.

You can of course do this -- it's generally the first step in transitioning a network -- but how will your machines get access to v6 without resorting to a proxy?

If you didn't manage to think that far ahead, then perhaps calling the people who did stupid is a bit unfair to them.

Nanashi

Re: Throw caution to the wind and it will fall upon someone else

Actually, Windows uses them by default. The main thing that doesn't is Linux without network-manager. I'm not sure if you're now going to praise Microsoft for doing the right thing and criticise Linux, but there you have it.

> as it makes me easier for hackers and other pernicious actors to locate.

You are, of course, harder to find on v6 because the search space is much larger. Other people's insecure IoT kit (because I know nobody on El Reg would run any of that stuff, but there are people out there who do) is also harder to find, sufficiently so that random network scanning is unlikely to remain a viable infection technique on v6.

Also, NAT has nothing to do with security and you don't need (and cannot use!) it to control inbound connections to your network. If you don't want people connecting, just don't configure your firewall to allow them to connect. v6 does not magically make your network impossible to secure.

Worst. Birthday. Ever. IPv6's party falls flat

Nanashi

Re: very little out there runs IPv6 ?

If you checked, you'd probably actually find that a decent percentage of your traffic is v6. I've seen stats from a few dual-stacked ISPs (from a few years ago, even), and it's common for around 50% of their traffic to be v6.

That's 50% of their traffic that doesn't need to go via CGNAT, which means less money spent on CGNAT hardware -- money which ultimately would need to come from their paying customers. There's also often a small latency advantage to v6, so that's a nice benefit too.

Obviously there's a big difference between "percentage of traffic" and "percentage of websites", but just because one of them is lower than the other doesn't mean that there are no benefits.

Nanashi

Re: IPv6 weekly spikes

Being windows boxen, they're vulnerable "out of the box".

I don't exactly have the best opinion of Windows either, but Windows boxes are not vulnerable in this manner out of the box. They ship with a firewall that blocks connections from off-subnet sources by default. On top of that, ISPs ship routers that also have a firewall that stops connections from even reaching the Windows firewall in the first place.

On top of that, v6 is really damn big and it's very difficult to find active IPs in it by random port scanning. It takes hundreds of millions of terabytes of traffic to scan a single network (or... attempt to scan, because your scan attempts will be dropped by the border router's firewall anyway), and all of that traffic has to go down your DSL's wet string -- if your wet string was 40 Gbit/s then it'd take nearly 5000 years to do a complete scan of each /64. Even if networks weren't behind firewalls and Windows didn't have its own firewall, it still wouldn't be easy to scan for devices.

The situation is about as far from "unfirewalled Windows 95 computer on dialup" as you can get. Those Russian bots are going to have a heck of a time finding unprotected v6 targets, unlike in v4 where you can exhaustively enumerate every target just by doing a quick scan of the entire internet.

Nanashi

Re: IPv6 weekly spikes

but I can't work out if its weekdays or weekends when there is higher usage

Strictly speaking, probably neither. v4 usage goes up on work days because people use Facebook from work, where v6 deployment is even worse than at home. More v4 usage combined with similar v6 usage means a lower percentage is v6. The trend is easier to see on Google's stats, since you can get the exact date from them. (Public holidays tend to be very noticeable too.)

Nanashi

Re: very little out there runs IPv6 ?

"There are a LOT of open ports on windows boxen that would be "on a public IPv6" if it were adopted by ISPs."

No, not really. ISPs doing v6 do so by shipping v6-capable routers with firewalls to their customers. Also, Windows itself ships with a firewall that blocks these connections as well. So that's TWO firewalls blocking any inbound connections to those ports.

I really wish we could stop perpetuating this "no NAT means you're wide open" meme.

Internet engineers tear into United Nations' plan to move us all to IPv6

Nanashi

Re: Mapping plan

I don't suppose you have a suggestion for what that simple plan would be? I'm guessing you don't, because it's not possible to get any simpler than the plan we already have.

djb also falls into this trap with that article -- he points out a bunch of problems, and then just sort of goes "these should be solved", without mentioning or apparently even realizing that they can't be solved in any better way than the way that v6 already solves them (with 6to4, Teredo, NAT64, DNS64/464XLAT and API translation).

Nanashi

Re: IPv6 should have taken off by now

I read the document. On v6, you are nominally expected to receive a /48, which gives you 16 bits (4 hex characters) to play with for your subnetting. Y.IPv6RefModel is mostly just a suggestion on how to use those 16 bits.

The suggestion boils down to: use the first character for a site ID, the second character for a category ID (DMZ/servers/LAN/IoT/other) and the third and fourth for a subnet number. It then says that if you set the site ID to 0 and make sure the 4th hex character is also 0, the subnet plan only uses 8 bits which makes it small enough to reasonably insert into a v4 address (since it then only needs a /16 rather than a /8).

It's not explained well in the recommendation, but if you use the same subnetting plan for v4 and v6 and are careful to also use the same host IDs for dual stack devices (which involves limiting yourself to only the first 256 addresses of the v6 /64...) then it's possible to define a stateless translation rule between v4 and v6 IPs for those devices. However, the mapping is purely local for the given network and there's no way to tell random people on the internet about the rule, so any translation would have to be done on your own local NAT64 router. There's no arbitrary v4<->v6 tunneling here.

Note that none of this is fundamentally new. You could already do all of it; this is just a recommendation for one way of going about it.

As for my opinion on the recommendation... it's coherent and it looks like it achieves the goals it sets out to achieve, but I'm not convinced the goals make much sense. Most people already have a v4 network with an incompatible addressing plan, so you can only really use this on a greenfield network. But if you have a greenfield network then there are better ways of going about it without paying the costs of this plan.

Nanashi

Re: Those brilliant minds who gave us IPv6

It would have been nice, yes. Unfortunately it's not possible due to the design of v4, so we can't do it and that's just something we're going to have to deal with.

Nanashi

Re: Headache

Actually it allows you to side-step a lot of the headache involved in running most v4 networks (that is, the headache involved in dealing with NAT).

Nanashi

Re: Oh dear.

An engineer that did that would be very clearly out of their depth for the task.

For one thing, an extra byte isn't enough, so you'd have to go through the entire process again in a few decades' time. For another, you can't just tack an extra byte on. You still have to go and add a new record type to DNS (like v6 did), and add a new socket type (like v6 did) and a new socket API to handle the new types (like v6 did), and update RAs/DHCP (like v6 did), and update all the other standards that hard-coded v4 (like v6 did). Everybody would need to update their software to handle the new sockets and DNS types (like they do for v6) and configure their networks to use it (like they do for v6).

Your suggestion omits all of those necessary steps, and if you add them in then you basically end up with something that looks the same as v6 does -- except it's too small and would itself need to be replaced.

The glorious uncertainty: Backup world is having a GDPR moment

Nanashi

I can think of an obvious way to handle this:

Step 1: when backing up a user's data, encrypt it with a unique key for that user.

Step 2: when a request-to-forget comes in, delete the key.

Your backups will remain immutable but the user's data is inaccessible.

Of course you'll need some system to manage all the encryption keys and that system is going to need its own backups, so this isn't a completely trivial solution, but encryption keys are small and it should be much easier to design a non-immutable backup system for them (especially since the keys themselves aren't PII, and you don't need to keep historical backups of them, just backups of the currently-valid set).

OK, this time it's for real: The last available IPv4 address block has gone

Nanashi

Re: Compatibility

Routers could convert the packets... but only if you restrict yourself to using 0.0.0.0/32, which means you wouldn't be able to talk to legacy v4 hosts if you tried to use any of the new addresses. You could do stateful NAT but that limits you to outbound connections, and it scales badly so you couldn't just have any random router in the internet core handle it.

Also, old software wouldn't be able to handle the longer addresses, so you'd either have to translate them to legacy v4 in the host OS, or you'd have to just use v4 directly.

If you wanted to use one of your new "v8" addresses, you'd end up doing one of two things: either you'd use two addresses at once, one from the expanded address space and one from the mapped v4 part, or you'd resign yourself to only doing outbound connections and you'd translate the source address on those to something that legacy hosts can handle. And you'd have to update your OS and software and router to do it.

What does this sound like? That's right, it's exactly the same set of problems v6 faces, with exactly the same set of solutions (dual stack, NAT64, 464XLAT, API translation). The people who designed v6 already went down this road, they already came up with what you're suggesting, and we're already deploying it. It's just that what you're suggesting doesn't allow transparent direct communication with legacy hosts -- and nothing you mentioned or implied gets around that without relying on something that already exists in v6.

Nanashi

You kinda are an idiot to use NAT when it's not necessary. If you use it when you don't need it, the only thing it does for you is make your network harder to admin, and make your security harder to reason about. It makes sense if you're a masochist, I guess.

(By NAT I specifically mean iptables' "-j MASQUERADE" mode; the one that you apply to outbound connections only. There are various other targeted cases of address translation that can be handy, like NAT64/NAT46 or load balancers, but we're talking about the type of NAT that people use on their home connections here, right?)

Of course it is often necessary -- you need it if you aren't receiving enough IP addresses for your network from your upstream ISP. That is why you see it used everywhere for v4. It's because we're so short on IP addresses that you're lucky if you can even get one single v4 IP for your entire network.

As a side note, you're going to need to deploy v6 on your local network and not just on the WAN side of your router, because there's no way to fit v6 addresses into v4 packet headers. Your LAN machines will have no way of reaching v6 hosts without v6 on the LAN. This is just an unavoidable consequence of the way v4 works, and the only way to fix it is to deploy a new protocol. (Or you could use a proxy, but nobody wants to use proxies.)

> NAT is a "sensible default" applied to the technology that happens to translate to a "block all incoming" as the final rule by the way it works

Woah, woah, woah... where did you get this idea from? NAT doesn't block any connections. Literally the only thing this type of NAT does is change the apparent source address of outgoing connections. It doesn't do anything to inbound connections.

Okay, I know the answer to this one: it's because you normally use NAT together with RFC1918, and using RFC1918 does make it difficult for most, if not all, of the internet to connect to you. But the NAT part of that does nothing to inbound connections. This is the "makes your security harder to reason about" that I mentioned above: it's causing a misunderstanding here that could potentially be dangerous if you try to rely on it.

Nanashi

Re: Compatibility

> I, for example, want to know if two addresses are the same. With IPv4 I look at them, do strcmp or simple 32 bit integer arithmetic; with IPv6 I have do do a massively complex normalisation step first then line them up on paper and use my fingers.

It's interesting how wrong this actually is. Here's a list of v4 addresses -- every single one of these refers to the exact same IP:

10.24.42

10.24.0.42

10.24.052

10.24.0.052

10.24.0x2a

10.24.0.0x2a

10.030.42

10.030.0.42

10.030.052

10.030.0.052

10.030.0x2a

10.030.0.0x2a

10.0x1a.42

10.0x1a.0.42

10.0x1a.052

10.0x1a.0.052

10.0x1a.0x2a

10.0x1a.0.0x2a

10.1572906

10.06000052

10.0x18002a

012.24.42

012.24.0.42

012.24.052

012.24.0.052

012.24.0x2a

012.24.0.0x2a

012.030.42

012.030.0.42

012.030.052

012.030.0.052

012.030.0x2a

012.030.0.0x2a

012.0x1a.42

012.0x1a.0.42

012.0x1a.052

012.0x1a.0.052

012.0x1a.0x2a

012.0x1a.0.0x2a

012.1572906

012.06000052

012.0x18002a

0xa.24.42

0xa.24.0.42

0xa.24.052

0xa.24.0.052

0xa.24.0x2a

0xa.24.0.0x2a

0xa.030.42

0xa.030.0.42

0xa.030.052

0xa.030.0.052

0xa.030.0x2a

0xa.030.0.0x2a

0xa.0x1a.42

0xa.0x1a.0.42

0xa.0x1a.052

0xa.0x1a.0.052

0xa.0x1a.0x2a

0xa.0x1a.0.0x2a

0xa.1572906

0xa.06000052

0xa.0x18002a

169345066

01206000052

0xa18002a

strcmp() ain't gonna help you here. v6 is pretty simple in comparison; here's a roughly equivalent address and its variations:

2001:db8:420:24::42

2001:db8:420:24:0::42

2001:db8:420:24::0:42

2001:db8:420:24::0:0:42

2001:db8:420:24:0::0:42

2001:db8:420:24:0:0::42

2001:db8:420:24:0:0:0:42

That's pretty short, and it's a lot easier to compare in your head too. (For instance, how many of you noticed that I made a mistake in my v4 list above? Some of those addresses aren't equivalent! Even now that I've straight up told you, how many of you can spot the mistake easily?)

In case anybody is wondering, the "massively complex normalisation step" that Adam referred to consists of calling getaddrinfo() on the address. That's, er, basically it.

Nanashi

Re: Compatibility

> Alternatively, put the IPV4 block as part of the IPV8. For example, the address 100.101.102.103 in IPV4 could just be 0.0.0.0.100.101.102.103 in a new, expanded 64-bit address space.

There's something very important that you didn't address in your post: how do existing, unmodified v4 clients talk to your new "v8" hosts? I'm guessing you didn't address it because you have no idea how to do it, which is completely understandable because it's impossible.

Other than the impossible bit, your suggestion is basically v6.

Nanashi

Re: Compatibility

They did give it thought. We have 6to4, Teredo, ISATAP, NAT64, 464XLAT, 6rd and DS-lite. We have proxies. We have a protocol that coexists cleanly with v4 on the same networks and the same hosts, with the same socket and DNS APIs and the same software.

What we don't have is "unmodified v4 host talks to v6 host"... because that's impossible.

What more are you asking for? What more could we possibly do? And why are you putting the blame on v6's designers, rather than putting it on v4's designers for failing to make their protocol forwards-compatible?

Nanashi

Re: Time to claw some back

Back in 2011, just before the first RIR ran out, we were going through more than one /8 per month. That was 7 years ago; the demand for v4 addresses is only going to be higher today. In other words, this would buy us something on the order of 2 weeks or so per /8. It really isn't worth the effort.

It's begun: 'First' IPv6 denial-of-service attack puts IT bods on notice

Nanashi

Re: Downside???

I thought we were talking about the average user? The average user does none of those things.

But sure. Use the IPs if you want: https://208.24.22.50/ and https://[2600::]/. I don't know about you, but I can only remember one of those off-hand, and it ain't the v4 one.

Nanashi

Re: IPv6 consumer devices are a dumpster fire

Or not so much. I know it's popular to rag on IoT stuff, but let's actually think about it for a moment. Let's imagine someone who buys a network camera, and who then configures their network so the camera is accessible from the internet so that they can look at it from work (because why else buy a network camera?).

On v4, the camera is found by scanners within a few hours, because the v4 space is tiny and easy to exhaustively scan. On v6? Not so much. You could spend a million times the effort scanning v6 and not even scratch a single /64, let alone all of the rest of the /64s. The camera is relatively unlikely to be found, and thus relatively unlikely to be exploited. This is still the case even if someone completely shuts down their firewall (which I suspect isn't really going to be the most common configuration).

Now, it's true that security by obscurity isn't security and there are various ways to narrow down the search space, but nevertheless if you make it much harder to find your IoT devices it's going to make it correspondingly hard to do anything to them. If anything, v6 seems like it should make the situation better rather than worse.

Nanashi

Re: IPv6 and CIDR

You say "of course" but I can't see how CIDR would make it impossible to null-route a subnet.

Nanashi

Re: Downside???

Um. The internet? Or specifically, it allows us to continue to bring the internet as it grows without losing performance and functionality. Surely that's something people want?

Also, v6 addresses aren't necessarily hard to remember. For example, here's a URL for accessing a site over v4: https://www.sprint.net/, and here's the v6 equivalent: https://www.sprint.net/. It's hardly more difficult to remember the second than it is to remember the first.

Nanashi

Re: Facebook not running IPv4 at all?

Their edge servers have v6 too, it's just that those are the only machines with v4 that Facebook run (with the exception of some HVAC control units in some of their datacenters). Some versions of ping are v4-only so I'm not sure that's the best tool to demonstrate anything with.

I have no idea where people get the idea that v6 is complex. It's no harder to use than v4, and in fact it's easier than v4 in practice because NAT is de-facto required on v4 but can be avoided on v6.

(I guess multicast NDP is a bit more complicated than broadcast ARP, but how many people reading this are writing NDP implementations? At a user level, with v4's NAT involved, v6 is less complicated than v4.)

Crashed RadioShack flogs off its IPv4 stash

Nanashi

Re: .. I'll bite.

I assume by "leaks addresses" you mean "allows connections from outside"? Some do, but it's because most of them have an additional firewall that blocks the connections.

Don't conflate firewalls with NAT. Just because they run on the same device doesn't mean they're the same thing.

Nanashi

Heh, did you ever actually try using the NAT in netfilter when you were writing modules for it? I've used it, and I can confirm that it absolutely does _not_ stop any connections at all. All it does it change the IP address the packets appear to be coming from. That's all it's supposed to do, so it shouldn't be surprising that that's all it does.

If you don't believe me, you can go and set up some VMs and test how netfilter's masquerading works for yourself. I went and did this myself a while ago in response to commenters here telling me I was wrong, and the result was... I wasn't wrong. The NAT didn't block any connections.

For reference, my test consisted of setting up a router with... I can't remember the exact ranges, but let's say 192.168.1.x/24 on the "LAN" side and 192.0.2.x/24 on the "WAN" side, with two extra machines, one on each side, that each had their default routes set to the router. All machines could talk to each other. I then configured the router to NAT the source address of connections coming from the LAN (with netfilter's "-j MASQUERADE" target) so that they would appear to come from the router's WAN-side address instead. Guess what? Outbound connections from the LAN were NATed correctly, but inbound connections to the LAN still worked. The conclusion I drew from this is that NAT doesn't block inbound connections, because if it did then those inbound connections would've been blocked, and they weren't.

I also did this on a regular internet-connected subnet with exactly the same results.

If you can explain what I did wrong or misinterpreted in my test, then I'm willing to listen. But please don't tell me something that either of us could demonstrate is false just by trying it on a test network and looking at what happens.

Nanashi

Re: Whatever happened to the great migration to IPv6?

The firewall in Windows actually works perfectly fine, and the vast majority of ISPs deploying v6 are doing so with CPEs that also have a firewall. Plus, on top of that, it's much harder to find the few unfirewalled machines on v6 because the address space is so damn large. Even just scanning one single /64 takes as long as scanning the v4 internet 4 billion times over.

If network attacks are what you're worried about, v6 is a lot better than v4 just purely because it's so hard to find devices with a network scan (and most of them are still firewalled anyway). If your malware can't find the vulnerable machines then it can't spread widely enough to be a major problem.

...at least not via network scanning. Other infection vectors still work just fine.

Nanashi

Your problem there wasn't running XP machines with a public v4 address, it was failing to put them behind a working firewall. Moving them behind NAT wasn't necessary, you just needed that firewall.

Finally a reason not to bother with IPv6: Uh, security concerns...?

Nanashi

Re: Why roll out IPv6 now?

The point of v6 isn't to give you new fancy stuff. It's to let you keep your fancy stuff, which you're otherwise going to lose.

We're out of bales of hay, and we can't make more of them. Yes, the horses are still working, but soon enough they're not going to be working. But we'd still like to have some form of transport. So what if the new transport still only goes at 80mph, and still doesn't have a range bigger than 400-800 miles? At least it's not dead.

I suspect that the very late implementation to fix Y2K was a big con

Yeah... probably not. Humans are UTTERLY TERRIBLE at long-term planning and will put things off until they absolutely can't, regardless of how costly that is to them. Just look at, say, cigarettes. Putting Y2k off until Y1.999k is completely consistent with that.

Nanashi

Re: If IP6v hadn't been made so goddamn complicated...

the fact that having every machine directly addressable by ip6 is a security nightmare -- sure would be nice if we could lay this particular meme to rest. No, it's not a security nightmare. Freely allowing anybody to connect to you might well be, but that's not what "globally unique address" means.

Remember all those hacked IoT devices? They get hacked because people expose them to the web so they can watch their camera from work or whatever. If they were running on v6 they'd be much less likely to get hacked, because the sheer size of v6 makes it much harder to port scan for exposed devices. How is that a security nightmare? v4 is the nightmare here.

Calling v6 "determined to be borderless and boundless" is also weird, because it's not. You've still got separate networks with their separate subnets and you've still got routers that manage access control between subnets and can do auditing or whatever else you want. The only difference is that you're not forced to rewrite addresses on packets due to a crippling address shortage, which is good because it makes your network simpler which makes it easier to secure.

"Expansive" is accurate though. I submit that it's a good thing to be, not a bad thing.

Page: