IPV4 best for the general public
I am behind a NAT router, my ISP gives me a dynamic IP address, and I wish to stay like this thanks very much. Our privacy and device security are compromised enough already.
The deployment of a new address system for the internet brings with it connectivity problems, network security issues and privacy concerns, according to a new study. The UK is lagging behind other areas of the world in relation to the transition to IPv6 and the continuing reliance on the existing IPv4 system of addresses has …
I am behind a NAT router, my ISP gives me a dynamic IP address, and I wish to stay like this thanks very much. Our privacy and device security are compromised enough already.
Can I just add...
Sticking your head in the sand will only result in you getting sea water up your nose when the tide comes in. You might be fortunate that most of the web sites that you want to go to have IPv4 addresses, in the West we got allocated lots of IPv4 addresses, that is not true for, eg China. It will change.
BTW: Pinset Masons is reporting old news, that report has 2012 written all over it!
"Sticking your head in the sand will only result in you getting sea water up your nose when the tide comes in......" Which is part of the problem for the IPv6 pluggers - they've been screaming about the tide coming in and us all due to drown for years, but those creating new network projects are still able to implement IPv4 solutions because most Western companies are looking three-to-five years ahead.
".....that report has 2012 written all over it!" The other part of the IPv6 plugger issue - they started screaming far too soon and far too loud, and too much of the screaming consisted of pluggers shrieking "Do it cos we say so, 'cos we're cleverer than you!" - brow-beating is not a good incentiviser when others can see holes in your argument. The myth of "drowning" is particularly vacuous for US companies and has been known to be so for years (http://www.circleid.com/posts/twenty_myths_and_truths_about_ipv6_and_the_us_ipv6_transition/)
The result is very much like the boy that cried wolf - we've got tired of listening to the exaggerated tales of doom. And part of the reason that the pluggers started screaming about IPv6 so loud and soon is because it is the most cackhanded design and marketing effort ever. One big problem faced by the IPv6 pluggers was the user perception that IPv4 has always been a pain and anything replacing it is going to be twice as painful. Some people still insist that IPv4 subnetting is a dark art. So they approached IPv6 with trepidation, only to be faced with a completely new and largely incompatible standard that simply looks like someone had a "bright idea", got upset by the criticism, and just decided to force it on the users regardless. This perception by the users is only heightened by the non-stop screaming of imminent "drowning" that somehow never happens. By far the simplest and easiest to implement solution would have been to simply add another pair of binary octets to the existing four-octet IPv4 addressing, which would have meant we could have quite easily converted existing IPv4 addresses to the new standard, only instead we got the mess of hexadecimal IPv6 which requires existing networks to be completely rejigged, dual-stacked or use translators between IPv4 and IPv6 subnets. Believe me, any time you ask a CIO to throw away something that is working relatively well and invest in something they have a problem seeing the value of you have a big problem.
And the arguments about IPv6 security don't seem to stack up either - I have known IPv6 nets that have been hacked, and most of the "built-in" security of IPv6 would seem to be possible to bolt on to IPv4 implementations. At the moment you have been telling us we're all going to drown every day for years, but the IPv6 "answer" sounds too much like asking everyone to buy and eat fifty expensive oysters in the hope we'll somehow grow gills.
Wow! It is not just your head that is in the sand.
Dual stacking by adding IPv6 is not hard, I cannot see why you are afraid to do it. Google and Akamai (to name but two) support IPv6, they would not do so if there was little point. I respectfully sugest that they know more about it than either you or me.
Do not make excuses for inaction.
Your suggested solution of adding another couple of octets to the IPv4 4 octets would be just as disruptive as the move to IPv6 with not as much of the gains.
Spoken like someone who knows nothing about programming. IPv4 is stored as a 32 bit int at a fixed point in the headers so adding the two extra octets will break everything just as much as IPv6 would.
The idea was to make sure that we only have to go through this pain once in our lifetimes rather than just having to do it all again in a few years and that's why they went with 128 bit addresses. Same pain, more gain.
Depending on what country, and in Europe that's everywhere apart from Germany, you're in that doesn't matter. Your ISP will happily inform the relevant parties upon request who was assigned a particular IP address. IPv6 has privacy extensions which give you more control of your addresses.
IPv6 isn't perfect and definitely needs more testing. Pity El Reg hasn't taken part in any of the IP6 days over the last few years or bother to run a dual-stack server like, say, Heise does.
My ISP finally got round to offering IPv6 last year and it is slowly becoming the standard for new connections. My router, my phones, my computers have no problems with it and it's faster when supported at both ends.
Yes, there's a good reason for the report to have 2012 written all over it: it was written in 2012 and DCMS has been desperately holding on to it trying to work out how to emasculate it every since. Now I don't know about you but when the government tries to suppress something I tend to think that it might be worth looking at.
> I am behind a NAT router, my ISP gives me a dynamic
> IP address, and I wish to stay like this thanks very much.
Why can't you can do exactly the same thing with IPv6?
maybe he has a shit router? Quite a few enterprise firewalls only started supporting IPv6 in the more recent times. MS couldnt be bothered to update their firewall (TMG) so canned it instead.
Perhaps if the naysayers wait long enough then someone big will release their IPv4 back to the pool and utilise IPv6 instead - then you can buy more!
NAT is a kludge (at best), which requires a lot of extra router processing these days to track all the stateful connections going through it (increase in cpu demand continues to outstrip increase of horsepower in available low power consumption cpus)
IPv6 at its core is just IPv4 with a much bigger address space. The IPsec stuff has been relegated from MUST to SHOULD have and in a lot of cases isn't necessary.
Large chunks of the Internet are already IPv6 only. You may not care to deal with them, but I need to as part of $dayjob.
A decent IPv6-capable home router will firewall your internal machines just as well as an IPv4 router does. If it doesn't then install WRT-DD.
Adoption of IPv6 is, unfortunately, frequently associated with the assignment of unique, persistent IPv6 addresses to every "thing" connected to the Internet. Conflation of addressing with identification would be thoroughly bad for privacy., allowing wholesale tracking, even within private networks (but at network rather than application or individual level).
The smallest IPV6 allocation you can get is a /64 . That gives you 2**64 - 1 addresses for TOR like purposes in respect of VPNs between friends, so your traffic could realistically emerge from and be received by anyone in your friend of a friend wider group given a suitable browser plugin. Yes I know you could use 10.*.*.* and other privately replicatable and publicly unroutable blocks for this, but the management problems of this replicated address space would make its use for this purpose more error prone, higher management effort and less likely to occur in practice.
Wasn't the NSA highly involved with the IPv6 working group?
I'm sure NSA/GCHQ would love us all to stay on IPV4. Carrier grade NAT will significantly degrade genuine peer to peer encrypted services such as ZRTP and RFC 6189 e.g. for P2P opportunistically encrypting VOIP forcing people to use Skype type services instead. If you can no longer punch a P2P port through a double layered NAT firewall we will all have to go through centrally controlled service registries rather than being able to run and secure our own servers.
As to NSA involvement in standards definition, this is an organisation with 2 mutually conflicting objectives:
a. Securing US Government computing and communications
b. Spying on people
If they contribute to deliberate brokenness of standards in respect of objective a. in order to make b more feasible, they are not meeting their mission objectives by making the US government more vulnerable. This conflict probably explains why DES was apparently designed to be resistant to differential cryptanalysis when this cracking technique was not in the public domain (making DES strong) with a key short enough for the NSA to brute force at a time it was considered too expensive for anyone else to do so. The problem the NSA have with the standards committees is that published security standards are by their nature subject to very intense outside scrutiny, and unpublished ones are less likely to be adequately peer reviewed or widely implemented due to fewer people having the security clearances needed.
The fact the NSA contributed SELinux to the Kernel shows they take objective a. seriously, and it took 2-3 years for this to be properly reviewed and improved before it was considered trustable enough to become part of the mainstream kernel. It must be very hard to hide exploits in open-source code when we know where it comes from given the amount of critical review this piece of source code must have received.
NSA et al probably have an interest because "under the IPv6 system, it will make it easier to link individuals with devices."
Why can I rent one for a few dollars a month?
Wrote :- "if ipv4 addresses are so rare Why can I rent one for a few dollars a month?"
Because you are sharing it with others.
There's a difference between rare and in short supply.
"Why can I rent one for a few dollars a month?" You can!
Yep, that's what he said
Errm...no-one is sharing my static IP thank you.
Because they are not (yet) rationing them by price. That may happen, but for now small quantities are still cheap. If you want lots you cant have them at all.
At some point Amazon EC2 won't be able to get addresses then you will have to switch... Google already went to ipv6 internally.
Even if you dont have a fully integrated IPv6 internal network your firewall should be able to 6over4 for you anyway, then get your server to ipv6 what you need. That way you can still have an IPv6 for your web/email/whatever server and leave your internal network (mostly) alone.
25 years ago I was _given_ 8000 of them, which I still hold.
The expectation then was that we would have to move to ipv6 by the end of the century.
When IPv4 was originally rolled out it was intended as an interim measure with a wide enough address space to cover the "foreseeable future" - which actually meant the 5-10 years it was expected to take to roll out better addressing methods.
By necessity it was a self-described ugly kludge. The fact that it grew legs and hair is mainly down to nothing better actually coming along (IPX - Internet Protocol Exchange - turned out to be an Unroutable Clusterfuck).
As previous commenters have mentioned, this is not necessarily a disadvantage: if everything has a v6 address, everything will need a *monitored* firewall. All those devices won't get that unless they are behind another firewall...which might as well do NAT then.
With regard to our ISP's, having users behind carrier grade NAT makes them the only reliable providers of geolocation data unless you are on a device with GPS and want to send the data direct. Sounds like a money making opportunity to me.
I'm sure v6 will eventually become widespread, and for content providers to be ready *now* is good practice. But for the eyeballs, it really isn't going to be that fast, and ranting nonsense about how we are going to be living in caves if we don't insist of everyone having their own /64 is really getting tired :-(
"As previous commenters have mentioned, this is not necessarily a disadvantage: if everything has a v6 address, everything will need a *monitored* firewall. All those devices won't get that unless they are behind another firewall...which might as well do NAT then."
NAT breaks a lot of things at IPv4 level. That's part of the reason it's disallowed in IPv6.
Firewalling can be done with or without NAT. It's a LOT easier to do without address translation. My home gateway NAT box does this already for its IPv6 stuff and uses about half the CPU on v6 when processing streams, compared to the V4 stuff.
If it wasn't for home NAT gateways and dynamic IP assignments, demand for IPv6 would have reached tipping point 10 years ago. The number of devices _already_ connected to the Internet (intermittently or permanently) is significantly greater than the entire IPv4 pool.
Carrier-grade NAT sounds like a nice idea until you start looking at what the combined effects of your home NAT firewall and a CG-NAT gateway will do (No need to theorise. I've been behind double-NAT a number of times in SE Asia and it's a clusterfuck which is barely tolerable for web/mail use and virtually unusable for evetything else. Want to play CoD, etc? Forget it!)
What amazes me is how willing people are to pile kludge upon kludge in order to stave off the inevitable by a few months. IPv6 _is_ better than IPv4 thanks to 20 extra years of experience in networking between their designs. Naysayers may bleat about 128 bits being excessive but every single estimate of how many devices would appear in future has historically been off by several orders of magnitude and this is unlikely to change in future.
As I've said previously, IPv4 was intended to be around for about 5-10 years as an interim measure. Life has a nasty habit of making "interim measures" the standard even if moving to something better would make things easier all round.
Again, I'm implementing my rule here:
An article telling us all off for being lazy and not implementing IPv6:
- On a tech site that publishes no AAAA records.
- Quoting another tech-law site that publishes no AAAA records.
- When all my systems and external websites and services are IPv6-enabled, even my personal ones, without any problems.
- When ALL modern major operating systems support IPv6 without any excuses.
Sorry, Reg, but until you follow your own advice, you're just hypocrites. As such, I can't comment seriously on any IPv6 or other article until you take the simple step of ringing up your hosting provider (I doubt you do this in-house, right?) and tell them to turn on that feature.
IPv6, SPF, SSL, the rule holds for everything.
Indeed. My own external servers went IPv6 4 years ago; I went IPv6 at home a couple of years ago. It is not hard. Unfortunately I did need to change ISP - my old one did not know what IPv6 meant.
May I use this comment to offer my services to help El Reg implement IPv6.
Seriously Reg, what's your timetable for IPv6 deployment? Has it even been discussed? Has anyone bothered to look into it? How much would it cost? What sort of costs outside of bog-standard network-guy time would it take? Why hasn't it been done up until now? What's the barrier to deployment?
Let's get rid of the junky articles telling us off, and the rubbish about how to back up our VMWare servers (if you don't know how to do that - why the hell are you in charge of running a VMWare server), and the paper-planes-in-space projects and put up an article series on the challenges of getting something like The Reg onto IPv6.
Or is it just that embarrassing that you don't know how to do it, or it would literally take a few lines of code and it would just work?
> My own external servers went IPv6 4 years ago
I converted my servers at about the same time.
It was a great learning experience, but honestly not that useful; I see almost no inbound IPv6 traffic - certainly nothing I'd miss if it disappeared - and my outbound stuff goes over IPv4 without issue.
I'm holding out for whatever comes after IPv6 - when someone realises that 128 bits was a drunken Friday-afternoon joke, and we settle down to something more realistic (perhaps 40- or 48-bits).
Don't use SPF - it can cause all sorts of problems:
> Don't use SPF - it can cause all sorts of problems:
Do use SPF. It only causes problems if you don't bother to read up on what statements you are making.
... Is chock-full of inaccuracy and misdirection. Bogus beyond belief.
Keeps making the same old claim about throwing away email you wanted to send - and that's patently wrong.
SPF is the simplest of simples: it is a way for the *owner* of a domain to specify which machines will send mail on behalf of that domain.
If you don't want to make such a bold statement about your own domain - then don't.
If you want a domain owner not to make such a bold styatement about his own domain, then you need to negotiate with him about how he uses his own property.
I've been using SPF for many years now, and it's a godsend. It *does* require a little care - most notably if you're trying to run an email forwarder. But that is a simple problem to solve, and is the only thing SPF actually breaks - the rest of the noise you'll hear about it is generally when someone wants a domain they don't own to behave differently...
Er, yes, that SPF stuff is just FUD.
Had it deployed for years. Never not received an email intended for me, never had problems sending an email (in fact, without SPF, it's much harder to send an email successfully to the large webmail providers from your own email server).
And, yes, I do check the logs so I know every SPF failure and why it happened (and have greylisting, and DKIM, and lots of other stuff too) and yet still have never "lost" an email in either direction on a dozen or more domains.
Just don't be stupid - use it quite simply to identify your domain's official outgoing mailservers (which are almost always also your MX servers for reception anyway) and don't try to get too clever (the macro crap in SPF is just not worth it).
I say that as someone who is used to doing all sorts of fancy redirection, forwarding, re-enveloping and have THOUSANDS of email addresses, one for each company/website that I deal with at least. SPF isn't a problem. DKIM is a pain to set up and doesn't seem to do much. But the amount of spam that I receive that I *can* reject instantly because of SPF failures is unbelievable and I wouldn't do without it.
SPF check, Spamhaus check, greylist (and thus they are told to "try again later" to send their email, their email is not officially delivered until they do try again - which spammers NEVER do - and otherwise their email is just forgotten about) gets rid of 99.999% of my unwanted email. And I've yet to see a false rejection of genuine email, or spam sneak through that failed any of those check.
Whilst I agree that some of it is FUD, and most issues can be worked around, there is one important thing that got me to stop using SPF, and it has nothing to do with my receiving email - I still use SPF filtering on my servers, along with greylisting etc.
Firstly, it doesn't matter how perfectly you configure your own setup.
I stopped publishing my own SPF records for one important and unavoidable reason:
If the recipient of an email uses aforwarding address, they may no longer get the email you send.
I had number of correspondents who this happened to.
They either had their own domains, or had forwarding for various other reasons.
Their email provider at their final destination was honouring SPF.
My mail to them was being dropped because their forwarding server was obviously not an SPF match for my servers (which used SPF-strict - otherwise what's the point?)
For some friends (who had no control of their email servers) the only option was to get their 'real' address.
This is not always possible, and especially affected me as I tend to reply off-list to a lot of problems posted to mailing lists - in these situations I don't know if an email address is being forwarded or not, and even if it is, I have no way to find out the 'real' address.
So, was my email dropped? Or did the recipient ignore it?
Should I be informed of non-delivery - in my opinion, yes, but many places just assume spam and blackhole the email so as not to create non-delivery spam.
To me, THIS the biggest contributer to making email unreliable - it is not the spam itself, but the systems that silently drop mail they don't deliver.
If any of my systems block an email for any reason, the sender (if legimate) gets to know about it. As this is generally done with a 5xx rejection code, the non-delivery notification itself diesn't generate a new enail.
Incidently, mailing lists that are really 'mail exploders' (i.e. the sender envelope is not set to the list address but left unaltered) break similarly.
If you are sure this hasn't affected any of your outgoing emails. (and your own logs will tell you bugger-all) - or you don't care - then you are lucky.
Personally, I'd like to avoid the crapshoot.
Can't say it's EVER been an issue, and almost every family member I know has email redirection from a different provider to a different webmail or ISP email address.
Note that ALL of my domains forward all of their email (via external hosts and their mail-forwaring, or my own server) to a handful of ACTUAL stored email accounts that I have (including a gmail.com one and an old hotmail.com one). I don't lose emails. And I have SPF setups like mad.
Anyone forwarding has to make a TEENSY TINY change to their forwarding setup if their forwarding setup was basically forging emails anyway (as the SPF FAQ on this says, it's called "remailling" not "forwarding", really). Every open-source MTA has been dealing with the situation since the beginning of SPF and any commercial ones would be dead in the water if they couldn't manage it for the last ten years.
There is zero impact in this - the only thing that changes is that you address the envelope differently rather than trying to pass on messages verbatim (which is a stupid idea anyway). You're forwarding email - the ONE job you need to do is to collect email and send it to someone else - why on Earth would you try to do that by basically "replaying" the SMTP session that you received - it's stupid and nobody does it nowadays (if you know someone who does, name-and-shame).
Every remailer/forwarder I've ever seen uses this envelope-recreation anyway (why would you not want to re-write the actual email address in your envelope to the one you're SENDING EMAIL TO?). It's stupid, un-updated MTA's that have a problem and if you're using one of those exposed to the net unmanaged by someone with half-a-brain you have much bigger problems anyway. They've probably been blocked left, right and centre already for basically attempting SMTP forgery on a huge scale.
Honestly, it's not as big a problem as you make out. One missing email to me would be a HUGE problem, and I monitor closely, and I've NEVER seen this kind of thing in the wild. And I manage networks (including several domains and hundreds of email accounts at every one, most of them set to also "forward" to the user's personal email too at the user's request).
You are MORE likely to have problems if your own mail forwarder is NOT SPF-aware than anything else (and senders won't matter at all).
SPF is an antiforgery tool. It's bloody useful.
The main problem with it is the number of half-assed ways people chooose to use it.
If someone says "these are the only servers authorised to send mail from these domains" why should I disagree with him/her? It's his domain after all.
My (not ISP) router fully supports IP6, including security and port address translation, and my blocklist source has provided IP6 ranges for a while; it can hide my devices too, because it can DHCP devices itself.
You're in the minority then. Most consumer routers don't have any useful degree of support for IPv6. I'm not even sure they know how they're going to present it to customers. I'm convinced that v6 adoption in homes is going to require a hell of a lot of work to present to non-technical customers in a humane fashion. At very least, we'll be needing a name server in every device so we don't have to deal with the actual numbers..
There seem to be a lot of badly broken consumer gear with regard to v6. One actually insisted on having a /48 assigned, rather than a /64. It's improving of course, but there's a lot of breakage there
It is worrying that ISPs seem to be ignoring IPv6, and, the last time I was looking, IPv6 support wasn't even mentioned on the retail packaging of router/modem hardware.
The sudden invocation of privacy concerns is not unexpected, but sticking with IPv4 is not going to stop NSA and GCHQ and their like. They're snooping on us already. My "dynamic" IPv4 address hasn't changed for over a week. It's not like the days of dial-up when the dynamic address was an accident of which ISP modem you were connected to. Should I switch off my broadband connection every half-hour?
My hardware is getting old enough that I am thinking about replacement, chiefly for better wi-fi, but why should I replace it with something that cannot support IPv6? Why should locked into an obsolete system?
I just put my router on a timer switch that turns it off from 3am to 7am and it changes the IP address every day that way. Might cause more disruption for someone else. Not that I believe for one moment the NSA or the like have been anywhere near me or even remotely interested.
Likewise I have a timer switch that turns the router off briefly in the wee hours combined with a startup script that pulls the MAC for the WAN port from /dev/urandom (on dd-wrt). With the browser clearing cookies, local storage, cache etc. on exit this should keep Google and its ilk at least somewhat in check as far as tracking goes. :)
How can an ISP that doesn't provide ipv6 access be legally called an internet service provider. Sure they provide an internet service, but the name kind of assumes that they provide a proper connection.
We need to come up with a name for "ISPs" that don't provide a proper connection to the internet and start using that to distinguish them from actual ISPs,
How about "Limited Internet Service Providers"?
Then you can tell everyone you have a LISP.
"How can an ISP that doesn't provide ipv6 access be legally called an internet service provider. Sure they provide an internet service, but the name kind of assumes that they provide a proper connection."
Ofcom and OFT are already looking at this very issue. Their current PoV is "wait and see" but there are very strong hints that once the majors start deploying IPv6 they'll step in and require anyone not providing IPv6 to very clearly say so.
Mines the one with the /32 of IPV6 in the pocket.
> Mines the one with the /32 of IPV6 in the pocket.
Bah. I've only got a /48 and a /56.
10^24 addresses is so little...
"Without new IPv4 addresses available, new computers, mobile devices, sensors, and other consumer and commercial devices cannot connect directly to the Internet,"
I see no reason why many of the listed devices actually need direct Internet connectivity, this just strikes me as lazy thinking - but that is the IPv6 story....
Biting the hand that feeds IT © 1998–2018