Companies - 2

Little bit of background about having certificates

A quote from https://www.brightedge.com/blog/http-https-and-seo/:

Google called for “HTTPS Everywhere” (secure search) at its I/O conference in June 2014 with its Webmaster Trends Analyst Pierre Far stating: “We want to convince you that all communications should be secure by default”

So, anybody with any sense in their head have moved to having their website prefer HTTPS as the communication protocol. For that to happen, a SSL certificate is required. In practice any X.509 would do the trick of encryption, but anybody visiting your website would get all kinds of warnings about that. An excellent website having failing certificates is https://badssl.com/. The precise error for you would see having a randomly selected certificate can be demonstrated at https://untrusted-root.badssl.com/.

Google, as the industry leader, has taken a huge role in driving certificate business to a direction it seems fit. They're hosting the most used website (google.com, according to https://en.wikipedia.org/wiki/List_of_most_popular_websites) and  the most used web browser (Chrome, according to https://en.wikipedia.org/wiki/Usage_share_of_web_browsers). So, when they say something, it has a major impact to the Internet.

What they have said, is to start using secured HTTP for communications. There is an entire web page by Google about Marking HTTP As Non-Secure, having the timeline of how every single website needs to use HTTPS or risk being undervalued by GoogleBot and being flagged as insecure to web browsing audience.

Little bit of background about what certificates do

Since people publishing their stuff to the Net, like me, don't want to be downvalued or flagged as insecure, having a certificate is kinda mandatory. And that's what I did. Couple years ago, in fact.

I have no interest in paying the huge bucks for the properly validated certificates, I simply went for the cheapest possible Domain Validated (DV) cert. All validation types are described in https://casecurity.org/2013/08/07/what-are-the-different-types-of-ssl-certificates/. The reasoning, why in my opinion, those different verification types are completely bogus can be found from my blog post from 2013, HTTP Secure: Is Internet really broken?. The quote from sslshopper.com is:
"SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate."

Nowhere in the technical specifcation of certificates, you can find anything related to actually identifying the other party you're encrypting your traffic with. A X.509 certificate has attributes in it, which may suggest that the other party is who the certificate says to be, but's an assumption at best. There is simply no way of you KNOWING it. What the SSL certificate industry wants you to believe, is that they doing all kinds of expensive verification makes your communications more secure. In reality it's just smoke and mirrors, a hoax. Your communications are as well encrypted using the cheapest or most expensive certificate.

Example:
You can steal a SSL certificate from Google.com and set up your own website having that as your certificate. It doesn't make your website Google, even the certificate so suggests.

Little bit of background about Symantec failing to do certificates

Nobody from Symantec or its affiliates informed me about this. Given, that I follow security scene and bumped into news about a dispute between Google and Symantec. This article is from 2015 in The Register: Fuming Google tears Symantec a new one over rogue SSL certs. A quote from the article says:

On October 12, Symantec said they had found that another 164 rogue certificates had been issued
in 76 domains without permission, and 2,458 certificates were issued for domains that were never registered.

"It's obviously concerning that a certificate authority would have such a long-running issue
and that they would be unable to assess its scope after being alerted to it and conducting an audit,"

So, this isn't anything new here. This is what all those years of fighting resulted as: Replace Your Symantec SSL/TLS Certificates:

Near the end of July 2017, Google Chrome created a plan to first reduce and then remove trust (by showing security warnings in the Chrome browser) of all Symantec, Thawte, GeoTrust, and RapidSSL-issued SSL/TLS certificates.

And: 23,000 HTTPS certs will be axed in next 24 hours after private keys leak.

In short:
They really dropped the ball. First they issued 164 certificates, which nobody actually ordered from them. Those rogue certificates included one for google.com. Then they somehow "lost" 23k private keys for already issued certificates.

That's really unacceptable for a company by their own words is "Global Leader In Next-Generation Cyber Security". That's what Symantec website https://www.symantec.com/ says, still today.

What next?

Symantec has a website called Check your website for Chrome distrust at https://www.websecurity.symantec.com/support/ssl-checker.

I did check the cert of this blog, and yup. It flagged the certificate as one needing immediate replacement. The certificate details have:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            24:6f:ae:e0:bf:16:8d:e5:7a:13:fb:bd:1e:1f:8d:a1
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=GeoTrust Inc., CN=RapidSSL SHA256 CA
        Validity
            Not Before: Nov 25 00:00:00 2017 GMT
            Not After : Feb 23 23:59:59 2021 GMT
        Subject: CN=blog.hqcodeshop.fi

That's a GeoTrust Inc. issued certificate. GeoTrust is a subsidiary of Symantec. I did study the history of Symantec' certificate business and back in 2010 they acquired Verisign's certificate business resulting as ownership of Thawte and GeoTrust. RapidSSL is the el-cheapo brand of GeoTrust.

As instructed, I just re-issued the existing certificate. It resulted in:

Now, my certificate traces back to a DigiCert CA root.

That's all good. I and you can continue browsing my blog without unnecessary this-website-is-not-secure -warnings.

If you're lucky enough to get to go to a really cool event, it may be handing out a Xyloband to everybody attending it.

For those who've never heard of a Xyloband, go see their website at http://xylobands.com/. It has some sample videos, which this screenshot was taken from:

See those colourful dots in the above pic? Every dot is a person having a Xyloband in their wrist.

The thing looks like this:

As you can see, mine is from King's Kingfomarket, Barcelona 2017. There is an YouTube video from the event, including some clips from the party at https://youtu.be/lnp6KjMRKW4. In the video, for example at 5:18, there is our CEO having the Xyloband in his right wrist and 5:20 one of my female colleagues with a flashing Xyloband. Because the thing in your wrist can be somehow remote controlled, it will create an extremely cool effect to have it flashing to the beat of music, or creating colourful effects in the crowd. So, ultimately you get to participate in the lighting of the venue.

After the party, nobody wanted those bands back, so of course I wanted to pop the cork of one. I had never even heard of such a thing and definitely wanted to see what makes it tick. Back of a Xyloband has bunch of phillips-head screws:

Given the size of the circular bottom, a guess that there would be a CR2032 battery in it is correct:

After removing the remaining 4 screws, I found two more CR2016 batteries:

The pic has only two batteries visible, but the white tray indeed has two cells in it. Given the spec of a button cell (https://en.wikipedia.org/wiki/Button_cell), for a CR-battery it says: diameter 20 mm, height 3.2 mm. So, if you need 6 VDC voltage instead of the 3 VDC a single cell can produce, just put two CR2016 instead of one CR2032. They will take exactly the same space than a CR2032, but will provide double the voltage. Handy, huh! My thinking is, that 9 VDC is bit high for a such a system. But having a part with 6 volts and another part with 3 volts would make more sense to me.

Plastic cover removed, the board of a Xyloband will look like this:

Nylon wristband removed, there is a flexing 4-wire cable having 8 RBG LEDs in it:

The circuits driving the thing are:

Upper one is an Atmel PLCC-32 chip with text Atmel XB-RBG-02 in it. If I read the last line correctly, it says ADPW8B. Very likely a 8-bit Microcontroller Atmel tailored for Xylobands to drive RBG-leds.

The radiochip at the bottom is a Silicon Labs Si4362. The spec is at https://www.silabs.com/documents/public/data-sheets/Si4362.pdf. A quote from the spec says:

Silicon Labs Si4362 devices are high-performance, low-current receivers  covering the sub-GHz frequency bands from 142 to 1050 MHz. The radios are part of the EZRadioPRO® family, which includes a complete line of transmitters, receivers, and transceivers covering a wide range of applications.

Given this, they're just using Silicon Labs off-the-shelf RF-modules to transmit data to individual devices. This data can be fed into the Microcontroller making the RBG LEDs work how DJ of the party wants them to be lit.

While investigating this, I found a YouTube video by Mr. Breukink. It is at https://youtu.be/DdGHo7BWIvo?t=1m33s. He manages to "reactivate" a different model of Xylobands in his video. Of course he doesn't hack the RF-protocol (which would be very very cool, btw.), but he makes the LEDs lit with a color of your choosing. Of course on a real life situation when driven by the Atmel chip, the RBG leds can produce any color. Still, nice hack.

I got and ad from Microsoft about a security summit they were organizing. Since it was virtual, I didn't have to travel anywhere and the agenda looked interesting, I signed up.

Quotes:

Discussion points:

• Security hygiene
  • Run patches to make your stuff up-to-date
  • Control user's access
  • Invest into your security, to make attackers ROI low enough to attack somebody else
• Security is a team sport!
  • Entire industry needs to share and participate
  • Law enforcement globally needs to participate
• Attacks are getting more sophisticated.
  • 90% of cybercrime start from a sophisticated phishing mail
  • When breached, new malware can steal domain admin's credentials and infect secured machines also.
  • Command & control traffic can utilize stolen user credentials and corporate VPN to pass trough firewall.
• Attackers are financially motivated.
  • Ransomware
  • Bitcoin mining
  • Petaya/Notpetaya being an exception, it just caused massive destruction
• Identity is the perimeter to protect
  • Things are in the cloud, there is no perimeter
  • Is the person logging in really who he/she claims to be?
  • Enabling 2-factor authentication is vital

Finally:

Since last July, this blog has been running in Microsoft Azure.

In January, Microsoft informed me, that I need to update my payment information or they'll cut off my service. Ever since, I've been trying to do that. For my amazement, I still cannot do it! There are JavaScript errors in their payment management panel, which seem to be impossible to fix.

So, eventually I got a warning, that they will discontinue my service unless I pay. Well ... I'd love to pay, but ... For the time being, all I can do is backup the site and plan for setting up shop somewhere else. This is so weird!

As an employee of (a subsidiary of) Activision/Blizzard, last year those who wanted, got keys for Destiny 2.

It never worked! I never go to play it.

On game launch:

... and BANG! The dreaded Nightingale error:

For past couple of months, that's how much I saw Destiny 2. That isn't much. Darn!
Actually, there is an Internet full of people having the same problem. There are various solutions to, which have worked for some people and for some, not so much.

After doing all the possible things, including throwing dried chicken bones to a magical sand circle, I ran out of options. I had to escalate the problem to Blizzard Support. Since this wasn't a paid game, obviously it didn't reach their highest priority queue. But ultimately the cogs of bureaucracy aligned and I got the required attention to my problem. But ... it was unsovalvable. Or it seemed to be one.

Today, after escalating the problem back to Bungie, they pointed out the problem. My computer didn't manage to reach their CDN, so the game got angry and spat the Nightingale on my face. They also hinted me about what my computer did instead and ...

Somewhere in the guts of the Destiny 2, there is a component reading the value of environment variable HTTP_PROXY. I had that set on the PC because of ... something I did for software development years ago.

After deleting the variable, the game started. WHOA!
So, it wasn't my router, DNS, firewall, or ... whatever I attempted before. Problem solved!

MaxMind GeoIP is pretty much the de-facto way of doing IP-address based geolocation. I've personally set up the database updates from http://geolite.maxmind.com/download/geoip/database/ to at least dozen different systems. In addition, there are a lot of open-source software, which can utilize those databases, if they are available. Wireshark, IPtables, Bind DNS, to mention few.

The announcement on their site says:

We will be discontinuing updates to the GeoLite Legacy databases as of April 1, 2018. You will still be able to download the April 2018 release until January 2, 2019. GeoLite Legacy users will need to update their integrations in order to switch to the free GeoLite2 or commercial GeoIP databases by April 2018.

In three month's time most software won't be able to use freshly updated GeoIP databases anymore for the sole reason, that NOBODY bothered to update to their new .mmdb DB-format.

To make this clear:
MaxMind will keep providing free-of-charge GeoIP-databases even after 1st April 2018. They're just forcing people to finally take the leap forward and migrate to their newer libraries and databases.

This is a classic case of human laziness. No developer saw the incentive to update to a new format, as it offers precisely the same data than the legacy format. It's just a new file format more suitable for the task. Now the incentive is there and there isn't too much of time to make the transition. What we will see  (I guarantee you this!) in 2019 and 2020 and onwards software still running in legacy format using outdated databases providing completely incorrect answers.

This won't happen often, but these outdated databases will reject your access on occasion, or claim that you're a fraudster.

UUUJEA!

Com Hem has been rolling out a native SLAAC/DHCPv6-based IPv6 to it's entire customer base, and they took a very important step 2 in their project. They started honoring Prefix Delegation -requests! To a non-network person that means absolutely nothing, but to a network administrator that is really a game changer!

Normally I don't use much of the features my Sagemcom cable-TV -router has, it's just set to bridge:

Since I failed earlier to get a prefix from my ISP, I was toying around with my router and set it to router-mode, and to my great surprise:

The thing issued my LAN a /64 IPv6-network! Nice.
After putting everything back and eye-balling the DHCPv6 lease file on my Linux-router:

lease6 {
  interface "enp1s0";
  ia-pd c4:d0:0a:85 {
    starts 1515858667;
    renew 302400;
    rebind 483840;
    iaprefix 2a04:ae00::/56 {
      starts 1515858667;
      preferred-life 604800;
      max-life 2592000;
    }
    option dhcp6.status-code success;
  }
}

Yes, it contains an ia-pd -section! The iaprefix from the file is mine, only mine, my precious address space!
I have no idea how long they have been honoring my PD-requests, but on December 17th they didn't.

A generally accepted IPv6-deployment principle is to follow RFC 5375 [IPv6 Unicast Address Assignment Considerations]'s suggestions and issue a minimum of /64 (18E IPv6 addresses) to customers. Since this /64 is completely useless for your own LAN, a second suggestion is to issue a /48 (1,2 million E IPv6 addresses) or /56 (4700E IPv6 addresses) prefix for consumer's own LANs.
Note: 18E is SI-prefix for exa, aka 10^18. A /64 IPv6 network has 18,446,744,073,709,551,616 unique addresses in it.

The numbers are astronomically big and it's quite easy to get confused and lose the perspective what they actually mean. A more concrete approach is, that by being issued a /56, I can now split my prefix into 256 separate /64 networks as I please. It's not like I need 256 LANs, I'm totally happy get even 1 of them to work!

Now I have my hands full to configure and test everything on my LAN. I need to make sure, that native-IPv6 works for wired and wireless toys I have here.

A month ago my ISP sent information that they're upgrading my connection speed without increasing the monthly cost! Nice. Totally unexpected from them.

Couple weeks ago my internet connection had dropped during night and I just flicked the switch on the cable router and it all came back. What I didn't initially realize, that I had an IPv6-address! WHOA!

Given zero public information about this on their public website, customer portal or anywhere, I just saw that on my network interface while investigating an another issue. They are broadcasting router advertisements and allocating a /64 from 2A04:AE00::/26 (SE-COMHEM-20140210). It looks like this on radvdump:

interface enp1s0 {
   AdvSendAdvert on;
   # Note: (Min,Max)RtrAdvInterval cannot be obtained with radvdump
   AdvManagedFlag on;
   AdvOtherConfigFlag on;
   AdvReachableTime 600000;
   AdvRetransTimer 0;
   AdvCurHopLimit 64;
   AdvDefaultLifetime 9000;
   AdvHomeAgentFlag off;
   AdvDefaultPreference high;
   AdvSourceLLAddress on;
   AdvLinkMTU 1500;
}; # End of interface definition

Since the O-bit for "other" (AdvOtherConfigFlag on) is enabled, it means that a DHCPv6-request will get more usable information. A DHCPv6 lease will look like this:

lease6 {   interface "enp1s0";
  ia-na xx:xx:xx:xx {
    starts 1512476381;
    renew 302400;
    rebind 483840;
    iaaddr 2a04:ae07:yyyy:yy::yyyy {
      starts 1512476381;
      preferred-life 604800;
      max-life 2592000;
  }
  option dhcp6.status-code success;
  }
  option dhcp6.client-id 0:1:2:3:4:5:6:7:8:9:a:b:c:d:e:f:10:11;
  option dhcp6.server-id 0:1:0:1:53:f:97:74:0:50:56:a8:22:a4;
  option dhcp6.name-servers 2a04:ae3a:ae3a::1,2a04:ae3a:ae3a::2;
}

It works and is fast and all, but ... (there's always the but part). Given SLAAC, they issue only a /64 prefix. Why is that a problem you ask. Well, to be able to issue an IPv6 address to all devices in my LAN, that's not enough.

I tried sending a Prefix Delegation -request via DHCPv6, but no. They didn't honor that request. Should that worked, I'd be happy. I'd have my own /48 prefix for my LAN-devices.

In the current form Com Hem's IPv6 is mostly useless as none of my actual devices have IPv6 addresses in them. I'm investigating this and if/when I find a solution for this, I'll post something about it. Meanwhile, if you know how to get a prefix out of them, please inform!

In Finland and Sweden, all major movie theaters are owned by Bridgepoint Advisers Limited. In Finland, the client-facing business is called Finnkino.

Since they run majority of all viewings of moving pictures, they also sell the tickets for them. When a superbly popular movie opens for ticket sales, the initial flood happens online. What Finnkino is well known is their inability to do capacity planning for online services. Fine examples of incidents where their ability to process online transactions was greatly impaired:

• 2015: Star Wars: The Force Awakens 
• 2016: Rogue One: A Star Wars Story
• 2017: Star Wars: The Last Jedi

The sales of movie tickets happens trough their website. I'd estimate, that 100% of their sales, either eletronic or physical points-of-sale, is done via their sales software. The system they're using is MCS, or MARKUS Cinema System, which according to their website "can be deployed both on premise and on Microsoft Azure". Out of those two options, guess which mode of deployment Finnkino chose!

Quick analysis indicates, that their site is running on their own /28 IPv4 network. Nice!
Based on eyewitness reports, their entire system is heavily targeted to serve the local points-of-sale, which were up and running, but both their online sales and vending machines were down. So, I'm speculating, that  their inability to do proper capacity planning is fully intentional. They choose to throw away the excess requests, keep serving people waiting in queue for the tickets and sell the tickets to avid fans later. That way they won't have to make heavy investments to their own hardware. And they escape from this nicely by apologizing in Twitter: "We're sorry (again)." And that's it. Done!

Hint to IT-staff of Finnkino: Consider cloud and/or hybrid-cloud options.

If you own your company and happen to use any Google services (I do both), then you're very likely to be approached by Google's AdWords marketing. They are pitching you initial free credits to use for your ads. Since my business really doesn't rely on advertising, or marketing or anything of such nature, I typically ignore any approaches regardless who is contacting me.

Google has this approach, that they send you snail-mail and the letter will contain a credit-card sized laminated card contaning my business' name and a discount code to be used during registration. As there are nice € sums of money in them, I never threw any of those away. And it so happened, that since I kept ignoring Google's marketing machine, they just kept sending me those cards over and over again.

Here:

There is 1150,- € worth of free advertising in those.

You at Google:
Keep sending them, I'll keep collecting them. And amp up the values, I won't even flinch with your 150,- € coupons!
Go big! Go for 500,- € or even bigger!

I had a simple task at hand, to draw a flowchart how information is exchanged in a distributed system. Since I din't have my Microsoft Visio installed in that machine and the task was rather simple, I chose to try the Google Drawings and learn it. Easy as pie, right? Nope.

As one of the first things I wanted in my flowchart was "regular Jane User" and I wanted shape of a laptop computer to represent her. Well, Google's shape library didn't have a laptop, so why not go google for it and ta-daa! Found a suitable in couple of mouse-clicks at http://www.flaticon.com/free-icon/apple-laptop-computer_22791. Vector version available in multiple formats, so I downloaded the SVG into my Google Drive and ...

An hour later I simply gave up. Nothing in G Suite knew how to use that. And I did attempt a lot of things. Including converted the things into a .wmf as suggested by StackExchange article Import SVG files to Google Docs as a drawing.

It. Simply. Does. Not. Work!

Given the vast amount of proof, there must have been a time when it did work, but doesn't do that anymore. However, after an another hour later I found article How to import SVG (or any vector) into GoogleDocs from Google Docs Help Forum, which claimed that .emf would work. And oh joy! It does!

So, this is my illustrated guide of importing SVG into Google Docs/Drive/Suite ... whatever they choose to be called today. I'm sure this information will eventually be as invalid as so many pages around The Web are at the time of writing this, but I'll leave my mark to The Net with this one.

In this guide I'm doing everything in Google Drive. In reality you have lots of options to do this and go with a completely another path and still end with the same result, but I try to keep this as simple as possible.

1. Upload all the required .svg-files into Google Drive
2. Right click a .svg-file and choose Open with > CloudConvert
   
3. (one-time-task) Accept CloudConvert OAuth request
   
4. (if returning from CloudConvert account creation), do 2. again and choose Open with > CloudConvert
5. At CloudConvert, select vector > emf, and make sure Save file to my Google Drive is checked. Then hit Start Conversion:
   
6. You can convert any number of files at one run, when conversion is done, close CloudConvert:
   
7. Return back to Google Drive. You will find the .emf version of your file in the same folder the original .svg conversion was started:
   
8. Right-click the .emf file, notice how you CAN open it in Google Drawings:
   
9. In Google Drawing, copy the file Ctrl-c in Windows or ⌘-c in Mac:
   
10. If needed, you can paste (Ctrl-v in Windows or ⌘-v in Mac) the converted symbol into any other type of Google document, for example presentation:
    
11. When looking at your Google Drive, there are three versions of the same file. To get rid of not-so-useful ones, which two to delete (from left to right: .emf, Google Drawings and .svg):
    
12. To make sure you're keeping the Google Drawings one, right click any file and select View Details:
    
13. Keep the one saying Google Drawings, delete rest:
    
14. Done!

I don't know why people at Google think this is a fun sequence to do for dozen or so symbols. They could easily do this conversion pretty much automatically for me.

Btw. The  above laptop icon needs to be attributed:
Icons made by Freepik from www.flaticon.com is licensed by CC 3.0 BY

Somebody has got new toys. I was just doing a casual Speedtest for my mobile subscription to see if it would have any oompf in it. This is the result:

Holy cow! Nearly 150 Mbit/s download. On an iPhone 7! Whaat?
I was just having a burger in Stockholm, my subscription is Finnish, so all the traffic will exit from a Finnish IP-address. That makes the ping bad, but the download speed is trough the roof.

Here are couple of other measurements from Finland (thanks guys for these!):

Similar style results on both cases.

I don't know what changed, but Finnish telcos have really amped it up. No complaints from me! Nice!

Ok, we've established earlier, that IPv6 isnt' getting traction. ISPs are simply to lazy and they don't care about their customers, only their profits matter. It's really bad for profit to do improvements on their systems and networks. Meanwhile IPv4-addresses ran out on IANA, but ISPs don't care about that either, they stockpiled addresses and have plenty to go with.

To get IPv6 on my systems, I've been using free-of-charge service SixXS for almost 10 years. They provide IPv6-on-IPv4 -tunnels using IP-protocol 41 or 6in4. The tunnels I've been using in Finland have been provided by local ISP, DNA, again free-of-charge. During those years of service, I managed to accumulate almost 7000 ISK, that's 5 ISK per week per tunnel, if the tunnel is running without any problems.

On IPv6 day (6th June) 2017 SixSX will shut down all services. See, sunset announcement for their rationale for doing this. They pretty much say, that they ran tunnels for 17 years and don't want to do that anymore, ISPs should provide native IPv6 to every single customer they have. I'm totally agreeing with them. I'd like to keep my tunnels running, still.

It is what it is, decisions have been made and it's not going to change. So, my sincere thanks go to SixXS and DNA, and especially to all the hard working people on those organizations. Thank you for your service!

Unlike last year, I didn't manage to get me an advent calendar this year. Unfortunately for me, Central European on-line stores won't do deliveries to Finland anymore.

This year I had to go for a much less elegant solution:

That's one for each of the 24 days.
Personally I'd prefer the real ones I had for the past couple years, but this will have to do.

I've been an active IPv6-user for many many years. Of course my ISP doesn't offer a native IPv6, so I'm using a tunnel from SixXS. They have been providing such tunnels free-of-charge for years, and for that I thank them and the ISPs volunteering their capacity for us nerds to have decent IPv6-connectivity. SixXS got tired for IPv6 not getting any traction, the ISPs have almost zero commitment for allowing people to use real, native IPv6. SixXS has a campaign called "Call Your ISP for IPv6!", but I don't think that's going to make much of an impact. When any ISP is actually asked about their IPv6 support, they'll stall by "we'll announce it later" or "but we do support IPv6" (by some unusable mechanism).

When looking what's happening on the ISP-side, Telia (or Sonera, as we call it here in Finland) has enabled 6rd for their connections. It combines DHCPv4 by returning enough parameters for an IPv6 setup with a 64-bitmask to be done. It kinda works, but ... still not the real thing I'm after. Also Elisa and DNA, two big mobile telcos in Finland, started offering IPv6 (DNA, Elisa) for their customers, but ... I'm not going to change my home fiber for a mobile connection. So something is happening at the telco-scene. I'm just waiting my ISP (Elisa) to act on the wired side too.

The other side of the chicken-egg -problem are the services. There is no real commitment on their side either. For example Amazon AWS (a really huge infrastructure provider) really doesn't support IPv6, they have nice IPv6 support for Internet-facing load-balancers, their S3 storage and their content delivery net Cloudfront, to mention few. But when it comes to running a server instance with real native IPv6, no dice. So, you can market your service to be IPv6-ready, all the critical Internet-facing services really do support IPv6, but your infra runs on IPv4 private addresses. Not cool.

And when it comes to services, this is a typical scenario:

That's what's been happening for LinkedIn for I-don't-know-how long. At least this week.

Me being the nerd I am, some background investigation:

# telnet www.linkedin.com 80
Trying 2620:109:c007:102::5be1:f881...
telnet: connect to address 2620:109:c007:102::5be1:f881:
Connection timed out Trying 91.225.248.129...
Connected to www.linkedin.com.
Escape character is '^]'.

A classic.
Their IPv6 is down and they don't know about it. This is their level of commitment:

On September 2014, they announce to have done a "Permanent launch of IPv6". But none of them are using it themselves to realize it has been down for a week! The really scary thing is, that they cannot afford $10 a month for a Pingdom check.

That's what I recommend for everybody to use for monitoring on-line services. Any reputable admin needs to know the second a service is out of reach by general public. IMHO that should include also admins at LinkedIn.

When it comes to lack of IPv6, I need to come clean. This blog isn't running on IPv6 either. Since most of you don't have it, it is impossible for you to know. My co-location host cannot offer me the IPv6, so no avail.

But why? Why is there no real commitment for IPv6? What's blocking all sensible people for going all-in IPv6? Everybody knows, that all possible IPv4 addresses were allocated by IANA to telcos and ISPs in January 2011. So, there is no more. Of course there are plenty of available addresses in RIRs to allocate for regional telcos, so we're not completely bankrupt with IPv4-addresses. But that day is eventually coming, it's just a waiting game. Notable efforts like World IPv6 Launch Day yield no mentionable results.

So what's holding us back? I don't know anything else except everybody going on the path-of-least-resistance. Since there are available IPv4-addresses, why risk a change. With change things can go broken or something may shift so that some people will lose some and others will win some. Not that much of a risk, if you ask me. But here we are, inching towards IPv6 very slowly. Speed it up, goddamnit!