Spend 30 minutes with IPv6 every Friday!

In every meeting I attend I try to add IPv6 as a topic. It doesn’t always succeed, but when it does, it opens up for interesting discussions. One thing I realize is that changing the mind set of people like me, that has spent years with good old IPv4, takes time. Learning old dogs new tricks and all that. Let’s look at IPv6 addresses again to try to sort up some confusion and discuss new tricks.

The need for NAT – or not?

One thing that keeps popping up is the need for NAT and private addresses. Let’s look at this as two separate issues. Why is private addresses a good thing? Well, if you change service provider you do not have to renumber the network people tell me. My response is that you can still do that. If you want permanent addresses there are Unique Local Addresses, ULA,  you can use for the same purpose – to address local resources. Now, this does not replace the global address on the same interface. When setting up communication, the application chooses one sender address and one destination address that works optimally. When communicating with a local printer, use the ULA. When surfing to a web site somewhere on the Internet, use the global address.

Over to part two, the need for NAT. Do you still need it? I guess not. At least not for this reason.

Selecting IPv6 addresses for communication

In IPv6, every host will have many IPv6 addressesThe task of selecting the right IPv4 address for communication has been an issue for me in many applications when I have a server with multiple addresses attached to different interfaces and networks. In IPv4, how to handle this situation was not really documented. In IPv6 this quickly became important. A desktop host may have a link local address (FE80::), a global address assigned with DHCP/RA and a temporary address for privacy reasons. The site may provide an Unique Local Address prefix too. In addition, the interface has a few multicast addresses to listen to. For a server we usually use permanent addresses, but may still have a few of these to select form in addition to the link local address.

Every IPv6 application needs to be ready for having to select an IPv6 address to send to, and one to send from. If both hosts are dual stack, we will have to test and select address family to (see Happy Eyeballs). The procedure for IPv6 address selection is documented in RFC 3484 – Default Address Selection for IP version 6.

“The IPv6 addressing architecture allows multiple unicast addresses to be assigned to interfaces. These addresses may have different reachability scopes (link-local, site-local, or global). These addresses may also be “preferred” or “deprecated”. Privacy considerations have introduced the concepts of “public addresses” and “temporary addresses” . The mobility architecture introduces “home addresses” and “care-of addresses”. In addition, multi- homing situations will result in more addresses per node. For example, a node may have multiple interfaces, some of them tunnels or virtual interfaces, or a site may have multiple ISP attachments with a global prefix per ISP. The end result is that IPv6 implementations will very often be faced with multiple possible source and destination addresses when initiating communication. It is desirable to have default algorithms, common across all implementations, for selecting source and destination addresses so that developers and administrators can reason about and predict the behavior of their systems.”

A shared task between the application and the O/S

The RFC describes how the address selection is implemented. The application use an API like getaddrinfo() to get a list of IP addresses that matches a host name. The operating system is responsible for sorting this list according to RFC 3484 (with some additions for ULAs, that did not exist at the time).  The application then starts with the top of the list and tries to connect and proceeds down the list until it reaches the other party. For dual stack hosts connecting to dual stack servers, this rule is modified by RFC 6555 – Happy Eyeballs - that say that the app should try IPv6 and IPv4 connections at simultaneously. RFC 6555 also suggests that systems could change the RFC 3484 configuration for ordering based on the results of the connection attempts. The rule set is explained this way:

“The algorithms use several criteria in making their decisions. The combined effect is to prefer destination/source address pairs for which the two addresses are of equal scope or type, prefer smaller scopes over larger scopes for the destination address, prefer non- deprecated source addresses, avoid the use of transitional addresses when native addresses are available, and all else being equal prefer address pairs having the longest possible common prefix. For source address selection, public addresses [3] are preferred over temporary addresses. In mobile situations [8], home addresses are preferred over care-of addresses. If an address is simultaneously a home address and a care-of address (indicating the mobile node is “at home” for that address), then the home/care-of address is preferred over addresses that are solely a home address or solely a care-of address.”

RFC 3484 implementations in Linux and FreeBSD

The RFC says that there is a default rule set for address selection, but the network or system manager should be able to change this. In Linux, GLIBC uses a configuration file called /etc/gai.conf and in FreeBSD there is a tool called ip6addrctl to manage this list. That makes it possible to add ULA addresses in the address selection rule set even though they did not exist at the time RFC 3484 was published.

Issues with RFC 3484

Microsoft has implemented RFC 3484 in Windows. They have noticed that this affects IPv4 as well, especially the support for Round Robin DNS load balancing since they implemented RFC 3484 address selection for both IPv4 and IPv6. I could not find a way to change the rule set for address selection in Windows.

There are a few known issues with RFC 3484, like the missing ULA address space. Work has started in updating the document, with an RFC and a draft published by the IETF listing the problems that are found, mentioning the issue with Round Robin DNS.

As a developer, read all of these documents

If you are a developer working with network-related code, my advice to you is to read all of the documents I have linked to in this text. Get an understanding how this affects your code as you port it to IPv6.  Make sure you include ULAs in your design. And test, test, test. I’ve had applications use site-local addresses when trying to contact a server with a global address. Don’t let that happen to your application. Combine these rules with Happy Eyeballs and you will still have a successful application as the net moves to IPv6.

Links:

 
Spend 30 minutes with IPv6 every Friday!

Change Takes Time. Start the transition to IPv6 now!

This is the time for change. We need to change the way millions of network engineers work with their networks. We need to change the way millions of developers design their applications. We need to change the way millions of companies purchase equipment and services. And we need to change without disrupting the current service on the corporate LAN, in the home and across the Internet. That’s a huge task. Of course, this will not be either quick or simple. While IPv6 gets more and more traction, there’s still resistance out there. Let’s look at IPv6 in the news flow and see what we learn from it.

IPv6 is international and growing

Googling for IPv6 or IPv6 news generates a lot of links. From the first page you see something different. A lot of the links are in Asian script. Why is this happening? The Internet was created in the USA. In the start, the 32 bit address space was a universe with no limits. Addresses was plenty and huge address blocks was allocated for US entities. When Asia connected to the Internet, we where already aware that the 32 bit IPv4 address space would run out, that it wasn’t enough. This means that there are huge differences in numbers of addresses per capita around the world. Asia needs IPv6 in order to deliver the same service as a normal Internet customer gets in the US. And they use the Internet to share their experience. Google sees that and serves me links in many languages.

Trying to understand the size of the current Internet is almost impossible. Trying to understand the growth rate is even more impossible. Look at the number of devices we’re adding. The growth of mobile, home and business connections in new countries in the Internet community. You don’t have to google for more than a few minutes on “Internet Growth” to understand that you need to change your perspective on things. IPv6 is the only way, and many are already implementing it. Mark Ward at BBC news recently published an article based on RIPE NCC’s IPv6 usage report. Norway is leading the IPv6 implementation race, Sweden is #5 after the Netherlands, Malaysia and Japan. Try to find USA on the top 20 list…

“There was more use of IPv6 in Asian nations, he said, because there were no more IPv4 addresses available to allocate to that region. To continue expanding and adding new customers, web firms in Asia had to adopt IPv6.”

Even with multiple layers of IPv4 NAT, with this growth there’s no way we can keep the Internet together unless we get more addresses. IPv6 is the only solution, regardless if we implement NAT or not.

IPv6 – so small so you can ignore it

Trevor Pott recently published an article on The Register named “Finally, it’s the year of Linux on the desktop IPv6! Are you following protocol?“.  This article is focusing on the World IPv6 Launch and claims that no one will care, nothing will happen and seems to indicate that since no one else cares, why should you?

“Despite the trebling hype amongst the networking nerd community, World IPv6 Launch Day is set to be yet another day when the internet at large yawns, hits the snooze button and rolls over to go back to sleep. While IPv6 is unquestionably the inescapable future, the world at large isn’t in a particular hurry to get there.”

“For the vast majority of us, World IPv6 Launch Day is set to be another damp squib. Maybe next year…”

Now, I’m looking for quotes that irritate me, of course. He also states a few important things: Vendors are not delivering, so transition to IPv6 is a pain for companies. Your local ISP has not added IPv6, so even if you want to, you can not easily add native IPv6 to your network. We need to learn from that and raise the pressure on vendors of products and services. This is not something you can ignore and let someone else do. You have the money to spend, you are in control. Use that to add pressure.

IPv6  - big enough for attackers to care

As the user base grows the security interested people follow, on both sides. Apple has got into the limelight lately, as their platforms has reached a large user base and gets some attention. IPv6, while still a small amount of Internet traffic, it has a large amount of devices around that are IPv6-enabled, much thanks to Microsoft that has IPv6 everywhere and even claims that Windows does not work as expected without IPv6.

Axel Pawlik, managing director of RIPE NCC, has recently published a comment on the ZDnet UK site discussing this.

“Most security incidents are caused by human error, either as the result of a programming error or through misconfiguration. In this sense, IPv6 is no different to IPv4. The real concern is the lack of experience and training for those IT professionals dealing with IPv6, which makes these mistakes more likely.”

“There is very little difference in the way you secure IPv6 compared with IPv4, because the environment in which both protocols sit is the same. Mitigation against these issues comes down to training and testing.

However, the impact of human error is unavoidable, and many of the real-world IPv6 lessons will come from trial and error. To lessen the impact, it is key for the technical community to document and share best practices and experiences to limit any widespread security issues from arising.”

The lesson to learn from Axel is that we need to lab, learn and test IPv6 early, regardless if you are a network user, manager or application developer. Don’t forget that you can start with an IPv6 tunnel - you don’t have to wait for your provider to deliver IPv6. Axel points out that RIPE has a very informative web site at www.ipv6actnow.org – which is a good starting point!

Transition to IPv6 in the cloud – watch out for bumps in the road

Lori MacVittie at F5 Networks have published an article on ZDnet UK discussing what the migration to IPv6 means for Cloud and Infrastructure as a service providers.

“As we’ve never attempted such a large transition before with the internet on its present scale, we must be prepared to cut everyone a bit of slack. It is no trivial task that the internet as a whole is undertaking. If we understand the complexity of the task before us, we should be able to cope with the inevitable bumps in the road.”

This is important. We need to start soon and share the experiences of the mistakes – and the solutions. Happy Eyeballs was one bump on the road that the community handled, fixed and now it’s time to move on to the next bump. It sounds like a kamikaze strategy, but it’s the only way forward. As Lori says, we haven’t got a test network the size of the Internet and with the same level of complexity. We need to start the migration and learn by practice in smaller scale than the whole Internet, but larger than the internal test beds.

Executive summary: Invest in IPv6 knowledge today.

We need to lab, learn, test and start the migration to IPv6 now by implementing dual stack services. When purchasing new products and services, make sure you put as much pressure as possible on vendors to support IPv6. If there is no other way than to buy IPv4-only today, make sure you let them know that this is not going to be acceptable next time around. They need user feedback with money attached to change. You have the money, they want it. Simple math says that they will listen if enough companies with money say the same thing.

That’s all for today. Follow the links and learn more. Set up your lab and start some internal training. Just do it.

/Olle

My Tweets