draft-ietf-v6ops-enterprise-incremental-ipv6-00.txt   draft-ietf-v6ops-enterprise-incremental-ipv6-01.txt 
v6ops K. Chittimaneni v6ops K. Chittimaneni
Internet-Draft Google Inc. Internet-Draft Google Inc.
Intended status: Informational T. Chown Intended status: Informational T. Chown
Expires: February 8, 2013 University of Southampton Expires: March 19, 2013 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
Aug 7, 2012 September 15, 2012
Enterprise Incremental IPv6 Enterprise IPv6 Deployment Guidelines
draft-ietf-v6ops-enterprise-incremental-ipv6-00 draft-ietf-v6ops-enterprise-incremental-ipv6-01
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 February 8, 2013. This Internet-Draft will expire on March 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 19 skipping to change at page 3, line 19
1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . . 5 1.2. IPv4-only Considerations . . . . . . . . . . . . . . . . . 5
1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 5 1.3. Reasons for a Phased Approach . . . . . . . . . . . . . . 5
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
3. Preparation and Assessment Phase . . . . . . . . . . . . . . . 6 3. Preparation and Assessment Phase . . . . . . . . . . . . . . . 6
3.1. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 6 3.1. Inventory Phase . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Network infrastructure readiness assessment . . . . . 6 3.1.1. Network infrastructure readiness assessment . . . . . 6
3.1.2. Applications readiness assessment . . . . . . . . . . 7 3.1.2. Applications readiness assessment . . . . . . . . . . 7
3.1.3. Importance of readiness validation and testing . . . . 7 3.1.3. Importance of readiness validation and testing . . . . 7
3.2. Training . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Training . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Security and Routing Policy . . . . . . . . . . . . . . . 8 3.4. Security Policy . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. Demystifying some IPv6 Security Myths . . . . . . . . 8 3.4.1. Demystifying some IPv6 Security Myths . . . . . . . . 8
3.4.2. Similarities between IPv6 and IPv4 security . . . . . 9 3.4.2. Similarities between IPv6 and IPv4 security . . . . . 9
3.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 10 3.4.3. Specific Security Issues for IPv6 . . . . . . . . . . 10
3.5. Address Plan . . . . . . . . . . . . . . . . . . . . . . . 11 3.5. Address Plan . . . . . . . . . . . . . . . . . . . . . . . 11
3.6. Program Planning . . . . . . . . . . . . . . . . . . . . . 12 3.6. Program Planning . . . . . . . . . . . . . . . . . . . . . 12
3.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . . 13 3.7. Tools Assessment . . . . . . . . . . . . . . . . . . . . . 13
4. External Phase . . . . . . . . . . . . . . . . . . . . . . . . 14 4. External Phase . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Servers and Applications . . . . . . . . . . . . . . . . . 17 4.4. Servers and Applications . . . . . . . . . . . . . . . . . 17
5. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Internal Phase . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Network Infrastructure . . . . . . . . . . . . . . . . . . 17 5.1. Network Infrastructure . . . . . . . . . . . . . . . . . . 17
5.2. End user devices . . . . . . . . . . . . . . . . . . . . . 19 5.2. End user devices . . . . . . . . . . . . . . . . . . . . . 19
5.3. Corporate Systems . . . . . . . . . . . . . . . . . . . . 20 5.3. Corporate Systems . . . . . . . . . . . . . . . . . . . . 20
5.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4. Security . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Other Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Other Phases . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Guest network . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Guest network . . . . . . . . . . . . . . . . . . . . . . 21
6.2. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. IPv6-only . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Considerations For Specific Enterprises . . . . . . . . . . . 22 7. Considerations For Specific Enterprises . . . . . . . . . . . 22
7.1. Content Delivery Networks . . . . . . . . . . . . . . . . 22 7.1. Content Delivery Networks . . . . . . . . . . . . . . . . 22
7.2. Data Center Virtualization . . . . . . . . . . . . . . . . 22 7.2. Data Center Virtualization . . . . . . . . . . . . . . . . 22
7.3. Campus Networks . . . . . . . . . . . . . . . . . . . . . 22 7.3. Campus Networks . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
An Enterprise Network as defined in [RFC4057] as: a network that has An Enterprise Network as 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). Adminstrators generally support an internal administrators). Adminstrators generally support an internal
network, consisting of users' computers and related peripherals, a network, consisting of users' computers and related peripherals, a
server network, consisting of accounting and business application server network, consisting of accounting and business application
skipping to change at page 8, line 36 skipping to change at page 8, line 36
Enterprises could also take the opportunity the introduction of IPv6 Enterprises could also take the opportunity the introduction of IPv6
brings to analyze your current environment and to identify which brings to analyze your current environment and to identify which
features you would like to change and what you would like to features you would like to change and what you would like to
implement. Then using the validation period as a way to validate implement. Then using the validation period as a way to validate
your new approach and even applying them to your IPv4 environment. your new approach and even applying them to your IPv4 environment.
Either way IPv6 introduces the opportunity to rationalize the Either way IPv6 introduces the opportunity to rationalize the
environment and to architect it for growth. environment and to architect it for growth.
3.4. Security and Routing Policy 3.4. Security Policy
It is obvious that IPv6 network should be deployed in a secure way. It is obvious that IPv6 network should be deployed in a secure way.
The industry has learned a lot about network security with IPv4, so, The industry has learned a lot about network security with IPv4, so,
network operators should leverage this knowledge and expertise when network operators should leverage this knowledge and expertise when
deploying IPv6. IPv6 is not so different than IPv4: it is a deploying IPv6. IPv6 is not so different than IPv4: it is a
connectionless network protocol using the same lower layer service connectionless network protocol using the same lower layer service
and delivering the same service to the upper layer. Therefore, the and delivering the same service to the upper layer. Therefore, the
security issues and mitigation techniques are mostly identical with security issues and mitigation techniques are mostly identical with
same exceptions that are described further. same exceptions that are described further.
skipping to change at page 9, line 18 skipping to change at page 9, line 18
One security myth is that thanks to its huge address space, a network One security myth is that thanks to its huge address space, a network
cannot be scanned by enumerating all IPv6 address in a /64 LAN hence cannot be scanned by enumerating all IPv6 address in a /64 LAN hence
a malevolent person cannot find a victim. [RFC5157] describes some a malevolent person cannot find a victim. [RFC5157] describes some
alternate techniques to find potential targets on a network, for alternate techniques to find potential targets on a network, for
example enumerating all DNS names in a zone. example enumerating all DNS names in a zone.
Another security myth is that IPv6 is more secure because it mandates Another security myth is that IPv6 is more secure because it mandates
the use of IPsec everywhere. [RFC6434] clearly states that the IPv6 the use of IPsec everywhere. [RFC6434] clearly states that the IPv6
support is a SHOULD only. Moreover, if all the intra-enterprise support is a SHOULD only. Moreover, if all the intra-enterprise
traffic is encrypted, then this renders all the network security traffic is encrypted, then this renders a lot of the network security
tools (IPS, firewall, ACL, IPFIX, etc) blind and pretty much useless. tools (IPS, firewall, ACL, IPFIX, etc) blind and pretty much useless.
Therefore, IPsec should be used in IPv6 pretty much like in IPv4 (for Therefore, IPsec should be used in IPv6 pretty much like in IPv4 (for
example to establish a VPN overlay over a non-trusted network or example to establish a VPN overlay over a non-trusted network or
reserve to some specific applications). reserved for some specific applications).
The last security myth is that amplification attacks (such as The last security myth is that amplification attacks (such as
http://www.cert.org/advisories/CA-1998-01.html) do not exist in IPv6 [SMURF]) do not exist in IPv6 because there is no more broadcast.
because there is no more broadcast. Alas, this is not true as ICMP Alas, this is not true as ICMP error (in some cases) or information
error (in some cases) or information messages can be generated by messages can be generated by routers and hosts when forwarding or
routers and hosts when forwarding or receiving a multicast message receiving a multicast message (section 2.4 of [RFC4443]). Therefore,
(section 2.4 of [RFC4443]). Therefore, the generation and the the generation and the forwarding rate of ICMPv6 messages must be
forwarding rate of ICMPv6 messages must be rate limited as in IPv4. limited as in IPv4.
3.4.2. Similarities between IPv6 and IPv4 security 3.4.2. Similarities between IPv6 and IPv4 security
As mentioned earlier, IPv6 is quite similar to IPv4, therefore As mentioned earlier, IPv6 is quite similar to IPv4, therefore
several attacks apply for both protocol family: several attacks apply for both protocol family:
o Application layer attacks: such as cross-site scripting or SQL o Application layer attacks: such as cross-site scripting or SQL
injection injection
o Rogue device: such as a rogue WiFi Access Point o Rogue device: such as a rogue WiFi Access Point
skipping to change at page 10, line 7 skipping to change at page 10, line 7
o Etc o Etc
A specific case of congruence is the IPv6 ULA [RFC4193] and IPv4 A specific case of congruence is the IPv6 ULA [RFC4193] and IPv4
private addressing [RFC1918] that do not provide any security by private addressing [RFC1918] that do not provide any security by
'magic'. In both case, the edge router must apply strict data plane 'magic'. In both case, the edge router must apply strict data plane
and routing policy to block those private addresses to leave and and routing policy to block those private addresses to leave and
enter the network. This filtering can be done by the enterprise or enter the network. This filtering can be done by the enterprise or
by the ISP. by the ISP.
IPv6 addresses can be spoofed as easily as IPv4 addresses and there IPv6 addresses can be spoofed as easily as IPv4 addresses and there
are packets with bogons IPv6 addresses (see are packets with bogons IPv6 addresses (see [CYMRU]). The anti-bogon
http://www.team-cymru.org/Services/Bogons/). The anti-bogon
filtering must be done in the data and routing planes. It can be filtering must be done in the data and routing planes. It can be
done by the enterprise or by the ISP. done by the enterprise or by the ISP.
3.4.3. Specific Security Issues for IPv6 3.4.3. Specific Security Issues for IPv6
Even if IPv6 is similar to IPv4, there are some differences that Even if IPv6 is similar to IPv4, there are some differences that
create some IPv6-only vulnerabilities or issues. create some IPv6-only vulnerabilities or issues.
Privacy extension addresses [RFC4941] are usually to protect Privacy extension addresses [RFC4941] are usually to protect
individual privacy by changing periodically the interface identifier individual privacy by changing periodically the interface identifier
part of the IPv6 address to avoid tracking a host by its always part of the IPv6 address to avoid tracking a host by its always
identical and unique EUI-64. While this presents a real advantage on identical and unique EUI-64. While this presents a real advantage on
the Internet, it complicates the task of audit trail when a security the Internet, it complicates the task of audit trail when a security
officer or network operator wants to trace back a log entry to a host officer or network operator wants to trace back a log entry to a host
in their network because when the tracing is done the searched IPv6 in their network because when the tracing is done the searched IPv6
address could have disappeared from the network. A good way to address could have disappeared from the network. Therefore, the use
prevent the use of privacy extension addresses without host of privacy extension addresses usually requires an additional
configuration is to send the Router Advertisement with the M-bit set monitoring and logging of the binding of the IPv6 address to a data-
(to force the use of DHCPv6 to get an address) and with all link layer address (see also the monitoring section of
advertized prefixes without the A-bit set (to prevent the use of [I-D.vyncke-opsec-v6]). An alternative is to try to prevent the use
stateless auto-configuration). of privacy extension addresses is to send the Router Advertisement
with the M-bit set (to force the use of DHCPv6 to get an address) and
with all advertized prefixes without the A-bit set (to prevent the
use of stateless auto-configuration); this technique requires that
all hosts support stateful DHCPv6.
Extension headers complicate the task of stateless packet filters Extension headers complicate the task of stateless packet filters
such as ACL. If ACL are used to enforce a security policy, then the such as ACL. If ACL are used to enforce a security policy, then the
enterprise must verify whether its ACL (but also stateful firewalls) enterprise must verify whether its ACL (but also stateful firewalls)
are able to process extension headers (this means understand them are able to process extension headers (this means understand them
enough to parse them to find the upper layers payloads) and to block enough to parse them to find the upper layers payloads) and to block
unwanted extension headers (e.g. to implement [RFC5095]). unwanted extension headers (e.g. to implement [RFC5095]).
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 must be allowed [RFC4890] through all filters. packet-too-big must be allowed [RFC4890] through all filters.
Fragments can also be used to evade some security mechanisms such as Fragments can also be used to evade some security mechanisms such as
RA-guard [RFC6105], see also [RFC5722]which appears to be widely RA-guard [RFC6105], see also [RFC5722] which appears to be widely
implemented in 2012. implemented in 2012.
But, the biggest difference is the replacement of ARP (RFC 826) by But, the biggest difference is the replacement of ARP (RFC 826) by
Neighbor Discovery Protocol [RFC4861]. NDP runs over ICMPv6 (this Neighbor Discovery Protocol [RFC4861]. NDP runs over ICMPv6 (this
means that security policies MUST allow some ICMPv6 messages see RFC means that security policies MUST allow some ICMPv6 messages see RFC
4890) but has the same lack of security as ARP (SeND [RFC3971] and 4890) but has the same lack of security as ARP (SeND [RFC3971] and
CGA [RFC3972] are not widely implemented). ARP can be made secure CGA [RFC3972] are not widely implemented). ARP can be made secure
with the help of techniques known as DHCPv4 snooping and dynamic ARP with the help of techniques known as DHCPv4 snooping and dynamic ARP
inspection by access switches. Therefore, enterprises using those inspection by access switches. Therefore, enterprises using those
techniques for IPv4 should use the equivalent techniques for IPv6: techniques for IPv4 should use the equivalent techniques for IPv6:
skipping to change at page 16, line 10 skipping to change at page 16, line 13
will want to attempt to use Native IPv6 connectivity. Native IPv6 will want to attempt to use Native IPv6 connectivity. Native IPv6
connectivity is preferred since it provides the most rebuts form of connectivity is preferred since it provides the most rebuts form of
connectivity. If Native IPv6 connectivity is not possible due to connectivity. If Native IPv6 connectivity is not possible due to
technical or business limitations, the Enterprise may utilize readily technical or business limitations, the Enterprise may utilize readily
available tunnelled IPv6 connectivity. There are IPv6 transit available tunnelled IPv6 connectivity. There are IPv6 transit
providers which provide tunnelled IPv6 connectivity which can operate providers which provide tunnelled IPv6 connectivity which can operate
over IPv4 networks. A Enterprise need not need to wait for their over IPv4 networks. A Enterprise need not need to wait for their
local Service Provider to support IPv6, as tunnelled connectivity can local Service Provider to support IPv6, as tunnelled connectivity can
be used. be used.
** Add some comment about setting MTU to 1280 to avoid tunnel pMTUd
black holes? **
4.2. Security 4.2. Security
The most important part of security for external IPv6 deployment is The most important part of security for external IPv6 deployment is
filtering. Filtering can be done by stateless ACL or stateful filtering and monitoring. Filtering can be done by stateless ACL or
firewall. As described in section 2.4.3, the security policies must stateful firewall. The security policies must be congruent for IPv4
be congruent for IPv4 and IPv6 except that ICMPv6 messages must be and IPv6 (else the attacker will use the less protected protocol
allowed through and to the filtering device (see [RFC4890]): stack) except that ICMPv6 messages must be allowed through and to the
filtering device (see [RFC4890]):
o unreachable packet-too-big o unreachable packet-too-big: really imporant to allow Path MTU
discovery to work
o unreachable parameter-problem o unreachable parameter-problem
o neighbor solicitation o neighbor solicitation
o neighbor advertisement o neighbor advertisement
** Add some comment about setting MTU to 1280 to avoid tunnel pMTUd
black holes? **
It could also be safer to block all fragments where the transport It could also be safer to block all fragments where the transport
layer header is not in the first fragment to avoid attack as layer header is not in the first fragment to avoid attack as
described in [RFC5722]. Some filtering devices allow this filtering. described in [RFC5722]. Some filtering devices allow this filtering.
To be fully compliant with [RFC5095], it can be useful to drop all To be fully compliant with [RFC5095], it can be useful to drop all
packet containing the routing extension header type 0. packet containing the routing extension header type 0.
If Intrusion Prevention Systems (IPS) are used for IPv4 traffic, then If Intrusion Prevention Systems (IPS) are used for IPv4 traffic, then
the same IPS should also be used for IPv6 traffic. This is just a the same IPS should also be used for IPv6 traffic. This is just a
generalization of the dual-stack deployment: do for IPv6 what you do generalization of the dual-stack deployment: do for IPv6 what you do
for IPv4. This also include all email content protection (anti-spam, for IPv4. This also include all email content protection (anti-spam,
content filtering, data leakage prevention, etc). content filtering, data leakage prevention, etc).
The peering router must also implement anti-spoofing technique based The peering router must also implement anti-spoofing technique based
on [RFC2827]. on [RFC2827].
In order to protect the networking device, it is advised to implement In order to protect the networking devices, it is advised to
control plane policing as per [RFC6192]. implement control plane policing as per [RFC6192].
The NDP cache exhaustion (see [I-D.gashinsky-v6ops-v6nd-problems]) The NDP cache exhaustion (see [I-D.gashinsky-v6ops-v6nd-problems])
attack can be mitigated by two techniques: attack can be mitigated by two techniques:
o good NDP implementation with memory utilization limits as well as o good NDP implementation with memory utilization limits as well as
rate-limiters and prioritization of requests. rate-limiters and prioritization of requests.
o else, as the external deployment usually involves just a couple of o else, as the external deployment usually involves just a couple of
exposed IPv6 statically configured addresses (virtual address of exposed IPv6 statically configured addresses (virtual address of
web, email servers, DNS server), then it is straightforward to web, email servers, DNS server), then it is straightforward to
skipping to change at page 18, line 19 skipping to change at page 18, line 22
incorporating features such as ARP inspection and DHCP Snooping. incorporating features such as ARP inspection and DHCP Snooping.
An important design choice to be made is what IGP to use inside the An important design choice to be made is what IGP to use inside the
network. A variety of IGPs (IS-IS, OSPFv3 and RIPng) support IPv6 network. A variety of IGPs (IS-IS, OSPFv3 and RIPng) support IPv6
today and picking one over the other is purely a design choice that today and picking one over the other is purely a design choice that
will be dictated mostly by existing operational policies in an will be dictated mostly by existing operational policies in an
enterprise network. As mentioned earlier, it would be beneficial to enterprise network. As mentioned earlier, it would be beneficial to
maintain operational parity between IPv4 and IPv6 and therefore it maintain operational parity between IPv4 and IPv6 and therefore it
might make sense to continue using the same protocol family that is might make sense to continue using the same protocol family that is
being used for IPv4. For example, if you use OSPFv2 for IPv4, it being used for IPv4. For example, if you use OSPFv2 for IPv4, it
might make sense to use OSPFv3 now. might make sense to use OSPFv3 now. It is important to note that
although OSPFv3 is similar to OSPFv2, they are not the same. On the
other hand, some organizations may chose to run different routing
protocols for different IP versions. For e.g., one may chose to run
OSPFv2 for IPv4 and IS-IS for IPv6. An important design question to
consider here is whether to support one IGP or two different IGPs
down the road. [I-D.matthews-v6ops-design-guidelines] presents
advice on the design choices that arise when considering one IGP vs.
the other and discusses the pros and cons in detail.
Another important consideration in enterprise networks is first hop Another important consideration in enterprise networks is first hop
router redundancy. This directly ties into network reachability from router redundancy. This directly ties into network reachability from
an end host's point of view. IPv6 Neighbor Discovery (ND), an end host's point of view. IPv6 Neighbor Discovery (ND),
[RFC4861], provides a node with the capability to maintain a list of [RFC4861], provides a node with the capability to maintain a list of
available routers on the link, in order to be able to switch to a available routers on the link, in order to be able to switch to a
backup path should the primary be unreachable. By default, ND will backup path should the primary be unreachable. By default, ND will
detect a router failure in 38 seconds and cycle onto the next default detect a router failure in 38 seconds and cycle onto the next default
router listed in its cache. While this feature does provide with a router listed in its cache. While this feature does provide with a
basic level of first hop router redundancy, most enterprise IPv4 basic level of first hop router redundancy, most enterprise IPv4
skipping to change at page 20, line 31 skipping to change at page 20, line 40
5.4. Security 5.4. Security
IPv6 must be deployed in a secure way. This means that all existing IPv6 must be deployed in a secure way. This means that all existing
IPv4 security policies must be extended to support IPv6; IPv6 IPv4 security policies must be extended to support IPv6; IPv6
security policies will be the IPv6 equivalent of the existing IPv4 security policies will be the IPv6 equivalent of the existing IPv4
ones (taking into account the difference for ICMPv6 [RFC4890]). As ones (taking into account the difference for ICMPv6 [RFC4890]). As
in IPv4, security policies for IPv6 will be enforced by firewalls, in IPv4, security policies for IPv6 will be enforced by firewalls,
ACL, IPS, VPN, ... ACL, IPS, VPN, ...
Privacy extension addresses [RFC4941] pose a real challenge for audit Privacy extension addresses [RFC4941] pose a real challenge for audit
trail. Therefore, it is recommended not to use them within the trail as explained in section Section 3.4.3.
enterprise network by using the configuration described previously.
But, the biggest problem is probably linked to all threats against But, the biggest problem is probably linked to all threats against
Neighbor Discovery. This means that the internal network at the Neighbor Discovery. This means that the internal network at the
access layer (i.e. where hosts connect to the network over wired or access layer (i.e. where hosts connect to the network over wired or
wireless) must implement RA-guard [RFC6105] and the techniques being wireless) must implement RA-guard [RFC6105] and the techniques being
specified by SAVI WG [I-D.ietf-savi-threat-scope]. specified by SAVI WG [I-D.ietf-savi-threat-scope]; see also
Section 3.4.3 for more information.
6. Other Phases 6. Other Phases
To be added. To be added.
6.1. Guest network 6.1. Guest network
To be added. To be added.
6.2. IPv6-only 6.2. IPv6-only
skipping to change at page 22, line 41 skipping to change at page 23, line 7
of the campus compauter science department network is a sensible of the campus compauter science department network is a sensible
first step. first step.
o The eduroam wireless network. Eduroam is the defacto wireless o The eduroam wireless network. Eduroam is the defacto wireless
roaming system for academic networks, and uses 802.1X based roaming system for academic networks, and uses 802.1X based
authentication, which is agnostic to the IP version used (unlike authentication, which is agnostic to the IP version used (unlike
web-redirection gateway systems). web-redirection gateway systems).
8. Security Considerations 8. Security Considerations
This document has multiple security sections detailing how do
securely deploy an IPv6 network within an enterprise network.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Chris Grundemann, Ray Hunter, Brian The authors would like to thank Chris Grundemann, Ray Hunter, Brian
Carpenter, Tina Tsou for their comments on the mailing list. Carpenter, Tina Tsou for their comments on the mailing list.
10. IANA Considerations 10. IANA Considerations
There are no IANA considerations or implications that arise from this There are no IANA considerations or implications that arise from this
document. document.
skipping to change at page 26, line 39 skipping to change at page 26, line 51
Chen, Z., Lopez, D., Tsou, T., and C. Zhou, "A Reference Chen, Z., Lopez, D., Tsou, T., and C. Zhou, "A Reference
Framework for DC Migration to IPv6", Framework for DC Migration to IPv6",
draft-lopez-v6ops-dc-ipv6-02 (work in progress), draft-lopez-v6ops-dc-ipv6-02 (work in progress),
June 2012. June 2012.
[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-17 IPv4 Sites using ISATAP", draft-templin-v6ops-isops-17
(work in progress), May 2012. (work in progress), May 2012.
[I-D.matthews-v6ops-design-guidelines]
Matthews, P., "Design Guidelines for IPv6 Networks",
draft-matthews-v6ops-design-guidelines-00 (work in
progress), June 2012.
[I-D.vyncke-opsec-v6]
Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational
Security Considerations for IPv6 Networks",
draft-vyncke-opsec-v6-01 (work in progress), July 2012.
[SMURF] "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service
Attacks",
<http://www.cert.org/advisories/CA-1998-01.html>.
[CYMRU] "THE BOGON REFERENCE",
<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
Highfield Highfield
Southampton, Hampshire SO17 1BJ Southampton, Hampshire SO17 1BJ
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
Lee Howard Lee Howard
Time Warner Cable Time Warner Cable
 End of changes. 27 change blocks. 
44 lines changed or deleted 78 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/