Static Routing

Routing refers to how packets get delivered to the correct destination node, out of the billions of possible nodes connected to the Internet. There are several levels (scopes) involved in this process, depending on how far the destination node is separated from the source node.

 

Packet Delivery to an On-Link Node in IPv4

If the destination node is On-Link (it is in the same physical link as the source node), routing is quite simple. On an Ethernet based link, you just write the packet to the link with the MAC address of the desired recipient as Destination Address. All nodes on the link see the packet. The node that owns the destination MAC address accepts the packet, while all the others ignore it. This filtering based on destination MAC address is usually done at the hardware level within the NIC, so the TCP/IP stack is not even aware that packets addressed to some other node were received. You can override this hardware filtering by putting the NIC in "promiscuous mode". If you are analyzing network traffic in your subnet with Wireshark, it automatically puts the NIC you are monitoring in this mode. Otherwise you would only see packets addressed to your node.

Any IPv4 broadcast address (255.255.255.255, or any address with the Interface Identifier containing all ones, e.g. 172.20.255.255 in 172.20/16) is mapped onto the MAC broadcast address, which is ff-ff-ff-ff-ff-ff. Any packets sent with this destination address will be accepted by all nodes on the link. Then each node has to decide whether the packet applies to them or not. For example, requests to a DHCPv4 server are sent to the broadcast address, and such packets apply only to nodes with a DHCPv4 server running. There is no IPv6 broadcast address.

Ethernet multicast works in a similar manner to Ethernet broadcast, but uses a different destination MAC address, which is based on the IP multicast address used.

In IPv4, the MAC multicast address consists of the 24 bits 0x01005E, followed the low 23 bits of the IPv4 multicast address right justified in the remaining 24 bits. So the IPv4 multicast address 224.1.2.100 would use the MAC address 01-00-5E-01-02-64. When a multicast packet arrives, the node compares the low 23 bits of the destination address against the low 23 bits of all multicast groups it has joined. If there is a match, the node accepts the packet.

 

Packet Delivery to an On-Link Node in IPv6

So how does this work in IPv6? Pretty much the same way, except that now every node has not only a Link-Local unicast address, it may also have one or more Global unicast addresses. If the destination node is on-link, you can use either the destination node's Link-Local unicast address, or its Global unicast address as the destination address. If the destination node is off-link, the destination address must be a Global unicast address (or possibly ULA). This is because nodes Link-Local addresses work only in the local link (hence the name). They are only unique in their own local link, and routers will not forward them into other links. What about the source address? If the destination node is on-link, you can use your own Link-Local address, or any of your Global unicast addresses as source address. If the destination is off-link, you cannot use your Link-Local address as source, because the off-link recipient would not be able to reply to you using your Link-Local address as destination address (it isn't usable in other links). If you send a packet off-link with a Link-Local source address, the router will reject it and send you an ICMPv6 message saying "destination exceeded source address range".

But taking this into account, delivery works pretty much the same was as in IPv4.

If the destination node is On-Link (it is in the same physical link as the source node), routing is quite simple. On an Ethernet based link, you just write the packet to the link with the MAC address of the desired recipient as Destination Address, and all nodes on the link see the packet. The node that has the destination MAC address of the packet accepts the packet, while all the others ignore it. This filtering based on destination MAC address is usually done at the hardware level within the NIC, so the TCP/IP stack is not even aware that packets addressed to some other node were received. You can override this hardware filtering by putting the NIC in "promiscuous mode". If you are analyzing network traffic in your subnet with Wireshark, it automatically puts the NIC you are monitoring in this mode. Otherwise you would only see packets addressed to your node.

There is no IPv6 broadcast address, so there is no Ethernet IPv6 broadcast address.

Ethernet multicast works in a similar manner to Ethernet broadcast, but uses a different destination MAC address, which is based on the IPv6 multicast address used.

In IPv6, the MAC multicast address consists of the 16 bits 0x3333 followed by the low 32 bits of the IPv6 multicast address. So the IPv6 multicast address ff02::1:2 would use MAC address 33-33-00-00-01-02. When a multicast packet arrives, the node compares the low 32 bits of the destination address against the low 32 bits of all multicast groups it has joined. If there is a match, the node accepts the packet.

 

Packet Delivery to Off-Link Nodes

If the destination node is Off-Link (it is not in the same physical link as the source node), by default, the packet is sent using normal on-link delivery, but to the default gateway address, not the destination address. The IP packet still contains the destination IP address of the actual recipient, but when the Ethernet frame is created, the destination MAC address is that of the default gateway, not that of the actual recipient. Every node has to know the IP address of its default gateway in order to successfully send packets to Off-Link nodes. In IPv4 the default gateway address is either manually configured or obtained from DHCPv4. In IPv6, the default gateway is either manually configured, or is obtained by Router Discovery (one of the mechanisms of the Neighbor Discovery protocol). It is not currently possible to obtain the default gateway from DHCPv6, which means you cannot do IPv6 network configuration with just DHCPv6.

 

Packet Delivery to Off-Link Nodes using Static Routes in IPv4

In simple subnets, the default routing rules will usually get the packet to the right place. But, what if you have two nested subnets, as in the following picture, for IPv4. There are three links shown - LAN A (10.1/16, where Alice lives), LAN B (10.2/16, where Bob lives) and the PPP link to the ISP (123.45.67/30, which has only two addresses in it - 123.45.67.2, the outside NIC of R2, and 123.45.67.1, the inside NIC of the router at the ISP). Router R1 connects LAN A and LAN B (this would be called an internal router). Router R2 connects LAN B to the ISP (this would be called a border router, or border gateway).

ipv4 nested subnets

If either Alice or Bob tries to send a packet to an on-link node (one in LAN A for Alice, or one in LAN B for Bob), normal Ethernet delivery would suffice.

What happens if Alice (at 10.1.0.20) tries to send a packet to any off-link node (e.g. Bob, at 10.2.0.30, or perhaps 4.2.2.2, which is on the other side of the ISP)? Alice realizes the destination address is off-link (has a different address prefix), so she delivers it via Ethernet to her default gateway, which happens to be 10.1.0.1 (the NIC of R1 attached to LAN A). As far as Alice is concerned, she has done everything she can do. She doesn't actually know where the off-link node is located - it could be in the adjoining link, or halfway around the world. Router R1 is entrusted to route Alice's packet to the correct destination (or at least get it started in the right direction).

If the destination is Bob (10.2.0.30), then router R1 realizes that its external NIC is connected to subnet 10.2/16, so it forwards the packet from its internal NIC to its external NIC, and that NIC delivers the packet to Bob. So far so good.

If the destination is 4.2.2.2 (halfway around the world), then R1 realizes that address isn't on any subnet it is connected directly to, so it uses the same default rule and delivers the packet to its default gateway address (yes, routers have default gateway addresses too). That would be 10.2.0.1, which is the inside NIC of router R2. As far as router R1 is concerned, it has done its job. It is now router R2's job to get it headed towards node 4.2.2.2. Again, router R2 realizes that address is not on any subnet it is connected directly to, so it delivers the packet to its default gateway address, which is 123.45.67.1, at the ISP. Hopefully the router at the ISP can figure it out from there.

If Bob (at 10.2.0.30) is sending a packet to an external address (e.g. 4.2.2.2) it works pretty much the same way. He delivers it to his default gateway (10.2.0.1), which takes it from there. But what if Bob sends a packet to Alice at 10.1.0.20? Bob realizes Alice is off-link, so by default he delivers the packet to his default gateway (10.2.0.1) which delivers it to its default gateway (123.45.67.1). Bob's packet is getting further and further away from Alice! At some point, the routers are going to realize that they have no idea of how to deliver a packet to a 10.1.0.20, and drop it (and then send Bob an "unable to deliver" ICMPv4 message).

The answer is to add some new information to the nodes in this network concerning the fact that Alice (and in fact, the entire LAN A) is "downstream" from Bob. This new information can take the form of a static route. You can add a static route onto any node (host or router).

The simple solution to let Bob send packets to Alice is to add a static route on Bob that says "you can deliver packets to Alice who is at 10.1.0.20, by sending them to 10.2.0.2". In Windows, you would add this route with the following command:

route -p add 10.1.0.20 mask 255.255.255.255 10.2.0.2

If you add this on Bob, he can now send packets to Alice. Alice could already send packets to Bob, so now we're good to go. At least for Alice and Bob.

But, what if there are other nodes in LAN A, such as Alex (10.1.0.21), Andy (10.1.0.22), etc? Bob can now communicate with Alice, but packets sent to Alex or Andy get lost, just like ones sent to Alice did. We could add static routes for each node on LAN A onto Bob, but that could get to be a pain. The better solution is to tell Bob "you can deliver packets to any node in 10.1/16, by sending them to 10.2.0.2". In Windows, you would add this route with the following command:

route -p add 10.1.0.0 mask 255.255.0.0 10.2.0.2

Now Bob can communicate with any node in LAN A. We're making progress. But now what about nodes Babs and Bonnie in LAN B? They have the same problem that Bob used to have. They can't deliver packets to anyone in LAN A. We could add the same static route on every node in LAN B, but this gets to be a pain also.

The answer is to add the above static route, but not on any host in LAN B, but on router R2. It needs to go there, because that is where nodes in LAN B send packets that are not on-link. Now any node in LAN B (Bob, Babs, Bonnie, etc) can send packets to any node in LAN A (Alice, Alex, Andy, etc). None of the hosts in LAN B know anything about LAN A - they just deliver off-link packets (e.g. to Alice) as usual to their default gateway (R2). R2 knows the secret - it says "wait - these packets are supposed to go to nodes in subnet 10.1/16, so instead of sending them to my default gateway, I will send them to 10.2.0.2, which is in my link".  Even though the packets now have to take a little side trip up to R2, now adding a single static route lets any node in LAN B send packets to any node in LAN A. We just had to put the static route in the right place, which was router R2.

 

Packet Delivery to Off-Link Nodes using Static Routes in IPv6

Here is the same network, but with IPv6 addresess instead of IPv4. I have simplified the Link-Local addresses to try to keep down clutter - normally the Interface Identifiers of Link-Local addresses will be either random or EUI-64 - both very messy in diagrams like this.

nested lans v6

Again, there are three links shown - LAN A (2001:db8:9:2::/64, where Alice lives), LAN B (2001:db8:9:2::/64, where Bob lives) and the PPP link to the ISP (2001:db8:9:3::, which has only two addresses in it - 2001:db8:9:3::2, the outside NIC of R2, and 2001:db8:9:3::1, the inside NIC of the router at the ISP). Router R1 connects LAN A and LAN B (this would be called an internal router). Router R2 connects LAN B to the ISP (this would be called a border router, or border gateway).

If either Alice or Bob tries to send a packet to an on-link node (one in LAN A for Alice, or one in LAN B for Bob), normal Ethernet delivery would suffice.

What happens if Alice tries to send a packet to any off-link node (e.g. Bob at 2001:db8:9:2::30, or perhaps to 2001:470:20::2, which is on the other side of the ISP)? Alice realizes the destination address is off-link (has a different address prefix from hers), so she delivers the packet via Ethernet to her default gateway, which happens to be fe80::2:2:2:2 (the NIC of R1 attached to LAN A). As far as Alice is concerned, she has done everything she can do. She doesn't actually know where the off-link node is located - it could be in the adjoining link, or halfway around the world. Router R1 is entrusted to route Alice's packet to the correct destination.

If the destination is Bob (2001:db8:9:2::30), then router R1 realizes that its external NIC is connected to subnet 2001:db8:9:2::/64, so it forwards the packet from its internal NIC to its external NIC, and that NIC delivers the packet to Bob. So far so good.

If the destination is 2001:470:20::2 (halfway around the world), then R1 realizes that address isn't on any subnet it is connected directly to, so it uses the same default rule and delivers the packet to its default gateway address (yes, routers have default gateway addresses too). That would be fe80::2:2:2:1, which is the inside NIC of router R2. As far as router R1 is concerned, it has done its job. It is now router R2's job to get it headed towards node 2001:470:20::2. Again, router R2 realizes that address is not on any subnet it is connected directly to, so it delivers the packet to its default gateway address, which is fe80::3:3:3:1, at the ISP. Hopefully the router at the ISP can figure it out from there.

If Bob is sending a packet to an external address (e.g. 2001:470:20::2) it works pretty much the same way. He delivers it to his default gateway (fe80::2:2:2:1), which takes it from there. But what if Bob sends a packet to Alice at 2001:db8:9:1::20? Bob realizes Alice is off-link, so by default he delivers the packet to his default gateway (fe80::2:2:2:1) which delivers the packet to its default gateway (fe80::3:3:3:1). Bob's packet is getting further and further away from Alice! At some point, the routers are going to realize that they have no idea of how to deliver a packet to link 2001:db8:9:1/64, and drop it (and send Bob an "unable to deliver" ICMPv6 message).

The answer is to add some new information to the nodes in this network concerning the fact that Alice is "downstream" from Bob. This new information can take the form of a static route. You can add a static route onto any node (host or router).

The simple solution to let Bob send packets to Alice is to add a static route on Bob that says "you can deliver packets to Alice who is at 2001:db8:9:1::20, by sending them to fe80::1:1:1:1". In Windows, you would add this route with the following command:

netsh int ipv6 add route 2001:db8:9:1::20/128 "Local Area Connection" fe80::2:2:2:2

If you add this on Bob, he can now send packets to Alice. Alice could already send packets to Bob, so now we're good to go. At least for Alice and Bob.

But, what if there are other nodes in LAN A, such as Alex (2001:db8:9:1::21), Andy (2001:db8:9:1::22), etc? Bob can now communicate with Alice, but packets sent to Alex or Andy get lost, just like ones to Alice used to. We could add static routes for each node on LAN A onto Bob, but that could get to be a pain. The better solution is to tell Bob "you can deliver packets to any node in 2001:db8:9:1::/64, by sending them to fe80::2:2:2:2". In Windows, you would add this route with the following command:

netsh int ipv6 add route 2001:db8:9:1::/64 "Local Area Connection" fe80::2:2:2:2

Now Bob can communicate with any node in LAN A. We're making progress. But now what about nodes Babs and Bonnie in LAN B? They has the same problem that Bob used to have. They can't deliver packets to anyone in LAN A. We could add the same static route on every node in LAN B, but this gets to be a pain also.

The answer is to add the above static route, but not on any host in LAN B, but on router R2. It needs to go there, because that is where nodes in LAN B send packets that are not on-link. Now any node in LAN B (Bob, Babs, Bonnie, etc) can send packets to any node in LAN A (Alice, Alex, Andy, etc). Node of the hosts in LAN B know anything about LAN A - they just deliver off-link packets (e.g. to Alice) as usual to their default gateway (R2). R2 knows the secret - it says "wait - these packets are supposed to go to nodes in subnet 2001:db8:9:1::/64, so instead of sending them to my default gateway, I will send them to fe80::2:2:2:2, which is in my link".  Even though the packets now have to take a little side trip up to R2, now adding a single static route lets any node in LAN B send packets to any node in LAN A. We just had to put the static route in the right place, which was router R2.

Could we have used the global unicast address of the outside NIC of R1 as the target of the static route? Technically it would appear to work, but then the redirect mechanism will fail. The target of IPv6 static routes should always be a Link-Local unicast address. Note: you may have to indicate the correct interface when specifying a Link-Local target address (like using the zone ID in a ping command).