Why IPv6 SEND will fail

26 03 2013

Before going into the security extension of the IPv6 Network Discovery Protocol (RFC 4861) called SEcure Network Discovery Protocol (RFC 3971) and why I think it will fail as a standard, I’d like to lay some groundwork by briefly touching on IPv6 adoption barriers, explaining the classic “Security, Ease-of-Use, Functionality Triangle” (Cyber Safety 1-5) and the default IPv6 behavior for network discovery and address assignment.   We will then look at how SEND attempts to secure the network discovery process.  I hope that by the end of the work the reader will see that while security is always an ideal, it isn’t always practical in its implementation and systems must have a degree of practicality on the Internet if they are to be adopted.

It is my observation from over 15 years’ experience in IT, a BS BA in MIS, MS in MIS, CISSP, and CCNA that IPv6 as a standard is very slow in its adoption due to a working infrastructure independent of IPv6, its highly disruptive nature, a lack of supporting equipment, and a general ignorance of the technology.  The only way for IPv6 to obtain global adoption is by force of emptying the IPv4 address pool.  Marketing tools such as “World IPv6 Day” are efforts to migrate networks before depletion of the IPv4 pool and subsequent service availability to those without an IPv4 address and vice versa.

The “Security, Ease-of-Use, Functionality Triangle” is one way of illustrating the fact that security, if not contradictory, works against an intuitive interface and the amount of a product’s functionality.  This idea is supported in the book Geekonomics.  In this book the author states that security is often left aside because functionality sells products.  Increased functionality increases complexity which drives up the costs to making those features secure (Rice).  Making a product more secure also makes it harder to use.  One must look no further than the standard computer login screen.  Many of us boot straight into our OS for our personal computers while at work we must certainly login first.  We boot straight into the OS because it is easier. As to make us not look like extreme lackeys, perhaps we do so because we rely on a layered security approach of our doors and windows being locked with alarm systems so we feel we don’t need login prompts.


We can see in the figure that the product is represented by the dot within the triangle.  As the dot moves towards Ease of Use, it moves away from Functionality and Security.  Think Linux versus Windows here.  Linux has functionality well beyond Windows but can be much harder to use.  OS manufacturers try to bridge the gap with a GUI and command prompt interfaces.  So to build a completely secure system, it must be limited to only those functions required and those functions guarded so as to function only as intended, when intended.


Keep this idea of the triangle with you while we transition to IPv6 Network Discovery and SEcure Network Discovery as we will circle back to it at the end.

One of the perks of IPv6 is a client’s ability to obtain an address without the use of a DHCP server.  It isn’t much of a perk since DHCP is already standard in most environments.  In fact, because DHCP is already standard, IPv6 Network Discovery with Stateless Address Auto configuration (SLAAC) can become disruptive at implementation.

Here is how SLAAC works:

An IPv6-enabled router is configured by default to answer to the multicast address FF02::2.  Anytime an IPv6-enabled devices needs to discover what network they are on, it will send a multicast Router Solicitation Packet to FF02::2.   The local gateway will respond with a multicast Router Advertisement packet from the router’s interface MAC address to the multicast address FE02::1.  FE02::1 is a standard all IPv6 speakers multicast group. The Router Advertisement packet includes the network prefix and default gateway.  From this the host can derive a link local IP address, globally unique IP address and a randomized globally unique IP address.  All three are based on its local network block.  The link local and non-random globally unique IP addresses are created from the extended unique identifier-64 (EUI-64) process.  In short, EUI-64 has the host flip the 7th bit of the 48-bit host MAC address (if it’s a one, it becomes a zero and vice versa) and adds the 16-bit hexadecimal value FFFE in the middle of the address to round out the 64-bit requirement of the 128-bit IPv6 address (Barker).



Once this is completed, the host sends a Neighbor Solicitation packet to the derived IPv6 address.  If it receives no response, it knows it is a unique address and the host assigns it to its interface.  This process is called duplicate address detection (DAD).  It runs DAD for each of its IPv6 addresses (link local, globally unique and random globally unique) and its completion also closes the SLAAC process (Barker).

4The SLAAC behavior is supported by industry standard manufacturers making it easier to implement when transitioning to IPv6.  It provides full network functionality using an automated process.  On the triangle, one could reasonably argue that SLAAC is on the bottom center as there are little safeguards from rouge gateways providing false network or gateway addresses.

SEND attempts to remedy some of the insecurities through the reliance on a public key infrastructure.  The chart below provides a good brief of known insecurities in IPv6 Network Discovery Protocol and SEND’s remedies.

The chart makes it a bit plainer to see how SEND uses crypto signatures to guard against a number of attacks.  Again, SEND is an extension to NDP, not a replacement.  The same router and neighbor solicitations and advertisements are used. They are just digitally signed. The problems with this tact are:


  • It is difficult to implement as it requires an established Certificate Authority (CA) on the network.
  • The CA’s root certificate must first be trusted by hosts and routers before any Network Solicitation or Advertisement packets are accepted.  This means either pre-staging equipment with the root certificate or undergoing an initial period of insecurity while accepting the initial untrusted advertisements.
  • The IP addresses move from EUI-64 or static, to a Cryptographically Generated Address (CGA). This address is unrecognizable and more difficult to manage.
  • Opens routers to DoS attacks before each signed message must be run through a crypto algorithm before acceptance/rejection.  This taxes the processor to the point where a flood of NDP messages could consume enough resources to impact router functionality.

While SEND does provide additional security against spoofing router and host messages, it does not provide enough functionality, and is difficult to implement and support.  SEND moves too far North on the triangle to be a practical solution.  It is for these reasons I believe that neither Microsoft nor Apple support SEND (Perschke).  This will prove to be the final nail in the coffin.  Without major vendor support, there is nothing to implement at the start.


Narten, T., IBM, E. Nordmark, Sun Microsystems, W. Simpson, Daydreamer, H. Soliman, and Elevate Technologies. “Neighbor Discovery for IP version 6 (IPv6).” RFC 4861. Internet Engineering Task Force (IETF), Sept. 2007. Web. 11 Feb. 2013. <http://tools.ietf.org/html/rfc4861&gt;.

Arkko, J., Ericsson, J. Kempf, DoCoMo Communication Labs USA, B. Zill, Microsoft, P. Nikander, and Ericsson. “SEcure Neighbor Discovery (SEND).” RFC 3971. Internet Engineering Task Force (IETF), Mar. 2005. Web. 11 Feb. 2013. <http://www.ietf.org/rfc/rfc3971.txt&gt;.

International Council of E-Commerce Consultants. Cyber Safety. Clifton Park, NY: EC-Council Press, 2010. Print.

Rice, David. “Six Billion Crash Test Dummies: Irrational Innovation and Perverse Incentives.” Geekonomics: The Real Cost of Insecure Software. Upper Saddle River, NJ: Addison-Wesley, 2008. Print.

Barker, Keith. “IPv6-04 IPv6 Stateless Address Autoconfiguration (SLAAC).” YouTube. 25 Aug. 2011. Web. 10 Feb. 2013.

Lakshmi. “IPv6.com – Secure Neighbor Discovery (SEND).” IPv6.com – The Source for IPv6 Information, Training, Consulting & Hardware. N.p., 2008. Web. 11 Feb. 2013. <http://ipv6.com/articles/research/Secure-Neighbor-Discovery.htm&gt;.

Perschke, Susan. “Hackers target IPv6.” Network World – Network World. N.p., 28 Nov. 2011. Web. 11 Feb. 2013. <http://www.networkworld.com/news/2011/112811-hackers-ipv6-253408.html&gt;.

Stretch, Jeremy. “IPv6 neighbor discovery.” Packet Life. N.p., 28 Aug. 2008. Web. 11 Feb. 2013. <http://packetlife.net/blog/2008/aug/28/ipv6-neighbor-discovery/&gt;.