Some time ago I was working on IPv6 implementation and in that period I wrote an article about NDP (you can read it here). After a while I received some comments that is not written very well so I reviewed a huge part of it. It looks my english was far worst two years ago that I was really aware of 🙂
In the reviewing process I realised that NDP usage of Solicited-Node multicast addresses was not clearly explained. This is the follow-up article which should explain how and why Solicited-Node multicast address are used in NDP. After all this kind of multicast addresses are there to enable IPv6 neighbor discovery function of NDP to work properly.
Solicited-node multicast address is IPv6 multicast address used on the local L2 subnet by NDP Network Discovery Protocol. NDP uses that multicast address to be able to find out L2 link-local addresses of other nodes present on that subnet.
NDP replaces ARP
As we know, NDP in IPv6 networks replaced the ARP function from IPv4 networks. In IPv4 world ARP used broadcast to send this kind of discovery messages and find out about neighbours IPv4 addresses on the subnet. With IPv6 and NDP use of broadcast is not really a good solution so we use special type of multicast group addresses to which all nodes join to enable NDP communication.
In my current studies I did some work about security inside networking data paths. In my recent work I tried to get some experiments done that needed to use source based routing in order to be completed. Like most of scientific work that tries to get from paper to experiment and then to something useful, it failed at the very beginning. If I can be more precise and improve a bit the appearance of my failure here. I can do it by explaining what happened and what did I came across while researching my idea. It’s something as simple as this:
Source based routing, by the suggestion of IETF needs to be disabled by default on networking devices. At least it should be as the feature itself is recognized as a major security threat and IETF itself is trying to get rid of it.
Of course that can be considered like a stop sign in an experiment where you are relying solely on source based routing to get your thing running. (:
When you look at the networking technology these days that’s probably IP protocol that you are talking about. Okay maybe you are new age junkie and the you are probably speaking about IPv6 protocol. Either way, the very first and main principle of routing packet across data network is based on destination IP address routing/decision making. Router is making decision on where will he send some packet based more or less solely on destination IP address. It is doing so by reading his locally built routing table of destination subnets. From that table router gets the info out of which interface will he sent the packet that is destined for some address.
Anycast is basically the same on IPv4 and IPv6 so this part below refers to both.
As the name says it’s an address that can exist more than once anywhere in the network. If we look public IP space that’s available on the Internet, anycast IPv6 address can exist on multiple places all over the Internet. This kind of address is basically enabling us to have servers and services physically closer to us as they would be if the unicast address was used. It this way we are able to have, for example, a server with one anycast IP address somewhere in US and other server with same service and same IP address somewhere is Europe. If I am in Europe, closest server with that IP address will handle my request. Without to much additional technology solutions my service will automatically be resolved to server who is closer to me and it will probably also improve service security and speed. All that is called load balancing and can be accomplished by different networking solutions and technology designs but anycast addressing is basically the simplest method possible to enable this kind of “geo” localization for a service.
How anycast works?
As said before anycast addresses are called anycast because one address can be assigned to multiple interfaces inside the same network. Packets that are going to anycast IP destination address will be caught by nearest device. Today’s anycast IP addresses are used on some special routers and the most important thing that runs them is Global Internet’s DNS root servers service. Google also rely on anycast for all his different solutions and apps like gmail, search and so on.
If you imagine how DNS works you can see why anycast would be used on root DNS servers. You can then have one copy of the same DNS server on each continent. BGP will by himself bring your DNS query to server near you and in that way save you some delay time and bandwidth usage and thus some time.
In IPv6 world, what changes?
IPv6 had from the development phase the intention to support anycast just like described from RFC 1546. (RFC 1546 mentioned below in history section). IPv6 anycast has no special prefix and IPv6 anycast addresses are basically normal global unicast addresses. Each IPv6 configured interface on some device needs to be configured with one anycast address.
There is a big chance that anycast interfaces have no defined region, in that case every anycast entry would need to be propagated throughout the whole Internet. That would probably not scale well so support for that kind of global anycast addresses will be more or less impossible to handle.
If there are regions defined, inside the region devices with same anycast address will only need a separate entry in the routing table.
All methods to mitigate IPv6 security issues Real life security intro
I the process of configuring our corporate network test segment for IPv6 support there was direct demand to pay particular attention to security. In few weeks it was my mayor role to go trough all materials I could get in order to learn more about IPv6 security. In that process first stop was my favorite packetpushers podcast that had exactly one podcast about IPv6 security that I needed between more than 160 available until now. In that security show from last year Healthy Paranoia Show 4:IPv6 Security Smackdown! Mrs. Y with bunch of great host discussed IPv6 security. They speak about almost all stuff that exist today in securing IPv6 enabled networks. One of the guests was Mr. Eric Vyncke, Cisco Distinguished Consulting Engineer who wrote IPv6 Security book for CiscoPress. Later, I did see that this book was everything you need to learn IPv6 security. Of course, it’s easy to get edge router to run IPv6 on Internet facing interface but my goal is to get IPv6 inside our environment and that part is still tricky if you include all the stuff needed to be done (especially on firewall part of the story).
I search for more info and some examples on how to configure Cisco gear for IPv6. Specially helpful were IPv6 webinars from long followed Networking/Cisco genius Ivan Pepelnjak at his great site ipspace.net (one of my homepage tabs). Here the guest is again Eric Vyncke.
After all the knowledge I pull out of those mentioned resources I was ready to carry out my test segment in our network and make it secure. Here are just a few rows about every one of IPv6 first-hop security features that are available on Cisco equipment. Just for the info, not all the equipment has all the features. Some of them came out few months ago so older switches and routers may not have all of these implemented. Sometimes you will be limited by the licence to. I need to mention that other vendors equipment has also implementation of some features mentioned below. For now it seems that Cisco invested the most effort and gathered the best team of engineers to implement all possible features for IPv6 first-hop security.
Let’s go with the list:
IPv6 RA Guard We know that RA messages are important part of IPv6 architecture as they are the only way to get default gateway info to host in the network (beside static configuration). DHCPv6 does not carry this information in his messages unlike DHCPv4. RA messages are Router Advertisement messages send from main router that is default gateway for that specific network segment. Having that in mind it’s clear that only port on the switch that needs to receive RA messages inbound is the port connecting the router. All other switch ports for hosts are only forwarding RA messages to host devices but there is no need for host to send RA messages back to switch. Even better, it is wrong if some host sends RA messages because he is then practically trying to take the role of default gateway away from router. Configuring RA Guard on all switch ports except port that heads to router we prevented rouge RA advertisements on that segment.
Some of this things I read in books and some of them took me few days of troubleshooting and sweating to get to them so I give them for free here to save you fellow networker some time:
The mighty SLAAC is the prefered method of IPv6 allocation, but is it so mighty? Or it only seems to be mighty and magic? Your computers or mobile phones in order to use SLAAC must be convinced to do so by the router RA message. That message includes the A flag set besides the prefix and all other info. That kind of RA message will tell the device receiving the RA that he needs to make the “A” autoconfiguration on his interface using EUI-64 method.
But that’s not all.
RA messages will need to have also the O flag set. With the O flag end hosts will tell the router that they will use DHCP but only for the “O” other options. In the first place that other option will be DNS server IPv6 address which is not possible to get from router RA messages. Why? I’m sure that’s the most frequent IPv6 question. The fellows who made the RFC 4861 documents didn’t put that option inside RA Router Advertisement Message Format.
I did try to find a reason why not. Maybe the only partially reasonable answer is that DNS is hierarchical system that needs to be centralized inside a network architecture and routers as devices that are running routing processes are distributed system (at least before we see SDN in real life). So the answer will be that is not okay to put allocation of DNS address rule on a system that is not centralized. It means that if you need to change DNS in a network with a lot of routers that are sending RA messages on their local subnets you would need to change the config on all routers one by one. That is the best answer that I did find until now, but this sounds more like excuse that a real reason for this decision. If you put all the info together the answer that fellows from RFC 4861 did actually made the wrong decision is in existence of fairly new RFC 6106 that proposes addition od DNS IPv6 address allocation in RA message.