idnits 2.17.1 draft-ietf-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 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1261. ** 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. 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 : ---------------------------------------------------------------------------- == There are 3 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 -- 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 (October 15, 2006) is 6403 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) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '1') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2766 (ref. '2') (Obsoleted by RFC 4966) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '5') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '6') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4214 (ref. '13') (Obsoleted by RFC 5214) == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-addcon-01 == Outdated reference: A later version (-07) exists of draft-ooms-v6ops-bgp-tunnel-06 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-security-overview-05 == Outdated reference: A later version (-07) exists of draft-ietf-v6ops-ent-analysis-06 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Chown 3 Internet-Draft University of Southampton 4 Expires: April 18, 2007 October 15, 2006 6 IPv6 Campus Transition Scenario Description and Analysis 7 draft-ietf-v6ops-campus-transition-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 18, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 In this document we consider and analyse the specific scenario of 41 IPv6 transition and deployment in a large department of a university 42 campus network. The department is large enough to operate its own 43 instances of all the conventional university services including (for 44 example) web, DNS, email, filestore, interactive logins, and remote 45 and wireless access. The scenario is a dual-stack one, i.e. 46 transition to IPv6 means deploying IPv6 in the first instance (and 47 probably for some time) alongside IPv4. This analysis identifies the 48 available components for IPv6 transition, while validating the 49 applicability of the IPv6 Enterprise Network Scenarios informational 50 text. It focuses on the network elements of the transition, rather 51 than the application elements. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.1. Site Philosophy . . . . . . . . . . . . . . . . . . . . . 4 57 2. Discussion of Scenarios Network Infrastructure Components . . 5 58 2.1. Component 1: Enterprise Provider Requirements . . . . . . 5 59 2.2. Component 2: Enterprise Application Requirements . . . . . 6 60 2.3. Component 3: Enterprise IT Department Requirements . . . . 7 61 2.4. Component 4: Enterprise Network Management System . . . . 8 62 2.5. Component 5: Enterprise Network Interoperation and 63 Coexistence . . . . . . . . . . . . . . . . . . . . . . . 9 64 3. Discussion of Network Infrastructure Component Requirements . 10 65 3.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.3. Configuration of Hosts . . . . . . . . . . . . . . . . . . 10 68 3.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.5. Applications . . . . . . . . . . . . . . . . . . . . . . . 10 70 3.6. Network Management . . . . . . . . . . . . . . . . . . . . 11 71 3.7. Address Planning . . . . . . . . . . . . . . . . . . . . . 11 72 3.8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 11 73 3.9. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 11 74 4. Specific Scenario Component Review . . . . . . . . . . . . . . 12 75 4.1. Network Components . . . . . . . . . . . . . . . . . . . . 12 76 4.1.1. Physical connectivity (Layer 2) . . . . . . . . . . . 12 77 4.1.2. Routing and Logical subnets (Layer 3) . . . . . . . . 12 78 4.1.3. Firewall . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.1.4. Intrusion Detection System . . . . . . . . . . . . . . 12 80 4.1.5. Management . . . . . . . . . . . . . . . . . . . . . . 12 81 4.1.6. Monitoring . . . . . . . . . . . . . . . . . . . . . . 12 82 4.1.7. Remote access . . . . . . . . . . . . . . . . . . . . 13 83 4.1.8. IPv6 External Access . . . . . . . . . . . . . . . . . 13 84 4.2. Address Allocation Components . . . . . . . . . . . . . . 13 85 4.2.1. IPv6 network prefix allocation . . . . . . . . . . . . 13 86 4.2.2. IPv6 Address allocation . . . . . . . . . . . . . . . 14 87 4.3. Services . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 4.3.1. Email . . . . . . . . . . . . . . . . . . . . . . . . 14 89 4.3.2. Web Hosting . . . . . . . . . . . . . . . . . . . . . 14 90 4.3.3. Databases . . . . . . . . . . . . . . . . . . . . . . 14 91 4.3.4. Directory Services . . . . . . . . . . . . . . . . . . 15 92 4.3.5. DNS . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 4.3.6. PKI . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 4.3.7. NTP . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 4.3.8. Multicast . . . . . . . . . . . . . . . . . . . . . . 15 96 4.3.9. Remote login . . . . . . . . . . . . . . . . . . . . . 15 97 4.3.10. File serving . . . . . . . . . . . . . . . . . . . . . 15 98 4.3.11. Backups . . . . . . . . . . . . . . . . . . . . . . . 16 99 4.4. Host and Device Platforms . . . . . . . . . . . . . . . . 16 100 4.4.1. Server platforms . . . . . . . . . . . . . . . . . . . 16 101 4.4.2. Desktop/laptop platforms . . . . . . . . . . . . . . . 16 102 4.4.3. PDA platforms . . . . . . . . . . . . . . . . . . . . 16 103 4.5. User Tools . . . . . . . . . . . . . . . . . . . . . . . . 17 104 4.5.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . 17 105 4.5.2. Mail Client . . . . . . . . . . . . . . . . . . . . . 17 106 4.5.3. Web Browser . . . . . . . . . . . . . . . . . . . . . 17 107 4.5.4. Conferencing systems . . . . . . . . . . . . . . . . . 17 108 4.5.5. Other collaboration tools . . . . . . . . . . . . . . 18 109 4.5.6. Usenet news client . . . . . . . . . . . . . . . . . . 18 110 4.5.7. Host communications . . . . . . . . . . . . . . . . . 18 111 4.6. Hard-coded address points . . . . . . . . . . . . . . . . 18 112 5. Analysis: Deployment Procedure . . . . . . . . . . . . . . . . 19 113 5.1. Advanced Planning . . . . . . . . . . . . . . . . . . . . 20 114 5.2. Testbed/Trial Deployment . . . . . . . . . . . . . . . . . 20 115 5.3. Production Deployment . . . . . . . . . . . . . . . . . . 21 116 6. Analysis: Dual-Stack Deployment - Transition toolbox . . . . . 22 117 7. Analysis: Considerations beyond the Scenarios Document . . . . 24 118 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 119 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 120 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 121 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 122 12. Informative References . . . . . . . . . . . . . . . . . . . . 25 123 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 124 Intellectual Property and Copyright Statements . . . . . . . . . . 29 126 1. Introduction 128 The scope of the enterprise network transition scenarios is very 129 large, much more so than that of the other three IPv6 transition 130 areas that have been studied within the IETF (ISP [9], unmanaged [7] 131 and 3GPP [14]). The IPv6 Enterprise Network Scenarios [11] have been 132 defined. In this document we present a specific case study area for 133 IPv6 transition, namely a large department (1,500 staff and students, 134 over 1,000 hosts) in an academic campus network. The purpose of this 135 document is to both define and analyse the IPv6 transition of such a 136 network, but also to test and validate the applicability of the IPv6 137 Enterprise Network Scenarios document to a specific example. 139 This document describes the transition at a campus, focusing on the 140 network elements. A separate document discusses ongoing issues with 141 campus transition, which are heavily related to the application 142 support and network management capability. 144 Our campus study falls under "Scenario 1" of the IPv6 Enterprise 145 Network Scenarios [11] document, i.e. the campus network is an 146 existing IPv4 network, where IPv6 is to be deployed in conjunction 147 with the IPv4 network. 149 "Scenario 1" has the assumption that the IPv4 network infrastructure 150 used has an equivalent capability in IPv6. This document analyses 151 that assumption. The Scenario also has requirements, i.e. that the 152 existing IPv4 network infrastructure is not disrupted, and that IPv6 153 should be equivalent or better than the network infrastructure in 154 IPv4. The Scenario also notes that it may also not be feasible to 155 deploy IPv6 on all parts of the network immediately. 157 These assumptions and requirements will be discussed later in this 158 text. 160 It should also be noted why Scenarios 2 and 3 did not apply to this 161 campus transition scenario. Scenario 2 talks of specific 162 applications, but in the campus case we wish to deploy IPv6 163 pervasively, in wired and wireless networks, as an enabler for 164 education and research, to encourage new application development. 165 Scenario 3 focuses on using IPv6 as the basis for most network 166 communication, but in the campus we already have a significant IPv4 167 deployment that will be utilised for the foreseeable future (Scenario 168 3 would perhaps be more appropriate for a greenfield deployment). 170 1.1. Site Philosophy 172 The site which is the subject of this study is a large departmental 173 network on a campus. That network (prior to transition) is an IPv4 174 network with around 20 subnets, using a core network infrastructure 175 that combines switch-router functionality in central devices, with 176 switches at the network edge. The main switching equipment is all 177 VLAN capable. There are around 1,000 networked nodes and 1,500 178 users, not including transient wireless visitors. 180 The site wishes to deploy IPv6 dual-stack to support its own users 181 along with its teaching and research needs. The goal is to IPv6 182 enable the network (on the wire) and services (DNS, SMTP, etc) such 183 that the whole operation is dual-stack. This in due course would 184 allow IPv6-only devices to be deployed within the fully IPv6-capable 185 environment. Some network links may become IPv6-only in the future. 187 This text has evolved over time. When we began writing, the 188 department did not have IPv6 capability on its existing IPv4 routing 189 equipment, thus a deployment method was required until the next 190 procurement. We discuss that interim solution within this document, 191 and present the discussion from an initial point of an interim 192 parallel IPv6 deployment prior to unifying the IPv4 and IPv6 routing 193 on a single platform. Our initial deployment plan used a separate 194 IPv6 path into the department with a parallel routing infrastructure 195 for IPv6. In practice this meant that our initial deployment used a 196 parallel IPv6 routing infrastructure, using BSD routers, for over 197 three years, prior to a unified solution on a commercial platform. 199 2. Discussion of Scenarios Network Infrastructure Components 201 In this section, we look at the issues raised by following the 202 Scenarios Network Infrastructure Components of the IPv6 Enterprise 203 Network Scenarios [11] document, section 3.2. This section is 204 written from the perspective of pre-transition planning, although we 205 are writing the document having undergone transition. 207 2.1. Component 1: Enterprise Provider Requirements 209 The answers to the questions posed in this section of the IPv6 210 Enterprise Network Scenarios document are as follows: 212 o There is external access to/from the campus network, regional MAN 213 and National Research Network beyond. 215 o There are needs for access by remote staff, student and 216 researchers. 218 o It is a single site, with four buildings. 220 o There are no leased lines or wide-area VPNs between remote 221 buildings. 223 o The department has 12 IPv4 Class C's, the campus has a Class B, 224 independent from its provider (assigned prior to use of CIDR). 226 o The IPv4 and IPv6 provider is the National Research and Education 227 Network (JANET in the UK). JANET provides a /48 IPv6 site prefix 228 for the university. The university offers a /52 prefix for the 229 department. 231 o The university and department make their own prefix allocations 232 for subnets. 234 o There is no multihoming, and thus no multihomed clients. 236 o The provider (JANET) offers an IPv6 Tunnel Broker [3] service and 237 a 6to4 [4] relay, though the campus has native IPv6 connectivity 238 via its regional MAN. 240 o There is no external IPv6 routing protocol needed due to the use 241 of static route configuration between the campus and the regional 242 network. 244 o There is no external data centre. 246 o IPv6 will run over the same access links to campus as IPv4 does 247 (the JANET backbone uses true dual stack, the regional MAN uses 248 6PE [19]). On campus, the IPv4 traffic to the department is 249 received through a Nokia IP740 firewall, the IPv6 traffic will 250 initially be received through a BSD firewall. Thus the access 251 links into the department for IPv4 and IPv6 are different, though 252 the goal in the longer term is to make them the same. (This 253 happened in 2006 when a new Checkpoint firewall was deployed.) 255 2.2. Component 2: Enterprise Application Requirements 257 Answers to the next IPv6 Enterprise Network Scenarios section are as 258 follows: 260 o The application inventory is discussed in the specific component 261 review in the next section. 263 o We expect the first applications to be moved will be the support 264 services, including DNS. The first applications should be the 265 common IPv4 applications, e.g. web, remote login and email, such 266 that IPv6 offers as least an equivalent service to IPv4 for the 267 core service applications. 269 o The academic environment has a good mix of open source and 270 commercial software, predominantly either Microsoft or Linux, but 271 with a growing number of Mac OS/X users. Specific platforms are 272 reviewed in the component review in the next main section. Most 273 open source applications have been upgraded to allow IPv6 274 operation; others can be upgraded given time. 276 o The general goal is for applications to support both IPv4 or IPv6 277 operation, i.e. to be IP agnostic. 279 o There is no use of NAT in the department's network. Home users, 280 or users access into the network remotely from certain locations, 281 may experience NAT at their client side. 283 o NAT issues are relevant from the end-to-end perspective, for 284 establishment of end-to-end security where desired, and in 285 relation to IPv6 transition (remote access) methods that may be 286 run through NATs. 288 o There is a mix of internal and external applications. Where 289 limitations occur, it is mainly by policy not technology, e.g. as 290 implemented in firewall restrictions. 292 2.3. Component 3: Enterprise IT Department Requirements 294 Here we list responses to the next IPv6 Enterprise Network Scenarios 295 section on IT Department Requirements. Again, in this section we 296 write our comments from a pre-transition perspective. 298 o Ownership and support is all in-house. 300 o Remote VPNs are supported. 302 o No inter-site networking is required. 304 o No IP mobility support is required at this point, though we expect 305 to use Mobile IPv6 between the department network and a local 306 community wireless network, on our wireless LAN deployment as it 307 grows in size, and to pilot its use inter-campus. 309 o The IPv6 address plan for the department requires a /52 prefix. 311 o There is no detailed asset database, though one exists providing a 312 host inventory (for DNS and DHCP use). 314 o There are no geographically separate sites. 316 o The internal IPv4 address assignment mechanism is DHCP for 317 clients, with manual configuration for servers. We thus expect to 318 use DHCPv6 for at least some, if not all, IPv6 clients. This will 319 depend on availability of DHCP client and server software. 321 o Internal IPv4 routing is static or uses RIP. We thus expect to 322 use RIPng internally. 324 o We expect our IPv6 network management policy to be very similar to 325 that for IPv4. Having coherent policies should make network 326 operation simpler. 328 o There is no QoS provision at present, largely due to the ample 329 campus bandwidth (1Gbit/s uplink). 331 o Security is applied through many technologies implementing our 332 policies, e.g. firewall, email scanning, wireless LAN access 333 controls. We expect similar policies for IPv6, but need to 334 analyse differences. 336 o Training will be done in-house. 338 o The impacted software components are discussed in the next main 339 section. Not all functions are upgradeable to IPv6; those that 340 are not are discussed in the analysis section. Some are, e.g. use 341 of OpenLDAP (IPv6 capable) as an interim step in place of MS 342 Active Directory (not IPv6 capable at the time of the analysis). 343 Our view is that if components cannot be given immediate IPv6 344 equivalents, this functionality will come in due course, and IPv4 345 transport can be used in the interim. But the goal is to 346 facilitate IPv6 capability. 348 o The impacted hardware components are discussed in the next main 349 section. Not all hardware is upgradeable, e.g. network printers. 350 There are no load balancing systems in use. There are wireless 351 LAN hosts in the network that are mobile, but currently the 352 wireless network is a single flat IPv4 subnet. There may be nodes 353 moving to external wireless networks (i.e. the local community 354 wireless network). 356 2.4. Component 4: Enterprise Network Management System 358 The responses to the next IPv6 Enterprise Network Scenarios section 359 are as follows: 361 o No performance management is required. 363 o There are a number of network management and monitoring tools in 364 use, which will need to be used in a dual stack or IPv6 mode, e.g. 365 the nocol availability monitoring tools, and SNMP-based 366 management. 368 o The configuration management may include use of tools to configure 369 services including DNS and email. 371 o No policy management and enforcement tools are required. 373 o No detailed security management is required, though we expect to 374 manage the implementations including firewalls and intrusion 375 detection. 377 o We may need to manage the deployed transition tools and 378 mechanisms. 380 o We need to analyse the considerations IPv6 creates for network 381 management, e.g. use (or not) of RFC3041 privacy addresses. The 382 need for user privacy is recognised, but the need for simplified 383 management is also a strong consideration. 385 2.5. Component 5: Enterprise Network Interoperation and Coexistence 387 Answers to the final IPv6 Enterprise Network Scenarios section on 388 Coexistence are as follows: 390 o The platforms that are required to be IPv6 capable are listed in 391 the next main section. 393 o There is only one network ingress and egress point to the site 394 that needs to be IPv6 capable; this is a Gigabit Ethernet 395 interface. 397 o The required transition mechanisms are discussed in the analysis 398 section. We expect to mainly use the VLAN [17] mechanism for 399 internal IPv6 transport, with a parallel IPv6 routing 400 infrastructure based on BSD routers, until the core infrastructure 401 is able to support IPv6 (via upgrade or a new procurement). 403 o The transition to IPv6 will be enabled on the wire first, enabling 404 clients, with a phased introduction of service capability, as 405 discussed below in the analysis section. 407 o The preferred mechanism for interoperation with legacy nodes is to 408 use dual-stack and thus IPv4 to communicate to IPv4 nodes and IPv6 409 to communicate to IPv6 nodes. We have not identified any in- 410 house, non-upgradeable legacy applications. 412 3. Discussion of Network Infrastructure Component Requirements 414 In this section, we discuss the network infrastructure component 415 requirements raised in the IPv6 Enterprise Network Scenarios [11] 416 document, in section 4. 418 3.1. DNS 420 BIND9 is used for our three internal name servers. The servers will 421 be made dual stack, to be available for IPv6 transport for local 422 dual-stack or IPv6-only nodes. The three servers will each be listed 423 with AAAA records, and AAAA glue added. 425 3.2. Routing 427 Internal routing is either statically configured or uses RIP. We 428 thus expect to use RIPng for internal IPv6 routing. The external 429 routing is statically configured for IPv4, and thus is likely to be 430 statically configured for IPv6. 432 3.3. Configuration of Hosts 434 IPv4 clients use DHCP for address and other configuration options. 435 We expect to use Dynamic Host Configuration Protocol for IPv6 436 (DHCPv6) [5] for IPv6 clients. This will require analysis of the 437 IPv4 and IPv6 Dual-Stack Issues for DHCPv6 [16]. We expect some 438 clients, especially in wireless LANs, to use IPv6 Stateless 439 Autoconfiguration [1], and these nodes will need support for 440 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6 441 [6] for other configuration options, including the IPv6 address of a 442 local DNS resolver. 444 Although IPv6 offers Stateless Autoconfiguration, it is expected that 445 the managed environment will continue, driven from the asset 446 database, for some time. Thus DHCPv6 is required. Use of Stateless 447 Autoconfiguration implies a requirement for dynamic DNS updates for 448 such nodes. It is not yet decided how to apply or enforce that plan; 449 it may certainly be flexible with time. 451 3.4. Security 453 We need to identify new IPv6 related security considerations, and 454 those associated with transition mechanisms [20]. Site policies may 455 need to be updated as a result. 457 3.5. Applications 459 The Application Aspects of IPv6 Transition [10] document describes 460 best porting practice for applications. There should also be 461 consideration for any required application proxies. 463 3.6. Network Management 465 The network management and monitoring systems will need to embrace 466 IPv6, and any transition mechanisms used to deploy IPv6. Monitoring 467 includes usage tracking (e.g. via MRTG) and availability monitoring 468 (e.g. via Nagios). 470 3.7. Address Planning 472 The department receives 12 Class C prefixes for IPv4 use, and uses 473 only globally routable addresses internally. The IPv4 address space 474 for the campus was obtained prior to CIDR, but the IPv6 address space 475 is allocated from the UK National Research Network (JANET) address 476 space under 2001:0630::/32. The university receives a /48 prefix, 477 which is 2001:0630:d0::/48. The department has a /52 allocation 478 within this block of 2001:0630:d0:0:/52. 480 IPv6 address assignment planning is discussed in the IPv6 Unicast 481 Address Assignment Considerations [18] text. 483 3.8. Multicast 485 IPv4 multicast is used for a number of applications, including the 486 AccessGrid. Connectivity is provided via the local campus and 487 regional network. We expect to use both IPv6 ASM (i.e. PIM-SM), and 488 we plan to make use of the Embedded-RP [8] technique. For bridging 489 between IPv4 and IPv6 multicast, we believe an IPv4 - IPv6 multicast 490 gateway [21] may prove valuable. Finally, we expect to make use of 491 source specific multicast (SSM) more heavily in IPv6, bringing IPv6 492 and SSM together in one deployment cycle. 494 The use of IPv6 multicast makes it much simpler for our site to 495 generate its own globally unique group addresses than is the case for 496 IPv4, where we need to use GLOP space from an upstream provider. For 497 IPv6, you can generate your own unique group address for regular or 498 Embedded-RP groups based on your unicast prefix (typically /48 or 499 /64). We expect to use Embedded-RP where possible, running our own 500 IPv6 RP to support our own content. 502 3.9. Multihoming 504 The site is not multihomed for IPv4, and thus will not be for IPv6. 505 This is typical for UK academic networks, but may change in due 506 course as resilience concerns rise. 508 4. Specific Scenario Component Review 510 Here we describe specific technology in use now in the department. 511 Later in this section we discuss any items not included in the above 512 section, i.e. those not explicitly mentioned in the IPv6 Enterprise 513 Network Scenarios document. Note that not all applications and 514 services have at the time of writing been made IPv6 capable. A gap 515 analysis is the subject of a separate ongoing 'live' document. This 516 text aims to be a stable description of the processes and thinking 517 followed during our campus transition. 519 4.1. Network Components 521 4.1.1. Physical connectivity (Layer 2) 523 o Switched Ethernet 525 o Gigabit Ethernet 527 o Wireless networking (802.11b) 529 4.1.2. Routing and Logical subnets (Layer 3) 531 The hybrid Layer 2/3 routing equipment has approximately 20 internal 532 IPv4 subnets (in effect, routed VLANs). There is no specific 533 internal routing protocol used. There is a static route via the site 534 firewall to the main upstream provider (academic) running at 1Gbit/s. 536 4.1.3. Firewall 538 The firewall is currently Firewall-1 running on a Nokia IP740 539 hardware platform. There is one internal facing interface, one 540 external facing interface, and two DMZ interfaces, one for wired 541 hosts and one for the Wireless LAN provision. 543 4.1.4. Intrusion Detection System 545 Snort is used locally for IPv4 IDS. 547 4.1.5. Management 549 Some network management is performed by SNMP; there is no specific 550 package for this. There is a greater emphasis on monitoring than 551 explicitly in management. 553 4.1.6. Monitoring 555 A number of tools are used, to monitor network usage as well as 556 systems availability, e.g. Nagios and MRTG. The network testing 557 tools include iperf, rude and crude. 559 4.1.7. Remote access 561 o Livingston Portmaster 56K/ISDN dialup (being phased out) 563 o RADIUS servers (running Radiator) 565 o (Microsoft) VPN servers 567 4.1.8. IPv6 External Access 569 o IPv6 connectivity will come via our regional network (which runs 570 6PE) through trunked (unrouted) VLANs across campus to our 571 departmental network. Because the existing IP firewall pre- 572 transition does not support IPv6, IPv6 will need to be transported 573 into the departmental network via a separate parallel IPv6 capable 574 firewall (e.g. a BSD system using pf). 576 4.2. Address Allocation Components 578 The department receives its IPv4 and IPv6 address allocations from 579 the University. For IPv4, the University has a Class B allocation 580 which is not aggregated under the JANET NREN. For IPv6, the 581 University receives its allocation from JANET. 583 4.2.1. IPv6 network prefix allocation 585 For IPv6, JANET has the prefix 2001:630::/32 from RIPE-NCC, as the 586 national academic ISP in the UK. The University has been allocated 587 2001:630:d0::/48 by JANET. The department transitioning will be 588 allocated a /52 size prefix under 2001:630:d0::/48, i.e. 2001:630:d0: 589 0::/52. 591 In the initial deployment, we expect that IPv4 and IPv6 subnets will 592 be congruent (and share the same VLANs). This is because the 593 existing subnet divisions are made for geographic or administrative 594 reasons that are not IP version dependent (e.g. by building location 595 or research group membership). 597 One advantage for IPv6 is that subnets will not need to be resized to 598 conserve or efficiently utilise address space as is the case 599 currently for IPv4 (as subnet host counts rise and fall for 600 administrative or research group growth/decline reasons). 602 4.2.2. IPv6 Address allocation 604 It is expected that the network devices will use a combination of 605 address allocation mechanisms: 607 o Manually configured addresses (in some servers) 609 o Stateful DHCPv6 (probably in fixed, wired devices and some 610 servers) 612 o Stateless address autoconfiguration (probably in wireless and 613 mobile devices) 615 o RFC3041 privacy addresses (in some client devices) 617 For devices using stateless or RFC3041 mechanisms, a Stateless DHCPv6 618 server will be required for other (non-address) configuration 619 options, e.g. DNS and NTP servers. 621 4.3. Services 623 4.3.1. Email 625 There are three MX hosts for inbound email, and two main internal 626 mail servers. Sendmail is the MTA. POP and IMAP (and their secure 627 versions) are used for mail access, using the Cyrus IMAP open source 628 code. There is an MS Exchange server used by a growing proportion of 629 users (generally those wanting shared access to mail spools, e.g. 630 professors and secretaries). MailScanner is used for anti-spam/ 631 anti-virus. This uses external services including various RBLs for 632 part of its spam checking. Successful reverse DNS lookup is required 633 for sendmail to accept internal SMTP connections for delivery. 635 4.3.2. Web Hosting 637 Web content hosting is provided either with Apache 2.x (open source) 638 or Microsoft IIS 5.0. Common components used to build systems with 639 are MySQL, PHP and Perl; these enable local tools such as Wikis to be 640 run. 642 4.3.3. Databases 644 All database systems are presented to users via a web interface, 645 including the financial systems. In some cases, e.g. student 646 records, ODBC-like access is required/used in to/out from the 647 department systems to the campus systems. Databases include: finance 648 records, people, projects and publications (offered using ePrints). 650 4.3.4. Directory Services 652 The following are used: 654 o NIS 656 o LDAP 658 o Active Directory 660 o RADIUS 662 4.3.5. DNS 664 The three DNS servers are running BIND9. A DNS secondary is held at 665 another UK university site. 667 4.3.6. PKI 669 The department has at least 10 SSL certificates from Thawte, 670 including Web-signing certificates. No personal certificates are 671 supported by the department (though users may have their own). 673 4.3.7. NTP 675 The JANET NREN offers a stratum 0 NTP server. The department also 676 has a GPS-based NTP server built-in to its own RIPE NCC test traffic 677 server and an NTP device from Meinberg. 679 4.3.8. Multicast 681 PIM-SM IPv4 multicast is facilitated via a dedicated Cisco 7206 682 router, using a Rendezvous Point operated by our regional network. 683 This supports applications including the IPv4 AccessGrid conferencing 684 system. A number of bugs in the existing IPv4 routing equipment 685 prevent heavy use of IPv4 Multicast within the department network 686 (another reason that an IPv6 Multicast solution is desirable). An 687 IPv4 Multicast beacon is used for monitoring Multicast. 689 4.3.9. Remote login 691 Remote login access is offered via ssh, with sftp for file transfer. 692 Remote use of insecure protocols such as telnet and ftp is denied by 693 the firewall. 695 4.3.10. File serving 697 The main file servers are SGI systems, hosting large (multi-TB) 698 standalone RAID arrays. The files are offered via NFS and Samba to 699 client systems. Our content (package) distribution server is hosted 700 on such a system. 702 4.3.11. Backups 704 Backups are run over SSH, which is IPv6-enabled. A site using a 705 proprietary remote backup solution may not yet have IPv6 capability. 707 4.4. Host and Device Platforms 709 4.4.1. Server platforms 711 These include: 713 o Windows 2003 server 715 o Windows 2000 server 717 o Windows NT 719 o Solaris 8 721 o Solaris 9 723 o Solaris 10 725 o RedHat Linux 727 o SGI Origin 300 (Irix 6.5.x) 729 4.4.2. Desktop/laptop platforms 731 These include: 733 o Windows 98, 2000, ME, XP 735 o Linux (various flavours) 737 o MacOS/X 739 o BSD (various flavours) 741 4.4.3. PDA platforms 743 These include: 745 o Windows CE/.NET, Pocket PC 747 o PalmOS 749 o Familiar Linux on iPaQ 751 o Zaurus (Linux) 753 4.5. User Tools 755 These are non-exhaustive but representative application/platform 756 lists 758 4.5.1. Hardware 760 o Networked printers 762 o Networked webcams 764 4.5.2. Mail Client 766 o Outlook (various versions) 768 o Eudora 770 o Mutt 772 o Pine 774 4.5.3. Web Browser 776 o MS Internet Explorer 778 o Mozilla 780 o Firefox 782 o Safari 784 o Opera 786 4.5.4. Conferencing systems 788 o AccessGrid 790 o A dedicated H.323 system 791 o MS Netmeeting 793 4.5.5. Other collaboration tools 795 o IRC 797 o Jabber 799 o MSN Messenger 801 o cvs 803 4.5.6. Usenet news client 805 o nn 807 o Mozilla 809 4.5.7. Host communications 811 o X11 813 o VNC 815 o PC Anywhere 817 4.6. Hard-coded address points 819 Usage of IPv4 hard-coded addresses is interesting for at least two 820 reasons. One is that it illustrates where IPv6 hard-coded addresses 821 may appear, and thus secondly it is useful to analyse which hard- 822 coded addresses may be barriers to smooth IPv6 renumbering. A 823 procedure for renumbering has been described in Procedures for 824 Renumbering an IPv6 Network without a Flag Day [12]. A non- 825 exhaustive list of instances of such addresses includes: 827 o Provider based prefix(es) 829 o Names resolved to IP addresses in firewall at startup time 831 o IP addresses in remote firewalls allowing access to remote 832 services 834 o IP-based authentication in remote systems allowing access to 835 online bibliographic resources 837 o IP address of both tunnel end points for IPv6 in IPv4 tunnel 838 o Hard-coded IP subnet configuration information 840 o IP addresses for static route targets 842 o Blocked SMTP server IP list (spam sources) 844 o Web .htaccess and remote access controls 846 o Apache .Listen. directive on given IP address 848 o Configured multicast rendezvous point 850 o TCP wrapper files 852 o Samba configuration files 854 o DNS resolv.conf on Unix 856 o Nocol monitoring tool 858 o NIS/ypbind via the hosts file 860 o Some interface configurations 862 o Unix portmap security masks 864 o NIS security masks 866 The author is contributing to work in studying things to think about 867 in IPv6 renumbering [22], where the above issues will be considered. 869 5. Analysis: Deployment Procedure 871 In this section we document (retrospectively) the procedure we went 872 through in deploying IPv6 within our campus site. 874 The work described in this document has also been fed into the IPv6 875 Enterprise Analysis [23]. The reader is referred in particular to 876 Section 4 ("Wide-Scale Dual-Stack Deployment") and Section 7 877 ("General issues and applicability for all Scenarios") which were 878 directly contributed from the work here. 880 As described in the IPv6 Enterprise Analysis [23] document, the 881 scenario here is one of wide-scale dual-stack deployment. The plan 882 for deployment follows the general guidelines of Section 7 of that 883 document, though we have expanded that description here from 884 subsequent experience. 886 Note that our analysis does not include issues relating to deployment 887 of new IPv6-specific technology, e.g. MIPv6. 889 5.1. Advanced Planning 891 A first phase for deployment includes the following actions. 893 o Include IPv6 requirements in all future tenders. Consult to 894 understand IPv6 specification requirements for tenders; this may 895 prove particularly valuable where new IPv6 specific technology is 896 desirable, e.g. Embedded-RP support for Multicast. 898 o Identify your IPv6 ISP. This will most likely be your IPv4 ISP 899 also, but in some cases it may not be. 901 o Speak to your IPv6 ISP to acquire IPv6 address space (a /48 902 prefix) for your site; you will need this at some point, so may as 903 well acquire the space sooner rather than later. This will 904 include delegation of IPv6 forward and reverse DNS for your site. 905 Our campus address space is a /48 prefix allocated by JANET, under 906 their prefix of 2001:630::/32. 908 o Establish IPv6 training for operational staff, for administration 909 of host and router platforms. 911 o Investigate how to deploy basic IPv6 network services: DNS, 912 routing, host configuration. 914 o Encourage operational staff to get some IPv6 familiarity by trying 915 IPv6 through services such as a public or ISP-supported IPv6 916 tunnel broker [3]. 918 o Review IPv6 security issues. IPv6 is enabled by default on many 919 host platforms; this should be considered when enforcing security 920 policies on systems and networks. 922 Following these action points should allow sites or networks to be 923 ready for a trial or pilot IPv6 deployment, and to have confidence 924 they understand and have control of their current - perhaps unwitting 925 - usage of IPv6 (from systems which have it enabled by default). 927 5.2. Testbed/Trial Deployment 929 In this stage a site is validating IPv6 for deployment, and will thus 930 take actions including the following: 932 o Assign and deploy an IPv6-capable router and (we recommend) a 933 firewall or filtering device. 935 o Establish IPv6 connectivity to the IPv6 ISP. Sites might use a 936 tunnelled service, or check for any native IPv6 offering. In our 937 case, the connectivity is native IPv6 from JANET, via the regional 938 MAN (using 6PE [19]) and the campus (using a VLAN to carry IPv6 939 natively). 941 o Connect testbed host systems on the internal router interface, 942 using one subnet prefix (a /64) from the site's allocated IPv6 /48 943 prefix. At this stage your trial network may be standalone 944 (disconnected from other internal networks) or, as we did, it may 945 be that you dual-stack your existing IPv4 DMZ(s) for the pilot 946 phase. 948 o Enable IPv6 on the host systems, and test IPv6 functions on 949 services and applications (e.g. BIND for DNS, Apache for Web, 950 sendmail or exim for mail transport). 952 In parallel, other preparation can be undertaken for a production 953 deployment: 955 o Survey systems, applications and services for IPv6 capability, 956 including management, monitoring and access control devices and 957 systems. The Enterprise Scenarios text as evaluated earlier in 958 this document is a good basis to undertake this task from. 960 o Formulate an IPv6 address plan for your site/network. Our campus 961 has allocated the department network a /56 prefix that can grow 962 into a /52 prefix, i.e. the department can create in theory up to 963 256 IPv6 subnets initially. We discuss address planning issues in 964 a separate document on IPv6 addressing considerations [18]. 966 o Discuss and document IPv6-related policies (e.g. use of Privacy 967 Addresses, and of stateless or stateful address assignment). 969 Once the site is satisfied in the testbed deployment, then a 970 production deployment can be considered, enabling IPv6 for 971 appropriate links and services. 973 5.3. Production Deployment 975 A production deployment includes the following action points: 977 o Plan which parts of the network will be IPv6-enabled, and which 978 existing subnets will be IPv6-enabled (made dual-stack). This may 979 be certain server subnets, a DMZ, or a Wireless LAN network, for 980 example. 982 o Determine how your production IPv6 connectivity will be handled; 983 it can (ideally) be via a single dual-stack entry point, or 984 through separate IPv4 and IPv6 links. 986 o Enable IPv6, and IPv6 routing, such that IPv6 is on the wire, 987 prior to host system activation. Ensure filtering and firewall 988 policies are implemented as required. 990 o Add IPv6 address configuration to your DNS systems, and configure 991 them to respond over IPv4 or IPv6 transport. 993 o Deploy IPv6 support in appropriate management and monitoring 994 tools. 996 o Enable IPv6 in selected production services and applications (e.g. 997 Apache or IIS for web servers). In our case, we focused initially 998 on DNS (bind), mail/MX (sendmail) and web services (Apache) in 999 dual-stack mode. 1001 o Include IPv6 transport in all ongoing security audit/penetration 1002 tests. 1004 o Support IPv4-IPv6 interworking. As there are not (yet) any IPv6- 1005 only links on our site, interworking methods are not required. 1006 Should IPv6-only devices be deployed on the dual-stack 1007 infrastructure, we anticipate using proxy tools (web cache, SMTP 1008 relay, etc) to support their access to legacy IPv4 services, 1009 rather than deploying translation-based tools. 1011 o Supporting remote users. These may connect via an IPv4 VPN and 1012 then use an IPv6 connection over that VPN, or use the remote IPv6 1013 services of your ISP (e.g. our ISP, JANET, runs a tunnel broker 1014 and a 6to4 relay). 1016 The depth of the IPv6 deployment may vary from site to site. By 1017 enabling key services you make your site ready for a fuller 1018 deployment, and gain confidence and experience in the technology, 1019 which is good for your support staff, your students and staff and 1020 researchers. 1022 6. Analysis: Dual-Stack Deployment - Transition toolbox 1024 Within our network we initially deployed IPv6 in parallel to IPv4, 1025 using a VLAN-based method as cited below. This allowed us to pilot 1026 IPv6 without risking adverse impact on our existing IPv4 platforms. 1027 This method was used for over two years. Towards the end of its use, 1028 the BSD platforms used to facilitate this were showing signs of 1029 strain under the load, in terms of pure unicast and multicast 1030 forwarding strain under heavier traffic bursts. We have since 1031 deployed a unified IPv4 and IPv6 routing platform from a single 1032 vendor, which met all our IPv4 and IPv6 procurement requirements for 1033 IPv4 and IPv6 unicast and multicast functions, including but not 1034 limited to: 1036 o IPv6 unicast routing protocols; 1038 o IPv6 multicast routing protocols (PIM-SM, SSM); 1040 o IPv6 multicast Embedded-RP support; 1042 o IPv6 multicast MLD(v1 and v2) snooping. 1044 We have used the following mechanisms in our department's transition 1045 process: 1047 o VLANs [17] to distribute IPv6 connectivity over the non-dual-stack 1048 capable network infrastructure. This VLAN solution was an interim 1049 step until full dual protocol capable equipment was deployed 1050 during 2005; 1052 o A Tunnel broker [3] for remote access, provided by our IPv6 ISP 1053 (JANET). We initially deployed our own tunnel broker, but now 1054 refer our home and roaming users to the JANET solution; 1056 o A 6to4 [4] relay for remote access, provided by our IPv6 ISP. 1057 Again, we used to run our own relay, but the relay operated by our 1058 IPv6 ISP is perfectly adequate at this time for communicating with 1059 6to4 sites. We do not believe 6to4 is an acceptable solution as a 1060 campus connectivity method (because we do not then use our own 1061 IPv6 address space as allocated by JANET, and 6to4 itself is prone 1062 to failure and abuse). 1064 We do NOT currently see a requirement for: 1066 o NAT-PT [2], because we are dual-stack with no IPv6-only networks 1067 (yet), and as we introduce such networks, or IPv6-only nodes in 1068 the dual-stack networks, we expect to use application layer 1069 gateways and proxies for legacy IPv4 access. If and when we do 1070 deploy an IPv6-only link, and ALGs are not sufficient, we would 1071 look at DSTM as a solution in preference NAT-PT; 1073 o ISATAP [13], because we prefer to use a structured internal IPv6 1074 deployment, and are doing so in a pervasive fashion (i.e. not as a 1075 sparse deployment). ISATAP may be useful for sparse deployment of 1076 IPv6 in sites who are happy to IPv6 pilot in a less structured 1077 fashion; 1079 o We considered deploying a Teredo [15] relay to support home users 1080 behind NATs, but chose not to do so since the tunnel broker 1081 service supports NAT traversal, and we feel it offers better 1082 management and monitoring facilities. This decision may be 1083 reviewed should Windows Vista ship with Teredo enabled by default. 1084 At the time of writing the status of Teredo in Vista is not 1085 finalised (Vista is not released). 1087 7. Analysis: Considerations beyond the Scenarios Document 1089 Here we mention issues or scenario components that were not 1090 explicitly listed in the IPv6 Enterprise Network Scenarios document. 1091 Due to the scope, that document could not embrace all details. We 1092 mention here components that other sites may also wish to consider: 1094 o Support for WLAN and other access control. One solution is to use 1095 802.1x which is IP-agnostic as a Layer 2 port control mechanism. 1097 o Consideration for hard-coded addresses. 1099 8. Summary 1101 In this document we have analysed the specific campus transition 1102 scenario for the author's site, and reported the analysis for the 1103 benefit of others who may be in a similar scenario, or for whom parts 1104 of the scenario are relevant. 1106 In our case transition does not mean from IPv4 only to IPv6 only, 1107 rather from IPv4 only to a dual-stack environment that could support 1108 IPv6 only nodes at a later date. We would probably best describe the 1109 process as dual stack integration. 1111 We have described how a phased approach to transition can be adopted 1112 at a campus site (or part thereof), from a planning stage through a 1113 pilot to a fuller deployment. During our transition we initially ran 1114 a parallel IPv6 routing infrastructure, then in 2005 unified the 1115 routing to a single platform, for unicast and multicast IPv6. We 1116 enabled key services for dual-stack operation from the outset (DNS, 1117 web and mail/MX) and have enabled other services as and when they 1118 have become available. The VLAN-based interim step was useful for 1119 two years until a dual-protocol solution could be procured. 1121 We do not discuss detailed availability of IPv6 capability in the 1122 services, platforms and user tools described in Section 4 above in 1123 this text. An ongoing gap analysis is being undertaken in a separate 1124 text. For the purposes of our network-oriented transition, we are 1125 happy that the path taken and current solution is stable and 1126 complete. 1128 The deployment has now been in full dual-stack operation for over a 1129 year, with key services enabled (including public-facing DNS, SMTP, 1130 web) without adverse effects on the IPv4 service. The author 1131 welcomes discussion with other sites that are undergoing or have 1132 undergone a similar transition or integration process. 1134 9. Acknowledgements 1136 Discussions with fellow participants on the 6NET and Euro6IX projects 1137 have been valuable. 1139 10. IANA Considerations 1141 The document contains no IANA considerations. 1143 11. Security Considerations 1145 There are no specific new considerations from this scenario 1146 description and analysis. 1148 12. Informative References 1150 [1] Thomson, S. and T. Narten, "IPv6 Stateless Address 1151 Autoconfiguration", RFC 2462, December 1998. 1153 [2] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - 1154 Protocol Translation (NAT-PT)", RFC 2766, February 2000. 1156 [3] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1157 Tunnel Broker", RFC 3053, January 2001. 1159 [4] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 1160 IPv4 Clouds", RFC 3056, February 2001. 1162 [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1163 Carney, "Dynamic Host Configuration Protocol for IPv6 1164 (DHCPv6)", RFC 3315, July 2003. 1166 [6] Droms, R., "Stateless Dynamic Host Configuration Protocol 1167 (DHCP) Service for IPv6", RFC 3736, April 2004. 1169 [7] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, 1170 "Evaluation of IPv6 Transition Mechanisms for Unmanaged 1171 Networks", RFC 3904, September 2004. 1173 [8] Savola, P. and B. Haberman, "Embedding the Rendezvous Point 1174 (RP) Address in an IPv6 Multicast Address", RFC 3956, 1175 November 2004. 1177 [9] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, 1178 "Scenarios and Analysis for Introducing IPv6 into ISP 1179 Networks", RFC 4029, March 2005. 1181 [10] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, 1182 "Application Aspects of IPv6 Transition", RFC 4038, March 2005. 1184 [11] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, 1185 June 2005. 1187 [12] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering 1188 an IPv6 Network without a Flag Day", RFC 4192, September 2005. 1190 [13] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 1191 Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, 1192 October 2005. 1194 [14] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation 1195 Partnership Project (3GPP) Networks", RFC 4215, October 2005. 1197 [15] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network 1198 Address Translations (NATs)", RFC 4380, February 2006. 1200 [16] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 1201 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 1202 Issues", RFC 4477, May 2006. 1204 [17] Chown, T., "Use of VLANs for IPv4-IPv6 Coexistence in 1205 Enterprise Networks", RFC 4554, June 2006. 1207 [18] Velde, G., "IPv6 Unicast Address Assignment Considerations", 1208 draft-ietf-v6ops-addcon-01 (work in progress), July 2006. 1210 [19] Clercq, J., "Connecting IPv6 Islands over IPv4 MPLS using IPv6 1211 Provider Edge Routers (6PE)", draft-ooms-v6ops-bgp-tunnel-06 1212 (work in progress), January 2006. 1214 [20] Davies, E., "IPv6 Transition/Co-existence Security 1215 Considerations", draft-ietf-v6ops-security-overview-05 (work in 1216 progress), September 2006. 1218 [21] Venaas, S., "An IPv4 - IPv6 multicast gateway", 1219 draft-venaas-mboned-v4v6mcastgw-00 (work in progress), 1220 February 2003. 1222 [22] Chown, T., "Things to think about when Renumbering an IPv6 1223 network", draft-chown-v6ops-renumber-thinkabout-05 (work in 1224 progress), September 2006. 1226 [23] Bound, J., "IPv6 Enterprise Network Analysis", 1227 draft-ietf-v6ops-ent-analysis-06 (work in progress), June 2006. 1229 Author's Address 1231 Tim Chown 1232 University of Southampton 1233 School of Electronics and Computer Science 1234 Southampton, Hampshire SO17 1BJ 1235 United Kingdom 1237 Email: tjc@ecs.soton.ac.uk 1239 Intellectual Property Statement 1241 The IETF takes no position regarding the validity or scope of any 1242 Intellectual Property Rights or other rights that might be claimed to 1243 pertain to the implementation or use of the technology described in 1244 this document or the extent to which any license under such rights 1245 might or might not be available; nor does it represent that it has 1246 made any independent effort to identify any such rights. Information 1247 on the procedures with respect to rights in RFC documents can be 1248 found in BCP 78 and BCP 79. 1250 Copies of IPR disclosures made to the IETF Secretariat and any 1251 assurances of licenses to be made available, or the result of an 1252 attempt made to obtain a general license or permission for the use of 1253 such proprietary rights by implementers or users of this 1254 specification can be obtained from the IETF on-line IPR repository at 1255 http://www.ietf.org/ipr. 1257 The IETF invites any interested party to bring to its attention any 1258 copyrights, patents or patent applications, or other proprietary 1259 rights that may cover technology that may be required to implement 1260 this standard. Please address the information to the IETF at 1261 ietf-ipr@ietf.org. 1263 Disclaimer of Validity 1265 This document and the information contained herein are provided on an 1266 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1267 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1268 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1269 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1270 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1271 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1273 Copyright Statement 1275 Copyright (C) The Internet Society (2006). This document is subject 1276 to the rights, licenses and restrictions contained in BCP 78, and 1277 except as set forth therein, the authors retain all their rights. 1279 Acknowledgment 1281 Funding for the RFC Editor function is currently provided by the 1282 Internet Society.