Subject: AW: PPP Frames on tunnel

From: Klausberger Walter <[email-masked]>
Date: Tue, 1 Aug 2000 13:02:22 +0200

Hi,

Well I don't see any contradiction in the replies of Mark and James. In my
opinion Mark states that FF 03 has to be added by LNS when sending packets
(unless ACFC is negotiated of course) and James says that FF03 must be added
to the tunneled frames (by the LNS).

I had similar questions about two years ago, when I stated that L2TP was too
much restricted to ISDN or modem access. The answer then was "Let's think
about that in a later extension, we want the draft to become RFC". Because
the LNSs in the fields would have to handle all types of framing (eg. Frame
Relay, ATM and so on) the whole thing was simply restricted to the
address/control field. This must be sent, because common PPP implementations
assume that this is a negotiable header for links over HDLC.

So a LAC having access over ATM, Frame Relay or even Ethernet has to be a
little bit intelligent to add and remove the address/control field.

Hope I'm not wrong
with best regards
Walter Klausberger
Siemens AG Austria 

-----Ursprüngliche Nachricht-----
Von: Andy Bickford [mailto:[email-masked]]
Gesendet am: Dienstag, 01. August 2000 11:16
An: [email-masked]
Betreff: Re: PPP Frames on tunnel

Hi folks,

Can anybody clarify the replies to Sridhar's question, as they appear to
contradict each other.

Hence what should be added to the PPP frames being sent from the LAC to
the LNS and the LNS to the LAC ?

How does the LAC/LNS distinguish between the FF 03 bytes that have been
added as extra bytes on entry to the tunnel and the real address and control
fields ?

Apologies if the questions have already been answered.

Best Regards

Andy Bickford
Technical Associate
IPWireless Inc

>Sridhar Malarothu wrote:
>
> Hi All,
>
>     LAC before sending ppp frames on tunnel to LAC should strip of
> the CRC, Link Framing and transperancy bytes, encapsulate them in L2TP
> header. But what should be status of the PPP frames on tunnel, if send
> by LNS.
>
> Best Regards
> Sridhar

>Mark Townsley's reply was:
>
>PPP framing of FF03, unless ACFC is negotiated, should exist on packets
>sent from the LNS and from the LAC.

>James Carlson's reply was:
>
>Data frames from the LNS should not have an appended CRC, framing, or
>transparency bytes, and they should have L2TP headers.
>
>Note that the leading FF 03 (the default values used for the HDLC Address
>and Control fields on regular PPP links) must be included on the tunneled
>frames, contrary to prior convention (such as described in RFCs 1598, 1973,
>and 2364). So, if you're coming from a regular PPP over Frame Relay network
>into an L2TP tunnel, you'll have to add those extra bytes on entry to the
>tunnel and remove them before going into Frame Relay.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 01 Aug 2000 10:01:52 -0400

> about that in a later extension, we want the draft to become RFC". Because

Given the obvious HDLC mindset of the day, there were valid arguments
for keeping the framing present of the tunneled packets --  For
instance, though not used so often today, RFC1663 requires the Address
and Control fields (for better or worse there was a lot of talk at the
time about making the data channel reliable... this was our way of
answering that request). Further, given the ability to negotiate away
the framing fields with ACFC, effectively adding another method to do so
in L2TP seemed a bit redundant. There could be other extensions to PPP
down the road that used these fields as well. I would say that there was
a certain amount of intrepidation about "backing ourselves into a
corner" by not requiring the framing to be sent, particularly given that
there was already an established way of getting rid of it via existing
PPP methods if desired.

With the increased usage of PPP over eth, ATM, FR, etc. together with
many LACs tunneling PPP without first stepping through LCP to determine
whether ACFC was negotiated, perhaps a "raw" framing type belongs in
l2tp-bis. I suspect that there are probably a handful of L2TP systems
that do not add or subtract the Address and Control fields properly now,
but PPP is resilient to the error. The reality is that most PPP
implementations are very forgiving of the presence of framing upon
receipt of a packet.