The article Top 10 Tasks for IPv6 Application Developers provides a concise overview of concerns when developing new applications that will support or enabling existing applications to support both a network infrastructure where only Internet Protocol version 4 (IPv4) is present and a network infrastructure where IPv4 and IPv6 are both present (dual-stack). Section 8 of that article describes IPv6 support in the Run Time Libraries (RTL) of various languages. That article was written over 10 years ago.
Since 2020, applications being developed no longer need to support dual-stack network infrastructures, The Internet Engineering Task Force (IETF) issued Request for Comments (RFC) 8925 IPv6-Only Preferred Option for DHCPv4, which enables IPv4-only and dual-stack nodes on a local-area network to continue to be supported while all new and updated nodes on the network will be IPv6-only (sometimes referred to as IPv6-mostly access), making The Need for IPv6-only Product Support even more important.
The article Designing and Testing IPv6-enabled Networking Software provides a broad overview of concerns when developing applications, while this presentation Application Development for IPv6 considers some more technical aspects. The more recent How Software Engineers Can Make Their Apps IPv6 Ready article and Preparing Apps for IPv6 (presentation and paper) provide details for several of those concerns. This Department of Veterans Affairs IPv6 Applications Testing Best Practices document includes a section with best practices for developing applications, plus another section with best practices for testing them. In contrast to IPv4, applications that generate IPv6 packets larger than the default path Maximum Transmission Unit (MTU) configured for the local network must use raw sockets rather than the sockets supported by the RTL of various languages, as described in this article.
This guide provides additional information for application developers. Tips on writing applications to run on multiple operating systems are offered by this Cross-Platform IPv6 Socket Programming article, while this IPv6 Guide for Windows Sockets Applications article offers tips on developing applications to run on Microsoft Windows operating systems.
The Application Conversion Tools article under the Applications section identifies conversion tools, utility software, and provides links to additional books, articles, and presentations on developing or enabling an application written in C/C++, Java, Python, Perl, or PHP to support both dual-stack and IPv6-only networking infrastructures and then testing the application. The IPv6, Samba, and CIFS article under the Infrastructure section describes the use of one such tool in enabling applications to support both IPv4 and IPv6. The IPv6 and PHP article under the Infrastructure section provides additional references for enabling PHP to support both IPv4 and IPv6.
Several RFCs published by the IETF describe the structure and use of sockets in applications that support IPv6:
RFC 3493 Basic Socket Interface Extensions for IPv6
RFC 3542 Advanced Sockets Application Program Interface (API) for IPv6
RFC 4038 Application Aspects of IPv6 Transition
RFC 4584 Extension to Sockets API for Mobile IPv6
RFC 5014 IPv6 Socket API for Source Address Selection,
and this RFC describes the requirement for IPv6 support in both new and existing hardware and applications:
RFC 6540 IPv6 Support Required for All IPv6-Capable Nodes.
The Neighbor Discovery Protocol (NDP) for Internet Protocol version 6 (IPv6) is described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 4861 (as further updated by RFCs 5942, 6980, 7048, 7527, 7559, 8028, 8319, 8425 and 9131). It effectively replaces the Address Resolution Protocol (ARP) used by IPv4. Subsection 3.5.3 of the National Institute for Standards and Technology (NIST) Special Publication (SP) 800-119 Guidelines for the Secure Deployment of IPv6, Dec, 2010, briefly describes the NDP and its improvements over the ARP, and Subsection 3.5.4 of that publication briefly describes some of the security ramifications. In addition, RFC 6105 Router Advertisement Guard (RA-Guard) as further updated by RFC 7737, and Internet Draft ND-Shield have been published. They describe mitigations for the various NDP threats as originally identified in RFC 3756 published in 2004 and described in the remainder of this article. RA-Guard is also discussed in Definition and Prevention of rogue Router Advertisements in the DHCP and SLAAC on IPv6 Networks article in the Infrastructure section. References in the IPv6 and IoT Security Best Practices article in the Security section also describe mitigations for various NDP threats.
The SEcure Neighbor Discovery (SEND) protocol described in RFC 3971, as further updated by 6494, 6495, and 6980, has been defined which can counter many of the threats to the NDP described in the remainder of this article. Subsection 5.4.2 of the above NIST SP 800-119 publication briefly describes the SEND protocol. Subsection 5.4.3 states that to date the SEND protocol has been neither widely implemented nor deployed. This presentation discusses why this is the case and offers some solutions.
In 2015, a series of articles on the SearchNetworkingTechTarget.com website described mitigations for and ways to avoid "Neighbor Discovery Protocol Attacks":
- How to avoid IPv6 neighbor discovery threats
- How to protect your IPv6 address management
- Mitigating IPv6 neighbor discovery attacks
- IPv6 attack attempts and how to mitigate them.
(Note: Embedded in each article is a “Continue Reading This Article” warning. Ignore the warning and scroll down to continue reading the article.)
The remainder of this article presents a summary of security threats associated with the IPv6 Neighbor Discovery protocols as described in RFC 3756. The designers of these protocols initially proposed IPsec as a mechanism to secure the protocols and the process of autoconfiguration. Since these protocols generally involve the bootstrap process, where a node does not know its full IPv6 address, automatic key management (via Internet Key Exchange [IKE1 which was obsoleted by the later IKE2] as further updated by RFCs 7427, 7670, 8247, 8983 and 9370) is not possible. This requires IPsec Security Associations (SAs) for these protocols to be manually configured. This manual configuration is tedious, error-prone, and scales poorly for even small networks. The vulnerabilities presented here warrant the use of some other mechanism to secure these processes.
RFC 3756 pays particular attention to the threat levels of each of these vulnerabilities in different environments. The environments considered are:
A. A corporate network where clients are expected to be well-behaved and not perform attacks on other nodes. The exception to this is if a node is compromised by a malicious user. Most workplace networks will fall into this category.
B. A public network where the infrastructure is generally trusted to be well-behaved, but other clients on the network are not trusted. This environment is typical of home users connecting to a public Internet Service Provider or to a known wireless network.
C. An ad-hoc network where the network infrastructure as well as the attached nodes cannot be trusted to be well-behaved.
1. Neighbor Solicitation / Neighbor Advertisement Spoofing
Attacking node sends neighbor advertisement with bogus binding of IP address and address. This is similar to ARP spoofing. Node A now sends traffic destined for Node B to this arbitrary media access control (MAC) address. If there is no response from the arbitrary MAC address, node A will eventually perform Neighbor Unreachability Detection (NUD) at which time the bogus binding will be flushed from it’s cache. Attacking node must respond to the NUD or issue another neighbor solicitation to continue the attack.
Environment “A”: Susceptible, at least one solution known
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, at least one solution known
2. Neighbor Unreachability Detection (NUD) failure
An attacking node may spoof Neighbor Advertisements, which can cause the NUD process to fail to recognize an unreachable node. The result is a Denial Of Service (DoS) attack, which keeps the attacked node from realizing that another node is, in fact, unreachable.
Environment “A”: Not Susceptible
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, at least one solution known
3. Denial of Service while obtaining address
Attacking node sends bogus neighbor solicitation during Duplicate Address Detection (DAD) of node. Node A attempts to detect of an address is currently in use before assigning that address to its interface. Attacking node replies with bogus response to make node A think that it’s address is already in use. The result is that node A cannot use that address. This attack can be continued for all of node A’s DAD attempts resulting in the failure for node A to acquire an address.
Environment “A”: Not Susceptible
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, at least one solution known
4. Malicious Last-Hop Router
An attacker can multicast bogus router advertisements (RAs) on a link or send bogus RAs (unicast) in response to router solicitations. If a node selects a bogus RA, the attacker can masquerade as a router and may perform man-in-the-middle attacks at the IP layer or discard legitimate traffic.
The attacker may also spoof RAs that appear to come from the legitimate router that specify a lifetime of zero, which will trick the node into thinking that the legitimate router will not route packets. This threat is partially mitigated by careful inspection of the lifetimes in RAs.
Environment “A”: Susceptible, at least one solution known
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, solution being researched
5. Eliminating all legitimate routers
If an attacker can make a node believe that all routers are unavailable (by crashing them, performing DoS attacks, or by convincing nodes that all routers are inaccessible), the node will assume that all destinations are “on-link” (per RFC 2461 as updated by RFC 4311 and obsoleted by RFC 4861 which was in turn obsoleted by a series of RFCs ending in 8028). This will cause a node that wishes to send packets to a node that is really off-link to attempt a Neighbor Discovery to find the node as if it were on-link. At this point, attacks are feasible for on-link nodes only can be extended to off-link hosts.
Environment “A”: Susceptible, at least one solution known, further solution being researched
Environment “B”: Susceptible, at least one solution known, further solution being researched
Environment “C”: Susceptible, solution being researched
6. Spoofed Redirect Message
An attacker may spoof a redirect packet that appears to come from a legitimate router. This will instruct the node to redirect packets for any given destination to an arbitrary link-layer media MAC address.
Environment “A”: Susceptible, at least one solution known
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, solution being researched
7. Bogus On-Link Prefix
An attacker can send a spoofed RA specifying that a particular prefix is on-link. When other on-link nodes try to communicate with a node that is on the spoofed prefix, it will attempt to communicate as if it were on-link (using Neighbor Discovery). The result is a DoS, since local nodes attempt to communicate via the local link, instead of through a router to get to destinations that are really off-link. This attack can have a large impact if the advertised prefix is short.
This attack can be extended to perform man-in-the-middle attacks or other DoS attacks if the attacking node masquerades as the target destination node.
Additionally, this attack can be extended to insert a large number of bogus routing table entries on all nodes, exhausting resources required to store the
routing entries.
Environment “A”: Not Susceptible
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, solution being researched
8. Bogus Address Configuration Prefix
An attacking node can spoof an RA message with a bogus prefix. Nodes performing address autoconfiguration with this RA may assign a bogus address to their interface. When the attacked node attempts to use the bogus source address to send packets off-link, responses will not be successfully routed back to the node.
This attack can further be expanded if the attacked node automatically performs a dynamic DNS update with the new (bogus) address. If this happens, other nodes performing DNS name resolution may get a bogus address, which will not get to the intended node. If the attacker specifies his own prefix in the bogus RA, application requests from anywhere on the Internet that use the DNS name may be routed to a node under control of the attacker. It may be simple for the attacker to insert a reverse-lookup entry to map the bogus address back to the hostname of the attacked host.
A variation of this attack is to advertise the prefix of a link that will be the target of a DoS attack. Nodes will use the bogus source address, and all replies to traffic sent from those nodes will be routed to the targeted network prefix causing a DoS.
Environment “A”: Not Susceptible
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, solution being researched
9. RA Parameter Spoofing
A bogus RA may specify an extremely low “Cur Hop Limit” field that nodes will use when sending packets. If this value is set low enough, packets sent off-link might not reach their final destination before the hop-limit is exceeded causing a DoS.
Another form of bogus RA can have the ‘M’ or ‘O’ bit set, which causes a node to use stateful address autoconfiguration (such as DHCPv6). An attacker can set up a bogus stateful address autoconfiguration service (e.g. a fake DHCPv6 server) that can assign arbitrary addresses to nodes.
Environment “A”: Not Susceptible
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, solution being researched
10. Replay Attacks
None of the Neighbor Discovery or Router Discovery messages have fields that could be used to prevent replay attacks. Previously transmitted legitimate packets can be replayed, supplying configuration or state information that may be out of date. This could lead to a DoS or redirection of traffic attacks as previously described.
Any security mechanism applied to Neighbor Discovery or Router Discovery messages should address replay attacks.
Environment “A”: Susceptible, at least one solution known
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, at least one solution known
11. Neighbor Discovery Flood DoS
Any host on the Internet can send a packet to an arbitrary address on a given prefix. If the last hop router has no recollection of the address in the packet, it is required to perform a neighbor solicitation in an attempt to find a node at that address. An attacker can flood the last hop router with packets, each requiring a neighbor discovery action, which uses up resources on the router. This is similar to TCP SYN flooding.
A variant of this is tricking an application flood its link with packets for non-existent nodes (virus or Trojan could invoke rogue application behavior).
Environment “A”: Susceptible, at least one solution known
Environment “B”: Susceptible, at least one solution known
Environment “C”: Susceptible, at least one solution known
For a long time, an “IPv6 is more secure” myth persisted because the IPv6 protocol required that Internet Protocol Security (IPsec) be implemented. Or at least it did, until Request for Comments (RFC) 6434 was adopted in 2011. (Since obsoleted in 2019 by RFC 8504.) Deploying and maintaining IPsec can be difficult for many reasons. This article describes some persistent misconceptions about IPv6 security. This publication from the National Security Administration (NSA) provides multiple configuration examples to facilitate the correct use of IPsec. This presentation describes a deployment of IPv6 multicast in conjunction with IPsec.
“Security” should not be used as a strong reason to consider deploying IPv6. More information on IPsec is available in this article and this later article from Salient CRGT (previously Command Information, Inc., now part of GovernmentCIO LLC). Since the Salient CRGT articles on this topic were published, this article from Nephos6 commented on the ramifications of what would become RFC6434.
Introduction
Vulnerability testing (also known as vulnerability assessment or scanning) is the inspection of one or more network services, resources or daemons on a network to check for the presence of known potential security vulnerabilities. Penetration testing is the determination that potential security vulnerabilities are (or are not) present in one or more network services, resources or daemons on a network by attempting to actually exploit them. Vulnerability Remediation is the implementation of measures that will remove known security vulnerabilities or that will minimize their impact when an attempt to exploit them occurs. This article explains the differences between vulnerability testing and penetration testing.
A vulnerability scanning tool is used to conduct vulnerability tests. As this article explains, a vulnerability scanning tool is only one of a wide variety of different penetration testing tools that may be used during a penetration test, along with a wide variety of testing techniques and methods. There are major differences between vulnerability scanning and penetration testing, as any company that offers penetration testing services will be quick to point out. A Google search of the web for “vulnerability assessment vs penetration testing” will find many articles describing those differences.
Vulnerability Testing
Vulnerability scanning tools are, for the most part, the same between Internet Protocol version 4 (IPv4) and IPv6, and many support both protocol families. There are many open source and commercial vulnerability scanning tools. There are also many articles available on the web reviewing and recommending such tools. This Open Web Applications Security Project (OWASP) article is only one among many listings of such tools.
Such tools generally detect and then inspect services or daemons that are listening on a specific network address, on any address in the address space of a network, or within a defined subset of the address space for a network, and then report the existence of any potential security vulnerabilities discovered during the inspection. Daemons are mostly IP version agnostic, so detection and vulnerability assessment is the same for IPv4 and IPv6. For a more in-depth discussion of the differences between vulnerability scanning in IPv4 versus IPv6, see this article.
The main differences between IPv4 and IPv6 are in the ability to detect services and daemons. It is rather easy to search a /24 IPv4 subnet. There are only 254 possible addresses. The smallest of IPv6 subnets are usually /64s (18 quintillion addresses!). You obviously cannot scan an entire /64 in a reasonable manner provided the addresses of the services and daemons listening on that subnet are securely assigned. Stateless Address Autoconfiguration (SLAAC) or Dynamic Host Configuration Protocol version 6 (DHCPv6) assigned addresses where the DHCPv6 server assigns randomized values are examples of secure assignment methods. Examples of insecure assignment methods include manually assigning addresses sequentially over a small range or embedding the IPv4 address of each service or daemon together with a static prefix/suffix in the IPv6 address of that service or daemon.
An attacker must then rely on active discovery of services and daemons on a network by exploiting Internet Control Message Protocol version 6 (ICMPv6) vulnerabilities or by passively monitoring the network. The same goes for IPv4 as well, although on a greatly reduced scale. Some say that there is a bright side to this: it is also harder for attackers to find services and daemons on an IPv6 network. But remember, attackers only have to find one vulnerable service or daemon, we have to protect them all!
Penetration Testing
While there is no one “right” way to conduct a comprehensive penetration test, there are many ways to conduct a penetration test which produces inconclusive or incomplete test results. Some of the open source communities and noncommercial groups that have developed guidelines describing comprehensive penetration testing processes include:
1. Penetration Testing Executive Standard (PTES) v1.0, 2014
(The PTES is a detailed, comprehensive document. An overview of the PTES is available in this article, which also mentions the next 3 guidelines.)
2. Penetration Testing Framework, 2014
3. Information Systems Security Assessment Framework, 2020 (An overview of the ISSAF is available in this article.)
4. Open Source Security Testing Methodology Manual (OSSTMM), 2010
5. PenTesters Framework (PTF) v2.0, 2018 (an evolutionary descendant of the PTES in item 1 above)
Discussions in these guidelines often do not distinguish between IPv6 and IPv4. Many of the specific testing techniques and methods described in these guidelines are internet protocol agnostic, applying to both IPv6 and IPv4. Others need to be modified due to differences between the protocols, which means some tests will need to be performed twice, once for each protocol. The Impact of IPv6 on Penetration Testing, 2012, and Testing the security of IPv6 implementations, 2014, are papers that discuss the need for those modifications.
When conducting specific penetration tests, however, the internet protocol being used must always be considered. Various commercial, government and academic organizations have tested a variety of tools to evaluate their support for IPv6 and reported their findings. A few of these reports are identified below. A single database or website that consolidates the findings does not exist.
- Results for web applications and server testing are given in this: Master Thesis: Penetration Testing over IPv6, Jun, 2012.
- The results of another analysis of penetration testing tools is described here.
- Search the University of Amsterdam System and Network Engineering OS3 Archive of Master's Theses from 2003-2004 to 2021 (https://www.os3.nl/archive/research_projects) for testing topics, such as “Security of IPv6 and DNSSEC for penetration testers, 2010-2011” (an expanded version was subsequently published in book form, ISBN-13: 978-3848422814). (Those Master's Theses are grouped by academic year).
- Search the System Administration Networking and Security (SANS) Institute white papers topics such as IPv6, for example "A Complete Guide on IPv6 Attack and Defense”. [Use the scroll bar on the left side of the search window to scroll through the white papers.]
Vulnerability Remediation
The Cybersecurity Infrastructure Security Agency (CISA) published Binding Operational Directive 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, Nov, 2021, providing guidance on how to remediate vulnerabilities identified in the Known Exploited Vulnerability (KEV) Catalog. At the same time, the CISA also issued Reducing the Significant Risk of Known Exploited Vulnerabilities, a web friendly version of that directive prescribing timelines for remediating the risks identified therein.
Microsoft Windows supports something called Internet Connection Sharing (ICS), which allows several computers to share one Internet connection without using a hardware router. In the home networking environment of the past, ICS was sometimes used as an economical way to connect several computers to the Internet. Microsoft supported ICS in Windows Vista and Windows XP, and still supports it in Windows 7 and 8/8.1/10/11 (although it is disabled by default).
However, when used in conjunction with Internet Protocol version 6 (IPv6) ICS causes severe configuration problems and creates strong security concerns. Almost all commercial, enterprise, and academic networks strongly recommend against the use of ICS. They will/should try to detect and deny access to any computer which has ICS enabled when it attempts to connect to their network. The various "Enabling IPv6 in Microsoft Windows ..." articles in the IP Transport section describe how to check the status of ICS on a system and disable it if enabled. Windows 10 (versions 1709 and prior only) contained a further evolution of ICS called Wi-Fi sense which should also be disabled if present, as described in the Enabling IPv6 in Microsoft Windows 8 and later Versions article.
When a Windows computer with ICS enabled is connected to a network, it sends out unauthorized Router Advertisement (RA) packets. Such packets are called "Rogue RAs", and are described in more detail in Definition and Prevention of rogue Router Advertisements in the DHCP and SLAAC on IPv6 Networks article in the Infrastructure section.