Subject: RE: ISSLOW drafts

From: "Goodchild,Jonathan" <[email-masked]>
Date: Mon, 16 Mar 1998 13:28:00 -0500

> Carsten, could you please publish the specifics of the problem you 
> mention?  There is no inherent problem with reusing the number; as 
> has been said before, the same thing was done with IPCP VJ 
> compression, and that transition worked quite well. 
> 
> I agree that we shouldn't go out of our way to expose a bug in 
> someone's product, but we can't always avoid it, and it's 
> traditionally not been considered a valid reason to change what 
> we're doing.
> 
> What do the rest of you think?

I think that re-using option 18 is not a good idea.  (I have to admit 
that my own code doesn't check the length of option 18, and will 
mistakenly ack a length of 3 - I've not read the ISSLOW draft, so I 
don't know what will happen as a result......)

Anyway, what is the problem with assigning a new number?  We're not 
getting short of them are we?  

Jonathan Goodchild

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 16 Mar 1998 13:52:36 -0700 (MST)

>      ... Suffice it to say that there is one widely deployed product
> that "ignores the length of the Multilink Short Sequence Number Header
> Format options in LCP Configure-Requests.  It will Configure-Ack them
> no matter how short or how long."  The other (equally well-known)
> product "will, when receiving a 3-byte long LCP option type 18,
> configure-ack the 3-byte option and then use Short Sequence Number
> Headers (without classes) on the link.  This is true no matter what
> the 3rd byte is, and is true for all versions of" the product
> (including a soon-to-be-release one).
> ...

Many implementations over the years have responded to options with wrong
or unrecognized lengths with other than Configure-Reject.  Some treat
bogus lengths as evidence the peer is hopelessly broken and kill the link
(or the just the protocol if it is not LCP).  Others ignore the length
and just hope there are the right number of bytes.  This issue has come
up more than once in this mailing list and elsewhere.

Vernon Schryver    [email-masked]