draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt   draft-ietf-v6ops-enterprise-incremental-ipv6-02.txt 
v6ops K. Chittimaneni Network Working Group K. Chittimaneni
Internet-Draft Google Inc. Internet-Draft Google Inc.
Intended status: Informational T. Chown Intended status: Informational T. Chown
Expires: March 19, 2013 University of Southampton Expires: August 29, 2013 University of Southampton
L. Howard L. Howard
Time Warner Cable Time Warner Cable
V. Kuarsingh V. Kuarsingh
Rogers Communications Rogers Communications
Y. Pouffary Y. Pouffary
Hewlett Packard Hewlett Packard
E. Vyncke E. Vyncke
Cisco Systems Cisco Systems
September 15, 2012 February 25, 2013
Enterprise IPv6 Deployment Guidelines Enterprise IPv6 Deployment Guidelines
draft-ietf-v6ops-enterprise-incremental-ipv6-01 draft-ietf-v6ops-enterprise-incremental-ipv6-02
Abstract Abstract
Enterprise network administrators worldwide are in various stages of Enterprise network administrators worldwide are in various stages of
preparing for or deploying IPv6 into their networks. The preparing for or deploying IPv6 into their networks. The
administrators face different challenges than operators of Internet administrators face different challenges than operators of Internet
access providers, and have reasons for different priorities. The access providers, and have reasons for different priorities. The
overall problem for many administrators will be to offer Internet- overall problem for many administrators will be to offer Internet-
facing services over IPv6, while continuing to support IPv4, and facing services over IPv6, while continuing to support IPv4, and
while introducing IPv6 access within the enterprise IT network. The while introducing IPv6 access within the enterprise IT network. The
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 19, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . . 4 1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . . 4
1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . . 5 1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . . 5
1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 5 1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 2. Preparation and Assessment Phase . . . . . . . . . . . . . . . 7
3. Preparation and Assessment Phase . . . . . . . . . . . . . . . 6 2.1. Program Planning . . . . . . . . . . . . . . . . . . . . . 7
3.1. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 6 2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Network infrastructure readiness assessment . . . . . 6 2.2.1. Network infrastructure readiness assessment . . . . . 8
3.1.2. Applications readiness assessment . . . . . . . . . . 7 2.2.2. Applications readiness assessment . . . . . . . . . . 9
3.1.3. Importance of readiness validation and testing . . . . 7 2.2.3. Importance of readiness validation and testing . . . . 10
3.2. Training . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 10
3.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 8 2.4.1. IPv6 is no more secure than IPv4 . . . . . . . . . . . 10
3.4.1. Demystifying some IPv6 Security Myths . . . . . . . . 8 2.4.2. Similarities between IPv6 and IPv4 security . . . . . 11
3.4.2. Similarities between IPv6 and IPv4 security . . . . . 9 2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 12
3.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 10 2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Address Plan . . . . . . . . . . . . . . . . . . . . . . . 11 2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . . 14
3.6. Program Planning . . . . . . . . . . . . . . . . . . . . . 12 2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . . 16
3.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . . 13 3. External Phase . . . . . . . . . . . . . . . . . . . . . . . . 17
4. External Phase . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4. Servers and Applications . . . . . . . . . . . . . . . . . 20
4.4. Servers and Applications . . . . . . . . . . . . . . . . . 17 3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 20
5. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Network Infrastructure . . . . . . . . . . . . . . . . . . 17 4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.2. End user devices . . . . . . . . . . . . . . . . . . . . . 19 4.2. Network Infrastructure . . . . . . . . . . . . . . . . . . 22
5.3. Corporate Systems . . . . . . . . . . . . . . . . . . . . 20 4.3. End user devices . . . . . . . . . . . . . . . . . . . . . 23
5.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 24
6. Other Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. Guest network . . . . . . . . . . . . . . . . . . . . . . 21 6. Considerations For Specific Enterprises . . . . . . . . . . . 26
6.2. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 26
7. Considerations For Specific Enterprises . . . . . . . . . . . 22 6.2. Data Center Virtualization . . . . . . . . . . . . . . . . 26
7.1. Content Delivery Networks . . . . . . . . . . . . . . . . 22 6.3. University Campus Networks . . . . . . . . . . . . . . . . 26
7.2. Data Center Virtualization . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7.3. Campus Networks . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 10. Informative References . . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
An Enterprise Network as defined in [RFC4057] as: a network that has An Enterprise Network is defined in [RFC4057] as a network that has
multiple internal links, one or more router connections to one or multiple internal links, one or more router connections to one or
more Providers, and is actively managed by a network operations more Providers, and is actively managed by a network operations
entity (the "administrator", whether a single person or department of entity (the "administrator", whether a single person or department of
administrators). Adminstrators generally support an internal administrators). Administrators generally support an internal
network, consisting of users' computers and related peripherals, a network, consisting of users' workstations, personal computers, other
server network, consisting of accounting and business application computing devices and related peripherals, a server network,
servers, and an external network, consisting of Internet-accessible consisting of accounting and business application servers, and an
services such as web servers, email servers, VPN systems, and external network, consisting of Internet-accessible services such as
customer applications. This document is intended as guidance for web servers, email servers, VPN systems, and customer applications.
network architects and administrators in planning their IPv6 This document is intended as guidance for network architects and
deployments. administrators in planning their IPv6 deployments.
The business reasons for spending time, effort, and money on IPv6 The business reasons for spending time, effort, and money on IPv6
will be unique to each enterprise. The most common drivers are due will be unique to each enterprise. The most common drivers are due
to the fact that when Internet service providers, including mobile to the fact that when Internet service providers, including mobile
wireless carriers, run out of IPv4 addresses, they will provide wireless carriers, run out of IPv4 addresses, they will provide
native IPv6 and non-native IPv4. The non-native IPv4 service may be native IPv6 and non-native IPv4. The non-native IPv4 service may be
NAT64, NAT444, Dual-stack Lite, or other transition technology, but NAT64, NAT444, Dual-stack Lite, or other transition technologies.
whether tunneled or translated, the native traffic will be perform Compared to tunneled or translated, native traffic typically performs
better and more reliably than non-native. It is thus in the better and more reliably than non-native. For example, for client
enterprise's interests to deploy native IPv6 itself. networks trying to reach enterprise networks, the IPv6 experience
will be better than the transitional IPv4 if the enterprise deploys
IPv6 in its public-facing services. The native IPv6 network path
should also be simpler to manage and, if necessary, troubleshoot.
Further, enterprises doing business in growing parts of the world may
find IPv6 growing faster there, where again potential new customers,
employees and partners are using IPv6. It is thus in the
enterprise's interests to deploy native IPv6, at the very least in
its public-facing services, but ultimately across the majority or all
of its scope.
The text in this document provides specific guidance for enterprise
networks, and complements other related work in the IETF, including
[I-D.ietf-v6ops-design-choices] and [RFC5375].
1.1. Enterprise Assumptions 1.1. Enterprise Assumptions
For the purposes of this document, assume: For the purpose of this document, we assume:
o The administrator is considering deploying IPv6 (but see o The administrator is considering deploying IPv6 (but see
Section 1.2 below). Section 1.2 below).
o The administrator has existing IPv4 networks and devices which o The administrator has existing IPv4 networks and devices which
will continue to exist. will continue to operate and be supported.
o The administrator will want to minimize the level of disruption to o The administrator will want to minimize the level of disruption to
the users and services by minimizing number of technologies and the users and services by minimizing number of technologies and
functions that are needed to mediate any given application. In functions that are needed to mediate any given application. In
other words, provide native IP wherever possible. other words, provide native IP wherever possible.
Based on these assumptions, an administrator will want to use Based on these assumptions, an administrator will want to use
technologies which minimize the number of flows being tunnelled, technologies which minimize the number of flows being tunnelled,
translated or intercepted at any given time. The administrator will translated or intercepted at any given time. The administrator will
choose transition technologies or strategies which allow most traffic choose transition technologies or strategies which allow most traffic
skipping to change at page 5, line 11 skipping to change at page 5, line 25
the administrator to minimize the cost of IPv6 transition the administrator to minimize the cost of IPv6 transition
technologies, by containing the number and scale of transition technologies, by containing the number and scale of transition
systems. systems.
1.2. IPv4-only Considerations 1.2. IPv4-only Considerations
As described in [RFC6302] administrators should take certain steps As described in [RFC6302] administrators should take certain steps
even if they are not considering IPv6. Specifically, Internet-facing even if they are not considering IPv6. Specifically, Internet-facing
servers should log the source port number, timestamp (from a reliable servers should log the source port number, timestamp (from a reliable
source), and the transport protocol. This will allow investigation source), and the transport protocol. This will allow investigation
of malefactors behind address-sharing technologies such as NAT44 or of malefactors behind address-sharing technologies such as NAT444 or
Dual-stack Lite. Enabling this additional logging will take a few Dual-stack Lite.
minutes on each server, and will probably require restarting the
service.
Other IPv6 considerations may impact ostensibly IPv4-only networks, Other IPv6 considerations may impact ostensibly IPv4-only networks,
e.g. [RFC6104] describes the rogue IPv6 RA problem, which may cause e.g. [RFC6104] describes the rogue IPv6 RA problem, which may cause
problems in IPv4-only networks where IPv6 is enabled in end systems problems in IPv4-only networks where IPv6 is enabled in end systems
on that network. on that network. Further discussion of the security implications of
IPv6 in IPv4-only networks can be found in
[I-D.ietf-opsec-ipv6-implications-on-ipv4-nets]).
1.3. Reasons for a Phased Approach 1.3. Reasons for a Phased Approach
Given the challenges of migrating user workstations, corporate Given the challenges of transitioning user workstations, corporate
systems, and Internet-facing servers, a phased approach allows systems, and Internet-facing servers, a phased approach allows
incremental deployment of IPv6, based on the administrator's own incremental deployment of IPv6, based on the administrator's own
determination of priorities. The Preparation Phases is highly determination of priorities. The Preparation Phase is highly
recommended to all administrators, as it will save errors and recommended to all administrators, as it will save errors and
complexity in later phases. Each administrator must decide whether complexity in later phases. Each administrator must decide whether
to begin with the External Phase (as recommended in [RFC5211]) or the to begin with the External Phase (as recommended in [RFC5211]) or the
Internal Phase. There is no "correct" answer here; the decision is Internal Phase. There is no "correct" answer here; the decision is
one for each enterprise to make. one for each enterprise to make.
Some considerations: Each scenario is likely to be different to some extent, but we can
highlight some considerations:
o In many cases, customers outside the network will have IPv6 before o In many cases, customers outside the network will have IPv6 before
the internal enterprise network. For these customers, IPv6 may the internal enterprise network. For these customers, IPv6 may
well perform better, especially for certain applications, than well perform better, especially for certain applications, than
translated or tunneled IPv4, so the administrator may want to translated or tunneled IPv4, so the administrator may want to
prioritize the External Phase. prioritize the External Phase such that those customers have the
simplest and most robust connectivity to the enterprise, or at
least its external-facing elements.
o Employees who access internal systems by VPN may find that their o Employees who access internal systems by VPN may find that their
ISPs provide translated IPv4, which does not support the required ISPs provide translated IPv4, which does not support the required
VPN protocols. In these cases, the administrator may want to VPN protocols. In these cases, the administrator may want to
prioritize the External Phase, and any other remotely-accessible prioritize the External Phase, and any other remotely-accessible
internal systems. internal systems. It is worth noting that a number of emerging
VPN solutions provide dual-stack connectivity; thus a VPN service
may be useful for employees in IPv4-only access networks to access
IPv6 resources in the enterprise network (much like many public
tunnel broker services, but specifically for the enterprise).
o Internet-facing servers cannot be managed over IPv6 unless the o Internet-facing servers cannot be managed over IPv6 unless the
management systems are IPv6-capable. These might be Network management systems are IPv6-capable. These might be Network
Management Systems (NMS), monitoring systems, or just remote Management Systems (NMS), monitoring systems, or just remote
management desktops. Thus in some cases, the Internet-facing management desktops. Thus in some cases, the Internet-facing
systems are dependent on IPv6-capable internal networks. However, systems are dependent on IPv6-capable internal networks. However,
dual-stack Internet-facing systems can still be managed over IPv4. dual-stack Internet-facing systems can still be managed over IPv4.
o Virtual machines may enable a faster rollout once initial system
deployment is complete. Management of VMs over IPv6 is still
dependent on the management software supporting IPv6.
o IPv6 is enabled by default on all modern operating systems, so it o IPv6 is enabled by default on all modern operating systems, so it
may be more urgent to manage and have visibility on the internal may be more urgent to manage and have visibility on the internal
traffic. traffic. It is important to manage IPv6 for security purposes,
even in an ostensibly IPv4-only network, as described in
[I-D.ietf-opsec-ipv6-implications-on-ipv4-nets].
o In many cases, the corporate accounting, payroll, human resource, o In many cases, the corporate accounting, payroll, human resource,
and other internal systems may only need to be reachable from the and other internal systems may only need to be reachable from the
internal network, so they may be a lower priority. But more and internal network, so they may be a lower priority. As enterprises
more internal applications support IPv6 by default and it can be require their vendors to support IPv6, more internal applications
expected that new applications will only support IPv6. will support IPv6 by default and it can be expected that
eventually new applications will only support IPv6. The
inventory, as described in Section 2.2, will help determine the
systems' readiness, as well as the readiness of the supporting
network elements and security, which will be a consideration in
prioritization of these corporate systems.
o Some organizations (even when using private IPv4 o Some large organizations (even when using private IPv4
addresses[RFC1918]) are facing IPv4 address exhaustion because of addresses[RFC1918]) are facing IPv4 address exhaustion because of
the internal network growth (for example the vast number of the internal network growth (for example the vast number of
virtual machines). virtual machines) or because of the acquisition of other companies
that often raise private IPv4 address overlapping issues.
o IPv6 restores end to end reachability even for internal o IPv6 restores end to end transparency even for internal
applications (of course security policies must still be enforced) applications (of course security policies must still be enforced).
which means that with IPv6 merging networks (after two When two organizations or networks merge
organizations merged) is much easier and faster. Yet, another [I-D.ietf-6renum-enterprise], the unique addressing of IPv6 can
reason to move the internal network to IPv6. make the merger much easier and faster. A merger may, therefore,
prioritize IPv6 for the affected systems.
These considerations are in conflict; each administrator must These considerations are in conflict; each administrator must
prioritize according to their local conditions. prioritize according to their company's conditions. It is worth
noting that the reasons given in one "Large Corporate User's View of
IPng", described in [RFC1687], for reluctance to deploy have largely
been satisfied or overcome in the intervening 18 years.
2. Requirements Language 2. Preparation and Assessment Phase
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 2.1. Program Planning
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [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.
3. Preparation and Assessment Phase 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, people and other resources are
committed 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, the
corresponding milestones and deliverables, 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. It may be necessary to complete the
Preparation Phase before determining which of the other phases will
be prioritized, since needs and readiness assessments are part of
that phase.
3.1. Inventory Phase The project manager will need to spend some time on 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 alternative products from other
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.
To comprehend the inventory phase spectrum we recommended dividing It is tempting to roll IPv6 projects into other architectural
the problem space in two: network infrastructure readiness and upgrades - this can be an excellent way to improve the network and
applications readiness. 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.
3.1.1. Network infrastructure readiness assessment The deployment of IPv6 will not generally stop all other technology
work. Once IPv6 has been identified as an important initiative, all
projects will need to evaluate their ability to support IPv6. If
expansions or new deployments fail to include IPv6, then additional
work will be required after all initial IPv6 has been completed. It
may not be possible to delay regular projects for IPv6, if their IPv6
support is dependent on network elements that have not yet been
upgraded, but the projects need to include a return to IPv6 support
in their eventual timeline.
The network infrastructure readiness assessment for IPv6 as its name It is very common for assessments to continue in some areas even as
state is focused on the network. The goal of this assessment is execution of the project begins in other areas. This is fine, as
identify the level of readiness of network equipment. This is an long as recommendations in other parts of this document are
important step as it will help identify the effort required to move considered, especially regarding security (for instance, one should
to an infrastructure that supports IPv6 with the same features as the not deploy IPv6 on a system before security has been evaluated). The
existing IPv4 network (for example MPLS-VPN [RFC4364] whose project manager will need to continue monitoring the progress of
equivalent in IPv6 is 6VPE [RFC4659]). 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.
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.
2.2. Inventory Phase
To comprehend the scope of the inventory phase we recommended
dividing the problem space in two: network infrastructure readiness
and applications readiness.
2.2.1. Network infrastructure readiness assessment
The goal of this assessment is to identify the level of IPv6
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 functional service capabilities as the
existing IPv4 network. This may also require a feature comparison
and gap analysis between IPv4 and IPv6 functionality on the network
equipment and software.
Be able to understand which network devices are already capable, Be able to understand which network devices are already capable,
which devices can be made IPv6 ready with a code/firmware upgrade, which devices can be made IPv6 ready with a code/firmware upgrade,
and which devices will need to be replaced. The data collection and which devices will need to be replaced. The data collection
consists of a network discovery to gain an understanding of the consists of a network discovery to gain an understanding of the
topology and inventory network infrastructure equipment and code topology and inventory network infrastructure equipment and code
versions with information gathered from static files and IP address versions with information gathered from static files and IP address
management, DNS and DHCP tools. management, DNS and DHCP tools.
Remember understanding the starting point and what are the technical Since IPv6 might already be present in the environment, through
issues and challenges is critical as IPv6 might already be present in default configurations or VPNs, an infrastructure assessment (at
the environment thus creating inherent security risks. minimum) is essential to evaluate potential security risks.
3.1.2. Applications readiness assessment 2.2.2. Applications readiness assessment
Just like network equipment, application software needs to support Just like network equipment, application software needs to support
IPv6. This includes OS, firmware, middleware and applications IPv6. This includes OS, firmware, middleware and applications
(including internally developed applications). Vendors will (including internally developed applications). Vendors will
typically handle IPv6 enablement of off-the-shelf products. typically handle IPv6 enablement of off-the-shelf products, but often
Enterprises need to request this support from vendors. For enterprises need to request this support from vendors. For
internally developed applications it is the responsibility of the internally developed applications it is the responsibility of the
enterprise to enable them for IPv6. Analyzing how a given enterprise to enable them for IPv6. Analyzing how a given
application communicates of the network will dictate the steps application communicates over the network will dictate the steps
required to support IPv6. Applications should be made to use APIs required to support IPv6. Applications should be made to use APIs
which hide the specifics of a given IP address family. Any which hide the specifics of a given IP address family. Any
applications that use APIs, such as the C language, which exposes the applications that use APIs, such as the C language, which exposes the
IP version specificity need to be modified to also work with IPv6. IP version specificity, need to be modified to also work with IPv6.
There are two ways to IPv6-enable your applications. The first There are two ways to IPv6-enable applications. The first approach
approach is to have separate logic for IPv4 and IPv6, thus leaving is to have separate logic for IPv4 and IPv6, thus leaving the IPv4
the IPv4 code path mainly untouched. This approach causes the least code path mainly untouched. This approach causes the least
disruption to the existing IPv4 logic flow, but introduces more disruption to the existing IPv4 logic flow, but introduces more
complexity, since the application now has to deal with two logic complexity, since the application now has to deal with two logic
loops with complex race conditions and error recovery mechanisms loops with complex race conditions and error recovery mechanisms
between these two logic loops. The second approach is to create a between these two logic loops. The second approach is to create a
combined IPv4/IPv6 logic, which ensures operation regardless of the combined IPv4/IPv6 logic, which ensures operation regardless of the
IP version used on the network. We recommend using industry IPv6- IP version used on the network. Knowing whether a given
porting tools to locate the code that need to be updated. implementation will use IPv4 or IPv6 in a given deployment is a
matter of some art; see Source Address Selection[RFC6724] and Happy
Eyeballs [RFC6555]. It is generally recommend that the application
developer use industry IPv6-porting tools to locate the code that
needs to be updated. Some discussion of IPv6 application porting
issues can be found in [RFC4038].
3.1.3. Importance of readiness validation and testing 2.2.3. Importance of readiness validation and testing
Lastly IPv6 introduces a completely new way of addressing endpoints, Lastly IPv6 introduces a completely new way of addressing endpoints,
which can have ramifications at the network layer all the way up to which can have ramifications at the network layer all the way up to
the applications. So to minimize disruption during the transition the applications. So to minimize disruption during the transition
phase we recommend complete functionality, scalability and security phase we recommend complete functionality, scalability and security
testing to understand how IPv6 impacts the services and networking testing to understand how IPv6 impacts the services and networking
infrastructure will be paramount. infrastructure.
3.2. Training
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.
3.3. Routing
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.
Enterprises could also take the opportunity the introduction of IPv6 2.3. Training
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.
Either way IPv6 introduces the opportunity to rationalize the IPv6 planning and deployment in the enterprise does not only affect
environment and to architect it for growth. the network. IPv6 adoption will be a multifaceted undertaking that
will touch everyone in the organization unlike almost any other
project. While technology and process transformations are taking
place, it is critical that personnel 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.
Better knowledge of the requirements to deploy IPv6 may also help
inform procurement processes.
3.4. Security Policy 2.4. Security Policy
It is obvious that IPv6 network should be deployed in a secure way. It is obvious that IPv6 networks should be deployed in a secure way.
The industry has learned a lot about network security with IPv4, so, The industry has learnt a lot about network security with IPv4, so,
network operators should leverage this knowledge and expertise when network operators should leverage this knowledge and expertise when
deploying IPv6. IPv6 is not so different than IPv4: it is a deploying IPv6. IPv6 is not so different than IPv4: it is a
connectionless network protocol using the same lower layer service connectionless network protocol using the same lower layer service
and delivering the same service to the upper layer. Therefore, the and delivering the same service to the upper layer. Therefore, the
security issues and mitigation techniques are mostly identical with security issues and mitigation techniques are mostly identical with
same exceptions that are described further. same exceptions that are described further.
3.4.1. Demystifying some IPv6 Security Myths 2.4.1. IPv6 is no more secure than IPv4
Some people believe that IPv6 is inherently more secure than IPv4 Some people believe that IPv6 is inherently more secure than IPv4
because it is new. Nothing can be more wrong. Indeed, being a new because it is new. Nothing can be more wrong. Indeed, being a new
protocol means that bugs in the implementations have yet to be protocol means that bugs in the implementations have yet to be
discovered and fixed and that few people have the operational discovered and fixed and that few people have the operational
security expertise needed to operate securely an IPv6 network. This security expertise needed to operate securely an IPv6 network. This
lack of operational expertise is the biggest threat when deploying lack of operational expertise is the biggest threat when deploying
IPv6: the importance of training is to be stressed again. IPv6: the importance of training is to be stressed again.
One security myth is that thanks to its huge address space, a network 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 cannot be scanned by enumerating all IPv6 address in a /64 LAN hence
a malevolent person cannot find a victim. [RFC5157] describes some a malevolent person cannot find a victim. [RFC5157] describes some
alternate techniques to find potential targets on a network, for alternate techniques to find potential targets on a network, for
example enumerating all DNS names in a zone. example enumerating all DNS names in a zone. Additional advice in
this area is also given in [I-D.ietf-opsec-ipv6-host-scanning].
Another security myth is that IPv6 is more secure because it mandates Another security myth is that IPv6 is more secure because it mandates
the use of IPsec everywhere. [RFC6434] clearly states that the IPv6 the use of IPsec everywhere. While the original IPv6 specifications
support is a SHOULD only. Moreover, if all the intra-enterprise may have implied this, [RFC6434] clearly states that IPsec support is
traffic is encrypted, then this renders a lot of the network security not mandatory. Moreover, if all the intra-enterprise traffic is
tools (IPS, firewall, ACL, IPFIX, etc) blind and pretty much useless. 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 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 example to establish a VPN overlay over a non-trusted network or
reserved for some specific applications). reserved for some specific applications).
The last security myth is that amplification attacks (such as The last security myth is that amplification attacks (such as
[SMURF]) do not exist in IPv6 because there is no more broadcast. [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 Alas, this is not true as ICMP error (in some cases) or information
messages can be generated by routers and hosts when forwarding or messages can be generated by routers and hosts when forwarding or
receiving a multicast message (section 2.4 of [RFC4443]). Therefore, receiving a multicast message (see Section 2.4 of [RFC4443]).
the generation and the forwarding rate of ICMPv6 messages must be Therefore, the generation and the forwarding rate of ICMPv6 messages
limited as in IPv4. must be limited as in IPv4.
3.4.2. Similarities between IPv6 and IPv4 security It should be noted that in a dual-stack network the security
implementation for both IPv4 and IPv6 needs to be considered, in
addition to security considerations related to the interaction of
(and transition between) the two, while they coexist.
2.4.2. Similarities between IPv6 and IPv4 security
As mentioned earlier, IPv6 is quite similar to IPv4, therefore As mentioned earlier, IPv6 is quite similar to IPv4, therefore
several attacks apply for both protocol family: several attacks apply for both protocol families:
o Application layer attacks: such as cross-site scripting or SQL o Application layer attacks: such as cross-site scripting or SQL
injection injection
o Rogue device: such as a rogue WiFi Access Point o Rogue device: such as a rogue Wi-Fi Access Point
o Flooding and all traffic based denial of services (including the o Flooding and all traffic-based denial of services (including the
use of control plane policing for IPv6 traffic see [RFC6192]) use of control plane policing for IPv6 traffic see [RFC6192])
o Etc o Etc.
A specific case of congruence is the IPv6 ULA [RFC4193] and IPv4 A specific case of congruence is IPv6 Unique Local Addresses (ULAs)
private addressing [RFC1918] that do not provide any security by [RFC4193] and IPv4 private addressing [RFC1918], which do not provide
'magic'. In both case, the edge router must apply strict data plane any security by 'magic'. In both cases, the edge router must apply
and routing policy to block those private addresses to leave and strict filters to block those private addresses from entering and,
enter the network. This filtering can be done by the enterprise or just as importantly, leaving the network. This filtering can be done
by the ISP. by the enterprise or by the ISP, but the cautious administrator will
prefer to do it in the enterprise.
IPv6 addresses can be spoofed as easily as IPv4 addresses and there IPv6 addresses can be spoofed as easily as IPv4 addresses and there
are packets with bogons IPv6 addresses (see [CYMRU]). The anti-bogon are packets with bogon IPv6 addresses (see [CYMRU]). Anti-bogon
filtering must be done in the data and routing planes. It can be filtering must be done in the data and routing planes. It can be
done by the enterprise or by the ISP. done by the enterprise or by the ISP, or both, but again the cautious
administrator will prefer to do it in the enterprise.
3.4.3. Specific Security Issues for IPv6 2.4.3. Specific Security Issues for IPv6
Even if IPv6 is similar to IPv4, there are some differences that Even if IPv6 is similar to IPv4, there are some differences that
create some IPv6-only vulnerabilities or issues. create some IPv6-only vulnerabilities or issues. We give examples of
such differences in this section.
Privacy extension addresses [RFC4941] are usually to protect Privacy extension addresses [RFC4941] are usually used to protect
individual privacy by changing periodically the interface identifier individual privacy by periodically changing the interface identifier
part of the IPv6 address to avoid tracking a host by its always part of the IPv6 address to avoid tracking a host by its otherwise
identical and unique EUI-64. While this presents a real advantage on always identical and unique MAC-based EUI-64. While this presents a
the Internet, it complicates the task of audit trail when a security real advantage on the Internet, moderated by the fact that the prefix
officer or network operator wants to trace back a log entry to a host part remains the same, it complicates the task of following an audit
in their network because when the tracing is done the searched IPv6 trail when a security officer or network operator wants to trace back
address could have disappeared from the network. Therefore, the use a log entry to a host in their network, because when the tracing is
of privacy extension addresses usually requires an additional done the searched IPv6 address could have disappeared from the
monitoring and logging of the binding of the IPv6 address to a data- network. Therefore, the use of privacy extension addresses usually
link layer address (see also the monitoring section of requires additional monitoring and logging of the binding of the IPv6
[I-D.vyncke-opsec-v6]). An alternative is to try to prevent the use address to a data-link layer address (see also the monitoring section
of privacy extension addresses is to send the Router Advertisement of [I-D.ietf-opsec-v6]). Some early enterprise deployments have
with the M-bit set (to force the use of DHCPv6 to get an address) and taken the approach to use tools that harvest IP/MAC address mappings
with all advertized prefixes without the A-bit set (to prevent the from switch and router devices to provide address accountability;
use of stateless auto-configuration); this technique requires that this approach has been shown to work, though it can involve gathering
all hosts support stateful DHCPv6. significantly more address data than in equivalent IPv4 networks. An
alternative is to try to prevent the use of privacy extension
addresses by enforcing the use of DHCPv6, such that hosts only get
addresses assigned by a DHCPv6 server. This can be done by
configuring routers to set the M-bit in Router Advertisements,
combined with all advertised prefixes being included without the
A-bit set (to prevent the use of stateless auto-configuration). This
technique of course requires that all hosts support stateful DHCPv6.
Extension headers complicate the task of stateless packet filters Extension headers complicate the task of stateless packet filters
such as ACL. If ACL are used to enforce a security policy, then the such as ACLs. If ACLs are used to enforce a security policy, then
enterprise must verify whether its ACL (but also stateful firewalls) the enterprise must verify whether its ACL (but also stateful
are able to process extension headers (this means understand them firewalls) are able to process extension headers (this means
enough to parse them to find the upper layers payloads) and to block understand them enough to parse them to find the upper layers
unwanted extension headers (e.g. to implement [RFC5095]). payloads) and to block unwanted extension headers (e.g., to implement
[RFC5095]). This topic is discussed further in
[I-D.carpenter-6man-ext-transmit].
Fragmentation is different in IPv6 because it is done only by source Fragmentation is different in IPv6 because it is done only by source
host and never during a forwarding operation. This means that ICMPv6 host and never during a forwarding operation. This means that ICMPv6
packet-too-big must be allowed [RFC4890] through all filters. packet-too-big messages must be allowed to pass through the network
Fragments can also be used to evade some security mechanisms such as and not be filtered [RFC4890]. Fragments can also be used to evade
RA-guard [RFC6105], see also [RFC5722] which appears to be widely some security mechanisms such as RA-guard [RFC6105]. See also
implemented in 2012. [RFC5722], and [I-D.ietf-v6ops-ra-guard-implementation].
But, the biggest difference is the replacement of ARP (RFC 826) by One of the biggest differences between IPv4 and IPv6 is the
Neighbor Discovery Protocol [RFC4861]. NDP runs over ICMPv6 (this introduction of the Neighbor Discovery Protocol [RFC4861], which
means that security policies MUST allow some ICMPv6 messages see RFC includes a variety of important IPv6 protocol functions, including
4890) but has the same lack of security as ARP (SeND [RFC3971] and those provided in IPv4 by ARP [RFC0826]. NDP runs over ICMPv6 (which
CGA [RFC3972] are not widely implemented). ARP can be made secure as stated above means that security policies must allow some ICMPv6
with the help of techniques known as DHCPv4 snooping and dynamic ARP messages to pass, as described in RFC 4890), but has the same lack of
inspection by access switches. Therefore, enterprises using those security as, for example, ARP, in that there is no inherent message
techniques for IPv4 should use the equivalent techniques for IPv6: authentication. While Secure Neighbour Discovery (SeND) [RFC3971]
this is RA-guard (RFC 6105) and all work in progress from the SAVI WG and CGA [RFC3972] have been defined, they are not widely
([I-D.ietf-savi-threat-scope] and others). Another DoS implemented). The threat model for Router Advertisements within the
vulnerabilities are related to NDP cache exhaustion NDP suite is similar to that of DHCPv4 (and DHCPv6), in that a rogue
([I-D.gashinsky-v6ops-v6nd-problems]) and they can be mitigated by host could be either a rogue router or a rogue DHCP server. An IPv4
careful tuning of the NDP cache. In 2012, there are already several network can be made more secure with the help of DHCPv4 snooping in
vendors offering those features on their switches. edge switches, and likewise RA snooping can improve IPv6 network
security (in IPv4-only networks as well). Thus enterprises using
such techniques for IPv4 should use the equivalent techniques for
IPv6, including RA-guard (RFC 6105) and all work in progress from the
SAVI WG, e.g. [I-D.ietf-savi-threat-scope], which is similar to the
protection given by dynamic ARP monitoring in IPv4. Other DoS
vulnerabilities are related to NDP cache exhaustion, and mitigation
techniques can be found in ([RFC6583]).
Running a dual-stack network doubles the attack exposure as a As stated previously, running a dual-stack network doubles the attack
malevolent person has now two attack vectors: IPv4 and IPv6. This exposure as a malevolent person has now two attack vectors: IPv4 and
simply means that all routers and hosts operating in a dual-stack IPv6. This simply means that all routers and hosts operating in a
environment with both protocol families enabled (even if by default) dual-stack environment with both protocol families enabled (even if
must have a congruent security policy for both protocol version. For by default) must have a congruent security policy for both protocol
example, permit TCP ports 80 and 443 to all web servers and deny all versions. For example, permit TCP ports 80 and 443 to all web
other ports to the same servers must be implemented both for IPv4 and servers and deny all other ports to the same servers must be
IPv6. implemented both for IPv4 and IPv6. It is thus important that the
tools available to administrators readily support such behaviour.
3.5. Address Plan 2.5. Routing
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 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, in a network using OSPFv2 for IPv4, it might
make sense to use OSPFv3 for IPv6. 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 example, 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
in the longer term. [I-D.ietf-v6ops-design-choices] presents advice
on the design choices that arise when considering IGPs and discusses
the advantages and disadvantages to different approaches in detail.
2.6. Address Plan
The most common problem encountered in IPv6 networking is in applying The most common problem encountered in IPv6 networking is in applying
the same principles of conservation that are so important in IPv4. the same principles of conservation that are so important in IPv4.
IPv6 addresses do not need to be assigned conservatively. In fact, a IPv6 addresses do not need to be assigned conservatively. In fact, a
single larger allocation is considered more conservative than single larger allocation is considered more conservative than
multiple discountiguous small blocks, because a single block occupies multiple non-contiguous small blocks, because a single block occupies
only a single entry in a routing table. The advice in [RFC5375] is only a single entry in a routing table. The advice in [RFC5375] is
still sound, and is recommended to the reader. If considering ULAs, still sound, and is recommended to the reader. If considering ULAs,
give careful consideration to how well it is supported, especially in give careful thought to how well it is supported, especially in
multiple address and multicast scenarios, and assess the strength of multiple address and multicast scenarios, and assess the strength of
the requirement for ULA. the requirement for ULA. If using ULAs instead of Globally Unique
Addressing for hosts, note that Network Prefix Translation will be
required [RFC6296] for Internet based communication; the implications
of which must be well understood before deploying.
The enterprise administrator will want to evaluate whether the The enterprise administrator will want to evaluate whether the
enterprise will request address space from its ISP (or Local Internet enterprise will request address space from a LIR (Local Internet
Registry (LIR)), or whether to request address space from the local Registry, such as an ISP), a RIR (Regional Internet Registry, such as
Internet Registry (whether a Regional Internet Registry such as AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC) or a NIR (National
AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC, or a National Internet Internet Registry, operated in some countries). The normal
Registry, operated in some countries). There may be a registration allocation is Provider Aggregatable (PA) address space from the
fee for requesting provider-independent (PI) space from and NIR/RIR, enterprise's ISP, but use of PA space implies renumbering when
but the enterprise will avoid some complexity if renumbering is changing provider. Instead, an enterprise may request Provider
required after changing ISPs (it should be noted that renumbering Independent (PI) space; this may involve an additional fee, but the
caused by outgrowing the space, merger, or other internal reason enterprise may then be better able to be multihomed using that
might not be avoided with PI space). prefix, and will avoid a renumbering process when changing ISPs
(though it should be noted that renumbering caused by outgrowing the
space, merger, or other internal reason would still not be avoided
with PI space).
Each location, no matter how small, should get at least a /48. In The type of address selected (PI vs. PA) should be congruent with the
routing needs of the enterprise. The selection of address type will
determine if an operator will need to apply new routing techniques
and may limit future flexibility. There is no right answer, but the
needs of the external phase may affect what address type is selected.
Each network location or site will need a prefix assignment.
Depending on the type of site/location, various prefix sizes may be
used. In general, historical guidance suggests that each site should
get at least a /48, as documented in RFC 5375 and [RFC6177]. In
addition to allowing for simple planning, this can allow a site to addition to allowing for simple planning, this can allow a site to
use its prefix for local connectivity, should the need arise, and if use its prefix for local connectivity, should the need arise, and if
the local ISP supports it. Generally, workstations managed by the the local ISP supports it.
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.
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.
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 [RFC6164]).
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.
3.6. Program Planning
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.
The project manager will need to spend some time planning. It is When assigning addresses to end systems, the enterprise may use
often useful for the sponsor to communicate with stakeholders at this manually-configured addresses (common on servers) or SLAAC or DHCPv6
time, to explain why IPv6 is important to the enterprise. Then, as for client systems. Early IPv6 enterprise deployments have used
the project manager is assessing what systems and elements will be SLAAC, both for its simplicity but also due to the time DHCPv6 has
affected, the stakeholders will understand why it is important for taken to mature. However, DHCPv6 is now very mature, and thus
them to support the effort. Well-informed project participants can workstations managed by an enterprise may use stateful DHCPv6 for
help significantly by explaining the relationships between addressing on corporate LAN segments. DHCPv6 allows for the
components. For a large enterprise, it may take several iterations additional configuration options often employed by enterprise
to really understand the level of effort required; some systems will administrators, and by using stateful DHCPv6, administrators
require additional development, some might require software updates, correlating system logs know which system had which address at any
and others might need new versions or alternate vendors. Once the given time. Such an accountability model is familiar from IPv4
projects are understood, the project manager can develop a schedule management, though for DHCPv6 hosts are identified by DUID rather
and a budget, and work with the project sponsor to determine what than MAC address. For equivalent accountability with SLAAC (and
constraints can be adjusted, if necessary. potentially privacy addresses), a monitoring system that harvests IP/
MAC mappings from switch and router equipment could be used.
It is tempting to roll IPv6 projects into other architectural In the data center or server room, assume a /64 per VLAN. This
upgrades - this can be an excellent way to improve the network and applies even if each individual system is on a separate VLAN. In a
reduce costs. Project participants are advised that by increasing /48 assignment, typical for a site, there are then still 65,535 /64
the scope of projects, the schedule is often affected. For instance, blocks. Addresses are either configured manually on the server, or
a major systems upgrade may take a year to complete, where just reserved on a DHCPv6 server, which may also synchronize forward and
patching existing systems may take only a few months. Understanding reverse DNS. Because of the need to synchronize RA timers and DNS
and evaluating these trade-offs are why a project manager is TTLs, SLAAC is rarely, if ever, used for servers, and would require
important. tightly coupled dynamic DNS updates.
[I-D.ietf-6renum-static-problem]
It is very common for assessments to continue in some areas even as All user access networks should be a /64. Point-to-point links where
execution of the project begins in other areas. This is fine, as Neighbor Discovery Protocol is not used may also utilize a /127 (see
long as recommendations in other parts of this document are [RFC6164]).
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.
As projects are completed, the project manager will confirm that work Plan to aggregate at every layer of network hierarchy. There is no
has been completed, often by means of seeing a completed test plan, need for VLSM [RFC1817] in IPv6, and addressing plans based on
and will report back to the project sponsor on completed parts of the conservation of addresses are short-sighted. Use of prefixes longer
project. A good project manager will remember to thank the people then /64 on network segments will break common IPv6 functions such as
who executed the project. SLAAC[RFC4862]. 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, plan to grow to about twice the current size that can be
accommodated; where rapid growth is planned, allow for twice that
growth. Also, if DNS (or reverse DNS) authority may be delegated to
others in the enterprise, assignments need to be on nibble boundaries
(that is, on a multiple of 4 bits, such as /64, /60, /56, ..., /48,
/44), to ensure that delegated zones align with assigned prefixes.
3.7. Tools Assessment 2.7. Tools Assessment
Enterprises will often have a number of operational tools and support Enterprises will often have a number of operational tools and support
systems which are used to provision, monitor, manage and diagnose the systems which are used to provision, monitor, manage and diagnose the
network and systems within their environment. These tools and network and systems within their environment. These tools and
systems will need to be assessed for compatibility with IPv6 systems will need to be assessed for compatibility with IPv6. The
operation. The compatibility may be related to actual addressing and compatibility may be related to the addressing and connectivity of
connectivity of various devices as well as IPv6 awareness in many of various devices as well as IPv6 awareness the tools and processing
tools and processing logic. logic.
The tools within the organization fall into two general categories, The tools within the organization fall into two general categories,
those which focus on managing the network, and those which are those which focus on managing the network, and those which are
focused on managing systems and applications on the network. In focused on managing systems and applications on the network. In
either instance, the tools will run on platforms which may or may not either instance, the tools will run on platforms which may or may not
be capable of operating in an IPv6 network. This lack in be capable of operating in an IPv6 network. This lack in
functionality may be related to Operating system version, or based on functionality may be related to Operating System version, or based on
some hardware constraint. Those systems which are found to be some hardware constraint. Those systems which are found to be
incapable of utilizing a IPv6 connection may need to be replaced or incapable of utilizing an IPv6 connection, or which are dependent on
upgraded. an IPv4 stack, may need to be replaced or upgraded.
In addition to devices working on an IPv6 network natively, or via a In addition to devices working on an IPv6 network natively, or via a
tunnel, many tools and support systems may require additional updates tunnel, many tools and support systems may require additional
to be IPv6 aware or even a hardware upgrade (mainly because of the software updates to be IPv6 aware, or even a hardware upgrade
memory utilization by IPv6 as the addresses are larger and because, (usually for additional memory: IPv6 as the addresses are larger and
for a while, IPv4 and IPv6 addresses will coexist in the tool). This for a while, IPv4 and IPv6 addresses will coexist in the tool). This
awareness may include the ability to manage IPv6 elements and/or awareness may include the ability to manage IPv6 elements and/or
applications in addition to the ability to store and utilize IPv6 applications in addition to the ability to store and utilize IPv6
addresses. addresses.
Considerations when assessing the tools and support systems may Considerations when assessing the tools and support systems may
include the fact that IPv6 addresses are significantly larger then include the fact that IPv6 addresses are significantly larger than
IPv4 requiring datastores to support the increased size. Such issues IPv4, requiring data stores to support the increased size. Such
are among those discussed in [RFC5952]. Many organizations may also issues are among those discussed in [RFC5952]. Many organizations
run dual stack networks, therefore the tools need not only support may also run dual-stack networks, therefore the tools need to not
IPv6 operation, but may also need to support the monitoring, only support IPv6 operation, but may also need to support the
management and intersection with both IPv6 and IPv4 simultaneously. monitoring, management and intersection with both IPv6 and IPv4
It is important to note that managing IPv6 is not just constrained to simultaneously. It is important to note that managing IPv6 is not
using large IPv6 addresses, but also that IPv6 interfaces and nodes just constrained to using large IPv6 addresses, but also that IPv6
may use two or more addresses as part of normal operation. Updating interfaces and nodes are likely to use two or more addresses as part
management systems to deal with these additional nuances will likely of normal operation. Updating management systems to deal with these
time and considerable effort. additional nuances will likely consume time and considerable effort.
For networking focus systems, like node management systems, it is not For networking systems, like node management systems, it is not
always necessary to support local IPv6 addressing and connectivity. always necessary to support local IPv6 addressing and connectivity.
Operation, such as SNMP MIB polling can occur over IPv4 transport Operations such as SNMP MIB polling can occur over IPv4 transport
while seeking responses related to IPv6 information. Where this may while seeking responses related to IPv6 information. Where this may
seem advantageous to some, it should be noted that without local IPv6 seem advantageous to some, it should be noted that without local IPv6
connectivity, the management system may not be able to perform all connectivity, the management system may not be able to perform all
expected functions - such as reachability and service checks. expected functions - such as reachability and service checks.
Organizations should be aware of changes to older IPv4-Only SNMP MIB Organizations should be aware that changes to older IPv4-only SNMP
specifications have been made by the IETF related to legacy operation MIB specifications have been made by the IETF related to legacy
in [RFC2096] and [RFC2011]. Updated specifications are now available operation in [RFC2096] and [RFC2011]. Updated specifications are now
in [RFC4296] and [RFC4293] which modified the older MIB framework to available in [RFC4296] and [RFC4293] which modified the older MIB
be IP protocol agnostic supporting IPv4 and IPv6. Polling systems framework to be IP protocol agnostic, supporting both IPv4 and IPv6.
will need to be upgraded to support these updates as well as the end Polling systems will need to be upgraded to support these updates as
stations which are polled. well as the end stations which are polled.
4. External Phase 3. External Phase
The external phase for Enterprise IPv6 adoption covers topics which The external phase for enterprise IPv6 adoption covers topics which
deal with how an organization connects their infrastructure to the deal with how an organization connects its infrastructure to the
external world. These external connections may be toward the external world. These external connections may be toward the
Internet at larges, or other networks. The external phase covers Internet at large, or to other networks. The external phase covers
connectivity, security, monitoring of various elements and outward connectivity, security and monitoring of various elements and outward
facing or accessible services. facing or accessible services.
How an organization connects to the outside worlds is very important How an organization connects to the outside worlds is very important
as it is often a critical part of how a business functions, therefore as it is often a critical part of how a business functions, therefore
must be dealt accordingly. it must be dealt accordingly.
4.1. Connectivity 3.1. Connectivity
The Enterprise will need to work with one or more Service Providers The enterprise will need to work with one or more Service Providers
to gain connectivity to the Internet or transport service to gain connectivity to the Internet or transport service
infrastructure such as a BGP/MPLS IP VPN as described in [RFC4364] infrastructure such as a BGP/MPLS IP VPN as described in [RFC4364]
and [RFC4659]. On significant factor guiding how an organization may and [RFC4659]. One significant factor that will guide how an
need to communist with the outside world will involve the use of PI organization may need to communicate with the outside world will
(Provider Independent) and/or PA (Provider Aggregatable) IPv6 space. involve the use of PI (Provider Independent) and/or PA (Provider
Aggregatable) IPv6 space.
In the case of PI, the organization will need to support BGP based Enterprises should be aware that depending on which address type they
connectivity for the most part since the address space is assigned selected (PI vs. PA) in their planning section, they may need to
direction from the Regional Registry to the local network. In this implement new routing functions and/or behaviours to support their
case, the local network would act as an Autonomous System on the connectivity to the ISP. In the case of PI, the upstream ISP may
Internet and must advertise routes accordingly. PA space is offer options to route the prefix (typically a /48) on the
delegated form the upstream service provider and can then be assigned enterprise's behalf and update the relevant routing databases. In
to the local network. If PA space is used, other forms of route other cases, the enterprise may need to perform this task on their
exchange may be possible such as RIPng, OSPFv3 and static. PA own and use BGP to inject the prefix into the global BGP system.
assigned space would normally be routed to the general Internet via This latter case is not how many enterprises operate today and is an
the upstream providers infrastructure lightening the burden on the important consideration.
local network administrations.
PI and PA space have additional contrasting behaviours when use such Note that the rules set by the RIRs for an enterprise acquiring PI
as how dual homing may work. Should an operator choose to dual home, address space have changed over time. For example, in the European
PI space would be routed to both upstream providers and then passed region the RIPE-NCC no longer requires an enterprise to be multihomed
on to other networks. Utilizing more then one upstream Service to be eligible for an IPv6 PI allocation. Requests can be made
Provider may introduce challenges since traffic utilizing a given PA directly or via an LIR. It is possible that the rules may change
assign block would be expected to flow through the assigning provider again, and may vary between RIRs.
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.
When seeking IPv6 connectivity to a Service Provider, the Enterprise When seeking IPv6 connectivity to a Service Provider, the Enterprise
will want to attempt to use Native IPv6 connectivity. Native IPv6 will prefer to use native IPv6 connectivity. Native IPv6
connectivity is preferred since it provides the most rebuts form of connectivity is preferred since it provides the most robust and
connectivity. If Native IPv6 connectivity is not possible due to efficient form of connectivity. If native IPv6 connectivity is not
technical or business limitations, the Enterprise may utilize readily possible due to technical or business limitations, the enterprise may
available tunnelled IPv6 connectivity. There are IPv6 transit utilize readily available tunnelled IPv6 connectivity. There are
providers which provide tunnelled IPv6 connectivity which can operate IPv6 transit providers which provide robust tunnelled IPv6
over IPv4 networks. A Enterprise need not need to wait for their connectivity which can operate over IPv4 networks. It is important
local Service Provider to support IPv6, as tunnelled connectivity can to understand the tunneling mechanism used, and to consider that it
be used. will have higher latency than native IPv4 or IPv6, and may have other
problems, e.g. related to MTUs.
** Add some comment about setting MTU to 1280 to avoid tunnel pMTUd The use of ULAs may provide additional flexibility when an enterprise
black holes? ** is using PA space, by providing an independent local prefix for
internal use, while using the PA prefix externally in conjunction
with NPTv6 [RFC6296]. Many enterprises today are used to using IPv4
host-based NAT, and indeed may choose to use this model even when
global IPv4 address space is available. NPTv6 instead performs
stateless prefix-based NAT, mapping from an external global prefix to
(usually) an internal ULA prefix. Such mappings can be used with
multiple prefixes in multihoming scenarios, rather than using both
ISP's global prefixes internally, with hosts receiving an IPv6
address from each prefix (and then needing to ensure the correct
source address is used to route traffic out of the correct egress).
While NPTv6 can provide for simplified renumbering in certain
scenarios, as described in [I-D.ietf-6renum-enterprise], it must be
noted that many of the well-known issues with NAT still apply, in
particular handling IPv6 addresses embedded in payloads.
4.2. Security It is important to evaluate MTU considerations when adding in IPv6 to
an existing IPv4 network. It is generally desirable to have the IPv6
and IPv4 MTU congruent to simplify operations. If the enterprise
uses tunnelling inside or externally for IPv6 connectivity, then
modification of the MTU on hosts/routers may be needed as mid-stream
fragmentation is no longer supported in IPv6. It is preferred that
pMTUD is used to optimize the MTU, so erroneous filtering of the
related ICMPv6 message types should be monitored. Adjusting the MTU
may be the only option if undesirable upstream ICMPv6 filtering
cannot be removed.
3.2. Security
The most important part of security for external IPv6 deployment is The most important part of security for external IPv6 deployment is
filtering and monitoring. Filtering can be done by stateless ACL or filtering and monitoring. Filtering can be done by stateless ACLs or
stateful firewall. The security policies must be congruent for IPv4 a stateful firewall. The security policies must be consistent for
and IPv6 (else the attacker will use the less protected protocol IPv4 and IPv6 (else the attacker will use the less protected protocol
stack) except that ICMPv6 messages must be allowed through and to the stack), except that certain ICMPv6 messages must be allowed through
filtering device (see [RFC4890]): and to the filtering device (see [RFC4890]):
o unreachable packet-too-big: really imporant to allow Path MTU o Unreachable packet-too-big: it is very important to allow Path MTU
discovery to work discovery to work
o unreachable parameter-problem o Unreachable parameter-problem
o neighbor solicitation o Neighbor solicitation
o neighbor advertisement o Neighbor advertisement
It could also be safer to block all fragments where the transport It could also be safer to block all fragments where the transport
layer header is not in the first fragment to avoid attack as layer header is not in the first fragment to avoid attacks as
described in [RFC5722]. Some filtering devices allow this filtering. described in [RFC5722]. Some filtering devices allow this filtering.
To be fully compliant with [RFC5095], it can be useful to drop all To be fully compliant with [RFC5095], all packets containing the
packet containing the routing extension header type 0. routing extension header type 0 must be dropped.
If Intrusion Prevention Systems (IPS) are used for IPv4 traffic, then If an Intrusion Prevention System (IPS) is used for IPv4 traffic,
the same IPS should also be used for IPv6 traffic. This is just a then an IPS should also be used for IPv6 traffic. In general, make
generalization of the dual-stack deployment: do for IPv6 what you do sure IPv6 security is at least as good as IPv4. This also includes
for IPv4. This also include all email content protection (anti-spam, all email content protection (anti-spam, content filtering, data
content filtering, data leakage prevention, etc). leakage prevention, etc.).
The peering router must also implement anti-spoofing technique based The edge router must also implement anti-spoofing techniques based on
on [RFC2827]. [RFC2827] (also known as BCP 38).
In order to protect the networking devices, it is advised to In order to protect the networking devices, it is advised to
implement control plane policing as per [RFC6192]. implement control plane policing as per [RFC6192].
The NDP cache exhaustion (see [I-D.gashinsky-v6ops-v6nd-problems]) The potential NDP cache exhaustion attack (see [RFC6538]) can be
attack can be mitigated by two techniques: mitigated by two techniques:
o good NDP implementation with memory utilization limits as well as o Good NDP implementation with memory utilization limits as well as
rate-limiters and prioritization of requests. rate-limiters and prioritization of requests.
o else, as the external deployment usually involves just a couple of o Or, as the external deployment usually involves just a couple of
exposed IPv6 statically configured addresses (virtual address of exposed statically configured IPv6 addresses (virtual addresses of
web, email servers, DNS server), then it is straightforward to web, email, and DNS servers), then it is straightforward to build
build an ingress ACL allowing traffic for those addresses and an ingress ACL allowing traffic for those addresses and denying
denying traffic to any other addresses. This actually prevents traffic to any other addresses. This actually prevents the attack
the attack as packet for random destination will be dropped and as a packet for a random destination will be dropped and will
will never trigger a neighbor resolution. never trigger a neighbor resolution.
4.3. Monitoring 3.3. Monitoring
Monitoring the use of the Internet connectivity should be done for 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 IPv6 as it is done for IPv4. This includes the use of IP Flow
[RFC5102] to detect abnormal traffic pattern (such as port scanning, Information eXport (IPFIX) [RFC5102] to detect abnormal traffic
SYN-flooding) and SNMP MIB [RFC4293] (another way to detect abnormal patterns (such as port scanning, SYN-flooding) and SNMP MIB [RFC4293]
bandwidth utilization). (another way to detect abnormal bandwidth utilization). Where using
Netflow, version 9 is required for IPv6 support.
4.4. Servers and Applications 3.4. Servers and Applications
5. Internal Phase The path to the servers accessed from the Internet usually involves
security devices (firewall, IPS), server load balancing (SLB) and
real physical servers. The latter stage is also multi-tiered for
scalability and security between presentation and data storage. The
ideal transition is to enable dual-stack on all devices but this may
seem too time-consuming and too risky.
This phase deals with the delivery of IPv6 to the internal user Operators have used the following approaches with success:
facing side of the IT infrastructure, which comprises of various
o Use a network device to apply NAT64 and basically translate an
inbound TCP connection (or any other transport protocol) over IPv6
into a TCP connection over IPv4. This is the easiest to deploy as
the path is mostly unchanged but it hides all IPv6 remote users
behind a single IPv4 address which leads to several audit trail
and security issues (see [RFC6302]).
o Use the server load balancer which acts as an application proxy to
do this translation. Compared to the NAT64, it has the potential
benefit of going through the security devices as native IPv6 (so
more audit and trace abilities) and is also able to insert a HTTP
X-Forward-For header which contains the remote IPv6 address. The
latter feature allows for logging, and rate-limiting on the real
servers based on the IPV6 address even if those servers run only
IPv4.
3.5. Network Prefix Translation for IPv6
Network Prefix Translation for IPv6, or NPTv6 as described in
[RFC6296] provides a framework to utilize prefix ranges within the
internal network which are separate (address-independent) from the
assigned prefix from the upstream provider or registry. As mentioned
above, while NPTv6 has potential use-cases in IPv6 networks, the
implications of its deployment need to be fully understood,
particularly where any applications might embed IPv6 addresses in
their payloads.
Use of NTPv6 can be chosen independently from how addresses are
assigned and routed within the internal network and how prefixes are
routed towards the Internet (included both PA and PI address
assignment options).
4. Internal Phase
This phase deals with the delivery of IPv6 to the internal user-
facing side of the IT infrastructure, which comprises various
components such as network devices (routers, switches, etc.), end components such as network devices (routers, switches, etc.), end
user devices and peripherals (workstations, printers, etc.), and user devices and peripherals (workstations, printers, etc.), and
internal corporate systems. internal corporate systems.
An important design paradigm to consider during this phase is "Dual An important design paradigm to consider during this phase is "dual-
Stack when you can, tunnel when you must". Dual stacking allows you stack when you can, tunnel when you must". Dual-stacking allows a
to build a more robust IPv6 network that is of production quality as more robust, production-quality IPv6 network than is typically
opposed to tunnels that are harder to troubleshoot and support. facilitated by internal use of tunnels that are harder to
Tunnels however do provide operators with a quick and easy way to troubleshoot and support, and that may introduce scalability and
play with IPv6 and gain some operational experience with the performance issues. Tunnels may of course still be used in
protocol. [RFC4213] describes various transition mechanisms in more production networks, but their use needs to be carefully considered,
detail. [I-D.templin-v6ops-isops] suggests operational guidance when e.g. where the tunnel may be run through a security or filtering
using ISATAP tunnels [RFC5214]. device. Tunnels do also provide a means to experiment with IPv6 and
gain some operational experience with the protocol. [RFC4213]
describes various transition mechanisms in more detail.
[I-D.templin-v6ops-isops] suggests operational guidance when using
ISATAP tunnels [RFC5214], though we would recommend use of dual-stack
wherever possible.
5.1. Network Infrastructure 4.1. Security
The typical enterprise network infrastructure comprises of a IPv6 must be deployed in a secure way. This means that all existing
combination of the following network elements - wired access IPv4 security policies must be extended to support IPv6; IPv6
switches, wireless access points, and routers. Although, it is security policies will be the IPv6 equivalent of the existing IPv4
fairly common to find hardware that collapses switching and routing ones (taking into account the difference for ICMPv6 [RFC4890]). As
functionality into a single device. Basic wired access switches and in IPv4, security policies for IPv6 will be enforced by firewalls,
access points that operate only at the physical and link layer, don't ACL, IPS, VPN, and so on.
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.
An important design choice to be made is what IGP to use inside the Privacy extension addresses [RFC4941] raise a challenge for an audit
network. A variety of IGPs (IS-IS, OSPFv3 and RIPng) support IPv6 trail as explained in section Section 2.4.3. The enterprise may
today and picking one over the other is purely a design choice that choose to attempt to enforce use of DHCPv6, or deploy monitoring
will be dictated mostly by existing operational policies in an tools that harvest accountability data from switches and routers
enterprise network. As mentioned earlier, it would be beneficial to (thus making the assumption that devices may use any addresses inside
maintain operational parity between IPv4 and IPv6 and therefore it the network).
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 But the major issue is probably linked to all threats against
might make sense to use OSPFv3 now. It is important to note that Neighbor Discovery. This means, for example, that the internal
although OSPFv3 is similar to OSPFv2, they are not the same. On the network at the access layer (where hosts connect to the network over
other hand, some organizations may chose to run different routing wired or wireless) should implement RA-guard [RFC6105] and the
protocols for different IP versions. For e.g., one may chose to run techniques being specified by SAVI WG [I-D.ietf-savi-threat-scope];
OSPFv2 for IPv4 and IS-IS for IPv6. An important design question to see also Section 2.4.3 for more information.
consider here is whether to support one IGP or two different IGPs
down the road. [I-D.matthews-v6ops-design-guidelines] presents 4.2. Network Infrastructure
advice on the design choices that arise when considering one IGP vs.
the other and discusses the pros and cons in detail. The typical enterprise network infrastructure comprises 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
operate only at the physical and link layers, and don't really have
any special IPv6 considerations other than being able to support IPv6
addresses themselves for management purposes. 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, or they may help limit where multicast floods by using
IGMP (or, in the case of IPv6, MLD) snooping.
Another important consideration in enterprise networks is first hop Another important consideration in enterprise networks is first hop
router redundancy. This directly ties into network reachability from router redundancy. This directly ties into network reachability from
an end host's point of view. IPv6 Neighbor Discovery (ND), an end host's point of view. IPv6 Neighbor Discovery (ND),
[RFC4861], provides a node with the capability to maintain a list of [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 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 backup path should the primary be unreachable. By default, ND will
detect a router failure in 38 seconds and cycle onto the next default 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 router listed in its cache. While this feature provides a basic
basic level of first hop router redundancy, most enterprise IPv4 level of first hop router redundancy, most enterprise IPv4 networks
networks are designed to fail over much faster. Although this delay are designed to fail over much faster. Although this delay can be
can be improved by adjusting the default timers, care must be taken improved by adjusting the default timers, care must be taken to
to protect against transient failures and to account for increased protect against transient failures and to account for increased
traffic on the link. Another option to provide robust first hop traffic on the link. Another option to provide robust first hop
redundancy is to use the Virtual Router Redundancy Protocol for IPv6 redundancy is to use the Virtual Router Redundancy Protocol for IPv6
(VRRPv3), [RFC5798]. This protocol provides a much faster switchover (VRRPv3), [RFC5798]. This protocol provides a much faster switchover
to an alternate default router than default ND parameters. Using to an alternate default router than default ND parameters. Using
VRRP, a backup router can take over for a failed default router in VRRPv3, a backup router can take over for a failed default router in
around three seconds (using VRRP default parameters). This is done around three seconds (using VRRPv3 default parameters). This is done
without any interaction with the hosts and a minimum amount of VRRP without any interaction with the hosts and a minimum amount of VRRP
traffic. traffic.
Last but not the least, one of the most important design choices to 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 make while deploying IPv6 on the internal network is whether to use
Stateless Automatic Address Configuration (SLAAC), [RFC4862], or Stateless Automatic Address Configuration (SLAAC), [RFC4862], or
Dynamic Host Configuration Protocol for IPv6 (DHCPv6), [RFC3315], or Dynamic Host Configuration Protocol for IPv6 (DHCPv6), [RFC3315], or
a combination thereof (possible when using a /64 subnet). Each a combination thereof. Each option has advantages and disadvantages,
option has its own unique set of pros and cons and the choice will and the choice will ultimately depend on the operational policies
ultimately depend on the operational policies that guide each that guide each enterprise's network design. For example, if an
enterprise's network design. For example, if an enterprise is enterprise is looking for ease of use, rapid deployment, and less
looking for ease of use, rapid deployments, and less administrative administrative overhead, then SLAAC makes more sense for
overhead, then SLAAC makes more sense. However, if the operational workstations. Manual or DHCPv6 assignments are still needed for
policies call for precise control over IP address assignment for servers, as described in the External Phase and Address Plan sections
auditing then DHCPv6 would be the way to go. DHCPv6 also allows you of this document. However, if the operational policies call for
tie into DNS systems for host entry updates and gives you the ability precise control over IP address assignment for auditing then DHCPv6
to send other options information to clients. In the long term, may be preferred. DHCPv6 also allows you tie into DNS systems for
DHCPv6 makes most sense for use in a managed environment. host entry updates and gives you the ability to send other options
and information to clients. It is worth noting that in general
operation RAs are still needed in DHCPv6 networks, as there is no
DHCPv6 Default Gateway option. Similarly, DHCPv6 is needed in RA
networks for other configuration information, e.g. NTP servers or,
in the absence of support for DNS resolvers in RAs [RFC6106], DNS
resolver information.
5.2. End user devices 4.3. End user devices
Most operating systems (OS) that are loaded on workstations and Most operating systems (OSes) that are loaded on workstations and
laptops in a typical enterprise support IPv6 today. However, there laptops in a typical enterprise support IPv6 today. However, there
are various out-of-the-box nuances that one should be mindful about. 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 For example, the default behavior of OSes vary; some may have IPv6
turned off entirely by default, some may only have certain features turned off by default, some may only have certain features such as
such as privacy addresses turned off while others have IPv6 fully privacy extensions to IPv6 addresses (RFC 4941) turned off while
enabled. It is important to note that most operating systems will, others have IPv6 fully enabled. Further, even when IPv6 is enabled,
by default, prefer to use native IPv6 over IPv4 when enabled. the choice of which address is used may be subject to Source Address
Therefore, it is advised that enterprises investigate the default Selection (RFC 6724) and Happy Eyeballs (RFC 6555). Therefore, it is
behavior of their installed OS base and account for it during the advised that enterprises investigate the default behavior of their
implementation of IPv6. Furthermore, some OSes may have tunneling installed OS base and account for it during the Inventory phases of
mechanisms turned on by default and in such cases, it is recommended their IPv6 preparations. Furthermore, some OSes may have tunneling
to administratively shut down such interfaces unless required. It is mechanisms turned on by default and in such cases it is recommended
recommended that IPv6 be deployed at the network infrastructure level to administratively shut down such interfaces unless required.
before it is rolled out to end user devices.
It is important to note that it is recommended that IPv6 be deployed
at the network and system infrastructure level before it is rolled
out to end user devices; ensure IPv6 is running and routed on the
wire, and secure and correctly monitored, before exposing IPv6 to end
users.
Smartphones and tablets are poised to become one of the major Smartphones and tablets are poised to become one of the major
consumers of IP addresses and enterprises should be ready to deploy consumers of IP addresses and enterprises, and should be ready to
and support IPv6 on various networks that serve such devices. In support IPv6 on various networks that serve such devices. In
general, support for IPv6 in these devices, albeit in its infancy, general, support for IPv6 in these devices, albeit in its infancy,
has been steadily rising. Most of the leading smartphone OSes have has been steadily rising. Most of the leading smartphone OSes have
some level of support for IPv6. However, the level of configurable some level of support for IPv6. However, the level of configurable
options are mostly at a minimum and are not consistent across all options are mostly at a minimum and are not consistent across all
platforms. Also, it is fairly common to find IPv6 support on the platforms. Also, it is fairly common to find IPv6 support on the
wifi connection alone and not on the radio interface in these Wi-Fi connection alone and not on the radio interface in these
devices. This is sometimes due to the radio network not being ready devices. This is sometimes due to the radio network not being IPv6
or device related. An IPv6 enabled enterprise wifi network will ready, or it may be device-related. An IPv6-enabled enterprise Wi-Fi
allow the majority of these devices to connect via IPv6. Much work network will allow the majority of these devices to connect via IPv6.
is still being done to bring the full IPv6 feature set across all Much work is still being done to bring the full IPv6 feature set
interfaces (802.11, 3G, LTE, etc.) and platforms. across all interfaces (802.11, 3G, LTE, etc.) and platforms.
IPv6 support in peripheral equipment such as printers, IP Cameras, IPv6 support in peripheral equipment such as printers, IP cameras,
etc. has been steadily rising as well, although at a much slower pace etc., has been steadily rising as well, although at a much slower
than traditional OSes and Smartphones. Most newer devices are coming pace than traditional OSes and smartphones. Most newer devices are
out with IPv6 support but there is still a large installed base of coming out with IPv6 support but there is still a large installed
legacy peripheral devices that might need IPv4 for sometime to come. base of legacy peripheral devices that might need IPv4 for some time
The audit phase mentioned earlier will make it easier for enterprises to come. The audit phase mentioned earlier will make it easier for
to plan for equipment upgrades, in line with their corporate enterprises to plan for equipment upgrades, in line with their
equipment refresh cycle. corporate equipment refresh cycle.
5.3. Corporate Systems 4.4. Corporate Systems
No IPv6 deployment will be successful without ensuring that all the No IPv6 deployment will be successful without ensuring that all the
corporate systems that enterprise uses as part of their IT corporate systems that an enterprise uses as part of its IT
infrastructure, support IPv6. Examples of such systems include, but infrastructure support IPv6. Examples of such systems include, but
are not limited to, Email, Video Conferencing, Telephony (VoIP), DNS, are not limited to, email, video conferencing, telephony (VoIP), DNS,
Radius, etc. All these systems must have their own detailed IPv6 RADIUS, etc. All these systems must have their own detailed IPv6
rollout plan in conjunction with the network IPv6 rollout. It is rollout plan in conjunction with the network IPv6 rollout. It is
important to note that DNS is one of the main anchors in an important to note that DNS is one of the main anchors in an
enterprise deployment, since most end hosts decide whether or not use enterprise deployment, since most end hosts decide whether or not to
IPv6 based on the presence of AAAA records in a reply to a DNS query. use IPv6 depending on the presence of IPv6 AAAA records in a reply to
It is recommended that system administrators selectively turn on AAAA a DNS query. It is recommended that system administrators
records for various systems as and when they are IPv6 enabled. selectively turn on AAAA records for various systems as and when they
Additionally, all monitoring and reporting tools across the are IPv6 enabled; care must be taken though to ensure all services
running on that host name are IPv6-enabled before adding the AAAA
record. Additionally, all monitoring and reporting tools across the
enterprise would need to be modified to support IPv6. enterprise would need to be modified to support IPv6.
5.4. Security 5. IPv6-only
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 ICMPv6 [RFC4890]). As
in IPv4, security policies for IPv6 will be enforced by firewalls,
ACL, IPS, VPN, ...
Privacy extension addresses [RFC4941] pose a real challenge for audit
trail as explained in section Section 3.4.3.
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 RA-guard [RFC6105] and the techniques being
specified by SAVI WG [I-D.ietf-savi-threat-scope]; see also
Section 3.4.3 for more information.
6. Other Phases
To be added.
6.1. Guest network
To be added.
6.2. IPv6-only
Although IPv4 and IPv6 networks will coexist for a long time to come, Early IPv6 enterprise deployments have generally taken a dual-stack
the long term enterprise network roadmap should include steps on approach to enabling IPv6, i.e. the existing IPv4 services have not
gradually deprecating IPv4 from the dual-stack network. In some been turned off. Although IPv4 and IPv6 networks will coexist for a
extreme cases, deploying dual-stack networks may not even be a viable long time, the long term enterprise network roadmap should include
option for very large enterprises due to lack of availability of RFC steps on gradually deprecating IPv4 from the dual-stack network. In
1918 addresses. In such cases, deploying IPv6-only networks might be some extreme cases, deploying dual-stack networks may not even be a
the only choice available to sustain network growth. viable option for very large enterprises due to the RFC 1918 address
space not being large enough to support the network's growth. In
such cases, deploying IPv6-only networks might be the only choice
available to sustain network growth. In other cases, there may be
elements of an otherwise dual-stack network that may be run IPv6-
only.
If nodes in the network don't need to talk to an IPv4-only node, then 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 deploying IPv6-only networks should be fairly trivial. However, in
the current environment, given that IPv4 is the dominant protocol on 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- 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 only node on the Internet. It is therefore important to provide such
nodes with a translation mechanism to ensure communication between nodes with a translation mechanism to ensure communication between
nodes configured with different address families. As [RFC6144] nodes configured with different address families. As [RFC6144]
points out, it is important to look at address translation as a points out, it is important to look at address translation as a
transition strategy that will get you to an IPv6-only network. transition strategy towards running an IPv6-only network.
There are various stateless and stateful IPv4/IPv6 translation There are various stateless and stateful IPv4/IPv6 translation
methods available today that help IPv4 to IPv6 communication. RFC methods available today that help IPv6 to IPv4 communication. RFC
6144 provides a framework for IPv4/IPv6 translation and describes in 6144 provides a framework for IPv4/IPv6 translation and describes in
detail various scenarios in which such translation mechanisms could detail various scenarios in which such translation mechanisms could
be used. [RFC6145] describes stateless address translation. In this be used. [RFC6145] describes stateless address translation. In this
mode, a specific IPv6 address range will represent IPv4 systems mode, a specific IPv6 address range will represent IPv4 systems
(IPv4-converted addresses), and the IPv6 systems have addresses (IPv4-converted addresses), and the IPv6 systems have addresses
(IPv4-translateable addresses) that can be algorithmically mapped to (IPv4-translatable addresses) that can be algorithmically mapped to a
a subset of the service provider's IPv4 addresses. [RFC6146], NAT64, subset of the service provider's IPv4 addresses. [RFC6146], NAT64,
describes stateful address translation. As the name suggests, the describes stateful address translation. As the name suggests, the
translation state is maintained between IPv4 address/port pairs and translation state is maintained between IPv4 address/port pairs and
IPv6 address/port pairs, enabling IPv6 systems to open sessions with IPv6 address/port pairs, enabling IPv6 systems to open sessions with
IPv4 systems. [RFC6147], DNS64, describes a mechanism for IPv4 systems. [RFC6147], DNS64, describes a mechanism for
synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs
6146 and RFC 6147 provide a viable method for an IPv6-only client to 6146 and RFC 6147 provide a viable method for an IPv6-only client to
initiate communications to an IPv4-only server. initiate communications to an IPv4-only server.
The address translation mechanisms for the stateless and stateful The address translation mechanisms for the stateless and stateful
translations are defined in [RFC6052]. It is important to note that translations are defined in [RFC6052]. It is important to note that
both of these mechanisms have limitations as to which protocols they both of these mechanisms have limitations as to which protocols they
support. For example, RFC 6146 only defines how stateful NAT64 support. For example, RFC 6146 only defines how stateful NAT64
translates unicast packets carrying TCP, UDP, and ICMP traffic only. translates unicast packets carrying TCP, UDP, and ICMP traffic only.
The ultimate choice of which translation mechanism to chose will be The classic problems of IPv4 NAT also apply, e.g. handling IP
dictated mostly by existing operational policies pertaining to literals in application payloads. The ultimate choice of which
application support, logging requirements, etc. translation mechanism to chose will be dictated mostly by existing
operational policies pertaining to application support, logging
requirements, etc.
There is additional work being done in the area of address There is additional work being done in the area of address
translation to enhance and/or optimize current mechanisms. For translation to enhance and/or optimize current mechanisms. For
example, [I-D.xli-behave-divi] describes limitations with the current example, [I-D.xli-behave-divi] describes limitations with the current
stateless translation, such as IPv4 address sharing and application stateless translation, such as IPv4 address sharing and application
layer gateway (ALG) problems, and presents the concept and layer gateway (ALG) problems, and presents the concept and
implementation of dual-stateless IPv4/IPv6 translation (dIVI) to implementation of dual-stateless IPv4/IPv6 translation (dIVI) to
address those issues. address those issues.
7. Considerations For Specific Enterprises It is worth noting that for IPv6-only access networks that use
technologies such as NAT64, the more content providers (and
enterprises) that make their content available over IPv6, the less
the requirement to apply NAT64 to traffic leaving the access network.
7.1. Content Delivery Networks 6. Considerations For Specific Enterprises
To be added. 6.1. Content Delivery Networks
7.2. Data Center Virtualization Some guidance for Internet Content and Application Service Providers
can be found in [I-D.ietf-v6ops-icp-guidance], which includes a
dedicated section on CDNs. An enterprise that relies on CDN to
deliver a 'better' e-commerce experience needs to ensure that their
CDN provider also supports IPv4/IPv6 traffic selection so that they
can ensure 'best' access to the content.
Another document ([I-D.lopez-v6ops-dc-ipv6]) describes in details the 6.2. Data Center Virtualization
specifics about IPv6 Data Center.
7.3. Campus Networks IPv6 Data Center considerations are described in
[I-D.lopez-v6ops-dc-ipv6].
A number of campus networks have made some initial IPv6 deployment. 6.3. University Campus Networks
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.
In particular the areas commonly approached are: A number of campus networks around the world have made some initial
IPv6 deployment. This has been encouraged by their National Research
and Education Network (NREN) backbones having made IPv6 available
natively since the early 2000's. Universities are a natural place
for IPv6 deployment to be considered at an early stage, perhaps
compared to other enterprises, as they are involved by their very
nature in research and education.
Campus networks can deploy IPv6 at their own pace; their is no need
to deploy IPv6 across the entire enterprise from day one, rather
specific projects can be identified for an initial deployment, that
are both deep enough to give the university experience, but small
enough to be a realistic first step. There are generally three areas
in which such deployments are currently made.
In particular those initial areas commonly approached are:
o External-facing services. Typically the campus web presence and o External-facing services. Typically the campus web presence and
commonly also external-facing DNS and MX services. commonly also external-facing DNS and MX services. This ensures
early IPv6-only adopters elsewhere can access the campus services
as simply and as robustly as possible.
o Computer science department. This is where IPv6-related research o Computer science department. This is where IPv6-related research
and/or teaching is most likely to occur, so enabling some or all and/or teaching is most likely to occur, and where many of the
of the campus compauter science department network is a sensible next generation of network engineers are studying, so enabling
first step. some or all of the campus computer science department network is a
sensible first step.
o The eduroam wireless network. Eduroam is the defacto wireless o The eduroam wireless network. Eduroam [I-D.wierenga-ietf-eduroam]
roaming system for academic networks, and uses 802.1X based is the de facto wireless roaming system for academic networks, and
authentication, which is agnostic to the IP version used (unlike uses 802.1X-based authentication, which is agnostic to the IP
web-redirection gateway systems). version used (unlike web-redirection gateway systems). Making a
campus' eduroam network dual-stack is a very viable early step.
8. Security Considerations The general IPv6 deployment model in a campus enterprise will still
follow the general principles described in this document. While the
above early stage projects are commonly followed, these still require
the campus to acquire IPv6 connectivity and address space from their
NREN (or other provider in some parts of the world), and to enable
IPv6 on the wire on at least part of the core of the campus network.
This implies a requirement to have an initial address plan, and to
ensure appropriate monitoring and security measures are in place, as
described elsewhere in this document.
This document has multiple security sections detailing how do Campuses which have deployed to date do not use ULAs, nor do they use
NPTv6. In general, campuses have very stable PA-based address
allocations from their NRENs (or their equivalent). However, campus
enterprises may consider applying for IPv6 PI; some have already done
so. The discussions earlier in this text about PA vs. PI still
apply.
Finally, campuses may be more likely than many other enterprises to
run multicast applications, such as IP TV or live lecture or seminar
streaming, so may wish to consider support for specific IPv6
multicast functionality, e.g. Embedded-RP [RFC3956] in routers and
MLDv1 and MLDv2 snooping in switches.
7. Security Considerations
This document has multiple security sections detailing how to
securely deploy an IPv6 network within an enterprise network. securely deploy an IPv6 network within an enterprise network.
9. Acknowledgements 8. Acknowledgements
The authors would like to thank Chris Grundemann, Ray Hunter, Brian The authors would like to thank Chris Grundemann, Ray Hunter, Brian
Carpenter, Tina Tsou for their comments on the mailing list. Carpenter, Tina Tsou, Christian Jaquenet, and Fred Templin for their
substantial comments and contributions.
10. IANA Considerations 9. IANA Considerations
There are no IANA considerations or implications that arise from this There are no IANA considerations or implications that arise from this
document. document.
11. References 10. Informative References
11.1. Normative References [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng",
Requirement Levels", BCP 14, RFC 2119, March 1997. RFC 1687, August 1994.
11.2. Informative References [RFC1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817,
August 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for
the Internet Protocol using SMIv2", RFC 2011, the Internet Protocol using SMIv2", RFC 2011,
November 1996. November 1996.
[RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, [RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096,
January 1997. January 1997.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
June 2005. June 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4293] Routhier, S., "Management Information Base for the [RFC4293] Routhier, S., "Management Information Base for the
skipping to change at page 25, line 43 skipping to change at page 30, line 39
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", RFC 6104, February 2011. Problem Statement", RFC 6104, February 2011.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011. February 2011.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011. IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011. April 2011.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, March 2011.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
Router Links", RFC 6164, April 2011. Router Links", RFC 6164, April 2011.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, March 2011. Router Control Plane", RFC 6192, March 2011.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011.
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
"Logging Recommendations for Internet-Facing Servers", "Logging Recommendations for Internet-Facing Servers",
BCP 162, RFC 6302, June 2011. BCP 162, RFC 6302, June 2011.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011. Requirements", RFC 6434, December 2011.
[RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol
(HIP) Experiment Report", RFC 6538, March 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6555] "Happy Eyeballs: Success with Dual-Stack Hosts".
[RFC6583] "Operational Neighbor Discovery Problems".
[I-D.xli-behave-divi] [I-D.xli-behave-divi]
Shang, W., Li, X., Zhai, Y., and C. Bao, "dIVI: Dual- Shang, W., Li, X., Zhai, Y., and C. Bao, "dIVI: Dual-
Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-04 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-04
(work in progress), October 2011. (work in progress), October 2011.
[I-D.gashinsky-v6ops-v6nd-problems] [I-D.wierenga-ietf-eduroam]
Jaeggli, J., Kumari, W., and I. Gashinsky, "Operational Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
Neighbor Discovery Problem", architecture for network roaming",
draft-gashinsky-v6ops-v6nd-problems-00 (work in progress), draft-wierenga-ietf-eduroam-00 (work in progress),
October 2011. October 2012.
[I-D.ietf-savi-threat-scope] [I-D.ietf-savi-threat-scope]
McPherson, D., Baker, F., and J. Halpern, "SAVI Threat McPherson, D., Baker, F., and J. Halpern, "SAVI Threat
Scope", draft-ietf-savi-threat-scope-05 (work in Scope", draft-ietf-savi-threat-scope-06 (work in
progress), April 2011. progress), February 2013.
[I-D.lopez-v6ops-dc-ipv6] [I-D.lopez-v6ops-dc-ipv6]
Chen, Z., Lopez, D., Tsou, T., and C. Zhou, "A Reference Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin,
Framework for DC Migration to IPv6", "IPv6 Operational Guidelines for Datacenters",
draft-lopez-v6ops-dc-ipv6-02 (work in progress), draft-lopez-v6ops-dc-ipv6-04 (work in progress),
June 2012. February 2013.
[I-D.templin-v6ops-isops] [I-D.templin-v6ops-isops]
Templin, F., "Operational Guidance for IPv6 Deployment in Templin, F., "Operational Guidance for IPv6 Deployment in
IPv4 Sites using ISATAP", draft-templin-v6ops-isops-17 IPv4 Sites using ISATAP", draft-templin-v6ops-isops-18
(work in progress), May 2012. (work in progress), October 2012.
[I-D.matthews-v6ops-design-guidelines] [I-D.carpenter-6man-ext-transmit]
Matthews, P., "Design Guidelines for IPv6 Networks", Carpenter, B. and S. Jiang, "Transmission of IPv6
draft-matthews-v6ops-design-guidelines-00 (work in Extension Headers", draft-carpenter-6man-ext-transmit-02
progress), June 2012. (work in progress), February 2013.
[I-D.vyncke-opsec-v6] [I-D.ietf-6renum-enterprise]
Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations and
Methods", draft-ietf-6renum-enterprise-06 (work in
progress), January 2013.
[I-D.ietf-6renum-static-problem]
Carpenter, B. and S. Jiang, "Problem Statement for
Renumbering IPv6 Hosts with Static Addresses in Enterprise
Networks", draft-ietf-6renum-static-problem-03 (work in
progress), December 2012.
[I-D.ietf-v6ops-design-choices]
Matthews, P., "Design Choices for IPv6 Networks",
draft-ietf-v6ops-design-choices-00 (work in progress),
February 2013.
[I-D.ietf-opsec-v6]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", Security Considerations for IPv6 Networks",
draft-vyncke-opsec-v6-01 (work in progress), July 2012. draft-ietf-opsec-v6-02 (work in progress), February 2013.
[I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-00 (work in
progress), December 2012.
[I-D.ietf-opsec-ipv6-implications-on-ipv4-nets]
Gont, F. and W. Liu, "Security Implications of IPv6 on
IPv4 Networks",
draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 (work
in progress), February 2013.
[I-D.ietf-v6ops-ra-guard-implementation]
Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)",
draft-ietf-v6ops-ra-guard-implementation-07 (work in
progress), November 2012.
[I-D.ietf-v6ops-icp-guidance]
Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content and Application Service Providers",
draft-ietf-v6ops-icp-guidance-05 (work in progress),
January 2013.
[SMURF] "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service [SMURF] "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service
Attacks", Attacks",
<http://www.cert.org/advisories/CA-1998-01.html>. <http://www.cert.org/advisories/CA-1998-01.html>.
[CYMRU] "THE BOGON REFERENCE", [CYMRU] "THE BOGON REFERENCE",
<http://www.team-cymru.org/Services/Bogons/>. <http://www.team-cymru.org/Services/Bogons/>.
Authors' Addresses Authors' Addresses
 End of changes. 170 change blocks. 
616 lines changed or deleted 912 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/