# Routing protocols and architectures/IPv6 routing

Nowadays routers are mostly ready for IPv6, even though performance in IPv6 is still worse than the one in IPv4 because of lack of experience and lower traffic demand. Often IPv6 routing is turned off by default even if the device supports IPv6 (on Cisco routers this is enabled by command ipv6 unicast-routing).
Two aspects have to be considered:
* routing tables: how to handle the forwarding of data packets?
* routing protocols: how to distribute routes across the network?

## Routing tables

Routing in IPv6 is performed in the same way as IPv4 but it requires two distinct routing tables, one for IPv4 routes and another for IPv6 routes. IPv6 routing tables can store several types of entries, including:
* indirect entries (O/S codes): they specify the addresses, typically link local, of the interfaces of the next-hop routers to which to send packets addressed towards remote links;
* direct entries: they specify the interfaces of the router itself through which to send packets addressed towards local links:
** connected networks (C code): they specify the prefixes of the local links;
** interface addresses (L code): they specify the interface identifiers in the local links.

### Next hop

As the next hop in computed dynamic routes, routing protocols always use link local addresses, even if a global address is configured on the neighbor interface, for the sake of simplicity: link local addresses always exist, while global addresses may not be used in some portions of the network.
However the usage of link local addresses makes difficult the task of determining the location of that address: the network address of a global address at least allows to identify the network in which the host should be present and thus determine the output interface, but a link local address that begins with FE80:: can be everywhere → next to the next hop address, routers also print the output local interface to solve ambiguities, such as:
For static routes, the choice is left to the network manager, who can use the address he prefers as the next hop:
* broadcast interface (e.g. Ethernet): the address of the next hop needs to be specified:
** global address: the local interface does not need to be specified because it can be determined from the network prefix: ipv6 route 2001:1::/64 2001::1
** link local address: the local interface needs to be specified too to identify the scope of the link local address: ipv6 route 2001:1::/64 FastEthernet0/0 fe80::1
* point-to-point interface (e.g. serial): the address of the next hop does not need to be specified because it is uniquely identified by the local interface: ipv6 route 2001:1::/64 serial 0
Since static routes can not adapt to network changes, it is strongly recommended to use global addresses as the next hop for static routes. This avoids that a route becomes invalid if the next hop changes: for example, if the network card on the next hop router is replaced because of a hardware fault:
* link local address: it depends on the MAC address of the card → the route needs to be changed;
* global address: the new interface should just be assigned the same global address.

## Routing protocols

Routing protocols supporting IPv6 can adopt two approaches:
* integrated routing (IS-IS, MP-BGP4): the protocol allows to exchange both IPv4 and IPv6 routing information at the same time:
** efficiency: IPv4 and IPv6 addresses belonging to the same destination can be transported via a single message;
** flexibility: a single protocol transports multiple address families;
** reactivity: if a fault or a network change occurs, the protocol discovers it for both address families;
** bugs: a problem in the protocol affects IPv4 and IPv6 networks in the same way;
** migration: if the protocol uses IPv4 to transport Hello packets, IPv4 can not be abolished in the network;
* ships in the night (RIPng, EIGRP, OSPFv3): the protocol allows to exchange only IPv6 routing information:
** efficiency: given a destination, a message needs to be exchanged for its IPv4 address and another message for its IPv6 address, and the messages are completely independent of each other;
** flexibility: two different protocols can be used, one for IPv4 routing information and another for IPv6 routing information;
** reactivity: if a fault or a network change occurs, both protocols have to discover it, each one with its timings and duplicate messages;
** bugs: a problem in the protocol does not affect routing in the other one;
** migration: each routing protocol generates messages of the address family it belongs to.

### RIPng

RIPng adopts the 'ships in the night' approach, and makes improvements to RIP mainly in Cisco command-line interface:
* support for multiple instances: the tag field allows to specify the protocol instance;
* per-interface configuration: new commands have been introduced:
** ipv6 rip <tag> enable: it replaces the network command and automatically configures RIP on that interface without having to specify an address;
** ipv6 rip <tag> default-information originate: it originates the default route (::/0), that is the rest of the world can be reached via this interface.

### OSPFv3

OSPFv3 adopts the 'ships in the night' approach, and differs from OSPF mainly for three aspects:
* per-interface configuration: the ipv6 ospf <process ID> area <area ID> has been introduced which specifies that all the networks and the addresses configured on this interface will be advertised as belonging to the specified area;
* Router ID: unfortunately OSPFv3 still uses a 32-bit-long Router ID, which it is not even able to automatically set when no IPv4 addresses is available → the ipv6 router-id <number> command becomes compulsory when the router is IPv6-only or is in an IPv6-only network;
* tunnel: a IPv6-on-IPv4 tunnel can be configured to connect together IPv6 islands through an IPv4 network.

### IS-IS

IS-IS for IPv6 adopts the 'integrated routing' approach: in fact it uses its own layer-3 protocol to transport protocol-specific packets, independently of the underlying IP protocol version.

### MP-BGP4

MP-BGP4 can adopt both approaches depending on configuration: TCP packets can be enveloped into IPv4 or IPv6 as needed.
The most common deployment follows the 'integrated routing' approach, because of the need to use the AS number (which is the same for both IPv4 and IPv6) for the BGP process. Integration also reflects to policies: IPv4 addresses and IPv6 addresses can be mixed at will.

## References

* ↑ Support for multiple instances was already present in RIPv2, but was not configurable on Cisco routers.