draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01.txt   draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02.txt 
Operational Security Capabilities for F. Gont Operational Security Capabilities for F. Gont
IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH IP Network Infrastructure (opsec) SI6 Networks / UTN-FRH
Internet-Draft W. Liu Internet-Draft W. Liu
Intended status: Informational Huawei Technologies Intended status: Informational Huawei Technologies
Expires: June 15, 2013 December 12, 2012 Expires: July 1, 2013 December 28, 2012
Security Implications of IPv6 on IPv4 Networks Security Implications of IPv6 on IPv4 Networks
draft-ietf-opsec-ipv6-implications-on-ipv4-nets-01 draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 June 15, 2013. This Internet-Draft will expire on July 1, 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
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
2. Security Implications of Native IPv6 Support . . . . . . . . . 4 2. Security Implications of Native IPv6 Support . . . . . . . . . 5
2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 4 2.1. Filtering Native IPv6 Traffic . . . . . . . . . . . . . . 5
3. Security Implications of Tunneling Mechanisms . . . . . . . . 6 3. Security Implications of Tunneling Mechanisms . . . . . . . . 7
3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Filtering 6in4 . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 7 3.2. Filtering 6over4 . . . . . . . . . . . . . . . . . . . . . 8
3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Filtering 6rd . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Filtering 6to4 . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 9 3.5. Filtering ISATAP . . . . . . . . . . . . . . . . . . . . . 10
3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 9 3.6. Filtering Teredo . . . . . . . . . . . . . . . . . . . . . 10
3.7. Filtering Tunnel Broker with Tunnel Setup Protocol 3.7. Filtering Tunnel Broker with Tunnel Setup Protocol
(TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 11 (TSP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. Additional Considerations when Filtering IPv6 Traffic . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Summary of filtering rules . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Summary of filtering rules . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Most general-purpose operating systems implement and enable by Most general-purpose operating systems implement and enable by
default native IPv6 [RFC2460] support and a number of transition/ default native IPv6 [RFC2460] support and a number of transition/
co-existence technologies. In those cases in which the corresponding co-existence technologies. In those cases in which the corresponding
devices are deployed on networks that are assumed to be IPv4-only, devices are deployed on networks that are assumed to be IPv4-only,
native IPv6 support and/or IPv6 transition/co-existence technologies native IPv6 support and/or IPv6 transition/co-existence technologies
could be leveraged by local or remote attackers for a number of could be leveraged by local or remote attackers for a number of
(illegitimate) purposes. For example, (illegitimate) purposes. For example,
skipping to change at page 3, line 44 skipping to change at page 3, line 44
that have been initiated from the internal network). that have been initiated from the internal network).
o IPv6 support might, either inadvertently or as a result of a o IPv6 support might, 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 traffic. Among such controls is the enforcement of on IPv4-tunneled traffic. Among such controls is the enforcement of
filtering policies, such that undesirable traffic is blocked. filtering policies, such that undesirable traffic is blocked. While
IPv6 widespread/global IPv6 deployment has been slower than expected,
it is nevertheless happening, and thus filtering IPv6 traffic
(whether native or transition/co-existence) to mitigate IPv6 security
implications on IPv4 networks should only be considered as a
temporary solution to protect a network until IPv6 is deployed. Only
in some exceptional cases (such as military operations networks)
could this approach to mitigating the aforementioned security
implications be thought of as a longer-term strategy.
This document discusses the security implications of IPv6 and IPv6 This document discusses the security implications of IPv6 and IPv6
transition/co-existence technologies on (allegedly) IPv4-only transition/co-existence technologies on (allegedly) IPv4-only
networks, and provides guidance on how to mitigate the aforementioned networks, and provides guidance on how to mitigate the aforementioned
issues. issues.
2. Security Implications of Native IPv6 Support 2. Security Implications of Native IPv6 Support
Most popular operating systems include IPv6 support that is enabled Most popular operating systems include IPv6 support that is enabled
by default. This means that even if a network is expected to be by default. This means that even if a network is expected to be
skipping to change at page 5, line 17 skipping to change at page 6, line 17
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 DCHPv6-
server messages. server messages.
Administrators considering the filtering of native IPv6 traffic at
layer-3 devices are urged to pay attention to the general
considerations for IPv6 traffic filtering discussed in Section 4.
If native IPv6 traffic is filtered at layer-2, local IPv6 nodes
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.
The aforementioned controls might include: deploying IPv6-enabled The aforementioned controls might include: deploying IPv6-enabled
NIDS, implementing IPv6 firewalling, etc. NIDS, implementing IPv6 firewalling, etc.
In some very specific scenarios (e.g., military operations In some very specific scenarios (e.g., military operations
networks) in which only IPv4 service might be desired, a network networks) in which only IPv4 service might be desired, a network
administrator might want to disable IPv6 support in all the administrator might want to disable IPv6 support in all the
communicating devices. communicating devices.
skipping to change at page 7, line 6 skipping to change at page 8, line 6
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-existence traffic. co-existence traffic.
Administrators considering the filtering of transition/co-existence
traffic are urged to pay attention to the general considerations for
IPv6 traffic filtering discussed in Section 4
3.1. Filtering 6in4 3.1. Filtering 6in4
Probably the most basic type of tunnel employed for connecting IPv6 Probably the most basic type of tunnel employed for connecting IPv6
"islands" is the so-called "6in4", in which IPv6 packets are "islands" is the so-called "6in4", in which IPv6 packets are
encapsulated within IPv4 packets. These tunnels are typically result encapsulated within IPv4 packets. These tunnels are typically result
from manual configuration at the two tunnel endpoints. from manual configuration at the two tunnel endpoints.
6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol 6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol
field of 41. field of 41.
skipping to change at page 8, line 16 skipping to change at page 9, line 24
set to 41. set to 41.
3.4. Filtering 6to4 3.4. Filtering 6to4
6to4 [RFC3056] is an address assignment and router-to-router, host- 6to4 [RFC3056] is an address assignment and router-to-router, host-
to-router, and router-to-host automatic tunnelling mechanism that is to-router, and router-to-host automatic tunnelling mechanism that is
meant to provide IPv6 connectivity between IPv6 sites and hosts meant to provide IPv6 connectivity between IPv6 sites and hosts
across the IPv4 Internet. across the IPv4 Internet.
The security considerations for 6to4 are discussed in detail in The security considerations for 6to4 are discussed in detail in
[RFC3964]. [RFC3964]. [RFC6343] provides advice to network operators about
6to4 (some of which relates to security mitigations).
As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4, As discussed in Section 3, all IPv6-in-IPv4 traffic, including 6to4,
could be easily blocked by filtering IPv4 that contain their Protocol could be easily blocked by filtering IPv4 that contain their Protocol
field set to 41. This is the most effective way of filtering such field set to 41. This is the most effective way of filtering such
traffic. traffic.
If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4 If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4
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
"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 with
their IPv4 Source Address set to 192.88.99.1. 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,
skipping to change at page 12, line 5 skipping to change at page 13, line 5
TSP can use either TCP or UDP as the transport protocol. In both TSP can use either TCP or UDP as the transport protocol. In both
cases TSP uses port number 3653, which has been assigned by the IANA cases TSP uses port number 3653, which has been assigned by the IANA
for this purpose. As a result, TSP (the Tunnel Broker control for this purpose. As a result, TSP (the Tunnel Broker control
channel) can be blocked by blocking TCP and UDP packets originating channel) can be blocked by blocking TCP and UDP packets originating
from the local network and destined to UDP port 3653 or TCP port from the local network and destined to UDP port 3653 or TCP port
3653. Additionally, the data channel can be blocked by blocking UDP 3653. Additionally, the data channel can be blocked by blocking UDP
packets originated from the local network and destined to UDP port packets originated from the local network and destined to UDP port
3653, and IPv4 packets with a Protocol field set to 41. 3653, and IPv4 packets with a Protocol field set to 41.
4. IANA Considerations 4. Additional Considerations when Filtering IPv6 Traffic
IPv6 deployments in the Internet are continually increasing, and some
hosts default to preferring IPv6 connectivity whenever it is
available. This is likely to cause IPv6-capable hosts to attempt to
reach an ever-increasing number of popular destinations via IPv6,
even if this IPv6 connectivity is provided relies on a transition
technology over an IPv4-only network.
A large source of IPv6 brokenness today comes from nodes that believe
that they have functional IPv6 connectivity, but the path to their
destination fails somewhere upstream [Anderson2010] [Anderson2011]
[Huston2010b] [Huston2012]. Upstream filtering of transition
technologies or situations where a misconfigured node attempts to
"provide" native IPv6 service on a given network without proper
upstream IPv6 connectivity may result in hosts attempting to reach
remote nodes via IPv6, and depending on the absence or presence and
specific implementation details of "Happy Eyeballs" [RFC6555], there
might be a non-trivial timeout period before the host falls back to
IPv4 [Huston2010a] [Huston2012].
For this reason, networks attempting to prevent IPv6 traffic from
traversing their devices should consider configuring their local
recursive DNS servers to ignore queries for AAAA DNS records, or even
consider filtering AAAA records at the network ingress point to
prevent end hosts from attempting their own DNS resolution. This
will ensure that end hosts which are on an IPv4-only network will
only receive DNS A records, and they will be unlikely to attempt to
use (likely broken) IPv6 connectivity to reach their desired
destinations. Additionally, it is generally deemed as good practice
to signal the packet drop to the source node, such that the source
node is able to react to such packet drop in a more appropriate and
timely way.
A firewall could signal the packet drop by means of an ICMPv6
error message (or TCP [RFC0793] RST segment if appropriate), such
that the source node can e.g. quickly react as described in
[RFC5461].
For obvious reasons, if the traffic being filtered is IPv6
transition/co-existence traffic, the signalling packet should be
sent by means of the corresponding IPv6 transition/co-existence
technology.
5. IANA Considerations
There are no IANA registries within this document. The RFC-Editor There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an can remove this section before publication of this document as an
RFC. RFC.
5. Security Considerations 6. Security Considerations
This document discusses the security implications of IPv6 on IPv4 This document discusses the security implications of IPv6 on IPv4
networks, and describes a number of techniques to mitigate the networks, and describes a number of techniques to mitigate the
aforementioned issues. In general, the possible mitigations boil aforementioned issues. In general, the possible mitigations boil
down to enforcing on native IPv6 and IPv6 transition/co-existence down to enforcing on native IPv6 and IPv6 transition/co-existence
traffic the same security policies currently enforced for IPv4 traffic the same security policies currently enforced for IPv4
traffic, and/or blocking the aforementioned traffic when it is deemed traffic, and/or blocking the aforementioned traffic when it is deemed
as undesirable. as undesirable.
6. Acknowledgements 7. Acknowledgements
The author would like to thank (in alphabetical order) Ran Atkinson, The authors would like to thank Wes George, who contributed most of
Panos Kampanakis, David Malone, Arturo Servin, Donald Smith, Tina the text that comprises Section 4 of this document.
Tsou, and Eric Vyncke, for providing valuable comments on earlier
versions of this document.
This document resulted from the project "Security Assessment of the The authors would like to thank (in alphabetical order) Ran Atkinson,
Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by Brian Carpenter, Panos Kampanakis, David Malone, Arturo Servin,
Fernando Gont on behalf of the UK Centre for the Protection of Donald Smith, Tina Tsou, and Eric Vyncke, for providing valuable
National Infrastructure (CPNI). comments on earlier versions of this document.
Fernando Gont would like to thank the UK CPNI for their continued This document is based on the results of the the project "Security
support. Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6],
carried out by Fernando Gont on behalf of the UK Centre for the
Protection of National Infrastructure (CPNI). Fernando Gont would
like to thank the UK CPNI for their continued support.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999. Domains without Explicit Tunnels", RFC 2529, March 1999.
[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",
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 2006. February 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 2007. January 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,
skipping to change at page 15, line 43 skipping to change at page 17, line 46
[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 5969, August 2010. RFC 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.
7.2. Informative References 8.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 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 2663, August 1999. RFC 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 2004. May 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.
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461,
February 2009.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011. February 2011.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011. Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
RFC 6343, August 2011.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
[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-guard-implementation-07 (work in draft-ietf-v6ops-ra-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-leakages-00 (work in progress), draft-ietf-opsec-vpn-leakages-00 (work in progress),
skipping to change at page 16, line 47 skipping to change at page 19, line 13
[CERT2009] [CERT2009]
CERT, "Bypassing firewalls with IPv6 tunnels", 2009, <http CERT, "Bypassing firewalls with IPv6 tunnels", 2009, <http
://www.cert.org/blogs/vuls/2009/04/ ://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]
Huston, G., "IPv6 Measurements", 2010,
<http://www.potaroo.net/stats/1x1/>.
[Huston2010b]
Huston, G., "Flailing IPv6", 2010,
<http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf>.
[Huston2012]
Huston, G., "Bemused Eyeballs: Tailoring Dual Stack
Applications for a CGN Environment", 2012,
<http://www.potaroo.net/ispcol/2012-05/notquite.pdf>.
[Anderson2010]
Anderson, T., "Measuring and combating IPv6 brokenness",
RIPE 61, Roma, November 2010,
<http://ripe61.ripe.net/presentations/162-ripe61.pdf>.
[Anderson2011]
Anderson, T., "IPv6 dual-stack client loss in Norway",
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]
"IPv6 Toolkit", "IPv6 Toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>. <http://www.si6networks.com/tools/ipv6toolkit>.
[THC-IPV6] [THC-IPV6]
 End of changes. 23 change blocks. 
39 lines changed or deleted 145 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/