One document matched: draft-ietf-v6ops-enterprise-incremental-ipv6-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY rfc1918 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY rfc2011 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2011.xml">
<!ENTITY rfc2096 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2096.xml">
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2827 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml">
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc3971 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY rfc3972 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY rfc4057 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4057.xml">
<!ENTITY rfc4193 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY rfc4213 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4213.xml">
<!ENTITY rfc4293 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4293.xml">
<!ENTITY rfc4296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4296.xml">
<!ENTITY rfc4364 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
<!ENTITY rfc4443 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY rfc4659 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4659.xml">
<!ENTITY rfc4861 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY rfc4862 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY rfc4890 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4890.xml">
<!ENTITY rfc4941 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml">
<!ENTITY rfc5095 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5095.xml">
<!ENTITY rfc5102 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5102.xml">
<!ENTITY rfc5157 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5157.xml">
<!ENTITY rfc5211 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5211.xml">
<!ENTITY rfc5214 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5214.xml">
<!ENTITY rfc5375 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5375.xml">
<!ENTITY rfc5722 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5722.xml">
<!ENTITY rfc5798 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5798.xml">
<!ENTITY rfc5952 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5952.xml">
<!ENTITY rfc6052 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml">
<!ENTITY rfc6104 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6104.xml">
<!ENTITY rfc6105 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6105.xml">
<!ENTITY rfc6144 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6144.xml">
<!ENTITY rfc6145 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6145.xml">
<!ENTITY rfc6146 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml">
<!ENTITY rfc6147 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6147.xml">
<!ENTITY rfc6192 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6192.xml">
<!ENTITY rfc6164 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6164.xml">
<!ENTITY rfc6302 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6302.xml">
<!ENTITY rfc6434 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6434.xml">
<!ENTITY I-D.ietf-savi-threat-scope PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-savi-threat-scope.xml">
<!ENTITY I-D.gashinsky-v6ops-v6nd-problems PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.gashinsky-v6ops-v6nd-problems.xml">
<!ENTITY I-D.xli-behave-divi PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.xli-behave-divi.xml">
<!ENTITY I-D.lopez-v6ops-dc-ipv6 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lopez-v6ops-dc-ipv6.xml">
<!ENTITY I-D.templin-v6ops-isops PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.templin-v6ops-isops.xml">
<!ENTITY I-D.matthews-v6ops-design-guidelines PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.matthews-v6ops-design-guidelines.xml">
<!ENTITY I-D.vyncke-opsec-v6 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.vyncke-opsec-v6.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!-- keep one blank line between list items -->
<rfc category="info" docName="draft-ietf-v6ops-enterprise-incremental-ipv6-01"
ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="enterprise-ipv6-deployment-guidelines">Enterprise IPv6
Deployment Guidelines</title>
<author fullname="Kiran K. Chittimaneni" initials="K"
surname="Chittimaneni">
<organization>Google Inc.</organization>
<address>
<postal>
<street>1600 Amphitheater Pkwy</street>
<city>Mountain View, California</city>
<country>USA</country>
<code>CA 94043</code>
</postal>
<email>kk@google.com</email>
</address>
</author>
<author fullname="Tim Chown" initials="T.J." surname="Chown">
<organization>University of Southampton</organization>
<address>
<postal>
<street>Highfield</street>
<city>Southampton</city>
<code>SO17 1BJ</code>
<region>Hampshire</region>
<country>United Kingdom</country>
</postal>
<email>tjc@ecs.soton.ac.uk</email>
</address>
</author>
<author fullname="Lee Howard" initials="L" surname="Howard">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13820 Sunrise Valley Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<phone>+1 703 345 3513</phone>
<email>lee.howard@twcable.com</email>
</address>
</author>
<author fullname="Victor Kuarsingh" initials="V" surname="Kuarsingh">
<organization>Rogers Communications</organization>
<address>
<postal>
<street>8200 Dixie Road</street>
<city>Brampton, Ontario</city>
<country>Canada</country>
<code/>
</postal>
<email>victor.kuarsingh@rci.rogers.com</email>
</address>
</author>
<author fullname="Yanick Pouffary" initials="Y" surname="Pouffary">
<organization>Hewlett Packard</organization>
<address>
<postal>
<street>950 Route Des Colles</street>
<city>Sophia-Antipolis</city>
<country>France</country>
<code>06901</code>
</postal>
<email>Yanick.Pouffary@hp.com</email>
</address>
</author>
<author fullname="Eric Vyncke" initials="E" surname="Vyncke">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>De Kleetlaan 6a</street>
<city>Diegem</city>
<country>Belgium</country>
<code>1831</code>
</postal>
<phone>+32 2 778 4677</phone>
<email>evyncke@cisco.com</email>
</address>
</author>
<date day="15" month="September" year="2012"/>
<!-- Meta-data Declarations -->
<area>Ops</area>
<workgroup>v6ops</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>IPv6 transition enterprise</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Enterprise network administrators worldwide are in various stages of
preparing for or deploying IPv6 into their networks. The administrators
face different challenges than operators of Internet access providers,
and have reasons for different priorities. The overall problem for many
administrators will be to offer Internet-facing services over IPv6,
while continuing to support IPv4, and while introducing IPv6 access
within the enterprise IT network. The overall transition will take most
networks from an IPv4-only environment to a dual stack network
environment and potentially an IPv6-only operating mode. This document
helps provide a framework for enterprise network architects or
administrators who may be faced with many of these challenges as they
consider their IPv6 support strategies.</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>An Enterprise Network as defined in <xref target="RFC4057"/> as: a
network that has multiple internal links, one or more router connections
to one or more Providers, and is actively managed by a network
operations entity (the "administrator", whether a single person or
department of administrators). Adminstrators generally support an
internal network, consisting of users' computers and related
peripherals, a server network, consisting of accounting and business
application servers, and an external network, consisting of
Internet-accessible services such as web servers, email servers, VPN
systems, and customer applications. This document is intended as
guidance for network architects and administrators in planning their
IPv6 deployments.</t>
<t>The business reasons for spending time, effort, and money on IPv6
will be unique to each enterprise. The most common drivers are due to
the fact that when Internet service providers, including mobile wireless
carriers, run out of IPv4 addresses, they will provide native IPv6 and
non-native IPv4. The non-native IPv4 service may be NAT64, NAT444,
Dual-stack Lite, or other transition technology, but whether tunneled or
translated, the native traffic will be perform better and more reliably
than non-native. It is thus in the enterprise's interests to deploy
native IPv6 itself.</t>
<t/>
<section title="Enterprise Assumptions">
<t>For the purposes of this document, assume:</t>
<t><list style="symbols">
<t>The administrator is considering deploying IPv6 (but see <xref
target="IPv4-only"/> below).</t>
<t>The administrator has existing IPv4 networks and devices which
will continue to exist.</t>
<t>The administrator will want to minimize the level of disruption
to the users and services by minimizing number of technologies and
functions that are needed to mediate any given application. In
other words, provide native IP wherever possible.</t>
</list></t>
<t>Based on these assumptions, an administrator will want to use
technologies which minimize the number of flows being tunnelled,
translated or intercepted at any given time. The administrator will
choose transition technologies or strategies which allow most traffic
to be native, and will manage non-native traffic. This will allow the
administrator to minimize the cost of IPv6 transition technologies, by
containing the number and scale of transition systems.</t>
</section>
<section anchor="IPv4-only" title="IPv4-only Considerations">
<t>As described in <xref target="RFC6302"/> administrators should take
certain steps even if they are not considering IPv6. Specifically,
Internet-facing servers should log the source port number, timestamp
(from a reliable source), and the transport protocol. This will allow
investigation of malefactors behind address-sharing technologies such
as NAT44 or Dual-stack Lite. Enabling this additional logging will
take a few minutes on each server, and will probably require
restarting the service.</t>
<t>Other IPv6 considerations may impact ostensibly IPv4-only networks,
e.g. <xref target="RFC6104"/> describes the rogue IPv6 RA problem,
which may cause problems in IPv4-only networks where IPv6 is enabled
in end systems on that network.</t>
</section>
<section title="Reasons for a Phased Approach">
<t>Given the challenges of migrating user workstations, corporate
systems, and Internet-facing servers, a phased approach allows
incremental deployment of IPv6, based on the administrator's own
determination of priorities. The Preparation Phases is highly
recommended to all administrators, as it will save errors and
complexity in later phases. Each administrator must decide whether to
begin with the External Phase (as recommended in <xref
target="RFC5211"/>) or the Internal Phase. There is no "correct"
answer here; the decision is one for each enterprise to make.</t>
<t>Some considerations:</t>
<t><list style="symbols">
<t>In many cases, customers outside the network will have IPv6
before the internal enterprise network. For these customers, IPv6
may well perform better, especially for certain applications, than
translated or tunneled IPv4, so the administrator may want to
prioritize the External Phase.</t>
<t>Employees who access internal systems by VPN may find that
their ISPs provide translated IPv4, which does not support the
required VPN protocols. In these cases, the administrator may want
to prioritize the External Phase, and any other
remotely-accessible internal systems.</t>
<t>Internet-facing servers cannot be managed over IPv6 unless the
management systems are IPv6-capable. These might be Network
Management Systems (NMS), monitoring systems, or just remote
management desktops. Thus in some cases, the Internet-facing
systems are dependent on IPv6-capable internal networks. However,
dual-stack Internet-facing systems can still be managed over
IPv4.</t>
<t>IPv6 is enabled by default on all modern operating systems, so
it may be more urgent to manage and have visibility on the
internal traffic.</t>
<t>In many cases, the corporate accounting, payroll, human
resource, and other internal systems may only need to be reachable
from the internal network, so they may be a lower priority. But
more and more internal applications support IPv6 by default and it
can be expected that new applications will only support IPv6.</t>
<t>Some organizations (even when using private IPv4 addresses<xref
target="RFC1918"/>) are facing IPv4 address exhaustion because of
the internal network growth (for example the vast number of
virtual machines).</t>
<t>IPv6 restores end to end reachability even for internal
applications (of course security policies must still be enforced)
which means that with IPv6 merging networks (after two
organizations merged) is much easier and faster. Yet, another
reason to move the internal network to IPv6.</t>
</list>These considerations are in conflict; each administrator must
prioritize according to their local conditions.</t>
</section>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>
when they appear in ALL CAPS. These words may also appear in this
document in lower case as plain English words, absent their normative
meanings.</t>
</section>
<section title="Preparation and Assessment Phase" toc="default">
<t/>
<section title="Inventory Phase">
<t>To comprehend the inventory phase spectrum we recommended dividing
the problem space in two: network infrastructure readiness and
applications readiness.</t>
<section title="Network infrastructure readiness assessment">
<t>The network infrastructure readiness assessment for IPv6 as its
name state is focused on the network. The goal of this assessment is
identify the level of readiness of network equipment. This is an
important step as it will help identify the effort required to move
to an infrastructure that supports IPv6 with the same features as
the existing IPv4 network (for example MPLS-VPN <xref
target="RFC4364"/> whose equivalent in IPv6 is 6VPE <xref
target="RFC4659"/>).</t>
<t>Be able to understand which network devices are already capable,
which devices can be made IPv6 ready with a code/firmware upgrade,
and which devices will need to be replaced. The data collection
consists of a network discovery to gain an understanding of the
topology and inventory network infrastructure equipment and code
versions with information gathered from static files and IP address
management, DNS and DHCP tools.</t>
<t>Remember understanding the starting point and what are the
technical issues and challenges is critical as IPv6 might already be
present in the environment thus creating inherent security
risks.</t>
</section>
<section title="Applications readiness assessment">
<t>Just like network equipment, application software needs to
support IPv6. This includes OS, firmware, middleware and
applications (including internally developed applications). Vendors
will typically handle IPv6 enablement of off-the-shelf products.
Enterprises need to request this support from vendors. For
internally developed applications it is the responsibility of the
enterprise to enable them for IPv6. Analyzing how a given
application communicates of the network will dictate the steps
required to support IPv6. Applications should be made to use APIs
which hide the specifics of a given IP address family. Any
applications that use APIs, such as the C language, which exposes
the IP version specificity need to be modified to also work with
IPv6.</t>
<t>There are two ways to IPv6-enable your applications. The first
approach is to have separate logic for IPv4 and IPv6, thus leaving
the IPv4 code path mainly untouched. This approach causes the least
disruption to the existing IPv4 logic flow, but introduces more
complexity, since the application now has to deal with two logic
loops with complex race conditions and error recovery mechanisms
between these two logic loops. The second approach is to create a
combined IPv4/IPv6 logic, which ensures operation regardless of the
IP version used on the network. We recommend using industry
IPv6-porting tools to locate the code that need to be updated.</t>
</section>
<section title="Importance of readiness validation and testing">
<t>Lastly IPv6 introduces a completely new way of addressing
endpoints, which can have ramifications at the network layer all the
way up to the applications. So to minimize disruption during the
transition phase we recommend complete functionality, scalability
and security testing to understand how IPv6 impacts the services and
networking infrastructure will be paramount.</t>
</section>
</section>
<section title="Training">
<t>IPv6 planning and deployment in the enterprise is not an entirely
network centric affair. IPv6 adoption will be a multifaceted
undertaking that will touch everyone in the organization. While
technology and process transformations are taking place is it critical
that people training takes place as well. Training will ensure that
people and skill gaps are assessed proactively and managed
accordingly. We recommend that training needs be analyzed and defined
in order to successfully inform, train, and prepare staff for the
impacts of the system or process changes.</t>
</section>
<section title="Routing">
<t>When deploying IPv6, we recommend initially choosing an IGP
protocol you are familiar with. That is to say if you are using OSPFv2
you should be using OSPFv3. The main advantage of this approach is
that staff do not need to be trained and existing processes can be
leveraged.</t>
<t>Enterprises could also take the opportunity the introduction of
IPv6 brings to analyze your current environment and to identify which
features you would like to change and what you would like to
implement. Then using the validation period as a way to validate your
new approach and even applying them to your IPv4 environment.</t>
<t>Either way IPv6 introduces the opportunity to rationalize the
environment and to architect it for growth.</t>
</section>
<section title="Security Policy">
<t>It is obvious that IPv6 network should be deployed in a secure way.
The industry has learned a lot about network security with IPv4, so,
network operators should leverage this knowledge and expertise when
deploying IPv6. IPv6 is not so different than IPv4: it is a
connectionless network protocol using the same lower layer service and
delivering the same service to the upper layer. Therefore, the
security issues and mitigation techniques are mostly identical with
same exceptions that are described further.</t>
<section title="Demystifying some IPv6 Security Myths">
<t>Some people believe that IPv6 is inherently more secure than IPv4
because it is new. Nothing can be more wrong. Indeed, being a new
protocol means that bugs in the implementations have yet to be
discovered and fixed and that few people have the operational
security expertise needed to operate securely an IPv6 network. This
lack of operational expertise is the biggest threat when deploying
IPv6: the importance of training is to be stressed again.</t>
<t>One security myth is that thanks to its huge address space, a
network cannot be scanned by enumerating all IPv6 address in a /64
LAN hence a malevolent person cannot find a victim. <xref
target="RFC5157"/> describes some alternate techniques to find
potential targets on a network, for example enumerating all DNS
names in a zone.</t>
<t>Another security myth is that IPv6 is more secure because it
mandates the use of IPsec everywhere. <xref target="RFC6434"/>
clearly states that the IPv6 support is a SHOULD only. Moreover, if
all the intra-enterprise traffic is encrypted, then this renders a
lot of the network security tools (IPS, firewall, ACL, IPFIX, etc)
blind and pretty much useless. Therefore, IPsec should be used in
IPv6 pretty much like in IPv4 (for example to establish a VPN
overlay over a non-trusted network or reserved for some specific
applications).</t>
<t>The last security myth is that amplification attacks (such as
<xref target="SMURF"/>) do not exist in IPv6 because there is no
more broadcast. Alas, this is not true as ICMP error (in some cases)
or information messages can be generated by routers and hosts when
forwarding or receiving a multicast message (section 2.4 of <xref
target="RFC4443"/>). Therefore, the generation and the forwarding
rate of ICMPv6 messages must be limited as in IPv4.</t>
</section>
<section title="Similarities between IPv6 and IPv4 security">
<t>As mentioned earlier, IPv6 is quite similar to IPv4, therefore
several attacks apply for both protocol family:</t>
<t><list style="symbols">
<t>Application layer attacks: such as cross-site scripting or
SQL injection</t>
<t>Rogue device: such as a rogue WiFi Access Point</t>
<t>Flooding and all traffic based denial of services (including
the use of control plane policing for IPv6 traffic see <xref
target="RFC6192"/>)</t>
<t>Etc</t>
</list></t>
<t>A specific case of congruence is the IPv6 ULA <xref
target="RFC4193"/> and IPv4 private addressing <xref
target="RFC1918"/> that do not provide any security by 'magic'. In
both case, the edge router must apply strict data plane and routing
policy to block those private addresses to leave and enter the
network. This filtering can be done by the enterprise or by the
ISP.</t>
<t>IPv6 addresses can be spoofed as easily as IPv4 addresses and
there are packets with bogons IPv6 addresses (see <xref
target="CYMRU"/>). The anti-bogon filtering must be done in the data
and routing planes. It can be done by the enterprise or by the
ISP.</t>
</section>
<section anchor="ipv6_security_specifics"
title="Specific Security Issues for IPv6">
<t>Even if IPv6 is similar to IPv4, there are some differences that
create some IPv6-only vulnerabilities or issues.</t>
<t>Privacy extension addresses <xref target="RFC4941"/> are usually
to protect individual privacy by changing periodically the interface
identifier part of the IPv6 address to avoid tracking a host by its
always identical and unique EUI-64. While this presents a real
advantage on the Internet, it complicates the task of audit trail
when a security officer or network operator wants to trace back a
log entry to a host in their network because when the tracing is
done the searched IPv6 address could have disappeared from the
network. Therefore, the use of privacy extension addresses usually
requires an additional monitoring and logging of the binding of the
IPv6 address to a data-link layer address (see also the monitoring
section of <xref target="I-D.vyncke-opsec-v6"/>). An alternative is
to try to prevent the use of privacy extension addresses is to send
the Router Advertisement with the M-bit set (to force the use of
DHCPv6 to get an address) and with all advertized prefixes without
the A-bit set (to prevent the use of stateless auto-configuration);
this technique requires that all hosts support stateful DHCPv6.</t>
<t>Extension headers complicate the task of stateless packet filters
such as ACL. If ACL are used to enforce a security policy, then the
enterprise must verify whether its ACL (but also stateful firewalls)
are able to process extension headers (this means understand them
enough to parse them to find the upper layers payloads) and to block
unwanted extension headers (e.g. to implement <xref
target="RFC5095"/>).</t>
<t>Fragmentation is different in IPv6 because it is done only by
source host and never during a forwarding operation. This means that
ICMPv6 packet-too-big must be allowed <xref target="RFC4890"/>
through all filters. Fragments can also be used to evade some
security mechanisms such as RA-guard <xref target="RFC6105"/>, see
also <xref target="RFC5722"/> which appears to be widely implemented
in 2012.</t>
<t>But, the biggest difference is the replacement of ARP (RFC 826)
by Neighbor Discovery Protocol <xref target="RFC4861"/>. NDP runs
over ICMPv6 (this means that security policies MUST allow some
ICMPv6 messages see RFC 4890) but has the same lack of security as
ARP (SeND <xref target="RFC3971"/> and CGA <xref target="RFC3972"/>
are not widely implemented). ARP can be made secure with the help of
techniques known as DHCPv4 snooping and dynamic ARP inspection by
access switches. Therefore, enterprises using those techniques for
IPv4 should use the equivalent techniques for IPv6: this is RA-guard
(RFC 6105) and all work in progress from the SAVI WG (<xref
target="I-D.ietf-savi-threat-scope"/> and others). Another DoS
vulnerabilities are related to NDP cache exhaustion (<xref
target="I-D.gashinsky-v6ops-v6nd-problems"/>) and they can be
mitigated by careful tuning of the NDP cache. In 2012, there are
already several vendors offering those features on their
switches.</t>
<t>Running a dual-stack network doubles the attack exposure as a
malevolent person has now two attack vectors: IPv4 and IPv6. This
simply means that all routers and hosts operating in a dual-stack
environment with both protocol families enabled (even if by default)
must have a congruent security policy for both protocol version. For
example, permit TCP ports 80 and 443 to all web servers and deny all
other ports to the same servers must be implemented both for IPv4
and IPv6.</t>
</section>
</section>
<section title="Address Plan">
<t>The most common problem encountered in IPv6 networking is in
applying the same principles of conservation that are so important in
IPv4. IPv6 addresses do not need to be assigned conservatively. In
fact, a single larger allocation is considered more conservative than
multiple discountiguous small blocks, because a single block occupies
only a single entry in a routing table. The advice in <xref
target="RFC5375"/> is still sound, and is recommended to the reader.
If considering ULAs, give careful consideration to how well it is
supported, especially in multiple address and multicast scenarios, and
assess the strength of the requirement for ULA.</t>
<t>The enterprise administrator will want to evaluate whether the
enterprise will request address space from its ISP (or Local Internet
Registry (LIR)), or whether to request address space from the local
Internet Registry (whether a Regional Internet Registry such as
AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC, or a National Internet
Registry, operated in some countries). There may be a registration fee
for requesting provider-independent (PI) space from and NIR/RIR, but
the enterprise will avoid some complexity if renumbering is required
after changing ISPs (it should be noted that renumbering caused by
outgrowing the space, merger, or other internal reason might not be
avoided with PI space).</t>
<t>Each location, no matter how small, should get at least a /48. In
addition to allowing for simple planning, this can allow a site to use
its prefix for local connectivity, should the need arise, and if the
local ISP supports it. Generally, workstations managed by the
enterprise will use stateful DHCPv6 for addressing on corporate LAN
segments. DHCPv6 allows for the additional configuration options often
employed by enterprise administrators, and by using stateful DHCPv6,
administrators correlating system logs know which system had which
address at any given time.</t>
<t>In the data center or server room, assume a /64 per VLAN. This
applies even if each individual system is on a separate VLAN; in a /48
assignment, typical for a site, there are 65,535 /64 blocks. Addresses
are either configured manually on the server, or reserved on a DHCPv6
server, which may also synchronize forward and reverse DNS.</t>
<t>All user access networks MUST be a /64. Point-to-point links
without MAC addresses (this is where Neighbor Discovery Protocol does
not run) SHOULD be a /127 (see also <xref target="RFC6164"/>).</t>
<t>Plan to aggregate at every layer of network hierarchy. Where
multiple VLANs or other layer two domains converge, allow some room
for expansion. Renumbering due to outgrowing the network plan is a
nuisance, so allow room within it. Generally, grow to about twice the
current size can be accomodated; where rapid growth is planned, allow
for twice that growth. Also, for any part of the network where DNS (or
reverse DNS) zones may be delegated, it is important to delegate
addresses on nibble boundaries (this is on a multiple of 4 bits), to
ensure propose name delegation.</t>
</section>
<section title="Program Planning">
<t>As with any project, an IPv6 deployment project will have its own
phases. Generally, one person is identified as the project sponsor or
champion, who will make sure time and talent resources are prioritized
appropriately for the project. Because enabling IPv6 can be a project
with many interrelated tasks, identifying a project manager is also
recommended. The project manager and sponsor can initiate the project,
determining the scope of work and identifying whose input is required,
and who will be affected by work. The scope will generally include the
Preparation Phase, and may include the Internal Phase, the External
Phase, or both, and may include any or all of the Other Phases
identified.</t>
<t>The project manager will need to spend some time planning. It is
often useful for the sponsor to communicate with stakeholders at this
time, to explain why IPv6 is important to the enterprise. Then, as the
project manager is assessing what systems and elements will be
affected, the stakeholders will understand why it is important for
them to support the effort. Well-informed project participants can
help significantly by explaining the relationships between components.
For a large enterprise, it may take several iterations to really
understand the level of effort required; some systems will require
additional development, some might require software updates, and
others might need new versions or alternate vendors. Once the projects
are understood, the project manager can develop a schedule and a
budget, and work with the project sponsor to determine what
constraints can be adjusted, if necessary.</t>
<t>It is tempting to roll IPv6 projects into other architectural
upgrades - this can be an excellent way to improve the network and
reduce costs. Project participants are advised that by increasing the
scope of projects, the schedule is often affected. For instance, a
major systems upgrade may take a year to complete, where just patching
existing systems may take only a few months. Understanding and
evaluating these trade-offs are why a project manager is
important.</t>
<t>It is very common for assessments to continue in some areas even as
execution of the project begins in other areas. This is fine, as long
as recommendations in other parts of this document are considered,
especially regarding security (for instance, one should not deploy
IPv6 on a system before security has been evaluated). The project
manager will need to continue monitoring the progress of discrete
projects and tasks, to be aware of changes in schedule, budget, or
scope. "Feature creep" is common, where engineers or management wish
to add other features while IPv6 development or deployment is ongoing;
each feature will need to be individually evaluated for its effect on
the schedule and budget, and whether expanding the scope increases
risk to any other part of the project.</t>
<t>As projects are completed, the project manager will confirm that
work has been completed, often by means of seeing a completed test
plan, and will report back to the project sponsor on completed parts
of the project. A good project manager will remember to thank the
people who executed the project.</t>
</section>
<section title="Tools Assessment">
<t>Enterprises will often have a number of operational tools and
support systems which are used to provision, monitor, manage and
diagnose the network and systems within their environment. These tools
and systems will need to be assessed for compatibility with IPv6
operation. The compatibility may be related to actual addressing and
connectivity of various devices as well as IPv6 awareness in many of
tools and processing logic.</t>
<t>The tools within the organization fall into two general categories,
those which focus on managing the network, and those which are focused
on managing systems and applications on the network. In either
instance, the tools will run on platforms which may or may not be
capable of operating in an IPv6 network. This lack in functionality
may be related to Operating system version, or based on some hardware
constraint. Those systems which are found to be incapable of utilizing
a IPv6 connection may need to be replaced or upgraded.</t>
<t>In addition to devices working on an IPv6 network natively, or via
a tunnel, many tools and support systems may require additional
updates to be IPv6 aware or even a hardware upgrade (mainly because of
the memory utilization by IPv6 as the addresses are larger and
because, for a while, IPv4 and IPv6 addresses will coexist in the
tool). This awareness may include the ability to manage IPv6 elements
and/or applications in addition to the ability to store and utilize
IPv6 addresses.</t>
<t>Considerations when assessing the tools and support systems may
include the fact that IPv6 addresses are significantly larger then
IPv4 requiring datastores to support the increased size. Such issues
are among those discussed in <xref target="RFC5952"/>. Many
organizations may also run dual stack networks, therefore the tools
need not only support IPv6 operation, but may also need to support the
monitoring, management and intersection with both IPv6 and IPv4
simultaneously. It is important to note that managing IPv6 is not just
constrained to using large IPv6 addresses, but also that IPv6
interfaces and nodes may use two or more addresses as part of normal
operation. Updating management systems to deal with these additional
nuances will likely time and considerable effort.</t>
<t>For networking focus systems, like node management systems, it is
not always necessary to support local IPv6 addressing and
connectivity. Operation, such as SNMP MIB polling can occur over IPv4
transport while seeking responses related to IPv6 information. Where
this may seem advantageous to some, it should be noted that without
local IPv6 connectivity, the management system may not be able to
perform all expected functions - such as reachability and service
checks.</t>
<t>Organizations should be aware of changes to older IPv4-Only SNMP
MIB specifications have been made by the IETF related to legacy
operation in <xref target="RFC2096"/> and <xref target="RFC2011"/>.
Updated specifications are now available in <xref target="RFC4296"/>
and <xref target="RFC4293"/> which modified the older MIB framework to
be IP protocol agnostic supporting IPv4 and IPv6. Polling systems will
need to be upgraded to support these updates as well as the end
stations which are polled.</t>
</section>
</section>
<section title="External Phase">
<t>The external phase for Enterprise IPv6 adoption covers topics which
deal with how an organization connects their infrastructure to the
external world. These external connections may be toward the Internet at
larges, or other networks. The external phase covers connectivity,
security, monitoring of various elements and outward facing or
accessible services.</t>
<t>How an organization connects to the outside worlds is very important
as it is often a critical part of how a business functions, therefore
must be dealt accordingly.</t>
<section title="Connectivity">
<t>The Enterprise will need to work with one or more Service Providers
to gain connectivity to the Internet or transport service
infrastructure such as a BGP/MPLS IP VPN as described in <xref
target="RFC4364"/> and <xref target="RFC4659"/>. On significant factor
guiding how an organization may need to communist with the outside
world will involve the use of PI (Provider Independent) and/or PA
(Provider Aggregatable) IPv6 space.</t>
<t>In the case of PI, the organization will need to support BGP based
connectivity for the most part since the address space is assigned
direction from the Regional Registry to the local network. In this
case, the local network would act as an Autonomous System on the
Internet and must advertise routes accordingly. PA space is delegated
form the upstream service provider and can then be assigned to the
local network. If PA space is used, other forms of route exchange may
be possible such as RIPng, OSPFv3 and static. PA assigned space would
normally be routed to the general Internet via the upstream providers
infrastructure lightening the burden on the local network
administrations.</t>
<t>PI and PA space have additional contrasting behaviours when use
such as how dual homing may work. Should an operator choose to dual
home, PI space would be routed to both upstream providers and then
passed on to other networks. Utilizing more then one upstream Service
Provider may introduce challenges since traffic utilizing a given PA
assign block would be expected to flow through the assigning provider
for entry to the Internet. Should traffic flow using sources addresses
which are not delegated form a given provider, reverse path forwarding
rules on the operator side may reject some traffic. These
considerations are quite different then those of IPv4 which relied on
NAT in most cases.</t>
<t>When seeking IPv6 connectivity to a Service Provider, the
Enterprise will want to attempt to use Native IPv6 connectivity.
Native IPv6 connectivity is preferred since it provides the most
rebuts form of connectivity. If Native IPv6 connectivity is not
possible due to technical or business limitations, the Enterprise may
utilize readily available tunnelled IPv6 connectivity. There are IPv6
transit providers which provide tunnelled IPv6 connectivity which can
operate over IPv4 networks. A Enterprise need not need to wait for
their local Service Provider to support IPv6, as tunnelled
connectivity can be used.</t>
<t>** Add some comment about setting MTU to 1280 to avoid tunnel pMTUd
black holes? **</t>
</section>
<section title="Security">
<t>The most important part of security for external IPv6 deployment is
filtering and monitoring. Filtering can be done by stateless ACL or
stateful firewall. The security policies must be congruent for IPv4
and IPv6 (else the attacker will use the less protected protocol
stack) except that ICMPv6 messages must be allowed through and to the
filtering device (see <xref target="RFC4890"/>):</t>
<t><list style="symbols">
<t>unreachable packet-too-big: really imporant to allow Path MTU
discovery to work</t>
<t>unreachable parameter-problem</t>
<t>neighbor solicitation</t>
<t>neighbor advertisement</t>
</list></t>
<t>It could also be safer to block all fragments where the transport
layer header is not in the first fragment to avoid attack as described
in <xref target="RFC5722"/>. Some filtering devices allow this
filtering. To be fully compliant with <xref target="RFC5095"/>, it can
be useful to drop all packet containing the routing extension header
type 0.</t>
<t>If Intrusion Prevention Systems (IPS) are used for IPv4 traffic,
then the same IPS should also be used for IPv6 traffic. This is just a
generalization of the dual-stack deployment: do for IPv6 what you do
for IPv4. This also include all email content protection (anti-spam,
content filtering, data leakage prevention, etc).</t>
<t>The peering router must also implement anti-spoofing technique
based on <xref target="RFC2827"/>.</t>
<t>In order to protect the networking devices, it is advised to
implement control plane policing as per <xref target="RFC6192"/>.</t>
<t>The NDP cache exhaustion (see <xref
target="I-D.gashinsky-v6ops-v6nd-problems"/>) attack can be mitigated
by two techniques:</t>
<t><list style="symbols">
<t>good NDP implementation with memory utilization limits as well
as rate-limiters and prioritization of requests.</t>
<t>else, as the external deployment usually involves just a couple
of exposed IPv6 statically configured addresses (virtual address
of web, email servers, DNS server), then it is straightforward to
build an ingress ACL allowing traffic for those addresses and
denying traffic to any other addresses. This actually prevents the
attack as packet for random destination will be dropped and will
never trigger a neighbor resolution.</t>
</list></t>
</section>
<section title="Monitoring">
<t>Monitoring the use of the Internet connectivity should be done for
IPv6 if it is done for IPv4. This includes the use of IP flow export
<xref target="RFC5102"/> to detect abnormal traffic pattern (such as
port scanning, SYN-flooding) and SNMP MIB <xref target="RFC4293"/>
(another way to detect abnormal bandwidth utilization).</t>
</section>
<section title="Servers and Applications">
<t/>
</section>
</section>
<section title="Internal Phase">
<t>This phase deals with the delivery of IPv6 to the internal user
facing side of the IT infrastructure, which comprises of various
components such as network devices (routers, switches, etc.), end user
devices and peripherals (workstations, printers, etc.), and internal
corporate systems.</t>
<t>An important design paradigm to consider during this phase is "Dual
Stack when you can, tunnel when you must". Dual stacking allows you to
build a more robust IPv6 network that is of production quality as
opposed to tunnels that are harder to troubleshoot and support. Tunnels
however do provide operators with a quick and easy way to play with IPv6
and gain some operational experience with the protocol. <xref
target="RFC4213"/> describes various transition mechanisms in more
detail. <xref target="I-D.templin-v6ops-isops"/> suggests operational
guidance when using ISATAP tunnels <xref target="RFC5214"/>.</t>
<section title="Network Infrastructure">
<t>The typical enterprise network infrastructure comprises of a
combination of the following network elements - wired access switches,
wireless access points, and routers. Although, it is fairly common to
find hardware that collapses switching and routing functionality into
a single device. Basic wired access switches and access points that
operate only at the physical and link layer, don't really have any
special IPv6 considerations other than being able to support IPv6
addresses themselves for management purposes, if the same exists for
IPv4. In many instances, these devices possess a lot more intelligence
than simply switching packets. For example, some of these devices help
assist with link layer security by incorporating features such as ARP
inspection and DHCP Snooping.</t>
<t>An important design choice to be made is what IGP to use inside the
network. A variety of IGPs (IS-IS, OSPFv3 and RIPng) support IPv6
today and picking one over the other is purely a design choice that
will be dictated mostly by existing operational policies in an
enterprise network. As mentioned earlier, it would be beneficial to
maintain operational parity between IPv4 and IPv6 and therefore it
might make sense to continue using the same protocol family that is
being used for IPv4. For example, if you use OSPFv2 for IPv4, it might
make sense to use OSPFv3 now. It is important to note that although
OSPFv3 is similar to OSPFv2, they are not the same. On the other hand,
some organizations may chose to run different routing protocols for
different IP versions. For e.g., one may chose to run OSPFv2 for IPv4
and IS-IS for IPv6. An important design question to consider here is
whether to support one IGP or two different IGPs down the road. <xref
target="I-D.matthews-v6ops-design-guidelines"/> presents advice on the
design choices that arise when considering one IGP vs. the other and
discusses the pros and cons in detail.</t>
<t>Another important consideration in enterprise networks is first hop
router redundancy. This directly ties into network reachability from
an end host's point of view. IPv6 Neighbor Discovery (ND), <xref
target="RFC4861"/>, provides a node with the capability to maintain a
list of available routers on the link, in order to be able to switch
to a backup path should the primary be unreachable. By default, ND
will detect a router failure in 38 seconds and cycle onto the next
default router listed in its cache. While this feature does provide
with a basic level of first hop router redundancy, most enterprise
IPv4 networks are designed to fail over much faster. Although this
delay can be improved by adjusting the default timers, care must be
taken to protect against transient failures and to account for
increased traffic on the link. Another option to provide robust first
hop redundancy is to use the Virtual Router Redundancy Protocol for
IPv6 (VRRPv3), <xref target="RFC5798"/>. This protocol provides a much
faster switchover to an alternate default router than default ND
parameters. Using VRRP, a backup router can take over for a failed
default router in around three seconds (using VRRP default
parameters). This is done without any interaction with the hosts and a
minimum amount of VRRP traffic.</t>
<t>Last but not the least, one of the most important design choices to
make while deploying IPv6 on the internal network is whether to use
Stateless Automatic Address Configuration (SLAAC), <xref
target="RFC4862"/>, or Dynamic Host Configuration Protocol for IPv6
(DHCPv6), <xref target="RFC3315"/>, or a combination thereof (possible
when using a /64 subnet). Each option has its own unique set of pros
and cons and the choice will ultimately depend on the operational
policies that guide each enterprise's network design. For example, if
an enterprise is looking for ease of use, rapid deployments, and less
administrative overhead, then SLAAC makes more sense. However, if the
operational policies call for precise control over IP address
assignment for auditing then DHCPv6 would be the way to go. DHCPv6
also allows you tie into DNS systems for host entry updates and gives
you the ability to send other options information to clients. In the
long term, DHCPv6 makes most sense for use in a managed
environment.</t>
</section>
<section title="End user devices">
<t>Most operating systems (OS) that are loaded on workstations and
laptops in a typical enterprise support IPv6 today. However, there are
various out-of-the-box nuances that one should be mindful about. For
example, the default behavior of OSes vary, some may have IPv6 turned
off entirely by default, some may only have certain features such as
privacy addresses turned off while others have IPv6 fully enabled. It
is important to note that most operating systems will, by default,
prefer to use native IPv6 over IPv4 when enabled. Therefore, it is
advised that enterprises investigate the default behavior of their
installed OS base and account for it during the implementation of
IPv6. Furthermore, some OSes may have tunneling mechanisms turned on
by default and in such cases, it is recommended to administratively
shut down such interfaces unless required. It is recommended that IPv6
be deployed at the network infrastructure level before it is rolled
out to end user devices.</t>
<t>Smartphones and tablets are poised to become one of the major
consumers of IP addresses and enterprises should be ready to deploy
and support IPv6 on various networks that serve such devices. In
general, support for IPv6 in these devices, albeit in its infancy, has
been steadily rising. Most of the leading smartphone OSes have some
level of support for IPv6. However, the level of configurable options
are mostly at a minimum and are not consistent across all platforms.
Also, it is fairly common to find IPv6 support on the wifi connection
alone and not on the radio interface in these devices. This is
sometimes due to the radio network not being ready or device related.
An IPv6 enabled enterprise wifi network will allow the majority of
these devices to connect via IPv6. Much work is still being done to
bring the full IPv6 feature set across all interfaces (802.11, 3G,
LTE, etc.) and platforms.</t>
<t>IPv6 support in peripheral equipment such as printers, IP Cameras,
etc. has been steadily rising as well, although at a much slower pace
than traditional OSes and Smartphones. Most newer devices are coming
out with IPv6 support but there is still a large installed base of
legacy peripheral devices that might need IPv4 for sometime to come.
The audit phase mentioned earlier will make it easier for enterprises
to plan for equipment upgrades, in line with their corporate equipment
refresh cycle.</t>
</section>
<section title="Corporate Systems">
<t>No IPv6 deployment will be successful without ensuring that all the
corporate systems that enterprise uses as part of their IT
infrastructure, support IPv6. Examples of such systems include, but
are not limited to, Email, Video Conferencing, Telephony (VoIP), DNS,
Radius, etc. All these systems must have their own detailed IPv6
rollout plan in conjunction with the network IPv6 rollout. It is
important to note that DNS is one of the main anchors in an enterprise
deployment, since most end hosts decide whether or not use IPv6 based
on the presence of AAAA records in a reply to a DNS query. It is
recommended that system administrators selectively turn on AAAA
records for various systems as and when they are IPv6 enabled.
Additionally, all monitoring and reporting tools across the enterprise
would need to be modified to support IPv6.</t>
</section>
<section title="Security">
<t>IPv6 must be deployed in a secure way. This means that all existing
IPv4 security policies must be extended to support IPv6; IPv6 security
policies will be the IPv6 equivalent of the existing IPv4 ones (taking
into account the difference for <xref target="RFC4890">ICMPv6</xref>).
As in IPv4, security policies for IPv6 will be enforced by firewalls,
ACL, IPS, VPN, ...</t>
<t><xref target="RFC4941">Privacy extension addresses</xref> pose a
real challenge for audit trail as explained in section <xref
target="ipv6_security_specifics"/>.</t>
<t>But, the biggest problem is probably linked to all threats against
Neighbor Discovery. This means that the internal network at the access
layer (i.e. where hosts connect to the network over wired or wireless)
must implement <xref target="RFC6105">RA-guard</xref> and the
techniques being specified by <xref
target="I-D.ietf-savi-threat-scope">SAVI WG</xref>; see also <xref
target="ipv6_security_specifics"/> for more information.</t>
</section>
</section>
<section title="Other Phases">
<t>To be added.</t>
<section title="Guest network">
<t>To be added.</t>
</section>
<section title="IPv6-only">
<t>Although IPv4 and IPv6 networks will coexist for a long time to
come, the long term enterprise network roadmap should include steps on
gradually deprecating IPv4 from the dual-stack network. In some
extreme cases, deploying dual-stack networks may not even be a viable
option for very large enterprises due to lack of availability of RFC
1918 addresses. In such cases, deploying IPv6-only networks might be
the only choice available to sustain network growth.</t>
<t>If nodes in the network don't need to talk to an IPv4-only node,
then deploying IPv6-only networks should fe fairly trivial. However,
in the current environment, given that IPv4 is the dominant protocol
on the Internet, an IPv6-only node most likely needs to talk to an
IPv4-only node on the Internet. It is therefore important to provide
such nodes with a translation mechanism to ensure communication
between nodes configured with different address families. As <xref
target="RFC6144"/> points out, it is important to look at address
translation as a transition strategy that will get you to an IPv6-only
network.</t>
<t>There are various stateless and stateful IPv4/IPv6 translation
methods available today that help IPv4 to IPv6 communication. RFC 6144
provides a framework for IPv4/IPv6 translation and describes in detail
various scenarios in which such translation mechanisms could be used.
<xref target="RFC6145"/> describes stateless address translation. In
this mode, a specific IPv6 address range will represent IPv4 systems
(IPv4-converted addresses), and the IPv6 systems have addresses
(IPv4-translateable addresses) that can be algorithmically mapped to a
subset of the service provider's IPv4 addresses. <xref
target="RFC6146"/>, NAT64, describes stateful address translation. As
the name suggests, the translation state is maintained between IPv4
address/port pairs and IPv6 address/port pairs, enabling IPv6 systems
to open sessions with IPv4 systems. <xref target="RFC6147"/>, DNS64,
describes a mechanism for synthesizing AAAA resource records (RRs)
from A RRs. Together, RFCs 6146 and RFC 6147 provide a viable method
for an IPv6-only client to initiate communications to an IPv4-only
server.</t>
<t>The address translation mechanisms for the stateless and stateful
translations are defined in <xref target="RFC6052"/>. It is important
to note that both of these mechanisms have limitations as to which
protocols they support. For example, RFC 6146 only defines how
stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP
traffic only. The ultimate choice of which translation mechanism to
chose will be dictated mostly by existing operational policies
pertaining to application support, logging requirements, etc.</t>
<t>There is additional work being done in the area of address
translation to enhance and/or optimize current mechanisms. For
example, <xref target="I-D.xli-behave-divi"/> describes limitations
with the current stateless translation, such as IPv4 address sharing
and application layer gateway (ALG) problems, and presents the concept
and implementation of dual-stateless IPv4/IPv6 translation (dIVI) to
address those issues.</t>
</section>
</section>
<section title="Considerations For Specific Enterprises">
<t/>
<section title="Content Delivery Networks">
<t>To be added.</t>
</section>
<section title="Data Center Virtualization">
<t>Another document (<xref target="I-D.lopez-v6ops-dc-ipv6"/>)
describes in details the specifics about IPv6 Data Center.</t>
</section>
<section title="Campus Networks">
<t>A number of campus networks have made some initial IPv6 deployment.
There are generally three areas in which such deployments may be made,
which correspond to the Internal Phase, External Phase and Other Phase
(Guest Network) descrobed above.</t>
<t>In particular the areas commonly approached are:</t>
<t><list style="symbols">
<t>External-facing services. Typically the campus web presence and
commonly also external-facing DNS and MX services.</t>
<t>Computer science department. This is where IPv6-related
research and/or teaching is most likely to occur, so enabling some
or all of the campus compauter science department network is a
sensible first step.</t>
<t>The eduroam wireless network. Eduroam is the defacto wireless
roaming system for academic networks, and uses 802.1X based
authentication, which is agnostic to the IP version used (unlike
web-redirection gateway systems).</t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>This document has multiple security sections detailing how do
securely deploy an IPv6 network within an enterprise network.</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Chris Grundemann, Ray Hunter, Brian
Carpenter, Tina Tsou for their comments on the mailing list.</t>
</section>
<section title="IANA Considerations">
<t>There are no IANA considerations or implications that arise from this
document.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informative References">
&rfc1918;
&rfc2011;
&rfc2096;
&rfc2827;
&rfc3315;
&rfc3971;
&rfc3972;
&rfc4057;
&rfc4193;
&rfc4213;
&rfc4293;
&rfc4296;
&rfc4364;
&rfc4443;
&rfc4659;
&rfc4861;
&rfc4862;
&rfc4890;
&rfc4941;
&rfc5095;
&rfc5102;
&rfc5157;
&rfc5211;
&rfc5214;
&rfc5375;
&rfc5722;
&rfc5798;
&rfc5952;
&rfc6052;
&rfc6104;
&rfc6105;
&rfc6144;
&rfc6145;
&rfc6146;
&rfc6147;
&rfc6164;
&rfc6192;
&rfc6302;
&rfc6434;
&I-D.xli-behave-divi;
&I-D.gashinsky-v6ops-v6nd-problems;
&I-D.ietf-savi-threat-scope;
&I-D.lopez-v6ops-dc-ipv6;
&I-D.templin-v6ops-isops;
&I-D.matthews-v6ops-design-guidelines;
&I-D.vyncke-opsec-v6;
<reference anchor="SMURF"
target="http://www.cert.org/advisories/CA-1998-01.html">
<front>
<title>CERT Advisory CA-1998-01 Smurf IP Denial-of-Service
Attacks</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="CYMRU"
target="http://www.team-cymru.org/Services/Bogons/">
<front>
<title>THE BOGON REFERENCE</title>
<author/>
<date/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:47:02 |