Subject: Insertion of IPv6 Segment Routing Headers in a Controlled Domain

From: Mark Smith <[email-masked]>
Date: Thu, 30 Mar 2017 06:58:07 +1100

So having further about this, I have fundamental question that it
isn't answering.

Why can't IPv6-in-IPv6 encapsulation be used for this? What is missing
from IPv6 that "requires" that EH insertion is used instead of much
simpler, off-the-shelf encapsulation/decapsulation?

For example, using IPv6-in-IPv6 encapsulation, I don't think an SRH is
needed at all in the "2. Source Domain and Packet Journey" example.

When node 2 realises that the link between itself and 3 has failed, it
encapsulates the original SA=1, DA=9 packet in a new IPv6 header
("tunnelling" it). The new IPv6 header has an SA=2, DA=5, and is sent
towards node 4.

Node 4 forwards the packet onto node 5 using conventional destination
address based IPv6 forwarding.

Node 5 receives the packet, and as it is DA=5, decapsulates the inner
SA=1, DA=9 packet. Node 5 then submits that packet to the standard
IPv6 forwarding table, resulting in it being forwarded to Node 3,
which then forwards it to Node 9. All of this is happening using
conventional IPv6 destination based forwarding.

Encapsulation is solving this problem by effectively creating a
on-demand virtual link or tunnel between Node 2 and Node 5, getting
the original packet past the failure point to a point along the
original packet's forwarding path. Once there, it pops out of the
virtual link and is sent along its way. I don't think the insertion of
the EH and DA swapping method could be described the same way or could
be described as simply.

I think this IP-in-IPv6 encapsulation solution to the above example is
better because:

- there is no need for an additional header of any type - the path
information is inherent in the DA of the outer IPv6 header when sent
to node 5, and in the DA of the inner IPv6 packet (now "the packet")
when being sent by node 5 to node 9.

- Encapsulation/Decapsulation performed by nodes 2 and nodes 5 is
conventional IPv6-in-IPv6 encapsulation, specified in RFC2473, now
nearly 20 years old.

- In this example, nodes 4, 5 and 3 could be off-the-shelf IPv6
devices that support conventional IPv6 forwarding and conventional
IPv6-in-IPv6 encapsulation/decapsulation (i.e., "tunnelling").

- Encapsulation/decapsulation is a simpler, universal and proven
operation (literally being done every time an IPv6 packet is being
sent and received over any and all layer 2 links)  compared to the DA
address swapping that occurs at Nodes 2 and Nodes 5 in the described
method.

More complicated examples would may require more information to be
carried about the path between the inner and outer IPv6 headers
(although encapsulation inside encapsulation/tunnelling inside
tunnelling probably be used at a greater packet overhead host, with
simpler per-hop processing), however I don't think this example
demonstrates why EH insertion is required.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Thu, 30 Mar 2017 07:08:03 +1100

> when being sent by node 5 to node 9.

To clarify, what I mean by "no need for an additional header of any
type" is no additional header beyond the IPv6 encapsulation header
i.e. no SRH EH or similar between the outer and inner IPv6 packets. It
is the original IPv6 packet inside a vanilla IPv6 packet with the
outer IPv6 packet's next header field set to 41.

---

From: Dirk Steinberg <[email-masked]>
Date: Thu, 30 Mar 2017 16:34:19 +0200

> Am 29.03.2017 um 22:08 schrieb Mark Smith <[email-masked]>:
> 
> outer IPv6 packet’s next header field set to 41.

Following this logic of not using „an additional header of any type“ leads to
the conclusion that for every entry in an SR policy represented by the 
SID list of an SRH, you would instead use one more nested IPv6 
encapsulation header. 

In the simple example of section 2 the TI-LFA policy only needs to specify 
one additional node, namely 5 (9 being the original destination), but 
conceivably the backup policy could be more complex including 3, 4, 5,
or more SIDs. Would you really want to propose that the PLR should
impose, say 4 nested IPv6 encapsulation headers at the same time
while still claiming this to be simpler and/or more efficient?

Let’s face the reality: the cost of adding an IPv6 encapsulation header 
is fairly high and while doing this once may be acceptable in certain situations
doing this N times nested is prohibitive both in terms of the burden on the
forwarding hardware and in terms of MTU growth. One more entry in
the SID list is just so much more efficient.

This is why in general the recurring argument to just use IPv6 encaps
whenever all you really need is one more entry in the SRH SID list
is completely missing the point.

/Dirk

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------