14

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?

Erik
  • 151
  • 1
  • 5

3 Answers3

21

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.

poige
  • 9,171
  • 2
  • 24
  • 50
kasperd
  • 29,894
  • 16
  • 72
  • 122
  • I would have linked to a Q/A about CIDR if I could have found a good one. One definitely need to understand CIDR before reading this answer. – kasperd Apr 22 '15 at 08:51
  • For CIDR seems the Wikipedia-Article okay for me, in my opinion a link to http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing is good for further understanding. – Erik Apr 22 '15 at 09:15
  • I have some problems with your answer. They do not cover the observed behavior, not for my ISP at home and not for the hosting provider at my server (both do not use classical neighbor discovery).
    I think i need more detailed description about the main scope of my question. Should i update my question or exist an other preferred way? Sorry, i am new on serverfault.com / StackExchange.     – Erik Apr 22 '15 at 09:22
  • I be confused about the situation you talk. Do you mean a ISP (for example on a DSL-Line) for a Internet connection for private home or do you mean a hosting provider that connects servers (with real Ethernet based LAN)? – Erik Apr 22 '15 at 09:27
  • @Erik Whether it is home, office, or data center, the same principles apply. However some providers don't do things the way they are intended to. For example I have seen hosting providers only provide a link /64 and no routed prefix. – kasperd Apr 22 '15 at 09:51
  • I think i do understand what you describe in your answer, but between an ISP for a DSL-Line (that use PPPoE for encapsulation of all IP-Traffic) and a hosting provider (that use native Ethernet for connecting all costumer servers) is that PPPoE itself has no Link-Layer-Addresses and that means it do **not** need neighbor discovery (Types 135/136 of ICMPv6-Packets). That means on a DSL-Line exist no difference between the prefixes, from the point of view of the CPE (the only real difference is that a /64-Prefix is typical not usable for subnetting but in theory it is also possible). – Erik Apr 22 '15 at 10:13
  • @Erik Point-to-point links do indeed not need neighbor discovery. That does eliminate most of the difference between a routed prefix and a link prefix. That means you can get away with pretending the link prefix is actually a routed prefix and use it as such. Main drawback of using such a link prefix as if it was a routed prefix is that there is a few addresses used for the link itself, which are going to not work when you assume them to be in the routed prefix. – kasperd Apr 22 '15 at 10:55
  • @Erik I should add a section about point-to-point links. I haven't actually had the opportunity to test a DSL line with IPv6. (One ISP promised to deliver me one, then delivered an IPV4-only connection and then claimed they never promised anything about IPv6). I have however been using tunnels, and 6in4 tunnel links are point-to-point links as well, so I would expect them to behave the same way. – kasperd Apr 22 '15 at 10:59
  • '@kasperd: (in the situation of a hosting provider with real Ethernet LAN) If i understand your answer correctly, than i need for a "routed prefix" always an _additional_ "link prefix". Why? Is this a weakness of the IPv6-Implementation inside the border-router / edge-router of the hosting provider or is this caused by the IPv6-Specification? In RFC 4861 i can not find a differentiation between "routed prefix" and "link prefix". – Erik Apr 22 '15 at 11:51
  • @Erik You need a link prefix for every link. That's how IP was designed back in the early 80's, and it hasn't changed. The only thing that has changed is that for a period various hacks have been used to stretch the supply of IPv4 addresses, and this has been going on for so long, that many people forgot how it was supposed to work in the first place, and most internet users haven't even seen an internet connection without those hacks in the first place. – kasperd Apr 22 '15 at 13:28
  • @Erik So when do you need the routed prefixes? The ISP need to provide you with IP addresses even for those links that are internal to your network and not connected directly to the ISP. The only way they can do that is by routing a prefix through your gateway. – kasperd Apr 22 '15 at 13:30
  • @Erik Additionally if a single node need lots of addresses it is not practical to have neighbors knowing about every single one of those addresses. This can be avoided by assigning a prefix to a link with no neighbors at all. That's why it is in some situations convenient to assign a prefix to a virtual link which isn't connected anywhere. – kasperd Apr 22 '15 at 13:33
  • @Erik I have written a bit more about point to point links. There are indeed cases in which the lack of neighbor discovery on point to point links can be an advantage. It does mean you can use lots of addresses without the neighbor discovery overhead. – kasperd Apr 22 '15 at 14:15
  • '@kasperd Your description about PPP-Links is in my opinion not completely correct. Should we talk about this in a chat? – Erik Apr 22 '15 at 15:28
  • '@kasperd In the case of a hosting provider with a lot of internal (virtual) Servers connected by Ethernet with the provider router, your answer implies that the provider router need two neighbor cache entries: one for the "routed prefix" [2001:db8:1:2::/64 -> 2001:db8:0:1::1] (this entry is completely static / manual) and one for the link-address [2001:db8:0:1::1 -> MAC-Address] (this entry is completely dynamical). In my opinion the provider router needs only one neighbor cache entry [2001:db8:1:2::/64 -> MAC-Address] (only the first half is static and the second half is dynamic). Right? – Erik Apr 22 '15 at 15:36
  • '@kasperd Why can the provider router not use a static neighbor cache entry for the "routed prefix" in this form [2001:db8:1:2::/64 -> 2001:db8:1:2::1] ? I mean, why not pointing from a prefix to a single individual address _inside_ this prefix? If the addressed server can respond to all addresses of the entire prefix with correct neighbor advertisements than the provider router should be able to create the second (dynamic) neighbor cache entry correctly. An additional alternative is to use a single individual Link-Local Address as destination for the prefix: [2001:db8:1:2::/64 -> FE80::XY]. – Erik Apr 22 '15 at 16:00
  • @Erik Routing table maps from destination IP address to (interface,gateway IP)-tuples (with the gateway feel being blank on directly attached segments). Neighbor cache maps from (interface,IP)-tuples to MAC address (as long as the network is Ethernet). The routing table can be static, at least it is static enough that it is rarely changed in response to simply routing a packet. The neighbor cache is dynamic in nature. Forwarding a packet involves consulting first the routing table and next the neighbor cache including a lookup of the later if the MAC address is not in the cache. – kasperd Apr 22 '15 at 16:50
  • @Erik Once the packet has been forwarded I would expect a backbone router to combine the two entries it just used into a mapping directly from (destination prefix) to (outgoing interface, destination MAC). This entry would then be written to a CAM table such that later packets can be forwarded in hardware and thus not consult either table. I would expect the CAM table entries to have usage counters that can be consulted in order to know which neighbor cache entries need to be refreshed before they expire. The last two comments are the same for IPv4 except that ND has taken the place of ARP. – kasperd Apr 22 '15 at 16:54
  • @Erik As for your "static neighbor cache" idea, what you describe is using an address inside a prefix as gateway for the route towards that prefix. That's not going to work because it would create a cyclic dependency. However using a link-local IP address as gateway for a route is valid, as long as the outgoing interface is specified explicitly. When the gateway is not link local, the outgoing interface can be inferred from the gateway IP. And yes, that way you can forward packets onto an interface which doesn't have a link prefix. – kasperd Apr 22 '15 at 17:00
  • Thank you very much for this detailed post. If my server is assigned a routed prefix, I guess all packets within that prefix should appear within a tcpdump packet capture. I currently have a /48 assigned to my server and tcpdump shows ICMP6 neighbor solicitation requests when receiving packets to addresses that are unconfigured. So I assume it is a link prefix. Is that assumption correct? – 1' OR 1 -- Mar 18 '17 at 17:57
  • 1
    @1'OR1-- If a packet to any unused address inside of the `/48` results in a neighbor solicitation packet for the destination IP, then it does indeed sound like the provider configured the `/48` as a link prefix. Configuring a `/48` as a link prefix is not a recommended configuration, but I have heard of providers doing it anyway. If it was a routed prefix then regardless of which IP address inside the `/48` a packet was targeted to, the neighbor solicitation you would see would be for the same IP address each time. And once you responded to that, you wouldn't see anymore neighbor solicitation. – kasperd Mar 18 '17 at 21:52
3

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.

Scott Nelson
  • 285
  • 1
  • 10
  • 1
    The sentence `If you received a /64 from your ISP, then you would simply have your router advertise that prefix on your LAN` would probably be less likely to be misunderstood if you made it explicit that `/64` is referring to the routed prefix. – kasperd Jan 26 '16 at 14:47
2

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.

rfc2460
  • 321
  • 1
  • 4