* Posts by Nanashi

261 posts • joined 19 Sep 2016

Page:

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

Nanashi Bronze badge

Not really that many

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

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

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

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

Nanashi Bronze badge

Re: What has it got in its pocketses?

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

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

Nanashi Bronze badge

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

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

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

Nanashi Bronze badge

Re: That's pretty much all it does

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

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

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

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

Nanashi Bronze badge

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

Nanashi Bronze badge

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

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

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

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

Nanashi Bronze badge

Re: What has it got in its pocketses?

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

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

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

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

So, yes. The cost of NAT.

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

Nanashi Bronze badge

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

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

Nanashi Bronze badge

Re: What has it got in its pocketses?

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

Nanashi Bronze badge

Isn't that what I said when I mentioned sparse allocations and aggregation? Allocations are made hierarchically and in large blocks in order to minimize fragmentation and the number of routing table entries needed, and all of this consumes address space.

Essentially, a majority of IP addresses "go unused" in order to make routing on the internet more efficient (but those addresses are actually in use, they're just being used to make routing more efficient rather than being used for assignment to an end host).

...which is why it's not enough for the IP:person ratio to be equal to or only very slightly higher than the number of devices that each person owns. You need to consider the various layers of allocations above the end device.

Nanashi Bronze badge

Re: What has it got in its pocketses?

It means that one third of the people hitting Google do so from TCP (...or UDP...) connections that have a v6 source address.

How the traffic is transported around inside the ISP is irrelevant to Google, who can't see any of those details.

Nanashi Bronze badge

Re: Hostnames

Thanks for the suggestion... although I'm not entirely sure what I'd discover that could change anything I've said.

v6 is already in many typical homes. It got there by having the same level of out-of-the-box usefulness and security as v4 does.

NAT and firewalls are two separate things. NAT doesn't provide any level of security for poorly configured/secured devices on the home network, but the firewall does and that's how home routers secure the network behind them, on both v4 and v6. We're already at the point you're saying we need to be at.

Nanashi Bronze badge

Re: That's pretty much all it does

"IPv6 nutters"? "Ivory tower"? Are we really going there? Again?

The people who designed v6 knew full well what would be involved. We ended up with what we did because there wasn't any other way to do it. v4 doesn't support addresses bigger than 32 bits, and fixing that involves replacing the IP stack with one that does support bigger addresses, and then plumbing that support through to everything that deals with IP addresses.

There's simply no way around this. You have to touch every system, because v4 is the layer of the internet that touches every system. The only methods that would help (things like 6to4, NAT64 etc) were used for v6.

Designing something that takes into account the limitations of the existing technology and of what can be done... is the exact opposite of an ivory tower.

If you're looking for people in ivory towers, perhaps you should look at the people who insist there's a way to make v4 somehow be forwards-compatible with bigger addresses without making any changes to v4 or any v4 devices. The people who are ignoring how both v4 and v6 work. Those are the people who are ignoring reality.

Incidentally, if you do have a way of designing a new protocol that's easier to deploy than v6 is, then feel free to prove me wrong by posting it -- so long as a) it actually works, and b) it's not something that v6 already does, because if it doesn't meet those two requirements it's just going to be another in the long list of dumb suggestions that don't actually help.

Nanashi Bronze badge

Re: If Only...

Not if you're paying attention. Gaming forums are full of people trying to "fix their NAT type", and they don't have much success when behind CGNAT. Games are using UPnP where they can, but people here keep complaining that UPnP is a security risk, and in any case it doesn't work so well behind CGNAT either. When they can't get a direct connection, games are relaying through central servers which adds latency and means you need the server to stay up to play the game. Similar problems abound outside of gaming too.

Yes, there are workarounds for many of the problems caused by NAT, but they're workarounds. The problems are still there, and the workarounds are expensive, and it's not necessary to pay that cost to stop people from accessing a server on your network.

Nanashi Bronze badge

Re: If Only...

Probably not hackers or the GCHQ/NSA. It's more likely to be gamers, people using VoIP, people wanting to reach their Nextcloud install or similar. These people aren't hackers.

It's okay to not want people from the internet to be able to connect by default, and it's okay to not want to change that. But you don't need NAT to stop people connecting, and in fact can't use NAT to stop people connecting, so not using NAT doesn't constitute a change to whether or not people can connect.

Nanashi Bronze badge

Yes? That's how I learnt v4 too, and I'd be willing to tick the v4 box on the same basis. If you're that afraid of running a network, then you already can't work in IT.

The risks aren't as big as you think they are... and the rewards are bigger than you think they are too. But I suppose you're not the only person who's afraid of new things.

Nanashi Bronze badge

Re: IPv6 isn't a very good solution?

They're not 4 bytes though, they're 4 octets. For computing architectures with 8-bit bytes, which is indeed common today, that's exactly equal to the length of 4 bytes, but that doesn't mean that the length of an IP address will change if you change the length of your bytes.

I was replying to a suggestion to change the size of a byte in order to get more addresses. Not only is this a non-trivial change to make, it wouldn't change the length of v4 addresses. (And even if it did, your bigger addresses would have the exact same compatibility problems with existing machines that v6 does...)

Nanashi Bronze badge

It's not enough because we're talking about layer 3 here, not layer 2. We aren't talking about MAC addresses, but IP addresses. They aren't allocated densely, but rather sparsely. The sparse allocation is critically important because it's how we scale the internet up to the scale of the internet. This is the entire reason we have IP in the first place rather than relying only on MAC addresses, and you can't just ignore it.

You're suggesting to allocate one /8 to each country, i.e. to use 8 bits of the address space to identify a country. With my lower-end allocations to end users, I'm suggesting to allocate 16 bits of address space to each user for their networks. Out of 48 bits, that leaves us with 48-8-16 = 24 bits of address space for the ISPs in each country. There are many countries, perhaps even most of them, that wouldn't fit into 24 bits of address space even in v4 land where the default end-user allocation size is often no addresses. As such, 48 total bits seems like it might very well be too few bits now, let alone in the future. That's why I don't think it'll meet the goal of giving us too many addresses.

To answer your last question: layer 2 is 64 bits for new protocols, and layer 3's routing and aggregation consumes additional address space, so we need something like 80-96 bits at L3 to handle the full L2 address space.

Nanashi Bronze badge

Re: I keep trying...

Psychic debugging time: PMTUD clamping. You might have it enabled for v4 but not for v6.

(I mean, I'd be happy to do non-psychic debugging too -- post a wget output of the failing URLs if you want, or at least tell us the sites in question.)

Nanashi Bronze badge

It doesn't obsolete your knowledge, because a significant fraction of your v4 knowledge applies to v6. It doesn't require expensive training courses; I learnt it from random web pages. It doesn't require a wholesale replacement of your entire infrastructure; you can replace each component during your normal refresh cycle. The security risks are not really any different to v4, and people's brains mostly don't lock up when dealing with v4.

If IPv8 was IPv4 with an additional two octets, then IPv8 would be too small. Deploying a new layer 3 protocol is an extremely long and expensive process. We absolutely do not want to do it more than once, so deploying a protocol that's too small would be a bad idea.

I'm also not convinced that making the protocol too small would give you universal buy-in. A lot of complaints don't seem to be based on reality, and most of the real problems involved in upgrading v4 will still exist regardless of how many bits you add.

Nanashi Bronze badge

It's really hard to put a specific duration on it, because it depends on how much you're willing to give up and how much time and effort you're willing to spend working around address space limitations, and on far too many parameters to get a proper handle on. But let's see what I can do.

In v6, you're supposed to get something between a /56 and a /48, with each network being /64. In other words, 256 to 65536 networks of effectively infinite hosts each. If we took the lower end of network count (256 networks, 8 bits) and dramatically reduced the number of hosts per network to 256 (again, 8 bits) and allocated out of a 48-bit space, then each user would get a /32 and there would be 2^32 (4 billion) /32s available.

Well, the standard allocation to end users in v4 is already either /32 or -- for phones or ISPs with CGNAT, which is probably billions of users -- absolutely nothing, and we're running out in v4, so with these allocation assumptions in a 48-bit space it seems like we'd be at least a significant fraction of the way to running out just with the current internet, let alone accommodating any future growth.

Deploying a new layer 3 protocol is an extremely long and expensive process. We only want to do it once, which means that providing far too many addresses is a design goal, so that we don't hit the point of having any reason to need another upgrade. I don't think 48 bits would meet that goal.

Nanashi Bronze badge

Re: What has it got in its pocketses?

Did anybody in your imagined conversation consider the cost of not rolling out v6? The cost of NAT, of dealing with RFC1918 clashes, of doing split DNS and VPNs and remapping, of the problems caused by CGNAT, of not being able to do things due to address exhaustion, of spending engineer time fixing problems in workarounds that just don't need to exist?

Probably not, since people ignore it constantly in the real world too, but that doesn't mean the cost isn't there.

Nanashi Bronze badge

Re: Not be simple

It's roughly the same design and architecture as v4, it just has longer addresses. There are some differences in the details but the overall design and architecture is unchanged. If you understand v4 then most of your knowledge of how it works can be transferred directly to v6.

v6 has many, many backwards compatibility methods. You can run both v4 and v6 side by side on the same networks. You've got NAT64, DS-lite, 6to4, Teredo and a number of other ways to provide v6 connectivity over v4 and connectivity to v4 hosts from v6. How can you say it's not backwards compatible when you have a whole host of backwards compatibility methods to use?

I'm considering the option of staying silent, but how is that going to help when people are spreading so much ignorant misinformation? I'd like to correct their misunderstandings, and I'd definitely like to stop the misinformation from spreading, and I don't see how I can do that by staying silent.

Nanashi Bronze badge

In that case you just copy/paste the address out of your /etc/resolv.conf file. Or type it out from memory, because it's not that hard to remember v6 addresses like 2001:db8:abcd::1; it's just your prefix plus "1". Or put it into /etc/hosts if your DNS breaks so often that this is such a big problem for you. Or connect over v4 -- one of the benefits of dual stack is that you can connect over one address family when you break the other one.

Nanashi Bronze badge

We already rolled out the new IP stacks 20 years ago. Even Windows had the new stack in XP. The hold-up in deployment hasn't been in rolling out new IP stacks, it's been in getting support for bigger addresses into software and in getting people to actually use them. Your suggestion wouldn't have helped the part that's taken most of the time.

The translation you mention already exists in v6 -- it just doesn't help as much as you think it does.

v4 took more than 10 years to become dominant, and it wasn't trying to replace a massively-entrenched existing protocol across literally billions of devices, so I think reaching roughly one third of users in the 7 years or so that we've been seriously deploying v6 is not so much a sign of failure but rather a sign of how difficult it is to upgrade layer 3.

Nanashi Bronze badge

Re: Quick experiment

The televisions possibly, but I don't believe you have 8 computers and 4 laptops that don't support IPv6. It sounds like you disabled v4 without setting up any alternate backwards compatibility mechanism for reaching legacy v4-only hosts.

I'm trying your experiment here and things are still working, because I have NAT64 to handle the backwards compat.

Nanashi Bronze badge

That wouldn't even come close to providing the extra address space we need.

Nanashi Bronze badge

Re: Not be simple

And my point is that that's not the case. Like I said, v6 is already backwards compatible. For example, with NAT64 you can talk to a.b.c.d by sending v6 packets to 64:ff9b::a.b.c.d. You can also map the v4 space into any arbitrary /96, so you could for example map your RFC1918 space into 2001:db8:4242::192.168.1.x to allow inbound connections over v6 to your v4-only LAN devices.

None of this saves you from deploying v6 on your network though.

Some of the header changes were a choice (a choice which, I note, was done to reduce the overall header length and complexity), but it's impossible to avoid changes to the header format because the v4 header only allocates 32 bits to src and dest addresses. Changing the header is a requirement, not a choice. The header format can be translated anyway, so the additional changes don't introduce any more problems than we already had.

Nanashi Bronze badge

Re: That's pretty much all it does

48 bits won't be enough in the long run (possibly not even in the short run), and even if it was, deploying an address family that used 48-bit addresses would take the same amount of work that deploying v6 is taking. The work isn't proportional to the number of bits! You need to do the same amount of work to deploy any address family with a bigger address size.

NAT isn't a vital security tool. It provides no security, so it isn't a security tool, and if it's not a security tool then it certainly can't be a vital one. If anything, NAT complicates your network and thus makes it harder to secure.

Nanashi Bronze badge

Re: How many IP addresses do we actually need?

Because it's the smallest power of two that's bigger than 64.

The point of L3 is to provide a layer of routing and aggregation on top of L2. Routing and aggregation consumes address space. L2 is 64 bits for new protocols, so L3 needs to be bigger than 64 bits. The next power of two up is 128, so here we are at 128 bits.

We could perhaps have gone for 80 or 96 bits, but can you imagine the sheer amount of wailing and teeth gnashing that a non-power-of-two bit length would've caused?

Nanashi Bronze badge

Re: Hostnames

Are you seriously arguing that most members of the public don't know the alphabet? I'm reasonably sure literacy rates are higher than that, and in any case someone who doesn't know the alphabet isn't going to be reading through their router admin pages.

Most people don't monitor for valid IPs when setting a new router up. They plug it in, turn it on, connect their devices and just use it. Most people are so unfamiliar with networking that v4 confuses them too. It's not going to be any worse with v6, and in fact the general lack of NAT will make it easier to understand and configure than v4 where NAT is a de-facto requirement.

Nanashi Bronze badge

Re: Not be simple

You are way off base. IP addresses are a sequence of bits. Decimal vs hexdecimal is purely for the textual representation, and has no bearing whatsoever on the packet format. So no, you couldn't have made the system backwards compatible by writing the addresses differently. The suggestion is entirely nonsensical.

In fairness, you did mention that you might not know what you're talking about. But for some reason that didn't stop you from calling the IETF a "bunch of shit-for-brains engineers". Here we have the Dunning-Kruger effect at its finest.

IPv6 is backwards compatible, by the way. Unfortunately v4 isn't forwards-compatible with larger address spaces which limits what you can do, but v6 supports all of the forms of backwards compatibility that are actually compatible with the design of v4.

Nanashi Bronze badge

Re: What has it got in its pocketses?

And fortunately we have IPv6 for those people, although a lot of them will outsource all of the technical aspects to their ISPs anyway.

Nanashi Bronze badge

Re: IPv6 was designed for a world of servers. now everything is a client instead.

Yes, and that's exactly what we did, except it doesn't seem to have stopped people from complaining about how massive the differences are and how we should've done the things we did do...

You don't need to rewrite your software from scratch to support v6. It's just some relatively minor alterations, and those alterations are exactly the same as the ones we'd have to make if we only added the 16 bits you seem to be suggesting we should've added -- which, incidentally, would be by far insufficient for the internet and would lead to needing to replace the IP protocol a second time. Surely it's better to add enough addresses the first time around?

v6 also does the "all existing addresses sit inside the new address space" thing, and it can do the simple translator thing you describe. Again, it already does the things you're saying it should've done.

ASN length was a different beast, because we didn't have hard-coded 16-bit ASN fields in every piece of network-capable software and hardware on the planet. The vast majority of network devices don't know or care about AS numbers at all. It's not relevant to the challenges posed by upgrading the IP layer.

Nanashi Bronze badge

Re: Not be simple

Mr. and Mrs. Average Public aren't expected to deal with IPs. They're expected to use hostnames, which by the way also use the letters in the range g to z as well as numbers and yet we don't complain about how hard those are to use.

Mr. and Mrs. Average Public don't need or want a 128-bit address on their machines. They just want their machines to work; the 128-bit addresses are just part of the technical details for how we engineers make that happen, rather than something that the end-user cares about. All of this is by design.

The format you suggest can't accommodate v6's address space, so it wouldn't even be an option. At least the "idiot engineers at IEFT" understood the limits of what it and isn't possible.

Nanashi Bronze badge

You're not supposed to remember them, you're supposed to use DNS and remember the hostnames.

And yes, there is: you can't just "allow bigger numbers" in the textual representation of a v4 address. The addresses are actually a sequence of 32 bits and there's no space in there to represent anything outside of the set of 256^4 addresses that it can currently do.

Nanashi Bronze badge

Before IANA ran out in 2011, we were going through one /8 per month, and demand has only gone up since then. At that rate, a /16 would last for about 2 hours of allocations. Even if you could hunt down a few thousand of them, it's just not a lot of space compared to what we need.

At the end of the day, v4 is simply too small. No amount of unused allocations will change that.

Nanashi Bronze badge

Re: IPv6 isn't a very good solution?

That would... not be simple. Or rather, it displays a complete misunderstanding of how v4 addresses work. Addresses in v4 aren't 4 bytes, they're 4 octets (32 bits). Bytes don't have to be 8 bits long, but v4 addresses are a fixed 32 bits regardless of the byte length of your computer's architecture. (It has to be this way because IP is used to talk between computer systems that use different byte lengths.)

You could design a protocol that used 40 bit addresses if you wanted, but it would end up looking very much like v6. In particular it'd have all of the same problems deploying as v6 would, because its 40 bit addresses are longer than v4's 32-bit addresses and that's where all the problems come from in the first place. You'd still have to patch all OSs and software to handle the new address length, upgrade legacy devices, update DHCP, DNS etc etc etc.

On top of that, 40 bits is woefully insufficient even for today's internet, let alone the future internet. After you finished deploying your 40-bit address family, you'd have to turn around and do it all again to increase the address size further. It'd be a complete waste of effort since you'd be back to doing v6 anyway.

So... no, that wouldn't even be a solution, let alone a simple one.

Nanashi Bronze badge

Re: IPv6 isn't a very good solution?

That's pretty much all it does. Almost everything else works the same way v4 does. Routing works the same way, address assignment works the same, DNS works the same, it works over the same L2 links that v4 does, TCP, UDP and other L4 protocols work the same, link-local addresses are in v4, and v4 even had router advertisements already before v6 was out... what's actually different?

There's NDP instead of ARP, but they work the same general way, except broadcast is removed in favor of multicast. v4 already has multicast so if anything this is actually a simplification. SLAAC is new, but that's really simple. I'm struggling to think of anything else.

> At this point we need an ipv7 that replaces ipv6 and is simply ipv4 with a 64-bit address space.

That's one of the last things we need. 64 bits would be insufficient, and expanding the address space from 32 bits to 64 bits has all of the exact same problems that expanding it to 128 bits does, so it wouldn't actually help you any. You'd just be throwing away 20 years of software support and deployment to restart from scratch with something that's going to have the same trouble deploying, which doesn't seem like it would help much to me.

Nanashi Bronze badge

Re: Sign of mass adoption

Yes? v4 is expected to stick around for a while. Undeploying v4 comes after deploying v6.

Nanashi Bronze badge

Re: Doomed to eternal limbo

v6 isn't going to cause a bigger breakdown in the internet than it's fixing. There's somewhere around a billion people using v6, about a third of the total on the internet, and it hasn't broken down, and neither have the networks of the people that're using it.

Meanwhile various things are broken on v4 and cannot really be fixed due to address shortages.

Nanashi Bronze badge

Re: @cdegroot

When you're stuck behind CGNAT without v6, tunnelling out to a VPS is keeping it simple. (Although it would be better to get a VPS from someone that actually does v6 properly, e.g. Linode, rather than paying someone that can't do routed prefixes.)

Nanashi Bronze badge

We already have a protocol that's backwards-compatible with v4 though (namely IPv6). How would designing another one help? You'd just end up in the same situation v6 is, except 20 years behind in software support and development.

The compatibility problem with v4 and v6 is that v4 isn't forwards compatible with bigger address sizes. Designing a new protocol won't change v4's lack of forwards-compatibility.

Nanashi Bronze badge

Re: Doomed to eternal limbo

You're thinking of MAC addresses, not IP addresses. MAC addresses come burned into each device, and get distributed via ARP/NDP. IP addresses are assigned to each machine from the prefix on the network.

SLAAC is very simple to set up... but the vast majority of people don't need to do so, because their routers will ship with it configured automatically in the same way they ship with DHCPv4 servers configured automatically. If you do need to set it up yourself, it's easier than setting a DHCP server up by yourself.

Nanashi Bronze badge

Re: IPv6 isn't a very good solution?

It's different because the telephone network was designed around variable-length phone numbers from the start, whereas v4 was designed around a fixed address length.

As such, it's easy to make phone numbers longer but it's much harder to make IP addresses longer. Should it be this way? There's not much point discussing that now; it is this way. If you have complaints, take them to the people who designed v4.

Nanashi Bronze badge

Re: What has it got in its pocketses?

We're not criticizing v4 for not being forwards compatible. It's just a fact of life that it isn't. (Meanwhile, v6 has various methods of backwards compatibility so people complaining that it doesn't are wrong.)

You're not going to fix this by introducing a new protocol to which v4 is also not forwards compatible. The way to fix it is education, but there seems to be an endless supply of people who don't know what they're talking about but are happy to talk as if they did.

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

Nanashi Bronze badge

Re: Plus which ...

If you moved on from the DOD that long ago, then you may have missed that computer networks and PCs have already become ubiquitous in the DOD. They're already using a "technology that potentially allows folks anywhere in the world to browser the contents of its computers if any of thousands of things go wrong".

All of the worries you bring up have already been addressed by their existing network teams for their existing network. They're essentially just FUD at this point.

Nanashi Bronze badge

Re: IPv6 was a great idea when it was invented

v6 doesn't require massive changes though, considering the scope of what it's doing. It requires something close to the minimal set of changes that are necessary to expand the address size.

The v6 networking model is pretty much identical to the v4 model; its main difference is that the addresses are longer than they are in v4. It's true that making the addresses longer requires a large set of changes, but... isn't that sort of unavoidable? v4 doesn't work with longer addresses, and those longer addresses are the reason we're doing this in the first place. How are you going to get them without making the changes needed to add support for them?

v6 already has widespread support and deployment. Dumping all of that in favor of something that still has to do most of the same work, from scratch with no existing support, would be incredibly counterproductive.

Nanashi Bronze badge

They interact with a lot of other entities, ones that don't have the largest allocation of v4 addresses to a single entity, and those other entities use a lot of RFC1918 space. That's going to lead to a lot of instances of needing to interoperate with networks that have overlapping RFC1918 space. RFC1918 overlaps are expensive to deal with, and are a security headache. I can understand not wanting to deal with them.

They're probably also interested in selling off some of that space.

Nanashi Bronze badge

Re: NAT is not a firewall

It may look an awful lot like one when combined with RFC1918 addresses, but it is not. Any inbound connection that's possible on a network that's not using NAT is also possible if you add NAT to the same network without changing anything else. NAT is applied only to outbound connections, not inbound ones.

I'm not saying that it "only blocks most" inbound connections here. It doesn't block any of them. That's why it's not a firewall, that's why you need a firewall and that's why you don't need NAT to have a firewall or to be secure. If anything, NAT is just going to confuse you into thinking you're secure when you're not.

Hopefully the DoD understands this better than the average El Reg commenter (who will now proceed to downvote me for calling out their misunderstandings of NAT).

Page:

SUBSCRIBE TO OUR WEEKLY TECH NEWSLETTER

Biting the hand that feeds IT © 1998–2020