Category: IPv6

Solicited-node multicast address

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.

Let’s go!

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.

| Continue Reading.. |

Source-based routing in IPv4 and IPv6 networks

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.

| Continue Reading.. |

IPv6 First-Hop Security

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.

| Continue Reading.. |

IPv6 Implementation beyond theory & How playing with RA messages may be issue-istic

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:

SLAAC

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.

| Continue Reading.. |

IPv6 RA Router Advertisement and all the flags inside

I can say at the beginning that more and more fellows is visiting this blog. Finally networking knowledge project did succeed to get some fans from out there so I felt the need to thank you all for visiting this place. As you can see here from the blog post list I didn’t follow this movement myself these days. I actually didn’t come here for some time now. My last few weeks where very intense. One of the reasons was my learning sessions that took me at least few hour a day and the most interesting reason was my new assignment at work. I got an assignment to carry out and even more interesting to secure IPv6 in our company for a whole network segment. At least one segment for now, but it was a nice thing to get me into IPv6 deep dive learning. And I make the last step of the learning like this:

What is better than document the networking job that you did until is fresh in your head. So I write it down for the future implementations but rather than put it into my notepad I do it here on my blog, so next time is easier to search for it and something even better than that, you can use it to.

RA - router advertisement message format from RFC 4861

RA – router advertisement message format from RFC 4861

This time I will write about some of the most important thing in IPv6 networking that you needed to know before you go on and carry out IPv6 implementation. RA router advertisements  and some strange special bits in the RA packet header that are configuration option flags. Good thing is that there are only few of them, four to be precise. The bad thing is that at first I needed couple of days to stop mixing them up.

| Continue Reading.. |