Finally a reason not to bother with IPv6: Uh, security concerns...? For all those sysadmins tired of having to make excuses for why they haven't moved to IPv6, worry no more: the new protocol brings with it the risk of network infiltration. That's according to NATO's Cooperative Cyber Defence Centre of Excellence, which has published a research paper [PDF] claiming it is possible to set up …
""Tunnel-based IPv6 transition mechanisms could allow the setup of egress communication channels over an IPv4-only or dual-stack network while evading detection by a network intrusion detection system,""
So what exactly is stopping this detection system from unpacking the traffic and checking the real contents, also considering the fact that we're talking plain tunneling / encapsulating here and not so much encryption?
Back in the days we used to tunnel our IPSec data across GRE, but check the contents and you could see exactly what was underneath: encrypted data.
In this scenario you can rule out the encryption so... what gives?
Why rule out encryption and how do you inspect IPSec encrypted traffic across anything including GRE?
Bollocks indeed.
One of the principles of IPv6 is IPSec encryption. Tunnelling IPv4 over end to end IPSec encryption precludes inspection. Are you suggesting Man In the Middle IPSec encryption ala Bluecoat with https?
Despite its age IPv6 implementations have a long way to go to reach the maturity of IPv4.
Maturity brings security (due to problems being overcome understood and mitigated).
So what exactly is stopping this detection system from unpacking the traffic and checking the real contents ...
I haven't read the paper, but judging by what it says in the article the point seems not to be that detections systems can't unpack the tunnelled traffic and check it, but that most currently available tunnelling systems don't do so.
In other words: it's a failure of existing tunnelling software, not of the tunnelling mechanism, per se, and certainly not if IPv6 itself.
As you suggest, if the traffic in the tunnel is encrypted it can't be checked in transit, only at the endpoint ... so it's at the endpoint of the tunnel that the checking must take place. This is where the current tools are inadequate.
So what exactly is stopping this detection system from unpacking the traffic and checking the real contents, also considering the fact that we're talking plain tunneling / encapsulating here and not so much encryption?
Maturity. I actually had to look at IPv6 risks about a decade ago for an entity that shall remain nameless, and IPv6 was deemed a massive risk for a number of reasons:
1 - it's still relatively new. That means hardware, drivers, tools, firewalls, proxies, analytics and configuration management are new and pretty much untested, a situation that will not improve until there is more deployment and time.
2 - it has more transport mechanisms. By way of example, extensible headers are an excellent place to run a covert communications channel inside a data stream.
3 - there is limited expertise in the West. Personally, if I were in charge of networking that needed to convert to IPv6 but stay safe I'd contract a Japanese network engineer - as a direct result of the Americans not giving them much IPv4 space to work with, they switched some decades ago and have thus already built up the body of expertise we still need to acquire.
That said, it's not like we didn't have advance warning. The problem is that few were willing to invest in the preparation until it was unavoidable, and that has denied most outfits the required learning curve.
there is limited expertise in the West. Personally, if I were in charge of networking that needed to convert to IPv6 but stay safe I'd contract a Japanese network engineer - as a direct result of the Americans not giving them much IPv4 space to work with, they switched some decades ago and have thus already built up the body of expertise we still need to acquire.
Whilst I see your logic in terms of finding people with largescale experience of IPv6 deployment, I suspect their expertise wrt IPv6 security is also limited. I suspect they have used exactly the same IPv6 product sets as we've been using - namely Cisco et al, complete with their limited security. As if they had delved deeper, we would surely be seeing upgraded firewalls, routers, detection systems etc. from Japanese companies.
Perhaps, we should talk to Japanese network engineers, with experience of IPv6 deployment in Japan, as they could tell us if there are such products in the Japanese domestic market (ie. only currently available with a Japanese UI).
Whilst I see your logic in terms of finding people with largescale experience of IPv6 deployment, I suspect their expertise wrt IPv6 security is also limited. I suspect they have used exactly the same IPv6 product sets as we've been using - namely Cisco et al, complete with their limited security. As if they had delved deeper, we would surely be seeing upgraded firewalls, routers, detection systems etc. from Japanese companies.
That is a valid argument, but I would see hiring people who already have in depth experience as a route to get at least the configuration and setup errors out of the way so we can concentrate more immediately on security instead of being chased by problems that result from inexperience in setup.
But in short I think we still have quite a learning curve ahead of us.
So what exactly is stopping this detection system from ...
As I read the article, the entire article boils down to "security tools haven't been updated to handle IPv6 yet". No sh!t Sherlock !
Well guess what, go back a few years, and tools then didn't detect what we now consider to be "common" threats. Tools improved, tools will improve, what we need is for the vendors to extract digit from orifice and handle "modern" network traffic - where modern could be considered to include "been around for 2 decades".
"security tools haven't been updated to handle IPv6 yet"
Exactly; why blame IPV6 when the problem is with security vendors not updating their software?
This is a problem that the market will fix; as long as some vendors implement IPV6 compatibility in their tools then eventually everyone left in the market will implement, because if you don't you'll be out of business.
This is feature-analysis of network security tools masquerading as a technical assessment of IPV6.
Any network worth being called secure doesn't allow end points direct access to the outside world, by default. Desktops must use a proxy. Servers can't see the internet except by pre-approved firewall exceptions to a specific port.
So how does this 6in4 tunnel traffic work? Via HTTPS proxying? In which case the proxy can _easily_ detect the 6in4 setup sequence, same as it can detect ssh on port 443.
Hmm, the paper says "All network hosts can establish a direct connection to the Internet without proxies or any other connection handlers."
So we're not talking about a secure network, anyway.
"Within the scope of this paper, a covert channel is under- stood as “a network connection that disguises its byte stream as normal traffic” [33]. Protocol steganography [34] for hiding and side-channeling data in unused fields or encoding data in existing field values can be considered a valid technique for covert information exfiltration. However, for newly-developed tool implementations described in this paper, exfiltrated data is directly stored in the protocol payload. This being done in order to test and verify the developed techniques in principle without using additional obfuscation approaches,......,"
So we're not talking about a secure network, anyway.
It is easy to defend against an attack you know. The trick is to detect and defend against an attack you haven't thought about.
In any event, a network-connected system (or a system equipped with any kind of sensors and transmitters or external control devices) under the full control of a determined and resourceful attacker will be able to communicate with a cooperating outside party. If the required bandwidth is low enough, it will be able to do so without detection at the network level.
ob-Lem: Doctor Diagoras
... everything would have moved over to it long ago. That and the fact that it offers no tangible benefits to the end user and even network providers don't seem too bothered about ip4 address space running out given the use of NAT nowadays (and the fact that having every machine directly addressable by ip6 is a security nightmare). Its been around 20 years and the IT industry is still resisting says it all to me.Future proving is one thing, over complicated dogs dinner is another entirely.
My prediction is that ip6 will become the backbone of all main communications lines (it is already with a lot of them) with ip4 being used behind company firewalls and home routers for the forseeable future which means tunnelling is here to stay.
SO much dog poop.
A bunch of admins are so terrified of change they are spreading a lot of FUD. "nobody uses it", "dont bother", "its too complicated", "doesn't have NAT", "no user demand" excuses come up every time the acronym IPv6 is mentioned in public.
From those who have taken the time and migrated there is almost always good things being said, almost the opposite "NAT works", "so easy to manage", "much simpler". Real "network providers" are in fact migrating wholesale and use of IPv4 has dropped below 85% of Internet traffic.
The laggards are corporate admins. You can see it in Googles IPv6 usage graph - 3% drop on Monday morning, 3% jump on Friday evening when work ends. Which makes a little sense if you consider those are the networks without user growth being a factor - the IPv4 they already have will do them a long while. So they will not see pain until the world around them goes IPv6-only and drops the CG-NAT which currently sustains their illusions of IPv4 being useful. That pain point will hit hard and suddenly, possibly overnight on one fateful day.
"excuses come up every time the acronym IPv6 is mentioned in public."
Given how many people are saying that, perhaps you should ask yourself why.
"The laggards are corporate admins."
And who can blame them. They have enough of a workload without having to wrestle with a new transport protocol that when all the money and effort is spent brings precisely nothing to the table.
"That pain point will hit hard and suddenly, possibly overnight on one fateful day"
You underestimate the clout of large corporations.
You underestimate the clout of large corporations.
Large corporations are deploying IPv6 - they are the network providers, since they need to stay in business as they have run out of IPv4 addresses. Go and look at the real penetration of IPv6, its carrying a large percentage of Internet traffic right now.
In regard to non-network focused large corporations - consider what happens when they want to provide their new services to customers - they will not stop just because of a low level technical thing (IPv what ??). They will fire the blockers and bring in people who understand it, deploy the required technology and move on. If you aren't skilled in this, you will simply be sidestepped by someone else who can.
Go ahead and live under your rock if you want, or go and read up on how it actually works and find out its no different to any of the other technologies that looked complex when you first started, but without fail turned out to be a lot easier when you started understanding it.
Your lack of understanding doesn't make it difficult.
As the old adage goes, the person who says its impossible is generally overtaken by the people who are already doing it
"Your lack of understanding doesn't make it difficult."
Pillock. I was programming IP6 support into network servers and clients in C 15 years ago (along with SCTP which DID die a death) when you were probably still playing pokemon, so don't talk to me about understanding. I understand IP6 perfectly well and its overkill for the job, makes simple tasks hard and security a headache. Now run along and try your feeble patronising attempts on someone else.
You expect me to take you seriously with the responses you've made so far ?
You claim that IPv6 brings no benefits, but then you claim you programmed support for the very same protocol for it in a previous decade - which implies that you must have at least a slight understanding of its benefits when you were defining the structs and noticed that they take a few more bytes than before.
Then you claim it makes security a headache - nope, its the exact same concept that IPv4 uses - the firewall allows or denies access, so I doubt your claim of "I understand IP6 perfectly well" - you can't even stuff the v in the middle of the protocol name ffs.
So, I refer to my previous statement. Your lack of understanding doesn't make it difficult.
As to PokeUrMum - sorry - I don't remember her.
You my note that your patronising attempts were unsuccessful, just like your attempts to explain that there are problems in something when there isn't.
"understanding of its benefits when you were defining the structs and noticed that they take a few more bytes than before."
128bit addresses *ARE* part of the problem. There is NO reason for an address that long - and don't even think of quoting IoT at me because 2^128 is approx 10^19 times the number of sand grains on earth! Also frequently having to tell the system which interface to use is an utter PITA because it seems often ip6 can't figure it out for itself!
"ou can't even stuff the v in the middle of the protocol name ffs."
Seriously? That the best you can come up with?
"As to PokeUrMum - sorry - I don't remember her."
Gosh, you're so edgy and risque with that ancient kids insult. How old are you, 16? Do yourself a favour and grow up you silly little boy.
Wow your lack of skill seems to know now bounds, glad I never employed you as a programmer.
Seems that when you can't get people to agree with your misguided view, you get all insulting and hope to force your view that way - well guess what chum, that won't work with me. As to trying to use an age insult - well guess what, I've not seen that before on the Internet, you should try and patent it before someone copies it. BTW you are wrong on that too. I've probably got more grey hair than you too, not that that's significant on this forum.
Lets have a little think about your latest poor assertion that "There is no reason for an address that long"
In case you forgot, old computers in the 70's when the Internet was created were typically 8 or 16 bit, so it was easy to do maths on 4 x 8 bit (i.e. a long), hence the 32 bit addresses used in IPv4. This also mapped well against the relatively small amount of memory in systems of the day and allowed people to use dotted quad notation when working with the resulting addresses, so it was good design on the day.
Now, roll the clock forwards a couple of decades and machines are typically 32 or more commonly 64 bit, so doing maths on 4 x 32 bit or 2 x 64 bit is trivially easy too since it maps to two 64 bit registers that are common in the hardware, hence the 128 bit addresses,
Doing it on a smaller bit length just doesn't make sense, whereas the longer bit length allows for far greater structure on the allocation of addresses which helps significantly with global routing on the core Internet routers.
If you looked closely, you would see that most of the routing on the outside of a company (i.e. on the core or at the ISP level) is done only on the most significant 64 bits, which improves performance and aligns nicely to the bit length in 64 bit hardware. You might also notice that the least significant 64 bits are handled within the end customers network generally as a single subnet, again for simplicity on implementation. Those that want a /56 or similar (hey look, nicely 8 bit aligned) or a /48 (hey look nicely 16 bit aligned) have minimal routing to do in the lower bits of the upper register, so yet again well structured and easy to code or put into hardware.
You might also notice that the addresses continue with the simple dotted formation, but to differentiate them from their predecessors and take advantage of the longer bit length they just uses colon for separation and 32 bit hex for the segments of the address, This is yet another benefit of IPv6, you can subnet down to any nibble and get meaningful and readable addresses which is far better than the "only works on 8 bit boundaries" that IPv4 enforces due to the use of decimal formatting. Network engineers care about little details like this.
So, with that background and as a supposedly expert programmer, I'be be interested in your view on how you think that could be improved from you assertion that its not optimal - as once again, clearly you are wrong.
Its clear that the designers put a lot of thought into the addressing and what happens at the network layer and how that would be handled within hardware from a network optimised implementation on custom network hardware with something like an FPGA in it, which can then deliver high performance. Alternately, it can scale right down to a low power system with fairly easy software implementation in a similar manner.
Now, if your routing isn't working right - then that probably flows back to a lack of knowledge on how IPv6 or more specifically routing works as it seems to work OK for everyone else, unless of course its running your code and there is a bug in it that you need to look at.
Oh - and BTW - you can stop acting like a prat too. Do try and cheer up, its Easter.
"Wow your lack of skill seems to know now bounds, glad I never employed you as a programmer."
You've never employed anyone.
"you get all insulting and hope to force your view that way"
Pot meet kettle.
"I've probably got more grey hair than you too, not that that's significant on this forum."
No sunshine, no one over 25 uses "ur mum" jokes unless they're special needs. Are you?
As for the rest of your cut-n-paste fatuous BS where you try to sound intelligent and that you have a clue, I gave up after the first page of irrelevant missed-the-point-by-a-country-mile rubbish - lifes too short. Feel free to post another treatise, however I won't be reading it. I've got some paint I can watch drying instead.
See, more and more of the same dismissive BS that tries to cover your lack of understanding of anything technical.
As for the facts and straight questions on how you would do it better - you have absolutely no answers. That's either because you know you are wrong or can't provide a sensible answer. Go on then, pick any part of the technical bit and prove me wrong ..
Cut-n-paste - nope, you are wrong on that as well (see the trend here). Go try and match any part of it on your favourite search engine and see for yourself. You might even learn something about IPv6 with the pages you end up landing on.
I had hoped that as you claim to be an experienced C programmer then you might get the low level mapping of bit fields as it allows efficient efficient code to be written, but you have shown from your lack of responses and attempts to be patronising that you can't do this either.
You are a waste of time and I shall not engage any further with you on this topic as you are not worth the effort.
Most people moaning about the take up rate for IPv6 do not have a clue about how organisations use IPv4 and the challenges they have moving. It's not all about connecting to Facebook or google.
When your business systems have been built on IPv4, the designers, architects and programmers long gone, your locked into legacy systems that barely function on IPv4 without an array of cludges, it's impossible to migrate that mess to IPv6. It needs a rebuild and no one wants to spend the money rebuilding something that works reliably. Permitting the public IPv6 access to your website is trivial in comparison and I imagine reverse proxies are already in place providing invisible translation.
IPv6 has many many flaws, many of which could have been designed out if they bothered to learn IPv4's lessons or if it was developed later. The design of IPv6 looks like Ethernet protocol engineers took umbrage at tcp/ip and tried to make a better l3 that could replace l2, the original intent of course for IPv6 to use the interface MAC address for the last part of its l3 addressing. The anti NAT posture was relevant in the 90's but we have all moved on now and NAT is a valid mechanism for obfuscation and preventing unsolicited access across routed domains. Don't fall into the trap believing a firewall is the great saviour. Firewalls protect badly configured systems from unwittingly exposing vulnerable connection sockets. If the application had proper security controls there would be no need for a separate system to protect it. A firewall configured to allow access will not prevent a vulnerable app from being compromised, fixing the buggy software does that. Hundreds of millions of phones and tablets that are used to process and store sensitive information are on the internet right now with no firewall and have not caused a huge security incident as they have not been compromised.
We need a better IPv6 or IPv8 or whatever, one that is backward compatible so the many thousands of internal legacy systems still work and takes into account the many lessons learnt in IPv4 that won't or can't be incorporated in IPv6, proper one to one NAT being the most obvious missing piece. Proper NAT goes a long way to migrating to a new system.
We are not terrified. We just want a better solution. IPv6 is broken, introduces security issues resolved years ago in IPv4, adds additional complexity (how many IP's per host and when you have 2 or more on a subnet how do you tell which one is sending traffic when your a hop away & the hosts are continually changing IP??)
IPv4 is structured and ordered, IPv6 is expansive and determined to be borderless and boundless, which makes security accountability and auditing difficult for professionals with thousands of £$ of tools and near impossible for the typical home user.
there are not enough AutoBots to save us from the Decepticons come IPv6 judgement day.
the fact that having every machine directly addressable by ip6 is a security nightmare -- sure would be nice if we could lay this particular meme to rest. No, it's not a security nightmare. Freely allowing anybody to connect to you might well be, but that's not what "globally unique address" means.
Remember all those hacked IoT devices? They get hacked because people expose them to the web so they can watch their camera from work or whatever. If they were running on v6 they'd be much less likely to get hacked, because the sheer size of v6 makes it much harder to port scan for exposed devices. How is that a security nightmare? v4 is the nightmare here.
Calling v6 "determined to be borderless and boundless" is also weird, because it's not. You've still got separate networks with their separate subnets and you've still got routers that manage access control between subnets and can do auditing or whatever else you want. The only difference is that you're not forced to rewrite addresses on packets due to a crippling address shortage, which is good because it makes your network simpler which makes it easier to secure.
"Expansive" is accurate though. I submit that it's a good thing to be, not a bad thing.
I never thought I'd see so many luddite comments here. A quick reply to some of the points:
1) There is nothing difficult with it.
2) Companies are avoiding it simply for upgrade cost reasons, it has nothing to do with the protocol itself.
3) The article mainly focuses on IP6-IN-IP4 tunnels. Therefore any issue is a problem with software that can't parse tunneled data on IP4. What has that got to do with IP6? If my own new whizzo protocol doesn't get picked up by so called intrusion detection software, how does that make my protocol at fault?
4) "It should have been made backwardly compatible" blah blah. With all the dual stack offerings, and tunnelling protocols, and single-stack-that-will-process-both-ip6-and-ip4, and the fact the two can coexist on the same wire, what more could you ask for? Those who think an Ip4 address could be shoehorned into an ip4 header and still somehow work with unmodified ip4 stacks are obviously clueless. Ok, so what about IP6 stacks being able to accept IP4? Guess what? THEY CAN!
5) What's all this nonsense someone commented about ip6 being less ordered than ip4? They are both equally ordered systems, but with the HUGE issue there aren't enough IP4 addresses, so creating a need for loads of routing rules for similar network ranges with totally different network topologies. (Though I do concede that recommending a single lan has at least a /64 is a stupid idea. Who cares about shoe-horning mac addresses? and auto-configuration is easier on ip6 anyway, so that justification is bogus)
6) The fact IP6 addresses are so big means that problem can be avoided. Couple this with the fact that things like reverse dns resolution can be partitoned down to a resolution of /4 instead of an /8 and you're quids in.
7) It's directly addressable! It's a security risk! Firewalls work as with ip4. Yes, residential ip4 networks have been lagely protected by nat, but that's a consequence of the restriction, not by design.. Maybe we should drop packet based comms alltogether, and run some single-connection thing, like a sort of faster rs232? That would be even more secure than ip4, does that make it a better solution? And for the really stuckists,, you can even use nat on ip6 if you really are so stubborn as to make your job harder.
Any techie scared of ip6 has no business being involved in any IP networking. Period.
Hell, some of you sound like a bunch of old people:
"Oh, I don't undestand that new fangled thing. Much simpler to only have 4 tv channels which you select from 4 buttons on the front of the machine"Time-shifting? That sounds like science fiction to me - nothing wrong with having my luch at 1pm promptly and catching the 1.00 new as it's shown"
And as for the security freakouts, you sound like guys in the past:
"Those motor car things are needlessly complicated. Nothing wrong with a good horse and carriage. Oh, and they are a flawed design - they are more dangerous because they can go faster... And security?? Anyone can create a crime and be the other side of the country in a few hours. And anyway, Joe Bloggs and all the other farms haven't replaced all their stables with these motors, and they should know what they are doing. cars are a danger, a security risk, and over complicated - they aren't even compatible with horses!. I can't wait for them to finally die out and we can then come up with a new more sensible way to progress"
""Those motor car things are needlessly complicated. Nothing wrong with a good horse and carriage. "
If a horse could cruise at 80mph for hours on end without needing a rest, be refuelled in 2 minutes and go 400-800 miles on a single bale of hay, only need maintaining once every month rather than every day, have air conditioning and in car entertainment, not randomly bolt at loud sounds or dogs and a predictable temperament that analogy might have a fighting chance of being valid.
However I'm frankly still waiting for anyone to tell me the advantage to a company to spend potentially millions on upgrading their kit and possibly retraining their IT staff to roll out IP6. After all that, what exacdtly do they have that they didn't have before with IP4 from a business POV? Take your time.
My ISP in the US has enabled IPV6 its one of the largest in the country. While there are still issues with the complexity I agree with, such as weird behavior on NAS devices and others, I think many industries have relegated that they will do it.
I just bought a new AC router a few months ago and it fully supports IPV6. While the one I bought isn't as robust as I would have liked in the IPV6 firewall area its a step in the right direction vs one I bought just 3 years ago that didn't support it. I use a chrome plugin called IPvFoo which shows me that quite a few sites support IPV6 outright or at least use a hybrid and to be honest I was supprised that so many sites are fully IPV6 granted it could just be the sites I use but Id say 20-25% or so seem to be least using IPV6 or at least have it available through their ad companies etc.
The register though is not one of those sites using IPV6 but of course google and their ad companies are ...lol
"The register though is not one of those sites using IPV6 but of course google and their ad companies are"
Microsoft doesn't, last I checked [except on a few specific servers, last time I sniffed a win-10-nic VM that had IPv6 enabled, which might not actually be theirs, and was probably over a year ago].
Which brings me to the REAL source of the problem: Imagine EVERY! WINDOWS! CLIENT! in the world having a PUBLICALLY! VIEWABLE! IP! ADDRESS!!! [yes, the "no NAT" FUD rears its ugly head].
Truth is that IPv6 CAN be NAT'ted, but nobody will bother doing it. It's truly better if it's FIREWALLED to block ALL of the listening ports that Micro-shaft suddenly FEELS it needs to listen on, but EVERY! STINKING! VERSION! of Windows since XP has been listening on open ports bound to "::" or 0.0.0.0 and the list of ports GROWS (and occasionally MORPHS) with each release. And those ports are (more or less) "well known" especially to those who might want to use them for nefarious purposes (and when new ones show up, they'll be known, too).
So what is the _CAUSE_ of the IT "my computer got hacked while I was on the corporate network" problem? That's right, it's MICROSOFT that CAUSES the problem, with their far-less-than-adequate approach to security. 'Microsoft Firewall' - what a joke. Anyone ELSE remember 'code red'? 'Win Nuke'? Look forward to more of the same when every Windows box is exposed unfiltered to the intarwebs.
Of course this COULD be fixed. By Micro-shaft. But they don't even bother implementing their OWN IPv6, and last time they TRIED, they completely cluster-blanked it...
http://www.theregister.co.uk/2017/01/19/windows_10_bug_undercuts_ipv6_rollout/
(I just checked, and microsoft.com _STILL_ has no AAAA records)
bob: say it with me: "NAT is NOT a security device!"
Just about any router worth its salt that can grok IPv6 can block inbound IPv6 connections by default just as easily as it can IPv4 without NAT. This is basic stateful firewalling aka connecion tracking in Linux. Hell Verizon Wireless does this automatically for all of their IPv6 clients.
bob: say it with me: "NAT is NOT a security device!"
+1000 upvotes @s2bu
I'd only add that any ordinary home router defaults to UPnP enabled, so extending the thinking into how that affects security - the firewall helpfully provides inbound connections direct to any device on the LAN that asks - straight through to the firewall and any NAT layer and directly onto your supposedly secure home network.
This is why all the IoT devices keep getting hacked - the actual level of security is far lower than most people believe it to be.
No IPv6 usage ... please re-check your homework
C:\>nslookup
> www.microsoft.com
Non-authoritative answer:
Name: e1863.dspb.akamaiedge.net
Addresses: 2a02:26f0:c8:287::747
2a02:26f0:c8:281::747
2.20.160.103
Aliases: www.microsoft.com
www.microsoft.com-c-2.edgekey.net
www.microsoft.com-c-2.edgekey.net.globalredir.akadns.net
So, nice IPv6 addresses clear to see
OK they are using Akami's CDN, but that is to be expected as they have a lot to distribute with their new OS every week and that's what CDN's are for.
if you use a proxy between endpoints of an SSH connection, like a firewall appliance or 'man in the middle' attack, the side that connects would need to accept the new cert. The server cert mismatch warning would be there, and the person connecting would have to make a decision about it. So it's not perfect, but should be ok if not connecting for the first time through a proxy or 'MITM' .
(and if connecting for the first time you get a different warning)
Actually, if they rolled it out to you, you'd be able to do IPv6 without worrying about this particular thing.
The article is quite clear that the security weakness stems from a lack of deep inspection of the encapsulatED packets. Yes, firewalls inspect the encapsulatING packet (GRE, IP-IP, etc.), but many do not sufficiently inspect the contents.
If you have native IPv6 access provided by your ISP, you do real IPv6 and turn off your tunnelling, and you can inspect the traffic. (You get other problems, but you can at least filter the IPv6 traffic and de-filter the encapsulation protocols.)
However I'm frankly still waiting for anyone to tell me the advantage to a company to spend potentially millions on upgrading their kit and possibly retraining their IT staff to roll out IP6.
At some stage IPv4 spaces will run dry and if you already have IPv6 running then you will be ahead of the game and built up more knowledge than a great many others which makes you worth more to others who have yet to start their roll out. :-)
Remember that pesky thing called Y2K? I remember watching a TV doco in the mid 70s about this upcoming problem, MID 70s, and nothing got done until the last couple of years before 2000 and what a panic that was. Hell, even Microsoft didn't make Windows 98 (or was it 98SE) Y2K compliant when it was released. Now if only they had known about this problem in say the 1970s then there wouldn't have been the panic.........oops wait......
I suspect that the very late implementation to fix Y2K was a big con in an attempt to panic those with the ability to afford it and to get them to pay more than the going rate. If the fix had been started when the problem became known, sorry, when it was economically feasible to add the extra RAM and then have the memory to include all 4 digits of the year, then this could have been rolled out at leisure over 15 or more years instead of the last 2 or 3. Some people made a stack full of dosh over Y2K. Shame I wasn't one. :-(
Paris, coz she is sad I didn't make a bundle out of Y2K as well.
The point of v6 isn't to give you new fancy stuff. It's to let you keep your fancy stuff, which you're otherwise going to lose.
We're out of bales of hay, and we can't make more of them. Yes, the horses are still working, but soon enough they're not going to be working. But we'd still like to have some form of transport. So what if the new transport still only goes at 80mph, and still doesn't have a range bigger than 400-800 miles? At least it's not dead.
I suspect that the very late implementation to fix Y2K was a big con
Yeah... probably not. Humans are UTTERLY TERRIBLE at long-term planning and will put things off until they absolutely can't, regardless of how costly that is to them. Just look at, say, cigarettes. Putting Y2k off until Y1.999k is completely consistent with that.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
