Subject: [re-ECN] IPv6 hop-by-hop extension headers, tunnels & ConEx

From: Bob Briscoe <[email-masked]>
Date: Mon, 11 Jan 2010 17:32:25 +0000

To anyone out there who knows what tunnels do in practice with v6 
hop-by-hop extension headers?

[OK, I admit this posting is about the details of encoding ConEx in 
IPv6, so we shouldn't get buried in this level of detail while having 
chartering discussions. But I'd like to have a warm feeling that 
there is some hope of doing ConEx properly in v6, and this issue has 
been bugging me...]

Whole path ConEx info introduced by the sender doesn't need to be 
changed by routers, but it does need to be visible at trust 
boundaries (e.g. borders). If a packet gets tunnelled, that means the 
ConEx info ought to be in the outer header. If it were in the inner, 
a border router shouldn't be burying down the layers to find it (and 
anyway it might be encrypted if the tunnel is IPsec ESH).

So I want to pick a way of encoding ConEx info that is likely to 
propagate into the outer header by default at most encapsulators. 
It's not a show-stopper if most tunnels don't (at least initially we 
can arrange for trials with tunnels modified to work), but it's a 
highly undesirable extra barrier to overcome.

* IPv4 in v4: A major reason for proposing bit-48 for ConEx was that 
there's a decent chance existing tunnel encapsulators will copy the 
incoming header to create the outer, so ConEx info would 'naturally' 
propagate into the outer.

* IPv6 in v6: We proposed adding an option to the v6 hop-by-hop 
extension header for ConEx info, in the expectation that a tunnel 
encap can copy it with the main header to create an outer header that 
consists of a new main header and the ConEx hop-by-hop extension header.

RFC2473 (S.5.1) says that a v6 encapsulator can copy incoming 
extension headers to create new outer extension headers after the 
main v6 header. But which ones are copied depends on how the 
encapsulator is configured. I assume it will be configured so that 
certain headers are always copied, e.g.:
* the jumbogram hop-by-hop option, otherwise a tunnelled jumbogram 
won't have a big enough total length field to say how big it is.
* the tunnel encap limit, otherwise it wouldn't be in the outer for 
the next potential tunnel ingress to check.

My question:
Q1. what is a tunnel encap likely to do with a hop-by-hop option that 
it doesn't recognise? Will it copy it to the outer by default? Does 
it depend on the implementation, or should all implementations follow 
a rule? Whatever, I'm told it will probably go via the slow path at first.

Bob

PS. I'm aware that we have no hope of 'legacy' v4inv6 & v6inv4 
tunnels propogating ConEx info by default, if we put ConEx info in 
completely different places in the v4 & v6 headers.

PPS: A subsidiary question:
Q2. what would probably happen at a tunnel encap if we defined a v6 
extension headers for ConEx that was not in the hop-by-hop extension 
header? I assume the chances of existing tunnels copying this to the 
outer would be much lower. (But it does seem that RFC2473 allows a 
tunnel ingress to be configured to copy non-hop-by-hop headers to the 
outer as well.)

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design