Document: draft-ietf-l2tpext-l2tp-base-13
Reviewer: Lucy Lynch
Date: May 13, 2004

This document seems pretty close to done - the structure follows
"RFC 2661 - Layer Two Tunneling Protocol "L2TP"" fairly closely,
and proposed changes are noted.  so, no objection

As a side note, the interoperability issues described (4.7) may be a cause
for concern. In particular, Terminology as defined in 2661 is now often
redefined. There are also some major new additions (eg. Pseudowire)

see:
1.1  Changes from RFC 2661 note:
"Notable differences between L2TPv2 and L2TPv3 include:

     Separation of all PPP-related AVPs, references, etc., including a
     portion of the L2TP data header that was specific to the needs of
     PPP.  The PPP-specific constructs are described in a companion
     document.

     Transition from a 16-bit Session ID and Tunnel ID to a 32-bit
     Session ID and Control Connection ID, respectively.

     Extension of the Tunnel Authentication mechanism to cover the
     entire control message rather than just a portion of certain
     messages.

   Details of these changes and a recommendation for transitioning to
   L2TPv3 are discussed in Section 4.7."

and

4.7  L2TPv2/v3 Interoperability and Migration note:
   "Most issues apply only to implementations that require both L2TPv2 and
L2TPv3 operation. However, even L2TPv3-only implementations must at least
be mindful of these issues in order to interoperate with implementations
that support both versions."

as an example:

RFC 2661 - Layer Two Tunneling Protocol "L2TP"
6.2 Start-Control-Connection-Reply (SCCRP)

The following AVPs MUST be present in the SCCRP:

      Message Type
      Protocol Version
      Framing Capabilities
      Host Name
      Assigned Tunnel ID

   The following AVPs MAY be present in the SCCRP:

      Bearer Capabilities
      Firmware Revision
      Vendor Name
      Receive Window Size
      Challenge
      Challenge Response

while the draft says:

6.2  Start-Control-Connection-Reply (SCCRP)

   The following AVPs MUST be present in the SCCRP:

      Message Type
      Host Name
      Router ID
      Assigned Control Connection ID
      Pseudowire Capabilities List

   The following AVPs MAY be present in the SCCRP:

      Random Vector
      Nonce
      Message Digest
      Vendor Name
      Receive Window Size
      Preferred Language

This bit a worrisome:

10.5  L2TP Control Message Header Bits

   There are nine remaining reserved bits in the control message header.
   Additional bits should only be assigned via a Standards Action
   [RFC2434].

   Care should be taken before using reserved bits 6 and 7 in the L2TPv3
   control message header since these bits have meaning for L2TPv2 data
   messages.  Using these two bits in L2TPv3 MAY trigger an unforeseen
   interoperability problem with L2TPv3 implementations based on L2TPv2.
   Therefore, it is recommended that these two bits be utilized last,
   after the other reserved bits have been assigned roles.

and I am unclear about the reason for using bits 6 & 7 last - is this in
hopes that L2TPv3 will have superceeded  L2TPv2 before they are used?