GÉANT IPv6 Workplan

Participants

• Tim Chown, University of Southampton/UKERNA, UK (project leader)
• David Harmelin, DANTE, UK
• Christian Schild, JOIN Project, DFN, Germany
• Wilfried Woeber, ACOnet, Austria
• Simon Leinen, SWITCH, Switzerland
• Stig Venaas, UNINETT, Norway
• Bernard Tuy, Renater, France
• Janos Mohacsi, BME, Hungary
• Yves Schaaf, RESTENA, Luxembourg
• Juergen Rauschenbach, DFN, Germany

It is planned that the project collaborate with other IPv6-focused projects within the European community, and beyond where appropriate. This, for example, might include adopting results and deliverable packages from the current EU 5th Framework 6INIT project or the new 6WINIT project.

Objectives

• To gain and develop an understanding of the issues involved in deploying IPv6 networks, in terms of areas including physical infrastructure, address allocation, registries, routing and DNS operation.
• To gain experience in operational management of an IPv4/IPv6 backbone.
• To gain insight into the implications of the new IPv6 protocol, and how it will impact the backbone network, NRN backbones and University end sites.
• To deploy and operate a production(or as close as possible to) quality IPv6 backbone network that can interconnect to any GÉANT participant IPv6 network, and that can peer with/offer transit to other world-wide IPv6 networks.
• To encourage NRNs to participate in GTPv6 such that they in turn may offer IPv6 connectivity to their own Universities/sites.
• To collaborate with other European IPv6 projects to gain a better mutual understanding of IPv6 deployment issues.

Description of Activities

Work items are split into "trial" and "study" areas indicating where practical work can be done and where reporting will be theoretical.

Primary Work Items

• Platforms, routing and interoperability. (Christian Schild)
  Trial:
  • Host and router platform implementation tracking. Reporting on deployment experiences, maintaining pointers to "howto" style documentation.
  • Informal interoperability tests (rigorous tests would be too time-consuming).
  Study:
  • Study of IPv6 network routing protocols and peering issues.

• DNS (David Harmelin)
  Trial:
  • Test BIND9
    • New IPv6 related records
    • Named behavior under high load
    • Implications of dynamic DNS
  • Run a semi-operational IPv6 DNS tree (on-going)
  • Assess potential interconnections to other DNS trees
    • Include operation of reverse DNS (and lookups)
  • Produce
    • Samples of configuration files
    • Configuration tips to the DNS admin
    • Configuration tips to the end-user
  Study:
  • Understand the problems at stake
    • AAAA records versus A6 records
    • DNAME records
    • Migration issues
    • Requirements for a DNS test platform

• Registries and addressing (Wilfried Woeber)
  Trial:
  • Management of IPv6 registry - registry interactions/requirements.
  • IPv6 address assignment policies.
  • Using RIPE production address space.
  Study:
  • Working with RIPE (and their IPv6 working group), tracking developments.
  • Promotion of address assignment policy/best practice to NRNs and sites.

• Transition tools. (Stig Venaas)
  Trial:
  • Selected tools: NAT-PT, 6to4
  • Tunnels and tunnel brokers.
  Study:
  • How does a backbone ISP migrate?
  • How does a university migrate?
  • Transition tool comparison for given scenarios.
  • Routing models, e.g. should IPv6/IPv4 use the same AS?

• Applications. (Tim Chown)
  Trial:
  • Core applications: mail, web, ...
  • Other applications: vic, rat, openldap, ...
  • IPv6 and Java (JDK 1.4)
  Study:
  • Track status of IPv6-enabled applications.
  • Study middleware issues/requirements.
  • Report on porting issues.

Secondary Work Items

• Network monitoring. (Simon Leinen)
  Trial:
  • Be able to report on application/protocol usage and possible problems.
  • Be able to report on network connectivity/routing information.
  Study:
  • Understand IPv6 traffic flows, performance issues.
  • Requirements put on monitoring tools/protocols by IPv6.
  (Integrate consideration of IPv6 with TF-NGN Network Monitoring project.)

• Multicast IPv6. (Tim Chown)
  Trial:
  • Trial existing implementations, e.g. FreeBSD/KAME PIM-SM.
  • Run multicast applications, e.g. vic, rat, icecast.
  • Attempt to deploy PIM-SM (or similar) between participant sites.
  Study:
  • Investigate scoping issues.
  (Integrate where possible with TF-NGN Multicast project.)

• Wireless access. (Tim Chown)
  Trial:
  • Deploy new technology, WaveLAN, Bluetooth, etc.
  • Run Mobile IPv6 implementations.
  Study:
  • Implications of large numbers of autoconfiguring hosts?
  • Study interworking with 3G IPv6 solutions.

• Multihoming. (Possibly Wilfried Woeber)
  Trial:
  • Possible IETF proposals, if arrive soon.
  • Src/dst address selection behaviour.
  Study:
  • Other IETF proposals.
  • Consider possibilities for per-provider service selection and for network resilience.
  • Reconsider GSE/8+8 addressing.

• IPSec. (Yves Schaaf)
  Trial:
  • Evaluation of IPv6 IPsec software, e.g. FreeSWAN/Pluto or KAME/Racoon.
  Study:
  • Study of issues in usage of IPv6 IPSec.

• Firewalls. (Mohacsi Janos)
  Trial:
  • Existing implementations: ip6fw (FreeBSD), netfilter (Linux).
  • Commercial firewalls: e-Border
  Study:
  • IPv4 compatibility.
  • Built-in translators.
  • Address scope issues.

Study areas omitted

• IPv6 and QoS
• DHCPv6
• IPv6 fragmentation issues.

Programme

There are also "background" tasks to be performed by the GTPv6 leader:

• Identification of European projects with mutual interest. The GTPv6 web site will contain links to such projects, and members of such projects may be invited to attend GÉANT meetings.
• Assistance for new sites/participants wishing to join GTPv6.
• Identifying potential new partners/networks with which to liaise outside of the European academic backbone. This may include collaborations with US or Japanese networks.
• General tracking of IETF developments.
• Promotion of the GÉANT IPv6 project.
• Ensuring the GTPv6 web presence is regularly maintained.

Resource requirements

The Quantum (QTPv6) Network

The QTPv6 testbed network was characterised by the following:

• The network was centered on a core ATM router provided by Ericsson Telebit. Thus the topology was a "star" with no sites having redundant/resilient links to other sites. While a good test environment, such a topology is not typical in deployed backbone networks.
• Participants used whatever IPv6-capable router they could spare for their experiments. This typically meant that the routers used were either low specification or PC-based routers. The most common platform used was Cisco, although Cisco provided only "beta" (not commercially-supported) IPv6 images.
• Participants were able to connect to the core router either via "native" IPv6 links carried in ATM PVCs or by IPv6-in-IPv4 tunnels. The bandwidth of the PVCs was typically 512Kbit/s. While native connectivity is desirable, the bandwidth available for PVCs is/was a limiting factor.
• Address space was allocated centrally from a 6bone prefix assigned to the QTPv6 project, i.e. 3ffe:803c::/34. Each site (or NRN) received a /48 prefix under that /34 from which it, and its own participant sites, allocated IPv6 addresses. Thus NRNs did not get to utilise more than what amounts to site level address space.
• BGP4+ was used as the common routing protocol between networks.
• Very few "real" userland applications were run on QTPv6. The JOIN project reported IRC was the most popular application over IPv6 on their network. Services such as DNS were run with success however.

Resource requirements for GÉANT

The GTPv6 group feels that it should seek to deploy well-specified IPv6-purposed routers at the earliest possible opportunity. Emphasis should be placed on establishing a production quality (or as close as possible given funding constraints) network.

There are two constraints on the router interconnections:

• The new GÉANT network will not be ATM-based; thus there will not be any ability to run native PVC-based connections beyond the date at which such PVCs will be removed, i.e. November 2001. It should also be noted that many NRNs will discontinue ATM use well before that date.
• There are no fibre circuits that could be utilised for native IPv6 interconnections within the GÉANT backbone infrastructure, unless such fibres could be acquired as part of the procurement deal for "test" purposes (e.g. perhaps lines of E3 bandwidth?).

• Running IPv6 as a secondary protocol to IPv4 on production GÉANT backbone routers. Gradually more and more traffic becomes IPv6. At present this is not the more likely option since most router vendors have no commercially-supported IPv6 product.
• Running IPv6 on parallel fibre infrastructure. Such an IPv6-only network would eventually become prominent. This is clearly the more costly option in terms of resources. It also has a disadvantage if the native bandwidth is significantly less that that available over IPv6-in-IPv4 tunnels.
• Running IPv6 as the primary protocol on routers also running IPv4, with interconnections tunnelled. As and when the infrastructure allows native IPv6 links, tunnels are removed and replaced by such native links. Realistically, this is the most probable option.

The tunnels could be set up manually, following the topology of the GÉANT network, or 6to4 could be used (which would leverage the IPv4 routing tables for best efficiency).

GTPv6 network deployment

The GÉANT IPv6 network will be characterised by:

• A topology representative of a "real" backbone network, i.e. core routers with a number of multiple interconnections. This is in contrast to the QTPv6 "star" yet would most likely not extend to a full mesh. It is unlikely that there will be a "core" router; this has the "benefit" that such a router does not have to be remotely maintained.
• Participants will ideally use well-specified router hardware (see below) from commercial vendors.
• Interconnections will most likely be tunnelled IPv6-in-IPv4 initially. Where possible native connections will be sought; options in the absence of ATM PVCs will be investigated (e.g. IPv6 over MPLS).
• Participant NRNs will be encouraged to utilise SubTLA address space where possible, i.e. production IPv6 address space obtained from RIPE under the 2001::/16 prefix. This stresses the importance of address allocation policy issues. Sites at very early stages of investigating IPv6 may be best advised by their NRN to connect via 6bone prefixes/tunnels (this is a matter for discussion).
• BGP4+ will likely remain the routing protocol between networks.
• The adoption, porting and development of user applications will be encouraged, though it is appreciated that GÉANT participants may lack the time to port or develop new software. End sites within NRNs may have the resources, especially on European funded projects. It may also be possible to obtain commercial vendor support in this area.

Peering/transit networks will need to be identified and probably made more formal than under QTPv6.

Router equipment

In order to best facilitate a high quality router infrastructure on GTPv6 the project will approach commercial router vendors with a view to gaining equipment donations or loans. The project will seek the backing of each NRN to which the equipment is to be loaned (either directly or to a site acting on their behalf).

It is hoped that equipment can be obtained for at least each named participant in GTPv6. Deliverables would be used as a means of justifying extensions of loans where required.

There is a possibility of funding via the IST 5th Framework, but such funding requires commercial partners. Some discussions are ongoing.

Physical location of the routers may be an issue. It is, for example, more likely that native connectivity may be gained at a major GÉANT PoP for an NRN, but that may not be at the participant's site.

PC-based router equipment may be used in some test configurations where the functionality on such a platform (e.g. PIM-SM on FreeBSD/KAME) is not available on commercial routers.

Timescale

• Report 1: at the end of Month 8 of the project (June 2001) in which the primary work items will be reported on.
• Report 2: at the end of the year (October 2001) in which the secondary items will be reported on and the primary work item reports updated.

It is hoped that a new IPv6 infrastructure can be put in place before July 2001. However, this is dependent on various factors, not least router provision. A "production quality" service would be sought before the end of October 2001 (i.e. before the ATM PVCs are removed on the old QTPv6 infrastructure).

For the operation of a production backbone, early recommendation and promotion of address assignment policies is required. Best practice is to be set by RIPE and its IPv6 Working Group.

Results and Deliverables

Report 2 will include updated reports on each primary work item, plus reports on each adopted secondary work item (items with no leader by February 2001 will be dropped from the report). Report 2 will be delivered at the end of GÉANT Year 1 (end of October 2001). Both reports will include introductory and summary text from the IPv6 project leader.

It is intended that a new IPv6 infrastructure, ideally based on commercial donated/leased routers, will be in place by July 2001. The existing QTPv6 infrastructure will continue to be of use in the short term but will cease to function in November 2001 (the ATM PVCs will no longer exist).

Dissemination is also important. This will be primarily online via the GTPv6 website but also via presentations at appropriate events. The online presence will include network maps, sample configuration files, and similar information.