draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05.txt   draft-ietf-opsec-ipv6-implications-on-ipv4-nets-06.txt 
Operational Security Capabilities for F. Gont opsec wg F. Gont
IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH Internet-Draft SI6 Networks/UTN-FRH
Internet-Draft W. Liu Intended status: Informational W. Liu
Intended status: Informational Huawei Technologies Expires: May 30, 2014 Huawei Technologies
Expires: January 6, 2014 July 5, 2013 November 26, 2013
Security Implications of IPv6 on IPv4 Networks Security Implications of IPv6 on IPv4 Networks
draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-06
Abstract Abstract
This document discusses the security implications of native IPv6 This document discusses the security implications of native IPv6
support and IPv6 transition/co-existence technologies on "IPv4-only" support and IPv6 transition/co-existence technologies on "IPv4-only"
networks, and describes possible mitigations for the aforementioned networks, and describes possible mitigations for the aforementioned
issues. issues.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2014. This Internet-Draft will expire on May 30, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Security Implications of Native IPv6 Support . . . . . . . . . 5 2. Security Implications of Native IPv6 Support . . . . . . . . 3
2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 5 2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 4
3. Security Implications of Tunneling Mechanisms . . . . . . . . 7 3. Security Implications of Tunneling Mechanisms . . . . . . . . 5
3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . 6
3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8 3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . 7
3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . 7
3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 10 3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . 9
3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 11 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . 9
3.7. Filtering Tunnel Broker with Tunnel Setup Protocol 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 11
(TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 11
3.8. Filtering AYIYA . . . . . . . . . . . . . . . . . . . . . 13 4. Additional Considerations when Filtering IPv6 Traffic . . . . 11
4. Additional Considerations when Filtering IPv6 Traffic . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Summary of filtering rules . . . . . . . . . . . . . 17
Appendix A. Summary of filtering rules . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Most general-purpose operating systems implement and enable native Most general-purpose operating systems implement and enable native
IPv6 [RFC2460] support and a number of transition/co-existence IPv6 [RFC2460] support and a number of transition/co-existence
technologies by default. Support of IPv6 by all nodes is intended to technologies by default. Support of IPv6 by all nodes is intended to
become best current practice [RFC6540]. Some enterprise networks become best current practice [RFC6540]. Some enterprise networks
might, however, choose to delay active use of IPv6. might, however, choose to delay active use of IPv6.
This document describes operational practices for enterprise networks This document describes operational practices for enterprise networks
to prevent security exposure resulting from unplanned use of IPv6 on to prevent security exposure resulting from unplanned use of IPv6 on
such networks. This document is only applicable to enterprise such networks. This document is only applicable to enterprise
networks: networks where the network operator is not providing a networks: networks where the network operator is not providing a
general-purpose internet, but rather a business-specific network. general-purpose internet, but rather a business-specific network.
The solutions proposed here are not practical for home networks, nor The solutions proposed here are not practical for home networks, nor
are they appropriate for provider networks such as ISPs, mobile are they appropriate for provider networks such as ISPs, mobile
providers, Wifi hotspot providers or any other public internet providers, Wifi hotspot providers or any other public internet
service. service.
In scenarios in which IPv6-enabled devices are deployed on enterprise In scenarios in which IPv6-enabled devices are deployed on enterprise
networks that are intended to be IPv4-only, native IPv6 support networks that are intended to be IPv4-only, native IPv6 support and/
and/or IPv6 transition/co-existence technologies could be leveraged or IPv6 transition/co-existence technologies could be leveraged by
by local or remote attackers for a number of (illegitimate) purposes. local or remote attackers for a number of (illegitimate) purposes.
For example, For example,
o A Network Intrusion Detection System (NIDS) might be prepared to o A Network Intrusion Detection System (NIDS) might be prepared to
detect attack patterns for IPv4 traffic, but might be unable to detect attack patterns for IPv4 traffic, but might be unable to
detect the same attack patterns when a transition/co-existence detect the same attack patterns when a transition/co-existence
technology is leveraged for that purpose. technology is leveraged for that purpose.
o An IPv4 firewall might enforce a specific security policy in IPv4, o An IPv4 firewall might enforce a specific security policy in IPv4,
but might be unable to enforce the same policy in IPv6. but might be unable to enforce the same policy in IPv6.
o A NIDS or firewall might support both IPv4 and IPv6, but might be o A NIDS or firewall might support both IPv4 and IPv6, but might be
not be configured to enforce on IPv6 traffic the same controls/ not be configured to enforce on IPv6 traffic the same controls/
skipping to change at page 3, line 46 skipping to change at page 3, line 21
o A NIDS or firewall might support both IPv4 and IPv6, but might be o A NIDS or firewall might support both IPv4 and IPv6, but might be
not be configured to enforce on IPv6 traffic the same controls/ not be configured to enforce on IPv6 traffic the same controls/
policies it enforces on IPv4 traffic. policies it enforces on IPv4 traffic.
o Some transition/co-existence mechanisms could cause an internal o Some transition/co-existence mechanisms could cause an internal
host with otherwise limited IPv4 connectivity to become globally host with otherwise limited IPv4 connectivity to become globally
reachable over IPv6, therefore resulting in increased (and reachable over IPv6, therefore resulting in increased (and
possibly unexpected) host exposure. possibly unexpected) host exposure.
Some transition/co-existence mechanisms (notably Teredo) are Some transition/co-existence mechanisms (notably Teredo) are
designed to traverse Network Address Port Translation (NAPT) designed to traverse Network Address Port Translation (NAPT)
[RFC2663] devices, allowing incoming IPv6 connections from the [RFC2663] devices, allowing incoming IPv6 connections from
Internet to hosts behind the organizational firewall or NAPT the Internet to hosts behind the organizational firewall or
(which in many deployments provides a minimum level of NAPT (which in many deployments provides a minimum level of
protection by only allowing those instances of communication protection by only allowing those instances of communication
that have been initiated from the internal network). that have been initiated from the internal network).
o IPv6 support could, either inadvertently or as a result of a o IPv6 support could, either inadvertently or as a result of a
deliberate attack, result in VPN traffic leaks if IPv6-unaware deliberate attack, result in VPN traffic leaks if IPv6-unaware
Virtual Private Network (VPN) software is employed by dual-stacked Virtual Private Network (VPN) software is employed by dual-stacked
hosts [I-D.ietf-opsec-vpn-leakages]. hosts [I-D.ietf-opsec-vpn-leakages].
In general, most of the aforementioned security implications can be In general, most of the aforementioned security implications can be
mitigated by enforcing security controls on native IPv6 traffic and mitigated by enforcing security controls on native IPv6 traffic and
on IPv4-tunneled IPv6 traffic. Among such controls is the on IPv4-tunneled IPv6 traffic. Among such controls is the
enforcement of filtering policies, to block undesirable traffic. enforcement of filtering policies, to block undesirable traffic.
skipping to change at page 5, line 47 skipping to change at page 4, line 42
administrator might mitigate IPv6-based attack vectors by means of administrator might mitigate IPv6-based attack vectors by means of
appropriate packet filtering. appropriate packet filtering.
2.1. Filtering Native IPv6 Traffic 2.1. Filtering Native IPv6 Traffic
Some layer-2 devices might have the ability to selectively filter Some layer-2 devices might have the ability to selectively filter
packets based on the type of layer-2 payload. When such packets based on the type of layer-2 payload. When such
functionality is available, IPv6 traffic could be blocked at those functionality is available, IPv6 traffic could be blocked at those
layer-2 devices by blocking, for example, Ethernet frames with the layer-2 devices by blocking, for example, Ethernet frames with the
Protocol Type field set to 0x86dd [IANA-ETHER]. We note, however, Protocol Type field set to 0x86dd [IANA-ETHER]. We note, however,
that enforcement of such filtering policy would break applications that blocking IPv6 at layer-2 might create problems that are
that expect IPv6 link-local connectivity to work properly (e.g. difficult to diagnose inclusive of intentional or incidental use of
Bonjour). link-local addressing (as in Multicast DNS/DNS-based Service
Discovery [RFC6762] [RFC6763]); sites that enforce such filtering
policy should keep that possibility in mind when debugging the
network.
SLAAC-based attacks [RFC3756] can be mitigated with technologies such SLAAC-based attacks [RFC3756] can be mitigated with technologies such
as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. In a as RA-Guard [RFC6105] [I-D.ietf-v6ops-ra-guard-implementation]. In a
similar way, DHCPv6-based attacks can be mitigated with technologies similar way, DHCPv6-based attacks can be mitigated with technologies
such as DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. However, such as DHCPv6-Shield [I-D.ietf-opsec-dhcpv6-shield]. However,
neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that neither RA-Guard nor DHCPv6-Shield can mitigate attack vectors that
employ IPv6 link-local addresses, since configuration of such employ IPv6 link-local addresses, since configuration of such
addresses does not rely on Router Advertisement messages or DCHPv6- addresses does not rely on Router Advertisement messages or
server messages. DCHPv6-server messages.
Administrators considering the filtering of native IPv6 traffic at Administrators considering the filtering of native IPv6 traffic at
layer-3 devices are urged to pay attention to the general layer-3 devices are urged to pay attention to the general
considerations for IPv6 traffic filtering discussed in Section 4. considerations for IPv6 traffic filtering discussed in Section 4.
If native IPv6 traffic is filtered at layer-2, local IPv6 nodes If native IPv6 traffic is filtered at layer-2, local IPv6 nodes
would only get to configure IPv6 link-local addresses. would only get to configure IPv6 link-local addresses.
In order to mitigate attacks based on native IPv6 traffic, IPv6 In order to mitigate attacks based on native IPv6 traffic, IPv6
security controls should be enforced on both IPv4 and IPv6 networks. security controls should be enforced on both IPv4 and IPv6 networks.
skipping to change at page 8, line 8 skipping to change at page 6, line 30
the corresponding transition/co-existence mechanisms be disabled on the corresponding transition/co-existence mechanisms be disabled on
each node connected to the organizational network. This would not each node connected to the organizational network. This would not
only prevent security breaches resulting from accidental use of these only prevent security breaches resulting from accidental use of these
mechanisms, but would also disable this functionality altogether, mechanisms, but would also disable this functionality altogether,
possibly mitigating vulnerabilities that might be present in the host possibly mitigating vulnerabilities that might be present in the host
implementation of these transition/co-existence mechanisms. implementation of these transition/co-existence mechanisms.
IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured IPv6-in-IPv4 tunnelling mechanisms (such as 6to4 or configured
tunnels) can generally be blocked by dropping IPv4 packets that tunnels) can generally be blocked by dropping IPv4 packets that
contain a Protocol field set to 41. Security devices such as NIDS contain a Protocol field set to 41. Security devices such as NIDS
might also include signatures that detect such transition/ might also include signatures that detect such transition/co-
co-existence traffic. existence traffic.
Administrators considering the filtering of transition/co-existence Administrators considering the filtering of transition/co-existence
traffic are urged to pay attention to the general considerations for traffic are urged to pay attention to the general considerations for
IPv6 traffic filtering discussed in Section 4. IPv6 traffic filtering discussed in Section 4.
We note that this document only covers standardized IPv6 tunneling We note that this document only covers standardized IPv6 tunneling
mechanisms, but does not aim to cover non-standard tunneling mechanisms, but does not aim to cover non-standard tunneling
mechanisms or IPsec-based [RFC4301] or SSL/TLS-based [RFC5246] mechanisms or IPsec-based [RFC4301] or SSL/TLS-based [RFC5246]
[RFC6101] tunneling of IPv6 packets. [RFC6101] tunneling of IPv6 packets.
skipping to change at page 9, line 49 skipping to change at page 8, line 25
traffic is allowed, then more finer-grained filtering rules could be traffic is allowed, then more finer-grained filtering rules could be
applied. For example, 6to4 traffic could be filtered by applying applied. For example, 6to4 traffic could be filtered by applying
filtering rules such as: filtering rules such as:
o Filter outgoing IPv4 packets that have the Destination Address set o Filter outgoing IPv4 packets that have the Destination Address set
to an address that belongs to the prefix 192.88.99.0/24. to an address that belongs to the prefix 192.88.99.0/24.
o Filter incoming IPv4 packets that have the Source Address set to o Filter incoming IPv4 packets that have the Source Address set to
an address that belongs to the prefix 192.88.99.0/24. an address that belongs to the prefix 192.88.99.0/24.
These rules assume that the corresponding nodes employ the These rules assume that the corresponding nodes employ the
"Anycast Prefix for 6to4 Relay Routers" [RFC3068]. "Anycast Prefix for 6to4 Relay Routers" [RFC3068].
It has been suggested that 6to4 relays send their packets with It has been suggested that 6to4 relays send their packets
their IPv4 Source Address set to 192.88.99.1. with their IPv4 Source Address set to 192.88.99.1.
o Filter outgoing IPv4 packets that have the Destination Address set o Filter outgoing IPv4 packets that have the Destination Address set
to the IPv4 address of well-known 6to4 relays. to the IPv4 address of well-known 6to4 relays.
o Filter incoming IPv4 packets that have the Source Address set to o Filter incoming IPv4 packets that have the Source Address set to
the IPv4 address of well-known 6to4 relays. the IPv4 address of well-known 6to4 relays.
These last two filtering policies will generally be unnecessary, These last two filtering policies will generally be unnecessary,
and possibly unfeasible to enforce (given the number of potential and possibly unfeasible to enforce (given the number of potential
6to4 relays, and the fact that many relays might remain unknown to 6to4 relays, and the fact that many relays might remain unknown to
skipping to change at page 12, line 5 skipping to change at page 10, line 30
filtering rules, since the information required to enforce them filtering rules, since the information required to enforce them
might be missing in the received fragments (which should be might be missing in the received fragments (which should be
expected if Teredo is being employed for malicious purposes). expected if Teredo is being employed for malicious purposes).
The most popular operating system that includes an implementation of The most popular operating system that includes an implementation of
Teredo in the default installation is Microsoft Windows. Microsoft Teredo in the default installation is Microsoft Windows. Microsoft
Windows obtains the Teredo server addresses (primary and secondary) Windows obtains the Teredo server addresses (primary and secondary)
by resolving the domain name teredo.ipv6.microsoft.com into DNS A by resolving the domain name teredo.ipv6.microsoft.com into DNS A
records. A network administrator might want to prevent Microsoft records. A network administrator might want to prevent Microsoft
Windows hosts from obtaining Teredo service by filtering at the Windows hosts from obtaining Teredo service by filtering at the
organizational firewall outgoing UDP datagrams (i.e. IPv4 packets organizational firewall outgoing UDP datagrams (i.e. IPv4 packets
with the Protocol field set to 17) that contain in the IPv4 with the Protocol field set to 17) that contain in the IPv4
Destination Address any of the IPv4 addresses that the domain name Destination Address any of the IPv4 addresses that the domain name
teredo.ipv6.microsoft.com maps to. Additionally, the firewall would teredo.ipv6.microsoft.com maps to. Additionally, the firewall would
filter incoming UDP datagrams from any of the IPv4 addresses to which filter incoming UDP datagrams from any of the IPv4 addresses to which
the domain names of well-known Teredo servers (such as the domain names of well-known Teredo servers (such as
teredo.ipv6.microsoft.com) resolve. teredo.ipv6.microsoft.com) resolve.
As these IPv4 addresses might change over time, an administrator As these IPv4 addresses might change over time, an administrator
should obtain these addresses when implementing the filtering should obtain these addresses when implementing the filtering
policy, and should also be prepared to keep this list up to date. policy, and should also be prepared to keep this list up to date.
skipping to change at page 18, line 28 skipping to change at page 13, line 48
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6
Tunnel Broker", RFC 3053, January 2001. Tunnel Broker", RFC 3053, January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001. RFC 3068, June 2001.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, Network Address Translations (NATs)", RFC 4380, February
February 2006. 2006.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795, Multicast Name Resolution (LLMNR)", RFC 4795, January
January 2007. 2007.
[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.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010. Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification", RFC
RFC 5969, August 2010. 5969, August 2010.
[RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the
Tunnel Setup Protocol (TSP)", RFC 5572, February 2010. Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.
8.2. Informative References 8.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC 793, September 1981. 793, September 1981.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations", RFC
RFC 2663, August 1999. 2663, August 1999.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, Discovery (ND) Trust Models and Threats", RFC 3756, May
May 2004. 2004.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for [RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, December 2004. 6to4", RFC 3964, December 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
skipping to change at page 19, line 46 skipping to change at page 15, line 22
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
RFC 6343, August 2011. RFC 6343, August 2011.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,
"IPv6 Support Required for All IP-Capable Nodes", BCP 177, "IPv6 Support Required for All IP-Capable Nodes", BCP 177,
RFC 6540, April 2012. RFC 6540, April 2012.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, 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-opsec-vpn-leakages] [I-D.ietf-opsec-vpn-leakages]
Gont, F., "Virtual Private Network (VPN) traffic leakages Gont, F., "Virtual Private Network (VPN) traffic leakages
in dual-stack hosts/ networks", in dual-stack hosts/ networks", draft-ietf-opsec-vpn-
draft-ietf-opsec-vpn-leakages-01 (work in progress), leakages-02 (work in progress), August 2013.
June 2013.
[I-D.ietf-opsec-dhcpv6-shield] [I-D.ietf-opsec-dhcpv6-shield]
Gont, F., Liu, W., and G. Velde, "DHCPv6-Shield: Gont, F., Will, W., and G. Velde, "DHCPv6-Shield:
Protecting Against Rogue DHCPv6 Servers", Protecting Against Rogue DHCPv6 Servers", draft-ietf-
draft-ietf-opsec-dhcpv6-shield-00 (work in progress), opsec-dhcpv6-shield-01 (work in progress), October 2013.
December 2012.
[I-D.massar-v6ops-ayiya] [I-D.massar-v6ops-ayiya]
Massar, J., "AYIYA: Anything In Anything", Massar, J., "AYIYA: Anything In Anything", draft-massar-
draft-massar-v6ops-ayiya-02 (work in progress), July 2004. v6ops-ayiya-02 (work in progress), July 2004.
[IANA-ETHER] [IANA-ETHER]
IANA, "Ether Types", 2012, IANA, , "Ether Types", 2012,
<http://www.iana.org/assignments/ethernet-numbers>. <http://www.iana.org/assignments/ethernet-numbers>.
[CERT2009] [CERT2009]
CERT, "Bypassing firewalls with IPv6 tunnels", 2009, <http CERT, , "Bypassing firewalls with IPv6 tunnels", 2009,
://www.cert.org/blogs/vuls/2009/04/ <http://www.cert.org/blogs/vuls/2009/04/
bypassing_firewalls_with_ipv6.html>. bypassing_firewalls_with_ipv6.html>.
[CORE2007] [CORE2007]
CORE, "OpenBSD's IPv6 mbufs remote kernel buffer CORE, , "OpenBSD's IPv6 mbufs remote kernel buffer
overflow", 2007, overflow", 2007,
<http://www.coresecurity.com/content/open-bsd-advisorie>. <http://www.coresecurity.com/content/open-bsd-advisorie>.
[Huston2010a] [Huston2010a]
Huston, G., "IPv6 Measurements", 2010, Huston, G., "IPv6 Measurements", 2010,
<http://www.potaroo.net/stats/1x1/>. <http://www.potaroo.net/stats/1x1/>.
[Huston2010b] [Huston2010b]
Huston, G., "Flailing IPv6", 2010, Huston, G., "Flailing IPv6", 2010,
<http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf>. <http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf>.
[Huston2012] [Huston2012]
Huston, G., "Bemused Eyeballs: Tailoring Dual Stack Huston, G., "Bemused Eyeballs: Tailoring Dual Stack
Applications for a CGN Environment", 2012, Applications for a CGN Environment", 2012,
<http://www.potaroo.net/ispcol/2012-05/notquite.pdf>. <http://www.potaroo.net/ispcol/2012-05/notquite.pdf>.
[Anderson2010] [Anderson2010]
Anderson, T., "Measuring and combating IPv6 brokenness", Anderson, T., "Measuring and combating IPv6 brokenness",
RIPE 61, Roma, November 2010, RIPE 61, Roma, November 2010, November 2010,
<http://ripe61.ripe.net/presentations/162-ripe61.pdf>. <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[Anderson2011] [Anderson2011]
Anderson, T., "IPv6 dual-stack client loss in Norway", Anderson, T., "IPv6 dual-stack client loss in Norway",
2011, <http://www.fud.no/ipv6/>. 2011, <http://www.fud.no/ipv6/>.
[CPNI-IPv6] [CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request). National Infrastructure, (available on request).
[IPv6-Toolkit] [IPv6-Toolkit]
"SI6 Networks' IPv6 Toolkit", , "SI6 Networks' IPv6 Toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>. <http://www.si6networks.com/tools/ipv6toolkit>.
[THC-IPV6] [THC-IPV6]
"The Hacker's Choice IPv6 Attack Toolkit", , "The Hacker's Choice IPv6 Attack Toolkit",
<http://www.thc.org/thc-ipv6/>. <http://www.thc.org/thc-ipv6/>.
[Waters2013] [Waters2013]
Waters, A., "The SLAAC Attack - using IPv6 as a weapon Waters, A., "The SLAAC Attack - using IPv6 as a weapon
against IPv4", 2013, <http://wirewatcher.wordpress.com/ against IPv4", 2013, <http://wirewatcher.wordpress.com/
2011/04/04/ 2011/04/04/the-slaac-attack-using-ipv6-as-a-weapon-
the-slaac-attack-using-ipv6-as-a-weapon-against-ipv4/>. against-ipv4/>.
[SixXS-stats] [SixXS-stats]
SixXS, "SixXS - IPv6 Deployment & Tunnel Broker :: SixXS, , "SixXS - IPv6 Deployment & Tunnel Broker ::
Statistics", 2013, <http://www.sixxs.net/misc/usage/>. Statistics", 2013, <http://www.sixxs.net/misc/usage/>.
Appendix A. Summary of filtering rules Appendix A. Summary of filtering rules
+------------+------------------------------------------------------+ +-------------------+-----------------------------------------------+
| Technology | Filtering rules | | Technology | Filtering rules |
+------------+------------------------------------------------------+ +-------------------+-----------------------------------------------+
| Native | EtherType 0x86DD | | Native IPv6 | EtherType 0x86DD |
| IPv6 | | +-------------------+-----------------------------------------------+
+------------+------------------------------------------------------+ | 6in4 | IP proto 41 |
| 6in4 | IP proto 41 | +-------------------+-----------------------------------------------+
+------------+------------------------------------------------------+ | 6over4 | IP proto 41 |
| 6over4 | IP proto 41 | +-------------------+-----------------------------------------------+
+------------+------------------------------------------------------+ | 6rd | IP proto 41 |
| 6rd | IP proto 41 | +-------------------+-----------------------------------------------+
+------------+------------------------------------------------------+ | 6to4 | IP proto 41 |
| 6to4 | IP proto 41 | +-------------------+-----------------------------------------------+
+------------+------------------------------------------------------+ | ISATAP | IP proto 41 |
| ISATAP | IP proto 41 | +-------------------+-----------------------------------------------+
+------------+------------------------------------------------------+ | Teredo | UDP Dest Port 3544 |
| Teredo | UDP Dest Port 3544 | +-------------------+-----------------------------------------------+
+------------+------------------------------------------------------+ | TB with TSP | (IP proto 41) || (UDP Dest Port 3653 || TCP |
| TB with | (IP proto 41) || (UDP Dest Port 3653 || TCP Dest | | | Dest Port 3653) |
| TSP | Port 3653) | +-------------------+-----------------------------------------------+
+------------+------------------------------------------------------+ | AYIYA | UDP Dest Port 5072 || TCP Dest Port 5072 |
| AYIYA | UDP Dest Port 5072 || TCP Dest Port 5072 | +-------------------+-----------------------------------------------+
+------------+------------------------------------------------------+
Table 1: Summary of filtering rules Table 1: Summary of filtering rules
NOTE: the table above describes general and simple filtering rules NOTE: the table above describes general and simple filtering rules
for blocking the corresponding traffic. More finer-grained rules for blocking the corresponding traffic. More finer-grained rules
might be available in each of the corresponding sections of this might be available in each of the corresponding sections of this
document. document.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks / UTN-FRH SI6 Networks / UTN-FRH
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: http://www.si6networks.com
 End of changes. 36 change blocks. 
112 lines changed or deleted 114 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/