idnits 2.17.1 draft-ietf-v6ops-vlan-usage-01.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 493. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 483. ** 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 (March 6, 2006) is 6620 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) -- Obsolete informational reference (is this intentional?): RFC 4214 (ref. '2') (Obsoleted by RFC 5214) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 10 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: September 7, 2006 March 6, 2006 6 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks 7 draft-ietf-v6ops-vlan-usage-01 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 September 7, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . 6 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 Appendix A. Appendix: Configuration example . . . . . . . . . . . 9 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 Intellectual Property and Copyright Statements . . . . . . . . . . 13 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 by 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 including that of the author. 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 that 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 standard PC-based IPv6 router with four 184 Ethernet ports could be used, one for the external link and three for 185 the internal links. In such a case one switch port would be needed 186 per link, to 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 stub links 192 using 64 bit subnet prefixes and associated Router Advertisements) 193 into the VLANs. 195 2.3. Collapsed VLANs on a single interface 197 Using multiple IPv6 routers and one port per IPv6 link (i.e. VLAN) 198 may be unnecessary. Many devices now support VLAN tagging based on 199 virtual interfaces such that multiple IPv6 VLANs could be assigned 200 (trunked) from one physical router interface port. Thus it is 201 possible to use just one router interface for "aggregated" VLAN 202 trunking from a switch. This is a far more interesting case for a 203 site planning the introduction of IPv6 to (part of) its site network. 205 This approach is viable while the IPv6 traffic load is light. As 206 traffic volume grows, the single collapsed interface could be 207 extended to utilise two or more physical ports, where the capacity of 208 the IPv6 router device allows it. 210 2.4. Congruent IPv4 and IPv6 Subnets 212 Such a VLAN-based technique can be used to deploy IPv6-only VLANs in 213 an enterprise network. However most enterprises will be interested 214 in dual-stack IPv4-IPv6 networking. 216 In such a case the IPv6 connectivity may be injected into the 217 existing IPv4 VLANs, such that the IPv4 and IPv6 subnets are 218 congruent (i.e. they coincide exactly when superimposed). Such a 219 method may have desirable administrative properties, e.g. the devices 220 in each IPv4 subnet will be in the same IPv6 subnets also. This is 221 the method used at the author's site. 223 Further, IPv6-only devices may be gradually added into the subnet 224 without any need to resize the IPv6 subnet (which may hold in effect 225 an infinite number of hosts in a /64 in contrast to IPv4 where the 226 subnet size is often relatively limited, or kept to a minimum 227 possible due to address space usage concerns). The lack of 228 requirement to periodically resize an IPv6 subnet is a useful 229 administrative advantage for IPv6. 231 2.5. IPv6 Addressing 233 One site using this VLAN technique has chosen to number its IPv6 234 links with the format [Site IPv6 prefix]:[VLAN ID]::/64. The VLAN 235 tag is 16 bits so this can work with a typical maximum 48 bit site 236 prefix. This is not a recommended addressing plan, but some sites 237 may wish to consider its usage. 239 2.6. Final IPv6 Deployment 241 The VLAN technique for IPv6 deployment offers a more structured 242 alternative to opportunistic per-host intra-site tunnelling methods 243 such as ISATAP [2]. It has the ability to offer a simple yet 244 efficient method for early IPv6 deployment to an enterprise site. 246 When the site acquires IPv6-capable switch-router equipment, the 247 VLAN-based mathod can still be used for delivery of IPv6 links to 248 physical switch interfaces, just as it is commonly today for IPv4 249 subnets, but with a common routing infrastructure. 251 3. Example VLAN topology 253 The following figure shows how a VLAN topology may be used to 254 introduce IPv6 in an enterprise network, using a parallel IPv6 255 routing infrastructure and VLAN tagging. 257 External IPv6 Internet 258 | 259 | 260 IPv6 Access Router 261 | 262 | 263 Switch-router with VLAN support 264 | 265 | 266 +--------------+----------------+ 267 |Site enterprise infrastructure | 268 | with support for VLANs | 269 +----+--------------------+-----+ 270 | | 271 | | 272 VLAN switch A VLAN switch B 273 | | | 274 | | | 275 Subnet1 Subnet2 Subnet3 277 Figure 1: IPv6 deployment using VLANs (physical diagram) 279 In this scenario, the IPv6 access router has one physical port facing 280 towards the internal infrastructure. In this example it need only be 281 IPv6-enabled, as its purpose is solely to handle IPv6 traffic for the 282 enterprise. The access router has an additional interface facing 283 towards the external infrastructure, which in this example could be 284 dual-stack if the external IPv6 connectivity is via a tunnel to an 285 IPv6 ISP. 287 A number of VLANs are handled by the internal-facing IPv6 router 288 port; in this case IPv6 links Subnet1, Subnet2, Subnet3. The VLANs 289 are seen as logical subinterfaces of the physical interface on the 290 IPv6 access router, which is using the "collapsed VLAN" method 291 described above, tagging the inbound traffic with one of three VLAN 292 IDs depending on the target IPv6 Subnet prefix. 294 The following figure shows how the IPv6 view of the deployment looks; 295 all IPv6 subnets are on-link to the IPv6 access router, whether they 296 share the same physical links over the VLAN infrastructure or not. 298 External IPv6 Internet 299 | 300 | 301 Site IPv6 Access Router 302 | | | 303 | | | 304 Subnet1 Subnet2 Subnet3 306 Figure 2: IPv6 view of the deployment (logical view) 308 In this example, the router acts as an IPv6 first-hop access router 309 to the physical links, separately from the IPv4-first hop router. 310 This technique allows a site to easily "inject" native IPv6 into all 311 the links where a VLAN-capable infrastructure is available, enabling 312 partial or full IPv6 deployment on the wire in a site. 314 4. IANA Considerations 316 There are no considerations for IANA in this document. 318 5. Security Considerations 320 There are no additional security considerations particular to this 321 method of enabling IPv6 on a link. 323 Where the IPv6 connectivity is delivered into the enterprise network 324 by a different path from the IPv4 connectivity, care should be given 325 that equivalent application of security policy (e.g. firewalling) is 326 made to the IPv6 path. 328 6. Acknowledgements 330 The author would like to thank colleagues on the 6NET project, where 331 this technique for IPv4-IPv6 coexistence is widely deployed, in 332 particular Pekka Savola (CSC/FUNET), but also including Janos Mohacsi 333 (Hungarnet), Martin Dunmore and Chris Edwards (Lancaster University), 334 Christian Strauf (JOIN Project, University of Muenster) and Stig 335 Venaas (UNINETT). 337 7. Informative References 339 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 340 for IP Version 6 (IPv6)", RFC 2461, December 1998. 342 [2] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site 343 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, 344 October 2005. 346 Appendix A. Appendix: Configuration example 348 In this section we describe a configuration example for using a 349 computer running the FreeBSD variant of the Berkeley Software 350 Distribution (BSD) operating system as a router to deploy IPv6 351 networking across a number of IPv6 links on an enterprise (in this 352 case, six links), for a scenario similar to the one described above. 353 Here the precise configuration may of course vary depending on the 354 existing site VLAN deployment. This section highlights that the VLAN 355 configuration must be manually configured; the support is not 356 "automatic". 358 In this example, the configuration is for an IPv6 BSD router 359 connected directly to a site's external IPv6 access router. The BSD 360 router has one interface (dc0) towards the site IPv6access router, 361 and three interfaces (dc1, dc2, dc3) over which the internal routing 362 is performed (the number of interfaces can be varied, three are used 363 here to distribute the traffic load). The IPv6 documentation prefix 364 (2001:db8::/32) is used in the example. 366 --- Example IPv6 VLAN configuration, FreeBSD --- 368 # 369 # To IPv6 enable a vlan 370 # 371 # 1. Add a new vlan device to cloned_interfaces called vlanX 372 # 373 # 2. Add an ifconfig_vlanX line, the number is the vlan tag ID 374 # 375 # 3. Add vlanX to ipv6_network_interfaces 376 # 377 # 4. Add an ipv6_ifconfig_vlanX line, with a new unique prefix 378 # 379 # 5. Add vlanX to rtadvd_interface 380 # 381 # 6. Add vlanX to ipv6_router_flags 382 ### Interfaces ### 384 # Bring physical interfaces up 385 ifconfig_dc0="up" 386 ifconfig_dc1="up" 387 ifconfig_dc2="up" 388 ifconfig_dc3="up" 390 # Create VLan interfaces 391 cloned_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" 393 # Upstream link to IPv6 Access Router 394 ifconfig_vlan0="vlan 37 vlandev dc0" 396 # Downstream interfaces, load balance over interfaces dc1,dc2,dc3 397 ifconfig_vlan1="vlan 11 vlandev dc1" # Subnet1 398 ifconfig_vlan2="vlan 17 vlandev dc2" # Subnet2 399 ifconfig_vlan3="vlan 24 vlandev dc3" # Subnet3 400 ifconfig_vlan4="vlan 25 vlandev dc1" # Subnet4 401 ifconfig_vlan5="vlan 34 vlandev dc2" # Subnet5 402 ifconfig_vlan6="vlan 14 vlandev dc3" # Subnet6 404 ### IPv6 ### 406 # Enable ipv6 407 ipv6_enable="YES" 409 # Forwarding 410 ipv6_gateway_enable="YES" 412 # Define Interfaces 413 ipv6_network_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" 414 # Define addresses 415 ipv6_ifconfig_vlan0="2001:db8:d0:101::2 prefixlen 64" # Uplink 416 ipv6_ifconfig_vlan1="2001:db8:d0:111::1 prefixlen 64" # Subnet1 417 ipv6_ifconfig_vlan2="2001:db8:d0:112::1 prefixlen 64" # Subnet2 418 ipv6_ifconfig_vlan3="2001:db8:d0:121::1 prefixlen 64" # Subnet3 419 ipv6_ifconfig_vlan4="2001:db8:d0:113::1 prefixlen 64" # Subnet4 420 ipv6_ifconfig_vlan5="2001:db8:d0:114::1 prefixlen 64" # Subnet5 421 ipv6_ifconfig_vlan6="2001:db8:d0:115::1 prefixlen 64" # Subnet6 423 # Router advertisements 424 rtadvd_enable="YES" 425 rtadvd_interfaces="-s vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" 427 ### Routing ### 429 # Multicast 430 mroute6d_enable="YES" 431 mroute6d_program="/sbin/pim6sd" 433 # RIP-ng 434 ipv6_router_enable="YES" 435 ipv6_router_flags="-N dc0,dc1,dc2,dc3,vlan1,vlan2,vlan3,vlan4,vlan5,vlan6" 437 --- End of configuration --- 439 Note that if there was only one internal facing interface, then again 440 so long as the OS supported VLAN trunking, all the VLAN IDs could be 441 associated to that interface (dc1, for example). 443 The VLAN IDs need to be managed by the site administrator, but would 444 probably already be assigned for existing IPv4 subnets (ones into 445 which IPv6 is being introduced). 447 For a large enterprise, a combination of internal tunnels and VLAN 448 usage could be used; the whole site need not be enabled by VLAN 449 tagging alone. This choice is one for the site administrator to 450 make. 452 Author's Address 454 Tim Chown 455 University of Southampton 456 Southampton, Hampshire SO17 1BJ 457 United Kingdom 459 Email: tjc@ecs.soton.ac.uk 461 Intellectual Property Statement 463 The IETF takes no position regarding the validity or scope of any 464 Intellectual Property Rights or other rights that might be claimed to 465 pertain to the implementation or use of the technology described in 466 this document or the extent to which any license under such rights 467 might or might not be available; nor does it represent that it has 468 made any independent effort to identify any such rights. Information 469 on the procedures with respect to rights in RFC documents can be 470 found in BCP 78 and BCP 79. 472 Copies of IPR disclosures made to the IETF Secretariat and any 473 assurances of licenses to be made available, or the result of an 474 attempt made to obtain a general license or permission for the use of 475 such proprietary rights by implementers or users of this 476 specification can be obtained from the IETF on-line IPR repository at 477 http://www.ietf.org/ipr. 479 The IETF invites any interested party to bring to its attention any 480 copyrights, patents or patent applications, or other proprietary 481 rights that may cover technology that may be required to implement 482 this standard. Please address the information to the IETF at 483 ietf-ipr@ietf.org. 485 Disclaimer of Validity 487 This document and the information contained herein are provided on an 488 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 489 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 490 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 491 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 492 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 493 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 495 Copyright Statement 497 Copyright (C) The Internet Society (2006). This document is subject 498 to the rights, licenses and restrictions contained in BCP 78, and 499 except as set forth therein, the authors retain all their rights. 501 Acknowledgment 503 Funding for the RFC Editor function is currently provided by the 504 Internet Society.