idnits 2.17.1 draft-ietf-v6ops-vlan-usage-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 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 471. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 484. ** 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 is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. 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 (July 11, 2005) is 6864 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 2461 (ref. '1') (Obsoleted by RFC 4861) == Outdated reference: A later version (-03) exists of draft-chown-v6ops-campus-transition-01 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 9 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: January 12, 2006 July 11, 2005 6 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks 7 draft-ietf-v6ops-vlan-usage-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 January 12, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Ethernet VLANs are quite commonly used in enterprise networks for the 41 purposes of traffic segregation. This document describes how such 42 VLANs can be readily used to deploy IPv6 networking in an enterprise, 43 which focuses on the scenario of early deployment prior to 44 availability of IPv6-capable switch-router equipment. In this method 45 IPv6 may be routed in parallel with the existing IPv4 in the 46 enterprise and delivered at Layer 2 via VLAN technology. The IPv6 47 connectivity to the enterprise may or may not enter the site via the 48 same physical link. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Enabling IPv6 per link . . . . . . . . . . . . . . . . . . . . 4 54 2.1 IPv6 routing over VLANs . . . . . . . . . . . . . . . . . 4 55 2.2 One VLAN per router interface . . . . . . . . . . . . . . 5 56 2.3 Collapsed VLANs on a single interface . . . . . . . . . . 5 57 2.4 Congruent IPv4 and IPv6 Subnets . . . . . . . . . . . . . 5 58 2.5 IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . 6 59 2.6 Final IPv6 Deployment . . . . . . . . . . . . . . . . . . 6 60 3. Example VLAN topology . . . . . . . . . . . . . . . . . . . . 7 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Informative References . . . . . . . . . . . . . . . . . . . . 9 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 66 A. Appendix: Configuration example . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . 12 69 1. Introduction 71 Ethernet VLANs are quite commonly used in enterprise networks for the 72 purposes of traffic segregation. This document describes how such 73 VLANs can be readily used to deploy IPv6 networking in an enterprise, 74 including the scenario of early deployment prior to availability of 75 IPv6-capable switch-router equipment, where IPv6 may be routed in 76 parallel with the existing IPv4 in the enterprise and delivered to 77 the desired LANs via VLAN technology. 79 It is expected that in the long run, sites migrating to dual-stack 80 networking will either upgrade existing switch-router equipment to 81 support IPv6 or procure new equipment that supports IPv6. If a site 82 already has production routers deployed that support IPv6, the 83 procedures described in this document are not required. In the 84 interim however, a method is required for early IPv6 adopters that 85 enables IPv6 to be deployed in a structured, managed way to some or 86 all of an enterprise network which currently lacks IPv6 support in 87 its core infrastructure. 89 The IEEE 802.1Q VLAN standard allows separate LANs to be deployed 90 over a single bridged LAN, by inserting "Virtual LAN" tagging or 91 membership information into Ethernet frames. Hosts and switches that 92 support VLANs effectively allow software-based reconfiguration of 93 LANs through configuration of the tagging parameters. The software 94 control means VLANs can be used to alter the LAN infrastructure 95 without having to physically alter the wiring between the LAN 96 segments and Layer 3 routers. 98 Many IPv4 enterprise networks are utilising VLAN technology. Where a 99 site does not have IPv6-capable Layer 2/3 switch-router equipment, 100 but VLANs are supported, a simple yet effective method exists to 101 gradually introduce IPv6 to some or all of that site's network, in 102 advance of the site's core infrastructure having dual-stack 103 capability. 105 If such a site wishes to introduce IPv6, it may do so by deploying a 106 parallel IPv6 routing infrastructure (which is likely to be a 107 different platform to the site's main infrastructure equipment, i.e. 108 one that supports IPv6 where the existing equipment does not), and 109 then using VLAN technology to "overlay" IPv6 links onto existing IPv4 110 links. This can be achieved without needing any changes to the IPv4 111 configuration. The VLANs don't need to differentiate between IPv4 112 and IPv6; the deployment is just dual stack, as Ethernet is without 113 VLANs. 115 The IPv4 default route to the VLAN is provided by one (IPv4) router, 116 while the IPv6 default route to the VLAN is provided a different 117 (IPv6) router. The IPv6 router can provide native IPv6 connectivity 118 to the whole site with just a single physical interface, thanks to 119 VLAN tagging and trunking, as described below. 121 The IPv6 connectivity to the enterprise may or may not enter the site 122 via the same physical link as the IPv4 traffic, and may be native or 123 tunneled from the external provider to the IPv6 routing equipment. 125 This VLAN usage is a solution adopted by a number of sites already, 126 and is referenced in our Campus Network IPv6 Transition [2] text. 128 It should be noted that a parallel infrastructure will require 129 additional infrastructure and thus cost, and will often require a 130 separate link into the site (from an IPv6 provider), quite possibly 131 tunneled, that will require the site's security policy to be applied 132 (e.g. firewalling, and intrusion detection). For sites who believe 133 early adoption of IPv6 is important, that price is one they may be 134 quite willing to pay. However, this document focuses on the 135 technical issues of VLAN usage in such a scenario. 137 2. Enabling IPv6 per link 139 The precise method by which IPv6 would be "injected" into the 140 existing IPv4 network is deployment specific. For example, perhaps a 141 site has an IPv4-only router, connected to an Ethernet switch that 142 supports VLANs, and a number of hosts connected to that VLAN. Let's 143 further assume the site has a dozen of these setups which it wishes 144 to IPv6-enable immediately. This could be done by upgrading the 145 twelve routers to support IPv6, and turning IPv6 on on those routers. 146 However, this may not be practical for various reasons. 148 The simplest approach would be to connect an IPv6 router with one 149 interface to an ethernet switch, and connect that switch to other 150 switches, and then use VLAN tags between the switches and the IPv6 151 router to "reach" all the IPv4-only subnets from the IPv6 router. 152 Thus the general principle is that the IPv6 router device (e.g. 153 performing IPv6 Router Advertisements [1] in the case of stateless 154 autoconfiguration) is connected to the target link through the use of 155 VLAN capable Layer 2 equipment. 157 2.1 IPv6 routing over VLANs 159 In a typical scenario where connectivity is to be offered to a number 160 of existing IPv6 internal subnets, one IPv6 router could be deployed, 161 with both an external interface and one or more internal interfaces. 162 The external interface connects to the wider IPv6 internet, and may 163 be dual-stack if some tunnel mechanism is used for external 164 connectivity, or IPv6-only if a native external connection is 165 available. 167 The internal interface(s) can be connected directly to a VLAN-capable 168 switch. It is then possible to write VLAN tags on the packets sent 169 from the internal router interface based on the target IPv6 link 170 prefix. The VLAN-tagged traffic is then transported across the 171 internal VLAN-capable site infrastructure to the target IPv6 links 172 (which may be dispersed widely across the site network). 174 Where the IPv6 router is unable to VLAN-tag the packets, a protocol- 175 based VLAN can be created on the VLAN-capable device connected to the 176 IPv6 router, causing IPv6 traffic to be tagged and then redistributed 177 on (congruent) IPv4 subnet links that lie in the same VLAN. 179 2.2 One VLAN per router interface 181 The VLAN marking may be done in different ways. Some sites may 182 prefer to use one router interface per VLAN, e.g. if there are three 183 internal IPv6 links, a BSD-based IPv6 router with four Ethernet ports 184 could be used, one for the external link and three for the internal 185 links. In such a case one switch port would be needed per link, to 186 receive the connectivity from each router port. 188 In such a deployment, the IPv6 routing could be cascaded through 189 lower tier internal IPv6-only routers. Here, the internal facing 190 ports on the IPv6 edge router may feed other IPv6 routers over IPv6- 191 only links which in turn inject the IPv6 connectivity (the /64 size 192 links and associated Router Advertisements) into the VLANs. 194 2.3 Collapsed VLANs on a single interface 196 Using multiple IPv6 routers and one port per IPv6 link (i.e. VLAN) 197 may be unnecessary. Many devices now support VLAN tagging based on 198 virtual interfaces such that multiple IPv6 VLANs could be assigned 199 (trunked) from one physical router interface port. Thus it is 200 possible to use just one router interface for "aggregated" VLAN 201 trunking from a switch. This is a far more interesting case for a 202 site planning the introduction of IPv6 to (part of) its site network. 204 This approach is viable while IPv6 traffic load is light. As traffic 205 volume grows, the single collapsed interface could be extended to 206 utilise two or more physical ports, where the capacity of the IPv6 207 router device allows it. 209 2.4 Congruent IPv4 and IPv6 Subnets 211 Such a VLAN-based technique can be used to deploy IPv6-only VLANs in 212 an enterprise network. However most enterprises will be interested 213 in dual-stack IPv4-IPv6 networking. 215 In such a case the IPv6 connectivity may be injected into the 216 existing IPv4 VLANs, such that the IPv4 and IPv6 subnets are 217 congruent (i.e. they coincide exactly when superimposed). Such a 218 method may have desirable administrative properties, e.g. the devices 219 in each IPv4 subnet will be in the same IPv6 subnets also. This is 220 the method being used in our Campus Network IPv6 Transition [2] text. 222 Further, IPv6-only devices may be gradually added into the subnet 223 without any need to resize the IPv6 subnet (which may hold in effect 224 an infinite number of hosts in a /64 in contrast to IPv4 where the 225 subnet size is often relatively limited, or kept to a minimum 226 possible due to address space usage concerns). The lack of 227 requirement to periodically resize an IPv6 subnet is a useful 228 administrative advantage for IPv6. 230 2.5 IPv6 Addressing 232 One site using this VLAN technique has chosen to number its IPv6 233 links with the format [Site IPv6 prefix]:[VLAN ID]::/64. This is not 234 a recommended addressing plan, but some sites may wish to consider 235 its usage. 237 2.6 Final IPv6 Deployment 239 The VLAN technique for IPv6 deployment offers a more structured 240 alternative to opportunistic per-host intra-site tunnelling methods 241 such as ISATAP [3]. It has the ability to offer a simple yet 242 efficient method for early IPv6 deployment to an enterprise site. 244 When the site acquires IPv6-capable switch-router equipment, the 245 VLAN-based mathod can still be used for delivery of IPv6 links to 246 physical switch interfaces, just as it is commonly today for IPv4 247 subnets, but with a common routing infrastructure. 249 3. Example VLAN topology 251 The following figure shows how a VLAN topology may be used to 252 introduce IPv6 in an enterprise network, using a parallel IPv6 253 routing infrastructure and VLAN tagging. 255 External IPv6 Internet 256 | 257 | 258 IPv6 Access Router 259 | 260 | 261 Switch-router with VLAN support 262 | 263 | 264 +--------------+----------------+ 265 |Site enterprise infrastructure | 266 | with support for VLANs | 267 +----+--------------------+-----+ 268 | | 269 | | 270 VLAN switch A VLAN switch B 271 | | | 272 | | | 273 Subnet1 Subnet2 Subnet3 275 Figure 1: IPv6 deployment using VLANs (physical diagram) 277 In this scenario, the IPv6 access router has one physical port facing 278 towards the internal infrastructure. In this example it need only be 279 IPv6-enabled, as its purpose is solely to handle IPv6 traffic for the 280 enterprise. The access router has an additional interface facing 281 towards the external infrastructure, which in this example could be 282 dual-stack if the external IPv6 connectivity is via a tunnel to an 283 IPv6 ISP. 285 A number of VLANs are handled by the internal-facing IPv6 router 286 port; in this case IPv6 links Subnet1, Subnet2, Subnet3. The VLANs 287 are seen as logical subinterfaces of the physical interface on the 288 IPv6 access router, which is using the "collapsed VLAN" method 289 described above, tagging the inbound traffic with one of three VLAN 290 IDs depending on the target IPv6 Subnet prefix. 292 The following figure shows how the IPv6 view of the deployment looks; 293 all IPv6 subnets are on-link to the IPv6 access router, whether they 294 share the same physical links over the VLAN infrastructure or not. 296 External IPv6 Internet 297 | 298 | 299 Site IPv6 Access Router 300 | | | 301 | | | 302 Subnet1 Subnet2 Subnet3 304 Figure 2: IPv6 view of the deployment (logical view) 306 In this example, the router acts as an IPv6 first-hop access router 307 to the physical links, separately from the IPv4-first hop router. 308 This technique allows a site to easily "inject" native IPv6 into all 309 the links where a VLAN-capable infrastructure is available, enabling 310 partial or full IPv6 deployment on the wire in a site. 312 4. IANA Considerations 314 There are no considerations for IANA in this document. 316 5. Security Considerations 318 There are no additional security considerations particular to this 319 method of enabling IPv6 on a link. 321 Where the IPv6 connectivity is delivered into the enterprise network 322 by a different path from the IPv4 connectivity, care should be given 323 that equivalent application of security policy (e.g. firewalling) is 324 made to the IPv6 path. 326 6. Acknowledgements 328 The author would like to thank colleagues on the 6NET project, where 329 this technique for IPv4-IPv6 coexistence is widely deployed, in 330 particular Pekka Savola (CSC/FUNET), but also including Janos Mohacsi 331 (Hungarnet), Martin Dunmore and Chris Edwards (Lancaster University), 332 Christian Strauf (JOIN Project, University of Muenster) and Stig 333 Venaas (UNINETT). 335 7. Informative References 337 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 338 for IP Version 6 (IPv6)", RFC 2461, December 1998. 340 [2] Chown, T., "IPv6 Campus Transition Scenario Description and 341 Analysis", draft-chown-v6ops-campus-transition-01 (work in 342 progress), October 2004. 344 [3] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site 345 Automatic Tunnel Addressing Protocol (ISATAP)", 346 draft-ietf-ngtrans-isatap-24 (work in progress), January 2005. 348 Author's Address 350 Tim Chown 351 University of Southampton 352 Southampton, Hampshire SO17 1BJ 353 United Kingdom 355 Email: tjc@ecs.soton.ac.uk 357 Appendix A. Appendix: Configuration example 359 In this section we describe a configuration example for BSD to deploy 360 IPv6 networking across a number of IPv6 links on an enterprise (in 361 this case, six links), for a scenario similar to the one described 362 above. Here the precise configuration may of course vary depending 363 on the existing site VLAN deployment. This section highlights that 364 the VLAN configuration must be manually configured; the support is 365 not "automatic". 367 In this example, the configuration is for an IPv6 BSD router 368 connected directly to a site's external IPv6 access router. The BSD 369 router has one interface (dc0) towards the site IPv6access router, 370 and three interfaces (dc1, dc2, dc3) over which the internal routing 371 is performed (the number of interfaces can be varied, three are used 372 here to distribute the traffic load). The IPv6 documentation prefix 373 (2001:db8::/32) is used in the example. 375 --- Example IPv6 VLAN configuration, FreeBSD --- 377 # 378 # To IPv6 enable a vlan 379 # 380 # 1. Add a new vlan device to cloned_interfaces called vlanX 381 # 382 # 2. Add an ifconfig_vlanX line, the number is the vlan tag ID 383 # 384 # 3. Add vlanX to ipv6_network_interfaces 385 # 386 # 4. Add an ipv6_ifconfig_vlanX line, with a new unique prefix 387 # 388 # 5. Add vlanX to rtadvd_interface 389 # 390 # 6. Add vlanX to ipv6_router_flags 392 ### Interfaces ### 394 # Bring physical interfaces up 395 ifconfig_dc0="up" 396 ifconfig_dc1="up" 397 ifconfig_dc2="up" 398 ifconfig_dc3="up" 400 # Create VLan interfaces 401 cloned_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" 403 # Upstream link to IPv6 Access Router 404 ifconfig_vlan0="vlan 37 vlandev dc0" 406 # Downstream interfaces, load balance over interfaces dc1,dc2,dc3 407 ifconfig_vlan1="vlan 11 vlandev dc1" # Subnet1 408 ifconfig_vlan2="vlan 17 vlandev dc2" # Subnet2 409 ifconfig_vlan3="vlan 24 vlandev dc3" # Subnet3 410 ifconfig_vlan4="vlan 25 vlandev dc1" # Subnet4 411 ifconfig_vlan5="vlan 34 vlandev dc2" # Subnet5 412 ifconfig_vlan6="vlan 14 vlandev dc3" # Subnet6 414 ### IPv6 ### 416 # Enable ipv6 417 ipv6_enable="YES" 419 # Forwarding 420 ipv6_gateway_enable="YES" 422 # Define Interfaces 423 ipv6_network_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" 424 # Define addresses 425 ipv6_ifconfig_vlan0="2001:db8:d0:101::2 prefixlen 64" # Uplink 426 ipv6_ifconfig_vlan1="2001:db8:d0:111::1 prefixlen 64" # Subnet1 427 ipv6_ifconfig_vlan2="2001:db8:d0:112::1 prefixlen 64" # Subnet2 428 ipv6_ifconfig_vlan3="2001:db8:d0:121::1 prefixlen 64" # Subnet3 429 ipv6_ifconfig_vlan4="2001:db8:d0:113::1 prefixlen 64" # Subnet4 430 ipv6_ifconfig_vlan5="2001:db8:d0:114::1 prefixlen 64" # Subnet5 431 ipv6_ifconfig_vlan6="2001:db8:d0:115::1 prefixlen 64" # Subnet6 433 # Router advs 434 rtadvd_enable="YES" 435 rtadvd_interfaces="-s vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" 437 ### Routing ### 439 # Multicast 440 mroute6d_enable="YES" 441 mroute6d_program="/sbin/pim6sd" 443 # RIP-ng 444 ipv6_router_enable="YES" 445 ipv6_router_flags="-N dc0,dc1,dc2,dc3,vlan1,vlan2,vlan3,vlan4,vlan5,vlan6" 447 --- End of configuration --- 449 Note that if there was only one internal facing interface, then again 450 so long as the OS supported VLAN trunking, all the VLAN IDs could be 451 associated to that interface (dc1, for example). 453 The VLAN IDs need to be managed by the site administrator, but would 454 probably already be assigned for existing IPv4 subnets (ones into 455 which IPv6 is being introduced). 457 For a large enterprise, a combination of internal tunnels and VLAN 458 usage could be used; the whole site need not be enabled by VLAN 459 tagging alone. This choice is one for the site administrator to 460 make. 462 Intellectual Property Statement 464 The IETF takes no position regarding the validity or scope of any 465 Intellectual Property Rights or other rights that might be claimed to 466 pertain to the implementation or use of the technology described in 467 this document or the extent to which any license under such rights 468 might or might not be available; nor does it represent that it has 469 made any independent effort to identify any such rights. Information 470 on the procedures with respect to rights in RFC documents can be 471 found in BCP 78 and BCP 79. 473 Copies of IPR disclosures made to the IETF Secretariat and any 474 assurances of licenses to be made available, or the result of an 475 attempt made to obtain a general license or permission for the use of 476 such proprietary rights by implementers or users of this 477 specification can be obtained from the IETF on-line IPR repository at 478 http://www.ietf.org/ipr. 480 The IETF invites any interested party to bring to its attention any 481 copyrights, patents or patent applications, or other proprietary 482 rights that may cover technology that may be required to implement 483 this standard. Please address the information to the IETF at 484 ietf-ipr@ietf.org. 486 Disclaimer of Validity 488 This document and the information contained herein are provided on an 489 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 490 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 491 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 492 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 493 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 494 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 496 Copyright Statement 498 Copyright (C) The Internet Society (2005). This document is subject 499 to the rights, licenses and restrictions contained in BCP 78, and 500 except as set forth therein, the authors retain all their rights. 502 Acknowledgment 504 Funding for the RFC Editor function is currently provided by the 505 Internet Society.