draft-ietf-v6ops-enterprise-incremental-ipv6-03.txt   draft-ietf-v6ops-enterprise-incremental-ipv6-04.txt 
Network Working Group K. Chittimaneni Network Working Group K. Chittimaneni
Internet-Draft Google Inc. Internet-Draft Google Inc.
Intended status: Informational T. Chown Intended status: Informational T. Chown
Expires: January 15, 2014 University of Southampton Expires: April 19, 2014 University of Southampton
L. Howard L. Howard
Time Warner Cable Time Warner Cable
V. Kuarsingh V. Kuarsingh
Rogers Communications Dyn Inc
Y. Pouffary Y. Pouffary
Hewlett Packard Hewlett Packard
E. Vyncke E. Vyncke
Cisco Systems Cisco Systems
July 14, 2013 October 16, 2013
Enterprise IPv6 Deployment Guidelines Enterprise IPv6 Deployment Guidelines
draft-ietf-v6ops-enterprise-incremental-ipv6-03 draft-ietf-v6ops-enterprise-incremental-ipv6-04
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
overall transition will take most networks from an IPv4-only overall transition will take most networks from an IPv4-only
environment to a dual stack network environment and potentially an environment to a dual stack network environment and eventually an
IPv6-only operating mode. This document helps provide a framework IPv6-only operating mode. This document helps provide a framework
for enterprise network architects or administrators who may be faced for enterprise network architects or administrators who may be faced
with many of these challenges as they consider their IPv6 support with many of these challenges as they consider their IPv6 support
strategies. strategies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 15, 2014. This Internet-Draft will expire on April 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . 4 1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . 4
1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 4 1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Network infrastructure readiness assessment . . . . . 8 2.2.1. Network infrastructure readiness assessment . . . . . 8
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 . . . 9
2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 9 2.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 9
2.4.1. IPv6 is no more secure than IPv4 . . . . . . . . . . 9 2.4.1. IPv6 is no more secure than IPv4 . . . . . . . . . . 10
2.4.2. Similarities between IPv6 and IPv4 security . . . . . 10 2.4.2. Similarities between IPv6 and IPv4 security . . . . . 11
2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 11 2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 11
2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 13 2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 13
2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 15 2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 16
3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 17 3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 19 3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 20
3.4. Servers and Applications . . . . . . . . . . . . . . . . 19 3.4. Servers and Applications . . . . . . . . . . . . . . . . 20
3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 20 3.5. Network Prefix Translation for IPv6 . . . . . . . . . . . 20
4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 20 4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 21 4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 22
4.3. End user devices . . . . . . . . . . . . . . . . . . . . 23 4.3. End user devices . . . . . . . . . . . . . . . . . . . . 23
4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 24 4.4. Corporate Systems . . . . . . . . . . . . . . . . . . . . 24
5. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Considerations For Specific Enterprises . . . . . . . . . . . 25 6. Considerations For Specific Enterprises . . . . . . . . . . . 26
6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 25 6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 26
6.2. Data Center Virtualization . . . . . . . . . . . . . . . 26 6.2. Data Center Virtualization . . . . . . . . . . . . . . . 26
6.3. University Campus Networks . . . . . . . . . . . . . . . 26 6.3. University Campus Networks . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Informative References . . . . . . . . . . . . . . . . . . . 27 10. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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, other
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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.
Tunnels used for IPv6/IPv4 transition are expected as near/mid- term
mechanisms, while IPv6 tunneling will be used for many long-term
operational purposes such as security, routing control, mobility,
multi-homing, traffic engineering, etc. We refer to the former class
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 or
Dual-stack Lite. Dual-stack Lite.
Other IPv6 considerations may impact ostensibly IPv4-only networks, Other IPv6 considerations may impact ostensibly IPv4-only networks,
skipping to change at page 6, line 17 skipping to change at page 6, line 24
prioritization of these corporate systems. prioritization of these corporate systems.
o Some large organizations (even when using private IPv4 o Some large organizations (even when using private IPv4
addresses[RFC1918]) are facing IPv4 address exhaustion because of addresses[RFC1918]) are facing IPv4 address exhaustion because of
the internal network growth (for example the vast number of the internal network growth (for example the vast number of
virtual machines) or because of the acquisition of other companies virtual machines) or because of the acquisition of other companies
that often raise private IPv4 address overlapping issues. that often raise private IPv4 address overlapping issues.
o IPv6 restores end to end transparency even for internal o IPv6 restores end to end transparency even for internal
applications (of course security policies must still be enforced). applications (of course security policies must still be enforced).
When two organizations or networks merge When two organizations or networks merge [RFC6879], the unique
[I-D.ietf-6renum-enterprise], the unique addressing of IPv6 can addressing of IPv6 can make the merger much easier and faster. A
make the merger much easier and faster. A merger may, therefore, merger may, therefore, prioritize IPv6 for the affected systems.
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 18 years.
2. Preparation and Assessment Phase 2. Preparation and Assessment Phase
2.1. Program Planning 2.1. Program Planning
skipping to change at page 12, line 19 skipping to change at page 12, line 29
[I-D.liu-bonica-dhcpv6-slaac-problem] provides a much more detailed [I-D.liu-bonica-dhcpv6-slaac-problem] provides a much more detailed
analysis on the interaction of the M-Bit and DHCPv6. 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 [RFC5095]). This topic is discussed further in
[I-D.carpenter-6man-ext-transmit]. [I-D.ietf-6man-ext-transmit].
Fragmentation is different in IPv6 because it is done only by source Fragmentation is different in IPv6 because it is done only by source
host and never during a forwarding operation. This means that ICMPv6 host and never during a forwarding operation. This means that ICMPv6
packet-too-big 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 [I-D.ietf-v6ops-ra-guard-implementation].
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
skipping to change at page 12, line 45 skipping to change at page 13, line 7
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 (RFC 6105) and all work in progress from the
SAVI WG, e.g. [I-D.ietf-savi-threat-scope], which is similar to the SAVI WG, e.g. [RFC6959], which is similar to the protection given by
protection given by dynamic ARP monitoring in IPv4. Other DoS dynamic ARP monitoring in IPv4. Other DoS vulnerabilities are
vulnerabilities are related to NDP cache exhaustion, and mitigation related to NDP cache exhaustion, and mitigation techniques can be
techniques can be found in ([RFC6583]). found in ([RFC6583]).
As stated previously, running a dual-stack network doubles the attack As stated previously, running a dual-stack network doubles the attack
exposure as a malevolent person has now two attack vectors: IPv4 and exposure as a malevolent person has now two attack vectors: IPv4 and
IPv6. This simply means that all routers and hosts operating in a IPv6. This simply means that all routers and hosts operating in a
dual-stack environment with both protocol families enabled (even if dual-stack environment with both protocol families enabled (even if
by default) must have a congruent security policy for both protocol by default) must have a congruent security policy for both protocol
versions. For example, permit TCP ports 80 and 443 to all web versions. For example, permit TCP ports 80 and 443 to all web
servers and deny all other ports to the same servers must be servers and deny all other ports to the same servers must be
implemented both for IPv4 and IPv6. It is thus important that the implemented both for IPv4 and IPv6. It is thus important that the
tools available to administrators readily support such behaviour. tools available to administrators readily support such behaviour.
skipping to change at page 13, line 43 skipping to change at page 14, line 5
The most common problem encountered in IPv6 networking is in applying The most common problem encountered in IPv6 networking is in applying
the same principles of conservation that are so important in IPv4. the same principles of conservation that are so important in IPv4.
IPv6 addresses do not need to be assigned conservatively. In fact, a IPv6 addresses do not need to be assigned conservatively. In fact, a
single larger allocation is considered more conservative than single larger allocation is considered more conservative than
multiple non-contiguous small blocks, because a single block occupies multiple non-contiguous small blocks, because a single block occupies
only a single entry in a routing table. The advice in [RFC5375] is only a single entry in a routing table. The advice in [RFC5375] is
still sound, and is recommended to the reader. If considering ULAs, still sound, and is recommended to the reader. If considering ULAs,
give careful thought to how well it is supported, especially in give careful thought to how well it is supported, especially in
multiple address and multicast scenarios, and assess the strength of multiple address and multicast scenarios, and assess the strength of
the requirement for ULA. If using ULAs in a ULA-only deployment the requirement for ULA. [I-D.ietf-v6ops-ula-usage-recommendations]
model, instead of using them in conjunction with Globally Unique provides much more detailed analysis and recommendations on the usage
Addressing for hosts, note that Network Prefix Translation will be of ULAs.
required [RFC6296] for Internet based communication; the implications
of which must be well understood before deploying.
[I-D.ietf-v6ops-ula-usage-recommendations] provides much more
detailed analysis and recommendations on the usage of ULAs.
The enterprise administrator will want to evaluate whether the The enterprise administrator will want to evaluate whether the
enterprise will request address space from a LIR (Local Internet enterprise will request address space from a LIR (Local Internet
Registry, such as an ISP), a RIR (Regional Internet Registry, such as Registry, such as an ISP), a RIR (Regional Internet Registry, such as
AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC) or a NIR (National AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC) or a NIR (National
Internet Registry, operated in some countries). The normal Internet Registry, operated in some countries). The normal
allocation is Provider Aggregatable (PA) address space from the allocation is Provider Aggregatable (PA) address space from the
enterprise's ISP, but use of PA space implies renumbering when enterprise's ISP, but use of PA space implies renumbering when
changing provider. Instead, an enterprise may request Provider changing provider. Instead, an enterprise may request Provider
Independent (PI) space; this may involve an additional fee, but the Independent (PI) space; this may involve an additional fee, but the
skipping to change at page 15, line 20 skipping to change at page 15, line 40
an enterprise network with a more controlled environment will need to an enterprise network with a more controlled environment will need to
disable SLAAC and force end hosts to use DHCPv6 only. 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. Addresses are either configured manually on the server, or
reserved on a DHCPv6 server, which may also synchronize forward and reserved on a DHCPv6 server, which may also synchronize forward and
reverse DNS. Because of the need to synchronize RA timers and DNS reverse DNS. Because of the need to synchronize RA timers and DNS
TTLs, SLAAC is rarely, if ever, used for servers, and would require TTLs, SLAAC is rarely, if ever, used for servers, and would require
tightly coupled dynamic DNS updates. tightly coupled dynamic DNS updates. [RFC6866]
[I-D.ietf-6renum-static-problem]
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
skipping to change at page 15, line 34 skipping to change at page 16, line 4
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.
When using ULAs, it is important to note that AAAA and PTR records
for ULA are not recommended to be installed in the global DNS.
Similarly, reverse (address-to-name) queries for ULA must not be sent
to name servers outside of the organization, due to the load that
such queries would create for the authoritative name servers for the
ip6.arpa zone. For more details please refer to section 4.4 of
[RFC4193].
Enterprise networks more and more include virtual networks where a
single physical node may host many virtualized addressable devices.
It is imperative that the addressing plans assigned to these virtual
networks and devices be consistent and non-overlapping with the
addresses assigned to real networks and nodes. For example, a
virtual network established within an isolated lab environment may at
a later time become attached to the production enterprise network.
2.7. Tools Assessment 2.7. Tools Assessment
Enterprises will often have a number of operational tools and support Enterprises will often have a number of operational tools and support
systems which are used to provision, monitor, manage and diagnose the systems which are used to provision, monitor, manage and diagnose the
network and systems within their environment. These tools and network and systems within their environment. These tools and
systems will need to be assessed for compatibility with IPv6. The systems will need to be assessed for compatibility with IPv6. The
compatibility may be related to the addressing and connectivity of compatibility may be related to the addressing and connectivity of
various devices as well as IPv6 awareness the tools and processing various devices as well as IPv6 awareness of the tools and processing
logic. logic.
The tools within the organization fall into two general categories, The tools within the organization fall into two general categories,
those which focus on managing the network, and those which are those which focus on managing the network, and those which are
focused on managing systems and applications on the network. In focused on managing systems and applications on the network. In
either instance, the tools will run on platforms which may or may not either instance, the tools will run on platforms which may or may not
be capable of operating in an IPv6 network. This lack in be capable of operating in an IPv6 network. This lack in
functionality may be related to Operating System version, or based on functionality may be related to Operating System version, or based on
some hardware constraint. Those systems which are found to be some hardware constraint. Those systems which are found to be
incapable of utilizing an IPv6 connection, or which are dependent on incapable of utilizing an IPv6 connection, or which are dependent on
an IPv4 stack, may need to be replaced or upgraded. an IPv4 stack, may need to be replaced or upgraded.
In addition to devices working on an IPv6 network natively, or via a In addition to devices working on an IPv6 network natively, or via a
tunnel, many tools and support systems may require additional transition tunnel, many tools and support systems may require
software updates to be IPv6 aware, or even a hardware upgrade additional software updates to be IPv6 aware, or even a hardware
(usually for additional memory: IPv6 as the addresses are larger and upgrade (usually for additional memory: IPv6 addresses are larger and
for a while, IPv4 and IPv6 addresses will coexist in the tool). This for a while, IPv4 and IPv6 addresses will coexist in the tool). This
awareness may include the ability to manage IPv6 elements and/or awareness may include the ability to manage IPv6 elements and/or
applications in addition to the ability to store and utilize IPv6 applications in addition to the ability to store and utilize IPv6
addresses. addresses.
Considerations when assessing the tools and support systems may Considerations when assessing the tools and support systems may
include the fact that IPv6 addresses are significantly larger than include the fact that IPv6 addresses are significantly larger than
IPv4, requiring data stores to support the increased size. Such IPv4, requiring data stores to support the increased size. Such
issues are among those discussed in [RFC5952]. Many organizations issues are among those discussed in [RFC5952]. Many organizations
may also run dual-stack networks, therefore the tools need to not may also run dual-stack networks, therefore the tools need to not
skipping to change at page 17, line 35 skipping to change at page 18, line 19
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 section, 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. In
other cases, the enterprise may need to perform this task on their other cases, the enterprise may need to perform this task on their
own and use BGP to inject the prefix into the global BGP system. own and use BGP to inject the prefix into the global BGP system. The
This latter case is not how many enterprises operate today and is an latter case however is not deployed by many enterprises today, which
important consideration. 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 an 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, the Enterprise
will prefer to use native IPv6 connectivity. 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 tunnelled IPv6 connectivity. There are utilize readily available transition tunnel IPv6 connectivity. There
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 tunneling mechanism used, and to consider that it to understand the transition tunnel mechanism used, and to consider
will have higher latency than native IPv4 or IPv6, and may have other that it will have higher latency than native IPv4 or IPv6, and may
problems, e.g. related to MTUs. have other problems, e.g. related to MTUs.
The use of ULAs may provide some flexibility when an enterprise is
using PA space from two or more providers in a multihoming scenario,
by providing an independent local prefix for internal use, while
using the PA prefix for external communication in conjunction with
NPTv6 at the egress [RFC6296]. While NPTv6 can provide for
simplified renumbering in certain scenarios, as described in
[I-D.ietf-6renum-enterprise], it must be noted that many of the well-
known issues with NAT still apply, in particular handling IPv6
addresses embedded in payloads. As mentioned earlier, if considering
ULAs, give careful thought to how well it is supported, especially in
multiple address and multicast scenarios, and assess the strength of
the requirement for ULA.[I-D.ietf-v6ops-ula-usage-recommendations]
provides much more detailed analysis and recommendations on the usage
of ULAs.
It should be noted that the use of PI space obviates the need for
using ULAs just in order to achieve multihoming.
It is important to evaluate MTU considerations when adding in IPv6 to It is important to evaluate MTU considerations when adding in IPv6 to
an existing IPv4 network. It is generally desirable to have the IPv6 an 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. If the enterprise
uses tunnelling inside or externally for IPv6 connectivity, then uses transition tunnels inside or externally for IPv6 connectivity,
modification of the MTU on hosts/routers may be needed as mid-stream then modification of the MTU on hosts/routers may be needed as mid-
fragmentation is no longer supported in IPv6. It is preferred that stream fragmentation is no longer supported in IPv6. It is preferred
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
skipping to change at page 19, line 26 skipping to change at page 19, line 41
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).
In order to protect the networking devices, it is advised to In order to protect the networking devices, it is advised to
implement control plane policing as per [RFC6192]. implement control plane policing as per [RFC6192].
The potential NDP cache exhaustion attack (see [RFC6538]) can be The potential NDP cache exhaustion attack (see [RFC6583]) can be
mitigated by two techniques: mitigated by two techniques:
o Good NDP implementation with memory utilization limits as well as o Good NDP implementation with memory utilization limits as well as
rate-limiters and prioritization of requests. rate-limiters and prioritization of requests.
o Or, as the external deployment usually involves just a couple of o Or, as the external deployment usually involves just a couple of
exposed statically configured IPv6 addresses (virtual addresses of exposed statically configured IPv6 addresses (virtual addresses of
web, email, and DNS servers), then it is straightforward to build web, email, and DNS servers), then it is straightforward to build
an ingress ACL allowing traffic for those addresses and denying an ingress ACL allowing traffic for those addresses and denying
traffic to any other addresses. This actually prevents the attack traffic to any other addresses. This actually prevents the attack
as a packet for a random destination will be dropped and will as a packet for a random destination will be dropped and will
never trigger a neighbor resolution. never trigger a neighbor resolution.
3.3. Monitoring 3.3. Monitoring
Monitoring the use of the Internet connectivity should be done for Monitoring the use of the Internet connectivity should be done for
IPv6 as it is done for IPv4. This includes the use of IP Flow IPv6 as it is done for IPv4. This includes the use of IP Flow
Information eXport (IPFIX) [RFC5102] to detect abnormal traffic Information eXport (IPFIX) [RFC5102] to report abnormal traffic
patterns (such as port scanning, SYN-flooding) and SNMP MIB [RFC4293] patterns (such as port scanning, SYN-flooding, related IP source
(another way to detect abnormal bandwidth utilization). Where using addresses) from monitoring tools and evaluating data read from SNMP
Netflow, version 9 is required for IPv6 support. MIBs [RFC4293] (some of which also enable the detection of abnormal
bandwidth utilization). Where Netflow is used, version 9 is required
for IPv6 support.
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 dual-stack on all devices but this may
seem too time-consuming and too risky. seem too time-consuming and too risky.
Operators have used the following approaches 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
skipping to change at page 21, line 8 skipping to change at page 21, line 29
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-
stack when you can, tunnel when you must". Dual-stacking allows a stack when you can, tunnel when you must". Dual-stacking allows a
more robust, production-quality IPv6 network than is typically more robust, production-quality IPv6 network than is typically
facilitated by internal use of tunnels that are harder to facilitated by internal use of transition tunnels that are harder to
troubleshoot and support, and that may introduce scalability and troubleshoot and support, and that may introduce scalability and
performance issues. Tunnels may of course still be used in performance issues. Tunnels may of course still be used in
production networks, but their use needs to be carefully considered, production networks, but their use needs to be carefully considered,
e.g. where the tunnel may be run through a security or filtering e.g. where the transition tunnel may be run through a security or
device. Tunnels do also provide a means to experiment with IPv6 and filtering device. Tunnels do also provide a means to experiment with
gain some operational experience with the protocol. [RFC4213] IPv6 and gain some operational experience with the protocol.
describes various transition mechanisms in more detail. [RFC4213] describes various transition mechanisms in more detail.
[I-D.templin-v6ops-isops] suggests operational guidance when using [RFC6964] suggests operational guidance when using ISATAP tunnels
ISATAP tunnels [RFC5214], though we would recommend use of dual-stack [RFC5214], though we would recommend use of dual-stack wherever
wherever possible. possible.
4.1. Security 4.1. Security
IPv6 must be deployed in a secure way. This means that all existing IPv6 must be deployed in a secure way. This means that all existing
IPv4 security policies must be extended to support IPv6; IPv6 IPv4 security policies must be extended to support IPv6; IPv6
security policies will be the IPv6 equivalent of the existing IPv4 security policies will be the IPv6 equivalent of the existing IPv4
ones (taking into account the difference for ICMPv6 [RFC4890]). As ones (taking into account the difference for ICMPv6 [RFC4890]). As
in IPv4, security policies for IPv6 will be enforced by firewalls, in IPv4, security policies for IPv6 will be enforced by firewalls,
ACL, IPS, VPN, and so on. ACL, IPS, VPN, and so on.
skipping to change at page 21, line 40 skipping to change at page 22, line 13
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 But the major issue is probably linked to all threats against
Neighbor Discovery. This means, for example, that the internal Neighbor Discovery. This means, for example, that the internal
network at the access layer (where hosts connect to the network over network at the access layer (where hosts connect to the network over
wired or wireless) should implement RA-guard [RFC6105] and the wired or wireless) should implement RA-guard [RFC6105] and the
techniques being specified by SAVI WG [I-D.ietf-savi-threat-scope]; techniques being specified by SAVI WG [RFC6959]; see also
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 22, line 44 skipping to change at page 23, line 18
Dynamic Host Configuration Protocol for IPv6 (DHCPv6), [RFC3315], or Dynamic Host Configuration Protocol for IPv6 (DHCPv6), [RFC3315], or
a combination thereof. Each option has advantages and disadvantages, a combination thereof. Each option has advantages and disadvantages,
and the choice will ultimately depend on the operational policies and the choice will ultimately depend on the operational policies
that guide each enterprise's network design. For example, if an that guide each enterprise's network design. For example, if an
enterprise is looking for ease of use, rapid deployment, and less enterprise is looking for ease of use, rapid deployment, and less
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 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, networks for other configuration information, e.g. NTP servers or, in
in the absence of support for DNS resolvers in RAs [RFC6106], DNS the absence of support for DNS resolvers in RAs [RFC6106], DNS
resolver information. resolver information.
4.3. End user devices 4.3. End user devices
Most operating systems (OSes) that are loaded on workstations and Most operating systems (OSes) that are loaded on workstations and
laptops in a typical enterprise support IPv6 today. However, there laptops in a typical enterprise support IPv6 today. However, there
are various out-of-the-box nuances that one should be mindful about. are various out-of-the-box nuances that one should be mindful about.
For example, the default behavior of OSes vary; some may have IPv6 For example, the default behavior of OSes vary; some may have IPv6
turned off by default, some may only have certain features such as turned off by default, some may only have certain features such as
privacy extensions to IPv6 addresses (RFC 4941) turned off while privacy extensions to IPv6 addresses (RFC 4941) turned off while
others have IPv6 fully enabled. Further, even when IPv6 is enabled, others have IPv6 fully enabled. Further, even when IPv6 is enabled,
the choice of which address is used may be subject to Source Address the choice of which address is used may be subject to Source Address
Selection (RFC 6724) and Happy Eyeballs (RFC 6555). Therefore, it is Selection (RFC 6724) and Happy Eyeballs (RFC 6555). Therefore, it is
advised that enterprises investigate the default behavior of their advised that enterprises investigate the default behavior of their
installed OS base and account for it during the Inventory phases of installed OS base and account for it during the Inventory phases of
their IPv6 preparations. Furthermore, some OSes may have tunneling their IPv6 preparations. Furthermore, some OSes may have some
mechanisms turned on by default and in such cases it is recommended transition tunneling mechanisms turned on by default and in such
to administratively shut down such interfaces unless required. cases it is recommended to administratively shut down such interfaces
unless required.
It is important to note that it is recommended that IPv6 be deployed It is important to note that it is recommended that IPv6 be deployed
at the network and system infrastructure level before it is rolled at the network and system infrastructure level before it is rolled
out to end user devices; ensure IPv6 is running and routed on the out to end user devices; ensure IPv6 is running and routed on the
wire, and secure and correctly monitored, before exposing IPv6 to end wire, and secure and correctly monitored, before exposing IPv6 to end
users. users.
Smartphones and tablets are poised to become one of the major Smartphones and tablets are poised to become one of the major
consumers of IP addresses and enterprises, and should be ready to consumers of IP addresses and enterprises, and should be ready to
support IPv6 on various networks that serve such devices. In support IPv6 on various networks that serve such devices. In
general, support for IPv6 in these devices, albeit in its infancy, general, support for IPv6 in these devices, albeit in its infancy,
has been steadily rising. Most of the leading smartphone OSes have has been steadily rising. Most of the leading smartphone OSes have
some level of support for IPv6. However, the level of configurable some level of support for IPv6. However, the level of configurable
options are mostly at a minimum and are not consistent across all options are mostly at a minimum and are not consistent across all
platforms. Also, it is fairly common to find IPv6 support on the Wi- 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. 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 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 it may be device-related. An IPv6-enabled enterprise Wi-Fi network
will allow the majority of these devices to connect via IPv6. Much 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 work is still being done to bring the full IPv6 feature set across
all interfaces (802.11, 3G, LTE, etc.) and platforms. 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 in peripheral equipment such as printers, IP cameras,
etc., has been steadily rising as well, although at a much slower etc., has been steadily rising as well, although at a much slower
pace than traditional OSes and smartphones. Most newer devices are pace than traditional OSes and smartphones. Most newer devices are
coming out with IPv6 support but there is still a large installed coming out with IPv6 support but there is still a large installed
base of legacy peripheral devices that might need IPv4 for some time base of legacy peripheral devices that might need IPv4 for some time
to come. The audit phase mentioned earlier will make it easier for to come. The audit phase mentioned earlier will make it easier for
enterprises to plan for equipment upgrades, in line with their enterprises to plan for equipment upgrades, in line with their
corporate equipment refresh cycle. corporate equipment refresh cycle.
skipping to change at page 25, line 14 skipping to change at page 25, line 38
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. initiate communications to an IPv4-only server. At the enterprise
level, operating NAT64 and DNS64 services for heavy usage may have
significant practical implications.
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 25, line 39 skipping to change at page 26, line 17
example, [I-D.xli-behave-divi] describes limitations with the current example, [I-D.xli-behave-divi] describes limitations with the current
stateless translation, such as IPv4 address sharing and application stateless translation, such as IPv4 address sharing and application
layer gateway (ALG) problems, and presents the concept and layer gateway (ALG) problems, and presents the concept and
implementation of dual-stateless IPv4/IPv6 translation (dIVI) to implementation of dual-stateless IPv4/IPv6 translation (dIVI) to
address those issues. address those issues.
It is worth noting that for IPv6-only access networks that use It is worth noting that for IPv6-only access networks that use
technologies such as NAT64, the more content providers (and technologies such as NAT64, the more content providers (and
enterprises) that make their content available over IPv6, the less enterprises) that make their content available over IPv6, the less
the requirement to apply NAT64 to traffic leaving the access network. the requirement to apply NAT64 to traffic leaving the access network.
This particular point is important for enterprises which may start
their IPv6 deployment well into the global IPv6 transition. As time
progresses, and given the current growth in availability of IPv6
content, IPv6-only operation using NAT64 to manage some flows will
become less expensive to run versus the traditional NAT44 deployments
since only IPv6 to IPv4 flows need translation. [RFC6883] provides
guidance and suggestions for Internet Content Providers and
Application Service Providers in this context.
Enterprises should also be aware that networks may be subject to
future convergence with other networks (i.e. mergers, acquisitions,
etc). An enterprise considering IPv6-only operation may need to be
aware that additional transition technologies and/or connectivity
strategies may be required depending on the level of IPv6 readiness
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 [I-D.ietf-v6ops-icp-guidance], which includes a can be found in [RFC6883], which includes a dedicated section on
dedicated section on CDNs. An enterprise that relies on CDN to CDNs. An enterprise that relies on CDN to deliver a 'better'
deliver a 'better' e-commerce experience needs to ensure that their e-commerce experience needs to ensure that their CDN provider also
CDN provider also supports IPv4/IPv6 traffic selection so that they supports IPv4/IPv6 traffic selection so that they can ensure 'best'
can ensure 'best' access to the content. access to the content.
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.lopez-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 natively since the early 2000's. Universities are a natural place for
for IPv6 deployment to be considered at an early stage, perhaps IPv6 deployment to be considered at an early stage, perhaps compared
compared to other enterprises, as they are involved by their very to other enterprises, as they are involved by their very nature in
nature in research and education. research and education.
Campus networks can deploy IPv6 at their own pace; their is no need Campus networks can deploy IPv6 at their own pace; their 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 31, line 12 skipping to change at page 31, line 51
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011. Translation", RFC 6296, June 2011.
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
"Logging Recommendations for Internet-Facing Servers", BCP "Logging Recommendations for Internet-Facing Servers", BCP
162, RFC 6302, June 2011. 162, RFC 6302, June 2011.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, December 2011. Requirements", RFC 6434, December 2011.
[RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
(HIP) Experiment Report", RFC 6538, March 2012. Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
[RFC6555] , "Happy Eyeballs: Success with Dual-Stack Hosts", . [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for
Renumbering IPv6 Hosts with Static Addresses in Enterprise
Networks", RFC 6866, February 2013.
[RFC6583] , "Operational Neighbor Discovery Problems", . [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and
Methods", RFC 6879, February 2013.
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content Providers and Application Service Providers", RFC
6883, March 2013.
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address
Validation Improvement (SAVI) Threat Scope", RFC 6959, May
2013.
[RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in
IPv4 Sites Using the Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)", RFC 6964, May 2013.
[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-05 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-05
(work in progress), June 2013. (work in progress), June 2013.
[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-00 (work in progress), October 2012. eduroam-01 (work in progress), July 2013.
[I-D.ietf-savi-threat-scope]
McPherson, D., Baker, F., and J. Halpern, "SAVI Threat
Scope", draft-ietf-savi-threat-scope-08 (work in
progress), April 2013.
[I-D.lopez-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- "IPv6 Operational Guidelines for Datacenters", draft-ietf-
lopez-v6ops-dc-ipv6-04 (work in progress), February 2013. v6ops-dc-ipv6-00 (work in progress), August 2013.
[I-D.templin-v6ops-isops]
Templin, F., "Operational Guidance for IPv6 Deployment in
IPv4 Sites using ISATAP", draft-templin-v6ops-isops-19
(work in progress), April 2013.
[I-D.carpenter-6man-ext-transmit]
Carpenter, B. and S. Jiang, "Transmission of IPv6
Extension Headers", draft-carpenter-6man-ext-transmit-02
(work in progress), February 2013.
[I-D.ietf-6renum-enterprise]
Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations and
Methods", draft-ietf-6renum-enterprise-06 (work in
progress), January 2013.
[I-D.ietf-6renum-static-problem] [I-D.ietf-6man-ext-transmit]
Carpenter, B. and S. Jiang, "Problem Statement for Carpenter, B. and S. Jiang, "Transmission and Processing
Renumbering IPv6 Hosts with Static Addresses in Enterprise of IPv6 Extension Headers", draft-ietf-6man-ext-
Networks", draft-ietf-6renum-static-problem-03 (work in transmit-04 (work in progress), September 2013.
progress), December 2012.
[I-D.ietf-v6ops-design-choices] [I-D.ietf-v6ops-design-choices]
Matthews, P., "Design Choices for IPv6 Networks", draft- Matthews, P., "Design Choices for IPv6 Networks", draft-
ietf-v6ops-design-choices-00 (work in progress), February ietf-v6ops-design-choices-00 (work in progress), February
2013. 2013.
[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-02 (work in progress), February 2013. opsec-v6-03 (work in progress), July 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-01 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-02 (work in
progress), April 2013. progress), July 2013.
[I-D.ietf-opsec-ipv6-implications-on-ipv4-nets] [I-D.ietf-opsec-ipv6-implications-on-ipv4-nets]
Gont, F. and W. Liu, "Security Implications of IPv6 on Gont, F. and W. Liu, "Security Implications of IPv6 on
IPv4 Networks", draft-ietf-opsec-ipv6-implications-on- IPv4 Networks", draft-ietf-opsec-ipv6-implications-on-
ipv4-nets-05 (work in progress), July 2013. ipv4-nets-05 (work in progress), July 2013.
[I-D.ietf-v6ops-ra-guard-implementation] [I-D.ietf-v6ops-ra-guard-implementation]
Gont, F., "Implementation Advice for IPv6 Router Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra- Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra-
guard-implementation-07 (work in progress), November 2012. guard-implementation-07 (work in progress), November 2012.
[I-D.ietf-v6ops-icp-guidance]
Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content and Application Service Providers", draft-ietf-
v6ops-icp-guidance-05 (work in progress), January 2013.
[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-01 (work in progress), February 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., Jiang, S., and C. Byrne, "Recommendations of
Using Unique Local Addresses", draft-ietf-v6ops-ula-usage- Using Unique Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-00 (work in progress), May 2013. recommendations-00 (work in progress), May 2013.
[SMURF] , "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service [SMURF] , "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service
Attacks", , Attacks", ,
<http://www.cert.org/advisories/CA-1998-01.html>. <http://www.cert.org/advisories/CA-1998-01.html>.
skipping to change at page 33, line 43 skipping to change at page 34, line 30
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
Rogers Communications Dyn Inc
8200 Dixie Road 150 Dow Street
Brampton, Ontario Manchester, NH
Canada US
Email: victor@jvknet.com
Email: victor.kuarsingh@rci.rogers.com
Yanick Pouffary Yanick Pouffary
Hewlett Packard Hewlett Packard
950 Route Des Colles 950 Route Des Colles
Sophia-Antipolis 06901 Sophia-Antipolis 06901
France France
Email: Yanick.Pouffary@hp.com Email: Yanick.Pouffary@hp.com
Eric Vyncke Eric Vyncke
Cisco Systems Cisco Systems
De Kleetlaan 6a De Kleetlaan 6a
Diegem 1831 Diegem 1831
Belgium Belgium
Phone: +32 2 778 4677 Phone: +32 2 778 4677
Email: evyncke@cisco.com Email: evyncke@cisco.com
 End of changes. 57 change blocks. 
155 lines changed or deleted 169 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/