Dekopon, Cherry Blossoms and Some Rain: BRM330 200 Km in West Izu

The dekopon season will be coming to an end soon, but to compensate the shorts-and-short-sleeves season has started! I enjoyed both on Saturday, buying local dekopon (4 big juicy ones for 300 yen) in West Izu. The roadside stand worked on the honour principle: I dropped my coins into the collection box and took one bag of fruits.

I was the only rider in shorts at the start of the 2019BRM330 200 km brevet in Mishima, out of 13 who had shown up, out of 30 who had signed up, the others having been put off by a weather forecast that predicted a high chance of rain in the evening.

I drove to Mishima on Friday night with the Elephant Bikes NFE in the back of my Prius and parked the car in a coin parking lot (700 yen for 24h). I stayed at the Toyoko Inn, which was also going to be the goal of the 203 km ride which started at Mishima station. There were 2 courses, the hilly Matsuzaki course and the insanely hilly Darumayama course. I had tried and DNFed the latter in 2017, so it was Matsuzaki again for me.

Before the 08:00 start I loaded up the course on my GPS unit, but hit an unexpected snag when it reported a file system error that required a factory reset of the unit, meaning I’d lose my stored breadcrumb trail for navigation that I normally use. So I had little alternative but using my phone and the paper cue sheets for navigation. However, I had not brought my usual plastic cover for the phone to protect it on the handle bars in case of rain, nor had I weather proofed the cue sheets. The map bag of my front bag is not totally waterproof.

I used RWGPS to load the course and map and it gave me verbal directions in English throughout the ride. I kept the phone connected to a 10,000 mAh USB battery in my front bag until the goal. I have two USB batteries and two phones. There’s always a plan B and sometimes a plan C! 🙂

When the rain started to come down on the way back near Toi, I covered the phone with a plastic shower cap from a hotel stay which I secured it with rubber bands. I always keep one shower cap in the front bag as an emergency cover for the leather saddle or whatever. When my wet fingers made the touch screen difficult to operate, I used spare dry socks that I also kept in the same bag to wipe the screen dry again.

During a brevet on February 10, 2019 organized by Audax Kinki, a participant was sadly hit from behind and killed by a car in a tunnel. Brevet participants are required to wear reflective vests throughout the ride, but sometimes they wear a backpack which could partly obscure the reflective vest. Thus we were asked to wear the vest on top of any backpack. I actually brought two reflective vests, one to wear and one for my light string backpack (for spare clothes) to “wear”, which made getting changed quicker. I had bought the second at a brevet reception when I had forgotten the original one at home.

Most of the starter group did not spread out much until we turned the NW corner of Izu and the bigger climbs started. I took some pictures of the others and the scenery, but it was too hazy to see anything of Mt Fuji or even much of the mainland coast of Shizuoka on the other side of the bay. Mt Fuji remained totally hidden for the entire day.

As it got warmer towards noon I started fading a bit. I would have been really uncomfortable in long pants and thermal jacket. I was now riding on my own but comfortable in the knowledge that I was 50 minutes ahead of minimum pace at that point, which should normally ensure that I would complete the ride under the time limit.

There were a fair number of cherry trees, but most of them weren’t in full bloom yet, many quite sparse at the top still, so I didn’t take too many pictures of them.

There were only two timed controls on this course between the start and the goal, with 161 km in between. Near the southernmost point of the ride there was a photo check: We had to take a picture of a viewing platform on a mountain road together with our brevet card to prove we passed there. I climbed the mountain road together with a young couple. They had already suffered a puncture in NW Izu that had cost them time, while I frequently stopped for pictures.

From there I enjoyed a long descent to Kumomi Onsen. I had visited there in December and then climbed Mt Eboshi, which offers a breathtaking scenery of the coast. We passed Iwachi Onsen, where I had often visited by car when our children were still little.

I was trying to make it to near Heda village by sunset, where a staff member was taking pictures of all of us as we passed, but my own pictures took priority. At the last conbini in Toi before the wilderness it started raining and I put on my rain gear. On the descents I had to be a lot more careful. The wet asphalt soaked up all the light.

The rain became quite intense and I couldn’t help thinking of the 17 non-starters who had listened to the weather forecast… but with my time buffer I expected I’d still make it in time, unless I had bad navigation problems in the last 20 km. The phone became difficult to use when its touch screen got wet. Once, the RWGPS app somehow ended up back on the route selection and I had to restart the Navigation, which seemed to have cost me my downloaded maps 🙁 Now I could only use the turn by turn instructions to follow the course, but no map view. Fortunately, those turn by turn instructions worked flawlessly, even if the sound volume wasn’t always high enough to be clearly audible. Worst case I had to check the screen. Twice I went off-course but it soon let me know and it recovered when I backtracked to the wrong turn.

After more than 3 hours of riding in the dark I finally got close to Mishima station. When I stopped at the traffic light across from the Toyoko Inn, a staff member waved at me and handed me a note with the finishing time after I crossed. It was 21:19, only 11 minutes under the cut-off time. At the goal reception I presented my brevet card, the receipts from PC1 and PC2 (both 7-11 stores) and showed a photograph of the viewing platform. I had successfully completed! The young couple also made it. They arrived a mere 2 minutes before closing time. Another cyclist who had punctured on the last part of the ride in the rain was over the time limit.

On the drive back to Tokyo I stopped twice at Tomei expressway service areas for some rest, as I was too sleepy. When I got home I unloaded the car, took a shower and went to bed at 02:00. Two more weekends before the 360+ km Fleche ride for which I’m preparing.

2019 AJ NishiTokyo 200 km Miura Peninsula

This is one of the last views of Mt Fuji I had last Saturday (2019-01-19), when I rode my first brevet of the year, BRM119 NishiTokyo 200 km Miura Peninsula. I also saw Mt Fuji from the Yamate area of Yokohama (near the Foreign General Cemetery), from the waterfront south of Yokosuka and from various spots on the west coast of Miura, including just before Enoshima.

This 200 km ride around Miura peninsula from Machida to Machida is one I have done before, though much of the course outside Miura was different from last year’s. There’s a 13h 30m time limit (6:00 start, 19:30 close), with two timed checkpoints and a third location for a picture check. I finished in 12h 42m. Together with my ride back to Tokyo it came to 237 km (on Strava).

First Brevet of the Year

January brevets here are always very popular and fill up quickly when the signup period opens. BRM119 by AJ NishiTokyo was no exception. It filled up the first evening.

For a 200 km ride this course has minimal elevation gain (less than 1200 m) so it’s not quite as physically challenging as other 200 km brevets (hence maybe easier for people you didn’t ride much since the end of the 2018 brevet season in October), but there are no easy brevets. In this one you trade mountains for traffic lights and some busy roads. The January chill definitely will suck your energy, especially before sunrise and after sunset. You will be using a lot of energy just to stay warm, even when simply breathing in cold air!

The temperature on the ride ranged from -1° C at the start to 19° C near Jogashima, before dropping back to 5° C at Machida. This is a huge swing that’s difficult to dress for. I have a large front bag with sufficient space for clothes (and food), but I don’t know how others handled it — probably by feeling very chilly for the first few hours and very warm during the day!

The temperature swing aside, the weather was near perfect. The sky was nearly cloudless for almost the entire day. We were spoilt by ocean views and Fuji views.

I rode from my home in Tokyo to Machida the night before, as I had booked a room at a ToyokoInn to better cope with the early start time (06:00). This is a chain of inexpensive hotels. The rooms are clean and offer all the essentials. The ride reception to pick up one’s brevet card opened at 05:00, with a pre-ride briefing scheduled for 05:30. I went to bed at 22:00 to get more than 6 hours of sleep. My alarm went off at 04:10 and I left the hotel 40 minutes later.

I was well prepared for this ride. It was my third Century (160.9+ km) ride of the month, all three of them started no later than 06:00 so I knew the temperatures before sunrise and how they would feel in what I was wearing.

These are my improvised shoe covers, a pair of old merino socks with strategically cut holes for the SPD cleats, during testing the week before:

I had more than enough clothes with me, for example a choice of a winter jacket or a windbreaker to wear on top of my LS merino jersey and I used both, at different times.

I wore most of my clothes at the start at 06:00 from Machida:

The only time I really did feel cold was when riding back to Tokyo after the event, as I hadn’t bothered to change back into my thermal underwear and base layer and consequently felt the wind chill on my hands. I improvised some poor man’s Bar Mitts ™ out of plastic bags and rubber bands that kept my hands toasty warm for the rest of the ride.

Pacing myself

During the descent towards the Tamagawa river from the west I could see the whole of Tokyo below me in the dawn, including the skyscrapers of Shinjuku and Tokyo Skytree, the 634 m broadcast tower on the opposite side of the city.

About an hour into the ride, the sun rose. It was dazzling us at times. Near Kawasaki station we hit rush hour traffic, but after that we switched to a cycling path by the riverside. After 48 km we reached PC1, the first control. Here I took off some of my layers as it was warming up.

Between there and Tsurumi we were cycling near the port area, with many trucks carrying heavy shipping containers on the road.

In Yokohama we passed Minato Mirai with its old brick warehouses and other historic buildings. After a Yamashita park we climbed up to the Yamate area, also known as the Bluff, a hillside that was home to the first foreigners who arrived in Japan for trading when Japan opened to the world in the final years of the Tokugawa shogunate. I got a surprising view of Mt Fuji from just outside the Foreign General Cemetery on the hill.

With a large group it’s always tempting to try to hang on to faster riders and I probably ended up doing that, riding a bit too fast for the first 60 km or so of the ride. Then my legs gradually started to complain and I dropped the pace and stopped for food near Yokosuka. I kept a more sustainable pace for the rest of the ride and felt pretty good. I also stopped often for pictures.

After Yokosuka you get good views of Boso peninsula on the opposite side of Tokyo bay. The scenery becomes more rural. By now the temperatures were much milder. I was riding without my winter jacket and later even removed my base layer under the long sleeve jersey.

I passed Hayama, Zushi and Kamakura on the west coast, enjoying views of the ocean and Mt Fuji. After Enoshima the road turned off the coast and headed north. I had a comfortable time buffer and didn’t have to worry about control closing times.

It was still daylight at PC2, the last control. From here it was 31 km to the goal. Once the sun set, the silhouette of Mt Fuji in the dusk was still visible to the west and I stopped a couple of times for more pictures.

I arrived at the goal with about the last fifth of the participants still behind me. AJ NishiTokyo staff served hot drinks and snacks. We talked and took some pictures of each other and the arriving finishers.

Outlook into the season

My next brevet will be a 200 km ride in west Izu at the end of March which will be a lot more hilly, but before that I will do at least one Century ride in February. In April I will be participating in a Flèche as part of a mixed 5 person team riding 360 km in 24h to meet up with other Randonneurs in Tokyo. Most likely I’ll also be riding a 400 km brevet in May.

I am not aiming for a 600 km ride or for completing the Super Randonneur series (200, 300, 400 and 600 km) this year, let alone participating in Paris-Brest-Paris 2019 in August. Rides up to 400 km are enough of a challenge for me 🙂

Outlook Express Error 0x800CCC0B and the End of TLS 1.0 (Deprecated SSL Protocol)

Microsoft Outlook Express (OE) is an obsolete mail client that was available in Microsoft Windows XP, Windows 2003 Server and older Microsoft operating systems. It was no longer available on Windows Vista and later, though Windows Live Mail is relatively close in user interface and appearance.

Despite being obsolete and only working on operating systems no longer supported or updated by Microsoft, it still has some users who prefer its simple but powerful user interface. Some of those users will have had a frustrating experience recently, when various mail servers stopped working for outbound mail in OE. Specifically, these are mail servers that use SSL on submission port 465 or 587 for SMTP.

Secure Socket Layer (SSL) is a mechanism for encrypting data between a client and a server. You may know it from website URIs starting with “https:” and web sessions displaying a padlock symbol next to the URI. There are various protocol versions that can implement this encryption layer. One of these, TLS 1.0 which was conceived in 1999, has now been officially deprecated (made officially obsolete) as of the end of June 2018. Software now has to use more recent protocols, such as TLS 1.1, TLS 1.2 or the recently defined TLS 1.3.

Unfortunately, TLS 1.0 is all that OE will speak. It does not understand TLS 1.1 or later. Therefore it can not pick up mail from a POP server using SSL on port 995 or an IMAP server on port 993 or send mail to an SMTP server on port 465 (or 587) with SSL enabled.

The only workaround I am aware of (other than switching to a more modern mail client) is to use Stunnel, a tool for Windows or Linux that acts as a proxy. You can configure it to establish an SSL connection to a given host and port when a connection to a given local port is made. Thus you could configure OE to connect to port 9465 on the machine running Stunnel, which might then connect via SSL to using a more modern TLS version supported by Stunnel (but not directly by OE).

Picasa: “Failed to download album list”

If you are still using the Picasa 3 desktop application by Google and got the above error message, here’s some bad news for you: Google has finally killed this app. On March 26, 2018 they announced that it would no longer be able to upload new albums. So this error message is not temporary and there is no direct fix.

I think it’s very regrettable that Google has been killing off Picasa step-by-step. This is only the latest nail in the coffin. I had been using Picasaweb and Picasa since 2010 and they were great products.

The good news is that you can still create albums from folders using a web browser. Say you have a folder named “2018-03-26 Cherry Blossom Party”. Just follow these steps (for Windows and Chrome):

1) Select its parent folder in Windows Explorer, then slowly click on the folder that you want to upload, twice: Once to select it, then once more to enable you to edit the folder name as if to rename it. When the name becomes editable, press Ctrl+C to copy the folder name, then press Esc to keep the name unchanged. This stores the folder name in the copy-and-paste clipboard, which will save you from having to manually retype the name later.

2) In Chrome, go to and click on “Upload” (on the top right). A file selector dialog will open up. Click through to the contents of the folder you want to upload. Select all files in the folder using Ctrl+A and click “Open” to confirm the upload.

3) The browser will upload all files and give you a choice of “Add to album” or “Shared album”. Select “Add to album”. To create a new album with the name of the folder, select “New album”. Click on the album name showing as “Untitled” and use Ctrl+V to paste the name you copied in step 1. Hit Enter and click on the check mark to confirm creation of the new album.

Voila, you have a new album online, with the same name as the local folder. Repeat as needed for multiple folders. This is as simple as it gets without the old Picasa app.

Strava Cycling Climbing Challenges

Strava is a popular service for logging bike rides and other activities, which provides a way of comparing one’s achievements with those of other cyclists and runners. Competition is a powerful stimulant and a main driver behind the success of the service. Monthly “challenges”, such as a Gran Fondo (a ride of at least 100 or 130 km, depending on the time of the year) or a monthly cumulative distance or elevation gain challenge, are particularly popular on Strava.

While I regularly participate in the Cycling Distance and Gran Fondo Challenge, I do not normally sign up for the Cycling Climbing Challenge, which is meant to encourage you do ride hilly courses. I love hilly courses. In fact, most of my weekend rides are hilly, usually going from close to sea level to over 900 m and back.

Last year I averaged one century ride (at least 160.9 km / 100 miles) about every other week, so the Gran Fondo challenge is not really that much of a challenge for me. My typical centuries are about 170-190 km with 1800-2100 m of elevation gain. Yet at 7500 to 8000 m the goal for the Cycling Climbing Challenge is set so high, I could do a hilly century ride four Saturdays in a row and still miss the climbing goal. So how do other people, who do not ride 170 km into the hills every other weekend complete the climbing challenge?

I think the Strava climbing goals are designed for people who record their rides with phones or other GPS devices that rely only on satellite data for elevation. GPS-based elevation data is much less precise than lattitude-longitude data. Other popular GPS units like the Garmin Edge 1000, Garmin Edge 520 (or my o_synce Navi2coach) use a barometer for more precise elevation tracking. The problem with GPS-based elevation is that it’s noisy, it will go up and down pretty randomly but all those little ups will be added up by Strava, resulting in a considerably inflated climbing total. If you’re using a GPS device measuring relatively accurate barometric elevation, you can’t really compete against all that noisy data 🙁

I could confirm this in group rides with other people who were using mix of equipment, where I had a chance to compare the posted stats on Strava afterwards. The iPhone or Android-app recorded totals were often 50-100% higher than the Garmin-recorded totals, for one and the same course.

Here is one random example of 4 people doing the same course up a volcano in Tenerife, Gran Canria yesterday. Note, this not my ride, I just randomly stumbled on it while looking at high scorers in the March Cycling Climbing Challenge on the Strava website. Two of these cyclists were using the Strava iPhone app, the other two were using a Garmin Edge 520:

Strava iPhone App:

Strava iPhone App:

Garmin Edge 520:

Garmin Edge 520:

As you can see, the two cyclists using the phone app posted almost double the total climbing for the course as the Garmin users, despite riding the very same roads and posting the same elevation profile for the activity (i.e. no hill repeats).

Based on evidence like that, I don’t think elevation gain competitions on Strava are happening on a level playing field! 😉

Downloading routes from RouteLabo (Yahoo LatLongLab)

Most of the brevets I ride are with AJ NishiTokyo, a randonneuring club based in the Machida/Sagamihara area. One thing I like about their rides is that they provide a link to a RouteLabo page for each event (RouteLabo is an online map service run by Yahoo Japan). This page shows a map of the course as well as download links for KML, GPX and TCX files of the course. By copying these files to your GPS device (Garmin or other) or by uploading a KML file to Google “My Maps” for your smartphone, you can almost completely do away with the need for paper cue sheets. I navigate all my brevets and many of my personal rides by following a “breadcrumb trail” on the screen of my GPS unit.

Unfortunately other clubs often only provide a map without any download option, like this Randonneurs Tokyo 2018 BRM421 Tokyo 600 Lake Hamana (BRM421東京600浜名湖鰻) page:

This does not help you much on the road. Without a link to the full RouteLabo page with download links, there’s no obvious way to obtain a GPX or KML file. You are still expected to navigate via printed turn instruction on a paper cue sheet, which I find cumbersome and error-prone.

However, there is a way!

The web page uses some Javascript code to display the map off the RouteLabo website, including a magic value that identifies the particular course to be shown. To see this value, view the source code of the page. This step varies by browser and operating system. On Chrome under MS Windows, Ctrl+U will show the source code, on a Mac under Chrome, Option+Command+U will do it. On Safari, once you enable the option via Safari > Preferences > Advanced > Show Develop Menu, you can also use Option+Command+U (just like in Chrome).

In the displayed HTML code, search until you find a line for Javascript like this one:

<script type="text/javascript" encoding="UTF-8" src="

The value consisting of 32 hexadecimal characters (128 bit) after “id=” is the magic value you’re looking for. A full RouteLabo page URI with the download options will look like this:

By replacing the value after “id=” in the URI with the ID from inside the HTML code using copy and paste, you will get a browser URI that will give you full access to the route, including route file download links to feed your GPS device of choice. You can then bookmark it for future reference. Bonne route! 🙂

Huawei Nexus 6P Battery Upgrade

I’ve had my Huawei Nexus 6P for about two years now. The combination of a great camera, an excellent screen, good performance and decent battery life has made this my best smartphone ever.

However, a couple of months ago something happened as the battery capacity appeared to have collapsed dramatically. Sometimes the phone would shut down only 5 hours after I had disconnected it from the AC charger when I left home, starting off supposedly fully charged! I had to always carry a USB battery and cable with me to not risk losing the use of my phone in the middle of the day.

Attempts to recalibrate the capacity indicator helped only insofar as the phone would shut down at 14% charge instead of say 55% charge, so there was slightly more warning, but the number of hours was still too short. This actually seems to be a common problem with the Nexus 6P, which otherwise is still a great phone.

It’s not uncommon for Li-ion batteries to significantly lose capacity after about about three years, but if it happens after less than two years as in my case, that’s not very good. Fortunately, replacement batteries are available and any competent phone repair shop will be happy to do the necessary surgery to replace a battery that is on its way out. Unfortunately the days when you could simply pop open the phone case without any tools and swap the battery yourself are long gone. This is a trend started by Apple and almost every other phone maker has since followed suit. I think it’s meant to get people to buy a new phone sooner, which is good for Apple and its competitors, but bad for consumers and for the planet.

There are Youtube videos that will show you how you how to open the Nexus 6P case and disassemble the phone to swap the battery. This involves the use of a hairdryer or heat gun to soften the glue that holds it all together as well as a plastic card and a small screw driver. As I did not feel adventurous enough to attempt this myself, I contacted several phone repair shops here in Tokyo. Repair King Japan replied. Though they they didn’t have the Nexus 6P battery in stock they were happy to order one for me. Once they got it, I dropped the phone off and two hours later I could have it back with a new battery. So far it’s looking good: It’s been 40 hours since the last full charge (with battery saver mode inactive) and it’s still showing 64% with about 3 days of power left 🙂

UPDATE: At 72 hours, it still had 23% charge left. At that point I connected it to a charger.

Hopefully with the new battery my Nexus 6P will be a great phone again for a few more years!

Adding Free SSL Certificates for HTTPS To Your Websites

I recently received a warning email from Google:

“Starting October 2017, Chrome (version 62) will show a ‘NOT SECURE’ warning when users enter text in a form on an HTTP page, and for all HTTP pages in Incognito mode.

The recommended solution was to migrate the affected website(s) to HTTPS. This requires an SSL certificate. There are many companies selling those for hundreds of dollars. I didn’t really want to spend that money.

It turns out there is a free alternative: The Let’s Encrypt project ( provides free SSL certificates with just enough functionality to run SSL with current browsers. It also provides automated tools that greatly assist you in obtaining and installing those certificates.

I had a default SSL host configured on my Apache 2.4 installation (inherited from a different server running Ubuntu) that I had to manually remove.

Then, when all virtual hosts only had port 80 (HTTP) enabled, I could run the certbot tool as root:

# certbot --apache

It enumerates all host names supported by your Apache installation. I ran it repeatedly, for each domain and the corresponding www. host name (e.g., in my installation and verified the results, one at a time. It will create a new virtual host file in /etc/httpd/hosts-enabled for those hosts for port 443 (HTTPS). I appended the content of that file to my existing port 80 (HTTP) virtual host file in /etc/httpd/hosts-available for that host name and deleted the new file created by certbot. That way I can track all configuration details for each website for both HTTP and HTTPS in a single file, but this purely a personal choice.

All it takes is an Apache restart to enable the new configuration.

You can test if SSL is working as expected by accessing the website with a browser using https:// instead of http:// at the start of the URI.

If you have iptables rules for port 80, you may want to replicate those for port 443 or the certificate generation / renewal may fail. Also, you want to make sure that SSLv3 is turned off on your Apache installation, to protect against the POODLE vulnerability. This required the following setting in ssl.conf:

/etc/httpd/conf.d/ssl.conf:SSLProtocol all -SSLv2 -SSLv3

The free certificates will expire in 90 days, but it’s recommended to add a daily cron job that requests renewals so that an updated key will be downloaded after 60 days, long before the old key expires. Once that is in place, maintenance of SSL keys will be totally automatic.

UPDATE (2017-11-01): If you’re using WordPress on your website, you should change the WordPress base URI to HTTPS too. To do that, log into the WordPress Dashboard. In there select Settings > General. Change the “http://” in the WordPress Address (URI) and Site Address (URI) fields to “https://” and click the Save Changes button. This ensures that any messages from WordPress to you will include secure URIs.

Nexus 6P Flashing Charge Icon

Recently the USB-C quick charger that came with my Huawei Nexus 6P appeared to stop working. I normally leave the phone charging over night, but one morning I found its battery charge was low and it hadn’t been charging. When I disconnected and reconnected it to the cable (which is reversible with USB-C connectors on both ends), the lightning bolt inside the battery charge indicator kept blinking (flashing on and off), rather than being solid on as it normally would while the device is charging.

Disconnecting and reconnecting the device or unplugging and reconnecting the charger to the wall socket made no difference whatsoever. Reversing the cable direction did not help either.

My only way to still charge the phone was to use a USB-A to USB-C cable that draws power from a PC USB socket, which is a much slower way to charge the phone. So I decided that the charger must have failed after less than a year of use. I already started looking for USB-C quick chargers on Amazon (they exist but are much more pricey than USB-A chargers), but didn’t order one yet.

Today I decided to Google for the problem and found others who had the exact same issue. It turned out that simply powering down the phone and powering it up again will fix the problem: Yepp, it will charge again!

I’m not sure what the fundamental issue is, but it seems I won’t have to rush out and buy a new charger (which wouldn’t have helped anyway!), as the issue is on the phone side.

If a simple phone reboot fixes it and it doesn’t happen too often, I guess I can live with that. The Nexus 6P has worked great for me so far.

Porting iptables to ip6tables

A couple of days ago I received an email notification by the Berkeley Security Notifications Team that a Linux server of mine had less restrictive firewall rules for IPv6 than it had for IPv4. This prompted me to update my ip6tables settings on that host to make it is as secure via IPv6 as it was for IPv4.

If you have a dual stack server with IPv4 A records and IPv6 AAAA records published in DNS, you should have it protected with firewall rules on both protocols. Even if you only publish A records and not AAAA ones, you should secure IPv6 access because its address may leak to potential attackers in other ways.

The ip6tables tool is installed as part of iptables on recent distributions, but you need to set up one set of rules for each protocol. They’re independent of each other. A (not very secure) default ip6tables configuration might look like this:

# Generated by ip6tables-save v1.4.21 on Thu Sep 24 11:17:56 2015
:OUTPUT ACCEPT [1456:118498]
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state –state NEW -m tcp –dport 22 -j ACCEPT
-A INPUT -j REJECT –reject-with icmp6-adm-prohibited
-A FORWARD -j REJECT –reject-with icmp6-adm-prohibited
# Completed on Thu Sep 24 11:17:56 2015

It’s relatively easy to port additional settings from iptables to ip6tables (e.g. in /etc/sysconfig/iptables and /etc/sysconfig/ip6tables for CentOS).

Below are some of the changes needed when porting common entries. As you can see, some names are replaced with those of IPv6 equivalents. Any IP addresses and CIDRs for ip6tables need to be written in IPv6 notation.

To easily port over IPv4 addresses, simply prefix them with “::ffff:”. If they’re followed by a bit count such as /24 (the routing prefix size), add 96 to that number (IPv6 addresses are 128 bits each versus 32 bits for IPv4). Add equivalent rules for the corresponding native IPv6 addresses as needed.

  1. Accept ping from any source:


    -A INPUT -p icmp -j ACCEPT


    -A INPUT -p ipv6-icmp -j ACCEPT

  2. Accept connection from white-listed address:


    -A SSH-IN -s -j ACCEPT


    -A SSH-IN -s ::ffff: -j ACCEPT
    -A SSH-IN -s 2345:abcd:678:42::/64 -j ACCEPT

  3. Rule to block access (after all the exceptions):


    -A INPUT -j REJECT –reject-with icmp-host-prohibited
    -A FORWARD -j REJECT –reject-with icmp-host-prohibited


    -A INPUT -j REJECT –reject-with icmp6-adm-prohibited
    -A FORWARD -j REJECT –reject-with icmp6-adm-prohibited