* Posts by Nanashi

352 publicly visible posts • joined 19 Sep 2016

Page:

I need an ISP that offers IPv6. Virgin Media: Whatevs, nerd

Nanashi

however, without an entry in my external router's NAT table and an associated forwarding rule you won't be able to establish a route because my NAT service will return a null IP address, resulting in packet discard, although I agree it will be the firewall or router that actually does the packet discard.

This is not quite how it normally works... if a packet comes in with dest addr <your router WAN address>, and there's no corresponding connection in the state table, then all that happens is that the dest address is left alone. It's not rewritten to 0.0.0.0. The packet will just be treated as if it was sent to the router itself (which is, after all, exactly where it was sent). It may in fact then get dropped or refused, but it could also just as well connect to a service running on the router.

That behavior is the same regardless of what the dest address in the packet is; if there's no corresponding entry in the NAT table then it just leaves the address alone and processes the packet as if you had no NAT configured. It might get dropped by a firewall if there is one, but it could also get routed onwards (possibly even back to the ISP).

You could perhaps make an implementation that behaved the way you describe, but it would be rather unusual and I'm not aware of one that does. Certainly netfilter doesn't work like that.

Nanashi

Why are people still posting this? Why are people still upvoting it??

It'll probably be with a /56-/60, which should be enough address space to avoid NAT. They're unlikely to do NAT on their managed CPEs. This is fine and not mad. It's not a problem for your IoT stuff to have a globally unique address; the important question is whether or not random people can connect to it, and you don't need NAT to stop that from happening.

VM doing v6 won't suddenly render it possible to connect to any of your devices without your permission. Inbound connections will still be blocked by default.

One IP address, multiple SSL sites? Beating the great IPv4 squeeze

Nanashi

Re: End to end is a myth

> So come on, explain how someone can route across the internet to just your rfc 1918 addressing when billions of others are using the same rfc 1918 addressing. Im really looking forward to your explanation.

Did you read any of the other posts here? This makes it seem rather like you didn't.

Nanashi

Re: End to end is a myth

Because instead of connecting to the machine you want to connect to, you have to connect to a different IP, and then configure that machine to carefully rewrite the dest addr to try and pretend that the packet was going to the first machine. This is clearly more effort than just using the target machine's IP.

Because it means that addresses on packets change mid-flight, making debugging and reasoning about the network harder than if they didn't change.

Because software can't accept inbound connections anywhere near as easily without manual setup or relying on third-party servers. (Remember that IoT software that broke when S3 went down? Wouldn't've happened if the Android remote-control software connected to your IoT device, but because of pervasive NAT this sort of software tends to go through a server hosted by the manufacturer these days.)

Because split DNS is more effort than not split DNS is.

Because you can't run two services on the same port, leading to having to manage and keep track of lots of alternate ports for things like ssh. (Then there was that one time that I wanted to run two DNS servers -- can't do that with a single public IP because DNS doesn't do alternate port numbers.)

Because we don't have enough IPs to even give one public IPv4 per person, which means you're going to end up being put behind an ISP-run NAT at some point. Have you ever thought about how you're going to accept an inbound connection when your ISP has you behind NAT and doesn't let you log into their router to configure it?

I'm guessing that you, like I, grew up using NAT everywhere. It doesn't seem so bad when that's all you've ever used and you don't know any different, but then I got a decently-sized block of IPs which let me get rid of NAT completely on my home network, and life really is easier without it.

Nanashi

Re: End to end is a myth

NAT does not make life easier in the general case. It's just an extra layer that gets in the way and adds extra admin overhead to everything you do. It can be useful in some targeted cases, but "on every network, all the time, for everything" isn't "some targeted cases".

> Can you provide a link to some article describing how this is done please? I'd love to know so I can mitigate any risks.

I don't have an article handy, but there's nothing complicated involved. Literally all you need to do is send the router a packet with a dest address of 192.168.1.42 (or whatever IP you're trying to talk to) and it'll route it on. It's just basic routing.

Global IPv4 address drought: Seriously, we're done now. We're done

Nanashi

Re: Dear network geeks, IPv6 is crap because...

Which isn't really how hacking actually works, but hey... nothing is going to stop an open connection short of closing it.

Nanashi

Re: "nat-has-nothing-to-do-with-security"

You're right, I do need to get my crystal ball cleaned, since you didn't make that very clear.

If I had lots of people in an office that I wanted to split up into groups, then I'd put them on separate VLANs with their own /64s. If I didn't want to split them up, then I wouldn't. Though I'd also prefer to do auth based on something like certificates, rather than relying on IPs and hoping that everyone is polite enough to use the addresses I've asked them to use. If you care about security then you need to make things actually secure -- and you can do that just as well on v6 as you can on v4. Or at least *I* could.

"random users accessing websites is a different topic all together which IPv6 has severe privacy issues with"

I can't believe you've been looking at v6 at all seriously if you still think this. It doesn't have any severe privacy issues for this scenario, above and beyond the ones that v4 already has.

Nanashi

Re: Dear network geeks, IPv6 is crap because...

More like no difference at all for the vast majority of people. The topology of most networks is "all hosts on one L2 domain", and if it's any more complicated then it's probably multiple L2 domains directly off of the main router. NPTing those will not change their topology.

Some networks have internal routing which could be quashed with NPT, but... if the visibility of a hop or two in a traceroute is a security vulnerability for you, then you've got bigger problems, and you should be focusing your admin effort on fixing those rather than wasting it on NAT.

...and I have no idea what "back hacking" is here. It sounds like Hollywood hacking rather than something you'd need to worry about.

Nanashi

Re: It's all Excel's fault

You'd have to synthesize fake A records to DNS queries and coordinate with a NAT46 instance (so it would be stateful and wouldn't work for v6 literals) but your idea is actually fundamentally possible, unlike so many others that I've seen. It would be useful for dealing with legacy v4-only hardware. I'm not aware of any implementations (TAYGA can do NAT46 but requires static config of each mapping).

It wouldn't be suitable for running at scale though; you wouldn't use it for your whole network, just for any stubbornly v4-only devices that you can't replace for whatever reason. I'm not kidding when I say that deploying v6 on a home network is very easy: over 30 million households in the US have done it, so it really can't be hard (despite what other posters would have you believe). You would just do that, rather than deal with the downsides of translating for every device.

About 8% of NZ users have v6 (deployed right to their end machines), so it sounds like you can get v6 if you want it over there.

Nanashi

Re: "nat-has-nothing-to-do-with-security"

Yep, that's the deal: if you have no firewall then your ISP (or anyone that can order them to cooperate) can connect to your LAN machines. Yes they'd have to work out what IP range you're using, but that's not very hard. And yes, your router would have to have no firewall. No, "your ISP" doesn't mean "the entire internet".

The key point is that it doesn't matter if you're using NAT -- if you want to block all inbound connections, you need a firewall, and if you have a firewall then inbound connections are blocked, so clearly the NAT isn't necessary for blocking inbound connections. You don't need to be scared about not using NAT.

"Session based obfuscation in IPv6 causes its own headaches for administrators"

In some cases, but not the ones you're thinking of there. Privacy addresses for a machine all come from the same /64, so for random internet clients you just match on the first 64 bits of the address. This is morally equivalent to matching on the WAN address of a NATed v4 network. I'll also tell you that privacy addresses are only changed once per day (or whenever you reboot or restart networking), so no, you don't see one IP per resource request and you won't need intimate web design knowledge to find log entries for a client.

Have you given any thought to what will happen when ISPs start putting people behind CGNAT for v4, and you end up with multiple different people accessing you from the same source IP? How do you plan on finding them in the logs then?

"Troubleshooting IPv6 will be a huge headache"

You don't have much experience with v6, do you? It's much easier to maintain and troubleshoot a network when there's no NAT involved. Since NAT is a de-facto requirement on v4, it's v4 that ends up being the huge headache to deal with (ever had to merge two networks with clashing RFC1918 ranges?), and it's is only going to get worse as the address crunch gets even more acute.

Nanashi

Re: Dear network geeks, IPv6 is crap because...

You should not be NATing at all on v6. It's true that 1:1 NAT is less terrible than masquerading, but it still involves rewriting addresses on packets. Just give your public addresses directly to your machines; I promise it's way less effort than NATing.

There are a few limited cases where NAT is useful (I'm thinking failover when using ISPs that refuse to support PI blocks), but in general you shouldn't be using it -- and as I say, if you do so anyway then you don't get to complain about it.

Nanashi

Re: Dear network geeks, IPv6 is crap because...

You should be getting enough address space to not need to NAT on v6, and if you do so anyway then you've brought all of the associated problems onto yourself, so you don't get to complain about them. This is, after all, kinda the reason v6 was designed with enough address bits in the first place (this plus routing aggregation).

Meanwhile v4 on NAT is necessary for the vast majority of people. That's why I'm doing the comparison between v4+NAT vs v6 without NAT.

Nanashi

Re: "nat-has-nothing-to-do-with-security"

No, it's not NAT that blocks connections or prevents routing. NAT doesn't do anything at the routing layer, it's purely an L3 thing, and also only applies to outbound connections in the typical setup. If you just send the router a packet with the correct dest address set already, then there's no inbound mapping required and no addresses need to be translated -- because the packet already has the right address. (As you say, the router won't be using its conntrack tables to deal with the packet, but that doesn't mean that the packet is impossible to process.)

The end of your post seems to indicate that you knew all of this already, so I'm not sure how you still managed to reach the wrong conclusion, but you're welcome to go and test this with some virtual machines, or even real routers, if you don't believe me. You'll find that they do in fact pass inbound traffic unless that traffic is blocked by a firewall.

Nanashi

Re: Dear network geeks, IPv6 is crap because...

The v4 network is behind NAT though, right? So you have to include the WAN address because it's part of the addressing of the network. Excluding it and then concluding that v4 is shorter because you've ignored half of the addresses involved is a little unfair, don't you think?

Nanashi

Re: Dear network geeks, IPv6 is crap because...

It's because they've actually used v6, and thus have discovered that most of the things you're complaining about aren't really a problem.

I don't understand why you think you can remember 203.0.113.42+172.18.10.10 and 203.0.113.42+172.18.10.20, yet won't be able to remember 2001:db8:113:10::10 and 2001:db8:113:10::20. The v6 versions make just as much sense as the v4 versions, and on top of that they're shorter. Yet you were complaining they're too long? I don't get it.

Nanashi

Re: Dear network geeks, IPv6 is crap because...

Then you're just being nonsensical, because you can't add a prefix to v4 addresses like that. There's only 32 bits in the v4 header for the address to go in, and all those bits are filled by the v4 address already (which is sort of the whole problem in a nutshell right there). But if your goal is just to get v4-only hosts to drop the packet then you don't need to play games with the address; there's a version field in the IP header and v6 is already making use of it.

Windows Vista, 7, 8, 8.1 and 10 all ship with a dual-stack firewall enabled out of the box. (XP SP2+ ship with a firewall but it's v4 only, but XP itself is v4-only out of the box anyway so that's okay.)

You might be able to talk your Grandmother through disabling UPnP, but don't forget that you also need to talk her through setting up NAT in the first place. That's harder than talking her through setting up a firewall, so this is yet another case where v6 would be better... if your Grandmother needed to set up either of them instead of just plugging in the ISP gear, which is already set up correctly.

Nanashi

Re: Dear network geeks, IPv6 is crap because...

Have you read any of the other comments on this article? Pretty much everything you brought up has already been addressed.

To briefly go over them again: addresses go in DNS so you don't need to remember most of them (I bet you can't remember El Reg's IP, can you? Yet you posted a comment to the site just fine.)

40 other networks? If you can remember the WAN IPs and RFC1918 range for all of those networks then you can remember the v6 prefix for them all too. (But why would you when you would just ssh to a hostname?)

Properly configured firewalls covers most users on the net, because their ISP hardware and OSs come with them out of the box. As you say, most of these users _don't_ care -- IPv6 just works for them.

(I find it interesting that in one paragraph you claim that nobody can configure anything, yet in the next you say "simply by turning off UPnP". These two paragraphs are inconsistent. Do you believe people can configure this stuff or not?)

And finally, the main thing wrong with "just prepend a letter and two numbers" is that it only adds 11 bits to the address. That's not enough. Why on earth would we go through all of the effort of migrating IP protocol, only to not add enough addresses and then have to go through it all again shortly afterwards? If we're going to migrate, let's migrate to something that's definitely big enough.

The only thing that hasn't been mentioned elsewhere is that 4 hex digits is a hell of a lot easier to subnet than anything involving decimal, because each hex digit corresponds exactly to 4 bits. That doesn't matter much to most people, but it's handy for network admins.

Nanashi

Re: Y U NO IPV6 BRO

With libsixel, of course.

Although if you've not heard of that before, you might want to avoid looking up how it works...

Nanashi

Re: "Let's use a firewall"

You actually can't assume that 10/8, 172.16/20 and 192.168/16 are local. What if your ISP configures 192.168.254.1 on their end and talks to your network from that? It would be RFC1918 but it wouldn't be local.

Determining what's local is done via either the routing table or the interface. For a router, you declare any traffic coming in on the local interface as local, and anything coming in on the WAN interface as global, regardless of what IP it uses. For end hosts (which only have one interface) you treat it as local if you have an on-link route for the prefix.

So, this stuff will work out of the box just fine in v6. Did you know that Windows does this with its firewall? If you set it to the Home profile, it allows connections from the local LAN but blocks them from other networks, and it does it in v4 and v6 without hardcoding the RFC1918 ranges. (If you set it to Public then it blocks connections from the local subnet too.)

Nanashi

Re: Address allocated but not live

No, I'm pretty sure that most people do want their stuff on the internet. That's why they bother to deploy NAT -- to get their machines on the internet even in the face of a lack of IP space to do it with.

And it definitely is true that there's not enough v4 space for everybody. It's also true that you can find unused v4 addresses, but... there aren't anywhere near enough (and fragmentation is a big issue). v4 is just not big enough.

(Also I shouldn't really need to say this again and again, but using v6 doesn't magically mean that all of your devices are accessible from the internet. Rejecting v6 because you think it means that is mistaken.)

Nanashi

You say that as if 40% is a small amount to be using. It's actually a really damn high amount to be using. Because of the way IPs are allocated and used, you want the number of actively-in-use-by-a-machine IPs to be less than a few percent. If you reach that high then you start hitting the need to conserve address space and things start to get annoying and expensive to deal with (which is a particularly silly situation to be in, because we're not dealing with a physically-constrained resource here -- these are just numbers).

It's a bit like fragmentation on your hard disk, where things slow down if you fill the drive, but worse because fragmenting IP allocations is really bad and there's no defragger you can run. And your disk is way too small anyway.

Nanashi

Re: IPv6 is fundamentally broken

You think NAT blocks connections and provides security, you don't know about DNS and you think that subnetting v4 is easier than v6, and yet you have the nerve to complain about "smug v6 bastards" not listening to you?

Just for starters, compare v6 addresses:

2001:db8:42:1::2

with the pair of addresses you get with NAT in v4:

213.0.113.42+192.168.1.2

The v6 is _shorter_. Why are you complaining about shorter? And once you put them in DNS you end up with "google.com" vs "google.com" and the length doesn't even matter.

This is the reason people aren't listening to you.

Windows 10 networking bug derails Microsoft's own IPv6 rollout

Nanashi

Re: A short and inaccurate history of NAT routers in the home

Yep, that's the point. If you configure a firewall then inbound connections will be blocked, but it's important to realize that configuring NAT doesn't automatically give you the firewall. The false sense of security comes when people set up NAT and expect it to block all inbound connections. Obviously doing NAT with no firewall is IMPROPERLY CONFIGURED, but a surprising number of people don't realize that!

(I find it interesting that v4 routers with no firewall are considered rare and improperly configured and irrelevant because of how broken they are, yet v6 routers with no firewall are apparently ubiquitous and acceptable and it's v6 at fault for the lack of firewall somehow, instead of the router manufacturer. Why the double standard?)

Nanashi

Re: I don't know what the fuss is about.

I didn't misunderstand; you just can't do that. If you want to connect a network to the v6 internet then you use v6 on it. You can't use v4 because there's not enough space in the v4 header to indicate which v6 host you want to connect to.

If you don't want to connect your network to the internet then that's fine; you can use a proxy over whatever local protocol you want (or just have no internet access). Pretty much nobody does that though.

Nanashi

Re: IPV6 is a bad design

The problem -- which el reg conveniently forgot in order to drive comments -- is that v4 isn't forward compatible, so it's not possible to make something which is somehow magically backwards compatible with it. Any approach you can take ends up looking like either 6to4, Teredo, NAT64+DNS64 or NAT64+464XLAT. Which as you can see already exist for v6.

I'll also note that v6 is both private and secure by default out of the box on current devices, and has been so for years (or at least it's no more terrible on those fronts than v4 is).

Nanashi

Re: A short and inaccurate history of NAT routers in the home

You're right -- NAT has indeed become a religion. The reality is that it's not required for security in the slightest. In v6, everything comes into your home via the router, and the router drops all inbound connections unless explicitly configured otherwise. That should sound familiar, because it's the exact behavior that you're attributing to NAT.

(In fact, as mentioned earlier in the comments, NAT often gives people a false sense of security, because it doesn't actually block any connections at all. Anybody that can send packets to your router with a dest IP set to 192.168.1.x can connect to your LAN machines regardless of any NAT going on on the router. It's true that most of the internet won't be able to do that, but your ISP certainly can, and so can any government agencies that feel like leaning on the ISP. You want your network to be actually secure? You can't use NAT for that.)

Nanashi

Re: Remembering IP's

It's not like remembering v6 addresses is even particularly hard. You can set most of the address to be zeros, which means you only have to remember approximately 64 bits:

2001:db8:42:1::5

which compares pretty well to v4 where you have to remember two 32-bit addresses:

203.0.113.42+192.168.1.5

Heck, the v6 address is shorter! If you think this needs to be hard then you haven't used v6 much.

Nanashi

Re: Sigh

Actually, Windows has been shipping with a enabled-by-default firewall that blocks inbound connections from the internet for over 10 years now.

On top of that, most people are sitting behind a router that does inbound firewalling on top of that, so in general there are *two* firewalls between your well-known listening ports and THE INTARWEBS. This is not the problem that it once was back in the dial-up days (where nobody used a router and Windows didn't have a firewall).

Nanashi

Re: I don't know what the fuss is about.

Is your network connected to the internet? If so then it's part of the internet, and hence falls under "should be IPv6".

Of course if your network really isn't connected to the internet then you can go ahead and keep using v4 (or IPX or whatever) on it, but very few networks are isolated these days.

IPv4 apocalypse means we just can't measure the internet any more

Nanashi

Re: And who told you I want to be measured?

Which doesn't seem to be the case, e.g. both Comcast and Sky have big v6 deployments and they deploy working firewalls on their CPEs. Their customers are no more vulnerable to "somebody on the internet can try to connect to me" on v6 than they are on v4.

> With just a basic fw you'd be DDOS'd in no time, be pawn'd & its totally worthwhile for scammers & hackers to do.

Um... no. Just no to all of those. Removing NAT and using only a basic firewall (which these days means "blocks inbound connections while blindly permitting all outbound connections") doesn't make any of these more likely.

>>There are some highly upvoted posts above to the effect of "but v6 will let the NSA/GHCQ/etc get access to my network"

> yes, this is true, without NAT your internal addresses are publicly routable

It's not true. "Routable" doesn't mean "connectable". Not having NAT does not mean that anybody can connect to any of your machines whenever they want. You still have to permit the connection on your firewall.

Nanashi

Re: And who told you I want to be measured?

Right, exactly: the existence of NAT does not stop routing from happening. It's nice that somebody gets it.

It was a valid test for what I was trying to demonstrate with it: that you *can* simply route through a router even when the router does NAT. There's no point constructing a packet that will hit the NAT engine, because the whole point was to show that inbound connections _don't_ touch the NAT.

I know this is all obvious stuff, but there were quite a few people above that argued pretty strongly that it didn't work like this.

> If your ISP supplied home router is so crap that it accepts and forwards traffic with dst addresses being in the same rfc 1918 address range as those on the inside of your network then you need to get a better router.

I agree, but the key thing to realize is that "better router" means "a router with a firewall". And that firewall is exactly what you need to prevent inbound connections on v6 too. You don't need any NAT for that.

> it won't work with connections originating from the internet.

Right, but not because of the NAT, only because people on the internet can't send packets with a dst IP of 192.168.y.x and have them show up at your router. It's just important to note that your ISP (or someone capable of strongarming them) could in fact do this.

There are some highly upvoted posts above to the effect of "but v6 will let the NSA/GHCQ/etc get access to my network" (so apparently this _is_ something people worry about, or else why use it as an argument?). But if you're relying on NAT for this then you've already screwed up, and in fact the lack of NAT in v6 will help because it'll remove your false sense of security. For some reason there are people arguing against doing this.

Nanashi

Re: And who told you I want to be measured?

No, your understanding of my network layout (and NAT) is wrong. It actually looks like this:

My router to ISP = <my WAN address that I don't really want to post>

My router to my Linux server: 203.0.113.1

My Linux server outside (upstream) IP = 203.0.113.2

My Linux server inside (downstream) IP = 192.168.128.1

My Linux VM host = 192.168.128.2

The NAT I installed to test with was on the Linux server, NATing outbound connections from 192.168.128.x to appear to come from 203.0.113.2. The pings/traceroutes above started at my router -- that's why there's two hops in the traceroute rather than just one.

> 1) you configuiered your nat to just nat your outbound connections it will have no affect on your inbound connection

Yep. This is the normal way of doing NAT. (Port forwards are slightly different, but I'm not setting any port forwards up here -- even for that port 443 connection I made.)

> 2) you did a traceroute to an internal host, if you where testing nat you would be addressing the outside ip, 203.0.113.2, on some port its nat process would know to translate to an inside IP.

No, I'm definitely testing the NAT here. I'm showing what a NATing router does if you send it a packet with the dest IP set to one of the LAN machine IPs. Setting the dest IP to 203.0.113.2 wouldn't demonstrate that very well.

> 3) You are initiating a connection from outside to inside, effectively just routing from 1 subnet to another.

This is completely correct. I am indeed just routing from one subnet to another. That's why I said this isn't an extraordinary claim at all. Routers route, it's what they do. Even if the router is also NATing, it'll still process packets that don't meet the condition to be NATed, which means that your ISP can send you packets with the dest IP set to one of your LAN machines and those packets will happily be routed onwards (unless you dropped them with a firewall).

>think about it, its impossible to come from the outside to inside over nat if the port mapping relationship hasn't been created first from teh tarffic initiated from the inside. How can the nat process route to the correct inside host when it doesn't know what host it needs to send to.

Did you read my posts above? There's no need to involve the NAT part of the router here at all. All that needs to happen is that a packet comes in from your WAN interface with the dest IP already set to one of your LAN machine IPs. Then NAT doesn't need to rewrite the address to one of your LAN machines, because it's already set to one!

(Note that NAT doesn't route, it just changes IPs/ports in packet headers. Routing is a completely separate thing that doesn't rely on NAT at all. When you set up a port forward, you're essentially pre-processing packets to have a LAN dest IP before they hit the routing engine -- but there's no need to do that if they already have a LAN dest IP.)

And there's no point linking to a page about bogons. If your ISP (or whoever is strong-arming them into helping) is trying to access your network this way, then they aren't going to filter their own traffic. You need to be dropping these packets yourself (NAT won't do the job, as I keep explaining).

Nanashi

Re: And who told you I want to be measured?

What exactly am I supposed to say here? Even looking at the theory, NAT doesn't block inbound connections, and I just demonstrated it in practice too. I can even traceroute in from the upstream side:

traceroute to 192.168.128.2 (192.168.128.2), 30 hops max, 60 byte packets

1 203.0.113.2 (203.0.113.2) 1.160 ms 1.007 ms 0.678 ms

2 192.168.128.2 (192.168.128.2) 1.056 ms 1.632 ms 0.542 ms

and it works perfectly fine. Obviously I had to add a route to 192.168.128.0/24 via 203.0.113.2, but I did say that originally: "your ISP [who can add such a route on their side] can access your network if you don't have a firewall, even if you have NAT".

This is just bog standard routing, it's nothing close to an extraordinary claim.

> No you haven't. The packets do not leave the kernel in that situation, Put a real analyser on the wire and you will see that you are not putting packets WAN-side.

Ah, I suppose you misunderstood my network layout (or I phrased it badly). I have one router attached to the ISP, and I have a separate Linux server attached behind that router. The Linux server runs LXC, and has a software bridge interface to which all the containers are attached. The server then routes (not bridges) between the bridge interface and my main LAN. Getting out to the internet from an LXC container requires going through two routing hops (the Linux server and the main router) before hitting the ISP's network.

From the perspective of the Linux server, my main router occupies the position that the ISP router normally occupies for most people's home router.

FWIW I do see the packets in tcpdump, on all parts of the link:

21:21:48.601083 IP 203.0.113.1 > 192.168.128.2: ICMP echo request, id 19286, seq 4, length 40

21:21:48.601188 IP 192.168.128.2 > 203.0.113.1: ICMP echo reply, id 19286, seq 4, length 40

(203.0.113.1 is the main router, 192.168.128.2 is the VM. The Linux server is sitting between them, with 203.0.113.2 on its upstream side and 192.168.128.1 on its downstream side.) TCP works too, in case you think it's just ICMP:

21:22:52.828393 IP 203.0.113.1.58732 > 192.168.128.2.443: Flags [S], seq 3300493212, [...], length 0

21:22:52.828516 IP 192.168.128.2.443 > 203.0.113.1.58732: Flags [S.], seq 1444074273, [...], length 0

21:22:52.829588 IP 203.0.113.1.58732 > 192.168.128.2.443: Flags [.], ack 1, [...], length 0

The three-way handshake completes, even when I'm applying NAT to outbound connections. (This is after all an inbound connection, so it's unaffected by what I do to outbound connections.)

Incidentally, I had to add this on the Linux server to get that inbound TCP connection to work, otherwise I got "connection refused" back:

iptables -I FORWARD -d 192.168.128.2 -p tcp --dport 443 -j ACCEPT

In other words, the connection didn't work unless I poked a hole in my firewall. Which is just more evidence that a firewall is necessary to block inbound connections even when NAT is involved.

> If you think IPv6 router are in common operation, you ave a nasty shock coming. Your configuration i very far from usual. I would go so far as to say "niche". IPv6 just isn't widely deployed, however much anyopne might like it to be.

80% of Sky users are using v6 as we speak. That's not a majority of the UK (it's about 15%), but it's far from niche -- it's millions of networks. The 15% is straight from Google, if you don't believe me:

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

And Sky's default router (which is exactly what some crazy high percentage -- I think 95-98% -- of their user base uses) does indeed have a firewall out of the box (and doesn't use NAT for v6 either).

Nanashi

Re: And who told you I want to be measured?

>>Yeah, I have, and I just tried it again for the sake of argument.

>I really doubt that you have.

If you're not going to believe me, then what was the point of asking me if I've done it?

> Fine. You've enabled NAT on your outbound connections.

Yep, and inbound connections still worked. That was the point that I've been making all along: NAT doesn't block inbound connections.

> OK - so tell us how you put bogons onto your WAN--side connection.

> This is something I could do when I worked for an ISP. It;s not something I can do now. I'd be interested to hear how you did it. If you did it.

With "ip addr add". I have a routed internal network, so essentially my main router is the WAN-side interface of the second router. I have full control over both and can put whatever IPs I like on any interfaces.

> No you shouldn't, because what you claim depends on bogons being routed by your ISP (which *never* happens unless your ISP is deliberately doing such) *and* it depends on the behaviour of your WAN-side equipment.

Didn't I say that right from the start? "Your ISP could access your network" and "if you don't have a firewall". Obviously that requires your ISP to deliberately do something, and it requires your equipment to not have a firewall. That was the whole point: NAT doesn't block inbound connections, and you need to have a firewall to do that. If you do in fact have a firewall (which is far more common than you think it is) then it won't work -- but the reason is because of the firewall, not because of the NAT.

> I have quite a few pieces of equipment that do exactly that - including the one I'm using right now. Are you trying to tell me that they can't exist?

Of course they do exist, but they're not what ISPs are using to deploy v6. Look at Comcast or Sky, they have millions and millions of users doing v6 and they aren't using routers that have no firewall out of the box.

Also you said this: "our experiments with forging LAN addresses on the WAN port only got through to the LAN side on a few really shitty routers". I guess your Vigor 2600v is one of those really shitty routers. Most enterprise routers probably fall into this category too (at least for the purpose of mass-market v6 deployment), since they make you configure everything yourself, but those aren't what ISPs are using to deploy v6 to their user base.

> Really? How do I pick my prefixes, then? Because the ones I've got were allocated to me by my upstream providers, and they're really not very memorable.

In exactly the same way you pick your v4 WAN addresses. Which, yes, means that they're assigned to you and not very memorable, but that's the same as in v4 so if you're happy with it there then you should be happy with it here.

> Yes you do. If the address is routable - as it is with v6 - it will be routed. Thus you have moved from default DENY to default ACCEPT.

This really depends very much on the firewall you have. Your traffic won't be routed if it's dropped by the firewall, which inbound traffic will be by default on the routers issued by ISPs doing v6.

> The ALGs only make things worse, not better, so it's a bit of a stretch to make the claim that you have; it would be more appropriate to say that certain manufacturers have made a prize cock-up in their kit. Actually, that's all that needs saying; - those ALGs are simply broken software deployed by someone who didn't know how to do the job properly.

Sure, but the point was that the manufacturers added the ALGs to try to fix up protocols that have trouble working through NAT. So it cost you money to pay them to program the ALGs, and then it cost you again when you tried to use them and they made things worse and you had to figure out what went wrong. And the root trigger for all of this was our use of NAT.

> OK - fine. Cost of setting up NAT on my network - £0. It was pre-installed. Cost of setting up firewall - I don't know. I've never costed it. But it took effort on my behalf. So actually - it's a very fair comparison.

Not for the vast majority of internet users ("as close to everybody as makes no difference"). You're using an outdated "really shitty" router, whereas ISPs are deploying routers where the inbound firewall /is/ set up by default. A fair comparison would use the routers that people are actually using.

Nanashi

Re: And who told you I want to be measured?

> the problem is the auto assigned /64 portion of the address is uses EUI and is made up from the machines MAC address. MAC addresses are well defined, from a known pool and are therefore in a small enough pool to be scanned. In addition, any receiving system can determine what vendor the originating machine is and from your subnet a collating service can determine how many hosts are on your network. in addition every time you connect it can track you from net to net, like from home, work, star bucks etc as the /64 can be the same across nets as it can be globally unique (as it uses the MAC address)

Not quite. There are two things you've missed here: RFC 7217-style opaque identifiers and privacy extensions.

Privacy extensions basically means that your host picks a random IP (which it changes frequently) from the subnet for outbound connections. People you connect to won't get your MAC address, and since the IP changes every time you change network you can't be tracked between subnets either. (The MAC-based v6 address is still assigned on the system, but it's only used for incoming connections.)

RFC 7217 opaque identifiers replaces the MAC-based addresses with a hash of the network prefix, the MAC and some secret value. Essentially this means you get a random address for each network you're on, but you always get the same address per network. Note that you still get privacy extensions (which are completely random) on top of this for outbound connections.

Privacy extensions are enabled by default on pretty much everything, and the RFC 7217 stuff is available and enabled by default on Windows 7+, the current version of OS X and in some cases on Linux. So the conclusions from your paragraph generally aren't what happens in practice.

> IP's are much harder to memorise in v6. if your /64 is constantly changing how are you meant to set your firewall rules to secure some hosts and not others

It's honestly really isn't (provided you've picked easy to remember addresses; it's possible to pick hard to remember addresses but if you do that _and_ refuse to use DNS then you only have yourself to blame). It's about as hard as v4's pair of two addresses is.

Firewalls can match on just the last 64 bits (or can generate the full 128 bits based on your current network setup). Although I do agree that dynamic prefixes suck and really should be avoided.

> NAT is easy to understand, especially for those who had no clue it was protecting their home setups.

I could grant you this, but not having NAT is still easier to understand than having it. There's no way that rewriting the address of packets in mid-flight is easier to understand than not doing it.

> the whole point of public addressing is to be able to route from point to point. no matter how often the IP changes it is clearly identifiable as it routes back to your continent, country, ISP and then your subnet they provide to you.

But it's no more identifiable than a NATed v4 network. Your v6 prefix is as identifiable as your WAN v4 address is, and the host part of the v6 address is basically random so it doesn't reveal any useful information.

You can certainly argue how identifiable an IP address is, but v6 addresses are no worse than v4 ones in this regard.

>> NAT is what makes consumer level broadband safe enough to do e-commerce over. [...] this is correct

No, what makes it safe is that people can't connect to machines on your network without manually permitting the connection. This isn't something you lose by deploying v6, so it's not a valid argument for not going to v6.

(Or, well, are we just ignoring TLS, remote code execution vulnerabilities in browsers and the fact that users are idiots and will run whatever dodgy crap they feel like? It feels like you have a conveniently narrow definition of security here.)

Nanashi

Re: And who told you I want to be measured?

> Have you actually tried this? Because when I did, it was only true for some real shit routers. Now I've not done the experiment for a while, but I actually do doubt your assertion here.

Yeah, I have, and I just tried it again for the sake of argument. I have a network running here with a Linux router and no NAT, and I can connect inbound to a few whitelisted host:port combinations. I just added NAT by doing this:

iptables -t nat -A POSTROUTING --out-interface wan0 -j MASQUERADE

and confirmed that outbound connections were NATed. Then I tried the inbound connections again, and... they still worked.

You should be able to tell that would happen by inspection of the iptables command though. Only the first packet of each connection goes through the nat table, and the MASQUERADE rule has "--out-interface wan0" in it. The first packet of any inbound connection will be coming _in_ from wan0, not going out of it! This masquerade rule doesn't match inbound connections at all, so whether or not you're doing NAT with this rule clearly can't affect inbound connections in any way, because the rule won't do anything to packets that don't match it.

> Of course it is. Plug in router, stuff works. [...] Now try doing that with a simple firewall - changing the rule from DROP to ACCEPT on the basis of the state of outgoing packets. It's possible, but it;s not easy.

Here's how you do a firewall in iptables:

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

iptables -A FORWARD -i lan0 -j ACCEPT

iptables -P FORWARD DROP

which does exactly what you said: packets corresponding to established connections are ACCEPTED, new connections from lan0 are ACCEPTED and new connections from any other interface are DROPed. This isn't hard.

And again, you're doing an unfair comparison. You're assuming that NAT is already set up on the router but that a firewall won't be. Why isn't it "plug in router, stuff works" for a firewall too, given that the firewall will be set up (and indeed apparently was on most of the routers you tested) by default out of the box too?

> Taking that away from them means they have to learn to program a firewall - now you might claim that it's "two rules which you copy/paste from a website", but the vast bulk of these users couldn't even get a text editor to change the correct file.

It doesn't mean that. That's like saying that those people couldn't set up NAT because they can't work out a text editor -- which they probably couldn't, but that's okay because it's already set up for them. Just like the firewall is.

Nanashi

Re: And who told you I want to be measured?

> This is simply incorrect. Incoming TCP connections might need some assistance in the event of CGNAT, but UDP doesn't. And if you're looking for the sort of isochronous connections that end-users might generally want - games, VoIP, that sort of thing - then UDP is going to be what you're after. If you want to set up web or mail servers, CGNAT probably isn't for you. But how many of us want to run web or mail servers and don't know how to work around CGNAT?

There's a huge pile of problems here. Even if it works in theory, it's not going to work so great in practice if the CGNAT is overloaded, or on a non-optimal network path, or if it has a super-aggressive timeout period. Even if none of those are a problem, it still costs money for the hardware and to maintain it. And sure, I know how to work around it (I buy a VPS with a public IP address -- which makes the huge assumption that those are even available. You DID get the "we're out of v4 addresses" memo, right?), but I shouldn't have to work around it in the first place. Nobody should.

I notice you didn't even mention all the protocols that aren't TCP and UDP. Those should work too.

CGNAT is no way to run an internet. It's a good way to phase out v4, but it's not what we should be picking for the next thousand years of internet growth.

> Indeed - the only time I've had difficulty with such setups is when the router tries to do something clever; a colleague of mine from years ago use to love putting Juniper kit anywhere he could. I soon found that the best way to use this was to turn off every ALG it offered; they were all crap.

Of course if it wasn't for NAT then they wouldn't have had the ALGs in the first place...

> Well, I can install SIP phones on an IPv4 network without a firewall, and they just work. If I install them on an IPv6 network, I must have a firewall to prevent the administration interfaces being visible to the Internet at large. I fail to see how this is "easier".

That's not a fair comparison. Either include the cost of setting up NAT on v4, because the phones won't work without it, or don't include the cost of setting the firewall up on v6. You can't argue "but the NAT was already set up for me" because the same will be true of the firewall on v6 (unless you're configuring your own router, in which case neither NAT nor a firewall will be configured by default).

> The visibility of your data to an attacker is entirely unrelated to the transport mechanism chosen. [...] CGNAT does not preclude TLS. Nor, indeed, does it make any difference in either direction to the snoopability of plaintext.

If your plaintext is going via a company's server, then it's a lot more snoopable for that company than if it wasn't.

TLS (or rather end-to-end encryption) is a good point. Can be hard to verify though, and we do still have all the other issues associated with relaying (it costs more money, it relies on servers that can get shut down, it's slower than direct). Relaying is a decent workaround for the inability to make direct connections, but again it's not something that should be a permanent requirement of the future internet. That's something we should be working to avoid.

> In protocol terms, yes. In human terms, no. Any time you have to get humans to modify their behaviour in any significant way in order to accommodate a computer, you've almost certainly screwed up.

The good news is that you use v6 the same way you use v4: by plugging in all of the stuff your ISP sent you and then pointing your browser to a search engine, typing into the search box, and then clicking a link. No significant changes there.

> A 64-bit address space with a MAU of /16 would give you individual prefixes for nearly 3x1014 users, with 65K addresses for each. Given that this planet really can't support 1010 people, and that no individual is going to be able to maintain 65K devices, that would have been enough until approximately the time we've colonised 10,000 other worlds. I can't see that happening before Christmas, if I'm honest.

It's funny, here you are arguing that v6 is too big and yet there's a poster earlier on that thinks it'll run out in five years. Your estimate for v6 use is at minimum _nineteen orders of magnitude_ lower than his. That's just crazy.

I'm not convinced 64 bits would be enough. It might be, but I'm not convinced we'd be able to avoid NAT on it indefinitely. And this is something we really don't want to be wrong on, because we'll be stuck with whatever we pick. 128 bits is definitely overkill (I'd say 80-96 is probably right, but those aren't powers of 2), but it's better to be stuck with overkill than a shortage.

> For starters, that's all very well if you know the prefix. But the prefix is the bit that will need memorising; most public addresses are likely to be on low subnet/address pairs, but the prefix is going to be utterly unpredictable.

There's some structure, for instance you should be getting a /48 or maybe a /56 so the last 8-16 bits will be zero, and the first 16 bits will usually be 2a0X or so in Europe. You end up with 32 bits of randomness and 16-24 bits that are selected from a small set of possibilities -- which is very similar to v4 with the WAN address (random) and LAN prefix (selected from small set of possibilities).

If you work on a v6 network for a while, you won't have any trouble remembering the prefix for it, and if you can't then it's just a copy/paste away in `ifconfig`.

Really the biggest downside is that you have to type the entire damn thing out. There needs to be some way to do "~::53" or something to refer to an IP in the current subnet. Between DNS and the clipboard it's rare to need to type an IP, but it could do with being easier when you do.

In any case, none of this is a show-stopper for v6, which we still need to do. You're a networking professional and it's your job to deal with it on behalf of users. And you yourself said that users aren't even "the vast majority" but "as close to everyone as makes no difference", so why would the job of the DNS repairman make a difference?

> So we all know that Google runs a DNS server on 8.8.8.8. But if you want to do that over IPv6, it's on 2001:4860:4860::8888. They've clearly worked hard to get the repetition into that prefix, but that's still not a number I can carry in my head.

This is another unfair comparison. You're comparing an easily-remembered v4 address to a less-easily-remembered v6 address. How about we use the IP of www.sprint.net instead?

www.sprint.net. 3560 IN A 208.24.22.50

www.sprint.net. 3555 IN AAAA 2600::

Suddenly, v6 is easier to remember.

> It's quite a few years since I worked for an ISP, but when I did, our experiments with forging LAN addresses on the WAN port only got through to the LAN side on a few really shitty routers.

Right, this is kinda my point: they only got through to the LAN side on routers that didn't have firewalls. On routers that did have firewalls, they didn't get through. I was very careful to say "unless you prevent them with a firewall".

Take note here, because it's important: those routers had firewalls. How much effort were those firewalls to set up? Right: none, because you didn't set them up, they just came with them, and they worked. The same is true on the v6 side of v6-supporting routers.

> To get the perimeter afforded by the first, you need to add a stateful firewall, which is another piece of equipment that needs maintenance. This is an increase in complexity, which might well be a show-stopper for those not versed in networking.

In practice it's the same piece of equipment that does your NATing, and it does it out of the box. There is no practical increase in complexity here for those not versed in networking, because the only required steps are "plug in the box from the ISP". (Not to say that there aren't people who have trouble doing that...)

> But I also have a fair bit of contact with "home users", for whom the transition to IPv6 without NAT will be a total nightmare.

Over 5 million UK internet users have already been through this transition, and it wasn't a nightmare. (Just to be clear: they aren't using NAT and they are using a firewall, and they didn't have to learn or do anything extra to do that.)

This is good news: your fears aren't reflected in reality.

Nanashi

Re: And who told you I want to be measured?

> IPv4 nat is accidental security, where is the IPv6 security by default equivalent?

On your router, and on Windows. Both of those will block inbound connections on v6 by default.

> The vast number of /64 host addresses is no deterrent to address scanning when you know part of the address resides in the known manufacturer ranges limiting scanning to a vastly reduced subset of the total, plus you could scan for apple, HP, Sony devices etc to target those conceivably more affluent marks.

This depends, there's an RFC (RFC 7217) to address this and Apple just added support for it. Windows has done basically the same thing since Windows 7, and dhcpcd has support for it on Linux. And even knowing the MAC prefix still leaves you with 16 million addresses to scan -- which is no longer an utterly impossible number but it's still over half a gigabyte of traffic _per OUI_, multiplied by however many /64s you're interested in. And your traffic is still blocked by the firewall so finding a computer doesn't even help you much.

> Where the NAT situation scores is that any other connection attempt - i.e. an unsolicited inbound connection - simply has nowhere to go.

But this is not true. It's a nice and easy way of explaining NAT, but it's not actually true.

Consider what happens if your router gets a packet on its WAN interface with, say, 192.168.1.20 as the destination address. What will it do with it? You can't say the packet has nowhere to go, because it certainly does -- it can go to 192.168.1.20. And that's exactly where it'll go if the router doesn't have a firewall configured to drop the packet.

(The other possibility is that it receives a packet with a dest address of the WAN interface. In that case, the packet also has somewhere to go: the router itself.)

If you don't believe me, feel free to try it.

> [NAT] provides an easy setup for those that don't know how to maintain a firewall

NAT is no easier or harder to set up than a firewall is. With netfilter on Linux, an inbound firewall is two rules which you copy/paste from a website, and NAT is one rule which you also copy/paste from a website (but don't forget the firewall rules as well, or your ISP will be able to connect into your network like I explained above).

If you can't manage one of those then you can't manage the other. Anybody that can manage to set up NAT can manage to set up a firewall. The problem with NAT is that actually running a network with NAT is harder than running one without it, because translating addresses mid-flight is an extra layer of unnecessary complexity to deal with.

> it is entirely transparent to everyone else.

Ah, well, if only that was the case, but I run networks that don't use any NAT at all and I still have to deal with NAT (when I help other people or when I write -- or use -- software that's affected by it). If we can get NAT down to <1% of connections then it'll be ignorable, but we can't do that without doing v6.

Nanashi

Re: And who told you I want to be measured?

And here's the megapost. I'm shooting myself in the foot by responding to everybody in a giant wall of text that nobody will ever read (except the moderators – sorry guys), but there's just so much outright wrong stuff being posted that somebody's got to do it.

> I don't see Sky turning off IPv4. They *could* decide to share public IPv4 addresses between customers, but as soon as they do that they are into a world of pain when it comes to handling police enquiries, having to log or lock down the port ranges used by each customer.

This will definitely happen. There plain and simply aren't enough v4 addresses to avoid doing this forever. It probably won't be next week or anything, but it'll happen. And yes, it'll suck -- which is why we need to be doing v6 _now_ so we're in a position to ignore the suckage when it happens.

> It seems to me there's a genuine risk of "peak IPv6" - where the majority of the marketplace rejects it

I worry about this sometimes. It's part of the reason that I'm in here trying to dispell people's misconceptions of v6 -- if too many people disable it then we'll never get to the point where random websites go v6-only, which means we'll be stuck with v4 forever. Surely that's not something we want, but a lot of people seem to be masochists when it comes to networking...

> Yes there is. The majority of users do not want inbound connections - or when they do, they want those connections very carefully controlled. At present, with IPv4, they've got that; the default is for connections to be denied

I could easily rephrase this to "the majority of people want to be capable of accepting inbound connections in at least some circumstances", and for that we're going to need v6. v4 just isn't going to cut it.

> And yet, here I am, running peer-to-peer communication through at least one layer of NAT (two for my wireless devices).

Behind CGNAT? If not then I suspect that'll be a nasty surprise for you when it happens.

Also... I'm doing this too, on v4. I know it's possible. But I'm also doing it on v6, and I can tell you that it's just easier on v6. NAT doesn't seem hard until you get rid of it, and suddenly you realize how much of a pain it really was.

> It isn't. That's partly because it's the zero-configuration option, and partly because it's how the IoT companies monetise their marks.

And partly because there's no other choice. Do you want it to be _possible_ for a company to release something that isn't trivial to spy on, or not? Not every company wants all your info (just most), but none of them will have any choice if everybody is behind CGNAT.

> Look, all everybody wanted was a larger address space. Can we planitively ask why you have just added an extra two fields to IPv4 (ie 192.168.0.1 becomes 0.0.192.168.0.1, taking the address space from (254*254*254*254) ~four point one billion addresses to (254*254*254*254*254*254) ~two hundred sixty-eight trillion, five hundred thirty-five billion addresses?

You can, and I can answer, but it's not that hard to figure out.

Adding two bytes is exactly as hard as adding 12 bytes. If you're going to add bytes, you may as well add enough bytes that you don't need to go "whoops, we didn't add enough, we need to go through all that again" later on.

(Perhaps you're thinking that 48 bits would be enough? But no, it wouldn't. It probably wouldn't even be enough to avoid NAT for more than a decade or two, let alone the thousands of years that I expect the internet to be around for. Read RFCs 1715 and 3194 for an explanation of why we need a lot more space than you'd think.)

> You could still actually memorise network addresses and layouts and talk to people about them. You can say (and remember) 10.0.1.20, you can't say (or reasonably be expected to remember) 3ffe:1900:4545:3:200:f8ff:fe21:67cf.

Okay, for starters: DNS. It's awesome and it's been around for years now and it makes your life a lot easier; I really suggest you read up on it.

For seconds: why did you pick such an awkward v6 address? If you needed to remember this address you should've picked something easier to remember, like 3ffe:1900:4545:3::2 (read that as "address 2 on subnet 3").

For thirds: it's not just "10.0.1.20" on v4, you also have your public v4 address to remember. So really, this comparison isn't "10.0.1.20 vs 3ffe:1900:4545:3:200:f8ff:fe21:67cf" but rather "203.0.113.45+10.0.1.20 vs 3ffe:1900:4545:3::2". The v6 address is actually three characters SHORTER than the v4 address pair. It's actually _easier_ to remember.

Finally, I think that if you refuse to use DNS _and_ you deliberately pick hard to remember addresses, then you can't really complain about how hard the addresses are to remember. You brought it on yourself.

> I judge the equipment manufacturers enthusiasm by the lack of cheap firewalls suitable for home users for under 50% of a users monthly takehome pay a decade on.

Most people can get appropriate hardware from their ISP for free. It does not cost you £500+ to start doing v6 at home.

> Now, because you were assigned an IPv6 netblock, your IP addresses are UNIQUE TO YOUR MACHINE, FOREVER.

Your post was good up until this line. This line is completely wrong. Your addresses aren't unique to your machine forever. Your address changes whenever you move between networks, and in fact it changes regularly even on the same network (if you have privacy extensions enabled, which is the default on most OSs).

> BUT, whenever you visit some web site, the web site knows who connected, YOUR publicly visible IPv6 address that is NOT translated.

This is true. The address will become useless after a while, because you won't be using it for long, but in that period the website could attempt to connect to you. At which point your firewall will block the connection.

Meanwhile the website served you a supercookie so it can track you wherever you go, and one of its adverts used a drive-by security vulnerability to infect you with a virus. But for some reason nobody worries about that.

> and what is more - with IPv6 packets you visited the website with digitally signed evidence

Uh, no. It's just an IP packet, it's no different to v4. No digital signatures here (unless you're using IPsec, but you could be using that in v4 too).

> IP4 addresses behind NAT are UNROUTEABLE. You cant reach them, and unless they make an outbound connection, you dont even know for sure they are there.

I do like to point out that this isn't completely true: your ISP (or anyone who can strongarm them) can connect to you even if you're behind a NATing router, unless you prevent them with a firewall.

> And even if they do, you cant be sure which internal machine is originating the connection.

The same is true in v6 with privacy extensions, which are enabled out of the box on most OSs.

> NAT is what makes consumer level broadband safe enough to do e-commerce over.

No. *Firewalls* are what make consumer-level broadband safe enough to do e-commerce over. NAT just saves you from having to set up a proxy server. (Or are you saying that Sky aren't secure enough for e-commerce now that they have v6?)

> The thought of machines with clearly identifiable unique routeable IP6 addresses on the public Internet, relying on user set up firewalls to protect them, scares me ****less.

It shouldn't. This is nothing like as big a deal as you think it is. The addresses aren't clearly identifiable (they're just random numbers that change often) and firewalls are set up automatically by ISP routers and by your OS.

> If I ever setup V6 I will still want a NAT equipped router between me and it.

You are free to do this to yourself. I accept your right to make your own life more annoying than it needs to be for no real benefit. Just don't force it on anybody else.

> The secure perimeter we now all have with ISP-supplied routers (no more USB cable modems, yay!) is the reason why the crims have now moved to the client-based penetration attempts. Take the perimeter wall away, and we're back to 1993.

IPv6 does _not_ take this perimeter away. You will still have the ISP-supplied router and it'll still be the perimeter to your network. Your network will still be yours and you'll still be in control of who gets to connect to machines on it. In fact v6 is what will let you keep that control – with CGNAT, you're going to lose it on v4.

> There is no downside to v6 if you understand networking. If you don't, Internet use will become much trickier.

This is backwards. NAT is the tricky thing to understand; things are a lot easier without it. Note that I'm basing this on actual experience, not fear of the unknown like most other people in this thread.

Nanashi

Re: And who told you I want to be measured?

> That's incorrect. You are perfectly able to make outgoing connections on a non-NATted connection as well; it is the firewall that prevents such outgoing traffic - and setting up a firewall for a NATted IPv4 connection is just the same as for a non-NATted IPv6 connection.

I should've explained that a bit better. You can make outbound connections without NAT, but only if you're using public addresses for your network. Obviously ISPs don't have enough v4 addresses for you to do that, so that means your internal network will be on one of the shared RFC1918 ranges.

In that situation, you can't make outbound connections from your LAN. They just won't work -- nothing to do with any firewall, it's just that you can't make connections on the internet without using a globally-routed address as the source address. So what do 99% of people do in this situation? They add NAT to their network, so they can make outbound connections.

And now, hopefully, you see what I mean by "the entire point of NAT is to let you make outbound connections which you otherwise wouldn't be able to make".

Nanashi

Re: And who told you I want to be measured?

Many people above have argued that v6 needs you to manually go out of your way to set your own firewall up in order to be safe.

It's not true. ISPs are deploying v6 with routers that have a firewall configured out of the box, and on top of that Windows ships with its own firewall that's also enabled out of the box. If you're just a clueless end user that knows nothing of anything... you'll have a firewall. This is a solved problem.

The difference with v6 is that it's actually possible to selectively disable bits of the firewall to allow an inbound connection. That's still mostly doable on v4 at the moment, but with CGNAT coming soon you won't be able to do that (because your ISP will put you behind their own NAT, and you won't be able to configure a port forward on their NAT). Having the ability to do this is a good thing, but going forwards you'll need v6 for it.

Nanashi

Re: I don't want to be measured!

> I routinely do inbound connections with IPv4. Never heard about a thing called "VPN"? It works through NAT too...

Using a VPN for inbound connections is just piling more hacks on top of hacks (and it's a big headache compared to just connecting to the machine you want to connect to), and the fact that you _can_ do it doesn't mean we shouldn't do IPv6.

> Games will keep on using central/cloud server more and more because that's how they make more and more money.

Maybe. But again, this isn't a reason to not do v6; we should be laying the groundwork to at least make it _possible_ for games to avoid going the central server route, because they certainly will go that route if they can't do anything else.

> Sure, I can use IPv6 and put enough security layers in front of my LAN so it won't change much - but it's not cheap because it means decent firewalls, routers, access point and switches

Actually it just needs a regular router, like the kind your ISP gives you. I realize ISP routers always suck, but they do function just fine as a firewall. Or you can replace it with your own router, roughly all of which support firewalling inbound v6. It's not expensive.

> Many others with cheap hardware will start to live in a crystal box - which after all is what Google & C. really wants.

Except not. Where did you get this "crystal box" idea from? IPv6 isn't a crystal box. Not having NAT doesn't magically make your network all open and visible for everybody. It's still your network, you're still behind a router and a firewall, it's still private. IPv6 is not some big conspiracy to make it easier to monitor you -- it's a conspiracy to make IP networks easier to run.

> In fact whole IPv4 vs IPv6 is complete non-issue to game development.

Anything that needs IP connectivity is affected by IP. Games in particular are affected because they're both latency sensitive and often peer to peer. CGNAT is bad for latency and it's definitely bad for peer-to-peer connections.

> Which is what Skype used to do before Microsoft took it over and decided only they can run the supernodes, whereas before any client could be one. This is corporate decision rather than technical issue.

Sort of... they may indeed have made the decision for corporate reasons, but the point is that us running out of v4 is forcing the decision on the technical side. If you want to have even the possibility of a competitor to Skype that doesn't run everything through an easily-monitored central server, then you want us to fix the technical side.

Nanashi

Re: I don't want to be measured!

I don't think trying to limit the number of devices you have is going to work well, in part because you could just run to NAT if they tried. But that doesn't mean everyone should be forced to use NAT all the time just in case some ISP somewhere goes retarded.

ISPs do suck, but that's no reason to fight v6.

> If ever I allow an IoT device on my LAN, it MUST exactly being able to connect to a central server WITHIN my LAN ONLY.

Yeah, this is basically how I run my IoT-style stuff too. You are free to do this even if you're using v6 on your LAN, it won't stop you from doing it. v6 just gives you the _possibility_ of accepting selected inbound connections in any situation where you actually do want remote control (which is something you won't be able to do on v4 once CGNAT ends up being common).

> Skype is going to a client/server model anyway, because peer-to-peer is not good for analyzing your contents...

Well, yeah, but the point is that nobody can make a direct peer-to-peer program when everybody is behind multiple levels of NAT. If you don't want to run everything through a central server, then step 0 is to make it possible to avoid doing that. Whether anybody will come along and take advantage of the possibility is a separate matter, but they definitely won't if it's not possible.

> and once you have a NAT traversal library for games you don't have to waste precious resources which hinder "awesomeness"

In theory, except people seem to have trouble with NAT traversal quite frequently, and it still requires running some form of servers to set up the traversal. And some games opt not to bother and instead require multiplayer to use central servers hosted by the company, which they have to pay for and will eventually shut down. (And did I mention the extra latency caused by all this crap?)

> Which makes extra work for whoever's programming the firewall and hence increases the probability of bugs

It's not so bad. The random addresses are for outbound connections; for inbound connections you have a fixed address (which is difficult to find without knowing what it is, because a /64 is so extremely large that it's impossible to scan). So your inbound firewalls don't need to change frequently.

What about firewalls/ACLs on servers that you connect to? For those, you just allow the /64, i.e. the whole network. That's what you had to do in v4 anyway, where the whole network was NATed behind one public IP.

So actually this part of firewalling ends up basically identical to the current situation in v4.

Nanashi

Re: And who told you I want to be measured?

> Rubbish. [...] It is hard to imagine how a bug in NAT could result in an incoming connection request actually getting routed to a machine on the LAN.

Not rubbish. If you think this then you don't understand how the internet works.

If an inbound connection comes into your router from the WAN interface, and the dst address of the connection is (say) 192.168.1.10, then your router will route that connection to 192.168.1.10. NAT won't affect this at all -- NAT (in the form that you see it on home routers) only affects outbound connections.

Now obviously, it's hard to send a packet to you with 192.168.1.10 as the dest address [which is one of the reasons that v6 needs to hurry up and be here], but your ISP can do it. NAT will not prevent your ISP, or anyone who can strongarm them, from making connections to any of your LAN machines.

> You see: my router supports IPv6 on the outside (also has an IPv6 address) but only provides IPv4 on the inside. It gets more bizarre: my IPv6 address is an /128 one. In other words: one fixed address, I'd have expected some kind of subnet for sure.

A /128 on the WAN is fairly common. You're generally expected to have only one machine on the WAN link (the router), so a single address is fine. Typically you then have to make a DHCPv6-PD request to pick up a /64 (or a /56, preferably) to use on the LAN side.

Which ISP is it? If it's Sky then the above is what's going on. Do the PD request and you'll get a /56, from which you can pick one /64 for your LAN.

> I'm happy to have a gateway between my PC and the Internet instead of having my PC's firewall act as the first and last line of defense. But this wasn't the way they intended IPv6 to be used, that's for sure!

It kinda was. You're expected to have a router between you and the rest of the internet -- that's just how the internet works. And typically you'll run a firewall on that router. Your PC firewalls won't be your only line of defense.

>> That's why all the IoT stuff ends up bouncing through a server owned by the company.

> That's not the only reason though. Other reasons include:

You're right, and you make a lot of good points. Vendor lock-in and an inability to keep their mitts off your private data is going to make a lot of companies go the central server route anyway. But still, if all of their devices live behind CGNAT then they're pretty much _required_ to go that route even if they don't want to. Removing NAT (and thus deploying v6) is a basic requirement to making it _possible_ for a non-evil company to design something where the server lives in your home and under your control.

> So, What happens when the various devices in my house talk to the Internet? [...] My understanding is that V6 allows a version of the LAN address to get out as the return address for the connection. So the manufacturer can be detected, and the number of different addresses used from my subnet gives an indication as to how many devices I have.

For the purpose of outbound connections, your machines generate a random address (which they change frequently). You can't detect the manufacturer from a random address, and the number of computers you use is also obscured (but instead of looking like one computer, it looks like thousands and thousands).

Nanashi

Re: And who told you I want to be measured?

> Phew... I think that about covers everything.

Except, of course, for the comments made while I was in the moderation queue.

> Nobody's business plan includes making their content available to a tiny proportion of the Internet.

It is not actually so tiny. In some specific areas (for instance, mobile networks in the US) it's >50%. Still too low to drop v4 _yet_, but what if it was 90%? Would you bother adding legacy v4 support to your new mobile service for that last 10%? Maybe you'd charge v4-only customers a bit extra to cover the costs (which are steadily increasing; v4 addresses aren't free).

> Why should I broadcast to the world that I have an NC Lathe?

You shouldn't. And IPv6 won't magically force you to do that. This is not a reason to not want v6.

> Why should I broadcast all the NC commands to the world? There is no reason at all.

You shouldn't! You won't have to! Just send the commands to your lathe over your local network. Where's the problem?

US govt pleads: What's it gonna take to get you people using IPv6?

Nanashi

Re: It's been too long

IPv6 doesn't mean "directly connected to the internet". You still connect via a router, and the router will still be running a firewall (or at least the one supplied by your ISP will be -- if you run pfsense or something then it's up to you). You'll still be protected.

Nanashi

Re: Less than honest

It wasn't so long ago that paying per address would've been called unreasonable.

Humans can get used to a surprising amount of badness, and will even happily argue that we shouldn't try to fix any of it. Almost feels like Stockholm syndrome.

Nanashi

But they're not fixed. v6 addresses change randomly every day and the prefix can be either dynamic or static like a v4 address. Plus you have a firewall because the router will have one.

It's not insecure at all -- or at least it's no worse than v4 on this front. Your browser is still as vulnerable as ever...

Nanashi

Re: the Register ... no IPv6

Let me share a fun thing with you. Elreg are sitting behind Cloudflare, and Cloudflare support IPv6. If you put a Cloudflare IP for the site into your hosts file, like this:

2400:cb00:2048:1::6814:4a6a forums.theregister.co.uk

2400:cb00:2048:1::6814:4a6a www.theregister.co.uk

then you can access the site over v6. Unfortunately posting doesn't seem to work though (the posts go into the aether).

Nanashi

Re: we are forced to have ipv6 internally so we have it 'on'

That's exactly what happens.

But just try getting people who grew up with NAT to comprehend running a network without it.

Page: