Well, I'm with Sky and have both an IPv4 and IPv6 address, but the only time I ever see IPv6 traffic is when my PC is talking directly to my router. Which kind of defeats the point, doesn't it?
We are absolutely, definitively, completely and utterly out of IPv4 addresses, warns RIPE
It happened four years ago. And again two years ago. And last year. But this time, on November 25, 2019, we have finally, finally, finally run out of IPv4 addresses. That’s according to RIPE, Europe’s regional internet registry, which announced on Monday “we made our final /22 IPv4 allocation from the last remaining addresses …
COMMENTS
-
-
-
This post has been deleted by its author
-
Tuesday 26th November 2019 07:35 GMT Anonymous Coward
re: If you don’t see traffic
going to Facebook and Google then it is a problem at your end?
Errrr Nope it isn't.
Those companies are blocked on all my systems via the hosts file and at my firewall so not even visitors can use my bandwidth to access them.
The problem isn't at my end at all. I don't use them which is a positive decision on my part.
-
Tuesday 26th November 2019 10:56 GMT tip pc
Re: re: If you don’t see traffic
"Errrr Nope it isn't.
Those companies are blocked on all my systems via the hosts file and at my firewall so not even visitors can use my bandwidth to access them.
The problem isn't at my end at all. I don't use them which is a positive decision on my part."
you've just explained that you've taken measures to stop access from your end, so specifically your problem is of your own creating and is at your end. That you don't see it as a problem is your interpretation, anyone using your systems wanting to use those services will see it as a problem.
-
Wednesday 27th November 2019 03:00 GMT gnarlymarley
Re: re: If you don’t see traffic
going to Facebook and Google then it is a problem at your end?
Why do I get the feeling that folks have forgot about the sites like yahoo and microsoft? Oh, right. Nobody uses those any more. Yahoo on IPv6 has not been very stable. On a more serious note, there are a lot of IPv6 sites out there (Including many search engines and audio and video streaming services), so if you see nothing on IPv6 then you have a setup problem. The problem also could be your network sniffer or it could be just that you are not looking at the right time. About 60% of my traffic goes over my IPv6 connection.
-
-
Tuesday 26th November 2019 10:28 GMT Len
If Sky gives his modem/router an IPv6 address and he visits an IPv6 resource like YouTube.com he should be connecting over IPv6. If he doesn't then the issue can hardly be with YouTube or Sky.
I run SixOrNot and you'd be surprised how common IPv6 is for websites. I have made IPv6 support a minimum requirement for all my sites and services years ago.
-
-
Tuesday 26th November 2019 11:10 GMT AVee
But the sites that matter lag behind:
$ host -t AAAA theregister.co.uk
theregister.co.uk has no AAAA record
They are 'working on it', like everybody else...
-
-
Tuesday 26th November 2019 09:55 GMT Tom Wood
Do Sky really give you a routable IPv6 address, or is it just a link-local one?
At work we have functioning IPV6 and traffic to sites that support it (like Google) uses v6. I used it to test my own personal websites which also work on v6.
But my ISP at home (EE) don't provide IPV6 connectivity. If they did I'd use it.
-
Tuesday 26th November 2019 13:07 GMT CrazyOldCatMan
and have both an IPv4 and IPv6 address
I'm with Zen and also have both a 16-address IPv4 block and an IPv6 allocation. And, despite reading and following all the IPv6 guides *still* can't get it to work..
(All my internal machines can see all the way to the VDSL router. Outside machines can see the VDSL IPv6 router outside address. I've fairly conclusively proved that the router is the problem but, despite following the advice from Zen and the manufacturer, still can't get it to work. So I gave up and did something more interesting - like watching mould grow on a windfall apple..)
-
Tuesday 26th November 2019 15:41 GMT bombastic bob
IPv6 not that hard... seriously
most web browsers that I am aware of have some means of resolving IPv6 before IPv4, and you can generally tell them which one to use first. I actually ran into some problems with CLOUDFLARE because they weren't handling IPv6 properly, and not that long ago. It was affecting my ability to read El Reg articles.
Aside from that, IPv6 is generally NOT hard to use on the client end. However, the one thing people aren't fully aware of (apparently) is that every IPv6 address that can be used to access 'teh intarwebs' is public. So that means windows machines MUST be properly firewalled, and I'm not talking about the "Windows Firewall" when I say that [laughing about pathetic Windows Firewall being stifled while I write this].
Seriously, though, IPv6 not that hard to set up for routers, either, assuming you're running FreeBSD or Linux. I suppose a Windows server might have problems... (but WHY would you be exposing a Windows Server directly to 'teh intarwebs' anyway? And THEN, using it as a ROUTER?)
/me uses FreeBSD as a network gateway and router, firewall, 'server in general'
-
Wednesday 27th November 2019 03:11 GMT gnarlymarley
Re: IPv6 not that hard... seriously
However, the one thing people aren't fully aware of (apparently) is that every IPv6 address that can be used to access 'teh intarwebs' is public.
Did I miss something here? RFC4193 talks about "private addresses" for IPv6, which will also include NAT66. I am sorry that you think this is the reason why you don't want to go to IPv6. I have successfully been using NAT on IPv6 for many years now. My IPv6 router is running FreeBSD. I first started with NAT66 on FreeBSD version 5.2.
So that means windows machines MUST be properly firewalled
One side note if you look further into it is your NAT router in IPv4 actually has a firewall to make the NAT work. (IPtables, PF, and IPFW are all firewalls that will redirect their packets to the NAT software. You will have one of these running on your wireless router.) So by claiming, you need a firewall to go to IPv6 is a cop out.
-
Wednesday 27th November 2019 13:06 GMT EnviableOne
Re: IPv6 not that hard... seriously
If you're using nat on the router anyway, why faf on with IPv6 inside your network.
v4 addresses are easier to deal with and there's little chance you'll use more than a 10.0.0.0/8
And dual stack on the router is not so hard ...
if people were not holding on to IPv4 unnesacarily, IPv4 would last some time yet, however, some minor tweaks to add more AS numbers would be nessacary.
a lot of IPv6 has back ported to v4 over the years, and the address space is exorbitant. I really dont see we will need to give 7 addresses to each atom of each person on earth and the space that takes up in headers is just a waste of resources and bad for the environment.
-
Wednesday 27th November 2019 13:38 GMT Nanashi
Re: IPv6 not that hard... seriously
Because you need v6 to reach v6 servers. If you don't know at least that much then you're not in a position to comment on this stuff. v6 also lets you sidestep all of the problems caused by NATing, which is another strong reason to be using it.
The energy cost of NATing (and subsequently recalculating the packet checksum) is worse for the environment than the few extra bytes in the header. The energy cost of the routers, servers and client machines involved are orders of magnitude worse however, to the point that worrying about a few bytes that are <1% of the packet size is utterly silly.
-
-
-
-
Wednesday 27th November 2019 10:32 GMT Lee D
Your phone almost certainly uses IPv6.
Your computer should be choosing to use IPv6 (but even Sky are flaky and the IPv6 support for the British ISPs is atrocious... Virgin don't even support it at all, but you'll get a "local" IPv6 address anyway).
Google say that something like 30% of all their queries come in over IPv6:
https://www.google.com/intl/en/ipv6/statistics.html
Just because YOU don't/can't use it, doesn't mean that it's not there to be used, or used by other people.
I bet that Sky have just given you a local-equivalent IPv6 (which is just your IPv4 inside a reserved area of IPv6) and you don't have a real external IPv6 address, or proper IPv6 connectivity, at all.
But I bet that your phone does and you don't even know it.
-
This post has been deleted by its author
-
-
-
-
Tuesday 26th November 2019 09:55 GMT Anonymous Coward
"And he will be dead in a ditch."
If I recall correctly, that wasn't a promise as such. I think he said "I'd rather be dead in a ditch"...
However, some might regard his commitment to lie down in front of the bulldozers at the site of Heathrow's proposed new runway as a promise, and since there aren't any yet, he still has a chance to honour that promise.... Hands up if you think he will? What, really, no-one believes him....?
-
-
-
-
Tuesday 26th November 2019 15:08 GMT Arthur the cat
a British state owned ISP will look at ipv6, decide it's too complicated, implement something more elegant that will work only because of 4 hugely kludgy routers custom built by a firm that will go out of business the day after they're delivered.
X.25, just like the original Janet. With big-endian DNS addresses that get swapped (or not, depending on an undocumented heuristic) as they go through the gateway to
realitythe rest of the net.-
Wednesday 27th November 2019 14:45 GMT Roland6
>X.25, just like the original Janet.
Well with a decent update, a CONS network service has much to offer particularly if QoS is important...
Although, a downside of X.25 was the by the byte/octet billing....
Sending 5 floppy disks (1.44MB) of data London-Montevideo over X.25 in the early 1990's, cost more than sending a courier on a first class return flight, plus overnight hotel. For some reason, we got sign off for the X.25 transfer, not for the flight...
-
-
-
-
-
-
-
-
Tuesday 26th November 2019 15:59 GMT bombastic bob
Re: The internet will be privatised
agreed. there is actually an IPv6/IPv4 gateway block that can be used to cover ALL IPv4 addresses with equivalent IPv6 ones. Why isn't THIS being used???
Sure, an IPv4-only system might have trouble routing back. For this you'd need a 'somewhat careful' NATing method, in effect the opposite of what IPv4 NAT already does, at whatever router is translating the IPv6 address space into an IPv4 one. It generally means "established connection" translations, to/from the IPv4 space, and it would really only work properly for services that aren't trying to connect out (but you would be able to connect TO them, and get responses back).
I expect this last part is the only real reason IPv4 needs to exist. but how ELSE could you map a bozillian possible IPv6 addresses down to a /32 address space?
So yeah, "said router" above would listen on the IPv6-mapped-to-IPv4 address. It would translate that incoming IPv6 packet into an IPv4 (assigning a private IPv4 to it) for the private network. The server on the private network would send traffic back, and the NAT on "said router" woudl translate it back to a public IPv6 to be transmitted the normal way. basically, "reverse NAT". And DNS for IPv6 could (in theory) be done the same way (as seen by the IPv4 side) for outbound connections, but you'd have to limit your "resolved" address space to 10/8 and 192.168/16 and so on, and expire the DNS records in a short enough time, and recycle the addresses 'as needed' to manage it.
[should be possible to "can" a solution to this with Linux or one of the BSDs, if it has not already been done]
-
Wednesday 27th November 2019 03:19 GMT gnarlymarley
Re: The internet will be privatised
agreed. there is actually an IPv6/IPv4 gateway block that can be used to cover ALL IPv4 addresses with equivalent IPv6 ones. Why isn't THIS being used???
The reason this is not being widely used is it requires DNS to synthesize the IPv6 pointers. This means it needs to be setup at your ISP's recursive name server and your ISP probably thinks it is just "too much work". Since I run my own name server and NAT setup, I can do this on my own.
-
-
-
-
-
Monday 25th November 2019 23:12 GMT IGotOut
Re: The internet will be privatised
Rubbish. Next you'll saying .org is being sold to a for profit organisation, .UK domains were sold and "given" away in the hope no one would notice the renewal of domains they didn't ask for and that ICAAN has deliberately sold a load of vanity domains knowing they can not only rake it in selling them but also when people argue over the right to own them.
-
-
Tuesday 26th November 2019 13:12 GMT CrazyOldCatMan
Re: The internet will be privatised
My boss realised we're still sat on a /28 block
We inherited (from a long-defunct parent organisation) a /22 netblock. About 4 years ago we got an ultimatum - use it or lose it..
We ended up just retaining a /24 of the original allocation - which we do actually use.
-
Tuesday 26th November 2019 16:06 GMT bombastic bob
Re: The internet will be privatised
those net blocks aren't issued by ISPs? Who issued them?
A while back this one ISP was issuing /28's for a DSL service [that I was testing at the time], instead of using PPPoE or some other means of "just having one IP address", esentially using one as a gateway, one as the actual IP address, a third for broadcast, and a fourth that was basically 'wasted'. It was an ineffective use of 4 assigned IP addresses in my opinion, but unfortunately necessary in THAT configuration.
Perhaps one of the simpler solutions here is to re-do the IP address assignments to eliminate the need for these kinds of /28 netblocks, and INSTEAD assign the addresses directly and use a different protocol to communicate the data. customer still has his fixed address(es), but fewer are actually being used, and become available for others.
(earlier comment about IPv6:IPv4 gateway probably applies)
-
Tuesday 26th November 2019 17:36 GMT Jellied Eel
Re: The internet will be privatised
A while back this one ISP was issuing /28's for a DSL service [that I was testing at the time], instead of using PPPoE or some other means of "just having one IP address", esentially using one as a gateway, one as the actual IP address, a third for broadcast, and a fourth that was basically 'wasted'. It was an ineffective use of 4 assigned IP addresses in my opinion, but unfortunately necessary in THAT configuration.
Some ISPs just want to see the blocks burn. Or went on an IP training course when instructors still waxed lyrical about Class A/B/C networks & not drugs. A /28 is 16 v4 addresses though, but there's still a suprising number of ISPs that think you must use /30 (4 IPs) on a point-to-point link.. Just in case a 2-endpoint scheme gets confused about subnet zero and broadcasts. Or perhaps they've got some legacy wiretapping kit that requires it's own address.
But re-doing addresses is far from trivial, especially given the lack of out-band connections meaning if there's an 'oops', you can lose access to the far-end device. Other tricks can work, ie using RFC1918 addressing for P2P links, especially consumer ones, but that has been frowned on by purists.
-
-
-
-
Tuesday 26th November 2019 13:40 GMT Anonymous Coward
Re: The internet will be privatised
"Lack of new addresses means existing companies find themselves sitting on an artificially scarce resource - the hyper-capitalist dream."
Are the IP addresses artificially scarce? In general, no - there was a limited number of IPv4 addresses and there is an alternative in IPv6.
Can a company easily sell off its existing IP addresses? Only if they have enough - typically you need at least a /24 provider independent address range to be able to sell it, otherwise the addresses belong to your ISP and not you.
And if the IPv4 market does take off? Suddenly the costs incurred in migrating from IPv4 to IPv6 will be dwarfed by the costs of staying on IPv4 and almost everyone will move...
I'm not sure that's the hyper-capitalist dream. More like the move from fossil fuel to electric cars, we know we have to do it, we just haven't done it yet... Because everyone loves car analogies.
-
Wednesday 27th November 2019 02:51 GMT veti
Re: The internet will be privatised
It's interesting to view "online" through the "frontier" metaphor. In the early days everything was up for grabs. As settlers moved in en mass, things became more ordered and more law got applied. And now it's getting positively crowded, and the restive folks are looking for where else to move on to.
And as with the "frontier", people who control the ultimate limiting resource will cash in. Trouble is - no-one seems entirely sure what that resource is. Is it advertising market share? IP blocks? Domain names? DNS tables? The HTML spec? You can make some kind of a case for any of these, but so far most attempts to milk rent out of each of these resources have backfired. On the Virtual Frontier, I don't think we have yet decided quite what "land" looks like.
-
-
-
Tuesday 26th November 2019 10:11 GMT Len
Re: Nope, never saw this coming
Facebook, Google, Instagram, WhatsApp and YouTube are some of the biggest stores of content in the world and all of it lives on IPv6.
Facebook has even dropped IPv4 entirely and only uses IPv6 internally. They just have a bunch of edge servers that translate to IPv4 for visitors that don't have IPv4 yet.
-
Tuesday 26th November 2019 13:31 GMT Anonymous Coward
Re: Nope, never saw this coming
> Facebook, Google, Instagram, WhatsApp and YouTube are some of the biggest stores of content in the world and all of it lives on IPv6.
> Facebook has even dropped IPv4 entirely and only uses IPv6 internally. They just have a bunch of edge servers that translate to IPv4 for visitors that don't have IPv4 yet.
Hmm, so the organisations that have the most vested interest in tracking their visitors' every move are also the ones that are most advanced in their deployment of IPv6 - a technology that allows everyone to have a unique IP address, rather than being anonymised behind carrier-grade NAT. Quelle surprise.
-
Tuesday 26th November 2019 15:16 GMT Len
Re: Nope, never saw this coming
All of them are fairly dubious players but I very much doubt IPv6 will benefit them much in their surveillance capitalism endeavours.
First of all, they have much better ways to track people than with IP addresses. IP addresses tend to change quite a lot, are tied to physical locations while people move around and people tend to switch from desktop to mobile and back all the time. IP addresses are simply not reliable enough for what the Googles of this world want.
Secondly, there is this thing called Privacy Extensions (RFC 4941) that is the default on most OS-es. That means that the IPv6 address that is visible from the outside (devices connected using IPv6 usually have multiple addresses, one for loop-local, one for the LAN, one for outside communication) changes at quite regular intervals.
This typically means that your laptop or phone behind your home router gets a different IP every day, the first part of the address stays the same, the second part varies. How big the size of the static part is compared to the variable part varies per ISP. If they give you a measly /64 a different section will change than if they give you a /56 or a /48.
Even if you were to maintain a regularly updated list of allocation sizes for every ISP in the world it would still mean that the closest you come to identifying someone is by their house, not by their machine. Just like with IPv4.
Ergo, at worst your privacy is the same under IPv6 as it was under IPv4, usually it’s considerably better.
-
Tuesday 26th November 2019 20:08 GMT Paul Crawford
Re: Nope, never saw this coming
"This typically means that your laptop or phone behind your home router gets a different IP every day, the first part of the address stays the same, the second part varies. How big the size of the static part is compared to the variable part varies per ISP. If they give you a measly /64 a different section will change than if they give you a /56 or a /48."
Given the HUGE size of IPv6 don't you think it is trivial to just bin addresses in such sized blocks? After all it is only YOU who is populating the allocated block. Yes, it might be harder to track people in your home individually (just as for IPv4 NAT) but your home use is simple to track and not per-home swapping to worry about.
-
-
-
-
Tuesday 26th November 2019 16:13 GMT bombastic bob
Re: Nope, never saw this coming
not DIRECTLY compatible you mean.
that's sort of inherent in a system where you somehow map a /64 into a /32 without some kind of "reverse NAT" in there.
And don't forget the IPv6 to IPv4 compatibility addresses... 64:ff9b::/96
-
Tuesday 26th November 2019 17:39 GMT bombastic bob
Re: Nope, never saw this coming
was thinking later.. I suppose if IPv6 blocks were /96 instead of /64 then you'd be mapping a /96 but whatever. So many IPv6's are already being generated from the subnet using MAC addresses, in addition to any others you might get automatically assigned [my windows box typically gets 4 of them, 2 private, 1 'temporary', and one actually issued by dhcpv6] that exist within a /64 subnet. Anyway, same basic idea...
I suppose issuing /96 should be the norm? That gives you 32 bits (4 bytes of the MAC) instead of 48, Or you could issue /80 to get 48 bits for the MAC. I think there's already a mechanism in place for automatic addressing to use the lower 32-bits of the MAC on a /96 (or a subnet even smaller than that).
-
-
-
Tuesday 26th November 2019 00:01 GMT Pascal Monett
"We have now run out of IPv4 addresses"
And ? Do the existing IPv4 addresses risk rusting out, or fading away ?
No, they don't. Whatever IPv4 addresses we have now are perfectly fine, thank you, and will continue to be so for millennia to come. They just might outlive the Human race, actually.
If IPv6 hadn't been artificially complicated in an engineer's fevered dream, there would have been no problem to go to IPv6. Just tack on four more bytes, and consider that the existing IPv4 space was simply 127.0.0.0.x.x.x.x and that would have worked fine and everyone would have understood.
But no, that was too simple. So they made IPv6 a monster of a thing that only network engineers can understand, and now it's languishing in adoption hell. Cry me a river.
Besides, what is RIPE crying about ? Now that IPv4 addresses no longer exist (again), new addresses will have to be IPv6, so where's the problem ? It's upgrade by restriction. RIPE should be happy.
-
-
-
Tuesday 26th November 2019 16:40 GMT Len
Re: "We have now run out of IPv4 addresses"
If you are a new ISP then that is often the only option. In practice that means DS-Lite where people get a public IPv6 plus an IPv4 behind CGNAT. It can give you some annoying compatibility issues. I know a German ISP had a lot issues with people with Playstations behind DS-Lite.
For online services it might be more difficult. Would you put a range of externally facing servers behind CGNAT?
-
-
-
-
Tuesday 26th November 2019 10:27 GMT david 12
Re: "We have now run out of IPv4 addresses"
IPV6 is, apparently, being used internally by growing ISPs, even when you don't see it at your end point.
IPV6 requires rebuilding their internal routing infrastructure, but we've already come to the point where that is cheaper than buying IPV4 on the open market.
-
Tuesday 26th November 2019 00:53 GMT Duncan Macdonald
Re: "We have now run out of IPv4 addresses"
Agreed - the people who "designed" IPv6 were the same sort of ivory tower theorists that would have thought that oblong wheels were a good idea. If IPv6 had just been an addressing extension then it would have been fully adopted years ago - instead it was polluted with a huge load of extra crap that is of no use whatsoever to 99.99% of internet users. Even the address range in IPv6 is stupid - adding 4 extra bytes would have taken the number of potential addresses to over 18 million million million - over 1 billion addresses per human being on Earth, there was no reason to expand the address range to 128 bits. (2^128 possible addresses is more than enough to allow every atom in every human on earth to have its own IPv6 address!!!)
-
Tuesday 26th November 2019 01:07 GMT Jamie Jones
Re: "We have now run out of IPv4 addresses"
The people who designed Ipv6 knew fully what the issues with Ipv4 were, and designed a system thatg could cope with them.
They spent years sorting out issues most people wouldn't have even thought of.
I agree that the address space is too large (as evidenced by them pushing /64's as a lan range for SLAAC to work) and there may be one or two things that you could argue are unnecessary, but frankly, this "ivory tower" / "loads of extra crap" bollocks that is prevalent on this site would be more suitable on a flat earth or climate change denial site.
-
Tuesday 26th November 2019 13:18 GMT CrazyOldCatMan
Re: "We have now run out of IPv4 addresses"
designed a system thatg could cope with them
While introducing a whole lot more issues - some of which don't yet have workarounds..
(It amuses me that the original IPv6 protocol didn't appear to have the capacity to be properly firewalled and that there were a whole lot of revisions produced once it started to be implemented and ran into real-world issues..)
-
Tuesday 26th November 2019 14:03 GMT sebbb
Re: "We have now run out of IPv4 addresses"
In fact sometimes reading comments on IP tech I wonder if this is a website with technical and enthusiast people or just a bunch of tired-to-chase-tech people that would rather stick with their (99.9% of the times) switchzilla gear of 1999 and have no Internet at home. I don't know, it's sad that professional IT audience doesn't understand that "keep patching it again Tony" doesn't work for long and they need to start their brains and learn something new, throw away that CCNA book. And then I wondered why half of people showing up for interviews at me had no mental flexibility to solve problems.
-
Tuesday 26th November 2019 14:51 GMT Pirate Dave
Re: "We have now run out of IPv4 addresses"
So would you have us show up at the Carrousel for a bit, or just go straight to the Soylent Green factory? We haven't been doing much the past 20 or 30 years, just keeping the wheels of Industry and Education turning, waiting for a Messiah such as yourself to come along and point out how utterly wasteful our lives have been. Thanks, mate. You've set us free now.
-
-
-
Tuesday 26th November 2019 08:28 GMT Anonymous Coward
Re: "We have now run out of IPv4 addresses"
The problem is it was 1996 and "the Internet" was still a small "nerdy" network with very few commercial companies and almost no "consumer" users. So they believed they could design a system addressing (pun intended) some of the issues of IPv4, and switch the "hole "Internet" quickly.
It never happened - in the same years the internet took off quickly with the old design, and then switching became a nightmare. And IPv6 too got old issues arose even before being really used - as it was designed for a different era.
-
-
-
Tuesday 26th November 2019 14:05 GMT Anonymous Coward
Re: "We have now run out of IPv4 addresses"
THIS! THIS! AND (MOSTLY) ONLY THIS!
Think about it this way - had they only added 1 additional address byte, we could have had 253 additional Internets. But that would suck implementing in hardware, which likes even byte boundaries. Two additional bytes would have take it up to 65,000-ish Internets, but still not optimal for hardware. 4 bytes would basically have made an Internet of Internets, and would land them squarely into 64-bit integers - nice and even and easy to do in hardware. And still relatively memorable, without needing any colon-cleansing place holders.
-
Tuesday 26th November 2019 15:41 GMT Nanashi
Re: "We have now run out of IPv4 addresses"
64 bits isn't enough. Hardware (EUI-64) addresses are 64 bits, and you need way more than 64 bits of L3 address space to handle 2^64 L2 hosts. The next power of 2 up from 64 is 128, so here we are.
You can already set most of a v6 address to zero (e.g. is 2600:: really so hard to remember?), to the point where anybody can easily make addresses that are ~64 bits of actual stuff plus ~64 bits of zeros. And they go straight into DNS so it's not like you even need to remember them anyway, but if you did then you have the 64 bit addresses you're asking for.
-
-
Wednesday 27th November 2019 09:30 GMT Nanashi
Re: @Nanashi - "We have now run out of IPv4 addresses"
I guess I didn't. But I have now, and the general point still stands: v6 routes are going to be for prefixes 64 bits or shorter. The large address size also means you have more aggregation, and thus fewer routes to look through.That should make your job of spotting anomalies easier than a shorter address length (with its corresponding higher fragmentation) would've done.
-
-
-
-
-
-
Tuesday 26th November 2019 10:23 GMT Len
Re: "We have now run out of IPv4 addresses"
Even if they had added only one byte to the IPv4 address it would still have required a complete redesign of every network stack in the world, an upgrade or replacement of every hardware network device in the world and a complete reconfiguration of allocations.
If you are going to do something as costly, time consuming and disruptive as that you might as well fix a whole bunch of other issues with IPv4 in the process. Hence IPv6 was created to tackle much more than just address space constraints.
For instance, multi-cast never really worked in IPv4 but does in IPv6. Quite useful now the internet has become a broadcast medium of choice.
-
Tuesday 26th November 2019 17:46 GMT Jellied Eel
Re: "We have now run out of IPv4 addresses"
Even if they had added only one byte to the IPv4 address it would still have required a complete redesign of every network stack in the world, an upgrade or replacement of every hardware network device in the world and a complete reconfiguration of allocations.
Which of course wasn't necessary for IPv6 given it's backward compatibility.. No, wait..
One reason was fending off the ITU, because an ability to just slap on a country code prefix would have been too easy, and too beneficial for national/international routing. Basically the IETF mostly ignored a problem the voice world had solved a century ago*
National networks would have resulted in some reconfiguration of allocations, or it'd just be left as a larger version of the old v4 'swamp' space. Changing hardware/software stacks isn't really a good reason given that had to be done anyway to support v6.
(*OK, there are some fun examples, ie Dublin's choice of numbering)
-
Tuesday 26th November 2019 21:39 GMT Len
Re: "We have now run out of IPv4 addresses"
That’s my whole point. IPv4 is not forward compatible (it was never meant to be used long term) so any minute change to it requires to overhaul the entire installed base.
If you’re overhauling the entire installed base anyway you might as well tackle much more than just a lack of address space.
-
Wednesday 27th November 2019 07:57 GMT Jellied Eel
Re: "We have now run out of IPv4 addresses"
That’s my whole point. IPv4 is not forward compatible (it was never meant to be used long term) so any minute change to it requires to overhaul the entire installed base.
Yup. It's why it's a false argument to suggest hardware and software changes prevented any alternative v6 proposals, including simpler ones like tacking on a country code and modest header changes. IPv4 headers have a version field to help.
If you’re overhauling the entire installed base anyway you might as well tackle much more than just a lack of address space.
Problem is it hasn't tackled much more very well. So yes, it's created a massive address pool, but it's done it very inefficiently and introduced new problems. So one example being the massive size of home user allocations, or just exposing local & potentially sensitive information to the world. So..
Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address.
For a 'compatibility' kludge. Prepend the useful data with a 96 bit 'version' field, which devices have to buffer, read and then act on. Which from a network perspective, is one of the biggest inefficencies given header bloat impacts throughput, or 'goodput'. A lot of user datagrams are small packets, often only a few bytes, so the ratio of header to payload is lousy. Plus the impact on hardware, especially service provider where more memory and processor is needed to buffer/queue/forward packets. Which also has a latency impact, ie having to read more bits before actioning.
Alternatives could have also simplified user adoption, so tacking on a country code or a few bytes would mean service providers could read incoming packets, read the IPv4 version field and then potentially just prepend.. So fewer changes needed at the user level. Problem is v6 is pretty much an entirely new protocol, so more resistance to change.
-
-
-
-
-
Tuesday 26th November 2019 01:00 GMT Jamie Jones
Re: "We have now run out of IPv4 addresses"
If IPv6 hadn't been artificially complicated in an engineer's fevered dream, there would have been no problem to go to IPv6. Just tack on four more bytes, and consider that the existing IPv4 space was simply 127.0.0.0.x.x.x.x and that would have worked fine and everyone would have understood.
You mean, somethung like:
Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128.
It's a shame they didn't implement such a thing.... https://www.google.com/search?q=ipv4-mapped+ipv6+address
Other than the longer IP addresses, and the fact they can be written in hex, and using NDP instead of arp, there isn't really much difference.
-
Tuesday 26th November 2019 09:48 GMT S4qFBxkFFg
Re: "We have now run out of IPv4 addresses"
"Just tack on four more bytes, and consider that the existing IPv4 space was simply 127.0.0.0.x.x.x.x"
Honest question - why can't we do this?
Obviously(?) it would only be possible to use it if everything between clients was doing the same thing, but is it possible to run your own protocol in a similar way to the fact that it's possible to run your own DNS without any reference to the root servers?
-
Tuesday 26th November 2019 10:00 GMT Tom Wood
Re: "We have now run out of IPv4 addresses"
Protocols only work if everyone wanting to use the protocol supports it.
There isn't enough space in an IPv4 packet header for any number of extra bytes of address.
Which is why IPv6 went from 32 bit addresses to 128 bit addresses - so we are not likely to ever need a longer IPv7 address...
If you want to create your own "MyIPv4+" protocol with 64 bit addresses, you could try, but it would be a lot easier just to adopt IPv6...
-
Tuesday 26th November 2019 13:14 GMT Brewster's Angle Grinder
Re: "We have now run out of IPv4 addresses"
That's what NAT does - it adds two extra bytes (the port number) to the address. That's a kludge.
We could have added an "options field" to the header with the extra address info, but that wouldn't have been backwardsly compatible. Although it probably could have been made to work and we might even have upgraded our systems by now.
-
Tuesday 26th November 2019 22:13 GMT Anonymous Coward
Re: "We have now run out of IPv4 addresses"
Fragmenting the address data in the IP header and requiring more process steps to compute the real address and route it would increases the time required to process each packet. Maybe not a big issue for the local NIC - especially the actual ones, but something more critical for core routers processing tons of packets.
Especially in the 1990s, with the processing power available at the time.
-
Wednesday 27th November 2019 15:05 GMT Roland6
Re: "We have now run out of IPv4 addresses"
>That's what NAT does - it adds two extra bytes (the port number) to the address. That's a kludge.
Not really a kludge, NAT simply treats the network behind your router as a single multi-user system (*), simple and elegant.
(*) On a multi-user system each user would use the IP address of the host, but different ports on that host. NAT just allows those users to be network attached systems rather than RS232 attached terminals.
-
-
Tuesday 26th November 2019 17:31 GMT Peter2
Re: "We have now run out of IPv4 addresses"
Honest question - why can't we do this?
Besides that nobody has programmed it, there is little practical reason. If somebody did program it up, I honestly think adoption would happen at practically breakneck speed compared to IPv6 because everybody would know and be happy with what it's doing conceptually without requiring comprehensive retraining.
In the real world nobody practically nobody actually gets this training on IPv6 and so practically nobody is willing to have anything to do with IPv6 because it has no benefit for the business, while presenting the exciting possibility of losing your job if the IPv6 design goal of "make all of my endpoints available to hackers" hasn't been adequately circumvented.
-
-
Tuesday 26th November 2019 13:14 GMT CrazyOldCatMan
Re: "We have now run out of IPv4 addresses"
IPv6 a monster of a thing that only network engineers can understand
Actually - most network engineers that I know (especially those as old as me) don't understand IPv6 either. Those that do seem to be a subset of people without much experience of old-fashioned IPv4 or fervent converts all aglow with a passion for IPv6..
-
Tuesday 26th November 2019 15:18 GMT Nanashi
Re: "We have now run out of IPv4 addresses"
If you understand v4, then you understand v6. The operating principles of the two protocols are somewhere around 90% identical.
I'm willing to bet there are a lot of network engineers that don't really understand v4 though. You only have to look around this thread at all the people who somehow think it's possible for v4 to be forwards compatible with v6...
-
Tuesday 26th November 2019 15:35 GMT Roland6
Re: "We have now run out of IPv4 addresses"
>who somehow think it's possible for v4 to be forwards compatible with v6...
Well there was a window of opportunity for this to have happened, however that was circa 1995 and was predicated on being a (relatively short) transition period after which IPv4 would be turned off, something that was possible when the main Internet infrastructure was owned and operated by academic institutions and not commercial interests.
Also that the only real difference was the length of addresses, with the leading 4 bytes effectively being padding and thus could be simply discarded or padded as necessary.
-
Wednesday 27th November 2019 09:09 GMT Nanashi
Re: "We have now run out of IPv4 addresses"
Transitioning quickly away from v4 wouldn't make v4 forwards compatible, it'd just take us off of the incompatible protocol quickly (which would avoid the problem, sure). I don't think you could've done that in 1995. Even 1985 probably would've been too late for that.
> Also that the only real difference was the length of addresses, with the leading 4 bytes effectively being padding and thus could be simply discarded or padded as necessary.
If the leading 4 bytes are padding then there's no point in them being there.
-
Wednesday 27th November 2019 15:27 GMT Roland6
Re: "We have now run out of IPv4 addresses"
>If the leading 4 bytes are padding then there's no point in them being there.
There was no point to IPv6 until now! ie. when the IPv4 address space becomes exhausted.
Back before the popularisation of the Internet to the masses in circa 1995, the academic institutions ran the show. So it was known that for the next 5+ years there would be no need to actually route outside of the IPv4 subnet of IPv6 addresses... So in this period a forced transitioned to IPv6 with everyone only using the IPv4 subnet was possible. Once the Internet went mass market and commercial entities got involved in running the backbone such a transition became much more problematic if not impossible.
>I don't think you could've done that in 1995. Even 1985 probably would've been too late for that.
I use circa, the key is some things were possible when the academic institutions ran the show and effectively could agree between themselves and tell everyone else what was going to happen and when commercial entities got involved in the mid-1990's. In any case those involved in the specification of IPv6 weren't going to be rushed into delivering 'IPv4 enlarged address space' and so the window of opportunity closed.
All of this baggage, historic design compromises just means TCP/IP is the networking world's QWERY keyboard.
-
Thursday 28th November 2019 14:52 GMT Nanashi
Re: "We have now run out of IPv4 addresses"
You talk about "academic institutions" like they're one entity, but they're not. There was nobody in a position to force them all to cooperate.
You would've had to individually convince all of them to a) rewrite all their software to handle longer addresses, b) deploy the new protocol on all of their computers and routers, c) do a coordinated drop on the old protocol.
And you want to do this early, when there were only a handful of institutions with minimal deployments as opposed to hundreds/thousands with substantial software and hardware deployments... so basically you'd need to do it at a time when v4 legitimately was sufficient for all the people involved; at a time where everybody understood it to be an experiment. You'd be doing it before work on the new protocol even began. And you'd be doing it in an environment where there were already multiple other competitors to v4 (remember that v4 only won everywhere in the late 90s; lots of people were still using IPX and god knows what else until then).
I'm honestly sceptical about your chances, there.
-
Friday 29th November 2019 13:22 GMT Roland6
Re: "We have now run out of IPv4 addresses"
>You talk about "academic institutions" like they're one entity, but they're not. There was nobody in a position to force them all to cooperate.
Back in the early 1990's the Internet was controlled by a handful of US academic institutions: they ran the DNS servers, they ran the core routers etc. everyone else just followed.
As I say there was a window, now long closed, that was recognised at the time, when people called on the IPv6 working group to deliver something usable quickly.
>remember that v4 only won everywhere in the late 90s;
TCP/IP had effectively won in 1989, it just took time for people to migrate off DECnet, SNA, OSLan, XNS, etc.
-
Friday 29th November 2019 23:00 GMT Nanashi
Re: "We have now run out of IPv4 addresses"
In the early 80s perhaps, but in the early 90s? By that stage, I think there were enough people involved that you would never have got universal agreement. You can't even get people to agree that v6 is necessary today, and v4's problems are widespread and obvious now. That was not so much the case in 1990.
I wasn't around at the time, so perhaps my idea of the size of the internet at that time is a little distorted, but I'm pretty sure it was reasonably widespread and there were far more than a handful of actors involved. I'd love to read a book that covered the history and growth of the internet in that period though, if anybody can recommend one.
-
-
-
-
-
-
-
-
-
Tuesday 26th November 2019 01:24 GMT Kevin McMurtrie
Cloudy
Now that the whole world is convinced that you should use "the cloud" there's no reason to worry about anything. "The cloud" will provide IPv4 addresses for you. Thousands of web sites can live on a single IP address as long as it's HTTP 2.0 or later.
I'm sure hosting providers like things just the way they are. Widespread adoption of IPv6, fiber links, and simplified peer-to-peer protocols might make people realize that "the cloud" is not Google, Amazon, and Microsoft. Oh, and Oracle. I don't want to get sued for forgetting them.
-
-
Tuesday 26th November 2019 13:41 GMT Marco Fontani
Re: In anticipation of the inevitable "why hasn't el reg got ip6 access" ?
That should be fine if you just add www; it will also work for "reads" of forums and search, but will not work for posting on forums (which is part of what we have yet to finish updating for full IPv6 support).
The image hosting domain, regmedia.co.uk, is also IPv6 and has been IPv6 for quite a while.
Forum posts which "fail" due to the poster having contacted forums using an IPv6 address will be
rm -f
until we can properly support IPv6. Not the user; the post. I'm not the BOFH, I don'trm -f
people.
-
-
Tuesday 26th November 2019 05:37 GMT Yes Me
Lies, damned lies, and statistics that don't lie.
But the real, real reason that people are not moving to IPv6 is because of the utterly idiotic decision by the IETF 20 years ago not to make IPv6 backwards compatible with IPv4.
When will you stop repeating this claim? IPv4 contains no provision for address extensions beyond 32 bits; it is therefore a simple logical fact that there can be no such thing as a backwards-compatible new version. You can't invent a way for a machine that believes all addresses are 32 bits long to receive or send packets with longer addresses.Do you seriously imagine that the IETF was unaware of this in 1994 when the basic IPv6 design was adopted? Do you seriously not know that since then, work on coexistence, transition and IPv4/IPv6 translation has been going on? How else do you think 25% of the Internet could be IPv6 without a catastrophe? (Incidentally, the statistics at https://www.google.com/intl/en/ipv6/statistics.html are still increasing and approaching 30%. Another fact check on your story.)
If you want to blame anybody, blame the designers of IPv4... more than 40 years ago.
-
Tuesday 26th November 2019 07:36 GMT sean.fr
Re: Lies, damned lies, and statistics that don't lie.
I remember CIDR (subnet masks beening introduced). The change did not require much relearning.
With proxy arp, the change was pretty painless.
If you ping scan the internet, much of the addresses are actually not responding,
There is massive scope to recover addresses. But this is hard work for the people holding addresses.
If IP addresses were taxed or widely traded, there would be a reason to do this hard thing.
The trading of IP addresses is possible, but there is no clear approved way to do this.
-
Tuesday 26th November 2019 09:32 GMT Anonymous Coward
Re: Lies, damned lies, and statistics that don't lie.
"If you ping scan the internet" you achieve bugger all.
I have some devices configured to respond to ping requests on the internet side, but others set to block (drop) them. Lack of ping response doesn't mean that the address isn't in use. I even have websites hosted on an address that doesn't respond to pings.
-
Tuesday 26th November 2019 18:19 GMT sean.fr
Re: Lies, damned lies, and statistics that don't lie.
While you can block ping and there could be good reasons to do so. Typically on BGP4 routers belonging to Internet providers. Mostly it is the last thing you want do. You want ping, traceroute and DNS working just to be sure your public facing services are up. Theregister.co.uk is pingable. But most addresses are not servers. They are ISP home routers with NAT.
How do you expect your ISP to provide support if you block ping?
So if 70% of addresses are not pingable, it is fair to guess 69% are not directly routable and could be reallocated.
-
Thursday 28th November 2019 08:24 GMT Kiwi
Re: Lies, damned lies, and statistics that don't lie.
Mostly it is the last thing you want do. You want ping, traceroute and DNS working just to be sure your public facing services are up.
DNS is out of my hands, handled by my domain register (and internally, the web/email/VPN servers don't actually need DNS to talk to an incoming connection, and I could probably use no DNS and just a hosts file for the things I want them connecting to as outbound (OS updates etc). I cannot recall why I disabled ping but I've been able to tell if systems are up with very simple checks - does the web browser display the expected page, or is an error thrown up? Is the error server-generated (eg 404) or browser generated ("the site at xxx.xxx is taking too long to respond")? Does the email client get emails? If not, does telnet reach the client (see - ping would tell me the router can be reached, telnet reaches past the router, past the firewalls, and into the very bowels of the email server - unless it's borked in which case ping would be worse than useless (of course I could pass ping through the router to a server, but which server?????). Likewise VPN - does the server respond? No? Then it's down or my ISP changed IP on me (another machine in the house has a connection to mega.com, and a little script on that checks the IP every few hours and updates a text file as needed - the changed file uploaded to mega and pushed through to my other device where I can log in to the registrar and change things there).
Maybe it was Gibson who taught me to kill Ping off many many many many many many years ago... Point of the waffle above though is that I don't need any of those things to tell me if the service is up or down. Knowing they're down is as easy as seeing if they respond, and only a tiny part of the problem, and I usually have a few ways to tell whether it's a machine or the whole lot.
But most addresses are not servers. They are ISP home routers with NAT.
Given the large corporate and other walled-off chunks, I'd suggest most addresses may not be such. Most in use ones however...
How do you expect your ISP to provide support if you block ping?
Also not been a problem. They have several other ways of knowing if you're connected or not without pinging your router. Hell, mine were even able to tell me the fault was a damaged cable between the cabinet and the exchange which they then got someone out to fix pronto, once they'd been notified.
The few times I've needed ISP support, they've had no issues with things not responding to ping. I've been with them for the better part of a decade so that's probably 5 support requests (3 or 4 of which were due to that faulty cable!). If my router is connected to their system, they can see it's there. If it's not connected, no amount of PING is going to tell them anything.
-
-
-
Tuesday 26th November 2019 13:22 GMT CrazyOldCatMan
Re: Lies, damned lies, and statistics that don't lie.
much of the addresses are actually not responding
Probably because (quite sensibly) they are sat behind firewalls that block specific ICMP traffic..
(If you want to do mass scanning you would be better off using nmap - but then it would take a *long* time to complete and probably get your source IP blacklisted..)
-
Wednesday 4th December 2019 01:16 GMT david 12
Re: Lies, damned lies, and statistics that don't lie.
According to the most recent figures, half of the IPV4 address values are not in use. Not attached to anything. Not responding to ping or in DNS because they aren't associated with anything.
Some of these IPV4 values could be 'easily' recovered. That is, for values of 'easily' which are much more difficult that implementing IPV6. As demonstrated by the fact that people who actually have to put money into it are adopting IPV6.
-
Friday 27th March 2020 18:01 GMT Number6
Re: Lies, damned lies, and statistics that don't lie.
I think "easily" in this context is like carrying an ice cream in a cone intact through the Sahara Desert - if you've been allocated a /24 and are using 150 of them, not necessarily consecutively, then it becomes problematic to reallocate things to free up some of them, and it's going to fragment route tables unless the excess is given to someone else at the same ISP . Even behind a NAT, I find it convenient to allocate users from one end and servers from the other.
-
-
-
-
Tuesday 26th November 2019 07:57 GMT Warm Braw
Re: Lies, damned lies, and statistics that don't lie.
It's a claim you often see from commentards, but if you're planning to write an article one would hope for a little more precision. The IETF made a lot of mistakes over IPv6, but the reason for IPv6 was precisely to anticipate the fact that once you've allocated your last IPv4 address you're snookered.
I'd say that the fundamental (in retrospect) design error was in the Unix network API: the client program has to pass an address to the connect() which means it needs to be aware of the structure of the address and explicitly convert a host name before the call. DECnet, for example, allowed you pass the host name (effectively) in the connect() equivalent, so you could in theory switch from Phase IV (16 bit addresses) to Phase V without even having to recompile your programs - the network software did the heavy lifting and chose the combination of protocols (Phase V also used a different transport, so it was like changing both IP and TCP) that would allow communication as the network transitioned.
But in fact, it wouldn't have made a huge difference. Despite it being rather easier to move to Phase V, DECnet users in fact migrated to TCP/IP because scientific institutions were starting to find that RiSC-based computers running Unix were cheaper to acquire than DEC hardware and dedicated cisco routers were cheaper and better-performing than serial cards plugged into mainframes. It came down to cost rather than technical merit.
In the end, it's the bottom line that will drive the process and it's hard enough to get people to see beyond the end of the next quarter and if another hack will postpone some transition costs, then another hack will be sought.
There are a number of things that could have been done that would have made transition easier while there were still IPv4 addresses available, but it's too late for that now. Only political and economic incentives will have any effect, but it's difficult to see how these can be sufficiently compelling: the Internet continues to work as far as most end users see it and end users will not see any improvement from IPv6 - the only thing that might have provided a marketing incentive. Unless, Google, say, makes an announcement that it's turning off its IPv4 connectivity soon, I can't see the urgency increasing.
-
Tuesday 26th November 2019 10:57 GMT Doctor Syntax
Re: Lies, damned lies, and statistics that don't lie.
IIRC DECNet relied on - or assumed - that the MAC addresses were the subset allocated to DEC. Trying to get HP-UX boxes talking to a VAX with a VAX-oriented management we had to buy a DECNet package for HP-UX. When it was installed it promptly changed the MAC (which was programmable) to look like DEC. That confused all the clients until their caches caught up.
-
Wednesday 27th November 2019 21:12 GMT fibrefool
Re: Lies, damned lies, and statistics that don't lie.
"IIRC DECNet relied on - or assumed - that the MAC addresses were the subset allocated to DEC. Trying to get HP-UX boxes talking to a VAX with a VAX-oriented management we had to buy a DECNet package for HP-UX. When it was installed it promptly changed the MAC (which was programmable) to look like DEC. That confused all the clients until their caches caught up."
I think you'll find DECnet used locally-assigned MAC addresses rather than addresses "allocated" to DEC. So that's why the MAC changed on you once you fired up DECnet. The locally-assigned MACs encoded the DECnet station ID I think - so you didn't need an ARP equivalent.
-
Thursday 28th November 2019 14:30 GMT Duncan Macdonald
Re: Lies, damned lies, and statistics that don't lie.
On ethernet, DECnet phase 4 encoded the area number (1-63) and the node within the area (1-1023) into the last 16 bits of the MAC address. This provided a means for DECnet nodes on the same ethernet to find one another without using a router. DECnet was designed to work over serial links as well as ethernet but required either a routing license (expensive) or a DECnet router (even more expensive) for a node that had more than one link. The elegant kludge of the MAC address allowed nodes with only one link (an ethernet connection) to communicate with other nodes on the same ethernet without needing a router.
-
-
-
Thursday 28th November 2019 08:28 GMT Kiwi
Re: Lies, damned lies, and statistics that don't lie.
Unless, Google, say, makes an announcement that it's turning off its IPv4 connectivity soon, I can't see the urgency increasing.
Oh you're so cruel! I glimpsed that and had a hope, for a moment, that I would be done fighting the evil scum (chances of IP6 in the remaining 30-40 expected years of my life? slim!).
Meany. Have a beer for the fantasy anyway!
-
-
-
-
Tuesday 26th November 2019 10:10 GMT simonb_london
Re: Lies, damned lies, and statistics that don't lie.
Which in turn is probably due to a simple router/WiFi arrangement being easier to configure for IPv6 than a complicated and funky corporate network with various NAT IP ranges and upstream gateways.
I've been bashing my head against just two PFSense boxes for days already and now so far I have a headache. And that's just a small outfit.
-
-
-
Tuesday 26th November 2019 08:21 GMT katrinab
Re: Lies, damned lies, and statistics that don't lie.
In 1994, LAN was a coaxial cable with terminators at each end. WAN was a telephone line with an acoustic coupler. That kit has long since gone to the museum, but IPv4 is still around.
Do you think perhaps if a 25 year old technology hasn’t been adopted yet, it probably never will?
-
Tuesday 26th November 2019 10:03 GMT Martin M
Re: Lies, damned lies, and statistics that don't lie.
Your timing's out. In 1994 I was connected from my college's computer room via 10base-T directly to university MAN. There were a few very old (probably 5-10 years) PCs in another room that used coax, but they were pretty ancient feeling and only used by a few geeks prepared to read their email via Pine at the Solaris command line. They got ripped out in 1995.
The university was connected to the JANET (UK Joint Academic Network) WAN. If I remember correctly (I may not), FTP'ing large files over this WAN link often saturated the local 10 Mb/s Ethernet connection.
Modem-wise acoustic couplers were long gone. I think I got my first modem - 2400 baud, as I was buying it from saved up pocket money - in 1991 and that connected straight to the phone line.
It took quite a while for TCP/IP to get widespread acceptance. First implementations were in 1975 and it didn't even make it into the Windows networking stack as standard until 1995. Most homes didn't have it when I left Uni in 1997, and lots of businesses were still on older technologies. So IPv6 is actually doing pretty reasonably by some measures.
-
Tuesday 26th November 2019 13:25 GMT CrazyOldCatMan
Re: Lies, damned lies, and statistics that don't lie.
I think I got my first modem - 2400 baud, as I was buying it from saved up pocket money - in 1991
Got my first one in the mid-1980s - a 1200/75 baud non-autodial modem (had to manually dial the numbers on the phone keypad then quickly put the phone down once I heard the start of the answering whistle..)
Managed to double my parents phone bills before they caught on to what I was doing.
-
Thursday 28th November 2019 08:40 GMT Kiwi
Re: Lies, damned lies, and statistics that don't lie.
Your timing's out. In 1994 I was connected from my college's computer room via 10base-T directly to university MAN.
Well.. El BOFH could give some interesting glimpses into things.. Take a look at various episodes and when they were published.
In 1998 I was still able to swap a couple of used 3com network cards with BNC connectors for cheaper-brand new RJ45-only 10meg (or 10/100?) cards, The shop did a straight no test no questions asked swap. I still have those cards today though they haven't been powered for more than 10 years). I think I saw my last Coax network in 2005 or 2006, but in '94/'95 they were very common where I had dealings. Hell, during my computing courses the institute still used them.. But then, within 3 weeks I was teaching their 'industry expert' programming tutor a few things about programming.
Icon coz my memory's a little fuzzy on things too...
-
-
Tuesday 26th November 2019 14:33 GMT theblackhand
Re: Lies, damned lies, and statistics that don't lie.
"In 1994, LAN was a coaxial cable with terminators at each end."
While coax and AUI were still around in 1994, the move to UTP and star topologies was well under way. I certainly managed to put my foot through a few ceiling tiles installing UTP between 1992 and 1994.
10BaseT was standardised in 1990 and the move away from shared network segments/hubs/repeaters was probably best signalled in 1994 when Cisco brought Kalpana. In 1995, we got fast ethernet.
-
Tuesday 26th November 2019 12:58 GMT Phil O'Sophical
Re: Lies, damned lies, and statistics that don't lie.
it is therefore a simple logical fact that there can be no such thing as a backwards-compatible new version. You can't invent a way for a machine that believes all addresses are 32 bits long to receive or send packets with longer addresses.
That's not quite correct. There's certainly no way for a machine that believes all addresses are 32 bits long to correctly interpret longer addresses, but it can certainly process them to some extent if it thinks those longer addresses are just part of the data, say in a header extension.
The trick with any backwards-compatible protocol is to create packet formats that new-version systems can fully understand, and old-version systems can at least process enough to get them to some translator or gateway system from where they can be routed. It usually looks like a horrible kludge, which is why the IETF academics ruled it out, but it need not be impossible, at least as a transition measure.
The big problem has always been that if you plug an IPv6 device onto a network that is 100% IPv4, it's just a doorstop. There's no way, not even a kludgy, inefficient, way, that an unmodified IPv4 router can get an IPv6 packet to somewhere where it can be processed correctly.
-
Tuesday 26th November 2019 13:27 GMT CrazyOldCatMan
Re: Lies, damned lies, and statistics that don't lie.
that an unmodified IPv4 router can get an IPv6 packet to somewhere where it can be processed correctly
Not *entirely* true - there are some IPv6 tunnelling products that sort-of-work. Of course, they utterly destroy any pretense of network security you might have but hey - SHINY!
-
Tuesday 26th November 2019 13:44 GMT tip pc
Re: Lies, damned lies, and statistics that don't lie.
"Not *entirely* true - there are some IPv6 tunnelling products that sort-of-work"
they work by tunnelling ipv6 over ipv4 and are something installed on the client.
you could tunnel ipv6 across ipv4 at a gateway but that would be a virtual private network.
-
-
Tuesday 26th November 2019 15:15 GMT Nanashi
Re: Lies, damned lies, and statistics that don't lie.
Actually, there's a way for a device on a v4-only network (even behind NAT) to get v6: Teredo. Also, every v4 address has a /48 of v6 space tunnelled to it via a mechanism called 6to4.
For some reason, the existence of these protocols doesn't seem to stop people from complaining that they don't exist.
-
-
Wednesday 27th November 2019 09:02 GMT Nanashi
Re: Lies, damned lies, and statistics that don't lie.
You're thinking of 6in4. (6to4 is basically an automatically-provisioned 6in4 tunnel for every v4 address.) Teredo lets a single client connect to v6 servers over a v4 network.
All of those let you do v6 over v4 infrastructure. I'm not seeing how that's not backwards compatibility.
-
-
-
-
Tuesday 26th November 2019 15:33 GMT jmch
Re: Lies, damned lies, and statistics that don't lie.
"You can't invent a way for a machine that believes all addresses are 32 bits long to receive or send packets with longer addresses."
Backward compatible means that the new version will work with the old, not that the old will work with the new
-
Tuesday 26th November 2019 15:55 GMT Nanashi
Re: Lies, damned lies, and statistics that don't lie.
Not if you believe El Reg's armchair network "engineers" it doesn't!
v6 is backwards compatible with v4, but as you say that doesn't mean that v4 is forwards compatible with v6. It also doesn't stop people from moaning constantly about how it's not backwards compatible.
-
Wednesday 27th November 2019 16:06 GMT Roland6
Re: Lies, damned lies, and statistics that don't lie.
>"You can't invent a way for a machine that believes all addresses are 32 bits long to receive or send packets with longer addresses."
Backward compatible means that the new version will work with the old, not that the old will work with the new
Compatibility depends on context and the style and level of interoperability desired. However, the emphasis on end-to-end security in recent years has made things a lot more complex than they were in the early to mid 1990's when most traffic was unencrypted.
If you sanction the use of intermediate systems/gateways it is perfectly possible to get a client system to initiate communications with a system that uses longer addresses. However, expect some things to break, just as they break today with NAT.
-
Thursday 28th November 2019 14:26 GMT Nanashi
Re: Lies, damned lies, and statistics that don't lie.
Sure, you can use a proxy, but it's pretty obvious that just about everybody wants direct network connections rather than proxies, because otherwise they wouldn't be complaining.
...or who am I kidding. People frequently complain that v6 can't do X even though it can. They'd happily complain forever that "v6 can't be proxied" even when presented with evidence that it can be, based on the fact that they do that with most of v6's other capabilities. But what can I do about that?
-
-
-
-
Tuesday 26th November 2019 07:57 GMT Herby
This just in.....IETF announces IPv7
Oh, it will be compatible with IPv4 as a subset. It adds a byte in the middle, so 127.3.2.1 becomes 127.0.3.2.1 if routed. Lots more addresses only TWO more bytes in the header. Easy for things to translate as needed. Oh, 256 times more addresses. Sorry not enough for every grain of sand on earth, but it should last a few years.
Well, we can always hope. Wishful thinking.
-
Tuesday 26th November 2019 08:07 GMT Warm Braw
Re: This just in.....IETF announces IPv7
How would that be compatible with IPv4? How does an IPv4 host - which by definition has 32 bits of address - communicate with a host that has 40? Where do the extra bits go? You've made precisely the same mistake as the author of the article. Suppose addresses had only 3 bits - it's fine when you have 8 hosts (ignoring localhost and broadcast), but suppose you need to go up to 16 and the new hosts have 4-bit addresses. The old hosts need to indicate which of the 16 total hosts they want to talk to, but they have only 3 bits with which to do it. It doesn't matter what other details of the protocol may have changed, add one single bit to an address field and you cut half the potential address space off from your old hosts. IPv6 was predicated on a transition occurring before that problem arose and it's not the fault of the IETF (there are plenty, but this isn't one) that hasn't happened.
-
Tuesday 26th November 2019 08:39 GMT Dave K
Re: This just in.....IETF announces IPv7
I would have expected IP6 to have included native support for IPv4 addressing so you dont need two separate protocols. Try an IPv6 connection, if that fails, fall back to compatibility mode. Problem is that the current system involves two separate protocols, and as long as IPv4 still works, plenty of companies can't see the point of implementing a second protocol. You double the hassle and attack vector for little benefit. Allowing IPv6 to support v4 via a compatibility mode would have helped here.
-
Tuesday 26th November 2019 15:00 GMT Nanashi
Re: This just in.....IETF announces IPv7
This is exactly what v6 does. The "compatibility mode" is v4. What else were you expecting it to be?
And in fact v6 has NAT64, which basically places the v4 address space into a v6 /96 so that v6-only clients can talk to v4-only servers. Is that somehow not good enough for you?
-
Wednesday 27th November 2019 10:04 GMT Dave K
Re: This just in.....IETF announces IPv7
Not a separate protocol for starters. At the moment, you have the choice of IPv6, IPv4 or both. Imagine if IPv6 included IPv4 functionality, such that OS vendors etc. could drop IPv4 as a separate protocol. It would have helped drive IPv6 adoption as you'd have to enable it to get connectivity. Not saying it is a perfect solution, but the current situation is that IPv6 is too easy to just disable/ignore.
-
-
-
-
-
Tuesday 26th November 2019 08:21 GMT Anonymous Coward
compatibility
"But the real, real reason that people are not moving to IPv6 is because of the utterly idiotic decision by the IETF 20 years ago not to make IPv6 backwards compatible with IPv4. We still haven’t seen or read a good explanation for what that decision was made - presumably because everyone involved is ashamed of themselves and doesn’t want to talk about it."
While it is true there was no compatibility for many years, and surely every suspect is highly ashamed about it, I think (can't put my hand onto the RFC itself) there is a compatibility now, aka, IPV4 addresses embedded into IPV6 packets.
-
Tuesday 26th November 2019 08:45 GMT Joseba4242
Vicious Circle
As long as significant number of end user connections are IPv4 only, pretty much all services will be available on IPv4.
As long as no significant services are IPv6-only, significant numbers of ISPs and end users won't have IPv6.
It's a vicious circle. Increased adoption does not help this at all. Whether 20% or 90% of traffic is IPv6, still 100% of end users and 100% of services require IPv4 connectivity.
It's not clear how to break out of this. The complaint that IPv6 isn't compatible with IPv4 is old and easy to make but at the same time no "compatible" proposals have been made that work and address the key problems.
-
Tuesday 26th November 2019 09:05 GMT Anonymous Coward
Re: Vicious Circle
Many ISPs doesn't bother to offer IPv6 - it will make their network configuration and management more complex, end-user support more expensive, they can make some money renting "fixed" IPv4 addresses, and they would need to buy IPv6 address space as well.
Here only two main ISPs offer IPv6, and one only in an "experimental" mode (you can use it, but don't bother them with issues). Even some late comer are forced to CG-NAT and then let you pay a premium for a "real" IP address - while not offering IPv6 at all.
Some smaller ISPs do, but you may get only a /64 prefix (which makes using VLANs an issue).
-
Tuesday 26th November 2019 12:38 GMT pmb00cs
Re: Vicious Circle
"but you may get only a /64 prefix"
What's wrong with a /64 prefix?
How many devices/subnets are you planning to set up that a /64 is insufficient for your needs?
"(which makes using VLANs an issue)"
How exactly? VLAN tags are entirely different to subnet masks. Also once you have a prefix you are free to split that prefix however you see fit, 2 subnets with /65 prefixes? or 4Billion subnets with /96 prefixes?
-
Tuesday 26th November 2019 15:11 GMT Anonymous Coward
"What's wrong with a /64 prefix?"
IPv6 expects you use bits of the prefix for subnetting - not bits of the interface identifier. Up to 16 bits of the prefix could be a subnet identifier.
You're right plain VLANs won't be an issue - I should have written subnets, not VLANs, but it's quite common to assign VLANs to subnets to isolate traffic yet being able to route traffic across subnets when needed.
Trying to use bits of the interface identifier to create subnet could create issues - not all devices may understand it when routing, and could be difficult to assign them but manually, many automatic ways to assign an IPv6 address may not let you assign some fixed bits to the interface identifier.
That's a clear difference and departure from IPv4 where you are much freer.
That's why the recommended smaller prefix assignment should be /56, not /64, even if some SOHO sites could use something smaller than a /56.
-
Tuesday 26th November 2019 22:32 GMT pmb00cs
Re: "What's wrong with a /64 prefix?"
Yes, the default behaviour using SLAAC is to use the MAC address (plus 16 other bits) to form the Host address, but there are privacy concerns with that, a device can be tracked across networks that way. However SLAAC isn't the only way to issue IPv6 addresses, and not all of them are tied to a 64 bit host address. So the argument against giving a /64 to a standard ISP connection of "but you can't do a none standard network partition without also using a none standard IP address assignment scheme" strikes me as poor. Most users are not going to subnet their network, and frankly those that are probably don't want to advertise their unique device identifiers to the internet. If for some reason you absolutely cannot have a shorter than 64 bit host address, and you need to subnet your network, you can subnet on link local addresses, and do some form of NAT (Oh I know, NAT is evil, but it is a possibility).
Also a /64 for a single connection is still, even if I accept that subnetting becomes impossible on that network, significantly better than what most of us find ourselves with on IPv4, a single IP address, and NAT, and in some cases that single IP address is non-routable as the connection is behind CGNAT.
PS: Yes I do know that IPv6 specifies giving multiple IP addresses to individual network interfaces, such that a laptop could have many IPv6 addresses, some for WiFi, some for cabled ethernet, some for Bluetooth, etc, even if you do take your /64 and sub split into 4 billion /96 subnets, using for example DHCPv6, each of those has 4 billion addresses going spare.
So I ask again, what are you planning to do that a /64 is insufficient for your needs?
-
Wednesday 27th November 2019 08:55 GMT Nanashi
Re: "What's wrong with a /64 prefix?"
SLAAC on two networks, e.g. main plus guest or IoT networks. You don't need any more justification than that.
/56 isn't a big allocation. In terms of fraction of the total available space, it's 1/256th of a single TCP port of a single v4 IP. Nobody should need to deal with an allocation size smaller than that, and the question of whether a /64 is sufficient or not should never need to be asked by anybody.
-
Wednesday 27th November 2019 10:24 GMT pmb00cs
Re: "What's wrong with a /64 prefix?"
I'm not suggesting that ISPs shouldn't be offering /56 allocations, my issue is with the implication that getting a /64 is somehow problematic compared to the status quo of IPv4 that exists for most users.
Anything you can do on a domestic ISP connection with a single IPv4 address you can do with an IPv6 /64 allocation, and the latter case is, in my opinion, vastly superior than the former.
-
Wednesday 27th November 2019 14:22 GMT Nanashi
Re: "What's wrong with a /64 prefix?"
Compared to the status quo of v4, sure, a single /64 is better than no v6. But we can aim a little higher than that. There are things you can't do with a single /64 but you can do with a /56, which is why you shouldn't be getting a single /64.
(Or to be more precise, it's why a single /64 shouldn't be the max you can get. If a user only requests one /64 then go ahead and only give them that much, but they should be able to get more without hassle if they want to.)
-
-
-
Monday 2nd December 2019 11:18 GMT Anonymous Coward
"So I ask again, what are you planning to do that a /64 is insufficient for your needs?"
At home I have three subnets that can access the internet. One is the main one, one is for IoT devices, the third one is for guests. Plus there are other three internal subnets. All with different firewall rules.
I wouldn't be able to separate such traffic easily with a /64 - without being forced to use some hacks that may not be supported by all devices. My pfSense 2.4 doesn't allow for full NAT on IPv6, for example, only network prefix translations. I also guess my two L3 switches won't understand prefixes larger than /64, making routing across some subnets no longer working.
Moreover, recent implementations of IPv6 will no longer use the plan MAC address to generate an IP, so you're not leaking that data.
Anyway if you do 1:1 NAT on the router, and yo don't "rotate" the mappings you're still giving away perfectly valid unique identifiers. If you're using a smaller pool of IPv6 addresses for NAT you're back to the issues you have with IPv4 (static ports mappings of UPnP)
-
-
-
-
Wednesday 27th November 2019 07:41 GMT sean.fr
Re: Vicious Circle
Pretty much all home users do not need a unique IPv4 routable address. Inside your on 192 or 172 or 10 NATed addresses.
It is business that need IP4v addreses. So if ISP do some NAT magic, based on DNS, they can still sell into the home market. As they renew ISP home boxes to existing homes, they can recover addresses v4 addresses to their business users.
-
Thursday 28th November 2019 09:01 GMT Kiwi
Re: Vicious Circle
It is business that need IP4v addreses. So if ISP do some NAT magic, based on DNS, they can still sell into the home market. As they renew ISP home boxes to existing homes, they can recover addresses v4 addresses to their business users.
Even further, it's only those businesses who want to run their own on-prem publicly accessible services.
Most businesses I know use internet for email, maybe some VOIP, and maybe viewing relevant web sites (most of what I know are small shops with less than 5 staff, often less than 2). Most are happy with hosted sites (places like wix[sorry for the swearing] etc).
The existence of free hosts should help cut IP needs for businesses considerably.
-
-
-
-
-
Tuesday 26th November 2019 16:02 GMT Roland6
Re: Here is your new scam!
>IPv6 to IPv4 adapters!
Given how many client systems have included an IPv6 stack for circa two decades, the problem is slightly different, namely getting ISP's to both support IPv6 and supply routers with IPv6 enabled.
In fact we are probably at a point where an ISP could supply a IPv6 WAN only router and many consumers would not experience any issues. This would largely remove the need for domestic IPv4 address allocations (could let people have one at extra cost if they discover they have devices that only support IPv4 for Internet access).
-
-
Tuesday 26th November 2019 09:05 GMT Pascal Monett
What should have happened with IPv6
IPv6 should have been an ISP thing. ISPs would transition to IPv6, and each ISP would have a full IPv4 environment for connecting their customers. Packets moving from one ISP to another would be bridged with an IPv6 packet (or tunneled, whatever).
If they had done that, IPv6 would have been adopted long ago, in the backend, and us users wouldn't even be talking about it.
Instead, we have the mess we're trudging through today, with some saying IPv6 is not very different from IPv4. Yeah, except that most everyone is still using IPv4, so IPv6 is neither easy nor convenient enough to adapt to at this point in time. And, since IPv4 addresses are not going anywhere any time soon, I've got the feeling that this kind of conversation will still be taking place in thirty years.
-
Tuesday 26th November 2019 10:36 GMT Charlie Clark
Re: What should have happened with IPv6
This is what many mobile networks have already done as they control so much of the configuration (especially routerS) and would otherwise have to pay more for the addresses. But, otherwise, ISPs counter by saying that as there is no need nor requirement for them to do so and it costs money to change, they won't do it yet.
This could be fixed easily by national regulators… But that would also have involved forcing operating systems and consumer hardware to do IPv6 properly, which was unlikely to happen due the fact that the US still has more than enough IPv4 addresses.
As it stands 24% of all network traffic is very impressive compared to a few years ago. A breakdown by region and mobile or fixed line would probably also show that some countries are pretty much IPv6 already.
-
-
Tuesday 26th November 2019 14:03 GMT Charlie Clark
Re: What should have happened with IPv6
You still need some kind of agreement for an interconnect and it would have been no problem with requiring telcos (the majority of the ISPs) to provide IPv6 for the interconnects. They could stay IPv4 internally, though probably wouldn't want to unless they have loads of customers on very old kit that they have no control over.
Germany had a sort of plan, which probably explains why it's take up (according to Google) is at nearly 45% compared with < 25% in the UK, well behind even India.
-
-
-
-
Saturday 30th November 2019 10:29 GMT sean.fr
Re: The good news is that this crimps IoT deployment
The internet of trash. Has internet connectivity, and security is not a selling point, Unlikely your heating or front door camera is going to stay patched and secure for long. It may be used against you or against other eg in DDos. Best to keep that off your private IPv4 subnet 192.168 or 172.16 or 10 networks.
-
-
Tuesday 26th November 2019 19:55 GMT Boothy
Re: Most email services do not support IPv6
hotmail.com and outlook.com both ping as v4 addresses as you state, but both also redirect me (when put into a browser) to outlook.live.com.
If I ping outlook.live.com I get a v6 address, and not v4 (unless I force v4 of course).
me.com was v4 only thought.
For ref, this is in the UK, on a home Sky broadband.
-
Tuesday 26th November 2019 10:43 GMT pakman
How I Learned to Stop Worrying and Love IPv6
Hands up if you remember this Verity Stob classic: https://www.theregister.co.uk/2012/08/21/verity_stob_ipv6/
-
-
-
-
Tuesday 26th November 2019 15:02 GMT Anonymous Coward
Re: We can take entire 24 ranges back
HP and IBM appear to have prepared to start giving address space back based on entries in ARIN but I can see any /16 or shorter examples where it has been reallocated. My guess is that this is preparation for selling small address blocks if the price justifies it.
Apple have yet to pass control back to a registry.
-
-
Tuesday 26th November 2019 14:53 GMT theblackhand
Re: We can take entire 24 ranges back
Assuming Wiki is up-to-date, there aren't many remaining /8 address block owners that aren't ISP's:
17.0.0.0/8 Apple Inc. 1992-07 1990-04-16
19.0.0.0/8 Ford Motor Company 1995-05 1988-06-15
44.0.0.0/8 Amateur Radio Digital Communications 1992-07 1992-07-01 44.192/10 sold to Amazon on 2019-07-18
48.0.0.0/8 Prudential Securities Inc. 1995-05 1990-12-07 The Prudential Insurance Company of America.
56.0.0.0/8 US Postal Service 1994-06 1992-11-02
The DoD has 13 /8's all to itself although it might be hard to pry them loose.
(from https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks)
-
Tuesday 26th November 2019 18:01 GMT Jellied Eel
Re: We can take entire 24 ranges back
Assuming Wiki is up-to-date, there aren't many remaining /8 address block owners that aren't ISP's:
Pfft.. /8's are for wimps! So there's 224.0.0.0/3, split into 224.0.0.0/4 and lightly used for multicasting, and then 240.0.0.0/4. That one was 'reserved for future use', and the future could be now. But IANA says 'NO!' and thou shalt move to IPv6.
But that's.. controversial, especially given there's probably a lot of 224/4 that could be recovered and reassigned.
-
Saturday 30th November 2019 11:43 GMT sean.fr
multicasting old school.
Multicasting is good for "broadcasting like services" to lots of watchers, eg London traffic cams and Empire State. The multicast enabled routers duplicate on demand. Which makes a bandwidth billing issue. But there are better ways to do this now. A single PC NIC is Gigabit and can feed 1000 whatchers. Netflix, Youtube look at traffic flows and put servers where they need to in your IPS racks. They cache near to customer what they can. They duplicate flows where they need to.
Multicast is still good for CCTV but off the internet.
-
-
-
-
Tuesday 26th November 2019 13:37 GMT tip pc
no one bothering to no enquiry as to why organisations are reluctant to go ipv6
there are some terrible privacy issues with IPv6, hackers will have a field day exfiltrating data, sys admins will struggle to identify (hard enough with ipv4) systems that shouldn't be doing bad things etc.
If IPv6 had embraced NAT at the start it would have gained much earlier adoption. While NAT is not needed in IPv6 some of us like the inherent security offered with NAT. I can hide tens of thousands of rfc 1918 (private IP's) IP's behind a handful of public IP's which are easy to look for, filter and monitor. with IPv6 Its possible & encouraged to use publicly addressable IP's internally. That way of thinking was seen as a huge drawback of ipv4 & nat was seen as a fudge to enable connectivity but had the extension of being a simple cheap no skill required way of securing systems especially domestic systems who's owners had no need to understand how it worked.
Embrace NAT, let the uninitiated hide behind a gateway, save ISP's costs/bandwidth from zombied customers machines etc etc etc.
The very real security shortcomings of IPv6 needs to be overcome before mass adoption, else we will all have to purchase expensive gateways with expensive security contracts to ensure our homes are secure from hackers & privacy invading internet sites.
-
Tuesday 26th November 2019 14:12 GMT katrinab
Re: no one bothering to no enquiry as to why organisations are reluctant to go ipv6
Another thing, if you change ISPs, as I did recently; on IPV4, the only thing I needed to change was the A record for gateway.mydomain. On IPV6, I would have got a completely different subnet, and I would have had to change everything, all the local devices, all the server virtual machines, all the DNS entries for everything, all the printer settings on anything that can access a printer, email settings for my scanner, firewall rules, and loads of other stuff.
-
Tuesday 26th November 2019 20:43 GMT Anonymous Coward
"if you change ISPs, as I did recently; on IPV4, the only thing"
Renumbering is a well known issue:
https://tools.ietf.org/html/rfc5887
https://tools.ietf.org/html/rfc6879
https://tools.ietf.org/html/rfc7010
You can try to obtain a Provider-independent address space - but it's not for small users, I'm afraid.
With IPv6 is highly advisable to automate address assignments as much as possible, and use FQDNs as well. It's also better to "parametrize" addresses in rules, etc. to change them in a single place when needed.
This is another aspect that probably looked simple in 1996 with simpler, flatter, networks, few server and clients configured by SLAAC - not so much later as network complexity grew.
-
-
Wednesday 27th November 2019 03:33 GMT gnarlymarley
Re: no one bothering to no enquiry as to why organisations are reluctant to go ipv6
If IPv6 had embraced NAT at the start it would have gained much earlier adoption. While NAT is not needed in IPv6 some of us like the inherent security offered with NAT. I can hide tens of thousands of rfc 1918 (private IP's) IP's behind a handful of public IP's which are easy to look for, filter and monitor. with IPv6 Its possible & encouraged to use publicly addressable IP's internally. That way of thinking was seen as a huge drawback of ipv4 & nat was seen as a fudge to enable connectivity but had the extension of being a simple cheap no skill required way of securing systems especially domestic systems who's owners had no need to understand how it worked.
Embrace NAT, let the uninitiated hide behind a gateway, save ISP's costs/bandwidth from zombied customers machines etc etc etc.
Ummm. Are you trying to say that me using NAT66 on IPv6 for about a decade is not possible? Do you have something against RFC4193 addresses in IPv6? Just because they have had RFC1918 equivalents on IPv6 since the early 2000s, doesn't mean we can diss IPv6 just because it does fully support NAT.
-
Wednesday 27th November 2019 16:30 GMT Roland6
Re: no one bothering to no enquiry as to why organisations are reluctant to go ipv6
>doesn't mean we can diss IPv6 just because it does fully support NAT.
Well RFC-6296 (2011) is still listed as being "experimental" and the IPv6 purists still publicly deriding NAT - wanting the Internet to work the way they thing it should "the right way" and not the way network tech's want and need it to work in the real world.
-
-
-
Tuesday 26th November 2019 13:54 GMT tip pc
why did IPv6 use 128bit Hex?
My guess is that it was trying to kludge together MAC addressing & IP addressing in 1 scheme, perhaps envisaging a world where the IP would just live in the ethernet frame, any machine could talk to any machine a full marriage of IP & Ethernet with a promise of efficiency, extensibility. Certainly the early implementations mandated the MAC address making up the end part of the IP until it was pointed out it was a privacy and security issue and was then made optional.
If they where creating IPv6 today it would look very very different to what we currently have.
-
Tuesday 26th November 2019 20:09 GMT Anonymous Coward
Re: why did IPv6 use 128bit Hex?
Well, in the original implementation the interface ID contains the MAC address. Now this is regarded not nice because it does leak a (mostly) unique identifier of the device which can be tracked across different networks. Probably that was not thought a big issue in 1996 when even usable laptops were a kind of novelty.
-
Tuesday 26th November 2019 21:29 GMT Jellied Eel
Re: why did IPv6 use 128bit Hex?
Actually it was desireable. Well, desireable by some, mostly the mobile industry. Along with the idea that exposing MAC addresses. So mobile wanted a zillion IP addresses because every handset (plus IoT) would need at least 4096 globally routable & unique IPs. To go with phone numbers, IMEIs, IMSIs and even the good'ol MAC address.. Or other hardware identifiers.
ISPs kinda scratched their heads wondering what benefit there'd be in MAC tagging, other than user tracking. Much the same with the mobile's argument, especially when the operators twigged that having a globally routable IP address on a phone meant users could potentially escape their walled gardens and do things the operators couldn't charge for.
But basically a protocol designed by committee with a bunch of different and competing interests & creating headaches for the ops community who had to figure out the security implications.
-
Wednesday 27th November 2019 09:18 GMT Nanashi
Re: why did IPv6 use 128bit Hex?
Your post seems to be mostly made up.
Every handset would need 4,096 IPs? No, I've never heard that. IPs would be used like IMEIs/IMSIs/MACs? No, that's specifically not what IPs are used for (use a UUID if you want a 128-bit identifier, but it won't work as an IP). ISPs wanted user tracking from MACs in v6 addresses? No, they already know who their users are, either from the prefix or the connection port. Global address on phone lets you escape their walled garden? No, they can still firewall you or do whatever they could do with RFC1918 addresses, public addressing doesn't change one bit of that.
Designed by committee? It has roughly the same design as v4. Ops community has to work out the security implications? Most of them are the same as v4, and for the ones that are different... well, it's your job to deal with them.
-
Wednesday 27th November 2019 17:14 GMT Roland6
Re: why did IPv6 use 128bit Hex?
>IPs would be used like IMEIs/IMSIs/MACs? No, that's specifically not what IPs are used for
There is a important distinction between what IPv6 addresses are now being used for and the ideas that were swimming around in the 90's when it was envisaged that IPv6 addresses could be static and thus could embed IMEI's, MAC addresses, phone numbers etc. to allow all of these to be used in IP communications. It is only a small step to say that the IMEI, MAC etc are just short forms of unique IPv6 addresses and thus say IPv6 addresses could be used as IMEI, MAC etc.
-
Monday 2nd December 2019 10:59 GMT Anonymous Coward
Re: why did IPv6 use 128bit Hex?
IPv6 embedded the MAC address only in the device/host part of the address (the lower 64 bit). The other part, the prefix (network) part of the address can't be embedded - otherwise routing becomes a nightmare - and quite impossible, as routing tables would become ginormous and would need to change as a device moves to a different network - less common in 1996, quite common in 2019 with all the mobile stuff.
-
Monday 2nd December 2019 21:52 GMT Roland6
Re: why did IPv6 use 128bit Hex?
>IPv6 embedded the MAC address only in the device/host part of the address (the lower 64 bit).
Yes, one of the ideas floated in the 90's was that the lower 64 bit was sufficiently large for every device to have their own unique (and burnt in) static address - and given the size of the IPv6 address space why would you want to bother with assigning your own lower 64 bit address components...
-
-
-
-
-
-
Tuesday 26th November 2019 14:10 GMT Anonymous Coward
I believe there are several reasons why IPv4 refuses to die and why people are hesistant to change to IPv6.
1) Most (older) software/games are either not compatible with IPv6 or still expects an IPv4 address to work.
2) Easier for remember/type a non-DNS/hostname-based adresses. I think the average person is more likely to remember a 192.168.X.X address than the IPv6 equivalent.
3) Familiarity and customer expectations, people expects their software to use IPv4 addesses because that's how it's always been.
The hardware/software companies knows this and thus uses IPv4 by default.
4) Lack of backward compatibility in general as previously mentioned in the comments.
-
-
-
Tuesday 26th November 2019 15:12 GMT Nanashi
Re: This is probably a dumb question...
Indeed.
v6 is already backwards compatible. Perhaps you wanted v4 to be forwards compatible, but we can't create an IPv7 which v4 is forwards compatible with for the same reason that we didn't create an IPv6 that it's forwards compatible with: because v4 isn't forwards compatible with any address size that's bigger than 32 bits.
If you could fix that problem, then we wouldn't need an IPv7. You could just make v4 be forwards compatible with v6.
-
-
-
Tuesday 26th November 2019 14:47 GMT Anonymous Coward
Following Kieren's link, one can find Google's stats of IPv6 users, which tells a whole different story than the doom'n'gloom he's peddling, with a rather steady growth:
https://www.google.com/intl/en/ipv6/statistics.html
"the utterly idiotic decision by the IETF 20 years ago not to make IPv6 backwards compatible with IPv4. We still haven’t seen or read a good explanation for what that decision was made"
Isn't that akin to demanding an explanation of why motorcars were not made backward compatible with horses? That seems like something that could explain the lack of an answer.
-
Tuesday 26th November 2019 16:06 GMT Anonymous Coward
Here's some IPv4 addresses for RIPE
"...will continue to recover... from organizations that have gone out of business or are closed, or from networks that return addresses they no longer need."
They should have a look at 163.165.0.0/16
I'm not sure that a Belgian catering company ever needed three quarters of that space (especially as they haven't used it in 20 years) nor that a European weather satellite organisation needs a quarter of it.
-
Tuesday 26th November 2019 16:44 GMT Big_Boomer
Who cares?
If you need a new public facing IP address then from now on you get IPv6 and no choice in the matter. IPv6 works, is demonstrably in use by millions of people and to my knowledge nobody has yet died due to not being able to get an IPv4 address. The ONLY reason why people are wary of IPv6 is that it's over complicated. Luckily, unless you really want to do something hyper-complicated (yes, it's you, the weirdos who just HAVE to subnet the crap out of everything, even when it's totally unnecessary) it just works most of the time.
I could care less what my public IP address is. Internally I use IPv4 but after the NAT my router can use whatever it damned well pleases. Eventually when some of my older kit finally dies, I may even go IPv6 inside the NAT.
-
Tuesday 26th November 2019 16:53 GMT Anonymous Coward
Bullshit. There are enough IPv4 Address for another 100+ years.
Just because there are no longer any free, unallocated IPv4s doesn't mean that we are out of them. What it means is that IPv4 addresses are now a scarce, "rivalrous" resource. So fucking what? We have an entire field of study dedicated to dealing with rivalrous resources. It's called "economics." Look it up.
So IPv4s will now have price tags attached to them. As demand increases, that price will go up. As the price goes up, people will find ways to use them more efficiently. More carrier NAT, more consolidation of servers behind reverse proxies, etc. And as that becomes more obnoxious, expensive, and inconvenient, those factors will move people to IPv6. And then IPv4 utilization will decrease, the price will eventually drop to zero, few people will notice, and nobody will care. Enough with the pearl-clutching already. The problem will take care of itself just fine.
And now I'll get flamed to a crisp, but I'm still right.
-
Tuesday 26th November 2019 17:14 GMT jason_derp
Re: Bullshit. There are enough IPv4 Address for another 100+ years.
That is all very well and true, but it's also very counter to the philosophy of the internet. Most proponents of internet use and it's position in society as an overall good usually emphasize the fact that there's no NEED for expensive "rivalrous resources". It should all be cheap and intangible, made out of thin air and available to the maximum number of people to foster the development and easy transferance of ideas and thoughts. It'd be like arguing that you shouldn't be able to print new books cheaply because we've already used up all the moveable type.
Also, populations increase exponentially, not linearly (Thanos is shit at math), so I'm not sure how you figure over a hundred years is a reasonable timeline for predicting a usable pool of IPv4 addresses.
-
-
Tuesday 26th November 2019 16:58 GMT jason_derp
My Stupid ISP
I've been asking them to change to IPv6 for years now. I finally had to define very pointed questions like "Is ther an actual plan to migrate over, and if so, what is it?". I later determined, after literal months of back and forth, that the guys in charge of that sort of thing think they should definitely do it, and have no actual framework or rough idea about HOW they're going to do it outside of saying "We have a rough plan about how we're going to do it" (the actual response I got when I asked about what the rough plan might be).
-
Wednesday 27th November 2019 18:06 GMT Roland6
Re: My Stupid ISP
The rough plan was to get IPv4/IPv6 stacks on client systems, routers etc., convert the backbone carrier network IPv6, use tunnelling to pass IPv4 over it then get the ISPs to adopt IPv6. This way many of the issues - still outstanding in IPv6 circa 2010, could be worked on and solved, before IPv6 hit the primetime, ie. generally released to end users.
However, not been aware of any great impetus in recent years to actually move things forward other than the regular cries of "we're out of IPv4 addresses - people must start using IPv6". Suspect part of the reason is the takeover of ICAAN, IETF, Nominet et al. by money extraction interests.
-
-
-
Tuesday 26th November 2019 17:21 GMT jason_derp
Re: Convert some local addresses?
I pretty much agree, but i wouldn't say "surely". With the growth of interconnected appliances and IoT devices you could likely use a large of that. Imagine the headquarters of a tech company where every coffee machine and lightbulb is a "smart" version of itself.
-
Tuesday 26th November 2019 18:40 GMT JohnFen
Re: Convert some local addresses?
"Surely nobody needs 16777214 local IP addresses?"
Surely not. But in my LAN, I use both the 10.x.x.x and 127..x.x.x ranges, and like having the entire range available, as I use the address to encode certain things about my machines. For instance, 10.0.0.x are infrastructure servers, 10.0.1.x are media servers, etc.
So, while I don't use all of the addresses in the range, I do leverage the ability to use any arbitrary address in those ranges.
Could I live without doing that? Sure, but being able to do this is very convenient.
-
Wednesday 27th November 2019 17:50 GMT Cynic_999
Re: Convert some local addresses?
"
Could I live without doing that? Sure, but being able to do this is very convenient.
"
But does that convenience outweigh the possibility that you will have to share your public IP address with 10 other customers of your ISP? Because the other way around the issue of insufficient IP4 addresses would be to have ISP-based NAT routers so public IP addresses can be shared amongst several unrelated people. Which would effectively stop you setting up any sort of public-facing server in your home.
-
Tuesday 3rd December 2019 21:36 GMT JohnFen
Re: Convert some local addresses?
"But does that convenience outweigh the possibility that you will have to share your public IP address with 10 other customers of your ISP?"
Yes, actually. I could restrict my use without pain (for instance, I don't really need both the 192.168.* and 10.* ranges). If the range that is safe to use gets too restricted, then it just means that I'll implement something to make it work, either with fancy router tricks or switching my LAN to use IPv6. I'm not sure which way I'd go -- it all depends on what the least painful path is, and I haven't needed to conduct that analysis yet.
-
-
-
Wednesday 27th November 2019 18:14 GMT Roland6
Re: Convert some local addresses?
re: 10.x.x.x
The fun and games start when two companies merge and both have extensively used 10.x.x.x ... been there...
This is about the only scenario where I can see the benefit of end systems (behind the firewall) having universally unique IP addresses.
-
-
Tuesday 26th November 2019 18:08 GMT Fred Daggy
So, around the mid 90's what should have been done is IETF "We need everyone coding a TCP/IP stack to update their #DEFINE LEN_IP_ADDR from 32 to 64 bits and the same for LEN_IP_MASK. Front PAD any v4 TCP addresses with 4 x 0 when translating between V4 and V6 addresses. If you can't reach the next hop send the DESTINATION NET NOT AVAILABLE code in the usual manner".
Recompile. Test.
This will be IP protocol V6.
New IP stacks could have been rolled out in as much time as it took the BSD crowd to code it, and others to implement the code in their OS/device. Weeks or at most months. IPv4 only devices would be museum pieces by now. A wistful Reg article on the passing of IPv4, commented on by a few greybeards, while a PFY mutters OK Boomer would all that marks its passing. "Imagine that, IP protocol with only 2 to the 32 addresses!"
(Errors and omissions are the fault of Surface horrible gummy keyboard)
-
This post has been deleted by its author
-
-
Tuesday 26th November 2019 18:23 GMT IGnatius T Foobar !
Take IPv4 away from consumer ISPs
The place to begin is by incenting consumer ISPs to move to IPv6-first architecture. For example, if you run Android on T-Mobile you get a native IPv6 address and a fake IPv4 address that is tunneled to a CGN somewhere on their edge. All consumer ISPs should do this. This will incent web service designers to build IPv6-native applications.
-
Tuesday 26th November 2019 18:23 GMT IGnatius T Foobar !
Backwards compatible
The way to make IPv6 "backwards compatible" would have been to make addresses variable-length. Initially, all addresses would just happen to be 32 bits in length. But after everyone's converted over, then you start handing out addresses that are longer than 32 bits. In 20 years we'd have gotten there by now.
Variable length addresses would have been compatible with existing routing algorithms that look for the "most specific route" and would give *every* node the ability to split its own address into a network. For example, if your ISP assigns you 100.64.10.10, you could subnet it into 100.64.10.10.1, 100.64.10.10.2, etc. and then downstream you could do the same thing with 100.64.10.10.2.1, 100.64.10.10.2.2, etc. And when someone on the other side of the world sends a packet deep into your network, the most specific address on the public Internet is still 100.64.10.10, and it goes to your router.
Think that's silly? Keep in mind that SNMP OID's are assigned *exactly* this way. You get your *one* number, and you can put as many levels underneath it as you want.
-
Wednesday 27th November 2019 10:15 GMT Nanashi
Re: Backwards compatible
People already moan constantly about how "complicated" v6 is, despite v6 using the same addressing and routing model as v4. I can only imagine how bad it would be if you introduced variable-length addresses, which would be an actual additional complication over v4.
But also I don't think making v6 have variable length addresses would help much, because the thing you're trying to make it compatible with is v4 and v4 doesn't have variable-length addresses, so it wouldn't be able to cope with any address length beyond 32 bits. "Send your packets to 100.64.10.10 with the extra address bits stored somewhere else in the packet" sounds an awful lot like 6to4, which already exists in v6, so if that's sufficient for being backwards compatible then v6 is already there.
Variable length addresses wouldn't save you from needing to fix software to handle the new address family (and that's going to be fun, what with all existing code being designed around fixed-length addresses. The prevalence of buffer overrun bugs suggests that many programmers can't cope with things that have variable length...).
The other major issue is that routing performance wouldn't be great, since handling a variable length address in hardware is not very fast. That would probably result in adoption happen slower rather than faster.
-
Wednesday 27th November 2019 18:25 GMT Roland6
Re: Backwards compatible
>People already moan constantly about how "complicated" v6 is, despite v6 using the same addressing and routing model as v4.
But it doesn't quite use the same model, remember it is more prescriptive about how the first 64 bits are divided up eg. Registry : ISP Prefix : Site Prefix : LAN Prefix
Although I suppose this is in line with the original specification of IPv4 when subnetting hadn't been considered. [Subnetting only being officially recognised in 1985 - RFC950.]
-
Thursday 28th November 2019 14:12 GMT Nanashi
Re: Backwards compatible
v4 divides its addresses up in exactly the same way. Registries get assigned their prefixes from IANA, ISPs get their prefix from the registries, sites get their prefix from the ISP, LANs get their prefix from the site. It's the same as in v6, with the only real difference being that v6 actually has the space to do sparse, aggregated allocations at all levels.
-
-
-
-
Wednesday 27th November 2019 02:51 GMT gnarlymarley
That approach continues to not work. IPv6 still sits at around 24 per cent of internet traffic - and has actually gone down from last year.
The reason for this is people have not been migrating and thanks to the shutdown of some IPv6 tunnel brokers, some people are now back on only IPv4.
There are the networks that refuse to peer on IPv6, even when they have done so over IPv4. Then there are the security concerns. The fact that technical solutions keep removing a sense of urgency. That IPv6 can kill your VPNs.
Unfortunately, I have no problems with VPNs and IPv6. Of course, I am a dual setup and my computers just fall back onto IPv4. It is possible that NAT64 could be their complaint, but my guess is that the folks that are making an excuse to not go to IPv6 are the people that have never used IPv6. When IPv6 first came out, it was "sold" as a product that would NEVER work with NAT66. The people behind IPv6 at the time sounded like they would come visit me and kill me if I tried NAT66. So, I did NAT66 and have been using it ever since. Most home routers do NAT66 now with all of them being capable of NAT64.
Then there’s the fact that some ISPs just don’t see it impacting their bottom line and so can’t be bothered.
My old ISP is called digis/risebroadband and they have so many IPv4 addresses, they know about IPv6 and don't want to implement it. So I blocked them from my router and I setup a tunnel with a different provider. When they finally put in IPv6 I will never be on it.
-
-
-
Wednesday 27th November 2019 18:34 GMT Roland6
>why did you pick an address like ...
Because in the real world you'll find that devices will typically have IPv6 addresses of the form:
fe80::c6224:4ff:fef1:9a0f
and IPv4 address - provided by your DHCP server of the form: 192.168.1.181
So given the constraints of the 192.168.n.n address range, I only need to actually remember 1.181 when looking through syslogs etc.
Fundamentally, IPv4 comes from a time when making things easy for people to use was a consideration. Glad DNS was dreamt up in that era, I can see the IPv6 purist evangelists being totally against it in the same way they are against NAT...
-
Thursday 28th November 2019 14:09 GMT Nanashi
In the real world you'll be using DNS, so it doesn't matter what the IPs are.
The address you gave is... well, invalid, but it's also intended to be a link-local and you're unlikely to actually use that. If you get your v6 addresses from a DHCP server like you do in v4, then your address will look like the one I gave in my original post. You'll only need to remember the "1::192" bit, which is basically no different to v4.
-
Friday 29th November 2019 13:45 GMT Roland6
>In the real world you'll be using DNS...
Depends on context, as I said looking through syslogs, DNS doesn't help you.
>The address you gave is... well, invalid...
Only to the extent that I transcribed it incorrectly, switching a digit and colon. Which demonstrates quite nicely that IPv6 addresses aren't really intended to be used by humans, even ones used to working in hex...
Yes, it was a local link address, but it was to hand and illustrates the point: put a wireshark on a LAN and on many networks in todays IPv4 first environment, you will lots of 'interesting' IPv6 addresses. the only way to find out what they are is to probe them. As I've not seen a pure IPv6 network, I'm not sure what I would see, but given IPv4, I anticipate in addition to the DHCP assigned addresses there will be a few 'interesting' addresses that will need to be investigated.
-
-
-
-
-
Wednesday 27th November 2019 09:49 GMT Paul Johnson 1
IPv4 is a barrier to entry, so ISPs like it.
The article says "Then there’s the fact that some ISPs just don’t see it impacting their bottom line and so can’t be bothered."
Its actually worse than that.
One of the things you want in a business is a barrier to entry for would-be competitors, the higher the better. If there is no barrier to entry then competition will drive prices down to the point where you can barely make any money (as any Uber driver will tell you). Having a barrier to entry lets you raise prices to just below the point where competitors would find it profitable to buy in.
Exhaustion of IPv4 addresses makes it difficult to start up a new ISP; you can't just request a few nice big /16 blocks to get you started, you have to go out and buy a /8 here and a /8 there. Meanwhile existing ISPs are sitting pretty with their existing pools of IPv4 addresses. In fact the secondary market makes those an appreciating asset, something else that businesses like to have.
If IPv6 becomes widespread then this barrier to entry disappears and the existing pools of IPv4 become worthless. So it is in the ISPs interests to delay this evil day for as long as possible.
-
Wednesday 27th November 2019 18:20 GMT Muscleguy
Technically but not actually, properly, meaningfully
I have a personal Fb page but it's locked down and with minimal info on it because it's sole function is to administer my business page. Since Fb don't allow you to create a business page without a personal page to administer it I have no choice.
My family has been informed of this and that no messaging will be responded to or friends made. I could do without cute family bagy photos (I've just become a Great Uncle) cluttiering things up. As for advertising on Fb, I've never seen any. Maybe Adblock really does work, or something.
-
Thursday 28th November 2019 04:15 GMT SNAFUology
Tunnel Vision
If I could know that my modems would not pass on IvP4 encapsulated IvP6 (Class A, B &C ) address then I would be more amenable to it BUT
Microsoft & others already have tunneling boasting of busting a hole thru NAT and identifying every little thing you have connected to your network.
This is as bad as Universal Plug & Play UPNP, letting anyone see the peripherals on your Computer.
IvP6 NAT or IvP6/4 NAT
So get up the hardware manufacturers to guarantee their gear can do that and that be one step in the right direction.
-
Friday 29th November 2019 22:06 GMT David Crowe
The problem with IPv6 is not whether it can be made to work, clearly it does. The problem is that it delivers no value until EVERY internet device is IPv6 capable and configured. Since that will never happen, we can predict that IPv6 will never deliver any value. There is absolutely nothing you can do on IPv6 that you can't do with IPv4. And with NAT technology you only need a teaspoon of IPv4 to supply an ocean of devices. And the world hasn't exhausted it's creativity with IPv4 addresses yet, such as utilizing the massive reserved 240.x.x.x block in intelligent ways.
-
Friday 29th November 2019 23:03 GMT Nanashi
I'm pretty sure I've explained to you before that v6 does deliver value even before every device supports it. It's delivering value right now, so we can already declare your prediction wrong.
NAT is not as capable as you think. There are many things it breaks, and many things that are still possible in the face of NAT but only with additional effort and expense. NAT is useful as a delaying tactic but is not a desirable end goal.
-
-
Thursday 5th December 2019 18:05 GMT moamin
A New Communications Stack
IPv4 depletion and IPv6 slow adoption are obvious reasons why (jacs.tech) was born....Short for 'Just Another Communications Stack'; it integrates blockchain with the good old CLNS (who remembers it?) with its HUGE 160-bits NSAP addresses to be the new stack/infrastructure of the Internet 3.0 (decentralized)