Subject: Re: l2tp-digest V1000 #171

From: Barney Wolff <[email-masked]>
Date: Tue, 18 Jan 2000 09:34 EST

> Date: Tue, 18 Jan 2000 23:29:56 -0800
> From: "W. Mark Townsley" <[email-masked]>
> 
> Not guaranteed. I am not 100% sure about ACCM treatment on LCP echos by
> these "strict" PPP implementations. My thought is that they can handle
> this (e.g. once ACCM negotiation is completed, it is OK), but you're
> right, you can be completely sure. Trying to surround LCP echos is truly
> silly and not guaranteed to work.

RFC 1661 says (in section 5) that only LCP codes 1-7 must be sent with
the default options in effect, but I've met implementations that send
Echo Response with default ACCM, and have always worried that those
might not recognize an Echo Request with non-default ACCM.  But I
agree, surrounding an LCP Echo with SLIs feels silly.

> > After all, the worst that happens if the wrong ACCM is applied is
> > that the packet is ignored, and packets get lost once in a while
> > anyway.
> 
> No, the worst is that the packet is *always* dropped, so LCP never
> completes, and the call itself is dropped. 

I don't think so, because the SLI will eventually be received, unless
the transport has failed.  Of course an implementation with a small
retry counter may have given up, but that's always a risk - the
recommended timeout/retry values in 1661 result is giving up sooner
than the values in 2661 would.

Of course if packets are consistently re-ordered, there's no hope.

Barney Wolff

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 19 Jan 2000 09:20:29 -0800

> I don't think so, because the SLI will eventually be received, unless

The problem is that the SLI *is* received. That is, the LNS negotiates
something other than the default map. When the LAC receives the SLI, it
blindly applies the new map, causing escaping to cease for some or all
characters. From this point forward, the strict PPP client will drop all
packets that do not have default escaping.