RFC 7123

Security Implications of IPv6 on IPv4 Networks

📅 published February 2014, from ietf

RFC 7123: Security Implications of IPv6 on IPv4 Networks 🎀

okay bestie, this one is by F. Gont (SI6 Networks/UTN-FRH) and W. Liu (Huawei Technologies) 💅 It's marked Informational, so it's sharing good info, not a rule you have to follow. It came out in February 2014 and has ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's just vibing on its own ✨

Abstract

okay so the abstract is giving: this doc talks about the security risks when IPv6 is turned on natively, and when IPv6 transition or coexistence tech is used, on networks that are supposed to be "IPv4-only" 👀 It also suggests ways to mitigate those problems 🛡️

Status of This Memo

ngl this part is a lot of official stuff 🙈 The doc is not an Internet Standards Track spec. It's published for information only 🧚 It's still an IETF product that has consensus of the IETF community, got public review, and was approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🤓

For the current status, errata, and feedback, go to http://www.rfc-editor.org/info/rfc7123 💌

the copyright is Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🔒 It's under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. Read those carefully, bestie, they explain your rights 📜 Code pulled out of this doc has to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and it comes with no warranty, same as the Simplified BSD License says 💖

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Security Implications of Native IPv6 Support  . . . . . . . .   4
  2.1.  Filtering Native IPv6 Traffic . . . . . . . . . . . . . .   4
3.  Security Implications of Tunneling Mechanisms . . . . . . . .   5
  3.1.  Filtering 6in4  . . . . . . . . . . . . . . . . . . . . .   6
  3.2.  Filtering 6over4  . . . . . . . . . . . . . . . . . . . .   7
  3.3.  Filtering 6rd . . . . . . . . . . . . . . . . . . . . . .   7
  3.4.  Filtering 6to4  . . . . . . . . . . . . . . . . . . . . .   8
  3.5.  Filtering ISATAP  . . . . . . . . . . . . . . . . . . . .   9
  3.6.  Filtering Teredo  . . . . . . . . . . . . . . . . . . . .   9
  3.7.  Filtering Tunnel Broker with Tunnel Setup Protocol (TSP)   11
  3.8.  Filtering AYIYA . . . . . . . . . . . . . . . . . . . . .  11
4.  Additional Considerations when Filtering IPv6 Traffic . . . .  12
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
Appendix A.  Summary of Filtering Rules . . . . . . . . . . . . .  18

1. Introduction ✨

okay so most general-purpose operating systems turn on native IPv6 support, plus a bunch of transition and coexistence tech, by default 🌈 [RFC2460] The goal is for all nodes to support IPv6, and that's becoming best current practice [RFC6540] 💜 Some enterprise networks might still hold off on actually using IPv6 for now, and that's valid 🫶

This doc describes operational practices for stopping security holes in enterprise networks that come from IPv6 showing up when nobody planned for it 🔍 It only applies to enterprise networks, meaning networks where the operator isn't giving you a general-purpose internet and instead runs a business-specific network 🏢 The solutions here aren't practical for home networks, and they aren't a fit for provider networks like ISPs, mobile providers, WiFi hotspot providers, or any other public internet service 🚫

So when IPv6-enabled devices get deployed on enterprise networks that are meant to be IPv4-only, native IPv6 support and/or IPv6 transition or coexistence tech can be used by local or remote attackers for all kinds of shady stuff 😭 Here's the tea:

  • A Network Intrusion Detection System (NIDS) might be set up to catch attack patterns in IPv4 traffic, but it might miss those same patterns when a transition or coexistence tech is used to sneak them through 💀
  • An IPv4 firewall might enforce a specific security policy in IPv4, but it might not be able to enforce the same policy in IPv6 🙈
  • A NIDS or firewall might support both IPv4 and IPv6, but it might not be set up to apply to IPv6 traffic the same controls and policies it applies to IPv4 traffic 🔥
  • Some transition or coexistence mechanisms could make an internal host with limited IPv4 connectivity globally reachable over IPv6, which means more host exposure, possibly in ways nobody expected 👀
NOTE: Some transition/coexistence mechanisms (notably Teredo) are designed to traverse Network Address Port Translation (NAPT) [RFC2663] devices, which lets incoming IPv6 connections from the Internet reach hosts behind the organizational firewall or NAPT. In many deployments, NAPT gives a minimum level of protection by only allowing communication that was started from the internal network. 🧚
  • IPv6 support could, by accident or because of a deliberate attack, cause Virtual Private Network (VPN) traffic leaks if dual-stacked hosts use IPv6-unaware VPN software [VPN-LEAKS] 🚨

okay so, most of these security problems can be fixed by enforcing security controls on native IPv6 traffic and on IPv4-tunneled IPv6 traffic 🛡️ One of those controls is enforcing filtering policies to block the bad traffic 💅 IPv6 deployment has been slower than people expected, but it's happening, periodt 🌸 So filtering IPv6 traffic, whether it's native or transition or coexistence traffic, to deal with IPv6 security problems on IPv4 networks should (generally) only be treated as a temporary measure until IPv6 is deployed ⏳

NOTE: The security controls mentioned above should think about not just network-based solutions, but also host-based solutions (such as, e.g., personal firewalls). 💖

2. Security Implications of Native IPv6 Support 🦋

most popular operating systems ship with IPv6 support turned on by default 👑 So even if a network is supposed to be IPv4-only, a lot of its infrastructure is probably IPv6-enabled anyway 🙈 For example, hosts will probably have at least link-local IPv6 connectivity, and attackers on the local network could totally exploit that 😳

Also, unless you take the right precautions, an attacker on an "IPv4-only" local network could pretend to be a local router and get local hosts to turn on their non-link-local IPv6 connectivity, for instance by sending Router Advertisement messages 📡 That could get around security controls that were only enforced on IPv4 communications 🙅‍♀️

NOTE: [THC-IPV6] and [IPv6-Toolkit] include tools that do this attack (along with a bunch of others). [Waters2011] shows an example of how this can be done with publicly available tools. 🧰

Native IPv6 support could also lead to VPN traffic leaks when hosts use VPN software that doesn't support IPv6 and also doesn't do anything about IPv6 traffic 🫠 [VPN-LEAKS] describes this problem and some ways to handle it 📖

In general, networks should enforce the same security policies on native IPv6 traffic that they already enforce on IPv4 traffic ✅ But if a network hasn't deployed IPv6 yet and enforcing those policies is considered infeasible, a network administrator might mitigate IPv6-based attack vectors with appropriate packet filtering 🎀

2.1. Filtering Native IPv6 Traffic 🧁

some layer-2 devices can selectively filter packets based on the type of layer-2 payload 🔎 When that's available, IPv6 traffic could be blocked at those layer-2 devices by blocking, for example, Ethernet frames whose Protocol Type field is set to 0x86dd [IANA-ETHER] 🚫 Heads up though: blocking IPv6 at layer-2 might cause problems that are hard to diagnose, including intentional or incidental use of link-local addressing (like in Multicast DNS/DNS-based Service Discovery [RFC6762] [RFC6763]). Sites that enforce this kind of filtering policy should keep that in mind when they debug the network 🐛

Attacks based on Stateless Address Autoconfiguration (SLAAC) [RFC3756] can be mitigated with stuff like Router Advertisement Guard (RA-Guard) [RFC6105] [RA-GRD-IMP] 🛡️ In a similar way, DHCPv6-based attacks can be mitigated with things like DHCPv6-Shield [SHIELD]. BUT, and this is important bestie, both RA-Guard and DHCPv6-Shield can't stop attack vectors that use IPv6 link-local addresses, because setting up those addresses doesn't rely on Router Advertisement messages or DHCPv6-server messages 😤

Administrators thinking about filtering native IPv6 traffic at layer-3 devices should pay close attention to the general considerations for IPv6 traffic filtering covered in Section 4 📚

NOTE: If native IPv6 traffic is filtered at layer-2, local IPv6 nodes would only be able to configure IPv6 link-local addresses. 🌙

To mitigate attacks based on native IPv6 traffic, IPv6 security controls should be enforced on both IPv4 and IPv6 networks 💜 Those controls might include deploying an IPv6-enabled NIDS, implementing IPv6 firewalling, and so on ✨

NOTE: In some very specific scenarios (e.g., military operations networks) where only IPv4 service is wanted, a network administrator might want to disable IPv6 support in all the communicating devices. 🫡

3. Security Implications of Tunneling Mechanisms 🎀

okay so, unless tunneling mechanisms are properly managed, they can cause some seriously negative security implications 😭 they might increase host exposure, might get leveraged to evade security controls, might contain protocol-based vulnerabilities, and/or the code might have bugs with security implications. yikes 💀

NOTE: [RFC6169] describes the security implications of tunneling mechanisms in detail. Of the plethora of tunneling mechanisms that have so far been standardized and widely implemented, the so-called "automatic tunneling" mechanisms (such as Teredo, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), and 6to4) are of particular interest from a security standpoint, since they might be employed without prior consent or action of the user or network administrator. 🦋

Tunneling mechanisms should be a concern not only to network administrators that have consciously deployed them, but also to those who have not deployed them, bestie, because these mechanisms might be leveraged to bypass their security policies. 😱

NOTE: [CERT2009] contains some examples of how tunnels can be leveraged to bypass firewall rules. 🔥

The aforementioned issues could be mitigated by applying the common security practice of only allowing traffic deemed as "necessary" (i.e., the so-called "default deny" policy). 💅 So when that policy is enforced, IPv6 transition/coexistence traffic would be blocked by default and would only be allowed as a result of an explicit decision. Very clean, very intentional, very main character 👑

NOTE: It should be noted that this type of policy is usually enforced on a network that is the target of such traffic (such as an enterprise network). IPv6 transition traffic should generally never be filtered, e.g., by an ISP when it is transit traffic. 🙈

In those scenarios in which transition/coexistence traffic is meant to be blocked, it is highly recommended that, in addition to enforcing filtering policies at the organizational perimeter, the corresponding transition/coexistence mechanisms be disabled on each node connected to the organizational network. 🫶 This would not only prevent security breaches resulting from accidental use of these mechanisms, but would also disable this functionality altogether, possibly mitigating vulnerabilities that might be present in the host implementation of these transition/coexistence mechanisms. Double protection, iconic ✨

IPv6-in-IPv4 tunneling mechanisms (such as 6to4 or configured tunnels) can generally be blocked by dropping IPv4 packets that contain a Protocol field set to 41. Security devices such as NIDS might also include signatures that detect such transition/coexistence traffic. 🧚

Administrators considering the filtering of transition/coexistence traffic are urged to pay attention to the general considerations for IPv6 traffic filtering discussed in Section 4. Read that part, it's important 🌸

We note that this document only covers standardized IPv6 tunneling mechanisms. It does not aim to cover non-standard tunneling mechanisms or tunneling based on IPsec [RFC4301] or on SSL/TLS [RFC5246] [RFC6101]. Not our tea today, but good to know 🍓

3.1. Filtering 6in4

Probably the most basic type of tunnel employed for connecting IPv6 "islands" is the so-called "6in4", in which IPv6 packets are encapsulated within IPv4 packets. These tunnels typically result from manual configuration at the two tunnel endpoints. Simple, but still a whole vibe 🌈

6in4 tunnels can be blocked by blocking IPv4 packets with a Protocol field of 41. 💖

3.2. Filtering 6over4

[RFC2529] specifies a mechanism known as 6over4 or 'IPv6 over IPv4' (or colloquially as 'virtual Ethernet'), which comprises a set of mechanisms and policies to allow isolated IPv6 hosts located on physical links with no directly connected IPv6 router to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. ✨

NOTE: This transition technology has never been widely deployed because of the low level of deployment of multicast in most networks. 💀

6over4 encapsulates IPv6 packets in IPv4 packets with their Protocol field set to 41. As a result, simply filtering all IPv4 packets that have a Protocol field equal to 41 will filter 6over4 (along with many other transition technologies). 🧹

A more selective filtering could be enforced such that 6over4 traffic is filtered while other transition traffic is still allowed. Such a filtering policy would block all IPv4 packets that have their Protocol field set to 41, and that have a Destination Address that belongs to the prefix 239.0.0.0/8. Very precise, very intentional 🎯

This filtering policy basically blocks 6over4 Neighbor Discovery traffic directed to multicast addresses, thus preventing SLAAC, address resolution, etc. Additionally, it would prevent the 6over4 multicast addresses from being leveraged for the purpose of network reconnaissance. Nobody gets to snoop around on our network 🙅‍♀️

3.3. Filtering 6rd

6rd builds upon the mechanisms of 6to4 to enable the rapid deployment of IPv6 on IPv4 infrastructures, while avoiding some downsides of 6to4. Usage of 6rd was originally documented in [RFC5569], and the mechanism was generalized to other access technologies and formally standardized in [RFC5969]. Glow-up energy 🌟

6rd can be blocked by blocking IPv4 packets with the Protocol field set to 41. 🔒

3.4. Filtering 6to4

6to4 [RFC3056] is an address assignment and router-to-router, host-to-router, and router-to-host automatic tunneling mechanism that is meant to provide IPv6 connectivity between IPv6 sites and hosts across the IPv4 Internet. 🌍

NOTE: The security considerations for 6to4 are discussed in detail in [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, could be easily blocked by filtering IPv4 packets that contain their Protocol field set to 41. This is the most effective way of filtering such traffic. Simple answer, no notes 💅

If 6to4 traffic is meant to be filtered while other IPv6-in-IPv4 traffic is allowed, then more finer-grained filtering rules could be applied. For example, 6to4 traffic could be filtered by applying filtering rules such as:

  • Filter outgoing IPv4 packets that have the Destination Address set to an address that belongs to the prefix 192.88.99.0/24.
  • Filter incoming IPv4 packets that have the Source Address set to an address that belongs to the prefix 192.88.99.0/24.
NOTE: 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 their IPv4 Source Address set to 192.88.99.1. 🧠
  • Filter outgoing IPv4 packets that have the Destination Address set to the IPv4 address of well-known 6to4 relays.
  • Filter incoming IPv4 packets that have the Source Address set to the IPv4 address of well-known 6to4 relays.

These last two filtering policies will generally be unnecessary, and possibly infeasible to enforce (given the number of potential 6to4 relays, and the fact that many relays might remain unknown to the network administrator). If anything, they should be applied with the additional requirement that such IPv4 packets have their Protocol field set to 41 to avoid the case where other services available at the same IPv4 address as a 6to4 relay are mistakenly made inaccessible. Don't accidentally block your own besties 🙈

If the filtering device has capabilities to inspect the payload of IPv4 packets, then the following filtering rules could be enforced:

  • Filter outgoing IPv4 packets that have their Protocol field set to 41, and that have an IPv6 Source Address (embedded in the IPv4 payload) that belongs to the prefix 2002::/16.
  • Filter incoming IPv4 packets that have their Protocol field set to 41, and that have an IPv6 Destination address (embedded in the IPv4 payload) that belongs to the prefix 2002::/16.

3.5. Filtering ISATAP

ISATAP [RFC5214] is an Intra-site tunneling protocol, and thus it is generally expected that such traffic will not traverse the organizational firewall of an IPv4-only network. Nevertheless, ISATAP can be easily blocked by blocking IPv4 packets with a Protocol field of 41. Blocked, but make it make sense 🎀

The most popular operating system that includes an implementation of ISATAP in the default installation is Microsoft Windows. Microsoft Windows obtains the ISATAP router address by resolving the domain name isatap.<localdomain> to DNS A resource records. Additionally, it tries to learn the ISATAP router address by employing Link-Local Multicast Name Resolution (LLMNR) [RFC4795] to resolve the name "isatap". As a result, blocking ISATAP by preventing hosts from successfully performing name resolution for the aforementioned names and/or by filtering packets with specific IPv4 destination addresses is both difficult and undesirable. Windows really out here being a lot 💀✨

3.6. Filtering Teredo 🦋

okay so Teredo [RFC4380] is this address assignment and automatic tunneling technology that gives IPv6 connectivity to dual-stack nodes stuck behind one or more Network Address Port Translation (NAPT) [RFC2663] devices. it works by wrapping IPv6 packets inside IPv4-based UDP datagrams 🎀 Teredo is meant to be a 'last-resort' IPv6 connectivity technology, so it's only used when stuff like 6to4 can't be deployed (for example, because the edge device hasn't been given a public IPv4 address) 💀

As noted in [RFC4380], in order for a Teredo client to configure its Teredo IPv6 address, it must contact a Teredo server through the Teredo service port (UDP port number 3544) 🧚

So to stop the Teredo initialization process from succeeding (and therefore stop Teredo from being used), an organizational firewall could filter outgoing UDP packets with a Destination Port of 3544 💅

NOTE: it's clear that this filtering policy doesn't stop an attacker from running their own Teredo server on the public Internet, using a non-standard UDP port for the Teredo service port (aka any port number other than 3544) 🙈

If the filtering device can inspect the payload of IPv4 packets, the following (additional) filtering policy could be enforced:

  • Filter outgoing IPv4/UDP packets that embed an IPv6 packet with the Version field set to 6, and an IPv6 Source Address that belongs to the prefix 2001::/32.
  • Filter incoming IPv4/UDP packets that embed an IPv6 packet with the Version field set to 6, and an IPv6 Destination Address that belongs to the prefix 2001::/32.
NOTE: these two filtering rules could, at least in theory, result in false positives 😭 they'd also generally require the filtering device to reassemble fragments before enforcing the rules, since the info needed might be missing from the received fragments (which is exactly what you'd expect if Teredo is being used for malicious purposes) 👀

The most popular operating system that ships with Teredo in the default installation is Microsoft Windows 👑 Windows gets the Teredo server addresses (primary and secondary) by resolving the domain name teredo.ipv6.microsoft.com into DNS A records. so a network admin might want to stop Windows hosts from getting Teredo service by filtering, at the organizational firewall, outgoing UDP datagrams (aka IPv4 packets with the Protocol field set to 17) whose IPv4 Destination Address is any of the IPv4 addresses that teredo.ipv6.microsoft.com maps to (or the IPv4 address of any well-known Teredo server) ✨ the firewall should also filter incoming UDP datagrams from any of the IPv4 addresses that the domain names of well-known Teredo servers (such as teredo.ipv6.microsoft.com) resolve to.

NOTE: these IPv4 addresses might change over time, so an administrator should grab them when implementing the filtering policy, and should also be ready to keep the list up to date 🍓 the addresses can be easily obtained from a UNIX host by running the command dig teredo.ipv6.microsoft.com a (without quotes), where dig(1) is a free-software tool (part of the "dnsutils" package) made by the Internet Software Consortium (ISC) 🌸

It should be noted that even with all these filtering policies in place, a node on the internal network might still be able to talk to some Teredo clients 🫣 that is, it could configure an IPv6 address itself (without even contacting a Teredo server), and it might send Teredo traffic to those peers that don't need the host's Teredo server involved (e.g., Teredo clients behind a cone NAT) 🦋

3.7. Filtering Tunnel Broker with Tunnel Setup Protocol (TSP) 🌈

okay the tunnel broker model is all about dynamic configuration of tunnels between a tunnel client and a tunnel server 💖 the tunnel broker gives you a control channel for creating, deleting, or updating a tunnel between the client and the server. it may also register the user's IPv6 address and name in the DNS 🧚 once the tunnel is set up, data can flow between the tunnel client and the tunnel server. [RFC3053] describes the tunnel broker model, while [RFC5572] specifies the Tunnel Setup Protocol (TSP), which clients can use to talk to the Tunnel Broker 🫶

TSP can use either TCP or UDP as its transport protocol. in both cases, TSP uses port number 3653, which the IANA assigned for this exact purpose 📚 so TSP (aka the Tunnel Broker control channel) can be blocked by blocking TCP and UDP packets that originate from the local network and are destined to UDP port 3653 or TCP port 3653. the data channel can also be blocked, by blocking UDP packets originated from the local network and destined to UDP port 3653, and IPv4 packets with a Protocol field set to 41 🔥

3.8. Filtering AYIYA 🎀

AYIYA ("Anything In Anything") [AYIYA] lets you tunnel packets across Network Address Port Translation (NAPT) [RFC2663] devices 🌸 the spec for this tunneling mechanism was never published as an RFC, but it's still widely deployed [SixXS-stats] 👑 iconic for something that's not even an RFC, honestly.

AYIYA can be blocked by blocking TCP and UDP packets that originate from the local network and are destined to UDP port 5072 or TCP port 5072 💅

4. Additional Considerations when Filtering IPv6 Traffic 🌈

okay IPv6 deployments on the Internet keep going up, and some hosts default to preferring IPv6 connectivity whenever it's available 📈 that means IPv6-capable hosts are likely to try reaching a growing number of popular destinations over IPv6, even when that IPv6 connectivity relies on a transition technology running over an "IPv4-only" network 😬

a big source of IPv6 brokenness right now comes from nodes that believe they have working IPv6 connectivity, when the path to their destination actually fails somewhere upstream [Anderson2010] [Anderson2011] [Huston2010b] [Huston2012] 💀 upstream filtering of transition technologies, or a misconfigured node trying to "provide" native IPv6 service on a network without proper upstream IPv6 connectivity, can make hosts try to reach remote nodes over IPv6. depending on whether "Happy Eyeballs" [RFC6555] is present or absent and on its specific implementation details, there might be a non-trivial timeout period before the host falls back to IPv4 [Huston2010a] [Huston2012] 😭

so for networks that want to stop IPv6 traffic from crossing their devices, it's worth configuring their local recursive DNS servers to answer AAAA DNS record queries with a DNS RCODE of 0 (NOERROR) [RFC1035], or to silently ignore those queries 🙈 it's also worth considering filtering AAAA records at the network ingress point, so internal hosts can't try their own DNS resolution. this makes sure hosts on an "IPv4-only" network only receive DNS A records, so they're unlikely to try using (probably broken) IPv6 connectivity to reach their destinations ✨

we should note that when DNSSEC [RFC4033] is deployed, stripping AAAA records from DNS responses would make responses elicited by queries with the DO and CD bits set [RFC4035] look invalid, so they'd get discarded 💔 this is similar to what happens with DNS64 [RFC6147] when DNSSEC is around, and it should be counted as a drawback of this approach.

also, when filtering IPv6 traffic, it's good practice to signal the packet drop to the source node, so it can react to the drop in a more appropriate and timely way 🫶 for example, a firewall could signal the drop with an ICMPv6 error message (or a TCP [RFC0793] RST segment if that's appropriate), so the source node can, e.g., quickly react as described in [RFC5461] 🧚 for obvious reasons, if the traffic being filtered is IPv6 transition/coexistence traffic, the signaling packet should be sent using the corresponding IPv6 transition/coexistence technology 🌈

5. Security Considerations 🔥

this document covers the security implications of IPv6 on IPv4 networks and describes a number of techniques to mitigate those issues 😤 in general, the possible mitigations boil down to enforcing the same security policies on native IPv6 and IPv6 transition/coexistence traffic that are currently enforced for IPv4 traffic, and/or blocking the aforementioned traffic when it's deemed undesirable. this is SERIOUS bestie, so treat it like it 💀⚠️

6. Acknowledgements 🫶

The authors would like to thank Wes George, who contributed most of the text that comprises Section 4 of this document 💖

The authors would like to thank (in alphabetical order) Ran Atkinson, Brian Carpenter, Stephen Farrell, Guillermo Gont, Joel Jaeggli, Panos Kampanakis, Warren Kumari, Ted Lemon, David Malone, Joseph Salowey, Arturo Servin, Donald Smith, Tina Tsou, and Eric Vyncke for providing valuable comments on earlier versions of this document 👑✨

This document is based on the results of the project "Security 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 📚

7.1. Normative References ✨

okay bestie, this is the list of stuff the spec needs you to have read first. no cap, the whole doc leans on these 💅

  • [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
  • [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
  • [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
  • [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
  • [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
  • [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
  • [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
  • [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
  • [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
  • [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
  • [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
  • [RFC5572] Blanchet, M. and F. Parent, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", RFC 5572, February 2010.
  • [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.

7.2. Informative References 📚

these are the extra reads. super useful for vibes and background, but the spec is still the main character 🎀

  • [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
  • [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
  • [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
  • [RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
  • [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
  • [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
  • [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
  • [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, August 2011.
  • [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
  • [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
  • [RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
  • [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, April 2012.
  • [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 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.
  • [RA-GRD-IMP] Gont, F., "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", Work in Progress, November 2012.
  • [VPN-LEAKS] Gont, F., "Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks", Work in Progress, August 2013.
  • [SHIELD] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Work in Progress, October 2013.
  • [AYIYA] Massar, J., "AYIYA: Anything In Anything", Work in Progress, July 2004.
  • [IANA-ETHER] IANA, "Ethernet Numbers", http://www.iana.org/assignments/ethernet-numbers.
  • [CERT2009] Giobbi, R., "Bypassing Firewalls with IPv6 Tunnels", CERT/ CC Blog, April 2009, http://www.cert.org/blogs/vuls/2009/04/bypassing_firewalls_with_ipv6.html.
  • [Huston2010a] Huston, G., "IPv6 Measurements", 2010, http://www.potaroo.net/stats/1x1/.
  • [Huston2010b] Huston, G., "Flailing IPv6", The ISP Column: A monthly column on things Internet, December 2010, http://www.potaroo.net/ispcol/2010-12/6to4fail.pdf.
  • [Huston2012] Huston, G., "Bemused Eyeballs: Tailoring Dual Stack Applications in a CGN Environment", The ISP Column: A monthly column on things Internet, May 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] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request), .
  • [IPv6-Toolkit] SI6 Networks, "SI6 Networks' IPv6 Toolkit", http://www.si6networks.com/tools/ipv6toolkit.
  • [THC-IPV6] The Hacker's Choice, "THC-IPV6 - attacking the IPV6 protocol suite", December 2013, http://www.thc.org/thc-ipv6/.
  • [Waters2011] Waters, A., "The SLAAC Attack - using IPv6 as a weapon against IPv4", April 2011, http://wirewatcher.wordpress.com/2011/04/04/the-slaac-attack-using-ipv6-as-a-weapon-against-ipv4/.
  • [SixXS-stats] SixXS, , "SixXS - IPv6 Deployment & Tunnel Broker :: Statistics", 2013, http://www.sixxs.net/misc/usage/.

Appendix A. Summary of Filtering Rules 🧚

okay this is the cheat sheet, the whole thing in one table. literally the easiest way to see every tunnel and what to filter for each one 🍓

   +-------------+-----------------------------------------------------+
   |  Technology |                   Filtering rules                   |
   +-------------+-----------------------------------------------------+
   | Native IPv6 |                   EtherType 0x86DD                  |
   +-------------+-----------------------------------------------------+
   |     6in4    |                     IP proto 41                     |
   +-------------+-----------------------------------------------------+
   |    6over4   |                     IP proto 41                     |
   +-------------+-----------------------------------------------------+
   |     6rd     |                     IP proto 41                     |
   +-------------+-----------------------------------------------------+
   |     6to4    |                     IP proto 41                     |
   +-------------+-----------------------------------------------------+
   |    ISATAP   |                     IP proto 41                     |
   +-------------+-----------------------------------------------------+
   |    Teredo   |                  UDP Dest Port 3544                 |
   +-------------+-----------------------------------------------------+
   | TB with TSP |   (IP proto 41) || (UDP Dest Port 3653 || TCP Dest  |
   |             |                      Port 3653)                     |
   +-------------+-----------------------------------------------------+
   |    AYIYA    |       UDP Dest Port 5072 || TCP Dest Port 5072      |
   +-------------+-----------------------------------------------------+

                    Table 1: Summary of filtering rules
NOTE: the table above describes general and simple filtering rules for blocking the corresponding traffic. More finer-grained rules might be available in each of the corresponding sections of this document.

Authors' Addresses 🎀

these are the humans who made it, so you know who to thank (or ask questions, lol) 🫶

   Fernando Gont
   SI6 Networks / UTN-FRH
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   EMail: fgont@si6networks.com
   URI:   http://www.si6networks.com


   Will (Shucheng) Liu
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   EMail: liushucheng@huawei.com
📦 where this page comes from