IPv6 Operations T. Chown
Internet-Draft University of Southampton
Expires: January 17, 2005 July 19, 2004
Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks
draft-chown-v6ops-vlan-usage-01
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Ethernet 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,
including the scenario of early deployment prior to availability of
IPv6-capable switch-router equipment, where 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.
Chown Expires January 17, 2005 [Page 1]
Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Enabling IPv6 per link . . . . . . . . . . . . . . . . . . . . 3
2.1 IPv6 routing . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. Informative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Chown Expires January 17, 2005 [Page 2]
Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2004
1. Introduction
Ethernet 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,
including the scenario of early deployment prior to availability of
IPv6-capable switch-router equipment, where IPv6 may be routed in
parallel with the existing IPv4 in the enterprise and delivered to
the desired LANs via VLAN technology.
The IEEE 802.1Q VLAN standard allows separate LANs to be implemented
over a single bridged LAN, by inserting "Virtual LAN" tagging or
membership information into Ethernet frames. Hosts and switches that
support VLANs effectively allow software-based reconfiguration of
LANs through configuration of the tagging parameters. The software
control means VLANs can be used to alter the LAN infrastructure
without having to physically alter the wiring between the LAN
segments and Layer 3 routers.
Many IPv4 enterprise networks are utilising VLAN technology. Where a
site does not have IPv6-capable Layer 2/3 switch-router equipment,
but VLANs are supported, a simple yet effective method exists to
gradually introduce IPv6 to some or all of that site's network.
If such a site wishes to introduce IPv6, it may do so by deploying a
parallel IPv6 routing infrastructure (which as described below may be
a single PC-based IPv6 router), and then using VLAN technology to
"overlay" IPv6 links onto existing IPv4 links. This can be achieved
without needing any changes to the IPv4 configuration.
The IPv6 connectivity to the enterprise may or may not enter the site
via the same physical link, 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,
and is referenced in our Campus Network IPv6 Transition [2] text.
2. Enabling IPv6 per link
The precise method by which IPv6 would be "injected" into the
existing IPv4 network is implementation specific. The general
principle is that the IPv6 router device (e.g. performing IPv6
Router Advertisements [1] in the case of stateless autoconfiguration)
is connected to the target link through the use of VLAN capable Layer
2 equipment.
Chown Expires January 17, 2005 [Page 3]
Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2004
2.1 IPv6 routing
In a typical scenario, one IPv6 router would be deployed, with both
an external interface and one or more internal interfaces. The
external interface connects to the wider IPv6 internet, and may be
dual-stack if some tunnel mechanism is used for external
connectivity, or IPv6-only if a native external connection is
available.
By connecting the internal interface(s) directly to a VLAN-capable
switch, and writing VLAN tags on the packets sent from the internal
router interface to the switch, VLAN tagging on the switch can be
used to carry tagged traffic across the internal VLAN-capable site
infrastructure to IPv6 links that may be dispered widely across the
site network.
It is not necessary to do VLAN tagging in all cases. On some Layer 3
switches, IPv6 traffic can directly be distributed to specific ports
by adding them to the same protocol-based VLAN (in this case
IPv6-based VLANs).
2.2 One VLAN per router interface
The VLAN marking may be done in different ways. Some sites may
prefer to use one router interface per VLAN, e.g. if there are three
internal IPv6 links, a PC-based IPv6 router with four Ethernet ports
could be used, one for the external link and three for the internal
links. In such a case one switch port would be needed per link, to
receive the connectivity from each router port.
In such a deployment, the IPv6 routing could be cascaded through
lower tier internal IPv6-only routers. Here, the internal facing
ports on the IPv6 edge router may feed other IPv6 routers over
IPv6-only links which in turn inject the IPv6 connectivity (the /64
size links and associated Router Advertisements) into the VLANs.
2.3 Collapsed VLANs on a single interface
Using multiple IPv6 routers and one port per IPv6 link (i.e. VLAN)
may be unnecessary. Many devices now support VLAN tagging based on
virtual interfaces such that multiple IPv6 VLANs could be assigned
from one physical router interface port. Thus it is possible to use
just one router interface for "aggregated" VLAN trunking from a
switch. This is a far more interesting case for a site planning the
introduction of IPv6 to (part of) its site network.
This approach is viable while IPv6 traffic load is light. As traffic
volume grows, the single collapsed interface could be extended to
Chown Expires January 17, 2005 [Page 4]
Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2004
utilise two or more physical ports, where the capacity of the IPv6
router device allows it.
2.4 Congruent IPv4 and IPv6 Subnets
Such a VLAN-based technique can be used to deploy IPv6-only VLANs in
an enterprise network. However most enterprises will be interested
in dual-stack IPv4-IPv6 networking.
In such a case the IPv6 connectivity may be injected into the
existing IPv4 VLANs, such that the IPv4 and IPv6 subnets are
congruent (i.e. they coincide exactly when superimposed). Such a
method may have desirable administrative properties, e.g. the
devices in each IPv4 subnet will be in the same IPv6 subnets also.
This is the method being used in our Campus Network IPv6 Transition
[2] text.
Further, IPv6-only devices may be gradually added into the subnet
without any need to resize the IPv6 subnet (which may hold in effect
an infinite number of hosts in a /64 in contrast to IPv4 where the
subnet size is often relatively limited, or kept to a minimum
possible due to address space usage concerns). The lack of
requirement to periodically resize an IPv6 subnet is a useful
administrative advantage for IPv6.
2.5 IPv6 Addressing
One site using this VLAN technique has chosen to number its IPv6
links with the format [Site IPv6 prefix]:[VLAN ID]::/64. This is not
a recommended addressing plan, but some sites may wish to consider
its usage.
2.6 Final IPv6 Deployment
The VLAN technique for IPv6 deployment offers a more structured
alternative to opportunistic per-host intra-site tunnelling methods
such as ISATAP [3]. 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 mathod can still be used for delivery of IPv6 links to
physical switch interfaces, just as it is commonly today for IPv4
subnets, but with a common routing infrastructure.
Chown Expires January 17, 2005 [Page 5]
Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2004
3. Example VLAN topology
The following figure shows how a VLAN topology may be used to
introduce IPv6 in an enterprise network, using a parallel IPv6
routing infrastructure and VLAN tagging.
(Subnet1) (Subnet2) (SubnetN)
\ / |
[Switch1] [SwitchN]
\ /
\ /
( VLAN infrastructure in the enterprise )
|
[ Ethernet switch with VLAN support ]
|
FE/GE w/ VLAN tagging
[ IPv6-router ]
|
( External IPv6 Internet )
Figure 1: IPv6 deployment using VLANs
In this scenario, the router has one physical port facing towards the
internal infrastructure, and is using the collapsed VLAN mechanism
described above. It may have an additional interface towards the
external infrastructure. The router can also function as a
"one-handed" router.
A number of VLANs are handled by the internal-facing IPv6 router
port; the VLANs are seen as logical subinterfaces of the physical
interface. Therefore, 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.
4. Security Considerations
There are no additional security considerations particular to this
method of enabling IPv6 on a link.
Where the IPv6 connectivity is delivered into the enterprise network
by a different path from the IPv4 connectivity, care should be given
that equivalent application of security policy (e.g. firewalling) is
made to the IPv6 path.
Chown Expires January 17, 2005 [Page 6]
Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2004
5. Acknowledgements
The author would like to thank colleagues on the 6NET project, where
this technique for IPv4-IPv6 coexistence is widely deployed,
including Janos Mohacsi (Hungarnet), Martin Dunmore and Chris Edwards
(Lancaster University), Christian Strauf (JOIN Project, University of
Muenster), Stig Venaas (UNINETT) and Pekka Savola (CSC/FUNET).
6 Informative References
[1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[2] Chown, T., "IPv6 Campus Transition Scenario Description and
Analysis", draft-chown-v6ops-campus-transition-00 (work in
progress), July 2004.
[3] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)",
draft-ietf-ngtrans-isatap-22 (work in progress), May 2004.
Author's Address
Tim Chown
University of Southampton
Southampton, Hampshire SO17 1BJ
United Kingdom
EMail: tjc@ecs.soton.ac.uk
Chown Expires January 17, 2005 [Page 7]
Internet-Draft VLANs for IPv4-IPv6 Coexistence July 2004
Intellectual Property Statement
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
ietf-ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Chown Expires January 17, 2005 [Page 8]