Posts by Nanashi

Watchdog slams Pentagon for failing – for a third time – to migrate US military to IPv6

Re: IPv6 in the UK...

Because if they don't, all of their customer traffic has to go over v4. They don't have enough v4 addresses for their customers, so that traffic has to be CGNATed, and CGNAT is expensive.

Doing v6 lowers their costs. EE are, in fact, doing v6 to their customers today for this reason.

There's also the part where you need v6 to reach v6-only servers, but even if you somehow thought that wasn't the case the cost situation is still there. (And no, v6 doesn't restrict their billing options. They can still see the traffic and know which customer generated it.)

Internet samurai says he'll sell 14,700,000 IPv4 addresses worth $300m-plus, plow it all into Asia-Pacific connectivity

Re: Civilian note

Start at /64 and expand leftwards every time the spammer demonstrates the ability to use adjacent unblocked addresses. You'll find the right size in O(log n) trials, not the O(n) that everybody seems to assume. Bonus points for expanding 4 bits at a time to keep on nibble boundaries, and for remembering the size on a per-ISP basis so you only have to do it once for each ISP.

Re: In 3.. 2.. 1..

The v6 equivalent could easily be "AD as ::250, ESX-01 as ::10, gateway as ::254". Is that really too much to handle?

Re: Civilian note

I see no reason why RBLs wouldn't work for v6 addresses (or more importantly, for v6 prefixes).

You. Drop and give me 20... per cent IPv6 by 2023, 80% by 2025, Uncle Sam tells its IT admins after years of slacking

Re: AAISP

That's a pretty trivial setup. DHCPv6-PD takes care of autoconfiguring both routers.

If you can't use DHCPv6-PD for whatever reason, it's still easy; you just need a static inbound route, which is no harder to do in v6 than in v4. If it's not working for you then you messed up the config, which isn't v6's fault.

It's because it's hard to do better than v6, especially at this stage. v6 is already very close to "v4 but with longer addresses", and it already has support in most networking hardware and software. If you tried to come up with something different, you'd be starting from scratch on deployment (which we've already established takes a long time), and you pretty much have a choice of coming up with something that looks very much like v6, or something which is more complicated. Neither of those are likely to improve on the current situation by enough to throw away all of the work we've already done on deploying v6.

> Who, aside from some enthusiasts, actually wants ipv6?

ISPs do. CGNAT is expensive. Deploying v6 moves over half of your traffic off of your CGNAT infrastructure, which immediately makes it cheaper and reduces the need for future upgrades. It's also less complex than CGNAT, which is another cost saving.

The complexity of NATed networks (taking RFC1918 clashes, split DNS, VPNs etc into account) is a driving force in many other places too.

Re: Crap

If you actually spend some time using v6, you'll find that v6 addresses can be parsed by a human easily enough. It's actually easier to parse subnet info out of them than with v4, because hex lines up with binary more readily than decimal does.

We are absolutely, definitively, completely and utterly out of IPv4 addresses, warns RIPE

You're going to pick addresses like "2001:db8:10d:1::2", which isn't really that much longer than "203.0.113.42+192.168.1.2". In fact it's 7 characters (a good 30%!) shorter.

Most people use DNS, but if you need to remember IPs then that's what you'll do.

I'm pretty sure I've explained to you before that v6 does deliver value even before every device supports it. It's delivering value right now, so we can already declare your prediction wrong.

NAT is not as capable as you think. There are many things it breaks, and many things that are still possible in the face of NAT but only with additional effort and expense. NAT is useful as a delaying tactic but is not a desirable end goal.

Re: "We have now run out of IPv4 addresses"

In the early 80s perhaps, but in the early 90s? By that stage, I think there were enough people involved that you would never have got universal agreement. You can't even get people to agree that v6 is necessary today, and v4's problems are widespread and obvious now. That was not so much the case in 1990.

I wasn't around at the time, so perhaps my idea of the size of the internet at that time is a little distorted, but I'm pretty sure it was reasonably widespread and there were far more than a handful of actors involved. I'd love to read a book that covered the history and growth of the internet in that period though, if anybody can recommend one.

Re: Easy Peezy

There are a ton of problems with NAT, and returning unused blocks just isn't going to fix any of them. v4 is too small. You'd just be rearranging deck chairs on the Titanic.

Re: "We have now run out of IPv4 addresses"

You talk about "academic institutions" like they're one entity, but they're not. There was nobody in a position to force them all to cooperate.

You would've had to individually convince all of them to a) rewrite all their software to handle longer addresses, b) deploy the new protocol on all of their computers and routers, c) do a coordinated drop on the old protocol.

And you want to do this early, when there were only a handful of institutions with minimal deployments as opposed to hundreds/thousands with substantial software and hardware deployments... so basically you'd need to do it at a time when v4 legitimately was sufficient for all the people involved; at a time where everybody understood it to be an experiment. You'd be doing it before work on the new protocol even began. And you'd be doing it in an environment where there were already multiple other competitors to v4 (remember that v4 only won everywhere in the late 90s; lots of people were still using IPX and god knows what else until then).

I'm honestly sceptical about your chances, there.

Re: Lies, damned lies, and statistics that don't lie.

Sure, you can use a proxy, but it's pretty obvious that just about everybody wants direct network connections rather than proxies, because otherwise they wouldn't be complaining.

...or who am I kidding. People frequently complain that v6 can't do X even though it can. They'd happily complain forever that "v6 can't be proxied" even when presented with evidence that it can be, based on the fact that they do that with most of v6's other capabilities. But what can I do about that?

Re: why did IPv6 use 128bit Hex?

IP addresses are assigned by the network you connect to. You can't use them like IMEIs or MACs, because they don't travel between networks. They simply aren't hardware identifiers.

Re: Backwards compatible

v4 divides its addresses up in exactly the same way. Registries get assigned their prefixes from IANA, ISPs get their prefix from the registries, sites get their prefix from the ISP, LANs get their prefix from the site. It's the same as in v6, with the only real difference being that v6 actually has the space to do sparse, aggregated allocations at all levels.

In the real world you'll be using DNS, so it doesn't matter what the IPs are.

The address you gave is... well, invalid, but it's also intended to be a link-local and you're unlikely to actually use that. If you get your v6 addresses from a DHCP server like you do in v4, then your address will look like the one I gave in my original post. You'll only need to remember the "1::192" bit, which is basically no different to v4.

Re: "What's wrong with a /64 prefix?"

Compared to the status quo of v4, sure, a single /64 is better than no v6. But we can aim a little higher than that. There are things you can't do with a single /64 but you can do with a /56, which is why you shouldn't be getting a single /64.

(Or to be more precise, it's why a single /64 shouldn't be the max you can get. If a user only requests one /64 then go ahead and only give them that much, but they should be able to get more without hassle if they want to.)

Re: IPv6 not that hard... seriously

Because you need v6 to reach v6 servers. If you don't know at least that much then you're not in a position to comment on this stuff. v6 also lets you sidestep all of the problems caused by NATing, which is another strong reason to be using it.

The energy cost of NATing (and subsequently recalculating the packet checksum) is worse for the environment than the few extra bytes in the header. The energy cost of the routers, servers and client machines involved are orders of magnitude worse however, to the point that worrying about a few bytes that are <1% of the packet size is utterly silly.

Re: Backwards compatible

People already moan constantly about how "complicated" v6 is, despite v6 using the same addressing and routing model as v4. I can only imagine how bad it would be if you introduced variable-length addresses, which would be an actual additional complication over v4.

But also I don't think making v6 have variable length addresses would help much, because the thing you're trying to make it compatible with is v4 and v4 doesn't have variable-length addresses, so it wouldn't be able to cope with any address length beyond 32 bits. "Send your packets to 100.64.10.10 with the extra address bits stored somewhere else in the packet" sounds an awful lot like 6to4, which already exists in v6, so if that's sufficient for being backwards compatible then v6 is already there.

Variable length addresses wouldn't save you from needing to fix software to handle the new address family (and that's going to be fun, what with all existing code being designed around fixed-length addresses. The prevalence of buffer overrun bugs suggests that many programmers can't cope with things that have variable length...).

The other major issue is that routing performance wouldn't be great, since handling a variable length address in hardware is not very fast. That would probably result in adoption happen slower rather than faster.

Dude... DNS.

And if you insist on dealing with the IPs themselves, why did you pick an address like "fdaa:bbcc:ddee:0:7c8a:a8c9:d4fb:acf1" when you could just as easily have picked "fd01::192", which is even shorter than the v4 address you used as a comparison?

Re: @Nanashi - "We have now run out of IPv4 addresses"

I guess I didn't. But I have now, and the general point still stands: v6 routes are going to be for prefixes 64 bits or shorter. The large address size also means you have more aggregation, and thus fewer routes to look through.That should make your job of spotting anomalies easier than a shorter address length (with its corresponding higher fragmentation) would've done.

Re: Here's some IPv4 addresses for RIPE

Great, that buys us a two hour supply of IPs. That'll solve our address shortage. Brilliant plan.

Re: why did IPv6 use 128bit Hex?

Your post seems to be mostly made up.

Every handset would need 4,096 IPs? No, I've never heard that. IPs would be used like IMEIs/IMSIs/MACs? No, that's specifically not what IPs are used for (use a UUID if you want a 128-bit identifier, but it won't work as an IP). ISPs wanted user tracking from MACs in v6 addresses? No, they already know who their users are, either from the prefix or the connection port. Global address on phone lets you escape their walled garden? No, they can still firewall you or do whatever they could do with RFC1918 addresses, public addressing doesn't change one bit of that.

Designed by committee? It has roughly the same design as v4. Ops community has to work out the security implications? Most of them are the same as v4, and for the ones that are different... well, it's your job to deal with them.

Re: "We have now run out of IPv4 addresses"

Transitioning quickly away from v4 wouldn't make v4 forwards compatible, it'd just take us off of the incompatible protocol quickly (which would avoid the problem, sure). I don't think you could've done that in 1995. Even 1985 probably would've been too late for that.

> Also that the only real difference was the length of addresses, with the leading 4 bytes effectively being padding and thus could be simply discarded or padded as necessary.

If the leading 4 bytes are padding then there's no point in them being there.

Re: Lies, damned lies, and statistics that don't lie.

You're thinking of 6in4. (6to4 is basically an automatically-provisioned 6in4 tunnel for every v4 address.) Teredo lets a single client connect to v6 servers over a v4 network.

All of those let you do v6 over v4 infrastructure. I'm not seeing how that's not backwards compatibility.

Re: "What's wrong with a /64 prefix?"

SLAAC on two networks, e.g. main plus guest or IoT networks. You don't need any more justification than that.

/56 isn't a big allocation. In terms of fraction of the total available space, it's 1/256th of a single TCP port of a single v4 IP. Nobody should need to deal with an allocation size smaller than that, and the question of whether a /64 is sufficient or not should never need to be asked by anybody.

They might know how to do it (or indeed they might not; have you considered how to handle that case?), but they couldn't do it because their ISP isn't exposing v6 to them.

Re: Lies, damned lies, and statistics that don't lie.

Not if you believe El Reg's armchair network "engineers" it doesn't!

v6 is backwards compatible with v4, but as you say that doesn't mean that v4 is forwards compatible with v6. It also doesn't stop people from moaning constantly about how it's not backwards compatible.

Re: "We have now run out of IPv4 addresses"

What? It had the capacity to be properly firewalled. What are you on about?

And yes, v6 has seen continued development, just as v4 has. This shouldn't be a negative point.

Re: "We have now run out of IPv4 addresses"

64 bits isn't enough. Hardware (EUI-64) addresses are 64 bits, and you need way more than 64 bits of L3 address space to handle 2^64 L2 hosts. The next power of 2 up from 64 is 128, so here we are.

You can already set most of a v6 address to zero (e.g. is 2600:: really so hard to remember?), to the point where anybody can easily make addresses that are ~64 bits of actual stuff plus ~64 bits of zeros. And they go straight into DNS so it's not like you even need to remember them anyway, but if you did then you have the 64 bit addresses you're asking for.

Re: "We have now run out of IPv4 addresses"

If you understand v4, then you understand v6. The operating principles of the two protocols are somewhere around 90% identical.

I'm willing to bet there are a lot of network engineers that don't really understand v4 though. You only have to look around this thread at all the people who somehow think it's possible for v4 to be forwards compatible with v6...

Re: Lies, damned lies, and statistics that don't lie.

Actually, there's a way for a device on a v4-only network (even behind NAT) to get v6: Teredo. Also, every v4 address has a /48 of v6 space tunnelled to it via a mechanism called 6to4.

For some reason, the existence of these protocols doesn't seem to stop people from complaining that they don't exist.

Re: This is probably a dumb question...

Indeed.

v6 is already backwards compatible. Perhaps you wanted v4 to be forwards compatible, but we can't create an IPv7 which v4 is forwards compatible with for the same reason that we didn't create an IPv6 that it's forwards compatible with: because v4 isn't forwards compatible with any address size that's bigger than 32 bits.

If you could fix that problem, then we wouldn't need an IPv7. You could just make v4 be forwards compatible with v6.

Re: The good news is that this crimps IoT deployment

Well, they don't have to use UPnP. They could also shovel all your data via a server that they own.

Sure, they already have an incentive to do that, but now they have an excuse too.

Re: We can take entire 24 ranges back

Good, that should buy us about 3 weeks.

But what then?

Re: This just in.....IETF announces IPv7

This is exactly what v6 does. The "compatibility mode" is v4. What else were you expecting it to be?

And in fact v6 has NAT64, which basically places the v4 address space into a v6 /96 so that v6-only clients can talk to v4-only servers. Is that somehow not good enough for you?

Get ready for a literal waiting list for European IPv4 addresses. And no jumping the line

Re: We need a new approach

I found it by Googling for "apnic ipv6 measurement". There's a more detailed explanation here: https://labs.apnic.net/?p=348.

AMS-IX are the best available public statistics. They're nowhere close to the best possible -- in fact the measurement they make is fairly useless in working out where v6 deployment is at. It misses out on on-net caches (which will be mostly v6 where available) and private peering (again mostly v6 by volume), which apparently account for something like 75% of ISP bandwidth between them. It counts large parts of the traffic from v6-only ISPs that use NAT64 as being v4. It's measuring at the wrong place to figure out what percentage of servers or clients have v6, and it's completely incapable of showing how readily available v6 support is to the people who aren't yet actively using it.

These are not very useful stats, unless your goal is to cherry-pick something that makes v6 deployment look bad.

> 3) What is the traffic volume that your statistics is based upon?

I don't know. But the volume doesn't matter if it's not a representative sample or if you're not measuring the right thing.

Re: We need a new approach

APNIC's methodology is explained here: https://labs.apnic.net/measureipv6/. AMS-IX's graphs are obviously flow statistics from their network only.

Your source was right in that these (plus Google's) are the best publicly available statistics, but they won't be of any use to you if you don't understand what they're measuring.

Re: We need a new approach

My "wide deployment" comment was referring to the things necessary to support a network of the type described in your draft/presentation but using existing v6 transition tech -- mainly that's support for v4, v6, NAT64 and NAT46 in ISP gear, CPEs and client devices. Those are either supported by almost everything or (in the case of ISP gear and CPEs for NAT64/NAT46) supported by enough things that you shouldn't have any trouble getting equipment for them if you want to.

I've looked at APNIC's stats many times, but what they track is the percentage of clients that hit their measurement servers over v6. As it happens, that's not a useful stat when it comes to tracking support for any of the above.

As for the AMS-IX stats, I already explained to you why they're not an accurate measurement of the overall amount of v6 traffic on the internet, but they're also not a useful stat for tracking the above things either.

Re: We need a new approach

We already spent far longer than it deserves discussing the thing last year. What you've come up with can be better handled using technologies that already exist and already have wide deployment.

Re: We need a new approach

I've already done everyone a big favor by going over the draft itself. The presentation is just a summary of the draft; it doesn't change how the draft functions and thus of course doesn't change my conclusions.

Re: We need a new approach

In case anybody cares, I looked at this draft the last time it was posted and came to the conclusion that it's more or less a rehashing of methods that already exist in v6 (that is, 6to4 and NAT64/NAT46).

Like I said earlier in this thread, people's ideas seem to be either impossible or already implemented in v6. This one happens to fall more into the latter.

Re: Seriously, whats wrong with IPV6 ?

...yes, we do. In fact we would need it even more then.

Re: Seriously, whats wrong with IPV6 ?

...no they don't. Even the routers that support NAT66 (which is a minority of the set that support v6) don't set it up by default. Major deployments in the UK (BT, Sky) and the US (Comcast) don't use NAT66. In fact I don't think I've heard of any ISP v6 deployments that rely on NAT66.

I'm under the impression that most new routers support v6, although there's certainly a long tail of crap out there. On the other hand, something like 97% of people use the ISP-provided router, so there's an argument that third-party routers are mostly irrelevant.

So what sort of network would require a complete redesign for v6? I'm sure there's something out there somewhere, but it's not common. People that incorrectly think that v6 would require a complete redesign of their network are a lot more common.

> IPv6 does the job, but it is certainly not the best solution to the problem. If it were, we wouldn't have an uptake problem.

Your second sentence doesn't logically follow from the first. It's entirely possible that the best solution has an uptake problem.

As far as I can tell, it's impossible to make a solution without an uptake problem, and it's my humble opinion that being impossible disqualifies a solution from being the best solution, on virtue of the fact that we couldn't actually do something that's impossible.

To be clear, my basis for believing that it's impossible is that (a) current v4 doesn't support bigger addresses, (b) any method of upgrading it requires lots of people to do something, and (c) it's the "require lots of people to do something" part that causes the problems in uptake.

Lots of people think they have a way around one or the other of those, but their ideas always seem to be either impossible or already implemented in v6.

(As always, you could easily change my mind by giving me something that doesn't fall into one of those categories. But if your idea is "just add another octet" or if it involves pointing me to dozens of pages of draft text, expecting me to read it all and decipher your idea for you and then spend weeks dancing around explaining it to me when I conclude that you've just reinvented something that already exists and ask you to explain how it's different... then you're probably not going to have much luck.)

Re: "Remind us again why the IETF didn't make IPv6 backwards compatible"

Perhaps it would be more accurate to say that v4 as currently specified and implemented everywhere is not forwards compatible with bigger address spaces.

It has multiple places where that forwards compatibility could be added: the version field, option headers, the reserved flag or even a reserved src/dest IP address. (Of those, v6 went with the version field for native operation and the protocol field for operation over the top of v4, which makes sense because that's the intended use of those fields.) But all of these options require upgrading hosts, routers, networks, software etc to handle them, so no existing devices will be compatible with the longer addresses, and none of them allow an unupgraded host to initiate connections to an arbitrary upgraded host.

At the point where you have to change v4 to support bigger addresses, can you really say that v4 is compatible with bigger addresses? Looking at the rest of the thread, it seems to me that "existing, unmodified v4 host can talk to arbitrary v6 host" is what people want, so it looks like their answer to this question is "no".

It might be more accurate to say that, but it's also an awful lot more words to type out every time.

Re: Why didn't they follow the phone system?

That still requires you to do almost everything that v6 requires you to do. It may save you some code in the IP stack, but that's the part we're not having any trouble with. You still have to update protocols, patch all your software, configure new addresses, firewalls etc, and those are the parts we're having trouble getting done.

And v6 has a mode that works like that! You can put a magic number (41) in the protocol field to indicate that the packet contains v6 addresses, and then the v6 addresses go after the v4 header. People doing v6 deployments seem to strongly prefer running it natively though.

Re: IPv6 was designed by theorists

People who care about performance. And yes, computers work for us and not the other way around, which is why you let DNS do the heavy lifting rather than manually dealing with IP addresses. Otherwise you're just doing the computer's work for it, which is backwards.

That prefix is actually just a default, though. If you're setting up your own NAT64 router and you want to use another prefix, you can.

> The v4 hosts don't need to contact all the "extended address" hosts, they would be in their own world, and a dual homed interface (like how IPv6 works now) would let them communicate with the outside world using the new 6 octet scheme.

Okay, so the mapping wouldn't actually do anything that we don't already have in v6. As such, it seems unlikely it would be much different to v6 in deployment time either.

Re: We need a new approach

It does, though? It reduces the amount of CGNAT hardware the ISP needs to provision. I think for EE the figure was something like 70% of their traffic flows over native v6, which cuts the costs of their CGNAT infrastructure by two thirds.

Having v6 also means that the v4 doesn't need to work as well -- being behind CGNAT is a lot more okay if you can side-step it. Also, in many cases you don't need v4 on the client side. For their v6-capable users, EE provide no v4 service on the network. T-Mobile in the US is the same.

(The server side is a little trickier. I do run most of my own personal services over v6 only, so it's certainly doable.)

Re: IPv6 was designed by theorists

64:ff9b:: is checksum neutral, so packets can be translated without needing to adjust the checksum on them (0xffff - 0x64 = 0xff9b, and the rest is all zeros). Since you don't generally deal with IPs directly it's not critical for the prefix to be shorter, while performance is important.

> Had they simply added two octets and made 0.0.x.x.x.x map to IPv4 probably everyone would be using it today.

You clearly didn't think any part of this through. Two extra octets isn't enough, and how would the mapping benefit anybody? How would v4 hosts send packets to the IPs outside of 0.0/16? There are multiple mappings of v4 addresses into v6, but none of them enable v4 to talk to more than 32 bits of hosts, because v4 isn't capable of it -- and v4 will still not be capable of it regardless of the design of the other protocol involved.