Re: [Fwd: Re: PPP implementation specific.]
James Carlson <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
Jakob Heitz writes: > rfc1661 says > "an implementation MUST still be able to receive the > full 1500 octet information field in case link synchronization is > lost." > > "in case link synchronization is lost." is open to liberal > interpretation. There are really only two cases for a "loss of synchronization" -- either LCP was closed, or it wasn't. If LCP wasn't closed, then the MRU is still valid. If LCP has been torn down by the peer, (1) the default MRU is 1500 and (2) the only valid messages on the link are LCP negotiation messages. So, if someone really wanted to go to the trouble of creating an implementation that was strict about MRU for all message types other than LCP negotiation messages (perhaps by checking the first few octets as they're decoded and using that to select an input buffer), then I believe that'd comply with the spirit of the RFC. I also agree that it'd be a baroque mechanism, but it'd work. > To avoid problems, I will assume the worst > interpretation by my peers and just accept the > 1500 bytes. Makes Tech Support happy. Yep. That's what many do. -- James Carlson, IP Systems Group <[email protected]> Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pppext