IPv6 behaves differently from IPv4 on local networks.
ICMPv6 mechanism breaks the connection between assigning an address assignment, and using a prefix for routing/forwarding decisions.
This article sheds some light on this new approach.
(a guide to rfc 5942)
IPv6 Local Networks
In the IPv4 world, configuring an ipv4 address on an interface means also that the matching (sub)network prefix is directly connected through this interface. The process of assigning an address, and configuring a local network prefix is the same process.
For IPv6 this is a little problematic.
Suppose an ISP (Internet Service Provider) is connected to a subscribers,and the subscribers’ CPE (customer premise equipment) is configured in a bridged mode (refer to the top image).
This means that the ISP can use a single prefix to assign addresses to more than a single subscriber. But then subscribers will use address resolution (ARP) to connect with each other. Since address resolution (for IPv4) uses L2 broadcasts, this will fail for cases where the ISP uses L2 networks that do not support broadcast (like ADSL). The ISP will use an aggregating router, and assign /32 addresses to the subscribers (using PPP or DHCP) to solve the problem.
IPv6 uses SLAAC (StateLess Address Auto Configuration) that count on /64 prefixes.
SLAAC uses /64 prefixes to create globally unique locally generated addresses, using either:
– modified EUI-64 identifiers or
– some other format (see rfc 4941)
So the router should send RA (Router Advertisements) with /64 prefixes, but these prefixes cannot be used to decide if a destination IPv6 address is on-link (the subscribers are still physically connected to the router alone).
In this scenario, all IPv6 packets should be sent to the router. If a host will try use ND Neighbor Solicitation (equivalent to ARP) to find a neighbor that shares the same /64 prefix, no replay will come.
IPv6 prefixes only for addressing
ICMPv6 RA carry a flag bit designed to solve this problem.
RFC 4861 says:
L 1-bit on-link flag. When set, indicates that this
prefix can be used for on-link determination. When
not set the advertisement makes no statement about
on-link or off-link properties of the prefix. In
other words, if the L flag is not set a host MUST
NOT conclude that an address derived from the
prefix is off-link. That is, it MUST NOT update a
previous indication that the address is on-link.
OK, they could say it more clearly..
The main idea is this:
If you receive RA-prefix with the L bit cleared, use it to create an address, but don’t use it for routing/forwarding decisions.
Prefix with no address
Ok, we’ve seen a prefix that is used to create an address, but not used “as a prefix”|
(i.e: address without a prefix).
What about the other way around ? (prefix with no address)
I I configure my host with a static IPv6 address (so no SLAAC), I can still receive prefixes and use them.
These prefixes will find their way into the routing table, and will be used as “local networks”.
If my host will try to send a packet to an address that belongs to such a prefix, the host will issue a Neighbor Solicitation message, and if successful, will send the packet directly to the other host.
That is – my host consider some prefixes to be local even though it has no address that belongs to these prefixes.
So next time, if you see a packet that has a source and destination that belong to separate prefixes, that packet can still be ‘local’ !!
Consider a network I use for experiments:
You cannot see it in the network diagram, but router R2 advertises the prefix 2001:0:0:16::/64 .
(Notice that the router itself does not have an address that belong to this prefix).
The leftmost host (“Lubuntu-1”), is configure not to use SLAAC, and has just a single IPv6 address. But if you look at its routing table you’ll see the prefix right there:
And when Lubuntu-1 pings a 2001:0:0:16::/64 address (given to local-host using SLAAC), the result is a direct forwarding: