As we learned last month, Apple has included a DNS64/NAT64 implementation in the upcoming version 10.11 of the Mac operating system, for the purpose of testing whether iOS applications are "IPv6-clean". I installed the public beta of 10.11 last week, so I was able to see how this DNS64/NAT64 implementation works.
Rond 1990, 1991 was ik vrijwilliger bij Lokatel, de lokale omroep in Den Haag. Lokatel had geloof ik iets van tweehonderd vrijwilligers en een handjevol betaalde krachten. Ik heb een enkele keer wat voor de radio en de televisie gedaan, maar ik was voornamelijk bezig met de kabelkrant.
In die tijd voor het World Wide Web hadden we wel teletekst, maar dat was nog niet zo ingeburgerd als het later zou worden. Bovendien zijn de grafische mogelijkheden van teletekst beperkt. Vandaar dat in die jaren het medium kabelkrant een zekere populariteit had. Een kabelkrant bestond uit een verzameling pagina's die één voor één in beeld kwamen op een (kabel-) televisiekanaal.
Ik vond nog een oude VHS-band terug met een stukje van de Lokatel Kabelkrant uit november of december 1989. Klik op het plaatje om naar de volgende pagina te gaan.
En ik ben reuze benieuwd welke Lokatelli's er straks allemaal naar de Lokatel-reünie in de bibliotheek/stadhuis gaan.
►
This July 30th, at 23:59:60, a leap second was added to Coordinated Universal Time (UTC). Dyn Research posted the following graph on Twitter that shows there was significant BGP update instability for five minutes after the leap second occurred:
▼
This July 30th, at 23:59:60, a leap second was added to Coordinated Universal Time (UTC). Dyn Research posted the following graph on Twitter that shows there was significant BGP update instability for five minutes after the leap second occurred:
Unfortunately, it's not clear why this happened. However, leap seconds have triggered all kinds of mishaps in the past. They're basically miniature Y2K problems. Time and time again, software engineers show that they can't be trusted to take corner cases into account properly.
This does remind me of a situation about a decade ago, where I had a customer that experienced BGP instability every night at the same time. They used Quagga running on Linux machines. We couldn't figure out what the problem was, until we realized that at that very moment, the ntpdate command was run from the cron. ntpdate synchronizes the system clock with an NTP server. As the machine in question had a very poor system clock, this meant that the system's time was adjusted a lot every night, I think a minute or more, but definitely more than 30 seconds.
Which meant that if Quagga had gotten a BGP keepalive message 8 seconds earlier, it now thought that was 38 seconds ago. If BGP is configured with a hold time of 30 seconds, this means that Quagga now thinks the other side has been quiet for longer than the hold time and it'll tear down the BGP session. This is what happened every night for a bunch of BGP sessions. We solved this by running the NTP daemon continuously, so there was never a big adjustment in system time. (Alternatively, just letting the time drift would also have worked.)
The minimum BGP hold time is 3 seconds, so adjusting for an (improperly handled) leap second shouldn't be able to make BGP think the hold time for a session is expired. However, there could be bug somewhere else that impacted BGP.
I'm not sure whether these kinds of issues are a good argument in favor of abandoning leap seconds, as the bugs won't go away, they'll just show up at a less predictable time. But I don't like the current leap second practice, as they're unpredictable, and you can't calculate the time difference in seconds between two dates without taking the entire list of leap seconds into account. I think it would be better to save the leap seconds up and apply them all at the end of a century.
Despite the blister on my foot I couldn't resist going out and trying out my new Powerslide Fothon wheels for my inline skates. I got a 4-pack of wheels with red LEDs:
The wheels contain a small generator that uses the rotation of the wheel to generate electricity for the LEDs, so they come on when the wheels turn. Because all of this slows down the wheels a bit, I'm only using one on each skate. They also come in white, blue and green.
And as always, iPhone slow motion video for the win!
At the NANOG meeting in San Francisco two weeks ago, there was a session on The benefits of deploying IPv6 only. Someone from T-Mobile explained that the latest Windows Mobile and Android support 464XLAT to allow IPv4-only applications to work over IPv6 with NAT64, so those devices now only get IPv6. Other devices only get IPv4, there's no dual stack. At that point, the panelists didn't know yet that Apple is requiring iOS 9 apps to work over IPv6 so those can work through NAT64 without 464XLAT.
Another interesting data point is the observation by Facebook that IPv6 tends to perform better than IPv4, with the margin being as large as 40%:
However, why this is is unclear: the RTTs are the same, yet the performance/bandwidth over IPv6 is better. There was some frustration because Apple's implementation of "happy eyeballs" only looks at the RTT to choose between IPv4 and IPv6, and thus lands on IPv4 a good deal of the time and doesn't enjoy the benefits of that better IPv6 performance.
