draft-ietf-v6ops-campus-transition-00.txt   draft-ietf-v6ops-campus-transition-01.txt 
IPv6 Operations T. Chown IPv6 Operations T. Chown
Internet-Draft University of Southampton Internet-Draft University of Southampton
Expires: April 18, 2007 October 15, 2006 Intended status: Informational March 28, 2007
Expires: September 29, 2007
IPv6 Campus Transition Scenario Description and Analysis IPv6 Campus Transition Scenario Description and Analysis
draft-ietf-v6ops-campus-transition-00 draft-ietf-v6ops-campus-transition-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2007. This Internet-Draft will expire on September 29, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
In this document we consider and analyse the specific scenario of In this document we consider and analyse the specific scenario of
IPv6 transition and deployment in a large department of a university IPv6 transition and deployment in a large department of a university
campus network. The department is large enough to operate its own campus network. The department is large enough to operate its own
instances of all the conventional university services including (for instances of all the conventional university services including (for
example) web, DNS, email, filestore, interactive logins, and remote example) web, DNS, email, filestore, interactive logins, and remote
and wireless access. The scenario is a dual-stack one, i.e. and wireless access. The scenario is a dual-stack one, i.e.
transition to IPv6 means deploying IPv6 in the first instance (and transition to IPv6 means deploying IPv6 in the first instance (and
probably for some time) alongside IPv4. This analysis identifies the probably for some time) alongside IPv4. This analysis identifies the
available components for IPv6 transition, while validating the available components for IPv6 transition, while validating the
applicability of the IPv6 Enterprise Network Scenarios informational applicability of the IPv6 Enterprise Network Scenarios informational
text. It focuses on the network elements of the transition, rather text. It focuses on the network and associated service elements of
than the application elements. the transition, rather than the application elements.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Site Philosophy . . . . . . . . . . . . . . . . . . . . . 4 1.1. Site Philosophy . . . . . . . . . . . . . . . . . . . . . 4
2. Discussion of Scenarios Network Infrastructure Components . . 5 2. Discussion of Scenarios Network Infrastructure Components . . 5
2.1. Component 1: Enterprise Provider Requirements . . . . . . 5 2.1. Component 1: Enterprise Provider Requirements . . . . . . 5
2.2. Component 2: Enterprise Application Requirements . . . . . 6 2.2. Component 2: Enterprise Application Requirements . . . . . 6
2.3. Component 3: Enterprise IT Department Requirements . . . . 7 2.3. Component 3: Enterprise IT Department Requirements . . . . 7
2.4. Component 4: Enterprise Network Management System . . . . 8 2.4. Component 4: Enterprise Network Management System . . . . 8
2.5. Component 5: Enterprise Network Interoperation and 2.5. Component 5: Enterprise Network Interoperation and
Coexistence . . . . . . . . . . . . . . . . . . . . . . . 9 Coexistence . . . . . . . . . . . . . . . . . . . . . . . 9
3. Discussion of Network Infrastructure Component Requirements . 10 3. Discussion of Network Infrastructure Component Requirements . 10
3.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Configuration of Hosts . . . . . . . . . . . . . . . . . . 10 3.3. Configuration of Hosts . . . . . . . . . . . . . . . . . . 10
3.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Applications . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Applications . . . . . . . . . . . . . . . . . . . . . . . 11
3.6. Network Management . . . . . . . . . . . . . . . . . . . . 11 3.6. Network Management . . . . . . . . . . . . . . . . . . . . 11
3.7. Address Planning . . . . . . . . . . . . . . . . . . . . . 11 3.7. Address Planning . . . . . . . . . . . . . . . . . . . . . 11
3.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 11 3.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12
3.9. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 11 3.9. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 12
4. Specific Scenario Component Review . . . . . . . . . . . . . . 12 4. Specific Scenario Component Review . . . . . . . . . . . . . . 12
4.1. Network Components . . . . . . . . . . . . . . . . . . . . 12 4.1. Network Components . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Physical connectivity (Layer 2) . . . . . . . . . . . 12 4.1.1. Physical connectivity (Layer 2) . . . . . . . . . . . 13
4.1.2. Routing and Logical subnets (Layer 3) . . . . . . . . 12 4.1.2. Routing and Logical subnets (Layer 3) . . . . . . . . 13
4.1.3. Firewall . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.3. Firewall . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.4. Intrusion Detection System . . . . . . . . . . . . . . 12 4.1.4. Intrusion Detection System . . . . . . . . . . . . . . 13
4.1.5. Management . . . . . . . . . . . . . . . . . . . . . . 12 4.1.5. Management . . . . . . . . . . . . . . . . . . . . . . 13
4.1.6. Monitoring . . . . . . . . . . . . . . . . . . . . . . 12 4.1.6. Monitoring . . . . . . . . . . . . . . . . . . . . . . 13
4.1.7. Remote access . . . . . . . . . . . . . . . . . . . . 13 4.1.7. Remote access . . . . . . . . . . . . . . . . . . . . 14
4.1.8. IPv6 External Access . . . . . . . . . . . . . . . . . 13 4.1.8. IPv6 External Access . . . . . . . . . . . . . . . . . 14
4.2. Address Allocation Components . . . . . . . . . . . . . . 13 4.2. Address Allocation Components . . . . . . . . . . . . . . 14
4.2.1. IPv6 network prefix allocation . . . . . . . . . . . . 13 4.2.1. IPv6 network prefix allocation . . . . . . . . . . . . 14
4.2.2. IPv6 Address allocation . . . . . . . . . . . . . . . 14 4.2.2. IPv6 Address allocation . . . . . . . . . . . . . . . 14
4.3. Services . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Core Services . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1. Email . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.1. Email . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.2. Web Hosting . . . . . . . . . . . . . . . . . . . . . 14 4.3.2. Web Hosting . . . . . . . . . . . . . . . . . . . . . 15
4.3.3. Databases . . . . . . . . . . . . . . . . . . . . . . 14 4.3.3. Directory Services . . . . . . . . . . . . . . . . . . 15
4.3.4. Directory Services . . . . . . . . . . . . . . . . . . 15 4.3.4. DNS . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.5. DNS . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3.5. NTP . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.6. PKI . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.3.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 16
4.3.7. NTP . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Hard-coded address points . . . . . . . . . . . . . . . . 16
4.3.8. Multicast . . . . . . . . . . . . . . . . . . . . . . 15 5. IPv6 Enterprise Deployment Procedure . . . . . . . . . . . . . 17
4.3.9. Remote login . . . . . . . . . . . . . . . . . . . . . 15 5.1. Advanced Planning . . . . . . . . . . . . . . . . . . . . 18
4.3.10. File serving . . . . . . . . . . . . . . . . . . . . . 15 5.2. Testbed/Trial Deployment . . . . . . . . . . . . . . . . . 19
4.3.11. Backups . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Production Deployment . . . . . . . . . . . . . . . . . . 20
4.4. Host and Device Platforms . . . . . . . . . . . . . . . . 16 6. Analysis: Dual-Stack Deployment - Transition toolbox . . . . . 21
4.4.1. Server platforms . . . . . . . . . . . . . . . . . . . 16 7. Analysis: Considerations beyond the Scenarios Document . . . . 22
4.4.2. Desktop/laptop platforms . . . . . . . . . . . . . . . 16 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.3. PDA platforms . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
4.5. User Tools . . . . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
4.5.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 24
4.5.2. Mail Client . . . . . . . . . . . . . . . . . . . . . 17 12. Informative References . . . . . . . . . . . . . . . . . . . . 24
4.5.3. Web Browser . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.5.4. Conferencing systems . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 28
4.5.5. Other collaboration tools . . . . . . . . . . . . . . 18
4.5.6. Usenet news client . . . . . . . . . . . . . . . . . . 18
4.5.7. Host communications . . . . . . . . . . . . . . . . . 18
4.6. Hard-coded address points . . . . . . . . . . . . . . . . 18
5. Analysis: Deployment Procedure . . . . . . . . . . . . . . . . 19
5.1. Advanced Planning . . . . . . . . . . . . . . . . . . . . 20
5.2. Testbed/Trial Deployment . . . . . . . . . . . . . . . . . 20
5.3. Production Deployment . . . . . . . . . . . . . . . . . . 21
6. Analysis: Dual-Stack Deployment - Transition toolbox . . . . . 22
7. Analysis: Considerations beyond the Scenarios Document . . . . 24
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. Informative References . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
The scope of the enterprise network transition scenarios is very The scope of the enterprise network transition scenarios being
large, much more so than that of the other three IPv6 transition considered by the IETF is very large, much more so than that of the
areas that have been studied within the IETF (ISP [9], unmanaged [7] other three IPv6 transition areas that have been studied (ISP [21],
and 3GPP [14]). The IPv6 Enterprise Network Scenarios [11] have been unmanaged [17] and 3GPP [27]). However, an IPv6 Enterprise Network
defined. In this document we present a specific case study area for Scenarios [23] description has been produced. In this case study
IPv6 transition, namely a large department (1,500 staff and students, document we present our experience in a specific area for IPv6
over 1,000 hosts) in an academic campus network. The purpose of this transition, namely a large department (1,500 staff and students, over
1,000 hosts) in an academic campus network. The purpose of this
document is to both define and analyse the IPv6 transition of such a document is to both define and analyse the IPv6 transition of such a
network, but also to test and validate the applicability of the IPv6 network, but also to test and validate the applicability of the IPv6
Enterprise Network Scenarios document to a specific example. Enterprise Network Scenarios document to a specific example. This
document describes the transition focusing on the network elements.
This document describes the transition at a campus, focusing on the
network elements. A separate document discusses ongoing issues with
campus transition, which are heavily related to the application
support and network management capability.
Our campus study falls under "Scenario 1" of the IPv6 Enterprise Our campus study falls under Scenario 1 of the IPv6 Enterprise
Network Scenarios [11] document, i.e. the campus network is an Network Scenarios [23] document, i.e. the campus network is an
existing IPv4 network, where IPv6 is to be deployed in conjunction existing IPv4 network, where IPv6 is to be deployed in conjunction
with the IPv4 network. with the IPv4 network.
"Scenario 1" has the assumption that the IPv4 network infrastructure Scenario 1 has the assumption that the IPv4 network infrastructure
used has an equivalent capability in IPv6. This document analyses used has an equivalent capability in IPv6. This document analyses
that assumption. The Scenario also has requirements, i.e. that the that assumption. The Scenario also has requirements, i.e. that the
existing IPv4 network infrastructure is not disrupted, and that IPv6 existing IPv4 network infrastructure is not disrupted, and that IPv6
should be equivalent or better than the network infrastructure in should be equivalent or better than the network infrastructure in
IPv4. The Scenario also notes that it may also not be feasible to IPv4. The Scenario also notes that it may also not be feasible to
deploy IPv6 on all parts of the network immediately. deploy IPv6 on all parts of the network immediately.
These assumptions and requirements will be discussed later in this These assumptions and requirements will be discussed later in this
text. text. An incremental deployment strategy may, for example, be a
desirable property.
It should also be noted why Scenarios 2 and 3 did not apply to this It should also be noted why Scenarios 2 and 3 did not apply to this
campus transition scenario. Scenario 2 talks of specific campus transition scenario. Scenario 2 talks of specific
applications, but in the campus case we wish to deploy IPv6 applications, but in the campus case we wish to deploy IPv6
pervasively, in wired and wireless networks, as an enabler for pervasively, in wired and wireless networks, as an enabler for
education and research, to encourage new application development. education and research, to encourage new application development.
Scenario 3 focuses on using IPv6 as the basis for most network Scenario 3 focuses on using IPv6 as the basis for most network
communication, but in the campus we already have a significant IPv4 communication, but in the campus we already have a significant IPv4
deployment that will be utilised for the foreseeable future (Scenario deployment that will be utilised for the foreseeable future (Scenario
3 would perhaps be more appropriate for a greenfield deployment). 3 would perhaps be more appropriate for a greenfield deployment).
1.1. Site Philosophy 1.1. Site Philosophy
The site which is the subject of this study is a large departmental The site which is the subject of this study is a large departmental
network on a campus. That network (prior to transition) is an IPv4 network on a campus. That network (prior to transition) is an IPv4
network with around 20 subnets, using a core network infrastructure network with around 20 subnets, using a core network infrastructure
that combines switch-router functionality in central devices, with that combines switch-router functionality in central devices, with
switches at the network edge. The main switching equipment is all switches at the network edge. The main switching equipment is all
VLAN capable. There are around 1,000 networked nodes and 1,500 VLAN (IEEE 802.1q) capable. There are around 1,000 networked nodes
users, not including transient wireless visitors. and 1,500 users, not including transient (mainly wireless) visitors.
The site wishes to deploy IPv6 dual-stack to support its own users The site wishes to deploy IPv6 dual-stack to support its own users
along with its teaching and research needs. The goal is to IPv6 along with its teaching and research needs. The goal is to IPv6
enable the network (on the wire) and services (DNS, SMTP, etc) such enable the network (on the wire) and services (DNS, SMTP, etc) such
that the whole operation is dual-stack. This in due course would that the whole operation is dual-stack. This in due course would
allow IPv6-only devices to be deployed within the fully IPv6-capable allow IPv6-only devices to be deployed within the fully IPv6-capable
environment. Some network links may become IPv6-only in the future. environment. Some network links may become IPv6-only in a subsequent
phase in the future.
This text has evolved over time. When we began writing, the This text has evolved over time. When we began writing, the
department did not have IPv6 capability on its existing IPv4 routing department did not have IPv6 capability on its existing IPv4 routing
equipment, thus a deployment method was required until the next equipment, thus an interim deployment method was required until the
procurement. We discuss that interim solution within this document, next router procurement. We discuss that interim solution within
and present the discussion from an initial point of an interim this document, and present the discussion from an initial point of an
parallel IPv6 deployment prior to unifying the IPv4 and IPv6 routing interim parallel IPv6 deployment prior to unifying the IPv4 and IPv6
on a single platform. Our initial deployment plan used a separate routing on a single platform. Our initial deployment plan used a
IPv6 path into the department with a parallel routing infrastructure separate IPv6 path into the department with a parallel routing
for IPv6. In practice this meant that our initial deployment used a infrastructure for IPv6. In practice this meant that our initial
parallel IPv6 routing infrastructure, using BSD routers, for over deployment used a parallel IPv6 routing infrastructure, using BSD
three years, prior to a unified solution on a commercial platform. routers, for over three years, prior to deployment of a unified
solution on a commercial platform.
2. Discussion of Scenarios Network Infrastructure Components 2. Discussion of Scenarios Network Infrastructure Components
In this section, we look at the issues raised by following the In this section, we look at the issues raised by following step by
Scenarios Network Infrastructure Components of the IPv6 Enterprise step the questions and considerations in the Scenarios Network
Network Scenarios [11] document, section 3.2. This section is Infrastructure Components of the IPv6 Enterprise Network Scenarios
written from the perspective of pre-transition planning, although we [23] document, section 3.2. This section is written from the
are writing the document having undergone transition. perspective of pre-transition planning, although we are writing this
document having undergone transition.
2.1. Component 1: Enterprise Provider Requirements 2.1. Component 1: Enterprise Provider Requirements
The answers to the questions posed in this section of the IPv6 The answers to the questions posed in this section of the IPv6
Enterprise Network Scenarios document are as follows: Enterprise Network Scenarios document are as follows:
o There is external access to/from the campus network, regional MAN o There is external access to/from the campus network, regional MAN
and National Research Network beyond. and National Research Network beyond.
o There are needs for access by remote staff, student and o There are needs for access by remote staff, student and
researchers. researchers.
o It is a single site, with four buildings. o It is a single site, with four geographically close buildings.
o There are no leased lines or wide-area VPNs between remote o There are no leased lines or wide-area VPNs between remote
buildings. buildings.
o The department has 12 IPv4 Class C's, the campus has a Class B, o The department has 12 IPv4 Class C's, the campus has a Class B,
independent from its provider (assigned prior to use of CIDR). independent from its provider (assigned prior to use of CIDR
[34]).
o The IPv4 and IPv6 provider is the National Research and Education o The IPv4 and IPv6 provider is the National Research and Education
Network (JANET in the UK). JANET provides a /48 IPv6 site prefix Network (JANET in the UK). JANET provides a /48 IPv6 site prefix
for the university. The university offers a /52 prefix for the for the university. The university offers a /52 prefix for the
department. department.
o The university and department make their own prefix allocations o The university and department make their own prefix allocations
for subnets. for subnets.
o There is no multihoming, and thus no multihomed clients. o There is no multihoming, and thus no multihomed clients. The
regional academic MAN supports network resilience measures.
o The provider (JANET) offers an IPv6 Tunnel Broker [3] service and o The provider (JANET) offers an IPv6 Tunnel Broker [6] service and
a 6to4 [4] relay, though the campus has native IPv6 connectivity a 6to4 [7] relay, though the campus is offered native IPv6
via its regional MAN. connectivity via its regional MAN.
o There is no external IPv6 routing protocol needed due to the use o There is no external IPv6 routing protocol needed due to the use
of static route configuration between the campus and the regional of static route configuration between the campus and the regional
network. network.
o There is no external data centre. o There is no external data centre.
o IPv6 will run over the same access links to campus as IPv4 does o IPv6 will run over the same access links to campus as IPv4 does
(the JANET backbone uses true dual stack, the regional MAN uses (the JANET backbone uses true dual stack, the regional MAN uses
6PE [19]). On campus, the IPv4 traffic to the department is 6PE [35]). On campus, the IPv4 traffic to the department is
received through a Nokia IP740 firewall, the IPv6 traffic will received through a commercial firewall solution, while the IPv6
initially be received through a BSD firewall. Thus the access traffic will initially be received through a BSD firewall. Thus
links into the department for IPv4 and IPv6 are different, though the access links into the department for IPv4 and IPv6 are
the goal in the longer term is to make them the same. (This different, though the goal in the longer term is to make them the
happened in 2006 when a new Checkpoint firewall was deployed.) same.
2.2. Component 2: Enterprise Application Requirements 2.2. Component 2: Enterprise Application Requirements
Answers to the next IPv6 Enterprise Network Scenarios section are as The focus of this document is network transition and services, but
follows: the answers to the next IPv6 Enterprise Network Scenarios section on
application aspects are as follows:
o The application inventory is discussed in the specific component o The application inventory is out of scope of this text.
review in the next section.
o We expect the first applications to be moved will be the support o We expect the first applications to be IPv6-enabled will be the
services, including DNS. The first applications should be the support services, including DNS. The first applications should be
common IPv4 applications, e.g. web, remote login and email, such the common IPv4 applications, e.g. web, remote login and email,
that IPv6 offers as least an equivalent service to IPv4 for the such that IPv6 offers as least an equivalent service to IPv4 for
core service applications. the core service applications.
o The academic environment has a good mix of open source and o The academic environment has a good mix of open source and
commercial software, predominantly either Microsoft or Linux, but commercial software, predominantly either Microsoft or Linux, but
with a growing number of Mac OS/X users. Specific platforms are with a growing number of Mac OS/X users. An exhaustive list of
reviewed in the component review in the next main section. Most desktop, laptop and PDA platforms is out of scope of this text.
open source applications have been upgraded to allow IPv6 Most open source applications have been upgraded to allow IPv6
operation; others can be upgraded given time. operation out of the box; others can be upgraded given time.
o The general goal is for applications to support both IPv4 or IPv6 o The general goal is for applications to support both IPv4 or IPv6
operation, i.e. to be IP agnostic. operation, i.e. to be IP agnostic.
o There is no use of NAT in the department's network. Home users, o There is no use of NAT in the department's network. Home users,
or users access into the network remotely from certain locations, or users access into the network remotely from certain locations,
may experience NAT at their client side. may experience NAT at their client side.
o NAT issues are relevant from the end-to-end perspective, for o NAT issues are relevant from the end-to-end perspective, for
establishment of end-to-end security where desired, and in establishment of end-to-end security where desired, and in
relation to IPv6 transition (remote access) methods that may be relation to IPv6 transition (remote access) methods that may need
run through NATs. to be run through NATs.
o There is a mix of internal and external applications. Where o There is a mix of internal and external applications. Where
limitations occur, it is mainly by policy not technology, e.g. as limitations occur, it is mainly by policy not technology, with
implemented in firewall restrictions. that policy typically implemented through firewall restrictions.
2.3. Component 3: Enterprise IT Department Requirements 2.3. Component 3: Enterprise IT Department Requirements
Here we list responses to the next IPv6 Enterprise Network Scenarios Here we list responses to the next IPv6 Enterprise Network Scenarios
section on IT Department Requirements. Again, in this section we section on IT Department Requirements. Again, in this section we
write our comments from a pre-transition perspective. write our comments from a pre-transition perspective.
o Ownership and support is all in-house. o Network and system ownership and support is all in-house.
o Remote VPNs are supported. o Remote VPNs are supported.
o No inter-site networking is required. o No inter-site networking is required.
o No IP mobility support is required at this point, though we expect o No IP mobility support is required at this point, though we expect
to use Mobile IPv6 between the department network and a local to use Mobile IPv6 between the department network and a local
community wireless network, on our wireless LAN deployment as it community wireless network, on our wireless LAN deployment as it
grows in size, and to pilot its use inter-campus. grows in size, and to pilot its use inter-campus.
o The IPv6 address plan for the department requires a /52 prefix. o The IPv6 address plan for the department requires a /52 prefix.
o There is no detailed asset database, though one exists providing a o There is no detailed asset database, though one exists providing a
host inventory (for DNS and DHCP use). host inventory (for DNS and DHCP use).
o There are no geographically separate sites. o There are no (significantly) geographically separate sites.
o The internal IPv4 address assignment mechanism is DHCP for o The internal IPv4 address assignment mechanism is DHCP for
clients, with manual configuration for servers. We thus expect to clients, with manual configuration for servers. We thus expect to
use DHCPv6 for at least some, if not all, IPv6 clients. This will use DHCPv6 for at least some, if not all, IPv6 clients. This will
depend on availability of DHCP client and server software. depend on availability of DHCP client and server software.
o Internal IPv4 routing is static or uses RIP. We thus expect to o Internal IPv4 routing is static or uses RIP. We thus expect to
use RIPng internally. use RIPng internally.
o We expect our IPv6 network management policy to be very similar to o We expect our IPv6 network management policy to be very similar to
that for IPv4. Having coherent policies should make network that for IPv4. Having coherent policies, and a consistent means
operation simpler. to configure them, should make network operation simpler.
o There is no QoS provision at present, largely due to the ample o There is no QoS provision at present, largely due to the ample
campus bandwidth (1Gbit/s uplink). campus bandwidth (1Gbit/s uplink).
o Security is applied through many technologies implementing our o Security is applied through many technologies implementing our
policies, e.g. firewall, email scanning, wireless LAN access policies, e.g. firewall, email scanning, IDS and wireless LAN
controls. We expect similar policies for IPv6, but need to access controls. We expect similar policies for IPv6, but need to
analyse differences. analyse potential differences (e.g. considering use of RFC3041
privacy addresses [5]).
o Training will be done in-house. o Training will be done in-house.
o The impacted software components are discussed in the next main o The impacted software service components are discussed in the next
section. Not all functions are upgradeable to IPv6; those that main section. Not all functions are upgradeable to IPv6; those
are not are discussed in the analysis section. Some are, e.g. use that are not are discussed in the analysis sections. Some are,
of OpenLDAP (IPv6 capable) as an interim step in place of MS e.g. use of OpenLDAP (IPv6 capable) as an interim step in place of
Active Directory (not IPv6 capable at the time of the analysis). MS Active Directory (not IPv6 capable at the time of the
Our view is that if components cannot be given immediate IPv6 analysis). Our view is that if components cannot be given
equivalents, this functionality will come in due course, and IPv4 immediate IPv6 equivalents, this functionality will come in due
transport can be used in the interim. But the goal is to course, and IPv4 transport can be used in the interim. But the
facilitate IPv6 capability. ultimate goal is to facilitate IPv6 capability.
o The impacted hardware components are discussed in the next main o The impacted hardware components are discussed in the next main
section. Not all hardware is upgradeable, e.g. network printers. section. Not all hardware is upgradeable, e.g. network printers.
There are no load balancing systems in use. There are wireless There are no load balancing systems in use. There are wireless
LAN hosts in the network that are mobile, but currently the LAN hosts in the network that are mobile, but currently the
wireless network is a single flat IPv4 subnet. There may be nodes wireless network is a single flat IPv4 subnet. There may be nodes
moving to external wireless networks (i.e. the local community moving to external wireless networks (i.e. the local community
wireless network). wireless network).
2.4. Component 4: Enterprise Network Management System 2.4. Component 4: Enterprise Network Management System
The responses to the next IPv6 Enterprise Network Scenarios section The responses to the next IPv6 Enterprise Network Scenarios section
are as follows: are as follows:
o No performance management is required. o No performance management is required. Systems are monitored for
loading for purposes for future capacity planning.
o There are a number of network management and monitoring tools in o There are a number of network management and monitoring tools in
use, which will need to be used in a dual stack or IPv6 mode, e.g. use, which will need to be used in a dual stack or IPv6 mode, e.g.
the nocol availability monitoring tools, and SNMP-based the nocol availability monitoring tools, and SNMP-based
management. management.
o The configuration management may include use of tools to configure o The configuration management may include use of tools to configure
services including DNS and email. services including DNS and email. In-house DNS management tools
are used.
o No policy management and enforcement tools are required. o No policy management and enforcement tools are required.
o No detailed security management is required, though we expect to o No detailed security management is required, though we expect to
manage the implementations including firewalls and intrusion manage the implementations including firewalls and intrusion
detection. detection, and here a consistent management interface for both
protocols is desirable..
o We may need to manage the deployed transition tools and o We may need to manage any specific deployed transition tools and
mechanisms. mechanisms.
o We need to analyse the considerations IPv6 creates for network o We need to analyse the considerations IPv6 creates for network
management, e.g. use (or not) of RFC3041 privacy addresses. The management, e.g. use (or not) of IPv6 privacy addresses. The need
need for user privacy is recognised, but the need for simplified for user privacy is recognised, but the need for simplified
management is also a strong consideration. management is also a strong consideration.
2.5. Component 5: Enterprise Network Interoperation and Coexistence 2.5. Component 5: Enterprise Network Interoperation and Coexistence
Answers to the final IPv6 Enterprise Network Scenarios section on Answers to the final IPv6 Enterprise Network Scenarios section on
Coexistence are as follows: Coexistence are as follows:
o The platforms that are required to be IPv6 capable are listed in o An exhaustive list of platforms that are required to be IPv6
the next main section. capable is out of scope of this text.
o There is only one network ingress and egress point to the site o There is only one network ingress and egress point to the site
that needs to be IPv6 capable; this is a Gigabit Ethernet that needs to be IPv6 capable; this is a Gigabit Ethernet
interface. interface.
o The required transition mechanisms are discussed in the analysis o The required transition mechanisms are discussed in the analysis
section. We expect to mainly use the VLAN [17] mechanism for section. In the initial phase of deployment, with the existing
internal IPv6 transport, with a parallel IPv6 routing IPv4 switch-router equipment not supporting IPv6 routing, We
infrastructure based on BSD routers, until the core infrastructure expect to mainly use the VLAN [32] mechanism for internal IPv6
is able to support IPv6 (via upgrade or a new procurement). transport, with a parallel IPv6 routing infrastructure based on
BSD routers, until the core infrastructure is able to support IPv6
(via upgrade or a new procurement).
o The transition to IPv6 will be enabled on the wire first, enabling o The transition to IPv6 will be enabled on the wire first, enabling
clients, with a phased introduction of service capability, as clients, with a phased introduction of service capability, as
discussed below in the analysis section. discussed below in the analysis section.
o The preferred mechanism for interoperation with legacy nodes is to o The preferred mechanism for interoperation with legacy nodes is to
use dual-stack and thus IPv4 to communicate to IPv4 nodes and IPv6 use dual-stack and thus IPv4 to communicate with IPv4 nodes and
to communicate to IPv6 nodes. We have not identified any in- IPv6 to communicate to IPv6 nodes. We have not identified any in-
house, non-upgradeable legacy applications. house, non-upgradeable legacy software applications (most in-house
applications are presented to users as web applications).
3. Discussion of Network Infrastructure Component Requirements 3. Discussion of Network Infrastructure Component Requirements
In this section, we discuss the network infrastructure component In this section, we discuss the network infrastructure component
requirements raised in the IPv6 Enterprise Network Scenarios [11] requirements raised in the IPv6 Enterprise Network Scenarios [23]
document, in section 4. document, in section 4. We document current IPv4 practices, and how
we see these being facilitated when IPv6 is deployed and enabled.
3.1. DNS 3.1. DNS
BIND9 is used for our three internal name servers. The servers will The open source package BIND (version 9) is used for our three
be made dual stack, to be available for IPv6 transport for local internal name servers. The servers will be made dual stack, to be
dual-stack or IPv6-only nodes. The three servers will each be listed available for IPv6 transport for local dual-stack or IPv6-only nodes.
with AAAA records, and AAAA glue added. The three servers will each be listed with AAAA records, and AAAA
glue added.
3.2. Routing 3.2. Routing
Internal routing is either statically configured or uses RIP. We Internal unicast routing is either statically configured or uses RIP.
thus expect to use RIPng for internal IPv6 routing. The external We thus expect to use RIPng for internal IPv6 routing. The external
routing is statically configured for IPv4, and thus is likely to be routing is statically configured for IPv4, and thus is likely to be
statically configured for IPv6. statically configured for IPv6.
3.3. Configuration of Hosts 3.3. Configuration of Hosts
IPv4 clients use DHCP for address and other configuration options. IPv4 clients use DHCP for address and other configuration options.
We expect to use Dynamic Host Configuration Protocol for IPv6 We expect to use Dynamic Host Configuration Protocol for IPv6
(DHCPv6) [5] for IPv6 clients. This will require analysis of the (DHCPv6) [11] for IPv6 clients. This will require analysis of the
IPv4 and IPv6 Dual-Stack Issues for DHCPv6 [16]. We expect some IPv4 and IPv6 Dual-Stack Issues for DHCPv6 [30]. We expect some
clients, especially in wireless LANs, to use IPv6 Stateless clients, perhaps those in wireless LANs, to use IPv6 Stateless
Autoconfiguration [1], and these nodes will need support for Autoconfiguration [3], and these nodes will need support for
Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6
[6] for other configuration options, including the IPv6 address of a [15] for other configuration options, including the IPv6 address of a
local DNS resolver. local DNS resolver.
Although IPv6 offers Stateless Autoconfiguration, it is expected that Although IPv6 offers Stateless Autoconfiguration, it is expected that
the managed environment will continue, driven from the asset the managed environment will continue, driven from the asset
database, for some time. Thus DHCPv6 is required. Use of Stateless database, for some time. The site administrators are comfortable
Autoconfiguration implies a requirement for dynamic DNS updates for with the use of DHCP for IPv4, and wish to use it for IPv6, for
such nodes. It is not yet decided how to apply or enforce that plan; global address and potentially IPv6 Privacy Address assignment. Thus
it may certainly be flexible with time. DHCPv6 is required. Use of Stateless Autoconfiguration implies a
requirement for dynamic DNS updates for such nodes. It is not yet
decided how to apply or enforce that plan; it may certainly be
flexible with time.
3.4. Security 3.4. Security
We need to identify new IPv6 related security considerations, and We need to identify new IPv6 related security considerations, and
those associated with transition mechanisms [20]. Site policies may those associated with transition mechanisms [37]. Site policies may
need to be updated as a result. need to be updated as a result.
3.5. Applications 3.5. Applications
The Application Aspects of IPv6 Transition [10] document describes Discussion of applications is out of scope of this document.
best porting practice for applications. There should also be However, the Application Aspects of IPv6 Transition [22] document
consideration for any required application proxies. describes best porting practice for applications. A new Advanced
Sockets API for IPv6 [13] defines the IP version independent API that
is now widely supported. Recent versions of Java support IPv4 and
IPv6 operation. There should also be consideration for making any
required application proxies dual-stack.
3.6. Network Management 3.6. Network Management
The network management and monitoring systems will need to embrace The network management and monitoring systems will need to support
IPv6, and any transition mechanisms used to deploy IPv6. Monitoring IPv6, and the management and monitoring of any transition mechanisms
includes usage tracking (e.g. via MRTG) and availability monitoring used to deploy IPv6. Monitoring includes usage tracking (e.g. via
(e.g. via Nagios). open source packages such as MRTG) and availability monitoring (e.g.
via the Nagios package).
3.7. Address Planning 3.7. Address Planning
The department receives 12 Class C prefixes for IPv4 use, and uses The department has been allocated 12 Class C prefixes for IPv4 use,
only globally routable addresses internally. The IPv4 address space and uses only globally routable addresses internally. No IPv4 NAT is
for the campus was obtained prior to CIDR, but the IPv6 address space used. The IPv4 address space for the campus was obtained prior to
is allocated from the UK National Research Network (JANET) address CIDR, but the IPv6 address space is allocated from the UK National
space under 2001:0630::/32. The university receives a /48 prefix, Research Network (JANET) address space. The university receives a
which is 2001:0630:d0::/48. The department has a /52 allocation /48 prefix, and the department has a /52 allocation within this
within this block of 2001:0630:d0:0:/52. block.
IPv6 address assignment planning is discussed in the IPv6 Unicast Given that global IPv4 addresses are in use throughout our network,
Address Assignment Considerations [18] text. we plan to use global IPv6 addresses as well. Since we also do not
expect to renumber (our IPv6 provider is expected to be JANET
indefinitely) and our connectivity is expected to be stable we do not
see any real need to deploy Unique Local Addresses (ULAs) [25].
Doing so would require full support for Default Address Selection
[12] (so that ULA source addresses are used for ULA destinations, and
global source addresses for global destinations) and running a two-
faced DNS (with ULAs advertised only internally), which we do not
currently do for IPv4.
IPv6 address assignment planning for a campus-style enterprise is
discussed separately in more detail in the IPv6 Unicast Address
Assignment Considerations [36] text.
3.8. Multicast 3.8. Multicast
IPv4 multicast is used for a number of applications, including the IPv4 multicast is used for a number of applications, including
AccessGrid. Connectivity is provided via the local campus and AccessGrid multi-party videoconferencing. Connectivity is provided
regional network. We expect to use both IPv6 ASM (i.e. PIM-SM), and via the local campus and regional network. We expect to use PIM-SM
we plan to make use of the Embedded-RP [8] technique. For bridging [33] for IPv6, initially as Any Source Multicast (ASM). We also plan
between IPv4 and IPv6 multicast, we believe an IPv4 - IPv6 multicast to make use of Source Specific Multicast (SSM) more heavily in IPv6,
gateway [21] may prove valuable. Finally, we expect to make use of bringing IPv6 and SSM together in one deployment cycle.
source specific multicast (SSM) more heavily in IPv6, bringing IPv6
and SSM together in one deployment cycle.
The use of IPv6 multicast makes it much simpler for our site to The use of IPv6 multicast makes it much simpler for our site to
generate its own globally unique group addresses than is the case for generate its own globally unique multicast group addresses than is
IPv4, where we need to use GLOP space from an upstream provider. For the case for IPv4, where we need to use GLOP space [8] from an
IPv6, you can generate your own unique group address for regular or upstream provider. For IPv6, you can generate your own unique
Embedded-RP groups based on your unicast prefix (typically /48 or multicast group address for regular groups [9] or Embedded-RP groups
/64). We expect to use Embedded-RP where possible, running our own [18] based on your unicast prefix (typically /48 or /64).
IPv6 RP to support our own content.
Since there is no MSDP [14] equivalent for IPv6, we only expect to
use regular unicast prefix based group addresses [9] within our own
organisational scope. For wider scope multicast we expect to use
Embedded-RP where possible, running our own IPv6 Rendezvous Point(s)
to support our own content. In terms of the IPv6 address
architecture [28], we plan to use a site scope (ff05) for our
department, with the university having organisational scope (ff08).
Locally assigned group IDs would honour the guidelines of RFC3307
[10].
3.9. Multihoming 3.9. Multihoming
The site is not multihomed for IPv4, and thus will not be for IPv6. The site is not multihomed for IPv4, and thus will not be for IPv6.
This is typical for UK academic networks, but may change in due This is typical for UK academic networks, where resilience is
course as resilience concerns rise. provisioned through the regional MAN links.
4. Specific Scenario Component Review 4. Specific Scenario Component Review
Here we describe specific technology in use now in the department. Here we describe specific technology in use now in the department.
Later in this section we discuss any items not included in the above Later in this section we discuss any items not included in the above
section, i.e. those not explicitly mentioned in the IPv6 Enterprise section, i.e. those not explicitly mentioned in the IPv6 Enterprise
Network Scenarios document. Note that not all applications and Network Scenarios document. Note that not all applications and
services have at the time of writing been made IPv6 capable. A gap services have at the time of writing been made IPv6 capable; in
analysis is the subject of a separate ongoing 'live' document. This general open source packages are IPv6 capable out of the box, but
text aims to be a stable description of the processes and thinking discussion of specific applications is outside the scope of this text
followed during our campus transition. (this text aims to be a stable description of the processes and
thinking followed during our campus transition).
4.1. Network Components 4.1. Network Components
4.1.1. Physical connectivity (Layer 2) 4.1.1. Physical connectivity (Layer 2)
o Switched Ethernet o Switched Ethernet
o Gigabit Ethernet o Gigabit Ethernet
o Wireless networking (802.11b) o Wireless networking (802.11a/b/g)
4.1.2. Routing and Logical subnets (Layer 3) 4.1.2. Routing and Logical subnets (Layer 3)
The hybrid Layer 2/3 routing equipment has approximately 20 internal The hybrid Layer 2/3 routing equipment has approximately 20 internal
IPv4 subnets (in effect, routed VLANs). There is no specific IPv4 subnets (in effect, routed VLANs). The only specific internal
internal routing protocol used. There is a static route via the site routing protocol used is RIP [2]. There is a static route via the
firewall to the main upstream provider (academic) running at 1Gbit/s. site firewall to the main upstream provider (academic) running at
1Gbit/s. We would expect to use RIPng [1] for IPv6 internally.
4.1.3. Firewall 4.1.3. Firewall
The firewall is currently Firewall-1 running on a Nokia IP740 The firewall is currently one running on a commercial hardware
hardware platform. There is one internal facing interface, one platform without IPv6 support. There is one internal facing
external facing interface, and two DMZ interfaces, one for wired interface, one external facing interface, and two DMZ interfaces, one
hosts and one for the Wireless LAN provision. for wired hosts and one for the Wireless LAN provision. We expect
the topology to remain the same, with the DMZ(s) becoming dual-stack.
4.1.4. Intrusion Detection System 4.1.4. Intrusion Detection System
Snort is used locally for IPv4 IDS. The Snort open source package is used locally for IPv4 IDS. Work on
IPv6 capability for Snort is ongoing, but needs to consider both
similar (e.g. application transport) issues as IPv4 as well as IPv6-
specific issues (e.g. excessive use of Hop-by-Hop options).
4.1.5. Management 4.1.5. Management
Some network management is performed by SNMP; there is no specific Some network management is performed by SNMP; there is no specific
package for this. There is a greater emphasis on monitoring than package for this (scripts used are in-house).
explicitly in management.
4.1.6. Monitoring 4.1.6. Monitoring
A number of tools are used, to monitor network usage as well as A number of open source tools are used, to monitor network usage as
systems availability, e.g. Nagios and MRTG. The network testing well as systems availability, e.g. Nagios and MRTG. The network
tools include iperf, rude and crude. testing tools include iperf, rude and crude.
4.1.7. Remote access 4.1.7. Remote access
o Livingston Portmaster 56K/ISDN dialup (being phased out) o RADIUS servers (our current RADIUS package supports IPv6)
o RADIUS servers (running Radiator)
o (Microsoft) VPN servers o VPN servers
4.1.8. IPv6 External Access 4.1.8. IPv6 External Access
o IPv6 connectivity will come via our regional network (which runs o IPv6 connectivity will come via our regional MAN (which runs 6PE)
6PE) through trunked (unrouted) VLANs across campus to our through trunked (unrouted) VLANs across campus to our departmental
departmental network. Because the existing IP firewall pre- network. Because the existing IP firewall pre-transition does not
transition does not support IPv6, IPv6 will need to be transported support IPv6, IPv6 will need to be transported into the
into the departmental network via a separate parallel IPv6 capable departmental network via a separate parallel IPv6 capable firewall
firewall (e.g. a BSD system using pf). (e.g. a BSD system using a package such as pf).
4.2. Address Allocation Components 4.2. Address Allocation Components
The department receives its IPv4 and IPv6 address allocations from The department receives its IPv4 and IPv6 address allocations from
the University. For IPv4, the University has a Class B allocation the University. For IPv4, the University has a Class B allocation
which is not aggregated under the JANET NREN. For IPv6, the which is not aggregated under the JANET NREN address space post-CIDR.
University receives its allocation from JANET. For IPv6, the University receives its allocation from JANET.
4.2.1. IPv6 network prefix allocation 4.2.1. IPv6 network prefix allocation
For IPv6, JANET has the prefix 2001:630::/32 from RIPE-NCC, as the For IPv6, JANET currently has a /32 prefix from RIPE-NCC, as the
national academic ISP in the UK. The University has been allocated national academic ISP in the UK. The university has been allocated a
2001:630:d0::/48 by JANET. The department transitioning will be /48 from this block by JANET. The department IPv6 deployment will be
allocated a /52 size prefix under 2001:630:d0::/48, i.e. 2001:630:d0: allocated a /52 size prefix from the university allocation.
0::/52.
In the initial deployment, we expect that IPv4 and IPv6 subnets will In the initial deployment, we expect that IPv4 and IPv6 subnets will
be congruent (and share the same VLANs). This is because the be congruent (and share the same VLANs). This is because the
existing subnet divisions are made for geographic or administrative existing subnet divisions are made for geographic or administrative
reasons that are not IP version dependent (e.g. by building location reasons that are not IP version dependent (e.g. by building location
or research group membership). or research group membership).
One advantage for IPv6 is that subnets will not need to be resized to One advantage of IPv6 is that subnets will not need to be resized to
conserve or efficiently utilise address space as is the case conserve or efficiently utilise address space as is the case
currently for IPv4 (as subnet host counts rise and fall for currently for IPv4 (as subnet host counts rise and fall for
administrative or research group growth/decline reasons). administrative or research group growth/decline reasons).
4.2.2. IPv6 Address allocation 4.2.2. IPv6 Address allocation
It is expected that the network devices will use a combination of It is expected that the network devices will use a combination of
address allocation mechanisms: address allocation mechanisms:
o Manually configured addresses (in some servers) o Manually configured addresses (in some servers)
skipping to change at page 14, line 11 skipping to change at page 15, line 4
conserve or efficiently utilise address space as is the case conserve or efficiently utilise address space as is the case
currently for IPv4 (as subnet host counts rise and fall for currently for IPv4 (as subnet host counts rise and fall for
administrative or research group growth/decline reasons). administrative or research group growth/decline reasons).
4.2.2. IPv6 Address allocation 4.2.2. IPv6 Address allocation
It is expected that the network devices will use a combination of It is expected that the network devices will use a combination of
address allocation mechanisms: address allocation mechanisms:
o Manually configured addresses (in some servers) o Manually configured addresses (in some servers)
o Stateful DHCPv6 (probably in fixed, wired devices and some o Stateful DHCPv6 (probably in fixed, wired devices and some
servers) servers)
o Stateless address autoconfiguration (probably in wireless and o Stateless address autoconfiguration (probably in wireless and
mobile devices) mobile devices)
o RFC3041 privacy addresses (in some client devices) o RFC3041 privacy addresses (in some client devices)
For devices using stateless or RFC3041 mechanisms, a Stateless DHCPv6 For devices using stateless or RFC3041 mechanisms, at least a
server will be required for other (non-address) configuration Stateless DHCPv6 service [15] will be required for other (non-
options, e.g. DNS and NTP servers. address) configuration options, e.g. DNS and NTP servers. It is
likely that a full DHCPv6 service would provide this function
however.
4.3. Services As discussed above, due to current experience with DHCP for IPv4,
where all addresses are managed centrally, we expect that use of
DHCPv6 for address allocation and management will be preferred (once
implementations are mature).
4.3. Core Services
4.3.1. Email 4.3.1. Email
There are three MX hosts for inbound email, and two main internal There are three MX hosts for inbound email, and two main internal
mail servers. Sendmail is the MTA. POP and IMAP (and their secure mail servers. Sendmail is the MTA. MailScanner is used for anti-
versions) are used for mail access, using the Cyrus IMAP open source spam/anti-virus. This uses external services including various RBLs
code. There is an MS Exchange server used by a growing proportion of for part of its spam checking. Successful reverse DNS lookup is
users (generally those wanting shared access to mail spools, e.g. required for sendmail to accept internal SMTP connections for
professors and secretaries). MailScanner is used for anti-spam/ delivery. Email access is provided by a variety of open source and
anti-virus. This uses external services including various RBLs for commercial client and server applications (including a web front end)
part of its spam checking. Successful reverse DNS lookup is required the details of which are outside the scope of this document.
for sendmail to accept internal SMTP connections for delivery.
We expect to continue to use sendmail for MX and MTA functions, as it
supports IPv6 out of the box. Each of our MX servers will be made
dual stack, noting the considerations in RFC3974 [20].
4.3.2. Web Hosting 4.3.2. Web Hosting
Web content hosting is provided either with Apache 2.x (open source) Web content hosting is provided either with Apache 2.x (open source)
or Microsoft IIS 5.0. Common components used to build systems with or in some cases commercial equivalents. Common components used to
are MySQL, PHP and Perl; these enable local tools such as Wikis to be build systems with are MySQL, PHP and Perl; these enable local tools
run. such as Wikis to be run. Apache 2.x has support for IPv6 included.
4.3.3. Databases
All database systems are presented to users via a web interface,
including the financial systems. In some cases, e.g. student
records, ODBC-like access is required/used in to/out from the
department systems to the campus systems. Databases include: finance
records, people, projects and publications (offered using ePrints).
4.3.4. Directory Services 4.3.3. Directory Services
The following are used: The following directory services are used:
o NIS o NIS (being phased out)
o LDAP o LDAP (OpenLDAP has IPv6 support)
o Active Directory o Active Directory
o RADIUS o RADIUS (Our current RADIUS package has IPv6 support)
4.3.5. DNS 4.3.4. DNS
The three DNS servers are running BIND9. A DNS secondary is held at The three DNS servers are running BIND9. A DNS secondary is held at
another UK university site. another UK university site. While we will make our three DNS servers
dual-stack, our DNS secondary would remain IPv4-only since it is out
4.3.6. PKI of our administrative control.
The department has at least 10 SSL certificates from Thawte,
including Web-signing certificates. No personal certificates are
supported by the department (though users may have their own).
4.3.7. NTP 4.3.5. NTP
The JANET NREN offers a stratum 0 NTP server. The department also The JANET NREN offers a stratum 1 NTP server. The department also
has a GPS-based NTP server built-in to its own RIPE NCC test traffic has a GPS-based NTP server built-in to its own RIPE NCC test traffic
server and an NTP device from Meinberg. server and an NTP device from a commercial provider. Both support
IPv6 operation and transport.
4.3.8. Multicast 4.3.6. Multicast
PIM-SM IPv4 multicast is facilitated via a dedicated Cisco 7206 PIM-SM IPv4 multicast is facilitated via a dedicated commercial
router, using a Rendezvous Point operated by our regional network. router, using a Rendezvous Point operated by our regional network.
This supports applications including the IPv4 AccessGrid conferencing This supports applications including the IPv4 AccessGrid conferencing
system. A number of bugs in the existing IPv4 routing equipment system. A number of bugs in the existing IPv4 routing equipment
prevent heavy use of IPv4 Multicast within the department network prevent heavy use of IPv4 Multicast within the department network
(another reason that an IPv6 Multicast solution is desirable). An (another reason that an IPv6 Multicast solution is desirable). An
IPv4 Multicast beacon is used for monitoring Multicast. IPv4 Multicast beacon is used for monitoring Multicast. Our IPv6
multicast deployment plans are discussed in Section 3.8 above.
4.3.9. Remote login
Remote login access is offered via ssh, with sftp for file transfer.
Remote use of insecure protocols such as telnet and ftp is denied by
the firewall.
4.3.10. File serving
The main file servers are SGI systems, hosting large (multi-TB)
standalone RAID arrays. The files are offered via NFS and Samba to
client systems. Our content (package) distribution server is hosted
on such a system.
4.3.11. Backups
Backups are run over SSH, which is IPv6-enabled. A site using a
proprietary remote backup solution may not yet have IPv6 capability.
4.4. Host and Device Platforms
4.4.1. Server platforms
These include:
o Windows 2003 server
o Windows 2000 server
o Windows NT
o Solaris 8
o Solaris 9
o Solaris 10
o RedHat Linux
o SGI Origin 300 (Irix 6.5.x)
4.4.2. Desktop/laptop platforms
These include:
o Windows 98, 2000, ME, XP
o Linux (various flavours)
o MacOS/X
o BSD (various flavours)
4.4.3. PDA platforms
These include:
o Windows CE/.NET, Pocket PC
o PalmOS
o Familiar Linux on iPaQ
o Zaurus (Linux)
4.5. User Tools
These are non-exhaustive but representative application/platform
lists
4.5.1. Hardware
o Networked printers
o Networked webcams
4.5.2. Mail Client
o Outlook (various versions)
o Eudora
o Mutt
o Pine
4.5.3. Web Browser
o MS Internet Explorer
o Mozilla
o Firefox
o Safari
o Opera
4.5.4. Conferencing systems
o AccessGrid
o A dedicated H.323 system
o MS Netmeeting
4.5.5. Other collaboration tools
o IRC
o Jabber
o MSN Messenger
o cvs
4.5.6. Usenet news client
o nn
o Mozilla
4.5.7. Host communications
o X11
o VNC
o PC Anywhere
4.6. Hard-coded address points 4.4. Hard-coded address points
Usage of IPv4 hard-coded addresses is interesting for at least two Usage of IPv4 hard-coded addresses is interesting for at least two
reasons. One is that it illustrates where IPv6 hard-coded addresses reasons. One is that it illustrates where IPv6 hard-coded addresses
may appear, and thus secondly it is useful to analyse which hard- may appear, and thus secondly it is useful to analyse which hard-
coded addresses may be barriers to smooth IPv6 renumbering. A coded addresses may be barriers to smooth IPv6 renumbering. A
procedure for renumbering has been described in Procedures for procedure for renumbering has been described in Procedures for
Renumbering an IPv6 Network without a Flag Day [12]. A non- Renumbering an IPv6 Network without a Flag Day [24]. A non-
exhaustive list of instances of such addresses includes: exhaustive list of instances of such addresses includes:
o Provider based prefix(es) o Provider based prefix(es)
o Names resolved to IP addresses in firewall at startup time o Names resolved to IP addresses in firewall at startup time
o IP addresses in remote firewalls allowing access to remote o IP addresses in remote firewalls allowing access to remote
services services
o IP-based authentication in remote systems allowing access to o IP-based authentication in remote systems allowing access to
online bibliographic resources online bibliographic resources
o IP address of both tunnel end points for IPv6 in IPv4 tunnel o IP address of both tunnel end points for IPv6 in IPv4 tunnel
o Hard-coded IP subnet configuration information o Hard-coded IP subnet configuration information
o IP addresses for static route targets o IP addresses for static route targets
o Blocked SMTP server IP list (spam sources) o Blocked SMTP server IP list (spam sources)
o Web .htaccess and remote access controls o Web .htaccess and remote access controls
o Apache .Listen. directive on given IP address o Apache .Listen. directive on given IP address
skipping to change at page 19, line 32 skipping to change at page 17, line 40
o Nocol monitoring tool o Nocol monitoring tool
o NIS/ypbind via the hosts file o NIS/ypbind via the hosts file
o Some interface configurations o Some interface configurations
o Unix portmap security masks o Unix portmap security masks
o NIS security masks o NIS security masks
The author is contributing to work in studying things to think about 5. IPv6 Enterprise Deployment Procedure
in IPv6 renumbering [22], where the above issues will be considered.
5. Analysis: Deployment Procedure
In this section we document (retrospectively) the procedure we went In this section we document (retrospectively) the procedure we went
through in deploying IPv6 within our campus site. through in deploying IPv6 within our campus site.
The work described in this document has also been fed into the IPv6 The work described in this document has also been fed into the IPv6
Enterprise Analysis [23]. The reader is referred in particular to Enterprise Analysis [38]. The reader is referred in particular to
Section 4 ("Wide-Scale Dual-Stack Deployment") and Section 7 Section 4 ("Wide-Scale Dual-Stack Deployment") and Section 7
("General issues and applicability for all Scenarios") which were ("General issues and applicability for all Scenarios") which were
directly contributed from the work here. directly contributed from the work here.
As described in the IPv6 Enterprise Analysis [23] document, the As described in the IPv6 Enterprise Analysis [38] document, the
scenario here is one of wide-scale dual-stack deployment. The plan scenario here is one of wide-scale dual-stack deployment. The plan
for deployment follows the general guidelines of Section 7 of that for deployment follows the general guidelines of Section 7 of that
document, though we have expanded that description here from document, though we have expanded that description here from
subsequent experience. subsequent experience.
Note that our analysis does not include issues relating to deployment Note that our analysis does not include issues relating to deployment
of new IPv6-specific technology, e.g. MIPv6. of new IPv6-specific technology, e.g. MIPv6 [16]. The focus of our
deployment has been deploying dual-stack pervasively on the wire,
with core network oriented services being IPv6 enabled.
5.1. Advanced Planning 5.1. Advanced Planning
A first phase for deployment includes the following actions. A first phase for deployment includes the following actions.
o Include IPv6 requirements in all future tenders. Consult to o Include IPv6 requirements in all future tenders. Consult to
understand IPv6 specification requirements for tenders; this may understand IPv6 specification requirements for tenders; this may
prove particularly valuable where new IPv6 specific technology is prove particularly valuable where new IPv6 specific technology is
desirable, e.g. Embedded-RP support for Multicast. desirable, e.g. Embedded-RP support for Multicast.
o Identify your IPv6 ISP. This will most likely be your IPv4 ISP o Identify your IPv6 ISP. This will most likely be your IPv4 ISP
also, but in some cases it may not be. also, but in some cases it may not be.
o Speak to your IPv6 ISP to acquire IPv6 address space (a /48 o Speak to your IPv6 ISP to acquire IPv6 address space (a /48
prefix) for your site; you will need this at some point, so may as prefix) for your site; you will need this at some point, so may as
well acquire the space sooner rather than later. This will well acquire the space sooner rather than later. This will
include delegation of IPv6 forward and reverse DNS for your site. include delegation of IPv6 forward and reverse DNS for your site.
Our campus address space is a /48 prefix allocated by JANET, under Our campus address space is a /48 prefix allocated by JANET.
their prefix of 2001:630::/32.
o Establish IPv6 training for operational staff, for administration o Establish IPv6 training for operational staff, for administration
of host and router platforms. of host and router platforms.
o Investigate how to deploy basic IPv6 network services: DNS, o Investigate how to deploy basic IPv6 network services: DNS,
routing, host configuration. routing, host configuration.
o Encourage operational staff to get some IPv6 familiarity by trying o Encourage operational staff to get some IPv6 familiarity by trying
IPv6 through services such as a public or ISP-supported IPv6 IPv6 through services such as a public or ISP-supported IPv6
tunnel broker [3]. tunnel broker [6].
o Review IPv6 security issues. IPv6 is enabled by default on many o Review IPv6 security issues. IPv6 is enabled by default on many
host platforms; this should be considered when enforcing security host platforms; this should be considered when enforcing security
policies on systems and networks. policies on systems and networks.
Following these action points should allow sites or networks to be Following these action points should allow sites or networks to be
ready for a trial or pilot IPv6 deployment, and to have confidence ready for a trial or pilot IPv6 deployment, and to have confidence
they understand and have control of their current - perhaps unwitting they understand and have control of their current - perhaps unwitting
- usage of IPv6 (from systems which have it enabled by default). - usage of IPv6 (from systems which have it enabled by default).
skipping to change at page 21, line 8 skipping to change at page 19, line 16
In this stage a site is validating IPv6 for deployment, and will thus In this stage a site is validating IPv6 for deployment, and will thus
take actions including the following: take actions including the following:
o Assign and deploy an IPv6-capable router and (we recommend) a o Assign and deploy an IPv6-capable router and (we recommend) a
firewall or filtering device. firewall or filtering device.
o Establish IPv6 connectivity to the IPv6 ISP. Sites might use a o Establish IPv6 connectivity to the IPv6 ISP. Sites might use a
tunnelled service, or check for any native IPv6 offering. In our tunnelled service, or check for any native IPv6 offering. In our
case, the connectivity is native IPv6 from JANET, via the regional case, the connectivity is native IPv6 from JANET, via the regional
MAN (using 6PE [19]) and the campus (using a VLAN to carry IPv6 MAN (using 6PE [35]) and the campus (using a VLAN to carry IPv6
natively). natively).
o Connect testbed host systems on the internal router interface, o Connect testbed host systems on the internal router interface,
using one subnet prefix (a /64) from the site's allocated IPv6 /48 using one subnet prefix (a /64) from the site's allocated IPv6 /48
prefix. At this stage your trial network may be standalone prefix. At this stage your trial network may be standalone
(disconnected from other internal networks) or, as we did, it may (disconnected from other internal networks) or, as we did, it may
be that you dual-stack your existing IPv4 DMZ(s) for the pilot be that you dual-stack your existing IPv4 DMZ(s) for the pilot
phase. phase.
o Enable IPv6 on the host systems, and test IPv6 functions on o Enable IPv6 on the host systems, and test IPv6 functions on
skipping to change at page 21, line 32 skipping to change at page 19, line 40
In parallel, other preparation can be undertaken for a production In parallel, other preparation can be undertaken for a production
deployment: deployment:
o Survey systems, applications and services for IPv6 capability, o Survey systems, applications and services for IPv6 capability,
including management, monitoring and access control devices and including management, monitoring and access control devices and
systems. The Enterprise Scenarios text as evaluated earlier in systems. The Enterprise Scenarios text as evaluated earlier in
this document is a good basis to undertake this task from. this document is a good basis to undertake this task from.
o Formulate an IPv6 address plan for your site/network. Our campus o Formulate an IPv6 address plan for your site/network. Our campus
has allocated the department network a /56 prefix that can grow has allocated the department network a /56 prefix that can grow
into a /52 prefix, i.e. the department can create in theory up to into a /52 prefix, i.e. the department can in theory create up to
256 IPv6 subnets initially. We discuss address planning issues in 256 IPv6 subnets initially. We discuss address planning issues in
a separate document on IPv6 addressing considerations [18]. a separate document on IPv6 addressing considerations [36].
o Discuss and document IPv6-related policies (e.g. use of Privacy o Discuss and document IPv6-related policies (e.g. use of Privacy
Addresses, and of stateless or stateful address assignment). Addresses, and of stateless or stateful address assignment).
Once the site is satisfied in the testbed deployment, then a Once the site is satisfied in the testbed deployment, then a
production deployment can be considered, enabling IPv6 for production deployment can be considered, enabling IPv6 for
appropriate links and services. appropriate links and services.
5.3. Production Deployment 5.3. Production Deployment
A production deployment includes the following action points: A production deployment includes the following action points:
o Plan which parts of the network will be IPv6-enabled, and which o Plan which parts of the network will be IPv6-enabled first, and
existing subnets will be IPv6-enabled (made dual-stack). This may which existing subnets will be IPv6-enabled (made dual-stack).
be certain server subnets, a DMZ, or a Wireless LAN network, for This may be certain server subnets, a DMZ, or a Wireless LAN
example. network, for example.
o Determine how your production IPv6 connectivity will be handled; o Determine how your production IPv6 connectivity will be handled;
it can (ideally) be via a single dual-stack entry point, or it can (ideally) be via a single dual-stack entry point, or
through separate IPv4 and IPv6 links. through separate IPv4 and IPv6 links.
o Enable IPv6, and IPv6 routing, such that IPv6 is on the wire, o Enable IPv6, and IPv6 routing, such that IPv6 is on the wire,
prior to host system activation. Ensure filtering and firewall prior to host system activation. Ensure filtering and firewall
policies are implemented as required. policies are implemented as required.
o Add IPv6 address configuration to your DNS systems, and configure o Add IPv6 address configuration to your DNS systems, and configure
them to respond over IPv4 or IPv6 transport. them to respond over IPv4 or IPv6 transport. Do not advertise
AAAA records for a node until it is IPv6-reachable. Be aware that
multiple services may run on a node, all of which may need to be
IPv6-enabled before a AAAA record for the node is published.
o Deploy IPv6 support in appropriate management and monitoring o Deploy IPv6 support in appropriate management and monitoring
tools. tools.
o Enable IPv6 in selected production services and applications (e.g. o Enable IPv6 in selected production services and applications (e.g.
Apache or IIS for web servers). In our case, we focused initially Apache or IIS for web servers). In our case, we focused initially
on DNS (bind), mail/MX (sendmail) and web services (Apache) in on DNS (bind), mail/MX (sendmail) and web services (Apache) in
dual-stack mode. dual-stack mode.
o Include IPv6 transport in all ongoing security audit/penetration o Include IPv6 transport in all ongoing security audit/penetration
skipping to change at page 22, line 42 skipping to change at page 21, line 5
rather than deploying translation-based tools. rather than deploying translation-based tools.
o Supporting remote users. These may connect via an IPv4 VPN and o Supporting remote users. These may connect via an IPv4 VPN and
then use an IPv6 connection over that VPN, or use the remote IPv6 then use an IPv6 connection over that VPN, or use the remote IPv6
services of your ISP (e.g. our ISP, JANET, runs a tunnel broker services of your ISP (e.g. our ISP, JANET, runs a tunnel broker
and a 6to4 relay). and a 6to4 relay).
The depth of the IPv6 deployment may vary from site to site. By The depth of the IPv6 deployment may vary from site to site. By
enabling key services you make your site ready for a fuller enabling key services you make your site ready for a fuller
deployment, and gain confidence and experience in the technology, deployment, and gain confidence and experience in the technology,
which is good for your support staff, your students and staff and which is good for your support staff, your students, staff and
researchers. researchers.
6. Analysis: Dual-Stack Deployment - Transition toolbox 6. Analysis: Dual-Stack Deployment - Transition toolbox
Within our network we initially deployed IPv6 in parallel to IPv4, Within our network we initially deployed IPv6 such that it was routed
using a VLAN-based method as cited below. This allowed us to pilot in parallel to IPv4, but with data running on the same end-host
IPv6 without risking adverse impact on our existing IPv4 platforms. links, using a VLAN-based method as cited below. This allowed us to
This method was used for over two years. Towards the end of its use, pilot IPv6 without risking adverse impact on our existing IPv4
the BSD platforms used to facilitate this were showing signs of platforms. This method was used for over two years. Towards the end
strain under the load, in terms of pure unicast and multicast of its use, the BSD platforms used to facilitate this were showing
forwarding strain under heavier traffic bursts. We have since signs of strain under the load, in terms of pure unicast and
deployed a unified IPv4 and IPv6 routing platform from a single multicast forwarding requirements under heavier traffic bursts. We
vendor, which met all our IPv4 and IPv6 procurement requirements for have since deployed a unified IPv4 and IPv6 commercial routing
IPv4 and IPv6 unicast and multicast functions, including but not platform from a single vendor, which met all our IPv4 and IPv6
limited to: procurement requirements for IPv4 and IPv6 unicast and multicast
functions, including but not limited to:
o IPv6 unicast routing protocols; o IPv6 unicast routing protocols;
o IPv6 multicast routing protocols (PIM-SM, SSM); o IPv6 multicast routing protocols (PIM-SM including SSM);
o IPv6 multicast Embedded-RP support; o IPv6 multicast Embedded-RP support;
o IPv6 multicast MLD(v1 and v2) snooping. o IPv6 multicast MLD(v1 and v2) snooping (see RFC4541 [31]).
We have used the following mechanisms in our department's transition We have used the following mechanisms in our department's transition
process: process:
o VLANs [17] to distribute IPv6 connectivity over the non-dual-stack o VLANs [32] in an initial phase to distribute IPv6 connectivity
capable network infrastructure. This VLAN solution was an interim over the non-dual-stack capable network infrastructure. This VLAN
step until full dual protocol capable equipment was deployed solution was an interim step until full dual protocol capable
during 2005; equipment was deployed during 2005;
o A Tunnel broker [3] for remote access, provided by our IPv6 ISP o A Tunnel broker [6] for remote access, provided by our IPv6 ISP
(JANET). We initially deployed our own tunnel broker, but now (JANET). We initially deployed our own tunnel broker, but now
refer our home and roaming users to the JANET solution; refer our home and roaming users to the JANET solution. This is
only used for remote access to our network, not within our
network;
o A 6to4 [4] relay for remote access, provided by our IPv6 ISP. o A 6to4 [7] relay for remote access, provided by our IPv6 ISP.
Again, we used to run our own relay, but the relay operated by our Again, we used to run our own relay, but the relay operated by our
IPv6 ISP is perfectly adequate at this time for communicating with IPv6 ISP is perfectly adequate at this time for communicating with
6to4 sites. We do not believe 6to4 is an acceptable solution as a 6to4 sites. We do not believe 6to4 is an acceptable solution as a
campus connectivity method (because we do not then use our own campus connectivity method (because we do not then use our own
IPv6 address space as allocated by JANET, and 6to4 itself is prone IPv6 address space as allocated by JANET, and 6to4 itself is prone
to failure and abuse). to failure and abuse [19]).
We do NOT currently see a requirement for: We do NOT currently see a requirement for:
o NAT-PT [2], because we are dual-stack with no IPv6-only networks o NAT-PT [4], because we are dual-stack with no IPv6-only networks
(yet), and as we introduce such networks, or IPv6-only nodes in (yet), and as we introduce such networks, or IPv6-only nodes in
the dual-stack networks, we expect to use application layer the dual-stack networks, we expect to use application layer
gateways and proxies for legacy IPv4 access. If and when we do gateways and proxies for legacy IPv4 access. Where dual-stack
deploy an IPv6-only link, and ALGs are not sufficient, we would nodes may in future be used on IPv6-only links, the Dual Stack
look at DSTM as a solution in preference NAT-PT; Transition Mechanism (DSTM) may be of value, but preference would
be given to use IPv6 transport where possible;
o ISATAP [13], because we prefer to use a structured internal IPv6 o ISATAP [26], because we prefer to use a structured internal IPv6
deployment, and are doing so in a pervasive fashion (i.e. not as a deployment, and are doing so in a pervasive fashion (i.e. not as a
sparse deployment). ISATAP may be useful for sparse deployment of sparse deployment). ISATAP may be useful for sparse deployment of
IPv6 in sites who are happy to IPv6 pilot in a less structured IPv6 in sites who are happy to IPv6 pilot in a less structured
fashion; fashion. We do not wish to see arbitrary automatic tunnels being
used between links on our network;
o We considered deploying a Teredo [15] relay to support home users o Teredo [29] - we considered deploying servers/relays to support
behind NATs, but chose not to do so since the tunnel broker home users behind NATs, but chose not to do so since our ISP's
service supports NAT traversal, and we feel it offers better tunnel broker service supports NAT traversal, and we feel it
management and monitoring facilities. This decision may be offers better management and monitoring facilities. This decision
reviewed should Windows Vista ship with Teredo enabled by default. may be reviewed if we see a rise in demand for Teredo service
At the time of writing the status of Teredo in Vista is not support.
finalised (Vista is not released).
7. Analysis: Considerations beyond the Scenarios Document 7. Analysis: Considerations beyond the Scenarios Document
Here we mention issues or scenario components that were not Here we mention issues or scenario components that were not
explicitly listed in the IPv6 Enterprise Network Scenarios document. explicitly listed in the IPv6 Enterprise Network Scenarios document.
Due to the scope, that document could not embrace all details. We Due to the scope, that document could not embrace all details. We
mention here components that other sites may also wish to consider: mention here components that other sites may also wish to consider:
o Support for WLAN and other access control. One solution is to use o Support for WLAN and other access control. Most sites tend to use
802.1x which is IP-agnostic as a Layer 2 port control mechanism. a web-redirection portal to authenticate users, but these
invariably do not detect or support use of IPv6. One solution is
to use 802.1x which is IP-agnostic as a Layer 2 port control
mechanism.
o Consideration for hard-coded addresses. o Consideration for hard-coded addresses.
The brevity of this list shows that the IPv6 Enterprise Network
Scenarios text includes very good coverage of the issues and
considerations faced by our enterprise site.
8. Summary 8. Summary
In this document we have analysed the specific campus transition In this document we have analysed the specific campus transition
scenario for the author's site, and reported the analysis for the scenario for the author's site, and reported the analysis for the
benefit of others who may be in a similar scenario, or for whom parts benefit of others who may be in a similar scenario, or for whom parts
of the scenario are relevant. of the scenario may be relevant.
In our case transition does not mean from IPv4 only to IPv6 only, In our case transition does not mean from IPv4 only to IPv6 only,
rather from IPv4 only to a dual-stack environment that could support rather from IPv4 only to a dual-stack environment that could support
IPv6 only nodes at a later date. We would probably best describe the IPv6 only nodes at a later date. We would probably best describe the
process as dual stack integration. process as dual stack integration.
We have described how a phased approach to transition can be adopted We have described how a phased approach to transition can be adopted
at a campus site (or part thereof), from a planning stage through a at a campus site (or part thereof), from a planning stage through a
pilot to a fuller deployment. During our transition we initially ran pilot to a fuller deployment. During our transition we initially ran
a parallel IPv6 routing infrastructure, then in 2005 unified the a parallel IPv6 routing infrastructure, then in 2005 unified the
routing to a single platform, for unicast and multicast IPv6. We routing to a single platform, for unicast and multicast IPv6. We
enabled key services for dual-stack operation from the outset (DNS, enabled key services for dual-stack operation from the outset (DNS,
web and mail/MX) and have enabled other services as and when they web and mail/MX) and have enabled other services as and when they
have become available. The VLAN-based interim step was useful for have become available. The VLAN-based interim step was useful for
two years until a dual-protocol solution could be procured. two years until a dual-protocol routing solution could be procured.
We do not discuss detailed availability of IPv6 capability in the We do not discuss detailed availability of IPv6 capability in the
services, platforms and user tools described in Section 4 above in services described in Section 4 above in this text, and we leave
this text. An ongoing gap analysis is being undertaken in a separate application support as an issue out of scope (though we observe that
text. For the purposes of our network-oriented transition, we are open source support for IPv6 is in general very good). For the
happy that the path taken and current solution is stable and purposes of our network-oriented transition, we are happy that the
complete. path taken and current solution is stable and complete.
The deployment has now been in full dual-stack operation for over a The deployment has now been in full dual-stack operation for over two
year, with key services enabled (including public-facing DNS, SMTP, years, with key services enabled (including public-facing DNS, SMTP,
web) without adverse effects on the IPv4 service. The author web) without any significant adverse effects on the IPv4 service.
welcomes discussion with other sites that are undergoing or have The author welcomes discussion with other sites that are undergoing
undergone a similar transition or integration process. or have undergone a similar transition or integration process.
9. Acknowledgements 9. Acknowledgements
Discussions with fellow participants on the 6NET and Euro6IX projects Discussions with fellow participants on the 6NET and Euro6IX projects
have been valuable. have been valuable. Input from the IETF IPv6 Operations WG list have
also been welcomed.
10. IANA Considerations 10. IANA Considerations
The document contains no IANA considerations. The document contains no IANA considerations.
11. Security Considerations 11. Security Considerations
There are no specific new considerations from this scenario There are no specific new considerations from this scenario
description and analysis. description and analysis.
12. Informative References 12. Informative References
[1] Thomson, S. and T. Narten, "IPv6 Stateless Address [1] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[2] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[2] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - [4] Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
Protocol Translation (NAT-PT)", RFC 2766, February 2000. Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[3] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [5] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[6] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, January 2001.
[4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via [7] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001. IPv4 Clouds", RFC 3056, February 2001.
[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. [8] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA
Guidelines for IPv4 Multicast Address Assignments", BCP 51,
RFC 3171, August 2001.
[9] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[10] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[11] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[6] Droms, R., "Stateless Dynamic Host Configuration Protocol [12] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[13] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced
Sockets Application Program Interface (API) for IPv6",
RFC 3542, May 2003.
[14] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol
(MSDP)", RFC 3618, October 2003.
[15] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[7] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, [16] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[17] Huitema, C., Austein, R., Satapati, S., and R. van der Pol,
"Evaluation of IPv6 Transition Mechanisms for Unmanaged "Evaluation of IPv6 Transition Mechanisms for Unmanaged
Networks", RFC 3904, September 2004. Networks", RFC 3904, September 2004.
[8] Savola, P. and B. Haberman, "Embedding the Rendezvous Point [18] Savola, P. and B. Haberman, "Embedding the Rendezvous Point
(RP) Address in an IPv6 Multicast Address", RFC 3956, (RP) Address in an IPv6 Multicast Address", RFC 3956,
November 2004. November 2004.
[9] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, [19] Savola, P. and C. Patel, "Security Considerations for 6to4",
RFC 3964, December 2004.
[20] Nakamura, M. and J. Hagino, "SMTP Operational Experience in
Mixed IPv4/v6 Environments", RFC 3974, January 2005.
[21] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola,
"Scenarios and Analysis for Introducing IPv6 into ISP "Scenarios and Analysis for Introducing IPv6 into ISP
Networks", RFC 4029, March 2005. Networks", RFC 4029, March 2005.
[10] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, [22] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro,
"Application Aspects of IPv6 Transition", RFC 4038, March 2005. "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[11] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, [23] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
June 2005. June 2005.
[12] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering [24] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering
an IPv6 Network without a Flag Day", RFC 4192, September 2005. an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[13] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- [25] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[26] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-
Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214,
October 2005. October 2005.
[14] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation [27] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation
Partnership Project (3GPP) Networks", RFC 4215, October 2005. Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[15] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network [28] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[29] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network
Address Translations (NATs)", RFC 4380, February 2006. Address Translations (NATs)", RFC 4380, February 2006.
[16] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host [30] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host
Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack
Issues", RFC 4477, May 2006. Issues", RFC 4477, May 2006.
[17] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in [31] Christensen, M., Kimball, K., and F. Solensky, "Considerations
for Internet Group Management Protocol (IGMP) and Multicast
Listener Discovery (MLD) Snooping Switches", RFC 4541,
May 2006.
[32] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in
Enterprise Networks", RFC 4554, June 2006. Enterprise Networks", RFC 4554, June 2006.
[18] Velde, G., "IPv6 Unicast Address Assignment Considerations", [33] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
draft-ietf-v6ops-addcon-01 (work in progress), July 2006. "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[19] Clercq, J., "Connecting IPv6 Islands over IPv4 MPLS using IPv6 [34] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR):
Provider Edge Routers (6PE)", draft-ooms-v6ops-bgp-tunnel-06 The Internet Address Assignment and Aggregation Plan", BCP 122,
(work in progress), January 2006. RFC 4632, August 2006.
[20] Davies, E., "IPv6 Transition/Co-existence Security [35] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
Considerations", draft-ietf-v6ops-security-overview-05 (work in "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider
progress), September 2006. Edge Routers (6PE)", RFC 4798, February 2007.
[21] Venaas, S., "An IPv4 - IPv6 multicast gateway", [36] Velde, G., "IPv6 Unicast Address Assignment Considerations",
draft-venaas-mboned-v4v6mcastgw-00 (work in progress), draft-ietf-v6ops-addcon-03 (work in progress), March 2007.
February 2003.
[22] Chown, T., "Things to think about when Renumbering an IPv6 [37] Davies, E., "IPv6 Transition/Co-existence Security
network", draft-chown-v6ops-renumber-thinkabout-05 (work in Considerations", draft-ietf-v6ops-security-overview-06 (work in
progress), September 2006. progress), October 2006.
[23] Bound, J., "IPv6 Enterprise Network Analysis", [38] Bound, J., "IPv6 Enterprise Network Analysis - IP Layer 3
draft-ietf-v6ops-ent-analysis-06 (work in progress), June 2006. Focus", draft-ietf-v6ops-ent-analysis-07 (work in progress),
December 2006.
Author's Address Author's Address
Tim Chown Tim Chown
University of Southampton University of Southampton
School of Electronics and Computer Science School of Electronics and Computer Science
Southampton, Hampshire SO17 1BJ Southampton, Hampshire SO17 1BJ
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 29, line 29 skipping to change at page 28, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 149 change blocks. 
531 lines changed or deleted 489 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/