The design of IPv6 represented a relatively conservative evolutionary step of the Internet protocol. Mostly, it's just IPv4 with significantly larger address fields. Mostly, but not completely, as there were some changes. IPv6 changed the boot process to use auto-configuration and multicast to perform functions that were performed by ARP and DHCP in IPv4. IPv6 added a 20-bit Flow Identifier to the packet header. IPv6 replaced IP header options with an optional chain of extension headers. IPv6 also changed the behaviour of packet fragmentation. Which is what we will look at here.
Please read this guest post by Byron Ellacott, Senior Software Architect at APNIC: The Internet of Things without the Internet is just things, and we’ve had things since the first caveman used a pointy stick to draw on a wall. What then does the Internet bring to things to justify a capital T?
In the past few months, we've added some new features and functionality to RIPE Atlas, including making the DNSMON code available on GitHub for personal use, displaying IPv4 vs IPv6 comparisons in LatencyMON, new credit sharing options, and new limits on probes per measurement and results per day. Learn more about the latest updates - and don't forget to tell us what you think.
This week, the RIPE NCC saw a milestone as the 10,000th Local Internet Registry (LIR) received IPv6 addresses. The first block of IPv6 addresses was allocated from IANA to the RIPE NCC in 1999, so we have been distributing IPv6 addresses for 17 years. In those years we have seen interesting policy developments, making it easier for LIRs to obtain enough IPv6 to satisfy their needs. In this article we track the policy developments that have made it progressively easier for LIRs to get the IPv6 they need.
We tend to make a number of assumptions about the Internet, and sometimes these assumptions don’t always stand up to critical analysis. We were perhaps ‘trained’ by the claims of the telephone service to believe that these communications networks supported a model of universal connectivity. Any telephone handset could establish a call with any other telephone handset was the underlying model of a ubiquitous telephone service, and we’ve carried that assumption into our perception of the Internet. On the Internet anyone can communicate with anyone else – right?
One of the more difficult design exercises in packet-switched network architectures is that of the design of packet fragmentation. In this article, I’d like to examine IP packet fragmentation in detail and look at the design choices made by IP version 4, and then compare that with the design choices made by IP version 6.
Wouldn’t it be nice if turning on IPv6 really was ‘press one button and the rest is magic’ easy?
The holiday season is rapidly approaching and this year is coming to a close, another one done and another one that seen some great and wonderful and also unfortunately some sad moments. One of those key moments was the depletion of the IPv4 pool in the ARIN region, which for some probably means the sad realisation that their business models will hit a growth barrier.
Every so often I hear the claim that some service or other does not support IPv6 not because of some technical issue, or some cost or business issue, but simply because the service operator is of the view that IPv6 offers an inferior level service as compared to IPv4, and by offering the service over IPv6 they would be exposing their clients to an inferior level of performance of the service. But is this really the case? Is IPv6 an inferior cousin of IPv4 in terms of service performance?
One of the measurements that we have been running for a long time is IPv6 RIPEness, where we measure the IPv6 activity of our members. We award our members with stars if they (for example) announce their IPv6 allocation in the global routing table.
We look at the RIPE NCC in terms of growth, geographic distribution and IPv6 deployment. We find that recent RIPE policy changes have had an impact on membership statistics and development trends.
Tony Smith from APNIC is looking at the increase in IPv6 deployment now ARIN depleted their free pool of IPv4 addresses.
If you monitor your external Internet connectivity, you may wonder which machine is the best to ping. Hesitate no more - you can use RIPE Atlas anchors as landmarks.
Some time ago, many people noticed rapid IPv6 deployment growth in Estonia (from 0% to 5% in 4 weeks). Tarko Tikan, from 3249/Elion/Estonian Telecom, explains the reason behind this.
Please find below a guest post by Darrin Veit and Christopher Palmer who originally posted this to the NANOG mailing list. It provides information for Xbox One, but also shares some relevant details on upcoming Windows functionality in terms of Teredo and IPv6 usage.
With the MENOG 15 meeting taking place this week, we look at Internet measurements and statistics for countries in the MENOG region.
We've been working with various Internet Exchange Points (IXPs) over the last few months to see how RIPE Atlas active measurements can provide insight into how they are keeping local traffic local. This could help improve performance and efficiency for IXPs and their members. To explore this, we've created a set of Python scripts to analyse Internet traffic paths between RIPE Atlas probes in a given country and try to identify whether they traverse IXPs.
On 14 September 2012, the RIPE NCC started allocating IPv4 addresses based on the last /8 policy. With more than two years passed, we look at the effects this had on membership numbers and demographics. We also look at what the last /8 policy meant for IPv6 uptake.
This time we explored Twitter feed visualisation with CartoDB, a map visualisation tool.
RIPE NCC Managing Director Axel Pawlik recently gave an interview about what he sees as the most important developments of 2014 and looks ahead to the big issues in 2015.