Subject: L2TPv2/v3 in-band interoperability problem

From: Jed Lau <[email-masked]>
Date: Thu, 20 Sep 2001 20:26:42 -0700 (PDT)

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: Stewart Bryant <[email-masked]>
Date: Mon, 24 Sep 2001 13:01:26 +0100

Jed

Firstly I hope that we can restrict your proposal to the in-band case only,
so that implementations operating over the L2TP protocol type do not need
this extra long word.

An alternative is to forbid session id values that alias the version field 
of earlier protocol versions. This is a bit of a hack, but acheives the same
thing without the dummey 4 bytes. Assuming 3 reserved version values this would
reduce the number of sessions by 8*10^8 from 4.3*10^9 to 3.4*10^9, but
would prohibit certain implementation techniques.

To prevent limitations in the future we should reserve a small set of session
ids for the protocol.

Regards

Stewart

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 25 Sep 2001 10:42:56 +0100

> would prohibit certain implementation techniques.

This is a *horrible* hack.

> To prevent limitations in the future we should reserve a small set of session

I know I'm coming to this late, but ...

the whole point of a "version" field in a protocol is so that you can tell
which version you're using. Why was it dropped from the v3 protocol ?

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <[email-masked]>  | Fax:  +44 20 8371 1037
Demon Internet      | WWW: http://www.davros.org | DFax: +44 20 8371 4037
Thus plc            |                            | Mobile: +44 7973 377646

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Sep 2001 11:55:20 +0100

> This is a *horrible* hack.

Yes, but you should at least put all the alternatives on the table before
picking one :)

> which version you're using. Why was it dropped from the v3 protocol ?

One of the new target roles for L2TP is the support of pseudo-wires (PWE3).
A pseudo wire will be expected to operate at speeds of 10Gb/s plus, and at
these speeds you really need to strip the protocol down to the minimum
necessary and sufficient fields, and then lay them out for maximum 
(implementation independent) processing efficiency.

If there are no out-band implementations of L2TPv2, then the compatibility
word is only needed for the inband case which is less likely to be used for
ultra-high speed implementations. So if could become the in-band
compatibility word that is checked and stripped before passing the 
remainder of the packet to a common in-band - out-band processing module.

The use of the opaque data field at the beginning of the L2TPv3 header
gives you the same capabilities as a version field for future protocol
versions. 

Stewart