If you do not know Segment Routing, we suggest that you first read the general presentation.
For IPv6 Segment Routing, a segment is encoded as a 128-bit IPv6 address. A node segment is represented by a node's loopback address, and an adjacency segment is represented by an interface's address.
The Segment Routing header (SRH) is defined as an extension of the IPv6 Routing Header, with routing type 4. It is an evolution of the Routing Header type 0 (RH0), which has been deprecated for security issues. The format of the SRH is the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Segment | Flags | HMAC Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[0] (128 bits IPv6 address) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Segment List[n] (128 bits IPv6 address) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (256 bits) |
| (optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SRH contains a list of segments (represented as IPv6 addresses), in reverse order. The last segment of the segment list is the first segment in the path, the penultimate segment of the segment list is the second segment in the path, and so on. The Segments Left field is the index of the current active segment in the segment list (e.g. if the packet is sent with n segments, then the Segments Left field has a value of n − 1). The First Segment field has a fixed value and represents the first segment in the path. Its value is set as the index of the last segment in the segment list.
The Flags field contains one flag of interest for SR-IPv6: the cleanup flag. When set, the penultimate segment endpoint has to strip the SRH from the packet before forwarding it to the last segment. Thanks to this flag, routers can remove the SRH when the packet is transmitted to another network or to a host that does not support SR-IPv6.
The last field of the SRH is important from a security viewpoint. In an open environment like a university campus network, the network operator cannot assume that all hosts, including students’ laptops, are trusted to only send packets containing a valid SRH. To enable routers to easily distinguish between valid (i.e. chosen by the network operator) and invalid SRHs, each SRH may contain a keyed-HMAC that is computed over a key and the SRH. If the HMAC is valid, the packet contains a trusted SRH and can be forwarded according to the SRH. Otherwise the packet is invalid and should be dropped. This mechanism addresses the security issues that led the IPv6 RH0 extension to be deprecated. Due to space limitations, we choose not to present the inner workings of the HMAC signature.
For further information, we invite you to read the SR-IPv6 IETF draft.
When a segment endpoint receives an SRH-enabled packet, it has to perform the following operations. First, it needs to inspect the SRH to verify its validity, and optionally, verify the HMAC signature if present. Then, the node decrements the Segments Left field and updates the IPv6 destination address of the packet to the next segment. If the cleanup flag is set and the Segments Left field reaches zero after decrement, the node strips the SRH from the packet. Finally, it forwards the packet to the next segment.
The SRH has to be inserted at some point in the network, by the source SR node. In theory, any node could perform this operation, but we mainly distinguish two types of source nodes: (i) a host originating an IPv6 packet and (ii) a SR domain ingress router encapsulating a received IPv6 packet into an outer IPv6 header, followed by the SRH.
When a packet is encapsulated by the SR domain ingress, it goes through a one-way virtual tunnel whose egress is the last segment of the path. When the packet reaches the tunnel egress, the outer header and the SRH are stripped from the packet and the inner packet is processed by the node. This mechanism allows an operator to transport other protocols than IPv6 (e.g. IPv4) as the inner packet.
Note that the SRH may also be inserted into the packet without adding an outer IPv6 header. This mode of operation is not documented in the IETF draft, but our implementation supports it as there is demand from the industry.