You may have heard this one before, but we have now really run out of public IPv4 address blocks.
The Internet Assigned Numbers Authority – the global overseers of network addresses – said it had run out of new addresses to dish out to regional internet registries (RIRs) in 2011. One of those RIRs, the Asia-Pacific Network …

COMMENTS

Time to claw some back

There are probably large blocks of unused IPv4 addresses out there, if only the IANA would get off it's bottom and reclaim them. A lot of the big companies who were assigned a /8, back in the day probably don't use the full range they hold, since the introduction of NAT.

Re: Time to claw some back

If they were going to, they would have needed to begin the effort a decade ago. You can't ask big organizations to re-IP hundreds of thousands of devices overnight. By the time old school /8's like Apple's, MIT's, HP's pair etc. become available everyone who needs more IPv4 addresses will have moved to IPv6.

Re: Time to claw some back

"What's the point in trying to claw back IPv4 addresses? It would not fix the problem, just delay it for another couple of years."

There's actually an interesting thought there. There are multiple groups of people who are "anti Internet".

One is the Facebook Crowd, they only want Facebook, not the Internet. Those people typically either don't use E-Mail at all or use one of the few largest mail providers.

The other one is the people being fed up with their ISPs meddling with the Internet and certain agencies sniffing it all, so they create their own overlay network using the Internet only as a transport network for their VPNs.

So there's a chance that in a few years people don't want the Internet any more.

compatability

Many companies running ipv4 routable addresses inside their network could release addresses by running IPv6 at the border and IPv4 internally. Basically turns their assigned range into a private network block. Not suitable for all, but should help migration timelines.

Re: Time to claw some back

I left ICL in 2001 - they had already at that point switched their internet link from a fully routed (but firewalled as approriate) internal network (145.227.0.0/16) to some seperate proxy / gateway in another net range run by ICLNET. 145.227.0.0 has basically been dead to the world since then, but is still allocated to (now) Fujitsu.

Sure, the renumbering of internal machines to the new 'private lan' scheme was taking ages, and most stuff still used 145.227.0.0/16 when I left, but it doesn't matter - the only internet access they have is through application-level proxies so they'll never need to route to a "real" 145.227.0.0/16 address if it was relinquished.

Same goes for most others - there is no need for them to all renumber before giving up a netblock.

Re: Time to claw some back

Re: Time to claw some back

"The other one is the people being fed up with their ISPs meddling with the Internet and certain agencies sniffing it all, so they create their own overlay network using the Internet only as a transport network for their VPNs."

This is what I and a handful of my friends have done for a few years now, but I never really considered it as being "anti-internet" at all, but rather using the internet as designed. The internet is, after all, just a transport network which various services use for communication. Also all of us use external services on the internet (obviously) as well.

Re: Time to claw some back

"What's the point in trying to claw back IPv4 addresses? It would not fix the problem, just delay it for another couple of years."

I'd submit that Plan A -- everybody grumbles a bit them and switches to IPv6.-- does not seem to be working. In reality, many users can't "upgrade" because third parties like their ISP don't support IPV6. Others lack resources to upgrade. Many users feel, possibly correctly, that the minimal security provided by IPV4 plus NAT is better than not having "NAT security". A lot of stuff that purportedly supports IPV6 doesn't. Less than a year and a half ago, Microsoft had to fix Windows 10 before they could change their headquarters network to IPV6. Most users don't have the resources to fix their OS(es) or their hardware. There may be other valid reasons. Whatever ... IPV6 adoption is glacial at best.

I'd submit that a few years to develop and implement a Plan B that -- unlike Plan A -- realistically addresses the needs/desires of users might be a really good idea.

And a Plan C developed in parallel with Plan B in case Plan B doesn't work out, might not be a bad idea either.

@AC - starting to see malware attacks in IPv6

And this is why the average person shouldn't want to switch to IPv6, even if his ISP, his router and his computer/devices all support IPv6 perfectly. With IPv4 pretty much every consumer uses NAT, and is mostly safe from direct attacks from the internet.

Sure IPv6 can use firewalls, but will consumers have that by default with all typical combinations of IPv6 supporting ISPs, routers, etc.? I wouldn't count on it - if my parents were urged by their ISP to switch to IPv6 I'd tell them not to. I know they are safe with IPv4 thanks to NAT, with IPv6 I'd have to check out the hardware, how it is set up, etc.

Even then I have to hope that they don't buy some internet connected light bulb that provides instructions telling you how to disable your router's firewall.

Re: @AC - starting to see malware attacks in IPv6

I've had two cable ISPs that supported IPv6, now. Every home router I've used that had IPv6 had a firewall turned on by default. My cell phone provider also uses IPv6, BTW, with IPv4 support behind carrier NAT.

NAT was never supposed to be a security barrier; that it functions as one is mostly by accident, because it happens to require a firewall.

I've had no problems except for once early on when Comcast turned up IPv6 locally before they were ready to route it. A substantial fraction of my web and video streaming traffic goes over IPv6 now, and I can't say I notice a difference. And that may be part of the problem; for the consumer this isn't really a value-added proposition.

Re: Time to claw some back

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

Re: Time to claw some back

part of the scheme uses an IPv4 /30 block, which basically wastes 3 of the addresses. In reality, a scheme that uses something _like_ PPPoE or some other kind of tunneling protocol would only require 1 IP address in a block of 255 to be a gateway address. The additional bandwidth you might get by having to NOT use a tunneling or PPP-derived protocol (maybe 5%, let's say) would be compensated for by a much lower price. The ISP would be able to sell 3 times (or more) as many fixed IPv4 addresses to customers that need them.

All of this being said, it's the lack of efficiency of small netblocks (particularly /30's that potentially waste 3 for every 1 that gets assigned) that's eating up the IPv4's I'd bet.

I still want everyone migrating to IPv6. It's just that the ISPs have been dragging their feet for SO long that it's likely I'll need to maintain a fixed IPv4 address for the short haul, at least. And I don't want to see them priced out of the range of affordability.

Re: Time to claw some back

part of the scheme uses an IPv4 /30 block, which basically wastes 3 of the addresses. In reality, a scheme that uses something _like_ PPPoE or some other kind of tunneling protocol would only require 1 IP address in a block of 255 to be a gateway address. The additional bandwidth you might get by having to NOT use a tunneling or PPP-derived protocol (maybe 5%, let's say) would be compensated for by a much lower price. The ISP would be able to sell 3 times (or more) as many fixed IPv4 addresses to customers that need them.

What scheme? I believe you, but I've never seen it myself apart from a few niche (and practical) cases. I hope it's just one ISP, not a general USA 'tang?

Most residential services I know use at least /24 or a /23 for their provisions.

But even if they use that reasoning that it's to avoid needing tunnelling, they are wrong.

My current connection isn't tunnelled any more - no PPPoE. - authorisation is done based on the physical connection - i.e. who is "me" is tied to the physical line (even in my days of adsl with PPPoE I'm pretty sure you couldn't login with someone elses user/password on your line - so the authorisation of PPPoE wasn't the prime purpose of its use.)

At the moment, my single external IP address is sitting on a /20 - I don't have the "local lan traffic" sent to me - the remote router deals with that.

Any connections I do try to make to my "local lan" - the remote router replies to arp requests with it's own MAC (proxy arp) which then acts as a bridge to the remote address.

From my routers point of view, it's just a normal machine in a /20 network - sending IP packets "directly" to other users machines "on my lan", and routing to the router for addresses off-lan. The remote end deals with the realities.

Re: Time to claw some back

Re: Time to claw some back

"they were assigned before IANA existed"

Yup, and the guy who assigned them (Jon Postel) has been dead over 20 years.

And there have been some highly questionable acquisitions of some of those blocks (Such as how OSF1's block ended up in the hands of av8 software, via OSF1's tech contact apparently just walking off with it when OSF1 effectively ceased to exist)

Re: I've been trying to get this happening

Won't happen, don't stress over it. When the first site that's gotta be visible for some application is available on IPv6 only, then you'll get what you need to go IPv6 :)

And that ain't ever going to happen, not in my lifetime anyway.

No *business* is going to put their content on IPv6 only and have it visible to only a fraction of the world, when for a few dollars more it can be visible to the whole world. Perhaps once 99% of the users have IPv6 access then IPv6-only sites will start to appear.

There is no IPv4 shortage at the *content provider* side of things. You can share IPv4 addresses via CDNs, reverse proxies, load balancers, HTTP virtual hosts, SNI etc; this has been going on for years.

Even if a content-provider business *does* need their own IPv4 address for a service, and suppose it cost $10,000, they would still pay it just to make their service usable to everyone; they often pay more just for a cool domain name.

Things are different at the access side (i.e. users / customers). There, the shortage of IPv4 addresses is acute (at least in some regions). But unfortunately, deploying IPv6 does nothing to reduce the shortage, because it doesn't remove the need for IPv4 source addresses to access most of the Internet. If you don't have enough IPv4 addresses to give each customer one, then you are forced to use some sort of NAT, whether it be NAT44 or NAT64.

I see one solution: connecting the IPv6 and IPv4 Internets with a giant NAT64. This could be done by the existing content providers (e.g. Akamai, Cloudflare, Google): each of them could treat the whole IPv4 Internet as a big pool of user content and NAT64 to it as a public service. Then an end-user could have an IPv6-only connection, but still reach the whole IPv4 Internet (at least over TCP and UDP).

Re: I've been trying to get this happening

Re: I've been trying to get this happening

That's impossible. If you had a service accessible only by IPv6, and people really, really needed it, someone would build an IPv4/IPv6 adapter so that IPv4 could reach it. More likely your service isn't that important and nobody would ever use it, they'd use a similar service that was IPv4 only.

Re: I've been trying to get this happening

I salute your heroic efforts. What will actually happen is that as the tsunami waters recede, thick with corpses, the mercifully few politcians left alive will start up their endless litany of "I knew this would happen" and "If only they'd listened to me" with a big dollop of "Only I know how to fix this, trust me" and your choices will be—as usual after a completely predictable and monstrously mishandled crisis—believe them; or cut their throats.

Strangely, human history shows that these greedy, self-serving cretins usually do not get their throats cut but go on to incubate the next colossal disaster.

If you want a short summary of human history and what is fatally wrong with our species, I suggest: "People believe words, instead of actions".

what is wrong

is that people believe things that aren't true and act on those beliefs. That's all you need. I believe that accounts for 100% of artificial problems in this corner of the cosmos. But how to act on that belief... so far my favourite thing to do is called "hesitate"

"Nobody uses it..."

Re: "Nobody uses it..."

IPV6 is supported by most major operating systems. However, if you do try to use it on your network you run into non-standard IPV6 implementations; Android in general and Samsung Android in particular.

@boxplayer - Re: "Nobody uses it..."

Brownie for you!

Now keep on and come back to us when you'll be a big bank, insurance company, multinational corporation with 24/7 mission legacy critical systems and you'll teach us how you managed to convince the top management to accept the risk.

Re: @AC Brownie for you!

Re: @boxplayer - "Nobody uses it..."

Now keep on and come back to us when you'll be a big bank, insurance company, multinational corporation with 24/7 mission legacy critical systems and you'll teach us how you managed to convince the top management to accept the risk.

Re: @boxplayer - "Nobody uses it..."

I stopped trying many year ago. And the reason is: if I manage to convince them, and it fails, my head will get chopped. If we succeed, I would be "spared".

So the thing to do is just tell them in writing: we need to do this, and it will getting more expensive as time passses by, no definite timeline right now. And that's it.. when its time to do it, ask for the money as where will be a bid damocles sword, and money will happen. Oh, and as they know they knew, they will probably be nice about it.

Re: @boxplayer - "Nobody uses it..."

> it will getting more expensive as time passses by

Citation Required™.

Running a dual stack network costs more than running a single stack network. If there were a defined end-point for running dual stack, then the cost could be quantified and limited. But there is no defined end-point, so the cost is unbounded.

Dual stack is not a "transition technology" in the true sense, which is to make a change to your own network. In other words: "I want to migrate my network from IPv4 to IPv6. So I will run IPv4 and IPv6 in parallel for (say) a month while I do the changes, and at the end I'll have an IPv6-only network". Dual stack would work very nicely for that.

Unfortunately, ending up with an IPv6-only network is a non-starter. You would be disconnecting yourself from the vast majority of the Internet. There is no clear benefit to starting the transition if you cannot finish the transition; but there is a very clear cost.

Of course, one day, it may be possible to actually transition a network from IPv4 to IPv6. When that time comes, those who waited will find a wider choice of less buggy IPv6 implementations to work with.

Despite what some people have said here, people aren't stupid when it comes to their own money. They *will* happily invest their own money if it will save them money. But that's not something IPv6 offers today. Just repeatedly saying that it will doesn't make it true.

Re: @boxplayer - "Nobody uses it..."

IPX was never an Internet protocol, just a LAN one. The actual transition was from ARPANET's NCP to TCP/IP. Since there were relatively few nodes at the time, the Defense Communications Agency simply set a mandatory "flag day" when NCP would stop being routed. Even that wasn't a total success; it was initially supposed to be January 1, 1983, but they had to give a three month extension because not everyone had successfully written TCP/IP stacks by then.

Re: @boxplayer - "Nobody uses it..."

One of the universities I worked for transitioned to IPv6. There were some hiccups at first but once the routing was sorted out, I set up some dual-stack servers without trouble. (I believe the Internet2 academic research network runs IPv6.) In some ways universities have fewer incentives than most, because many of them got huge allocations.

The biggest problem isn't that it's difficult, it's that there's still a lot of old equipment rattling around that either doesn't support it at all, or doesn't perform well enough. I've seen places gradually phase it in as they replaced crusty old routers with new kit.

Re: "Nobody uses it..."

I use it!

Congratulations.

Now, image that you are a really big organisation that's invested a lot of money in the whole IPv4 pit - routers, firewalls, access control measures, all of which are potentially bypassable by a bad IPv6 implementation..

In short, IPv6 is a mess. It's a total camel[1], designed by people who really, really didn't consider about how it would get implemented in the real world.

And, when those implementation issues became obvious, made it more complicated still.

A pox on it. We need IPv7 - just add another octet at the start of IPv6..

[1] A camel being a horse designed by a committee. And not a cute itty-bitty-kitty-committee either..

Re: "Nobody uses it..."

Right. Friends don't let friends use IPv6.

Adding an octet to the address field alone won't do the trick, though, a 40-year-old IPv4 carries a lot of other baggage, none fixed by IPv6. Better to keep using NAT where it's suitable, use the secondary market to buy and sell IPv4 space, and migrate over time to RINA ( pouzinsociety.org )

Re: "Nobody uses it..."

>A pox on it. We need IPv7 - just add another octet at the start of IPv6..

Couldn't we add one onto IPv4 instead and keep the rest of it the same? Then the hard-won skills of a multitude of consumer grannies (and me) could be transferred and nobody has to play how-many-colons bingo with that ridiculously opaque address scheme. Worked pretty well when we needed more phone numbers, amirite?

Re: "Nobody uses it..."

I think you mean that we need another octet at the beginning of the IPv4 address.

That's as unlikely as IPv6 ever being widely implemented.

If you consider the port number part of the IPv4 address (which it really is) and less use of port numbers by HTML5 etc., there is no shortage of IPv4 addresses from now until infinity. Sure it's messier than a clean new system, but IPv6 is hardly a clean system, and hardly new.

Re: "Nobody uses it..."

"I use it!

My home network, my ISP connection and the server where all my web sites live (and the sites I host for others) are all dual stack. It wasn't THAT hard."

I'm almost the same. My home and server both are dual stack. My home network tries to be, but I think there's a bug in my old router that stops IPv6 working fully. Can't be arsed to fix that just yet, but it's on my TODO.

cost

I'm on a small rural ISP which uses carrier grade NAT and it's working very well. Yes, it's a nuisance to not be able to use IPv6 without a tunnel, but I shudder to think about all the work this ISP would have to do to add IPv6 for their users. The two employees are already working to capacity so they would have to hire extra manpower to do that as well as deal with all their clients having problems stemming from a changeover, and I really don't think there is an economic incentive to do so.

Perhaps it's time for government grants for small providers. I just don't see us reaching the point where IPv6 becomes an absolute necessity for a very long time. It's going to take a lot more than the insistent begging and nagging from the IETF.

Perhaps it's time for government grants for small providers

Should the taxpayers really be saddled with the cost of government (inefficiently) teaching a small provider how to convert their networks to IPv6? Can't the provider just, you know, read a book like we did? Or go to Hurricane Electric like we did? It's really not that hard.

How about a compromise: if you want to get your own checkbook out to sponsor a small provider to learn IPv6, you should absolutely do that. And good on you.

Re: Compatibility

The IPv4-addresses-running-out-stories are getting old and so are the if-only-they-made-it compatible-with-IPv4-comments.

IPv4 uses 32-bit addresses. You can't stuff more addresses in 32 bits. So you need to make the addresses bigger. If you do that it is not IPv4 anymore. If you would even change one bit in IPv4 and make IPv4.1, still all devices using IPv4.0 need to be updated. So we need a *new* protocol with bigger addresses, 128 bits, which is IPv6. And while they were at it, they improved some other things that we didn't like about IPv4.

IPv6 was designed to run alongside IPv4 from the beginning. They work independently and you device might have IPv4, IPv6 or both and you would not notice the difference.

The reason we're dragging this so long:

- it's different, scary!

- we might need to buy new/updated device/software and it costs money!

Re: Compatibility

What you actually mean is that while they were at it, they improved/changed some other things that THEY didn't like about IPv4. Then stuck their fingers in their ears and ignored all the complaints for nearly THIRTY YEARS!!! Thus dooming their shiny new system to being a bizarre cult that people only join if there's no other possible choice.

I predict we'll get the paperless office before total IPv6 switchover. Or even the three seashells...

"IPv6 was designed to run alongside IPv4 from the beginning. "

Sure, so well that DHCP was an afterthought - the RCF came only in 2003, five years later, - because they thought routers could assign addresses but didn't think about every other need DNS, dynamic IP-hostnames assignment, etc. etc. IPv6 was designed too early and wasn't thereby designed truly for actual needs.

So you got AFAIK, three different ways to have addresses assigned and have to ensure they are configured correctly, then you need the software updated to manage them all.

Re: "IPv6 was designed to run alongside IPv4 from the beginning. "

Sure, so well that DHCP was an afterthought - the RCF came only in 2003, five years later, - because they thought routers could assign addresses but didn't think about every other need DNS, dynamic IP-hostnames assignment

SLAAC could do all of those things. The reason DHCP6 happened was the exact inertia people are reporting here. SLAAC: It's new. It's scary. What does rtadvd stand for anyway? Brown alert!

So we ended up with two ways to do the same thing and now we have to support both on the gateway because the wonderful thing about standards is there's so many to choose from.

Re: "IPv6 was designed to run alongside IPv4 from the beginning. "

So you got AFAIK, three different ways to have addresses assigned and have to ensure they are configured correctly

Indeed. So, my ISP enables IPv6 for me (at my request), which means that my router now has an IPv6 address. My firewall, that sits behind the router, also gets an IPv6 address.

Unfortunately, one that my router doesn't seem to understand, despite the fact that it's in (theoretically) the same prefix. So my devices inside the firewall can get their IPv6 addresses from the firewall and can see the firewall and all the IPv6-enabled devices inside. But nothing past the external interface of the firewall. The external interface of the firewall can see the internal interface of the router, but not the outside interface and nothing at all outside. So even manually looking up the IPv6 address of an external site and trying to ping6 it gets me a total failure to ping (IPv4 ping can reach it fine).

My firewall rules are OK (anything IPv6 can see anything outside on IPv6 - I'll get it working first then worry about protecting things). My router isn't running any firewall.

Can I work out how to fix it? No. Lots of theoretical stuff on "this is how it should work" that is totally unhelpful. And, after day of trying to make it work, several bottles of gin are starting to look mighty attractive, even though my head is already hurting trying to work my way through the broken IPv6 model..

In the end I gave up and turned off IPv6. Nothing I had needed it anyway..

Re: Compatibility

You can't stuff more addresses in 32 bits. So you need to make the addresses bigger. If you do that it is not IPv4 anymore.

No it's not, but if they had just made the first octet a pair, 0-65535, and added an extra octet at the end for local routing (with a default zero if not specified), they would have come up with a 6-byte IPv4+ address scheme which would have found far more acceptance than what IPv6 has received.

Most people could understand that, simply by reading it. IPv6; too complicated, not interested, bye.

Re: Compatibility

Alternatively, put the IPV4 block as part of the IPV8 [I'm making up a fictional logical profile]. For example, the address 100.101.102.103 in IPV4 could just be 0.0.0.0.100.101.102.103 in a new, expanded 64-bit address space. So you want the 128-bit address space? How about 0.0.0.0.0.0.0.0.0.0.0.0.100.101.102.103. IPV8 could be a drop-in replacement for IPV4, because anything that worked on IPV8 would coexist perfectly with IPV4 addresses. Anything that didn't work with IPV8 would still have all of the IPV4 address space while it gets updated.

Re: Compatibility

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

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

Re: Compatibility

To those who say this is impossible, not quite. Any IPV8-capable system would consider missing sections being high-order octets and their value to be 0. Thus, a request by an IPV4 system for 1.2.3.4 would be resolved by the IPV8 network to the same address 0...1.2.3.4. Certain networks that work only on version 4 would have problems. Any change does that. However, you could get one system functioning on IPV8 without breaking the others, as an IPV8 router would not break an IPV4 client. More specifically, all the original IPV4 tactics would hold--0...127.0.0.1 is still localhost, 0...10.0.0.0 is still private address space, etc. IPV6 does not do this, either on the theory that the features aren't needed or simply because they changed all the numbers. That results in the IPV6 system functioning independently from IPV4, but not functioning at all for backward compatibility. Perhaps it's wishful thinking, but perhaps if systems could be upgraded in place using a model as described, it would have been easier to transition.

I'm sure there are corner cases in code that would not allow any of this automatic code to function, although I'm not sure which parts of the code would break, but that is the case for any change, and people make plenty. People upgrade operating systems with the knowledge that code may need updating afterwards, but that most of it will still work. People have found ways to upgrade hardware without bringing down the systems running on it. By designing a system that provides the new functionality with a layer designed to allow most, if not all, legacy code to work, the barriers to construction of the new system are significantly lowered.

Re: Compatibility

So what is a legacy IPv4 stack going to do when it receives one of these hypothetical "IPv8" packets? It's just going to puke on a corrupted header. So you'll still have to rip and replace the stack in every device!

Re: Compatibility

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

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

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

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

Re: Compatibility

"No it's not, but if they had just made the first octet a pair, 0-65535, and added an extra octet at the end for local routing (with a default zero if not specified), "

And just HOW the fucketty fuck do you intend to shoe-horn 6 bytes into existing network protocols that have a 4-byte address field? Do you have any idea how many low-level network protocols have literally 4 bytes in which to pass "the address"? It's not all fucking FTP writing them out in plain text until it hits some fucking whitespace.

Re: Compatibility

In the late 90's they could have specified a bit to signify the 32-bit or larger addressing. A bit of support from say Cisco and Microsoft and you've got the foundation for adoption.

It would only then require relatively small tweaks from application software over the next twenty years and you're in business. As most software doesn't survive unchanged over twenty years, we'd be on IPV4.1 right now.

RIPE and co could make new blocks conditional on rolling out support for IPV4.1. Because there's so much time, that would just be a case of replacing older hardware/software with newer hardware/software as it reached EOL.

Re: Compatibility

128 bits for an IP address? No wonder nobody wants it. That's more addresses per person on the planet than there are cells in her/his body with a lot left over. You can be sure somebody, somewhere, somehow, has worked out how to use these redundant bits abusively.

I can remember the 32-bit IP address of my ISP. Comes in handy for connecting when there's no DNS available. No way would I be able to memorise a 128-bit address.

How many addresses do we actually need? Clearly 4G of them aren't enough. But ~100 addresses per person would surely do. That's an extra 8 bits. Add on a further 8 bits for a bit of slack, and we'd end up with 48-bit addresses, what the 6 in IPv6 suggests.

Re: Compatibility

Who on earth thought that 128-bit addresses was a good idea?

The idea of 128-bit addresses is you can afford to waste some of them in order to simplify routing. IPv6 addressing breaks down on some very specific barriers. There's no "wait, what's the broadcast address for a /27, again?" mental math.

The biggest thing to remember is that the smallest subnet is a /64. The last 64 bits are yours to do what you want with, so you can make them something memorable if you like. So that's a maximum of 16 arbitrary hex digits you might have to remember. But! You also get to omit leading zeroes, and collapse 16-bit blocks that are all 0. So it's not even that bad.

To give a real-world example, Comcast's DNS servers are 2001:558:feed::1 and 2001:558:feed::2. Those don't strike me as harder to memorize than most arbitrary IPv4 addresses. (OK, they're harder than 8.8.8.8, but that's something of a special case.)

Re: Compatibility

"Who on earth thought that 128-bit addresses was a good idea?"

A fair question, with a fair answer. The short answer is that you aren't supposed to use all 128 bits. The first few (for some variable value of "few") classifies the address type, the next few up to 48, 56 or 64, tells you the "destination network" and the final 64 is enough space to allow devices to assign their own addresses efficiently without fear of conflicts.

In addition to this separation, address allocation protocols are designed so that devices inside such a "destination network" can be easily re-assigned to a different prefix. This makes large-scale re-organisation of the network possible. IOW, IPv6's designers looked at the Balkanisation of the IPv4 address space in the 1990s, saw that by 2010 or so the major interconnects were going to need billions of entries in their routing tables, and decided to design a system that could "repair itself" from that kind of entropy.

The sheer length is mitigated by header compression strategies (in binary formats) and the various conventions for text formats. In any case, nearly all configuration should use DNS names and so almost the only things you need to know the numerical addresses of are your DNS servers and gateways. Those can be assigned hand-chosen addresses of the form "prefix::small-integer". If even that fails, you can ask a local subnet for its nearest host of a given type by using well-known multicast addresses.

In short, the designers of IPv6 were and are network people who grovel over these long addresses for a living and they designed it that way to make their lives easier. It is deeply puzzling that the greatest opposition to IPv6 appears to come from others in a similar line of work who have simply memorised all the arcane warts in IPv4 and are apparently afraid to learn about a much cleaner system.

Re: Compatibility

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

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

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

Re: Compatibility

>And why are you putting the blame on v6's designers, rather than putting it on v4's designers for failing to make their protocol forwards-compatible?

1. The v6 designers deliberately chose not to make their protocol compatible, thinking that migration would simply require the throwing of a great big switch. When they started this might have been possible, however by circa 1995 it was no longer a feasible option; yet the v6 designers persisted and continued to ignore the realworld.

2. It was only much later that more sensible people gave thought to interworking and migration.

3. The v4 designers did give thought to forwards-compatibility - it because of this compatibility that v6 traffic can be sent down the same pipe as v4 traffic and intermediate and end systems can pass the traffic to the relevant stack.

What is perhaps more relevant is given MS has supplied v6 since circa 2002, along with many (enterprise) network equipment vendors, why so few ISPs actually offer dual protocol services as standard.

Aside: I note that many consumer DSL routers etc. only support v4 and it is now 2018.

Re: Compatibility

@LenG

uh, do you REALLY understand IPv6 at all? It coexists just fine with IPv4. but yeah, really old code written ONLY for IPv4 would need to be updated to do IPv4/IPv6 sockets. That, and devices with ethernet or wifi devices that only handle IPv4 [like wiznet ethernet controllers, for example].

Re: Compatibility

IPv6 does not "coexist", it exists besides and outside of IPv4. It doesn't do IPv4 at all. And if we're going to switch to it, it needs to be a drop-in replacement which handles both, instead of an abstracted parallel universe where we struggle to find out what our address (or block) is, or to understand if our firewall is actually protecting us, let alone be able to choose which static IPv6 addresses we want our home web server to use.

Hurrah for everyone who found it "simple" to migrate to IPv6. Now kindly share your tutorials rather than sniffing at us old dinosaurs.

Re: Compatibility

Hurrah for everyone who found it "simple" to migrate to IPv6. Now kindly share your tutorials rather than sniffing at us old dinosaurs

Actually ISPs are already doing that. I've had V6 for many years but I had to build my own Linux-based border router/firewall. And V6 runs seamlessly internally on all our hosts - Linux, Windows, Android - when they talk to inside & outside V6 servers. I was surprised and fascinated to discover on holiday in Hawaii last year that the local (cable) ISP provided V6 service. The cable router was an Arris box so that manufacturer seems to have cracked the amazingly difficult problem of supporting V6 in their border router (it must be hard as so few other router mfrs seem to be able to do it).

Re: Compatibility

drop-in replacement which handles both, instead of an abstracted parallel universe where we struggle to find out what our address (or block) is, or to understand if our firewall is actually protecting us

Re: Compatibility

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

IPv4 addresses (without CIDR) can be understood by humans in their heads. IPv6 ones can't.

Re: Compatibility

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

Computationally, strcmp is, and always has been, the wrong way to do this. What if I decide to throw some leading zeroes into an octet, i.e. 010 instead of 10?

The correct answer, as it always has been, is to use inet_pton (or the equivalent in your favourite language) and compare the two addresses in binary form. That's just as true in IPv4 as it is in IPv6.

As for the human element, well in IPv4 you already remove trailing zeroes in your head from each octet and you can continue doing that for each quad in IPv6. As for address expansion, well that's hardly rocket science either.

None of this is actually difficult, you're just not used to it. You will get used to it. It just takes a little bit of time.

Re: Compatibility

Computationally, strcmp is, and always has been, the wrong way to do this. The correct answer, as it always has been, is to use inet_pton (or the equivalent in your favourite language) and compare the two addresses in binary form.

I think Adam's point was that the human brain's stdlib only has strcmp(). It doesn't implement inet_pton or binary comparison.

Re: Compatibility

You are weird. No normal user has ever wanted to do this. Come to think of it, neither have I and I'm happily running IPv6 on my network.

"IPv4 addresses (without CIDR) can be understood by humans in their heads. IPv6 ones can't."

Not sure what you mean by understanding an address, but if you are referring to network prefixes I rather suspect that the IPv6 ones are no more numerous or harder to remember than the IPv4 ones. I also rather suspect that you are over-stating the need to understand an address. You aren't the computer. Even if you are a network admin, if you are in any way competent, you won't spend much time grovelling over packets.

Re: Compatibility

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

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

10.24.42

10.24.0.42

10.24.052

10.24.0.052

10.24.0x2a

10.24.0.0x2a

10.030.42

10.030.0.42

10.030.052

10.030.0.052

10.030.0x2a

10.030.0.0x2a

10.0x1a.42

10.0x1a.0.42

10.0x1a.052

10.0x1a.0.052

10.0x1a.0x2a

10.0x1a.0.0x2a

10.1572906

10.06000052

10.0x18002a

012.24.42

012.24.0.42

012.24.052

012.24.0.052

012.24.0x2a

012.24.0.0x2a

012.030.42

012.030.0.42

012.030.052

012.030.0.052

012.030.0x2a

012.030.0.0x2a

012.0x1a.42

012.0x1a.0.42

012.0x1a.052

012.0x1a.0.052

012.0x1a.0x2a

012.0x1a.0.0x2a

012.1572906

012.06000052

012.0x18002a

0xa.24.42

0xa.24.0.42

0xa.24.052

0xa.24.0.052

0xa.24.0x2a

0xa.24.0.0x2a

0xa.030.42

0xa.030.0.42

0xa.030.052

0xa.030.0.052

0xa.030.0x2a

0xa.030.0.0x2a

0xa.0x1a.42

0xa.0x1a.0.42

0xa.0x1a.052

0xa.0x1a.0.052

0xa.0x1a.0x2a

0xa.0x1a.0.0x2a

0xa.1572906

0xa.06000052

0xa.0x18002a

169345066

01206000052

0xa18002a

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

2001:db8:420:24::42

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

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

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

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

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

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

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

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

Re: Compatibility

Some frameworks, in their 2015 incarnations break with IPv6, as happens for example with some Java frameworks (been there, done that..)

One example is reverse DNS from some java frameworks/libraries.. and that is just one of the cases.

That breaks some of my code in interceptors for WS-Security.

Now, you might say that that should be in the webserver (nginx, apache..) but there are advantages in having the auth in the java.. as for example some ipv6 addresses/ranges might be considered safe, etc.

Re: Compatibility

In some respects it is a helpful reminder that networking doesn't change very quickly - the article is from 2011, but still relevant; as are the comments.

I think we need to hold back from the "No need for NAT in ipv6" until we have workable solutions for all the various realworld use cases for which NAT has been found to be the solution. By 'workable' I mean solutions that for example don't rely on ISP's etc. suddenly waking up and deciding to be generous to their customers.

Re: Compatibility

cretins who designed IP6 had given some thought to making it backward compatible

It's quite clear from the various notes about the IPv6 design process that the people involved wanted to design a 'pure' new address methodology and so discarded anything 'old and broken'. And, in the process, managed to ensure that migration was not only difficult but, potentially, dangerous in terms of network security.

Re: Compatibility

"cretins who designed IP6 had given some thought to making it backward compatible"

They did. It's flat out impossible. IPv6 is 128 bit address space. IPv4 is 32-bit address space. You can address IPv4 from IPv6 but not the other way around.

In 1995 there was a meeting held with the objective of getting IPv6 deployed before the next "killer app" drove up Internet usage and made changeover harder. That same year in another room in the same conference centre at the same conference _at the same time_ there was a BoF meeting on html standards and the world wide web. Damn that Berners-Lee fellow!

The ironic thing is that IPv4 was originally going to be 128bit addressing, but Vint Cerf was browbeaten into reducing it to 32 bits because V4 was a kludge expected to only be needed for 5 years at most until the "real" internet protocol was developed.

Re: BT

I believe they rolled out firmware updates to devices going back to the HomeHub 4. I can't speak from personal experience, though.

I'm also on VM. I got fed up with waiting and implemented ipv6 with a Hurricane Electric tunnel. It works perfectly and maxes out my bandwidth with ease.

My advice to any VM customer is to switch their POS "super hub" into modem mode and use a decent router behind it. I have used nothing but OpenWRT routers for years. The ipv6 autoconfigures effortlessly if plugged into an ipv6 native connection, and even the tunnel config was straightforward to set up.

Re: BT

So BT completed the rollout, the problem is with your customer equipment.

I can understand you being frustrated with BT as they supplied you with the hardware (and it seems the firmware updates that were promised for earlier models were not delivered), but the fact is that you do have an ipv6 enabled line. Your problem is the shitty support BT offer for the equipment they supply.

If you were that way inclined, you could probably liberate the router from their proprietary firmware and implement ipv6 yourself - the hardware is perfectly capable.

Personally

I've made several attempts at switching over to IPV6 in the past. It's been a pretty heavy lift -- heavy enough that I gave up. Perhaps things have improved since then? When I can afford a weekend to devote to this, I'll try again.

Re: Personally

It took me two tries. The first time I ran into a couple of roadblocks. My ISP wouldn't support it, so I tried a tunnel broker (since defunct). The tunnel broker wouldn't complete my application, despite several attempts to contact them. Then, I misconfigured something and assumed that my ISP was blocking the encapsulated traffic.

The second time around, I used a different tunnel broker and got everything running after a couple of days. After that, I reconfigured all my machines to make sure that they weren't using static IPv6 addresses when talking to the outside world. It turned out to be surprisingly easy in the end, although I would much prefer to own my own IPv6 block rather than relying on a tunnel broker, and I haven't fully figured out the best way to do native IPv6 address management in a segmented network.

It's crazy how ISPs and even otherwise-reputable hosting companies (ovh, blacknight) aren't taking IPv6 seriously. Get a free IPv6 address? You have got to be f- joking.

Re: Personally

Re: Personally

Have they managed to put IPv6 on all their broadband gateways yet?

When I was experiencing the infamous "single thread performance" issue (see thinkbroadband), and after my complaints were being taken seriously and not just dismissed, the first thing they made me do was go back to v4 only, as they had only enabled one broadband gateway for v6. Proper ISP indeed. This wasn't that long ago - 2016 I think.

Meanwhile, on "not proper ISP" BT, IPv6 just works, didn't have to ask for it to be turned on, don't need to care about which part of the network my router is load balanced onto - and I don't have single thread performance issues!

Re: Personally

A lot of the horror stories out there are from people who tried it a few years back, when things were much less well sorted. When your ISP supports it, it's not too bad. At my current house my cable provider turned it on and it took me about a week to notice something had changed.

Supporting dual-stack servers is slightly trickier. A lot depends on how old your software is. Recently maintained software like Apache will happily dual-stack right out of the box. I run a couple MUSHes that have 1990s-era code bases and they were a little trickier. One of them I was able to coax into accepting IPv6 connections over a shared 4/6 socket. The other one I ended up using socat to accept IPv6 connections and relay them via IPv4, which is ugly, but effective.

Re: "this time it's for real"

IPv6 on the Internet and IPv4 inside

That's the future and those who gave IPv6 to the world should start working on making it reality.

Let's all face it, no sane management will spend (huge amount of) money and accept to put their legacy mission critical systems at risk just because Internet runs out of IPv4 addresses.

The happy bunch of IPv6 lovers must realize that in large enterprises there's simply no business case for such a migration. Yes, IPv6 is modern, more efficient but the potential impact on back-end systems can be huge and business continuity always comes first.

Re: IPv6 on the Internet and IPv4 inside

No, that is an absurdity. The few remaining big boys who run the network could easily do it with IPV4 between each other. Ordinary office users can mostly manage with a local net, e.g. 10.x.y.z, or IPV6 to make their system impenetrable to system engineers, hackers, ... Shopping, banking, access to el Reg, ... are all done by name, i.e. by DNS. It should be invisible to the user whether DNS goes via IPV4 or IPV6.

Selling this to management will be hard.

"Hey, can we spend lots of money to give you pretty much what you had before?"

https://www.6connect.com/resources/top-5-concerns-of-network-admins-about-migrating-to-ipv6/ has a pretty good summary of the problems in selling this upgrade.

We have systems that won't even support SMBv2 (issue at the vendor level, not at the OS) level and I consider that an easier nut to crack. We still have many servers deployed where we turned IPv6 off to stability reasons and those servers are going to be around for years.

I *will* admit that it's a lot harder to figure out IPv6 than the old reliable four octet address but maybe I am showing my age.

Re: Selling this to management will be hard.

I *will* admit that it's a lot harder to figure out IPv6 than the old reliable four octet address but maybe I am showing my age.

I dunno, I find smaller CIDR networks kind of a pain to keep track of. I mean, yeah, if you're still doing 1993-style classful addressing IPv4 is easy, but I sure can't rattle off the network and broadcast addresses for an arbitrary /27.

Re: Selling this to management will be hard.

"Hey, can we spend lots of money to give you pretty much what you had before?"

It's called maintenance. If you plan ahead, you can spend the time and money when it suits you. If you keep putting it off, you will wake up one morning and find that today is the day and this large figure is the price.

Re: Selling this to management will be hard.

"We have systems that won't even support SMBv2 (issue at the vendor level, not at the OS) level and I consider that an easier nut to crack."

We had that at my workplace. Our attitude was that EITHER we carry on running SMB1 and it is only a matter of time before something like WannaCry tanks all operations for an indefinite period at unspecified cost to the business OR we switch off the shitty hardware. Put that way, the nut almost cracked itself.

About the only one that hasn't figured out IPv6 are enterprise & SMB

The carriers have it all down pat, and 65-85% of residential users and wireless users are using IPv6 natively already. Mostly because the CPE can be remotely configured by the carriers to handle what they need.

But when techs have to go configure SMB firewall, they won't bother to learn how to do IPv6, and they only configure the IPv4 side (if their gear even supports dual stack).

Meanwhile, the residential and wireless users are driving most of the content so the content providers provide big fat pipes that can handle their needs.

Re: About the only one that hasn't figured out IPv6 are enterprise & SMB

“And then you woke up from the dream and had to face reality..”

Mobile (in Europe at least) is virtually wholly IPv6. Yes you’re often NAT’d to v4 at the carrier network edge, but that’s a necessity if you want to access a v4 only server.

It’s not particularly difficult to go dual stack, end eventually retire v4. It’s just that there’s very little incentive to do so at the moment. It needs both a carrot and a stick. As it stands there is neither, so nothing will change.

Re: About the only one that hasn't figured out IPv6 are enterprise & SMB

"(In the UK, pretty much all residental ISPs use NAT. NAT and more NAT. Because there's lots of people who understand it and, in general, not many residential people need to run servers..)"

No they don't - assuming you mean carrier grade NAT and not the use of NAT in their supplied routers.

BT experimented with it with some of their lowest end customers - IIRC people on the cheapest ADSL plan - but you could opt back out of the trial and get a real public IP again.

But Sky, TalkTalk, BT, Plusnet and Virgin still routinely assign you a good old dynamic routable IP, and those that support IPv6 will happily hand you a prefix to do what you like with. Plusnet will still give you an IPv4 block if you ask nicely.

The mobile operators on the other hand do indeed routinely use CGNAT, though there is a way for anyone to get a public IP on 3.

Re: IVP4, IVP6 Ehhh

IPv6 can be made easy to remember. If you get a /48 from your Business ISP (or /64 if we are talking residential) You would only have to remember the first 3 sections /48 ie 2001:db8:a0b:: . That is not too hard, not as nice as IPv4 but still not too bad. Then since we manage the rest of the address space(host part) just use all zeros until the last segment. So 2001:0db8:0a0b:0000:0000:0000:0000:0001

Once you get use the rules on shortening the IP's you can now express it as 2001:db8:a0b::0001

IPv6 did really baffle me but i was determined to get my head around it so spent a day just reading and reading until i got it. Biggest problem is waiting for the ISPs to support it so you can play properly.

Re: IVP4, IVP6 Ehhh

Yea! Remembering passwords is bad enough. I can remember my IPV4 IP address and a few others.

I need brain training to fix an IVP6 in my head. I think this is the main reason people hane not taken it up; reading out and IVP6 address over the phone would leed to errors. It will always have to be copy and paste and not all routers accept that or have a method to retrieve an address fro the web say. Perhaps to make it human every IPV6 address will have to have a DNS name!

IPv6 in the DMZ

You don't need to rip 'n replace all the IPv4 stuff. Most networks use the 10. 172, and 192 private IPv4 blocks internally and only ever worry about real IPv4 addresses in their DMZ.

You simply add IPv6 to those few machines in the DMZ and you are pretty much done.

I believe various network kit vendors EG: F5 supply application layer gateways/proxies in their offerings. As long as your boarder firewalls, load balancers etc can do IPv6 and of course your upstream provider you are golden :)

Re: IPv6 in the DMZ

Well actually many companies are already working on getting IPv6 in their internal networks, as those private blocks are already to small for them, but yes, if you are contempt with E-Mail and the Web, there is no need to have IPv6 on your internal network.

Incentives / Demand

Currently there is very little reason for users to demand ipv6, about the only vendor doing anything positive is microsoft who publish documentation for the xbox one which encourages you to use ipv6 for a better experience. Users are not asking for ipv6, so providers don't bother offering it.

If users were demanding ipv6, isps would start providing it or lose customers, and sites would start offering dual stack at least.

A lot of US government sites are available over ipv6, because the government demanded it... In the UK, there are no government sites available over ipv6 that i'm aware of, even the relatively new gov.uk site is ipv4-only.

Even when everything supports ipv6, many people will not bother to configure it or even explicitly disable it.

One approach would be for the likes of google and facebook (who both already fully support ipv6) to start offering new (ie beta) features over ipv6 first, and displaying warnings to users accessing services without ipv6. Having beta services available over ipv6 would result in better beta testers in the short term (people with ipv6 now are more likely to be tech savvy), and result in more users demanding ipv6 from their isp.

When YOU BOTHER to put an IPv6 address on your website, as already supported by your browsers, DNS host, webserver, content delivery network, and everything in between... THEN you can be sarcastic about a poor IPv6 deployment statistic.

It's companies like you that are precisely the problem. "We've got our IPv4, and it would 'take effort' to make everything work for IPv6, so why bother?" is the attitude you've given for... what... 8 years? Maybe more. I'll check my comment history where I have about half-a-dozen annual "Yeah, we're going to look into that next year" things.

I mean, at least you did eventually get around to SSL. But, honestly, you should restrain yourself from sarcastic IPv6 comments until you at least have an AAAA record on a beta-domain:

IPv6 is present in all modern smartphones - it's a requirement of the protocols involved.

IPv6 is present in all modern communication protocols - including DOCSIS.

IPv6 is present in all modern operating systems. It took decades to get it in there.

IPv6 is present in all modern switching/routing hardware. It took decades to get it in there.

Nobody is going to supplant IPv6.

You know what hindered it? That NONSENSE about it meaning that every device had to have a globally addressable address. That was the problem. Nobody wants their local devices to have an address like that. NAT is perfectly fine. And converting a NAT network to IPv6 consists of this... add IPv6 to the gateway device. Done. Everything else can be done at leisure, or stay IPv4 into perpetuity - nobody would ever care.

That nonsense literally held back adoption, because who the hell wants to go through every switch, router, server, client, phone, printer, etc. and give them all IPv6 addresses and then address them only by that? Nobody. Internal networks, it does not matter how they operate. That's why they're internal.

But the anti-NAT brigade set us back 10 years on IPv6 because of that.

You are not going to get anything but IPv6 for the next 20 years. Deal with it. Activating it, using it testing it, and understanding it takes about an hour tops for any IT professional, with a deployment plan then going into normal change management.

Sorry, but you can make all the excuses you like, like The Reg does. All my servers, domains, etc. are IPv6 capable and have been for years. It really doesn't take much and things like log-file analysers and custom-made sticking-plaster scripts are the things that need time to be converted. The protocol support? It's just there. In your device, in your OS, in all the things you use that OS on.

And deploying it affects nothing IPv4-wise, so there's no reason not to. Do it using ipv6.yourdomain.com and say it's a test. Google report that something approaching 10% of their traffic is IPv6 now. It's not going anywhere.

That nonsense literally held back adoption, because who the hell wants to go through every switch, router, server, client, phone, printer, etc. and give them all IPv6 addresses and then address them only by that?

Eh? I don't understand what the complaint is here.

Yeah, you plug in the printer and your router will automatically give it a global IPv6 address. Your router will also have a firewall in it, probably on by default, so there's no real security concern here.

If you don't like that global address, that's fine, because IPv6 allows multiple addresses per interface, and the fe80:: block is set aside for local use; you can set up all the private, non-routable IPv6 addresses you want there, and in the fd00:: block. Actually, given modern discovery protocols like Bonjour, your printer will probably do this automatically and broadcast its existence to your computer, so you never actually have to enter the address manually.

The only real difference here is you don't have to go through a broken NAT layer that has to keep track of every single connection, and guess when they're idle in order to clear out that memory table. The limitations of this become readily apparent when you launch BitTorrent on a NAT'd machine and everyone else's SSH connections drop because the NAT table filed up.

You've gone from "Just add an IPv6 address to the device already running NAT on the front-end of your Internet connection" which is centralised, easy to diagnose and easy to revert to "set up IPv6 local DHCP which could interfere with local services if they aren't already set up for IPv6, while making sure that all your internal access lists, subnets, etc. are also configured for IPv6, etc. etc. etc." not to mention "now you have to consider that every machine has a globally routable IP", so your firewall config just expanded from securing ONE IP to an entire subnet on a protocol you aren't familiar with.

Worrying about NAT literally held everyone back. NAT isn't broken. It works for the vast majority of the world. You know how we know? Because the vast majority of the world has a NAT router on their DSL connection. And the solution to "poor" IPv6 deployment is now likely to be carrier-grade NAT on IPv4. Ironically, the "problem" cited by everyone like yourself - spewing NAT-hate - actually CAUSES PEOPLE to stay on IPv4, which means ISPs are forced to NAT them as they can't get any more public routable IPv4 addresses.

Nobody is saying "stay like that forever", but the initial transition is literally an hour of work, for a site with an unlimited number of existing machines, with no changes to internal services whatsoever. But NAT-fear stopped people doing that, because "with IPv6 you should ditch NAT too", etc. etc. Which turns it into a 6-12 month project of testing and reconfiguration.

Your post is the epitome of demonstrating my explanation. NAT or not-NAT has nothing to do with security either. I'm not even claiming that. NAT is a "sensible default" applied to the technology that happens to translate to a "block all incoming" as the final rule by the way it works, and that should be your default rule anyway.

What you did was tell people: You're an idiot to use NAT, turn it off. When everyone is using NAT and there are no inherent problems with a proven technology that serves a practical purpose. And because you conflated that with "here, have a bunch of new-style IP addresses", nobody moved to new-style IP addresses because they were afraid they'd also have to change EVERYTHING about a technology they've been using successfully for decades.

P.S. Your IPv6 router/firewall, no matter how basic it is, still has to keep track of connections. Stateful firewall is the norm. If it's not, you should worry. And though connection tracking on IPv6 does technically take up slightly more memory... there's no way you should be hitting limits on any router advertising itself as IPv6-capable.

P.P.S. I've run Bittorrent on NAT'd connections, like I imagine the majority of the world has. It's never dropped unrelated connections. That's a factor of "crappy router" not NAT. I've literally never witnessed the symptoms you describe (but sheer bandwidth can fill up your outgoing line, which knocks your users for six if you have asymmetric connections and they can't get TCP request and acknowledgements etc. back out. Solution: QoS, not removing NAT.)

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

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

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

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

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

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

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

...your firewall config just expanded from securing ONE IP to an entire subnet on a protocol you aren't familiar with.

That doesn't actually make your firewall config more complex if the default is "block all incoming," which is what you're arguing we should use NAT to do anyway. (This is assuming a bridge-style "transparent" firewall, but those are common even on IPv4 networks at this point.)

...everyone is using NAT and there are no inherent problems with a proven technology that serves a practical purpose.

If you think NAT isn't broken, it's because you're used to the brokenness. I started using it when it was called "IP masquerading" and was an experimental Linux kernel module. It's always been hacky and buggy, people now just think the breakage is normal.

Besides the problem I noted earlier, there are others:

- Double NAT. Right now most traffic only has to traverse one layer of NAT, at the home router. It does usually work OK if you only go through one layer of it. Try to go through two -- say, you're using a mobile hotspot (NAT'd on the phone) on a mobile carrier that's also using NAT -- and things start to break. FTP simply stops working, for example, even in passive mode. As time goes on we'll be seeing more and more levels of NAT applied and more and more protocols will fall apart.

- Peer-to-peer protocols that work across the Internet but fail if you try to use them with someone on your LAN, because the IP addresses don't match up. I've played some online games that I could play with literally everyone in the world except my own family.

- Idle TCP/IP connection timeouts. After 5-10 minutes of silence, a lot of home routers will decide a TCP/IP connection is no longer needed and drop it to free up space in the NAT table. This is why SSH sessions over home routers tend to drop if you step away for a few minutes. This has resulted in a lot of hacky keepalive systems that send useless data every minute or so just to keep the channel open.

- The security disaster that is UPnP, which exists mostly to give NAT'd devices an automated way to request port forwarding.

Anyway, the fact is that IPv6 *does* support a form of NAT. It's called Network Prefix Translation. But it's not commonly implemented because it doesn't actually serve a useful purpose.

Mostly wherever you do nat, you will still have a session table in IPv6 because it's a firewall.

On home lans, the issue is rubbishy kit breaking connectivity. On enterprise lans, bonjour is not a good thing, and troubleshooting without dns is certainly a thing. That makes things harder with IPv6.

We probably need routing protocols to include not just addresses, but names, which provides local resolution with the same trust level as numerical addresses. That's not dns, that's just route mnemonics.

Then IPv6 would be a lot less scary.

We could also start demanding voip over IPv6 only, so we can blacklist those scammers.

Certainly, single LAN segment services like Bonjour are a pain in the arse in (larger) enterprise office deployments, but in the main that is down to a disconnect between logical and physical network structure and people's perceptions: why can I not see the office printer that is just across the corridor from me?

Hence to me services such as Bonjour are indicative of omissions in our network protocol suites that really need to be addressed.

Various inane ramblings.

Back in the day a certain large Telco had several Class A allocations because at the time few companies wanted one or even knew what one was. Have they been returned, or are they an appreciating asset?

Users demand V6......come on, 95% of users at least have no idea what IP stands for, what DNS is, MAC address, anything that underpins the easy names used to identify and connect to network resources. If all new installs from ISPs were IPv6 only, the end user wouldn't even notice as long as all the devices in the home were V6 capable. Even then the ISP supplied router could act as a gateway for legacy kit.

I suspect that one of the main anchors is ISPs continuing to roll out obsolete kit {cough}SH3{cough} and not wanting to replace the enormous real estate which is end user devices. The current service is "good enough". In the States, allegedly, there is a vast estate of cable routers which are old, slow and tired {know how they feel} which are also a massive cash cow. Why kill the cow that gives the golden milk?

Until major services start to fail in an obvious manner and there just aren't any more bodges (NAT, carrier grade NAT) to keep the current edifice stumbling along there is no incentive to go V6.

In fact, didn't NAT completely take the wind out of IPv6's sails by making it an interesting but non-urgent idea?

Re: It's bad to say....

I don't use them enough so always look them up.

Don't be embarrassed. You have to be regularly dealing in subnet masks to easily switch between /28 and 255.255.255.240 I've seen many network engineers with little crib sheets on the side of their monitors to cross reference between the two formats.

Re: It's bad to say....

Re: It's bad to say....

I always use a subnet calculator (http://jodies.de/ipcalc). Anything else is just going to introduce errors, because a lot of things WILL still work with an incorrect subnet.

For instance, the range I inherited was 48.0/22 (255.255.252.0) - that's a really odd range.

They were using the 48's for client DHCP initially (again - NO IDEA WHY, it's within a local range!). Then they needed more addresses, so some fool decided to do the above (which gives you the 48.49.50 and 51's). But they didn't update the subnet everywhere. So what you get are a lot of computers that can get an IP, log on, talk to the gateway, connect to the Internet, etc.

But when you try to talk to printers or, say, anything broadcast - DLNA, Chromecasts, Airplay, etc. then it doesn't work properly.

And you get things like... the 48's are filtered for web, but the rest aren't. All kinds of issues. And I guarantee you that the CCTV, access control, etc. guys will just read it as their bog-standard, "we-don't-know-why-just-type-it" 255.255.255.0 no matter how much you highlight the fact because they don't understand what a subnet is (or a VLAN or VPN or STP or anything, for that matter).

The solution, of course, is to stop faffing about and use well-known subnets. Very few places have IT big enough to worry about broadcast floods, etc. and hence want to limit their subnets down to the bare minimum necessary, but no IT department that understands the issue... just use the whole damn range and a bog-standard subnet and be done with it.

Then you have the numbering issues? Then don't. Nobody needs to care about IP addresses any more. I wouldn't be able to tell you the IP address of any of the 1000+ devices on my networks except for a) the gateway, b) the primary and secondary DNS, c) the main DC (which is actually the primary DNS anyway, but I don't actually NEED to know that, I could just use it's name!).

At home is the same. My router gives everything a name. Sure, at one point you have the IP there but it's DHCP and then you "reserve" the lease and it's permanently on that address but... more importantly... you then just give it a name. Anything that doesn't have a name will autodiscover, I assure you (e.g. Chromecasts by using the broadcast address).

And it's a damn sight easier for grandpa to remember to type in "backup" into his browser than "192.168.0.182" for his backup NAS, or cctv, or printer whatever else.

As far as I'm concerned, if I don't need to know anything more than gateway and DNS (the two things you really CAN'T refer to by a DNS name), then nobody else does either. I've memorised my VLANs and subnets on each VLAN, though. That matters. But the IP of individual machines? Nope.

And, to be honest, it REALLY shouldn't matter. Anything that needs to talk to a server should be using the name. Because then transition and retirement is much easier because you just change what the name resolves to without having to have two machines with the same IP trying to failover to each other etc. as you make the switch. Anything else should be picking up a random from DHCP, or literally a "fill-in-the-gap" on your static lists as necessary.

Too many simple problems are caused by referring to machines DIRECTLY by IP or MAC. Whereas we solved that problem for the Internet by making them all invisible behind a chosen nomenclature.

Do you know, I don't even know my outside static IP. Because it literally doesn't matter as NOWHERE is it referred to, except the DNS records of my domain. And yet I have a dozen or more outside services for hundreds of users.

Make your life simple. Choose simple, well-known subnets (the entire 10.0 range is perfectly fine for a local network, nobody will ever have that many devices that it will matter, without having a switch capable of handling such things). Name everything. Use the .1 and .2 as gateway, DNS, etc. done.

Stop doing IP addresses and use DNS

IPv6 will only start taking off when people (thats *you and me*) stop working with dumb IP addresses and start using DNS correctly. The amound of times I have to shout at people who hard-code IP's into apps, files etc gives me an ulcer. THe *point* of DNS is that we dont need to remember stupidly long IP's.

And don't get me started on the abombination that is CGNAT. WTF - its a too-small plaster for a festering boil, and I hope it breaks and takes all its apps with it.

My VPS comes with 1 IPv4 address and 30 IPv6 addresses, but yet my ISP doesn't offer IPV6 on its network even though the router does support it. I tried using a IPv6 tunnel but gave up after a couple of hours of unsuccessful messing about so currenly not using any of the 30 IPv6 addresses on my VPS.

I am sure that my ISP must be running low of IPv4 addresses since their leases are so short that if i switch off the router for 30 seconds and then back on the IP address changes.

A few years back, I was working at that company which had a whole /8...

... and a few /24 on the side (when they got them, they were actually called Class A and C).

And they were using a good dozen IP addresses out of them! Okay, maybe a couple of dozens, let's be generous.

And it got funnier: internally, they were using a different range of public addresses, not allocated to them but to another continent. Their reason: they starting using that range before RFC1918 was published, and the effort needed to change was too big.

IPv6? They'd heard of it, but rather than not planning for it, they were more like actively resisting the newfangled protocol.

Aerospace company. Not a very well known name, anyhow, let's leave it at that.

The lack of IPv4....

No one is going to move to IPv6 because of this, ISPs have plenty of IPv4 addresses, and not just that, they have the technical expertise to free many more in case they need them from their old networks.

All it does is increase the price of the commodity which has been made scarce, and prevents competition as the primary resource to start an ISP is IPv4 addresses.

Enjoy your IPv6 designed at a time where people couldn't possibly anticipate what its adoption would entail 20 years later.

Carrot will always work over stick

As one of the other commentators say, there has to be an advantage for using IPV6. Either companies have to be generous and offer freebies to IPV6 connections (i.e. Valve offering extra free game weekends over IPV6), or perhaps funding companies to disable adverts on IPV6 for now.

Go on, reg, if you actually care. Enable IPV6 on thereg, and disable adverts over it for a few weeks, or say ten minutes of no ads for IPV6 users a day. Put your money where your mouth is.

Consumers do not care about IPV6, but they won't change because their ISP doesn't support it, and their router may not either. If the ISP fixed those two problems, their operating system would very probably 'just work' (all currently supported operating systems support IPV6, and it's available to people who are still using XP..)

Re: Carrot will always work over stick

Its the business case, stupid.

Look at it from an ISPs point of view. Most of their customers have never heard of IPv6, and will require a lot of support and hand-holding as they learn the new system. All sorts of old and obsolete bits of kit will break. Some software won't work. Imagine explaining to Joe Homeworker that they need to tell their corporate IT to upgrade to IPv6 before they can start work again. There will have to be an IPv4 to IPv6 gateway for the foreseeable future, and that is going to be a big headache for all sorts of applications.

And from an ISPs point of view the current situation is actually very good for business. If you hold a block of IPv4 addresses then you own a valuable commodity. If nobody else can get them then this is a barrier to entry for competitors, which is something that all the business strategy books say is a very important thing to have. So the ISPs are highly disincentivized to migrate to IPv6.

Re: Its the business case, stupid.

It is less work than going CG-NAT. For customers, it makes no difference. That's the beauty of dual stack. I have a techie friend whose ISP switched to IPv6 and he didn't notice until I pointed it out. ISP updated the router firmware, assigned a IPv6 IPs, and his computers picked them up and started dual stacking.

We currently have a /21 public range, and we're probably using less than 5% of the address. I occasionally get companies ring asking if we have any address space for sale. I guess those calls could get more commonplace now!

I used to be with Plusnet and it seems they still don't offer it even though they rebuilt their network a year or so ago. In fact the only thing IPv6 related that happened during that rebuild is that their IPv6 test servers were turned off so those lucky few on the IPv6 trial lost it.

Meanwhile their parent company has at least been offering it for a year or so.

Just Make IP4 addresses 8bytes

IPv6 is a fail. It was compromised by special interests at standards time.

Adding a class of IPv4 with 8 bytes (IPv4+4) with 0.0.0.0.IPv4 being old IPv4 addresses.

Practically no programming changes needed. and we KNOW IPv4 works and scales!

OK let IPv6 live next to IPv4+4 and see who wins

Are the router manufacturers, MS, Apple and Google brave enough? Surely its in their interests to have a working scaling Internet. Otherwise it open up the opportunity to have a "private" proprietary Internet... Oh that's their plan!...

That's called 6to4 and already works nicely

It's for people who only have an IPv6 connection to connect to IPv4 hosts. AFAIK it uses some sort of NAT mechanism for this. It cannot be done directly as the legacy host would only get the truncated address and therefore couldn't reply.

Your suggestion would essentially be the same as IPv6, but with much shorter addresses. You'd still have all disadvantages of the switch, but without any of the advantages.

Re: Just Make IP4 addresses 8bytes

"(I was the founder of First Commercial Internet company in Europe)"

Perhaps you'd like to give your real name then. Because you seem to demonstrate a total lack of understanding of why v6 was designed in the way that it is, and the problem you'd create by introducing your proposal.

(which is to say that you'd still have to update every bit of network infrastructure anyway, as has already been largely done for v6 - but you'd get few of the benefits of v6)

The IPv6 debate is settled. It's happening whether the luddites like it or not.

Happy New Year!

Welcome to 2050 - doesn't time fly! Seems like only yesterday we were driving around in manually-controlled cars and buying things with pounds instead of cryptocredits. That was before Korean War II of course.

Anyway to business - IPV4 addresses are really really REALLY about to run out. What to do about IP V6?

Money to be made from a feudal internet

If all the clients have to connect through CGNATs this enables what the proles do to be more rigorously controlled by everyone from governments which don't like encryption to cloud service providers which will be in control of person to person exchanges and all the crap IOT stuff they flog which captures our every thought and movement. Allow ordinary users to run programs acting as servers on their own premises and all hell breaks loose with this centralised money making control model. Many if not most of the powerful players here clearly have little interest in us upgrading to IPV6.

Dual stack. Have been since I subscribed. I actually can iPV6 VPN to work from here. Although I did immediately get a call from my buddy in the security team. They didn't like that because... they had no throttling on the IPV6 connections into the VPN.

As for 6 to 4 or 4 to 6. There are a couple of different ways this can be handled, including one particularly interesting suggestion -> to allocate an IPV6 block to be the gateway to IPV4, and to have any device that had IPV6 only on one side and both stacks on the other side effectively become a NAT. DNS lookup on IPV6 only device bolts in the predicate IPV6 block on any ipv4 only return. Going 4 to 6 is somewhat harder, but there are implementations that work, although in the cases I've seen they are effectively reverse proxies.

Plenty of poorly used blocks left

I used to work at CSC, and at the time we owned 20.x. I owned 20.254. I see that they actually handed it back - good on them. But there are still other /8's around that really should be given back - such as 19, 28 and 56.net

Re: NAT Me

There's one thing that's not easy to do in IPv6: merge multiple servers providing one service each into one master address providing all of those services publicly. Instead of being able to do a simple NAT from the public master address based on port, now we get to expose all of the backend servers directly and individually. That means more DNS lookups and more delay client side.

Is there a way to do this, without proxies running on the public server, with IPv6??

Perhaps We Missed Something?

It seems that parties who promote or support going to the IPv6 platform have only focused on the exhaustion of IPv4 pool without questioning how each address has been used. On the other hand, had IPv6 been designed with compatibility to IPv4 in mind, it probably would have avoided the fundamental hurdle in rolling out the IPv6. Allow me to share a bit of our experience.

A few years ago, we accidentally ventured into studying the IPv4 address pool exhaustion challenge, perhaps due to the curiosity from our telephony background. We now have submitted a proposal, called EzIP (phonetic for Easy IPv4) to IETF:

EzIP will not only resolve IPv4 address shortage issues, but also largely mitigate cyber security vulnerabilities, plus open up new possibilities for the Internet. These should relieve the urgency to move onto the IPv6. Originally, our efforts were inspired by two regularly updated worldwide statistics:

https://ams-ix.net/technical/statistics/sflow-stats/ether-type

https://stats.labs.apnic.net/ipv6

So, we thought that the initial EzIP targets would be emerging regions and rural areas of developed countries where assignable IPv4 addresses are in short supply. A recent article about the Internet activities provided a surprising new perspective:

https://dyn.com/blog/ipv6-adoption-still-lags-in-federal-agencies/

It concluded that the IPv6 adoption even at US Federal Agencies was moving at "a glacial pace". This seems to imply that the entire market for alternatives to the IPv6 approach, such as the EzIP, is now open. The general public should be equally informed of this kind of choices, instead of being led by the existing industrial interests. Hopefully, these provide you some updated references to your analysis.

Plenty of IPv4 Space on the secondary market.

Re: Plenty of IPv4 Space on the secondary market.

Yes, the whole "IP address ownership" practice is the fundamental cause of the current situation. In the early days, they were given out to whoever asked for them. Then, there was no accountability causing the assignable address pool to exhaust while there were lots of hidden surplus (never used) address blocks. When they were offered for sale in recent years, often the purchasers turned out to be IPv6 promoters! There are also lots of addresses with expired registration. Instead of recycling them after a certain period of time (like the telephone numbers), they have been held waiting for someone to register. This gives hackers the opportunity to fake it for claiming the ownership. Meanwhile, emerging regions and rural areas of developed countries are for sure short of IP addresses. The list of surprises goes on and on, if one looks at them with conventional logic. It is really convoluted.

On the other hand, we figured out a way to relieve this shortage issue with a proposal called EzIP (phonetic for Easy IPv4) to IETF. The EzIP utilizes the original IPv4 standard RFC791 and the long-reserved yet hardly-used 240/4 address block to expand the assignable public address pool by 256M (Million) fold:

Basically, the EzIP approach will not only resolve IPv4 address shortage issues, but also largely mitigate the root cause to cyber security vulnerabilities, plus open up new possibilities for the Internet, all within the confines of the IPv4 domain. A degenerated form of the EzIP may even be deployed "stealthily" for isolated areas where needed. These should relieve the urgency to deploy the IPv6 for an appreciable length of time, as well as to discourage the IPv4 address trading activities.

Re: Plenty of IPv4 Space on the secondary market.

Our study now indicates that there is practically no more shortage of IPv4 address, let alone going to IPv6.

Since EzIP can multiply each public IPv4 address by 256M (Million) fold without affecting current equipment, this enables over 75% of nations to serve their respective countries starting from just one IPv4 address that is already assigned to that nation.

Essentially, the CIR (Country-based Internet Registry) model proposed by ITU-T utilizing IPv6 a few years ago can now be stealthily implemented under IPv4, even without forming the sixth RIR at all.