Network Working Group T. Chown Request for Comments: 4554 University of Southampton Category: Informational June 2006 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).
AbstractEthernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how such VLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Enabling IPv6 per Link . . . . . . . . . . . . . . . . . . . . 3 2.1. IPv6 Routing over VLANs . . . . . . . . . . . . . . . . . 3 2.2. One VLAN per Router Interface . . . . . . . . . . . . . . 4 2.3. Collapsed VLANs on a Single Interface . . . . . . . . . . 4 2.4. Congruent IPv4 and IPv6 Subnets . . . . . . . . . . . . . 5 2.5. IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . 5 2.6. Final IPv6 Deployment . . . . . . . . . . . . . . . . . . 5 3. Example VLAN Topology . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. Informative References . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Configuration Example . . . . . . . . . . . . . . . . 8
The IPv4 default route to the VLAN is provided by one (IPv4) router, while the IPv6 default route to the VLAN is provided by a different (IPv6) router. The IPv6 router can provide native IPv6 connectivity to the whole site with just a single physical interface, thanks to VLAN tagging and trunking, as described below. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link as the IPv4 traffic, and may be native or tunneled from the external provider to the IPv6 routing equipment. This VLAN usage is a solution adopted by a number of sites already, including that of the author. It should be noted that a parallel infrastructure will require additional infrastructure and thus cost, and will often require a separate link into the site (from an IPv6 provider), quite possibly tunneled, that will require the site's security policy to be applied (e.g., firewalling and intrusion detection). For sites that believe early adoption of IPv6 is important, that price is one they may be quite willing to pay. However, this document focuses on the technical issues of VLAN usage in such a scenario. 1] in the case of stateless autoconfiguration) is connected to the target link through the use of VLAN-capable Layer 2 equipment.
be dual-stack if some tunnel mechanism is used for external connectivity, or IPv6-only if a native external connection is available. The internal interface(s) can be connected directly to a VLAN-capable switch. It is then possible to write VLAN tags on the packets sent from the internal router interface based on the target IPv6 link prefix. The VLAN-tagged traffic is then transported across the internal VLAN-capable site infrastructure to the target IPv6 links (which may be dispersed widely across the site network). Where the IPv6 router is unable to VLAN-tag the packets, a protocol- based VLAN can be created on the VLAN-capable device connected to the IPv6 router, causing IPv6 traffic to be tagged and then redistributed on (congruent) IPv4 subnet links that lie in the same VLAN.
2]. It has the ability to offer a simple yet efficient method for early IPv6 deployment to an enterprise site. When the site acquires IPv6-capable switch-router equipment, the VLAN-based method can still be used for delivery of IPv6 links to physical switch interfaces, just as it is commonly used today for IPv4 subnets, but with a common routing infrastructure.
External IPv6 Internet | | IPv6 Access Router | | Switch-router with VLAN support | | +--------------+----------------+ |Site enterprise infrastructure | | with support for VLANs | +----+--------------------+-----+ | | | | VLAN switch A VLAN switch B | | | | | | Subnet1 Subnet2 Subnet3 Figure 1: IPv6 deployment using VLANs (physical diagram) In this scenario, the IPv6 access router has one physical port facing toward the internal infrastructure. In this example, it need only be IPv6-enabled, as its purpose is solely to handle IPv6 traffic for the enterprise. The access router has an additional interface facing toward the external infrastructure, which in this example could be dual-stack if the external IPv6 connectivity is via a tunnel to an IPv6 ISP. A number of VLANs are handled by the internal-facing IPv6 router port; in this case, IPv6 links Subnet1, Subnet2, Subnet3. The VLANs are seen as logical subinterfaces of the physical interface on the IPv6 access router, which is using the "collapsed VLAN" method described above, tagging the inbound traffic with one of three VLAN IDs depending on the target IPv6 Subnet prefix.
The following figure shows how the IPv6 view of the deployment looks; all IPv6 subnets are on-link to the IPv6 access router, whether or not they share the same physical links over the VLAN infrastructure. External IPv6 Internet | | Site IPv6 Access Router | | | | | | Subnet1 Subnet2 Subnet3 Figure 2: IPv6 view of the deployment (logical view) In this example, the router acts as an IPv6 first-hop access router to the physical links, separately from the IPv4 first-hop router. This technique allows a site to easily "inject" native IPv6 into all the links where a VLAN-capable infrastructure is available, enabling partial or full IPv6 deployment on the wire in a site.  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.  Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005.
# Create VLan interfaces cloned_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" # Upstream link to IPv6 Access Router ifconfig_vlan0="vlan 37 vlandev dc0" # Downstream interfaces, load balance over interfaces dc1,dc2,dc3 ifconfig_vlan1="vlan 11 vlandev dc1" # Subnet1 ifconfig_vlan2="vlan 17 vlandev dc2" # Subnet2 ifconfig_vlan3="vlan 24 vlandev dc3" # Subnet3 ifconfig_vlan4="vlan 25 vlandev dc1" # Subnet4 ifconfig_vlan5="vlan 34 vlandev dc2" # Subnet5 ifconfig_vlan6="vlan 14 vlandev dc3" # Subnet6 ### IPv6 ### # Enable ipv6 ipv6_enable="YES" # Forwarding ipv6_gateway_enable="YES" # Define Interfaces ipv6_network_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" # Define addresses ipv6_ifconfig_vlan0="2001:db8:d0:101::2 prefixlen 64" # Uplink ipv6_ifconfig_vlan1="2001:db8:d0:111::1 prefixlen 64" # Subnet1 ipv6_ifconfig_vlan2="2001:db8:d0:112::1 prefixlen 64" # Subnet2 ipv6_ifconfig_vlan3="2001:db8:d0:121::1 prefixlen 64" # Subnet3 ipv6_ifconfig_vlan4="2001:db8:d0:113::1 prefixlen 64" # Subnet4 ipv6_ifconfig_vlan5="2001:db8:d0:114::1 prefixlen 64" # Subnet5 ipv6_ifconfig_vlan6="2001:db8:d0:115::1 prefixlen 64" # Subnet6 # Router advertisements rtadvd_enable="YES" rtadvd_interfaces="-s vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6" ### Routing ### # Multicast mroute6d_enable="YES" mroute6d_program="/sbin/pim6sd"
# RIP-ng ipv6_router_enable="YES" ipv6_router_flags="-N dc0,dc1,dc2,dc3, vlan1,vlan2,vlan3, vlan4,vlan5,vlan6" --- End of configuration --- Note that if there was only one internal-facing interface, then again so long as the OS supported VLAN trunking, all the VLAN IDs could be associated to that interface (dc1, for example). The VLAN IDs need to be managed by the site administrator, but would probably already be assigned for existing IPv4 subnets (ones into which IPv6 is being introduced). For a large enterprise, a combination of internal tunnels and VLAN usage could be used; the whole site need not be enabled by VLAN tagging alone. This choice is one for the site administrator to make.
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).