IPv6 at CERN, a status report

Keywords

IPv6 (Next Generation Internet Protocol), NAT-PT (Network Address Translation -Protocol Translation), DSTM (Dual Stack Transition Mechanism), QTPv6 (Quantum Test Program IPv6), GTPv6 (Geant Test Program IPv6), 6BONE (Test Bed for Deployment of IPv6), 6TAP (Native IPv6 Exchange in Chicago)

Abstract

In this paper we report on the current status of the IPv6 pilot project at CERN. The network consists of hosts running common operating systems like Solaris, Linux (Red Hat and Suse), FreeBSD, Windows 2000 and Windows XP. Routers connect this network to 6BONE [6bone] via native IPv6 connections (6TAP [6tap]) or tunnels. Transition mechanisms like NAT-PT [natpt] and DSTM [dstm] are being tested. A set of tools is available for monitoring and information retrieval.

Introduction

CERN got involved in 6REN (IPv6 Research & Education Network) [6ren] and QTPv6 (Quantum IPv6 Test Program) [qtpv6] in the second part of 1999. A native IPv6 connection to 6TAP and a router in Amsterdam was created soon. A pTLA (pseudo Top Level Aggregator) was acquired in early 2001 and BGP4+ peering with some 15 other sites is currently established. The Ipv6 pilot network consists of about 10 hosts running various common operating systems, two routers (one in Geneva and one in Chicago connected to 6TAP) and another router for NAT-PT 

Topology

Figure 1 gives an overview of network, compressed in time: QTPv6 does not exist any more, because the native MBS (Managed Bandwidth Service) connection to the core router in Amsterdam disappeared with the replacement of TEN155 [ten155] by GEANT [geant]. Meanwhile a new high speed IPv6 network infrastructure is being created by the 6NET [6net] initiative, to which we hope to connect in due time. Also the tunnel to Chicago will be replaced soon by a native connection.

Three types of tunnels have been implemented: 6to4, 6in4 and GRE (Generic Routing Encapsulation). Each 6in4 or GRE tunnel is a manually configured point-to-point connection. The 6to4 mechanism specifies a unique IPv6 routing prefix for each end user, providing a one-to-one match with an IPv4 address. Via a pseudo-interface (IPv4 tunnel endpoint) Ipv6 connectivity is assured over the IPv4 routing infrastructure 

Because the IPv6 network resides outside the CERN firewall, which does not handle IPv6 yet, bypassing it to get  “IPv6 to the office” was considered a safety hazard (in spite of certain access restrictions to this network).  Fortunately, the latest field test version of our router software allowed for extended access control lists, which made it possible to safely create a VPN (Virtual Private Network) from the router to a block of offices, where some workstations running Red Hat Linux and Windows XP are Ipv6 capable. Ipv6 on Windows 2000 was initially possible with an “IPv6 Technology Preview”, but it became unstable, supposedly after a set of security upgrades.

Transition Mechanisms

IPv6 only nodes need access to the IPv4 world for some time to come. We are testing two methods:

·         NAT-PT: Here IPv6 packets are converted to IPv4 packets and vice versa [natpt]. Every application has to be IPv6 capable. A dedicated router in our network is running this protocol converter. The system is stable but slow and does not support FTP yet. It allows IPv4 access to the IPv6-only webserver (on Suse Linux) which also does rsh access to a router that does not support rsh for IPv6.

·         DSTM: Here packets from an IPv4 application are encapsulated in IPv6 packets and sent to a gateway, which de-encapsulates and forwards them to the IPv4 destination and vice versa. A first successful test has been done with a static client on a FreeBSD host with a server/gateway located at ENST-Bretagne.  Currently we are trying to set up a dynamic server/gateway at CERN with software from INRIA and ENST-Bretagne