draft-ietf-v6ops-enterprise-incremental-ipv6-05.txt   draft-ietf-v6ops-enterprise-incremental-ipv6-06.txt 
Network Working Group K. Chittimaneni Network Working Group K. Chittimaneni
Internet-Draft Google Inc. Internet-Draft Dropbox Inc.
Intended status: Informational T. Chown Intended status: Informational T. Chown
Expires: July 16, 2014 University of Southampton Expires: February 1, 2015 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
January 12, 2014 July 31, 2014
Enterprise IPv6 Deployment Guidelines Enterprise IPv6 Deployment Guidelines
draft-ietf-v6ops-enterprise-incremental-ipv6-05 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 introducing IPv6 access within the enterprise IT network. The while introducing IPv6 access within the enterprise IT network. The
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 16, 2014. 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 4 1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 4
1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . 4 1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . 4
1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 5 1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 5
2. Preparation and Assessment Phase . . . . . . . . . . . . . . 6 2. Preparation and Assessment Phase . . . . . . . . . . . . . . 6
2.1. Program Planning . . . . . . . . . . . . . . . . . . . . 6 2.1. Program Planning . . . . . . . . . . . . . . . . . . . . 6
2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 8 2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Network infrastructure readiness assessment . . . . . 8 2.2.1. Network infrastructure readiness assessment . . . . . 7
2.2.2. Applications readiness assessment . . . . . . . . . . 8 2.2.2. Applications readiness assessment . . . . . . . . . . 8
2.2.3. Importance of readiness validation and testing . . . 9 2.2.3. Importance of readiness validation and testing . . . 8
2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 10 2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 9
2.4.1. IPv6 is no more secure than IPv4 . . . . . . . . . . 10 2.4.1. IPv6 is no more secure than IPv4 . . . . . . . . . . 9
2.4.2. Similarities between IPv6 and IPv4 security . . . . . 11 2.4.2. Similarities between IPv6 and IPv4 security . . . . . 10
2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 11 2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 10
2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 13 2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 13
2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 16 2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 15
3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 17 3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 19 3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Servers and Applications . . . . . . . . . . . . . . . . 20 3.4. Servers and Applications . . . . . . . . . . . . . . . . 19
3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 20 3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 20
4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 20 4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 21 4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 21
4.3. End user devices . . . . . . . . . . . . . . . . . . . . 23 4.3. End user devices . . . . . . . . . . . . . . . . . . . . 22
4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 24 4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Informative References . . . . . . . . . . . . . . . . . . . 28 10. Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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 department of
administrators). Administrators generally support an internal administrators). Administrators generally support an internal
network, consisting of users' workstations, personal computers, other network, consisting of users' workstations, personal computers,
computing devices and related peripherals, a server network, mobile devices, other computing devices and related peripherals, a
consisting of accounting and business application servers, and an server network, consisting of accounting and business application
external network, consisting of Internet-accessible services such as servers, and an external network, consisting of Internet-accessible
web servers, email servers, VPN systems, and customer applications. services such as web servers, email servers, VPN systems, and
This document is intended as guidance for network architects and customer applications. This document is intended as guidance for
administrators in planning their IPv6 deployments. enterprise network architects and administrators in planning their
IPv6 deployments.
The business reasons for spending time, effort, and money on IPv6 The business reasons for spending time, effort, and money on IPv6
will be unique to each enterprise. The most common drivers are due will be unique to each enterprise. The most common drivers are due
to the fact that when Internet service providers, including mobile to the fact that when Internet service providers, including mobile
wireless carriers, run out of IPv4 addresses, they will provide wireless carriers, run out of IPv4 addresses, they will provide
native IPv6 and non-native IPv4. The non-native IPv4 service may be native IPv6 and non-native IPv4. The non-native IPv4 service may be
NAT64, NAT444, Dual-stack Lite, or other transition technologies. NAT64, NAT444, Dual-stack Lite, MAP-T, MAP-E, or other transition
Compared to tunneled or translated, native traffic typically performs technologies. Compared to tunneled or translated service, native
better and more reliably than non-native. For example, for client traffic typically performs better and more reliably than non-native.
networks trying to reach enterprise networks, the IPv6 experience For example, for client networks trying to reach enterprise networks,
will be better than the transitional IPv4 if the enterprise deploys the IPv6 experience will be better than the transitional IPv4 if the
IPv6 in its public-facing services. The native IPv6 network path enterprise deploys IPv6 in its public- facing services. The native
should also be simpler to manage and, if necessary, troubleshoot. IPv6 network path should also be simpler to manage and, if necessary,
Further, enterprises doing business in growing parts of the world may troubleshoot. Further, enterprises doing business in growing parts
find IPv6 growing faster there, where again potential new customers, of the world may find IPv6 growing faster there, where again
employees and partners are using IPv6. It is thus in the potential new customers, employees and partners are using IPv6. It
enterprise's interests to deploy native IPv6, at the very least in is thus in the enterprise's interests to deploy native IPv6, at the
its public-facing services, but ultimately across the majority or all very least in its public-facing services, but ultimately across the
of its scope. 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]. [I-D.ietf-v6ops-design-choices] 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:
o The administrator is considering deploying IPv6 (but see o The administrator is considering deploying IPv6 (but see
Section 1.2 below). Section 1.2 below).
o The administrator has existing IPv4 networks and devices which o The administrator has existing IPv4 networks and devices which
will continue to operate and be supported. will continue to operate and be supported.
o The administrator will want to minimize the level of disruption to o The administrator will want to minimize the level of disruption to
the users and services by minimizing number of technologies and the users and services by minimizing number of technologies and
functions that are needed to mediate any given application. In functions that are needed to mediate any given application. In
other words, provide native IP wherever possible. other words: provide native IP wherever possible.
Based on these assumptions, an administrator will want to use Based on these assumptions, an administrator will want to use
technologies which minimize the number of flows being tunnelled, technologies which minimize the number of flows being tunnelled,
translated or intercepted at any given time. The administrator will translated or intercepted at any given time. The administrator will
choose transition technologies or strategies which allow most traffic choose transition technologies or strategies which allow most traffic
to be native, and will manage non-native traffic. This will allow to be native, and will 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.
skipping to change at page 4, line 41 skipping to change at page 4, line 45
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 multi-homing, 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 or of malefactors behind address-sharing technologies such as NAT444,
Dual-stack Lite. MAP, or Dual-stack Lite. Such logs should be protected for
integrity, safeguarded for privacy and periodically purged within
applicable 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 RA problem, which may cause
problems in IPv4-only networks where IPv6 is enabled in end systems problems in IPv4-only networks where IPv6 is enabled in end systems
on that network. Further discussion of the security implications of on that network. Further discussion of the security implications of
IPv6 in IPv4-only networks can be found in IPv6 in IPv4-only networks can be found in [RFC7123]).
[I-D.ietf-opsec-ipv6-implications-on-ipv4-nets]).
1.3. Reasons for a Phased Approach 1.3. Reasons for a Phased Approach
Given the challenges of 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. The Preparation Phase is highly determination of priorities. This document outlines suggested
recommended to all administrators, as it will save errors and phases: a Preparation and Assessment Phase, an Internal Phase, and an
complexity in later phases. Each administrator must decide whether External Phase. The Preparation Phase is highly recommended to all
to begin with the External Phase (as recommended in [RFC5211]) or the administrators, as it will save errors and complexity in later
Internal Phase. There is no "correct" answer here; the decision is phases. Each administrator must decide whether to begin with an
one for each enterprise to make. External Phase (enabling IPv6 for Internet-facing systems, as
recommended in [RFC5211]) or an Internal Phase (enabling IPv6 for
internal interconnections first).
Each scenario is likely to be different to some extent, but we can Each scenario is likely to be different to some extent, but we can
highlight some considerations: highlight some considerations:
o In many cases, customers outside the network will have IPv6 before o In many cases, customers outside the network will have IPv6 before
the internal enterprise network. For these customers, IPv6 may the internal enterprise network. For these customers, IPv6 may
well perform better, especially for certain applications, than well perform better, especially for certain applications, than
translated or tunneled IPv4, so the administrator may want to translated or tunneled IPv4, so the administrator may want to
prioritize the External Phase 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
skipping to change at page 5, line 37 skipping to change at page 5, line 41
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
[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 may enable a faster rollout once initial system
deployment is complete. Management of VMs over IPv6 is still deployment is complete. Management of VMs over IPv6 is still
dependent on the management software supporting IPv6. 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
[I-D.ietf-opsec-ipv6-implications-on-ipv4-nets]. [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
skipping to change at page 6, line 34 skipping to change at page 6, line 42
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 one "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 18 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
As with any project, an IPv6 deployment project will have its own Since enabling IPv6 is a change to the most fundamental Internet
phases. Generally, one person is identified as the project sponsor Protocol, and since there are so many interdependencies, having a
or champion, who will make sure time, people and other resources are professional project manager organize the work is highly recommended.
committed appropriately for the project. Because enabling IPv6 can In addition, an executive sponsor should be involved in determining
be a project with many interrelated tasks, identifying a project the goals of enabling IPv6 (which will establish the order of the
manager is also recommended. The project manager and sponsor can phases), and should receive regular updates.
initiate the project, determining the scope of work, the
corresponding milestones and deliverables, and identifying whose
input is required, and who will be affected by work. The scope will
generally include the Preparation Phase, and may include the Internal
Phase, the External Phase, or both, and may include any or all of the
Other Phases identified. It may be necessary to complete the
Preparation Phase before determining which of the other phases will
be prioritized, since needs and readiness assessments are part of
that phase.
The project manager will need to spend some time on planning. It is
often useful for the sponsor to communicate with stakeholders at this
time, to explain why IPv6 is important to the enterprise. Then, as
the project manager is assessing what systems and elements will be
affected, the stakeholders will understand why it is important for
them to support the effort. Well-informed project participants can
help significantly by explaining the relationships between
components. For a large enterprise, it may take several iterations
to really understand the level of effort required; some systems will
require additional development, some might require software updates,
and others might need new versions or alternative products from other
vendors. Once the projects are understood, the project manager can
develop a schedule and a budget, and work with the project sponsor to
determine what constraints can be adjusted, if necessary.
It is tempting to roll IPv6 projects into other architectural It may be necessary to complete the Preparation Phase before
upgrades - this can be an excellent way to improve the network and determining whether to prioritized the Internal or External Phase,
reduce costs. Project participants are advised that by increasing since needs and readiness assessments are part of that phase. For a
the scope of projects, the schedule is often affected. For instance, large enterprise, it may take several iterations to really understand
a major systems upgrade may take a year to complete, where just the level of effort required. Depending on the required schedule, it
patching existing systems may take only a few months. Understanding may be useful to roll IPv6 projects into other architectural
and evaluating these trade-offs are why a project manager is upgrades--this can be an excellent way to improve the network and
important. reduce costs. However, by increasing the scope of projects, the
schedule is often affected. For instance, a major systems upgrade
may take a year to complete, where just patching existing systems may
take only a few months.
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 will need to evaluate their ability to support IPv6. If projects, both new and in-progress, will need to be reviewed to
expansions or new deployments fail to include IPv6, then additional ensure IPv6 support.
work will be required after all initial IPv6 has been completed.
Having a purchasing policy that no hardware or software will be
purchased that is not trivially upgradeable to IPv6 will help
minimizing such future work.It may not be possible to delay regular
projects for IPv6, if their IPv6 support is dependent on network
elements that have not yet been upgraded, but the projects need to
include a return to IPv6 support in their eventual timeline.
It is very common for assessments to continue in some areas even as 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). The not deploy IPv6 on a system before security has been evaluated).
project manager will need to continue monitoring the progress of
discrete projects and tasks, to be aware of changes in schedule,
budget, or scope. "Feature creep" is common, where engineers or
management wish to add other features while IPv6 development or
deployment is ongoing; each feature will need to be individually
evaluated for its effect on the schedule and budget, and whether
expanding the scope increases risk to any other part of the project.
As projects are completed, the project manager will confirm that work
has been completed, often by means of seeing a completed test plan,
and will report back to the project sponsor on completed parts of the
project. A good project manager will remember to thank the people
who executed the project.
2.2. Inventory Phase 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 is an important step as it will readiness of network equipment. This will identify the effort
help identify the effort required to move to an infrastructure that required to move to an infrastructure that supports IPv6 with the
supports IPv6 with the same functional service capabilities as the same functional service capabilities as the existing IPv4 network.
existing IPv4 network. This may also require a feature comparison This may also require a feature comparison and gap analysis between
and gap analysis between IPv4 and IPv6 functionality on the network IPv4 and IPv6 functionality on the network equipment and software.
equipment and software. IPv6 support will require testing; features often work differently in
vendors' labs than production networks. Some devices and software
will require IPv4 support for IPv6 to work.
Be able to understand 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.
skipping to change at page 9, line 5 skipping to change at page 8, line 22
2.2.2. Applications readiness assessment 2.2.2. Applications readiness assessment
Just like network equipment, application software needs to support Just like network equipment, application software needs to support
IPv6. This includes OS, firmware, middleware and applications IPv6. This includes OS, firmware, middleware and applications
(including internally developed applications). Vendors will (including internally developed applications). Vendors will
typically handle IPv6 enablement of off-the-shelf products, 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 be made to use APIs required to support IPv6. Applications should avoid instructions
which hide the specifics of a given IP address family. Any specific to a given IP address family. Any applications that use
applications that use APIs, such as the C language, which exposes the APIs, such as the C language, that expose the IP version
IP version specificity, 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
disruption to the existing IPv4 logic flow, but introduces more disruption to the existing IPv4 logic flow, but introduces more
complexity, since the application now has to deal with two logic complexity, since the application now has to deal with two logic
loops with complex race conditions and error recovery mechanisms loops with complex race conditions and error recovery mechanisms
between these two logic loops. The second approach is to create a between these two logic loops. The second approach is to create a
combined IPv4/IPv6 logic, which ensures operation regardless of the combined IPv4/IPv6 logic, which ensures operation regardless of the
IP version used on the network. 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 recommend 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
IPv6 planning and deployment in the enterprise does not only affect Many organizations falter in IPv6 deployment because of a perceived
the network. IPv6 adoption will be a multifaceted undertaking that training gap. Training is important for those who work with
will touch everyone in the organization unlike almost any other addresses regularly, as with anyone whose work is changing. Better
project. While technology and process transformations are taking knowledge of the reasons IPv6 is being deployed will help inform the
place, it is critical that personnel training takes place as well. assessment of who needs training, and what training they need.
Training will ensure that people and skill gaps are assessed
proactively and managed accordingly. We recommend that training
needs be analyzed and defined in order to successfully inform, train,
and prepare staff for the impacts of the system or process changes.
Better knowledge of the requirements to deploy IPv6 may also help
inform procurement processes.
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 learnt a lot about network security with IPv4, so,
network operators should leverage this knowledge and expertise when network operators should leverage this knowledge and expertise when
deploying IPv6. IPv6 is not so different than IPv4: it is a deploying IPv6. IPv6 is not so different than IPv4: it is a
connectionless network protocol using the same lower layer service connectionless network protocol using the same lower layer service
and delivering the same service to the upper layer. Therefore, the and delivering the same service to the upper layer. Therefore, the
security issues and mitigation techniques are mostly identical with security issues and mitigation techniques are mostly identical with
skipping to change at page 10, line 37 skipping to change at page 9, line 45
cannot be scanned by enumerating all IPv6 address in a /64 LAN hence cannot be scanned by enumerating all IPv6 address in a /64 LAN hence
a malevolent person cannot find a victim. [RFC5157] describes some a malevolent person cannot find a victim. [RFC5157] describes some
alternate techniques to find potential targets on a network, for alternate techniques to find potential targets on a network, for
example enumerating all DNS names in a zone. Additional advice in example enumerating all DNS names in a zone. Additional advice in
this area is also given in [I-D.ietf-opsec-ipv6-host-scanning]. this area is also given in [I-D.ietf-opsec-ipv6-host-scanning].
Another security myth is that IPv6 is more secure because it mandates Another security myth is that IPv6 is more secure because it mandates
the use of IPsec everywhere. 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, then this renders a lot of the network security tools encrypted, both malefactors and security tools that rely on payload
(IPS, firewall, ACL, IPFIX, etc) blind and pretty much useless. inspection (IPS, firewall, ACL, IPFIX ([RFC7011] and [RFC7012]), etc)
Therefore, IPsec should be used in IPv6 pretty much like in IPv4 (for will be thwarted. Therefore, IPsec is as useful in IPv6 as in IPv4
example to establish a VPN overlay over a non-trusted network or (for example to establish a VPN overlay over a non-trusted network or
reserved for some specific applications). reserved for some specific applications).
The last security myth is that amplification attacks (such as The last security myth is that amplification attacks (such as
[SMURF]) do not exist in IPv6 because there is no more broadcast. [SMURF]) do not exist in IPv6 because there is no more broadcast.
Alas, this is not true as ICMP error (in some cases) or information Alas, this is not true as ICMP error (in some cases) or information
messages can be generated by routers and hosts when forwarding or messages can be generated by routers and hosts when forwarding or
receiving a multicast message (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.
skipping to change at page 11, line 10 skipping to change at page 10, line 19
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: 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])
o Etc.
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
skipping to change at page 12, line 7 skipping to change at page 11, line 13
always identical and unique MAC-based EUI-64. While this presents a always identical and unique MAC-based EUI-64. 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 of [I-D.ietf-opsec-v6]). Some early enterprise deployments have
taken the approach to use tools that harvest IP/MAC address mappings taken the approach of using tools that harvest IP/MAC address
from switch and router devices to provide address accountability; mappings from switch and router devices to provide address
this approach has been shown to work, though it can involve gathering accountability; this approach has been shown to work, though it can
significantly more address data than in equivalent IPv4 networks. An involve gathering significantly more address data than in equivalent
alternative is to try to prevent the use of privacy extension IPv4 networks. An alternative is to try to prevent the use of
addresses by enforcing the use of DHCPv6, such that hosts only get privacy extension addresses by enforcing the use of DHCPv6, such that
addresses assigned by a DHCPv6 server. This can be done by hosts only get addresses assigned by a DHCPv6 server. This can be
configuring routers to set the M-bit in Router Advertisements, done by configuring routers to set the M-bit in Router
combined with all advertised prefixes being included without the Advertisements, combined with all advertised prefixes being included
A-bit set (to prevent the use of stateless auto-configuration). This without the A-bit set (to prevent the use of stateless auto-
technique of course requires that all hosts support stateful DHCPv6. configuration). This technique of course requires that all hosts
It is important to note that not all operating systems exhibit the support stateful DHCPv6. It is important to note that not all
same behavior when processing RAs with the M-Bit set. The varying OS operating systems exhibit the same behavior when processing RAs with
behavior is related to the lack of prescriptive definition around the the M-Bit set. The varying OS behavior is related to the lack of
A, M and O-bits within the ND protocol. prescriptive definition around the A, M and O-bits within the ND
[I-D.liu-bonica-dhcpv6-slaac-problem] provides a much more detailed protocol. [I-D.liu-bonica-dhcpv6-slaac-problem] provides a much more
analysis on the interaction of the M-Bit and DHCPv6. detailed analysis on the 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 ACL (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 layers
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 source
host and never during a forwarding operation. This means that ICMPv6 host and never during a forwarding operation. This means that ICMPv6
packet-too-big messages must be allowed to pass through the network packet-too-big messages must be allowed to pass through the network
and not be filtered [RFC4890]. Fragments can also be used to evade and not be filtered [RFC4890]. Fragments can also be used to evade
some security mechanisms such as RA-guard [RFC6105]. See also some security mechanisms such as RA-guard [RFC6105]. See also
[RFC5722], and [I-D.ietf-v6ops-ra-guard-implementation]. [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 the Neighbor Discovery Protocol [RFC4861], which
includes a variety of important IPv6 protocol functions, including includes a variety of important IPv6 protocol functions, including
those provided in IPv4 by ARP [RFC0826]. NDP runs over ICMPv6 (which those provided in IPv4 by ARP [RFC0826]. NDP runs over ICMPv6 (which
as stated above means that security policies must allow some ICMPv6 as stated above means that security policies must allow some ICMPv6
messages to pass, as described in RFC 4890), but has the same lack of messages to pass, as described in RFC 4890), but has the same lack of
security as, for example, ARP, in that there is no inherent message security as, for example, ARP, in that there is no inherent message
authentication. While Secure Neighbour Discovery (SeND) [RFC3971] authentication. While Secure Neighbour Discovery (SeND) [RFC3971]
and CGA [RFC3972] have been defined, they are not widely and CGA [RFC3972] have been defined, they are not widely
implemented). The threat model for Router Advertisements within the implemented). The threat model for Router Advertisements within the
NDP suite is similar to that of DHCPv4 (and DHCPv6), in that a rogue NDP suite is similar to that of DHCPv4 (and DHCPv6), in that a rogue
host could be either a rogue router or a rogue DHCP server. An IPv4 host could be either a rogue router or a rogue DHCP server. An IPv4
network can be made more secure with the help of DHCPv4 snooping in network can be made more secure with the help of DHCPv4 snooping in
edge switches, and likewise RA snooping can improve IPv6 network edge switches, and likewise RA snooping can improve IPv6 network
security (in IPv4-only networks as well). Thus enterprises using security (in IPv4-only networks as well). Thus enterprises using
such techniques for IPv4 should use the equivalent techniques for such techniques for IPv4 should use the equivalent techniques for
IPv6, including RA-guard (RFC 6105) and all work in progress from the IPv6, including RA-guard [RFC6105] and all work in progress from the
SAVI WG, e.g. [RFC6959], which is similar to the protection given by SAVI WG, e.g. [RFC6959], which is similar to the protection given by
dynamic ARP monitoring in IPv4. Other DoS vulnerabilities are 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
skipping to change at page 15, line 9 skipping to change at page 14, line 17
additional configuration options often employed by enterprise additional configuration options often employed by enterprise
administrators, and by using stateful DHCPv6, administrators administrators, and by using stateful DHCPv6, administrators
correlating system logs know which system had which address at any correlating system logs know which system had which address at any
given time. Such an accountability model is familiar from IPv4 given time. Such an accountability model is familiar from IPv4
management, though for DHCPv6 hosts are identified by DUID rather management, though for DHCPv6 hosts are identified by DUID rather
than MAC address. For equivalent accountability with SLAAC (and than MAC address. For equivalent accountability with SLAAC (and
potentially privacy addresses), a monitoring system that harvests IP/ potentially privacy addresses), a monitoring system that harvests IP/
MAC mappings from switch and router equipment could be used. 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. In a traditional IPv4 network, the to get host DNS records updated. Commonly, either the host will send
two commonly used methods are to either have the host send DNS DNS updates or the DHCP server will update records. If there is
updates itself or have the DHCPv4 server update DNS records. The sufficient trust between the hosts and the DNS server, the hosts may
former implies that there is sufficient trust between the hosts and update (and the enterprise may use SLAAC for addressing). Otherwise,
the DNS server while the latter implies a slightly more controlled the DHCPv6 server can be configured to update the DNS server. Note
environment where only DHCP servers are trusted to make these that an enterprise network with this more controlled environment will
updates. If the enterprise uses the first model, then SLAAC is a need to disable SLAAC on network segments and force end hosts to use
perfectly valid option to assign addresses to end systems. However, DHCPv6 only.
an enterprise network with a more controlled environment will need to
disable SLAAC and force end hosts to use 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. Addresses are either configured manually on the server, or blocks. Some administrators reserve a /64 but configure a small
reserved on a DHCPv6 server, which may also synchronize forward and subnet, such as /112, /126, or /127, to prevent rogue devices from
reverse DNS. Because of the need to synchronize RA timers and DNS attaching and getting numbers; an alternative is to monitor traffic
TTLs, SLAAC is rarely, if ever, used for servers, and would require for surprising addresses or ND tables for new entries. Addresses are
tightly coupled dynamic DNS updates. [RFC6866] either configured manually on the server, or reserved on a DHCPv6
server, which may also synchronize forward and reverse DNS (though
see [RFC6866] for considerations on static addressing). SLAAC is not
recommended for servers, because of the need to synchronize RA timers
with DNS TTLs so that 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 Neighbor Discovery Protocol 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 VLSM [RFC1817] in IPv6, and addressing plans based on
conservation of addresses are short-sighted. Use of prefixes longer conservation of addresses are short-sighted. Use of prefixes longer
then /64 on network segments will break common IPv6 functions such as then /64 on network segments will break common IPv6 functions such as
SLAAC[RFC4862]. Where multiple VLANs or other layer two domains SLAAC[RFC4862]. Where multiple VLANs or other layer two domains
converge, allow some room for expansion. Renumbering due to converge, allow some room for expansion. Renumbering due to
outgrowing the network plan is a nuisance, so allow room within it. outgrowing the network plan is a nuisance, so allow room within it.
Generally, plan to grow to about twice the current size that can be Generally, plan to grow to about twice the current size that can be
accommodated; where rapid growth is planned, allow for twice that accommodated; where rapid growth is planned, allow for twice that
growth. Also, if DNS (or reverse DNS) authority may be delegated to growth. Also, if DNS (or reverse DNS) authority may be delegated to
others in the enterprise, assignments need to be on nibble boundaries others in the enterprise, assignments need to be on nibble boundaries
(that is, on a multiple of 4 bits, such as /64, /60, /56, ..., /48, / (that is, on a multiple of 4 bits, such as /64, /60, /56, ..., /48,
44), to ensure that delegated zones align with assigned prefixes. /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. ULA 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 more and more include virtual networks where a
single physical node may host many virtualized addressable devices. single physical node may host many virtualized addressable devices.
It is imperative that the addressing plans assigned to these virtual It is imperative that the addressing plans assigned to these virtual
networks and devices be consistent and non-overlapping with the networks and devices be consistent and non-overlapping with the
addresses assigned to real networks and nodes. For example, a addresses assigned to real networks and nodes. For example, a
skipping to change at page 17, line 34 skipping to change at page 16, line 45
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 which
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 outward
facing or accessible services. facing or accessible services.
How an organization connects to the outside worlds is very important
as it is often a critical part of how a business functions, therefore
it must be dealt accordingly.
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 (Provider Independent) and/or PA (Provider
Aggregatable) 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 they
selected (PI vs. PA) in their planning section, they may need to 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 behaviours 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. In enterprise's behalf and update the relevant routing databases.
other cases, the enterprise may need to perform this task on their Otherwise, the enterprise may need to perform this task on their own
own and use BGP to inject the prefix into the global BGP system. The and use BGP to inject the prefix into the global BGP system.
latter case however is not deployed by many enterprises today, which
is an important consideration.
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 multihomed
to be eligible for an IPv6 PI allocation. Requests can be made to be eligible for an IPv6 PI allocation. Requests can be made
directly or via a LIR. It is possible that the rules may change 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, the Enterprise When seeking IPv6 connectivity to a Service Provider, Native IPv6
will prefer to use native IPv6 connectivity. 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 which provide robust tunnelled IPv6
connectivity which can operate over IPv4 networks. It is important connectivity which can operate over IPv4 networks. It is important
to understand the transition tunnel mechanism used, and to consider to understand the transition tunnel mechanism used, and to consider
that it will have higher latency than native IPv4 or IPv6, and may that it will have higher latency than native IPv4 or IPv6, and may
have other problems, e.g. related to MTUs. have other problems, e.g. related to MTUs.
It is important to evaluate MTU considerations when adding in IPv6 to It is important to evaluate MTU considerations when adding IPv6 to an
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. If the enterprise and IPv4 MTU congruent to simplify operations (so the two address
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 pMTUD is used to optimize the MTU, so erroneous filtering of the
related ICMPv6 message types should be monitored. Adjusting the MTU related ICMPv6 message types should be monitored. Adjusting the MTU
may be the only option if undesirable upstream ICMPv6 filtering may be the only option if undesirable upstream ICMPv6 filtering
cannot be removed. 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 (else the attacker will use the less protected protocol
stack), except that certain ICMPv6 messages must be allowed through stack), except that certain ICMPv6 messages must be allowed through
and to the filtering device (see [RFC4890]): and to the filtering device (see [RFC4890]):
o Unreachable packet-too-big: it is very important to allow Path MTU o Packet Too Big: essential to allow Path MTU discovery to work
discovery to work
o Unreachable parameter-problem o Parameter Problem
o Neighbor solicitation o Time Exceeded
o Neighbor advertisement In addition, Neighbor Discovery Protocol messages (including Neighbor
Solicitation, Router Advertisements, etc.) are required for local
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.
To be fully compliant with [RFC5095], all packets containing the Ingress filters and firewalls should follow [RFC5095] in handling
routing extension header type 0 must be dropped. routing extension header type 0, dropping the packet and sending
ICMPv6 Parameter Problem, unless Segments Left = 0 (in which case,
ignore the header).
If an Intrusion Prevention System (IPS) is used for IPv4 traffic, If an Intrusion Prevention System (IPS) is used for IPv4 traffic,
then an IPS should also be used for IPv6 traffic. In general, make then an IPS should also be used for IPv6 traffic. In general, make
sure IPv6 security is at least as good as IPv4. This also includes sure IPv6 security is at least as good as IPv4. This also includes
all email content protection (anti-spam, content filtering, data all email content protection (anti-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).
skipping to change at page 19, line 51 skipping to change at page 19, line 13
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 IP Flow
Information eXport (IPFIX) [RFC7012] to report abnormal traffic Information eXport (IPFIX) [RFC7012] to report abnormal traffic
patterns (such as port scanning, SYN-flooding, related IP source patterns (such as port scanning, SYN-flooding, related IP source
addresses) from monitoring tools and evaluating data read from SNMP addresses) from monitoring tools and evaluating data read from SNMP
MIBs [RFC4293] (some of which also enable the detection of abnormal MIBs [RFC4293] (some of which also enable the detection of abnormal
bandwidth utilization). Where Netflow is used, version 9 is required bandwidth utilization) and syslogs (finding server and system
for IPv6 support. errors). Where Netflow is used, version 9 is required for IPv6
support. Monitoring systems should be able to examine IPv6 traffic,
use IPv6 for connectivity, record IPv6 address, and any log parsing
tools and reporting need to support IPv6. Some of this data can be
sensitive (including personally identifiable information) and care in
securing it should be taken, with periodic purges. Integrity
protection on logs and sources of log data is also important to
detect unusual behavior (misconfigurations or attacks). Logs may be
used in investigations, which depend on trustworthy data sources
(tamper resistant).
In addition, monitoring of external services (such as web sites)
should be made address-specific, so that people are notified when
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, 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 dual-stack on all devices but this may ideal transition is to enable native dual-stack on all devices; but
seem too time-consuming and too risky. as part of the phased approach, operators have used the following
techniques with success:
Operators have used the following approaches 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 to
do this translation. Compared to the NAT64, it has the potential do this translation. Compared to the NAT64, it has the potential
benefit of going through the security devices as native IPv6 (so benefit of going through the security devices as native IPv6 (so
more audit and trace abilities) and is also able to insert a HTTP more audit and trace abilities) and is also able to insert a HTTP
X-Forward-For header which contains the remote IPv6 address. The X-Forward-For header which contains the remote IPv6 address. The
latter feature allows for logging, and rate-limiting on the real latter feature allows for logging, and rate-limiting on the real
servers based on the IPV6 address even if those servers run only servers based on the IPV6 address even if those servers run only
IPv4. IPv4.
In either of these cases, care should be taken to secure logs for
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 which 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 and how prefixes are assigned and routed within the internal network, how prefixes are
routed towards the Internet (included both PA and PI address routed towards the Internet, or whether PA or PI addresses are used.
assignment options).
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 IT infrastructure, which comprises various
components such as network devices (routers, switches, etc.), end components such as network devices (routers, switches, etc.), end
user devices and peripherals (workstations, printers, etc.), and user devices and peripherals (workstations, printers, etc.), and
internal corporate systems. internal corporate systems.
An important design paradigm to consider during this phase is "dual- An important design paradigm to consider during this phase is "dual-
skipping to change at page 21, line 38 skipping to change at page 21, line 21
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 Section 2.4.3. The enterprise may
choose to attempt to enforce use of DHCPv6, or deploy monitoring 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).
But the major issue is probably linked to all threats against One major issue is threats against Neighbor Discovery. This means,
Neighbor Discovery. This means, for example, that the internal for example, that the internal network at the access layer (where
network at the access layer (where hosts connect to the network over hosts connect to the network over wired or wireless) should implement
wired or wireless) should implement RA-guard [RFC6105] and the RA-guard [RFC6105] and the techniques being specified by SAVI WG
techniques being specified by SAVI WG [RFC6959]; see also [RFC6959]; see also Section 2.4.3 for more information.
Section 2.4.3 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
skipping to change at page 23, line 4 skipping to change at page 22, line 33
administrative overhead, then SLAAC makes more sense for administrative overhead, then SLAAC makes more sense for
workstations. Manual or DHCPv6 assignments are still needed for workstations. Manual or DHCPv6 assignments are still needed for
servers, as described in the External Phase and Address Plan sections servers, as described in the External Phase and Address Plan sections
of this document. However, if the operational policies call for of this document. However, if the operational policies call for
precise control over IP address assignment for auditing then DHCPv6 precise control over IP address assignment for auditing then DHCPv6
may be preferred. DHCPv6 also allows you to tie into DNS systems for may be preferred. DHCPv6 also allows you to tie into DNS systems for
host entry updates and gives you the ability to send other options host entry updates and gives you the ability to send other options
and information to clients. It is worth noting that in general and 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, in networks for other configuration information, e.g. NTP servers or,
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
skipping to change at page 23, line 32 skipping to change at page 23, line 13
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 interfaces
unless required. 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 poised to become one of the major Smartphones and tablets are significant IPv6-capable platforms,
consumers of IP addresses and enterprises, and should be ready to depending on the support of the carrier's data network.
support IPv6 on various networks that serve such devices. In
general, support for IPv6 in these devices, albeit in its infancy,
has been steadily rising. Most of the leading smartphone OSes have
some level of support for IPv6. However, the level of configurable
options are mostly at a minimum and are not consistent across all
platforms. Also, it is fairly common to find IPv6 support on the Wi-
Fi connection alone and not on the radio interface in these devices.
This is sometimes due to the radio network not being IPv6 ready, or
it may be device-related. An IPv6-enabled enterprise Wi-Fi network
will allow the majority of these devices to connect via IPv6. Much
work is still being done to bring the full IPv6 feature set across
all interfaces (802.11, 3G, LTE, etc.) and platforms. For example,
mobility management functions will be needed to accommodate handovers
between diverse access technologies.
IPv6 support in peripheral equipment such as printers, IP cameras, IPv6 support for peripherals varies. Much like servers, printers are
etc., has been steadily rising as well, although at a much slower generally configured with a static address (or DHCP reservation) so
pace than traditional OSes and smartphones. Most newer devices are clients can discover them reliably.
coming out with IPv6 support but there is still a large installed
base of legacy peripheral devices that might need IPv4 for some time
to come. The audit phase mentioned earlier will make it easier for
enterprises to plan for equipment upgrades, in line with their
corporate equipment refresh cycle.
4.4. Corporate Systems 4.4. Corporate Systems
No IPv6 deployment will be successful without ensuring that all the No IPv6 deployment will be successful without ensuring that all the
corporate systems that an enterprise uses as part of its IT corporate systems that an enterprise uses as part of its IT
infrastructure support IPv6. Examples of such systems include, but infrastructure support IPv6. Examples of such systems include, but
are not limited to, email, video conferencing, telephony (VoIP), DNS, are not limited to, email, video conferencing, telephony (VoIP), DNS,
RADIUS, etc. All these systems must have their own detailed IPv6 RADIUS, etc. All these systems must have their own detailed IPv6
rollout plan in conjunction with the network IPv6 rollout. It is rollout plan in conjunction with the network IPv6 rollout. It is
important to note that DNS is one of the main anchors in an important to note that DNS is one of the main anchors in an
enterprise deployment, since most end hosts decide whether or not 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. Additionally, all monitoring and reporting tools across the record. Care with web proxies is advised; a mismatch in the level of
enterprise would need to be modified to support IPv6. IPv6 support between the client, proxy, and server can cause
communication problems. All monitoring and reporting tools across
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 on gradually deprecating IPv4 from the dual-stack network. In steps to simplify engineering and operations by deprecating IPv4 from
some extreme cases, deploying dual-stack networks may not even be a the dual-stack network. In some extreme cases, deploying dual-stack
viable option for very large enterprises due to the RFC 1918 address networks may not even be a viable option for very large enterprises
space not being large enough to support the network's growth. In due to the RFC 1918 address space not being large enough to support
such cases, deploying IPv6-only networks might be the only choice the network's growth. In such cases, deploying IPv6-only networks
available to sustain network growth. In other cases, there may be might be the only choice available to sustain network growth. In
elements of an otherwise dual-stack network that may be run other cases, there may be elements of an otherwise dual-stack network
IPv6-only. that may be run IPv6-only.
If nodes in the network don't need to talk to an IPv4-only node, then If nodes in the network don't need to talk to an IPv4-only node, then
deploying IPv6-only networks should be fairly trivial. However, in deploying IPv6-only networks should be straightforward. However,
the current environment, given that IPv4 is the dominant protocol on most nodes will need to communicate with some IPv4-only nodes; an
the Internet, an IPv6-only node most likely needs to talk to an IPv6-only node may therefore require a translation mechanism. As
IPv4-only node on the Internet. It is therefore important to provide
such nodes with a translation mechanism to ensure communication
between nodes configured with different address families. As
[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. [RFC6146], NAT64,
describes stateful address translation. As the name suggests, the describes stateful address translation. As the name suggests, the
translation state is maintained between IPv4 address/port pairs and translation state is maintained between IPv4 address/port pairs and
IPv6 address/port pairs, enabling IPv6 systems to open sessions with IPv6 address/port pairs, enabling IPv6 systems to open sessions with
IPv4 systems. [RFC6147], DNS64, describes a mechanism for IPv4 systems. [RFC6147], DNS64, describes a mechanism for
synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs synthesizing AAAA resource records (RRs) from A RRs. Together, RFCs
6146 and RFC 6147 provide a viable method for an IPv6-only client to 6146 and RFC 6147 provide a viable method for an IPv6-only client to
initiate communications to an IPv4-only server. At the enterprise initiate communications to an IPv4-only server. As described in the
level, operating NAT64 and DNS64 services for heavy usage may have assumptions section, the administrator will usually want most traffic
significant practical implications. 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
skipping to change at page 26, line 20 skipping to change at page 25, line 31
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
CDNs. An enterprise that relies on CDN to deliver a 'better' Content Delivery Networks (CDNs). An enterprise that relies on a CDN
e-commerce experience needs to ensure that their CDN provider also to deliver a 'better' e-commerce experience needs to ensure that
supports IPv4/IPv6 traffic selection so that they can ensure 'best' their CDN provider also supports IPv4/IPv6 traffic selection so that
access to the content. they can ensure 'best' access to the content. A CDN could enable
external IPv6 content delivery even if the enterprise provides that
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
[I-D.ietf-v6ops-dc-ipv6]. [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 deployment. This has been encouraged by their National Research
and Education Network (NREN) backbones having made IPv6 available and Education Network (NREN) backbones having made IPv6 available
natively since the early 2000's. Universities are a natural place for natively since the early 2000's. Universities are a natural place
IPv6 deployment to be considered at an early stage, perhaps compared for IPv6 deployment to be considered at an early stage, perhaps
to other enterprises, as they are involved by their very nature in compared to other enterprises, as they are involved by their very
research and education. 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:
skipping to change at page 27, line 39 skipping to change at page 26, line 51
Campuses which have deployed to date do not use ULAs, nor do they use Campuses which 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 may wish to consider support for specific IPv6
multicast functionality, e.g. Embedded-RP [RFC3956] in routers and multicast functionality, e.g. Embedded-RP [RFC3956] in routers and
MLDv1 and MLDv2 snooping in switches. 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 how to
securely deploy an IPv6 network within an enterprise network. securely deploy an IPv6 network within an enterprise network.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Chris Grundemann, Ray Hunter, Brian The authors would like to thank Robert Sparks, Steve Hanna, Tom
Carpenter, Tina Tsou, Christian Jaquenet, and Fred Templin for their Taylor, Brian Haberman, Stephen Farrell, Chris Grundemann, Ray
substantial comments and contributions. Hunter, Kathleen Moriarty, Benoit Claise, Brian Carpenter, Tina Tsou,
Christian Jaquenet, and Fred Templin for their substantial comments
and contributions.
9. IANA Considerations 9. IANA Considerations
There are no IANA considerations or implications that arise from this There are no IANA considerations or implications that arise from this
document. document.
10. Informative References 10. Informative References
[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
skipping to change at page 32, line 17 skipping to change at page 31, line 29
6883, March 2013. 6883, March 2013.
[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.
[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.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of
the IP Flow Information Export (IPFIX) Protocol for the
Exchange of Flow Information", STD 77, RFC 7011, September
2013.
[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
IPv4 Networks", RFC 7123, February 2014.
[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", RFC7045 , December 2013,
<http://tools.ietf.org/html/rfc7045>. <http://tools.ietf.org/html/rfc7045>.
[I-D.xli-behave-divi] [I-D.xli-behave-divi]
Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-
Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-06 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-06
(work in progress), January 2014. (work in progress), January 2014.
[I-D.wierenga-ietf-eduroam] [I-D.wierenga-ietf-eduroam]
Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
architecture for network roaming", draft-wierenga-ietf- architecture for network roaming", draft-wierenga-ietf-
eduroam-01 (work in progress), July 2013. eduroam-03 (work in progress), February 2014.
[I-D.ietf-v6ops-dc-ipv6] [I-D.ietf-v6ops-dc-ipv6]
Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin, Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin,
"IPv6 Operational Guidelines for Datacenters", draft-ietf- "IPv6 Operational Guidelines for Datacenters", draft-ietf-
v6ops-dc-ipv6-00 (work in progress), August 2013. v6ops-dc-ipv6-01 (work in progress), February 2014.
[I-D.ietf-v6ops-design-choices] [I-D.ietf-v6ops-design-choices]
Matthews, P., "Design Choices for IPv6 Networks", draft- Matthews, P. and V. Kuarsingh, "Design Choices for IPv6
ietf-v6ops-design-choices-00 (work in progress), February Networks", draft-ietf-v6ops-design-choices-01 (work in
2013. progress), March 2014.
[I-D.ietf-opsec-v6] [I-D.ietf-opsec-v6]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks", draft-ietf- Security Considerations for IPv6 Networks", draft-ietf-
opsec-v6-04 (work in progress), October 2013. opsec-v6-04 (work in progress), October 2013.
[I-D.ietf-opsec-ipv6-host-scanning] [I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-02 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-04 (work in
progress), July 2013. progress), June 2014.
[I-D.ietf-opsec-ipv6-implications-on-ipv4-nets]
Gont, F. and W. Will, "Security Implications of IPv6 on
IPv4 Networks", draft-ietf-opsec-ipv6-implications-on-
ipv4-nets-07 (work in progress), December 2013.
[I-D.ietf-v6ops-ra-guard-implementation]
Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra-
guard-implementation-07 (work in progress), November 2012.
[I-D.liu-bonica-dhcpv6-slaac-problem] [I-D.liu-bonica-dhcpv6-slaac-problem]
Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration
Interaction Problem Statement", draft-liu-bonica-dhcpv6 Interaction Problem Statement", draft-liu-bonica-dhcpv6-
-slaac-problem-02 (work in progress), September 2013. slaac-problem-02 (work in progress), September 2013.
[I-D.ietf-v6ops-ula-usage-recommendations] [I-D.ietf-v6ops-ula-usage-recommendations]
Liu, B., Jiang, S., and C. Byrne, "Recommendations of Liu, B. and S. Jiang, "Considerations of Using Unique
Using Unique Local Addresses", draft-ietf-v6ops-ula-usage- Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-01 (work in progress), October 2013. recommendations-03 (work in progress), 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 [SMURF] "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service
Attacks", Attacks",
<http://www.cert.org/advisories/CA-1998-01.html>. <http://www.cert.org/advisories/CA-1998-01.html>.
[CYMRU] "THE BOGON REFERENCE", [CYMRU] "THE BOGON REFERENCE",
<http://www.team-cymru.org/Services/Bogons/>. <http://www.team-cymru.org/Services/Bogons/>.
Authors' Addresses Authors' Addresses
Kiran K. Chittimaneni Kiran K. Chittimaneni
Google Inc. Dropbox Inc.
1600 Amphitheater Pkwy 1600 Amphitheater Pkwy
Mountain View, California CA 94043 Mountain View, California CA 94043
USA USA
Email: kk@google.com 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 US
Phone: +1 703 345 3513 Phone: +1 703 345 3513
Email: lee.howard@twcable.com Email: lee.howard@twcable.com
Victor Kuarsingh Victor Kuarsingh
 End of changes. 81 change blocks. 
313 lines changed or deleted 276 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/