Any chance we could use public and private rather than real and fake IP addresses? 192.168.x.x is not a fake address, it's a private address, and 90.52.x.x is no more or less real but is a public address.
Sheffield ISP: You don't need a whole IPv4 address to yourself, right?
Facing the shortage of IPv4 addresses, and glacial adoption of IPv6, UK ISP PlusNet is looking for volunteers among its customers to test out sharing the IPv4 addresses on its network. The technique being tested by PlusNet uses a NAT (Network Address Translator) to share a single internet-facing IP address between multiple …
-
Tuesday 15th January 2013 12:55 GMT Phil W
Volunteering for the unknown
Surely anyone who really understands what this actually means, probably won't be the sort of person willing to volunteer due to have some kind of port forwarding in place for remote desktop or some such thing.
Also what about sites that restrict file downloads per hour/day based on IP. If the person/people I'm sharing with use it all up I'm screwed.
I'd much rather have an IPV6 address, than a NAT'd connection with some stranger.
-
Tuesday 15th January 2013 14:28 GMT Andy Fletcher
Re: Volunteering for the unknown
That's the trick though isn't it? No self respecting Reg reader would bother - imagine playing COD on a setup like that. The latency is already terrible enough thanks.
It'll be punted to people as a budget option, and joe public will see the price first and worry about the technical details when they've already bought it and realised it's crap.
-
Tuesday 15th January 2013 14:45 GMT Charlie Clark
Re: Volunteering for the unknown
Makes you wonder doesn't it? Here my ISP already takes care of the IPv4 / IPv6 handling and servers are also increasingly ambidextrous:
$ host h-online.com
h-online.com has address 193.99.144.80
h-online.com has IPv6 address 2a02:2e0:3fe:100::8
h-online.com mail is handled by 10 relay.heise.de
Meanwhile in steam-powered old England:
$ host theregister.co.uk
theregister.co.uk has address 92.52.96.89
theregister.co.uk mail is handled by 10 aspmx2.googlemail.com.
theregister.co.uk mail is handled by 10 aspmx4.googlemail.com.
theregister.co.uk mail is handled by 1 aspmx.l.google.com.
theregister.co.uk mail is handled by 10 aspmx5.googlemail.com.
theregister.co.uk mail is handled by 5 alt2.aspmx.l.google.com.
theregister.co.uk mail is handled by 10 aspmx3.googlemail.com.
theregister.co.uk mail is handled by 5 alt1.aspmx.l.google.com.
Given the apparent cluelessness of ISPs and technical publications is it time we thought of jumping ship?
-
Tuesday 15th January 2013 14:55 GMT big_D
Sounds like...
the old shared party telephone lines... *shudder*
Here in Germany, since October, I think, Deutsche Telekom has been giving customers of their combined DSL and VOIP (i.e. no ISDN or analogue telephone connection accompanying the DSL) packages IPv6 addresses by default.
Most other ISPs seem to be going over to dualstack IPv4 and IPv6 connections. At least the most popular modem/routers over here (AVM Fritz!Box devices, which account for over 50% of households) have a good IPv6 firewall, with a proper default configuration.
-
Wednesday 16th January 2013 10:23 GMT CynicalOptimist
Re: Sounds like...
a 'party line' was used as a plot device in the Doris Day romcom Pillow Talk to connect two strangers who antagonise each other at first but ultimately fall in love. Perhaps a 'party IP' remake is due. Better hurry up though, it will be an anachronistic joke soon (at least outside of the UK).
-
Tuesday 15th January 2013 16:11 GMT Steve Knox
Re: Volunteering for the unknown
I'm not so sure what the problem is here. For years I had a local network NAT'ed (10.x.x.x)* behind a Wireless Router which itself was NAT'ed (192.168.1.x) behind a VoIP router (192.168.1.x) and I was able to run any p2p client apps (games, bittorrent, chat apps) I wanted, without punching holes, and I did run quite a few.
* A bit overkill, I grant -- I only used about 10 addresses in 10.1.1.x -- but it's not routed anywhere and 10.1.1.x is much easier to type than 192.168.1.x. So why make things difficult?
-
Tuesday 15th January 2013 18:37 GMT Athan
Re: Volunteering for the unknown
Likely the other end of any connection in your uses cases was not behind any (non-forwarding) NAT. You connect out through NAT, the other end simply replies. But it would have meant any P2P clients couldn't initiate connections to you, you'd have to talk to them first.
So, no, not working 100% without issues.
-
Tuesday 15th January 2013 21:46 GMT Anonymous Coward
Re: Volunteering for the unknown
@Steve Knox
I liked it when we used 10. addresses for private IP addresses on our network. Not for ease of typing - though it helped - but because it was more obviously not a public IP address and if I saw 192.168. then I knew it was something that had reset itself.
-
-
Tuesday 15th January 2013 12:57 GMT Phil O'Sophical
No surprise, I predict that there will be more to come
I can see this becoming more common. It's a great pity that the IPv6 developers chose a new mechanism that was unable to permit a phased change. I assume that was in part due to the "ivory tower" mentality that pervades academia; only a perfect solution to every problem would be acceptable and anything with extended headers or other compatible hackery would have been beyond the pale, architecturally.
Also, of course, when IPv6 was being developed the internet was a lot smaller, and the idea of switching it all off one night and restarting the next day with new addresses probably wasn't as unthinkable as it is today.
I seriously don't see how we can have even a semi-painless move to IPv6 worldwide. Is there a plan? (serious question)
-
Tuesday 15th January 2013 13:19 GMT Gerhard Mack
Re: No surprise, I predict that there will be more to come
Well you know what they say: "anything is easy if you don't know what you are talking about". IPv4 is a fixed length header field so there was no way to just expand the address length. DNS allows both address formats and IPv6 addressable machines can also have an IPv4 address. The ideal plan was for IPv6 to coexist with IPv4 and then phase out IPv6 when IPv6 was ready. The problem was that everyone waited for everyone else to go first so the ISPs didn't bother because there was no software support and the OS providers didn't bother because there were no uses yet.
To put it simply: we had over a decade to do this the easy way but everyone waited until the last possible moment and now the transition will be painful. Don't blame the IPv6 designers for stupid people who can't see the benefit of spending money on anything that doesn't bring a result before the next quarter.
-
Tuesday 15th January 2013 13:50 GMT Phil O'Sophical
Re: No surprise, I predict that there will be more to come
> Well you know what they say: "anything is easy if you don't know what you are talking about"
Sorry, my last 20+ years working with comms protocols must have got lost, I suppose.
I didn't suggest expanding the address length, that is of course fixed, but other protocols have worked around this by adding additional extended headers. It makes temporary co-existence possible. Look at some of the original suggestions in RFC 1287, for example.
IPv6 went through many proposals, TUBA, SIP etc. The final one chosen was designed to fix all the perceived problems of IPv4, and direct compatibility was not seen as a requirement.
As for
> Don't blame the IPv6 designers for stupid people who can't see the benefit of spending money on anything that doesn't bring a result before the next quarter.
Why not, as I said they were academic purists who had little practical regard for commercial interests. Let's face in, when IPng work started, the World-Wide Web hadn't even been described outside of CERN!
I'll bet if you made IPv6 vanish, and asked Google to come up with a solution to IPv4 address exhaustion, you have something that was workable in a year. Ugly, but workable.
Downvote away :)
-
Tuesday 15th January 2013 14:04 GMT Anonymous Coward
Re: No surprise, I predict that there will be more to come
Hi Phil,
What exactly is your suggestion for a better proposal than IPv6? It's not very clear to me what you think should be done as an alternative, apart from "not ipv6". Add additional headers to ipv4? How would that solve the problem?
Is your solution really "hope Google come up with something if we ask them to (so far they haven't)"?
Cheers
-
Tuesday 15th January 2013 14:17 GMT Phil O'Sophical
Re: No surprise, I predict that there will be more to come
Oh, it's at least 15 years too late for any other solution now. CG NAT is what we'll have to get used to as a transition measure, probably as part of a two-speed internet where IPv6 also exists, but isn't widely used for a long time.
It will be very interesting to look back at this in, say, 2020. Barring a killer app that makes IPv6 essential, no matter what the cost, my money is on widespread CG NAT, at least for domestic ISPs. It's a horrible thought, but I can't see a viable alternative. I suppose we might see IPv6 appearing on mobile networks more quickly.
So far nobody has answered my question, though. What is the plan for really achieving migration to IPv6, other than waving our hands in the air and saying "well, somebody should make it happen", while downvoting the doom-mongers :) ??
-
Tuesday 15th January 2013 15:41 GMT Anonymous Coward
Re: No surprise, I predict that there will be more to come
Actually Phil, it seems like people have answered your question quite a few times already. IPv4 and IPv6 can co-exist, so they will do, till businesses transition themselves over gradually.
Do you really think there's "A Plan" that every business in the world is going to sign up to? For IPv6, or anything else? Does that exist in any sphere of business anywhere? I can't think of an example.
Not sure what your point is really, you have no actual alternative proposal, IPv4 and IPv6 can co-exist, be routed between... what is it you actually want to know?
-
Tuesday 15th January 2013 16:25 GMT Jon Press
Re: IPv4 and IPv6 can co-exist
They can, like telephones can co-exist with the postal service. However if you can only have a phone or a letterbox - but not both - the co-existence is not necessarily helpful.
And that's unfortunately the territory we're entering - the transition plan has always assumed that the coexistence phase would have pretty much come to an end before the IPv4 space was exhausted.
-
Wednesday 16th January 2013 23:16 GMT Roland6
Re: IPv4 and IPv6 can co-exist
To drive Jon's point home the issue isn't co-existence it is end-to-end interoperability. Try having a telephone conversation with some who can only be reached by letter.
IPv4 and IPv6 can co-exist on the same network as they use different network protocol Id's, this was by design. Similarly the V series of modem protocols co-existed on the same network as voice communications, however there was no way for a voice terminal (ie. a phone) to meaningfully communicate with a data modem (beyond dialling the recipients number).
The lack of practical real-world interop and/or migration between IPv4 and IPv6 can be blamed directly and wholly upon the team responsible for drawing up IPv6; as they could have drawn upon the vast body of expertise and experience in the OSI and CCITT communities instead of adopting a superior "not invented here" attitude, which has left us with a problem that we have been grappling with ever since.
-
-
Tuesday 15th January 2013 17:10 GMT Phil O'Sophical
Re: No surprise, I predict that there will be more to come
> IPv4 and IPv6 can co-exist, be routed between... what is it you actually want to know?
Of course they can be, I've been doing it since before IPv6 was officially published as a protocol.
The point, as was made in a post just above, is that having a host with IPv6 is pointless if the network equipment between it and it's destination can't handle IPv6, and no-one will upgrade the network equipment until there are enough IPv6 hosts to make it worthwhile. My question is what incentive there is to fix that, and no-one has been able to answer me. What do you think it will take for BT/Plusnet/Sky/Virgin etc. to replace every single customer router with an IPv6-compatible one? We've been waiting for businesses to transition "gradually" for 15 years, and despite the huge explosion in connected devices we're now at the staggering level of 1% IPv6 penetration. Now it looks like they're transitioning instead to the lower-cost and less painful alternative, CG NAT. Yuk.
There are ways to add new features to protocols such that existing protocol stacks can still process them, while just ignoring the new features. The IPv6 designers chose not to do so, which may have seemed like a good idea architecturally but is now a severe disincentive to upgrade.
-
Tuesday 15th January 2013 17:53 GMT Anonymous Coward
Re: No surprise, I predict that there will be more to come
> There are ways to add new features to protocols such that existing protocol stacks can still process them, while just ignoring the new features. The IPv6 designers chose not to do so, which may have seemed like a good idea architecturally but is now a severe disincentive to upgrade.
But there is no way to physically extend the 32bit IPv4 address space. The IPv4 header is a fixed length (20 octets). Even if a way was devised you would still have exactly the same problem. Some routers/equipment would support the extension and some wouldn't. Customers routers would still have to be replaced for those supporting the IPv4 "extension" (firmware flashing would be as much of a solution as it is for IPv6).
-
Tuesday 15th January 2013 19:53 GMT Ken Hagan
Re: No surprise, I predict that there will be more to come
"There are ways to add new features to protocols such that existing protocol stacks can still process them, while just ignoring the new features. The IPv6 designers chose not to do so, which may have seemed like a good idea architecturally but is now a severe disincentive to upgrade."
Back in academia, I think the assumption was that you would upgrade by loading up revised firmware for your router and run a dual stack. Back in 1995 or whenever, that would have had an expected financial cost of nothing and a labour cost of bugger all.
Fast forward to 2010 and the world is full of domestic ADSL boxes whose manufacturers refuse either to issue new firmware or to help anyone else write new firmware, because *they* want the cost to be "£50 for a new box thank you very much". (Rather ironic that the sticking point here is *software* that in nearly every case was Linux, gratefully picked up for free by the manufacturer.) Notice that extensions to IPv4 would have suffered the same fate. (One can argue that the ISPs are also part of the problem if they want to sell IPv6 as a chargeable extra.)
-
Wednesday 16th January 2013 16:25 GMT PyLETS
IPV6 transition can happen now
It's already happened as far as I'm concerned - home network and hosted server and applications I maintain all upgraded to run dual stack. That's even though my best available ISP (Cable offers better speeds than ADSL) is IPV4 only, so I tunnel IPV6 over IPV4 using protocol 41. I had to do something similar to get Internet in the late eighties by tunneling IPV4 over X25. Well, now that FTTC makes better ISPs available in perhaps the next 18 months, my existing one (Virgin Media) is going to have to offer dual stack pretty soon, or I'll be ditching them for one of the ISPs which are offering IPV6 natively. At least Virgin Media don't block protocol 41, like some crummy ISPs do.
I suspect most consumer equipment could be firmware upgraded to run dual stack, and ISPs providing tunnel servers more locally could support consumers they can't firmware upgrade without requiring hardware replacement.
-
-
-
Tuesday 15th January 2013 15:58 GMT Anonymous Coward
Re: No surprise, I predict that there will be more to come
The internet of things is the killer app.
You can hardly blame the designers, IPv6 was ready to use in 1996 before the internet was very large at all. ISPs could have saved themselves all the transition hassle if they had adopted it sooner.
-
Tuesday 15th January 2013 22:14 GMT Decade
Re: No surprise, I predict that there will be more to come
Well, my plan for achieving migration is saying, "I will make it happen," on my network. If you are a network administrator, now it is YOUR personal duty to enable IPv6 connectivity on your network. IPv4 was deployed by millions of individual decisions to join the Internet. IPv6 will be deployed by the same.
In my section of the USA, the ISPs are trying to eliminate the home router market. When you get new Internet service from Comcast or AT&T, you get a combination modem and wireless router device, too. The upside is that the routers that they've starting shipping in the last few months support IPv6. This means the homes in the USA are gradually shifting to IPv6, without the consumers having to learn new technology. This is a positive development.
-
-
-
Tuesday 15th January 2013 15:01 GMT Gerhard Mack
Re: No surprise, I predict that there will be more to come
An extended header would have left us in pretty much exactly the position we are in now only with slower header processing (a big deal for routers), no one would have bothered to implement them until the last moment.
One of the main reasons they chose 128 bits was because the designers couldn't see a way to extend the addressing and they knew the transition would be painful so they decided to make it large enough that there wouldn't need to be another transition in the foreseeable future. That's hardly "ivory tower"
-
-
Tuesday 15th January 2013 17:59 GMT Fatman
Re: we had over a decade to do this the easy way
I remember when I first started diving into IPv6, one item I noticed was a specific prefix that would have allowed existing IPv4 addresses some space within the IPv6 universe; and wondered why it was never readily used.
Then the old standby reminded me - it's called the bottom line. Fuckers too cheap to spend the $$$$.
-
-
Tuesday 15th January 2013 13:43 GMT Skoorb
Re: No surprise, I predict that there will be more to come
RIPE NCC in September:
"On Friday 14 September, 2012, the RIPE NCC, the Regional Internet Registry (RIR) for Europe, the Middle East and parts of Central Asia, distributed the last blocks of IPv4 address space from the available pool...
"It is now imperative that all [ISPs] deploy IPv6 on their networks to ensure the continuity of their online operations and the future growth of the Internet."
Somebody didn't read the memo.
http://www.ripe.net/internet-coordination/news/announcements/ripe-ncc-begins-to-allocate-ipv4-address-space-from-the-last-8
-
Tuesday 15th January 2013 13:52 GMT An0n C0w4rd
Re: No surprise, I predict that there will be more to come
IPv4 and IPv6 can co-exist. There was never any plan for an overnight switch from v4 to v6. IPv6 was designed to run in a dual stack environment where both v4 and v6 addresses were in use. If you were connecting to a system that also had a v4 and a v6 address, then local configuration will determine if you make the connection over v4 or v6, with the default to be to use v6.
Of course this isn't perfect. People can have a v6 iP that isn't able to connect to your v6 IP, and people don't want to wait 90 seconds for the v6 connection to time out before retrying on v4. This lead companies to develop a standard called "Happy Eyeballs" which try and learn whether to use v4 or v6. Yahoo! also sponsored an extension to BIND to try and help mitigate the split network scenario.
The real reasons nothing happened until it was too late was lethargy and inertia. Vendors didn't want to spend the (considerable) effort in making their products IPv6 compliant as it wasn't affecting purchasing decisions in the vast majority of cases. Customers weren't asking for V6 because either the people making the decisions didn't understand or because they didn't want to pay more to get v6. End user devices (DSL modelms, etc) didn't support v6 as ISPs didn't offer it, and ISPs didn't offer it because no devices could use it. A set of classic chicken and egg scenarios.
Yes, IPv6 was largely driven by academia, and that can be witnessed by the original specs for IPv6 autoconfiguration where the end client figured out what the subnet it was on was and then used its Ethernet MAC address as the last 48 bits of the submit and hey presto, you got a unique routable IPv6 IP. Its why IPv6 subnets tend to be /48s - the 48 bits in the MAC. It wasn't until years later that someone pointed out that MACs are globally unique (or are meant to be) so it didn't matter what network you were on, your computer could be uniquely identified through the IP it chose. A new autoconfiguration mechanism was released in the past 2-3 years to address that.
Even though Cisco has supported IPv6 natively in IOS for years, initial implementations were not carrier grade. IPv4 was handled through very efficient DCEF, which IPv6 packets were process switched, a very expensive process. Only recently has Cisco moved IPv6 into DCEF (or whatever they call it today).
As for CGN (Carrier Grade NAT, the industry term for what Plusnet is trying), there are a lot of implications and not all of them are well thought out. The issues raised in the article are relevant, and search engines and other such web sites are already concerned about the rise of CGN as it impacts their operations to not only monetise their search results and make them more relevant by using geolocation, it makes defending the sites against attack a lot more difficult as you can't just block the IP and affect a single user any more. The search engines have been in talks with ISPs for years about IPv4 to IPv6 transitions, and the need for CGN as an interim phase. Search engines would much rather we all move to v6, but thats not going to happen any time soon.
CGN also has implications for non HTTP traffic such as VOIP, as SIP really REALLY doesn't like NAT. That is one issue that I don't think is easily solved in CGN deployments without sniffing and rewriting the SIP control packets, which would be a non-trivial exercise with high traffic deployments.
-
Tuesday 15th January 2013 16:03 GMT Jamie Jones
Re: No surprise, I predict that there will be more to come
An0n, I agree with your post apart from this bit:
"search engines and other such web sites are already concerned about the rise of CGN as it impacts their operations to not only monetise their search results and make them more relevant by using geolocation, it makes defending the sites against attack a lot more difficult as you can't just block the IP and affect a single user any more"
This has been an issue for decades, since DHCP largely took over from static IP's for home users.
And as a CGN will be allocated to an ISP, geolocation won't be affected. Even if the ISP has customers (and hence peers) in other countries, they will be using a different CGN for that country, else all their traffic will be routed back to one country and out again (and indeed, if there is an ISP that works like this already, then geoloation would already be similarly affected)
Nope, search engines and advertisers have long gone for cookies etc. not specific IP address
-
Tuesday 15th January 2013 20:40 GMT Alan Brown
Re: No surprise, I predict that there will be more to come
"This has been an issue for decades, since DHCP largely took over from static IP's for home users."
ISP-level HTTP transparent proxies have been around a long time too and that doesn't seem to have affected them much (hint: That's why cookies are used)
-
-
Tuesday 15th January 2013 17:36 GMT Mr Flibble
Re: No surprise, I predict that there will be more to come
Subnetting using /48 isn't to do with MAC addresses. Subnetting using /64, however, is. And I recall reading something saying that the preferred allocation is now /56. (I have a /48, but I've yet to need more than a /60. Well, two /64s, really. I could get away with one but I need a publicly-routeable address on the external network interface and I don't have any sort of IPv6 address translation going on, not that anybody should need that.)
Why not /80? But then you couldn't have local addresses which don't contain something which could be a MAC address…
-
Wednesday 16th January 2013 14:15 GMT Vic
Re: No surprise, I predict that there will be more to come
> SIP really REALLY doesn't like NAT.
SIP is fine with NAT. All my phones are behind at least one NAT router.
The trick is to set up the STUN service properly - that means the external IP address can be embedded in the SIP packet.
Oh - and turn off all those "helpful" SIP ALG implementations in routers. They're universally crap...
Vic.
-
-
Tuesday 15th January 2013 14:42 GMT Anonymous Coward
@Phil
"It's a great pity that the IPv6 developers chose a new mechanism that was unable to permit a phased change."
And why wouldn't it? As other already mentioned; DNS can use both A and AAAA for the same site; thus leaving it up to the user to, well, use either one.
If any the only thing I think you can blame the "IPv6 lobby" for is that they've been playing "Cry Wolf" for too long. You know; predict the end of the Internet due to running out on IPv4 addresses after which nothing happened. And not once, not twice but at least four times in a row. That was a very good way to lose a lot of credibility really fast.
They should never have made it as dramatic as they did, then people may have taken them a lot more serious than now. Good luck presenting IPv6 implementation plans to the upper brass now: "But haven't we heard those doom stories for the last 10 years now? And everything just kept running, so why should we bother with all this when everything works just fine?".
-
Tuesday 15th January 2013 20:35 GMT Alan Brown
Re: @Phil
"But haven't we heard those doom stories for the last 10 years now? And everything just kept running, so why should we bother with all this when everything works just fine?".
Step one was dynamic IP allocations - that staved off things for a few years
Step two was NAT - that staved off things for a few more years.
Step three was allocating all the reserved ranges - that staved off things for a few more years.
Not bad for a protocol which was a kludgy hack only intended for general use for 5 years or so (and that's why 4 billion addresses was "enough") until IPX was ready.
It's a pity that IPX turned out to be more of a clusterfuck than IPv4
-
Wednesday 16th January 2013 14:36 GMT Vic
Re: @Phil
> the only thing I think you can blame the "IPv6 lobby" for
I'm blaming them for giving us non-memorable IP addresses.
IPv4 is *nearly enough*. 32 bits is a bit less than 1 address per human - particularly when you take out the reserved portions of the address space.
So what we need is a little bigger - 34, 35 bits, something like that. That would give us an address each, and still be feasible to hold an address in your head. But we like multiples of 8, so a 40-bit or 48-bit addressing scheme would have been wonderful - 40 bits is still 256 instances of the current IPv4 Internet, and that is a lot.
128 bits is unwieldy in extremis - it's far, far bigger than we're ever going to need. We have MAUs of /64 - why would anyone need a /64 as the *minimum* allocation? We're never going to have 2^64 humans, and I can't imagine any one of them needing 2^64 addresses. I personally have a /56 and a /48, and I have a sum total of 3 machines on those 10^23 addresses...
Vic.
-
Saturday 19th January 2013 16:18 GMT Ken Hagan
Re: non-memorable addresses
IPv4 gave us non-memorable addresses. A memorable one uses words and has variable length segments that not only uniquely identify the addressee but also tell you how to get there. As proof of this, I'd wager that the ordinary end-user can probably quote you quite a few DNS names but no IP addresses.
Funnily enough, the reason the ivory tower academics jumped to 128 bits for IPv6 was the realisation that a longer binary address could be used the same way. I don't know how successful this is in practice, but the extra bits were supposed to be carved up so as to make it really easy to implement routing algorithms.
-
Sunday 20th January 2013 21:59 GMT Vic
Re: non-memorable addresses
> IPv4 gave us non-memorable addresses
Nonsense. I spend every day surrounded by people who readily recite IPv4 addresses from memory.
The same simply cannot be said for IPv6.
> I don't know how successful this is in practice
It isn't...
> the extra bits were supposed to be carved up so as to make it really easy to implement routing algorithms
Having a MAU of /64 pretty much obviates that.
Vic.
-
-
-
-
-
Tuesday 15th January 2013 12:59 GMT Mr Tumnus
Network Ranges
Hi Bill, it's not strictly true to say 192.168 addresses are "fake" or "not valid", they are valid ip addresses, it's just they're reserved as private ip ranges, for anyone who wants to use on their private networks. Therefore they're not routable on the internet.
They're private network ranges, rather than public network ranges, and are defined in RFC1918. But in every other sense, they're "valid" and "real" ip addresses. So one company in Texas might use the same private IP range behind their internet routers as another company in Liverpool, eg, 192.168.10.0/24.
The reserved ranges are;
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
You could use routable addresses as your local network range, but it would mean the routable addresses weren't reachable, because your clients would expect that range to be local, not out on the internet (they'd arp for those ips, rather than routing traffic to their local gateway)
Eg, if you used 173.194.78.0/24 as your local network range, you might have trouble getting to some of Google's services, because that range is used for www.google.com (among other things. Although Google also have www.google.com on other ranges too)
-
Tuesday 15th January 2013 12:59 GMT M7S
"The days when everyone ran their own servers are long gone and almost everything is available in the (better secured) cloud these days"
I'd like to run my own mail server, and intend in future to have things like the ability to check home cctv, respond to callers at the entryphone (fitted with IP camera) etc from my smartphone. Surely with all these future connected households we hear about, where one can start the bath running whilst still travelling home valid connections will be a requirement?
-
Tuesday 15th January 2013 13:22 GMT Arrrggghh-otron
"The days when everyone ran their own servers are long gone and almost everything is available in the (better secured) cloud these days"
I still do, on a plusnet static address. I like knowing who is looking after my email... particularly after the email storage cock up at plusnet a good few years back.
Maybe this will spur plusnet to get on with their public IPv6 deployment - it has been trailed on and off for the past few years, so this seems as good a reason as any to roll it out.
-
This topic is closed for new posts.
Biting the hand that feeds IT
