Ethernet-over-IPv6 tunnel app

[lukego]

Support point-to-point tunnels based on the simple Keyed IPv6 Tunnels internet draft.

[altexy]

From lukego:

This is a minimalistic implementation of the same function that Alex Gall has been working on. (I met with Alex yesterday, I don't think he plans to optimize his app to the level that I need, so I'd like to make a separate one.)

The App would have an input/output called "encapsulated" and an input/output called "decapsulated".

The "decapsulated" link receives raw Ethernet packets. Each of these packets is prepended with a simple IPv6/L2TPv3 header and transmitted on the "encapsulated" link.

The "encapsulated" link does the reverse: it receives IPv6/L2TPv3 packets, strips off that header, and transmits the remaining raw Ethernet onto the "decapsulated" link.

from http://tools.ietf.org/html/draft-mkonstan-keyed-ipv6-tunnel-01:

RFC4719 [RFC4719] describes encapsulation of Ethernet over L2TPv3. Paraphrasing from this document, the Ethernet frame, without the preamble or frame check sequence (FCS), is encapsulated in L2TPv3 and is sent as a single packet by the ingress router.

Should I remove any "preamble" during encapsulation? The same for other direction, should I prepand such preamble? How can I test this SnS app to be sure i'm doing right things? Please provide me with any hint.

I see next configuration parameters: local IPv6 address remote IPv6 address Cookie Session ID, optional

It should be possible to use zero-copy approach in both direction.

Should I check before decapsulation that packet contains valid fields: Version, Next header, Source and Destination addresses?

Regards Alexander Altshuler

[lukego]

Howdy!

Yep: to decapsulate you can remove the preamble, probably by hacking iovec.offset. To encapsulate you can add the preamble, probably by inserting a new iovec at index 0.

I'll see what more information I can get about integration testing possibilities, but that might have to come a little later. I'd say that a good testing roadmap is something like:

1. Testing using Wireshark and PcapReader/PcapWriter i.e. read packets from a file, encap/decap them, write results to another file. Load the traces in Wireshark and see if the contents look right. (I'm not sure if Wireshark understands this protocol yet -- may have to read it as hex.)
2. Testing using the app with itself and PcapReader/PcapWriter i.e. same test but do both encapsulation and decapsulation and make sure your output looks the same as your input.
3. Testing with an external system. I'll need to identify a good one. My first guess is Linux L2TPv3 but I'm not sure if that's implementing the same internet draft as we're talking about (the author of that blog post is involved in the same project as us though...).

I'd say only do the validation that's required by the standard.

I believe that Alex Gall managed to factor out the IPv6 control messages (neighbor discovery / etc) as a separate app. You might want to ignore that aspect to begin with since we can probably reuse his code.

Does that help? (next questions?)

[altexy]

Thanks Luke, I will proceed tonight.

[altexy]

One small detail: Sessions ID/Cookie should be specified separately for both directions.

[altexy]

Hi Luke

I have first working version of tunnel passed encap-decap test. Encapsulated traces looks well, although Wireshark cannot parse it. I hope Monday I will send you pull-request. I will still need some work with IPv6 part.

One thing is not clear for me in tunnel itself - should we specify Session ID or not.

Session ID. In the "Static 1:1 mapping" case described in Section 2, the IPv6 address resolves to an L2TPv3 session immediately, thus the Session ID may be ignored upon receipt. For compatibility with other tunnel termination platforms supporting only 2-stage resolution (IPv6 Address + Session ID), this specification recommends supporting explicit configuration of Session ID to any value other than zero. For cases where both tunnel endpoints support one-stage resolution (IPv6 Address only), this specification recommends setting the Session ID to all ones for easy identification in case of troubleshooting. The Session ID of zero MUST NOT be used, as it is reserved for use by L2TP control messages RFC3931 [RFC3931].

Currently I set it to "all ones" before tx and ignore upon rx.

You wrote that you have access to Cisco router with custom firmware which support this tunnel draft. Can you ask about tunnel configuration example? It may give me a clue before we will do real interoperability test.

Alexander

[lukego]

Hi Alex,

Setting to all ones sounds like the right interpretation to me to.

I'm not working on getting a router config dump + an interoperability testing setup. I expect this will come some time after we merge the first version of this code though so we can revise the code as needed when that is available.

[theo19]

Even if this is closed, it might be worth to add that in early 2017, the draft has eveolved to the standard "Keyed IPv6 Tunnel", see https://tools.ietf.org/html/rfc8159

It is afaik also generally supported in linux as per the ip-l2tp command, http://man7.org/linux/man-pages/man8/ip-l2tp.8.html