Section: New Results

IPv6 transition

Participants : Frédéric Beck, Isabelle Chrisment [ contact ] , Olivier Festor.

IP networks are widely spread and used in many different applications and domains. Their growth continues at an amazing rate sustained by its high penetration in both the Home networks and the mobile markets. Although often postponed thanks to hacks like NAT, the exhaustion of available addresses, and other scale issues like routing tables explosion will occur in a near future. The IPv6 protocol was defined [RFC2460] with a bigger address space (128 bits) and comes along with new built-in services (address auto-configuration [RFC2462], native IPSec and other functionalities, routes aggregation, simplified header...). It is a fact that IPv6 deployment is slower than foreseen. Many reasons are valid to explain this: economic, political, technological, and human. In this project we are interested in the scientific part of the technological problems that highly impact human acceptance. Many network administrators are indeed reluctant to deploy IPv6 because (1) they do not well know the protocol itself and (2) they do not have sufficiently rich software support to manage seamlessly the transition from their Ipv4 to Ipv6 networks. To address this later issue, we propose to investigate, design and later implement a transition framework with the objective of making it self-managed. As the IPv4-IPv6 transition is a very complex operation, and can lead to the death of the network, there is a real need for a transition engine to ease the network administrators task; the ideal being a "one click" transition.

The first step of our work was to establish a data model representing the network on which the transition will be applied. The addressing mechanism is based on a logic representation of the network to transition. This means that, for example, Virtual LANs will be seen as different links in the graph, even if physically they are multiplexed on the same link. The network will thus be represented as a graph with the border router (interconnected with the ISP) as root. In case of multi-homing, we would have one logical view of the network per border router. We defined a specification of the different network topologies (for example, simple networks as lines or trees, bus, mesh, rings) that can be transitioned from IPv4 to IPv6 [27] . We also described all the procedures for IPv4-IPv6 numbering like they were listed for renumbering an IPv6 network in the RFC4192.

Then, we identified the pre-requisites to the transition of an IPv4 network to IPv6 and we built the specification of a transition engine and the associated algorithms given an addressing scheme for the site, using the minimal number of /64 prefixes possible and optimizing the aggregation [28] .