How To Do SR In An RFC 8200 Compliant Way
Introduction
Currently there is a debate going on in the IETF 6man and SPRING working groups, about whether to allow insertion of Extension Headers (EHs) within existing packets when performing Segment Routing (SR).The following article is the contents of a private email that I sent in this discussion which describes a model of how to do SR in IPv6 that is compliant with the Internet Standard RFC for IPv6, RFC 8200.
Note that all of the text is mine, including the '>' quotation from RFC 8200.
How to do SR in an RFC 8200 compliant way
"On Sun, 15 Sep 2019 at 09:45, Mark Smith <markzzzsmith@gmail.com> wrote:>
<snip>
> After that, from RFC 8200,
>
> "Extension headers (except for the Hop-by-Hop Options header) are not
> processed, inserted, or deleted by any node along a packet's delivery
> path, until the packet reaches the node (or each of the set of nodes,
> in the case of multicast) identified in the Destination Address field
> of the IPv6 header."
>
>
So, to make it clear, the way to do SR in an RFC 8200 complaint way is
to have a path across an SR domain constructed of a (likely
contiguous) sequence of X-in-IPv6 tunnels.
At each of the tunnel origins is the opportunity to "insert" or add
new supplemental information via an newly created, or copied and
modified EH.
At each of the tunnel end-points is the opportunity to process the
received EHs. They could be used to create or copy and modify the EHs
that are used for the next segment in the path.
In other words, "segments" are 1:1 with X-in-IPv6 tunnels. In an IPv6
network, "Tunnel Routing" would be a synonym for Segment Routing.
If "mid-segment", supplemental information needs to be added or
removed, then that means the existing segment/tunnel has ended, and a
new segment/tunnel needs to start.
Another way to validate RFC 8200 compliance is to imagine that the
segment/tunnel head end applied encryption to the payload (i.e.
payload packet) via IPsec. Could a device mid-way along the segment
add or remove information? No it couldn't, it wouldn't even be able to
recognise that the packet is a segment/tunnel packet, because that
information is hidden by the encryption.
If, in the presence of encryption, a segment/tunnel "midpoint" needs
to add or remove information, then that is solved by making the
"midpoint" a segment/tunnel end-point. The end-point would have the
decryption key, would know the packet is to be processed locally
because the end-point node has the same DA as in the packet, and would
know which decryption key to use because of the packet's Source
Address.
Yes, there is an overhead issue with X-in-IPv6 tunnelling, which is
fundamentally caused by IPv6 addresses being so large. They're large
because they need to be able to uniquely identify all IPv6 nodes in
literally all contexts i.e. the global Internet, and perhaps down the
track the entire Universe.
I doubt this literal global uniqueness of IPv6 addresses and therefore
literal globally unique SIDs is necessary in a limited domain model
and mechanism such as SR, which is why SR over MPLS or native SR over
IPv4 would be ways to avoid this X-over-IPv6 overhead.
However, as IPv6 is likely the future commodity (cheapest) protocol,
the overhead is the cost of gaining from IPv6 commodification. Nothing
is free, everything is a trade off.
There are ways to reduce this X-in-IPv6 overhead that both don't
compromise and would fit RFC 8200:
"Skinny IPv6 in IPv6 Tunnelling"
https://tools.ietf.org/html/draft-smith-skinny-ipv6-in-ipv6-tunnelling-00
"The RObust Header Compression (ROHC) Framework"
https://tools.ietf.org/html/rfc5795
(I don't know much about ROHC, however I think could be applied to the
inner X payload packet before the compressed packet is then
encapsulated in the new outer X-in-IPv6 tunnel header. Performance and
state would likely be an issue at high Gbps, which is why I wrote
"Skinny IPv6 in IPv6 Tunnelling".)
There may be other suitable compression methods.
Regards,
Mark."
