draft-ietf-v6ops-enterprise-incremental-ipv6-02.txt   draft-ietf-v6ops-enterprise-incremental-ipv6-03.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: August 29, 2013 University of Southampton Expires: January 15, 2014 University of Southampton
L. Howard L. Howard
Time Warner Cable Time Warner Cable
V. Kuarsingh V. Kuarsingh
Rogers Communications Rogers Communications
Y. Pouffary Y. Pouffary
Hewlett Packard Hewlett Packard
E. Vyncke E. Vyncke
Cisco Systems Cisco Systems
February 25, 2013 July 14, 2013
Enterprise IPv6 Deployment Guidelines Enterprise IPv6 Deployment Guidelines
draft-ietf-v6ops-enterprise-incremental-ipv6-02 draft-ietf-v6ops-enterprise-incremental-ipv6-03
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 potentially 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 August 29, 2013. This Internet-Draft will expire on January 15, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . . 4 1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 4
1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . . 5 1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . 4
1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 5 1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 4
2. Preparation and Assessment Phase . . . . . . . . . . . . . . . 7 2. Preparation and Assessment Phase . . . . . . . . . . . . . . 6
2.1. Program Planning . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . 9 2.2.2. Applications readiness assessment . . . . . . . . . . 8
2.2.3. Importance of readiness validation and testing . . . . 10 2.2.3. Importance of readiness validation and testing . . . 9
2.3. Training . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . 12 2.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 11
2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . . 14 2.6. Address Plan . . . . . . . . . . . . . . . . . . . . . . 13
2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . . 16 2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 15
3. External Phase . . . . . . . . . . . . . . . . . . . . . . . . 17 3. External Phase . . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . . 21 4. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Security . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Network Infrastructure . . . . . . . . . . . . . . . . . . 22 4.2. Network Infrastructure . . . . . . . . . . . . . . . . . 21
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
6. Considerations For Specific Enterprises . . . . . . . . . . . 26 5. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 26 6. Considerations For Specific Enterprises . . . . . . . . . . . 25
6.2. Data Center Virtualization . . . . . . . . . . . . . . . . 26 6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 25
6.3. University Campus Networks . . . . . . . . . . . . . . . . 26 6.2. Data Center Virtualization . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6.3. University Campus Networks . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
10. Informative References . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 10. Informative References . . . . . . . . . . . . . . . . . . . 27
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
computing devices and related peripherals, a server network, computing devices and related peripherals, a server network,
skipping to change at page 5, line 29 skipping to change at page 4, line 39
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,
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
[I-D.ietf-opsec-ipv6-implications-on-ipv4-nets]). [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
skipping to change at page 8, line 45 skipping to change at page 8, line 7
expanding the scope increases risk to any other part of the project. expanding the scope increases risk to any other part of the project.
As projects are completed, the project manager will confirm that work As projects are completed, the project manager will confirm that work
has been completed, often by means of seeing a completed test plan, 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 and will report back to the project sponsor on completed parts of the
project. A good project manager will remember to thank the people project. A good project manager will remember to thank the people
who executed the project. who executed the project.
2.2. Inventory Phase 2.2. Inventory Phase
To comprehend the scope of the inventory phase we recommended To comprehend the scope of the inventory phase we recommend dividing
dividing the problem space in two: network infrastructure readiness the problem space in two: network infrastructure readiness and
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 is an important step as it will
help identify the effort required to move to an infrastructure that help identify the effort required to move to an infrastructure that
supports IPv6 with the same functional service capabilities as the supports IPv6 with the same functional service capabilities as the
existing IPv4 network. This may also require a feature comparison existing IPv4 network. This may also require a feature comparison
and gap analysis between IPv4 and IPv6 functionality on the network and gap analysis between IPv4 and IPv6 functionality on the network
equipment and software. equipment and software.
skipping to change at page 9, line 47 skipping to change at page 9, line 9
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 recommend 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
skipping to change at page 12, line 41 skipping to change at page 12, line 5
from switch and router devices to provide address accountability; from switch and router devices to provide address accountability;
this approach has been shown to work, though it can involve gathering this approach has been shown to work, though it can involve gathering
significantly more address data than in equivalent IPv4 networks. An significantly more address data than in equivalent IPv4 networks. An
alternative is to try to prevent the use of privacy extension alternative is to try to prevent the use of privacy extension
addresses by enforcing the use of DHCPv6, such that hosts only get addresses by enforcing the use of DHCPv6, such that hosts only get
addresses assigned by a DHCPv6 server. This can be done by addresses assigned by a DHCPv6 server. This can be done by
configuring routers to set the M-bit in Router Advertisements, configuring routers to set the M-bit in Router Advertisements,
combined with all advertised prefixes being included without the combined with all advertised prefixes being included without the
A-bit set (to prevent the use of stateless auto-configuration). This A-bit set (to prevent the use of stateless auto-configuration). This
technique of course requires that all hosts support stateful DHCPv6. technique of course requires that all hosts support stateful DHCPv6.
It is important to note that not all operating systems exhibit the
same behavior when processing RAs with the M-Bit set. The varying OS
behavior is related to the lack of prescriptive definition around the
A, M and O-bits within the ND protocol.
[I-D.liu-bonica-dhcpv6-slaac-problem] provides a much more 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 [RFC5095]). This topic is discussed further in
[I-D.carpenter-6man-ext-transmit]. [I-D.carpenter-6man-ext-transmit].
skipping to change at page 13, line 26 skipping to change at page 12, line 45
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. [I-D.ietf-savi-threat-scope], which is similar to the
protection given by dynamic ARP monitoring in IPv4. Other DoS protection given by dynamic ARP monitoring in IPv4. Other DoS
vulnerabilities are related to NDP cache exhaustion, and mitigation vulnerabilities are related to NDP cache exhaustion, and mitigation
techniques can be found in ([RFC6583]). techniques can be 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 14, line 24 skipping to change at page 13, line 43
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 instead of Globally Unique the requirement for ULA. If using ULAs in a ULA-only deployment
model, instead of using them in conjunction with Globally Unique
Addressing for hosts, note that Network Prefix Translation will be Addressing for hosts, note that Network Prefix Translation will be
required [RFC6296] for Internet based communication; the implications required [RFC6296] for Internet based communication; the implications
of which must be well understood before deploying. 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 26 skipping to change at page 14, line 50
addressing on corporate LAN segments. DHCPv6 allows for the addressing on corporate LAN segments. DHCPv6 allows for the
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
to get host DNS records updated. In a traditional IPv4 network, the
two commonly used methods are to either have the host send DNS
updates itself or have the DHCPv4 server update DNS records. The
former implies that there is sufficient trust between the hosts and
the DNS server while the latter implies a slightly more controlled
environment where only DHCP servers are trusted to make these
updates. If the enterprise uses the first model, then SLAAC is a
perfectly valid option to assign addresses to end systems. However,
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. 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.
[I-D.ietf-6renum-static-problem] [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]).
skipping to change at page 15, line 51 skipping to change at page 15, line 38
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.
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 the tools and processing
logic. logic.
skipping to change at page 18, line 22 skipping to change at page 18, line 9
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 tunnelled IPv6 connectivity. There are
IPv6 transit providers which provide robust tunnelled IPv6 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 tunneling mechanism used, and to consider that it
will have higher latency than native IPv4 or IPv6, and may have other will have higher latency than native IPv4 or IPv6, and may have other
problems, e.g. related to MTUs. problems, e.g. related to MTUs.
The use of ULAs may provide additional flexibility when an enterprise The use of ULAs may provide some flexibility when an enterprise is
is using PA space, by providing an independent local prefix for using PA space from two or more providers in a multihoming scenario,
internal use, while using the PA prefix externally in conjunction by providing an independent local prefix for internal use, while
with NPTv6 [RFC6296]. Many enterprises today are used to using IPv4 using the PA prefix for external communication in conjunction with
host-based NAT, and indeed may choose to use this model even when NPTv6 at the egress [RFC6296]. While NPTv6 can provide for
global IPv4 address space is available. NPTv6 instead performs simplified renumbering in certain scenarios, as described in
stateless prefix-based NAT, mapping from an external global prefix to [I-D.ietf-6renum-enterprise], it must be noted that many of the well-
(usually) an internal ULA prefix. Such mappings can be used with known issues with NAT still apply, in particular handling IPv6
multiple prefixes in multihoming scenarios, rather than using both addresses embedded in payloads. As mentioned earlier, if considering
ISP's global prefixes internally, with hosts receiving an IPv6 ULAs, give careful thought to how well it is supported, especially in
address from each prefix (and then needing to ensure the correct multiple address and multicast scenarios, and assess the strength of
source address is used to route traffic out of the correct egress). the requirement for ULA.[I-D.ietf-v6ops-ula-usage-recommendations]
While NPTv6 can provide for simplified renumbering in certain provides much more detailed analysis and recommendations on the usage
scenarios, as described in [I-D.ietf-6renum-enterprise], it must be of ULAs.
noted that many of the well-known issues with NAT still apply, in
particular handling IPv6 addresses embedded in payloads. 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 tunnelling inside or externally for IPv6 connectivity, then
modification of the MTU on hosts/routers may be needed as mid-stream modification of the MTU on hosts/routers may be needed as mid-stream
fragmentation is no longer supported in IPv6. It is preferred that fragmentation is no longer supported in IPv6. It is preferred that
pMTUD is used to optimize the MTU, so erroneous filtering of the 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
skipping to change at page 23, line 49 skipping to change at page 23, line 35
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 platforms. Also, it is fairly common to find IPv6 support on the Wi-
Wi-Fi connection alone and not on the radio interface in these Fi connection alone and not on the radio interface in these devices.
devices. This is sometimes due to the radio network not being IPv6 This is sometimes due to the radio network not being IPv6 ready, or
ready, or it may be device-related. An IPv6-enabled enterprise Wi-Fi it may be device-related. An IPv6-enabled enterprise Wi-Fi network
network will allow the majority of these devices to connect via IPv6. will allow the majority of these devices to connect via IPv6. Much
Much work is still being done to bring the full IPv6 feature set work is still being done to bring the full IPv6 feature set across
across all interfaces (802.11, 3G, LTE, etc.) and platforms. all interfaces (802.11, 3G, LTE, etc.) and platforms.
IPv6 support in peripheral equipment such as printers, IP cameras, IPv6 support in peripheral equipment such as printers, IP cameras,
etc., has been steadily rising as well, although at a much slower 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 24, line 48 skipping to change at page 24, line 35
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 on gradually deprecating IPv4 from the dual-stack network. In
some extreme cases, deploying dual-stack networks may not even be a some extreme cases, deploying dual-stack networks may not even be a
viable option for very large enterprises due to the RFC 1918 address viable option for very large enterprises due to the RFC 1918 address
space not being large enough to support the network's growth. In space not being large enough to support the network's growth. In
such cases, deploying IPv6-only networks might be the only choice such cases, deploying IPv6-only networks might be the only choice
available to sustain network growth. In other cases, there may be available to sustain network growth. In other cases, there may be
elements of an otherwise dual-stack network that may be run IPv6- elements of an otherwise dual-stack network that may be run
only. 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 fairly trivial. However, in
the current environment, given that IPv4 is the dominant protocol on the current environment, given that IPv4 is the dominant protocol on
the Internet, an IPv6-only node most likely needs to talk to an IPv4- the Internet, an IPv6-only node most likely needs to talk to an
only node on the Internet. It is therefore important to provide such IPv4-only node on the Internet. It is therefore important to provide
nodes with a translation mechanism to ensure communication between such nodes with a translation mechanism to ensure communication
nodes configured with different address families. As [RFC6144] between nodes configured with different address families. As
points out, it is important to look at address translation as a [RFC6144] points out, it is important to look at address translation
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,
skipping to change at page 27, line 32 skipping to change at page 27, line 17
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 Chris Grundemann, Ray Hunter, Brian
skipping to change at page 28, line 16 skipping to change at page 27, line 46
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
address for transmission on Ethernet hardware", STD 37, address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC1687] Fleischman, E., "A Large Corporate User's View of IPng", [RFC1687] Fleischman, E., "A Large Corporate User's View of IPng",
RFC 1687, August 1994. RFC 1687, August 1994.
[RFC1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, [RFC1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817, August
August 1995. 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets", BCP
BCP 5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for
the Internet Protocol using SMIv2", RFC 2011, the Internet Protocol using SMIv2", RFC 2011, November
November 1996. 1996.
[RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, [RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January
January 1997. 1997.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address", RFC
RFC 3956, November 2004. 3956, November 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition", Castro, "Application Aspects of IPv6 Transition", RFC
RFC 4038, March 2005. 4038, March 2005.
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
June 2005. June 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
skipping to change at page 29, line 47 skipping to change at page 29, line 28
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", RFC 4890, May 2007. ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095, December
December 2007. 2007.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export", Meyer, "Information Model for IP Flow Information Export",
RFC 5102, January 2008. RFC 5102, January 2008.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC
RFC 5157, March 2008. 5157, March 2008.
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July
July 2008. 2008.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008. March 2008.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
and C. Hahn, "IPv6 Unicast Address Assignment and C. Hahn, "IPv6 Unicast Address Assignment
Considerations", RFC 5375, December 2008. Considerations", RFC 5375, December 2008.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
skipping to change at page 31, line 24 skipping to change at page 31, line 6
L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
Router Links", RFC 6164, April 2011. Router Links", RFC 6164, April 2011.
[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the
Router Control Plane", RFC 6192, March 2011. Router Control Plane", RFC 6192, March 2011.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix [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", "Logging Recommendations for Internet-Facing Servers", BCP
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 [RFC6538] Henderson, T. and A. Gurtov, "The Host Identity Protocol
(HIP) Experiment Report", RFC 6538, March 2012. (HIP) Experiment Report", RFC 6538, 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". [RFC6555] , "Happy Eyeballs: Success with Dual-Stack Hosts", .
[RFC6583] "Operational Neighbor Discovery Problems". [RFC6583] , "Operational Neighbor Discovery Problems", .
[I-D.xli-behave-divi] [I-D.xli-behave-divi]
Shang, W., Li, X., Zhai, Y., and C. Bao, "dIVI: Dual- Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-
Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-04 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-05
(work in progress), October 2011. (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", architecture for network roaming", draft-wierenga-ietf-
draft-wierenga-ietf-eduroam-00 (work in progress), eduroam-00 (work in progress), October 2012.
October 2012.
[I-D.ietf-savi-threat-scope] [I-D.ietf-savi-threat-scope]
McPherson, D., Baker, F., and J. Halpern, "SAVI Threat McPherson, D., Baker, F., and J. Halpern, "SAVI Threat
Scope", draft-ietf-savi-threat-scope-06 (work in Scope", draft-ietf-savi-threat-scope-08 (work in
progress), February 2013. progress), April 2013.
[I-D.lopez-v6ops-dc-ipv6] [I-D.lopez-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", "IPv6 Operational Guidelines for Datacenters", draft-
draft-lopez-v6ops-dc-ipv6-04 (work in progress), lopez-v6ops-dc-ipv6-04 (work in progress), February 2013.
February 2013.
[I-D.templin-v6ops-isops] [I-D.templin-v6ops-isops]
Templin, F., "Operational Guidance for IPv6 Deployment in Templin, F., "Operational Guidance for IPv6 Deployment in
IPv4 Sites using ISATAP", draft-templin-v6ops-isops-18 IPv4 Sites using ISATAP", draft-templin-v6ops-isops-19
(work in progress), October 2012. (work in progress), April 2013.
[I-D.carpenter-6man-ext-transmit] [I-D.carpenter-6man-ext-transmit]
Carpenter, B. and S. Jiang, "Transmission of IPv6 Carpenter, B. and S. Jiang, "Transmission of IPv6
Extension Headers", draft-carpenter-6man-ext-transmit-02 Extension Headers", draft-carpenter-6man-ext-transmit-02
(work in progress), February 2013. (work in progress), February 2013.
[I-D.ietf-6renum-enterprise] [I-D.ietf-6renum-enterprise]
Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations and Network Renumbering Scenarios, Considerations and
Methods", draft-ietf-6renum-enterprise-06 (work in Methods", draft-ietf-6renum-enterprise-06 (work in
progress), January 2013. progress), January 2013.
[I-D.ietf-6renum-static-problem] [I-D.ietf-6renum-static-problem]
Carpenter, B. and S. Jiang, "Problem Statement for Carpenter, B. and S. Jiang, "Problem Statement for
Renumbering IPv6 Hosts with Static Addresses in Enterprise Renumbering IPv6 Hosts with Static Addresses in Enterprise
Networks", draft-ietf-6renum-static-problem-03 (work in Networks", draft-ietf-6renum-static-problem-03 (work in
progress), December 2012. progress), December 2012.
[I-D.ietf-v6ops-design-choices] [I-D.ietf-v6ops-design-choices]
Matthews, P., "Design Choices for IPv6 Networks", Matthews, P., "Design Choices for IPv6 Networks", draft-
draft-ietf-v6ops-design-choices-00 (work in progress), ietf-v6ops-design-choices-00 (work in progress), February
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", Security Considerations for IPv6 Networks", draft-ietf-
draft-ietf-opsec-v6-02 (work in progress), February 2013. opsec-v6-02 (work in progress), February 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-00 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-01 (work in
progress), December 2012. progress), April 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", IPv4 Networks", draft-ietf-opsec-ipv6-implications-on-
draft-ietf-opsec-ipv6-implications-on-ipv4-nets-03 (work ipv4-nets-05 (work in progress), July 2013.
in progress), February 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)", Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra-
draft-ietf-v6ops-ra-guard-implementation-07 (work in guard-implementation-07 (work in progress), November 2012.
progress), November 2012.
[I-D.ietf-v6ops-icp-guidance] [I-D.ietf-v6ops-icp-guidance]
Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content and Application Service Providers", Content and Application Service Providers", draft-ietf-
draft-ietf-v6ops-icp-guidance-05 (work in progress), v6ops-icp-guidance-05 (work in progress), January 2013.
January 2013.
[SMURF] "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service [I-D.liu-bonica-dhcpv6-slaac-problem]
Attacks", Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration
Interaction Problem Statement", draft-liu-bonica-dhcpv6
-slaac-problem-01 (work in progress), February 2013.
[I-D.ietf-v6ops-ula-usage-recommendations]
Liu, B., Jiang, S., and C. Byrne, "Recommendations of
Using Unique Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-00 (work in progress), May 2013.
[SMURF] , "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service
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. Google Inc.
1600 Amphitheater Pkwy 1600 Amphitheater Pkwy
Mountain View, California CA 94043 Mountain View, California CA 94043
USA USA
 End of changes. 46 change blocks. 
141 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/