Archive for April, 2012
When we did our IPv6 sprint earlier this year, one of the biggest surprises (and sources of confusion) was how we needed to deal with multiple IPv6 addresses per network interface. The confusion wasn’t about having multiple addresses, it was predicting which address would be used as the source address when sending packets. Almost everyone was already familiar with “VIFs” (Virtual Interfaces) or equivalent from Solaris, Linux or other operating systems. But VIFs don’t have the problem of needing to select a source address.
The interesting issue is that the source address you must select depends on the network path between you and your destination. The same source computer shows up as different IPv6 addresses on different destination systems.
Since source addresses are the basis for many security mechanisms, such as rules on network firewalls and destination host iptables configurations, you need to know which address a source host will use in several different cases. This makes managing source-host-specific firewall and iptables rules….. complicated.
Fortunately, the need to be able to predict (or configure) the source address was recognized early on in IPv6 development and rules for selecting IPv6 source address were documented in RFC 3484 (2003). However, like many RFCs, it is a great specification, but is light on readability and explanations. The RFC also has no specification for the implementation details, such as the user interface for the “User Configuration Table” which allows the system administrator to change the default behavior.
Fortunately, at least for Linux, one of the developers for “glibc” (which implements the network stack interface), has written about these issues for Linux, and there are some good articles about the specifics of the Linux RFC 3484 implementation. That’s the good news. The bad news is that it is still complicated.
Source address selection is controlled by the User Configuration Table, which I’ll show in a later post. After that, I’ll cover how this adds even more weight to the argument that host-IP-based access restrictions need to be revisited (or just not used) in IPv6-capable networks.