Layer Two Tunneling Protocol - Version 3 (L2TPv3)
draft-ietf-l2tpext-l2tp-base-15

Did the PWE3 folks review the PWE3 capabilities additions?

I reviewed the control message reliability and congestion control:  it would be
even better if it was not optional, but it's an acceptable spec.

$ idnits-v1.27 --nitcount <drafts/draft-ietf-l2tpext-l2tp-base-13.txt
idnits 1.27, (09 May 2004)

  Checking conformance with RFC 2026 boilerplate...
  There are 14 instances of too long lines in the document,
  -- the longest one being 4 characters in excess of 72.

  Warnings:
    The document seems to lack an RFC 2026 Section 10.4(B) IPR Disclosure Invitation
    The document has an RFC 2026 Section 10.4(D) IPR Notice
    There are 10 instances of lines with hyphenated line breaks in the document.

    Line 3169 has weird spacing: '...eptable   conn...'
    Line 3175 has weird spacing: '...breaker    los...'
    Line 3180 has weird spacing: '...ol-conn    est...'
    Line 3190 has weird spacing: '...ol-conn    est...'
    Line 3260 has weird spacing: '...e local    wai...'
      ...

Comments from the ops directorate (Pekka Savola)

Tx/Rx Connect speed is in bit/s and is a 32 bit value.
While is this sufficient at the moment, and immediate future,
this could become a problem later on. Is there a reason for 
using a 32 bit value ? Otherwise, you might want to
define the field as kb/s or make it a 64bit value.

Section 4.1.4 discusses fragmentation. You might want to split
this section in a part that discusses fragmentation for
ipv4 and one for ipv6 due to differences in fragmentation
handling in ipv4 and ipv6.

Nits:

- has normative references to two Informational documents RFC1958,
  RFC2072; this is not allowed.  Move to informational references.

- there are some cases of bogus use of upper-case keywords for
  non-implementation purposes, for example in:

   Protecting the L2TP packet stream with IPsec does, in turn, also
   protect the data within the tunneled session packets while
   transported from one LCCE to the other.  Such protection MUST NOT be
   considered a substitution for end-to-end security between
   communicating hosts or applications.

(This should obviously be in lower-case -- please review the use of
the keywords.)

Reviewed by Lucy Lynch, Gen-ART

I agree that requiring non-use of UDP checksums is nonsensical and should be dropped, but "no further objection".

Why does the new version permit directly layering on top of IP? That seems like a step backwards.

Where does the cookie's length come from?  It's not explicit in the packet.  Is the receiver supposed to know what it should be, based on what it assigned?

4.1.3: State that the proposed IPsec solution takes away the ability to verify ports numbers based on cryptographic identity.

5.1: It's usually better to ignore reserved bits, rather than verify that they're zero.

7.1: The text implies that a node SHOULD ignore malformed AVPs, but it's stated as MUST.  As the text notes, it's not always possible to ignore such an error.

In section 4.1, the draft says:

      The optional Cookie field contains a variable length (maximum 64
      bits) value used to check the association of a received data
      message with the session identified by the Session ID.  The Cookie
      MUST be set to the configured or signaled random value for this
      session utilizing all bits in the field.

If this is a variable length value, what does "utilizing all bits in the field" mean
here--that there is padding to the maximum 64 bits?  If so, how is it padded?
If it means something else, can this be clarified.

In section 4.1.2.2, the draft says:


  A NAT device that can pass TFTP
   traffic with variant UDP ports should be able to pass L2TP UDP
   traffic since both protocols employ similar policies with regard to
   UDP port selection.

RFC 3617's applicability statement discourages its use, so the selection
of a different example protocol is probably in order.