IPv6 draft: IPv6-in-IPv6 encapsulation

[IurmanJ]

The IPv6-in-IPv6 encapsulation paragraph says the following:

... The destination address of the outer IPv6 header is the same
 as the inner IPv6 destination address ...

I don't think it's correct. Well, it's not something common when dealing with tunnels. Instead, I do believe it should be the IPv6 address of an egress node from the IOAM domain. Of course, both techniques have pros and cons:

Outer IPv6 destination address == Inner IPv6 destination address

Pros

• same routing (theoretically) without pain

Cons

• contradicts RFC 2473 (this is a weird tunnel configuration)
• the egress node is not supposed to decapsulate something for another target
• what if a Destination Option is used? The egress should not "see" it

Outer IPv6 destination address == Egress IPv6 address

Pros

• compliant with RFC 2473
• the egress node can (automatically) decapsulate a packet as it is the destination
• a Destination Option is (automatically) "seen" by the egress

Cons

• what if the configured egress IPv6 address is not the good one anymore (the routing has changed, or whatever)?

---

Section 3.1 from RFC 2473 says:

At encapsulation, the source field of the tunnel IPv6 header is
filled with an IPv6 address of the tunnel entry-point node, and the
destination field with an IPv6 address of the tunnel exit-point.

So the second option has more pros than cons, but its only inconvenient is an annoying one. At the contrary, the first option solves this annoying problem... at the price of a lot of cons. Open question: What would be the best compromise? Option 1, and we don't care about RFCs (yes, I know some operators would not mind)? Or option 2, and we try to find a suitable solution to its potential issue? As a side note, the kernel implementation uses the second option and there is no chance the first one gets accepted.

[IurmanJ]

@brockners Should we talk about this during ippm meeting?

[brockners]

https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-04#section-4.4.2 already covers the scenario of "Outer IPv6 destination address == Egress IPv6 address".

"Outer IPv6 destination address == Inner IPv6 destination address" was indeed intended for those scenarios, where the main objective is to keep the forwarding of the packet similar (and yes - ECMP might still change with the extra header, even if the dest IP stays the same) - at the expense of a set of challenges, which you summarize.

So the question is: How useful is the "Outer IPv6 destination address == Inner IPv6 destination address" in practice, given the pros and cons. We could simply drop section https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-04#section-4.4.1

[IurmanJ]

So the question is: How useful is the "Outer IPv6 destination address == Inner IPv6 destination address" in practice, given the pros and cons. We could simply drop section https://tools.ietf.org/html/draft-ietf-ippm-ioam-ipv6-options-04#section-4.4.1

That's an interesting question. It is actually useful. But, in practice, this more looks like a hack and I guess it shouldn't be used as is if you want to respect standards. People can still go that way if they want to, but it should not be mentioned in the draft (or RFC, hopefully). So I'd be tempted to drop the section, as you proposed.

[IurmanJ]

Solved-by: commit 83d9e27