idnits 2.17.1 draft-chown-v6ops-campus-transition-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 982. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 959. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 966. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 972. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 988), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 161 has weird spacing: '...perhaps be mo...' == Line 466 has weird spacing: '...ting to a Nok...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2004) is 7227 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '8' is defined on line 905, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '1') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '4') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '5') (Obsoleted by RFC 8415) == Outdated reference: A later version (-02) exists of draft-chown-v6ops-vlan-usage-00 == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-00 == Outdated reference: A later version (-04) exists of draft-ietf-dhc-dual-stack-00 == Outdated reference: A later version (-07) exists of draft-ietf-mboned-embeddedrp-00 == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-application-transition-00 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-ent-scenarios-00 == Outdated reference: A later version (-07) exists of draft-ooms-v6ops-bgp-tunnel-00 == Outdated reference: A later version (-03) exists of draft-savola-v6ops-security-overview-00 Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Operations T. Chown 2 Internet-Draft University of Southampton 3 Expires: January 10, 2005 July 12, 2004 5 IPv6 Campus Transition Scenario Description and Analysis 6 draft-chown-v6ops-campus-transition-00 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 10, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 In this document we consider and analyse the specific scenario of 40 IPv6 transition and deployment in a large department of a university 41 campus network. The department is large enough to operate its own 42 instances of all the conventional university services including (for 43 example) web, DNS, email, filestore, interactive logins, and remote 44 and wireless access. The scenario is a dual-stack one, i.e. 45 transition to IPv6 means deploying IPv6 in the first instance 46 alongside IPv4. This analysis will both identify the available (and 47 still missing) components for IPv6 transition, and also test the 48 applicability of the recently completed IPv6 Enterprise Network 49 Scenarios document. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Discussion of Scenarios Network Infrastructure Components . 5 55 2.1 Component 1: Enterprise Provider Requirements . . . . . . 5 56 2.2 Component 2: Enterprise Application Requirements . . . . . 6 57 2.3 Component 3: Enterprise IT Department Requirements . . . . 6 58 2.4 Component 4: Enterprise Network Management System . . . . 8 59 2.5 Component 5: Enterprise Network Interoperation and 60 Coexistence . . . . . . . . . . . . . . . . . . . . . . . 8 61 3. Discussion of Network Infrastructure Component 62 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.1 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.2 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.3 Configuration of Hosts . . . . . . . . . . . . . . . . . . 9 66 3.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.5 Applications . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.6 Network Management . . . . . . . . . . . . . . . . . . . . 10 69 3.7 Address Planning . . . . . . . . . . . . . . . . . . . . . 10 70 3.8 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 10 71 3.9 Multihoming . . . . . . . . . . . . . . . . . . . . . . . 10 72 4. Specific Scenario Component Review . . . . . . . . . . . . . 10 73 4.1 Network Components . . . . . . . . . . . . . . . . . . . . 10 74 4.1.1 Physical connectivity (Layer 2) . . . . . . . . . . . 10 75 4.1.2 Routing and Logical subnets (Layer 3) . . . . . . . . 11 76 4.1.3 Firewall . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.1.4 Intrusion Detection System . . . . . . . . . . . . . . 11 78 4.1.5 Management . . . . . . . . . . . . . . . . . . . . . . 11 79 4.1.6 Monitoring . . . . . . . . . . . . . . . . . . . . . . 11 80 4.1.7 Remote access . . . . . . . . . . . . . . . . . . . . 11 81 4.1.8 IPv6 External Access . . . . . . . . . . . . . . . . . 12 82 4.2 Address Allocation Components . . . . . . . . . . . . . . 12 83 4.2.1 IPv6 network prefix allocation . . . . . . . . . . . . 12 84 4.2.2 IPv6 Address allocation . . . . . . . . . . . . . . . 12 85 4.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 4.3.1 Email . . . . . . . . . . . . . . . . . . . . . . . . 13 87 4.3.2 Web Hosting . . . . . . . . . . . . . . . . . . . . . 13 88 4.3.3 Databases . . . . . . . . . . . . . . . . . . . . . . 13 89 4.3.4 Directory Services . . . . . . . . . . . . . . . . . . 13 90 4.3.5 DNS . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 4.3.6 PKI . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 4.3.7 NTP . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 4.3.8 USENET News . . . . . . . . . . . . . . . . . . . . . 14 94 4.3.9 Multicast . . . . . . . . . . . . . . . . . . . . . . 14 95 4.3.10 Remote login . . . . . . . . . . . . . . . . . . . . 14 96 4.3.11 File serving . . . . . . . . . . . . . . . . . . . . 14 98 4.4 Host and Device Platforms . . . . . . . . . . . . . . . . 14 99 4.4.1 Server platforms . . . . . . . . . . . . . . . . . . . 14 100 4.4.2 Desktop/laptop platforms . . . . . . . . . . . . . . . 15 101 4.4.3 PDA platforms . . . . . . . . . . . . . . . . . . . . 15 102 4.5 User Tools . . . . . . . . . . . . . . . . . . . . . . . . 15 103 4.5.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . 15 104 4.5.2 Mail Client . . . . . . . . . . . . . . . . . . . . . 16 105 4.5.3 Web Browser . . . . . . . . . . . . . . . . . . . . . 16 106 4.5.4 Conferencing systems . . . . . . . . . . . . . . . . . 16 107 4.5.5 Other collaboration tools . . . . . . . . . . . . . . 16 108 4.5.6 Usenet news client . . . . . . . . . . . . . . . . . . 16 109 4.5.7 Host communications . . . . . . . . . . . . . . . . . 17 110 4.6 Hard-coded address points . . . . . . . . . . . . . . . . 17 111 5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 18 112 5.1 Philosophy . . . . . . . . . . . . . . . . . . . . . . . . 18 113 5.2 Current deployment . . . . . . . . . . . . . . . . . . . . 18 114 5.3 Planned transition steps . . . . . . . . . . . . . . . . . 18 115 5.4 Missing components . . . . . . . . . . . . . . . . . . . . 18 116 5.5 Considerations beyond the Scenarios Document . . . . . . . 19 117 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 20 118 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 119 8. Security Considerations . . . . . . . . . . . . . . . . . . 20 120 9. Informative References . . . . . . . . . . . . . . . . . . . 20 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . 21 122 Intellectual Property and Copyright Statements . . . . . . . 22 124 1. Introduction 126 The scope of the enterprise network transition scenarios is very 127 large, much more so than that of the other three IPv6 transition 128 areas under study within the IETF. The IPv6 Enterprise Network 129 Scenarios [13] have been defined. In this document we present a 130 specific case study area for IPv6 transition, namely a large 131 department (1,500 staff and students, over 1,000 hosts) in an 132 academic campus network. The purpose of this document in its current 133 form is to both define and analyse the IPv6 transition of such a 134 network, but also to test the applicability of the IPv6 Enterprise 135 Network Scenarios document to a specific example. 137 Our campus study falls under "Scenario 1" of the IPv6 Enterprise 138 Network Scenarios [13] document, i.e. the campus network is an 139 existing IPv4 network, where IPv6 is to be deployed in conjunction 140 with the IPv4 network. 142 "Scenario 1" has the assumption that the IPv4 network infrastructure 143 used has an equivalent capability in IPv6. This document will 144 analyse that assumption. The Scenario also has requirements, i.e. 145 that the existing IPv4 network infrastructure is not disrupted, and 146 that IPv6 should be equivalent or better than the network 147 infrastructure in IPv4. The Scenario also notes that it may also not 148 be feasible to deploy IPv6 on all parts of the network immediately. 150 These assumptions and requirements will be discussed later in this 151 text. 153 It should also be noted why Scenarios 2 and 3 did not apply to this 154 campus transition scenario. Scenario 2 talks of specific 155 applications, but in the campus case we wish to deploy IPv6 156 pervasively, in wired and wireless networks, as an enabler for 157 education and research, to encourage new application development. 158 Scenario 3 focuses on using IPv6 as the basis for most network 159 communication, but in the campus we already have a significant IPv4 160 deployment that will be utilised for the foreseeable future (Scenario 161 3 would perhaps be more appropriate for a greenfield deployment). 163 This document is very much a work in progress, and thus this first 164 instance of this document is not intended to be complete or 165 comprehensive. Some sections are empty at this stage. We make no 166 claims that this campus scenario is typical, but believe the lessons 167 leanrt and analysis undertaken may be of wider interest. Feedback is 168 sought on scope and the required level of detail. 170 2. Discussion of Scenarios Network Infrastructure Components 172 In this section, we look at the issues raised by following the 173 Scenarios Network Infrastructure Components of the IPv6 Enterprise 174 Network Scenarios [13] document, section 3.2. 176 2.1 Component 1: Enterprise Provider Requirements 178 The answers to the questions posed in this section of the IPv6 179 Enterprise Network Scenarios document are as follows: 181 o There is external access to/from the campus network, regional MAN 182 and National Research Network beyond. 184 o There are needs for access by remote staff, student and 185 researchers. 187 o It is a single site, with four buildings. 189 o There are no leased lines or wide-area VPNs between remote 190 buildings. 192 o The department has 12 IPv4 Class C's, the campus has a Class B, 193 independent from its provider (assigned prior to use of CIDR). 195 o The IPv4 and IPv6 provider is the National Research and Education 196 Network (JANET in the UK). JANET provides a /48 prefix for the 197 university. The university offers a /52 prefix for the 198 department. 200 o The university and department make their own prefix allocations 201 for subnets. 203 o There is no multihoming, and thus no multihomed clients. 205 o The only IPv6 service offered by the provider to date is a 6to4 206 [3] relay. 208 o There is no exteral IPv6 routing protocol needed due to the use of 209 static route configuration. 211 o There is no external data centre. 213 o IPv6 runs over the same access links to campus (the JANET backbone 214 uses true dual stack, the regional MAN uses 6PE [14]. On campus, 215 the IPv4 traffic to the department is received through a Nokia 216 IP740 firewall, the IPv6 traffic is received through a BSD 217 firewall. Thus the access links into the department for IPv4 and 218 IPv6 are different, though the goal is to make them the same. 220 2.2 Component 2: Enterprise Application Requirements 222 Answers to the next IPv6 Enterprise Network Scenarios section are as 223 follows: 225 o The application inventory is discussed in the specific component 226 review in the next section. 228 o We expect the first applications to be moved will be the support 229 services, including DNS. The first applications should be the 230 common IPv4 applications, e.g. web, remote login and email, such 231 that IPv6 offers as least an equivalent service to IPv4 for the 232 important applications. 234 o The academic environment has a good mix of open source and 235 commercial software, predominantly either Microsoft or Linux, but 236 with a growing number of Mac OS/X users. Specific platforms are 237 reviewed in the component review in the next main section. Most 238 open source applications have been upgraded to allow IPv6 239 operation; others can be upgraded given time. 241 o The general goal is for applications to support both IPv4 or IPv6 242 operation, i.e. to be IP agnostic. 244 o There is no use of NAT in the department's network. Home users, 245 or users access into the network remotely from certain locations, 246 may experience NAT at their client side. 248 o NAT issues are relevant from the end-to-end perspective, for 249 establishment of end-to-end security where desired, and in 250 relation to IPv6 transition (remote access) mathods that may be 251 run through NATs. 253 o There is a mix of internal and external applications. Where 254 limitations occur, it is mainly by policy not technology, e.g. as 255 implemented in firewall restrictions. 257 2.3 Component 3: Enterprise IT Department Requirements 259 Here we list responses to the next IPv6 Enterprise Network Scenarios 260 section on IT Department Requirements: 262 o Ownership and support is all in-house. 264 o Remote VPNs are supported. 266 o No inter-site networking is required. 268 o No network mobility support is needed at this point, though we 269 expect to use Mobile IPv6 between the department network and a 270 local community wireless network. 272 o The IPv6 address plan for the department requires a /52 prefix. 274 o There is no detailed asset database, though one is being built. 276 o There are no geographically separate sites. 278 o The internal IPv4 address assignment mechanism is DHCP for 279 clients, with manual configuration for servers. We thus expect to 280 use DHCPv6 for at least some IPv6 clients. 282 o Internal IPv4 routing is static or uses RIP. We thus expect to 283 use RIPng internally. 285 o We expect our IPv6 network management policy to be very similar to 286 that for IPv4. 288 o There is no QoS provision at present, largely due to the ample 289 campus bandwidth (1Gbit/s uplink). 291 o Security is applied through many technologies implementing our 292 policies, e.g. firewall, email scanning, wireless LAN access 293 controls. We expect similar policies for IPv6, but need to 294 analyse differences. 296 o Training will be done in-house. 298 o The impacted software components are discussed in the next main 299 section. Not all functions are upgradeable to IPv6; those that 300 are not are discussed in the analysis section. Some are, e.g. 301 use of OpenLDAP in place of MS Active Directory. 303 o The impacted hardware components are discussed in the next main 304 section. Not all hardware is upgradeable, e.g. network printers. 305 There are no load balancing systems in use. There are wireless 306 LAN hosts in the network that are mobile, but currently the 307 wireless network is a flat IPv4 subnet. There may be nodes moving 308 to external wireless networks (the local community wireless 309 network. 311 2.4 Component 4: Enterprise Network Management System 313 The responses to the next IPv6 Enterprise Network Scenarios section 314 are as follows: 316 o No performance management is required. 318 o There are a number of network management and monitoring tools in 319 use, which will need to be used in a dual stack or IPv6 mode, e.g. 320 the nocol availability monitring tools, and SNMP-based management. 322 o The configuration management may include use of tools to configure 323 services including DNS and email. 325 o No policy management and enforcement tools are required. 327 o No detailed security management is required, though we expect to 328 manage the implementations including firewalls and intrusion 329 detection. 331 o We may need to manage the deployed transition tools and 332 mechanisms. 334 o We need to analyse the considerations IPv6 creates for network 335 management, e.g. use (or not) of RFC3041 privacy addresses. 337 2.5 Component 5: Enterprise Network Interoperation and Coexistence 339 Answers to the final IPv6 Enterprise Network Scenarios section on 340 Coexistence are as follows: 342 o The platforms that are required to be IPv6 capable are listed in 343 the next main section. 345 o There is only one network ingress and egress point to the site 346 that needs to be IPv6 capable; this is a Gigabit Ethernet 347 interface. 349 o The required transition mechanisms are discussed in the analysis 350 section. We expect to mainly use the VLAN [7] mechanism for 351 internal IPv6 transport, with a parallel IPv6 routing 352 infrastructure based on BSD routers. 354 o The transition to IPv6 will be enabled on the wire first, enabling 355 clients, with a phased introduction of service capability, as 356 discussed below in the analysis section. 358 o The preferred mechanism for interoperation with legacy nodes is to 359 use dual-stack and thus IPv4 to communicate to IPv4 nodes and IPv6 360 to communicate to IPv6 nodes. We have not identified any 361 in-house, non-upgradeable legacy applications. 363 3. Discussion of Network Infrastructure Component Requirements 365 In this section, we discuss the network infrastructure component 366 requirements raised in the IPv6 Enterprise Network Scenarios [13] 367 document, in section 4. 369 3.1 DNS 371 BIND9 is used for our three internal name servers. The servers will 372 be made dual stack, to be available for IPv6 transport for local 373 dual-stack or IPv6-only nodes. 375 3.2 Routing 377 Internal routing is either statically configured or uses RIP. We 378 thus expect to use RIPng for internal IPv6 routing. The external 379 routing is statically configured for IPv4, and thus is likely to be 380 statically configured for IPv6. 382 3.3 Configuration of Hosts 384 IPv4 clients use DHCP for address and other configuration options. 385 We expect to use Dynamic Host Configuration Protocol for IPv6 386 (DHCPv6) [4] for IPv6 clients. This will require analysis of the 387 IPv4 and IPv6 Dual-Stack Issues for DHCPv6 [10]. We expect some 388 clients, especially in wireless LANs, to use IPv6 Stateless 389 Autoconfiguration [1], and these nodes will need support for 390 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 391 [5] for other configuration options, including the IPv6 address of a 392 local DNS resolver. 394 3.4 Security 396 We need to identify new IPv6 related security considerations, and 397 those associated with transition mechanisms [15]. Site policies may 398 need to be updated as a result. 400 3.5 Applications 402 The Application Aspects of IPv6 Transition [12] document describes 403 best porting practice for applications. There should also be 404 consideration for any required application proxies. 406 3.6 Network Management 408 The network management and monitoring systems will need to embrace 409 IPv6, and any transition mechanisms used to deploy IPv6. Monitoring 410 includes usage tracking (e.g. via MRTG) and availability monitoring 411 (e.g. via nocol). 413 3.7 Address Planning 415 The department receives 12 Class C prefixes for IPv4 use, and uses 416 only globally routable addresses internally. The IPv4 address space 417 for the campus was obtained prior to CIDR, but the IPv6 address space 418 is allocated from the UK National Research Network (JANET) address 419 space under 2001:0630::/32. The university receives a /48 prefix, 420 which is 2001:0630:d0::/48. The department has a /52 allocation 421 within this block of 2001:0630:d0:0:/52. 423 3.8 Multicast 425 IPv4 multicast is used for a number of applications, including the 426 AccessGrid. Connectivity is provided via the local campus and 427 regional network. We expect to use both IPv6 ASM (i.e. PIM-SM), and 428 may seek to make use of the Embedding the Address of RP in IPv6 429 Multicast Address [11] technique. For briding between IPv4 and IPv6 430 multicast, we believe an IPv4 - IPv6 multicast gateway [16] may prove 431 valuable. Finally, we expect to make use of source specific 432 multicast (SSM) more heavily in IPv6, bringing IPv6 and SSM together 433 in one deployment cycle. 435 3.9 Multihoming 437 The site is not multihomed. 439 4. Specific Scenario Component Review 441 Here we describe specific technology in use now in the department. 442 Later in this section we discuss any items not included in the above 443 section, i.e. those not explicitly mentioned in the IPv6 Enterprise 444 Network Scenarios document. In the next main section we analyse 445 these for missing technologies, as a form of gap analysis. 447 4.1 Network Components 449 4.1.1 Physical connectivity (Layer 2) 450 o Switched Ethernet 452 o Gigabit Ethernet 454 o Wireless networking (802.11b) 456 4.1.2 Routing and Logical subnets (Layer 3) 458 The hybrid Layer 2/3 routing equipment has approximately 20 internal 459 IPv4 subnets (in effect, routed VLANs). There is no specific 460 internal routing protocol used. There is a static route via the site 461 firewall to the main upstream provider (academic) running at 1Gbit/s. 463 4.1.3 Firewall 465 The firewall is currently CheckPoint Firewall-1 running on a Sun 466 Solaris platform, just migrating to a Nokia IP740 hardware platform. 467 There is one internal facing interface, one external facing 468 interface, and two .DMZ. interfaces, one for wired hosts and one for 469 the Wireless LAN provision. 471 4.1.4 Intrusion Detection System 473 o Snort 475 4.1.5 Management 477 Some network management is performend by SNMP; there is no specific 478 package for this. There is a greater emphasis on monitoring than 479 explictly in management. 481 4.1.6 Monitoring 483 A number of tools are used, to monitor network usage as well as 484 systems availability, e.g. nocol, nagios and MRTG. The IBM AWM tool 485 is used for network testing, along with iperf, rude and crude. 487 4.1.7 Remote access 489 o Livingston Portmaster 56K/ISDN dialup 491 o RADIUS server 493 o (Microsoft) VPN server 495 4.1.8 IPv6 External Access 497 o IPv6 connectivity comes via 6PE from our regional network. 499 4.2 Address Allocation Components 501 The department receives its IPv4 and IPv6 address allocations from 502 the University. For IPv4, the University has a Class B allocation 503 which is not aggregated under the JANET NREN. For IPv6, the 504 University receives its allocation from JANET. 506 4.2.1 IPv6 network prefix allocation 508 For IPv6, JANET has the prefix 2001:630::/32 from RIPE-NCC, as the 509 national academic ISP in the UK. The University has been allocated 510 2001:630:d0::/48 by JANET. The department transitioning will be 511 allocated a /52 size prefix under 2001:630:d0::/48, i.e. 512 2001:630:d0:0::/52. 514 In the initial deployment, we expect that IPv4 and IPv6 subnets will 515 be congruent (and share the same VLANs). The advantage for IPv6 is 516 that subnets will not need to be resized to conserve or efficiently 517 utilise address space as is the case currently for IPv4 (as subnet 518 host counts rise and fall for administrative or research group 519 growth/decline reasons). 521 4.2.2 IPv6 Address allocation 523 It is expected that the network devices will use a combination of 524 address allocation mechanisms: 526 o Manually configured addresses (in some servers) 528 o Stateful DHCPv6 (probably in fixed, wired devices and some 529 servers) 531 o Stateless address autoconfiguration (probably in wireless and 532 mobile devices) 534 o RFC3041 privacy addresses (in some client devices) 536 For devices using stateless or RFC3041 mechanisms, a Stateless DHCPv6 537 server will be required for other (non-address) configuration 538 options, e.g. DNS and NTP servers. 540 4.3 Services 542 4.3.1 Email 544 There are three MX hosts for inbound email, and two main internal 545 mail servers. Sendmail is the MTA. POP and IMAP (and their secure 546 versions) are used for mail access, using the UW-IMAP open source 547 code. There is an MS Exchange server used by up to 100 users 548 (generally those wanting shared access to mail spools, e.g. 549 professors and secretaries). MailScanner is used for anti-spam/ 550 anti-virus. This uses external services including various RBLs for 551 part of its spam checking. Successful reverse DNS lookup is required 552 for sendmail to accept internal SMTP connections for delivery. 554 4.3.2 Web Hosting 556 Web content hosting is provided either with Apache 1.3.x (open 557 source) or Microsoft IIS 5.0. Common components used to build 558 systems with are MySQL, PHP 4 and Perl 5; these enable local tools 559 such as Wikis to be run. 561 4.3.3 Databases 563 All database systems are presented via a web interface, including the 564 financial systems. In some cases, e.g. student records, ODBC-like 565 access is required/used in to/out from the department systems to the 566 campus systems. Databases include: finance records, people, projects 567 and publications (offered using ePrints). 569 4.3.4 Directory Services 571 The following are used: 573 o NIS (6 servers, all Solaris) 575 o LDAP 577 o Active Directory 579 o RADIUS 581 4.3.5 DNS 583 The three DNS servers have recently been upgraded to BIND9. A DNS 584 secondary is held at another UK university site. 586 4.3.6 PKI 588 The department has at least 10 SSL certificates from Thawte, 589 including Web-signing certificates. No personal certificates are 590 supported by the department (though users may have their own). 592 4.3.7 NTP 594 The JANET NREN offers a stratum 0 NTP server. The department also 595 has a GPS-based NTP server built-in to its own RIPE NCC test traffic 596 server. 598 4.3.8 USENET News 600 The news feed is delivered using dnews. 602 4.3.9 Multicast 604 There is PIM-SM IPv4 multicast via a dedicated Cisco 7206 router. 605 This supports applications including the IPv4 AccessGrid conferencing 606 system. A number of bugs in the existing IPv4 equipment prevent 607 heavy use of IPv4 Multicast within the department network (thus an 608 IPv6 Multicast solution is highly desirable). An IPv4 Multicast 609 beacon is used for monitoring Multicast. 611 4.3.10 Remote login 613 Remote login access is offered via ssh, with sftp for file transfer. 614 Remote use of telnet and ftp is denied by the firewall. 616 4.3.11 File serving 618 The main file servers are SGI systems, hosting large (multi-TB) 619 standalone RAID arrays. The files are offered via NFS and Samba to 620 client systems. The content distribution server is hosted on such a 621 system (e.g. containing MS software licenced under the Campus 622 Agreement). 624 4.4 Host and Device Platforms 626 4.4.1 Server platforms 628 These include: 630 o Windows 2003 server 632 o Windows 2000 server 633 o Windows NT 635 o Solaris 8 637 o Solaris 9 639 o RedHat Linux 641 o SGI Origin 300 (Irix 6.5.x) 643 4.4.2 Desktop/laptop platforms 645 These include: 647 o Windows 98, 2000, ME, XP 649 o Linux (various flavours) 651 o MacOS/X 653 o BSD (various flavours) 655 4.4.3 PDA platforms 657 These include: 659 o Windows CE/.NET, Pocket PC 661 o PalmOS 663 o Familiar Linux on iPaQ 665 o Zaurus (Linux) 667 4.5 User Tools 669 These are non-exhaustive but representative application/platform 670 lists 672 4.5.1 Hardware 674 o Networked printers 676 o Networked webcams 678 4.5.2 Mail Client 680 o Outlook (various versions) 682 o Eudora 684 o Mutt 686 o Pine 688 4.5.3 Web Browser 690 o MS Internet Explorer 692 o Mozilla 694 o Safari 696 o Opera 698 4.5.4 Conferencing systems 700 o AccessGrid 702 o A dedicated H.323 system 704 o MS Netmeeting 706 4.5.5 Other collaboration tools 708 o IRC 710 o Jabber 712 o MSN Messenger 714 o cvs 716 4.5.6 Usenet news client 718 o nn 720 o Mozilla 722 4.5.7 Host communications 724 o X11 726 o VNC 728 o PC Anywhere 730 4.6 Hard-coded address points 732 Usage of IPv4 hard-coded addresses is interesting for at least two 733 reasons. One is that it illustrates where IPv6 hard-coded addresses 734 may appear, and thus secondly it is useful to analyse which 735 hard-coded addresses may be barriers to smooth IPv6 renumbering. A 736 procedure for renumbering has been described in Procedures for 737 Renumbering an IPv6 Network without a Flag Day [6]. A non-exhaustive 738 list of instances of such addresses includes: 740 o Provider based prefix(es) 742 o Names resolved to IP addresses in firewall at startup time 744 o IP addresses in remote firewalls allowing access to remote 745 services 747 o IP-based authentication in remote systems allowing access to 748 online bibliographic resources 750 o IP address of both tunnel end points for IPv6 in IPv4 tunnel 752 o Hard-coded IP subnet configuration information 754 o IP addresses for static route targets 756 o Blocked SMTP server IP list (spam sources) 758 o Web .htaccess and remote access controls 760 o Apache .Listen. directive on given IP address 762 o Configured multicast rendezvous point 764 o TCP wrapper files 766 o Samba configuration files 768 o DNS resolv.conf on Unix 769 o Nocol monitoring tool 771 o NIS/ypbind via the hosts file 773 o Some interface configurations 775 o Unix portmap security masks 777 o NIS security masks 779 5. Analysis 781 To be added. 783 5.1 Philosophy 785 To be added. Essentially dual-stack is a path to allowing IPv6-only 786 devices to be added later, and preferred external IPv6 787 communications. 789 Some mechanisms will be needed for remote access from staff or 790 student homes in the absence of their ISP not supporting IPv6, e.g. 791 Tunnel broker [2], 6to4 [3] or Teredo [9]. These are to be analysed, 792 and the support implications (where appropriate). 794 5.2 Current deployment 796 To be added. 798 5.3 Planned transition steps 800 To be added. 802 5.4 Missing components 804 An initial gap analysis for technology highlights the following 805 missing components: 807 o No IPv6 Layer 3 functionality on the department's current Ethernet 808 switch/routing equipment (this will be worked around using the 809 parallel VLAN method, until new IPv6-capable equipment is 810 deployed); 812 o Lack of NFS/Samba IPv6 support; 814 o Lack of MS Exchange, Outlook or Eudora IPv6 support; 815 o AccessGrid is IPv4-only (IPv6-enabling work is to be undertaken in 816 6NET); 818 o Some Apache 2 modules lack Apache 1.3 functionality, hence 819 migrating is a problem in a small number of cases; 821 o No IPv6 support for Active Directory; 823 o No IPv6 dnews, so one would have to use inn as a Usenet news 824 server; 826 o Lack of supported IPv6 for Windows 98/2000/ME; 828 o Lack of supported IPv6 for Irix; 830 o Lack of supported IPv6 for various PDA platforms; 832 o No method available to offer reverse IPv6 DNS for sendmail to 833 verify autoconfiguring hosts (prepopulating a 64 bit subnet space 834 is a problem, some wildcard method is required); 836 o Lack of MLDv2 snooping in Ethernet switch equipment (thus IPv6 837 Multicast will flood subnets); 839 o No available IPv6-enabled X11 (there is an xfree but it is 840 encumbered by an unpopular copyright statement that most 841 distributors find unnacceptable); 843 o No support for IPv6 hotspot access control via web-redirection 844 systems. 846 5.5 Considerations beyond the Scenarios Document 848 Here we mention issues or scenario components that were not 849 explicitly listed in the IPv6 Enterprise Network Scenarios document. 850 Due to the scope, that document could not embrace all details. We 851 mention here components that other sites may also wish to consider: 853 o Support for WLAN and other access control. One solution is to use 854 802.1x which is IP-agnostic as a Layer 2 port control mechanism. 856 o Consideration for hard-coded addresses. 858 o ..To be completed.. 860 6. Summary 862 In this document we will analyse the specific campus transition 863 scenario for the author's site, and report the analysis for the 864 benefit of others who may be in a similar scenario, or for whom parts 865 of the scenario are relevant. The basic IPv6 deployment is doable 866 now, but there are still missing components that prevent a full 867 dual-stack deployment. 869 7. Acknowledgements 871 Discussions with fellow participants on the 6NET and Euro6IX projects 872 have been valuable. 874 8. Security Considerations 876 There are no specific new considerations from this scenario 877 description and analysis. 879 9 Informative References 881 [1] Thomson, S. and T. Narten, "IPv6 Stateless Address 882 Autoconfiguration", RFC 2462, December 1998. 884 [2] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel 885 Broker", RFC 3053, January 2001. 887 [3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 888 IPv4 Clouds", RFC 3056, February 2001. 890 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 891 Carney, "Dynamic Host Configuration Protocol for IPv6 892 (DHCPv6)", RFC 3315, July 2003. 894 [5] Droms, R., "Stateless Dynamic Host Configuration Protocol 895 (DHCP) Service for IPv6", RFC 3736, April 2004. 897 [6] Baker, F., "Procedures for Renumbering an IPv6 Network without 898 a Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in 899 progress), October 2003. 901 [7] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in 902 Enterprise Networks", draft-chown-v6ops-vlan-usage-00 (work in 903 progress), October 2003. 905 [8] Chown, T., "IPv4 and IPv6 Dual-Stack Issues for DHCPv6", 906 draft-chown-dhc-dual-stack-00 (work in progress), February 907 2004. 909 [9] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 910 draft-huitema-v6ops-teredo-00 (work in progress), June 2003. 912 [10] Chown, T., "IPv4 and IPv6 Dual-Stack Issues for DHCPv6", 913 draft-ietf-dhc-dual-stack-00 (work in progress), March 2004. 915 [11] Savola, P. and B. Haberman, "Embedding the Address of RP in 916 IPv6 Multicast Address", draft-ietf-mboned-embeddedrp-00 (work 917 in progress), October 2003. 919 [12] Shin, M., "Application Aspects of IPv6 Transition", 920 draft-ietf-v6ops-application-transition-00 (work in progress), 921 December 2003. 923 [13] Bound, J., "IPv6 Enterprise Network Scenarios", 924 draft-ietf-v6ops-ent-scenarios-00 (work in progress), October 925 2003. 927 [14] Clercq, J., "Connecting IPv6 Islands across IPv4 Clouds with 928 BGP", draft-ooms-v6ops-bgp-tunnel-00 (work in progress), 929 October 2002. 931 [15] Savola, P., "IPv6 Transition/Co-existence Security 932 Considerations", draft-savola-v6ops-security-overview-00 (work 933 in progress), June 2003. 935 [16] Venaas, S., "An IPv4 - IPv6 multicast gateway", 936 draft-venaas-mboned-v4v6mcastgw-00 (work in progress), February 937 2003. 939 Author's Address 941 Tim Chown 942 University of Southampton 944 School of Electronics and Computer Science 945 Southampton, Hampshire SO17 1BJ 946 United Kingdom 948 EMail: tjc@ecs.soton.ac.uk 950 Intellectual Property Statement 952 The IETF takes no position regarding the validity or scope of any 953 Intellectual Property Rights or other rights that might be claimed to 954 pertain to the implementation or use of the technology described in 955 this document or the extent to which any license under such rights 956 might or might not be available; nor does it represent that it has 957 made any independent effort to identify any such rights. Information 958 on the procedures with respect to rights in RFC documents can be 959 found in BCP 78 and BCP 79. 961 Copies of IPR disclosures made to the IETF Secretariat and any 962 assurances of licenses to be made available, or the result of an 963 attempt made to obtain a general license or permission for the use of 964 such proprietary rights by implementers or users of this 965 specification can be obtained from the IETF on-line IPR repository at 966 http://www.ietf.org/ipr. 968 The IETF invites any interested party to bring to its attention any 969 copyrights, patents or patent applications, or other proprietary 970 rights that may cover technology that may be required to implement 971 this standard. Please address the information to the IETF at 972 ietf-ipr@ietf.org. 974 Disclaimer of Validity 976 This document and the information contained herein are provided on an 977 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 978 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 979 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 980 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 981 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 982 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 984 Copyright Statement 986 Copyright (C) The Internet Society (2004). This document is subject 987 to the rights, licenses and restrictions contained in BCP 78, and 988 except as set forth therein, the authors retain all their rights. 990 Acknowledgment 992 Funding for the RFC Editor function is currently provided by the 993 Internet Society.