IPv6: differences between "routed prefix" and "link prefix"?

What are the exact differences between "routed prefix" and "link prefix" for IPv6?
How do these differences in a wireshark-Trace? (if you observe a Host with an assigned "routed prefix" or a Host with an assigned "link prefix").
How do these differences in the Neighbor Discovery Protocol? (from the point of view of an other/external Host)
Do they working together, these two types of prefixes?

The easiest way to understand the difference between the two is via an example showing the hierarchical nature of the prefixes.

An example hierarchy

An ISP has been allocated a prefix from a RIR (Regional Internet Registry) which in this example we will assume is 2001:db8::/32. This prefix is different from the ones handed down to the customers in the sense that the ISP will have to announce it through BGP to other ISPs it's peered with.

The ISP is now going to allocate prefixes to a customer. First they assign 2001:db8:0:1::/64 to the link connecting the ISP router to the CPE (customer-premises equipment) router. This is a link prefix because it is assigned to a link. As a general recommendation all link prefixes in IPv6 should be /64.

The ISP router will send router advertisements announcing this prefix and the CPE will use SLAAC to construct an address for the external interface pointing towards the ISP router within the /64. Let's assume the external interface got the IP address 2001:db8:0:1:42:ff:fe00:42/64 (in this notation /64 is included to remind us what the length of the link prefix is, but I could as well have left it out).

This link prefix is sufficient for the CPE router to communicate with the rest of the world, but it doesn't help the CPE router to support any clients on the LAN connected to its internal interface. The CPE router needs a prefix for the LAN which is routed through this CPE router, hence this is called a routed prefix.

The routed prefix can be configured statically or through DHCPv6. The exact details of how the CPE router negotiate a prefix length with the DHCPv6 server provided by the ISP is outside the scope of this answer. A search for prefix delegation can tell you more about this. Let's assume the routed prefix end up being 2001:db8:1::/48. On the ISP router a routing table entry will be created indicating that 2001:db8:1::/48 need to be routed through the gateway 2001:db8:0:1:42:ff:fe00:42. This routing table entry is the defining feature of routed prefix.

The CPE router might have multiple internal LANs, from the /48 it can allocate a /64 link prefix to each internal LAN. If we assume one of the LANs has been assigned 2001:db8:1:1::/64 as its link prefix a node on this link may get the address 2001:db8:1:1::42:ff:fe00:43 through SLAAC. That node might be a wireless router which happen to need a prefix for its wireless interface. The CPE could assign 2001:db8:1:100::/60 as the routed prefix for the wireless router, and the wireless router could assign 2001:db8:1:100::/64 as the link prefix for the wireless interface.

Now in such a setup what we have is a hierarchy of prefixes. The following are all nested beneath each other:

• 2001:db8::/32 BGP announced prefix
• 2001:db8:1::/48 routed prefix
• 2001:db8:1:100::/60 routed prefix
• 2001:db8:1:100::/64 link prefix

How are packets actually handled

When the ISP router receives a packet for 2001:db8:0:1::/64 which is a link prefix, it performs neighbor discovery to find the MAC address of the host within the /64.

This way the ISP router is going to need a separate neighbor cache entry for every IP address within the link prefix.

When the ISP router receives a packet for 2001:db8:1::/48 which is a routed prefix, it performs neighbor discovery to find the MAC address of the gateway 2001:db8:0:1:42:ff:fe00:42.

This way the ISP router only need a single neighbor cache entry for the gateway in order to route packets to any IP address within the routed prefix. This property is crucial to the scalability of the internet.

Working around lack of routed prefix

Occasionally customers find themselves stuck with an ISP that will only provide a link prefix and no routed prefix. In such a situation it is possible for the customer to install a daemon that responds to neighbor discovery for all IP addresses within a specific subrange of the link prefix. This will have an effect similar to configuring that prefix as a routed prefix. But it has several drawbacks:

• In general routed prefixes are supposed to be shorter than /64, but the daemon responding to neighbor discovery requests can only create a "routed" prefix which is longer than /64.
• It increases the latency slightly due to an extra roundtrip every time an IP address is not in the neighbor cache on the ISP router.
• It increase the load on the ISP router due to needing much more frequent neighbor discovery. It is quite likely that the ISP router can forward packets to an already known destination prefix purely in hardware, but neighbor discovery is going to be done in software.
• It increase memory consumption on the ISP router. If the ISP allocate a routed prefix to each customer, they can easily get away with having only a single neighbor cache entry per customer. But with the neighbor responder daemon this could turn into thousands of entries per customer.

The processing overhead on the ISP router can be a significant issue. Some routers have been so bad at handling a flood of packets needing neighbor discovery that it turned into an actual DoS attacks, and using longer link prefixes (in the /120 - 127 range) has been used as workaround for such DoS attacks.

Even if the router isn't vulnerable to the DoS attack, the memory needed for neighbor cache entries when the workaround described above is used is much more expensive for the ISP than the IP addresses for a routed prefix would be, so there is little reason for an ISP to refuse handing out a routed prefix.

Special cases around point-to-point links

On point to point links (such as 6in4 tunnels and PPP links) there is no need for neighbor discovery. There is only one direction to send a packet on such a link and no hardware address needs to be looked up before sending the packet.

This means the overhead of neighbor discovery isn't an issue on such a link. So having one end of a point to point link use a lot of addresses is not a problem, as long as the endpoints have some agreement on who uses which addresses. Lack of neighbor discovery means there is no duplicate address detection either, so should both endpoints try to use the same address it will not work as expected (unless you are expecting it to behave as an anycast address).

There is one caveat to keep in mind around point to point links. Each endpoint will assume that all addresses on the link it is not assigned itself are assigned to the other end. This means that unused addresses on a point to point link are prone to trigger a routing loop. Such a routing loop (and several other cases of routing loops) can be avoided by an endpoint never sending a packet directly back to the node it was received from. So a packet received from a point to point link must not be sent back over the same point to point link, as long as one endpoint gets this right, the routing loop is broken. As a side node on Ethernet it is valid to receive a packet and forward it back onto the same link, but it is a good idea to avoid doing so if it would be forwarded back to the same MAC address from where it was received.

Since most addresses on a point to point link are just going to be forwarded to the other end of the link without any need for neighbor discovery, it looks very similar to a routed prefix. For example if the ISP assigned 2001:db8:42::/64 to a point to point link with the endpoints being assigned addresses 2001:db8:42::1 and 2001:db8:42::2, then packets to most addresses in 2001:db8:42::/64 will be forwarded from the ISP to the customer just the same way they would if this was a routed prefix using 2001:db8:42::2 as gateway.

This means a certain hack is possible. On the CPE it is possible to actually configure 2001:db8:42::/64 as link prefix on the LAN. In order for the CPE to know which of the two links a certain destination is on, the actual configuration on the point to point link towards the ISP would then have to be changed to 2001:db8:42::/126. This will all work with one minor exception, hosts on the LAN cannot communicate with the four IP addresses in 2001:db8:42::/126. Since they probably didn't need to communicate with those anyway, this is no major problem. However it is not recommended to use this hack, the proper configuration is to get a routed prefix from the ISP.

Another hack to save addresses is to only allocate global addresses for a routed prefix and use RFC 4193 addresses for the point to point link. This is however a silly hack since it still introduces some drawbacks in order to solve a non-existent problem.

It is also possible not to assign any prefix at all to a point to point link. As long as each endpoint has another interface on which it does have a global address, they can use the address assigned to the other interface when communicating on the point to point link. I don't know of any drawbacks from this approach, so if you find that this approach to point to point links simplifies your network configuration feel free to use it, but don't use it as a measure to save addresses.

Use cases for a routed prefix

• Hierarchical routing as in my first example is what the routed prefixes are designed for.
• VPN/tunnels add another layer into the hierarchy of routers needing prefixes. Though they are virtual rather than real hardware, they are no different in terms of addressing and need a routed prefix just like a physical link would.
• Assigning many addresses to a host. There are use cases for assigning a lot of addresses to a single host. For a few addresses they can simply be assigned and handled with neighbor discovery for each and as many cache entries as there are addresses. But if thousands of addresses are needed a routed prefix is better.

A more detailed example of the last point would be DNS recursors. Since I don't see DNSSEC getting a lot of traction until after we are done fighting with IPv4, other measures against DNS poisoning are needed. Effort has been put into getting as much entropy into queries as possible. ID and port number can hold at most 32 bits of entropy, another few bits can be hold in the request if upper and lower case is mixed in the domain name to be resolved. You will rarely get to more than 48 bits total this way. Assigning a full /64 to the DNS recursor would allow the entropy to be increased by 64 bits in one go, which is more than all the other efforts combined.

A link prefix is used between your router and your ISP.

The routed prefix is used inside your network.

If you receive a /64 routed prefix from your ISP, then you would simply have your router advertise that prefix on your LAN. If you got a prefix smaller than /64 (perhaps a /48?) you should consider how to subnet that prefix in a logical way, to be used by all of your routers in your organization.

In Wireshark, depending on where you capture the packets, you might see only the routed prefix being used (if you capture on the LAN) or you might see both prefixes used (if you capture on the WAN).

Regarding Neighbor Discovery Protocol, it also depends on the link. On the link between the ISP and your router, NDP is used to discover the MAC address of your router's WAN interface and your ISP's upstream router's MAC address. On your LAN interface, NDP is used to discover the MAC address of hosts on your LAN segment.

Hope this helps.

A prefix is a routed prefix if packets to that prefix need to go through a router to reach their destination. A prefix is a link prefix if it is on a segment that a local network interface is attached to.

As a packet is traveling across the internet the /64 it is targeted to will be a routed prefix until you reach the last hop. Then it will be a link prefix.

Routed prefixes are usually aggregated. Many /64 can be aggregated into a single shorter prefix to keep routing tables smaller. On the boundary between internet providers it is common to enforce a maximum prefix length of /48.

If a prefix is anything from /0 to /63 you can usually assume it's a routed prefix. If the prefix is /64 you need more information to know if it is a routed or a link prefix.