draft-ietf-v6ops-enterprise-incremental-ipv6-06.txt   rfc7381.txt 
Network Working Group K. Chittimaneni Internet Engineering Task Force (IETF) K. Chittimaneni
Internet-Draft Dropbox Inc. Request for Comments: 7381 Dropbox, Inc.
Intended status: Informational T. Chown Category: Informational T. Chown
Expires: February 1, 2015 University of Southampton ISSN: 2070-1721 University of Southampton
L. Howard L. Howard
Time Warner Cable Time Warner Cable
V. Kuarsingh V. Kuarsingh
Dyn Inc Dyn, Inc.
Y. Pouffary Y. Pouffary
Hewlett Packard Hewlett Packard
E. Vyncke E. Vyncke
Cisco Systems Cisco Systems
July 31, 2014 October 2014
Enterprise IPv6 Deployment Guidelines Enterprise IPv6 Deployment Guidelines
draft-ietf-v6ops-enterprise-incremental-ipv6-06
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
while introducing IPv6 access within the enterprise IT network. The introducing IPv6 access within the enterprise IT network. The
overall transition will take most networks from an IPv4-only overall transition will take most networks from an IPv4-only
environment to a dual stack network environment and eventually an environment to a dual-stack network environment and eventually an
IPv6-only operating mode. This document helps provide a framework IPv6-only operating mode. This document helps provide a framework
for enterprise network architects or administrators who may be faced for enterprise network architects or administrators who may be faced
with many of these challenges as they consider their IPv6 support with many of these challenges as they consider their IPv6 support
strategies. strategies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7381.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 1, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 4 1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 5
1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . 4 1.2. IPv4-Only Considerations . . . . . . . . . . . . . . . . 5
1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 5 1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 6
2. Preparation and Assessment Phase . . . . . . . . . . . . . . 6 2. Preparation and Assessment Phase . . . . . . . . . . . . . . 7
2.1. Program Planning . . . . . . . . . . . . . . . . . . . . 6 2.1. Program Planning . . . . . . . . . . . . . . . . . . . . 7
2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 7 2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Network infrastructure readiness assessment . . . . . 7 2.2.1. Network Infrastructure Readiness Assessment . . . . . 8
2.2.2. Applications readiness assessment . . . . . . . . . . 8 2.2.2. Application Readiness Assessment . . . . . . . . . . 9
2.2.3. Importance of readiness validation and testing . . . 8 2.2.3. Importance of Readiness Validation and Testing . . . 9
2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 9 2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. IPv6 is no more secure than IPv4 . . . . . . . . . . 9 2.4.1. IPv6 Is No More Secure Than IPv4 . . . . . . . . . . 10
2.4.2. Similarities between IPv6 and IPv4 security . . . . . 10 2.4.2. Similarities between IPv6 and IPv4 Security . . . . . 11
2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 10 2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 11
2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 13 2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 14
2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 15 2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 16
3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 16 3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 19 3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 20
3.4. Servers and Applications . . . . . . . . . . . . . . . . 19 3.4. Servers and Applications . . . . . . . . . . . . . . . . 20
3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 20 3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 21
4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 20 4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 21 4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 22
4.3. End user devices . . . . . . . . . . . . . . . . . . . . 22 4.3. End-User Devices . . . . . . . . . . . . . . . . . . . . 23
4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 23 4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 24
5. IPv6 Only . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Considerations for Specific Enterprises . . . . . . . . . . . 26
6. Considerations For Specific Enterprises . . . . . . . . . . . 25 6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 26
6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 25 6.2. Data Center Virtualization . . . . . . . . . . . . . . . 26
6.2. Data Center Virtualization . . . . . . . . . . . . . . . 25 6.3. University Campus Networks . . . . . . . . . . . . . . . 26
6.3. University Campus Networks . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. Informative References . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
10. Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
An Enterprise Network is 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 a department
administrators). Administrators generally support an internal of administrators). Administrators generally support an internal
network, consisting of users' workstations, personal computers, network, consisting of users' workstations; personal computers;
mobile devices, other computing devices and related peripherals, a mobile devices; other computing devices and related peripherals; a
server network, consisting of accounting and business application server network, consisting of accounting and business application
servers, and an external network, consisting of Internet-accessible servers; and an external network, consisting of Internet-accessible
services such as web servers, email servers, VPN systems, and services such as web servers, email servers, VPN systems, and
customer applications. This document is intended as guidance for customer applications. This document is intended as guidance for
enterprise network architects and administrators in planning their enterprise network architects and administrators in planning their
IPv6 deployments. 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, MAP-T, MAP-E, or other transition NAT64, NAT444, Dual-Stack Lite (DS-Lite), Mapping of Address and Port
technologies. Compared to tunneled or translated service, native using Translation (MAP-T), Mapping of Address and Port using
traffic typically performs better and more reliably than non-native. Encapsulation (MAP-E), or other transition technologies. Compared to
For example, for client networks trying to reach enterprise networks, tunneled or translated service, native traffic typically performs
the IPv6 experience will be better than the transitional IPv4 if the better and more reliably than non-native. For example, for client
enterprise deploys IPv6 in its public- facing services. The native networks trying to reach enterprise networks, the IPv6 experience
IPv6 network path should also be simpler to manage and, if necessary, will be better than the transitional IPv4 if the enterprise deploys
troubleshoot. Further, enterprises doing business in growing parts IPv6 in its public-facing services. The native IPv6 network path
of the world may find IPv6 growing faster there, where again should also be simpler to manage and, if necessary, troubleshoot.
potential new customers, employees and partners are using IPv6. It Further, enterprises doing business in growing parts of the world may
is thus in the enterprise's interests to deploy native IPv6, at the find IPv6 growing faster there, where again potential new customers,
very least in its public-facing services, but ultimately across the employees, and partners are using IPv6. It is thus in the
majority or all of its scope. enterprise's interest 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 The text in this document provides specific guidance for enterprise
networks, and complements other related work in the IETF, including networks and complements other related work in the IETF, including
[I-D.ietf-v6ops-design-choices] and [RFC5375]. [IPv6-DESIGN] and [RFC5375].
1.1. Enterprise Assumptions 1.1. Enterprise Assumptions
For the purpose of this document, we assume: For the purpose of this document, we assume the following:
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 that will
will continue to operate and be supported. 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 the number of technologies
functions that are needed to mediate any given application. In and functions that are needed to mediate any given application.
other words: provide native IP wherever possible. In 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 that minimize the number of flows being tunneled,
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 that both allow most
to be native, and will manage non-native traffic. This will allow traffic to be native and manage non-native traffic. This will allow
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.
Tunnels used for IPv6/IPv4 transition are expected as near/mid- term Tunnels used for IPv6/IPv4 transition are expected as near-/mid-term
mechanisms, while IPv6 tunneling will be used for many long-term mechanisms, while IPv6 tunneling will be used for many long-term
operational purposes such as security, routing control, mobility, operational purposes such as security, routing control, mobility,
multi-homing, traffic engineering, etc. We refer to the former class multihoming, traffic engineering, etc. We refer to the former class
of tunnels as "transition tunnels" of tunnels as "transition tunnels".
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 NAT444, of malefactors behind address-sharing technologies such as NAT444,
MAP, or Dual-stack Lite. Such logs should be protected for MAP, or DS Lite. Such logs should be protected for integrity,
integrity, safeguarded for privacy and periodically purged within safeguarded for privacy, and periodically purged within applicable
applicable regulations for log retention. regulations for log retention.
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 Router Advertisement (RA)
problems in IPv4-only networks where IPv6 is enabled in end systems problem, which may cause problems in IPv4-only networks where IPv6 is
on that network. Further discussion of the security implications of enabled in end systems on that network. Further discussion of the
IPv6 in IPv4-only networks can be found in [RFC7123]). security implications of IPv6 in IPv4-only networks can be found in
[RFC7123].
1.3. Reasons for a Phased Approach 1.3. Reasons for a Phased Approach
Given the challenges of transitioning 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. This document outlines suggested determination of priorities. This document outlines suggested
phases: a Preparation and Assessment Phase, an Internal Phase, and an phases: a Preparation and Assessment Phase, an Internal Phase, and an
External Phase. The Preparation Phase is highly recommended to all External Phase. The Preparation Phase is highly recommended to all
administrators, as it will save errors and complexity in later administrators, as it will save errors and complexity in later
skipping to change at page 5, line 35 skipping to change at page 6, line 33
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 such that those customers have the prioritize the External Phase such that those customers have the
simplest and most robust connectivity to the enterprise, or at simplest and most robust connectivity to the enterprise, or at
least its external-facing elements. 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. It is worth noting that a number of emerging internal systems. It is worth noting that a number of emerging
VPN solutions provide dual-stack connectivity; thus a VPN service VPN solutions provide dual-stack connectivity; thus, a VPN service
may be useful for employees in IPv4-only access networks to access may be useful for employees in IPv4-only access networks to access
IPv6 resources in the enterprise network (much like many public IPv6 resources in the enterprise network (much like many public
tunnel broker services, but specifically for the enterprise). tunnel broker services, but specifically for the enterprise).
Some security considerations are described in Some security considerations are described in [RFC7359].
[I-D.ietf-opsec-vpn-leakages].
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 o Virtual Machines (VMs) may enable a faster rollout once initial
deployment is complete. Management of VMs over IPv6 is still system deployment is complete. Management of VMs over IPv6 is
dependent on the management software supporting IPv6. 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. It is important to manage IPv6 for security purposes, traffic. It is important to manage IPv6 for security purposes,
even in an ostensibly IPv4-only network, as described in even in an ostensibly IPv4-only network, as described in
[RFC7123]. [RFC7123].
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. As enterprises internal network, so they may be a lower priority. As enterprises
require their vendors to support IPv6, more internal applications require their vendors to support IPv6, more internal applications
will support IPv6 by default and it can be expected that will support IPv6 by default, and it can be expected that
eventually new applications will only support IPv6. The eventually new applications will only support IPv6. The
inventory, as described in Section 2.2, will help determine the inventory, as described in Section 2.2, will help determine the
systems' readiness, as well as the readiness of the supporting systems' readiness, as well as the readiness of the supporting
network elements and security, which will be a consideration in network elements and security, which will be a consideration in
prioritization of these corporate systems. prioritization of these corporate systems.
o Some large organizations (even when using private IPv4 o Some large organizations (even when using private IPv4 addresses
addresses[RFC1918]) are facing IPv4 address exhaustion because of [RFC1918]) are facing IPv4 address exhaustion because of the
the internal network growth (for example the vast number of internal network growth (for example, the vast number of VMs) or
virtual machines) or because of the acquisition of other companies because of the acquisition of other companies that often raise
that often raise private IPv4 address overlapping issues. private IPv4 address overlapping issues.
o IPv6 restores end to end transparency 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).
When two organizations or networks merge [RFC6879], the unique When two organizations or networks merge [RFC6879], the unique
addressing of IPv6 can make the merger much easier and faster. A addressing of IPv6 can make the merger much easier and faster. A
merger may, therefore, prioritize IPv6 for the affected systems. 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 company's conditions. It is worth prioritize according to their company's conditions. It is worth
noting that the reasons given in one "Large Corporate User's View of noting that the reasons given in "A Large Corporate User's View of
IPng", described in [RFC1687], for reluctance to deploy have largely IPng", described in [RFC1687], for reluctance to deploy have largely
been satisfied or overcome in the intervening years. been satisfied or overcome in the intervening years.
2. Preparation and Assessment Phase 2. Preparation and Assessment Phase
2.1. Program Planning 2.1. Program Planning
Since enabling IPv6 is a change to the most fundamental Internet Since enabling IPv6 is a change to the most fundamental Internet
Protocol, and since there are so many interdependencies, having a Protocol, and since there are so many interdependencies, having a
professional project manager organize the work is highly recommended. professional project manager organize the work is highly recommended.
In addition, an executive sponsor should be involved in determining In addition, an executive sponsor should be involved in determining
the goals of enabling IPv6 (which will establish the order of the the goals of enabling IPv6 (which will establish the order of the
phases), and should receive regular updates. phases) and should receive regular updates.
It may be necessary to complete the Preparation Phase before It may be necessary to complete the Preparation Phase before
determining whether to prioritized the Internal or External Phase, determining whether to prioritize the Internal or External Phase,
since needs and readiness assessments are part of that phase. For a since needs and readiness assessments are part of that phase. For a
large enterprise, it may take several iterations to really understand large enterprise, it may take several iterations to really understand
the level of effort required. Depending on the required schedule, it the level of effort required. Depending on the required schedule, it
may be useful to roll IPv6 projects into other architectural may be useful to roll IPv6 projects into other architectural upgrades
upgrades--this can be an excellent way to improve the network and -- this can be an excellent way to improve the network and reduce
reduce costs. However, by increasing the scope of projects, the costs. However, by increasing the scope of projects, the schedule is
schedule is often affected. For instance, a major systems upgrade often affected. For instance, a major systems upgrade may take a
may take a year to complete, where just patching existing systems may year to complete, where just patching existing systems may take only
take only a few months. a few months.
The deployment of IPv6 will not generally stop all other technology The deployment of IPv6 will not generally stop all other technology
work. Once IPv6 has been identified as an important initiative, all work. Once IPv6 has been identified as an important initiative, all
projects, both new and in-progress, will need to be reviewed to projects, both new and in progress, will need to be reviewed to
ensure IPv6 support. ensure IPv6 support.
It is normal for assessments to continue in some areas while It is normal for assessments to continue in some areas while
execution of the project begins in other areas. This is fine, as execution of the project begins in other areas. This is fine, as
long as recommendations in other parts of this document are long as recommendations in other parts of this document are
considered, especially regarding security (for instance, one should considered, especially regarding security (for instance, one should
not deploy IPv6 on a system before security has been evaluated). not deploy IPv6 on a system before security has been evaluated).
2.2. Inventory Phase 2.2. Inventory Phase
To comprehend the scope of the inventory phase we recommend dividing To comprehend the scope of the Inventory Phase, we recommend dividing
the problem space in two: network infrastructure readiness and the problem space in two: network infrastructure readiness and
applications readiness. applications readiness.
2.2.1. Network infrastructure readiness assessment 2.2.1. Network Infrastructure Readiness Assessment
The goal of this assessment is to identify the level of IPv6 The goal of this assessment is to identify the level of IPv6
readiness of network equipment. This will identify the effort readiness of network equipment. This will identify the effort
required to move to an infrastructure that supports IPv6 with the required to move to an infrastructure that supports IPv6 with the
same functional service capabilities as the existing IPv4 network. same functional service capabilities as the existing IPv4 network.
This may also require a feature comparison and gap analysis between This may also require a feature comparison and gap analysis between
IPv4 and IPv6 functionality on the network equipment and software. IPv4 and IPv6 functionality on the network equipment and software.
IPv6 support will require testing; features often work differently in IPv6 support will require testing; features often work differently in
vendors' labs than production networks. Some devices and software vendors' labs than production networks. Some devices and software
will require IPv4 support for IPv6 to work. will require IPv4 support for IPv6 to work.
The inventory will show which network devices are already capable, The inventory will show 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.
Since IPv6 might already be present in the environment, through Since IPv6 might already be present in the environment, through
default configurations or VPNs, an infrastructure assessment (at default configurations or VPNs, an infrastructure assessment (at
minimum) is essential to evaluate potential security risks. minimum) is essential to evaluate potential security risks.
2.2.2. Applications readiness assessment 2.2.2. Application 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, but often 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 over the network will dictate the steps application communicates over the network will dictate the steps
required to support IPv6. Applications should avoid instructions required to support IPv6. Applications should avoid instructions
specific to a given IP address family. Any applications that use specific to a given IP address family. Any applications that use
APIs, such as the C language, that expose the IP version APIs, such as the C language, that expose the IP version
specifically, need to be modified to also work with IPv6. specifically, need to be modified to also work with IPv6.
There are two ways to IPv6-enable applications. The first approach There are two ways to IPv6-enable applications. The first approach
is to have separate logic for IPv4 and IPv6, thus leaving the IPv4 is to have separate logic for IPv4 and IPv6, thus leaving the IPv4
code path mainly untouched. This approach causes the least code path mainly untouched. This approach causes the least
skipping to change at page 8, line 43 skipping to change at page 9, line 40
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. Knowing whether a given IP version used on the network. Knowing whether a given
implementation will use IPv4 or IPv6 in a given deployment is a implementation will use IPv4 or IPv6 in a given deployment is a
matter of some art; see Source Address Selection [RFC6724] and Happy matter of some art; see Source Address Selection [RFC6724] and Happy
Eyeballs [RFC6555]. It is generally recommended that the application Eyeballs [RFC6555]. It is generally recommended that the application
developer use industry IPv6-porting tools to locate the code that developer use industry IPv6-porting tools to locate the code that
needs to be updated. Some discussion of IPv6 application porting needs to be updated. Some discussion of IPv6 application porting
issues can be found in [RFC4038]. issues can be found in [RFC4038].
2.2.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. infrastructure.
2.3. Training 2.3. Training
Many organizations falter in IPv6 deployment because of a perceived Many organizations falter in IPv6 deployment because of a perceived
training gap. Training is important for those who work with training gap. Training is important for those who work with
addresses regularly, as with anyone whose work is changing. Better addresses regularly, as with anyone whose work is changing. Better
knowledge of the reasons IPv6 is being deployed will help inform the knowledge of the reasons IPv6 is being deployed will help inform the
assessment of who needs training, and what training they need. assessment of who needs training and what training they need.
2.4. Security Policy 2.4. Security Policy
It is obvious that IPv6 networks should be deployed in a secure way. It is obvious that IPv6 networks should be deployed in a secure way.
The industry has learnt a lot about network security with IPv4, so, The industry has learned 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. the same exceptions that are described further.
2.4.1. IPv6 is no more secure than IPv4 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
cannot be scanned by enumerating all IPv6 address in a /64 LAN hence network cannot be scanned by enumerating all IPv6 addresses in a /64
a malevolent person cannot find a victim. [RFC5157] describes some LAN; hence, a malevolent person cannot find a victim. [RFC5157]
alternate techniques to find potential targets on a network, for describes some alternate techniques to find potential targets on a
example enumerating all DNS names in a zone. Additional advice in network, for example, enumerating all DNS names in a zone.
this area is also given in [I-D.ietf-opsec-ipv6-host-scanning]. Additional advice in this area is also given in [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. While the original IPv6 specifications the use of IPsec everywhere. While the original IPv6 specifications
may have implied this, [RFC6434] clearly states that IPsec support is may have implied this, [RFC6434] clearly states that IPsec support is
not mandatory. Moreover, if all the intra-enterprise traffic is not mandatory. Moreover, if all the intra-enterprise traffic is
encrypted, both malefactors and security tools that rely on payload encrypted, both malefactors and security tools that rely on payload
inspection (IPS, firewall, ACL, IPFIX ([RFC7011] and [RFC7012]), etc) inspection (Intrusion Prevention System (IPS), firewall, Access
will be thwarted. Therefore, IPsec is as useful in IPv6 as in IPv4 Control List (ACL), IP Flow Information Export (IPFIX) ([RFC7011] and
(for example to establish a VPN overlay over a non-trusted network or [RFC7012]), etc.) will be affected. Therefore, IPsec is as useful in
reserved for some specific applications). IPv6 as in IPv4 (for example, to establish a VPN overlay over a non-
trusted network or to reserve 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 (see Section 2.4 of [RFC4443]). receiving a multicast message (see Section 2.4 of [RFC4443]).
Therefore, the generation and the forwarding rate of ICMPv6 messages Therefore, the generation and the forwarding rate of ICMPv6 messages
must be limited as in IPv4. must be limited as in IPv4.
It should be noted that in a dual-stack network the security It should be noted that in a dual-stack network, the security
implementation for both IPv4 and IPv6 needs to be considered, in implementation for both IPv4 and IPv6 needs to be considered, in
addition to security considerations related to the interaction of addition to security considerations related to the interaction of
(and transition between) the two, while they coexist. (and transition between) the two, while they coexist.
2.4.2. Similarities between IPv6 and IPv4 security 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 families, including: several attacks apply for both protocol families, including:
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 Wi-Fi 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])
A specific case of congruence is IPv6 Unique Local Addresses (ULAs) A specific case of congruence is IPv6 Unique Local Addresses (ULAs)
[RFC4193] and IPv4 private addressing [RFC1918], which do not provide [RFC4193] and IPv4 private addressing [RFC1918], which do not provide
any security by 'magic'. In both cases, the edge router must apply any security by 'magic'. In both cases, the edge router must apply
strict filters to block those private addresses from entering and, strict filters to block those private addresses from entering and,
just as importantly, leaving the network. This filtering can be done just as importantly, leaving the network. This filtering can be done
by the enterprise or by the ISP, but the cautious administrator will by the enterprise or by the ISP, but the cautious administrator will
prefer to do it in the enterprise. 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 bogon IPv6 addresses (see [CYMRU]). 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, or both, but again the cautious done by the enterprise or by the ISP, or both, but again the cautious
administrator will prefer to do it in the enterprise. administrator will prefer to do it in the enterprise.
2.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. We give examples of create some IPv6-only vulnerabilities or issues. We give examples of
such differences in this section. such differences in this section.
Privacy extension addresses [RFC4941] are usually used to protect Privacy extension addresses [RFC4941] are usually used to protect
individual privacy by periodically changing the interface identifier individual privacy by periodically changing the interface identifier
part of the IPv6 address to avoid tracking a host by its otherwise part of the IPv6 address to avoid tracking a host by its otherwise
always identical and unique MAC-based EUI-64. While this presents a always identical and unique 64-bit Extended Unique Identifier
(EUI-64) based on Media Access Control (MAC). While this presents a
real advantage on the Internet, moderated by the fact that the prefix real advantage on the Internet, moderated by the fact that the prefix
part remains the same, it complicates the task of following an audit part remains the same, it complicates the task of following an audit
trail when a security officer or network operator wants to trace back trail when a security officer or network operator wants to trace back
a log entry to a host in their network, because when the tracing is a log entry to a host in their network because when the tracing is
done the searched IPv6 address could have disappeared from the done, the searched IPv6 address could have disappeared from the
network. Therefore, the use of privacy extension addresses usually network. Therefore, the use of privacy extension addresses usually
requires additional monitoring and logging of the binding of the IPv6 requires additional monitoring and logging of the binding of the IPv6
address to a data-link layer address (see also the monitoring section address to a data-link layer address (see also the monitoring section
of [I-D.ietf-opsec-v6]). Some early enterprise deployments have in [IPv6-SECURITY], Section 2.5). Some early enterprise deployments
taken the approach of using tools that harvest IP/MAC address have taken the approach of using tools that harvest IP/MAC address
mappings from switch and router devices to provide address mappings from switch and router devices to provide address
accountability; this approach has been shown to work, though it can accountability; this approach has been shown to work, though it can
involve gathering significantly more address data than in equivalent involve gathering significantly more address data than in equivalent
IPv4 networks. An alternative is to try to prevent the use of IPv4 networks. An alternative is to try to prevent the use of
privacy extension addresses by enforcing the use of DHCPv6, such that privacy extension addresses by enforcing the use of DHCPv6, such that
hosts only get addresses assigned by a DHCPv6 server. This can be hosts only get addresses assigned by a DHCPv6 server. This can be
done by configuring routers to set the M-bit in Router done by configuring routers to set the M bit in RAs, combined with
Advertisements, combined with all advertised prefixes being included all advertised prefixes being included without the A bit set (to
without the A-bit set (to prevent the use of stateless auto- prevent the use of stateless autoconfiguration). Of course, this
configuration). This technique of course requires that all hosts technique requires that all hosts support stateful DHCPv6. It is
support stateful DHCPv6. It is important to note that not all important to note that not all operating systems exhibit the same
operating systems exhibit the same behavior when processing RAs with behavior when processing RAs with the M bit set. The varying OS
the M-Bit set. The varying OS behavior is related to the lack of behavior is related to the lack of prescriptive definition around the
prescriptive definition around the A, M and O-bits within the ND A, M, and O bits within the Neighbor Discovery Protocol (NDP).
protocol. [I-D.liu-bonica-dhcpv6-slaac-problem] provides a much more [DHCPv6-SLAAC-PROBLEM] provides a much more detailed analysis on the
detailed analysis on the interaction of the M-Bit and DHCPv6. interaction of the M bit and DHCPv6.
Extension headers complicate the task of stateless packet filters Extension headers complicate the task of stateless packet filters
such as ACLs. If ACLs are used to enforce a security policy, then such as ACLs. If ACLs are used to enforce a security policy, then
the enterprise must verify whether its ACL (but also stateful the enterprise must verify whether its ACLs (but also stateful
firewalls) are able to process extension headers (this means firewalls) are able to process extension headers (this means
understand them enough to parse them to find the upper layers understand them enough to parse them to find the upper-layer
payloads) and to block unwanted extension headers (e.g., to implement payloads) and to block unwanted extension headers (e.g., to implement
[RFC5095]). This topic is discussed further in [RFC7045]. [RFC5095]). This topic is discussed further in [RFC7045].
Fragmentation is different in IPv6 because it is done only by source Fragmentation is different in IPv6 because it is done only by the
host and never during a forwarding operation. This means that ICMPv6 source host and never during a forwarding operation. This means that
packet-too-big messages must be allowed to pass through the network ICMPv6 packet-too-big messages must be allowed to pass through the
and not be filtered [RFC4890]. Fragments can also be used to evade network and not be filtered [RFC4890]. Fragments can also be used to
some security mechanisms such as RA-guard [RFC6105]. See also evade some security mechanisms such as RA-Guard [RFC6105]. See also
[RFC5722], and [RFC7113]. [RFC5722] and [RFC7113].
One of the biggest differences between IPv4 and IPv6 is the One of the biggest differences between IPv4 and IPv6 is the
introduction of the Neighbor Discovery Protocol [RFC4861], which introduction of NDP [RFC4861], which includes a variety of important
includes a variety of important IPv6 protocol functions, including IPv6 protocol functions, including those provided in IPv4 by the
those provided in IPv4 by ARP [RFC0826]. NDP runs over ICMPv6 (which Address Resolution Protocol (ARP) [RFC0826]. NDP runs over ICMPv6
as stated above means that security policies must allow some ICMPv6 (which as stated above means that security policies must allow some
messages to pass, as described in RFC 4890), but has the same lack of ICMPv6 messages to pass, as described in RFC 4890), but has the same
security as, for example, ARP, in that there is no inherent message lack of security as, for example, ARP, in that there is no inherent
authentication. While Secure Neighbour Discovery (SeND) [RFC3971] message authentication. While Secure Neighbor Discovery (SEND)
and CGA [RFC3972] have been defined, they are not widely [RFC3971] and Cryptographically Generated Addresses (CGAs) [RFC3972]
implemented). The threat model for Router Advertisements within the have been defined, they are not widely implemented). The threat
NDP suite is similar to that of DHCPv4 (and DHCPv6), in that a rogue model for RAs within the NDP suite is similar to that of DHCPv4 (and
host could be either a rogue router or a rogue DHCP server. An IPv4 DHCPv6), in that a rogue host could be either a rogue router or a
network can be made more secure with the help of DHCPv4 snooping in rogue DHCP server. An IPv4 network can be made more secure with the
edge switches, and likewise RA snooping can improve IPv6 network help of DHCPv4 snooping in edge switches, and likewise RA snooping
security (in IPv4-only networks as well). Thus enterprises using can improve IPv6 network security (in IPv4-only networks as well).
such techniques for IPv4 should use the equivalent techniques for Thus, enterprises using such techniques for IPv4 should use the
IPv6, including RA-guard [RFC6105] and all work in progress from the equivalent techniques for IPv6, including RA-Guard [RFC6105] and all
SAVI WG, e.g. [RFC6959], which is similar to the protection given by work in progress from the Source Address Validation Improvement
dynamic ARP monitoring in IPv4. Other DoS vulnerabilities are (SAVI) WG, e.g., [RFC6959], 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 related to NDP cache exhaustion, and mitigation techniques can be
found in ([RFC6583]). found in ([RFC6583]).
As stated previously, running a dual-stack network doubles the attack As stated previously, running a dual-stack network doubles the attack
exposure as a malevolent person has now two attack vectors: IPv4 and exposure as a malevolent person has now two attack vectors: IPv4 and
IPv6. This simply means that all routers and hosts operating in a IPv6. This simply means that all routers and hosts operating in a
dual-stack environment with both protocol families enabled (even if dual-stack environment with both protocol families enabled (even if
by default) must have a congruent security policy for both protocol by default) must have a congruent security policy for both protocol
versions. For example, permit TCP ports 80 and 443 to all web versions. For example, permit TCP ports 80 and 443 to all web
servers and deny all other ports to the same servers must be servers and deny all other ports to the same servers must be
implemented both for IPv4 and IPv6. It is thus important that the implemented both for IPv4 and IPv6. It is thus important that the
tools available to administrators readily support such behaviour. tools available to administrators readily support such behavior.
2.5. Routing 2.5. Routing
An important design choice to be made is what IGP to use inside the An important design choice to be made is what IGP is to use inside
network. A variety of IGPs (IS-IS, OSPFv3 and RIPng) support IPv6 the network. A variety of IGPs (IS-IS, OSPFv3, and Routing
today and picking one over the other is a design choice that will be Information Protocol Next Generation (RIPng)) support IPv6 today, and
dictated mostly by existing operational policies in an enterprise picking one over the other is a design choice that will be dictated
network. As mentioned earlier, it would be beneficial to maintain mostly by existing operational policies in an enterprise network. As
operational parity between IPv4 and IPv6 and therefore it might make mentioned earlier, it would be beneficial to maintain operational
sense to continue using the same protocol family that is being used parity between IPv4 and IPv6; therefore, it might make sense to
for IPv4. For example, in a network using OSPFv2 for IPv4, it might continue using the same protocol family that is being used for IPv4.
make sense to use OSPFv3 for IPv6. It is important to note that For example, in a network using OSPFv2 for IPv4, it might make sense
although OSPFv3 is similar to OSPFv2, they are not the same. On the to use OSPFv3 for IPv6. It is important to note that although OSPFv3
other hand, some organizations may chose to run different routing is similar to OSPFv2, they are not the same. On the other hand, some
protocols for different IP versions. For example, one may chose to organizations may chose to run different routing protocols for
run OSPFv2 for IPv4 and IS-IS for IPv6. An important design question different IP versions. For example, one may chose to run OSPFv2 for
to consider here is whether to support one IGP or two different IGPs IPv4 and IS-IS for IPv6. An important design question to consider
in the longer term. [I-D.ietf-v6ops-design-choices] presents advice here is whether to support one IGP or two different IGPs in the
on the design choices that arise when considering IGPs and discusses longer term. [IPv6-DESIGN] presents advice on the design choices
the advantages and disadvantages to different approaches in detail. that arise when considering IGPs and discusses the advantages and
disadvantages to different approaches in detail.
2.6. Address Plan 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 non-contiguous 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 thought 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. [I-D.ietf-v6ops-ula-usage-recommendations] the requirement for ULA. [ULA-USAGE] provides much more detailed
provides much more detailed analysis and recommendations on the usage analysis and recommendations on the usage of ULAs.
of ULAs.
The enterprise administrator will want to evaluate whether the The enterprise administrator will want to evaluate whether the
enterprise will request address space from a LIR (Local Internet enterprise will request address space from a Local Internet Registry
Registry, such as an ISP), a RIR (Regional Internet Registry, such as (LIR) such as an ISP; a Regional Internet Registry (RIR) 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 (NIR) operated in some countries. The normal allocation is
allocation is Provider Aggregatable (PA) address space from the Provider-Aggregated (PA) address space from the enterprise's ISP, but
enterprise's ISP, but use of PA space implies renumbering when use of PA space implies renumbering when changing providers.
changing provider. Instead, an enterprise may request Provider Instead, an enterprise may request Provider-Independent (PI) space;
Independent (PI) space; this may involve an additional fee, but the this may involve an additional fee, but the enterprise may then be
enterprise may then be better able to be multihomed using that better able to be multihomed using that prefix and will avoid a
prefix, and will avoid a renumbering process when changing ISPs renumbering process when changing ISPs (though it should be noted
(though it should be noted that renumbering caused by outgrowing the that renumbering caused by outgrowing the space, merger, or other
space, merger, or other internal reason would still not be avoided internal reason would still not be avoided with PI space).
with PI space).
The type of address selected (PI vs. PA) should be congruent with the The type of address selected (PI vs. PA) should be congruent with the
routing needs of the enterprise. The selection of address type will routing needs of the enterprise. The selection of address type will
determine if an operator will need to apply new routing techniques determine if an operator will need to apply new routing techniques
and may limit future flexibility. There is no right answer, but the and may limit future flexibility. There is no right answer, but the
needs of the external phase may affect what address type is selected. needs of the External Phase may affect what address type is selected.
Each network location or site will need a prefix assignment. Each network location or site will need a prefix assignment.
Depending on the type of site/location, various prefix sizes may be Depending on the type of site/location, various prefix sizes may be
used. In general, historical guidance suggests that each site should used. In general, historical guidance suggests that each site should
get at least a /48, as documented in RFC 5375 and [RFC6177]. In 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. the local ISP supports it.
When assigning addresses to end systems, the enterprise may use When assigning addresses to end systems, the enterprise may use
manually-configured addresses (common on servers) or SLAAC or DHCPv6 manually configured addresses (common on servers) or Stateless
for client systems. Early IPv6 enterprise deployments have used Address Autoconfiguration (SLAAC) or DHCPv6 for client systems.
SLAAC, both for its simplicity but also due to the time DHCPv6 has
taken to mature. However, DHCPv6 is now very mature, and thus Early IPv6 enterprise deployments have used SLAAC both for its
workstations managed by an enterprise may use stateful DHCPv6 for simplicity and the time DHCPv6 has taken to mature. However, DHCPv6
addressing on corporate LAN segments. DHCPv6 allows for the is now very mature; thus, workstations managed by an enterprise may
additional configuration options often employed by enterprise use stateful DHCPv6 for addressing on corporate LAN segments. DHCPv6
administrators, and by using stateful DHCPv6, administrators allows for the additional configuration options often employed by
correlating system logs know which system had which address at any enterprise administrators, and by using stateful DHCPv6,
given time. Such an accountability model is familiar from IPv4 administrators correlating system logs know which system had which
management, though for DHCPv6 hosts are identified by DUID rather address at any given time. Such an accountability model is familiar
than MAC address. For equivalent accountability with SLAAC (and from IPv4 management, though DHCPv6 hosts are identified by a DHCP
potentially privacy addresses), a monitoring system that harvests IP/ Unique Identifier (DUID) rather than a MAC address. For equivalent
MAC mappings from switch and router equipment could be used. accountability with SLAAC (and potentially privacy addresses), a
monitoring system that harvests IP/MAC mappings from switch and
router equipment could be used.
A common deployment consideration for any enterprise network is how A common deployment consideration for any enterprise network is how
to get host DNS records updated. Commonly, either the host will send to get host DNS records updated. Commonly, either the host will send
DNS updates or the DHCP server will update records. If there is DNS updates or the DHCP server will update records. If there is
sufficient trust between the hosts and the DNS server, the hosts may sufficient trust between the hosts and the DNS server, the hosts may
update (and the enterprise may use SLAAC for addressing). Otherwise, update (and the enterprise may use SLAAC for addressing). Otherwise,
the DHCPv6 server can be configured to update the DNS server. Note the DHCPv6 server can be configured to update the DNS server. Note
that an enterprise network with this more controlled environment will that an enterprise network with this more controlled environment will
need to disable SLAAC on network segments and force end hosts to use need to disable SLAAC on network segments and force end hosts to use
DHCPv6 only. DHCPv6 only.
In the data center or server room, assume a /64 per VLAN. This 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 applies even if each individual system is on a separate VLAN. In a
/48 assignment, typical for a site, there are then still 65,535 /64 /48 assignment, typical for a site, there are then still 65,535 /64
blocks. Some administrators reserve a /64 but configure a small blocks. Some administrators reserve a /64 but configure a small
subnet, such as /112, /126, or /127, to prevent rogue devices from subnet, such as /112, /126, or /127, to prevent rogue devices from
attaching and getting numbers; an alternative is to monitor traffic attaching and getting numbers; an alternative is to monitor traffic
for surprising addresses or ND tables for new entries. Addresses are for surprising addresses or Neighbor Discovery (ND) tables for new
either configured manually on the server, or reserved on a DHCPv6 entries. Addresses are either configured manually on the server or
server, which may also synchronize forward and reverse DNS (though reserved on a DHCPv6 server, which may also synchronize forward and
see [RFC6866] for considerations on static addressing). SLAAC is not reverse DNS (though see [RFC6866] for considerations on static
recommended for servers, because of the need to synchronize RA timers addressing). SLAAC is not recommended for servers because of the
with DNS TTLs so that the DNS entry expires at the same time as the need to synchronize RA timers with DNS Times to Live (TTLs) so that
address. the DNS entry expires at the same time as the address.
All user access networks should be a /64. Point-to-point links where All user access networks should be a /64. Point-to-point links where
Neighbor Discovery Protocol is not used may also utilize a /127 (see NDP is not used may also utilize a /127 (see [RFC6164]).
[RFC6164]).
Plan to aggregate at every layer of network hierarchy. There is no Plan to aggregate at every layer of network hierarchy. There is no
need for VLSM [RFC1817] in IPv6, and addressing plans based on need for variable length subnet mask (VLSM) [RFC1817] in IPv6, and
conservation of addresses are short-sighted. Use of prefixes longer addressing plans based on conservation of addresses are shortsighted.
then /64 on network segments will break common IPv6 functions such as Use of prefixes longer then /64 on network segments will break common
SLAAC[RFC4862]. Where multiple VLANs or other layer two domains IPv6 functions such as SLAAC [RFC4862]. Where multiple VLANs or
converge, allow some room for expansion. Renumbering due to other Layer 2 domains converge, allow some room for expansion.
outgrowing the network plan is a nuisance, so allow room within it. Renumbering due to outgrowing the network plan is a nuisance, so
Generally, plan to grow to about twice the current size that can be allow room within it. Generally, plan to grow to about twice the
accommodated; where rapid growth is planned, allow for twice that current size that can be accommodated; where rapid growth is planned,
growth. Also, if DNS (or reverse DNS) authority may be delegated to allow for twice that growth. Also, if DNS (or reverse DNS) authority
others in the enterprise, assignments need to be on nibble boundaries may be delegated to others in the enterprise, assignments need to be
(that is, on a multiple of 4 bits, such as /64, /60, /56, ..., /48, on nibble boundaries (that is, on a multiple of 4 bits, such as /64,
/44), to ensure that delegated zones align with assigned prefixes. /60, /56, ..., /48, /44), to ensure that delegated zones align with
assigned prefixes.
If using ULAs, it is important to note that AAAA and PTR records for If using ULAs, it is important to note that AAAA and PTR records for
ULA are not recommended to be installed in the global DNS. ULAs are not recommended to be installed in the global DNS.
Similarly, reverse (address-to-name) queries for ULA must not be sent Similarly, reverse (address-to-name) queries for ULA must not be sent
to name servers outside of the organization, due to the load that to name servers outside of the organization, due to the load that
such queries would create for the authoritative name servers for the such queries would create for the authoritative name servers for the
ip6.arpa zone. For more details please refer to section 4.4 of ip6.arpa zone. For more details, please refer to Section 4.4 of
[RFC4193]. [RFC4193].
Enterprise networks more and more include virtual networks where a Enterprise networks are increasingly including virtual networks where
single physical node may host many virtualized addressable devices. a single, physical node may host many virtualized addressable
It is imperative that the addressing plans assigned to these virtual devices. It is imperative that the addressing plans assigned to
networks and devices be consistent and non-overlapping with the these virtual networks and devices be consistent and non-overlapping
addresses assigned to real networks and nodes. For example, a with the addresses assigned to real networks and nodes. For example,
virtual network established within an isolated lab environment may at a virtual network established within an isolated lab environment may,
a later time become attached to the production enterprise network. at a later time, become attached to the production enterprise
network.
2.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 that 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. The systems will need to be assessed for compatibility with IPv6. The
compatibility may be related to the addressing and connectivity of compatibility may be related to the addressing and connectivity of
various devices as well as IPv6 awareness of the tools and processing various devices as well as IPv6 awareness of the 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 that focus on managing the network and those that are focused
focused on managing systems and applications on the network. In on managing systems and applications on the network. In either
either instance, the tools will run on platforms which may or may not instance, the tools will run on platforms that may or may not be
be capable of operating in an IPv6 network. This lack in capable of operating in an IPv6 network. This lack in functionality
functionality may be related to Operating System version, or based on may be related to operating system version or based on some hardware
some hardware constraint. Those systems which are found to be constraint. Those systems that are found to be incapable of
incapable of utilizing an IPv6 connection, or which are dependent on utilizing an IPv6 connection, or which are dependent on an IPv4
an IPv4 stack, may need to be replaced or upgraded. 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
transition tunnel, many tools and support systems may require transition tunnel, many tools and support systems may require
additional software updates to be IPv6 aware, or even a hardware additional software updates to be IPv6 aware or even a hardware
upgrade (usually for additional memory: IPv6 addresses are larger and upgrade (usually for additional memory, IPv6 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 than include the fact that IPv6 addresses are significantly larger than
IPv4, requiring data stores to support the increased size. Such IPv4, requiring data stores to support the increased size. Such
issues are among those discussed in [RFC5952]. Many organizations issues are among those discussed in [RFC5952]. Many organizations
may also run dual-stack networks, therefore the tools need to not may also run dual-stack networks; therefore, the tools need to not
only support IPv6 operation, but may also need to support the only support IPv6 operation but may also need to support the
monitoring, management and intersection with both IPv6 and IPv4 monitoring, management, and intersection with both IPv6 and IPv4
simultaneously. It is important to note that managing IPv6 is not simultaneously. It is important to note that managing IPv6 is not
just constrained to using large IPv6 addresses, but also that IPv6 just constrained to using large IPv6 addresses, but also that IPv6
interfaces and nodes are likely to use two or more addresses as part interfaces and nodes are likely to use two or more addresses as part
of normal operation. Updating management systems to deal with these of normal operation. Updating management systems to deal with these
additional nuances will likely consume time and considerable effort. additional nuances will likely consume time and considerable effort.
For networking 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.
Operations 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 that changes to older IPv4-only SNMP Organizations should be aware that changes to older IPv4-only SNMP
MIB specifications have been made by the IETF related to legacy MIB specifications have been made by the IETF and are related to
operation in [RFC2096] and [RFC2011]. Updated specifications are now legacy operation in [RFC2096] and [RFC2011]. Updated specifications
available in [RFC4292] and [RFC4293] which modified the older MIB are now available in [RFC4292] and [RFC4293] that modified the older
framework to be IP protocol agnostic, supporting both IPv4 and IPv6. MIB framework to be IP protocol agnostic, supporting both IPv4 and
Polling systems will need to be upgraded to support these updates as IPv6. Polling systems will need to be upgraded to support these
well as the end stations which are polled. updates as well as the end stations, which are polled.
3. External Phase 3. External Phase
The external phase for enterprise IPv6 adoption covers topics which The External Phase for enterprise IPv6 adoption covers topics that
deal with how an organization connects its 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 large, or to other networks. The external phase covers Internet at large or to other networks. The External Phase covers
connectivity, security and monitoring of various elements and outward connectivity, security and monitoring of various elements, and
facing or accessible services. outward-facing or accessible services.
3.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]. One significant factor that will guide how an and [RFC4659]. One significant factor that will guide how an
organization may need to communicate with the outside world will organization may need to communicate with the outside world will
involve the use of PI (Provider Independent) and/or PA (Provider involve the use of PI and/or PA IPv6 space.
Aggregatable) IPv6 space.
Enterprises should be aware that depending on which address type they Enterprises should be aware that, depending on which address type
selected (PI vs. PA) in their planning phase, they may need to they selected (PI vs. PA) in their planning phase, they may need to
implement new routing functions and/or behaviours to support their implement new routing functions and/or behaviors to support their
connectivity to the ISP. In the case of PI, the upstream ISP may connectivity to the ISP. In the case of PI, the upstream ISP may
offer options to route the prefix (typically a /48) on the offer options to route the prefix (typically a /48) on the
enterprise's behalf and update the relevant routing databases. enterprise's behalf and update the relevant routing databases.
Otherwise, the enterprise may need to perform this task on their own Otherwise, the enterprise may need to perform this task on their own
and use BGP to inject the prefix into the global BGP system. and use BGP to inject the prefix into the global BGP system.
Note that the rules set by the RIRs for an enterprise acquiring PI Note that the rules set by the RIRs for an enterprise acquiring PI
address space have changed over time. For example, in the European address space have changed over time. For example, in the European
region the RIPE-NCC no longer requires an enterprise to be multihomed region, the RIPE-NCC no longer requires an enterprise to be
to be eligible for an IPv6 PI allocation. Requests can be made multihomed to be eligible for an IPv6 PI allocation. Requests can be
directly or via a LIR. It is possible that the rules may change made directly or via a LIR. It is possible that the rules may change
again, and may vary between RIRs. again and may vary between RIRs.
When seeking IPv6 connectivity to a Service Provider, Native IPv6 When seeking IPv6 connectivity to a service provider, native IPv6
connectivity is preferred since it provides the most robust and connectivity is preferred since it provides the most robust and
efficient form of connectivity. If native IPv6 connectivity is not efficient form of connectivity. If native IPv6 connectivity is not
possible due to technical or business limitations, the enterprise may possible due to technical or business limitations, the enterprise may
utilize readily available transition tunnel IPv6 connectivity. There utilize readily available transition tunnel IPv6 connectivity. There
are IPv6 transit providers which provide robust tunnelled IPv6 are IPv6 transit providers that provide robust tunneled IPv6
connectivity which can operate over IPv4 networks. It is important connectivity that can operate over IPv4 networks. It is important to
to understand the transition tunnel mechanism used, and to consider understand the transition-tunnel mechanism used and to consider that
that it will have higher latency than native IPv4 or IPv6, and may it will have higher latency than native IPv4 or IPv6, and may have
have other problems, e.g. related to MTUs. other problems, e.g., related to MTUs.
It is important to evaluate MTU considerations when adding IPv6 to an It is important to evaluate MTU considerations when adding IPv6 to an
existing IPv4 network. It is generally desirable to have the IPv6 existing IPv4 network. It is generally desirable to have the IPv6
and IPv4 MTU congruent to simplify operations (so the two address and IPv4 MTU congruent to simplify operations (so the two address
families behave similarly, that is, as expected). If the enterprise families behave similarly, that is, as expected). If the enterprise
uses transition tunnels inside or externally for IPv6 connectivity, uses transition tunnels inside or externally for IPv6 connectivity,
then modification of the MTU on hosts/routers may be needed as mid- then modification of the MTU on hosts/routers may be needed as mid-
stream fragmentation is no longer supported in IPv6. It is preferred stream fragmentation is no longer supported in IPv6. It is preferred
that pMTUD is used to optimize the MTU, so erroneous filtering of the that Path MTU Discovery (pMTUD) be used to optimize the MTU, so
related ICMPv6 message types should be monitored. Adjusting the MTU erroneous filtering of the related ICMPv6 message types should be
may be the only option if undesirable upstream ICMPv6 filtering monitored. Adjusting the MTU may be the only option if undesirable
cannot be removed. upstream ICMPv6 filtering cannot be removed.
3.2. Security 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 ACLs or filtering and monitoring. Filtering can be done by stateless ACLs or
a stateful firewall. The security policies must be consistent for a stateful firewall. The security policies must be consistent for
IPv4 and IPv6 (else the attacker will use the less protected protocol IPv4 and IPv6 (or else the attacker will use the less-protected
stack), except that certain ICMPv6 messages must be allowed through protocol stack), except that certain ICMPv6 messages must be allowed
and to the filtering device (see [RFC4890]): through and to the filtering device (see [RFC4890]):
o Packet Too Big: essential to allow Path MTU discovery to work o Packet Too Big: essential to allow Path MTU discovery to work
o Parameter Problem o Parameter Problem
o Time Exceeded o Time Exceeded
In addition, Neighbor Discovery Protocol messages (including Neighbor In addition, NDP messages (including Neighbor Solicitation, RAs,
Solicitation, Router Advertisements, etc.) are required for local etc.) are required for local hosts.
hosts.
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 attacks 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.
Ingress filters and firewalls should follow [RFC5095] in handling Ingress filters and firewalls should follow [RFC5095] in handling
routing extension header type 0, dropping the packet and sending routing extension header type 0, dropping the packet and sending
ICMPv6 Parameter Problem, unless Segments Left = 0 (in which case, ICMPv6 Parameter Problem, unless Segments Left = 0 (in which case,
ignore the header). ignore the header).
If an Intrusion Prevention System (IPS) is used for IPv4 traffic, If an IPS is used for IPv4 traffic, then an IPS should also be used
then an IPS should also be used for IPv6 traffic. In general, make for IPv6 traffic. In general, make sure IPv6 security is at least as
sure IPv6 security is at least as good as IPv4. This also includes good as IPv4. This also includes all email content protection (anti-
all email content protection (anti-spam, content filtering, data spam, content filtering, data leakage prevention, etc.).
leakage prevention, etc.).
The edge router must also implement anti-spoofing techniques based on The edge router must also implement anti-spoofing techniques based on
[RFC2827] (also known as BCP 38). [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 potential NDP cache exhaustion attack (see [RFC6583]) can be The potential NDP cache exhaustion attack (see [RFC6583]) 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 Or, as the external deployment usually involves just a couple of o Or, as the external deployment usually involves just a couple of
exposed statically configured IPv6 addresses (virtual addresses of exposed statically configured IPv6 addresses (virtual addresses of
web, email, and DNS servers), then it is straightforward to build web, email, and DNS servers), then it is straightforward to build
an ingress ACL allowing traffic for those addresses and denying an ingress ACL allowing traffic for those addresses and denying
traffic to any other addresses. This actually prevents the attack traffic to any other addresses. This actually prevents the attack
as a packet for a random destination will be dropped and will as a packet for a random destination will be dropped and will
never trigger a neighbor resolution. never trigger a neighbor resolution.
3.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 as it is done for IPv4. This includes the use of IP Flow IPv6 as it is done for IPv4. This includes the use of IPFIX
Information eXport (IPFIX) [RFC7012] to report abnormal traffic [RFC7012] to report abnormal traffic patterns (such as port scanning,
patterns (such as port scanning, SYN-flooding, related IP source SYN flooding, and related IP source addresses) from monitoring tools
addresses) from monitoring tools and evaluating data read from SNMP and evaluating data read from SNMP MIBs [RFC4293] (some of which also
MIBs [RFC4293] (some of which also enable the detection of abnormal enable the detection of abnormal bandwidth utilization) and syslogs
bandwidth utilization) and syslogs (finding server and system (finding server and system errors). Where NetFlow is used, Version 9
errors). Where Netflow is used, version 9 is required for IPv6 is required for IPv6 support. Monitoring systems should be able to
support. Monitoring systems should be able to examine IPv6 traffic, examine IPv6 traffic, use IPv6 for connectivity, and record IPv6
use IPv6 for connectivity, record IPv6 address, and any log parsing addresses, and any log parsing tools and reporting need to support
tools and reporting need to support IPv6. Some of this data can be IPv6. Some of this data can be sensitive (including personally
sensitive (including personally identifiable information) and care in identifiable information) and care in securing it should be taken,
securing it should be taken, with periodic purges. Integrity with periodic purges. Integrity protection on logs and sources of
protection on logs and sources of log data is also important to log data is also important to detect unusual behavior
detect unusual behavior (misconfigurations or attacks). Logs may be (misconfigurations or attacks). Logs may be used in investigations,
used in investigations, which depend on trustworthy data sources which depend on trustworthy data sources (tamper resistant).
(tamper resistant).
In addition, monitoring of external services (such as web sites) In addition, monitoring of external services (such as web sites)
should be made address-specific, so that people are notified when should be made address specific, so that people are notified when
either the IPv4 or IPv6 version of a site fails. either the IPv4 or IPv6 version of a site fails.
3.4. Servers and Applications 3.4. Servers and Applications
The path to the servers accessed from the Internet usually involves The path to the servers accessed from the Internet usually involves
security devices (firewall, IPS), server load balancing (SLB) and security devices (firewall and IPS), server load balancing (SLB), and
real physical servers. The latter stage is also multi-tiered for real physical servers. The latter stage is also multi-tiered for
scalability and security between presentation and data storage. The scalability and security between presentation and data storage. The
ideal transition is to enable native dual-stack on all devices; but ideal transition is to enable native dual stack on all devices; but
as part of the phased approach, operators have used the following as part of the phased approach, operators have used the following
techniques with success: techniques with success:
o Use a network device to apply NAT64 and basically translate an o Use a network device to apply NAT64 and basically translate an
inbound TCP connection (or any other transport protocol) over IPv6 inbound TCP connection (or any other transport protocol) over IPv6
into a TCP connection over IPv4. This is the easiest to deploy as 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 the path is mostly unchanged, but it hides all IPv6 remote users
behind a single IPv4 address which leads to several audit trail behind a single IPv4 address, which leads to several audit trail
and security issues (see [RFC6302]). and security issues (see [RFC6302]).
o Use the server load balancer which acts as an application proxy to o Use the server load balancer, which acts as an application proxy
do this translation. Compared to the NAT64, it has the potential to do this translation. Compared to the NAT64, it has the
benefit of going through the security devices as native IPv6 (so potential benefit of going through the security devices as native
more audit and trace abilities) and is also able to insert a HTTP IPv6 (so more audit and trace abilities) and is also able to
X-Forward-For header which contains the remote IPv6 address. The insert an HTTP X-Forward-For header that contains the remote IPv6
latter feature allows for logging, and rate-limiting on the real address. The latter feature allows for logging and rate limiting
servers based on the IPV6 address even if those servers run only on the real servers based on the IPV6 address even if those
IPv4. servers run only IPv4.
In either of these cases, care should be taken to secure logs for In either of these cases, care should be taken to secure logs for
privacy reasons, and to periodically purge them. privacy reasons and to periodically purge them.
3.5. Network Prefix Translation for IPv6 3.5. Network Prefix Translation for IPv6
Network Prefix Translation for IPv6, or NPTv6 as described in Network Prefix Translation for IPv6, or NPTv6 as described in
[RFC6296] provides a framework to utilize prefix ranges within the [RFC6296], provides a framework to utilize prefix ranges within the
internal network which are separate (address-independent) from the internal network that are separate (address independent) from the
assigned prefix from the upstream provider or registry. As mentioned assigned prefix from the upstream provider or registry. As mentioned
above, while NPTv6 has potential use-cases in IPv6 networks, the above, while NPTv6 has potential use cases in IPv6 networks, the
implications of its deployment need to be fully understood, implications of its deployment need to be fully understood,
particularly where any applications might embed IPv6 addresses in particularly where any applications might embed IPv6 addresses in
their payloads. their payloads.
Use of NPTv6 can be chosen independently from how addresses are Use of NPTv6 can be chosen independently from how addresses are
assigned and routed within the internal network, how prefixes are assigned and routed within the internal network, how prefixes are
routed towards the Internet, or whether PA or PI addresses are used. routed towards the Internet, or whether PA or PI addresses are used.
4. Internal Phase 4. Internal Phase
This phase deals with the delivery of IPv6 to the internal user- This phase deals with the delivery of IPv6 to the internal user-
facing side of the IT infrastructure, which comprises various facing side of the Information Technology (IT) infrastructure, which
components such as network devices (routers, switches, etc.), end comprises various components such as network devices (routers,
user devices and peripherals (workstations, printers, etc.), and switches, etc.), end-user devices and peripherals (workstations,
internal corporate systems. printers, etc.), and 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 a stack when you can, tunnel when you must". Dual stacking allows a
more robust, production-quality IPv6 network than is typically more robust, production-quality IPv6 network than is typically
facilitated by internal use of transition tunnels that are harder to facilitated by internal use of transition tunnels that are harder to
troubleshoot and support, and that may introduce scalability and troubleshoot and support, and that may introduce scalability and
performance issues. Tunnels may of course still be used in performance issues. Of course, tunnels may still be used in
production networks, but their use needs to be carefully considered, production networks, but their use needs to be carefully considered,
e.g. where the transition tunnel may be run through a security or e.g., where the transition tunnel may be run through a security or
filtering device. Tunnels do also provide a means to experiment with filtering device. Tunnels do also provide a means to experiment with
IPv6 and gain some operational experience with the protocol. IPv6 and gain some operational experience with the protocol.
[RFC4213] describes various transition mechanisms in more detail. [RFC4213] describes various transition mechanisms in more detail.
[RFC6964] suggests operational guidance when using ISATAP tunnels [RFC6964] suggests operational guidance when using Intra-Site
[RFC5214], though we would recommend use of dual-stack wherever Automatic Tunnel Addressing Protocol (ISATAP) tunnels [RFC5214],
possible. though we would recommend use of dual stack wherever possible.
4.1. Security 4.1. Security
IPv6 must be deployed in a secure way. This means that all existing IPv6 must be deployed in a secure way. This means that all existing
IPv4 security policies must be extended to support IPv6; IPv6 IPv4 security policies must be extended to support IPv6; IPv6
security policies will be the IPv6 equivalent of the existing IPv4 security policies will be the IPv6 equivalent of the existing IPv4
ones (taking into account the difference for ICMPv6 [RFC4890]). As ones (taking into account the difference for ICMPv6 [RFC4890]). As
in IPv4, security policies for IPv6 will be enforced by firewalls, in IPv4, security policies for IPv6 will be enforced by firewalls,
ACL, IPS, VPN, and so on. ACL, IPS, VPN, and so on.
Privacy extension addresses [RFC4941] raise a challenge for an audit Privacy extension addresses [RFC4941] raise a challenge for an audit
trail as explained in section Section 2.4.3. The enterprise may trail as explained in Section 2.4.3 of this document. The enterprise
choose to attempt to enforce use of DHCPv6, or deploy monitoring may choose to attempt to enforce use of DHCPv6 or deploy monitoring
tools that harvest accountability data from switches and routers tools that harvest accountability data from switches and routers
(thus making the assumption that devices may use any addresses inside (thus making the assumption that devices may use any addresses inside
the network). the network).
One major issue is threats against Neighbor Discovery. This means, One major issue is threats against ND. This means, for example, that
for example, that the internal network at the access layer (where the internal network at the access layer (where hosts connect to the
hosts connect to the network over wired or wireless) should implement network over wired or wireless) should implement RA-Guard [RFC6105]
RA-guard [RFC6105] and the techniques being specified by SAVI WG and the techniques being specified by the SAVI WG [RFC6959]; see also
[RFC6959]; see also Section 2.4.3 for more information. Section 2.4.3 of this document for more information.
4.2. Network Infrastructure 4.2. Network Infrastructure
The typical enterprise network infrastructure comprises a combination The typical enterprise network infrastructure comprises a combination
of the following network elements - wired access switches, wireless of the following network elements -- wired access switches, wireless
access points, and routers (although it is fairly common to find access points, and routers (although it is fairly common to find
hardware that collapses switching and routing functionality into a hardware that collapses switching and routing functionality into a
single device). Basic wired access switches and access points single device). Basic wired access switches and access points
operate only at the physical and link layers, and don't really have operate only at the physical and link layers and don't really have
any special IPv6 considerations other than being able to support IPv6 any special IPv6 considerations other than being able to support IPv6
addresses themselves for management purposes. In many instances, addresses themselves for management purposes. In many instances,
these devices possess a lot more intelligence than simply switching these devices possess a lot more intelligence than simply switching
packets. For example, some of these devices help assist with link packets. For example, some of these devices help assist with link-
layer security by incorporating features such as ARP inspection and layer security by incorporating features such as ARP inspection and
DHCP Snooping, or they may help limit where multicast floods by using DHCP snooping, or they may help limit where multicast floods by using
IGMP (or, in the case of IPv6, MLD) snooping. IGMP (or, in the case of IPv6, Multicast Listener Discovery (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 ND [RFC4861] provides a node with
[RFC4861], provides a node with the capability to maintain a list of the capability to maintain a list of available routers on the link,
available routers on the link, in order to be able to switch to a in order to be able to switch to a backup path should the primary be
backup path should the primary be unreachable. By default, ND will unreachable. By default, ND will detect a router failure in 38
detect a router failure in 38 seconds and cycle onto the next default seconds and cycle onto the next default router listed in its cache.
router listed in its cache. While this feature provides a basic While this feature provides a basic level of first-hop router
level of first hop router redundancy, most enterprise IPv4 networks redundancy, most enterprise IPv4 networks are designed to fail over
are designed to fail over much faster. Although this delay can be much faster. Although this delay can be improved by adjusting the
improved by adjusting the default timers, care must be taken to default timers, care must be taken to protect against transient
protect against transient failures and to account for increased failures and to account for increased traffic on the link. Another
traffic on the link. Another option to provide robust first hop option in which to provide robust first-hop redundancy is to use the
redundancy is to use the Virtual Router Redundancy Protocol for IPv6 Virtual Router Redundancy Protocol Version 3 (VRRPv3) for IPv6
(VRRPv3), [RFC5798]. This protocol provides a much faster switchover [RFC5798]. This protocol provides a much faster switchover to an
to an alternate default router than default ND parameters. Using alternate default router than default ND parameters. Using VRRPv3, a
VRRPv3, a backup router can take over for a failed default router in backup router can take over for a failed default router in around
around three seconds (using VRRPv3 default parameters). This is done 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 least, one of the most important design choices to make
make while deploying IPv6 on the internal network is whether to use while deploying IPv6 on the internal network is whether to use SLAAC
Stateless Automatic Address Configuration (SLAAC), [RFC4862], or [RFC4862], the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Dynamic Host Configuration Protocol for IPv6 (DHCPv6), [RFC3315], or [RFC3315], or a combination thereof. Each option has advantages and
a combination thereof. Each option has advantages and disadvantages, disadvantages, and the choice will ultimately depend on the
and the choice will ultimately depend on the operational policies operational policies that guide each enterprise's network design.
that guide each enterprise's network design. For example, if an For example, if an enterprise is looking for ease of use, rapid
enterprise is looking for ease of use, rapid deployment, and less deployment, and less administrative overhead, then SLAAC makes more
administrative overhead, then SLAAC makes more sense for sense for workstations. Manual or DHCPv6 assignments are still
workstations. Manual or DHCPv6 assignments are still needed for needed for servers, as described in the Address Plan and External
servers, as described in the External Phase and Address Plan sections Phase sections of this document; see Sections 2.6 and 3,
of this document. However, if the operational policies call for respectively. However, if the operational policies call for precise
precise control over IP address assignment for auditing then DHCPv6 control over IP address assignment for auditing, then DHCPv6 may be
may be preferred. DHCPv6 also allows you to tie into DNS systems for preferred. DHCPv6 also allows you to tie into DNS systems for host
host entry updates and gives you the ability to send other options entry updates and gives you the ability to send other options and
and information to clients. It is worth noting that in general information to clients. It is worth noting that in general
operation RAs are still needed in DHCPv6 networks, as there is no operation, RAs are still needed in DHCPv6 networks, as there is no
DHCPv6 Default Gateway option. Similarly, DHCPv6 is needed in RA DHCPv6 Default Gateway option. Similarly, DHCPv6 is needed in RA
networks for other configuration information, e.g. NTP servers or, networks for other configuration information, e.g., NTP servers or,
in the absence of support for DNS resolvers in RAs [RFC6106], DNS in the absence of support for DNS resolvers in RAs [RFC6106], DNS
resolver information. resolver information.
4.3. End user devices 4.3. End-User Devices
Most operating systems (OSes) 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 by default, some may only have certain features such as turned off by default, some may only have certain features such as
privacy extensions to IPv6 addresses (RFC 4941) turned off while privacy extensions to IPv6 addresses (RFC 4941) turned off, while
others have IPv6 fully enabled. Further, even when IPv6 is enabled, others have IPv6 fully enabled. Further, even when IPv6 is enabled,
the choice of which address is used may be subject to Source Address the choice of which address is used may be subject to source address
Selection (RFC 6724) and Happy Eyeballs (RFC 6555). Therefore, it is selection (RFC 6724) and Happy Eyeballs (RFC 6555). Therefore, it is
advised that enterprises investigate the default behavior of their advised that enterprises investigate the default behavior of their
installed OS base and account for it during the Inventory phases of installed OS base and account for it during the Inventory Phases of
their IPv6 preparations. Furthermore, some OSes may have some their IPv6 preparations. Furthermore, some OSes may have some
transition tunneling mechanisms turned on by default and in such transition tunneling mechanisms turned on by default, and in such
cases it is recommended to administratively shut down such interfaces cases, it is recommended to administratively shut down such
unless required. interfaces unless required.
It is important to note that it is recommended that IPv6 be deployed It is important to note that it is recommended that IPv6 be deployed
at the network and system infrastructure level before it is rolled at the network and system infrastructure level before it is rolled
out to end user devices; ensure IPv6 is running and routed on the out to end-user devices; ensure IPv6 is running and routed on the
wire, and secure and correctly monitored, before exposing IPv6 to end wire, and secure and correctly monitored, before exposing IPv6 to end
users. users.
Smartphones and tablets are significant IPv6-capable platforms, Smartphones and tablets are significant IPv6-capable platforms,
depending on the support of the carrier's data network. depending on the support of the carrier's data network.
IPv6 support for peripherals varies. Much like servers, printers are IPv6 support for peripherals varies. Much like servers, printers are
generally configured with a static address (or DHCP reservation) so generally configured with a static address (or DHCP reservation) so
clients can discover them reliably. clients can discover them reliably.
skipping to change at page 23, line 34 skipping to change at page 24, line 35
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 to enterprise deployment, since most end hosts decide whether or not to
use IPv6 depending on the presence of IPv6 AAAA records in a reply to use IPv6 depending on the presence of IPv6 AAAA records in a reply to
a DNS query. It is recommended that system administrators a DNS query. It is recommended that system administrators
selectively turn on AAAA records for various systems as and when they selectively turn on AAAA records for various systems as and when they
are IPv6 enabled; care must be taken though to ensure all services are IPv6 enabled; care must be taken though to ensure all services
running on that host name are IPv6-enabled before adding the AAAA running on that host name are IPv6 enabled before adding the AAAA
record. Care with web proxies is advised; a mismatch in the level of record. Care with web proxies is advised; a mismatch in the level of
IPv6 support between the client, proxy, and server can cause IPv6 support between the client, proxy, and server can cause
communication problems. All monitoring and reporting tools across communication problems. All monitoring and reporting tools across
the enterprise will need to be modified to support IPv6. the enterprise will need to be modified to support IPv6.
5. IPv6-only 5. IPv6 Only
Early IPv6 enterprise deployments have generally taken a dual-stack Early IPv6 enterprise deployments have generally taken a dual-stack
approach to enabling IPv6, i.e. the existing IPv4 services have not approach to enabling IPv6, i.e., the existing IPv4 services have not
been turned off. Although IPv4 and IPv6 networks will coexist for a been turned off. Although IPv4 and IPv6 networks will coexist for a
long time, the long term enterprise network roadmap should include long time, the long-term enterprise network roadmap should include
steps to simplify engineering and operations by deprecating IPv4 from steps to simplify engineering and operations by deprecating IPv4 from
the dual-stack network. In some extreme cases, deploying dual-stack the dual-stack network. In some extreme cases, deploying dual-stack
networks may not even be a viable option for very large enterprises networks may not even be a viable option for very large enterprises
due to the RFC 1918 address space not being large enough to support due to the address space described in RFC 1918 not being large enough
the network's growth. In such cases, deploying IPv6-only networks to support the network's growth. In such cases, deploying IPv6-only
might be the only choice available to sustain network growth. In networks might be the only choice available to sustain network
other cases, there may be elements of an otherwise dual-stack network growth. In other cases, there may be elements of an otherwise dual-
that may be run IPv6-only. stack network that may be run in 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 be straightforward. However, deploying IPv6-only networks should be straightforward. However,
most nodes will need to communicate with some IPv4-only nodes; an most nodes will need to communicate with some IPv4-only nodes; an
IPv6-only node may therefore require a translation mechanism. As IPv6-only node may, therefore, require a translation mechanism. As
[RFC6144] points out, it is important to look at address translation [RFC6144] points out, it is important to look at address translation
as a transition strategy towards running an IPv6-only network. as a 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 IPv6 to IPv4 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-translatable addresses) that can be algorithmically mapped to a (IPv4-translatable addresses) that can be algorithmically mapped to a
subset of the service provider's IPv4 addresses. [RFC6146], NAT64, subset of the service provider's IPv4 addresses. NAT64 [RFC6146]
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. DNS64 [RFC6147] describes a mechanism for synthesizing
synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs AAAA resource records (RRs) from A RRs. Together, RFCs 6146 and RFC
6146 and RFC 6147 provide a viable method for an IPv6-only client to 6147 provide a viable method for an IPv6-only client to initiate
initiate communications to an IPv4-only server. As described in the communications to an IPv4-only server. As described in Enterprise
assumptions section, the administrator will usually want most traffic Assumptions, Section 1.1, the administrator will usually want most
or flows to be native, and only translate as needed. traffic or flows to be native and only translate as needed.
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 classic problems of IPv4 NAT also apply, e.g. handling IP The classic problems of IPv4 NAT also apply, e.g., handling IP
literals in application payloads. The ultimate choice of which literals in application payloads. The ultimate choice of which
translation mechanism to chose will be dictated mostly by existing translation mechanism to chose will be dictated mostly by existing
operational policies pertaining to application support, logging operational policies pertaining to application support, logging
requirements, etc. 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, [DIVI] describes limitations with the current stateless
stateless translation, such as IPv4 address sharing and application translation, such as IPv4 address sharing and application layer
layer gateway (ALG) problems, and presents the concept and gateway (ALG) problems, and presents the concept and implementation
implementation of dual-stateless IPv4/IPv6 translation (dIVI) to of dual-stateless IPv4/IPv6 translation (dIVI) to address those
address those issues. issues.
It is worth noting that for IPv6-only access networks that use It is worth noting that for IPv6-only access networks that use
technologies such as NAT64, the more content providers (and technologies such as NAT64, the more content providers (and
enterprises) that make their content available over IPv6, the less enterprises) that make their content available over IPv6, the less
the requirement to apply NAT64 to traffic leaving the access network. the requirement to apply NAT64 to traffic leaving the access network.
This particular point is important for enterprises which may start This particular point is important for enterprises that may start
their IPv6 deployment well into the global IPv6 transition. As time their IPv6 deployment well into the global IPv6 transition. As time
progresses, and given the current growth in availability of IPv6 progresses, and given the current growth in availability of IPv6
content, IPv6-only operation using NAT64 to manage some flows will content, IPv6-only operation using NAT64 to manage some flows will
become less expensive to run versus the traditional NAT44 deployments become less expensive to run versus the traditional NAT44 deployments
since only IPv6 to IPv4 flows need translation. [RFC6883] provides since only IPv6-to-IPv4 flows need translation. [RFC6883] provides
guidance and suggestions for Internet Content Providers and guidance and suggestions for Internet Content Providers and
Application Service Providers in this context. Application Service Providers in this context.
Enterprises should also be aware that networks may be subject to Enterprises should also be aware that networks may be subject to
future convergence with other networks (i.e. mergers, acquisitions, future convergence with other networks (i.e., mergers, acquisitions,
etc). An enterprise considering IPv6-only operation may need to be etc.). An enterprise considering IPv6-only operation may need to be
aware that additional transition technologies and/or connectivity aware that additional transition technologies and/or connectivity
strategies may be required depending on the level of IPv6 readiness strategies may be required depending on the level of IPv6 readiness
and deployment in the merging networking. and deployment in the merging networking.
6. Considerations For Specific Enterprises 6. Considerations for Specific Enterprises
6.1. Content Delivery Networks 6.1. Content Delivery Networks
Some guidance for Internet Content and Application Service Providers Some guidance for Internet Content and Application Service Providers
can be found in [RFC6883], which includes a dedicated section on can be found in [RFC6883], which includes a dedicated section on
Content Delivery Networks (CDNs). An enterprise that relies on a CDN Content Delivery Networks (CDNs). An enterprise that relies on a CDN
to deliver a 'better' e-commerce experience needs to ensure that to deliver a 'better' e-commerce experience needs to ensure that
their CDN provider also supports IPv4/IPv6 traffic selection so that their CDN provider also supports IPv4/IPv6 traffic selection so that
they can ensure 'best' access to the content. A CDN could enable they can ensure 'best' access to the content. A CDN could enable
external IPv6 content delivery even if the enterprise provides that external IPv6 content delivery even if the enterprise provides that
content over IPv4. content over IPv4.
6.2. Data Center Virtualization 6.2. Data Center Virtualization
IPv6 Data Center considerations are described in IPv6 Data Center considerations are described in [IPv6-DC].
[I-D.ietf-v6ops-dc-ipv6].
6.3. University Campus Networks 6.3. University Campus Networks
A number of campus networks around the world have made some initial A number of campus networks around the world have made some initial
IPv6 deployment. This has been encouraged by their National Research IPv6 deployments. This has been encouraged by their National
and Education Network (NREN) backbones having made IPv6 available Research and Education Network (NREN) backbones, having made IPv6
natively since the early 2000's. Universities are a natural place available natively since the early 2000's. Universities are a
for IPv6 deployment to be considered at an early stage, perhaps natural place for IPv6 deployment to be considered at an early stage,
compared to other enterprises, as they are involved by their very perhaps compared to other enterprises, as they are involved by their
nature in research and education. very nature in research and education.
Campus networks can deploy IPv6 at their own pace; there is no need Campus networks can deploy IPv6 at their own pace; there is no need
to deploy IPv6 across the entire enterprise from day one, rather to deploy IPv6 across the entire enterprise from day one. Rather,
specific projects can be identified for an initial deployment, that specific projects can be identified for an initial deployment that
are both deep enough to give the university experience, but small are both deep enough to give the university experience but small
enough to be a realistic first step. There are generally three areas enough to be a realistic first step. There are generally three areas
in which such deployments are currently made. in which such deployments are currently made.
In particular those initial areas commonly approached are: 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. This ensures commonly also external-facing DNS and mail exchange (MX) services.
early IPv6-only adopters elsewhere can access the campus services This ensures early IPv6-only adopters elsewhere can access the
as simply and as robustly as possible. 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, and where many of the and/or teaching is most likely to occur, and where many of the
next generation of network engineers are studying, so enabling next generation of network engineers are studying, so enabling
some or all of the campus computer science department network is a some or all of the campus computer science department network is a
sensible first step. sensible first step.
o The eduroam wireless network. Eduroam [I-D.wierenga-ietf-eduroam] o The eduroam wireless network. Eduroam [EDUROAM] is the de facto
is the de facto wireless roaming system for academic networks, and wireless roaming system for academic networks and uses
uses 802.1X-based authentication, which is agnostic to the IP authentication based on 802.1X, which is agnostic to the IP
version used (unlike web-redirection gateway systems). Making a version used (unlike web-redirection gateway systems). Making a
campus' eduroam network dual-stack is a very viable early step. campus' eduroam network dual stack is a very viable early step.
The general IPv6 deployment model in a campus enterprise will still The general IPv6 deployment model in a campus enterprise will still
follow the general principles described in this document. While the follow the general principles described in this document. While the
above early stage projects are commonly followed, these still require above early stage projects are commonly followed, these still require
the campus to acquire IPv6 connectivity and address space from their the campus to acquire IPv6 connectivity and address space from their
NREN (or other provider in some parts of the world), and to enable 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. 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 This implies a requirement to have an initial address plan, and to
ensure appropriate monitoring and security measures are in place, as ensure appropriate monitoring and security measures are in place, as
described elsewhere in this document. described elsewhere in this document.
Campuses which have deployed to date do not use ULAs, nor do they use Campuses that have deployed to date do not use ULAs, nor do they use
NPTv6. In general, campuses have very stable PA-based address NPTv6. In general, campuses have very stable PA-based address
allocations from their NRENs (or their equivalent). However, campus allocations from their NRENs (or their equivalent). However, campus
enterprises may consider applying for IPv6 PI; some have already done enterprises may consider applying for IPv6 PI; some have already done
so. The discussions earlier in this text about PA vs. PI still so. The discussions earlier in this text about PA vs. PI still
apply. apply.
Finally, campuses may be more likely than many other enterprises to Finally, campuses may be more likely than many other enterprises to
run multicast applications, such as IP TV or live lecture or seminar run multicast applications, such as IP TV or live lecture or seminar
streaming, so may wish to consider support for specific IPv6 streaming, so they may wish to consider support for specific IPv6
multicast functionality, e.g. Embedded-RP [RFC3956] in routers and multicast functionality, e.g., the Embedded Rendezvous Point
MLDv1 and MLDv2 snooping in switches. (Embedded-RP) [RFC3956] in routers and MLDv1 and MLDv2 snooping in
switches.
7. Security Considerations 7. Security Considerations
This document has multiple security sections detailing how to This document has multiple security sections detailing with how to
securely deploy an IPv6 network within an enterprise network. securely deploy an IPv6 network within an enterprise network.
8. Acknowledgements 8. Informative References
The authors would like to thank Robert Sparks, Steve Hanna, Tom [CYMRU] Team CYMRU Community Services, "THE BOGON REFERENCE",
Taylor, Brian Haberman, Stephen Farrell, Chris Grundemann, Ray Version 7, April 2012,
Hunter, Kathleen Moriarty, Benoit Claise, Brian Carpenter, Tina Tsou, <http://www.team-cymru.org/Services/Bogons/>.
Christian Jaquenet, and Fred Templin for their substantial comments
and contributions.
9. IANA Considerations [DHCPv6-SLAAC-PROBLEM]
Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration
Interaction Problem Statement", Work in Progress, draft-
liu-bonica-dhcpv6-slaac-problem-02, September 2013.
There are no IANA considerations or implications that arise from this [DIVI] Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-
document. Stateless IPv4/IPv6 Translation", Work in Progress, draft-
xli-behave-divi-06, January 2014.
10. Informative References [EDUROAM] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
architecture for network roaming", Work in Progress,
draft-wierenga-ietf-eduroam-04, August 2014.
[HOST-SCANNING]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", Work in Progress, draft-ietf-opsec-ipv6-host-
scanning-04, June 2014.
[IPv6-DC] Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin,
"IPv6 Operational Guidelines for Datacenters", Work in
Progress, draft-ietf-v6ops-dc-ipv6-01, February 2014.
[IPv6-DESIGN]
Matthews, P. and V. Kuarsingh, "Design Choices for IPv6
Networks", Work in Progress, draft-ietf-v6ops-design-
choices-02, September 2014.
[IPv6-SECURITY]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", Work in
Progress, draft-ietf-opsec-v6-04, October 2013.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982,
<http://www.rfc-editor.org/info/rfc826>.
[RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng",
RFC 1687, August 1994. RFC 1687, August 1994,
<http://www.rfc-editor.org/info/rfc1687>.
[RFC1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, August [RFC1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, August
1995. 1995, <http://www.rfc-editor.org/info/rfc1817>.
[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", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for
the Internet Protocol using SMIv2", RFC 2011, November the Internet Protocol using SMIv2", RFC 2011, November
1996. 1996, <http://www.rfc-editor.org/info/rfc2011>.
[RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January [RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January
1997. 1997, <http://www.rfc-editor.org/info/rfc2096>.
[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,
<http://www.rfc-editor.org/info/rfc2827>.
[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,
<http://www.rfc-editor.org/info/rfc3315>.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", RFC Point (RP) Address in an IPv6 Multicast Address", RFC
3956, November 2004. 3956, November 2004,
<http://www.rfc-editor.org/info/rfc3956>.
[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,
<http://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition", RFC Castro, "Application Aspects of IPv6 Transition", RFC
4038, March 2005. 4038, March 2005,
<http://www.rfc-editor.org/info/rfc4038>.
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
June 2005. June 2005, <http://www.rfc-editor.org/info/rfc4057>.
[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,
<http://www.rfc-editor.org/info/rfc4193>.
[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,
<http://www.rfc-editor.org/info/rfc4213>.
[RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006.
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April
2006. 2006, <http://www.rfc-editor.org/info/rfc4292>.
[RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006,
<http://www.rfc-editor.org/info/rfc4293>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006,
<http://www.rfc-editor.org/info/rfc4364>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for "BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, September 2006. IPv6 VPN", RFC 4659, September 2006,
<http://www.rfc-editor.org/info/rfc4659>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, May 2007. ICMPv6 Messages in Firewalls", RFC 4890, May 2007,
<http://www.rfc-editor.org/info/rfc4890>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, December of Type 0 Routing Headers in IPv6", RFC 5095, December
2007. 2007, <http://www.rfc-editor.org/info/rfc5095>.
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow
Information Export (IPFIX)", RFC 7012, September 2013.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC
5157, March 2008. 5157, March 2008,
<http://www.rfc-editor.org/info/rfc5157>.
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July
2008. 2008, <http://www.rfc-editor.org/info/rfc5211>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008. March 2008, <http://www.rfc-editor.org/info/rfc5214>.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
and C. Hahn, "IPv6 Unicast Address Assignment and C. Hahn, "IPv6 Unicast Address Assignment
Considerations", RFC 5375, December 2008. Considerations", RFC 5375, December 2008,
<http://www.rfc-editor.org/info/rfc5375>.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009. RFC 5722, December 2009,
<http://www.rfc-editor.org/info/rfc5722>.
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798, March 2010. Version 3 for IPv4 and IPv6", RFC 5798, March 2010,
<http://www.rfc-editor.org/info/rfc5798>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[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,
<http://www.rfc-editor.org/info/rfc6104>.
[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, <http://www.rfc-editor.org/info/rfc6105>.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration", "IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010. RFC 6106, November 2010,
<http://www.rfc-editor.org/info/rfc6106>.
[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,
<http://www.rfc-editor.org/info/rfc6144>.
[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,
<http://www.rfc-editor.org/info/rfc6145>.
[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,
<http://www.rfc-editor.org/info/rfc6146>.
[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, <http://www.rfc-editor.org/info/rfc6147>.
[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,
<http://www.rfc-editor.org/info/rfc6164>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177, March 2011,
<http://www.rfc-editor.org/info/rfc6177>.
[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,
<http://www.rfc-editor.org/info/rfc6192>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011. Translation", RFC 6296, June 2011,
<http://www.rfc-editor.org/info/rfc6296>.
[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", BCP "Logging Recommendations for Internet-Facing Servers", BCP
162, RFC 6302, June 2011. 162, RFC 6302, June 2011,
<http://www.rfc-editor.org/info/rfc6302>.
[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,
<http://www.rfc-editor.org/info/rfc6434>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012,
<http://www.rfc-editor.org/info/rfc6555>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012. Neighbor Discovery Problems", RFC 6583, March 2012,
<http://www.rfc-editor.org/info/rfc6583>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>.
[RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for
Renumbering IPv6 Hosts with Static Addresses in Enterprise Renumbering IPv6 Hosts with Static Addresses in Enterprise
Networks", RFC 6866, February 2013. Networks", RFC 6866, February 2013,
<http://www.rfc-editor.org/info/rfc6866>.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and Network Renumbering Scenarios, Considerations, and
Methods", RFC 6879, February 2013. Methods", RFC 6879, February 2013,
<http://www.rfc-editor.org/info/rfc6879>.
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content Providers and Application Service Providers", RFC Content Providers and Application Service Providers", RFC
6883, March 2013. 6883, March 2013,
<http://www.rfc-editor.org/info/rfc6883>.
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address
Validation Improvement (SAVI) Threat Scope", RFC 6959, May Validation Improvement (SAVI) Threat Scope", RFC 6959, May
2013. 2013, <http://www.rfc-editor.org/info/rfc6959>.
[RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in
IPv4 Sites Using the Intra-Site Automatic Tunnel IPv4 Sites Using the Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)", RFC 6964, May 2013. Addressing Protocol (ISATAP)", RFC 6964, May 2013,
<http://www.rfc-editor.org/rfc/rfc6964.txt>.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
the IP Flow Information Export (IPFIX) Protocol for the the IP Flow Information Export (IPFIX) Protocol for the
Exchange of Flow Information", STD 77, RFC 7011, September Exchange of Flow Information", STD 77, RFC 7011, September
2013. 2013, <http://www.rfc-editor.org/info/rfc7011>.
[RFC7113] Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", RFC 7113, February 2014.
[RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow
IPv4 Networks", RFC 7123, February 2014. Information Export (IPFIX)", RFC 7012, September 2013,
<http://www.rfc-editor.org/info/rfc7012>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC7045 , December 2013, of IPv6 Extension Headers", RFC 7045, December 2013,
<http://tools.ietf.org/html/rfc7045>. <http://www.rfc-editor.org/info/rfc7045>.
[I-D.xli-behave-divi]
Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-
Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-06
(work in progress), January 2014.
[I-D.wierenga-ietf-eduroam]
Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
architecture for network roaming", draft-wierenga-ietf-
eduroam-03 (work in progress), February 2014.
[I-D.ietf-v6ops-dc-ipv6]
Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin,
"IPv6 Operational Guidelines for Datacenters", draft-ietf-
v6ops-dc-ipv6-01 (work in progress), February 2014.
[I-D.ietf-v6ops-design-choices] [RFC7113] Gont, F., "Implementation Advice for IPv6 Router
Matthews, P. and V. Kuarsingh, "Design Choices for IPv6 Advertisement Guard (RA-Guard)", RFC 7113, February 2014,
Networks", draft-ietf-v6ops-design-choices-01 (work in <http://www.rfc-editor.org/info/rfc7113>.
progress), March 2014.
[I-D.ietf-opsec-v6] [RFC7123] Gont, F. and W. Liu, "Security Implications of IPv6 on
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational IPv4 Networks", RFC 7123, February 2014,
Security Considerations for IPv6 Networks", draft-ietf- <http://www.rfc-editor.org/info/rfc7123>.
opsec-v6-04 (work in progress), October 2013.
[I-D.ietf-opsec-ipv6-host-scanning] [RFC7359] Gont, F., "Layer 3 Virtual Private Network (VPN) Tunnel
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Traffic Leakages in Dual-Stack Hosts/Networks", RFC 7359,
Networks", draft-ietf-opsec-ipv6-host-scanning-04 (work in August 2014, <http://www.rfc-editor.org/info/rfc7359>.
progress), June 2014.
[I-D.liu-bonica-dhcpv6-slaac-problem] [SMURF] The Cert Division of the Software Engineering Institute,
Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration "Smurf IP Denial-of-Service Attacks", CERT Advisory CA-
Interaction Problem Statement", draft-liu-bonica-dhcpv6- 1998-01, March 2000,
slaac-problem-02 (work in progress), September 2013. <http://www.cert.org/advisories/CA-1998-01.html>.
[I-D.ietf-v6ops-ula-usage-recommendations] [ULA-USAGE]
Liu, B. and S. Jiang, "Considerations of Using Unique Liu, B. and S. Jiang, "Considerations of Using Unique
Local Addresses", draft-ietf-v6ops-ula-usage- Local Addresses", Work in Progress, draft-ietf-v6ops-ula-
recommendations-03 (work in progress), July 2014. usage-recommendations-03, July 2014.
[I-D.ietf-opsec-vpn-leakages]
Gont, F., "Layer-3 Virtual Private Network (VPN) tunnel
traffic leakages in dual- stack hosts/networks", draft-
ietf-opsec-vpn-leakages-06 (work in progress), April 2014.
[SMURF] "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Acknowledgements
Attacks",
<http://www.cert.org/advisories/CA-1998-01.html>.
[CYMRU] "THE BOGON REFERENCE", The authors would like to thank Robert Sparks, Steve Hanna, Tom
<http://www.team-cymru.org/Services/Bogons/>. Taylor, Brian Haberman, Stephen Farrell, Chris Grundemann, Ray
Hunter, Kathleen Moriarty, Benoit Claise, Brian Carpenter, Tina Tsou,
Christian Jacquenet, and Fred Templin for their substantial comments
and contributions.
Authors' Addresses Authors' Addresses
Kiran K. Chittimaneni
Dropbox Inc.
1600 Amphitheater Pkwy
Mountain View, California CA 94043
USA
Email: kk@dropbox.com Kiran K. Chittimaneni
Dropbox, Inc.
185 Berry Street, Suite 400
San Francisco, CA 94107
United States
EMail: kk@dropbox.com
Tim Chown Tim Chown
University of Southampton University of Southampton
Highfield Highfield
Southampton, Hampshire SO17 1BJ Southampton, Hampshire SO17 1BJ
United Kingdom United Kingdom
EMail: tjc@ecs.soton.ac.uk
Email: tjc@ecs.soton.ac.uk
Lee Howard Lee Howard
Time Warner Cable Time Warner Cable
13820 Sunrise Valley Drive 13820 Sunrise Valley Drive
Herndon, VA 20171 Herndon, VA 20171
US United States
Phone: +1 703 345 3513 Phone: +1 703 345 3513
Email: lee.howard@twcable.com EMail: lee.howard@twcable.com
Victor Kuarsingh Victor Kuarsingh
Dyn Inc Dyn, Inc.
150 Dow Street 150 Dow Street
Manchester, NH Manchester, NH
US United States
EMail: victor@jvknet.com
Email: victor@jvknet.com
Yanick Pouffary Yanick Pouffary
Hewlett Packard Hewlett Packard
950 Route Des Colles 950 Route Des Colles
Sophia-Antipolis 06901 Sophia-Antipolis 06901
France France
EMail: Yanick.Pouffary@hp.com
Email: Yanick.Pouffary@hp.com
Eric Vyncke Eric Vyncke
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Phone: +32 2 778 4677 Phone: +32 2 778 4677
Email: evyncke@cisco.com EMail: evyncke@cisco.com
 End of changes. 240 change blocks. 
640 lines changed or deleted 673 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/