RFC 4942
IPv6 Transition/Co-existence Security Considerations
IPv6 Transition/Coexistence Security Considerations 🎀
okay bestie, this is RFC 4942 from the Network Working Group 💖. It's by E. Davies (Consultant), S. Krishnan (Ericsson), and P. Savola (CSC/Funet). It's Informational, dated September 2007 ✨. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅.
Status of This Memo 📌
this memo is here to give info to the Internet community 🌸. it does not specify an Internet standard of any kind, so it's not a spec you have to follow 🫶. distribution of this memo is unlimited, so share it with everyone 🦋.
Abstract ✨
okay so the switch from a pure IPv4 network to one where IPv4 and IPv6 live side by side brings a whole bunch of extra security stuff you have to think about 😭. that's true when you're deploying IPv6, and when you're running the dual-protocol network and all its transition mechanisms too. this doc gives you an overview of the issues, sorted into three buckets:
- issues due to the IPv6 protocol itself,
- issues due to transition mechanisms, and
- issues due to IPv6 deployment.
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4
2.1. IPv6 Protocol-Specific Issues . . . . . . . . . . . . . . 5
2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 5
2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 6
2.1.3. Site-Scope Multicast Addresses . . . . . . . . . . . . 7
2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 7
2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 8
2.1.6. Anycast Traffic Identification and Security . . . . . 9
2.1.7. Address Privacy Extensions Interact with DDoS
Defenses . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.8. Dynamic DNS: Stateless Address Autoconfiguration,
Privacy Extensions, and SEND . . . . . . . . . . . . . 10
2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 11
2.1.10. Fragmentation: Reassembly and Deep Packet
Inspection . . . . . . . . . . . . . . . . . . . . . . 14
2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 15
2.1.12. Link-Local Addresses and Securing Neighbor
Discovery . . . . . . . . . . . . . . . . . . . . . . 16
2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17
2.1.14. Host-to-Router Load Sharing . . . . . . . . . . . . . 18
2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 18
2.2. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . 19
2.3. Increased End-to-End Transparency . . . . . . . . . . . . 20
2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 20
2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 21
2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22
3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 23
3.1. IPv6 Transition/Coexistence Mechanism-Specific Issues . . 23
3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 23
3.3. Tunneling IPv6 through IPv4 Networks May Break IPv4
Network Security Assumptions . . . . . . . . . . . . . . . 24
4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 26
4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 26
4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 28
4.3. Addressing Schemes and Securing Routers . . . . . . . . . 28
4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 28
4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 29
4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 30
4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 30
4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 31
4.8. Operational Factors when Enabling IPv6 in the Network . . 31
4.9. Security Issues Due to Neighbor Discovery Proxies . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Normative References . . . . . . . . . . . . . . . . . . . 33
7.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 37
Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 38
B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 38
B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 39
B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 391. Introduction ✨
okay so the big picture: the move from pure IPv4 to a coexisting IPv4 and IPv6 world brings a bunch of extra security considerations 🔥. you need to handle them when you deploy IPv6, and when you run the dual-protocol network along with its transition mechanisms 💜. this doc gives an overview of the issues, grouped into the same three categories:
- issues due to the IPv6 protocol itself,
- issues due to transition mechanisms, and
- issues due to IPv6 deployment.
here's the thing that matters most 👑: nobody is swapping IPv4 for IPv6 anytime soon (at least not in the short term) 🙈. instead, IPv6 gets bolted on and runs in parallel with IPv4 for a long time. so security issues with transition mechanisms and dual-stack networks are going to be a constant worry 😭. the reason this period is so long is mostly the sheer size of the current IPv4 network. it's not realistic to think the many millions of IPv4 nodes will flip over overnight 💀. it's more likely that it'll take two or three capital equipment replacement cycles (somewhere between nine and 15 years) for IPv6 capabilities to spread through the network. in the meantime, plenty of services will stay IPv4-only for a significant stretch, while others will be offered on IPv6 only or on both protocols 🌈. to keep service levels where they are today, enterprises and service providers will need to run IPv4 and IPv6 in parallel for some time 🫶.
this doc also covers two matters that people wrongly flagged as potential security concerns for IPv6 in the past 🙄. it explains why they're unlikely to cause problems: probing/mapping IPv6 addresses (Appendix A) and privacy in IPv6 (Appendix B) ✨.
2. Issues Due to IPv6 Protocol 🎀
okay bestie, heads up 💅: some of the rules in this section could accidentally drop a little bit of legit traffic 😭. that's because the source might have made unusual, arguably unreasonable choices when it built the packet. the IPv6 specification [RFC2460] leaves packet originators a bunch of choices that still conform to the spec, but that a rational, legit traffic generator is unlikely to make. for example, sending a fragmented packet as a way-larger-than-necessary pile of tiny segments 🙃. this doc points out choices a malicious source might make to damage the target host or network 💀. it also suggests rules that try to tell conforming packets that are legit apart from conforming packets that are trying to subvert the spec to cause damage 🔍. the goal is a reasonable compromise between securing the network and letting through every possible conforming packet 🦋. so to avoid losing important traffic, admins are advised to log the packets these rules drop and check the logs regularly 📋. make sure the rules are doing their job and not blocking stuff they shouldn't 👀.
the built-in flexibility of IPv6 is a double-edged sword 🗡️. the line between legit and malicious traffic, as these rules draw it, could shift over time. new options might show up in the future, and the rules may need updating so apps can legitimately use those new capabilities ✨. so the doc recommends that filtering be configurable, so admins can update their rules as new pieces of the IPv6 spec get standardized 🌸.
2.1. IPv6 Protocol-Specific Issues 💖
ngl, IPv6 and IPv4 are really different in a bunch of ways, and some of those spec changes can lead to potential security issues 😬. several of these issues have been covered in separate documents. they're summarized here so this doc doesn't need normative references to documents that might never become RFCs 🧚. the problems listed below are the ones identified so far, but this isn't necessarily a complete list, so keep your eyes open 👀.
2.1.1. Routing Headers and Hosts 🎀
okay so all IPv6 nodes must be able to process routing headers [RFC2460] 💅. It can be read (not explicitly stated, but still) as meaning that all nodes, hosts included, must have this processing enabled 🧚. The "Requirements for Internet Hosts" [RFC1122] lets implementations do "local source routing", which means forwarding a packet with a routing header back out through the same interface it came in on, and there are no restrictions on this even for hosts 😭. Put those rules together and hosts can end up forwarding received traffic to another node whenever there are segments left in the Routing Header when it reaches the host. It's giving chaos 💀
A bunch of potential security issues come with this behaviour 🙈. Some are already sorted. A separate routing header (Type 2) got standardised for Mobile IPv6 [RFC3775], and ICMP Traceback never got standardised. But two issues are still lowkey unresolved 🔥:
- Both existing types of routing header can be used to dodge access controls based on destination addresses 👀. An attacker sends a packet that looks like it's going to a publicly accessible host address, but the routing header has a 'forbidden' address in it. If that publicly accessible host processes routing headers, it forwards the packet to the destination address in the routing header, which the packet filters would have blocked if that address had been in the destination field when the packet was checked. Rude 💅.
- If the packet source address can be spoofed when using a Type 0 routing header, the trick from the bullet above could be used with any host to pull off an anonymous reflection denial-of-service attack, by having any publicly accessible host redirect the attack packets 😱. (This attack can't use Type 2 routing headers, because the packet can't be forwarded outside the host that processes the routing header, which is the packet's original destination 🦋.)
So to counteract these threats, if a device is enforcing access controls based on destination addresses, it needs to check both the destination address in the base IPv6 header and any waypoint destinations in a routing header that the packet hasn't reached yet at the point where it's being checked 🫶.
There are also amplification attacks on routers and firewalls that use the routing header, and people could come up with all sorts of them 🌈. A simple version repeats the address of a waypoint several times in the routing header. More complex versions could alternate waypoint addresses so the packet keeps re-transiting the router or firewall, which is so chaotic 😭. These can be countered by making sure routing headers don't contain the same waypoint address more than once, and by doing ingress/egress filtering to check that the source address suits the destination. Packets that try to reverse their own path will fail that test 🚫.
2.1.2. Routing Headers for Mobile IPv6 and Other Purposes 🌸
Along with the basic Routing Header (Type 0), which is meant to shape a packet's trajectory through a network by listing a sequence of router waypoints, Routing Header (Type 2) was defined as part of the Mobile IPv6 specifications in [RFC3775] ✨. The Type 2 Routing Header is meant for hosts to handle 'interface local' forwarding needed when packets are sent to the care-of address of a mobile node that's away from its home address 🧚.
It's important that nodes treat the different types of routing header appropriately 💖. It should be possible to apply separate filtering rules to the different types of Routing Header. By design, hosts must process Type 2 Routing Headers to support Mobile IPv6, but routers should not. To avoid the issues in Section 2.1.1, it may be desirable to forbid or limit the processing of Type 0 Routing Headers in hosts and some routers 🙅♀️.
Routing Headers are an extremely powerful and general capability 👑. Any alternative future uses of Routing Headers need to be carefully assessed, so they don't open new avenues of attack that can be exploited. Main character energy, but make it careful 💅.
2.1.3. Site-Scope Multicast Addresses 🦋
IPv6 supports multicast addresses with site scope, and if they're misused they can potentially let an attacker identify certain important resources on the site 👀.
Particular examples are the 'all routers' (FF05::2) and 'all Dynamic Host Configuration Protocol (DHCP) servers' (FF05::1:3) addresses defined in [RFC2375]. If an attacker manages to sneak a message destined for these addresses onto the site, they could get back information that identifies key resources on the site 😱. That information can then be the target of directed attacks, from simple flooding all the way to more specific mechanisms designed to subvert the device 💀.
Some of these addresses have current legitimate uses within a site, so this is a tricky one 🥺. The risk can be minimised by making sure all firewalls and site boundary routers are configured to drop packets with site-scope destination addresses 🛡️. Also, nodes should not join multicast groups that have no legitimate use on the site, and site routers should be configured to drop packets directed to these unused addresses 🌈.
2.1.4. ICMPv6 and Multicast 🍓
It's possible to launch a Denial-of-Service (DoS) attack using IPv6 that could get amplified by the multicast infrastructure 📢.
Unlike ICMP for IPv4, ICMPv6 [RFC4443] allows error notification responses to be sent when certain unprocessable packets are sent to multicast addresses ✨.
Responses are sent in these cases:
- The received packet is longer than the next link Maximum Transmission Unit (MTU): 'Packet Too Big' responses are needed to support Path MTU Discovery for multicast traffic 📦.
- The received packet contains an unrecognized option in a hop-by-hop or destination options extension header, with the first two bits of the option type set to binary '10': 'Parameter Problem' responses are intended to inform the source that some or all of the recipients cannot handle the option in question 🤔.
If an attacker can craft a suitable packet sent to a multicast destination, it may be possible to trigger multiple responses aimed at the victim (the spoofed source of the multicast packet) 😬. On the other hand, the use of 'reverse path forwarding' checks, which get rid of loops in multicast forwarding, automatically limits the range of addresses that can be spoofed 🔒.
In practice, an attack using oversize packets isn't likely to cause much amplification, unless the attacker can carefully tune the packet size to exploit a network where the MTU at the edge is smaller than in the core 🎯. Similarly, a packet with an unrecognized hop-by-hop option would be dropped by the first router without resulting in multiple responses. However, a packet with an unrecognized destination option could generate multiple responses 👀.
On top of amplification, this kind of attack could also eat up large amounts of forwarding state resources in routers on multicast-enabled networks 😵.
2.1.5. Bogus Errored Packets in ICMPv6 Error Messages 💌
Apart from the spurious load on the network, routers, and hosts, bogus ICMPv6 error messages (types 0 to 127) that contain a spoofed errored packet can impact higher-layer protocols. This happens when the alleged errored packet gets passed up to the higher layer at the destination of the ICMPv6 packet [RFC4443] 🫣. The potentially damaging effects on TCP connections, and some ways to mitigate the threats, are documented in [ICMP-ATT] 📚.
Specific countermeasures for particular higher-layer protocols are beyond the scope of this document 🙃. But firewalls may be able to help counter the threat by inspecting the alleged errored packet embedded in the ICMPv6 error message 🔍. Measures to mitigate the threat include:
- The receiving host should test that the embedded packet is all or part of a packet that was transmitted by the host 🙋♀️.
- The firewall may be able to test that the embedded packet contains addresses that would have been legitimate (i.e., would have passed ingress/egress filtering) for a packet sent from the receiving host. However, the possibility of asymmetric routing of the outgoing and returning packets may prevent this sort of test, depending on the topology of the network, the location of the firewall, and whether state synchronization between firewalls is in use 🔄.
- If the firewall is stateful and the test is not prevented by asymmetric routing, the firewall may also be able to check that the embedded packet is all or part of a packet that recently transited the firewall in the opposite direction 🧠.
- Firewalls and destination hosts should be suspicious of ICMPv6 error messages with unnecessarily truncated errored packets (e.g., those that only carry the address fields of the IPv6 base header) 🚩. The specification of ICMPv6 requires that error messages carry as much of the errored packet as possible (unlike ICMP for IPv4, which requires only a minimum amount of the errored packet), and IPv6 networks must have a guaranteed minimum MTU of 1280 octets 📏. So the ICMPv6 message should normally carry all the header fields of the errored packet, together with a significant amount of the payload, so it can be robustly compared against the outgoing packet ✨.
2.1.6. Anycast Traffic Identification and Security 🌟
IPv6 introduces the notion of anycast addresses and services 🛰️. Originally, the IPv6 standards disallowed using an anycast address as the source address of a packet. That meant responses from an anycast server had to supply a unicast address for the responding server 😅. To avoid exposing knowledge about the internal structure of the network, it is recommended that anycast servers now take advantage of the ability to return responses with the anycast address as the source address, if possible 💅.
If the server needs to use a unicast address for any reason, it may be desirable to consider using specialised addresses for anycast servers, which aren't used for any other part of the network, to restrict the information exposed 🔐. Alternatively, operators may wish to restrict the use of anycast services from outside the domain, which means requiring firewalls to filter anycast requests. For this purpose, firewalls need to know which addresses are being used for anycast services. The catch is these addresses are arbitrary and not distinguishable from any other IPv6 unicast address by structure or pattern 🥹.
One particular class of anycast addresses that deserves special attention is the set of Subnet-Router anycast addresses defined in "IP Version 6 Addressing Architecture" [RFC4291] 🌷. All routers are required to support these addresses for all subnets they have interfaces on. For most subnets using global unicast addresses, filtering anycast requests to these addresses can be done by dropping packets with the lower 64 bits (the Interface Identifier) set to all zeros 🫶.
2.1.7. Address Privacy Extensions Interact with DDoS Defenses 🎀
okay so the whole point of the privacy extensions [RFC4941] is to change the interface identifier (and therefore the global scope addresses generated from it) from time to time 🦋. by constantly switching up the addresses, eavesdroppers and other info collectors have a much harder time figuring out which transactions actually relate to a specific node 🕵️♀️✨
but here's the tea 🍵 a security issue can pop up if the address changes happen so often that they actually work. with a relatively high rate of change, the traffic starts looking kinda like a node (or a bunch of nodes) taking part in a Distributed Denial-of-Service (DDoS) attack 😭 ngl that's a lot of suspicion for a totally innocent node. it's worth noting, though, that addresses made this way are topologically correct, and the other characteristics of the traffic may show there's no malicious intent 💖
this is fixable in most cases by tuning the rate of change appropriately 💅
also, even if a node is totally well behaved, changing its address could make life harder for a security admin trying to write an address-based policy rule (like an access control list) 🙈 but good news bestie: nodes using privacy addresses don't have to use them for every single communication 🫶
2.1.8. Dynamic DNS: Stateless Address Autoconfiguration, Privacy Extensions, and SEND 🌈
okay this one is giving main character energy 👑. Stateless Address Autoconfiguration (SLAAC) [RFC2462] came with IPv6, and it adds a new challenge to the security of Dynamic Domain Name System (DDNS) 🧚
with manual addressing or DHCP, the number of security associations you need to keep up to secure access to the Domain Name Service (DNS) server stays pretty limited, as long as any needed updates are done by the DHCP server. this is true for both IPv4 and IPv6 🍓
but SLAAC doesn't rely on one single, potentially trusted DHCP server. instead it depends on each node getting its own address, so securing the insertion of updates into DDNS may need a security association between every node and the DDNS server 😭 more on this in [RFC4472] 📚
using the Privacy Extensions to SLAAC [RFC4941] can seriously bump up how often DDNS gets updated 🔥. even if a node using them doesn't publish its address for 'forward' lookup (because that would basically undo the privacy it's going for), it may still need to update the reverse DNS records. if those reverse DNS records aren't updated, servers that do reverse DNS checks won't accept connections from the node, and it won't be possible to reach IP Security (IPsec) keying material stored in DNS [RFC4025] 💀
and if the rate of change needed for real privacy has to go up (see Section 2.1.7), the update rate for DDNS may become excessive 🙈
similarly, the cryptographically generated addresses used by SEND [RFC3971] are expected to be regenerated periodically, in line with recommendations for maximum key lifetimes. that regeneration could also put a significant extra load on DDNS 🫠
2.1.9. Extension Headers 🧚
a bunch of security issues around IPv6 Extension headers have been identified 👀 and several of them come from ambiguous or incomplete specification in the base IPv6 specification [RFC2460]. so let's dig in 🔍
2.1.9.1. Processing Extension Headers in Middleboxes 🛡️
in IPv4, deep packet inspection is used to do policing and filtering, both in routers and in middleboxes like firewalls 🔥. fully extending these techniques to IPv6 would mean inspecting all the extension headers in a packet. this is essential so policy constraints on the use of certain headers and options actually get enforced, and so packets with potentially damaging unknown options get removed at the earliest opportunity 🙌
this clashes with Section 4 of the IPv6 specification in [RFC2460], which says that only hop-by-hop options get processed at any node the packet passes through, until it reaches the right destination (either the final destination or a routing header waypoint) 😤
also, [RFC2460] forbids processing the headers in any order other than the order they show up in the packet 🙅♀️
another ambiguity: should an intermediate node throw away a packet that has a header or destination option it doesn't recognize? if you follow the rules above slavishly, it is not (or may not be) legit for that intermediate node to discard the packet, because it shouldn't be processing those headers or options in the first place 🤯
so basically [RFC2460] doesn't seem to account for how middleboxes and other non-final destinations inspect packets, and that can limit the security protection those boxes can give 😭. firewall vendors and admins may choose to ignore these rules to get better security, since it doesn't seem to have any serious consequences with the extensions defined so far ✨. just be aware that future extensions might need different treatment 🔮
2.1.9.2. Processing Extension Header Chains 🔗
there's another problem for middleboxes that want to look at the transport headers at the end of the IPv6 header chain 👀. to find the transport header (or other protocol data unit), the node has to parse the header chain first 💅
the IPv6 specification [RFC2460] doesn't require the Type-Length-Value (TLV) format with a fixed layout at the start of each header, even though most headers defined so far use it 🧩. (only the Type field is guaranteed in size and offset.)
so a middlebox can't guarantee it can process header chains that include headers defined after the box was manufactured 😬. as Section 2.1.9.3 discusses further, middleboxes ideally shouldn't need to know the detailed layout of every header type, but they still need to be able to skip over those headers to find where the transport payload starts. if they can't, that either limits the security policy firewalls can apply or makes it hard to deploy new extension header types 🥲
at the time of writing, only the Fragment Header doesn't fully conform to the TLV format used by the other extension headers 🧐. in practice, lots of firewalls reassemble fragmented packets before doing deep packet inspection, so this divergence is less of a problem than it could've been. it's also at least partly justified, because the full header chain isn't present in every fragment 🫶
hop-by-hop and destination options may also contain unknown options. however, those options are required to be encoded in TLV format, so intermediate nodes can skip over them during processing, unlike the enclosing extension headers ✨
2.1.9.3. Unknown Headers/Destination Options and Security Policy 🚧
a strict security policy might say that packets with unknown headers or destination options get discarded by firewalls or other filters 🚫. but doing that means the firewall has to process the whole extension header chain, which may currently conflict with the IPv6 specification (as discussed in Section 2.1.9.1) 😵💫
even if the firewall does inspect the whole header chain, dropping packets with items it doesn't recognize may not be sensible. the intermediate node has no idea which options and headers are implemented in the destination node, and IPv6 was deliberately designed to be extensible by adding new header options 🧚♀️. this puts firewall admins in a real dilemma 😩. on one hand, letting in packets with 'unknown' options is a security risk. on the other hand, dropping them might disable a useful new extension 🥺
the best compromise seems to be picking firewalls with a configurable discard policy based on the types of the extensions 🎀. then, when a new extension gets standardized, admins can reconfigure the firewall to pass packets with legit items it wouldn't otherwise recognize, since its hardware or software isn't aware of the new definition 🙌. as long as new extensions follow the same TLV layout as current ones, the firewall wouldn't need detailed knowledge of the extension header's function or layout 💖
2.1.9.4. Excessive Hop-by-Hop Options 📦
IPv6 doesn't limit how many hop-by-hop options can be in a hop-by-hop option header, and any option can show up multiple times 😳. that lack of a limit, combined with the extensibility bits that force nodes to ignore classes of options they don't understand, can be used to launch denial-of-service attacks that hit every node on a path 💀
a packet with lots of unknown hop-by-hop options gets processed at every node it's forwarded through, and each node burns significant resources figuring out what to do with each option 🔥. current options, with the exception of Pad1 and PadN, shouldn't appear more than once, so packets with inappropriately repeated options can be dropped 🗑️. however, keeping track of which options have been seen adds complexity to firewalls, and it may not hold up for future extensions 🤷♀️. see Section 2.1.9.3 for a discussion of whether it's a good idea to drop packets with unknown options in firewalls 🧐
2.1.9.5. Misuse of Pad1 and PadN Options 🧸
IPv6 lets you put multiple padding options of arbitrary sizes in both Hop-by-Hop and Destination option headers 🎀
PadN options are required to contain zero octets as 'payload', but receivers have no incentive to check that 😬. so it may be possible to use the 'payload' of padding options as a covert channel 🕵️♀️. firewalls and receiving hosts should actively check that PadN only has zero octets in its 'payload' 🫡
there's no legit reason to pad beyond the next eight-octet boundary. the whole option header is aligned on an eight-octet boundary, but it can't be guaranteed to sit on a 16 (or higher power of two)-octet boundary 🤓. the IPv6 specification lets multiple Pad1 and PadN options be combined in any way the source likes to make up the required padding. reasonable design choices seem to be using however many Pad1 options (i.e., zero octets) are needed, or using a single PadN option of the required size (from two up to seven octets) 💅. admins should consider at least logging unusual padding patterns, and may consider dropping packets with unusual patterns if they're certain of the expected source behavior 🧾
2.1.9.6. Overuse of Router Alert Option 🚨
the IPv6 router alert option specifies a hop-by-hop option that, if present, tells the router to take a closer look at the packet 👀. this can be used for denial-of-service attacks 😱. by sending a huge number of packets with a router alert option, an attacker can drain the processor cycles on routers that legit traffic needs 💀🌸
2.1.10. Fragmentation: Reassembly and Deep Packet Inspection ✨
okay so the current IPv6 specs in [RFC2460] don't set any minimum packet size for the fragments before the last one 🧩. The only rule is that every fragment still has to carry the unfragmentable part, and that's it 💅
The unfragmentable part doesn't include the transport port numbers 🙈. That means the first fragment might not have enough info for deep packet inspection that needs the port numbers. bestie, that's a whole problem 💀
Packets with overlapping fragments are seen as a major security risk 🚨. The reassembly rules for fragmented packets in [RFC2460] don't require any behavior that would cut down on the effects of overlapping fragments, though 😤.
To make deep packet inspection work right on fragmented packets 🔍, a lot of firewalls and other nodes that use it will collect the fragments and put the packet back together before they look at it. Depending on how reassembly is implemented and how those nodes handle fragments, these spec issues could leave IPv6 open to the kinds of attacks described in [RFC1858] and [RFC3128] for IPv4 😱.
Here are the steps you can take to mitigate these threats 🛡️:
- Even though [RFC2460] allows it, there's no good reason for a source to make overlapping packet fragments 🙅. Overlaps could be banned in a future revision of the protocol spec. Firewalls should drop all packets with overlapped fragments, and some implementations in firewalls and other nodes already drop them 👑.
- Setting a minimum size for packet fragments doesn't help the way it does for IPv4 🙃. That's because IPv6 extension headers can be made to look super long. An attacker could slip in one or more undefined destination options with long lengths and the
'ignore if unknown'bit set. Since IPv6 has a guaranteed minimum MTU, it seems reasonable for hosts to make sure the transport port numbers land in the first fragment in almost all cases 🧠. Deep packet inspection should also be very suspicious of first fragments that don't have them (see also the discussion of fragment sizes in Section 2.1.11) 🕵️♀️.
2.1.11. Fragmentation Related DoS Attacks 🌪️
packet reassembly in IPv6 hosts also opens the door to a bunch of fragment-related security attacks 😩. Some of them are basically the same as attacks already identified for IPv4. The one that's really concerning is a DoS attack where someone sends tons of small fragments and never sends a last fragment to finish things off. That can overload the reconstruction buffers and eat up a lot of CPU 🔥.
Mandating the size of packet fragments could make this attack hurt less, since it would limit how fast fragments can arrive and how many have to be processed 📉. But the IPv6 standard doesn't specify this right now. In practice, protocol stacks will probably make one of two design choices 🎀. They might max out the size of every non-final fragment using the path MTU (the most likely choice), or spread the data evenly across the minimum number of fragments needed. Either way, the smallest non-final fragment ends up at least half the guaranteed minimum MTU, which is 640 octets. The worst case is when a payload is just a bit too big for one packet and gets split into two roughly equal halves ⚖️.
Administrators should consider setting up firewalls and hosts to drop non-final fragments smaller than 640 octets 🧱.
2.1.12. Link-Local Addresses and Securing Neighbor Discovery 🔗
All IPv6 nodes are required to configure a link-local address on each interface 🏠. This address is how a node talks to other nodes directly connected to the same link through that interface. It's super important during neighbor discovery and autoconfiguration 🧚. Link-local addresses are basically fundamental to the Neighbor Discovery Protocol (NDP) [RFC2461] and Stateless Address Autoconfiguration (SLAAC) [RFC2462]. NDP also does the job that the Address Resolution Protocol (ARP) does in IPv4 networks, which is linking link-layer addresses to IP addresses 🪄.
Standard NDP has a bunch of security threats tied to ARP spoofing attacks on IPv4 😬. These threats are written up in [RFC3756], and SEcure Neighbor Discovery (SEND) [RFC3971] describes the mechanisms that fight them. SEND is optional, but it's especially useful in wireless and other places where it's hard to physically secure the link 📶.
Here's the tea ☕: link-local addresses can usually be acquired without any outside help or control. So an attacker can start communicating on the link without needing to know the address prefixes in use or talk to any authorities on the link 👀. That gives a malicious node the chance to attack any other node on that link, and this problem exists on top of any direct attacks on NDP. Link-local addresses can also enable unauthorized use of the link bandwidth ('bandwidth theft') to talk to another unauthorized node on the same link 💸.
There are a few ways to reduce the vulnerabilities of IPv6 link-local addresses in NDP 🛠️. A general solution will require:
- authenticating the link-layer connectivity, for example by using IEEE 802.1X functionality [IEEE.802-1X] or physical security, and
- using SEcure Neighbor Discovery (SEND) to create a cryptographically generated link-local address (as described in [RFC3971]) that's tied to the authenticated link-layer address 🔐.
This solution would be a great fit for wireless LAN deployments, where it's hard to physically secure the infrastructure 📡. It might not be considered necessary on wired networks, where the physical infrastructure can be kept secure by other means 🧵.
Limiting how link-local addresses can be abused in general packet exchanges is trickier 😵💫. There may be situations, like isolated networks, where using them is totally appropriate. Telling use apart from abuse can need complicated filtering rules that have to run on hosts. The risk of misuse might be seen as too small to be worth the effort of controlling it. Still, special attention should be paid to tunnel end-points (see 2.4, 3.2, and 3.3) 🚇.
Any filtering has to be done by a host-based or bridging firewall 🧱. Generally, link-local addresses are expected to be used by applications written to handle specific interfaces and links, usually for control and management 🎛️. A node attached to multiple links has to deal with the potentially overlapping link-local address spaces of those links. IPv6 handles this with zone identifiers that tell the different address scopes apart [RFC4007], plus the scope identifier that can go with a socket address structure [RFC3493] 🗺️. Most users don't know about any of this, and general-purpose applications aren't meant to handle that kind of discrimination 🙃. Link-local addresses are also normally not used with the Domain Name System (DNS), and DNS can't supply zone identifiers.
If you really want to stop link-local addresses from being used by anything other than control and management protocols, administrators may want to limit which protocols can use them 🚫. At a minimum, ICMPv6 and any intra-domain routing protocol in use (like Open Shortest Path First (OSPF) or Routing Information Protocol (RIP)) need to be allowed. Other protocols might be needed too 📋. RIP is a good example of how messy filtering can get 🤯: its messages are carried as User Datagram Protocol (UDP) payloads, so filtering has to tell RIP messages sent to UDP port 521 apart from other UDP messages.
2.1.13. Securing Router Advertisements 📣
As part of Neighbor Discovery, routers on a link advertise what they can do in Router Advertisement messages 📢. The version of NDP defined in [RFC2461] doesn't protect the integrity of these messages or check the claims inside them 🙅♀️. So any node that connects to the link can maliciously say it offers routing services it won't actually provide, and advertise bad prefixes and parameters 😤. These threats are documented in [RFC3756].
A malicious node can also launch a DoS attack by deprecating an established, valid prefix (by advertising it with a zero lifetime) 💥. Similar DoS attacks are possible if the optional Router Selection mechanism is implemented as described in the security considerations of [RFC4191] 🧨.
SEND [RFC3971] can verify that routers are authorized to provide the services they advertise, using a certificate-based mechanism 🪪. This is especially helpful in wireless environments, where clients rely on what routers say rather than on a physically secured connection 📶.
2.1.14. Host-to-Router Load Sharing ⚖️
If a host uses the optional host-to-router load-sharing mechanism [RFC4311], a malicious application could launch a DoS attack on one or more load-sharing routers 😈. It could do that if it knows the load-sharing algorithm well enough to create traffic that messes with the algorithm and sends a huge volume of bogus traffic toward a subset of the routers. The chance of this attack goes down if the implementation uses a sufficiently sophisticated load-sharing algorithm, as described in the security considerations of [RFC4311] 🧠.
2.1.15. Mobile IPv6 📱
Mobile IPv6 is way more secure than Mobile IPv4, especially when it uses optimized routing and care-of addresses 🙌. Return routability checks give fairly strong assurance that the different addresses a mobile node uses as it moves around really do belong to the same node 🗺️. The threats and solutions are described in [RFC3775], and if you want a deeper look at the security side of the design, check out [RFC4225] 📚.
2.1.15.1. Obsolete Home Address Option in Mobile IPv6 🚫
The Home Address option from early Mobile IPv6 versions made a super easy source spoofing attack possible 😱. Hosts were required to swap the source address of incoming packets with the address in the option, which could let attackers dodge checks on the packet source address. The version of Mobile IPv6 standardized in [RFC3775] fixed this. It only processes the Home Address destination option when there's a matching binding cache entry, and it secures Binding Update messages 🔒.
Some pre-standard Mobile IPv6 implementations used this obsolete and insecure option. Be careful to avoid running those obsolete systems 🙏💜.
2.2. IPv4-Mapped IPv6 Addresses ✨
okay so overloaded functionality is always a double-edged sword 🗡️ it can give you some real deployment perks, but it also comes with the ambiguity tax, and nobody wants to pay that 💀
one example is IPv4-mapped IPv6 addresses (::ffff/96) 🦋 these are a way to show an IPv4 address in IPv6 form inside an operating system, as defined in [RFC3493]. since the original spec, mapped addresses got promoted to a transition mechanism, the Stateless IP/ICMP Translation algorithm (SIIT) [RFC2765], where they can actually end up in the addresses of packets on the wire 🌊
so it gets messy 😭 it's hard to tell whether an IPv4-mapped address is really an IPv4 address dressed up in IPv6 format (the basic API behavior) or an IPv6 address that came off the wire (where it might be forged, etc.) (the SIIT behavior). the security issues that pop up when mapped addresses show up on the wire include:
- If an attacker sends an IPv6 packet with
::ffff:127.0.0.1in the IPv6 source address field, they might sneak past a node's access controls by tricking applications into thinking the packet came from the node itself (specifically, the IPv4 loopback address,127.0.0.1). The same attack could be pulled off using the node's IPv4 interface address instead. 🙈 - If an attacker sends an IPv6 packet with IPv4-mapped addresses in the IPv6 destination address field that match IPv4 addresses inside a site's security perimeter (e.g.,
::ffff:10.1.1.1), they might be able to bypass IPv4 packet filtering rules and slip through a site's firewall 🚨 - If an attacker sends an IPv6 packet with IPv4-mapped addresses in both the IPv6 source and destination fields to a protocol that swaps IPv6 source and destination addresses, they might be able to use a node as a proxy for certain kinds of attacks. For example, this might be used to build broadcast multiplication and proxy TCP port scan attacks. 💀
also, these special cases give deployment benefits in some areas but need a whole lot of extra code complexity (like in the implementation of bind() system calls and reverse DNS lookups). that's probably not ideal, but it can be managed in this case 🫶
here's the tea ☕ SIIT's packet translation mechanisms are specified for use in "Network Address Translator - Protocol Translator (NAT-PT)" [RFC2766], but NAT-PT uses a different mechanism from IPv4-mapped IPv6 addresses to carry embedded IPv4 addresses inside IPv6 addresses. also, SIIT is not recommended as a standalone transition mechanism 🙅♀️ given all the issues we've identified, it makes sense that mapped addresses should not be used on the wire. BUT changing application behavior by deprecating mapped addresses in the operating system interface would have a big impact on application porting methods (as described in [RFC4038]), so it's expected that IPv4-mapped IPv6 addresses will keep being used within the API to help applications stay portable 🎀
using the basic API behavior also has some security implications, because it adds complexity to address-based access controls 😬 the main problem is that an IPv6 (AF_INET6) socket will accept IPv4 packets even when the node has no IPv4 (AF_INET) sockets open. application developers have to take this into account, and it may let a malicious IPv4 peer reach a service even when there are no open IPv4 sockets. that really breaks the security principle of "least surprise" 😭🔥
2.3. Increased End-to-End Transparency 🌈
one of IPv6's major design goals was to keep the original IP architectural concept of end-to-end transparency 💖 transparency can help spark innovation in areas like peer-to-peer communication, but keeping the network secure at the same time does require some changes to the network architecture. ultimately, the security model will probably need to change too, compared with the norms we're used to for IPv4 networks 🧚
2.3.1. IPv6 Networks without NATs 🫧
so the shortage of IPv4 addresses made Network Address Translators (NATs) a necessity in IPv4 networks, and that basically wiped out end-to-end transparency for most IPv4 connections. using IPv6 would bring that transparency back ✨ but the use of NATs, and the private addressing schemes that come with them, has gotten inappropriately tangled up with providing security in enterprise networks 🙃 so the restored end-to-end transparency of IPv6 networks can feel like a threat to poorly informed enterprise network managers. some of them seem to want to limit IPv6's end-to-end capabilities, like by deploying private, local addressing and translators even when it's not necessary, given how abundant IPv6 addresses are 💅
if you want to design an IPv6 network that meets the security and connectivity needs people currently assume from IPv4 NATs, while still keeping the perks of IPv6 end-to-end transparency, check out "IP Version 6 Network Architecture Protection" [RFC4864] 🦋
2.3.2. Enterprise Network Security Model for IPv6 🏰
the favored enterprise security model for IPv4 leans heavily on a security perimeter, policed by autonomous firewalls and with NATs built right in 🧱 both perimeter firewalls and NATs add asymmetry and cut down on transparency across the perimeter. IPv6's symmetric bidirectionality and transparency are celebrated as its virtues, but they can seem to clash with this model 😬 so network managers might even see them as undesirable, since they conflict with the need to control threats and attacks on the networks they run.
it's worth saying that IPv6 does not require end-to-end connectivity 💡 it only provides end-to-end addressability. connectivity can still be controlled with firewalls (or other mechanisms), and it's honestly wise to do that 🛡️
a bunch of things signal that IPv6 networks should move toward an improved security model, one that boosts overall network security while also making end-to-end communication easier 🌸
- Increased use of end-to-end security, especially at the network layer. IPv6 mandates that all nodes provide IPsec capability, and more end-to-end security is a challenge for autonomous firewalls that can't do deep packet inspection on encrypted packets. it's also incompatible with NATs, because they modify packets, even when those packets are only authenticated rather than encrypted. 🔐
- Acknowledging that leaning too hard on the perimeter model is potentially dangerous. an attacker who gets past today's perimeters will, in many cases, have free rein inside them. and a successful attack will generally let the attacker capture information or resources and use them. 😱
- Developing mechanisms like 'Trusted Computing' [TCGARCH] that boost the level of trust network managers can place in hosts. 🖥️
- Developing centralized security policy repositories and secure distribution mechanisms that, together with trusted hosts, let network managers rely more on security mechanisms at the endpoints. the mechanisms will likely include end-node firewalling and intrusion detection systems, plus secure protocols that let endpoints influence how perimeter security devices behave. 🫶
- Reviewing the role of perimeter devices, with more emphasis on intrusion detection, and on network resource protection and coordination to thwart distributed denial-of-service attacks. 🔥
a few of the technologies needed to support this enhanced security model are still in development, including secure protocols that let endpoints control firewalls. the full security model using these technologies is emerging now, but it still needs some work 🚧
in the meantime, early deployments will need to use firewalling and intrusion detection techniques similar to IPv4's, which may temporarily limit end-to-end transparency. but they should be ready to adopt the new security model as it develops, and avoid NATs by using the architectural techniques in [RFC4864] 🌈 in particular, using NAT-PT [RFC2766] as a general-purpose transition mechanism should be avoided, since it's likely to limit the exploitation of end-to-end security and other IPv6 capabilities later on, as explained in [RFC4966] 🙅♀️
2.4. IPv6 in IPv6 Tunnels 🚇
okay this one is serious 🚨 IPv6 in IPv6 tunnels can be used to circumvent security checks, so it's essential to filter packets at both tunnel ingress and egress points (the encapsulator and decapsulator). that makes sure both the inner and outer addresses are acceptable, and that the tunnel isn't carrying inappropriate traffic 🧐 [RFC3964], which is mostly about the 6to4 transition tunneling mechanism (see Section 3.1), has useful discussions of possible attacks and ways to counter those threats 📚
3. Issues Due to Transition Mechanisms 🦋
3.1. IPv6 Transition/Coexistence Mechanism-Specific Issues 🎀
the more complicated IPv6 transition/coexistence gets, the bigger the danger that security issues will sneak in, either 😬
- in the mechanisms themselves,
- in the interaction between mechanisms, or
- by introducing unsecured paths through multiple mechanisms.
these issues might or might not be obvious 👀 so it would be desirable to keep the mechanisms simple (as few in number as possible, and built from pieces as small as possible) to make analysis easier 🧠
one case where these security issues have been analyzed in detail is the 6to4 tunneling mechanism [RFC3964] 🌸
tunneling has been proposed as a model for more cases than are currently in use, so its security properties should be analyzed in more detail. there are some generic dangers to tunneling 🚩
- It may be easier to avoid ingress filtering checks.
- It is possible to attack the tunnel interface. several IPv6 security mechanisms depend on checking that Hop Limit equals 255 on receipt and that link-local addresses are used. sending such packets to the tunnel interface is much easier than getting access to a physical segment and sending them there. 😈
- Automatic tunneling mechanisms are typically especially dangerous, since there's no pre-configured association between endpoints. so at the receiving end of the tunnel, packets have to be accepted and decapsulated from any source. that means special care should be taken when specifying automatic tunneling techniques ⚠️
3.2. Automatic Tunneling and Relays 🧚
Okay so there are two mechanisms that use automatic tunneling and are meant for use outside a single domain 💅. 6to4 [RFC3056] wraps the IPv6 packet straight inside an IPv4 packet, and Teredo [RFC4380] wraps it inside an IPv4 UDP packet 🦋. Either way, any similarly equipped nodes on the IPv4 Internet can send and receive these packets 🌸.
As we covered in Section 3.1, the big vulnerability here is that receiving nodes have to allow decapsulation of traffic sourced from anywhere on the Internet 😭. That decapsulation has to be extremely well secured, because the list of potential sources is huge 🔥.
Then there's the even harder problem: these mechanisms need some kind of "relay" to talk to native IPv6 nodes or to each other 🫶. Relays could be deployed in a few different places:
- all native IPv6 nodes,
- native IPv6 sites,
- in IPv6-enabled ISPs, or
- just somewhere in the Internet.
A relay has to trust all the sources sending it traffic (in the 6to4 case, that's all 6to4 routers) 🧐. So you've got two headaches: getting that trust to work, and scaling the relay system so a small number of relays doesn't get overloaded 💀.
Authentication of a relay service is really hard to pull off, especially in some of the possible deployment models 🙈. That makes relays a potential vehicle for address spoofing, (reflected) denial-of-service attacks, and other threats 😱.
Threats related to 6to4 and measures to combat them are discussed in [RFC3964]. [RFC4380] incorporates extensive discussion of the threats to Teredo and how to combat them 📚.
3.3. Tunneling IPv6 through IPv4 Networks May Break IPv4 Network Security Assumptions 🙈
NATs and firewalls have been deployed extensively across the IPv4 Internet, as discussed in Section 2.3 💖. The operators who deploy them usually have some security and operational requirements in mind (for example, a desire to block inbound connection attempts), which may or may not be misguided 🤷♀️.
Adding tunneling can change the security model those deployments are trying to enforce 😬. IPv6-over-IPv4 tunneling using protocol 41 is typically either explicitly allowed or implicitly disallowed 🎀. Tunneling IPv6 over IPv4 encapsulated in UDP is a trickier problem, because UDP usually has to be allowed to pass through NATs and firewalls 🌈. So using UDP implies the ability to punch holes in NATs and firewalls 🕳️. Depending on the implementation, though, that ability may be limited or only achieved in a stateful manner ✨. In practice, these mechanisms have been explicitly designed to traverse both NATs and firewalls in a similar fashion 💅.
One possible view is that tunneling is especially questionable in home and SOHO (small office/home office) environments 🏠. The level of network administration expertise there is typically not very high, and the hosts may not be as tightly managed as elsewhere (for example, network services might be enabled unnecessarily) 😩. That can lead to security break-ins or other vulnerabilities 💀.
Holes that let tunneled traffic through NATs and firewalls can be punched both intentionally and unintentionally 🫣. When the administrator or user makes an explicit decision to create the hole, it's less of a problem 👍. Some enterprises might still want to block IPv6 tunneling explicitly, though, if employees could create such holes without involving administrators 🙅♀️. On the other hand, if a hole is punched transparently, a proportion of users are likely to not understand the consequences 😵. That will very probably turn into a serious threat sooner or later 🚨.
When deploying tunneling solutions, especially ones that are automatic and/or can be enabled easily by users who don't understand the consequences, care should be taken not to compromise the security assumptions held by the users 🫶.
For example, NAT traversal should not be performed by default unless there is a firewall producing a similar by-default security policy to that provided by IPv4 NAT. IPv6-in-IPv4 (protocol 41) tunneling is less of a problem, as it is easier to block if necessary. However, if the host is protected in IPv4, the IPv6 side should be protected as well 🛡️.
As shown in Appendix A, it's relatively easy to determine the IPv6 address corresponding to an IPv4 address in tunneling deployments 👀. So it is vital NOT to rely on "security by obscurity", meaning assuming that nobody is able to guess or determine the IPv6 address of the host, especially when using automatic tunneling transition mechanisms 🔐.
The network architecture must provide separate IPv4 and IPv6 firewalls. Tunneled IPv6 traffic arrives encapsulated in IPv4 packets, gets routed through the IPv4 firewall before being decapsulated, and then goes through the IPv6 firewall, as shown in Figure 1 🧩.
+--------+ +--------+ +--------+
Site | Native | IPv6 |v6 in v4| IPv4 | Native | Public
Network <--->| IPv6 |<---->| Tunnel |<---->| IPv4 |<---> Internet
|Firewall| |Endpoint| |Firewall|
+--------+ +--------+ +--------+
Figure 1: Tunneled Traffic and Firewalls4. Issues Due to IPv6 Deployment 🌷
4.1. Avoiding the Trap of Insecure IPv6 Service Piloting 🪤
IPv6 is a brand-new service for many networks, so network managers will often opt for a pilot deployment in one part of the network 🧪. The goal is to gain experience and understand both the problems and the benefits that could come with a full production-quality IPv6 service 📈.
Unless IPv6 service piloting is done as securely as possible, there's a risk 😬. If security in the pilot doesn't match what's achievable with the current IPv4 production service, that comparison can seriously hurt the overall assessment of the IPv6 pilot 📉. That might lead to a decision to delay or even avoid deploying an IPv6 production service 🥲. For example, hosts and routers might not be protected by IPv6 firewalls, even if the matching IPv4 service is fully protected by firewalls 🙈. The use of tunneling transition mechanisms (see Section 3.3) and their interaction with virtual private networks also need careful attention to keep site security intact 🔒. This is especially critical where IPv6 capabilities are turned on by default in new equipment or new operating system releases, since network managers may not be fully aware of the security exposure that creates 🚩.
In some cases, a perceived lack of IPv6 firewalls and other security capabilities, such as intrusion detection systems, may have led network managers to resist any kind of IPv6 service deployment 🙃. These problems may be partly due to the relatively slow development and deployment of IPv6-capable security equipment. But the major problems appear to have been a lack of information and, more importantly, a lack of documented operational experience that managers can draw on 📚. Honestly, though, at the time of writing there were already a significant number of alternative IPv6 packet filters and firewalls out there that could provide sufficient access controls 💪.
There are still a small number of areas where available equipment and capabilities may be a barrier to secure deployment, as of the time of writing 👀:
- 'Personal firewalls' with support for IPv6 and intended for use on hosts are not yet widely available.
- Enterprise firewalls are at an early stage of development and may not provide the full range of capabilities needed to implement the necessary IPv6 filtering rules. Network managers often expect the same devices used for IPv4 today to also become IPv6-capable, even though this isn't really required, and the equipment may not have the hardware capabilities needed for fast packet filtering for IPv6 🛠️. Suggestions for appropriately deploying firewalls are given in Section 3.3. As that section shows, it's usually desirable for the firewalls to be in separate boxes, and there's no need for them to be the same model of equipment 📦.
- A lesser factor is that some design decisions in the IPv6 protocol make it harder for firewalls to be implemented and to work in all cases, and to be fully future-proof (for example, when new extension headers are used), as discussed in Section 2.1.9 🧱. It is significantly more difficult for intermediate nodes to process IPv6 header chains than IPv4 packets 😩.
- Adequate Intrusion Detection Systems (IDS) are harder to build for IPv6 🕵️♀️. IDSs are only now beginning to become available, but the pattern-based mechanisms used for IPv4 may not be the most appropriate for the long-term development of these systems as end-to-end encryption becomes more prevalent 🔐. Future systems may rely more on traffic flow pattern recognition 🔮.
- Implementations of high availability capabilities supporting IPv6 are also in short supply 🥺. In particular, development of the IPv6 version of the Virtual Router Redundancy Protocol (VRRP) [VRRP] has lagged behind the main IPv6 protocol, although alternatives may be available for some environments 🔄.
In all these areas, developments are ongoing, and they should not be considered a long-term bar to deploying IPv6, either as a pilot or as a production service 🌱. The necessary tools are available now to make a secure IPv6 deployment. With careful selection of components and careful design of the network architecture, a successful pilot or production IPv6 service can be deployed 🎉. Recommendations for secure deployment and appropriate management of IPv6 networks can be found in the documentation archives of the European Union 6net project [SIXNET] and in the Deployment Guide published by the IPv6 Promotion Council of Japan [JpIPv6DC] 📖.
4.2. DNS Server Problems 🌐
Some DNS server implementations have flaws that severely affect DNS queries for IPv6 addresses, as discussed in [RFC4074] 😭. These flaws can be used for DoS attacks that affect both IPv4 and IPv6 🚨. The trick is inducing caching DNS servers to believe a domain is broken, which causes the server to block access to all requests for that domain for a precautionary period 🙀.
4.3. Addressing Schemes and Securing Routers ✨
okay so brute force scanning of IPv6 subnets is basically impossible 🙈 the address space is enormously bigger than IPv4's, and the 64-bit interface identifiers make it even harder (see Appendix A). BUT this only stays true if admins don't take advantage of all that space and use unguessable interface identifiers. no cap, the giant space is our friend only if we actually use it 💅
complete IPv6 addresses are so unmemorable 😭 so there's a temptation to just use small integers as interface identifiers when configuring them by hand, like on point-to-point links, or when handing out complete addresses from a DHCPv6 server. those choices make life way too easy for an attacker, who can find active nodes and then port scan them. not me giving attackers a free map 🗺️
to make the bigger address space work properly, admins should be super careful when typing IPv6 addresses into their configs (like access control lists). numerical IPv6 addresses are more prone to human error than IPv4 because they're so long and so hard to remember. typo city, bestie 🫠
it's also essential to lock down the management interfaces on routers 🔒 for example, only allow remote access using Secure Shell (SSH), and make sure local craft interfaces have non-default passwords. this matters because the router usually holds a big cache of neighbor addresses in its neighbor cache, so it's a seriously juicy target 🍯
4.4. Consequences of Multiple Addresses in IPv6
one iconic thing about IPv6 ✨ nodes that don't need global access can still talk locally just by using a link-local address (if very local access is enough), or talk across the site using a Unique Local Address (ULA). either way, it's easy to keep access outside the node's assigned domain of activity under control with simple filters. those filters should be the default for link-locals 🧚 BUT the security hazards of using link-local addresses for general purposes, as documented in Section 2.1.12, should be kept in mind. main character energy has limits, babe 💀
now the plot twist 🌀 a node or interface can have multiple global scope addresses, which makes access control filtering (on both ingress and egress) more complex and needs higher maintenance levels. vendors and network admins need to get it into their heads that multiple addresses are the norm, not the exception, in IPv6 💜 so when they're building and picking tools for security and management, a highly desirable feature is being able to "tokenize" access control lists and configurations in general, so they can handle multiple addresses and/or address prefixes. literally the dream 🌸
the addresses could come from the same network prefix. for example, privacy mechanisms [RFC4941] will periodically create new addresses from the same prefix, and two or more of those can be active at the same time 🦋 or the addresses could come from different prefixes. that happens when a network is multihomed, when a node belongs to several subnets on the same link for management purposes, or when it's implementing anycast services ✨ in all these cases, a single host could be using several different addresses with different prefixes and/or different interface identifiers. it's really desirable that the security admin can figure out that the same host is behind all these addresses. no one wants a mystery host situation 🕵️♀️
some network admins might find the constantly changing addresses (from privacy mechanisms) undesirable 🙃 because of the current difficulties in maintaining access control lists and knowing where traffic is coming from. generally speaking, turning off privacy addresses is only possible if the full stateful DHCPv6 mechanism [RFC3315] is used to allocate IPv6 addresses AND DHCPv6 requests for privacy addresses are not honored. (okay the capital AND is just me being dramatic, it's a lowercase "and" in the original 😂)
4.5. Deploying ICMPv6
in IPv4, it's commonly accepted that some filtering of ICMP packets by firewalls is essential for security 🛡️ BUT ICMPv6 [RFC2461] is doing SO much more, with a multitude of functions 🤯 so the simple dropping rules that people usually use in IPv4 need to be seriously developed for IPv6. the blanket dropping of all ICMP messages, which some super strict environments do, is simply not possible for IPv6. sorry, no shortcuts here 😭
in an IPv6 firewall, the policy needs to let some messages through, but it also has to permit certain messages to and from the firewall itself. especially the ones with link-local sources on links the firewall is attached to 🫶 these messages must be permitted so that Neighbor Discovery [RFC2462], Multicast Listener Discovery ([RFC2710], [RFC3810]), and Stateless Address Configuration [RFC4443] all work as expected. without them, everything just breaks, and that's not the vibe 💔
for recommendations on filtering ICMPv6 messages, check out [RFC4890] 📖✨
4.5.1. Problems Resulting from ICMPv6 Transparency
as described in Section 4.5, certain ICMPv6 error packets need to pass through a firewall in both directions. this means some ICMPv6 error packets can be exchanged between inside and outside without any filtering 👀
and here's the tea ☕ malicious users can use this to communicate between the inside and outside of a firewall, which bypasses the admin's inspection (proxy, firewall, etc.). for example, it might be possible to have a covert conversation through the payload of ICMPv6 error messages, or to tunnel inappropriate encapsulated IP packets inside ICMPv6 error messages. yikes 😱 the fix is to filter ICMPv6 errors using a stateful packet inspection mechanism, to make sure the packet carried as the payload is associated with legitimate traffic to or from the protected network. (we love a good safety net 🧷)
4.6. IPsec Transport Mode
IPsec provides security for end-to-end communications at the network layer (layer 3) 🔐 the security features available include access control, connectionless integrity, data origin authentication, protection against replay attacks, confidentiality, and limited traffic flow confidentiality (see [RFC4301] Section 2.1). and IPv6 mandates the implementation of IPsec in all conforming nodes, which makes it possible to secure end-to-end communication in a way that's generally NOT available to IPv4 (lowercase in the original, it's just me being extra 😂). slay 👑
to secure IPv6 end-to-end communications, IPsec transport mode would generally be the solution of choice 💖 BUT these IPsec security features can cause novel problems for network admins, and they can make perimeter firewalls less effective. why? because encrypted packets are way more common now, and firewalls can't do deep packet inspection and filtering on them 🙈
one example of these problems is the lack of security solutions in the middlebox. that includes effective content-filtering, the ability to provide DoS prevention based on the expected TCP protocol behavior, and intrusion detection 🚨 future solutions to this problem are discussed in Section 2.3.2. another example is an IPsec-based DoS (for example, sending malformed ESP/AH packets), which can be especially detrimental to software-based IPsec implementations 💀
4.7. Reduced Functionality Devices
with IPv6 rolling out, we can expect a very large number of new IPv6-enabled devices with scarce resources and low computing capacity 🧸 those resource limits are generally because of a market demand for cost reduction 💸 and although [RFC4294] specifies some mandatory security capabilities for every conformant node, those don't include the functions a node needs to protect itself. so some of these devices may not even be able to do the minimum needed to protect themselves (for example, a "personal" firewall, automatic firmware update, or enough CPU power to survive DoS attacks) 😩 which means a different security scheme may be necessary for these reduced functionality devices. the little guys need their own glow-up 🌱
4.8. Operational Factors when Enabling IPv6 in the Network
there are a few reasons it's essential to take extra care when enabling IPv6 on network equipment 🧐
first up, IPv6-enabled router software may be less mature than current IPv4-only implementations, and there's less experience configuring IPv6 routing 🍓 that can lead to disruptions in the IPv6 routing environment and (IPv6) network outages. oof 😬
next, IPv6 processing may not happen at (or near) line speed, or at a comparable performance level to IPv4 on the same equipment 🐢 a high level of IPv6 traffic (even legit traffic, like Network News Transport Protocol, NNTP) could easily overload IPv6 processing, especially when it's software-based without the hardware support you'd typically find in high-end routers. and this may have deleterious knock-on effects on IPv4 processing, which hits the availability of both services 📉 so if people don't feel confident in the IPv6 capabilities of their equipment, they'll be reluctant to enable it in their "production" networks. fair, honestly 🫠
sometimes essential features are missing from early vendor software releases 🙃 an example is software that enables IPv6 telnet/SSH access (for example, to a router's configuration application), but with NO ability to turn it off or limit access to it! (that's the one I'm mad about 😤)
sometimes the default IPv6 configuration is insecure too 🫣 for example, in one vendor's implementation, if you've restricted IPv4 telnet to just a few hosts in the configuration, you need to know that IPv6 telnet will be automatically enabled. the configuration commands you used before don't block IPv6 telnet, IPv6 telnet is open to the world by default, and you have to use a separate command to also lock down IPv6 telnet access. so many layers of "wait, what??" 🙀
many operator networks have to run interior routing protocols for both IPv4 and IPv6 🛣️ it's possible to run both in one routing protocol, or to have two separate routing protocols. either approach has its tradeoffs [RFC4029]. if multiple routing protocols are used, one should note that this causes double the amount of processing when links flap or when recalculation is otherwise needed. that might overload the router's CPU more easily, causing slightly slower convergence time 🐌 choose your chaos wisely, bestie 💅
4.9. Security Issues Due to Neighbor Discovery Proxies
to span a single subnet over multiple physical links, a new experimental capability is being trialed in IPv6: proxying Neighbor Discovery messages 🧪 a node with this capability is called an NDProxy (see [RFC4389]). NDProxies are susceptible to the same security issues as hosts using unsecured Neighbor Discovery or ARP 😬 these proxies may process unsecured messages and update the neighbor cache as a result, which lets a malicious node divert or hijack traffic 🦹♀️ this may undermine the advantages of using SEND [RFC3971]. ugh, not the plot 💔
if a form of NDProxy gets standardized, SEND will need to be extended to support this capability 🔧 we'll see you there 🩷
5. Security Considerations 🚨
this memo attempts to give an overview of security considerations for the different aspects of IPv6 💜 especially how they relate to the transition to a network where IPv4- and IPv6-based communications need to coexist. this is the part where everything we just talked about comes together, so pay attention, bestie 🫶
6. Acknowledgements 💖
Okay bestie, this is the thank-you list, and honestly everyone on it deserves a whole fan club 🫶 This doc pulled together loads of security work from the IPV6 and V6OPS working groups. Alain Durand, Alain Baudot, Luc Beloeil, Sharon Chisholm, Tim Chown, Lars Eggert, Andras Kis-Szabo, Vishwas Manral, Janos Mohacsi, Mark Smith, Alvaro Vives, and Margaret Wassermann gave feedback that made it better ✨ Satoshi Kondo, Shinsuke Suzuki, and Alvaro Vives added more input, working with the Deployment Working Group of the Japanese IPv6 Promotion Council and the Euro6IX IST co-funded project. Jordi Palet, Brian Carpenter, and Peter Bieringer helped too 🌸 Michael Wittsend and Michael Cole talked through the probing/mapping and privacy stuff, which is so important 🙈 Craig Metz and Jun-ichiro itojun Hagino did the original work spotting the problems with using IPv4-mapped IPv6 addresses on the wire, iconic behaviour 👑 Vishwas Manral dug into how tiny fragments affect IPv6 security 💅 Francis Dupont raised the issues around IPv6 Privacy Addresses 🦋 And Pekka Savola wrote a bunch of IPv6 security documents that got folded into this work. His "Firewalling Considerations for IPv6" (October 2003) was the first to flag many of the problems with the base IPv6 spec that are written up here. He literally started the whole thing, no cap 😭
7. References 📚
7.1. Normative References
These are the must-read ones, the foundations everything else sits on 🎀
[RFC1122]Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.[RFC2375]Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.[RFC2460]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.[RFC2461]Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.[RFC2462]Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.[RFC2710]Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.[RFC3056]Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.[RFC3775]Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.[RFC3810]Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.[RFC3964]Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.[RFC4007]Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.[RFC4291]Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.[RFC4380]Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.[RFC4443]Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.[RFC4941]Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
7.2. Informative References
These are the extra reading for the curious, the deep-dive playlist 🧚
[FNAT]Bellovin, S., "Technique for Counting NATted Hosts", Proc. Second Internet Measurement Workshop , November 2002, <http://www.research.att.com/~smb/papers/fnat.pdf>.[ICMP-ATT]Gont, F., "ICMP attacks against TCP", Work in Progress, May 2007.[IEEE.802-1X]Institute of Electrical and Electronics Engineers, "Port-Based Network Access Control", IEEE Standard for Local and Metropolitan Area Networks 802.1X-2004, December 2004.[JpIPv6DC]Deployment WG, "IPv6 Deployment Guideline (2005 Edition)", IPv6 Promotion Council (Japan) Deployment Working Group, 2005, <http://www.v6pc.jp/>.[RFC1858]Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.[RFC2765]Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.[RFC2766]Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.[RFC3128]Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.[RFC3315]Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.[RFC3493]Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.[RFC3756]Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.[RFC3971]Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.[RFC4025]Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.[RFC4029]Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.[RFC4038]Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.[RFC4074]Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005.[RFC4191]Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.[RFC4225]Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.[RFC4294]Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.[RFC4301]Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.[RFC4311]Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, November 2005.[RFC4389]Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.[RFC4472]Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006.[RFC4864]Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.[RFC4890]Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.[RFC4966]Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Historic Status", RFC 4966, July 2007.[SCAN-IMP]Chown, T., "IPv6 Implications for Network Scanning", Work in Progress, March 2007.[SIXNET]6Net, "Large Scale International IPv6 Pilot Network", EU Information Society Technologies Project , 2005, <http://www.6net.org/>.[TCGARCH]The Trusted Computing Group, "TCG Specification Architecture Overview", April 2004, <https://www.trustedcomputinggroup.org/groups/TCG_1_0_Architecture_Overview.pdf>.[VRRP]Hinden, R. and J. Cruz, "Virtual Router Redundancy Protocol for IPv6", Work in Progress, March 2007.
Appendix A. IPv6 Probing/Mapping Considerations 🔍
Okay so, there were two schools of thought here 🍓 One group wanted the IPv6 numbering topology, whether at network or node level, to match IPv4 as closely as possible. Others saw IPv6 as a chance for more flexibility in address plans and didn't want the addressing design to be boxed in. Nowadays, mirroring the address plans is generally seen as a security threat, because an IPv6 deployment may have different security properties from IPv4. Not ideal, periodt 💀
Now, IPv6 network security is still pretty immature, so if an attacker knows a node's IPv4 address and thinks it's dual-stacked with IPv4 and IPv6, they might try probing the matching IPv6 address. Their logic is that the defenses there might be weaker. This is especially likely for nodes that sit behind a NAT in IPv4 but are globally addressable in IPv6 😬 Naturally, none of this is a worry if similar and adequate security policies are in place 💅
On the flip side, brute-force scanning or probing of addresses is computationally infeasible, thanks to the huge search space of interface identifiers on most IPv6 subnets. That space is somewhat less than 64 bits wide, depending on how identifiers are chosen. This holds as long as identifiers are picked at random out of the available space, as discussed in [SCAN-IMP] ✨
Here's where it gets messy 🙃 Automatic tunneling mechanisms typically use deterministic methods for generating IPv6 addresses, which makes probing and port-scanning an IPv6 node a lot simpler. The IPv4 address is embedded at least in 6to4, Teredo, and ISATAP addresses. With 6to4 in particular, you can also learn the address behind the prefix. For example, the Microsoft 6to4 implementation uses the address 2002:V4ADDR::V4ADDR, while older Linux and FreeBSD implementations default to 2002:V4ADDR::1. That can be used to identify an implementation and then target any specific weaknesses it has 😭
One proposal was to randomize the addresses or subnet identifier in the 6to4 router's address. Sadly, this doesn't really help, because the 6to4 router, whether it's a host or a router, will return an ICMPv6 Hop Limit Exceeded message that reveals the IP address. Hosts behind the 6to4 router can use methods such as privacy addresses [RFC4941] to hide themselves, as long as they aren't meant to be reachable by sessions started from elsewhere. If they do want to receive communications initiated from elsewhere, they would still need a globally accessible static address 🦋
To wrap it up: when an automatic tunneling mechanism is in use, the corresponding IPv6 address could possibly be guessed fairly easily from a given IPv4 address. That's a big deal if the IPv6 security policy is weaker than the one for IPv4 🚨
Appendix B. IPv6 Privacy Considerations ✨
okay bestie, privacy is a BIG deal 🔐 so let's get into it. Making IPv6 addresses out of MAC addresses could let people track what users do, which might be a privacy violation 😬. [RFC4941] has mechanisms that can lower that risk 🛡️. People have also claimed IPv6 is bad for privacy, either by exposing the MAC address or by exposing how many nodes are connected to a site 👀.
More privacy talk lives in [RFC4864] 📚🧚
B.1. Exposing MAC Addresses
so with stateless address autoconfiguration, the MAC address gets baked into an EUI64 🧩, which can reveal the model of the network card 💻. The worry is that a user might not want outsiders knowing their gear. Like, a thief could spot expensive equipment from the vendor identifier in a MAC address 🦹♀️, or someone could figure out what equipment is in use and go after specific security weaknesses 🎯 💀
ngl, in most cases this seems totally unfounded 🙄. First, an address has to be learned somehow, and that's not easy 🕵️♀️. Those addresses do show up in things like Web site access logs, but the chances that some random Web site owner is collecting this info (or that it'd even be useful to them) are pretty slim 😅. Eavesdropping on traffic to pick up addresses (say, by compromising DSL (Digital Subscriber Line) or Cable modem physical media) also seems super far-fetched 🙃. And if you're really worried, using statically configured interface identifiers or privacy addresses [RFC4941] for this stuff is straightforward 💅. Second, the burglar would need to map the IP address to a physical location. That usually only works with the ISP's private customer database and, for big sites, the site's administrative records 🗂️. Some physical address info might still be available from the WHOIS database of Internet registries, though 📍
B.2. Exposing Multiple Devices
another concern people have aired is wanting to hide how many computers or other devices are on a network 👻. NAT can "hide" all that equipment behind a single address, but it isn't perfect either [FNAT] 🫣
one practical reason some admins find this desirable is that it can mess with certain ISPs' business models 💸. Those models charge based on the number of connected computers, rather than on the connectivity as a whole 🧾
similar feasibility issues to the ones above apply 🤷♀️. To a degree, the number of machines could be obscured by reusing privacy addresses [RFC4941] often enough 🔄. Like, if dozens of generated addresses seem to be in use during a short period, it's hard to tell whether one host made them all or multiple hosts did 🤔
B.3. Exposing the Site by a Stable Prefix
when an ISP gives IPv6 connectivity to its customers, including home or consumer users, it delegates a fixed global routing prefix (usually a /48) to them 🏠. This is different from the typical IPv4 setup, where home users get a dynamically allocated address that may only stay stable for a few hours ⏰
because the allocation is fixed, it's easier to correlate the global routing prefix to a network site 🔗. With consumer users, that correlation becomes a privacy issue, since a site is often basically one individual or one family 👨👩👧. So some users might be concerned about being tracked by their /48 allocation if it's static [RFC4941] 😟. On the flip side, plenty of users may actually find a static allocation desirable, since it makes hosting services on their network way easier 🖥️✨
🚨 changing your interface ID or subnet ID doesn't fix this, because malicious users can still discover the binding 🙅♀️
on bigger sites, the situation can be helped by using "untraceable" IPv6 addresses as described in [RFC4864] 🛡️. It's also possible that ISPs might be ready to offer untraceable addresses to their consumer customers someday to minimize privacy issues 🔮
this privacy issue is common to both IPv4 and IPv6 🌍. It's inherent in using IP addresses as both identifiers for node interfaces and locators for the nodes 🧠💜
Authors' Addresses 👩💻
Elwyn B. Davies
Consultant
Soham, Cambs
UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC H4P 2N2
Canada
Phone: +1 514-345-7900
EMail: suresh.krishnan@ericsson.com
Pekka Savola
CSC/Funet
EMail: psavola@funet.fiFull Copyright Statement ©
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🎀
okay, so the IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) that might be claimed to cover the technology in this document are valid or in scope 🤐. It also doesn't say whether any license under those rights might be available, and it hasn't independently tried to find any such rights 🔍. If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79 📖
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users of this specification to use those proprietary rights can all be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🗃️
and the IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard 📬. Send that info to the IETF at ietf-ipr@ietf.org 💌🫶
📦 where this page comes from
- ietf: rfc4942 2007-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms