IPv6 Operations T. Chown Internet-Draft University of Southampton Expires: September 7, 2006 March 6, 2006 IPv6 Campus Transition Scenario Description and Analysis draft-chown-v6ops-campus-transition-02 Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In this document we consider and analyse the specific scenario of IPv6 transition and deployment in a large department of a university campus network. The department is large enough to operate its own instances of all the conventional university services including (for example) web, DNS, email, filestore, interactive logins, and remote and wireless access. The scenario is a dual-stack one, i.e. transition to IPv6 means deploying IPv6 in the first instance alongside IPv4. This analysis will both identify the available (and still missing) components for IPv6 transition, and also test the Chown Expires September 7, 2006 [Page 1] Internet-Draft IPv6 Campus Transition March 2006 applicability of the recently completed IPv6 Enterprise Network Scenarios document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Site Philosphy . . . . . . . . . . . . . . . . . . . . . . 5 2. Discussion of Scenarios Network Infrastructure Components . . 5 2.1. Component 1: Enterprise Provider Requirements . . . . . . 5 2.2. Component 2: Enterprise Application Requirements . . . . . 6 2.3. Component 3: Enterprise IT Department Requirements . . . . 7 2.4. Component 4: Enterprise Network Management System . . . . 8 2.5. Component 5: Enterprise Network Interoperation and Coexistence . . . . . . . . . . . . . . . . . . . . . . . 9 3. Discussion of Network Infrastructure Component Requirements . 9 3.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Configuration of Hosts . . . . . . . . . . . . . . . . . . 10 3.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Applications . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Network Management . . . . . . . . . . . . . . . . . . . . 10 3.7. Address Planning . . . . . . . . . . . . . . . . . . . . . 10 3.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 11 4. Specific Scenario Component Review . . . . . . . . . . . . . . 11 4.1. Network Components . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Physical connectivity (Layer 2) . . . . . . . . . . . 11 4.1.2. Routing and Logical subnets (Layer 3) . . . . . . . . 11 4.1.3. Firewall . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.4. Intrusion Detection System . . . . . . . . . . . . . . 12 4.1.5. Management . . . . . . . . . . . . . . . . . . . . . . 12 4.1.6. Monitoring . . . . . . . . . . . . . . . . . . . . . . 12 4.1.7. Remote access . . . . . . . . . . . . . . . . . . . . 12 4.1.8. IPv6 External Access . . . . . . . . . . . . . . . . . 12 4.2. Address Allocation Components . . . . . . . . . . . . . . 12 4.2.1. IPv6 network prefix allocation . . . . . . . . . . . . 12 4.2.2. IPv6 Address allocation . . . . . . . . . . . . . . . 13 4.3. Services . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.1. Email . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.2. Web Hosting . . . . . . . . . . . . . . . . . . . . . 13 4.3.3. Databases . . . . . . . . . . . . . . . . . . . . . . 14 4.3.4. Directory Services . . . . . . . . . . . . . . . . . . 14 4.3.5. DNS . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.6. PKI . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.7. NTP . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.8. Multicast . . . . . . . . . . . . . . . . . . . . . . 14 4.3.9. Remote login . . . . . . . . . . . . . . . . . . . . . 15 Chown Expires September 7, 2006 [Page 2] Internet-Draft IPv6 Campus Transition March 2006 4.3.10. File serving . . . . . . . . . . . . . . . . . . . . . 15 4.3.11. Backups . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Host and Device Platforms . . . . . . . . . . . . . . . . 15 4.4.1. Server platforms . . . . . . . . . . . . . . . . . . . 15 4.4.2. Desktop/laptop platforms . . . . . . . . . . . . . . . 15 4.4.3. PDA platforms . . . . . . . . . . . . . . . . . . . . 16 4.5. User Tools . . . . . . . . . . . . . . . . . . . . . . . . 16 4.5.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . 16 4.5.2. Mail Client . . . . . . . . . . . . . . . . . . . . . 16 4.5.3. Web Browser . . . . . . . . . . . . . . . . . . . . . 16 4.5.4. Conferencing systems . . . . . . . . . . . . . . . . . 17 4.5.5. Other collaboration tools . . . . . . . . . . . . . . 17 4.5.6. Usenet news client . . . . . . . . . . . . . . . . . . 17 4.5.7. Host communications . . . . . . . . . . . . . . . . . 17 4.6. Hard-coded address points . . . . . . . . . . . . . . . . 17 5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Dual-Stack Deployment: Procedure . . . . . . . . . . . . . 19 5.2. Dual-Stack Deployment: Transition toolbox . . . . . . . . 20 5.3. Missing components . . . . . . . . . . . . . . . . . . . . 20 5.3.1. Standards (IETF)-specific . . . . . . . . . . . . . . 20 5.3.2. Vendor or platform-specific . . . . . . . . . . . . . 21 5.3.3. Application-specific . . . . . . . . . . . . . . . . . 21 5.3.4. Other (policy, political,...) . . . . . . . . . . . . 21 5.4. Considerations beyond the Scenarios Document . . . . . . . 21 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Informative References . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Chown Expires September 7, 2006 [Page 3] Internet-Draft IPv6 Campus Transition March 2006 1. Introduction The scope of the enterprise network transition scenarios is very large, much more so than that of the other three IPv6 transition areas under study within the IETF. The IPv6 Enterprise Network Scenarios [9] have been defined. In this document we present a specific case study area for IPv6 transition, namely a large department (1,500 staff and students, over 1,000 hosts) in an academic campus network. The purpose of this document in its current form is to both define and analyse the IPv6 transition of such a network, but also to test the applicability of the IPv6 Enterprise Network Scenarios document to a specific example. This version of this campus transition draft is an interim release to reinitiate discussion of the campus issues. The work on IPv6 Enterprise Analysis [19] is now at an advanced stage, and this campus transition experience has been fed into that analysis. Our campus study falls under "Scenario 1" of the IPv6 Enterprise Network Scenarios [9] document, i.e. the campus network is an existing IPv4 network, where IPv6 is to be deployed in conjunction with the IPv4 network. "Scenario 1" has the assumption that the IPv4 network infrastructure used has an equivalent capability in IPv6. This document will analyse that assumption. The Scenario also has requirements, i.e. that the existing IPv4 network infrastructure is not disrupted, and that IPv6 should be equivalent or better than the network infrastructure in IPv4. The Scenario also notes that it may also not be feasible to deploy IPv6 on all parts of the network immediately. These assumptions and requirements will be discussed later in this text. It should also be noted why Scenarios 2 and 3 did not apply to this campus transition scenario. Scenario 2 talks of specific applications, but in the campus case we wish to deploy IPv6 pervasively, in wired and wireless networks, as an enabler for education and research, to encourage new application development. Scenario 3 focuses on using IPv6 as the basis for most network communication, but in the campus we already have a significant IPv4 deployment that will be utilised for the foreseeable future (Scenario 3 would perhaps be more appropriate for a greenfield deployment). This document is very much a work in progress, and thus this first instance of this document is not intended to be complete or comprehensive. Some sections are empty at this stage. We make no claims that this campus scenario is typical, but believe the lessons Chown Expires September 7, 2006 [Page 4] Internet-Draft IPv6 Campus Transition March 2006 leanrt and analysis undertaken may be of wider interest. Feedback is sought on scope and the required level of detail. 1.1. Site Philosphy The site which is the subject of this study is an IPv4 network with up to 20 subnets, using a core network infrastructure that combines switch-router functionality in centralised devices, with switches at the network edge. The main switching equipment is all VLAN capable. There are around 1,000 networked nodes, and 1,500 users. The site wishes to deploy IPv6 dual-stack. Currently, the core network infrastructure does not support IPv6, and no upgrade is possible. Thus the infrastructure cannot support IPv6 until the next procurement cycle. Given the site wishes to deploy IPv6 pervasively as soon as possible, and interim deployment solution is required. The goal is to IPv6 enable the network (on the wire) and services (DNS, SMTP, etc) such that the whole operation is dual-stack. This will allow in due course IPv6-only devices to be deployed within the fully IPv6-capable environment. Some network links may become IPv6- only in the future. 2. Discussion of Scenarios Network Infrastructure Components In this section, we look at the issues raised by following the Scenarios Network Infrastructure Components of the IPv6 Enterprise Network Scenarios [9] document, section 3.2. 2.1. Component 1: Enterprise Provider Requirements The answers to the questions posed in this section of the IPv6 Enterprise Network Scenarios document are as follows: o There is external access to/from the campus network, regional MAN and National Research Network beyond. o There are needs for access by remote staff, student and researchers. o It is a single site, with four buildings. o There are no leased lines or wide-area VPNs between remote buildings. 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). Chown Expires September 7, 2006 [Page 5] Internet-Draft IPv6 Campus Transition March 2006 o The IPv4 and IPv6 provider is the National Research and Education Network (JANET in the UK). JANET provides a /48 prefix for the university. The university offers a /52 prefix for the department. o The university and department make their own prefix allocations for subnets. o There is no multihoming, and thus no multihomed clients. o The provider offers an IPv6 Tunnel Broker [3] service and a 6to4 [4] relay, though the campus has native IPv6 connectivity via its regional MAN. o There is no exteral IPv6 routing protocol needed due to the use of static route configuration. o There is no external data centre. o IPv6 runs over the same access links to campus (the JANET backbone uses true dual stack, the regional MAN uses 6PE [15]. On campus, the IPv4 traffic to the department is received through a Nokia IP740 firewall, the IPv6 traffic is received through a BSD firewall. Thus the access links into the department for IPv4 and IPv6 are different, though the goal is to make them the same. 2.2. Component 2: Enterprise Application Requirements Answers to the next IPv6 Enterprise Network Scenarios section are as follows: o The application inventory is discussed in the specific component review in the next section. o We expect the first applications to be moved will be the support services, including DNS. The first applications should be the common IPv4 applications, e.g. web, remote login and email, such that IPv6 offers as least an equivalent service to IPv4 for the important applications. o The academic environment has a good mix of open source and commercial software, predominantly either Microsoft or Linux, but with a growing number of Mac OS/X users. Specific platforms are reviewed in the component review in the next main section. Most open source applications have been upgraded to allow IPv6 operation; others can be upgraded given time. Chown Expires September 7, 2006 [Page 6] Internet-Draft IPv6 Campus Transition March 2006 o The general goal is for applications to support both IPv4 or IPv6 operation, i.e. to be IP agnostic. o There is no use of NAT in the department's network. Home users, or users access into the network remotely from certain locations, may experience NAT at their client side. o NAT issues are relevant from the end-to-end perspective, for establishment of end-to-end security where desired, and in relation to IPv6 transition (remote access) mathods that may be run through NATs. o There is a mix of internal and external applications. Where limitations occur, it is mainly by policy not technology, e.g. as implemented in firewall restrictions. 2.3. Component 3: Enterprise IT Department Requirements Here we list responses to the next IPv6 Enterprise Network Scenarios section on IT Department Requirements: o Ownership and support is all in-house. o Remote VPNs are supported. o No inter-site networking is required. o No network mobility support is needed at this point, though we expect to use Mobile IPv6 between the department network and a local community wireless network. o The IPv6 address plan for the department requires a /52 prefix. o There is no detailed asset database, though one is being built. o There are no geographically separate sites. o The internal IPv4 address assignment mechanism is DHCP for clients, with manual configuration for servers. We thus expect to use DHCPv6 for at least some IPv6 clients. o Internal IPv4 routing is static or uses RIP. We thus expect to use RIPng internally. o We expect our IPv6 network management policy to be very similar to that for IPv4. Chown Expires September 7, 2006 [Page 7] Internet-Draft IPv6 Campus Transition March 2006 o There is no QoS provision at present, largely due to the ample campus bandwidth (1Gbit/s uplink). o Security is applied through many technologies implementing our policies, e.g. firewall, email scanning, wireless LAN access controls. We expect similar policies for IPv6, but need to analyse differences. o Training will be done in-house. o The impacted software components are discussed in the next main section. Not all functions are upgradeable to IPv6; those that are not are discussed in the analysis section. Some are, e.g. use of OpenLDAP in place of MS Active Directory. o The impacted hardware components are discussed in the next main section. Not all hardware is upgradeable, e.g. network printers. There are no load balancing systems in use. There are wireless LAN hosts in the network that are mobile, but currently the wireless network is a flat IPv4 subnet. There may be nodes moving to external wireless networks (the local community wireless network. 2.4. Component 4: Enterprise Network Management System The responses to the next IPv6 Enterprise Network Scenarios section are as follows: o No performance management is required. 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. the nocol availability monitring tools, and SNMP-based management. o The configuration management may include use of tools to configure services including DNS and email. o No policy management and enforcement tools are required. o No detailed security management is required, though we expect to manage the implementations including firewalls and intrusion detection. o We may need to manage the deployed transition tools and mechanisms. o We need to analyse the considerations IPv6 creates for network management, e.g. use (or not) of RFC3041 privacy addresses. The Chown Expires September 7, 2006 [Page 8] Internet-Draft IPv6 Campus Transition March 2006 need for user privacy is recognised, but the need for simplified managed is also present. 2.5. Component 5: Enterprise Network Interoperation and Coexistence Answers to the final IPv6 Enterprise Network Scenarios section on Coexistence are as follows: o The platforms that are required to be IPv6 capable are listed in the next main section. o There is only one network ingress and egress point to the site that needs to be IPv6 capable; this is a Gigabit Ethernet interface. o The required transition mechanisms are discussed in the analysis section. We expect to mainly use the VLAN [13] mechanism for internal IPv6 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 clients, with a phased introduction of service capability, as discussed below in the analysis section. o The preferred mechanism for interoperation with legacy nodes is to use dual-stack and thus IPv4 to communicate to IPv4 nodes and IPv6 to communicate to IPv6 nodes. We have not identified any in- house, non-upgradeable legacy applications. 3. Discussion of Network Infrastructure Component Requirements In this section, we discuss the network infrastructure component requirements raised in the IPv6 Enterprise Network Scenarios [9] document, in section 4. 3.1. DNS BIND9 is used for our three internal name servers. The servers will be made dual stack, to be available for IPv6 transport for local dual-stack or IPv6-only nodes. The three servers will each be listed with AAAA records, and AAAA glue added. 3.2. Routing Internal routing is either statically configured or uses RIP. We thus expect to use RIPng for internal IPv6 routing. The external Chown Expires September 7, 2006 [Page 9] Internet-Draft IPv6 Campus Transition March 2006 routing is statically configured for IPv4, and thus is likely to be statically configured for IPv6. 3.3. Configuration of Hosts IPv4 clients use DHCP for address and other configuration options. We expect to use Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5] for IPv6 clients. This will require analysis of the IPv4 and IPv6 Dual-Stack Issues for DHCPv6 [14]. We expect some clients, especially in wireless LANs, to use IPv6 Stateless Autoconfiguration [1], and these nodes will need support for Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 [6] for other configuration options, including the IPv6 address of a local DNS resolver. Although IPv6 offers Stateless Autoconfiguration, it is expected that the managed environment will continue, driven from the asset database, for some time. Thus 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 We need to identify new IPv6 related security considerations, and those associated with transition mechanisms [16]. Site policies may need to be updated as a result. 3.5. Applications The Application Aspects of IPv6 Transition [8] document describes best porting practice for applications. There should also be consideration for any required application proxies. 3.6. Network Management The network management and monitoring systems will need to embrace IPv6, and any transition mechanisms used to deploy IPv6. Monitoring includes usage tracking (e.g. via MRTG) and availability monitoring (e.g. via nocol). 3.7. Address Planning The department receives 12 Class C prefixes for IPv4 use, and uses only globally routable addresses internally. The IPv4 address space for the campus was obtained prior to CIDR, but the IPv6 address space is allocated from the UK National Research Network (JANET) address space under 2001:0630::/32. The university receives a /48 prefix, Chown Expires September 7, 2006 [Page 10] Internet-Draft IPv6 Campus Transition March 2006 which is 2001:0630:d0::/48. The department has a /52 allocation within this block of 2001:0630:d0:0:/52. 3.8. Multicast IPv4 multicast is used for a number of applications, including the AccessGrid. Connectivity is provided via the local campus and regional network. We expect to use both IPv6 ASM (i.e. PIM-SM), and may seek to make use of the Embedding the Address of RP in IPv6 Multicast Address [7] technique. For briding between IPv4 and IPv6 multicast, we believe an IPv4 - IPv6 multicast gateway [17] may prove valuable. Finally, we expect to make use of source specific multicast (SSM) more heavily in IPv6, bringing IPv6 and SSM together in one deployment cycle. 3.9. Multihoming The site is not multihomed. 4. Specific Scenario Component Review Here we describe specific technology in use now in the department. Later in this section we discuss any items not included in the above section, i.e. those not explicitly mentioned in the IPv6 Enterprise Network Scenarios document. In the next main section we analyse these for missing technologies, as a form of gap analysis. 4.1. Network Components 4.1.1. Physical connectivity (Layer 2) o Switched Ethernet o Gigabit Ethernet o Wireless networking (802.11b) 4.1.2. Routing and Logical subnets (Layer 3) The hybrid Layer 2/3 routing equipment has approximately 20 internal IPv4 subnets (in effect, routed VLANs). There is no specific internal routing protocol used. There is a static route via the site firewall to the main upstream provider (academic) running at 1Gbit/s. 4.1.3. Firewall The firewall is currently CheckPoint Firewall-1 running on a Sun Chown Expires September 7, 2006 [Page 11] Internet-Draft IPv6 Campus Transition March 2006 Solaris platform, just migrating to a Nokia IP740 hardware platform. There is one internal facing interface, one external facing interface, and two .DMZ. interfaces, one for wired hosts and one for the Wireless LAN provision. 4.1.4. Intrusion Detection System Snort is used locally for IPv4 IDS. There is some IPv6 functionality in Snort. The precise requirements of an IPv6 IDS need to be understood. 4.1.5. Management Some network management is performend by SNMP; there is no specific package for this. There is a greater emphasis on monitoring than explictly in management. 4.1.6. Monitoring A number of tools are used, to monitor network usage as well as systems availability, e.g. nocol, nagios and MRTG. The IBM AWM tool is used for network testing, along with iperf, rude and crude. 4.1.7. Remote access o Livingston Portmaster 56K/ISDN dialup o RADIUS server o (Microsoft) VPN server 4.1.8. IPv6 External Access o IPv6 connectivity comes via 6PE from our regional network. 4.2. Address Allocation Components The department receives its IPv4 and IPv6 address allocations from the University. For IPv4, the University has a Class B allocation which is not aggregated under the JANET NREN. For IPv6, the University receives its allocation from JANET. 4.2.1. IPv6 network prefix allocation For IPv6, JANET has the prefix 2001:630::/32 from RIPE-NCC, as the national academic ISP in the UK. The University has been allocated 2001:630:d0::/48 by JANET. The department transitioning will be allocated a /52 size prefix under 2001:630:d0::/48, i.e. 2001:630:d0: Chown Expires September 7, 2006 [Page 12] Internet-Draft IPv6 Campus Transition March 2006 0::/52. In the initial deployment, we expect that IPv4 and IPv6 subnets will be congruent (and share the same VLANs). The advantage for IPv6 is that subnets will not need to be resized to conserve or efficiently utilise address space as is the case currently for IPv4 (as subnet host counts rise and fall for administrative or research group growth/decline reasons). 4.2.2. IPv6 Address allocation It is expected that the network devices will use a combination of address allocation mechanisms: o Manually configured addresses (in some servers) o Stateful DHCPv6 (probably in fixed, wired devices and some servers) o Stateless address autoconfiguration (probably in wireless and mobile devices) o RFC3041 privacy addresses (in some client devices) For devices using stateless or RFC3041 mechanisms, a Stateless DHCPv6 server will be required for other (non-address) configuration options, e.g. DNS and NTP servers. 4.3. Services 4.3.1. Email There are three MX hosts for inbound email, and two main internal mail servers. Sendmail is the MTA. POP and IMAP (and their secure versions) are used for mail access, using the Cyrus IMAP open source code. There is an MS Exchange server used by up to 100 users (generally those wanting shared access to mail spools, e.g. professors and secretaries). MailScanner is used for anti-spam/ anti-virus. This uses external services including various RBLs for part of its spam checking. Successful reverse DNS lookup is required for sendmail to accept internal SMTP connections for delivery. 4.3.2. Web Hosting Web content hosting is provided either with Apache 2.x (open source) or Microsoft IIS 5.0. Common components used to build systems with are MySQL, PHP 4 and Perl 5; these enable local tools such as Wikis to be run. Chown Expires September 7, 2006 [Page 13] Internet-Draft IPv6 Campus Transition March 2006 4.3.3. Databases All database systems are presented 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 The following are used: o NIS o LDAP o Active Directory o RADIUS 4.3.5. DNS The three DNS servers have recently been upgraded to BIND9. A DNS secondary is held at another UK university site. 4.3.6. PKI 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 The JANET NREN offers a stratum 0 NTP server. The department also has a GPS-based NTP server built-in to its own RIPE NCC test traffic server. 4.3.8. Multicast There is PIM-SM IPv4 multicast via a dedicated Cisco 7206 router. This supports applications including the IPv4 AccessGrid conferencing system. A number of bugs in the existing IPv4 equipment prevent heavy use of IPv4 Multicast within the department network (thus an IPv6 Multicast solution is highly desirable). An IPv4 Multicast beacon is used for monitoring Multicast. Chown Expires September 7, 2006 [Page 14] Internet-Draft IPv6 Campus Transition March 2006 4.3.9. Remote login Remote login access is offered via ssh, with sftp for file transfer. Remote use of 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. The content distribution server is hosted on such a system (e.g. containing MS software licenced under the Campus Agreement). 4.3.11. Backups Backups are run over SSH, which is IPv6-enabled. A site using a proprietary rempte 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 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 Chown Expires September 7, 2006 [Page 15] Internet-Draft IPv6 Campus Transition March 2006 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 Safari o Opera Chown Expires September 7, 2006 [Page 16] Internet-Draft IPv6 Campus Transition March 2006 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 Usage of IPv4 hard-coded addresses is interesting for at least two reasons. One is that it illustrates where IPv6 hard-coded addresses may appear, and thus secondly it is useful to analyse which hard- coded addresses may be barriers to smooth IPv6 renumbering. A procedure for renumbering has been described in Procedures for Renumbering an IPv6 Network without a Flag Day [10]. A non- exhaustive list of instances of such addresses includes: o Provider based prefix(es) o Names resolved to IP addresses in firewall at startup time o IP addresses in remote firewalls allowing access to remote services Chown Expires September 7, 2006 [Page 17] Internet-Draft IPv6 Campus Transition March 2006 o IP-based authentication in remote systems allowing access to online bibliographic resources o IP address of both tunnel end points for IPv6 in IPv4 tunnel o Hard-coded IP subnet configuration information o IP addresses for static route targets o Blocked SMTP server IP list (spam sources) o Web .htaccess and remote access controls o Apache .Listen. directive on given IP address o Configured multicast rendezvous point o TCP wrapper files o Samba configuration files o DNS resolv.conf on Unix o Nocol monitoring tool o NIS/ypbind via the hosts file o Some interface configurations o Unix portmap security masks o NIS security masks The author is contributing to work in studying things to think about in IPv6 renumbering [18], where the above issues will be considered. 5. Analysis We start by noting that our analysis does not include issues relating to deployment of new IPv6-specific technology, e.g. MIPv6. The work described in this document is also being fed into the IPv6 Enterprise Analysis [19] document, currently an ongoing work within the IPv6 Operations WG. The reader is referred in particular to Section 4 ("Wide-Scale Dual-Stack Deployment") and Section 7 ("General issues and applicability for all Scenarios") which were directly contributed from the work here. Chown Expires September 7, 2006 [Page 18] Internet-Draft IPv6 Campus Transition March 2006 5.1. Dual-Stack Deployment: Procedure As described in the IPv6 Enterprise Analysis [19] document, the scenario here is one of wide-scale dual-stack deployment. The plan for deployment follows the general guidelines of Section 7 of that document, i.e.: o Gaining initial connectivity. In our case, the connectivity is native IPv6 from JANET, via the regional MAN (using 6PE [15]) and the campus (using a VLAN to carry IPv6 natively). o Obtaining global IPv6 address space. The campus address space is a /48 prefix allocated by JANET, under their prefix of 2001: 630::/32. o Deploying basic network services: DNS, routing, host configuration support. We are currently using BIND9 for DNS servers, static or RIPng routing, and SLAAC host configuration until DHCPv6 implementations are available. o Formulating an IPv6 addressing plan. Our campus 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 256 IPv6 subnets initially. However, because the department runs an IPv6 tunnel broker for remote access, allocations from the /52 will be taken up early. o Ensuring IPv6 security. This is a function of site policy, which needs to be updated for IPv6-specific issues, e.g. privacy addresses, and implemented, via an IPv6 firewall and other measures. o IPv4-IPv6 interworking. As there are not (yet) any IPv6-only links, interowrking methods are not required. Should IPv6-only devices be deployed on the dual-stack infrastructure, we anticipate using proxy tools (web cache, SMTP relay, etc) to support their access to legacy IPv4 services. 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 services that we operate (a tunnel broker and a 6to4 relay, as described below). o Deploying wider IPv6 application, management and service support. This is an ongoing task, based on the services described in previous sections. Chown Expires September 7, 2006 [Page 19] Internet-Draft IPv6 Campus Transition March 2006 5.2. Dual-Stack Deployment: Transition toolbox We are using the following mechanisms in our department transition plan: o VLANs [13] to distribute IPv6 connectivity over the existing non- dual-stack network infrastructure. When dual-stack infrastructure is available, and the next procurement due, we will upgrade the core network infrastructure to dual-stack. The VLAN solution is an interim step as full dual protocol capable equipment is deployed; o An Tunnel broker [3] for remote access; o A 6to4 [4] relay for remote access. Users can manually configure the relay's IPv4 address. We considered deploying a Teredo [12] relay to support home users behind NATs, but chose not to do so since the tunnel broker service supports NAT traversal, and offers us better management and monitoring facilities. We do NOT currently see a requirement for: o NAT-PT [2], because we are dual-stack with no IPv6-only networks (yet), and as we introduce such networks, or IPv6-only nodes in the dual-stack networks, we expect to use application layer gateways and proxies for legacy IPv4 access; o ISATAP [11], because we prefer to use a structured internal IPv6 deployment, and are doing so in a pervasive fashion (i.e. not as a sparse deployment); o Teredo [12], as our remote users are capable of using other access methods. However, we may deploy a Teredo relay in due course to support home users behind NATs if they report problems with using other access methods. 5.3. Missing components An initial gap analysis for technology highlights the following missing components. 5.3.1. Standards (IETF)-specific o No method available to offer reverse IPv6 DNS for sendmail to verify autoconfiguring hosts (prepopulating a 64 bit subnet space is a problem, some wildcard method is required). Chown Expires September 7, 2006 [Page 20] Internet-Draft IPv6 Campus Transition March 2006 5.3.2. Vendor or platform-specific o During early 2005, there was no IPv6 Layer 3 functionality on the department's Ethernet switch/routing equipment; we thus used the parallel VLAN method. We now have IPv6-capable routing equipment deployed since August 2005; o Lack of NFS/Samba IPv6 support; o No IPv6 support for Active Directory; o Lack of supported IPv6 for Windows 98/2000/ME; o Lack of supported IPv6 for Irix; o Lack of supported IPv6 for various PDA platforms; o Lack of MLDv2 (or MLDv1) snooping in some legacy Ethernet switch equipment (thus IPv6 Multicast will flood subnets). Our newly procured equipment does support this; o No available IPv6-enabled X11 (there is an xfree but it is encumbered by an unpopular copyright statement that most distributors find unnacceptable); o No support for IPv6 hotspot access control via web-redirection systems; o Few DHCPv6 server implemntations, very few client implementations. 5.3.3. Application-specific o Lack of MS Exchange, Outlook or Eudora IPv6 support; o AccessGrid is IPv4-only (initial IPv6-enabling work was undertaken in the 6NET project); o Some Apache 2 modules lack Apache 1.3 functionality, hence migrating is a problem in a small number of cases; 5.3.4. Other (policy, political,...) o The migration from ip6.int to ip6.arpa is moving slowly. 5.4. Considerations beyond the Scenarios Document Here we mention issues or scenario components that were not explicitly listed in the IPv6 Enterprise Network Scenarios document. Chown Expires September 7, 2006 [Page 21] Internet-Draft IPv6 Campus Transition March 2006 Due to the scope, that document could not embrace all details. We mention here components that other sites may also wish to consider: o Support for WLAN and other access control. 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 ..To be completed.. 6. Summary In this document we have analysed the specific campus transition 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 of the scenario are relevant. Our current status is that the core department routing infrastructure is now dual-protocol capable, and we run both IPv4 and IPv6 on the wire with congruent subnets. The deployment has now been in full dual-stack operation, with key services enabled (including DNS, SMTP, web) without adverse effects. The VLAN-based interim step was useful for two years until a dual- protocol solution could be procured. We plan a new update of this text after IETF65; input is welcomed. The address planning element of our campus deployment is being discussed in a separate addressing considerations [20] text. 7. Acknowledgements Discussions with fellow participants on the 6NET and Euro6IX projects have been valuable. 8. Security Considerations There are no specific new considerations from this scenario description and analysis. 9. Informative References [1] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [2] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. Chown Expires September 7, 2006 [Page 22] Internet-Draft IPv6 Campus Transition March 2006 [3] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [6] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [7] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. [8] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. [9] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005. [10] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [11] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005. [12] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [13] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks", draft-chown-v6ops-vlan-usage-02 (work in progress), October 2004. [14] Chown, T., "DHCP: IPv4 and IPv6 Dual-Stack Issues", draft-ietf-dhc-dual-stack-04 (work in progress), October 2005. [15] Clercq, J., "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)", draft-ooms-v6ops-bgp-tunnel-06 (work in progress), January 2006. [16] Savola, P., "IPv6 Transition/Co-existence Security Considerations", draft-savola-v6ops-security-overview-03 (work in progress), October 2004. Chown Expires September 7, 2006 [Page 23] Internet-Draft IPv6 Campus Transition March 2006 [17] Venaas, S., "An IPv4 - IPv6 multicast gateway", draft-venaas-mboned-v4v6mcastgw-00 (work in progress), February 2003. [18] Chown, T., "Things to think about when Renumbering an IPv6 network", draft-chown-v6ops-renumber-thinkabout-03 (work in progress), July 2005. [19] Bound, J., "IPv6 Enterprise Network Analysis", draft-ietf-v6ops-ent-analysis-04 (work in progress), February 2006. [20] Velde, G., "IPv6 Unicast Address Assignment Considerations", draft-vandevelde-v6ops-addcon-00 (work in progress), February 2006. Chown Expires September 7, 2006 [Page 24] Internet-Draft IPv6 Campus Transition March 2006 Author's Address Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom Email: tjc@ecs.soton.ac.uk Chown Expires September 7, 2006 [Page 25] Internet-Draft IPv6 Campus Transition March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at 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 Funding for the RFC Editor function is currently provided by the Internet Society. Chown Expires September 7, 2006 [Page 26]