From ietf-ppp-request@MERIT.EDU Tue Feb 4 09:21:35 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA10397; Tue, 4 Feb 1997 09:21:35 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 09:21:35 -0500 (EST) From: msp@corp.sprintmail.com (Mark Petrovic) Message-Id: <199702041420.IAA07532@manny.ops.sprintisp.net> Subject: asyncmap and rfc 1661 To: ietf-ppp@MERIT.EDU Date: Tue, 4 Feb 1997 08:20:11 -0600 (CST) Reply-to: msp@corp.sprintmail.com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hffy9.0.uX2.4Nqzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2604 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Where might I find a discussion of why the LCP option asyncmap is not mentioned in RFC 1661, yet holds a prominent place in RFC 1548? -- Mark S. Petrovic, Operations v 816 854-3152 Sprint Internet Passport p 800 724-3508 1200 Main, Kansas City, MO PIN 385-6972, or msp@corp.sprintmail.com 3856972@pagenet.net - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 10:15:11 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11730; Tue, 4 Feb 1997 10:15:11 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 10:15:11 -0500 (EST) Message-Id: <11017.9702041513@vulcan.xylogics.com> To: msp@corp.sprintmail.com Cc: ietf-ppp@MERIT.EDU Subject: Re: asyncmap and rfc 1661 In-Reply-To: Your message of "Tue, 04 Feb 1997 08:20:11 CST." <199702041420.IAA07532@manny.ops.sprintisp.net> Date: Tue, 04 Feb 1997 10:13:39 -0500 From: James Carlson Resent-Message-ID: <"3aYxE1.0.ws2.u9rzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2605 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In message <199702041420.IAA07532@manny.ops.sprintisp.net>, Mark Petrovic writes: > Where might I find a discussion of why the LCP option asyncmap is not > mentioned in RFC 1661, yet holds a prominent place in RFC 1548? RFC 1662 would be a good place to start ... --- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4782 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 10:21:33 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11874; Tue, 4 Feb 1997 10:21:33 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 10:21:33 -0500 (EST) Message-Id: <199702041521.KAA11840@merit.edu> Date: Tue, 4 Feb 97 09:21:13 CST From: "Martz, John R. (8-852-5539)" To: IETF-PPP@MERIT.EDU Subject: asyncmap and rfc 1661 Resent-Message-ID: <"y7OYt1.0.9v2.tFrzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2606 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Ref: Your note of Tue, 4 Feb 1997 08:20:11 -0600 (CST) (attached) Here's is my understanding of it: Back when RFC 1661 and 1662 et alia were created, the intent was to separate out the parts of PPP that are protocol dependent are document those in separate RFC's. That's why the HDLC encapsulation is discussed in 1662 and not in 1661. And since the asynch map really only applies to an asynch link layer, it also is covered in RFC1662. This confused the heck out of me too when I was first attempting to digest the PPP RFC's. However, to those who regularly contribute to this mailing list, this organization is considered to be so "obvious" that it's hard for them to understand why folks like you and I get confused. For what it's worth, -john martz, AS/400 TCP/IP configuration (and stuff) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 12:03:42 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id MAA14425; Tue, 4 Feb 1997 12:03:42 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 12:03:42 -0500 (EST) From: msp@corp.sprintmail.com (Mark Petrovic) Message-Id: <199702041702.LAA08222@manny.ops.sprintisp.net> Subject: looped back lines and magic number To: ietf-ppp@MERIT.EDU Date: Tue, 4 Feb 1997 11:02:58 -0600 (CST) Reply-to: msp@corp.sprintmail.com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"nq9Lv2.0.1X3.dlszo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2607 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I understand what the magicnumber options does for detecting looped-back links under PPP, but I don't understand how the anomalous condition of a looped-back link itself comes to be. Are looped-back links common? I don't think I've ever heard of one... -- Mark S. Petrovic, Operations v 816 854-3152 Sprint Internet Passport p 800 724-3508 1200 Main, Kansas City, MO PIN 385-6972, or msp@corp.sprintmail.com 3856972@pagenet.net - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 12:25:09 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id MAA15112; Tue, 4 Feb 1997 12:25:09 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 12:25:09 -0500 (EST) Date: Tue, 4 Feb 1997 09:24:49 -0800 (PST) From: Erik Olson To: Mark Petrovic cc: ietf-ppp@MERIT.EDU Subject: Re: looped back lines and magic number In-Reply-To: <199702041702.LAA08222@manny.ops.sprintisp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"dqAgy2.0.ch3.h3tzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2608 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Tue, 4 Feb 1997, Mark Petrovic wrote: > I understand what the magicnumber options does for detecting > looped-back links under PPP, but I don't understand how the anomalous > condition of a looped-back link itself comes to be. Are looped-back > links common? I don't think I've ever heard of one... We get looped-back lines when the modem is in local-echo mode (ie, hasn't dialed yet), or we're connected to a server that is still expecting a text login and doesn't switch over to PPP... and is still echoing everything back. --- Erik Olson eriko@wrq.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 12:44:52 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id MAA15656; Tue, 4 Feb 1997 12:44:52 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 12:44:52 -0500 (EST) Message-ID: <32F77551.6913@asys-h.de> Date: Tue, 04 Feb 1997 18:43:45 +0100 From: Peter Sager Reply-To: sager@asys-h.de Organization: advanced systems software GmbH X-Mailer: Mozilla 3.01 [de] (WinNT; I) MIME-Version: 1.0 To: ietf-ppp@MERIT.EDU CC: sager@asysha.asys-h.de Subject: Questions on STD51/RFC1661 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8pa8D3.0.Eq3.EMtzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2609 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello, I am working on a PPP implementation based on the STD51 document. The document date is July 1994, have there been any changes or bug fixes in the FSM since then ? If so, where can I obtain them ? I am wondering wether the entry in state 9 (Opened) on event RTR should contain an additional str action, since the next state is 5 (Stopping) in which the automaton awaits a Terminate Ack ? Thank you in advance for any help or comments ! Regards, Peter Sager -- o-----------------------------------------------------------o | Peter Sager sager@asys-h.de | | Advanced Systems Software GmbH http://www.asys-h.de | | Vahrenwalder Strasse 205-207 VOICE: +49 511 37294 0 | | D-30165 Hannover FAX: +49 511 37294 1 | o-----------------------------------------------------------o - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 14:04:41 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA17443; Tue, 4 Feb 1997 14:04:41 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 14:04:41 -0500 (EST) Date: Tue, 4 Feb 1997 11:04:16 -0800 Message-Id: <199702041904.LAA02124@gump.eng.ascend.com> From: Karl Fox To: sager@asys-h.de Cc: ietf-ppp@MERIT.EDU Subject: Questions on STD51/RFC1661 In-Reply-To: <32F77551.6913@asys-h.de> References: <32F77551.6913@asys-h.de> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"y-ncA.0.1G4.-Wuzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2610 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Peter Sager writes: > I am working on a PPP implementation based on the > STD51 document. The document date is July 1994, have there > been any changes or bug fixes in the FSM since then ? > If so, where can I obtain them ? No, STD51 (RFC1661) is the latest and greatest. > I am wondering wether the entry in state 9 (Opened) on > event RTR should contain an additional str action, since > the next state is 5 (Stopping) in which the automaton > awaits a Terminate Ack ? Just because you're in state 5 doesn't necessarily mean you're awaiting a Terminate-Ack. Remember that we made the transition from state 9 to state 5 because we received a Terminate-Request, and we replied with a Terminate-Ack at the same time, so no further packets need to be passed. Another thing we did at the state transition was to zero the Restart counter, so as soon as the Restart timer expires, we'll get a TO- event, do a tlf and go to state 3 (Stopped). Or, in the case of a dialed connection, we might get a Down event because the other side hung up the phone. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 14:05:46 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA17495; Tue, 4 Feb 1997 14:05:46 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 14:05:46 -0500 (EST) Date: Tue, 4 Feb 1997 11:04:56 -0800 (PST) From: Pete Heirendt X-Sender: heirendt@bertha To: Mark Petrovic Cc: ietf-ppp@MERIT.EDU Subject: Re: looped back lines and magic number In-Reply-To: <199702041702.LAA08222@manny.ops.sprintisp.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Aiez63.0.yG4.3Yuzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2611 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Mark, Loopbacks are often used to test a WAN link at the physical layer (T1, 56K DDS, etc.); most commonly following installation of a new line or upon failure of an existing line. Loopback capabilities are implemented in many DSU/CSU's on the market. Although loopbacks are typically never used during normal operations, it is possible for an inadvertent loopback to get set either through operator error or through poorly designed DSU/CSU equipment. If you're interested in more details: Standards for T1 describe protocols to allow one DSU to command the opposite end DSU to go into loopback. These commands include simple "loop up codes" which simply overwrite the normal data stream with a repeated bit pattern that is extremely unlikely to be seen in normal user data. For instance, a very common protocol is a repeating "10000" bit pattern transmitted continuously for 5 seconds (since there are 5 bits, the pattern can't be duplicated by a repeating 8 bit pattern). Although it is extremely unlikley that normal user data could accidently duplicate this pattern, a poorly designed DSU/CSU may do a sloppy job of verifying the pattern and mistakenly put itself into loopback upon seeing something that only vaguely resembles a true "10000" pattern. On Tue, 4 Feb 1997, Mark Petrovic wrote: > I understand what the magicnumber options does for detecting > looped-back links under PPP, but I don't understand how the anomalous > condition of a looped-back link itself comes to be. Are looped-back > links common? I don't think I've ever heard of one... > > -- > Mark S. Petrovic, Operations v 816 854-3152 > Sprint Internet Passport p 800 724-3508 > 1200 Main, Kansas City, MO PIN 385-6972, or > msp@corp.sprintmail.com 3856972@pagenet.net > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 14:46:36 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA18466; Tue, 4 Feb 1997 14:46:36 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 14:46:36 -0500 (EST) Message-ID: <32F791E8.4184@asys-h.de> Date: Tue, 04 Feb 1997 20:45:44 +0100 From: Peter Sager Reply-To: sager@asys-h.de Organization: advanced systems software GmbH X-Mailer: Mozilla 3.01 [de] (WinNT; I) MIME-Version: 1.0 To: Karl Fox CC: ietf-ppp@MERIT.EDU Subject: Re: Questions on STD51/RFC1661 References: <32F77551.6913@asys-h.de> <199702041904.LAA02124@gump.eng.ascend.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"72quV3.0.6W4.M8vzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2612 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Karl Fox wrote: > > Peter Sager writes: ... > > I am wondering wether the entry in state 9 (Opened) on > > event RTR should contain an additional str action, since > > the next state is 5 (Stopping) in which the automaton > > awaits a Terminate Ack ? > > Just because you're in state 5 doesn't necessarily mean you're > awaiting a Terminate-Ack. Remember that we made the transition from > state 9 to state 5 because we received a Terminate-Request, and we > replied with a Terminate-Ack at the same time, so no further packets > need to be passed. Another thing we did at the state transition was > to zero the Restart counter, so as soon as the Restart timer expires, > we'll get a TO- event, do a tlf and go to state 3 (Stopped). Or, in > the case of a dialed connection, we might get a Down event because the > other side hung up the phone. OK, I got it. The additional delay ensures that our Term-Ack reaches the other side, before the tlf action disrupts the ISDN connection. Thanks for help. Regards Peter Sager -- o-----------------------------------------------------------o | Peter Sager sager@asys-h.de | | Advanced Systems Software GmbH http://www.asys-h.de | | Vahrenwalder Strasse 205-207 VOICE: +49 511 37294 0 | | D-30165 Hannover FAX: +49 511 37294 1 | o-----------------------------------------------------------o - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 14:47:48 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA18537; Tue, 4 Feb 1997 14:47:48 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 14:47:48 -0500 (EST) Message-Id: <2.2.32.19970204194814.003196b8@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Feb 1997 11:48:14 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: Re: Questions on STD51/RFC1661 Resent-Message-ID: <"Yh7ID1.0.CX4.T9vzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2613 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 11:04 AM 2/4/97 -0800, Karl Fox wrote: >Peter Sager writes: >> I am working on a PPP implementation based on the >> STD51 document. The document date is July 1994, have there >> been any changes or bug fixes in the FSM since then ? >> If so, where can I obtain them ? > >No, STD51 (RFC1661) is the latest and greatest. There was some debate in the past about the whether the state machine really reflects what is best, and whether implementations might benefit from deviating from it. If I recall, the state machine requires that after sending a Terminate-Request, you discard all received packets while waiting for the Terminate-Ack. Many implementations do not follow this, and instead continue processing/forwarding received packets while waiting for the Terminate-Ack. There are many circumstances where continuing to process/forward while waiting is beneficial. (It can avoid packet loss when tearing down one link of a multi-link bundle, for example.) IMHO, the next version of PPP should modify the state machine to allow this common behavior. Were I creating a new PPP implementation today, I would consider implementing this behavior. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 14:51:25 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA18668; Tue, 4 Feb 1997 14:51:25 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 14:51:25 -0500 (EST) Date: Tue, 4 Feb 1997 14:47:06 -0500 (EST) From: John Shriver Message-Id: <199702041947.OAA01126@shiva-dev.shiva.com> To: msp@corp.sprintmail.com CC: ietf-ppp@MERIT.EDU In-reply-to: <199702041702.LAA08222@manny.ops.sprintisp.net> (msp@corp.sprintmail.com) Subject: Re: looped back lines and magic number Resent-Message-ID: <"buLvm3.0.IZ4.sCvzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2614 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In my experience, looping was the most common error I encountered when I was babysitting a leased line from Proteon to MIT (before NEARNet). This applied to both the 3002-type 4-wire leased line, and the later 56kb DDS line. The typical mess-up was: >------------------+-----------------> | <------------------+ X <----------< Since leased lines were a primary focus of the original PPP design effort (a common protocol for Cisco, Proteon, ACC, and others), it was very important to detect this most common failure mode. The Proteon proprietary serial line format didn't detect this error. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 14:54:13 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA18747; Tue, 4 Feb 1997 14:54:13 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 14:54:13 -0500 (EST) Message-Id: <2.2.32.19970204195441.00330848@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 04 Feb 1997 11:54:41 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: Re: looped back lines and magic number Resent-Message-ID: <"t7Zbx.0.Ua4.TFvzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2615 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >On Tue, 4 Feb 1997, Mark Petrovic wrote: > >> I understand what the magicnumber options does for detecting >> looped-back links under PPP, but I don't understand how the anomalous >> condition of a looped-back link itself comes to be. Are looped-back >> links common? I don't think I've ever heard of one... I used to develop code for telephone modems. Many modems are connected to devices (e.g., PADs) which echo characters (so the sender can 'see' what he's typing). I have seen modems "negotiate" an error correction protocol with their own echo. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 4 16:35:29 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id QAA21296; Tue, 4 Feb 1997 16:35:29 -0500 (EST) Resent-Date: Tue, 4 Feb 1997 16:35:29 -0500 (EST) From: nashley@VNET.IBM.COM Message-Id: <199702042135.QAA21240@merit.edu> Date: Tue, 4 Feb 97 16:33:36 EST To: ietf-ppp@MERIT.EDU Subject: remove Resent-Message-ID: <"fp0Of.0.HC5.Okwzo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2616 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 5 14:18:57 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA07723; Wed, 5 Feb 1997 14:18:57 -0500 (EST) Resent-Date: Wed, 5 Feb 1997 14:18:57 -0500 (EST) Date: Wed, 5 Feb 1997 11:16:50 -0800 Message-Id: <199702051916.LAA05999@gump.eng.ascend.com> From: Karl Fox To: inads@research.ftp.com Cc: Steve Coya , ietf-ppp@MERIT.EDU Subject: Microsoft Point-To-Point Compression (MPPC) Protocol to Informational Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"F9w_x2.0.Rt1.uoD-o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2617 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Frank and Jeff, The PPPEXT Working Group recommends that the current MPPC Internet Draft, draft-ietf-pppext-mppc-00.txt, be advanced to Informational. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 6 10:41:12 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA23394; Thu, 6 Feb 1997 10:41:12 -0500 (EST) Resent-Date: Thu, 6 Feb 1997 10:41:12 -0500 (EST) Date: Thu, 6 Feb 1997 07:40:03 -0800 Message-Id: <199702061540.HAA10513@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Subject: Agenda items for April IETF in Memphis, Tennessee Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"BP7y23.0._i5.ajV-o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2618 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Please send me requests for agenda items for the April meeting in Memphis, Tennessee. I need these ASAP so that we can reserve the time slots that I expect we'll need. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 6 18:26:53 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id SAA02271; Thu, 6 Feb 1997 18:26:53 -0500 (EST) Resent-Date: Thu, 6 Feb 1997 18:26:53 -0500 (EST) Date: Thu, 06 Feb 97 18:24:54 EST From: "Whelan, Bill" Message-Id: <9701068552.AA855282444@netx.nei.com> To: ietf-ppp@MERIT.EDU Subject: DESE - Why encrypt the Initial Nonce? Resent-Message-ID: <"x-pjA2.0.2Z.pYc-o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2619 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU As long as we are talking about changes to DESE, I thought I'd bring up another issue. RFC1969 section 6.3 indicates that the Initial Nonce must be encrypted before being used to decrypt the first packet. I believe (disclaimer - not a Real Cryptographer) this encryption step provides no added value (security) and is more an annoyance than anything else. Such "protection" is not provided on any packets other than the first packet. Our implementation initially did not perform this encryption. This error resulted in us always losing the first packet then successfully decrypting all subsequent packets. Therefore, if this encryption is of any value (Real Cryptographers?), it is marginal at best. It is also inconsistent with the handling of subsequent packets. By itself, this issue wouldn't warrant a change to DESE. But if a replacement RFC is to be written to address the padding controversy, I would vote to remove this step at the same time. Bill Whelan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 7 12:27:56 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id MAA14407; Fri, 7 Feb 1997 12:27:56 -0500 (EST) Resent-Date: Fri, 7 Feb 1997 12:27:56 -0500 (EST) Date: Fri, 7 Feb 1997 09:25:34 -0800 Message-Id: <199702071725.JAA14808@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Subject: Tiebreaker: Plaintext padding in RFC 1969, DESE In-Reply-To: <199701171916.LAA08622@spud.ascend.com> References: <199701171916.LAA08622@spud.ascend.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"00p2P1.0.yV3.hMs-o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2620 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Concerning my request for opinions on how plaintext ought to be padded in DESE: The (slight) majority preferred using SDP regardless of whether it had been negotiated in LCP (option 1B as clarified by Bill Whelan). Almost all the rest (a slight minority) wanted some sort of count; many people specifically requested an ESP-style pad count at the end of the packet, an option I hadn't considered. So, let me try to break the near-tie: Given only the two options below, which do you prefer? Please respond directly to me, karl@ascend.com, not to the entire list. 1B: Unlink plaintext padding and ciphertext padding. Always pad the plaintext before encrypting using the techniques of SDP. Do not require the negotiation of SDP to do so. SDP negotiation would only apply to the ciphertext. 5: Pad in the style of ESP-DES-CBC--after decrypting, the last byte of the plaintext buffer contains the pad count, which does not include the pad count itself. This value, therefore, ranges from 0 to 7. Note that both options are exactly equivalent in terms of line efficiency. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 10 12:00:49 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id MAA13431; Mon, 10 Feb 1997 12:00:49 -0500 (EST) Resent-Date: Mon, 10 Feb 1997 12:00:49 -0500 (EST) Date: Mon, 10 Feb 1997 11:59:21 -0500 (EST) From: avri doria To: ietf-ppp@MERIT.EDU Subject: control for selecting service provider in ppp Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"wj3BN2.0.GH3.lFr_o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2621 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I am in the process of designing some equipment that hangs at the edge of the copper loop doing xDSL to multi service provider access. This design has made me aware of an issue I need to resolve. What i am looking for is a way to terminate PPP at that point. Before i can do authentication, however, i need to allow the user to pick a service provider. Since it is not dialup, i don't have the luxury of a phone number. What i am looking for is a way to, before authentication, designate a service provider. I don't think this will be an application where tunneling will work, so the "Layer Two Tunneling Protocol" protocol doesn't solve my problem. In terms of looking for solutions, the following have been looked at: - find an already existing field in the LCP which serves this function. I couldn't find one that seemed designed for that. - use the vendor specific LCP functions. While this is a possible solution, I believe that the utility of such a capability goes beyond GDC and GDC's customers, as the enhanced capabilities envisioned for the future do include multiple ISP selection. While it not certain that the access network providers will standardize on PPP, it is a possibility they are entertaining. Besides, it is not a property of controlling the line, so in a purist sense, overloading the LCP with this function seems somewhat inappropriate. BTW, the basic application assumption is that the multi-service access provider provides co-location service (per the 1996 Telecommunications Deregulation Act) to various ISPs. Since the cu termination is an xDSL port, when changes from one provider to another, it is currently necessary to change a hardwired connection. In the future, this needs to be done dynamically, and as mentioned above, it is likely that users will wish to subscribe to more then one service provider. It is not certain that PPP will be terminated in the access provider DSLAM, but it is a distinct possibility. Even if it is not, it would need to be terminated before the Internet service provider. My question is, does it seem reasonable to design another PPP control protocol to handle service selection. Is anyone already working on such a thing? If it is reasonable, I figure such a protocol would need to not only include an identifier, but a key to the type of identifier being used. i..e NSAP, IPv[4,6] address, telephone number .... If is seems at all reasonable to any of you, I will write up a draft and send it in. I don't want, however, to burden the group with another draft for which there is not interest or which is redundant. avri - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 10 18:19:01 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id SAA22232; Mon, 10 Feb 1997 18:19:01 -0500 (EST) Resent-Date: Mon, 10 Feb 1997 18:19:01 -0500 (EST) From: tmima@mediagate.com Date: Mon, 10 Feb 97 12:43:59 -0800 Subject: STAC LZS: histories can get out of sync. To: ietf-ppp@MERIT.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"-zINq1.0.sQ5.Ppw_o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2622 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In a multilink environment, the compressor's and decompressor's histories can get out of sync even when sequence numbers are used as a CCP check mode. This is an example similar to the one in rfc1974 (page 9). In this example the algorithm works fine. 2.5.3.3.1 History Synchronization with Sequence Numbers Example Compressing Sender Decompressing Receiver .... .... send seq 101 -----------> recv seq 101 is 101 == 101? Ok. forward packet for processing set internal reference to 102 send seq 102 -----------> recv seq 102 is 102 == 102? Ok. forward packet for processing set internal reference to 103 send seq 103 ------X (packet lost) send seq 104 -----------> recv seq 104 is 104 == 103? Send reset req! silently discard packet set internal reference to 105 <----------- send reset request (ID=200) post-increment the identifier. send seq 105 -----------> recv seq 105 is 105 == 105? Ok. was reset ack received? No! silently discard packet set internal reference to 106 recv reset req <----------- (after line delay) (ID=200) reset compression history send reset ack -----------> recv reset ack (ID=200) (ID=200 ) send seq 106 -----------> recv seq 106 is 106 == 106? Ok. forward packet for processing set internal reference to 107 .... .... A very similar sequence will cause a failure in another setting: We have two machines: compressor (machine C) and decompressor (machine D) They are using multilink, and connected using 2 links. One link is slower (link S), and the other link is F (fast). Packet 103 is lost. Machine C is alternating packets on the links. It sent packet 104 on link F, and then sent packet 105 on link S. When packet 104 arrives it causes a receive failure on D. D is sending CCP Reset Request on link F. C replies with CCP Reset Ack on link F as a CCP protocol, not MP (C is using MP only for data packets). Since link F is fast, and the CCP packets are tiny, the CCP packets were exchanged BEFORE machine D received packet 105. When 105 arrives, D will accept it, and the histories are out of sync. send seq 103 ------X (packet lost) F send seq 104 -----------> recv seq 104 is 104 == 103? Send reset req! silently discard packet set internal reference to 105 S send seq 105 -----------> F recv reset req <----------- send reset request (ID=200) (ID=200) post-increment the identifier. reset compression history F send reset ack -----------> recv reset ack (ID=200) (ID=200 ) S -----------> recv seq 105 (after line delay) is 105 == 105? Ok. forward packet for processing set internal reference to 106 .... .... A suggestion for a fix: In CCP Reset Ack, in addition to the history number also add the sequence # of the packet following the history reset. The decompressor will silently discard packets with lower sequence#. In our case, the CCP Reset Ack will also say sequence# 106. Packet 105 will be discarded. (This can be backward compatible with rfc1974: If the length field of the CCP Reset Ack is 7, there is a seq# following the history#). Thanks, Tmima - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 10 18:32:23 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id SAA22712; Mon, 10 Feb 1997 18:32:23 -0500 (EST) Resent-Date: Mon, 10 Feb 1997 18:32:23 -0500 (EST) Date: Mon, 10 Feb 1997 15:32:03 -0800 (PST) From: Mike Thornburg To: tmima@mediagate.com cc: ietf-ppp@MERIT.EDU Subject: Re: STAC LZS: histories can get out of sync. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"B67RH3.0.WY5.00x_o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2623 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Mon, 10 Feb 1997 tmima@mediagate.com wrote: > > In a multilink environment, the compressor's and decompressor's histories can get out of > sync even when sequence numbers are used as a CCP check mode. > > [snip] > > send seq 103 ------X (packet lost) > > F > send seq 104 -----------> recv seq 104 > is 104 == 103? Send reset req! > silently discard packet > set internal reference to 105 > S > send seq 105 -----------> > > F > recv reset req <----------- send reset request (ID=200) > (ID=200) post-increment the identifier. > > reset compression > history F > send reset ack -----------> recv reset ack (ID=200) > (ID=200 ) > S > -----------> recv seq 105 > (after line delay) > is 105 == 105? Ok. > forward packet for processing > set internal reference to 106 > .... .... > If the the reset-ack is sent encapsulated in multilink headers, and if the multilink code on the decompressor is written properly so that packets are not reordered upon reception, there is no problem here. Delivery of the reset-ack to the CCP code will be delayed until after seq 105 has been received and delivered to the CCP code. The proper solution here is to make sure that reset-requests and reset-acks are *always* sent encapsulated in multilink headers so that their correct ordering relative to the compressed data packets can be preserved. Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 10 19:05:55 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id TAA23343; Mon, 10 Feb 1997 19:05:55 -0500 (EST) Resent-Date: Mon, 10 Feb 1997 19:05:55 -0500 (EST) From: "Wasson, Scott" To: ietf-ppp , tmima Subject: RE: STAC LZS: histories can get out of sync. Date: Mon, 10 Feb 97 19:03:00 PST Message-ID: <32FFE1DC@smtpgate.xyplex.com> Encoding: 162 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"Y8R1t1.0.Ji5.TVx_o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2624 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The problem isn't that CCP needs a compression sequence number field in the Ack message, but rather that the Ack must be processed in the proper (multilink) sequential order. This sounds like the problem since you're not using ML for the resets and acks. Currently, I don't believe CCP specifically outlaws sending resets and acks outside of multilink, but IMHO I think it would be cleaner to outlaw this behavior than it would be to 'fix' CCP to cope with a 'broken' data-link layer. -Scott Wasson, Xyplex ---------- From: tmima To: ietf-ppp Subject: STAC LZS: histories can get out of sync. Date: Monday, February 10, 1997 12:43PM In a multilink environment, the compressor's and decompressor's histories can get out of sync even when sequence numbers are used as a CCP check mode. This is an example similar to the one in rfc1974 (page 9). In this example the algorithm works fine. 2.5.3.3.1 History Synchronization with Sequence Numbers Example Compressing Sender Decompressing Receiver .... .... send seq 101 -----------> recv seq 101 is 101 == 101? Ok. forward packet for processing set internal reference to 102 send seq 102 -----------> recv seq 102 is 102 == 102? Ok. forward packet for processing set internal reference to 103 send seq 103 ------X (packet lost) send seq 104 -----------> recv seq 104 is 104 == 103? Send reset req! silently discard packet set internal reference to 105 <----------- send reset request (ID=200) post-increment the identifier. send seq 105 -----------> recv seq 105 is 105 == 105? Ok. was reset ack received? No! silently discard packet set internal reference to 106 recv reset req <----------- (after line delay) (ID=200) reset compression history send reset ack -----------> recv reset ack (ID=200) (ID=200 ) send seq 106 -----------> recv seq 106 is 106 == 106? Ok. forward packet for processing set internal reference to 107 .... .... A very similar sequence will cause a failure in another setting: We have two machines: compressor (machine C) and decompressor (machine D) They are using multilink, and connected using 2 links. One link is slower (link S), and the other link is F (fast). Packet 103 is lost. Machine C is alternating packets on the links. It sent packet 104 on link F, and then sent packet 105 on link S. When packet 104 arrives it causes a receive failure on D. D is sending CCP Reset Request on link F. C replies with CCP Reset Ack on link F as a CCP protocol, not MP (C is using MP only for data packets). Since link F is fast, and the CCP packets are tiny, the CCP packets were exchanged BEFORE machine D received packet 105. When 105 arrives, D will accept it, and the histories are out of sync. send seq 103 ------X (packet lost) F send seq 104 -----------> recv seq 104 is 104 == 103? Send reset req! silently discard packet set internal reference to 105 S send seq 105 -----------> F recv reset req <----------- send reset request (ID=200) (ID=200) post-increment the identifier. reset compression history F send reset ack -----------> recv reset ack (ID=200) (ID=200 ) S -----------> recv seq 105 (after line delay) is 105 == 105? Ok. forward packet for processing set internal reference to 106 .... .... A suggestion for a fix: In CCP Reset Ack, in addition to the history number also add the sequence # of the packet following the history reset. The decompressor will silently discard packets with lower sequence#. In our case, the CCP Reset Ack will also say sequence# 106. Packet 105 will be discarded. (This can be backward compatible with rfc1974: If the length field of the CCP Reset Ack is 7, there is a seq# following the history#). Thanks, Tmima - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 10 20:12:54 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id UAA24483; Mon, 10 Feb 1997 20:12:54 -0500 (EST) Resent-Date: Mon, 10 Feb 1997 20:12:54 -0500 (EST) Date: Mon, 10 Feb 1997 17:12:12 -0800 (PST) From: Andy Valencia Message-Id: <199702110112.RAA29007@vandys5.cisco.com> To: adoria@gdc.com Cc: ietf-ppp@MERIT.EDU Subject: Re: control for selecting service provider in ppp Newsgroups: cisco.external.ietf.ppp References: X-Newsreader: NN version 6.5.0 #1 (NOV) Resent-Message-ID: <"jsqaW1.0.5-5.FUy_o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2626 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >I am in the process of designing some equipment that hangs at the edge >of the copper loop doing xDSL to multi service provider access. This >design has made me aware of an issue I need to resolve. >What i am looking for is a way to terminate PPP at that point. Before >i can do authentication, however, i need to allow the user to pick a >service provider. Since it is not dialup, i don't have the luxury of >a phone number. What i am looking for is a way to, before >authentication, designate a service provider. I don't think this will >be an application where tunneling will work, so the "Layer Two >Tunneling Protocol" protocol doesn't solve my problem. Well, with my "L2TP" hat on, I guess I have to ask, why must this be *before* authentication? Why not have the subscriber unit set its claimed authentication name based on where it wants to go, and have the boundary accept, parse, and forward the collected data *during* authentication? L2TP defines how to make this happen midstream, after all. If it's, say, CHAP, then the boundary device will forward an authentication which can be either be accepted as definitive authentication (without a CHAP restart) or can use it to see if the unit (delta a replay attack) is legit, but then the termination device can do its own full CHAP sequence. In either case, the unit can change its name from "joe@isp" to "joe@work" based on where you want to connect. The UI for choosing the name is left as an exercise for the reader; I currently am thinking a MAC multicast generated from a PC app might do the trick (and spares you having to define an IP function in the subscriber "xDSL modem"). Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 10 20:12:43 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id UAA24443; Mon, 10 Feb 1997 20:12:43 -0500 (EST) Resent-Date: Mon, 10 Feb 1997 20:12:43 -0500 (EST) From: tmima@mediagate.com Date: Mon, 10 Feb 97 17:07:10 -0800 Subject: RE: STAC LZS: histories can get out of sync. To: "Wasson, Scott" , ietf-ppp X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <32FFE1DC@smtpgate.xyplex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"d4ISR2.0.Zz5.2Uy_o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2625 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Any protocol can be sent over multilink not encapsulated in MP header: the hosts can use the two links by alternating IP packets. Even the packets 104, 105 from the example can be just IP packets. You'll have to change rfc 1990 not to allow non-MP packets over multilink, and this is not desired. The LZS seq# are there to synchronize the hosts. Tmima --- On Mon, 10 Feb 97 19:03:00 PST "Wasson, Scott" wrote: > > The problem isn't that CCP needs a compression sequence > number field in the Ack message, but rather that the Ack must be processed > in the proper (multilink) sequential order. This sounds like the problem > since you're not using ML for the resets and acks. > > Currently, I don't believe CCP specifically outlaws sending resets and acks > outside of multilink, but IMHO I think it would be cleaner to outlaw this > behavior > than it would be to 'fix' CCP to cope with a 'broken' data-link layer. > > -Scott Wasson, Xyplex > ---------- > From: tmima > To: ietf-ppp > Subject: STAC LZS: histories can get out of sync. > Date: Monday, February 10, 1997 12:43PM > > > In a multilink environment, the compressor's and decompressor's histories > can > get out of > sync even when sequence numbers are used as a CCP check mode. > > This is an example similar to the one in rfc1974 (page 9). In this example > the algorithm > works fine. > > > 2.5.3.3.1 History Synchronization with Sequence Numbers Example > > Compressing Sender Decompressing Receiver > .... .... > send seq 101 -----------> recv seq 101 > is 101 == 101? Ok. > forward packet for processing > set internal reference to 102 > > send seq 102 -----------> recv seq 102 > is 102 == 102? Ok. > forward packet for processing > set internal reference to 103 > > send seq 103 ------X (packet lost) > > send seq 104 -----------> recv seq 104 > is 104 == 103? Send reset req! > silently discard packet > set internal reference to 105 > > <----------- send reset request (ID=200) > post-increment the identifier. > > send seq 105 -----------> recv seq 105 > is 105 == 105? Ok. > was reset ack received? No! > silently discard packet > set internal reference to 106 > > recv reset req <----------- > (after line delay) > (ID=200) > > reset compression > history > send reset ack -----------> recv reset ack (ID=200) > (ID=200 ) > > > send seq 106 -----------> recv seq 106 > is 106 == 106? Ok. > forward packet for processing > set internal reference to 107 > .... .... > > > A very similar sequence will cause a failure in another setting: > > We have two machines: compressor (machine C) and decompressor (machine D) > They are using multilink, and connected using 2 links. One link is slower > (link S), and the > other link is F (fast). > > > Packet 103 is lost. > Machine C is alternating packets on the links. It sent packet 104 on link F, > and then sent > packet 105 on link S. > > > When packet 104 arrives it causes a receive failure on D. > > D is sending CCP Reset Request on link F. > > C replies with CCP Reset Ack on link F as a CCP protocol, not MP (C is using > MP only for > data packets). > > Since link F is fast, and the CCP packets are tiny, the CCP packets were > exchanged BEFORE > machine D received packet 105. > > When 105 arrives, D will accept it, and the histories are out of sync. > > > send seq 103 ------X (packet lost) > > F > send seq 104 -----------> recv seq 104 > is 104 == 103? Send reset req! > silently discard packet > set internal reference to 105 > S > send seq 105 -----------> > > F > recv reset req <----------- send reset request (ID=200) > (ID=200) post-increment the identifier. > > reset compression > history F > send reset ack -----------> recv reset ack (ID=200) > (ID=200 ) > S > -----------> recv seq 105 > (after line delay) > is 105 == 105? Ok. > forward packet for processing > set internal reference to 106 > .... .... > > > > > A suggestion for a fix: > > In CCP Reset Ack, in addition to the history number also add the sequence # > of the packet > following the history reset. > The decompressor will silently discard packets with lower sequence#. > > In our case, the CCP Reset Ack will also say sequence# 106. Packet 105 will > be discarded. > > (This can be backward compatible with rfc1974: > If the length field of the CCP Reset Ack is 7, there is a seq# following the > history#). > > > Thanks, > Tmima > > > > > > > > > > > ---------------End of Original Message----------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 10 20:54:26 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id UAA25452; Mon, 10 Feb 1997 20:54:26 -0500 (EST) Resent-Date: Mon, 10 Feb 1997 20:54:26 -0500 (EST) From: tmima@mediagate.com Date: Mon, 10 Feb 97 17:43:43 -0800 Subject: Re: STAC LZS: histories can get out of sync. To: ietf-ppp@MERIT.EDU, Mike Thornburg X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"lkEyz1.0.CD6.A5z_o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2628 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --- On Mon, 10 Feb 1997 17:23:12 -0800 (PST) Mike Thornburg wrote: > > On Mon, 10 Feb 1997 tmima@mediagate.com wrote: > > > > > Any protocol can be sent over multilink not encapsulated in MP header: the hosts can use > > the two links by alternating IP packets. Even the packets 104, 105 from the example can be > > just IP packets. > > You'll have to change rfc 1990 not to allow non-MP packets over multilink, and this is not > > desired. > > The LZS seq# are there to synchronize the hosts. > > Tmima > > > > > > > > OK, then just change the RFC 1962 (CCP) to forbid sending compressed data > packets, CCP Reset-Requests, and CCP Reset-Acks over a multilink bundle > without encapsulating them in multilink headers so that they may be > ordered properly. Many compression protocols also depend on having the > compressed data delivered in the correct order. In STAC LZS if the > compressed data is delivered out of order the protocol does not permit you > to try to reorder the packets according to sequence number. Instead, you > are required to send reset-requests. If you are using CRC or LCB check > mode, you have *no* sequence number available to reorder them with. > > Allowing anything else exposes CCP to all sorts of reordering problems > when run over multilink. > > Even if it is technically allowed right now by the RFCs to send these > packets without encapsulating them in multilink headers, it is a > profoundly bad idea. It should not be done by any robust implementation > and the RFCs should be amended to forbid this practice. > > Mike > -------------- > Mike Thornburg frigate networks 415.903.2266 > mthorn@frigate.com http://www.frigate.com/ > > > I guess a fix is required for rfc 1974 either way. Tmima - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 10 20:54:17 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id UAA25415; Mon, 10 Feb 1997 20:54:17 -0500 (EST) Resent-Date: Mon, 10 Feb 1997 20:54:17 -0500 (EST) From: "Wasson, Scott" To: ietf-ppp , "Wasson, Scott" , tmima Subject: RE: STAC LZS: histories can get out of sync. Date: Mon, 10 Feb 97 20:53:00 PST Message-ID: <32FFFB48@smtpgate.xyplex.com> Encoding: 42 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"0kRgR1.0.eC6._4z_o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2627 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU No, 1990 would not need to prohibit non-multilink traffic. Just non- compression related multilink traffic. It's perfectly OK to send across non-compression related, non-multilink packets. But since the acks are compression related, they must be sent through multlink. -Scott ---------- From: tmima To: Wasson, Scott; ietf-ppp Subject: RE: STAC LZS: histories can get out of sync. Date: Monday, February 10, 1997 5:07PM Any protocol can be sent over multilink not encapsulated in MP header: the hosts can use the two links by alternating IP packets. Even the packets 104, 105 from the example can be just IP packets. You'll have to change rfc 1990 not to allow non-MP packets over multilink, and this is not desired. The LZS seq# are there to synchronize the hosts. Tmima --- On Mon, 10 Feb 97 19:03:00 PST "Wasson, Scott" wrote: > > The problem isn't that CCP needs a compression sequence > number field in the Ack message, but rather that the Ack must be processed > in the proper (multilink) sequential order. This sounds like the problem > since you're not using ML for the resets and acks. > > Currently, I don't believe CCP specifically outlaws sending resets and acks > outside of multilink, but IMHO I think it would be cleaner to outlaw this > behavior > than it would be to 'fix' CCP to cope with a 'broken' data-link layer. > > -Scott Wasson, Xyplex - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 10 22:28:28 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id WAA26751; Mon, 10 Feb 1997 22:28:28 -0500 (EST) Resent-Date: Mon, 10 Feb 1997 22:28:28 -0500 (EST) Date: Mon, 10 Feb 1997 20:28:00 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702110328.UAA14077@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: STAC LZS: histories can get out of sync Resent-Message-ID: <"TXBTi1.0.WX6.JT-_o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2629 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I guess a fix is required for rfc 1974 either way. Instead, why not read RFC 1962, especially section 2.1 where it talks about sending compressed packets either above or below muiltilink? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 11 02:09:02 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id CAA28765; Tue, 11 Feb 1997 02:09:02 -0500 (EST) Resent-Date: Tue, 11 Feb 1997 02:09:02 -0500 (EST) From: Archie Cobbs Message-Id: <199702110707.XAA09175@bubba.whistle.com> Subject: Re: control for selecting service provider in ppp In-Reply-To: <199702110112.RAA29007@vandys5.cisco.com> from Andy Valencia at "Feb 10, 97 05:12:12 pm" To: vandys@cisco.com (Andy Valencia) Date: Mon, 10 Feb 1997 23:07:58 -0800 (PST) Cc: adoria@gdc.com, ietf-ppp@MERIT.EDU X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"yRlCd3.0.517.7i10p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2630 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > >I am in the process of designing some equipment that hangs at the edge > >of the copper loop doing xDSL to multi service provider access. This > >design has made me aware of an issue I need to resolve. > >What i am looking for is a way to terminate PPP at that point. Before > >i can do authentication, however, i need to allow the user to pick a > >service provider. Since it is not dialup, i don't have the luxury of > >a phone number. What i am looking for is a way to, before > >authentication, designate a service provider. I don't think this will > >be an application where tunneling will work, so the "Layer Two > >Tunneling Protocol" protocol doesn't solve my problem. > > Well, with my "L2TP" hat on, I guess I have to ask, why must this be > *before* authentication? Why not have the subscriber unit set its claimed > authentication name based on where it wants to go, and have the boundary > accept, parse, and forward the collected data *during* authentication? > L2TP defines how to make this happen midstream, after all. This would work, but it also seems (IMHO) that a sufficiently general mechanism like the one described would facilitate this and who knows what other similar future extensions... I can imagine this could ultimately be used for many different purposes, e.g., choosing a remote server via IP address (analogous to L2TP) in situations where the primary ("forwarding") server doesn't necessarily have an a priori association established with every potential remote server (ie., the primary server doesn't necessarily know how to decode the login string). This is a lukewarm argument I guess.. interesting idea in any case. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 11 07:57:11 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id HAA01058; Tue, 11 Feb 1997 07:57:11 -0500 (EST) Resent-Date: Tue, 11 Feb 1997 07:57:11 -0500 (EST) Mime-Version: 1.0 Date: Tue, 11 Feb 1997 12:48:00 +0000 Message-ID: <3006c440@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Compressible and Encryptable protocols To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"uhrJB3.0.6G._n60p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2631 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU There seems to be general agreement that only protocols in the range 0000-3FFF should be compressed, although this is only stated explicitly in RFC 1977 (BSD) and RFC 1979 (Deflate). I can't find any equivalent rule for Encryption. Should the same rule apply, or should NCPs be encrypted as well ? (This question is related to the recent thread about Stac histories - if both compressing and encrypting, the receiver needs to make sure that unencrypted CCP Reset-Requests and Reset-Acks don't overtake anything in the queue to the decryptor. It would be nice if RFC 1962 stated explicitly that the order of Resets needs to be preserved with respect to the compressed data.) --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 11 08:41:17 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id IAA02221; Tue, 11 Feb 1997 08:41:17 -0500 (EST) Resent-Date: Tue, 11 Feb 1997 08:41:17 -0500 (EST) Date: Tue, 11 Feb 1997 08:44:10 -0500 From: Patrick Klos Message-Id: <199702111344.IAA17448@linux.klos.com> To: ietf-ppp@MERIT.EDU, Jonathan.Goodchild@rdl.co.uk Subject: Re: Compressible and Encryptable protocols Resent-Message-ID: <"va1cW3.0.HX.qR70p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2632 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >There seems to be general agreement that only protocols in the range >0000-3FFF should be compressed, although this is only stated explicitly in >RFC 1977 (BSD) and RFC 1979 (Deflate). > >I can't find any equivalent rule for Encryption. Should the same rule >apply, or should NCPs be encrypted as well ? My initial take on encryption of NCP is this: I think you may want to encrypt some (or all) NCP packets just as you encrypt data packets. The reason for encryption is different than the reason for compression. We encrypt packets to add a level of security to the link. Some of that security could be diminished if certain aspects of an NCPs negotiations we "left out in the open". At the least, an implementation SHOULD be allowed to encrypt NCP packets (i.e. it shouldn't be explicitly disallowed). ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://web.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 11 11:40:01 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA06043; Tue, 11 Feb 1997 11:40:01 -0500 (EST) Resent-Date: Tue, 11 Feb 1997 11:40:01 -0500 (EST) Date: Tue, 11 Feb 1997 09:39:37 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702111639.JAA15351@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: Compressible and Encryptable protocols Resent-Message-ID: <"pMfLz.0.xT1.N3A0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2633 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > (This question is related to the recent thread about Stac histories - if > both compressing and encrypting, the receiver needs to make sure that > unencrypted CCP Reset-Requests and Reset-Acks don't overtake anything in > the queue to the decryptor. It would be nice if RFC 1962 stated explicitly > that the order of Resets needs to be preserved with respect to the > compressed data.) I think that would cross the line between making things clear and stating the obvious and making the document more confusing. It is impossible to state everything explicitly without producing a document that is useless for communicating what is going on. See Russell & Whitehead's Principia for a definite proof by example. I doubt anyone who fails to understand implicitly that compressed or encrypted packets with inter-packet history must be kept ordered, and that the same applies to any signals that reset or otherwise change that history is not going to be helped by a statement of the obvious. It would be good to make have such statements of the obvious in a textbook about PPP, along with other background information. An RFC should not be an introductory textbook. ] >I can't find any equivalent rule for Encryption. Should the same rule ] >apply, or should NCPs be encrypted as well ? ] ] My initial take on encryption of NCP is this: I think you may want to ] encrypt some (or all) NCP packets just as you encrypt data packets. I agree. A major reason those compression protocols omit protocols 0000-3fff is that those protocols are likely to be so infrequent that they would not be effectively compressed, and adding them would reduce the compression of the main data by perturbing the compression histories. ] ... Some of that ] security could be diminished if certain aspects of an NCPs negotiations ] we "left out in the open". At the least, an implementation SHOULD be ] allowed to encrypt NCP packets (i.e. it shouldn't be explicitly disallowed). That idea argues for a stronger statement, that some of those packets not merely "MAY" but "SHOULD" or "MUST" be encrypted. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 11 17:12:39 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id RAA12317; Tue, 11 Feb 1997 17:12:39 -0500 (EST) Resent-Date: Tue, 11 Feb 1997 17:12:39 -0500 (EST) From: "Wasson, Scott" To: ietf-ppp , vjs Subject: re: Compressible and Encryptable protocols Date: Tue, 11 Feb 97 17:12:00 PST Message-ID: <330118AE@smtpgate.xyplex.com> Encoding: 23 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"9ytMF.0.103.8xE0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2634 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I think that would cross the line between making things clear and > stating the obvious and making the document more confusing. It is > impossible to state everything explicitly without producing a document > that is useless for communicating what is going on. ... > ... It would be good to make have such statements of the obvious in a > textbook about PPP, along with other background information. An RFC > should not be an introductory textbook. You're right. Adding any explanations to the RFC's that make the point that the author(s) and WG are trying to make clearer would be a mistake. The reader MUST be sufficiently clairvoyant in order to properly interpret the specifications. Making the specifications adequately devoid of underlying meaning serves to filter out bad programmers, who would have just produced non-interoperable software anyway. ;-) -Scott Wasson >Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 11 18:02:36 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id SAA13245; Tue, 11 Feb 1997 18:02:36 -0500 (EST) Resent-Date: Tue, 11 Feb 1997 18:02:36 -0500 (EST) Message-Id: <2.2.32.19970211230226.00323e20@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Feb 1997 15:02:26 -0800 To: From: "Eric L. Michelsen" Subject: RE: STAC LZS: histories can get out of sync. Resent-Message-ID: <"pHZe93.0.XE3.4gF0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2635 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU All this relates back to whether PPP delivers packets in-order or not. Many error recovery processes were (tacitly) designed such that they REQUIRE in-order delivery to work. I'll bet dollars to doughnuts there are other error-recovery procedures in other NCPs that have similar problems, since out-of-order delivery was not a consideration in their design. I think the answer is NOT to band-aid every single NCP with warning labels and prohibitions. If anything, (along the lines of discussion about MP a few weeks ago), MP should include a warning that all "related" packets streams SHOULD be delivered in order. And that means senders must not switch between MP and non-MP encapsulations (for "related" data). If you do, you're violating a basic assumption (tacitly made) in the design of those protocols. Doesn't L2TP, when used without payload sequencing, have the potential to deliver payload packets out of order (since it may run over IP)? If so, the same synchronization error may occur under those conditions with L2TP. At 08:53 PM 2/10/97 PST, Wasson, Scott wrote: > >No, 1990 would not need to prohibit non-multilink traffic. Just non- >compression related multilink traffic. It's perfectly OK to send across >non-compression related, non-multilink packets. But since the acks >are compression related, they must be sent through multlink. > > -Scott > ---------- >From: tmima >To: Wasson, Scott; ietf-ppp >Subject: RE: STAC LZS: histories can get out of sync. >Date: Monday, February 10, 1997 5:07PM > > > >Any protocol can be sent over multilink not encapsulated in MP header: the >hosts can use >the two links by alternating IP packets. Even the packets 104, 105 from the >example can be >just IP packets. >You'll have to change rfc 1990 not to allow non-MP packets over multilink, >and this is not >desired. >The LZS seq# are there to synchronize the hosts. >Tmima > > > --- On Mon, 10 Feb 97 19:03:00 PST "Wasson, Scott" >wrote: >> >> The problem isn't that CCP needs a compression sequence >> number field in the Ack message, but rather that the Ack must be processed >> in the proper (multilink) sequential order. This sounds like the problem >> since you're not using ML for the resets and acks. >> >> Currently, I don't believe CCP specifically outlaws sending resets and >acks >> outside of multilink, but IMHO I think it would be cleaner to outlaw this >> behavior >> than it would be to 'fix' CCP to cope with a 'broken' data-link layer. >> >> -Scott Wasson, Xyplex > > > > -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 11 18:39:47 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id SAA14068; Tue, 11 Feb 1997 18:39:47 -0500 (EST) Resent-Date: Tue, 11 Feb 1997 18:39:47 -0500 (EST) From: tmima@mediagate.com Date: Tue, 11 Feb 97 15:20:52 -0800 Subject: RE: STAC LZS: histories can get out of sync. To: ietf-ppp@MERIT.EDU X-Mailer: Chameleon ATX 6.0.1, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <2.2.32.19970211230226.00323e20@coppermountain.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"dVvdw3.0.SR3.zCG0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2636 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU You'll get the same fault if you send all compressed and resets as non-MP: it's not the switching that causes the fault. If you don't want to enhance the reset ack packet, you must force all compression-related packets including the resets to be MP encapsulated over multilink. This is taken from rfc1974 section 3.4: The Stac LZS protocol provides a means to detect these error conditions: LCB or CRC for erroneous datagrams, and sequence number for dropped or mis-ordered datagrams. And this is not correct: mis-ordered packets can break the synchronization. Tmima --- On Tue, 11 Feb 1997 15:02:26 -0800 "Eric L. Michelsen" wrote: > All this relates back to whether PPP delivers packets in-order or not. Many > error recovery processes were (tacitly) designed such that they REQUIRE > in-order delivery to work. I'll bet dollars to doughnuts there are other > error-recovery procedures in other NCPs that have similar problems, since > out-of-order delivery was not a consideration in their design. > > I think the answer is NOT to band-aid every single NCP with warning labels > and prohibitions. If anything, (along the lines of discussion about MP a > few weeks ago), MP should include a warning that all "related" packets > streams SHOULD be delivered in order. And that means senders must not > switch between MP and non-MP encapsulations (for "related" data). If you > do, you're violating a basic assumption (tacitly made) in the design of > those protocols. > > Doesn't L2TP, when used without payload sequencing, have the potential to > deliver payload packets out of order (since it may run over IP)? If so, the > same synchronization error may occur under those conditions with L2TP. > > At 08:53 PM 2/10/97 PST, Wasson, Scott wrote: > > > >No, 1990 would not need to prohibit non-multilink traffic. Just non- > >compression related multilink traffic. It's perfectly OK to send across > >non-compression related, non-multilink packets. But since the acks > >are compression related, they must be sent through multlink. > > > > -Scott > > ---------- > >From: tmima > >To: Wasson, Scott; ietf-ppp > >Subject: RE: STAC LZS: histories can get out of sync. > >Date: Monday, February 10, 1997 5:07PM > > > > > > > >Any protocol can be sent over multilink not encapsulated in MP header: the > >hosts can use > >the two links by alternating IP packets. Even the packets 104, 105 from the > >example can be > >just IP packets. > >You'll have to change rfc 1990 not to allow non-MP packets over multilink, > >and this is not > >desired. > >The LZS seq# are there to synchronize the hosts. > >Tmima > > > > > > --- On Mon, 10 Feb 97 19:03:00 PST "Wasson, Scott" > >wrote: > >> > >> The problem isn't that CCP needs a compression sequence > >> number field in the Ack message, but rather that the Ack must be processed > >> in the proper (multilink) sequential order. This sounds like the problem > >> since you're not using ML for the resets and acks. > >> > >> Currently, I don't believe CCP specifically outlaws sending resets and > >acks > >> outside of multilink, but IMHO I think it would be cleaner to outlaw this > >> behavior > >> than it would be to 'fix' CCP to cope with a 'broken' data-link layer. > >> > >> -Scott Wasson, Xyplex > > > > > > > > > -- > Eric L. Michelsen, Copper Mountain Networks, Inc. > ---------------End of Original Message----------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 11 19:01:05 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id TAA14461; Tue, 11 Feb 1997 19:01:05 -0500 (EST) Resent-Date: Tue, 11 Feb 1997 19:01:05 -0500 (EST) Message-Id: <2.2.32.19970212000049.0035989c@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Feb 1997 16:00:49 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: RE: STAC LZS: histories can get out of sync. Resent-Message-ID: <"z2DgA2.0.bX3.wWG0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2637 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 03:20 PM 2/11/97 -0800, tmima@mediagate.com wrote: > >You'll get the same fault if you send all compressed and resets as non-MP: it's not the >switching that causes the fault. If you mean sending the packets without MP, but over multiple links, then certainly you'll run into trouble. So far as I know, you can rarely expect reasonable results if you use multiple links without using MP. >If you don't want to enhance the reset ack packet, you must force all compression-related >packets including the resets to be MP encapsulated over multilink. > >This is taken from rfc1974 section 3.4: > >The Stac LZS protocol provides a means to detect these error > conditions: LCB or CRC for erroneous datagrams, and sequence number > for dropped or mis-ordered datagrams. > >And this is not correct: mis-ordered packets can break the synchronization. Agreed. That statement is not correct. >Tmima > >--- On Tue, 11 Feb 1997 15:02:26 -0800 "Eric L. Michelsen" >wrote: >> All this relates back to whether PPP delivers packets in-order or not. Many >> error recovery processes were (tacitly) designed such that they REQUIRE >> in-order delivery to work. I'll bet dollars to doughnuts there are other >> error-recovery procedures in other NCPs that have similar problems, since >> out-of-order delivery was not a consideration in their design. >> >> I think the answer is NOT to band-aid every single NCP with warning labels >> and prohibitions. If anything, (along the lines of discussion about MP a >> few weeks ago), MP should include a warning that all "related" packets >> streams SHOULD be delivered in order. And that means senders must not >> switch between MP and non-MP encapsulations (for "related" data). If you >> do, you're violating a basic assumption (tacitly made) in the design of >> those protocols. >> >> Doesn't L2TP, when used without payload sequencing, have the potential to >> deliver payload packets out of order (since it may run over IP)? If so, the >> same synchronization error may occur under those conditions with L2TP. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 05:34:43 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id FAA20032; Wed, 12 Feb 1997 05:34:43 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 05:34:43 -0500 (EST) Mime-Version: 1.0 Date: Wed, 12 Feb 1997 09:52:15 +0000 Message-ID: <3019c730@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Compressible and Encryptable protocols To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"uyueG1.0.au4.ZoP0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2638 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Patrick Klos writes: >My initial take on encryption of NCP is this: I think you may want to >encrypt some (or all) NCP packets just as you encrypt data packets. >The reason for encryption is different than the reason for compression. >We encrypt packets to add a level of security to the link. Some of >that security could be diminished if certain aspects of an NCPs >negotiations we "left out in the open". At the least, an >implementation SHOULD be allowed to encrypt NCP packets (i.e. it >shouldn't be explicitly disallowed). and Vernon Schryver writes: ]That idea argues for a stronger statement, that some of those packets ]not merely "MAY" but "SHOULD" or "MUST" be encrypted. Yes, that was my view. Clearly the rules are: 1) An implementation MAY encrypt any protocol (once ECP is open), with the exception of LCP negotiations (i.e Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request and Terminate-Ack) 2) An implementation MUST be prepared to receive any decrypted protocol ID (exception: for LCP the same rules apply as per LCP on a multilink bundle - RFC 1990 section 2). In terms of a stronger statement, which of: 1a) An implementation SHOULD encrypt protocols in the range 0000-7FFF or 1b) An implementation SHOULD encrypt protocols in the range 0000-BFFF is preferable ? I was also wondering about: 1c) If an implementation encrypts compressed data then it MUST also encrypt CCP packets. but maybe this is overkill as the receiver should be able to preserve the order of the CCP packets with respect to the decrypted data. --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 11:41:14 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA25023; Wed, 12 Feb 1997 11:41:14 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 11:41:14 -0500 (EST) Message-Id: <2.2.32.19970212164110.002ebd1c@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Feb 1997 08:41:10 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: Re: Compressible and Encryptable protocols Resent-Message-ID: <"xMQIT.0.Z66.UAV0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2639 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I think we should clarify the intent here. I'm not sure if the recommendation is to encrypt because some people think that's a good security practice, or if there is some interoperability issue. I see 2 possibilities, though: Possibility 1. The standard tells people to encrypt certain things, because we think it's a good idea for security. If this is the reason, I would say that "what to encrypt" is a policy decision that should be left to the implementor, and need not be standardized. Possibility 2. The standard tells people to encrypt certain things because it improves interoperability. And here, I can see 2 subcases: (2a) it improves interoperability because it helps preserve packet order in implementations where encryption/decryption may use a separate data path from non-encrypted data; or (2b) it improves interoperability because some implementations' policy is to refuse to communicate with devices that don't encrypt everything. But I think it's important to distinguish "advice" to implementors about what constitutes good security practices, from recommendations that improve interoperability under certain non-obvious conditions. At 09:52 AM 2/12/97 +0000, Jonathan Goodchild wrote: >Patrick Klos writes: >>My initial take on encryption of NCP is this: I think you may want to >>encrypt some (or all) NCP packets just as you encrypt data packets. >>The reason for encryption is different than the reason for compression. >>We encrypt packets to add a level of security to the link. Some of >>that security could be diminished if certain aspects of an NCPs >>negotiations we "left out in the open". At the least, an >>implementation SHOULD be allowed to encrypt NCP packets (i.e. it >>shouldn't be explicitly disallowed). > >and Vernon Schryver writes: >]That idea argues for a stronger statement, that some of those packets >]not merely "MAY" but "SHOULD" or "MUST" be encrypted. > >Yes, that was my view. Clearly the rules are: > > 1) An implementation MAY encrypt any protocol (once ECP is open), > with the exception of LCP negotiations (i.e Configure-Request, > Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request > and Terminate-Ack) > > 2) An implementation MUST be prepared to receive any decrypted > protocol ID (exception: for LCP the same rules apply as per > LCP on a multilink bundle - RFC 1990 section 2). > >In terms of a stronger statement, which of: > > 1a) An implementation SHOULD encrypt protocols in the range 0000-7FFF >or > 1b) An implementation SHOULD encrypt protocols in the range 0000-BFFF > >is preferable ? I was also wondering about: > > 1c) If an implementation encrypts compressed data then it MUST also > encrypt CCP packets. > >but maybe this is overkill as the receiver should be able to preserve the order >of the CCP packets with respect to the decrypted data. > >--- >Jonathan.Goodchild@rdl.co.uk > > > > > > -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 11:53:41 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA25404; Wed, 12 Feb 1997 11:53:41 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 11:53:41 -0500 (EST) Message-Id: <97Feb12.115106est.29569-2@janus.border.com> To: "Eric L. Michelsen" cc: ietf-ppp@MERIT.EDU Subject: Re: Compressible and Encryptable protocols References: <2.2.32.19970212164110.002ebd1c@coppermountain.com> In-reply-to: Your message of "Wed, 12 Feb 1997 11:41:10 -0500". <2.2.32.19970212164110.002ebd1c@coppermountain.com> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 813 2054 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Wed, 12 Feb 1997 11:53:15 -0500 Sender: chk@border.com Resent-Message-ID: <"JxKWL.0.aC6.EMV0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2640 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In message <2.2.32.19970212164110.002ebd1c@coppermountain.com>, "Eric L. Michelsen" writes: > > Possibility 1. The standard tells people to encrypt certain things, because > we think it's a good idea for security. If this is the reason, I would say > that "what to encrypt" is a policy decision that should be left to the > implementor, and need not be standardized. Disagree. Security is *hard*. Most implementors get it wrong (just ask Netscape about their first few SSL implementations). It is important to standardise and mandate the security related aspects of a protocol. -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 100 University Ave., 7th Floor, Toronto ON M5J 1V6 +1 416 813 2054 (voice) | "Madness takes its toll. Please have exact change." +1 416 813 2001 (fax) | -Karen Murphy - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 13:25:55 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id NAA27503; Wed, 12 Feb 1997 13:25:55 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 13:25:55 -0500 (EST) Date: Wed, 12 Feb 1997 10:31:19 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: Jonathan Goodchild Cc: ietf-ppp@MERIT.EDU Subject: Re: Compressible and Encryptable protocols In-Reply-To: <3019c730@rdl.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ATPDb.0.Nj6.jiW0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2641 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Encrypting the NCP protocols is not obvious is your read RFC1669/RFC1969 for DES Link Level Encryption. I think it is a good idea, but this needs to be clearly stated in the appropriate RFCs. Philip Rakity FlowPoint On Wed, 12 Feb 1997, Jonathan Goodchild wrote: > Patrick Klos writes: > >My initial take on encryption of NCP is this: I think you may want to > >encrypt some (or all) NCP packets just as you encrypt data packets. > >The reason for encryption is different than the reason for compression. > >We encrypt packets to add a level of security to the link. Some of > >that security could be diminished if certain aspects of an NCPs > >negotiations we "left out in the open". At the least, an > >implementation SHOULD be allowed to encrypt NCP packets (i.e. it > >shouldn't be explicitly disallowed). > > and Vernon Schryver writes: > ]That idea argues for a stronger statement, that some of those packets > ]not merely "MAY" but "SHOULD" or "MUST" be encrypted. > > Yes, that was my view. Clearly the rules are: > > 1) An implementation MAY encrypt any protocol (once ECP is open), > with the exception of LCP negotiations (i.e Configure-Request, > Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request > and Terminate-Ack) > > 2) An implementation MUST be prepared to receive any decrypted > protocol ID (exception: for LCP the same rules apply as per > LCP on a multilink bundle - RFC 1990 section 2). > > In terms of a stronger statement, which of: > > 1a) An implementation SHOULD encrypt protocols in the range 0000-7FFF > or > 1b) An implementation SHOULD encrypt protocols in the range 0000-BFFF > > is preferable ? I was also wondering about: > > 1c) If an implementation encrypts compressed data then it MUST also > encrypt CCP packets. > > but maybe this is overkill as the receiver should be able to preserve the order > of the CCP packets with respect to the decrypted data. > > --- > Jonathan.Goodchild@rdl.co.uk > > > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 14:28:30 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA29204; Wed, 12 Feb 1997 14:28:30 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 14:28:30 -0500 (EST) Date: Wed, 12 Feb 1997 14:25:05 -0500 (EST) From: Connie Leblanc To: Philip Rakity Cc: Jonathan Goodchild , ietf-ppp@MERIT.EDU Subject: Re: Compressible and Encryptable protocols In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"jRU-Y3.0.-77.JdX0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2642 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Does this not cause a problem for the TA's. An issue was brought up at the last CIUG workshop that if the NCP's were compressed, the TA's could not check them to see if it must do something with them (example BACP and BAP). The same will be for encryption. Connie On Wed, 12 Feb 1997, Philip Rakity wrote: > Encrypting the NCP protocols is not obvious is your read RFC1669/RFC1969 > for DES Link Level Encryption. I think it is a good idea, but this needs > to be clearly stated in the appropriate RFCs. > > Philip Rakity > FlowPoint > > On Wed, 12 Feb 1997, Jonathan Goodchild wrote: > > > Patrick Klos writes: > > >My initial take on encryption of NCP is this: I think you may want to > > >encrypt some (or all) NCP packets just as you encrypt data packets. > > >The reason for encryption is different than the reason for compression. > > >We encrypt packets to add a level of security to the link. Some of > > >that security could be diminished if certain aspects of an NCPs > > >negotiations we "left out in the open". At the least, an > > >implementation SHOULD be allowed to encrypt NCP packets (i.e. it > > >shouldn't be explicitly disallowed). > > > > and Vernon Schryver writes: > > ]That idea argues for a stronger statement, that some of those packets > > ]not merely "MAY" but "SHOULD" or "MUST" be encrypted. > > > > Yes, that was my view. Clearly the rules are: > > > > 1) An implementation MAY encrypt any protocol (once ECP is open), > > with the exception of LCP negotiations (i.e Configure-Request, > > Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request > > and Terminate-Ack) > > > > 2) An implementation MUST be prepared to receive any decrypted > > protocol ID (exception: for LCP the same rules apply as per > > LCP on a multilink bundle - RFC 1990 section 2). > > > > In terms of a stronger statement, which of: > > > > 1a) An implementation SHOULD encrypt protocols in the range 0000-7FFF > > or > > 1b) An implementation SHOULD encrypt protocols in the range 0000-BFFF > > > > is preferable ? I was also wondering about: > > > > 1c) If an implementation encrypts compressed data then it MUST also > > encrypt CCP packets. > > > > but maybe this is overkill as the receiver should be able to preserve the order > > of the CCP packets with respect to the decrypted data. > > > > --- > > Jonathan.Goodchild@rdl.co.uk > > > > > > > > > > > > Connie Leblanc cleblanc@gandalf.ca Software Designer (613)274-6500 ex. 8019 Gandalf Technologies Inc. "Opinions expressed by me are not Nepean, Ontario K2E 7M4 necessarily those of a sane person or of Gandalf's." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 14:56:38 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA00157; Wed, 12 Feb 1997 14:56:38 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 14:56:38 -0500 (EST) Date: Wed, 12 Feb 1997 12:55:04 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702121955.MAA19225@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Compressible and Encryptable protocols Resent-Message-ID: <"G6bDM1.0.82.n1Y0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2643 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Connie Leblanc > Does this not cause a problem for the TA's. An issue was brought up at the > last CIUG workshop that if the NCP's were compressed, the TA's could not > check them to see if it must do something with them (example BACP and > BAP). The same will be for encryption. That's a compelling argument in favor of requiring encryption of NCP's. What is the difference between an oh-so-smart ISDN TA fiddling with a PPP system's packets without the knowledge of the PPP system for good reasons and a bad guy improving the same packets but for bad reasons? I don't see how BACP or BAP are themselves relevant, even if you disagree with me and think BACP or BAP have a future. However, familar demand dialing, dynamic bandwidth TA's without BACP or BAP such as Motorola's might have problems snarfing PAP passwords to replay when creating second channels (i.e. commit a "replay-attack" with the permission if not the knowledge of the real authenticatee) if everything were encrypted. By the way, has Motorola fixed or said how it is going to fix their problem with CHAP and second channels on the Bitsurfer? The only good solution I see is to let the TA in on the secret and let it make up its own CHAP responses. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 15:25:06 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id PAA01055; Wed, 12 Feb 1997 15:25:06 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 15:25:06 -0500 (EST) Message-Id: <9702122022.AA00857@adtrn-ws01.adtran.com> From: "Kyle Farnsworth" To: Subject: Re: Compressible and Encryptable protocols Date: Wed, 12 Feb 1997 14:26:26 -0600 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Z7Kza3.0.3G.PSY0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2644 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: Vernon Schryver > By the way, has Motorola fixed or said how it is going to fix their > problem with CHAP and second channels on the Bitsurfer? The only good > solution I see is to let the TA in on the secret and let it make up its > own CHAP responses. > Motorola is going to pass the secret to the TA via AT-like command. That is the 'only good solution' if want your secret going across the serial line whenever you dial. The best solution is for Microsoft to fix the problem. The Adtran TA's will jump in the middle of the negotiation and Nak down to PAP when dialing with Win95. Kyle - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 15:32:15 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id PAA01380; Wed, 12 Feb 1997 15:32:15 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 15:32:15 -0500 (EST) From: sullivan@gandalf.ca (Chris Sullivan) Message-Id: <9702122030.AA22002@hobbit.gandalf.ca> Subject: Re: Compressible and Encryptable protocols To: vjs@mica.denver.sgi.com (Vernon Schryver) Date: Wed, 12 Feb 1997 15:30:09 -0500 (EST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199702121955.MAA19225@mica.denver.sgi.com> from "Vernon Schryver" at Feb 12, 97 12:55:04 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"s_u7d1.0.FL.9ZY0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2645 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Does this not cause a problem for the TA's. An issue was brought up at the > > last CIUG workshop that if the NCP's were compressed, the TA's could not > > check them to see if it must do something with them (example BACP and > > BAP). The same will be for encryption. > > That's a compelling argument in favor of requiring encryption of > NCP's. What is the difference between an oh-so-smart ISDN TA fiddling > with a PPP system's packets without the knowledge of the PPP system for > good reasons and a bad guy improving the same packets but for bad > reasons? > > I don't see how BACP or BAP are themselves relevant, even if you > disagree with me and think BACP or BAP have a future. However, familar > demand dialing, dynamic bandwidth TA's without BACP or BAP such as > Motorola's might have problems snarfing PAP passwords to replay when > creating second channels (i.e. commit a "replay-attack" with the > permission if not the knowledge of the real authenticatee) if everything > were encrypted. > > By the way, has Motorola fixed or said how it is going to fix their > problem with CHAP and second channels on the Bitsurfer? The only good > solution I see is to let the TA in on the secret and let it make up its > own CHAP responses. The change to the protocol numbers of BAP and BACP was to make sure they are always sent in the clear (uncompressed) and TAs could sniff them. The same reasoning holds true for encryption, and the protocol numbers should have the same effect. PAP and CHAP packets should remain unencrypted for the same reasons and by the same mechanism. -- Chris Sullivan Gandalf Data Limited sullivan@gandalf.ca does not necessarily share my opinions, including this one - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 15:55:18 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id PAA02763; Wed, 12 Feb 1997 15:55:18 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 15:55:18 -0500 (EST) Date: Wed, 12 Feb 1997 13:53:39 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702122053.NAA19396@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Compressible and Encryptable protocols Resent-Message-ID: <"731gy1.0.lg.juY0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2646 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: sullivan@gandalf.ca (Chris Sullivan) > To: vjs (Vernon Schryver) > Cc: ietf-ppp@MERIT.EDU > ... > The change to the protocol numbers of BAP and BACP was to make sure they > are always sent in the clear (uncompressed) and TAs could sniff them. The > same reasoning holds true for encryption, and the protocol numbers should > have the same effect. > > PAP and CHAP packets should remain unencrypted for the same reasons and > by the same mechanism. Not so. Maybe leaving authenication packets uncompressed and unencrypted helps BAP and BACP, but it does absolutely nothing for CHAP. A TA can do nothing useful by sniffing CHAP packets, because you cannot replay a CHAP packet. Unless the TA knows the secret, the TA cannot create CHAP responses. If the TA knows the secret, the TA need not sniff CHAP packets. There is little that might be gained by encrypting CHAP packets; even the username is of little use. Running PAP unencrypted when you might encrypt it just so that TAs can sniff PAP would be strange. You don't throw away security lightly. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 16:10:25 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id QAA03401; Wed, 12 Feb 1997 16:10:25 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 16:10:25 -0500 (EST) Date: Wed, 12 Feb 1997 14:08:52 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702122108.OAA19473@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Compressible and Encryptable protocols Resent-Message-ID: <"wkkBv2.0.qq.x6Z0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2647 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Kyle Farnsworth" > > By the way, has Motorola fixed or said how it is going to fix their > > problem with CHAP and second channels on the Bitsurfer? The only good > > solution I see is to let the TA in on the secret and let it make up its > > own CHAP responses. > > > Motorola is going to pass the secret to the TA via AT-like command. That > is the 'only good solution' if want your secret going across the serial > line whenever you dial. The best solution is for Microsoft to fix the > problem. The Adtran TA's will jump in the middle of the negotiation and > Nak down to PAP when dialing with Win95. I do not understand any of that. Exactly what could Microsoft or any vendor to affect the problem? Either the TA has the CHAP secret or it does not. If the TA has the secret, then it can answer CHAP challenges and all is fine. If the TA does not have the secret, then the TA can't play. If the TA has the secret, it is either told as much at the start of each session with AT commands or equivalent, or it keeps the secret in its own memory. Exactly what is so terrible about sending the secret accross a couple feet of RS-232 wires between the modem and the computer at the start of every session? If you have reason to worry that your RS-232 cables are bugged, you have far bigger problems than anything that might be addressed by PAP, CHAP, or anything else in PPP. TA's that try to Nak down to PAP sound broken as well as unworkable. If one or the other host wants to be authenticator with CHAP, how can the TA force PAP? Such an authenicator is not going to settle for PAP any more than it is going to settle for a CHAP response with the wrong hash value. If it were possible to force PAP, there would be a catastrophic security hole in PPP. A bad guy could use the "tell me your PAP password" attack. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 16:40:44 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id QAA04491; Wed, 12 Feb 1997 16:40:44 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 16:40:44 -0500 (EST) Message-Id: <9702122137.AA02590@adtrn-ws01.adtran.com> From: "Kyle Farnsworth" To: "Vernon Schryver" , Subject: Re: Compressible and Encryptable protocols Date: Wed, 12 Feb 1997 15:41:57 -0600 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"tdfkc2.0.l51.MZZ0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2648 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: Vernon Schryver > > From: "Kyle Farnsworth" > > > > By the way, has Motorola fixed or said how it is going to fix their > > > problem with CHAP and second channels on the Bitsurfer? The only good > > > solution I see is to let the TA in on the secret and let it make up its > > > own CHAP responses. > > > > > Motorola is going to pass the secret to the TA via AT-like command. That > > is the 'only good solution' if want your secret going across the serial > > line whenever you dial. The best solution is for Microsoft to fix the > > problem. The Adtran TA's will jump in the middle of the negotiation and > > Nak down to PAP when dialing with Win95. > > I do not understand any of that. Exactly what could Microsoft or any > vendor to affect the problem? For one, Microsoft could fix Win95 to allow responses to the CHAP re-challenges. Is that not exact enough for you? The TA routes the challenge from the 2nd B-channel to the PC and the response is then sent out that 2nd B-channel. > Either the TA has the CHAP secret > or it does not. If the TA has the secret, then it can answer CHAP > challenges and all is fine. If the TA does not have the secret, > then the TA can't play. If the TA has the secret, it is either told > as much at the start of each session with AT commands or equivalent, > or it keeps the secret in its own memory. The AT command allows you to change the secret for the different destinations being dialed. > Exactly what is so terrible about sending the secret accross a couple > feet of RS-232 wires between the modem and the computer at the start > of every session? If you have reason to worry that your RS-232 cables > are bugged, you have far bigger problems than anything that might be > addressed by PAP, CHAP, or anything else in PPP. It's now just that. Anyone could open up your Dialup Networking window and look at the string your using for dialing and there is the secret in the clear. > TA's that try to Nak down to PAP sound broken as well as unworkable. > If one or the other host wants to be authenticator with CHAP, how can > the TA force PAP? Such an authenicator is not going to settle for PAP > any more than it is going to settle for a CHAP response with the wrong > hash value. If it were possible to force PAP, there would be a > catastrophic security hole in PPP. A bad guy could use the "tell me > your PAP password" attack. You are correct. That's why it is a temporary solution only until Win95 accepts CHAP rechallenges. Kyle - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 16:48:30 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id QAA04948; Wed, 12 Feb 1997 16:48:30 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 16:48:30 -0500 (EST) Date: Wed, 12 Feb 1997 16:51:35 -0500 From: Patrick Klos Message-Id: <199702122151.QAA27142@linux.klos.com> To: ietf-ppp@MERIT.EDU, vjs@mica.denver.sgi.com Subject: Re: Compressible and Encryptable protocols Resent-Message-ID: <"8h-YR1.0._C1.cgZ0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2649 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Running PAP unencrypted when you might encrypt it just so that TAs can >sniff PAP would be strange. You don't throw away security lightly. Did I miss something? If I recall the rules properly, you can't negotiate CCP until you reach the Network-Layer Protocol phase. And you can't get to the Network-Layer Protocol phase until you complete the Authentication phase. If you're using PAP, the only time PAP packets cross the link is DURING authentication. So how can you encrypt a PAP packet when you haven't negotiated CCP yet? ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://web.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 17:04:24 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id RAA05421; Wed, 12 Feb 1997 17:04:24 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 17:04:24 -0500 (EST) From: sullivan@gandalf.ca (Chris Sullivan) Message-Id: <199702122205.RAA09235@stealth> Subject: Re: Compressible and Encryptable protocols To: klos@klos.com (Patrick Klos) Date: Wed, 12 Feb 1997 17:05:28 -0500 (EST) Cc: ietf-ppp@MERIT.EDU, vjs@mica.denver.sgi.com In-Reply-To: <199702122151.QAA27142@linux.klos.com> from "Patrick Klos" at Feb 12, 97 04:51:35 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Rb2Y71.0.OK1.YvZ0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2650 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > >Running PAP unencrypted when you might encrypt it just so that TAs can > >sniff PAP would be strange. You don't throw away security lightly. > > Did I miss something? If I recall the rules properly, you can't negotiate > CCP until you reach the Network-Layer Protocol phase. And you can't > get to the Network-Layer Protocol phase until you complete the > Authentication phase. If you're using PAP, the only time PAP packets > cross the link is DURING authentication. > > So how can you encrypt a PAP packet when you haven't negotiated CCP > yet? With CHAP you can re-challenge after auth but encrypting CHAP would be kind of silly anyway. I guess more than just the protocol number protects PAP. Lets put auth into LCP just to make sure. -- Chris Sullivan Gandalf Data Limited sullivan@gandalf.ca does not necessarily share my opinions, including this one - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 17:23:55 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id RAA06067; Wed, 12 Feb 1997 17:23:55 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 17:23:55 -0500 (EST) Date: Wed, 12 Feb 1997 15:23:36 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702122223.PAA19732@mica.denver.sgi.com> To: Subject: Re: Compressible and Encryptable protocols Resent-Message-ID: <"YrlZW2.0.TU1.qBa0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2651 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Kyle Farnsworth" > ... > For one, Microsoft could fix Win95 to allow responses to the CHAP > re-challenges. Is that not exact enough for you? The TA routes the > challenge from the 2nd B-channel to the PC and the response is then sent > out that 2nd B-channel. That's a good idea, but has problems. I think the topology is this: _______ ______ link-1 _______ | | | |+++++++++++| | |PPP-A|===| TA | | hub | | | | | link-2 | | |-----| | |+++++++++++| | |----| |-----| 1. link-1 is dialed, LCP negotiated. 2. hub sends CHAP challenge, which is passed to PPP-A, which responds, which is sent on link-1 3. link-2 is dialed, LCP negotiate. 4. hub sends CHAP challenge on link-2, TA gets it, remembers it arrived on link-2, passes it to PPP-A 5. PPP-A responds, the TA remembers and sends the response back on link-2. That simple, initial case works, But what if the hub later re-challenges on both links simultaneously? What if PPP-A answers the challenges in either order? Do you keep track of the last CHAP challenge seen on each link so that you can know which response belongs to which link? What if the hub uses the same Identifier on both challenges (different links, so that is perfectly valid and as long as the values vary, perfectly secure)? How can the TA know which response belongs to which link? What if PPP-A tries to challenge the hub? How can PPP-A check both links? > > Either the TA has the CHAP secret > > or it does not. If the TA has the secret, then it can answer CHAP > > challenges and all is fine. If the TA does not have the secret, > > then the TA can't play. If the TA has the secret, it is either told > > as much at the start of each session with AT commands or equivalent, > > or it keeps the secret in its own memory. > The AT command allows you to change the secret for the different > destinations being dialed. I would also rather not keep an important security secret in a modem. > > Exactly what is so terrible about sending the secret accross a couple > > feet of RS-232 wires between the modem and the computer at the start > > of every session? If you have reason to worry that your RS-232 cables > > are bugged, you have far bigger problems than anything that might be > > addressed by PAP, CHAP, or anything else in PPP. > It's now just that. Anyone could open up your Dialup Networking window and > look at the string your using for dialing and there is the secret in the > clear. So fix the "Dialup Networking window" software to keep secrets secret. Yes, now that you point this out, it sounds like a real problem, but is a problem in whatever PC software is being used, not the PPP protocol or even the AT-like-commands protocol. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 17:55:30 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id RAA07157; Wed, 12 Feb 1997 17:55:30 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 17:55:30 -0500 (EST) Message-Id: <9702122252.AA03332@adtrn-ws01.adtran.com> From: "Kyle Farnsworth" To: Subject: Re: Compressible and Encryptable protocols Date: Wed, 12 Feb 1997 16:56:51 -0600 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hQ9KG3.0.Nl1.Nfa0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2652 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: Vernon Schryver > > From: "Kyle Farnsworth" > > > ... > > For one, Microsoft could fix Win95 to allow responses to the CHAP > > re-challenges. Is that not exact enough for you? The TA routes the > > challenge from the 2nd B-channel to the PC and the response is then sent > > out that 2nd B-channel. > > That's a good idea, but has problems. I think the topology is this: > > _______ ______ link-1 _______ > | | | |+++++++++++| | > |PPP-A|===| TA | | hub | > | | | | link-2 | | > |-----| | |+++++++++++| | > |----| |-----| > > 1. link-1 is dialed, LCP negotiated. > 2. hub sends CHAP challenge, which is passed to PPP-A, which > responds, which is sent on link-1 > 3. link-2 is dialed, LCP negotiate. > 4. hub sends CHAP challenge on link-2, TA gets it, remembers it > arrived on link-2, passes it to PPP-A > 5. PPP-A responds, the TA remembers and sends the response back on > link-2. > > That simple, initial case works, But what if the hub later > re-challenges on both links simultaneously? > What if PPP-A answers the challenges in either order? > Do you keep track of the last CHAP challenge seen on each link > so that you can know which response belongs to which link? > What if the hub uses the same Identifier on both challenges (different > links, so that is perfectly valid and as long as the values vary, perfectly > secure)? How can the TA know which response belongs to which link? > Your right that this situation could happen although unlikely since the Identifier's on both challenge's would have to be the same. This type of situation has never been reported to me. > What if PPP-A tries to challenge the hub? How can PPP-A check both > links? > PPP-A can't because the TA "terminates" the second LCP link. But PPP-A won't care because as far has it's concerned there is only one link. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 12 19:29:54 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id TAA08586; Wed, 12 Feb 1997 19:29:54 -0500 (EST) Resent-Date: Wed, 12 Feb 1997 19:29:54 -0500 (EST) Date: Wed, 12 Feb 1997 17:28:22 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702130028.RAA20014@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Compressible and Encryptable protocols Resent-Message-ID: <"SwpXu2.0.r52.x1c0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2653 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Kyle Farnsworth" > ... > > That simple, initial case works, But what if the hub later > > re-challenges on both links simultaneously? > > What if PPP-A answers the challenges in either order? > > Do you keep track of the last CHAP challenge seen on each link > > so that you can know which response belongs to which link? > > What if the hub uses the same Identifier on both challenges (different > > links, so that is perfectly valid and as long as the values vary, perfectly > > secure)? How can the TA know which response belongs to which link? > > > Your right that this situation could happen although unlikely since the > Identifier's on both challenge's would have to be the same. This type of > situation has never been reported to me. That you have not had reports of the situation suggests to me only that your current customers are not dealing with PPP hubs that re-authenticate. A system that re-authenticates, and maintains separate Auth. state machines including timers and ID generators might be expected to have the authentication requests on the links drift with respect to each other, and eventually have approximately coincident requests with the same ID. That drift is inevitiable, because of the interference of other traffic on RS-232 link between the TA and the PC, including the auth. packets for the ISDN link. As I understand basic protocol design, any protocol that clearly and unambigously does not work in some valid case is broken, even if that case is "unlikely" as measured by complaints from current customers. > > What if PPP-A tries to challenge the hub? How can PPP-A check both > > links? > > > PPP-A can't because the TA "terminates" the second LCP link. But PPP-A > won't care because as far has it's concerned there is only one link. Of course, that was basically my point. You are basically saying that authentication by the system using the TA is completely broken. That is consistent with the PC and ISP hope that no one bad guys notice the holes in not authenticating "servers." I think that is not a wise hope. For one thing, this is not a secret or even private mailing list. It is both archived and gatewayed into newsgroups. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 05:53:49 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id FAA12985; Thu, 13 Feb 1997 05:53:49 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 05:53:49 -0500 (EST) Mime-Version: 1.0 Date: Thu, 13 Feb 1997 10:44:18 +0000 Message-ID: <302f25a0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Compressible and Encryptable protocols To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"Md9M.0.VA3.BAl0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2654 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Chris Sullivan writes (in response to Patrick Klos): > > > Did I miss something? If I recall the rules properly, you can't > > negotiate _ECP_ until you reach the Network-Layer Protocol phase. And > > you can't get to the Network-Layer Protocol phase until you complete the > > Authentication phase. If you're using PAP, the only time PAP > > packets cross the link is DURING authentication. > > > > So how can you encrypt a PAP packet when you haven't negotiated > > _ECP_ yet? >With CHAP you can re-challenge after auth but encrypting CHAP would be kind of >silly anyway. I guess more than just the protocol number protects PAP. Lets >put auth into LCP just to make sure. Well obviously Patrick is correct that the initial authentication CANNOT be encrypted, so I don't think there's any need to put auth into LCP just to avoid encrypting CHAP re-challenges. Anyway, is it fair to say that the consensus is: An implementation MAY encrypt any protocol (once ECP is open), with the exception of LCP negotiations (i.e. Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request and Terminate-Ack); the implementation SHOULD encrypt protocols in the range 0000-BFFF, and SHOULD NOT encrypt authentication protocols. --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 09:55:05 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA16863; Thu, 13 Feb 1997 09:55:05 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 09:55:05 -0500 (EST) From: Daniel_Brennan@3mail.3com.com X-Lotus-FromDomain: 3COM To: ietf-ppp@MERIT.EDU Message-ID: <8525643D.00520453.00@hqoutbound.ops.3com.com> Date: Thu, 13 Feb 1997 09:57:24 -0400 Subject: Re: Compressible and Encryptable protocols Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"GjsPr3.0.574.-io0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2655 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU encrypting NCPs spells trouble for TAs. > Encrypting the NCP protocols is not obvious is your read RFC1669/RFC1969 > for DES Link Level Encryption. I think it is a good idea, but this needs > to be clearly stated in the appropriate RFCs. > > Philip Rakity > FlowPoint > > On Wed, 12 Feb 1997, Jonathan Goodchild wrote: > > > Patrick Klos writes: > > >My initial take on encryption of NCP is this: I think you may want to > > >encrypt some (or all) NCP packets just as you encrypt data packets. > > >The reason for encryption is different than the reason for compression. > > >We encrypt packets to add a level of security to the link. Some of > > >that security could be diminished if certain aspects of an NCPs > > >negotiations we "left out in the open". At the least, an > > >implementation SHOULD be allowed to encrypt NCP packets (i.e. it > > >shouldn't be explicitly disallowed). > > > > and Vernon Schryver writes: > > ]That idea argues for a stronger statement, that some of those packets > > ]not merely "MAY" but "SHOULD" or "MUST" be encrypted. > > > > Yes, that was my view. Clearly the rules are: > > > > 1) An implementation MAY encrypt any protocol (once ECP is open), > > with the exception of LCP negotiations (i.e Configure-Request, > > Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request > > and Terminate-Ack) > > > > 2) An implementation MUST be prepared to receive any decrypted > > protocol ID (exception: for LCP the same rules apply as per > > LCP on a multilink bundle - RFC 1990 section 2). > > > > In terms of a stronger statement, which of: > > > > 1a) An implementation SHOULD encrypt protocols in the range 0000-7FFF > > or > > 1b) An implementation SHOULD encrypt protocols in the range 0000-BFFF > > > > is preferable ? I was also wondering about: > > > > 1c) If an implementation encrypts compressed data then it MUST also > > encrypt CCP packets. > > > > but maybe this is overkill as the receiver should be able to preserve the order > > of the CCP packets with respect to the decrypted data. > > > > --- > > Jonathan.Goodchild@rdl.co.uk > > > > > > > > > > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 09:58:49 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA16986; Thu, 13 Feb 1997 09:58:49 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 09:58:49 -0500 (EST) From: Daniel_Brennan@3mail.3com.com X-Lotus-FromDomain: 3COM To: ietf-ppp@MERIT.EDU Message-ID: <8525643D.00523C50.00@hqoutbound.ops.3com.com> Date: Thu, 13 Feb 1997 10:01:03 -0400 Subject: Re: Compressible and Encryptable protocols Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"oGnyw3.0.094.Ymo0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2656 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Sorry Vern, my oh-so-smart TA will have problems with encrypted NCPs (APs for that matter). So I would rather not see it happen. Dan Brennan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 10:09:45 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17598; Thu, 13 Feb 1997 10:09:45 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 10:09:45 -0500 (EST) From: Daniel_Brennan@3mail.3com.com X-Lotus-FromDomain: 3COM To: ietf-ppp@MERIT.EDU Message-ID: <8525643D.0053677B.00@hqoutbound.ops.3com.com> Date: Thu, 13 Feb 1997 10:11:59 -0400 Subject: Re: Compressible and Encryptable protocols Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"gT-HF1.0.UI4.owo0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2657 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I do not understand any of that. Exactly what could Microsoft or any > vendor to affect the problem? Either the TA has the CHAP secret Vern, obviously you don't know the underlying issue here, so it's best to take a seat and observe at this point. Dan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 10:56:43 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA18975; Thu, 13 Feb 1997 10:56:43 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 10:56:43 -0500 (EST) Mime-Version: 1.0 Date: Thu, 13 Feb 1997 15:47:45 +0000 Message-ID: <30339840@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: PCs, TAs and Auth [Was: Re: Compressible and Encryptable...] To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"9i37v2.0.zd4.qcp0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2658 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > > ... > > > That simple, initial case works, But what if the hub later > > > re-challenges on both links simultaneously? > > > What if PPP-A answers the challenges in either order? > > > Do you keep track of the last CHAP challenge seen on each link > > > so that you can know which response belongs to which link? > > > What if the hub uses the same Identifier on both challenges (different > > > links, so that is perfectly valid and as long as the values vary, > > > perfectly secure)? How can the TA know which response belongs to which > > > link? > > > > > You're right that this situation could happen although unlikely since the > > identifier's on both challenge's would have to be the same. This type > > of situation has never been reported to me. > >That you have not had reports of the situation suggests to me only that >your current customers are not dealing with PPP hubs that >re-authenticate. A system that re-authenticates, and maintains separate >Auth. state machines including timers and ID generators might be expected >to have the authentication requests on the links drift with respect to >each other, and eventually have approximately coincident requests with >the same ID. That drift is inevitiable, because of the interference >of other traffic on RS-232 link between the TA and the PC, including >the auth. packets for the ISDN link. > >As I understand basic protocol design, any protocol that clearly and >unambigously does not work in some valid case is broken, even if that >case is "unlikely" as measured by complaints from current customers. > > > > What if PPP-A tries to challenge the hub? How can PPP-A check > > > both links? > > > > > PPP-A can't because the TA "terminates" the second LCP link. But > > PPP-A won't care because as far has it's concerned there is only one > > link. > >Of course, that was basically my point. > >You are basically saying that authentication by the system using the TA >is completely broken. >... As I see it, there are 2 CHAP-related problems when using a TA to provide your PC with MP capability: 1) Authenticatee - either the TA needs to know the secret, or it needs to passthrough the challenges on each link (assuming that the PC can actually cope with being challenged a second time), in which case there is the problem of coincident challenges with the same identifier. 2) Authenticator - how does the TA authenticate the second link ? Although I can think of partial solutions to both problems, in my (admittedly biased) opinion, if you're worried about security, you're far better off using an ISDN card for your PC instead of a TA. :-) --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 12:48:32 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id MAA20897; Thu, 13 Feb 1997 12:48:32 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 12:48:32 -0500 (EST) Date: Thu, 13 Feb 1997 10:48:01 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702131748.KAA22079@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU, l2tp@ca.newbridge.com Subject: CHAP hole Resent-Message-ID: <"QmEhV.0.665.eFr0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2659 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I've added the PPP mailing list to this discussion that starte din the L2TP list, because it involves what seems to me a significant thing about CHAP. I've also quoted too much to ensure there is enough context for the readers only of the PPP list. I appologize to those who will receive two copies as a result. I think additional comments should be sent to the PPP mailing list. > From: Barney Wolff > ... > Ok. Say both sides share a single secret. > > Both sides negotiate CHAP. Now: > > Bad Guy Victim > <------------CHAP challenge, id=x,random=yyyyy > CHAP challenge, id=x, random=yyyyy-------> > <------------CHAP response, id=x,hash=zzzzzz > CHAP response, id=x, hash=zzzzzz---------> > > And now the Victim believes that the Bad Guy is valid, while the Bad Guy > had to know nothing at all. The Victim's mistake was believing that > PPP/CHAP is symmetric and so it could respond to the Bad Guy's challenge > before seeing and validating the Bad Guy's response to its own > challenge. Separate secrets defeats this attack. (So would checking > that a CHAP challenge you get is not equal to one you sent. So would > refusing to respond until you see the other side's response, but > obviously both boxes can't do that.) If a box uses the same secret in > initiating and responding to calls, there is a two-call attack along > similar lines that allows the attacker to get each of two victim boxes > to compute the proper responses and so believe they are talking to each > other while it is the bad guy talking to both. > ... That is a good point. Thanks. I'll modify my own code to have a cache of random numbers recently sent or received in challenges, and ignore challenges with numbers in that cache. I think the cache need be no larger than twice the maximum CHAP timeout times the CHAP retranmission rate (adjusted if you use non-linear retransmission delays). > ... > I don't believe that having a caller use CHAP to validate a callee adds > any real security at all. If a bad guy succeeds in getting a victim to > call the wrong number, the bad guy then calls the right number and > relays CHAP frames back and forth between the two calls until > authentication succeeds. The bad guy can then do whatever he likes on > one or both calls. As the CHAP RFC says, CHAP does not protect against > man-in-the-middle (aka "active") attacks. With dialup, > man-in-the-middle is trivial. Thus, I claim, having the caller use CHAP > is no better than just checking that the callee's user id is as expected. Yes, CHAP does not defend against man-in-the-middle attacks, but that does not imply that bidirectional CHAP is valueless. On the contrary, unless you use some kind of bidirectional PPP authentication (and you don't want bidirectional PAP!), one peer has no confidence of the identity of the other. Man-in-the-middle would be at least a little more hassle than only attacking a caller (e.g. calling a modem target just as it is going off-hook). Protection from man-in-the-middle requires ECP. If you encrypt not only the authentication secrets (e.g. with CHAP) but also the other traffic, the man in the middle can relay to his heart's content, but not add his own data to the stream or read yours. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 13:40:49 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id NAA22013; Thu, 13 Feb 1997 13:40:49 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 13:40:49 -0500 (EST) Message-Id: <28725.9702131837@vulcan.xylogics.com> To: ietf-ppp@MERIT.EDU, l2tp@ca.newbridge.com Cc: vjs@mica.denver.sgi.com (Vernon Schryver) Subject: Re: CHAP hole In-Reply-To: Your message of "Thu, 13 Feb 1997 10:48:01 MST." <199702131748.KAA22079@mica.denver.sgi.com> Date: Thu, 13 Feb 1997 13:37:45 -0500 From: James Carlson Resent-Message-ID: <"vcRkr.0.aN5.h0s0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2660 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In message <199702131748.KAA22079@mica.denver.sgi.com>, Vernon Schryver writes: > Yes, CHAP does not defend against man-in-the-middle attacks, but that > does not imply that bidirectional CHAP is valueless. On the contrary, > unless you use some kind of bidirectional PPP authentication (and you > don't want bidirectional PAP!), one peer has no confidence of the > identity of the other. Man-in-the-middle would be at least a little > more hassle than only attacking a caller (e.g. calling a modem target > just as it is going off-hook). Why on earth would you use the same secret (or password) for authenticating in each direction? That seems to be ridiculous at best. Each system should authenticate itself to the other. In order to do that, each system needs a security profile representing the other system. It certainly should not be the case that these are identical, or many sorts of security will break down, not just PAP and CHAP. Casting it into another light to (perhaps) make the problem clearer, let's try this: if I log into another system (say, via telnet), I will prove my identity by giving up my username and password. How could that remote system prove its identity to me? Surely, you can't be suggesting that the remote system should send me my own username and password as proof?! --- James Carlson , Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4782 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 14:05:42 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA23215; Thu, 13 Feb 1997 14:05:42 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 14:05:42 -0500 (EST) Message-ID: <3303200A.6231@masinter.net> Date: Thu, 13 Feb 1997 14:07:06 +0000 From: "John F. Masinter" Reply-To: john@masinter.net Organization: Total Business Computing Inc. X-Mailer: Mozilla 3.0Gold (WinNT; U) MIME-Version: 1.0 To: ietf-ppp@MERIT.EDU Subject: Re: L2TP working group. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"cx-iq3.0.Gg5.wNs0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2661 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU For those intrigued by the heated security debates being held on the L2TP mail list, you may learn more about the issues and L2TP in general, by visiting the web page. The "Unofficial L2TP Web Page" can be found at: http://www.masinter.net/~l2tp/ The mail list archive found there is up to date (thru 2/13.) \\"""// (0 0) +----oOO---------(_)-----------------+ | John F. Masinter 770-516-6600 | | | | mailto:john@masinter.net | | http://www.masinter.net | |------------------------------------| | Total Business Computing Inc. | | POB 88584, Atlanta GA 30356 USA | +-----------------------------oOO----+ |__|__| || || ooO Ooo !! REDISTRIBUTION OF THIS WORK BY THE !! !! MICROSOFT NETWORK IS STRICTLY PROHIBITED !! - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 14:31:40 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA23967; Thu, 13 Feb 1997 14:31:40 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 14:31:40 -0500 (EST) Date: Thu, 13 Feb 1997 12:31:20 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702131931.MAA22217@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: CHAP hole Resent-Message-ID: <"4h3Ku3.0.4s5.Lms0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2662 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: James Carlson > To: ietf-ppp@merit.edu, l2tp@ca.newbridge.com (I'm sending only to the PPP mailing list) > ... > Why on earth would you use the same secret (or password) for authenticating > in each direction? That seems to be ridiculous at best. Perhaps it is ridiculous to use the same password in both directions, but how do you keep users and operators from doing ridiculous things? Adding a cache of your random numbers seems cheap and effective. It might break some too clever by half ISDN TA's, but that's just too bad. (to the L2TP list he wrote in part): ] Is there anyone out there who is actually using the same secret to generate ] a CHAP response as to validate the peer's CHAP response? (And willing to ] admit it?!) It seems fairly common for people who use PPP to configure systems to use the same username for both. I bet a bunch of those also use the same CHAP secrets. Using a cache of your own random values is a cheap and effective fix for the hole. I think it allows the same password to be configured for both directions. (I was wrong when I said you need to cache the other guy's challenge values.) It would be good if this hole and its fixes (checking random values or requiring distinct secrets) were documented in the next version of RFC 1994. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 14:42:16 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA24392; Thu, 13 Feb 1997 14:42:16 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 14:42:16 -0500 (EST) Message-Id: <2.2.32.19970213194215.002f7c24@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Feb 1997 11:42:15 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: Re: PCs, TAs and Auth [Was: Re: Compressible and Encryptable...] Resent-Message-ID: <"nrih_.0.my5.Iws0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2663 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 03:47 PM 2/13/97 +0000, Jonathan Goodchild wrote: >Vernon Schryver writes: >> > ... >> > > That simple, initial case works, But what if the hub later >> > > re-challenges on both links simultaneously? I think some TAs simply serialize the CHAPs to the PC. The CHAP timeout is of the order of seconds, and the PC's CHAP response time is of the order of milliseconds. The TA simply delays sending new challenges to the PC while an old one is outstanding. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 14:48:33 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA24682; Thu, 13 Feb 1997 14:48:33 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 14:48:33 -0500 (EST) From: Barney Wolff To: ietf-ppp@MERIT.EDU Date: Thu, 13 Feb 1997 13:56 EST Subject: Re: CHAP hole Content-Type: text/plain Message-ID: <33036ffc0.53f5@databus.databus.com> Resent-Message-ID: <"mebmV2.0.E16.B0t0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2664 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Date: Thu, 13 Feb 1997 13:37:45 -0500 > From: James Carlson > > Why on earth would you use the same secret (or password) for authenticating > in each direction? That seems to be ridiculous at best. Well, yes. But 1334 didn't say it. 1994 does - I think I had a little to do with that. > Each system should authenticate itself to the other. In order to do that, > each system needs a security profile representing the other system. It > certainly should not be the case that these are identical, or many sorts > of security will break down, not just PAP and CHAP. A system *also* needs to use a different pair of secrets with a given other system depending on who initiated the connection, if both sides are allowed to do so, as with a pair of dial-on-demand routers. Otherwise the Bad Guy simply dials both victims and relays CHAP frames until the auth phase is done, thus inserting himself in the middle with virtually no effort. That's why I consider allowing the caller to authenticate the callee with CHAP to be a bug not a feature. PPP tradition has been quite rigid about not depending on info from the physical layer, but here's a case where I think it's essential. The info may not be perfectly reliable, in that a lucky attacker can dial an outgoing port at just the moment when that port is making a call. But the attacker has to work a lot harder, and may well be noticed. Barney Wolff - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 16:09:07 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id QAA26331; Thu, 13 Feb 1997 16:09:07 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 16:09:07 -0500 (EST) Date: Thu, 13 Feb 1997 14:08:49 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702132108.OAA22452@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: PCs, TAs and Auth Resent-Message-ID: <"62sh03.0.3R6.iBu0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2665 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Eric L. Michelsen" > >> > ... > >> > > That simple, initial case works, But what if the hub later > >> > > re-challenges on both links simultaneously? > > I think some TAs simply serialize the CHAPs to the PC. The CHAP timeout is > of the order of seconds, and the PC's CHAP response time is of the order of > milliseconds. The TA simply delays sending new challenges to the PC while > an old one is outstanding. Why must CHAP timeouts be seconds instead of something computed from previous CHAP RTT's? Maybe to detect or inconvenience men in the middle? (Of course, such a TA is a benign man-in-the-middle.) I've recently argued privately with an implementor that a response to a CHAP challenge should either take milliseconds or the authentication server should be replaced with a real computer. He insists that in current, real life systems, it can take seconds for the authentication server to respond. Maybe he's right. If the answer to that objection (that the response of the PC can be very long) is that PC's don't use authentication servers and aren't connected to networks, then I might respond uncharitably about the likely fate of outfits that fail to look past their current narrow corner of the market and choose to build junk that does not quite work such as PPP implementations that cannot renegotiate LCP. ........................ ] From: Barney Wolff ] > Why on earth would you use the same secret (or password) for authenticating ] > in each direction? That seems to be ridiculous at best. ] ] Well, yes. But 1334 didn't say it. 1994 does - I think I had a little ] to do with that. Despite skimming 1994, I failed to find new, relevant words. Where did are they? ] > Each system should authenticate itself to the other. In order to do that, ] > each system needs a security profile representing the other system. It ] > certainly should not be the case that these are identical, or many sorts ] > of security will break down, not just PAP and CHAP. ] ] A system *also* needs to use a different pair of secrets with a given ] other system depending on who initiated the connection, if both sides ] are allowed to do so, as with a pair of dial-on-demand routers. Please say why 4 secrets are needed and why which secrets are used should depend on who calls whom (of course assuming defenses against playbacks). ] Otherwise ] the Bad Guy simply dials both victims and relays CHAP frames until the ] auth phase is done, thus inserting himself in the middle with virtually ] no effort. Please say why with 1, 2, or 4 secrets the Bad Guy cannot always do that exactly that. A man-in-the-middle need not know how many secrets are involve, since it is just blindly relaying CHAP packets. ] That's why I consider allowing the caller to authenticate the ] callee with CHAP to be a bug not a feature. I don't see how having the caller authenticate the callee reduces security, provided care is taken to prevent replay attacks using either system as the source of playbacks. ] PPP tradition has been ] quite rigid about not depending on info from the physical layer, but ] here's a case where I think it's essential. The info may not be perfectly ] reliable, in that a lucky attacker can dial an outgoing port at just the ] moment when that port is making a call. But the attacker has to work ] a lot harder, and may well be noticed. If you're saying that something like caller-ID is a good thing, then who could argue? I'm not sure I'd trust the typical CID box to ignore stray FSK tones intended by a bad guy to flush the real CID info, but that's a secondary worry. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 17:40:43 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id RAA28331; Thu, 13 Feb 1997 17:40:43 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 17:40:43 -0500 (EST) From: Barney Wolff To: ietf-ppp@MERIT.EDU Date: Thu, 13 Feb 1997 16:16 EST Subject: Re: PCs, TAs and Auth Content-Type: text/plain Message-ID: <3303985c0.57d3@databus.databus.com> Resent-Message-ID: <"47Sfr3.0.Jw6.aXv0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2666 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Date: Thu, 13 Feb 1997 14:08:49 -0700 > From: vjs@mica.denver.sgi.com (Vernon Schryver) > > Despite skimming 1994, I failed to find new, relevant words. Where did > are they? In Security Considerations: "The secret SHOULD NOT be the same in both directions. This allows an attacker to replay the peer's challenge, accept the computed response, and use that response to authenticate." > ] > Each system should authenticate itself to the other. In order to do that, > ] > each system needs a security profile representing the other system. It > ] > certainly should not be the case that these are identical, or many sorts > ] > of security will break down, not just PAP and CHAP. > ] > ] A system *also* needs to use a different pair of secrets with a given > ] other system depending on who initiated the connection, if both sides > ] are allowed to do so, as with a pair of dial-on-demand routers. > > Please say why 4 secrets are needed and why which secrets are used should > depend on who calls whom (of course assuming defenses against playbacks). If I use a different secret when dialed from the one I use when I dial, the attacker can't dial me and get me to compute a response using the secret that my peer expects me to use when I dial him. The attacker instead has to convince me that I dialed, when in fact the attacker dialed me. Way harder. Caching recently sent randoms works on a single system but not on a distributed one, such as a global network of terminal servers. > ] Otherwise > ] the Bad Guy simply dials both victims and relays CHAP frames until the > ] auth phase is done, thus inserting himself in the middle with virtually > ] no effort. > > Please say why with 1, 2, or 4 secrets the Bad Guy cannot always do that > exactly that. A man-in-the-middle need not know how many secrets are > involve, since it is just blindly relaying CHAP packets. The attacker now has to convince me that I dialed, when in fact the attacker dialed me. Otherwise I'll use the wrong secret, and my peer will reject me, as in this case we want him to. > ] That's why I consider allowing the caller to authenticate the > ] callee with CHAP to be a bug not a feature. > > I don't see how having the caller authenticate the callee reduces > security, provided care is taken to prevent replay attacks using > either system as the source of playbacks. If my reasoning is correct that 4 secrets are required to make bidirectional CHAP secure, and (I'm willing to wager) nobody has code that does that, then bidirectional CHAP reduces security. If a callee refuses to compute a CHAP response, then nobody can pretend to be him. If a callee refuses to transmit a CHAP response until it validates the caller's response, then again nobody can pretend to be him. But you have to know which side is caller and which is callee. > ] PPP tradition has been > ] quite rigid about not depending on info from the physical layer, but > ] here's a case where I think it's essential. The info may not be perfectly > ] reliable, in that a lucky attacker can dial an outgoing port at just the > ] moment when that port is making a call. But the attacker has to work > ] a lot harder, and may well be noticed. > > If you're saying that something like caller-ID is a good thing, then > who could argue? I'm not sure I'd trust the typical CID box to ignore > stray FSK tones intended by a bad guy to flush the real CID info, but > that's a secondary worry. No, just that it really matters whether a call is incoming or outgoing. If it's practical to hit a dialing modem with an incoming call and not have the modem notice, then only real ipsec will help. But if the modem told you it was an incoming call, and you ignore the info because "everybody knows" that PPP is symmetric, you're easy meat. To summarize: *Something* must break the symmetry. Either you use different secrets in each direction and when calling vs called, or you use a different algorithm in each direction (eg, refusing to send your response until you get & validate the other side's response, or not doing CHAP at all in one direction). Barney Wolff - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 21:15:49 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id VAA01968; Thu, 13 Feb 1997 21:15:49 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 21:15:49 -0500 (EST) Date: Thu, 13 Feb 1997 19:14:27 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702140214.TAA23110@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: PCs, TAs and Auth Resent-Message-ID: <"0Gj0U2.0.OU.9hy0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2667 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Barney Wolff > ... > > Please say why 4 secrets are needed and why which secrets are used should > > depend on who calls whom (of course assuming defenses against playbacks). > > If I use a different secret when dialed from the one I use when I dial, > the attacker can't dial me and get me to compute a response using the > secret that my peer expects me to use when I dial him. The attacker > instead has to convince me that I dialed, when in fact the attacker > dialed me. Way harder. If you never reuse random values, and if you have 2 secrets, your willingness to compute responses for the other guy's secret allows nothing more than a man-in-the-middle attack. Is that the point? If so, then 4 secrets is a good defense against the simultaneous-dial attack on a modem. It makes men in the middle by that method way harder, but that's not the only way to get a man in the middle. > Caching recently sent randoms works on a single system but not on a > distributed one, such as a global network of terminal servers. Are you assuming the bad guy would be allowed to dial two terminal servers, and use one as an oracle to compute CHAP responses for the challenges of the other? If you don't do distributed challenge value computing (e.g. do it all in your authentication server), the cache still works fine. > ... > > Please say why with 1, 2, or 4 secrets the Bad Guy cannot always do that > > exactly that. A man-in-the-middle need not know how many secrets are > > involve, since it is just blindly relaying CHAP packets. > > The attacker now has to convince me that I dialed, when in fact > the attacker dialed me. Otherwise I'll use the wrong secret, and > my peer will reject me, as in this case we want him to. That sounds like a nice defense against a man-in-the-middle using the dial-at-the-right time attack on modems. I don't think it's worth the trouble, compared to using something such as ISDN, which prevents what I understand the telco people call "glare." > ... > If my reasoning is correct that 4 secrets are required to make bidirectional > CHAP secure, and (I'm willing to wager) nobody has code that does that, > then bidirectional CHAP reduces security. I'd like to take that wager about code for 4 secrets. Then I'd tell you about the code SGI has been shipping for years. That's not a bragging point, but a reflection of an excessively general configuration scheme and a side effect of its history. I wouldn't be surprised if other systems have the same characteristic. It comes from having completely separate configuration data for incoming and outgoing phone calls. > ... > To summarize: *Something* must break the symmetry. Either you use > different secrets in each direction and when calling vs called, or > you use a different algorithm in each direction (eg, refusing to > send your response until you get & validate the other side's response, > or not doing CHAP at all in one direction). If I understand the issue, I think that's a misleading way to phrase it. Better is "unless you know the direction or have 4 secrets, you are more vulnerable to man-in-the-middle attacks." Knowing the direction of the call or having 4 secrets makes men-in-the-middle harder, but not impossible using other means. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 13 21:27:31 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id VAA02694; Thu, 13 Feb 1997 21:27:31 -0500 (EST) Resent-Date: Thu, 13 Feb 1997 21:27:31 -0500 (EST) Date: Thu, 13 Feb 1997 18:27:14 -0800 Message-Id: <199702140227.SAA09159@gump.eng.ascend.com> From: Karl Fox To: Holger Kummert Cc: ietf-ppp@MERIT.EDU Subject: Re: Tiebreaker: Plaintext padding in RFC 1969, DESE In-Reply-To: <3302d6290.4552@gin.conware.de> References: <199702071725.JAA14808@gump.eng.ascend.com> <3302d6290.4552@gin.conware.de> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"70mS41.0.gf.Csy0p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2668 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Holger Kummert writes: > > Hello Karl, > > > Note that both options are exactly equivalent in terms of line > > efficiency. > > is this really true? If the SDP-like padding will be done according > to RFC1570, then not in every case there will be padding (in ESP there > will be, if I understood it correctly, at least one byte). > RFC1570 says, that "If the final octet is greater than MPV, no > additional padding is required". > > So if the length of the packet is a multiple of 8 bytes and does > not end with a value <=8, no padding is needed. > Am I correct? Oops. Yes. Thanks for pointing that out. > Holger > > > -- > Holger Kummert Phone: +49 721 9495-0 > Nentec GmbH http://www.nentec.de/ P.S. I hope you don't mind that I sent this response to the whole list. I thought your comment was important enough that everyone should be allowed to benefit from it. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 14 01:43:31 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id BAA06111; Fri, 14 Feb 1997 01:43:31 -0500 (EST) Resent-Date: Fri, 14 Feb 1997 01:43:31 -0500 (EST) From: Barney Wolff To: ietf-ppp@MERIT.EDU Date: Fri, 14 Feb 1997 01:14 EST Subject: Re: PCs, TAs and Auth Content-Type: text/plain Message-ID: <330409870.5e2f@databus.databus.com> Resent-Message-ID: <"_Mwen1.0.7V1.Cc01p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2669 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Date: Thu, 13 Feb 1997 19:14:27 -0700 > From: vjs@mica.denver.sgi.com (Vernon Schryver) > > > Caching recently sent randoms works on a single system but not on a > > distributed one, such as a global network of terminal servers. > > Are you assuming the bad guy would be allowed to dial two terminal > servers, and use one as an oracle to compute CHAP responses for the > challenges of the other? If you don't do distributed challenge value > computing (e.g. do it all in your authentication server), the cache > still works fine. Let's define an "interesting network" as one big enough that you can't use a single auth server. Anyway, I'm not aware of any distributed auth scheme that uses the auth server to compute the CHAP random. I know that RADIUS does not. As the two-call attack works against any purely symmetric scheme, I think the caching scheme is moot. Barney Wolff - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 14 09:42:23 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA10329; Fri, 14 Feb 1997 09:42:23 -0500 (EST) Resent-Date: Fri, 14 Feb 1997 09:42:23 -0500 (EST) Date: Fri, 14 Feb 97 09:40:10 EST From: "Whelan, Bill" Message-Id: <9701148559.AA855941927@netx.nei.com> To: kummert@nentec.de, Karl Fox Cc: ietf-ppp@MERIT.EDU Subject: Re[2]: Tiebreaker: Plaintext padding in RFC 1969, DESE Resent-Message-ID: <"_aKxW3.0.-W2.nc71p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2670 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> So if the length of the packet is a multiple of 8 bytes and does >> not end with a value <=8, no padding is needed. >> Am I correct? >Oops. Yes. Thanks for pointing that out. My interpretation is that if the packet ends in the sequence 01 02 03 04 05 06 07 08 then it MUST be padded (regardless of the packet size). More generally, if it ends in any sequence 01 02 03 ... xx (where xx <= FF) then it must be padded. Though I never add more than eight bytes of padding, I will strip off more than eight bytes in cases where my peer is paranoid enough to want to hide the actual data length. For reference (though it is not specifically applicable here) see The ESP DES-CBC Transform (RFC 1829) section 2: Pad Length ... The value typically ranges from 0 to 7, but may be up to 255 to permit hiding of the actual data length. I figured whatever rationale went into allowing large pad lengths at the network layer applies equally well to the link layer. Interestingly enough, I think the code fragment allowing for the larger pads is simpler than the code fragment limiting you to the smaller fragments (though it may execute longer). Let me know if I'm wrong, because it would mean I've a bug in my receive side code, though it may occur only infrequently (only about once every 256^7 packets). Bill Whelan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 14 11:28:43 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA12722; Fri, 14 Feb 1997 11:28:43 -0500 (EST) Resent-Date: Fri, 14 Feb 1997 11:28:43 -0500 (EST) Date: Fri, 14 Feb 1997 09:28:17 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702141628.JAA24104@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: PCs, TAs and Auth Resent-Message-ID: <"kYBNq2.0.P63.rA91p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2671 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Barney Wolff > > > Caching recently sent randoms works on a single system but not on a > > > distributed one, such as a global network of terminal servers. > > > > Are you assuming the bad guy would be allowed to dial two terminal > > servers, and use one as an oracle to compute CHAP responses for the > > challenges of the other? If you don't do distributed challenge value > > computing (e.g. do it all in your authentication server), the cache > > still works fine. > > Let's define an "interesting network" as one big enough that you can't > use a single auth server. Anyway, I'm not aware of any distributed > auth scheme that uses the auth server to compute the CHAP random. I > know that RADIUS does not. > > As the two-call attack works against any purely symmetric scheme, I > think the caching scheme is moot. "Moot" doesn't sound like the right word. Perhaps "useless" was meant. What do you suggest instead? It seems you would require a choice among only these alternatives: 1. one secret, authentication only of the caller, and allow only one peer to call, at least on modems that don't use ground-start. 2. two secrets, and allow only one peer to call. 3. four secrets. In my view #1 is a non-starter, because symmetric demand dialing (where either system calls to start the link) is the wave of the future for non-toy installations. I'm a 100% telecommuter. It would silly for me to keep my link nailed up 24x7 in case of incoming email and other traffic, instead of letting SGI's other computers call this system. (I realize many vendors of PPP boxes and Internet Service Providers would like to censor talk of symmetric demand dialing lest their customers hear, because their equipment is hostle to it.) How do you ensure that the people installing things use either #2 or #3? It's fine to say in RFC 1994 that 1 secret is a bad idea. Practically no PPP links will be installed or configured by people who have will have read RFC 1994. The notion of the cache is not to make 1 secret equivalent to 2 or 4, but to reduce the dangers of 1 secret when an uninformed operator fails to heed warnings. Moreover, what's wrong with having RADIUS provide the random number? On general, anti-playback grounds that sounds like a good idea. The server is more likely to have a good clock and/or stable storage, and the coordination in all of its instances to ensure it doesn't reuse the same number. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 14 13:48:29 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id NAA15289; Fri, 14 Feb 1997 13:48:29 -0500 (EST) Resent-Date: Fri, 14 Feb 1997 13:48:29 -0500 (EST) Message-Id: <2.2.32.19970214184833.00305170@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Feb 1997 10:48:33 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: Re: PCs, TAs and Auth Resent-Message-ID: <"CqCq23.0.Tk3.qDB1p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2672 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 02:08 PM 2/13/97 -0700, Vernon Schryver wrote: >> From: "Eric L. Michelsen" > >> >> > ... >> >> > > That simple, initial case works, But what if the hub later >> >> > > re-challenges on both links simultaneously? >> >> I think some TAs simply serialize the CHAPs to the PC. The CHAP timeout is >> of the order of seconds, and the PC's CHAP response time is of the order of >> milliseconds. The TA simply delays sending new challenges to the PC while >> an old one is outstanding. > >Why must CHAP timeouts be seconds instead of something computed >from previous CHAP RTT's? Maybe to detect or inconvenience men >in the middle? (Of course, such a TA is a benign man-in-the-middle.) > >I've recently argued privately with an implementor that a response to a >CHAP challenge should either take milliseconds or the authentication >server should be replaced with a real computer. He insists that in >current, real life systems, it can take seconds for the authentication >server to respond. Maybe he's right. ... Note that I a neither endorse nor disparage the practice of TAs serializing CHAP challenges. But I am aware of one implementation which does so. In practice, I suspect it works quite reliably because the "local" CHAP challenge and response, between the TA and the PC, consumes only a small fraction of the total round-trip time that the challenger sees. (Note that telephone modems can easily have hundreds of milliseconds of delay.) Since the challenger typically allows for a delay a few times the average delay, the additional delay of serialized challenges likely falls well within the tolerance of even an adaptive delay algorithm in the challenger. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 14 14:43:01 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA16801; Fri, 14 Feb 1997 14:43:01 -0500 (EST) Resent-Date: Fri, 14 Feb 1997 14:43:01 -0500 (EST) From: Barney Wolff To: ietf-ppp@MERIT.EDU Date: Fri, 14 Feb 1997 13:22 EST Subject: Re: PCs, TAs and Auth Content-Type: text/plain Message-ID: <3304c0310.68f6@databus.databus.com> Resent-Message-ID: <"1E1OY1.0.064.y0C1p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2673 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Date: Fri, 14 Feb 1997 09:28:17 -0700 > From: vjs@mica.denver.sgi.com (Vernon Schryver) > > > > As the two-call attack works against any purely symmetric scheme, I > > think the caching scheme is moot. > > "Moot" doesn't sound like the right word. Perhaps "useless" was meant. > What do you suggest instead? It seems you would require a choice among > only these alternatives: > > 1. one secret, authentication only of the caller, and allow only one > peer to call, at least on modems that don't use ground-start. > 2. two secrets, and allow only one peer to call. > 3. four secrets. > > In my view #1 is a non-starter, because symmetric demand dialing (where > either system calls to start the link) is the wave of the future for > non-toy installations. I'm a 100% telecommuter. It would silly for me > to keep my link nailed up 24x7 in case of incoming email and other > traffic, instead of letting SGI's other computers call this system. > (I realize many vendors of PPP boxes and Internet Service Providers > would like to censor talk of symmetric demand dialing lest their > customers hear, because their equipment is hostle to it.) I don't view caching as useless, but as two-call attacks are today so simple, something that solves the one-call attack for some cases does not solve enough of the problem to make it worth the pain, imho. And if you're going to change your code, isn't it easier to force the secrets in the two directions to be different than to cache? #1 is a fine pragmatic solution for the majority of Internet and telecommuter access today. It's what exists. But I agree, it's ducking the problem rather than solving it. I don't insist on 4 secrets, but on something to break the symmetry. Although making the CHAP computation depend on whether you believe you or the other party initiated the connection would be in some sense best, simply having the party that thinks the other party initiated the connection refuse to send its CHAP response until having authenticated its peer is good enough. All of these schemes depend on the reliability of an indication from the physical layer of whether you received or initiated the connection. Even that would do no good if the Bad Guy has somehow convinced you to dial the wrong number. Once that happens, all is lost, because the Bad Guy dials the right number, relays as always, and is then in charge. So I'm left to ask: If conning a victim into dialing the wrong number leads to a successful attack despite CHAP with all its symmetry problems cured, is bidirectional CHAP any better than checking that the user id in the CHAP challenge from the server you reach is what you expected? Well, it does force the Bad Guy to get a second phone line and spend a few hours writing some relay code. I fear a security scheme that looks dependable but isn't. > How do you ensure that the people installing things use either #2 or #3? > It's fine to say in RFC 1994 that 1 secret is a bad idea. Practically > no PPP links will be installed or configured by people who have will > have read RFC 1994. The notion of the cache is not to make 1 secret > equivalent to 2 or 4, but to reduce the dangers of 1 secret when an > uninformed operator fails to heed warnings. So would code that insisted on enough secrets. Would you approve of code that allowed a null secret? How about a secret that's in the dictionary? After all, since MD5 is so fast, running a dictionary attack on a sniffed challenge/response takes only a few seconds (probably less on a good SGI :-) Alas, RADIUS conveniently puts both challenge and response in one packet, in the clear. > Moreover, what's wrong with having RADIUS provide the random number? > On general, anti-playback grounds that sounds like a good idea. The > server is more likely to have a good clock and/or stable storage, > and the coordination in all of its instances to ensure it doesn't > reuse the same number. Again, is this worth doing when one can require multiple secrets with less effort? RADIUS so far does not even include a mechanism to have the server help the NAS in computing a CHAP response, were it to be challenged. Of course, such a mechanism would have to be very heavily defended, so that it could not be used by the Bad Guy. Rather than force allocation of randoms centrally, a tagging scheme where you stick your own IP address in the challenge along with enough random bits, would then allow you to check that the challenge you get did not come from you, without having to cache. As caching could only help against the one-call attack, this would be as good as caching and much easier for a little box to implement. On reflection, I seem to have convinced at least myself that, as CHAP is not proof against "active attacks" and as such attacks are far easier with dialup than with a leased line, CHAP is not nearly as strong on dialup as we'd like to think. EAP/IPSEC, where are you when I need you? Barney Wolff - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 14 16:44:04 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id QAA19603; Fri, 14 Feb 1997 16:44:04 -0500 (EST) Resent-Date: Fri, 14 Feb 1997 16:44:04 -0500 (EST) Date: Fri, 14 Feb 1997 13:43:42 -0800 Message-Id: <199702142143.NAA13023@gump.eng.ascend.com> From: Karl Fox To: "Whelan, Bill" Cc: kummert@nentec.de, ietf-ppp@MERIT.EDU Subject: Re[2]: Tiebreaker: Plaintext padding in RFC 1969, DESE In-Reply-To: <9701148559.AA855941927@netx.nei.com> References: <9701148559.AA855941927@netx.nei.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"-PFsp3.0.tn4.SoD1p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2674 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Bill Whelan writes: > My interpretation is that if the packet ends in the sequence > 01 02 03 04 05 06 07 08 > then it MUST be padded (regardless of the packet size). Correct, although you examine only the last byte of already-aligned packets when padding. > More generally, if it ends in any sequence > 01 02 03 ... xx (where xx <= FF) > then it must be padded. > > Though I never add more than eight bytes of padding, I will strip off more > than eight bytes in cases where my peer is paranoid enough to want to hide > the actual data length. If the MPV (Maximum Pad Value; see RFC1570) is 8, then such excess padding wouldn't be allowed. A small MPV would minimize overhead, but would remove the option for long padding sequences. If MPV==255, then *all* packets must be padded. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 14 17:57:46 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id RAA01110; Fri, 14 Feb 1997 17:57:46 -0500 (EST) Resent-Date: Fri, 14 Feb 1997 17:57:46 -0500 (EST) Date: Fri, 14 Feb 1997 15:56:34 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702142256.PAA24945@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: PCs, TAs and Auth Resent-Message-ID: <"SQGNp.0.lG.msE1p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2675 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Barney Wolff > > 1. one secret, authentication only of the caller, and allow only one > > peer to call, at least on modems that don't use ground-start. > > 2. two secrets, and allow only one peer to call. > > 3. four secrets. > ... > I don't view caching as useless, but as two-call attacks are today so > simple, something that solves the one-call attack for some cases does > not solve enough of the problem to make it worth the pain, imho. And if > you're going to change your code, isn't it easier to force the secrets > in the two directions to be different than to cache? I think you are mixing two kinds of attacks. CHAP does not and cannot ensure that there is no man in the middle adding, deleting or changing your data. All that CHAP can do is ensure that the system at the other end of the link is right. There are many places and ways where a bad guy in the middle can improve the data that really matters, IP packets. A two-call attack (if I understand what you mean) is no more or less than one way for a bad guy to get in the middle, in a position to modify your real traffic. > #1 is a fine pragmatic solution for the majority of Internet and > telecommuter access today. It's what exists. But I agree, it's > ducking the problem rather than solving it. #1 kills symmetric demand dialing. It is NOT "fine" for any telecommuter who has seen the bright lights of symmetric dialing. It is fine for the very common toy use of PPP, web surfing by people would be just as happy with and better served by a fancy dumb terminal protocol (e.g. some kind of X terminal) instead of IP/PPP. > I don't insist on 4 secrets, but on something to break the symmetry. > ... > Even that would do no good if the Bad Guy has somehow convinced you to > dial the wrong number. Call forwarding? Injecting a few DTMF tones at the right time? > Once that happens, all is lost, ... > I fear a security scheme that looks dependable but isn't. CHAP is an authentication and authorization scheme. Like checking your finger prints, it only ensures that you are you, not that you are uncoerced, sane, etc. CHAP is not a confidentiality scheme, and even as an A&A scheme, protects only a part of the IP path that is the safest, once you are using PAP or CHAP. > > ... The notion of the cache is not to make 1 secret > > equivalent to 2 or 4, but to reduce the dangers of 1 secret when an > > uninformed operator fails to heed warnings. > > So would code that insisted on enough secrets. Would you approve of > code that allowed a null secret? How about a secret that's in the > dictionary? ... Protecting people from themselves is a bad idea, does not work and cannot be made to work. The strong user-account password rules/programs have demonstrated that repeatedly for the last 30 years. You must allow people to use any password, including a null password. It is good to asking them if they really know what they're doing and accept the consequences, but they're the boss, not you. If you try to force them, they just do worse things like alternating passwords, or writing them down. In my code, I do not see how to even warn people about single or otherwise bad CHAP passwords, since I use an ASCII configuration file. It's bad to have poor passwords, but it is even worse to have the PPP daemon whine about them where bad guys might hear, in your system logs. > ... Alas, RADIUS conveniently puts both > challenge and response in one packet, in the clear. Which makes the issue of good CHAP passwods moot (i.e. fruitless to talk about). > > Moreover, what's wrong with having RADIUS provide the random number? > > On general, anti-playback grounds that sounds like a good idea. The > > server is more likely to have a good clock and/or stable storage, > > and the coordination in all of its instances to ensure it doesn't > > reuse the same number. > > Again, is this worth doing when one can require multiple secrets with > less effort? I see no way in most PPP implementations that you can <> multiple secrets. More, repeating a random CHAP value is a worse sin than having 1 CHAP password, since it allows playback. A RADIUS server could ensure the random values are good, and incidentally make the 1-secret case the same as the 2-secret case. > RADIUS so far does not even include a mechanism to have > the server help the NAS in computing a CHAP response, were it to be > challenged. Of course, such a mechanism would have to be very heavily > defended, so that it could not be used by the Bad Guy. Besides the predictability of the random value generator, I see nothing needing defending. The whole idea of CHAP is that one challenge/response pair gives nothing away about any other. > Rather than force allocation of randoms centrally, a tagging scheme > where you stick your own IP address in the challenge along with > enough random bits, would then allow you to check that the challenge > you get did not come from you, without having to cache. As caching > could only help against the one-call attack, this would be as good > as caching and much easier for a little box to implement. That is equivalent to caching. Caching is simply a way to detect your own random values. If you can do that algorithmically instead of with memory, so much the better. If you are sure you have something unique, you could just append it to your random value. But finding a globally unique tag is hard. You cannot use IP addresses as tags for many reasons. You might not have an IP address until after authentication. You might not be doing IPCP. Etc. > ... > On reflection, I seem to have convinced at least myself that, as CHAP is > not proof against "active attacks" and as such attacks are far easier > with dialup than with a leased line, CHAP is not nearly as strong on > dialup as we'd like to think. EAP/IPSEC, where are you when I need you? I agree. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Feb 16 21:32:46 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id VAA17829; Sun, 16 Feb 1997 21:32:46 -0500 (EST) Resent-Date: Sun, 16 Feb 1997 21:32:46 -0500 (EST) Message-ID: <01BC1C50.A24DCB60@tang.trisignal.com> From: tang@trisignal.com (tang) To: "'IETF'" Subject: SPAP Date: Sun, 16 Feb 1997 21:30:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"CoS1y.0.AM4.aCy1p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2676 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, SPAP is considered is more secure than the regular PAP by sending the = Encrypted Password to the authenticator. Could you please tell me what = kind of encryption that the SPAP uses to encrypt the Password. Thanks a lot for your help. Tang@trisignal.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 17 08:18:56 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id IAA21713; Mon, 17 Feb 1997 08:18:56 -0500 (EST) Resent-Date: Mon, 17 Feb 1997 08:18:56 -0500 (EST) Date: Sun, 16 Feb 1997 20:17:21 -0500 From: Patrick Klos Message-Id: <199702170117.UAA12525@linux.klos.com> To: ietf-ppp@MERIT.EDU, tang@trisignal.com Subject: Re: SPAP Resent-Message-ID: <"g9_a43.0.cI5.Cg52p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2677 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Hi, >SPAP is considered is more secure than the regular PAP by sending the = >Encrypted Password to the authenticator. Could you please tell me what = >kind of encryption that the SPAP uses to encrypt the Password. > >Thanks a lot for your help. >Tang@trisignal.com SPAP uses a (fairly) simple XOR type hash with a seed an two sources of XOR values (I don't know that these are official encryption terms, so let me know if you don't understand what I mean?). SPAP's protocol also uses several options (in control protocol format) which I have been unable to reverse-engineer. So far, Shiva has decided NOT to release the spec for SPAP (last I knew). ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://web.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 17 14:33:07 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA29286; Mon, 17 Feb 1997 14:33:07 -0500 (EST) Resent-Date: Mon, 17 Feb 1997 14:33:07 -0500 (EST) From: msp@corp.sprintmail.com (Mark Petrovic) Message-Id: <199702171932.NAA01004@manny.ops.sprintisp.net> Subject: Renegotiating MRU To: ietf-ppp@MERIT.EDU Date: Mon, 17 Feb 1997 13:32:01 -0600 (CST) Reply-to: msp@corp.sprintmail.com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Q8J9s3.0.D97.b9B2p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2678 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I understand it is acceptable to renegotiate LCP during a PPP session. What I do not know is whether there are client PPP drivers, and terminal server drivers, currently employed that do this in practice --- specifically, renegotiate MRU if poor line quality is sensed. -- Mark S. Petrovic v 816 854-3152 Technical Operations and Development p 800 724-3508 Sprint Internet Passport PIN 385-6972, or Kansas City, MO 3856972@pagenet.net msp@corp.sprintmail.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 17 14:53:41 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA00316; Mon, 17 Feb 1997 14:53:41 -0500 (EST) Resent-Date: Mon, 17 Feb 1997 14:53:41 -0500 (EST) Date: Mon, 17 Feb 1997 12:53:16 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702171953.MAA01868@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: Renegotiating MRU Resent-Message-ID: <"QitOu2.0.c4.-SB2p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2679 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: msp@corp.sprintmail.com (Mark Petrovic) > I understand it is acceptable to renegotiate LCP during a PPP session. > What I do not know is whether there are client PPP drivers, and > terminal server drivers, currently employed that do this in practice > --- specifically, renegotiate MRU if poor line quality is sensed. I don't see how a renegotiated MRU would help poor lines. The upper layer packets are likely to be whatever size they were before, but more bits will be on the wire as a result of the headers in IP fragments. More bits means more errors, and any error in any IP fragments kills the entire IP packet. Trying to reduce the MRU is unfriendly to many hosts. Once an application starts a TCP connection, it will have negoticated the TCP MSS based on the MTU at that time. Even if you can reduce the MTU, it's likely to be at least painful. You cannot force the MRU to be reduced, because the peer can always reject the MRU option to force 1500. That's what my code does if the peer refuses to offer a reasonable MRU. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 19 08:02:21 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id IAA14523; Wed, 19 Feb 1997 08:02:21 -0500 (EST) Resent-Date: Wed, 19 Feb 1997 08:02:21 -0500 (EST) Date: Wed, 19 Feb 1997 08:00:58 -0500 (EST) From: Connie Leblanc To: ietf-ppp@MERIT.EDU Subject: ECP mailing list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"SpYP1.0.YY3.kcl2p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2680 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Could anyone tell me if there is a mailing list that exists primarily for ECP? Much appreciated. Connie Leblanc cleblanc@gandalf.ca Software Designer (613)274-6500 ex. 8019 Gandalf Technologies Inc. "Opinions expressed by me are not Nepean, Ontario K2E 7M4 necessarily those of a sane person or of Gandalf's." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 19 15:56:43 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id PAA25546; Wed, 19 Feb 1997 15:56:43 -0500 (EST) Resent-Date: Wed, 19 Feb 1997 15:56:43 -0500 (EST) Date: Wed, 19 Feb 1997 15:48:28 -0500 (EST) From: John Shriver Message-Id: <199702192048.PAA00181@shiva-dev.shiva.com> To: msp@corp.sprintmail.com CC: ietf-ppp@MERIT.EDU In-reply-to: <199702171932.NAA01004@manny.ops.sprintisp.net> (msp@corp.sprintmail.com) Subject: Re: Renegotiating MRU Resent-Message-ID: <"q22vI2.0.pE6.vZs2p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2681 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: msp@corp.sprintmail.com (Mark Petrovic) I understand it is acceptable to renegotiate LCP during a PPP session. What I do not know is whether there are client PPP drivers, and terminal server drivers, currently employed that do this in practice --- specifically, renegotiate MRU if poor line quality is sensed. Strikes me as possibly rather pointless in these days of compressing error-correcting modems. They deal with the bad lines and make them look good. In general, I don't think that most systems that serve PPP dial-up clients ever renegotiate LCP, since that would lead to interoperability problems with a lot of PPP dial-up clients. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 19 16:41:52 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id QAA26977; Wed, 19 Feb 1997 16:41:52 -0500 (EST) Resent-Date: Wed, 19 Feb 1997 16:41:52 -0500 (EST) Date: Wed, 19 Feb 1997 16:39:08 -0500 (EST) From: John Shriver Message-Id: <199702192139.QAA03782@shiva-dev.shiva.com> To: tang@trisignal.com CC: ietf-ppp@MERIT.EDU In-reply-to: <01BC1C50.A24DCB60@tang.trisignal.com> Subject: Re: SPAP Resent-Message-ID: <"REwfI.0.6b6.PEt2p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2682 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU We don't make any claims on enhanced security for SPAP over PAP by encrypting the password. As Patrick noted, the encryption is relatively banal, and reversible. We're not interested in publishing details on the encryption. Mostly SPAP is a conduit for a number of enhanced features, like passing parameters for the password cards, dialback, banners, and things like that. Yes, we still consider SPAP proprietary, and don't publish it. The Shiva servers support PAP and CHAP, that's what we expect third-party clients to use. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 20 10:25:18 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11997; Thu, 20 Feb 1997 10:25:18 -0500 (EST) Resent-Date: Thu, 20 Feb 1997 10:25:18 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-bacp-06.txt Date: Thu, 20 Feb 1997 09:35:21 -0500 Sender: cclark@ietf.org Message-ID: <9702200935.aa01592@ietf.org> Resent-Message-ID: <"razNd3.0.mw2.mo63p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2683 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP) Author(s) : C. Richards, K. Smith Filename : draft-ietf-pppext-bacp-06.txt Pages : 22 Date : 02/19/1997 This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol [2]. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). BAP can be used to manage the number of links in a multilink bundle. BAP defines datagrams to co-ordinate adding and removing individual links in a multilink bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multilink connection. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-bacp-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-bacp-06.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-bacp-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970219140614.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-bacp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bacp-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219140614.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 20 11:07:46 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA13054; Thu, 20 Feb 1997 11:07:46 -0500 (EST) Resent-Date: Thu, 20 Feb 1997 11:07:46 -0500 (EST) Message-Id: <330C7781.778F@raleigh.ibm.com> Date: Thu, 20 Feb 1997 11:10:41 -0500 From: Don Grosser Organization: Mobile Networking Access Product Development X-Mailer: Mozilla 2.01Gold (Win95; I) Mime-Version: 1.0 To: ietf-ppp@MERIT.EDU Subject: Revisiting MRU-MRRU Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"04sFw3.0.aB3.BR73p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2684 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU After revisiting the dialog from this thread about MRU-MRRU and RFC 1990, I am still unclear about the relationship between MRU & MRRU. Let's consider the case for MP long sequence numbers: It seems to me that there are 2 possible interpretations: #1.) Non-multilink IP Packet: FF 03 00 21 xx xx xx xx xx xx xx xx xx xx FCS <------------ MRU ----------> Multilink IP Packet: FF 03 00 3D C0 00 00 01 00 21 xx xx xx xx xx xx xx xx xx FCS <----------------- MRU --------------------> <------- MRRU -----------> For this case, it seems that if MRRU > (MRU-6), then MP fragmentation will be REQUIRED on maximum sized packets (info size = MRRU) to insure that packets are not thrown away by the receiving peer's MRU check. #2.) Non-multilink IP Packet: FF 03 00 21 xx xx xx xx xx xx xx xx xx xx FCS <------------ MRU ----------> Multilink IP Packet: FF 03 00 3D C0 00 00 01 00 21 xx xx xx xx xx xx xx xx xx xx FCS <---------- MRU ------------> <---------- MRRU -----------> For this case, it seems that fragmentation would not be REQUIRED until MRRU > MRU (on maximum sized packets). From my experience at the past bakeoff in October, most people were sending MRU=MRRU. This indicates to me that most are taking interpretation #2.) because with interpretation #1.) and MRU=MRRU, maximum sized packets (info = MRRU) REQUIRE MP fragmentation (even over only one link with MP hdrs) and we saw many that were not fragmenting. We are currently using interpretation #2.) and are interested in what interpretation everybody else is taking? Thanks. --Don -- Donald B. Grosser grosser@raleigh.ibm.com IBM Corporation Phone (919)254-2160 Remote Access Products Fax (919)543-7378 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 20 11:37:27 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA14180; Thu, 20 Feb 1997 11:37:27 -0500 (EST) Resent-Date: Thu, 20 Feb 1997 11:37:27 -0500 (EST) Mime-Version: 1.0 Date: Thu, 20 Feb 1997 16:33:35 +0000 Message-ID: <30c7da00@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"cncxX2.0.FT3.1t73p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2685 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I thought this was sufficiently important that it should reach a wider audience. It also seems to answer a question I posted to the (PPP) list back in September (if anyone can remember that far back). Anyway, John Shriver writes (on the L2TP mailing list thread Re: UDP Checksums, in response to Vernon Schryver): >> ] Just for L2TP, how will you deal with VJ header compressed >> ] packets? As is well known, unless you can detect errors in the VJ >> ] header, you will get undetectable data corruption, as packets are >> ] intermingled among VJ-compressed streams. >> >> Gurdeep> The CRC below IP (over which L2TP is carried) will help >> eliminate corrupted packets. >> >> A CRC below IP that eliminates corrupted packets does no good for >> what I'm talking about. In fact, it makes the problem worse, if it >> causes packets to be discarded without notifying the VJ >> decompressor to toss future VJ compressed packets. This also >> applies to packets detected and discarded by a UDP checksum check. >> >> I may be asking a dumb question, and I know it is not very relevant >> to whether UDP checksums are a good idea. What I'm asking is >> whether one ultimate PPP peer or the other must know the L2TP >> tunnel exists so that VJ slot ID compression can be not >> Conf-Requested or Conf-Rejected. > >It sounds like anything that tunnels PPP over the Internet ought to >be configured to disable VJ slot ID compression. In L2F, I'm already >used to having to extensively configure the NAS's PPP LCP >configuration, to match the HG's narrower available set of LCP >options. I'm sure that the same can be done at the L2TP LAC (or LNS, >depending on the PPP LCP negotiation model used). > >Certainly a point worth making as a comment in the spec. Vernon then goes on to say: ] Others have pointed out in the main PPP working group that VJ header ] compression even without slot ID compression does not deal well with ] links with probable silent packet loss. If you don't get the ] uncompressed packet that reassigns a slot-ID, you will stuff the ] next VJ compressed packet you receive into the wrong TCP stream. ] You won't know that anything is wrong until you finally get an ] uncompressed packet for the old stream. So it looks like the answer to my question from last September is that tunnelling does breaks VJ compression. On that assumption, what do "oh-so-smart" TAs do about VJ compression ? If they allow VJ compression to be negotiated, what do they do when they receive frames with CRC errors ? If they discard them, the same problem arises as for L2TP. So do they transmit a frame on the opposite interface with a deliberately bad CRC each time they receive a frame with a bad CRC ? --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 20 11:57:46 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA14798; Thu, 20 Feb 1997 11:57:46 -0500 (EST) Resent-Date: Thu, 20 Feb 1997 11:57:46 -0500 (EST) Date: Thu, 20 Feb 1997 11:55:06 -0500 (EST) From: John Shriver Message-Id: <199702201655.LAA16179@shiva-dev.shiva.com> To: grosser@raleigh.ibm.com CC: ietf-ppp@MERIT.EDU In-reply-to: <330C7781.778F@raleigh.ibm.com> (message from Don Grosser on Thu, 20 Feb 1997 11:10:41 -0500) Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"R0wA32.0.vc3.4A83p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2686 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I use interpretation 1. The MRRU for a bundle has to affect the upper layers in exactly the way an MRU for a link would. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 20 12:09:10 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id MAA15319; Thu, 20 Feb 1997 12:09:10 -0500 (EST) Resent-Date: Thu, 20 Feb 1997 12:09:10 -0500 (EST) Message-Id: <9702201705.AA23109@adtrn-ws01.adtran.com> From: "Kyle Farnsworth" To: "Jonathan Goodchild" , Subject: Re: VJ compression, Tunneling and TAs Date: Thu, 20 Feb 1997 11:10:01 -0600 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"H07CR3.0.fk3.kK83p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2687 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: Jonathan Goodchild > So it looks like the answer to my question from last September is that > tunnelling does breaks VJ compression. > > On that assumption, what do "oh-so-smart" TAs do about VJ compression ? > > If they allow VJ compression to be negotiated, what do they do when > they receive frames with CRC errors ? > > If they discard them, the same problem arises as for L2TP. So do they > transmit a frame on the opposite interface with a deliberately bad CRC > each time they receive a frame with a bad CRC ? > Yes. Datagrams pass through untouched with the exception of aborts or non-octet alignment errors. In which case they are dropped. Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Kyle - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 20 12:11:08 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id MAA15580; Thu, 20 Feb 1997 12:11:08 -0500 (EST) Resent-Date: Thu, 20 Feb 1997 12:11:08 -0500 (EST) Date: Thu, 20 Feb 1997 09:53:44 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702201653.JAA12501@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU, l2tp@ca.newbridge.com Subject: VJ compression, Tunneling and TAs Resent-Message-ID: <"8gmls.0.wm3.QM83p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2689 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > ... > So it looks like the answer to my question from last September is that > tunnelling does breaks VJ compression. > > On that assumption, what do "oh-so-smart" TAs do about VJ compression ? > > If they allow VJ compression to be negotiated, what do they do when > they receive frames with CRC errors ? That's a neat idea that also solves the problem of VJ header compression with slot-ID compression through L2TP tunnels, at least for modems if not ISDN. In the one direction, the end of the tunnel can tell the IPCP code about packet loss, after having detected using the same mechanisms it uses to ensure packet sequencing. In the other direction, the end of the tunnel can send a VJ header compressed packet with bad PPP FCS over the modem to the PPP client. Even with ISDN, where it might be hard to generate a bad FCS, the end of the tunnel or super-smart ISDN TA could track slot numbers and drop all VJ header compressed packets that the peer might misinterpret. With or without slot ID compression the TCP systems will soon notice the loss, retransmit, and cause an uncompressed packet. Since this would happen only when TCP segments have already been lost, about the worst that would happen is a full timeout and slow-start instead of fast-retransmission, which is better than undetected corruption of TCP data. The smart TA or tunnel-end could get really tricky, and instead of dropping, convert corrupting VJ compressed packets to uncompressed packets that are TCP window probes, causing the TCP system to send ACKs, which would cause fast retransmissions. (can we patent this?) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 20 12:09:35 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id MAA15367; Thu, 20 Feb 1997 12:09:35 -0500 (EST) Resent-Date: Thu, 20 Feb 1997 12:09:35 -0500 (EST) Message-Id: <199702201709.MAA17643@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: grosser@raleigh.ibm.com, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Thu, 20 Feb 1997 12:08:53 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"GzgLP.0.il3.8L83p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2688 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Interpretation #1 is correct and is what we use. The MRU is=20 independent of the protocol type (interpretation #2 would require a=20 different meaning of MRU for MP packets, which would violate RFC=20 1661). It is the maximum acceptable length of the info field in a PPP=20 packet. The MRRU is the maximum length of the info field of the=20 reassembled packet (MRU of the bundle). >>Reply to message from Don Grosser (grosser@raleigh.ibm.com) dated=20 2/20/97 11:15 AM > After revisiting the dialog from this thread about > MRU-MRRU and RFC > 1990, I am still unclear about the relationship between > MRU & MRRU. >=20 > Let's consider the case for MP long sequence numbers: > It seems to me that there are 2 possible interpretations: >=20 > #1.) > Non-multilink IP Packet: > =20 > FF 03 00 21 xx xx xx xx xx xx xx xx xx xx FCS > <------------ MRU ----------> > =20 > Multilink IP Packet: > =20 > FF 03 00 3D C0 00 00 01 00 21 xx xx xx xx xx xx xx xx > xx FCS > <----------------- MRU --------------------> > <------- MRRU -----------> >=20 > For this case, it seems that if MRRU > (MRU-6), then MP > fragmentation > will be REQUIRED on maximum sized packets (info > size =3D MRRU) to=20 > insure that packets are not thrown away by the > receiving peer's MRU=20 > check.=20 >=20 > #2.) > Non-multilink IP Packet: > =20 > FF 03 00 21 xx xx xx xx xx xx xx xx xx xx FCS > <------------ MRU ----------> > =20 > Multilink IP Packet: > =20 > FF 03 00 3D C0 00 00 01 00 21 xx xx xx xx xx xx xx xx > xx xx FCS > <---------- MRU ------------> > <---------- MRRU -----------> >=20 > For this case, it seems that fragmentation would not be > REQUIRED > until MRRU > MRU (on maximum sized packets). >=20 > >From my experience at the past bakeoff in October, > most people > were sending MRU=3DMRRU. This indicates to me that > most are taking > interpretation #2.) because with interpretation #1.) and > MRU=3DMRRU, > maximum sized packets (info =3D MRRU) REQUIRE MP > fragmentation=20 > (even over only one link with MP hdrs) and we saw > many that were > not fragmenting. >=20 > We are currently using interpretation #2.) and are > interested in what > interpretation everybody else is taking? >=20 > Thanks. > --Don > --=20 > Donald B. Grosser =20 > grosser@raleigh.ibm.com > IBM Corporation Phone > (919)254-2160 > Remote Access Products Fax > (919)543-7378 >=20 >=20 >>End of message _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 20 13:50:16 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id NAA18857; Thu, 20 Feb 1997 13:50:16 -0500 (EST) Resent-Date: Thu, 20 Feb 1997 13:50:16 -0500 (EST) From: Gina.Deplanche@proteon.com (Gina DePlanche) Message-Id: <9702201849.AA28257@banacek.proteon.com> Subject: Re: Revisiting MRU-MRRU To: grosser@raleigh.ibm.com (Don Grosser) Date: Thu, 20 Feb 1997 13:49:25 -0500 (EST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <330C7781.778F@raleigh.ibm.com> from "Don Grosser" at Feb 20, 97 11:10:41 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BDrfA3.0.Gc4.Up93p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2690 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Don, We are using interpretation #2 for the following reasons: 1) MRU is the PPP _payload_ size offered to upper layers when MP is OFF. Additional PPP encapsulation is NOT counted in the MRU. 2) MRRU is the PPP _payload_ size offered to upper layers when MP is ON. Once again, PPP encapsulations are not counted in the MRRU. 3) The largest MP fragment must accomodate MRU payload bytes BEFORE adding any PPP encapsulations including multilink itself. Some number of these fragments may be received to assemble an MRRU byte payload. - Gina According to Don Grosser ... -> ->After revisiting the dialog from this thread about MRU-MRRU and RFC ->1990, I am still unclear about the relationship between MRU & MRRU. -> ->Let's consider the case for MP long sequence numbers: ->It seems to me that there are 2 possible interpretations: -> ->#1.) ->Non-multilink IP Packet: -> ->FF 03 00 21 xx xx xx xx xx xx xx xx xx xx FCS -> <------------ MRU ----------> -> ->Multilink IP Packet: -> ->FF 03 00 3D C0 00 00 01 00 21 xx xx xx xx xx xx xx xx xx FCS -> <----------------- MRU --------------------> -> <------- MRRU -----------> -> ->For this case, it seems that if MRRU > (MRU-6), then MP fragmentation ->will be REQUIRED on maximum sized packets (info size = MRRU) to ->insure that packets are not thrown away by the receiving peer's MRU ->check. -> ->#2.) ->Non-multilink IP Packet: -> ->FF 03 00 21 xx xx xx xx xx xx xx xx xx xx FCS -> <------------ MRU ----------> -> ->Multilink IP Packet: -> ->FF 03 00 3D C0 00 00 01 00 21 xx xx xx xx xx xx xx xx xx xx FCS -> <---------- MRU ------------> -> <---------- MRRU -----------> -> ->For this case, it seems that fragmentation would not be REQUIRED ->until MRRU > MRU (on maximum sized packets). -> ->>From my experience at the past bakeoff in October, most people ->were sending MRU=MRRU. This indicates to me that most are taking ->interpretation #2.) because with interpretation #1.) and MRU=MRRU, ->maximum sized packets (info = MRRU) REQUIRE MP fragmentation ->(even over only one link with MP hdrs) and we saw many that were ->not fragmenting. -> ->We are currently using interpretation #2.) and are interested in what ->interpretation everybody else is taking? -> ->Thanks. ->--Don -- Gina M. DePlanche | OpenROUTE Networks, Inc. gmd@openroute.com | A subsidiary of Proteon, Inc. (508) 898-2800 x2541 | 9 Technology Drive, Westborough, MA Fax: (508) 898-2547 | 01581-1799 MailStop #23 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 20 14:37:54 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA20288; Thu, 20 Feb 1997 14:37:54 -0500 (EST) Resent-Date: Thu, 20 Feb 1997 14:37:54 -0500 (EST) Date: Thu, 20 Feb 1997 12:37:25 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702201937.MAA13149@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"hLg-P1.0.hy4.8WA3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2691 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > We are using interpretation #2 for the following reasons: > > 1) MRU is the PPP _payload_ size offered to upper layers when MP > is OFF. Additional PPP encapsulation is NOT counted in the MRU. > > 2) MRRU is the PPP _payload_ size offered to upper layers when > MP is ON. Once again, PPP encapsulations are not counted in the MRRU. What are the "upper layers"? Why isn't the layering this way: IP,IPX, etc MP PPP So that the MRU is the payload size that PPP gives MP, and the MRRU the payload size that MP gives IP, IPX, etc? > 3) The largest MP fragment must accomodate MRU payload bytes > BEFORE adding any PPP encapsulations including multilink itself. Some > number of these fragments may be received to assemble an MRRU byte > payload. That does not and cannot work. It means that the receiver cannot know how big the incoming PPP packets might be. It violates RFC 1661, since it means that some PPP packets will be larger than 1500 bytes when LCP negotiations occurred without any MRU options. > ->#1.) > ->Non-multilink IP Packet: > -> > ->FF 03 00 21 xx xx xx xx xx xx xx xx xx xx FCS > -> <------------ MRU ----------> > -> > ->Multilink IP Packet: > -> > ->FF 03 00 3D C0 00 00 01 00 21 xx xx xx xx xx xx xx xx xx FCS > -> <----------------- MRU --------------------> > -> <------- MRRU -----------> > ... > ->#2.) > ->Non-multilink IP Packet: > -> > ->FF 03 00 21 xx xx xx xx xx xx xx xx xx xx FCS > -> <------------ MRU ----------> > -> > ->Multilink IP Packet: > -> > ->FF 03 00 3D C0 00 00 01 00 21 xx xx xx xx xx xx xx xx xx xx FCS > -> <---------- MRU ------------> > -> <---------- MRRU -----------> #2 makes no sense for several reasons. One big one is that it requires that the LCP MRU have a different meaning depending on whether the packet has an MP header. A single link can carry intermingled MP and non-MP traffic. Would you really want to have to look for the 0x3d to know if you have a babble frame? > ->For this case, it seems that fragmentation would not be REQUIRED > ->until MRRU > MRU (on maximum sized packets). That is true. > ->>From my experience at the past bakeoff in October, most people > ->were sending MRU=MRRU. This indicates to me that most are taking > ->interpretation #2.) because with interpretation #1.) and MRU=MRRU, > ->maximum sized packets (info = MRRU) REQUIRE MP fragmentation > ->(even over only one link with MP hdrs) and we saw many that were > ->not fragmenting. Perhaps you saw only packets that were small enough. You cannot know if they were doing #2 unless you saw packets that violate RFC 1661 and were bigger than the negoiated or defaulted LCP MRU. > ->We are currently using interpretation #2.) and are interested in what > ->interpretation everybody else is taking? Until the message from Proteon, I would have said you are alone in your misinterpertation of RFC 1990 and 1661. I'm sorry to be so blunt, but that is what it is. The MTU problems implied by the extra bytes in the MP header were thrashed out in this mailing list before RFC 1717 was given a number. The words on the bottom of page 3 of RFC 1990 almost clearly say that #1 is the right answer. They probably need to be made more clear. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 20 14:41:05 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA20583; Thu, 20 Feb 1997 14:41:05 -0500 (EST) Resent-Date: Thu, 20 Feb 1997 14:41:05 -0500 (EST) Date: Thu, 20 Feb 1997 14:37:59 -0500 (EST) From: John Shriver Message-Id: <199702201937.OAA28003@shiva-dev.shiva.com> To: Gina.Deplanche@proteon.com CC: grosser@raleigh.ibm.com, ietf-ppp@MERIT.EDU In-reply-to: <9702201849.AA28257@banacek.proteon.com> (Gina.Deplanche@proteon.com) Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"692F43.0.115.4ZA3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2692 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I differ with Gina. To the link in a bundle, the MP header is data -- payload. The LCP negotiation of MRU is important, since it may be negotiating on behalf of a device driver or hardware that has a limited MTU. We can't change that definition, the hardware/driver has to handle MRU plus 4 bytes header, 2 bytes CRC, and byte-stuffing. (There's some additional fudge that's added for one of the briding protocols, I deliberately avoid remembering it.) If you use option 2, you have changed the hardware's definition, it has to accomodate 4 or 6 bytes of MP header. You can't make that change retroactively. That is, the MRU defines two things: (1) the maximum size of the packet on the wire, and (2) the number of bytes the network layer protocol can put in the packet. The MRRU defines only one thing: the number of bytes the network protocol can put in the packet. One use of MP is to allow network layer sizes larger than the MRU, even on a single link. I'm not saying it's silly having this interpretation problem. I asked Keith about it when I started implementation. I think it is something that ought to be clarified by a concrete example in the next version of the RFC. Thankfully, most of us are robust about packets that creep over MRU and MRRU. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 01:49:19 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id BAA03439; Fri, 21 Feb 1997 01:49:19 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 01:49:19 -0500 (EST) From: pillai@multitech.com (N. Balasubramania Pillai) To: grosser@raleigh.ibm.com, ietf-ppp@MERIT.EDU (PPP ML) Message-ID: <1997Feb21.004400.1944.51441@multitech.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: Multi-Tech Systems, Inc. Date: Fri, 21 Feb 1997 00:48:22 -0600 Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"diKle2.0.Lr.8LK3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2693 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > After revisiting the dialog from this thread about MRU-MRRU and RFC > 1990, I am still unclear about the relationship between MRU & MRRU. > > Let's consider the case for MP long sequence numbers: > It seems to me that there are 2 possible interpretations: > > #1.) > Non-multilink IP Packet: > > FF 03 00 21 xx xx xx xx xx xx xx xx xx xx FCS > <------------ MRU ----------> > > Multilink IP Packet: > > FF 03 00 3D C0 00 00 01 00 21 xx xx xx xx xx xx xx xx xx FCS > <----------------- MRU --------------------> > <------- MRRU -----------> > > For this case, it seems that if MRRU > (MRU-6), then MP fragmentation > will be REQUIRED on maximum sized packets (info size =3D MRRU) to > insure that packets are not thrown away by the receiving peer's MRU > check. > > #2.) > Non-multilink IP Packet: > > FF 03 00 21 xx xx xx xx xx xx xx xx xx xx FCS > <------------ MRU ----------> > > Multilink IP Packet: > > FF 03 00 3D C0 00 00 01 00 21 xx xx xx xx xx xx xx xx xx xx FCS > <---------- MRU ------------> > <---------- MRRU -----------> > > For this case, it seems that fragmentation would not be REQUIRED > until MRRU > MRU (on maximum sized packets). > > From my experience at the past bakeoff in October, most people > were sending MRU=3DMRRU. This indicates to me that most are taking > interpretation #2.) because with interpretation #1.) and MRU=3DMRRU, > maximum sized packets (info =3D MRRU) REQUIRE MP fragmentation > (even over only one link with MP hdrs) and we saw many that were > not fragmenting. > > We are currently using interpretation #2.) and are interested in what > interpretation everybody else is taking? > Hi I feel there is some thing wrong in the way the MRRU is interpreted. Correct me if I am wrong MRU is the maximum acceptable length of the info field in a PPP packet. The MRRU is the maximum length of the info field of the reassembled packet (ie MRU of the bundle) when usinng MP. MRRU has nothing to do with MRU. It can be grater than, equal to or less than MRU's of the the individual links (remember MRU can be different for the different links in a multilink bundle.) When using MP, the upper layer's (ie the protocl stacks) see a virtual link with a MTU which is equal to MRRU. The MP module decides whether the packet needs fragmentation and send the MP fragments on the individual links. The individual fragments, along with MP headers are, the _payload_ or data for the individual PPP links. So the individual fragments, along with MP headers should not exceed the MRU of that link on which the fragment is send. In case if there is only one link in the Multilink bundle, still the same rule holds. Regards Balu - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 02:24:01 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id CAA04254; Fri, 21 Feb 1997 02:24:01 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 02:24:01 -0500 (EST) Message-ID: <330D4BB7.11D5@gw2.csr.co.jp> Date: Fri, 21 Feb 1997 16:16:07 +0900 From: Masayuki KOBAYASHI Reply-To: kobayasi@gw2.csr.co.jp Organization: CSR X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ietf-ppp@MERIT.EDU Subject: TEST,Please Ignoure Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Resent-Message-ID: <"XQGwB2.0.821.AsK3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2694 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Is ietf-ppp@MERIT.EDU working? -- kobayasi - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 05:26:43 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id FAA06355; Fri, 21 Feb 1997 05:26:43 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 05:26:43 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 10:17:58 +0000 Message-ID: <30d78140@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Revisiting MRU-MRRU To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"de7cq.0.-Y1.-WN3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2695 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: >Until the message from Proteon, I would have said you are alone in your >misinterpertation of RFC 1990 and 1661. I'm sorry to be so blunt, but >that is what it is. The MTU problems implied by the extra bytes in the >MP header were thrashed out in this mailing list before RFC 1717 was >given a number. >The words on the bottom of page 3 of RFC 1990 almost clearly say that >#1 is the right answer. They probably need to be made more clear. Hmmm.. while I agree with Vernon, I had a feeling that there were different interpretations of the MRU & MRRU, which is why I asked my original question. It seems to me that there are actually 3 pieces of information required about the MRU, and only 2 of them are negotiated. If you have IP, CCP, ECP & MP then the relationship is: IP -------- "Inner MRU" CCP ECP -------- MRRU MP -------- "Outer MRU" LCP Or to put it another way: FF 03 00 3D C0 00 00 00 53 ee ee FD nn 21 45 ip ip ip ip ip FCS <-------------- Outer MRU -----------------------> <------------- MRRU --------------> <-- Inner MRU --> (Note for the purposes of illustration I've drawn this with Null encryption and compression - obviously the values would change for the real thing) The Outer MRU is negotiated by the LCP MRU option, and obviously the MRRU is negotiated by the MRRU option. There is no explicit information about the Inner MRU, and I think this is where the problem lies. Now, in my software, I only have one sort of buffers, so my maximum receive unit size at any layer is the same (i.e. Outer MRU == MRRU == Inner MRU), so it does make sense to negotiate MRU and MRRU to be the same. On the other hand, it is common to negotiate MRU larger than the Inner MRU to allow space for compression headers (and even expansion of the data), etc. I think it would be better to negotiate the inner MRU explcitly, so I would like to propose a new LCP option for this purpose. The default value would be the same as the MRRU (if MP is negotiated) or the MRU (if not using MP), so it would therefore not break any existing implementations. n.n. Inner-Maximum-Receive-Unit (IMRU) Description This Configuration Option may be sent to inform the peer to inform the peer of the maximum size of packet that can be delivered to the Network Layer. The default value is the same as the Maximum-Receive-Unit if the Multilink Protocol is not negotiated, or the Maximum-Reconstructed-Receive-Unit if the Multilink Protocol is negotiated. A summary of the Inner-Maximum-Receive-Unit Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Inner-Maximum-Receive-Unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Length 4 Inner-Maximum-Receive-Unit The Inner-Maximum-Receive-Unit field is two octets, and specifies the maximum number of octets that can be delivered to the Network Layer. Of course, the IMRU could be renamed "Payload-Maximum-Receive-Unit", or anything else that is clear and unambiguous. Any comments ? Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 08:51:57 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id IAA08293; Fri, 21 Feb 1997 08:51:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 08:51:57 -0500 (EST) Date: Fri, 21 Feb 1997 08:55:20 -0500 From: Patrick Klos Message-Id: <199702211355.IAA25740@linux.klos.com> To: grosser@raleigh.ibm.com, ietf-ppp@MERIT.EDU, pillai@multitech.com Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"5oEWu1.0.G12.tXQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2696 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >I feel there is some thing wrong in the way the MRRU is interpreted. >Correct me if I am wrong > >MRU is the maximum acceptable length of the info field in a PPP packet. Yes. Noone can deny this. (well, I think there are some NBFCP people out there who might have a slight problem with this, but that's another story!) >The MRRU is the maximum length of the info field of the reassembled >packet (ie MRU of the bundle) when usinng MP. Yes again. This is my understanding as well. >MRRU has nothing to do with MRU. It can be grater than, equal to or >less than MRU's of the the individual links (remember MRU can be >different for the different links in a multilink bundle.) YES! This I think is one of the important points that some people are missing. There is NO explicit relationship between MRU and MRRU! Like you said, the MRU can be less than, equal to, OR greater than the MRRU. In some situations, your system can define MRU in relation to MRRU or visa versa, but the specs don't actually tie one to the other. Obviously, the different combinations have their own ramifications, but any decent MP implementation will be able to handle all possible situations. >When using MP, the upper layer's (ie the protocl stacks) see a virtual >link with a MTU which is equal to MRRU. The MP module decides whether >the packet needs fragmentation and send the MP fragments on the >individual links. The individual fragments, along with MP headers are, >the _payload_ or data for the individual PPP links. So the individual >fragments, along with MP headers should not exceed the MRU of that link >on which the fragment is send. > >In case if there is only one link in the Multilink bundle, still the >same rule holds. This is exactly how I see it also. So unless we're missing something, it doesn't get much simpler than this (Thanks Balu!). ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://web.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 09:18:51 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08909; Fri, 21 Feb 1997 09:18:51 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:51 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 09:45:00 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09857; Fri, 21 Feb 1997 09:45:00 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:45:00 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:43:16 +0000 Message-ID: <30db4cb0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Revisiting MRU-MRRU To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"Ai1LR2.0.iP2.cJR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2699 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From Patrick Klos: > >MRRU has nothing to do with MRU. It can be grater than, equal to or > >less than MRU's of the the individual links (remember MRU can be > >different for the different links in a multilink bundle.) >YES! This I think is one of the important points that some people >are missing. Well, I can only speak for myself, but I did not miss that point - it simply wasn't relevant to the case we were discussing, which was about sending a whole MP fragment: to be able to send a whole fragment of size MRRU then MRU must be >= MRRU+5. > >When using MP, the upper layer's (ie the protocol stacks) see a > >virtual link with a MTU which is equal to MRRU. Actually, this is only guaranteed when using neither compression nor encryption. Because of the overhead of the encryption header & padding, you may need the MRRU to be greater than the upper layer MTU. Which is why I think that the upper layer MTU and MRU need to be negotiated explicitly. --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 09:41:27 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09600; Fri, 21 Feb 1997 09:41:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 09:59:57 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA10453; Fri, 21 Feb 1997 09:59:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:59:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536375@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:46:15 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"l5ZjX.0.-Y2.cXR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2700 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:46:12 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00585 for ; Fri, 21 Feb 1997 23:45:41 +0900 Received: by fw.nikkeibp.co.jp; id XAA06583; Fri, 21 Feb 1997 23:45:48 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006575; Fri, 21 Feb 97 23:45:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05178 for ; Fri, 21 Feb 1997 23:44:17 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09854; Fri, 21 Feb 1997 09:44:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:44:59 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:43:16 +0000 Message-ID: <30db4cb0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Revisiting MRU-MRRU To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"Ai1LR2.0.iP2.cJR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2699 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From Patrick Klos: > >MRRU has nothing to do with MRU. It can be grater than, equal to or > >less than MRU's of the the individual links (remember MRU can be > >different for the different links in a multilink bundle.) >YES! This I think is one of the important points that some people >are missing. Well, I can only speak for myself, but I did not miss that point - it simply wasn't relevant to the case we were discussing, which was about sending a whole MP fragment: to be able to send a whole fragment of size MRRU then MRU must be >= MRRU+5. > >When using MP, the upper layer's (ie the protocol stacks) see a > >virtual link with a MTU which is equal to MRRU. Actually, this is only guaranteed when using neither compression nor encryption. Because of the overhead of the encryption header & padding, you may need the MRRU to be greater than the upper layer MTU. Which is why I think that the upper layer MTU and MRU need to be negotiated explicitly. --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:02:25 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA10779; Fri, 21 Feb 1997 10:02:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:02:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537301@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:01:41 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ZmAPX.0.6e2.rZR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2701 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:01:39 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01414 for ; Sat, 22 Feb 1997 00:01:08 +0900 Received: by fw.nikkeibp.co.jp; id AAA07433; Sat, 22 Feb 1997 00:01:15 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007421; Sat, 22 Feb 97 00:01:01 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05428 for ; Fri, 21 Feb 1997 23:59:52 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA10449; Fri, 21 Feb 1997 09:59:56 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:59:56 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536375@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:46:15 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"l5ZjX.0.-Y2.cXR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2700 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:46:12 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00585 for ; Fri, 21 Feb 1997 23:45:41 +0900 Received: by fw.nikkeibp.co.jp; id XAA06583; Fri, 21 Feb 1997 23:45:48 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006575; Fri, 21 Feb 97 23:45:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05178 for ; Fri, 21 Feb 1997 23:44:17 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09854; Fri, 21 Feb 1997 09:44:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:44:59 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:43:16 +0000 Message-ID: <30db4cb0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Revisiting MRU-MRRU To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"Ai1LR2.0.iP2.cJR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2699 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From Patrick Klos: > >MRRU has nothing to do with MRU. It can be grater than, equal to or > >less than MRU's of the the individual links (remember MRU can be > >different for the different links in a multilink bundle.) >YES! This I think is one of the important points that some people >are missing. Well, I can only speak for myself, but I did not miss that point - it simply wasn't relevant to the case we were discussing, which was about sending a whole MP fragment: to be able to send a whole fragment of size MRRU then MRU must be >= MRRU+5. > >When using MP, the upper layer's (ie the protocol stacks) see a > >virtual link with a MTU which is equal to MRRU. Actually, this is only guaranteed when using neither compression nor encryption. Because of the overhead of the encryption header & padding, you may need the MRRU to be greater than the upper layer MTU. Which is why I think that the upper layer MTU and MRU need to be negotiated explicitly. --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:10:16 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11278; Fri, 21 Feb 1997 10:10:16 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:10:16 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537456@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:04:16 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"65wJT2.0.rl2.HhR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2702 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:04:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01565 for ; Sat, 22 Feb 1997 00:03:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA07603; Sat, 22 Feb 1997 00:03:50 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007598; Sat, 22 Feb 97 00:03:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05476 for ; Sat, 22 Feb 1997 00:02:21 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA10776; Fri, 21 Feb 1997 10:02:22 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:02:22 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537301@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:01:41 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ZmAPX.0.6e2.rZR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2701 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:01:39 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01414 for ; Sat, 22 Feb 1997 00:01:08 +0900 Received: by fw.nikkeibp.co.jp; id AAA07433; Sat, 22 Feb 1997 00:01:15 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007421; Sat, 22 Feb 97 00:01:01 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05428 for ; Fri, 21 Feb 1997 23:59:52 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA10449; Fri, 21 Feb 1997 09:59:56 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:59:56 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536375@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:46:15 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"l5ZjX.0.-Y2.cXR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2700 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:46:12 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00585 for ; Fri, 21 Feb 1997 23:45:41 +0900 Received: by fw.nikkeibp.co.jp; id XAA06583; Fri, 21 Feb 1997 23:45:48 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006575; Fri, 21 Feb 97 23:45:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05178 for ; Fri, 21 Feb 1997 23:44:17 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09854; Fri, 21 Feb 1997 09:44:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:44:59 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:43:16 +0000 Message-ID: <30db4cb0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Revisiting MRU-MRRU To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"Ai1LR2.0.iP2.cJR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2699 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From Patrick Klos: > >MRRU has nothing to do with MRU. It can be grater than, equal to or > >less than MRU's of the the individual links (remember MRU can be > >different for the different links in a multilink bundle.) >YES! This I think is one of the important points that some people >are missing. Well, I can only speak for myself, but I did not miss that point - it simply wasn't relevant to the case we were discussing, which was about sending a whole MP fragment: to be able to send a whole fragment of size MRRU then MRU must be >= MRRU+5. > >When using MP, the upper layer's (ie the protocol stacks) see a > >virtual link with a MTU which is equal to MRRU. Actually, this is only guaranteed when using neither compression nor encryption. Because of the overhead of the encryption header & padding, you may need the MRRU to be greater than the upper layer MTU. Which is why I think that the upper layer MTU and MRU need to be negotiated explicitly. --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:12:34 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11486; Fri, 21 Feb 1997 10:12:34 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:12:34 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537911@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:11:51 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VPzKg.0.9p2.RjR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2703 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:11:48 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01960 for ; Sat, 22 Feb 1997 00:11:18 +0900 Received: by fw.nikkeibp.co.jp; id AAA07979; Sat, 22 Feb 1997 00:11:24 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007966; Sat, 22 Feb 97 00:11:07 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05614 for ; Sat, 22 Feb 1997 00:10:02 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11275; Fri, 21 Feb 1997 10:10:14 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:10:14 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537456@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:04:16 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"65wJT2.0.rl2.HhR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2702 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:04:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01565 for ; Sat, 22 Feb 1997 00:03:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA07603; Sat, 22 Feb 1997 00:03:50 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007598; Sat, 22 Feb 97 00:03:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05476 for ; Sat, 22 Feb 1997 00:02:21 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA10776; Fri, 21 Feb 1997 10:02:22 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:02:22 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537301@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:01:41 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ZmAPX.0.6e2.rZR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2701 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:01:39 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01414 for ; Sat, 22 Feb 1997 00:01:08 +0900 Received: by fw.nikkeibp.co.jp; id AAA07433; Sat, 22 Feb 1997 00:01:15 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007421; Sat, 22 Feb 97 00:01:01 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05428 for ; Fri, 21 Feb 1997 23:59:52 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA10449; Fri, 21 Feb 1997 09:59:56 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:59:56 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536375@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:46:15 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"l5ZjX.0.-Y2.cXR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2700 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:46:12 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00585 for ; Fri, 21 Feb 1997 23:45:41 +0900 Received: by fw.nikkeibp.co.jp; id XAA06583; Fri, 21 Feb 1997 23:45:48 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006575; Fri, 21 Feb 97 23:45:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05178 for ; Fri, 21 Feb 1997 23:44:17 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09854; Fri, 21 Feb 1997 09:44:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:44:59 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:43:16 +0000 Message-ID: <30db4cb0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Revisiting MRU-MRRU To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"Ai1LR2.0.iP2.cJR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2699 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From Patrick Klos: > >MRRU has nothing to do with MRU. It can be grater than, equal to or > >less than MRU's of the the individual links (remember MRU can be > >different for the different links in a multilink bundle.) >YES! This I think is one of the important points that some people >are missing. Well, I can only speak for myself, but I did not miss that point - it simply wasn't relevant to the case we were discussing, which was about sending a whole MP fragment: to be able to send a whole fragment of size MRRU then MRU must be >= MRRU+5. > >When using MP, the upper layer's (ie the protocol stacks) see a > >virtual link with a MTU which is equal to MRRU. Actually, this is only guaranteed when using neither compression nor encryption. Because of the overhead of the encryption header & padding, you may need the MRRU to be greater than the upper layer MTU. Which is why I think that the upper layer MTU and MRU need to be negotiated explicitly. --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:16:58 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11950; Fri, 21 Feb 1997 10:16:58 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:58 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:24:56 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12814; Fri, 21 Feb 1997 10:24:56 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:56 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538650@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yNN8o2.0.Y73.wuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2707 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02544 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08723; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008710; Sat, 22 Feb 97 00:23:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05778 for ; Sat, 22 Feb 1997 00:22:13 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12532; Fri, 21 Feb 1997 10:22:52 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:52 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:25:01 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12830; Fri, 21 Feb 1997 10:25:01 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:25:01 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538648@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:08 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yacTi2.0.n73.zuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2708 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02546 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08724; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008715; Sat, 22 Feb 97 00:23:37 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05785 for ; Sat, 22 Feb 1997 00:22:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12243; Fri, 21 Feb 1997 10:20:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:20:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538344@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:19:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"GUGsS.0.z-2.ArR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2705 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:19:01 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02265 for ; Sat, 22 Feb 1997 00:18:30 +0900 Received: by fw.nikkeibp.co.jp; id AAA08352; Sat, 22 Feb 1997 00:18:36 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008333; Sat, 22 Feb 97 00:18:20 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05713 for ; Sat, 22 Feb 1997 00:17:08 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11947; Fri, 21 Feb 1997 10:16:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:27:29 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13210; Fri, 21 Feb 1997 10:27:29 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:29 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:38 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"cyFbL2.0.eD3.LxR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2709 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:37 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02675 for ; Sat, 22 Feb 1997 00:26:06 +0900 Received: by fw.nikkeibp.co.jp; id AAA08853; Sat, 22 Feb 1997 00:26:13 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008824; Sat, 22 Feb 97 00:25:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05817 for ; Sat, 22 Feb 1997 00:24:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12805; Fri, 21 Feb 1997 10:24:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538650@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yNN8o2.0.Y73.wuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2707 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02544 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08723; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008710; Sat, 22 Feb 97 00:23:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05778 for ; Sat, 22 Feb 1997 00:22:13 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12532; Fri, 21 Feb 1997 10:22:52 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:52 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:20:50 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12246; Fri, 21 Feb 1997 10:20:50 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:20:50 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538344@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:19:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"GUGsS.0.z-2.ArR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2705 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:19:01 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02265 for ; Sat, 22 Feb 1997 00:18:30 +0900 Received: by fw.nikkeibp.co.jp; id AAA08352; Sat, 22 Feb 1997 00:18:36 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008333; Sat, 22 Feb 97 00:18:20 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05713 for ; Sat, 22 Feb 1997 00:17:08 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11947; Fri, 21 Feb 1997 10:16:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:29:53 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13626; Fri, 21 Feb 1997 10:29:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:29:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538928@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:28:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VrcmD2.0.aK3.fzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2711 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:28:44 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02799 for ; Sat, 22 Feb 1997 00:28:13 +0900 Received: by fw.nikkeibp.co.jp; id AAA08979; Sat, 22 Feb 1997 00:28:19 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008970; Sat, 22 Feb 97 00:28:02 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05873 for ; Sat, 22 Feb 1997 00:26:54 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13206; Fri, 21 Feb 1997 10:27:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:38 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"cyFbL2.0.eD3.LxR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2709 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:37 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02675 for ; Sat, 22 Feb 1997 00:26:06 +0900 Received: by fw.nikkeibp.co.jp; id AAA08853; Sat, 22 Feb 1997 00:26:13 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008824; Sat, 22 Feb 97 00:25:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05817 for ; Sat, 22 Feb 1997 00:24:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12805; Fri, 21 Feb 1997 10:24:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538650@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yNN8o2.0.Y73.wuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2707 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02544 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08723; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008710; Sat, 22 Feb 97 00:23:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05778 for ; Sat, 22 Feb 1997 00:22:13 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12532; Fri, 21 Feb 1997 10:22:52 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:52 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:30:19 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13773; Fri, 21 Feb 1997 10:30:19 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:30:19 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538957@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:29:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"NiDNF3.0.dM3.wzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2712 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:29:13 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02819 for ; Sat, 22 Feb 1997 00:28:42 +0900 Received: by fw.nikkeibp.co.jp; id AAA08997; Sat, 22 Feb 1997 00:28:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008988; Sat, 22 Feb 97 00:28:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05879 for ; Sat, 22 Feb 1997 00:27:18 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13249; Fri, 21 Feb 1997 10:27:43 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:43 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538770@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:10 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SileH3.0.lE3.exR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2710 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02648 for ; Sat, 22 Feb 1997 00:25:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08822; Sat, 22 Feb 1997 00:25:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008815; Sat, 22 Feb 97 00:25:42 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05814 for ; Sat, 22 Feb 1997 00:24:38 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12823; Fri, 21 Feb 1997 10:24:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:59 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538648@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:08 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yacTi2.0.n73.zuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2708 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02546 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08724; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008715; Sat, 22 Feb 97 00:23:37 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05785 for ; Sat, 22 Feb 1997 00:22:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12243; Fri, 21 Feb 1997 10:20:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:20:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538344@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:19:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"GUGsS.0.z-2.ArR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2705 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:19:01 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02265 for ; Sat, 22 Feb 1997 00:18:30 +0900 Received: by fw.nikkeibp.co.jp; id AAA08352; Sat, 22 Feb 1997 00:18:36 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008333; Sat, 22 Feb 97 00:18:20 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05713 for ; Sat, 22 Feb 1997 00:17:08 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11947; Fri, 21 Feb 1997 10:16:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:27:44 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13252; Fri, 21 Feb 1997 10:27:44 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:44 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538770@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:10 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SileH3.0.lE3.exR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2710 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02648 for ; Sat, 22 Feb 1997 00:25:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08822; Sat, 22 Feb 1997 00:25:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008815; Sat, 22 Feb 97 00:25:42 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05814 for ; Sat, 22 Feb 1997 00:24:38 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12823; Fri, 21 Feb 1997 10:24:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:59 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538648@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:08 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yacTi2.0.n73.zuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2708 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02546 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08724; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008715; Sat, 22 Feb 97 00:23:37 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05785 for ; Sat, 22 Feb 1997 00:22:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12243; Fri, 21 Feb 1997 10:20:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:20:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538344@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:19:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"GUGsS.0.z-2.ArR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2705 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:19:01 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02265 for ; Sat, 22 Feb 1997 00:18:30 +0900 Received: by fw.nikkeibp.co.jp; id AAA08352; Sat, 22 Feb 1997 00:18:36 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008333; Sat, 22 Feb 97 00:18:20 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05713 for ; Sat, 22 Feb 1997 00:17:08 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11947; Fri, 21 Feb 1997 10:16:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:36:07 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14635; Fri, 21 Feb 1997 10:36:07 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:36:07 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539318@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:35:18 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SxgG7.0.Ea3.O3S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2714 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:35:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03070 for ; Sat, 22 Feb 1997 00:34:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09304; Sat, 22 Feb 1997 00:34:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009283; Sat, 22 Feb 97 00:34:33 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06050 for ; Sat, 22 Feb 1997 00:33:28 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14209; Fri, 21 Feb 1997 10:32:23 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:32:23 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539084@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:20 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"MXlUk1.0.VS3.s_R3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2713 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02915 for ; Sat, 22 Feb 1997 00:30:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA09068; Sat, 22 Feb 1997 00:30:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009060; Sat, 22 Feb 97 00:30:44 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05909 for ; Sat, 22 Feb 1997 00:29:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13623; Fri, 21 Feb 1997 10:29:51 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:29:51 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538928@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:28:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VrcmD2.0.aK3.fzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2711 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:28:44 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02799 for ; Sat, 22 Feb 1997 00:28:13 +0900 Received: by fw.nikkeibp.co.jp; id AAA08979; Sat, 22 Feb 1997 00:28:19 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008970; Sat, 22 Feb 97 00:28:02 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05873 for ; Sat, 22 Feb 1997 00:26:54 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13206; Fri, 21 Feb 1997 10:27:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:38 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"cyFbL2.0.eD3.LxR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2709 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:37 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02675 for ; Sat, 22 Feb 1997 00:26:06 +0900 Received: by fw.nikkeibp.co.jp; id AAA08853; Sat, 22 Feb 1997 00:26:13 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008824; Sat, 22 Feb 97 00:25:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05817 for ; Sat, 22 Feb 1997 00:24:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12805; Fri, 21 Feb 1997 10:24:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538650@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yNN8o2.0.Y73.wuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2707 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02544 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08723; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008710; Sat, 22 Feb 97 00:23:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05778 for ; Sat, 22 Feb 1997 00:22:13 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12532; Fri, 21 Feb 1997 10:22:52 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:52 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:22:55 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12537; Fri, 21 Feb 1997 10:22:55 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:55 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:32:29 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14235; Fri, 21 Feb 1997 10:32:29 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:32:29 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539084@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:20 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"MXlUk1.0.VS3.s_R3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2713 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02915 for ; Sat, 22 Feb 1997 00:30:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA09068; Sat, 22 Feb 1997 00:30:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009060; Sat, 22 Feb 97 00:30:44 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05909 for ; Sat, 22 Feb 1997 00:29:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13623; Fri, 21 Feb 1997 10:29:51 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:29:51 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538928@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:28:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VrcmD2.0.aK3.fzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2711 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:28:44 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02799 for ; Sat, 22 Feb 1997 00:28:13 +0900 Received: by fw.nikkeibp.co.jp; id AAA08979; Sat, 22 Feb 1997 00:28:19 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008970; Sat, 22 Feb 97 00:28:02 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05873 for ; Sat, 22 Feb 1997 00:26:54 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13206; Fri, 21 Feb 1997 10:27:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:38 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"cyFbL2.0.eD3.LxR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2709 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:37 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02675 for ; Sat, 22 Feb 1997 00:26:06 +0900 Received: by fw.nikkeibp.co.jp; id AAA08853; Sat, 22 Feb 1997 00:26:13 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008824; Sat, 22 Feb 97 00:25:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05817 for ; Sat, 22 Feb 1997 00:24:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12805; Fri, 21 Feb 1997 10:24:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538650@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yNN8o2.0.Y73.wuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2707 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02544 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08723; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008710; Sat, 22 Feb 97 00:23:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05778 for ; Sat, 22 Feb 1997 00:22:13 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12532; Fri, 21 Feb 1997 10:22:52 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:52 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:39:57 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14965; Fri, 21 Feb 1997 10:39:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:39:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539108@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"9Xebj2.0.Kf3.y6S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2716 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02977 for ; Sat, 22 Feb 1997 00:31:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09118; Sat, 22 Feb 1997 00:31:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009088; Sat, 22 Feb 97 00:31:04 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05915 for ; Sat, 22 Feb 1997 00:29:58 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13770; Fri, 21 Feb 1997 10:30:17 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:30:17 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538957@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:29:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"NiDNF3.0.dM3.wzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2712 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:29:13 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02819 for ; Sat, 22 Feb 1997 00:28:42 +0900 Received: by fw.nikkeibp.co.jp; id AAA08997; Sat, 22 Feb 1997 00:28:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008988; Sat, 22 Feb 97 00:28:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05879 for ; Sat, 22 Feb 1997 00:27:18 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13249; Fri, 21 Feb 1997 10:27:43 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:43 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538770@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:10 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SileH3.0.lE3.exR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2710 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02648 for ; Sat, 22 Feb 1997 00:25:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08822; Sat, 22 Feb 1997 00:25:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008815; Sat, 22 Feb 97 00:25:42 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05814 for ; Sat, 22 Feb 1997 00:24:38 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12823; Fri, 21 Feb 1997 10:24:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:59 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538648@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:08 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yacTi2.0.n73.zuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2708 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02546 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08724; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008715; Sat, 22 Feb 97 00:23:37 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05785 for ; Sat, 22 Feb 1997 00:22:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12243; Fri, 21 Feb 1997 10:20:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:20:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538344@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:19:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"GUGsS.0.z-2.ArR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2705 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:19:01 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02265 for ; Sat, 22 Feb 1997 00:18:30 +0900 Received: by fw.nikkeibp.co.jp; id AAA08352; Sat, 22 Feb 1997 00:18:36 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008333; Sat, 22 Feb 97 00:18:20 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05713 for ; Sat, 22 Feb 1997 00:17:08 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11947; Fri, 21 Feb 1997 10:16:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:42:10 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15385; Fri, 21 Feb 1997 10:42:10 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:42:10 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539619@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:40:19 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"Voc4V.0.Yj3.o8S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2718 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:40:16 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03253 for ; Sat, 22 Feb 1997 00:39:46 +0900 Received: by fw.nikkeibp.co.jp; id AAA09525; Sat, 22 Feb 1997 00:39:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009515; Sat, 22 Feb 97 00:39:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06093 for ; Sat, 22 Feb 1997 00:38:36 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14874; Fri, 21 Feb 1997 10:38:40 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:38:40 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539467@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:37:47 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VB__V.0.8e3.v5S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2715 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:37:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03163 for ; Sat, 22 Feb 1997 00:37:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09438; Sat, 22 Feb 1997 00:37:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009431; Sat, 22 Feb 97 00:37:17 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06081 for ; Sat, 22 Feb 1997 00:36:10 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14632; Fri, 21 Feb 1997 10:36:05 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:36:05 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539318@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:35:18 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SxgG7.0.Ea3.O3S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2714 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:35:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03070 for ; Sat, 22 Feb 1997 00:34:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09304; Sat, 22 Feb 1997 00:34:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009283; Sat, 22 Feb 97 00:34:33 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06050 for ; Sat, 22 Feb 1997 00:33:28 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14209; Fri, 21 Feb 1997 10:32:23 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:32:23 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539084@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:20 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"MXlUk1.0.VS3.s_R3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2713 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02915 for ; Sat, 22 Feb 1997 00:30:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA09068; Sat, 22 Feb 1997 00:30:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009060; Sat, 22 Feb 97 00:30:44 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05909 for ; Sat, 22 Feb 1997 00:29:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13623; Fri, 21 Feb 1997 10:29:51 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:29:51 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538928@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:28:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VrcmD2.0.aK3.fzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2711 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:28:44 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02799 for ; Sat, 22 Feb 1997 00:28:13 +0900 Received: by fw.nikkeibp.co.jp; id AAA08979; Sat, 22 Feb 1997 00:28:19 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008970; Sat, 22 Feb 97 00:28:02 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05873 for ; Sat, 22 Feb 1997 00:26:54 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13206; Fri, 21 Feb 1997 10:27:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:38 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"cyFbL2.0.eD3.LxR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2709 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:37 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02675 for ; Sat, 22 Feb 1997 00:26:06 +0900 Received: by fw.nikkeibp.co.jp; id AAA08853; Sat, 22 Feb 1997 00:26:13 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008824; Sat, 22 Feb 97 00:25:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05817 for ; Sat, 22 Feb 1997 00:24:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12805; Fri, 21 Feb 1997 10:24:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538650@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yNN8o2.0.Y73.wuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2707 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02544 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08723; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008710; Sat, 22 Feb 97 00:23:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05778 for ; Sat, 22 Feb 1997 00:22:13 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12532; Fri, 21 Feb 1997 10:22:52 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:52 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:42:51 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15464; Fri, 21 Feb 1997 10:42:51 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:42:51 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539709@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:41:49 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"gdRDq1.0.Bn3.m9S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2719 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:41:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03332 for ; Sat, 22 Feb 1997 00:41:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09595; Sat, 22 Feb 1997 00:41:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009589; Sat, 22 Feb 97 00:41:13 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06109 for ; Sat, 22 Feb 1997 00:39:55 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14956; Fri, 21 Feb 1997 10:39:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:39:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539108@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"9Xebj2.0.Kf3.y6S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2716 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02977 for ; Sat, 22 Feb 1997 00:31:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09118; Sat, 22 Feb 1997 00:31:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009088; Sat, 22 Feb 97 00:31:04 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05915 for ; Sat, 22 Feb 1997 00:29:58 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13770; Fri, 21 Feb 1997 10:30:17 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:30:17 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538957@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:29:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"NiDNF3.0.dM3.wzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2712 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:29:13 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02819 for ; Sat, 22 Feb 1997 00:28:42 +0900 Received: by fw.nikkeibp.co.jp; id AAA08997; Sat, 22 Feb 1997 00:28:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008988; Sat, 22 Feb 97 00:28:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05879 for ; Sat, 22 Feb 1997 00:27:18 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13249; Fri, 21 Feb 1997 10:27:43 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:43 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538770@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:10 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SileH3.0.lE3.exR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2710 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02648 for ; Sat, 22 Feb 1997 00:25:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08822; Sat, 22 Feb 1997 00:25:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008815; Sat, 22 Feb 97 00:25:42 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05814 for ; Sat, 22 Feb 1997 00:24:38 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12823; Fri, 21 Feb 1997 10:24:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:59 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538648@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:08 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yacTi2.0.n73.zuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2708 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02546 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08724; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008715; Sat, 22 Feb 97 00:23:37 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05785 for ; Sat, 22 Feb 1997 00:22:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12243; Fri, 21 Feb 1997 10:20:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:20:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538344@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:19:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"GUGsS.0.z-2.ArR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2705 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:19:01 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02265 for ; Sat, 22 Feb 1997 00:18:30 +0900 Received: by fw.nikkeibp.co.jp; id AAA08352; Sat, 22 Feb 1997 00:18:36 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008333; Sat, 22 Feb 97 00:18:20 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05713 for ; Sat, 22 Feb 1997 00:17:08 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11947; Fri, 21 Feb 1997 10:16:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:41:37 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15190; Fri, 21 Feb 1997 10:41:37 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:41:37 -0500 (EST) Message-Id: <199702211541.KAA15156@merit.edu> Date: Fri, 21 Feb 97 10:37:29 EST From: "C. S. McIlvaine (444-9906)" To: ietf-ppp@MERIT.EDU Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"A_WAk.0.xi3.c8S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2717 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Is the MP header data, or part of the PPP header? My interpretation is that it is part of the PPP header. RFC1990 refers to "A new PPP header consisting of the Multilink Protocol Identifier, and the Multilink header." Yes, device drivers/hardware have to be changed to take into account the increased size of the PPP header (plus 10 bytes header instead of plus 4). Yes, this is a waste if you are not running MP. The incoming PPP packet size is still MRU + PPP header + CRC. If MRU is not negotiated this would be 1500 + PPP header + CRC. If the protocols use a payload of 1500 bytes and you desire the ability to send the payload on any link without fragmentation it is logical that MRU=MRRU=1500. Why negotiate for an MRU of 1500 if MP is not negotiated successfully and an MRU of 1506 if MP is negotiated successfully? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:38:42 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14880; Fri, 21 Feb 1997 10:38:42 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:38:42 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539467@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:37:47 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VB__V.0.8e3.v5S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2715 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:37:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03163 for ; Sat, 22 Feb 1997 00:37:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09438; Sat, 22 Feb 1997 00:37:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009431; Sat, 22 Feb 97 00:37:17 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06081 for ; Sat, 22 Feb 1997 00:36:10 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14632; Fri, 21 Feb 1997 10:36:05 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:36:05 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539318@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:35:18 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SxgG7.0.Ea3.O3S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2714 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:35:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03070 for ; Sat, 22 Feb 1997 00:34:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09304; Sat, 22 Feb 1997 00:34:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009283; Sat, 22 Feb 97 00:34:33 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06050 for ; Sat, 22 Feb 1997 00:33:28 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14209; Fri, 21 Feb 1997 10:32:23 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:32:23 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539084@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:20 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"MXlUk1.0.VS3.s_R3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2713 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02915 for ; Sat, 22 Feb 1997 00:30:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA09068; Sat, 22 Feb 1997 00:30:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009060; Sat, 22 Feb 97 00:30:44 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05909 for ; Sat, 22 Feb 1997 00:29:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13623; Fri, 21 Feb 1997 10:29:51 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:29:51 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538928@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:28:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VrcmD2.0.aK3.fzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2711 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:28:44 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02799 for ; Sat, 22 Feb 1997 00:28:13 +0900 Received: by fw.nikkeibp.co.jp; id AAA08979; Sat, 22 Feb 1997 00:28:19 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008970; Sat, 22 Feb 97 00:28:02 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05873 for ; Sat, 22 Feb 1997 00:26:54 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13206; Fri, 21 Feb 1997 10:27:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:38 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"cyFbL2.0.eD3.LxR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2709 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:37 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02675 for ; Sat, 22 Feb 1997 00:26:06 +0900 Received: by fw.nikkeibp.co.jp; id AAA08853; Sat, 22 Feb 1997 00:26:13 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008824; Sat, 22 Feb 97 00:25:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05817 for ; Sat, 22 Feb 1997 00:24:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12805; Fri, 21 Feb 1997 10:24:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538650@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yNN8o2.0.Y73.wuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2707 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02544 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08723; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008710; Sat, 22 Feb 97 00:23:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05778 for ; Sat, 22 Feb 1997 00:22:13 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12532; Fri, 21 Feb 1997 10:22:52 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:52 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:45:58 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16125; Fri, 21 Feb 1997 10:45:58 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:45:58 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539897@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:44:57 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"qyD-22.0.yw3.VCS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2720 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:44:47 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03432 for ; Sat, 22 Feb 1997 00:44:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09695; Sat, 22 Feb 1997 00:44:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009679; Sat, 22 Feb 97 00:44:07 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06141 for ; Sat, 22 Feb 1997 00:42:57 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15460; Fri, 21 Feb 1997 10:42:50 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:42:50 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539709@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:41:49 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"gdRDq1.0.Bn3.m9S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2719 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:41:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03332 for ; Sat, 22 Feb 1997 00:41:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09595; Sat, 22 Feb 1997 00:41:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009589; Sat, 22 Feb 97 00:41:13 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06109 for ; Sat, 22 Feb 1997 00:39:55 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14956; Fri, 21 Feb 1997 10:39:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:39:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539108@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"9Xebj2.0.Kf3.y6S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2716 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02977 for ; Sat, 22 Feb 1997 00:31:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09118; Sat, 22 Feb 1997 00:31:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009088; Sat, 22 Feb 97 00:31:04 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05915 for ; Sat, 22 Feb 1997 00:29:58 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13770; Fri, 21 Feb 1997 10:30:17 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:30:17 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538957@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:29:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"NiDNF3.0.dM3.wzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2712 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:29:13 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02819 for ; Sat, 22 Feb 1997 00:28:42 +0900 Received: by fw.nikkeibp.co.jp; id AAA08997; Sat, 22 Feb 1997 00:28:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008988; Sat, 22 Feb 97 00:28:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05879 for ; Sat, 22 Feb 1997 00:27:18 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13249; Fri, 21 Feb 1997 10:27:43 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:43 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538770@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:10 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SileH3.0.lE3.exR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2710 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02648 for ; Sat, 22 Feb 1997 00:25:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08822; Sat, 22 Feb 1997 00:25:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008815; Sat, 22 Feb 97 00:25:42 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05814 for ; Sat, 22 Feb 1997 00:24:38 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12823; Fri, 21 Feb 1997 10:24:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:59 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538648@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:08 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yacTi2.0.n73.zuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2708 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02546 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08724; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008715; Sat, 22 Feb 97 00:23:37 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05785 for ; Sat, 22 Feb 1997 00:22:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12243; Fri, 21 Feb 1997 10:20:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:20:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538344@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:19:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"GUGsS.0.z-2.ArR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2705 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:19:01 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02265 for ; Sat, 22 Feb 1997 00:18:30 +0900 Received: by fw.nikkeibp.co.jp; id AAA08352; Sat, 22 Feb 1997 00:18:36 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008333; Sat, 22 Feb 97 00:18:20 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05713 for ; Sat, 22 Feb 1997 00:17:08 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11947; Fri, 21 Feb 1997 10:16:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:48:26 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16460; Fri, 21 Feb 1997 10:48:26 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:48:26 -0500 (EST) Date: Fri, 21 Feb 1997 08:47:56 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702211547.IAA16108@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"Eg1yo.0.g04.uES3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2722 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > ... > IP > -------- "Inner MRU" > CCP > ECP > -------- MRRU > MP > -------- "Outer MRU" > LCP > ... > I think it would be better to negotiate the inner MRU explcitly, so I > would like to propose a new LCP option for this purpose. The default > value would be the same as the MRRU (if MP is negotiated) or the MRU > (if not using MP), so it would therefore not break any existing > implementations. > ... Not having the Inner MRU can be handled, but only with some ugly code. You can negotiate the MRRU and/or MRU to have the right, larger than necessary values. You can also tell your upper layers that the inner MRU is the MRRU less the ECP and CCP overhead. (Note that the CCP problem is not just extra headers but the worst case expansion of data for those compression schemes that can expand the data.) In 4.*BSD UNIX network code, it is not a problem to change the Inner MRU as long as you do it before the interface is made available to applications (i.e. the IFF_UP and IFF_RUNNING bits set). After the interface is up and applications are using it, you really do not want to change the if_mtu value in the struct if_net. CCP might come up after IPCP, or the compression scheme might be re-negotiated and changed, so you cannot count on getting IP up last. You might plan ahead and always try to negotiate a smaller Outer MRU, but the peer can always force you to use 1500. You might plan ahead and always use something smaller than 1500 for the Inner MRU, but that has undesirable side effects (IP fragmentation). Those difficulties asside, I fear it is about 9 years too late to fix the problem and have an explicit Inner MRU negotiation. Like my hobby horse of putting authentication into the Establish Phase, it is now so late that every implementation must forever be prepared to deal peers that do things the old way. If you must have all of that ugliness to deal with the problem when talking to ancient peers, why bother ever implementing the new, clean way? There is another problem with an Inner MRU option. What happens if the peers cannot agree on the Inner MRU? What if the user-data receiver wants a smaller value than the sender wants to send? If the send does not want to IP fragment, it need simply refuse to play the game, which means that even if the Inner MRU option had been proposed 8 or 9 years ago, we would still must have that nasty code to deal to deal with the case of not negotiating the Inner MRU, which means that negotiating the Inner MRU doesn't save us anything. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:47:56 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16407; Fri, 21 Feb 1997 10:47:56 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:47:56 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539907@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:45:07 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"pAR3g.0.vz3.KES3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2721 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:44:47 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03434 for ; Sat, 22 Feb 1997 00:44:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09690; Sat, 22 Feb 1997 00:44:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009670; Sat, 22 Feb 97 00:43:56 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06133 for ; Sat, 22 Feb 1997 00:42:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15382; Fri, 21 Feb 1997 10:42:07 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:42:07 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539619@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:40:19 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"Voc4V.0.Yj3.o8S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2718 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:40:16 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03253 for ; Sat, 22 Feb 1997 00:39:46 +0900 Received: by fw.nikkeibp.co.jp; id AAA09525; Sat, 22 Feb 1997 00:39:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009515; Sat, 22 Feb 97 00:39:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06093 for ; Sat, 22 Feb 1997 00:38:36 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14874; Fri, 21 Feb 1997 10:38:40 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:38:40 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539467@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:37:47 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VB__V.0.8e3.v5S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2715 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:37:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03163 for ; Sat, 22 Feb 1997 00:37:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09438; Sat, 22 Feb 1997 00:37:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009431; Sat, 22 Feb 97 00:37:17 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06081 for ; Sat, 22 Feb 1997 00:36:10 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14632; Fri, 21 Feb 1997 10:36:05 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:36:05 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539318@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:35:18 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SxgG7.0.Ea3.O3S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2714 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:35:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03070 for ; Sat, 22 Feb 1997 00:34:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09304; Sat, 22 Feb 1997 00:34:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009283; Sat, 22 Feb 97 00:34:33 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06050 for ; Sat, 22 Feb 1997 00:33:28 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14209; Fri, 21 Feb 1997 10:32:23 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:32:23 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539084@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:20 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"MXlUk1.0.VS3.s_R3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2713 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02915 for ; Sat, 22 Feb 1997 00:30:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA09068; Sat, 22 Feb 1997 00:30:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009060; Sat, 22 Feb 97 00:30:44 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05909 for ; Sat, 22 Feb 1997 00:29:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13623; Fri, 21 Feb 1997 10:29:51 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:29:51 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538928@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:28:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VrcmD2.0.aK3.fzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2711 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:28:44 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02799 for ; Sat, 22 Feb 1997 00:28:13 +0900 Received: by fw.nikkeibp.co.jp; id AAA08979; Sat, 22 Feb 1997 00:28:19 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008970; Sat, 22 Feb 97 00:28:02 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05873 for ; Sat, 22 Feb 1997 00:26:54 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13206; Fri, 21 Feb 1997 10:27:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:38 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"cyFbL2.0.eD3.LxR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2709 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:37 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02675 for ; Sat, 22 Feb 1997 00:26:06 +0900 Received: by fw.nikkeibp.co.jp; id AAA08853; Sat, 22 Feb 1997 00:26:13 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008824; Sat, 22 Feb 97 00:25:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05817 for ; Sat, 22 Feb 1997 00:24:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12805; Fri, 21 Feb 1997 10:24:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538650@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yNN8o2.0.Y73.wuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2707 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02544 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08723; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008710; Sat, 22 Feb 97 00:23:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05778 for ; Sat, 22 Feb 1997 00:22:13 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12532; Fri, 21 Feb 1997 10:22:52 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:52 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:51:53 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17012; Fri, 21 Feb 1997 10:51:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:51:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:43:18 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"rrDRN.0.584.UHS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2725 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:43:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03354 for ; Sat, 22 Feb 1997 00:42:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09627; Sat, 22 Feb 1997 00:42:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009625; Sat, 22 Feb 97 00:42:49 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06119 for ; Sat, 22 Feb 1997 00:41:45 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15185; Fri, 21 Feb 1997 10:41:35 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:41:35 -0500 (EST) Message-Id: <199702211541.KAA15156@merit.edu> Date: Fri, 21 Feb 97 10:37:29 EST From: "C. S. McIlvaine (444-9906)" To: ietf-ppp@MERIT.EDU Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"A_WAk.0.xi3.c8S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2717 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Is the MP header data, or part of the PPP header? My interpretation is that it is part of the PPP header. RFC1990 refers to "A new PPP header consisting of the Multilink Protocol Identifier, and the Multilink header." Yes, device drivers/hardware have to be changed to take into account the increased size of the PPP header (plus 10 bytes header instead of plus 4). Yes, this is a waste if you are not running MP. The incoming PPP packet size is still MRU + PPP header + CRC. If MRU is not negotiated this would be 1500 + PPP header + CRC. If the protocols use a payload of 1500 bytes and you desire the ability to send the payload on any link without fragmentation it is logical that MRU=MRRU=1500. Why negotiate for an MRU of 1500 if MP is not negotiated successfully and an MRU of 1506 if MP is negotiated successfully? --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:51:36 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16984; Fri, 21 Feb 1997 10:51:36 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:51:36 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540186@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:49:46 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"MBfDE1.0.o44.zGS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2723 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:49:45 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03622 for ; Sat, 22 Feb 1997 00:49:14 +0900 Received: by fw.nikkeibp.co.jp; id AAA09917; Sat, 22 Feb 1997 00:49:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009906; Sat, 22 Feb 97 00:49:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06198 for ; Sat, 22 Feb 1997 00:47:58 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16455; Fri, 21 Feb 1997 10:48:24 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:48:24 -0500 (EST) Date: Fri, 21 Feb 1997 08:47:56 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702211547.IAA16108@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"Eg1yo.0.g04.uES3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2722 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > ... > IP > -------- "Inner MRU" > CCP > ECP > -------- MRRU > MP > -------- "Outer MRU" > LCP > ... > I think it would be better to negotiate the inner MRU explcitly, so I > would like to propose a new LCP option for this purpose. The default > value would be the same as the MRRU (if MP is negotiated) or the MRU > (if not using MP), so it would therefore not break any existing > implementations. > ... Not having the Inner MRU can be handled, but only with some ugly code. You can negotiate the MRRU and/or MRU to have the right, larger than necessary values. You can also tell your upper layers that the inner MRU is the MRRU less the ECP and CCP overhead. (Note that the CCP problem is not just extra headers but the worst case expansion of data for those compression schemes that can expand the data.) In 4.*BSD UNIX network code, it is not a problem to change the Inner MRU as long as you do it before the interface is made available to applications (i.e. the IFF_UP and IFF_RUNNING bits set). After the interface is up and applications are using it, you really do not want to change the if_mtu value in the struct if_net. CCP might come up after IPCP, or the compression scheme might be re-negotiated and changed, so you cannot count on getting IP up last. You might plan ahead and always try to negotiate a smaller Outer MRU, but the peer can always force you to use 1500. You might plan ahead and always use something smaller than 1500 for the Inner MRU, but that has undesirable side effects (IP fragmentation). Those difficulties asside, I fear it is about 9 years too late to fix the problem and have an explicit Inner MRU negotiation. Like my hobby horse of putting authentication into the Establish Phase, it is now so late that every implementation must forever be prepared to deal peers that do things the old way. If you must have all of that ugliness to deal with the problem when talking to ancient peers, why bother ever implementing the new, clean way? There is another problem with an Inner MRU option. What happens if the peers cannot agree on the Inner MRU? What if the user-data receiver wants a smaller value than the sender wants to send? If the send does not want to IP fragment, it need simply refuse to play the game, which means that even if the Inner MRU option had been proposed 8 or 9 years ago, we would still must have that nasty code to deal to deal with the case of not negotiating the Inner MRU, which means that negotiating the Inner MRU doesn't save us anything. Vernon Schryver, vjs@sgi.com --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:52:06 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17038; Fri, 21 Feb 1997 10:52:06 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:52:06 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540157@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:49:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"pc2zp.0.594.xHS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2726 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:49:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03595 for ; Sat, 22 Feb 1997 00:48:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09896; Sat, 22 Feb 1997 00:48:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009892; Sat, 22 Feb 97 00:48:46 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06193 for ; Sat, 22 Feb 1997 00:47:42 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16118; Fri, 21 Feb 1997 10:45:55 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:45:55 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539897@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:44:57 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"qyD-22.0.yw3.VCS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2720 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:44:47 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03432 for ; Sat, 22 Feb 1997 00:44:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09695; Sat, 22 Feb 1997 00:44:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009679; Sat, 22 Feb 97 00:44:07 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06141 for ; Sat, 22 Feb 1997 00:42:57 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15460; Fri, 21 Feb 1997 10:42:50 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:42:50 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539709@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:41:49 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"gdRDq1.0.Bn3.m9S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2719 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:41:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03332 for ; Sat, 22 Feb 1997 00:41:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09595; Sat, 22 Feb 1997 00:41:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009589; Sat, 22 Feb 97 00:41:13 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06109 for ; Sat, 22 Feb 1997 00:39:55 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14956; Fri, 21 Feb 1997 10:39:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:39:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539108@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"9Xebj2.0.Kf3.y6S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2716 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02977 for ; Sat, 22 Feb 1997 00:31:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09118; Sat, 22 Feb 1997 00:31:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009088; Sat, 22 Feb 97 00:31:04 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05915 for ; Sat, 22 Feb 1997 00:29:58 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13770; Fri, 21 Feb 1997 10:30:17 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:30:17 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538957@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:29:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"NiDNF3.0.dM3.wzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2712 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:29:13 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02819 for ; Sat, 22 Feb 1997 00:28:42 +0900 Received: by fw.nikkeibp.co.jp; id AAA08997; Sat, 22 Feb 1997 00:28:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008988; Sat, 22 Feb 97 00:28:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05879 for ; Sat, 22 Feb 1997 00:27:18 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13249; Fri, 21 Feb 1997 10:27:43 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:43 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538770@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:10 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SileH3.0.lE3.exR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2710 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02648 for ; Sat, 22 Feb 1997 00:25:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08822; Sat, 22 Feb 1997 00:25:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008815; Sat, 22 Feb 97 00:25:42 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05814 for ; Sat, 22 Feb 1997 00:24:38 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12823; Fri, 21 Feb 1997 10:24:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:59 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538648@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:08 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yacTi2.0.n73.zuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2708 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02546 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08724; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008715; Sat, 22 Feb 97 00:23:37 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05785 for ; Sat, 22 Feb 1997 00:22:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12243; Fri, 21 Feb 1997 10:20:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:20:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538344@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:19:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"GUGsS.0.z-2.ArR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2705 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:19:01 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02265 for ; Sat, 22 Feb 1997 00:18:30 +0900 Received: by fw.nikkeibp.co.jp; id AAA08352; Sat, 22 Feb 1997 00:18:36 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008333; Sat, 22 Feb 97 00:18:20 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05713 for ; Sat, 22 Feb 1997 00:17:08 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11947; Fri, 21 Feb 1997 10:16:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:51:38 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16987; Fri, 21 Feb 1997 10:51:38 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:51:38 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540189@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:49:49 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"6jYeJ2.0.R54.5HS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2724 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:49:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03626 for ; Sat, 22 Feb 1997 00:49:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09918; Sat, 22 Feb 1997 00:49:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009907; Sat, 22 Feb 97 00:49:07 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06199 for ; Sat, 22 Feb 1997 00:48:03 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16404; Fri, 21 Feb 1997 10:47:54 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:47:54 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539907@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:45:07 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"pAR3g.0.vz3.KES3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2721 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:44:47 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03434 for ; Sat, 22 Feb 1997 00:44:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09690; Sat, 22 Feb 1997 00:44:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009670; Sat, 22 Feb 97 00:43:56 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06133 for ; Sat, 22 Feb 1997 00:42:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15382; Fri, 21 Feb 1997 10:42:07 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:42:07 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539619@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:40:19 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"Voc4V.0.Yj3.o8S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2718 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:40:16 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03253 for ; Sat, 22 Feb 1997 00:39:46 +0900 Received: by fw.nikkeibp.co.jp; id AAA09525; Sat, 22 Feb 1997 00:39:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009515; Sat, 22 Feb 97 00:39:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06093 for ; Sat, 22 Feb 1997 00:38:36 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14874; Fri, 21 Feb 1997 10:38:40 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:38:40 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539467@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:37:47 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VB__V.0.8e3.v5S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2715 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:37:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03163 for ; Sat, 22 Feb 1997 00:37:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09438; Sat, 22 Feb 1997 00:37:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009431; Sat, 22 Feb 97 00:37:17 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06081 for ; Sat, 22 Feb 1997 00:36:10 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14632; Fri, 21 Feb 1997 10:36:05 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:36:05 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539318@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:35:18 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SxgG7.0.Ea3.O3S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2714 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:35:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03070 for ; Sat, 22 Feb 1997 00:34:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09304; Sat, 22 Feb 1997 00:34:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009283; Sat, 22 Feb 97 00:34:33 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06050 for ; Sat, 22 Feb 1997 00:33:28 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14209; Fri, 21 Feb 1997 10:32:23 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:32:23 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539084@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:20 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"MXlUk1.0.VS3.s_R3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2713 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02915 for ; Sat, 22 Feb 1997 00:30:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA09068; Sat, 22 Feb 1997 00:30:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009060; Sat, 22 Feb 97 00:30:44 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05909 for ; Sat, 22 Feb 1997 00:29:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13623; Fri, 21 Feb 1997 10:29:51 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:29:51 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538928@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:28:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VrcmD2.0.aK3.fzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2711 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:28:44 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02799 for ; Sat, 22 Feb 1997 00:28:13 +0900 Received: by fw.nikkeibp.co.jp; id AAA08979; Sat, 22 Feb 1997 00:28:19 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008970; Sat, 22 Feb 97 00:28:02 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05873 for ; Sat, 22 Feb 1997 00:26:54 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13206; Fri, 21 Feb 1997 10:27:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:38 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"cyFbL2.0.eD3.LxR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2709 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:37 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02675 for ; Sat, 22 Feb 1997 00:26:06 +0900 Received: by fw.nikkeibp.co.jp; id AAA08853; Sat, 22 Feb 1997 00:26:13 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008824; Sat, 22 Feb 97 00:25:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05817 for ; Sat, 22 Feb 1997 00:24:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12805; Fri, 21 Feb 1997 10:24:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538650@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yNN8o2.0.Y73.wuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2707 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02544 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08723; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008710; Sat, 22 Feb 97 00:23:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05778 for ; Sat, 22 Feb 1997 00:22:13 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12532; Fri, 21 Feb 1997 10:22:52 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:52 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:56:40 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17938; Fri, 21 Feb 1997 10:56:40 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:56:40 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540479@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:54:36 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"Ysoo53.0.DM4.gLS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2731 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:54:25 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03886 for ; Sat, 22 Feb 1997 00:53:54 +0900 Received: by fw.nikkeibp.co.jp; id AAA10208; Sat, 22 Feb 1997 00:54:00 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010176; Sat, 22 Feb 97 00:53:36 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06287 for ; Sat, 22 Feb 1997 00:52:26 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17025; Fri, 21 Feb 1997 10:52:01 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:52:01 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540157@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:49:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"pc2zp.0.594.xHS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2726 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:49:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03595 for ; Sat, 22 Feb 1997 00:48:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09896; Sat, 22 Feb 1997 00:48:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009892; Sat, 22 Feb 97 00:48:46 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06193 for ; Sat, 22 Feb 1997 00:47:42 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16118; Fri, 21 Feb 1997 10:45:55 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:45:55 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539897@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:44:57 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"qyD-22.0.yw3.VCS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2720 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:44:47 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03432 for ; Sat, 22 Feb 1997 00:44:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09695; Sat, 22 Feb 1997 00:44:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009679; Sat, 22 Feb 97 00:44:07 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06141 for ; Sat, 22 Feb 1997 00:42:57 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15460; Fri, 21 Feb 1997 10:42:50 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:42:50 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539709@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:41:49 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"gdRDq1.0.Bn3.m9S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2719 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:41:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03332 for ; Sat, 22 Feb 1997 00:41:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09595; Sat, 22 Feb 1997 00:41:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009589; Sat, 22 Feb 97 00:41:13 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06109 for ; Sat, 22 Feb 1997 00:39:55 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14956; Fri, 21 Feb 1997 10:39:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:39:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539108@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"9Xebj2.0.Kf3.y6S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2716 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02977 for ; Sat, 22 Feb 1997 00:31:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09118; Sat, 22 Feb 1997 00:31:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009088; Sat, 22 Feb 97 00:31:04 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05915 for ; Sat, 22 Feb 1997 00:29:58 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13770; Fri, 21 Feb 1997 10:30:17 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:30:17 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538957@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:29:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"NiDNF3.0.dM3.wzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2712 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:29:13 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02819 for ; Sat, 22 Feb 1997 00:28:42 +0900 Received: by fw.nikkeibp.co.jp; id AAA08997; Sat, 22 Feb 1997 00:28:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008988; Sat, 22 Feb 97 00:28:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05879 for ; Sat, 22 Feb 1997 00:27:18 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13249; Fri, 21 Feb 1997 10:27:43 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:43 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538770@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:10 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SileH3.0.lE3.exR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2710 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02648 for ; Sat, 22 Feb 1997 00:25:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08822; Sat, 22 Feb 1997 00:25:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008815; Sat, 22 Feb 97 00:25:42 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05814 for ; Sat, 22 Feb 1997 00:24:38 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12823; Fri, 21 Feb 1997 10:24:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:59 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538648@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:08 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yacTi2.0.n73.zuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2708 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02546 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08724; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008715; Sat, 22 Feb 97 00:23:37 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05785 for ; Sat, 22 Feb 1997 00:22:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12243; Fri, 21 Feb 1997 10:20:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:20:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538344@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:19:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"GUGsS.0.z-2.ArR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2705 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:19:01 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02265 for ; Sat, 22 Feb 1997 00:18:30 +0900 Received: by fw.nikkeibp.co.jp; id AAA08352; Sat, 22 Feb 1997 00:18:36 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008333; Sat, 22 Feb 97 00:18:20 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05713 for ; Sat, 22 Feb 1997 00:17:08 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11947; Fri, 21 Feb 1997 10:16:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:56:34 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17931; Fri, 21 Feb 1997 10:56:34 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:56:34 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540469@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:54:26 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"D-pfr2.0.bL4.QLS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2730 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:54:23 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03878 for ; Sat, 22 Feb 1997 00:53:52 +0900 Received: by fw.nikkeibp.co.jp; id AAA10209; Sat, 22 Feb 1997 00:53:59 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010167; Sat, 22 Feb 97 00:53:38 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06288 for ; Sat, 22 Feb 1997 00:52:27 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11483; Fri, 21 Feb 1997 10:12:32 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:12:32 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537911@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:11:51 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VPzKg.0.9p2.RjR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2703 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:11:48 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01960 for ; Sat, 22 Feb 1997 00:11:18 +0900 Received: by fw.nikkeibp.co.jp; id AAA07979; Sat, 22 Feb 1997 00:11:24 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007966; Sat, 22 Feb 97 00:11:07 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05614 for ; Sat, 22 Feb 1997 00:10:02 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11275; Fri, 21 Feb 1997 10:10:14 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:10:14 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537456@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:04:16 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"65wJT2.0.rl2.HhR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2702 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:04:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01565 for ; Sat, 22 Feb 1997 00:03:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA07603; Sat, 22 Feb 1997 00:03:50 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007598; Sat, 22 Feb 97 00:03:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05476 for ; Sat, 22 Feb 1997 00:02:21 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA10776; Fri, 21 Feb 1997 10:02:22 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:02:22 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537301@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:01:41 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ZmAPX.0.6e2.rZR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2701 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:01:39 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01414 for ; Sat, 22 Feb 1997 00:01:08 +0900 Received: by fw.nikkeibp.co.jp; id AAA07433; Sat, 22 Feb 1997 00:01:15 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007421; Sat, 22 Feb 97 00:01:01 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05428 for ; Fri, 21 Feb 1997 23:59:52 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA10449; Fri, 21 Feb 1997 09:59:56 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:59:56 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536375@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:46:15 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"l5ZjX.0.-Y2.cXR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2700 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:46:12 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00585 for ; Fri, 21 Feb 1997 23:45:41 +0900 Received: by fw.nikkeibp.co.jp; id XAA06583; Fri, 21 Feb 1997 23:45:48 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006575; Fri, 21 Feb 97 23:45:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05178 for ; Fri, 21 Feb 1997 23:44:17 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09854; Fri, 21 Feb 1997 09:44:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:44:59 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:43:16 +0000 Message-ID: <30db4cb0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Revisiting MRU-MRRU To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"Ai1LR2.0.iP2.cJR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2699 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From Patrick Klos: > >MRRU has nothing to do with MRU. It can be grater than, equal to or > >less than MRU's of the the individual links (remember MRU can be > >different for the different links in a multilink bundle.) >YES! This I think is one of the important points that some people >are missing. Well, I can only speak for myself, but I did not miss that point - it simply wasn't relevant to the case we were discussing, which was about sending a whole MP fragment: to be able to send a whole fragment of size MRRU then MRU must be >= MRRU+5. > >When using MP, the upper layer's (ie the protocol stacks) see a > >virtual link with a MTU which is equal to MRRU. Actually, this is only guaranteed when using neither compression nor encryption. Because of the overhead of the encryption header & padding, you may need the MRRU to be greater than the upper layer MTU. Which is why I think that the upper layer MTU and MRU need to be negotiated explicitly. --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:58:32 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA18069; Fri, 21 Feb 1997 10:58:32 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:58:32 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 15:51:57 +0000 Message-ID: <30dc5d10@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Revisiting MRU-MRRU To: ietf-ppp@MERIT.EDU, John Bray Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"rngrS3.0.XP4.5OS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2732 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU John Bray writes: >Couldn't this be handled internally by simply adjusting the upper >layer MTU to account for the additional overhead? Why is it >necessary to negotiate this? Because if I have an Upper Layer MRU of 1500, I might want to negotiate the MRRU to 1524 in order to allow for the CCP header. But then the peer might not support CCP, in which case it would think that it could send me an IP packet of 1524 octets, which I wouldn't be able to cope with. --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:56:31 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17928; Fri, 21 Feb 1997 10:56:31 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:56:31 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540472@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:54:31 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"vHGJS2.0.PL4.OLS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2729 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:54:24 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03884 for ; Sat, 22 Feb 1997 00:53:54 +0900 Received: by fw.nikkeibp.co.jp; id AAA10206; Sat, 22 Feb 1997 00:53:59 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010130; Sat, 22 Feb 97 00:53:32 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06273 for ; Sat, 22 Feb 1997 00:52:10 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17000; Fri, 21 Feb 1997 10:51:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:51:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:43:18 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"rrDRN.0.584.UHS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2725 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:43:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03354 for ; Sat, 22 Feb 1997 00:42:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09627; Sat, 22 Feb 1997 00:42:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009625; Sat, 22 Feb 97 00:42:49 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06119 for ; Sat, 22 Feb 1997 00:41:45 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15185; Fri, 21 Feb 1997 10:41:35 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:41:35 -0500 (EST) Message-Id: <199702211541.KAA15156@merit.edu> Date: Fri, 21 Feb 97 10:37:29 EST From: "C. S. McIlvaine (444-9906)" To: ietf-ppp@MERIT.EDU Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"A_WAk.0.xi3.c8S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2717 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Is the MP header data, or part of the PPP header? My interpretation is that it is part of the PPP header. RFC1990 refers to "A new PPP header consisting of the Multilink Protocol Identifier, and the Multilink header." Yes, device drivers/hardware have to be changed to take into account the increased size of the PPP header (plus 10 bytes header instead of plus 4). Yes, this is a waste if you are not running MP. The incoming PPP packet size is still MRU + PPP header + CRC. If MRU is not negotiated this would be 1500 + PPP header + CRC. If the protocols use a payload of 1500 bytes and you desire the ability to send the payload on any link without fragmentation it is logical that MRU=MRRU=1500. Why negotiate for an MRU of 1500 if MP is not negotiated successfully and an MRU of 1506 if MP is negotiated successfully? --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 11:02:24 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA19429; Fri, 21 Feb 1997 11:02:24 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 11:02:24 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540815@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 01:00:15 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"1QX3L2.0.fh4.VRS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2734 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: Too many Items. Please divide and retry. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:59:58 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA04159 for ; Sat, 22 Feb 1997 00:59:27 +0900 Received: by fw.nikkeibp.co.jp; id AAA10583; Sat, 22 Feb 1997 00:59:32 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010561; Sat, 22 Feb 97 00:59:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06393 for ; Sat, 22 Feb 1997 00:58:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17920; Fri, 21 Feb 1997 10:56:28 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:56:28 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540479@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:54:36 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"Ysoo53.0.DM4.gLS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2731 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:54:25 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03886 for ; Sat, 22 Feb 1997 00:53:54 +0900 Received: by fw.nikkeibp.co.jp; id AAA10208; Sat, 22 Feb 1997 00:54:00 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010176; Sat, 22 Feb 97 00:53:36 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06287 for ; Sat, 22 Feb 1997 00:52:26 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17025; Fri, 21 Feb 1997 10:52:01 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:52:01 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540157@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:49:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"pc2zp.0.594.xHS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2726 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:49:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03595 for ; Sat, 22 Feb 1997 00:48:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09896; Sat, 22 Feb 1997 00:48:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009892; Sat, 22 Feb 97 00:48:46 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06193 for ; Sat, 22 Feb 1997 00:47:42 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16118; Fri, 21 Feb 1997 10:45:55 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:45:55 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539897@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:44:57 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"qyD-22.0.yw3.VCS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2720 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:44:47 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03432 for ; Sat, 22 Feb 1997 00:44:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09695; Sat, 22 Feb 1997 00:44:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009679; Sat, 22 Feb 97 00:44:07 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06141 for ; Sat, 22 Feb 1997 00:42:57 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15460; Fri, 21 Feb 1997 10:42:50 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:42:50 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539709@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:41:49 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"gdRDq1.0.Bn3.m9S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2719 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:41:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03332 for ; Sat, 22 Feb 1997 00:41:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09595; Sat, 22 Feb 1997 00:41:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009589; Sat, 22 Feb 97 00:41:13 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06109 for ; Sat, 22 Feb 1997 00:39:55 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14956; Fri, 21 Feb 1997 10:39:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:39:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539108@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"9Xebj2.0.Kf3.y6S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2716 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02977 for ; Sat, 22 Feb 1997 00:31:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09118; Sat, 22 Feb 1997 00:31:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009088; Sat, 22 Feb 97 00:31:04 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05915 for ; Sat, 22 Feb 1997 00:29:58 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13770; Fri, 21 Feb 1997 10:30:17 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:30:17 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538957@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:29:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"NiDNF3.0.dM3.wzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2712 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:29:13 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02819 for ; Sat, 22 Feb 1997 00:28:42 +0900 Received: by fw.nikkeibp.co.jp; id AAA08997; Sat, 22 Feb 1997 00:28:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008988; Sat, 22 Feb 97 00:28:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05879 for ; Sat, 22 Feb 1997 00:27:18 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13249; Fri, 21 Feb 1997 10:27:43 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:43 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538770@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:10 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SileH3.0.lE3.exR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2710 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02648 for ; Sat, 22 Feb 1997 00:25:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08822; Sat, 22 Feb 1997 00:25:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008815; Sat, 22 Feb 97 00:25:42 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05814 for ; Sat, 22 Feb 1997 00:24:38 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12823; Fri, 21 Feb 1997 10:24:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:59 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538648@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:08 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yacTi2.0.n73.zuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2708 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02546 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08724; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008715; Sat, 22 Feb 97 00:23:37 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05785 for ; Sat, 22 Feb 1997 00:22:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12243; Fri, 21 Feb 1997 10:20:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:20:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538344@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:19:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"GUGsS.0.z-2.ArR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2705 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:19:01 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02265 for ; Sat, 22 Feb 1997 00:18:30 +0900 Received: by fw.nikkeibp.co.jp; id AAA08352; Sat, 22 Feb 1997 00:18:36 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008333; Sat, 22 Feb 97 00:18:20 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05713 for ; Sat, 22 Feb 1997 00:17:08 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11947; Fri, 21 Feb 1997 10:16:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:56:20 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17912; Fri, 21 Feb 1997 10:56:20 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:56:20 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540440@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:53:59 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"G2ApG3.0.bJ4.3LS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2727 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:53:53 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03828 for ; Sat, 22 Feb 1997 00:53:22 +0900 Received: by fw.nikkeibp.co.jp; id AAA10141; Sat, 22 Feb 1997 00:53:27 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010126; Sat, 22 Feb 97 00:53:13 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06269 for ; Sat, 22 Feb 1997 00:52:04 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16963; Fri, 21 Feb 1997 10:51:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:51:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540186@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:49:46 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"MBfDE1.0.o44.zGS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2723 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:49:45 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03622 for ; Sat, 22 Feb 1997 00:49:14 +0900 Received: by fw.nikkeibp.co.jp; id AAA09917; Sat, 22 Feb 1997 00:49:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009906; Sat, 22 Feb 97 00:49:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06198 for ; Sat, 22 Feb 1997 00:47:58 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16455; Fri, 21 Feb 1997 10:48:24 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:48:24 -0500 (EST) Date: Fri, 21 Feb 1997 08:47:56 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702211547.IAA16108@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"Eg1yo.0.g04.uES3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2722 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > ... > IP > -------- "Inner MRU" > CCP > ECP > -------- MRRU > MP > -------- "Outer MRU" > LCP > ... > I think it would be better to negotiate the inner MRU explcitly, so I > would like to propose a new LCP option for this purpose. The default > value would be the same as the MRRU (if MP is negotiated) or the MRU > (if not using MP), so it would therefore not break any existing > implementations. > ... Not having the Inner MRU can be handled, but only with some ugly code. You can negotiate the MRRU and/or MRU to have the right, larger than necessary values. You can also tell your upper layers that the inner MRU is the MRRU less the ECP and CCP overhead. (Note that the CCP problem is not just extra headers but the worst case expansion of data for those compression schemes that can expand the data.) In 4.*BSD UNIX network code, it is not a problem to change the Inner MRU as long as you do it before the interface is made available to applications (i.e. the IFF_UP and IFF_RUNNING bits set). After the interface is up and applications are using it, you really do not want to change the if_mtu value in the struct if_net. CCP might come up after IPCP, or the compression scheme might be re-negotiated and changed, so you cannot count on getting IP up last. You might plan ahead and always try to negotiate a smaller Outer MRU, but the peer can always force you to use 1500. You might plan ahead and always use something smaller than 1500 for the Inner MRU, but that has undesirable side effects (IP fragmentation). Those difficulties asside, I fear it is about 9 years too late to fix the problem and have an explicit Inner MRU negotiation. Like my hobby horse of putting authentication into the Establish Phase, it is now so late that every implementation must forever be prepared to deal peers that do things the old way. If you must have all of that ugliness to deal with the problem when talking to ancient peers, why bother ever implementing the new, clean way? There is another problem with an Inner MRU option. What happens if the peers cannot agree on the Inner MRU? What if the user-data receiver wants a smaller value than the sender wants to send? If the send does not want to IP fragment, it need simply refuse to play the game, which means that even if the Inner MRU option had been proposed 8 or 9 years ago, we would still must have that nasty code to deal to deal with the case of not negotiating the Inner MRU, which means that negotiating the Inner MRU doesn't save us anything. Vernon Schryver, vjs@sgi.com --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 11:01:21 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA19149; Fri, 21 Feb 1997 11:01:21 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 11:01:21 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540772@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:59:31 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"vT8hS3.0.lg4._QS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2733 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:59:26 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA04109 for ; Sat, 22 Feb 1997 00:58:55 +0900 Received: by fw.nikkeibp.co.jp; id AAA10525; Sat, 22 Feb 1997 00:59:01 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010513; Sat, 22 Feb 97 00:58:53 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06385 for ; Sat, 22 Feb 1997 00:57:50 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17903; Fri, 21 Feb 1997 10:56:17 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:56:17 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540472@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:54:31 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"vHGJS2.0.PL4.OLS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2729 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:54:24 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03884 for ; Sat, 22 Feb 1997 00:53:54 +0900 Received: by fw.nikkeibp.co.jp; id AAA10206; Sat, 22 Feb 1997 00:53:59 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010130; Sat, 22 Feb 97 00:53:32 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06273 for ; Sat, 22 Feb 1997 00:52:10 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17000; Fri, 21 Feb 1997 10:51:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:51:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:43:18 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"rrDRN.0.584.UHS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2725 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:43:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03354 for ; Sat, 22 Feb 1997 00:42:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09627; Sat, 22 Feb 1997 00:42:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009625; Sat, 22 Feb 97 00:42:49 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06119 for ; Sat, 22 Feb 1997 00:41:45 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15185; Fri, 21 Feb 1997 10:41:35 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:41:35 -0500 (EST) Message-Id: <199702211541.KAA15156@merit.edu> Date: Fri, 21 Feb 97 10:37:29 EST From: "C. S. McIlvaine (444-9906)" To: ietf-ppp@MERIT.EDU Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"A_WAk.0.xi3.c8S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2717 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Is the MP header data, or part of the PPP header? My interpretation is that it is part of the PPP header. RFC1990 refers to "A new PPP header consisting of the Multilink Protocol Identifier, and the Multilink header." Yes, device drivers/hardware have to be changed to take into account the increased size of the PPP header (plus 10 bytes header instead of plus 4). Yes, this is a waste if you are not running MP. The incoming PPP packet size is still MRU + PPP header + CRC. If MRU is not negotiated this would be 1500 + PPP header + CRC. If the protocols use a payload of 1500 bytes and you desire the ability to send the payload on any link without fragmentation it is logical that MRU=MRRU=1500. Why negotiate for an MRU of 1500 if MP is not negotiated successfully and an MRU of 1506 if MP is negotiated successfully? --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 10:56:31 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17925; Fri, 21 Feb 1997 10:56:31 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:56:31 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540446@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:54:04 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"FhUjL.0.2L4.KLS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2728 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:53:53 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03829 for ; Sat, 22 Feb 1997 00:53:22 +0900 Received: by fw.nikkeibp.co.jp; id AAA10142; Sat, 22 Feb 1997 00:53:28 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010127; Sat, 22 Feb 97 00:53:16 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06272 for ; Sat, 22 Feb 1997 00:52:10 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16981; Fri, 21 Feb 1997 10:51:35 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:51:35 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540189@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:49:49 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"6jYeJ2.0.R54.5HS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2724 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:49:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03626 for ; Sat, 22 Feb 1997 00:49:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09918; Sat, 22 Feb 1997 00:49:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009907; Sat, 22 Feb 97 00:49:07 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06199 for ; Sat, 22 Feb 1997 00:48:03 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16404; Fri, 21 Feb 1997 10:47:54 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:47:54 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539907@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:45:07 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"pAR3g.0.vz3.KES3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2721 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:44:47 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03434 for ; Sat, 22 Feb 1997 00:44:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09690; Sat, 22 Feb 1997 00:44:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009670; Sat, 22 Feb 97 00:43:56 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06133 for ; Sat, 22 Feb 1997 00:42:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15382; Fri, 21 Feb 1997 10:42:07 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:42:07 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539619@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:40:19 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"Voc4V.0.Yj3.o8S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2718 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:40:16 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03253 for ; Sat, 22 Feb 1997 00:39:46 +0900 Received: by fw.nikkeibp.co.jp; id AAA09525; Sat, 22 Feb 1997 00:39:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009515; Sat, 22 Feb 97 00:39:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06093 for ; Sat, 22 Feb 1997 00:38:36 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14874; Fri, 21 Feb 1997 10:38:40 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:38:40 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539467@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:37:47 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VB__V.0.8e3.v5S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2715 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:37:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03163 for ; Sat, 22 Feb 1997 00:37:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09438; Sat, 22 Feb 1997 00:37:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009431; Sat, 22 Feb 97 00:37:17 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06081 for ; Sat, 22 Feb 1997 00:36:10 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14632; Fri, 21 Feb 1997 10:36:05 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:36:05 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539318@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:35:18 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SxgG7.0.Ea3.O3S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2714 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:35:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03070 for ; Sat, 22 Feb 1997 00:34:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09304; Sat, 22 Feb 1997 00:34:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009283; Sat, 22 Feb 97 00:34:33 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06050 for ; Sat, 22 Feb 1997 00:33:28 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14209; Fri, 21 Feb 1997 10:32:23 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:32:23 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539084@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:20 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"MXlUk1.0.VS3.s_R3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2713 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02915 for ; Sat, 22 Feb 1997 00:30:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA09068; Sat, 22 Feb 1997 00:30:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009060; Sat, 22 Feb 97 00:30:44 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05909 for ; Sat, 22 Feb 1997 00:29:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13623; Fri, 21 Feb 1997 10:29:51 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:29:51 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538928@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:28:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VrcmD2.0.aK3.fzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2711 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:28:44 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02799 for ; Sat, 22 Feb 1997 00:28:13 +0900 Received: by fw.nikkeibp.co.jp; id AAA08979; Sat, 22 Feb 1997 00:28:19 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008970; Sat, 22 Feb 97 00:28:02 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05873 for ; Sat, 22 Feb 1997 00:26:54 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13206; Fri, 21 Feb 1997 10:27:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:38 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"cyFbL2.0.eD3.LxR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2709 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:37 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02675 for ; Sat, 22 Feb 1997 00:26:06 +0900 Received: by fw.nikkeibp.co.jp; id AAA08853; Sat, 22 Feb 1997 00:26:13 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008824; Sat, 22 Feb 97 00:25:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05817 for ; Sat, 22 Feb 1997 00:24:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12805; Fri, 21 Feb 1997 10:24:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538650@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yNN8o2.0.Y73.wuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2707 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02544 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08723; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008710; Sat, 22 Feb 97 00:23:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05778 for ; Sat, 22 Feb 1997 00:22:13 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12532; Fri, 21 Feb 1997 10:22:52 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:52 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 11:12:01 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA20202; Fri, 21 Feb 1997 11:12:01 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 11:12:01 -0500 (EST) Message-Id: <199702211611.LAA05930@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 11:11:17 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"GFiWD2.0.Gx4.8bS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2736 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 10:58 AM >=20 >=20 >=20 > John Bray writes: >=20 > >Couldn't this be handled internally by simply adjusting > the upper=20 > >layer MTU to account for the additional overhead? Why > is it=20 > >necessary to negotiate this? >=20 > Because if I have an Upper Layer MRU of 1500, I might > want to=20 > negotiate the MRRU to 1524 in order to allow for the > CCP header. But=20 > then the peer might not support CCP, in which case it > would think=20 > that it could send me an IP packet of 1524 octets, which > I wouldn't=20 > be able to cope with. It seems to me it's the peer's responsibility to allow for the CCP=20 header. If you set your MRRU to 1500, the peer is forbidden to exceed=20 that. The logical way to do that would be for the peer to set its=20 upper layer MTU to, say, 1476 (or perhaps even smaller to allow for=20 expansion). _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 11:11:00 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA20146; Fri, 21 Feb 1997 11:11:00 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 11:11:00 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856541381@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 01:09:37 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"4IsDQ3.0.Rw4.CaS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2735 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 01:09:29 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id BAA04476 for ; Sat, 22 Feb 1997 01:08:58 +0900 Received: by fw.nikkeibp.co.jp; id BAA10948; Sat, 22 Feb 1997 01:09:04 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010940; Sat, 22 Feb 97 01:08:56 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id BAA06509 for ; Sat, 22 Feb 1997 01:07:50 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17909; Fri, 21 Feb 1997 10:56:19 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:56:19 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540469@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:54:26 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"D-pfr2.0.bL4.QLS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2730 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:54:23 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03878 for ; Sat, 22 Feb 1997 00:53:52 +0900 Received: by fw.nikkeibp.co.jp; id AAA10209; Sat, 22 Feb 1997 00:53:59 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010167; Sat, 22 Feb 97 00:53:38 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06288 for ; Sat, 22 Feb 1997 00:52:27 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11483; Fri, 21 Feb 1997 10:12:32 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:12:32 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537911@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:11:51 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VPzKg.0.9p2.RjR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2703 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:11:48 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01960 for ; Sat, 22 Feb 1997 00:11:18 +0900 Received: by fw.nikkeibp.co.jp; id AAA07979; Sat, 22 Feb 1997 00:11:24 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007966; Sat, 22 Feb 97 00:11:07 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05614 for ; Sat, 22 Feb 1997 00:10:02 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11275; Fri, 21 Feb 1997 10:10:14 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:10:14 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537456@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:04:16 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"65wJT2.0.rl2.HhR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2702 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:04:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01565 for ; Sat, 22 Feb 1997 00:03:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA07603; Sat, 22 Feb 1997 00:03:50 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007598; Sat, 22 Feb 97 00:03:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05476 for ; Sat, 22 Feb 1997 00:02:21 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA10776; Fri, 21 Feb 1997 10:02:22 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:02:22 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856537301@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:01:41 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ZmAPX.0.6e2.rZR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2701 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:01:39 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA01414 for ; Sat, 22 Feb 1997 00:01:08 +0900 Received: by fw.nikkeibp.co.jp; id AAA07433; Sat, 22 Feb 1997 00:01:15 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma007421; Sat, 22 Feb 97 00:01:01 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05428 for ; Fri, 21 Feb 1997 23:59:52 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA10449; Fri, 21 Feb 1997 09:59:56 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:59:56 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536375@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:46:15 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"l5ZjX.0.-Y2.cXR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2700 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:46:12 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00585 for ; Fri, 21 Feb 1997 23:45:41 +0900 Received: by fw.nikkeibp.co.jp; id XAA06583; Fri, 21 Feb 1997 23:45:48 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006575; Fri, 21 Feb 97 23:45:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05178 for ; Fri, 21 Feb 1997 23:44:17 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09854; Fri, 21 Feb 1997 09:44:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:44:59 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:43:16 +0000 Message-ID: <30db4cb0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Revisiting MRU-MRRU To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"Ai1LR2.0.iP2.cJR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2699 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From Patrick Klos: > >MRRU has nothing to do with MRU. It can be grater than, equal to or > >less than MRU's of the the individual links (remember MRU can be > >different for the different links in a multilink bundle.) >YES! This I think is one of the important points that some people >are missing. Well, I can only speak for myself, but I did not miss that point - it simply wasn't relevant to the case we were discussing, which was about sending a whole MP fragment: to be able to send a whole fragment of size MRRU then MRU must be >= MRRU+5. > >When using MP, the upper layer's (ie the protocol stacks) see a > >virtual link with a MTU which is equal to MRRU. Actually, this is only guaranteed when using neither compression nor encryption. Because of the overhead of the encryption header & padding, you may need the MRRU to be greater than the upper layer MTU. Which is why I think that the upper layer MTU and MRU need to be negotiated explicitly. --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 11:15:35 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA20629; Fri, 21 Feb 1997 11:15:35 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 11:15:35 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540803@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 01:00:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"lCLrB3.0.V15.PeS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2737 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:59:57 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA04157 for ; Sat, 22 Feb 1997 00:59:26 +0900 Received: by fw.nikkeibp.co.jp; id AAA10579; Sat, 22 Feb 1997 00:59:32 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010544; Sat, 22 Feb 97 00:59:06 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06389 for ; Sat, 22 Feb 1997 00:58:01 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17873; Fri, 21 Feb 1997 10:56:02 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:56:02 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540440@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:53:59 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"G2ApG3.0.bJ4.3LS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2727 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:53:53 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03828 for ; Sat, 22 Feb 1997 00:53:22 +0900 Received: by fw.nikkeibp.co.jp; id AAA10141; Sat, 22 Feb 1997 00:53:27 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010126; Sat, 22 Feb 97 00:53:13 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06269 for ; Sat, 22 Feb 1997 00:52:04 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16963; Fri, 21 Feb 1997 10:51:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:51:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540186@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:49:46 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"MBfDE1.0.o44.zGS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2723 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:49:45 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03622 for ; Sat, 22 Feb 1997 00:49:14 +0900 Received: by fw.nikkeibp.co.jp; id AAA09917; Sat, 22 Feb 1997 00:49:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009906; Sat, 22 Feb 97 00:49:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06198 for ; Sat, 22 Feb 1997 00:47:58 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16455; Fri, 21 Feb 1997 10:48:24 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:48:24 -0500 (EST) Date: Fri, 21 Feb 1997 08:47:56 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702211547.IAA16108@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"Eg1yo.0.g04.uES3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2722 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > ... > IP > -------- "Inner MRU" > CCP > ECP > -------- MRRU > MP > -------- "Outer MRU" > LCP > ... > I think it would be better to negotiate the inner MRU explcitly, so I > would like to propose a new LCP option for this purpose. The default > value would be the same as the MRRU (if MP is negotiated) or the MRU > (if not using MP), so it would therefore not break any existing > implementations. > ... Not having the Inner MRU can be handled, but only with some ugly code. You can negotiate the MRRU and/or MRU to have the right, larger than necessary values. You can also tell your upper layers that the inner MRU is the MRRU less the ECP and CCP overhead. (Note that the CCP problem is not just extra headers but the worst case expansion of data for those compression schemes that can expand the data.) In 4.*BSD UNIX network code, it is not a problem to change the Inner MRU as long as you do it before the interface is made available to applications (i.e. the IFF_UP and IFF_RUNNING bits set). After the interface is up and applications are using it, you really do not want to change the if_mtu value in the struct if_net. CCP might come up after IPCP, or the compression scheme might be re-negotiated and changed, so you cannot count on getting IP up last. You might plan ahead and always try to negotiate a smaller Outer MRU, but the peer can always force you to use 1500. You might plan ahead and always use something smaller than 1500 for the Inner MRU, but that has undesirable side effects (IP fragmentation). Those difficulties asside, I fear it is about 9 years too late to fix the problem and have an explicit Inner MRU negotiation. Like my hobby horse of putting authentication into the Establish Phase, it is now so late that every implementation must forever be prepared to deal peers that do things the old way. If you must have all of that ugliness to deal with the problem when talking to ancient peers, why bother ever implementing the new, clean way? There is another problem with an Inner MRU option. What happens if the peers cannot agree on the Inner MRU? What if the user-data receiver wants a smaller value than the sender wants to send? If the send does not want to IP fragment, it need simply refuse to play the game, which means that even if the Inner MRU option had been proposed 8 or 9 years ago, we would still must have that nasty code to deal to deal with the case of not negotiating the Inner MRU, which means that negotiating the Inner MRU doesn't save us anything. Vernon Schryver, vjs@sgi.com --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 11:16:39 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA20760; Fri, 21 Feb 1997 11:16:39 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 11:16:39 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540810@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 01:00:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"8QhSt.0.r35.QfS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2739 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:59:58 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA04159 for ; Sat, 22 Feb 1997 00:59:27 +0900 Received: by fw.nikkeibp.co.jp; id AAA10583; Sat, 22 Feb 1997 00:59:32 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010561; Sat, 22 Feb 97 00:59:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06393 for ; Sat, 22 Feb 1997 00:58:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17920; Fri, 21 Feb 1997 10:56:28 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:56:28 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540479@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:54:36 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"Ysoo53.0.DM4.gLS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2731 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:54:25 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03886 for ; Sat, 22 Feb 1997 00:53:54 +0900 Received: by fw.nikkeibp.co.jp; id AAA10208; Sat, 22 Feb 1997 00:54:00 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010176; Sat, 22 Feb 97 00:53:36 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06287 for ; Sat, 22 Feb 1997 00:52:26 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17025; Fri, 21 Feb 1997 10:52:01 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:52:01 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540157@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:49:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"pc2zp.0.594.xHS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2726 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:49:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03595 for ; Sat, 22 Feb 1997 00:48:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09896; Sat, 22 Feb 1997 00:48:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009892; Sat, 22 Feb 97 00:48:46 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06193 for ; Sat, 22 Feb 1997 00:47:42 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16118; Fri, 21 Feb 1997 10:45:55 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:45:55 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539897@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:44:57 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"qyD-22.0.yw3.VCS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2720 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:44:47 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03432 for ; Sat, 22 Feb 1997 00:44:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09695; Sat, 22 Feb 1997 00:44:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009679; Sat, 22 Feb 97 00:44:07 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06141 for ; Sat, 22 Feb 1997 00:42:57 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15460; Fri, 21 Feb 1997 10:42:50 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:42:50 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539709@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:41:49 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"gdRDq1.0.Bn3.m9S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2719 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:41:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03332 for ; Sat, 22 Feb 1997 00:41:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09595; Sat, 22 Feb 1997 00:41:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009589; Sat, 22 Feb 97 00:41:13 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06109 for ; Sat, 22 Feb 1997 00:39:55 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14956; Fri, 21 Feb 1997 10:39:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:39:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539108@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"9Xebj2.0.Kf3.y6S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2716 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02977 for ; Sat, 22 Feb 1997 00:31:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09118; Sat, 22 Feb 1997 00:31:21 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009088; Sat, 22 Feb 97 00:31:04 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05915 for ; Sat, 22 Feb 1997 00:29:58 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13770; Fri, 21 Feb 1997 10:30:17 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:30:17 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538957@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:29:17 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"NiDNF3.0.dM3.wzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2712 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:29:13 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02819 for ; Sat, 22 Feb 1997 00:28:42 +0900 Received: by fw.nikkeibp.co.jp; id AAA08997; Sat, 22 Feb 1997 00:28:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008988; Sat, 22 Feb 97 00:28:23 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05879 for ; Sat, 22 Feb 1997 00:27:18 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13249; Fri, 21 Feb 1997 10:27:43 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:43 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538770@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:10 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SileH3.0.lE3.exR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2710 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02648 for ; Sat, 22 Feb 1997 00:25:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08822; Sat, 22 Feb 1997 00:25:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008815; Sat, 22 Feb 97 00:25:42 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05814 for ; Sat, 22 Feb 1997 00:24:38 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12823; Fri, 21 Feb 1997 10:24:59 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:59 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538648@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:08 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yacTi2.0.n73.zuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2708 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02546 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08724; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008715; Sat, 22 Feb 97 00:23:37 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05785 for ; Sat, 22 Feb 1997 00:22:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12243; Fri, 21 Feb 1997 10:20:48 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:20:48 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538344@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:19:03 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"GUGsS.0.z-2.ArR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2705 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:19:01 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02265 for ; Sat, 22 Feb 1997 00:18:30 +0900 Received: by fw.nikkeibp.co.jp; id AAA08352; Sat, 22 Feb 1997 00:18:36 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008333; Sat, 22 Feb 97 00:18:20 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05713 for ; Sat, 22 Feb 1997 00:17:08 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA11947; Fri, 21 Feb 1997 10:16:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:16:57 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536164@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:42:43 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"UQGW21.0.Nw2.ZnR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2704 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:42:40 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA00426 for ; Fri, 21 Feb 1997 23:42:10 +0900 Received: by fw.nikkeibp.co.jp; id XAA06391; Fri, 21 Feb 1997 23:42:16 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma006357; Fri, 21 Feb 97 23:42:05 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA05111 for ; Fri, 21 Feb 1997 23:41:00 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA09594; Fri, 21 Feb 1997 09:41:25 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:41:25 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702218565.AA856536036@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Fri, 21 Feb 97 23:40:34 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"ilNCJ2.0.cL2.GGR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2698 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Fri, 21 Feb 97 23:20:11 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id XAA29347 for ; Fri, 21 Feb 1997 23:19:40 +0900 Received: by fw.nikkeibp.co.jp; id XAA05438; Fri, 21 Feb 1997 23:19:46 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma005413; Fri, 21 Feb 97 23:19:18 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id XAA04873 for ; Fri, 21 Feb 1997 23:18:14 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA08906; Fri, 21 Feb 1997 09:18:49 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 09:18:49 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 14:10:20 +0000 Message-ID: <30dae930@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: VJ compression, Tunneling and TAs To: ietf-ppp@MERIT.EDU, "Kyle Farnsworth" Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bcJNe.0.oA2.3xQ3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2697 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: >Datagrams pass through untouched with the exception of aborts or non-octet >alignment errors. In which case they are dropped. Aren't aborts also potentially TYPE-ERRORs ? (You could get a noise hit on the end flag which turned the frame into an abort.) Similarly for non-octet alignment errors. >Obviously, if the TA is doing the Multilink bad CRC's frames are dropped. Ah, so the TA could break VJ compression. Perhaps it's not been noticed because error rates on ISDN lines are so low, so maybe the situation hardly ever arises. But if it was my product I wouldn't want to count on it.... --- Jonathan.Goodchild@rdl.co.uk --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 11:15:50 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA20686; Fri, 21 Feb 1997 11:15:50 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 11:15:50 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540830@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 01:00:30 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"01Pur1.0.W25.feS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2738 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 01:00:26 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA04192 for ; Sat, 22 Feb 1997 00:59:55 +0900 Received: by fw.nikkeibp.co.jp; id BAA10626; Sat, 22 Feb 1997 01:00:01 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010605; Sat, 22 Feb 97 00:59:38 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06403 for ; Sat, 22 Feb 1997 00:58:33 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA17900; Fri, 21 Feb 1997 10:56:16 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:56:16 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540446@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:54:04 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"FhUjL.0.2L4.KLS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2728 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:53:53 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03829 for ; Sat, 22 Feb 1997 00:53:22 +0900 Received: by fw.nikkeibp.co.jp; id AAA10142; Sat, 22 Feb 1997 00:53:28 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma010127; Sat, 22 Feb 97 00:53:16 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06272 for ; Sat, 22 Feb 1997 00:52:10 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16981; Fri, 21 Feb 1997 10:51:35 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:51:35 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856540189@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:49:49 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"6jYeJ2.0.R54.5HS3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2724 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:49:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03626 for ; Sat, 22 Feb 1997 00:49:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09918; Sat, 22 Feb 1997 00:49:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009907; Sat, 22 Feb 97 00:49:07 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06199 for ; Sat, 22 Feb 1997 00:48:03 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA16404; Fri, 21 Feb 1997 10:47:54 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:47:54 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539907@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:45:07 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"pAR3g.0.vz3.KES3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2721 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:44:47 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03434 for ; Sat, 22 Feb 1997 00:44:16 +0900 Received: by fw.nikkeibp.co.jp; id AAA09690; Sat, 22 Feb 1997 00:44:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009670; Sat, 22 Feb 97 00:43:56 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06133 for ; Sat, 22 Feb 1997 00:42:32 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA15382; Fri, 21 Feb 1997 10:42:07 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:42:07 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539619@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:40:19 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"Voc4V.0.Yj3.o8S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2718 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:40:16 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03253 for ; Sat, 22 Feb 1997 00:39:46 +0900 Received: by fw.nikkeibp.co.jp; id AAA09525; Sat, 22 Feb 1997 00:39:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009515; Sat, 22 Feb 97 00:39:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06093 for ; Sat, 22 Feb 1997 00:38:36 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14874; Fri, 21 Feb 1997 10:38:40 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:38:40 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539467@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:37:47 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VB__V.0.8e3.v5S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2715 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:37:46 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03163 for ; Sat, 22 Feb 1997 00:37:15 +0900 Received: by fw.nikkeibp.co.jp; id AAA09438; Sat, 22 Feb 1997 00:37:22 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009431; Sat, 22 Feb 97 00:37:17 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06081 for ; Sat, 22 Feb 1997 00:36:10 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14632; Fri, 21 Feb 1997 10:36:05 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:36:05 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539318@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:35:18 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"SxgG7.0.Ea3.O3S3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2714 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:35:15 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA03070 for ; Sat, 22 Feb 1997 00:34:44 +0900 Received: by fw.nikkeibp.co.jp; id AAA09304; Sat, 22 Feb 1997 00:34:51 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009283; Sat, 22 Feb 97 00:34:33 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA06050 for ; Sat, 22 Feb 1997 00:33:28 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA14209; Fri, 21 Feb 1997 10:32:23 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:32:23 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856539084@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:31:20 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"MXlUk1.0.VS3.s_R3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2713 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:31:14 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02915 for ; Sat, 22 Feb 1997 00:30:43 +0900 Received: by fw.nikkeibp.co.jp; id AAA09068; Sat, 22 Feb 1997 00:30:49 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma009060; Sat, 22 Feb 97 00:30:44 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05909 for ; Sat, 22 Feb 1997 00:29:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13623; Fri, 21 Feb 1997 10:29:51 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:29:51 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538928@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:28:48 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"VrcmD2.0.aK3.fzR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2711 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:28:44 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02799 for ; Sat, 22 Feb 1997 00:28:13 +0900 Received: by fw.nikkeibp.co.jp; id AAA08979; Sat, 22 Feb 1997 00:28:19 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008970; Sat, 22 Feb 97 00:28:02 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05873 for ; Sat, 22 Feb 1997 00:26:54 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA13206; Fri, 21 Feb 1997 10:27:27 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:27:27 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538798@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:26:38 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"cyFbL2.0.eD3.LxR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2709 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:26:37 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02675 for ; Sat, 22 Feb 1997 00:26:06 +0900 Received: by fw.nikkeibp.co.jp; id AAA08853; Sat, 22 Feb 1997 00:26:13 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008824; Sat, 22 Feb 97 00:25:43 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05817 for ; Sat, 22 Feb 1997 00:24:40 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12805; Fri, 21 Feb 1997 10:24:53 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:24:53 -0500 (EST) From: intermgr_at_nikkeibp/router@cm.nikkeibp.co.jp Message-Id: <9702228565.AA856538650@cm.nikkeibp.co.jp> X-Mailer: ccMail Link to SMTP R6.0 Date: Sat, 22 Feb 97 00:24:09 +0900 To: Subject: cc:Mail Link to SMTP Undeliverable Message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" Resent-Message-ID: <"yNN8o2.0.Y73.wuR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2707 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Message is undeliverable. Reason: User "takahiro_kikuchi@cm.nikkeibp.co.jp" is not found in the cc:Mail Directory. Original text follows: --------------------- --simple boundary Content-Type: text/plain; charset=US-ACSII Content-Transfer-Encoding: 7bit Received: from bpmail.nikkeibp.co.jp by cm.nikkeibp.co.jp (ccMail Link to SMTP R6.0) ; Sat, 22 Feb 97 00:24:07 +0900 Return-Path: Received: from fw.nikkeibp.co.jp (firewall-user@[162.4.96.11]) by bpmail.nikkeibp.co.jp (8.6.10+2.4W/3.3W6-950210m) with ESMTP id AAA02544 for ; Sat, 22 Feb 1997 00:23:36 +0900 Received: by fw.nikkeibp.co.jp; id AAA08723; Sat, 22 Feb 1997 00:23:43 +0900 (JST) Received: from bpwww.nikkeibp.co.jp(202.26.186.35) by fw.nikkeibp.co.jp via smap (g3.0.3) id xma008710; Sat, 22 Feb 97 00:23:30 +0900 Received: from merit.edu (merit.edu [35.1.1.42]) by bpwww.nikkeibp.co.jp (8.7.1+2.6Wbeta4/3.3W6-950210w) with ESMTP id AAA05778 for ; Sat, 22 Feb 1997 00:22:13 +0900 (JST) Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA12532; Fri, 21 Feb 1997 10:22:52 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 10:22:52 -0500 (EST) Message-Id: <199702211522.KAA00884@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 10:22:09 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"tKjj1.0.B33.4tR3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2706 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from Jonathan Goodchild=20 (Jonathan.Goodchild@rdl.co.uk) dated 2/21/97 9:52 AM >=20 > > >When using MP, the upper layer's (ie the protocol > stacks) see a=20 > > >virtual link with a MTU which is equal to MRRU.=20 Strictly speaking, the MTU need not be *equal* to the MRRU (or MRU=20 for single-link). It could be (and in some cases must be) less. >=20 > Actually, this is only guaranteed when using neither > compression nor=20 > encryption. Because of the overhead of the encryption > header &=20 > padding, you may need the MRRU to be greater than > the upper layer=20 > MTU. Which is why I think that the upper layer MTU > and MRU need to=20 > be negotiated explicitly. >=20 Couldn't this be handled internally by simply adjusting the upper=20 layer MTU to account for the additional overhead? Why is it necessary=20 to negotiate this? _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 (508) 684-6645 E-mail: bray@ftp.com --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- --simple boundary-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 11:52:57 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA22301; Fri, 21 Feb 1997 11:52:57 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 11:52:57 -0500 (EST) Mime-Version: 1.0 Date: Fri, 21 Feb 1997 16:50:51 +0000 Message-ID: <30dd2c50@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Revisiting MRU-MRRU To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"YYXYQ3.0.8S5.YBT3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2740 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: >Those difficulties asside, I fear it is about 9 years too late to fix >the problem and have an explicit Inner MRU negotiation. Like my hobby >horse of putting authentication into the Establish Phase, it is now so >late that every implementation must forever be prepared to deal peers >that do things the old way. If you must have all of that ugliness >to deal with the problem when talking to ancient peers, why bother ever >implementing the new, clean way? I feared as much, although there's no harm in trying, except for the endlessly repeated undeliverable message notifications :-( However, if the new option improved performance by preventing the need for IP fragmentation, it might be worthwhile, especially if it improved interoperabily as well. >There is another problem with an Inner MRU option. What happens if the >peers cannot agree on the Inner MRU? What if the user-data receiver >wants a smaller value than the sender wants to send? If the send does >not want to IP fragment, it need simply refuse to play the game, which >means that even if the Inner MRU option had been proposed 8 or 9 years >ago, we would still must have that nasty code to deal to deal with the >case of not negotiating the Inner MRU, which means that negotiating the >Inner MRU doesn't save us anything. Good point, but if it had been proposed 8 or 9 years ago it could have defaulted to 1500, which would solve those problems. --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 12:22:04 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id MAA23339; Fri, 21 Feb 1997 12:22:04 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 12:22:04 -0500 (EST) Date: Fri, 21 Feb 1997 10:21:40 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702211721.KAA16350@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"JFvWA1.0.Ji5.rcT3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2741 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "C. S. McIlvaine (444-9906)" > Is the MP header data, or part of the PPP header? > My interpretation is that it is part of the PPP > header. RFC1990 refers to "A new PPP header consisting > of the Multilink Protocol Identifier, and the Multilink > header." Would you interpret the ECP and CCP standards in the same way? No, instead, the word "new" should be understood as "additional". The words themselves might be read that as making the MRU negotiation completely meaningless, but if you look at the mailing list archives (i.e. do as the U.S. Supreme Court does to determine the intent of Congress), you'll find that is not what they were intended to mean. Look at it as a layering issue. If your implementation had any separation between the parts that deal with raw PPP frames and the parts that deal with ECP, CCP, and MP, how would you handle the MRU? The raw PPP machine should not have to know whether the packet involves ECP, CCP, and MP. It should just handle PPP frames without having to peak inside. > ... > If the protocols use a payload of 1500 bytes and you > desire the ability to send the payload on any link without > fragmentation it is logical that MRU=MRRU=1500. Why negotiate > for an MRU of 1500 if MP is not negotiated successfully and an > MRU of 1506 if MP is negotiated successfully? It makes perfect sense to negotiate MRU=MRRU=1500. It does imply that a 1480 byte IP packet with 20 byte IP header will have to be fragmented by MRRU. That may be undesirable, but it does make perfect sense. I seem to recall proposing in the PPP mailing list before RFC 1990 that the default value for the MRRU be 1500+MP_header_size, and getting shot down. No one else wanted to complicate the words, since RFC 1990 now refers to the 1500 default without naming it. Besides, you can no longer have MP without negotiating the MRRU. ] From: John Bray ] ... ] It seems to me it's the peer's responsibility to allow for the CCP ] header. If you set your MRRU to 1500, the peer is forbidden to exceed ] that. The logical way to do that would be for the peer to set its ] upper layer MTU to, say, 1476 (or perhaps even smaller to allow for ] expansion). Yes, that's what the peer must do, nasty as it is, especially in implementations that support demand dialing. (Then you have an IP interface that outlives PPP links. If on the next PPP link you let the peer have a smaller MRU, you're forced to renege on the MTU you gave your upper layers such as TCP and IP , which is Not Nice(tm) (think of the TCP MSS negotiation).) I guess that's why we get the big bucks. } From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) (about an Inner MRU option) } Good point, but if it had been proposed 8 or 9 years ago it could have } defaulted to 1500, which would solve those problems. Yes, except I think you'd want to default the Outer MRU to about 1580 and the the middle MRU or MRRU to about 1540 so that the Inner MRU could always be 1500. What about tunneling? Then you have an Inner-Outer or Outer-Inner MRU to worry about. Or is it an Outer-Outer? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 14:51:06 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA26572; Fri, 21 Feb 1997 14:51:06 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 14:51:06 -0500 (EST) From: revell@lucent.com (Revell Ruttenberg) Date: Fri, 21 Feb 1997 13:52:35 -0600 Message-Id: <199702211952.NAA21109@ihgp128f.ih.lucent.com> Original-From: revell@ihgp.ih.lucent.com (Revell Ruttenberg) To: ietf-ppp@MERIT.EDU Subject: 16 bit fcs computation Content-Type: text Resent-Message-ID: <"E_jK81.0.oU6.UoV3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2742 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU on pages 20-21 how would this algorithmn be used to generate a FCS calculation over say, 0x90, 0x87, 0x50 ( 3 bytes )? What would the inital FCS value be, or where did 0xffff come from? How would we validate the FCS value? thanks! Lucent Technologies _/_/_/_/ _/_/_/_/ _/ _/ Rev Ruttenberg _/ _/ _/ _/ _/ IX 1G405 _/_/_/_/ _/_/_/_/ _/ _/ 630 979-0972 _/ _/ _/ _/ _/ ihgp!revell _/ _/ _/_/_/_/ _/ revell@lucent.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 14:54:51 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id OAA26829; Fri, 21 Feb 1997 14:54:51 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 14:54:51 -0500 (EST) Message-Id: <199702211954.OAA27942@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: mcilvaine@VNET.IBM.COM, ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: RE: Revisiting MRU-MRRU Date: Fri, 21 Feb 1997 14:54:06 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"z6kQQ3.0.uY6.4sV3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2743 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>Reply to message from C. S. McIlvaine (444-9906)=20 (mcilvaine@VNET.IBM.COM) dated 2/21/97 10:49 AM >=20 > Is the MP header data, or part of the PPP header? > My interpretation is that it is part of the PPP > header. RFC1990 refers to "A new PPP header > consisting > of the Multilink Protocol Identifier, and the Multilink > header." The MP header is part of the information field of the PPP packet=20 (just as an IP header is). It is not part of the PPP header,=20 notwithstanding the somewhat misleading wording in RFC1990. >=20 > Yes, device drivers/hardware have to be changed to > take > into account the increased size of the PPP header (plus > 10 bytes header instead of plus 4). Yes, this is a waste > if you are not running MP. The incoming PPP packet > size > is still MRU + PPP header + CRC. If MRU is not > negotiated > this would be 1500 + PPP header + CRC. If you want to negotiate a larger MRU value to allow for the MP=20 header, you're perfectly free to do so. What you are not free to do=20 is to assume that the MRU does not include the MP header. It does. >=20 > If the protocols use a payload of 1500 bytes and you > desire the ability to send the payload on any link > without > fragmentation it is logical that MRU=3DMRRU=3D1500. Why > negotiate > for an MRU of 1500 if MP is not negotiated successfully > and an > MRU of 1506 if MP is negotiated successfully? You don't have to, but as you've pointed out, packets which are=20 larger than MRU minus MP header will be fragmented if you don't. _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 E-mail: bray@ftp.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 21 18:25:14 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id SAA01133; Fri, 21 Feb 1997 18:25:14 -0500 (EST) Resent-Date: Fri, 21 Feb 1997 18:25:14 -0500 (EST) Message-Id: <199702212324.SAA01093@merit.edu> From: Stuart Venters Subject: Re: 16 bit fcs computation To: revell@lucent.com (Revell Ruttenberg) (Revell Ruttenberg) Date: Fri, 21 Feb 97 17:00:41 CST Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199702211952.NAA21109@ihgp128f.ih.lucent.com>; from "Revell Ruttenberg" at Feb 21, 97 1:52 pm Mailer: Elm [revision: 70.85] Resent-Message-ID: <"g9X-B.0.HH.GxY3p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2744 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU i think it works this way: > > > on pages 20-21 how would this algorithmn be used to generate > a FCS calculation over say, 0x90, 0x87, 0x50 ( 3 bytes )? > What would the inital FCS value be, or where did 0xffff come > from? 1) initialize sum to ff ff 2) clock in the three bytes 90 87 50 3) resulting sum is 0b 23 4) transmit the 1's comp f4 dc > > How would we validate the FCS value? 1) initialize sum to ff ff 2) clock in the message bytes including the crc 90 87 50 f4 dc 3) resulting sum should always be b8 f0 > the following program should let you make test cases on a pc . it has been tested against hardware hdlc controllers and i think it is correct. If you find otherwise, please let me know. Stuart Venters, Adtran /* pppcalc.c ppp hdlc checksum calculator */ #include /* table from PPP spec */ static unsigned int fcstab[256] = { 0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf, 0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7, 0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e, 0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876, 0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd, 0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5, 0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c, 0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974, 0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb, 0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3, 0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a, 0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72, 0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9, 0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1, 0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738, 0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70, 0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7, 0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff, 0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036, 0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e, 0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5, 0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd, 0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134, 0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c, 0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3, 0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb, 0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232, 0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a, 0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1, 0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9, 0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330, 0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78 }; /* Command/response checksum polynomial (see V.41) */ #define PM_CRC_POLY 0x8408 /* X**12 + X**5 + X**0 */ unsigned int Remainder; /* PPP CRC remainder */ unsigned int Test; /* PPP CRC remainder Test */ typedef unsigned char BYTE; /* Update the CRC accumulator for a data byte */ /* Calculation is per CCITT/PPP spec */ /* X**0 is Remainder LSB */ static void CrcByte( BYTE TheByte ) { BYTE i; Remainder ^= TheByte; for( i=0; i<8; i++) { if( Remainder & 1) Remainder = (Remainder >> 1) ^ PM_CRC_POLY; else Remainder = Remainder >> 1; } Test = (Test >> 8) ^ fcstab[(Test ^ TheByte) & 255]; } /* CrcByte */ main( argc, argv ) int argc; char *argv[]; { int i; int Temp; if( argc < 2) { fprintf(stderr,"usage: pppcalc 00 13 1a"); exit(1); } Remainder = 0xffff; Test = 0xffff; for( i=1; i> 8; printf("\nCRC2=%x (Xmt=%x)",Temp, 255 & ~Temp); return(0); }  - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 24 05:55:17 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id FAA29205; Mon, 24 Feb 1997 05:55:17 -0500 (EST) Resent-Date: Mon, 24 Feb 1997 05:55:17 -0500 (EST) Mime-Version: 1.0 Date: Mon, 24 Feb 1997 10:30:44 +0000 Message-ID: <3116f320@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Revisiting MRU-MRRU To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"dkkia.0.087.XDN4p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2745 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: >.. >I seem to recall proposing in the PPP mailing list before RFC 1990 >that the default value for the MRRU be 1500+MP_header_size, and >getting shot down. I'm not surprised What would be the point of that ? Seeing as MRRU would normally be the MRU of the upper layer (except with CCP & ECP) a default MRRU would naturally be 1500. >] It seems to me it's the peer's responsibility to allow for the CCP >] header. If you set your MRRU to 1500, the peer is forbidden to exceed >] that. The logical way to do that would be for the peer to set its >] upper layer MTU to, say, 1476 (or perhaps even smaller to allow for >] expansion). > >Yes, that's what the peer must do, nasty as it is... Well, not necessarily for CCP as it always has the option of sending the packet in native encapsulation. It is, however, true for ECP. If you want to be able to receive an upper layer protocol unit of 1500 byte, what do you set your value of the MRU to ? How do you know that the peer will use the same rules to derive the Inner MRU ? Are you saying that the only way of preventing the peer from sending anything larger than your inner MRU is to negotiate the (outer) MRU (or MRRU, as applicable) to the value of the inner MRU and force the peer to fragment the upper layer protocol ? Anyway, what about protocols other than IP which aren't fragmentable ? Is it possible to fragment bridged packets, for example ? Ok, when you're using MP you can use MP fragmentation, but what happens when you're not using MP? It seems to me that the only thing you can do is negotiate MRU of Inner MRU + header + padding and hope that the peer doesn't send anything that exceeds the Inner MRU. Not really very satisfactory. Alternatively, you configure your inner MRU to be at least as large as anything that you would expect to receive from the peer. Or perhaps in real life everyone uses an inner MRU of 1500 ? Or they rely on manual re-configuration if a connection fails to work properly ? I still think negotiating the Inner MRU could be a good idea - ok it's no use for interoperability with existing equipment, but then it's only compression which causes the difficulty, and if you assume that the inner MRU is the same as the MRU (or the MRRU as applicable), you can send anything that expands to exceed it in native encapsulation. The real killer is encryption, but encryption is new (or at least, interoperability between different equipment is new) - after all, we're in the process of changing the DESE spec, so we could easily add an additional requirement to negotiate the inner MRU. >What about tunneling? Then you have an Inner-Outer or Outer-Inner MRU to >worry about. Or is it an Outer-Outer? Tunnelling is also new, so maybe it could use the Inner MRU option. >... >I guess that's why we get the big bucks. Speak for yourself :-) --- Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 24 10:02:17 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id KAA03775; Mon, 24 Feb 1997 10:02:17 -0500 (EST) Resent-Date: Mon, 24 Feb 1997 10:02:17 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eaprsa-04.txt Date: Mon, 24 Feb 1997 09:51:19 -0500 Sender: cclark@ietf.org Message-ID: <9702240951.aa12947@ietf.org> Resent-Message-ID: <"soLUN3.0.ew.lrQ4p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2746 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP EAP RSA Public Key Authentication Protocol Author(s) : W. Whelan Filename : draft-ietf-pppext-eaprsa-04.txt Pages : 14 Date : 02/20/1997 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authentication its peer before allowing Network Layer protocols to transmit over the link. PPP Extensible Authentication Protocol (EAP) [2] provides for a number of authentication mechanisms. One of these is RSA Public Key Authentication. This document defines RSA Public Key Authentication Protocol within PPP EAP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-eaprsa-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eaprsa-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eaprsa-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970221102616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eaprsa-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eaprsa-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970221102616.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 24 11:37:52 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA06599; Mon, 24 Feb 1997 11:37:52 -0500 (EST) Resent-Date: Mon, 24 Feb 1997 11:37:52 -0500 (EST) Date: Mon, 24 Feb 1997 08:37:36 -0800 Message-Id: <199702241637.IAA12247@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Subject: PPP EAP RSA Public Key Authentication Protocol - Working Group Last Call Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"Db8de2.0.kc1.OFS4p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2747 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This is last call. I will advise the area directors that we want to take the PPP EAP RSA Public Key Authentication Protocol to Informational Standard on March 10 unless there is substantive comment raised on the list. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Feb 24 15:05:26 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id PAA11948; Mon, 24 Feb 1997 15:05:26 -0500 (EST) Resent-Date: Mon, 24 Feb 1997 15:05:26 -0500 (EST) Date: Mon, 24 Feb 1997 13:03:25 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199702242003.NAA08248@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Revisiting MRU-MRRU Resent-Message-ID: <"5R1hA3.0.Gw2.tHV4p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2748 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > Well, not necessarily for CCP as it always has the option of sending the > packet in native encapsulation. ... That is true only for come flavors of CCP. Others are vulnerable to inflation and cannot use native encapsulation. > If you want to be able to receive an upper layer protocol unit of 1500 > byte, what do you set your value of the MRU to ? That depends on the situation. For MP with long sequence numbers, I try for an MRRU of 1500 and an MRU of 1505. If I might be using Predictor compression, I reduce the MTU by 6 bytes, which is the worst case inflation for it. (MTU, not MRU) And I follow the "generous in what you accept" and only complain about packets up to 10K. > How do you know that > the peer will use the same rules to derive the Inner MRU ? Are you > saying that the only way of preventing the peer from sending anything > larger than your inner MRU is to negotiate the (outer) MRU (or MRRU, as > applicable) to the value of the inner MRU and force the peer to fragment > the upper layer protocol ? Yes, as far as that goes, I see no alternative. It doesn't go very far because the peer might force you to accept an MRU of 1500 by rejecting the LCP MRU negotiation. They you are stuck with accepting bloated packets. > Anyway, what about protocols other than IP which aren't fragmentable ? > Is it possible to fragment bridged packets, for example ? Ok, when > you're using MP you can use MP fragmentation, but what happens when > you're not using MP? > > It seems to me that the only thing you can do is negotiate MRU of Inner > MRU + header + padding and hope that the peer doesn't send anything that > exceeds the Inner MRU. Not really very satisfactory. Yes, just about as bad as having authentication after LCP. And related, since it is not until you have a name for the remote via authentication, it's hard to know its preferred values. > Alternatively, you configure your inner MRU to be at least as large as > anything that you would expect to receive from the peer. The MTU is a bigger problem. With BSD code or any other design I can imagine built to handle more media than PPP and Ethernet (e.g. ATM or FDDI), you can always be generous and accept packets a little too long. But you must not stress the peer, and so must ensure your MTU is conservative. And changing the MTU is painful for hosts. > Or perhaps in real life everyone uses an inner MRU of 1500 ? Or they > rely on manual re-configuration if a connection fails to work properly ? Or they're generous in what they accept. > I still think negotiating the Inner MRU could be a good idea - ok it's > no use for interoperability with existing equipment, but then it's only > compression which causes the difficulty, and if you assume that the > inner MRU is the same as the MRU (or the MRRU as applicable), you can > send anything that expands to exceed it in native encapsulation. I still think authentication belongs in LCP. > The real killer is encryption, but encryption is new (or at least, > interoperability between different equipment is new) - after all, we're > in the process of changing the DESE spec, so we could easily add an > additional requirement to negotiate the inner MRU. > > >What about tunneling? Then you have an Inner-Outer or Outer-Inner MRU to > >worry about. Or is it an Outer-Outer? > > Tunnelling is also new, so maybe it could use the Inner MRU option. But tunnelling's design goals include being invisible to current PC software. > ... > >I guess that's why we get the big bucks. > Speak for yourself :-) Oh? So your boss thinks you deserve more money than you're getting? Here's a completely different hassle. I think I've finally nailed some bogus FCS errors I've been seeing under odd cases. Consider what happens in the following: 1. you start, using both transmit and receive ACCM=0xffffffff (recall the receive ACCM tells you to discard bytes that should have been escaped) 2. LCP negotiates ACCM=0 3. things go fine for a while, then you drop out of the Network Phase for one of: - terminating the link - changing LCP parameters - re-checking PAP password 4. after you restore both ACCM's to 0xffffffff, but before the peer gets your packet and does the same, you get a packet from the peer where it used a transmit ACCM of 0x0. So you'll honor your receive ACCM and throw away all bytes from 0x00 to 0x1f, and so get a bad FCS. I found consistent cases of this while testing other stuff using rlogin/TCP/IP beneath PPP. My partial solution is to never revert to a receive ACCM of 0xffffffff, but to stick whatever the peer sent before, initialzed to 0xffffffff before hearing from the peer. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 25 18:13:02 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id SAA06110; Tue, 25 Feb 1997 18:13:02 -0500 (EST) Resent-Date: Tue, 25 Feb 1997 18:13:02 -0500 (EST) To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@MERIT.EDU From: The IESG Subject: Document Action: Microsoft Point-To-Point Compression (MPPC) Protocol to Informational Date: Tue, 25 Feb 1997 18:12:52 -0500 Sender: scoya@ietf.org Message-ID: <9702251812.aa03352@ietf.org> Resent-Message-ID: <"3au3y3.0.6V1.t7t4p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2750 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IESG has reviewed the Internet-Draft "Microsoft Point-To-Point Compression (MPPC) Protocol" and recommends that it be published by the RFC Editor as an Informational RFC. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 25 18:12:08 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id SAA06040; Tue, 25 Feb 1997 18:12:08 -0500 (EST) Resent-Date: Tue, 25 Feb 1997 18:12:08 -0500 (EST) To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@MERIT.EDU From: The IESG Subject: Protocol Action: The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP) to Proposed Standard Date: Tue, 25 Feb 1997 18:08:31 -0500 Sender: scoya@ietf.org Message-ID: <9702251808.aa02922@ietf.org> Resent-Message-ID: <"HlWyP2.0.uT1.J6t4p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2749 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IESG has approved the Internet-Draft "The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP)" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan. Technical Summary This document defines a protocol used to dynamically allocate bandwidth on PPP links which are using the PPP Multilink Protocol. The protocol includes mechanisms for adding links to and deleting links from the multilink bundle. Working Group Summary This protocol was developed in the PPPEXT working group. Development was without rancor. Protocol Quality The protocol has been reviewed by Frank Kastenholz and Jeff Burgan. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Feb 25 19:01:18 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id TAA07147; Tue, 25 Feb 1997 19:01:18 -0500 (EST) Resent-Date: Tue, 25 Feb 1997 19:01:18 -0500 (EST) Message-Id: <2.2.32.19970226000152.002fb428@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Feb 1997 16:01:52 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: Re: Protocol Action: The PPP Bandwidth Allocation Protocol (BAP) Resent-Message-ID: <"dr6Gb3.0.Kl1.8rt4p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2751 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 06:08 PM 2/25/97 -0500, The IESG wrote: > > > The IESG has approved the Internet-Draft "The PPP Bandwidth > Allocation Protocol (BAP) The PPP Bandwidth Allocation Control > Protocol (BACP)" as a Proposed > Standard. This document is the product of the Point-to-Point Protocol > Extensions Working Group. The IESG contact persons are Frank > Kastenholz and Jeffrey Burgan. When does this get an RFC #? I would have expected a "Proposed Standard" to have one. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Feb 26 18:02:01 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id SAA29557; Wed, 26 Feb 1997 18:02:01 -0500 (EST) Resent-Date: Wed, 26 Feb 1997 18:02:01 -0500 (EST) Date: Wed, 26 Feb 1997 15:00:47 -0800 Message-Id: <199702262300.PAA22459@gump.eng.ascend.com> From: Karl Fox To: "Eric L. Michelsen" Cc: ietf-ppp@MERIT.EDU Subject: Re: Protocol Action: The PPP Bandwidth Allocation Protocol (BAP) In-Reply-To: <2.2.32.19970226000152.002fb428@coppermountain.com> References: <2.2.32.19970226000152.002fb428@coppermountain.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"l9uq83.0.CD7.j2C5p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2752 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Eric L. Michelsen writes: > At 06:08 PM 2/25/97 -0500, The IESG wrote: > > > > The IESG has approved the Internet-Draft "The PPP Bandwidth > > Allocation Protocol (BAP) The PPP Bandwidth Allocation Control > > Protocol (BACP)" as a Proposed > > Standard. This document is the product of the Point-to-Point Protocol > > Extensions Working Group. The IESG contact persons are Frank > > Kastenholz and Jeffrey Burgan. > > When does this get an RFC #? I would have expected a "Proposed Standard" to > have one. When the RFC Editors get to it. They have had a pretty long backlog for the last several months, and BACP just now entered the queue. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 27 09:49:42 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id JAA10615; Thu, 27 Feb 1997 09:49:42 -0500 (EST) Resent-Date: Thu, 27 Feb 1997 09:49:42 -0500 (EST) Date: Thu, 27 Feb 1997 06:48:53 -0800 Message-Id: <199702271448.GAA24447@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Subject: DESE plaintext padding Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"RlN3c3.0.Vb2.HxP5p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2753 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Well, we still don't have consensus on how to pad plaintext in DESE. The numbers were still almost exactly evenly divided between a fixed SDP and an ESP-DES-style of padding. We will now entertain more arguments for the benefits of the various systems, hoping that one will emerge as the choice of the group. Please don't hold back; make your opinions known. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 27 11:38:15 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id LAA12697; Thu, 27 Feb 1997 11:38:15 -0500 (EST) Resent-Date: Thu, 27 Feb 1997 11:38:15 -0500 (EST) Message-Id: <97Feb27.113835est.11649@elgreco.rnd.border.com> To: Karl Fox cc: ietf-ppp@MERIT.EDU Subject: Re: DESE plaintext padding References: <199702271448.GAA24447@gump.eng.ascend.com> In-reply-to: Your message of "Thu, 27 Feb 1997 09:48:53 -0500". <199702271448.GAA24447@gump.eng.ascend.com> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 813 2054 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Thu, 27 Feb 1997 11:37:51 -0500 Sender: chk@border.com Resent-Message-ID: <"DA_V-3.0.163.lXR5p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2754 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In message <199702271448.GAA24447@gump.eng.ascend.com>, Karl Fox writes: > > Please don't hold back; make your opinions known. SDP creates "known plaintext" values in the last block of the packet. This makes some people nervous, even though all cryptographic transforms are supposed to be resistant to known plaintext. ESP-DES style padding allows random bytes. However, it also allows the sender to be lazy, and place arbitrary data in the padding section of the packet. Some people worry that this would allow poor implementations to leak secret data (suck as keys) accidentally when transmitting padded packets. [ Both of these arguments appeared when discussing the topic of padding in the IPsec working group. ] In short, there's no clear technical advantage of one over the other. Since many implementations already implement SDP, it's probably slightly easier to use it. But really; just pick one and be done with it. -- Harald Koch - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 27 17:35:05 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id RAA19897; Thu, 27 Feb 1997 17:35:05 -0500 (EST) Resent-Date: Thu, 27 Feb 1997 17:35:05 -0500 (EST) Date: Thu, 27 Feb 97 17:32:47 EST From: "Whelan, Bill" Message-Id: <9701278570.AA857093519@netx.nei.com> To: ietf-ppp@MERIT.EDU Subject: Re: DESE plaintext padding Resent-Message-ID: <"wyDeC1.0.as4.BmW5p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2755 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Could someone describe exactly what is meant by "ESP-DES-style" of padding? I can guess, but I'd rather know exactly. I assume "Payload Type" disappears? My main goal was to eliminate any need to negotiate SDP separately from ECP. I think that has been accomplished with either of the two alternatives. What remains are two options which are IMHO very similar. I'd prefer we make a decision rather than let this debate linger much longer. I've got a quarter I can flip. Who wants to call it. Bill Whelan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Feb 27 20:31:02 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id UAA22632; Thu, 27 Feb 1997 20:31:02 -0500 (EST) Resent-Date: Thu, 27 Feb 1997 20:31:02 -0500 (EST) Message-Id: <2.2.32.19970228013139.00304bfc@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Feb 1997 17:31:39 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: Re: DESE plaintext padding Resent-Message-ID: <"yeDvg.0.JX5.GLZ5p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2756 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 11:37 AM 2/27/97 -0500, C. Harald Koch wrote: >SDP creates "known plaintext" values in the last block of the packet. This >makes some people nervous, even though all cryptographic transforms are >supposed to be resistant to known plaintext. I should correct a statement I made on this list a few weeks ago. It is true that any cryptographic system which can be broken *easily* by knowing a plaintext-cyphertext pair is essentially worthless. However, it is clearly easi*er* to break any cryptographic system given a plaintext-cyphertext pair, than to break it without such a pair. So there is *some* legitimacy for nervousness about SDP before encryption. But I would think that anyone truly serious about encryption would use something other than DES, anyway, given the relative weakness of DES. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 28 03:50:45 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id DAA26487; Fri, 28 Feb 1997 03:50:45 -0500 (EST) Resent-Date: Fri, 28 Feb 1997 03:50:45 -0500 (EST) From: balasr To: "'ppp'" Subject: Test Date: Fri, 28 Feb 97 14:06:00 PST Message-Id: <331756D0@msgate.future.futsoft.com> Encoding: 1 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"HZ1ov2.0.YT6.Lnf5p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2757 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Feb 28 15:13:04 1997 Received: (from slist@localhost) by merit.edu (8.8.5/merit-2.0) id PAA06653; Fri, 28 Feb 1997 15:13:04 -0500 (EST) Resent-Date: Fri, 28 Feb 1997 15:13:04 -0500 (EST) Message-Id: <199702282008.PAA19737@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: ietf-ppp@MERIT.EDU X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Sender: John Bray Subject: BACP/BAP implementations? Date: Fri, 28 Feb 1997 15:11:20 -0500 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"_SF_B2.0.Nd1.Bmp5p"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2758 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Does anyone have a BACP/BAP server implementation using the new=20 protocol ID's (c02b/c02d) available for testing? Thanks. _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 E-mail: bray@ftp.com - - - - - - - - - - - - - - - - -