draft-ietf-v6ops-enterprise-incremental-ipv6-04.txt   draft-ietf-v6ops-enterprise-incremental-ipv6-05.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: April 19, 2014 University of Southampton Expires: July 16, 2014 University of Southampton
L. Howard L. Howard
Time Warner Cable Time Warner Cable
V. Kuarsingh V. Kuarsingh
Dyn Inc Dyn Inc
Y. Pouffary Y. Pouffary
Hewlett Packard Hewlett Packard
E. Vyncke E. Vyncke
Cisco Systems Cisco Systems
October 16, 2013 January 12, 2014
Enterprise IPv6 Deployment Guidelines Enterprise IPv6 Deployment Guidelines
draft-ietf-v6ops-enterprise-incremental-ipv6-04 draft-ietf-v6ops-enterprise-incremental-ipv6-05
Abstract Abstract
Enterprise network administrators worldwide are in various stages of Enterprise network administrators worldwide are in various stages of
preparing for or deploying IPv6 into their networks. The preparing for or deploying IPv6 into their networks. The
administrators face different challenges than operators of Internet administrators face different challenges than operators of Internet
access providers, and have reasons for different priorities. The access providers, and have reasons for different priorities. The
overall problem for many administrators will be to offer Internet- overall problem for many administrators will be to offer Internet-
facing services over IPv6, while continuing to support IPv4, and facing services over IPv6, while continuing to support IPv4, and
while introducing IPv6 access within the enterprise IT network. The while introducing IPv6 access within the enterprise IT network. The
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2014. This Internet-Draft will expire on July 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 4 1.1. Enterprise Assumptions . . . . . . . . . . . . . . . . . 4
1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . 4 1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . 4
1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 4 1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 5
2. Preparation and Assessment Phase . . . . . . . . . . . . . . 6 2. Preparation and Assessment Phase . . . . . . . . . . . . . . 6
2.1. Program Planning . . . . . . . . . . . . . . . . . . . . 6 2.1. Program Planning . . . . . . . . . . . . . . . . . . . . 6
2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 8 2.2. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 10
2.4.1. IPv6 is no more secure than IPv4 . . . . . . . . . . 10 2.4.1. IPv6 is no more secure than IPv4 . . . . . . . . . . 10
2.4.2. Similarities between IPv6 and IPv4 security . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . 16 2.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . 20
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 5. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Considerations For Specific Enterprises . . . . . . . . . . . 26 6. Considerations For Specific Enterprises . . . . . . . . . . . 26
6.1. Content Delivery Networks . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Informative References . . . . . . . . . . . . . . . . . . . 28 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
skipping to change at page 7, line 33 skipping to change at page 7, line 36
the scope of projects, the schedule is often affected. For instance, the scope of projects, the schedule is often affected. For instance,
a major systems upgrade may take a year to complete, where just a major systems upgrade may take a year to complete, where just
patching existing systems may take only a few months. Understanding patching existing systems may take only a few months. Understanding
and evaluating these trade-offs are why a project manager is and evaluating these trade-offs are why a project manager is
important. important.
The deployment of IPv6 will not generally stop all other technology The deployment of IPv6 will not generally stop all other technology
work. Once IPv6 has been identified as an important initiative, all work. Once IPv6 has been identified as an important initiative, all
projects will need to evaluate their ability to support IPv6. If projects will need to evaluate their ability to support IPv6. If
expansions or new deployments fail to include IPv6, then additional expansions or new deployments fail to include IPv6, then additional
work will be required after all initial IPv6 has been completed. It work will be required after all initial IPv6 has been completed.
may not be possible to delay regular projects for IPv6, if their IPv6 Having a purchasing policy that no hardware or software will be
support is dependent on network elements that have not yet been purchased that is not trivially upgradeable to IPv6 will help
upgraded, but the projects need to include a return to IPv6 support minimizing such future work.It may not be possible to delay regular
in their eventual timeline. projects for IPv6, if their IPv6 support is dependent on network
elements that have not yet been upgraded, but the projects need to
include a return to IPv6 support in their eventual timeline.
It is very common for assessments to continue in some areas even as It is very common for assessments to continue in some areas even as
execution of the project begins in other areas. This is fine, as execution of the project begins in other areas. This is fine, as
long as recommendations in other parts of this document are long as recommendations in other parts of this document are
considered, especially regarding security (for instance, one should considered, especially regarding security (for instance, one should
not deploy IPv6 on a system before security has been evaluated). The not deploy IPv6 on a system before security has been evaluated). The
project manager will need to continue monitoring the progress of project manager will need to continue monitoring the progress of
discrete projects and tasks, to be aware of changes in schedule, discrete projects and tasks, to be aware of changes in schedule,
budget, or scope. "Feature creep" is common, where engineers or budget, or scope. "Feature creep" is common, where engineers or
management wish to add other features while IPv6 development or management wish to add other features while IPv6 development or
skipping to change at page 12, line 28 skipping to change at page 12, line 31
A, M and O-bits within the ND protocol. A, M and O-bits within the ND protocol.
[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 [RFC7045].
[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 16, line 4 skipping to change at page 15, line 40
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 If using ULAs, it is important to note that AAAA and PTR records for
for ULA are not recommended to be installed in the global DNS. ULA are not recommended to be installed in the global DNS.
Similarly, reverse (address-to-name) queries for ULA must not be sent Similarly, reverse (address-to-name) queries for ULA MUST NOT be sent
to name servers outside of the organization, due to the load that to name servers outside of the organization, due to the load that
such queries would create for the authoritative name servers for the such queries would create for the authoritative name servers for the
ip6.arpa zone. For more details please refer to section 4.4 of ip6.arpa zone. For more details please refer to section 4.4 of
[RFC4193]. [RFC4193].
Enterprise networks more and more include virtual networks where a Enterprise networks more and more include virtual networks where a
single physical node may host many virtualized addressable devices. single physical node may host many virtualized addressable devices.
It is imperative that the addressing plans assigned to these virtual It is imperative that the addressing plans assigned to these virtual
networks and devices be consistent and non-overlapping with the networks and devices be consistent and non-overlapping with the
addresses assigned to real networks and nodes. For example, a addresses assigned to real networks and nodes. For example, a
skipping to change at page 17, line 32 skipping to change at page 17, line 20
always necessary to support local IPv6 addressing and connectivity. always necessary to support local IPv6 addressing and connectivity.
Operations such as SNMP MIB polling can occur over IPv4 transport Operations such as SNMP MIB polling can occur over IPv4 transport
while seeking responses related to IPv6 information. Where this may while seeking responses related to IPv6 information. Where this may
seem advantageous to some, it should be noted that without local IPv6 seem advantageous to some, it should be noted that without local IPv6
connectivity, the management system may not be able to perform all connectivity, the management system may not be able to perform all
expected functions - such as reachability and service checks. expected functions - such as reachability and service checks.
Organizations should be aware that changes to older IPv4-only SNMP Organizations should be aware that changes to older IPv4-only SNMP
MIB specifications have been made by the IETF related to legacy MIB specifications have been made by the IETF related to legacy
operation in [RFC2096] and [RFC2011]. Updated specifications are now operation in [RFC2096] and [RFC2011]. Updated specifications are now
available in [RFC4296] and [RFC4293] which modified the older MIB available in [RFC4292] and [RFC4293] which modified the older MIB
framework to be IP protocol agnostic, supporting both IPv4 and IPv6. framework to be IP protocol agnostic, supporting both IPv4 and IPv6.
Polling systems will need to be upgraded to support these updates as Polling systems will need to be upgraded to support these updates as
well as the end stations which are polled. well as the end stations which are polled.
3. External Phase 3. External Phase
The external phase for enterprise IPv6 adoption covers topics which The external phase for enterprise IPv6 adoption covers topics which
deal with how an organization connects its infrastructure to the deal with how an organization connects its infrastructure to the
external world. These external connections may be toward the external world. These external connections may be toward the
Internet at large, or to other networks. The external phase covers Internet at large, or to other networks. The external phase covers
skipping to change at page 20, line 17 skipping to change at page 19, line 47
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 report abnormal traffic Information eXport (IPFIX) [RFC7012] to report abnormal traffic
patterns (such as port scanning, SYN-flooding, related IP source patterns (such as port scanning, SYN-flooding, related IP source
addresses) from monitoring tools and evaluating data read from SNMP addresses) from monitoring tools and evaluating data read from SNMP
MIBs [RFC4293] (some of which also enable the detection of abnormal MIBs [RFC4293] (some of which also enable the detection of abnormal
bandwidth utilization). Where Netflow is used, version 9 is required bandwidth utilization). Where Netflow is used, version 9 is required
for IPv6 support. 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
skipping to change at page 21, line 4 skipping to change at page 20, line 33
o Use the server load balancer which acts as an application proxy to o Use the server load balancer which acts as an application proxy to
do this translation. Compared to the NAT64, it has the potential do this translation. Compared to the NAT64, it has the potential
benefit of going through the security devices as native IPv6 (so benefit of going through the security devices as native IPv6 (so
more audit and trace abilities) and is also able to insert a HTTP more audit and trace abilities) and is also able to insert a HTTP
X-Forward-For header which contains the remote IPv6 address. The X-Forward-For header which contains the remote IPv6 address. The
latter feature allows for logging, and rate-limiting on the real latter feature allows for logging, and rate-limiting on the real
servers based on the IPV6 address even if those servers run only servers based on the IPV6 address even if those servers run only
IPv4. IPv4.
3.5. Network Prefix Translation for IPv6 3.5. Network Prefix Translation for IPv6
Network Prefix Translation for IPv6, or NPTv6 as described in Network Prefix Translation for IPv6, or NPTv6 as described in
[RFC6296] provides a framework to utilize prefix ranges within the [RFC6296] provides a framework to utilize prefix ranges within the
internal network which are separate (address-independent) from the internal network which are separate (address-independent) from the
assigned prefix from the upstream provider or registry. As mentioned assigned prefix from the upstream provider or registry. As mentioned
above, while NPTv6 has potential use-cases in IPv6 networks, the above, while NPTv6 has potential use-cases in IPv6 networks, the
implications of its deployment need to be fully understood, implications of its deployment need to be fully understood,
particularly where any applications might embed IPv6 addresses in particularly where any applications might embed IPv6 addresses in
their payloads. their payloads.
Use of NTPv6 can be chosen independently from how addresses are Use of NPTv6 can be chosen independently from how addresses are
assigned and routed within the internal network and how prefixes are assigned and routed within the internal network and how prefixes are
routed towards the Internet (included both PA and PI address routed towards the Internet (included both PA and PI address
assignment options). assignment options).
4. Internal Phase 4. Internal Phase
This phase deals with the delivery of IPv6 to the internal user- This phase deals with the delivery of IPv6 to the internal user-
facing side of the IT infrastructure, which comprises various facing side of the IT infrastructure, which comprises various
components such as network devices (routers, switches, etc.), end components such as network devices (routers, switches, etc.), end
user devices and peripherals (workstations, printers, etc.), and user devices and peripherals (workstations, printers, etc.), and
skipping to change at page 27, line 10 skipping to change at page 26, line 40
6.3. University Campus Networks 6.3. University Campus Networks
A number of campus networks around the world have made some initial A number of campus networks around the world have made some initial
IPv6 deployment. This has been encouraged by their National Research IPv6 deployment. This has been encouraged by their National Research
and Education Network (NREN) backbones having made IPv6 available and Education Network (NREN) backbones having made IPv6 available
natively since the early 2000's. Universities are a natural place for natively since the early 2000's. Universities are a natural place for
IPv6 deployment to be considered at an early stage, perhaps compared IPv6 deployment to be considered at an early stage, perhaps compared
to other enterprises, as they are involved by their very nature in to other enterprises, as they are involved by their very 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; there is no need
to deploy IPv6 across the entire enterprise from day one, rather to deploy IPv6 across the entire enterprise from day one, rather
specific projects can be identified for an initial deployment, that specific projects can be identified for an initial deployment, that
are both deep enough to give the university experience, but small are both deep enough to give the university experience, but small
enough to be a realistic first step. There are generally three areas enough to be a realistic first step. There are generally three areas
in which such deployments are currently made. in which such deployments are currently made.
In particular those initial areas commonly approached are: In particular those initial areas commonly approached are:
o External-facing services. Typically the campus web presence and o External-facing services. Typically the campus web presence and
commonly also external-facing DNS and MX services. This ensures commonly also external-facing DNS and MX services. This ensures
skipping to change at page 29, line 39 skipping to change at page 29, line 21
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4293] Routhier, S., "Management Information Base for the [RFC4293] Routhier, S., "Management Information Base for the
Internet Protocol (IP)", RFC 4293, April 2006. Internet Protocol (IP)", RFC 4293, April 2006.
[RFC4296] Bailey, S. and T. Talpey, "The Architecture of Direct Data [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April
Placement (DDP) and Remote Direct Memory Access (RDMA) on 2006.
Internet Protocols", RFC 4296, December 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for "BGP-MPLS IP Virtual Private Network (VPN) Extension for
skipping to change at page 30, line 23 skipping to change at page 30, line 5
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, December of Type 0 Routing Headers in IPv6", RFC 5095, December
2007. 2007.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. [RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow
Meyer, "Information Model for IP Flow Information Export", Information Export (IPFIX)", RFC 7012, September 2013.
RFC 5102, January 2008.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", RFC
5157, March 2008. 5157, March 2008.
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July [RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, 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.
skipping to change at page 32, line 32 skipping to change at page 32, line 17
6883, March 2013. 6883, March 2013.
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address [RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address
Validation Improvement (SAVI) Threat Scope", RFC 6959, May Validation Improvement (SAVI) Threat Scope", RFC 6959, May
2013. 2013.
[RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in [RFC6964] Templin, F., "Operational Guidance for IPv6 Deployment in
IPv4 Sites Using the Intra-Site Automatic Tunnel IPv4 Sites Using the Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)", RFC 6964, May 2013. Addressing Protocol (ISATAP)", RFC 6964, May 2013.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC7045 , December 2013,
<http://tools.ietf.org/html/rfc7045>.
[I-D.xli-behave-divi] [I-D.xli-behave-divi]
Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual- Bao, C., Li, X., Zhai, Y., and W. Shang, "dIVI: Dual-
Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-05 Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-06
(work in progress), June 2013. (work in progress), January 2014.
[I-D.wierenga-ietf-eduroam] [I-D.wierenga-ietf-eduroam]
Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
architecture for network roaming", draft-wierenga-ietf- architecture for network roaming", draft-wierenga-ietf-
eduroam-01 (work in progress), July 2013. eduroam-01 (work in progress), July 2013.
[I-D.ietf-v6ops-dc-ipv6] [I-D.ietf-v6ops-dc-ipv6]
Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin, Lopez, D., Chen, Z., Tsou, T., Zhou, C., and A. Servin,
"IPv6 Operational Guidelines for Datacenters", draft-ietf- "IPv6 Operational Guidelines for Datacenters", draft-ietf-
v6ops-dc-ipv6-00 (work in progress), August 2013. v6ops-dc-ipv6-00 (work in progress), August 2013.
[I-D.ietf-6man-ext-transmit]
Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", draft-ietf-6man-ext-
transmit-04 (work in progress), September 2013.
[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-03 (work in progress), July 2013. opsec-v6-04 (work in progress), October 2013.
[I-D.ietf-opsec-ipv6-host-scanning] [I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-02 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-02 (work in
progress), July 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. Will, "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-07 (work in progress), December 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.liu-bonica-dhcpv6-slaac-problem] [I-D.liu-bonica-dhcpv6-slaac-problem]
Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration
Interaction Problem Statement", draft-liu-bonica-dhcpv6 Interaction Problem Statement", draft-liu-bonica-dhcpv6
-slaac-problem-02 (work in progress), September 2013. -slaac-problem-02 (work in progress), September 2013.
[I-D.ietf-v6ops-ula-usage-recommendations] [I-D.ietf-v6ops-ula-usage-recommendations]
Liu, B., Jiang, S., and C. Byrne, "Recommendations of Liu, B., 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-01 (work in progress), October 2013.
[SMURF] , "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service [SMURF] "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service
Attacks", , Attacks",
<http://www.cert.org/advisories/CA-1998-01.html>. <http://www.cert.org/advisories/CA-1998-01.html>.
[CYMRU] , "THE BOGON REFERENCE", , [CYMRU] "THE BOGON REFERENCE",
<http://www.team-cymru.org/Services/Bogons/>. <http://www.team-cymru.org/Services/Bogons/>.
Authors' Addresses Authors' Addresses
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
Email: kk@google.com Email: kk@google.com
Tim Chown Tim Chown
University of Southampton University of Southampton
 End of changes. 32 change blocks. 
48 lines changed or deleted 47 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/