Abstract
Over the last decade, IPv6 has established itself as the most mature network protocol for the future Internet. Its recent deployment in core networks of operators, its availability to end customers of multiple ISPs together with the availability of native access to large services like Google assess the increasing penetration of IPv6. While its deployment from the inside of the network leading to the edges is successful, the transition remains an issue today for many enterprises which see it as a tedious and error prone task for network administrators. To fill this gap, we present the necessary algorithms and provide the supporting tools to enable this transition to become automatic. Based on a model of an IPv4 network, we describe the algorithms to build an optimized IPv6 adressing scheme and to automatically generate the adequate security plan as well as the corresponding configurations for the different devices in the network.
I. INTRODUCTION
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 tricks like NAT, the exhaustion of available addresses, and other scale issues like routing tables explosion will occur in a near future. IPv6 [1] was defined with a bigger address space (128 bits) and comes along with new built-in services (address autoconfiguration [2], native IPSec, routes aggregation, simplified header...). Despite its slow start, IPv6 is today more than ever the most mature network protocol for the future Internet. To faster its acceptance and deployment, it has however to offer capabilities reducing and often eliminating the man in the loop. We are convinced that such features are also required for the evolutionary aspects of an IP network, the transition from IPv4 to IPv6 being an essential one. Many network administrators are indeed reluctant to deploy IPv6 because they do not fully master the protocol itself and because they do not have sufficiently rich algorithmic support to seamlessly manage the transition from their IPv4 networks to IPv6. To address this issue, we investigate, design and aim at implementing a transition framework with the objective of making it selfmanaged. The contributions of this paper are : 1) a set of algorithms that automate the generation of the IPv6 addressing scheme for an IPv4 enterprise network that can be enriched with on-the fly administrator constraints; 2) an algorithm that generates the security configuration of firewalls for the newly created IPv6 addressing plan; 3) the description of a fully operational, openly available and extensively tested in real environments transition engine that also propagates on-demand the configuration to the devices. The structure of the paper is as follows. In Section II, we describe the network modeling we used and the algorithms we defined to enable an automatic addressing and configuration of an IPv6 network. Section III focuses on the security aspects, where the security plan of the new IPv6 network is automatically derived. We evaluate and validate in Section IV our transition engine implementation through various scenarios. Section V reviews related work on IPv6 deployment. In Section VI we conclude this paper.
II. IPV6 ADDRESSING
We address enterprise networks as defined in [3], i.e. networks that have multiple internal links, one or more routers interconnections to one ore more Internet Service Providers (ISP). We assume that the IPv6 network has to be built without direct mapping from IPv4 to IPv6 addressing. A. Network Model The network topology is modeled by an oriented graph where a vertex consists of a router or a network (end-user or interconnection). An edge connects either two routers via a point-to-point network or a router to a network. This graph provides a logical view of the network to be deployed. The root of the graph is the border router connected to the IPv6 Internet. There will be as many graphs as border routers that are connected to an ISP. The interconnection between a border router and the IPv6 provider is not considered in our model. We only consider this interconnection from the filtering point of view, as firewall rules will be set at the border to protect the network. Inside the network, the IPv6 connection is seen as native.


Download full report
http://googleurl?sa=t&source=web&cd=1&ve...466223.pdf&ei=sGVbTvyHCMyIrAfW7MSMCA&usg=AFQjCNE67UmgX3ZMnMLq6F9k44IFXORRmQ