The introduction of a second IP protocol into the Internet presents many technical issues, and in previous columns we've explored many of the issues related to network engineering and infrastructure. In this column I'd like to head upward in the protocol stack to the rarefied air way up there at the level of the application, and look at how applications are managing to cope with the issue of two IP stacks.
Often when looking at IPv6 deployment statistics, the size of the organisation or the network is not taken into account. In this article, we look at IPv6 deployment of Local Internet Registries (LIRs) per country in correlation with the size of the LIR.
In this article we look at two "Happy Eyeballs" implementations, that aim to reduce degraded user experience as the result of broken dual-stack configurations. We call this degraded user experience "Unhappy Eyeballs". The Chrome web browser implementation seems to succeed in this aim, while Apple's Mac OS X Lion operating system only partially succeeds in avoiding "Unhappy Eyeballs". Furthermore we show that Mac OS X Lion, in combination with the Safari web browser results in "Happy Eyeballs", but leaves well performing native IPv6 capacity unused in roughly half of the cases we measured, a condition we name "Hampering Eyeballs".
In this article we suggest a technical solution to the issue of publicly displaying MD5 password hashes in the RIPE Database.
Passwords are the most used authentication method in the RIPE Database. This mechanism has two major design problems. The MD5 hash is public, when running a single query (not for bulk queries). And in case of email updates, plain text passwords are sent by email to update the database. Find below some recommendations on how to secure your objects until these issues have been addressed.
Following up from the recently published IPv6 RIPEness update, we are now looking at the IPv6 RIPEness of Local Internet Registries relative to their age and relative to their size.
RIPE Atlas has made steady progress in its first year. But we have more ambitious plans. Please read below how we are suggesting to achieve them and why we need your support.
This article provides a summary of the RIPEstat live demo session held on Monday, 31 October 2011 at RIPE 63 in Vienna. The focus of this demo was to review all current features, show some use cases of RIPEstat, and an provide an overview of planned developments. Information about the next demo can be found at the end of the article.
Following your feedback, we decided to make IPv6 RIPEness a production service. We are currently working on some new features. Stay tuned!
According to address policy, the experimental address allocations for RIPE RIS beacons have to be returned soon. This would mean we have to either discontinue the RIS beacons or request permanent allocations for them according to address policy. We are asking for community support to continue operating the RIS beacons at the current addresses and for support for the address allocations.