Subject: Re: L2TPv2/v3 in-band interoperability problem

From: Ignacio Goyret <[email-masked]>
Date: Fri, 21 Sep 2001 09:55:04 -0700

This is not necessarily a problem: since you are using IP/UDP,
you can determine which peer you are talking to and thus, the type
of the remote peer.

-Ignacio

NB: I'm still not convinced that the new v3 headers are a good thing.

At 08:26 PM 9/20/01 -0700, Jed Lau wrote:
>Hi all,
>
>After a conversation with one of my peers, it became evident to me that we
>have a problem when an L2TPv2- and v3-capable LCCE receives both v2 and v3
>traffic in-band (i.e. over IP/UDP, port 1701).  The LCCE has no way of
>distinguishing v2 traffic from v3 traffic.
>
>BACKGROUND
>----------
>
>The first four bytes of an L2TPv2 header are defined as follows:
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Length (opt)         |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   ...
>
>For L2TPv2, the L2TP header's first two-byte "version and flags" field is
>the smallest denomination for determining the "type" of packet that has
>been received (e.g. L2F or L2TP, control or data, etc.).
>
>In contrast, the first four bytes of an L2TPv3 data header is just the
>32-bit Session ID field:
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                           Session ID                          |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   ...
>
>PROBLEM
>-------
>
>When L2TPv3 data traffic is received in-band with L2TPv2 control and data
>traffic, there is no way to determine whether the first two bytes of the
>L2TP header comprise the L2TPv2 "version and flags" field, or whether they
>comprise the first two bytes of the L2TPv3 32-bit Session ID field.
>
>PROPOSAL
>--------
>
>For backwards compatibility, add four bytes to the front of the L2TPv3
>data header, which contain the two-byte "version and flags" field and 2
>bytes of padding.  The L2TPv3 data header would thus appear as follows:
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |T|L|x|x|S|x|O|P|x|x|x|x|  Ver  |          Padding              |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                           Session ID                          |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                             Cookie                            |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | L2-Specific Sublayer (arbitrary length)...                    |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Tunneled L2 Frame...
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>The T bit MUST be set to 0, indicating that this packet is a data message.
>The L, S, O, and P bits SHOULD be set to 0, even though in the context of
>L2TPv3, they won't mean anything.  (We might even want to say that the P
>bit MUST be set to 0.  If it were set to 1, the packet might be
>prematurely punted for handling at a higher priority.)  Padding must be
>ignored (necessary, however, to maintain long word alignment).
>
>The Ver field is the key differentiator between L2TPv2 packets (either
>control or data) and L2TPv3 data packets.  On sending an L2TPv3 data
>packet, the Ver field MUST be set to 3.
>
>PRO: When the L2TPv3 control plane and data plane run in-band, the
>high-order bit of the Session ID no longer plays a role in distinguishing
>control traffic from data traffic.  (See the current text in Section 5.7
>of the draft.)  The Session ID space is thus able to utilize all 32 bits
>in all cases.
>
>CON: (1) 4 bytes are added to the L2TPv3 data header.  (2) If the L2TPv3
>control plane and L2TPv3 data plane are running in-band with L2TPv2, 3
>bits (the T bit, plus the least-significant 2 bits of the Ver field) now
>need to be checked to distinguish an L2TPv3 data message from an L2TPv3
>control message.  Previously, only 1 bit (the T bit) needed to be checked.
>
>Comments?  Questions?  Other proposals?
>
>Thanks.
>
>Jed
>
>
>
>
>
>
>
>
>

---

From: Skip Booth <[email-masked]>
Date: Fri, 21 Sep 2001 13:32:18 -0400

> you can determine which peer you are talking to and thus, the type

This requires a separate, and expensive, lookup.  Besides, I can imagine
scenarios where you have L2F, L2TPv2 and L2TPv3 tunnels between the same
peer.  I don't think the draft explicitely prohibits this either.

-Skip