* Posts by Nanashi

145 posts • joined 19 Sep 2016

Page:

We've found another problem with IPv6: It's sparked a punch-up between top networks

Nanashi

Re: IPv4 Address Pool Has Been Expanded Significantly

I just mean any system that can parse a v4 address and generate a v4 packet. This isn't some extra thing that needs to be added, it's literally the software that's already in those systems and which they're already using for v4.

I don't think I even understand what you mean by "transparent" any more. Do you mean "existing devices keep working", or do you mean "end users don't need to change what they're doing" or is it "the engineers responsible for making the network hardware and software are unable to detect any changes in behavior or functionality"? Or maybe even something else?

Nanashi

Re: IPv4 Address Pool Has Been Expanded Significantly

By this definition, v6 is backwards compatible. It can transparently handle v4 on any system that has the appropriate software support, and it doesn't require anybody to be capable of doing v6 if they don't want to do v6.

Is this what you mean by backwards compatibility, or are you going to change your mind again?

Nanashi

Re: IPv4 Address Pool Has Been Expanded Significantly

It would've been helpful to put that in your kosher definition of backwards compatibility when I asked you for it. By this expanded definition, EzIP is not backwards compatible, because it uses v4 unless both sides have EzIP. Operators and users need to deal with both.

Nanashi

Re: IPv4 Address Pool Has Been Expanded Significantly

60 bits is 32+28 bits. 2^32 is ~4 billion and 2^28 is ~256 million.

The "Kosher" definition of a product / system that is backwards compatible to its predecessor is that upon introduction, everyone (from operator to end-user) can continue what each has been doing previously.

By this definition, v6 is definitely backwards compatible. Adding v6 support to a network, router or host has no impact on its existing v4 support, and you can continue using v4 as you were previously. So it meets this definition.

Nanashi

Re: IPv4 Address Pool Has Been Expanded Significantly

If you insist, I'll answer it directly: yes, I can roughly figure it out. I don't agree that it would be the right way to do it, and at 60 bits I'm not convinced it would be big enough, but it's certainly a way, and I did think I made it clear already that I understood how EzIP is supposed to work.

(I also don't agree that it relies on nothing after RFC791. It relies on a lot of things after RFC791, including its own 43 page draft.)

Now perhaps you could answer my question, so that we can stop flip-flopping between two different definitions for it: what, exactly, do you mean by backwards compatibility? This is a technical matter, given that it concerns the technical capabilities of the things we're talking about.

Nanashi

Re: IPv4 Address Pool Has Been Expanded Significantly

No, v6 didn't "ignore" backwards compatibility. v6 CAN'T DO backwards compatibility because v4 doesn't support it. There's no way to do complete bi-directional transparent backwards compatibility with v4. Nothing can be backwards compatible in that manner with existing, unmodified v4 nodes. It's not possible.

v6 isn't transparently backwards compatible with v4. Neither is EzIP, for the same reasons.

You need to decide whether you consider EzIP to be backwards compatible or not. If you think it is, then you also think that v6 is backwards compatible, because v6 uses the exact same mechanisms (dual stack, NAT, tunnelling) that EzIP does to be compatible with v4.

Do those mechanisms count as backwards compatibility or not? I'll let you decide. But either both v6 and EzIP are backwards compatible, or they both are not. You can't have it both ways. Not when they use the same methods.

If you don't believe me then you're welcome to learn v6 and see for yourself. If you're not going to do that, then you're going to have to rely on other people who do know it. Either way, please stop using your own preconceptions of what v6 can and cannot do, because they're wrong.

Re: peering, I'm talking about direct peering agreements between end-user ISPs and big content networks - people like Google, Netflix, Akamai. These people all push huge amounts of traffic, and they all do v6. Peering between end-user ISPs and content providers effectively takes that traffic off of the public internet (and it's the public internet that the article is talking about).

If so, how could anything like IPv6 that is built on top of lots of RFCs afterwards be simpler?

By not requiring that it be run as an overlay network. v6 can run as an overlay, but it also supports running natively, and running natively is way simpler than requiring a fully operational v4 internet and then running on top of it forever.

The number of RFCs isn't the important part. You'll find that going from a draft idea to something with completely defined behavior that can be implemented correctly everywhere requires thinking about and defining a bazillion things you never thought you'd need to deal with. That's what those RFCs represent. (That, plus 20 years' worth of further development on core internet protocols.)

Please be specific. I can reiterate the deployment conditions of EzIP for you. [...] There is really no "difficulty" in deployment to speak of.

Great to hear there's no difficulty! v6 can be deployed in exactly the same way. For example, you can deploy dual-stack routers without affecting anything in anybody's current internet setup. The various forms of NAT cover communicating between protocol versions. 6to4 covers the "give every existing IP more IPs" aspect (although it gives a trillion trillion IPs per v4 IP, rather than just 256M).

And, you have not made clear enough description about why EzIP isn't better, except by statements of your own words.

What else can I give? The way v6 works is public knowledge, and you're free to go and verify anything I've said.

Nanashi

Re: IPv4 Address Pool Has Been Expanded Significantly

As I explained before, it's fundamentally not possible to do the kind of backwards compatibility that you seem to want from v6. v4 doesn't support it. There are a few ways of working around that deficiency of v4, and v6 uses those ways, and I would argue that v6 is backwards compatible because of its use of those workarounds.

You already know what those workarounds are. In fact, you figured them out yourself for EzIP, because it uses those exact same workarounds. (By your argument, this means that either EzIP isn't backwards compatible either, or it means that v6 is.)

and still did not work (carrying only about 2% of the total Internet traffic)

I know that's what is written on AMS-IX's graphs, but that's not an accurate measure of internet-wide v6 traffic. Over half of ISP traffic comes from on-net caches, which are typically v6, and over half of the remaining traffic goes via direct peering and never hits an IX. There's a correlation between "big enough to peer" and "does a lot of v6 traffic". IXs are going to see abnormally low amounts of v6 traffic.

25% of internet users have v6, and on average ~50% of traffic for a dual-stacked user goes over v6. These stats sound a lot better, don't they?

In a sense, we just have to admit the mistake of the current IPv6 and swallow it, then move on with something more reasonable,

Do you have something more reasonable? Because, as I've mentioned, v6 is already about as simple as it can possibly be given the constraints it's working under. EzIP ends up being more complicated because it permanently requires running on top of v4 using workarounds intended for backwards compatibility, whereas v6 is also capable of working without the workarounds.

EzIP also has the exact same deployment difficulties that v6 has (e.g. the need to upgrade everything that needs to interact directly with it) and offers nothing to ease those deployment issues that v6 itself doesn't offer.

So if you want us to use something more reasonable then EzIP isn't it, and I haven't seen any better suggestions. Why should we abandon the substantial v6 deployment we have to start over from scratch with something that isn't even better?

Also, seriously, you need to learn v6. It's not difficult, I swear. 80% of it is pretty much identical to v4 but with longer addresses. If you have your head around v4 (as you clearly do) then you already understand all of the concepts; v6 just makes the addresses longer, which doesn't change how any of it works.

Go and grab a tunnel from tunnelbroker.net and set it up on your network. Play around with it for a bit. Seeing it in action should show you that it's not as scary as you think.

Nanashi

Re: IPv4 Address Pool Has Been Expanded Significantly

I don't think that ignoring v6 in a discussion of v4 address shortage is appropriate. It's the solution that we've already developed and that we're already deploying. It's extremely relevant.

How can you hope to improve upon v6 without knowing about v6? ...and if you don't plan on improving upon v6, then why should we care?

Nanashi

Re: IPv4 Address Pool Has Been Expanded Significantly

If anybody cares, I actually went to the effort of getting my head around the linked draft a couple of months ago in the comments to this article:

https://forums.theregister.co.uk/forum/1/2018/06/06/vint_cerf_ipv6_program/

The short summary is: it doesn't manage to be backwards-compatible with v4 in any way that v6 isn't already. It can't talk to v4 without using either dual stack (which v6 has) or cross-protocol NAT (which v6 has, as NAT64). And it works over the v4 internet essentially by tunnelling, which v6 also has (6to4).

This shouldn't be a surprise, because v4's design isn't forwards compatible, and as a result it's impossible to do direct backwards compatibility in the manner that people seem to want. There is no possible design for v6 that can change this existing limitation of v4.

Any engineer who claims that this lack of backwards compatibility in v6 is an engineering failure on v6's part is themselves failing at one of the fundamental requirements of being an engineer -- the need to understand what they're talking about. If you don't understand the limitations of v4, then you are in no position to insult the ability of the people that designed v6.

If you think I'm wrong, don't just downvote me. Reply with an explanation of how, exactly, you'd make that backwards compatibility work. All you have to do to show me that I'm wrong is to demonstrate how to do it. Put your money where your mouth is, and I'll give you fair consideration, as I did for this draft. But you won't be very convincing if your idea doesn't work, or if it has the same limitations that v6's existing options for backwards compatibility have.

Microsoft pulls plug on IPv6-only Wi-Fi network over borked VPN fears

Nanashi

Re: @ITS Retired - Welcome to the real world, MS

So, it's been 11 days since I could bring myself to check the comments here, and I see that lots of people managed to downvote me but nobody managed to tell me how to make v6 more backwards compatible. I think that makes my point, no?

(I didn't forget to mention "v4 on the inside, v6 on the outside and NAT between". I didn't mention it because it doesn't work. That said, even if it did work it wouldn't require any changes to v6, so it wouldn't be a way of improving v6's design.)

Nanashi

Re: Two questions if I may

They are actually behind Cloudflare, which means v6 is just a toggle away. It also means that, with appropriate hosts file entries, you can talk to El Reg over native v6 even without them explicitly enabling it. The last time I tried this, it worked fine except that attempting to post a comment didn't work. The post just disappeared into the aether, and never showed up.

What did show up, however, was a post from an admin complaining that they had to manually drop my post from the queue.

I'm guessing some part of the post pipeline can't handle long addresses (e.g. a database with a short VARCHAR column). Cloudflare have a workaround to deal with that though (hashing the v6 address into 240/4) so maybe there's something else that needs the real address (geolocation/spam filtering?). Hard to tell exactly unless they feel like showing up here and telling us.

As it happens, I do have a way to summon admins...

Nanashi

Re: "IPv4-only hosts are unreachable without either a dual stack or an address translator"

I guess you could even argue that we did do something along those lines:

$ curl -v https://www.theregister.co.uk/ | grep "<title>"

* Trying 64:ff9b::104.18.225.129...

* Connected to www.theregister.co.uk (64:ff9b::104.18.225.129) port 443 (#0)

<title>The Register: Sci/Tech News for the World</title>

Works fine so long as you have a translator box in your network path. It's outbound only unless you manually configure a port forward*, but then that's how NAT already works so that's hardly a new problem.

(* This is the part that lets you avoid being restricted to a 32-bit address space. Either you allow connections to be established both ways, which restricts you to 32 bits, or you restrict it to outbound only which allows you to use the full v6 address space.)

Nanashi

Re: Why do we need IPv6

Seriously. Why more than one public IP per household, and maybe a dozen or so on average per organization?

Because most people have more than one device, and most organizations have more than a dozen or so devices. I guess we could all use proxies, but I know nobody wants to use those -- they actually want their devices to be connected to the internet, which is what the IPs are for.

We are not really running out of IP4, only out obviously unallocated IP4.

No, we're out. We're beyond out, almost nobody has enough addresses and everybody has to spend tons of time and effort trying to stretch what limited address supply they can get their hands on.

Back in 2011, before IANA ran out, we were going through one /8 per month. Given that demand has only gone up since then, 16 million addresses would be something like a 2 week supply now. If you think DEC's block is going to save v4, then you can think again.

You can't actually go IP6 only till everyone has IP6.

Not true. You can certainly do v6 before everybody has v6.

Nanashi

We need v6 because a) we will lose important internet functionality without it, and b) maintaining v4 is expensive, and is going to get extremely more so if we try to run the internet on it forever.

But as usual, people can't see past the next quarter when it comes to planning how they're going to spend their money.

Nanashi

Re: @ITS Retired - Welcome to the real world, MS

If the people who designed v6 answered their outside phones, they'd spend all their time talking to crackpots and people who don't understand what they're on about.

v6 is already designed about as well as it can be given the constraints it's working under: it works almost exactly the same as v4 does (the two changes I can think of being SLAAC and NDP instead of ARP for neighbor discovery, both pretty simple things), and it's as backwards compatible with v4 as it is possible to be.

If you think I'm wrong about that last one, all you need to do is respond and tell me how, exactly, you'd make v6 have better backwards compatibility than it does. And I suspect you'll end up demonstrating my first paragraph.

Nanashi

Re: "IPv4-only hosts are unreachable without either a dual stack or an address translator"

The explanation is the pigeonhole principle.

The problem with your suggestion is that it limits you to a range of addresses that's 32 bits in size, and those 32 bits have to map exactly onto the v4 address space. So er... it's just v4, but it won't work with all routers, so computers will still have to ship with and use their v4 stack anyway, so what do you even gain with your suggestion?

Nanashi

Re: Catch 22

We don't need an emergency, we need a deadline. Humans are incapable of responding to open-ended emergencies (see: global warming), but they can cope with deadlines even for the most unimportant crap.

The problem is that there's nobody in a position to enforce a deadline on the global internet.

Strewth! Aussie ISP gets eye-watering IPv4 bill, shifts to IPv6 addresses

Nanashi

Re: Another IPV6 article which exposes issues with IPV6

As mentioned, you don't need a special address allocation on the local network; DNS64 returns addresses in the NAT64 prefix and clients connect to them like they do any other address. The router running NAT64 needs to handle the translation, but that could be at your ISP.

NAT64 translates from v6 (inside) to v4 (outside). Inbound connections from v4-only hosts are possible if you configure a port forward. Basically that's the same restriction NAT has when it's v4 on both sides.

My point really was that this is about the best you can do. You can't come up with a scheme that lets communication work directly between v6-only hosts and unmodified legacy v4 hosts. This isn't v6's fault, and there's nothing that you change in v6 to make it work. It just isn't possible, and if you're going to put the blame on anything for that then it would need to be on v4's design.

Nanashi

Re: Has anyone truly made the switch?

A high-volume e-commerce site is exactly the sort of site that should be really interested in v6.

Small increases in page load time lead to large differences in the amount of users that give up on your site and try another one. (Search for "latency impact on revenue" for studies. The numbers are kinda crazy; things like 5% of total revenue for 500ms of extra waiting time.) For an ecommerce site, that means less money for you.

Facebook measured their site as loading 10-15% faster over v6 (https://code.fb.com/networking-traffic/ipv6-it-s-time-to-get-on-board/). That should be interesting to a large e-commerce site.

Nanashi

Re: Another IPV6 article which exposes issues with IPV6

There is a backwards compatible transition mechanism though, specifically NAT64. What more do you want?

Stern Vint Cerf blasts techies for lackluster worldwide IPv6 adoption

Nanashi

Re: There Might Be An Alternative

I spent quite a few hours getting my head around your draft. I don't think I'm stuck in any thinking here; it's just that the draft really does describe a system that is largely the same as IPv6 with 6to4.

If you want to convince me that's not the case, then you're going to have to explain exactly how it's different. I went to a lot of effort to explain to you why it's not different; now it's your turn.

"I don't understand v6" isn't enough to convince me that you've come up with something that's different to v6. If anything it just makes it even more likely, because v6 is about as simple as it can be given the constraints it's working under, which means it should be no surprise that an independent attempt to do the same thing ends up looking more or less the same. How can you be so sure you've come up with something different without knowing the thing that you claim it's different to?

Please note that there is nothing to do with IPv6 in the whole EzIP schema. We are dealing with the fundamental address pool shortage issue. The only protocol involved is RFC791 which is as old as the Internet (1981).

This isn't true. You're building a new protocol on top of v4, so you're no longer dealing with only v4. And it so happens that the manner in which the protocol you built works is exactly the same way v6 with 6to4 works. There is the minor difference of using an extension header rather than a protocol, but that's just an implementation detail.

To start with, the only module needed to realize the EzIP service is the new inline SPR. All current Internet components do not need be modified. Only certain IoTs need be upgraded to be EzIP-capable if they desire to enjoy the router, instead of the CGN, service from the SPR.

And all of this is exactly the same as it is in v6. The "SPR" is basically a dual-stack router. In v6, you can deploy a dual stack router without touching anything else. Only "certain IoTs", to use your term, need to be upgraded to use the dual stack router instead of relying on CGN. You aren't describing anything that we don't already have in v6.

Nanashi

Re: There Might Be An Alternative

I'm not suggesting you bust your brains over it. It's just v6, it's not difficult.

I did largely answer the question: you've basically come up with v6+NAT64+6to4, with more or less the same features and drawbacks as those. So it should work about as well as they do, but also have the same drawbacks as they do You still have the same "existing hosts need to be upgraded" problem, the "existing routers need to be upgraded" problem, the "existing software needs to be upgraded" problem, the "you can't talk between them without a translator" problem, and roughly every other problem. It's still not backwards compatible, except in the ways that v6 already is backwards compatible.

That's the general problem with it: that it brings nothing new to the table, doesn't solve any unsolved problems and doesn't add any new backwards compatibility that we don't already have. It also doesn't solve some of the problems v6 does solve, so it doesn't avoid the need to do v6. Plus, it currently has no software or hardware support and no existing deployment, while v6 already has many well-tested implementations and is actively in use by 25% of internet clients already.

That just doesn't seem like a great combination of things to be spending our limited effort on.

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.

IPv6: It's only NAT-ural that network nerds are dragging their feet...

Nanashi

Re: "the world is clinging stubbornly to IPv4"

You can do NAT with v6 already. Nothing stops you apart from the sheer silliness of it.

It's been four days since your post, and now that Google's stats (which lag behind by a couple of days) have updated, they're showing that deployment is still at the 20%/24% week/weekend cycle it's been at for a while, and hasn't jumped up to 100%.

So no, it seems like the ability to do NAT on v6 didn't lead to the world being on v6 a day after your post. This suggests that the main blockers are probably elsewhere.

Nanashi

Re: "4.3 billion addresses are moe or less all allocated"

There are no "other 3.3 billion addresses". Of the addresses available for unicast allocation, almost all have been allocated to somebody.

Unless you're trying to say that there's a lot of addresses that haven't been assigned to a machine? Obviously there are, because that's how IPs work. Unlike MACs, they're assigned hierarchically in blocks of 2^n addresses. Of course that's going to lead to a lot of addresses not being assigned to a machine.

Those "unused" addresses aren't actually unused, they're performing the very important role of making the internet possible at scale. They won't save you from v4 exhaustion.

Nanashi

Re: "the world is clinging stubbornly to IPv4"

Alright... so basically, what you're suggesting is no more backwards compatible than v6 is. Most of the rest of your post is just a rant about feature creep, which is itself interesting given that v6 didn't really add much in the way of new features.

What new stuff is there in v6? Routing and subnetting work the same way as in v4. So do firewalls, and TCP/UDP/DNS if they count. IPsec? That was made optional, and it was backported to v4 anyway so apparently people wanted it. RAs? v4 got those in 1991. SLAAC is new, but SLAAC is super simple (and you can't really say "DHCP is ubiquitous, why not just use that, it's the obvious choice" because it wasn't in 1993. RFC 1531 itself is from late 1993, and there were tons of config protocols in common use for at least a few years after that.). NDP instead of ARP is new, but it does the same thing ARP does. It does go over multicast, but multicast isn't new either, and this allows removing broadcast which is the opposite of feature creep. Mobile IPv6? That came 8 years after Mobile IPv4. SEND? That's new, but nobody uses it. We did need a new socket type, and a new DNS API for handling multiple address families, but that was completely unavoidable. Any new address family would've needed that.

And... I'm out of ideas. I'm sure I've missed something or another, but I'm not really seeing the creep. We could've added variable length addresses, or split the concept of an IP into separate location and identification IDs, or any number of other useful redesigns of L3, but we didn't. v6 is mostly just v4 with longer addresses.

Nanashi

That's an odd way to write "lots of advantages". It's not like you need to completely give up using v4 to use v6.

>What we need is IPv7. Admit that IPv6 was a failure and do it right (i.e. as an extension to IPv4 that gradually sucks the life out of its host).

You say this as if you think it were possible. It's not; there's no way to extend the amount of IPs in v4 without doing something that looks like v6.

I'll ask you the same question I've asked other people: if you think it is, in fact, possible, then explain how to do it.

Nanashi

Re: "the world is clinging stubbornly to IPv4"

"Use the version field" is the approach v6 took. How does doing the same thing with a 5 instead of a 6 change anything?

> For compatibility, devices would then just have to look at the version.

How do you expect existing devices to know what to do with a version of 5? The whole problem is that existing devices don't know how to handle the new stuff.

Nanashi

Re: Why does anyone care what going on in my internal network?

...you do understand that 6to4 requires deploying v6 to your LAN, right?

Nanashi

Re: "4.3 billion addresses are moe or less all allocated"

No, they're pretty much all allocated. You can see the high-level allocations at https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml; of the three quarters of the address space that's available for unicast allocations, all of it has been allocated either directly or to RIRs.

Of the space managed by RIRs, the only remaining unallocated parts are summarized at https://ipv4.potaroo.net/, and they basically boil down to a total of about one /8, most of which is reserved for transitional purposes.

Nanashi

Re: "the world is clinging stubbornly to IPv4"

Yes, let's have an explanation please. If you think it's so simple to just add a few octets, tell us how to do it.

There are good fundamental reasons why it's not possible to do, which I, Charles 9, and that "smug" "IPv6 committee" all understood. But if you've somehow worked out how we're wrong, then put your money where your mouth is and just tell us how! We'd really love to know!

I've seen a lot of people say "just add some octets", and I've asked a fair few of them to explain how to go about doing that without ending up with something that has the same compatibility issues that v6 has, and nobody has managed to do so. Perhaps you will be the one to finally share the solution?

(For the avoidance of doubt: whichever method you suggest has to actually work. This ought to be obvious, but something that doesn't work is not going to work.)

Nanashi

Re: "the world is clinging stubbornly to IPv4"

> What's wrong with a world where home users and small businesses use IPv4 and their ISP bridges their traffic onto IPv6?

The primary issue with this is that it's not possible. I mean, you can use a proxy, but approximately nobody wants to use proxies (as evidenced by the fact that people go straight for NAT, despite its problems).

(There is 464XLAT or 4in6 to transport v4 traffic over v6, but you still need to deploy v6 to your network or else your hosts will only be able to connect to v4 servers. v4 only has 32 bits available for the dest address, after all.)

Nanashi

Would it have been feasible to devise a protocol which accepted IPv4 as a fully accepted subset? I don't know, but if it would then anything else would have been a serious mistake.

No, it wouldn't. There's no way to do what you're imagining. That's why we didn't do it.

Note that it is possible to connect from v6 to v4 via NAT64, and there's a standard range for that (64:ff9b::0:0/96). For example, in the process of making this post, my browser is talking to 64:ff9b::104.18.227.129, since for the fun of it I removed v4 from my desktop and am relying purely on v6.

Is that close enough to what you wanted?

It's impossible to do a completely seamless transition, because v4 is just not designed in a way that supports that, and obviously you can't change v4 to support a seamless transition because that wouldn't be seamless. v6's design makes the transition as seamless as possible given the constraints it's working under.

Nanashi

Re: Privacy implications

That's not how IPs work. You're thinking of MAC addresses, not IPs.

When we say "unique v6 address", what we mean is that only one machine has that IP at a time. That doesn't mean that the IP is in any way tied to the machine, or that it can be used to identify which machine was using the IP. To do that, you'd need some sort of IP<->MAC mapping. Since MACs don't make it through routers, the only place that mapping can be made is on the router to your own network.

I'm not sure why you mentioned NAT here, unless it was just simply because you misunderstood what NAT was doing for you. MAC addresses don't go through routers whether or not you're using NAT.

Nanashi

Re: Ipv4 origins

They get an IP from the network they're connected to. The prefix for the network is allocated from its parent allocation, and so on up to the root. All allocations are large and sparse so as to reduce routing fragmentation.

Basically it's no different to v4 in method, it's just that the address space is large enough that aggregation can work.

Nanashi

Re: "the world is clinging stubbornly to IPv4"

Nobody is suggesting that your IoT stuff should be directly on the internet. We're just saying that NAT is an unnecessary headache, that it breaks too much stuff and requires too many compromises, and that you should be avoiding it.

You do not need NAT in order to connect your devices via a router.

Nanashi

Re: Obvious need for..

I see there's quite a bit of "v6 should've been backwards-compatible" circle-jerking here... do you guys really not realize that v6 is backwards compatible? You can connect from v6 to v4 via NAT64, and you can run v6 islands accessible over the v4 internet with 6to4.

Those are roughly the only forms of backwards compatibility that are possible with the design of v4, and v6 has them. There are some other forms of backwards compatibility that are impossible, and v6 doesn't have those because those are impossible.

What else could we possibly have done??

Sitting pretty in IPv4 land? Look, you're gonna have to talk to IPv6 at some stage

Nanashi

Re: It'll never work

I saw that article. It's, ah, how should I put this... wrong on almost all counts. Like, failing to realize that v6 has backwards compatibility, or that v4's lack of forward compatibility can't be worked around by replacing v6, or that Google's stats are fundamentally different and not comparable to IXP traffic stats, or that internet exchanges are a poor measure of v6 deployment, or that NAT causes real unsolvable problems, or just not knowing how DNS works... I could go into more detail, but I think that pretty much covers every single major point.

Nanashi

Re: Overly Gloom and Doom 90's Predictions

It doesn't really reveal that much about your network. v6 is so sparse that it's hard to even find your network, let alone devices on the network, and all it typically reveals is that you have internet-capable devices; it doesn't even reveal how many. And it only does that much to people in a position to sniff your traffic, and only if you actively allow your devices to talk to the internet, which you don't have to do.

It does share a lot of issues with v4 (e.g. "you can download malware over v6"), but you can't really count those as a disadvantage for v6 when v4 shares the same issues.

Nanashi

Re: Never!

How does one actually connect to an RFC1918 address behind a NAT without the inside connecting first?

Hey, I didn't say anything about RFC1918. We're talking about NAT here (the thing you get from doing `iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE` with netfilter, yes?). You can use RFC1918 without NAT and you can use NAT without RFC1918; they're two separate things.

It's true that running a network on RFC1918 will drastically limit the set of people that can connect to it, but a) some people (e.g. your ISP, your government) can still connect, so it's not secure, and b) RFC1918 isn't NAT, so even if you think using RFC1918 makes you secure, it's still not NAT that's doing it.

If anybody doesn't believe me, feel free to set up a few VMs and test it for yourself.

Nanashi

Re: "won't be long before websites *demand* that you access them over IPv6"

Facebook have measured their site as loading 10-15% faster over v6. That seems like something that websites ought to be interested in, no?

Having v6 on your website doesn't reduce your potential audience. I'm not entirely sure where you got that idea from.

Nanashi

Re: Never!

It's not exactly horribly difficult though, is it? If you know how to run these four commands:

iptables -P FORWARD DROP

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

iptables -A FORWARD -i lan0 -j ACCEPT

iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE

then you already know how to run these three commands:

ip6tables -P FORWARD DROP

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

ip6tables -A FORWARD -i lan0 -j ACCEPT

It doesn't take a long sysadmin course to learn how to not run one command! What's everybody so afraid of?

For the other 99% of people who don't know to set up the necessary firewall rules for a NATed network in v4, it's even simpler: just plug in the ISP-provided dumb box and away you go, just like you've always done it.

Nanashi

Re: Never!

Have you tried pushing an unexpected connection through a NAT router?

I have -- it worked fine. The form of NAT that we're talking about here (`iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE`, right?) only applies to outbound connections (that's the "-o wan0" part); it has no impact on inbound ones, which won't match the rule above.

If you have a router that's NATing outbound connections, you can still do inbound connections just fine unless some other aspect of the router or network setup (such as... a firewall) prevents it.

(I know that most networks have those aspects, but I set one up that NATed outbound connections yet still had working inbound connections just to prove that doing so does in fact work, and that it's not the NAT that's breaking the inbound connections.)

Nanashi

Re: NAT

Normally you would just use your global addresses on the LAN. If you have a dynamic prefix and you want a fixed LAN range, you can run ULA on the LAN at the same time as the global addresses. It's not necessary to invoke any form of NAT at all to do any of this.

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.

Page:

Biting the hand that feeds IT © 1998–2019