Mar 092012
Spend 30 minutes with IPv6 every Friday!

The Internet Engineering Task ForceWhile IPv6 was standardized by the IETF, the Internet Engineering Task Force, many years ago, it’s now that we see the experience of operating IPv6 during many years and implementing it in various applications. There are many documents still coming out, some proposing new functions, correcting old ones that turned out bad and some documenting best current practice. I will take you by the hand and browse through some documents, not cover them all. Let’s take a look!

The IETF has a large amount of Working Groups. Many of them are touching the subject of IPv6 from one perspective or another, like the SIP area or the routing area. There are still some groups focused on the IPv6 topic. Let’s go through the major ones:

The IPv6 maintenance working group has this charter:

The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF.

The IPv6 Renumbering group(6renum)  has a long charter, but the core of it can be found in this part:

If IPv6 site renumbering continues to be considered difficult, network managers will turn to PI addressing for IPv6 to attempt to minimise the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space.

 The V6Ops group works with the transition from IPv4 to Ipv6, which is covered in their charter:

The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and nodes. This deployment must be properly handled to avoid the division of the Internet into separate IPv4 and IPv6 networks while ensuring addressing and connectivity for all IPv4 and IPv6 nodes. The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations.

Drafts and documents in the RFC publishing queue

The V6ops group has produced the very important Happy Eyeballs document, which currently waits to be published as an RFC. This document applies to almost every TCP/IP service that needs to connect over dual stack connections. The abstract is clear:

“When a server’s IPv4 path and protocol is working but the server’s IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay, and provides an algorithm.”

Another set of documents from this group is the “Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)” and the “IPv6 Router Advertisment Guard (RFC 6105)“that addresses the issue of devices that accidentally or on purpose start announcing IPv6 prefixes on a LAN.

“When operating IPv6 in a shared layer-2 (L2) network segment without complete SEcure Neighbor Discovery (SEND) support by all devices connected or without the availability of the infrastructure necessary to support SEND [RFC3971], there is always the risk of facing operational problems due to rogue Router Advertisements (RAs) generated maliciously or unintentionally by unauthorized or improperly configured routers connecting to the segment.”

“This document describes a solution framework for the rogue-RA problem [RFC6104] where network segments are designed around a single L2-switching device or a set of L2-switching devices capable of identifying invalid RAs and blocking them.”

Renumbering an IPv6 network

The 6renum group has a few documents that are trying to outline the problem area and set up requirements for a solution to the problem of renumbering. If they do not succeed, many enterprises will get provider independent IPv6 addresses and that will put a lot of pressure on the routing system. Another way is for sites to use NAT66 like they used NAT in the IPv4 network, something a lot of IPv6 gurus wants to avoid at all cost. There is a draft called “IPv6 Enterprise Network Renumbering Scenarios and Guidelines” that covers this in a good way:

“IPv6 site renumbering is considered difficult. Network managers currently prefer to use Provider Independent (PI) addressing for IPv6 to attempt to minimize the need for future renumbering. However, widespread use of PI may create very serious BGP4 scaling problems and PI space is not always available for enterprise according to the RIR (Regional Internet Registry) policies. It is thus desirable to develop tools and practices that may make renumbering a simpler process to reduce demand for IPv6 PI space. In any case, renumbering may be necessary for other reasons. This document undertakes scenario descriptions, including documentation of current capabilities and existing BCPs, for enterprise networks. It takes [RFC5887] and other relevant documents as the primary input.”

The enterprise renumbering draft also covers a few reasons on why a enterprise network will need renumbering:

  • Switching to a new ISP
  • Adding new prefixes from uplink provider
  • Adding a new uplink for multihoming
  • Company merger or split
  • Change of network topology and/or sub netting
Among the tools suggested to minimize the impact is of course using DNS names, using service location protocol, using DHCP PD internally and some use of Unique Local Addresses alongside the global addresses. It also discusses in detail use of ND, DHCP and DNS in order to make the renumbering procedure easier.
This document also highlights some gaps for further work. One of them being that making it very simple to renumber sites will make it hard to manage black lists as the site just quickly renumbers itself… Also the fact that any automatic renumbering procedure can be misused, making it easy to hijack a complete site.

6man – managing the IPv6 protocol

The 6man working group is the maintainers, but also cleaning staff, for IPv6. Some old (yes, IPv6 is getting old before deployment) documents and proposals are being moved to historic status, some issues are being more clearly specified or changed, based on deployment experience. The 6man status page has a long list of RFCs, drafts and documents in RFC editor’s queue.
One of the new drafts in this working group discuss management of Address Selection policies for hosts. RFC 3484 provides the rules, but also opens up for other systems to give input to the policies used. The draft “Considerations for IPv6 Address Selection Policy Changes” discusses how this can happen and gives some examples. Another draft proposes managing these policies by using DHCPv6 – “Distributing Address Selection Policy using DHCPv6“.

Executive summary: The polls are coming in and the IETF is listening

To summarize, the IETF is actively maintaining IPv6 and making sure that the transition moves smoothly. Based on feedback from service providers as well as enterprises and home users, the protocol is improved and many aspects fixed. When purchasing or downloading IPv6 software and equipment, it’s important to make sure that the vendors are up to date with the IPv6 standards and not basing their solutions on the more than 15 year old base documents.