Received: from cnri by ietf.org id aa18878; 2 Jun 97 20:51 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa14821; 2 Jun 97 20:51 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id UAA28393; Mon, 2 Jun 1997 20:23:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 2 Jun 1997 20:19:55 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id UAA28354 for ietf-ppp-outgoing; Mon, 2 Jun 1997 20:19:55 -0400 (EDT) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by merit.edu (8.8.5/8.8.5) with ESMTP id UAA28350 for ; Mon, 2 Jun 1997 20:19:49 -0400 (EDT) Received: from awfulhak.demon.co.uk (localhost [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id BAA14329; Tue, 3 Jun 1997 01:09:46 +0100 (BST) Message-Id: <199706030009.BAA14329@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: ietf-ppp@merit.edu cc: J Wunsch , Brian Somers Subject: rfc1661, state transition to Closing after RTR Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Jun 1997 01:09:45 +0100 From: Brian Somers Sender: owner-ietf-ppp@merit.edu Hi. I'm a little confused about the rationale behind the transition from "Opened" to "Stopping" after a RTR. The rfc says that a STA should be done (resulting in the sender of the TR exiting) on receipt of the RTR, and that: (extract from rfc1661, 3.7) The receiver of a Terminate-Request SHOULD wait for the peer to disconnect, and MUST NOT disconnect until at least one Restart time has passed after sending a Terminate-Ack. PPP SHOULD proceed to the Link Dead phase. Wouldn't it be wiser that we do the STA and proceed directly to the "Stopped" state ? Can someone say what the rationale behind the 3 second "pause" is ? Thanks. -- Brian , Don't _EVER_ lose your sense of humour....   Received: from cnri by ietf.org id aa10434; 3 Jun 97 12:05 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa08174; 3 Jun 97 12:05 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA09004; Tue, 3 Jun 1997 11:42:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 3 Jun 1997 11:36:43 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA08874 for ietf-ppp-outgoing; Tue, 3 Jun 1997 11:36:42 -0400 (EDT) Received: from ni1.ni.net (ni1.ni.net [192.215.247.1]) by merit.edu (8.8.5/8.8.5) with ESMTP id LAA08870 for ; Tue, 3 Jun 1997 11:36:35 -0400 (EDT) From: mikep@alr.com Received: from bastion.alr.com (bastion.alr.com [199.107.15.5]) by ni1.ni.net (8.8.5/8.8.5) with SMTP id IAA18574 for ; Tue, 3 Jun 1997 08:36:27 -0700 (PDT) Received: from ccmail.alr.com by bastion.alr.com id aa29131; 3 Jun 97 8:26 PDT Received: from ccMail by ccmail.alr.com (ccMail Link to SMTP R6.00.02) id AA865352031; Tue, 03 Jun 97 08:33:53 -0800 Message-Id: <9706038653.AA865352031@ccmail.alr.com> X-Mailer: ccMail Link to SMTP R6.00.02 Date: Tue, 03 Jun 97 08:34:06 -0800 MMDF-Warning: Parse error in original version of preceding line at bastion.alr.com To: ietf-ppp@merit.edu MMDF-Warning: Parse error in original version of preceding line at bastion.alr.com Subject: IPXCP Routing Protocol Config Option MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu RFC 1552, Section 3.4, Paragraph 2 states: "By default, Novell's combination of Routing Information Protocol (RIP) and Server Advertising Protocol (SAP) is expected." Does this mean that it is unnecessary to negotiate an IPX Routing Protocol option via IPXCP if RIP/SAP (value=2) is all that would be indicated ? I am interfacing to at least one vendor that CONFIGURE ACKs my IPX Routing Protocol = 2 CONFIGURE REQUESTs, but will only generate CONFIGURE REQUESTs without the IPX Routing Protocol option indicated at all in response to my CONFIGURE NAKs with IPX Routing Protocol = 2. ??? Mike P. mikep@alr.com   Received: from cnri by ietf.org id aa24844; 4 Jun 97 22:27 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa15423; 4 Jun 97 22:27 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id WAA07726; Wed, 4 Jun 1997 22:01:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 4 Jun 1997 21:58:02 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA07599 for ietf-ppp-outgoing; Wed, 4 Jun 1997 21:58:01 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-07.dialip.mich.net [141.211.7.175]) by merit.edu (8.8.5/8.8.5) with SMTP id VAA07583 for ; Wed, 4 Jun 1997 21:57:52 -0400 (EDT) Date: Thu, 5 Jun 97 01:39:29 GMT From: William Allen Simpson Message-ID: <6001.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: rfc1661, state transition to Closing after RTR Sender: owner-ietf-ppp@merit.edu > From: Brian Somers > I'm a little confused about the rationale behind the > transition from "Opened" to "Stopping" after a RTR. >... > Wouldn't it be wiser that we do the STA and proceed directly > to the "Stopped" state ? Can someone say what the rationale > behind the 3 second "pause" is ? > How do you know the reason that the STR was sent by the peer? How do you know that the peer intends to drop the hardware link after it receives the STA? How do you expect the peer to receive the STA if you drop the hardware link in the middle of the packet transmission? Maybe this is a NCP, not LCP? Look at what happens in that Stopping state after the 3 second pause at TO-: "tlf/3". Just follow the state machine. That's what "wiser" folks do.... It's already been debugged by dozens of folks. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2   Received: from cnri by ietf.org id aa25096; 4 Jun 97 22:34 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa15489; 4 Jun 97 22:34 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id WAA07730; Wed, 4 Jun 1997 22:01:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 4 Jun 1997 21:58:00 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id VAA07592 for ietf-ppp-outgoing; Wed, 4 Jun 1997 21:58:00 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm012-07.dialip.mich.net [141.211.7.175]) by merit.edu (8.8.5/8.8.5) with SMTP id VAA07581 for ; Wed, 4 Jun 1997 21:57:45 -0400 (EDT) Date: Thu, 5 Jun 97 01:32:16 GMT From: William Allen Simpson Message-ID: <6000.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: IPXCP Routing Protocol Config Option Sender: owner-ietf-ppp@merit.edu > From: mikep@alr.com > RFC 1552, Section 3.4, Paragraph 2 states: > > "By default, Novell's combination of Routing Information Protocol > (RIP) and Server Advertising Protocol (SAP) is expected." > > Does this mean that it is unnecessary to negotiate an IPX Routing > Protocol option via IPXCP if RIP/SAP (value=2) is all that would be > indicated ? > Yes. > I am interfacing to at least one vendor that CONFIGURE ACKs my IPX > Routing Protocol = 2 CONFIGURE REQUESTs, but will only generate > CONFIGURE REQUESTs without the IPX Routing Protocol option indicated > at all in response to my CONFIGURE NAKs with IPX Routing Protocol = 2. > I don't understand. They are sending what, that prompts your Nak? It is never necessary to Nak with the default.... although not illegal. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2   Received: from cnri by ietf.org id aa08514; 5 Jun 97 12:06 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa08581; 5 Jun 97 12:06 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA16915; Thu, 5 Jun 1997 11:48:25 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 5 Jun 1997 11:44:08 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA16802 for ietf-ppp-outgoing; Thu, 5 Jun 1997 11:44:07 -0400 (EDT) Received: from coppermountain.com (cmcnt.coppermountain.com [206.71.190.2]) by merit.edu (8.8.5/8.8.5) with SMTP id LAA16798 for ; Thu, 5 Jun 1997 11:44:02 -0400 (EDT) Received: by coppermountain.com from localhost (router,SLMAILNT V2.2); Thu, 05 Jun 1997 08:44:47 Pacific Daylight Time Received: by coppermountain.com from eric (206.71.190.13::mail daemon; unverified,SLMAILNT V2.2); Thu, 05 Jun 1997 08:44:47 Pacific Daylight Time Message-Id: <2.2.32.19970605154442.002e43f0@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, 05 Jun 1997 08:44:42 -0700 To: William Allen Simpson , ietf-ppp@merit.edu From: "Eric L. Michelsen" Subject: Re: rfc1661, state transition to Closing after RTR Sender: owner-ietf-ppp@merit.edu At 01:39 AM 6/5/97 GMT, William Allen Simpson wrote: ... >Just follow the state machine. That's what "wiser" folks do.... It's >already been debugged by dozens of folks. On the other hand, during the MP discussion on this list, many people found that it's wiser to modify the state machine slightly, by continuing to accept packets after a Terminate-Request is sent, but before the Terminate-Ack. -- Eric L. Michelsen, Copper Mountain Networks, Inc.   Received: from cnri by ietf.org id aa14050; 5 Jun 97 18:01 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa13392; 5 Jun 97 18:01 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA25954; Thu, 5 Jun 1997 17:49:42 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 5 Jun 1997 17:47:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA25910 for ietf-ppp-outgoing; Thu, 5 Jun 1997 17:47:30 -0400 (EDT) Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by merit.edu (8.8.5/8.8.5) with SMTP id RAA25906 for ; Thu, 5 Jun 1997 17:47:26 -0400 (EDT) From: lanzo@raleigh.ibm.com Received: from rtpmail01.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA25944; Thu, 5 Jun 1997 17:47:17 -0400 Received: from anomaly.raleigh.ibm.com (anomaly.raleigh.ibm.com [9.37.177.111]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA24788 for ; Thu, 5 Jun 1997 17:47:22 -0400 Received: by anomaly.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24240; Thu, 5 Jun 1997 17:47:20 -0400 Message-Id: <9706052147.AA24240@anomaly.raleigh.ibm.com> Subject: NBF frames allowed to exceed MRU ? To: ietf-ppp@merit.edu Date: Thu, 5 Jun 1997 17:47:18 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu I have a question about one item in RFC 2097 (NBFCP), which seems seriously wrong to me. The RFC has this comment in section 2.2: "If IEEE-MAC-Address-Required boolean configuration option is negotiated, all NBF datagrams MUST be sent with the specified 12 octet IEEE MAC address header. Since negotiation of this option occurs after the LCP phase, NBF packets MAY exceed the negotiated PPP MRU size. A PPP implementation which negotiates this option MUST allow reception of PPP NBF packets 12 octets larger than the negotiated MRU size. Is this kosher? To me, this seems to be a total violation of the framing mechanism defined by RFC 1661 et al, and instead this should read something more akin to: NBF packets must not exceed the negotiated PPP MRU size. Bridged MAC addresses are part of the Information field, and must be accounted for as part of the MRU space. Therefore, to bridge frames on a PPP link, the negotiated MRU must be large enough to accommodate the bridged packet along with the bridging header (MAC address, as negotiated by the control protocol). Is "redefining" the MRU in this way (or equivalently, declaring part of the PPP bridged packet payload to be part of the PPP frame header) in this way considered an acceptable practice, or is this an error in the RFC? Mark Lanzo lanzo@raleigh.ibm.com   Received: from cnri by ietf.org id aa15832; 5 Jun 97 20:19 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa15023; 5 Jun 97 20:19 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id UAA27761; Thu, 5 Jun 1997 20:00:22 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 5 Jun 1997 19:58:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id TAA27736 for ietf-ppp-outgoing; Thu, 5 Jun 1997 19:58:42 -0400 (EDT) Received: from linux.klos.com (klos@klos.com [192.80.49.1]) by merit.edu (8.8.5/8.8.5) with SMTP id TAA27732 for ; Thu, 5 Jun 1997 19:58:34 -0400 (EDT) Received: (from klos@localhost) by linux.klos.com (8.6.12/8.6.9) id TAA18711; Thu, 5 Jun 1997 19:58:02 -0400 Date: Thu, 5 Jun 1997 19:58:02 -0400 From: Patrick Klos Message-Id: <199706052358.TAA18711@linux.klos.com> To: ietf-ppp@merit.edu, lanzo@raleigh.ibm.com Subject: Re: NBF frames allowed to exceed MRU ? Sender: owner-ietf-ppp@merit.edu >I have a question about one item in RFC 2097 (NBFCP), which seems >seriously wrong to me. The RFC has this comment in section 2.2: > > "If IEEE-MAC-Address-Required boolean configuration option is > negotiated, all NBF datagrams MUST be sent with the specified 12 > octet IEEE MAC address header. Since negotiation of this option > occurs after the LCP phase, NBF packets MAY exceed the negotiated PPP > MRU size. A PPP implementation which negotiates this option MUST > allow reception of PPP NBF packets 12 octets larger than the > negotiated MRU size. > >Is this kosher? Yes... and No. >To me, this seems to be a total violation of the >framing mechanism defined by RFC 1661 et al, and instead this >should read something more akin to: > > NBF packets must not exceed the negotiated PPP MRU size. > Bridged MAC addresses are part of the Information field, > and must be accounted for as part of the MRU space. > Therefore, to bridge frames on a PPP link, the negotiated > MRU must be large enough to accommodate the bridged packet > along with the bridging header (MAC address, as negotiated > by the control protocol). Maybe so, but it's a bit late in the game to try to change the spec. >Is "redefining" the MRU in this way (or equivalently, declaring >part of the PPP bridged packet payload to be part of the PPP frame >header) in this way considered an acceptable practice, or is this an >error in the RFC? Well, it's NOT an error in the RFC. It's one of those deviations that has been tolerated because (if I recall properly) Microsoft was pushing it and already had a significant number of products that already did things that way. It's a bad thing, but who is going to tell Microsoft to fix their implementation? Basically, if you're going to implement NBFCP, you need to hack your PPP (LCP) implementation to handle packets some size larger than the negotiated MRU. ============================================================================ 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/ ============================================================================   Received: from cnri by ietf.org id aa06899; 6 Jun 97 10:23 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa06356; 6 Jun 97 10:23 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA06724; Fri, 6 Jun 1997 09:53:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 6 Jun 1997 09:50:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA06616 for ietf-ppp-outgoing; Fri, 6 Jun 1997 09:50:19 -0400 (EDT) Received: from hobbit.gandalf.ca (hobbit.gandalf.ca [134.22.80.1]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA06610 for ; Fri, 6 Jun 1997 09:50:14 -0400 (EDT) Received: from cheeko.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA15944; Fri, 6 Jun 97 09:50:11 EDT From: Chris Sullivan Message-Id: <9706061350.AA15944@hobbit.gandalf.ca> Subject: Re: NBF frames allowed to exceed MRU ? To: IETF PPP Date: Fri, 6 Jun 1997 09:50:12 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu >>I have a question about one item in RFC 2097 (NBFCP), which seems >>seriously wrong to me. The RFC has this comment in section 2.2: >> >> "If IEEE-MAC-Address-Required boolean configuration option is >> negotiated, all NBF datagrams MUST be sent with the specified 12 >> octet IEEE MAC address header. Since negotiation of this option >> occurs after the LCP phase, NBF packets MAY exceed the negotiated PPP >> MRU size. A PPP implementation which negotiates this option MUST >> allow reception of PPP NBF packets 12 octets larger than the >> negotiated MRU size. >> >>Is this kosher? > >Yes... and No. > >>To me, this seems to be a total violation of the >>framing mechanism defined by RFC 1661 et al, and instead this >>should read something more akin to: >> >> NBF packets must not exceed the negotiated PPP MRU size. >> Bridged MAC addresses are part of the Information field, >> and must be accounted for as part of the MRU space. >> Therefore, to bridge frames on a PPP link, the negotiated >> MRU must be large enough to accommodate the bridged packet >> along with the bridging header (MAC address, as negotiated >> by the control protocol). > >Maybe so, but it's a bit late in the game to try to change the spec. > >>Is "redefining" the MRU in this way (or equivalently, declaring >>part of the PPP bridged packet payload to be part of the PPP frame >>header) in this way considered an acceptable practice, or is this an >>error in the RFC? > >Well, it's NOT an error in the RFC. It's one of those deviations that >has been tolerated because (if I recall properly) Microsoft was pushing >it and already had a significant number of products that already did >things that way. It's a bad thing, but who is going to tell Microsoft >to fix their implementation? > >Basically, if you're going to implement NBFCP, you need to hack your >PPP (LCP) implementation to handle packets some size larger than the >negotiated MRU. This sounds an awful lot like the problem with bridging over PPP that we had. We were announcing an MRU which was too small for the largest bridged ethernet packet. You could easily get into this boat by not announcing your MRU at all, since the default (1500) is too small for the largest bridged ethernet packet. Anyway we were negotiating multilink with the peer. So even on a single link, the packets which were too large for our announced MRU *could* have been fragmented by the peer, at that boundary. But alas, the peer, I guess perfectly legally, was silently dropping these packets, because it *knew* we could not receive packets that big. Took us a long time even to find out that what was happening, let alone why. I think a good rule of thumb is, if you *know* you are going to be bridging, or doing NBFCP, or at least attempting to, announce an MRU big enough to handle the largest packet you might get. That way you don't risk the peer silently dropping packets larger than that. If you really can't handle packets that big, what are you doing bridging, anyway? Anyway if you do this you will never be obliged to receive a packet bigger than your MRU. If there *are* packets bigger than a peer's announced MRU, and you are multilinking, a polite thing to do it to fragment them, so as not to blow the peer's rx buffer. Of course they must not exceed the peer's MRRU, so the same rule of thumb applies to the MRRU. If you are compressing *and* multilinking, announce at least an MRRU, or both MRU and MRRU, big enougn to handle the largest packet the peer's compressor might produce (sometimes uncompressible packets, like precompressed images, actually grow when they are put through a compression engine). -- Chris Sullivan Gandalf Data Limited sullivan@gandalf.ca does not necessarily share my opinions, including this one   Received: from cnri by ietf.org id aa07941; 6 Jun 97 11:14 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa07028; 6 Jun 97 11:14 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA08065; Fri, 6 Jun 1997 10:48:52 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 6 Jun 1997 10:48:46 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA08051 for ietf-ppp-outgoing; Fri, 6 Jun 1997 10:48:46 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id KAA08047 for ; Fri, 6 Jun 1997 10:48:38 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id HAA27539 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Fri, 6 Jun 1997 07:48:36 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id IAA08594 for ietf-ppp@merit.edu; Fri, 6 Jun 1997 08:48:29 -0600 Date: Fri, 6 Jun 1997 08:48:29 -0600 From: Vernon Schryver Message-Id: <199706061448.IAA08594@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: NBF frames allowed to exceed MRU ? Sender: owner-ietf-ppp@merit.edu > From: sullivan@gandalf.ca (Chris Sullivan) > ... > I think a good rule of thumb is, if you *know* you are going to be bridging, > or doing NBFCP, or at least attempting to, announce an MRU big enough to > handle the largest packet you might get. That way you don't risk the peer > silently dropping packets larger than that. If you really can't handle > packets that big, what are you doing bridging, anyway? > ... > If you are compressing *and* multilinking, announce at least an MRRU, or both > MRU and MRRU, big enougn to handle the largest packet the peer's compressor > might produce (sometimes uncompressible packets, like precompressed images, > actually grow when they are put through a compression engine). The main rub is knowing during the LCP negotiation what you are going to negotiate later during the NCP's. It seems reasonable to know you want to bridge, but there are so many compression protocols that it is hard to know what MRU to ask. You don't want to ask for something more than 1500 needlessly, since many peers will choke and force an extra round of Conf-Nak/Conf-Request. The obvious and theoretically right alternative is to renegotiate LCP, but that runs into the problem of standard non-standard junk PC implementations. Vernon Schryver, vjs@sgi.com   Received: from cnri by ietf.org id aa03191; 9 Jun 97 6:57 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa04291; 9 Jun 97 6:57 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id GAA03438; Mon, 9 Jun 1997 06:26:22 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 9 Jun 1997 06:21:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id GAA03409 for ietf-ppp-outgoing; Mon, 9 Jun 1997 06:21:08 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id GAA03405 for ; Mon, 9 Jun 1997 06:20:36 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id LAA16906 for ; Mon, 9 Jun 1997 11:20:10 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 39bd8c60; Mon, 9 Jun 97 11:19:50 +0100 Mime-Version: 1.0 Date: Mon, 9 Jun 1997 10:23:13 +0100 Message-ID: <39bd8c60@rdl.co.uk> From: Jonathan Goodchild Subject: Re: NBF frames allowed to exceed MRU ? To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu Vernon Schryver writes:- >The main rub is knowing during the LCP negotiation what you are going >to negotiate later during the NCP's. >It seems reasonable to know you want to bridge, but there are so many >compression protocols that it is hard to know what MRU to ask. >You don't want to ask for something more than 1500 needlessly, since >many peers will choke and force an extra round of >Conf-Nak/Conf-Request. >The obvious and theoretically right alternative is to renegotiate LCP, >but that runs into the problem of standard non-standard junk PC >implementations. It seems to me that anything that chokes on MRUs larger than 1500 almost falls into the same category as junk implementations which can't renegotiate LCP. What is the point of Nak-ing the MRU to something smaller ? You don't have to send anything that big - if the peer's MRU is more than 1500 and you can't send more than 1500 octets, why not set your MTU to 1500 ? Besides, an extra round of Conf-Nak/Conf-Request doesn't take all that long, especially if you are considering renegotiating LCP once you have established that the peer supports bridging and/or a particular compression scheme. What you're doing is optimizing for interoperation with older, limited (if not actually broken) peers rather than for interoperation with more sophisticated peers. Anyway, going back to the original subject about NBF frames exceeding the MRU, this just emphasises my point from a couple of months ago about outer and inner MRUs, but I won't bore you all with that again... --- Jonathan.Goodchild@rdl.co.uk   Received: from cnri by ietf.org id aa12617; 10 Jun 97 16:46 EDT Received: from merit.edu by CNRI.Reston.VA.US id aa11485; 10 Jun 97 16:46 EDT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA05770; Tue, 10 Jun 1997 16:03:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 10 Jun 1997 15:55:48 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id PAA05665 for ietf-ppp-outgoing; Tue, 10 Jun 1997 15:55:47 -0400 (EDT) Received: from trancell.stph.net (prasan@ns.trancell.stph.net [196.12.38.36]) by merit.edu (8.8.5/8.8.5) with ESMTP id PAA05655 for ; Tue, 10 Jun 1997 15:55:14 -0400 (EDT) Received: (from prasan@localhost) by trancell.stph.net (8.7.3/8.7.3) id BAA25917 for ietf-ppp@merit.edu; Wed, 11 Jun 1997 01:38:02 +0530 (IST) From: "N.G.Prasanna Kumar" Message-Id: <199706102008.BAA25917@trancell.stph.net> Subject: L2TP query! To: ietf-ppp@merit.edu Date: Wed, 11 Jun 1997 01:38:01 +0530 (IST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi , L2Tp draft says that , This protocol may also be used to solve the "multilink hunt-group splitting" problem. Multilink PPP, often used to aggregate ISDN B channels, requires that all channels composing a multilink bundle be grouped at a single NAS. Because L2TP makes a PPP session appear at a location other than the physical point at which the session was physically received, it can be used to make all channels appear at a single NAS, allowing multilink operation even when the physical calls are spread across distinct physical NAS's I am talking from the point of view of implementation of L2TP in the client i.e our end of the router. Does this mean we would dial out two different ISP 's and achieve the PPP MLP of L2TP . Does this mean he has two different accounts ?? Is my understanding of the problem is right ?? -Thanx Prasanna   Received: from cnri by ietf.org id ab04032; 12 Jun 97 6:52 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid GAA13789 for ; Thu, 12 Jun 1997 06:52:10 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id GAA07078; Thu, 12 Jun 1997 06:16:57 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Jun 1997 06:12:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id GAA07057 for ietf-ppp-outgoing; Thu, 12 Jun 1997 06:12:31 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id GAA07053 for ; Thu, 12 Jun 1997 06:12:26 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id LAA16812; Thu, 12 Jun 1997 11:11:50 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 39fcb5b0; Thu, 12 Jun 97 11:11:39 +0100 Mime-Version: 1.0 Date: Thu, 12 Jun 1997 11:06:57 +0100 Message-ID: <39fcb5b0@rdl.co.uk> From: Jonathan Goodchild Subject: Re: fsm questions To: Chris Sullivan Cc: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu Chris Sullivan writes: > So either I must have sent him a data packet which I shouldn't before > we get to state 9, or something he doesn't support. I'm not sure > forcing another Req/Ack will accomplish anything, or even that it > won't get us into a loop, but OK. I don't think you'd end up with a loop - the peer will just send another Ack to your Request, as it is waiting for an Ack to its own Request. > That makes it important to avoid doing things like sending > Identification packet types in state 7. > > I think the draft explains that the reason for making the > Identification an LCP packet type is so that it can be done as early > as possible in the Link Establishment Phase, without creating a > NAK-able option for it. It can certainly be sent in states 6 or 7, > and is supposed to result in an RXJ+ if the peer code-rejects it. Well, if you can think of a good reason to send an Identification packet in either of states 6 or 7 then maybe it is acceptable to treat the Code Reject of the Identification packet as the RXR event instead of the RXJ+ event. Either way it shouldn't upset the peer. --- Jonathan Goodchild   Received: from cnri by ietf.org id aa07586; 12 Jun 97 9:42 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA14298 for ; Thu, 12 Jun 1997 09:41:12 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA08654; Thu, 12 Jun 1997 09:14:46 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Jun 1997 09:14:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA08638 for ietf-ppp-outgoing; Thu, 12 Jun 1997 09:14:25 -0400 (EDT) Received: from mail.Germany.EU.net (mail.germany.eu.net [192.76.144.65]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA08634 for ; Thu, 12 Jun 1997 09:14:20 -0400 (EDT) Received: from materna.Materna.DE [139.2.40.1] by mail.Germany.EU.net with ESMTP (5.59+:40/2.6.2.e) id OAA07996; Thu, 12 Jun 1997 14:16:02 +0200 Message-ID: From: Thomas Nagel To: "'ietf-ppp@merit.edu'" Subject: PPP LCP Protocol-Reject packets and Protocol-Field compression Date: Thu, 12 Jun 1997 12:19:35 +0200 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Dear sirs, I'm developping (commercial) PPP drivers for several Non-Unix OS'es. Now I've come accross a point that isn't completely defined in RFC 1661: If one station has successfully negotiated the use of Protocol-Field compression it may then send any non-LCP PID with PF-Comression. Such packets could also contain a PPP Protocol-Id that the peer does not implement, thus the PID could be sent using only one byte. Should the peer then send the rejected PID as a 2-byte field in the Protocol-Reject, or should the peer stick to the format received, i.e. use only a 1-byte PID? As far as I understand there is a conflict, because the rejected data should reflect as close as possible the rejected packet, but on the other hand RFC1661 states explicitly that the rejected PID should occupy a 2-byte field. Regards, Thomas Nagel, Dr. Materna GmbH, D-44141 Dortmund, Germany   Received: from cnri by ietf.org id aa08407; 12 Jun 97 9:55 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA14439 for ; Thu, 12 Jun 1997 09:54:53 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA08839; Thu, 12 Jun 1997 09:28:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Jun 1997 09:28:45 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA08825 for ietf-ppp-outgoing; Thu, 12 Jun 1997 09:28:45 -0400 (EDT) Received: from linux.klos.com (klos@klos.com [192.80.49.1]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA08820 for ; Thu, 12 Jun 1997 09:28:39 -0400 (EDT) Received: (from klos@localhost) by linux.klos.com (8.6.12/8.6.9) id JAA27046; Thu, 12 Jun 1997 09:28:47 -0400 Date: Thu, 12 Jun 1997 09:28:47 -0400 From: Patrick Klos Message-Id: <199706121328.JAA27046@linux.klos.com> To: ietf-ppp@merit.edu, thomas.nagel@materna.de Subject: Re: PPP LCP Protocol-Reject packets and Protocol-Field compression Sender: owner-ietf-ppp@merit.edu > I'm developping (commercial) PPP drivers for several Non-Unix OS'es. > >Now I've come accross a point that isn't completely defined in RFC 1661: > >If one station has successfully negotiated the use of Protocol-Field >compression >it may then send any non-LCP PID with PF-Comression. >Such packets could also contain a PPP Protocol-Id that the peer does not >implement, >thus the PID could be sent using only one byte. > >Should the peer then send the rejected PID as a 2-byte field in the >Protocol-Reject, >or should the peer stick to the format received, i.e. use only a 1-byte >PID? > >As far as I understand there is a conflict, because the rejected data >should reflect >as close as possible the rejected packet, but on the other hand RFC1661 >states explicitly >that the rejected PID should occupy a 2-byte field. The rejected Protocol ID MUST be 2 bytes long. Negotiating Protocol Field Compression should effect the the frame's Protocol ID field only, except when encapsulating PPP packets. Even when encapsulating PPP, compressing the Protocol Field is often controlled by explicit text in the associated RFC. ============================================================================ 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/ ============================================================================   Received: from cnri by ietf.org id aa09063; 12 Jun 97 10:10 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA14547 for ; Thu, 12 Jun 1997 10:09:14 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA08944; Thu, 12 Jun 1997 09:37:23 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Jun 1997 09:37:18 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA08930 for ietf-ppp-outgoing; Thu, 12 Jun 1997 09:37:17 -0400 (EDT) Received: from hobbit.gandalf.ca (hobbit.gandalf.ca [134.22.80.1]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA08926 for ; Thu, 12 Jun 1997 09:37:13 -0400 (EDT) Received: from jester.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA01383; Thu, 12 Jun 97 09:37:12 EDT Received: by jester.gandalf.ca (SMI-8.6/SMI-SVR4) id JAA24639; Thu, 12 Jun 1997 09:36:30 -0400 From: Chris Sullivan Message-Id: <199706121336.JAA24639@jester.gandalf.ca> Subject: Re: fsm questions To: Jonathan Goodchild Date: Thu, 12 Jun 1997 09:36:30 -0400 (EDT) Cc: sullivan@hobbit.gandalf.ca, ietf-ppp@merit.edu In-Reply-To: <39fcb5b0@rdl.co.uk> from "Jonathan Goodchild" at Jun 12, 97 11:06:57 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > > So either I must have sent him a data packet which I shouldn't before > > we get to state 9, or something he doesn't support. I'm not sure > > forcing another Req/Ack will accomplish anything, or even that it > > won't get us into a loop, but OK. > > I don't think you'd end up with a loop - the peer will just send another > Ack to your Request, as it is waiting for an Ack to its own Request. > > > That makes it important to avoid doing things like sending > > Identification packet types in state 7. > > > > I think the draft explains that the reason for making the > > Identification an LCP packet type is so that it can be done as early > > as possible in the Link Establishment Phase, without creating a > > NAK-able option for it. It can certainly be sent in states 6 or 7, > > and is supposed to result in an RXJ+ if the peer code-rejects it. > > Well, if you can think of a good reason to send an Identification packet > in either of states 6 or 7 then maybe it is acceptable to treat the Code > Reject of the Identification packet as the RXR event instead of the RXJ+ > event. Either way it shouldn't upset the peer. Exactly. That 6 in state 7 should be a 7. -- Chris Sullivan Gandalf Data Limited sullivan@gandalf.ca does not necessarily share my opinions, including this one   Received: from cnri by ietf.org id aa11093; 12 Jun 97 10:27 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA14620 for ; Thu, 12 Jun 1997 10:26:27 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA09366; Thu, 12 Jun 1997 10:04:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Jun 1997 10:04:23 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA09350 for ietf-ppp-outgoing; Thu, 12 Jun 1997 10:04:23 -0400 (EDT) Received: from atlas.xylogics.com (atlas.xylogics.com [132.245.33.7]) by merit.edu (8.8.5/8.8.5) with ESMTP id KAA09346 for ; Thu, 12 Jun 1997 10:04:18 -0400 (EDT) Received: from vulcan.xylogics.com (vulcan.xylogics.com [132.245.33.8]) by atlas.xylogics.com (8.7.3/8.7.3) with SMTP id KAA06466; Thu, 12 Jun 1997 10:03:35 -0400 (EDT) Received: from localhost by vulcan.xylogics.com id AA19405 (4.1/UK-doug-951219); Thu, 12 Jun 97 10:03:35 EDT Message-Id: <19405.9706121403@vulcan.xylogics.com> To: Thomas Nagel Cc: ietf-ppp@merit.edu Subject: Re: PPP LCP Protocol-Reject packets and Protocol-Field compression In-Reply-To: Your message of "Thu, 12 Jun 1997 12:19:35 +0200." Date: Thu, 12 Jun 1997 10:03:35 -0400 From: James Carlson Sender: owner-ietf-ppp@merit.edu In message , Thomas Nagel writes: > Now I've come accross a point that isn't completely defined in RFC 1661: > > If one station has successfully negotiated the use of Protocol-Field > compression > it may then send any non-LCP PID with PF-Comression. Actually, you don't need a special test for LCP, since LCP's protocol ID number can't be compressed anyway. > Such packets could also contain a PPP Protocol-Id that the peer does not > implement, > thus the PID could be sent using only one byte. Possible, but unlikely except for data corruption. Passing protocol numbers low enough to be subject to PFC usually requires negotiation of that protocol, which always uses a non-compressible number. > Should the peer then send the rejected PID as a 2-byte field in the > Protocol-Reject, > or should the peer stick to the format received, i.e. use only a 1-byte > PID? "Be liberal in what you expect and conservative in what you send." I would send these as fixed two octet fields, and would accept either one or two octets on receive. (Vernon would accept any length, of course. ;-}) > As far as I understand there is a conflict, because the rejected data > should reflect > as close as possible the rejected packet, but on the other hand RFC1661 > states explicitly > that the rejected PID should occupy a 2-byte field. An implementation which can handle compressed protocol IDs in this field can also handle uncompressed, by definition. An implementation which cannot handle compressed IDs in this case will fail if you send this number as you received it. Therefore, I'd send it uncompressed. (Nobody cares about the performance of Protocol-Reject messages, since they don't carry user data, so saving the octet isn't useful.) --- 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 4789   Received: from cnri by ietf.org id aa05234; 12 Jun 97 22:50 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA16987 for ; Thu, 12 Jun 1997 22:49:51 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id WAA21149; Thu, 12 Jun 1997 22:30:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Jun 1997 22:30:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id WAA21131 for ietf-ppp-outgoing; Thu, 12 Jun 1997 22:30:31 -0400 (EDT) Received: from trancell.stph.net (ashok@[196.12.55.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id WAA21127 for ; Thu, 12 Jun 1997 22:30:24 -0400 (EDT) Received: (from ashok@localhost) by trancell.stph.net (8.7.3/8.7.3) id IAA07164 for ietf-ppp@MERIT.EDU; Fri, 13 Jun 1997 08:13:38 +0530 (IST) From: "R.Ashok Ramchandra" Message-Id: <199706130243.IAA07164@trancell.stph.net> Subject: IPCP Help Required To: ietf-ppp@merit.edu Date: Fri, 13 Jun 1997 08:13:37 +0530 (IST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi All, I am facing a pecuilar problem with one particular ISP while negotiating the IP address to be used for the WAN link. I have been configured for Dynamic IP address on both the sides of WAN link. When the IPCP negotiations kick off, I ACK the IP address which the ISP wants it for its own side, but the ISP is not ready to respond to my configure request with the IP address of 0.0.0.0. Instead of coming back with a IP address to be used on my side he once again comes back with a configure request with a IP address which I had ACked earlier for him. This goes on till my retries are over and then I initiate a terminate req. Can any one suggest me as to what is happening because of which the ISP is not ready to accept my ACK (ISP had asked for the addr and control field Compression in the LCP nego, so I am not sending those fields, Will these cause any problems???) Even the Protocol Field Cmpression was also nego but Control Protocol values are not supposed to be compressed right?? Why is the ISP coming back with the Conf req's again and again and responding for for my Conf REq's. I would sincerely appreciate any help on this. Thanks, R.Ashok   Received: from cnri by ietf.org id aa10398; 12 Jun 97 23:34 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA17057 for ; Thu, 12 Jun 1997 23:33:21 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id XAA21418; Thu, 12 Jun 1997 23:02:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Jun 1997 23:02:27 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id XAA21400 for ietf-ppp-outgoing; Thu, 12 Jun 1997 23:02:26 -0400 (EDT) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by merit.edu (8.8.5/8.8.5) with SMTP id XAA21396 for ; Thu, 12 Jun 1997 23:02:23 -0400 (EDT) Received: (fox@localhost) by greatdane.cisco.com (8.6.12/8.6.5) id UAA26336; Thu, 12 Jun 1997 20:00:38 -0700 From: Craig Fox Message-Id: <199706130300.UAA26336@greatdane.cisco.com> Subject: Re: IPCP Help Required To: "R.Ashok Ramchandra" Date: Thu, 12 Jun 97 20:00:37 PDT Cc: ietf-ppp@merit.edu In-Reply-To: <199706130243.IAA07164@trancell.stph.net>; from "R.Ashok Ramchandra" at Jun 13, 97 8:13 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ietf-ppp@merit.edu > > Hi All, > > I am facing a pecuilar problem with one particular ISP while > negotiating the IP address to be used for the WAN link. I have been > configured for Dynamic IP address on both the sides of WAN link. > When the IPCP negotiations kick off, I ACK the IP address which the > ISP wants it for its own side, but the ISP is not ready to respond > to my configure request with the IP address of 0.0.0.0. Instead of > coming back with a IP address to be used on my side he once again > comes back with a configure request with a IP address which I had ACked > earlier for him. > > This goes on till my retries are over and then I initiate a terminate > req. Can any one suggest me as to what is happening because of which > the ISP is not ready to accept my ACK (ISP had asked for the addr and > control field Compression in the LCP nego, so I am not sending those > fields, Will these cause any problems???) Even the Protocol Field > Cmpression was also nego but Control Protocol values are not supposed > to be compressed right?? Why is the ISP coming back with the Conf req's > again and again and responding for for my Conf REq's. > > I would sincerely appreciate any help on this. > It helps to see a trace of the actual negotiation because verbal descriptions tend to be imprecise. It sounds like your LCP messages are being ignored on the peer's end. If you do not have a way of capturing a trace on your end of the link, the ISP may have a way of doing it on its end of the link. You are correct, Address and Control Field Compression applies to IPCP packets but Protocol Field Compression does not (the IPCP protocol value, 0x8021, is not compressible). Craig > Thanks, > R.Ashok >   Received: from cnri by ietf.org id aa10633; 12 Jun 97 23:48 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid XAA17080 for ; Thu, 12 Jun 1997 23:47:21 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id XAA21595; Thu, 12 Jun 1997 23:22:18 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 12 Jun 1997 23:22:13 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id XAA21580 for ietf-ppp-outgoing; Thu, 12 Jun 1997 23:22:13 -0400 (EDT) Received: from img.outgoing.com (img.outgoing.com [209.14.30.51]) by merit.edu (8.8.5/8.8.5) with ESMTP id XAA21575 for ; Thu, 12 Jun 1997 23:22:09 -0400 (EDT) Received: (from email@localhost) by img.outgoing.com (8.8.3/8.7.3) id XAA05103 for ietf-ppp@merit.edu; Thu, 12 Jun 1997 23:23:56 -0400 (EDT) Date: Thu, 12 Jun 1997 23:23:56 -0400 (EDT) Message-Id: <199706130323.XAA05103@img.outgoing.com> From: info@did-it.com To: ietf-ppp@merit.edu Subject: Is your site listed? Sender: owner-ietf-ppp@merit.edu Hi, I just surfed in from your Yahoo listing. It's good to see that you are listed there... As a webmaster or webmarketer, you know that getting traffic from the search engines and directories is absolutely crucial to the success of your (or your client's) site. You have probably used Submit-it or another service to submit your sites. Submit-it is a really great service .... but, as you may be aware, the search engines don't always process the submissions, and they also drop many sites that used to be listed out of the directories to keep the size of their database down, so you never can be sure if you have an active listing, till now. So, we have launched a new service called did-it.com at http://www.did-it.com. The did-it.com Detective will check any URL to see if the URL is listed in the search engines and e-mail you a status report FREE OF CHARGE. If you find you're not listed, you can utilize our Did-it submission service. What is unique about this service is that it will monitor the status of your site on all the popular search engines and automatically resubmit you wherever you're not listed. Today, that's the ONLY way you can be sure you get listed and stay listed, automatically. Come take a look... http://www.did-it.com and use our detective service FREE! BTW, If you like our service you can also become a did-it.com Partner. In exchange for putting a small icon next to a link to us, you will become eligible for did-it.com Partner benefits. Check out the partner program at: http://www.did-it.com/ click on the partner icon. Thanks so much. Regards, The did-it.com team.   Received: from cnri by ietf.org id aa06808; 13 Jun 97 9:26 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid JAA17857 for ; Fri, 13 Jun 1997 09:25:31 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA25677; Fri, 13 Jun 1997 09:07:28 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Jun 1997 09:03:29 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA25632 for ietf-ppp-outgoing; Fri, 13 Jun 1997 09:03:28 -0400 (EDT) Received: from directors.rdl.co.uk (directors.rdl.co.uk [193.119.77.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id JAA25617 for ; Fri, 13 Jun 1997 09:03:05 -0400 (EDT) Received: from imaccgw.rdl.co.uk (imaccgw.rdl.co.uk [193.240.106.205]) by directors.rdl.co.uk (8.7.3/8.7.3) with SMTP id OAA02320 for ; Fri, 13 Jun 1997 14:02:26 +0100 (BST) Received: from ccMail by imaccgw.rdl.co.uk (IMA Internet Exchange 1.04b) id 3a143c40; Fri, 13 Jun 97 13:57:40 +0100 Mime-Version: 1.0 Date: Fri, 13 Jun 1997 09:20:14 +0100 Message-ID: <3a143c40@rdl.co.uk> From: Jonathan Goodchild Subject: Another FSM question To: ietf-ppp@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ppp@merit.edu From R.Ashok Ramchandra's description of his IPCP problem it would appear that his peer is not seeing his IPCP Configure-Requests at all, and is going through the loop of RCA:irc/7, TO+:scr/6, RCA:irc/7, etc. While we're on the subject of FSM questions, what terminates this loop ? It seems to go on forever unless the peer disconnects, because the retry count keeps getting reset by the irc action. I know it is very unlikely that this loop would occur in real life, except when the peer is broken (after all, if you can receive the Conf-Ack, why can't you receive the Conf-Req ?), but it seems to me that the FSM ought to protect against brokenness where possible. Any views on this ? --- Jonathan Goodchild   Received: from cnri by ietf.org id aa09698; 13 Jun 97 11:22 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA18418 for ; Fri, 13 Jun 1997 11:22:08 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA27356; Fri, 13 Jun 1997 10:43:37 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Jun 1997 10:41:59 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA27293 for ietf-ppp-outgoing; Fri, 13 Jun 1997 10:41:58 -0400 (EDT) Received: from hobbit.gandalf.ca (hobbit.gandalf.ca [134.22.80.1]) by merit.edu (8.8.5/8.8.5) with SMTP id KAA27285 for ; Fri, 13 Jun 1997 10:41:53 -0400 (EDT) Received: from jester.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA06795; Fri, 13 Jun 97 10:41:52 EDT Received: by jester.gandalf.ca (SMI-8.6/SMI-SVR4) id KAA13534; Fri, 13 Jun 1997 10:41:11 -0400 From: Chris Sullivan Message-Id: <199706131441.KAA13534@jester.gandalf.ca> Subject: Re: Another FSM question To: Jonathan Goodchild Date: Fri, 13 Jun 1997 10:41:11 -0400 (EDT) Cc: ietf-ppp@merit.edu In-Reply-To: <3a143c40@rdl.co.uk> from "Jonathan Goodchild" at Jun 13, 97 09:20:14 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > >From R.Ashok Ramchandra's description of his IPCP problem it would > appear that his peer is not seeing his IPCP Configure-Requests at all, > and is going through the loop of RCA:irc/7, TO+:scr/6, RCA:irc/7, etc. > > While we're on the subject of FSM questions, what terminates this loop ? > > It seems to go on forever unless the peer disconnects, because the retry > count keeps getting reset by the irc action. > > I know it is very unlikely that this loop would occur in real life, > except when the peer is broken (after all, if you can receive the > Conf-Ack, why can't you receive the Conf-Req ?), but it seems to me > that the FSM ought to protect against brokenness where possible. Don't think you can surmise what his peer is doing without a trace. It is likely, as Craig says, not hearing any packets at all. This is very likely to happen for a variety of reasons (like Frame Relay congestion in one direction only, or a broken wire). Eventually somebody will run out of retries. -- Chris Sullivan Gandalf Data Limited sullivan@gandalf.ca does not necessarily share my opinions, including this one   Received: from cnri by ietf.org id aa10629; 13 Jun 97 11:59 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA18644 for ; Fri, 13 Jun 1997 11:58:54 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA28084; Fri, 13 Jun 1997 11:24:21 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Jun 1997 11:22:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA28052 for ietf-ppp-outgoing; Fri, 13 Jun 1997 11:22:50 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm002-00.dialip.mich.net [141.211.7.136]) by merit.edu (8.8.5/8.8.5) with SMTP id LAA28046 for ; Fri, 13 Jun 1997 11:22:45 -0400 (EDT) Date: Fri, 13 Jun 97 14:21:03 GMT From: William Allen Simpson Message-ID: <6035.wsimpson@greendragon.com> To: ietf-ppp@merit.edu Subject: Re: fsm questions Sender: owner-ietf-ppp@merit.edu > From: sullivan@hobbit.gandalf.ca (Chris Sullivan) > > Well, if you can think of a good reason to send an Identification packet > > in either of states 6 or 7 then maybe it is acceptable to treat the Code > > Reject of the Identification packet as the RXR event instead of the RXJ+ > > event. Either way it shouldn't upset the peer. > > Exactly. That 6 in state 7 should be a 7. > No, that should be a 6, as written. Error recovery is just about the hardest part of the automaton, and everything here has been argued into the ground already. In this case, as best as I remember, one of the possible scenarios is that the Code was mangled in such a way that the FCS was still correct. That Code _could_ have been your Ack, or something equally vital. You have to start again. In any case, the FSA needs to be designed so that it operates correctly for all possible Code_Rejects, not with separate special cases for each new Code (such as Identification) that won't affect the negotiation. The negotiation was designed to be _extensible_, but the FSA is not! Almost every interoperability problem I have encountered in recent years was with some smart person who thought that they could "improve" the FSA to save a single packet here and there. Who cares about "optimizing" error recovery in special cases?!?! Please remember that some of the transitions are there to fix serious bugs in early shipped implementations of an earlier FSA, such as Cisco's. It was easier to contort the FSA in newer code. And I spent hundreds and hundreds of hours (much of it unpaid) testing against every existing implementation to make sure every transition worked without generating loops. Any new loops and problems are due to insufficient testing of new implementations, and are therefore inexcusable. Also, I have a comment on an earlier message: # From: "Eric L. Michelsen" # At 01:39 AM 6/5/97 GMT, William Allen Simpson wrote: # ... # >Just follow the state machine. That's what "wiser" folks do.... It's # >already been debugged by dozens of folks. # # On the other hand, during the MP discussion on this list, many people found # that it's wiser to modify the state machine slightly, by continuing to # accept packets after a Terminate-Request is sent, but before the Terminate-Ack. # Actually, there was rather a lot of blather in such a vein, but it was not to be taken seriously. A Terminate-Request _means_ that the layer is not accepting more packets. You cannot change the semantics of a message at will, any more than you could file a cam on your automobile engine and expect it to run. Again, it lead to severe interoperability problems, generating lots of pointless discussion. If any of the MP folks had been competent designers, they would have created a new message that meant "I'd like you to stop sending, and go down sometime in the near future". BACP comes to mind. Correct design of this facility would require a 3-way handshake, not the 2-way Terminate handshake alone. Lots of folks don't understand why there are both Up/Down and Open/Close, but educating them for free at this late date is not my problem.... WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2   Received: from cnri by ietf.org id aa11692; 13 Jun 97 12:43 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA18773 for ; Fri, 13 Jun 1997 12:42:56 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA28590; Fri, 13 Jun 1997 11:57:49 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Jun 1997 11:56:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA28550 for ietf-ppp-outgoing; Fri, 13 Jun 1997 11:56:11 -0400 (EDT) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by merit.edu (8.8.5/8.8.5) with SMTP id LAA28546 for ; Fri, 13 Jun 1997 11:56:07 -0400 (EDT) Received: (fox@localhost) by greatdane.cisco.com (8.6.12/8.6.5) id IAA29757; Fri, 13 Jun 1997 08:53:47 -0700 From: Craig Fox Message-Id: <199706131553.IAA29757@greatdane.cisco.com> Subject: Re: Another FSM question To: Chris Sullivan Date: Fri, 13 Jun 97 8:53:47 PDT Cc: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@merit.edu In-Reply-To: <199706131441.KAA13534@jester.gandalf.ca>; from "Chris Sullivan" at Jun 13, 97 10:41 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ietf-ppp@merit.edu > > > >From R.Ashok Ramchandra's description of his IPCP problem it would > > appear that his peer is not seeing his IPCP Configure-Requests at all, > > and is going through the loop of RCA:irc/7, TO+:scr/6, RCA:irc/7, etc. > > > > While we're on the subject of FSM questions, what terminates this loop ? > > > > It seems to go on forever unless the peer disconnects, because the retry > > count keeps getting reset by the irc action. > > > > I know it is very unlikely that this loop would occur in real life, > > except when the peer is broken (after all, if you can receive the > > Conf-Ack, why can't you receive the Conf-Req ?), but it seems to me > > that the FSM ought to protect against brokenness where possible. > > Don't think you can surmise what his peer is doing without a trace. It > is likely, as Craig says, not hearing any packets at all. This is very > likely to happen for a variety of reasons (like Frame Relay congestion > in one direction only, or a broken wire). Eventually somebody will run > out of retries. > Possibly, but Patrick Klos pointed out in private mail that since they got thru LCP (in order to start IPCP), that some packets had been successfully exchanged. In addition to ACFC kicking in, so does the ACCM. Now that I think about it, it is the most likely problem. The IPCP packets are not seen by the peer so it is Req Sent state, timing out and retransmitting the packets. Perhaps, Ramchandra's code is not escaping all of the characters requested since it is the peer that appears to be dropping the packet. Craig > -- > Chris Sullivan Gandalf Data Limited > sullivan@gandalf.ca does not necessarily share my opinions, > including this one >   Received: from cnri by ietf.org id aa12478; 13 Jun 97 13:12 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA18901 for ; Fri, 13 Jun 1997 13:11:34 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA29102; Fri, 13 Jun 1997 12:39:01 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Jun 1997 12:37:34 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA29077 for ietf-ppp-outgoing; Fri, 13 Jun 1997 12:37:33 -0400 (EDT) Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.8.5/8.8.5) with SMTP id MAA29073 for ; Fri, 13 Jun 1997 12:37:29 -0400 (EDT) Received: from mica.denver.sgi.com (mica.denver.sgi.com [169.238.67.6]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id JAA21928 for <@sgi.engr.sgi.com:ietf-ppp@merit.edu>; Fri, 13 Jun 1997 09:37:27 -0700 env-from (vjs@mica.denver.sgi.com) Received: (from vjs@localhost) by mica.denver.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA02833 for ietf-ppp@merit.edu; Fri, 13 Jun 1997 10:37:23 -0600 Date: Fri, 13 Jun 1997 10:37:23 -0600 From: Vernon Schryver Message-Id: <199706131637.KAA02833@mica.denver.sgi.com> To: ietf-ppp@merit.edu Subject: Re: fsm questions Sender: owner-ietf-ppp@merit.edu > From: "William Allen Simpson" > To: ietf-ppp@merit.edu > ... > # From: "Eric L. Michelsen" > # At 01:39 AM 6/5/97 GMT, William Allen Simpson wrote: > # ... > # >Just follow the state machine. That's what "wiser" folks do.... It's > # >already been debugged by dozens of folks. > # > # On the other hand, during the MP discussion on this list, many people found > # that it's wiser to modify the state machine slightly, by continuing to > # accept packets after a Terminate-Request is sent, but before the Terminate-Ack. > # > Actually, there was rather a lot of blather in such a vein, but it was > not to be taken seriously. > > A Terminate-Request _means_ that the layer is not accepting more > packets. You cannot change the semantics of a message at will, any more > than you could file a cam on your automobile engine and expect it to run. > Again, it lead to severe interoperability problems, generating lots of > pointless discussion. > > If any of the MP folks had been competent designers, they would have > created a new message that meant "I'd like you to stop sending, and go > down sometime in the near future". BACP comes to mind. Correct design > of this facility would require a 3-way handshake, not the 2-way > Terminate handshake alone. > > Lots of folks don't understand why there are both Up/Down and > Open/Close, but educating them for free at this late date is not my > problem.... That is a load of self-serving, self-promoting nonsense that sounds like sour-grapes from Mr. Simpson's failed attempt to hijack the MP RFC. (Newcomers should check the mailing list archives to see that incredible saga in Mr. Simpson's own words.) It does absolutely no harm to continue to accept data packets after sending a Terminate-Request. It is easy to prove formally that there are and can be no interoperability problems, severe or otherwise in being generous and accepting data packets that the peer has sent before receiving your Terminate-Request. It is also easy to observe pragmatically that the many implemenations that do that do not suffer any interoperablity problems as a consequence. The distinctions between Up/Down and Open/Close are an old fault in PPP. Such a notion is a more or less good idea, but it has never been well defined in the standards. Continuing to accept packets after sending a Terminate-Request is a separate issue, both from that distinction and from MP. It is true that the undesirable consequences of not continuing to accept data from the peer after sending your Terminate-Request are most evident with MP, but they occur elsewhere. A three-way shut-down handshake using explicit would be generally undesirable. Why wait another half RTT? In fact, we already effectively have a three-way shut down handshake. Dropping the phone line is the Ack for the Terminate-Ack. Vernon Schryver, vjs@sgi.com   Received: from cnri by ietf.org id aa12499; 13 Jun 97 13:12 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA18913 for ; Fri, 13 Jun 1997 13:12:02 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA29173; Fri, 13 Jun 1997 12:41:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Jun 1997 12:41:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA29156 for ietf-ppp-outgoing; Fri, 13 Jun 1997 12:41:19 -0400 (EDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by merit.edu (8.8.5/8.8.5) with ESMTP id MAA29149 for ; Fri, 13 Jun 1997 12:41:14 -0400 (EDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id JAA00956; Fri, 13 Jun 1997 09:40:43 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma000954; Fri Jun 13 09:40:28 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id JAA27641; Fri, 13 Jun 1997 09:40:28 -0700 (PDT) From: Archie Cobbs Message-Id: <199706131640.JAA27641@bubba.whistle.com> Subject: Re: Another FSM question In-Reply-To: <199706131553.IAA29757@greatdane.cisco.com> from Craig Fox at "Jun 13, 97 08:53:47 am" To: Craig Fox Date: Fri, 13 Jun 1997 09:40:28 -0700 (PDT) Cc: sullivan@hobbit.gandalf.ca, Jonathan.Goodchild@rdl.co.uk, ietf-ppp@merit.edu X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > Possibly, but Patrick Klos pointed out in private mail that since they got > thru LCP (in order to start IPCP), that some packets had been successfully > exchanged. In addition to ACFC kicking in, so does the ACCM. Now that > I think about it, it is the most likely problem. The IPCP packets are not > seen by the peer so it is Req Sent state, timing out and retransmitting the > packets. Perhaps, Ramchandra's code is not escaping all of the characters > requested since it is the peer that appears to be dropping the packet. I've seen a situation where LCP negotiated successfully but IPCP didn't, because the requested IP address contained a 17 in it (the ASCII value for CTRL-Q) and the server was getting IPCP frames with a missing byte, and thus dropping them. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com   Received: from cnri by ietf.org id aa12902; 13 Jun 97 13:25 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA18954 for ; Fri, 13 Jun 1997 13:24:18 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id NAA29709; Fri, 13 Jun 1997 13:00:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Jun 1997 12:59:23 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA29655 for ietf-ppp-outgoing; Fri, 13 Jun 1997 12:59:22 -0400 (EDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by merit.edu (8.8.5/8.8.5) with ESMTP id MAA29645 for ; Fri, 13 Jun 1997 12:59:15 -0400 (EDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id JAA01041; Fri, 13 Jun 1997 09:58:44 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma001037; Fri Jun 13 09:58:21 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id JAA27765; Fri, 13 Jun 1997 09:58:21 -0700 (PDT) From: Archie Cobbs Message-Id: <199706131658.JAA27765@bubba.whistle.com> Subject: Re: Another FSM question In-Reply-To: <199706131654.JAA02703@greatdane.cisco.com> from Craig Fox at "Jun 13, 97 09:54:13 am" To: Craig Fox Date: Fri, 13 Jun 1997 09:58:21 -0700 (PDT) Cc: archie@whistle.com, fox@cisco.com, sullivan@hobbit.gandalf.ca, Jonathan.Goodchild@rdl.co.uk, ietf-ppp@merit.edu X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > > I've seen a situation where LCP negotiated successfully but IPCP > > didn't, because the requested IP address contained a 17 in it (the > > ASCII value for CTRL-Q) and the server was getting IPCP frames with > > a missing byte, and thus dropping them. > > > Interesting. Some implementations always negotiate an ACCM of 0x000A0000 > to protect from unknown components in the path that might do this. Seems > like it might be considered a BCP. That's exactly what we ended up doing. It was easier than convincing the ISP running the server that they had misconfigured it... -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com   Received: from cnri by ietf.org id aa13084; 13 Jun 97 13:30 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA19007 for ; Fri, 13 Jun 1997 13:30:01 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA29610; Fri, 13 Jun 1997 12:57:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Jun 1997 12:57:30 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA29596 for ietf-ppp-outgoing; Fri, 13 Jun 1997 12:57:29 -0400 (EDT) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by merit.edu (8.8.5/8.8.5) with SMTP id MAA29592 for ; Fri, 13 Jun 1997 12:57:24 -0400 (EDT) Received: (fox@localhost) by greatdane.cisco.com (8.6.12/8.6.5) id JAA02703; Fri, 13 Jun 1997 09:54:13 -0700 From: Craig Fox Message-Id: <199706131654.JAA02703@greatdane.cisco.com> Subject: Re: Another FSM question To: Archie Cobbs Date: Fri, 13 Jun 97 9:54:13 PDT Cc: fox@cisco.com, sullivan@hobbit.gandalf.ca, Jonathan.Goodchild@rdl.co.uk, ietf-ppp@merit.edu In-Reply-To: <199706131640.JAA27641@bubba.whistle.com>; from "Archie Cobbs" at Jun 13, 97 9:40 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ietf-ppp@merit.edu > > > > Possibly, but Patrick Klos pointed out in private mail that since they got > > thru LCP (in order to start IPCP), that some packets had been successfully > > exchanged. In addition to ACFC kicking in, so does the ACCM. Now that > > I think about it, it is the most likely problem. The IPCP packets are not > > seen by the peer so it is Req Sent state, timing out and retransmitting the > > packets. Perhaps, Ramchandra's code is not escaping all of the characters > > requested since it is the peer that appears to be dropping the packet. > > I've seen a situation where LCP negotiated successfully but IPCP > didn't, because the requested IP address contained a 17 in it (the > ASCII value for CTRL-Q) and the server was getting IPCP frames with > a missing byte, and thus dropping them. > Interesting. Some implementations always negotiate an ACCM of 0x000A0000 to protect from unknown components in the path that might do this. Seems like it might be considered a BCP. Craig > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com >   Received: from cnri by ietf.org id aa14996; 13 Jun 97 14:59 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA19279 for ; Fri, 13 Jun 1997 14:58:24 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA00814; Fri, 13 Jun 1997 14:00:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 13 Jun 1997 13:59:56 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id NAA00793 for ietf-ppp-outgoing; Fri, 13 Jun 1997 13:59:55 -0400 (EDT) Received: from hobbit.gandalf.ca (hobbit.gandalf.ca [134.22.80.1]) by merit.edu (8.8.5/8.8.5) with SMTP id NAA00786 for ; Fri, 13 Jun 1997 13:59:50 -0400 (EDT) Received: from jester.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA14382; Fri, 13 Jun 97 13:59:42 EDT Received: by jester.gandalf.ca (SMI-8.6/SMI-SVR4) id NAA17656; Fri, 13 Jun 1997 13:59:02 -0400 From: Chris Sullivan Message-Id: <199706131759.NAA17656@jester.gandalf.ca> Subject: Re: IPCP Help Required To: IETF PPP Date: Fri, 13 Jun 1997 13:59:01 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu I have been unable to help via private email, so I am throwing this out to the list. Seems either there is an (invisible?) ACCM problem as has been discussed, or the peer is lying about being able to decompress ACFC. I enclose my annotated version of the trace, then the whole enchilada: There does seem to be a 17h in the IP address. REM is the ISP (remote), and WR is the local box. REM ff03 c021 01 010018 010405dc 020600000000 050655d809e6 0702 0802 WR ff03 c021 01 01000e 010405dc 020600000000 REM ff03 c021 02 01000e 010405dc 020600000000 WR ff03 c021 01 02000e 010405dc 020600000000 WR ff03 c021 01 03000e 010405dc 020600000000 REM ff03 c021 01 030018 010405dc 020600000000 050655d809e6 0702 0802 WR ff03 c021 03 030008 010405f4 Here he NAK'ed his peer's MRU upwards. Unlikely to succeed. May cause interoperability problems (failure to converge). REM ff03 c021 02 03000e 010405dc 020600000000 REM ff03 c021 01 040018 010405dc 020600000000 050655d809e6 0702 0802 See? It won't change. Good thing local box will live with that. WR ff03 c021 02 040018 010405dc 020600000000 050655d809e6 0702 0802 WR ff03 c021 01 04000e 010405dc 020600000000 REM ff03 c021 01 050018 010405dc 020600000000 050655d809e6 0702 0802 WR ff03 c021 02 050018 010405dc 020600000000 050655d809e6 0702 0802 REM ff03 c021 02 04000e 010405dc 020600000000 OK, now LCP is open, the ISP has announced MRU of 05DC, ACCM of 0, magic, ACFC (he can uncompress it) and PFC (he can uncompress it). The local box has announced MRU of 05DC, ACCM of 0. WR 8021 01 01000a 030600000000 REM ff03 8021 01 21000a 0306ccb38817 WR 8021 02 21000a 0306ccb38817 WR 8021 01 02000a 030600000000 REM ff03 8021 01 22000a 0306ccb38817 WR 8021 02 22000a 0306ccb38817 WR 8021 01 03000a 030600000000 repeats... WR ff03 c021 05 050004 term req REM ff03 8021 05 2b0004 REM ff03 c021 06 050004 OK, now the whole trace: The packets which are labelled "WR" at the start of line are sent out of my router and the packets which are labelled in as REM are the one which are coming from the remote end i.e ISP. Don't worry about the second and third columns. Then is your trace. Hope that helps. Thanks, R.Ashok > >WR :M2: 2 41540000 >REM:M2: 5 41544f4b 04000000 > >REM:M2: 31 ff03c021 01010018 010405dc 02060000 > 00000506 55d809e6 07020802 c5b97e00 > >WR :M2: 22 7eff03c0 21010100 0e010405 dc020600 > 0000004f 357e0000 >REM:M2: 22 7eff03c0 21020100 0e010405 dc020600 > 00000071 b67e0000 >WR :M2: 22 7eff03c0 21010200 0e010405 dc020600 > 000000b8 3b7e0000 >WR :M2: 22 7eff03c0 21010300 0e010405 dc020600 > 00000015 3e7e0000 >REM:M2: 32 7eff03c0 21010300 18010405 dc020600 > 00000005 0655d809 e6070208 0246a27e > >WR :M2: 16 7eff03c0 21030300 08010405 f4cf507e > >REM:M2: 22 ffff03c0 21020300 0e010405 dc020600 > 0000002b bd7e0000 >REM:M2: 32 7eff03c0 21010400 18010405 dc020600 > 00000005 0655d809 e6070208 020a077e > >WR :M2: 32 7eff03c0 21020400 18010405 dc020600 > 00000005 0655d809 e6070208 02c6ea7e > >REM:M2: 10 7eff8021 ccb388ab e37e0000 >WR :M2: 22 7eff03c0 21010400 0e010405 dc020600 > 00000056 267e0000 >REM:M2: 7 7eff8021 209c7e00 >REM:M2: 32 7eff03c0 21010500 18010405 dc020600 > 00000005 0655d809 e6070208 02c38e7e > >WR :M2: 32 7eff03c0 21020500 18010405 dc020600 > 00000005 0655d809 e6070208 020f637e > >REM:M2: 22 7eff03c0 21020400 0e010405 dc020600 > 00000068 a57e0000 >WR :M2: 16 7e802101 01000a03 06000000 006dc67e > >REM:M2: 18 7eff0380 21012100 0a0306cc b38817d3 > 307e0000 >WR :M2: 16 7e802102 21000a03 06ccb388 17c4aa7e > >WR :M2: 16 7e802101 02000a03 06000000 006a107e > >REM:M2: 18 7eff0380 21012200 0a0306cc b38817d4 > e67e0000 >WR :M2: 16 7e802102 22000a03 06ccb388 17c37c7e > >WR :M2: 16 7e802101 03000a03 06000000 00975d7e > >REM:M2: 18 7eff0380 21012300 0a0306cc b3881729 > ab7e0000 >WR :M2: 16 7e802102 23000a03 06ccb388 173e317e > >WR :M2: 16 7e802101 04000a03 06000000 0075b47e > >REM:M2: 18 7eff0380 21012400 0a0306cc b38817cb > 427e0000 >WR :M2: 16 7e802102 24000a03 06ccb388 17dcd87e > >WR :M2: 16 7e802101 05000a03 06000000 0088f97e > >REM:M2: 18 7eff0380 21012500 0a0306cc b3881736 > 0f7e0000 >WR :M2: 16 7e802102 25000a03 06ccb388 1721957e > >WR :M2: 16 7e802101 06000a03 06000000 008f2f7e > >REM:M2: 18 7eff0380 21012600 0a0306cc b3881731 > d97e0000 >WR :M2: 16 7e802102 26000a03 06ccb388 1726437e > >WR :M2: 16 7e802101 07000a03 06000000 0072627e > >REM:M2: 18 7eff0380 21012700 0a0306cc b38817cc > 947e0000 >WR :M2: 16 7e802102 27000a03 06ccb388 17db0e7e > >WR :M2: 16 7e802101 08000a03 06000000 005af47e > >REM:M2: 18 7eff0380 21012800 0a0306cc b38817e4 > 027e0000 >WR :M2: 16 7e802102 28000a03 06ccb388 17f3987e > >WR :M2: 16 7e802101 09000a03 06000000 00a7b97e > >REM:M2: 18 7eff0380 21012900 0a0306cc b3881719 > 4f7e0000 >WR :M2: 16 7e802102 29000a03 06ccb388 170ed57e > >WR :M2: 16 7e802101 0a000a03 06000000 00a06f7e > >REM:M2: 18 7eff0380 21012a00 0a0306cc b388171e > 997e0000 >WR :M2: 16 7e802102 2a000a03 06ccb388 1709037e > >WR :M2: 12 7eff03c0 21050500 045ca47e >REM:M2: 12 7eff0380 21052b00 04adb57e >REM:M2: 12 7eff03c0 21060500 0491817e >WR :M2: 2 41540000 >REM:M2: 11 ff03c021 05080004 235b7e00 >REM:M2: 11 ff03c021 05090004 ff017e00 >WR :M2: 2 41540000 >REM:M2: 5 41544f4b 50000000 >WR :M2: 4 41542646 >REM:M2: 7 41542646 4f4b2000 >WR :M2: 3 61747a00 >REM:M2: 4 61747a21 >REM:M2: 3 4f4b2500 >WR :M2: 7 41544454 37373700 >REM:M2: 7 41544454 37373700 >REM:M2: 14 434f4e4e 45435420 35373630 307e0000 > >WR :M2: 22 7eff03c0 21010100 0e010405 dc020600 > 0000004f 357e0000 >REM:M2: 31 ff03c021 01010018 010405dc 02060000 > 00000506 d3db1afb 07020802 01417e00 > >WR :M2: 16 7eff03c0 21030100 08010405 f474677e > >REM:M2: 22 7eff03c0 21020100 0e010405 dc020600 > 00000071 b67e0000 >REM:M2: 32 7eff03c0 21010200 18010405 dc020600 > 00000005 06d3db1a fb070208 024bd37e > >WR :M2: 32 7eff03c0 21020200 18010405 dc020600 > 00000005 06d3db1a fb070208 02873e7e > >WR :M2: 16 7e802101 01000a03 06000000 006dc67e > >REM:M2: 18 7eff0380 21011f00 0a0306cc b3881e6a > 7e7e0000 >WR :M2: 16 7e802102 1f000a03 06ccb388 1e7de47e > >WR :M2: 16 7e802101 02000a03 06000000 006a107e > >REM:M2: 18 7eff0380 21012000 0a0306cc b3881eef > e07e0000 >WR :M2: 16 7e802102 20000a03 06ccb388 1ef87a7e > >WR :M2: 16 7e802101 03000a03 06000000 00975d7e > >REM:M2: 18 7eff0380 21012100 0a0306cc b3881e12 > ad7e0000 >WR :M2: 16 7e802102 21000a03 06ccb388 1e05377e > >WR :M2: 16 7e802101 04000a03 06000000 0075b47e > >REM:M2: 18 7eff0380 21012200 0a0306cc b3881e15 > 7b7e0000 >WR :M2: 16 7e802102 22000a03 06ccb388 1e02e17e > >WR :M2: 16 7e802101 05000a03 06000000 0088f97e > >REM:M2: 18 7eff0380 21012300 0a0306cc b3881ee8 > 367e0000 >WR :M2: 16 7e802102 23000a03 06ccb388 1effac7e > >WR :M2: 16 7e802101 06000a03 06000000 008f2f7e > >REM:M2: 18 7eff0380 21012400 0a0306cc b3881e0a > df7e0000 >WR :M2: 16 7e802102 24000a03 06ccb388 1e1d457e > >WR :M2: 16 7e802101 07000a03 06000000 0072627e > > >TOTAL OF 99 RECORDS >value = 21 = 0x15   Received: from cnri by ietf.org id aa25657; 13 Jun 97 22:47 EDT Received: from hosaka (hosaka.SmallWorks.COM [192.207.126.1]) by cnri.reston.va.us (8.8.5/8.7.3) with SMTPid WAA20297 for ; Fri, 13 Jun 1997 22:47:01 -0400 (EDT) Received: by hosaka (SMI-8.6/SMI-SVR4) id QAA04456; Fri, 13 Jun 1997 16:51:59 -0500 Received: from motgate.mot.com by hosaka (SMI-8.6/SMI-SVR4) id QAA04433; Fri, 13 Jun 1997 16:51:23 -0500 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.7.6/8.6.10/MOT-3.8) with ESMTP id QAA09761; Fri, 13 Jun 1997 16:49:14 -0500 (CDT) Received: from il02dns1.comm.mot.com (il02dns1.comm.mot.com [145.1.3.2]) by pobox.mot.com (8.7.6/8.6.10/MOT-3.8) with ESMTP id QAA12307; Fri, 13 Jun 1997 16:48:46 -0500 (CDT) Received: from ssd.comm.mot.com ([145.1.92.11]) by il02dns1.comm.mot.com (8.7.5/8.7.3) with SMTP id QAA18521; Fri, 13 Jun 1997 16:48:47 -0500 (CDT) Received: from ssdultra24.ssd by ssd.comm.mot.com (4.1/SMI-4.1) id AA22040; Fri, 13 Jun 97 16:48:36 CDT Origin: ssd Received: by ssdultra24.ssd (SMI-8.6/SMI-SVR4) id QAA17980; Fri, 13 Jun 1997 16:48:33 -0500 Date: Fri, 13 Jun 1997 16:48:33 -0500 From: Chris Stanaway Message-Id: <9706131648.ZM17978@comm.mot.com> In-Reply-To: Jim Solomon "Re: I-D ACTION:draft-ietf-pppext-ipcp-mip-01.txt" (May 30, 1:36pm) References: <9705301844.AA07466@becks.comm.mot.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: ietf-ppp@merit.edu Subject: (mobile-ip) Re: I-D ACTION:draft-ietf-pppext-ipcp-mip-01.txt Cc: mobile-ip@hosaka.smallworks.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@hosaka.smallworks.com Precedence: bulk Reply-To: Chris Stanaway I've a question on how this would work with co-located COA's. How would a new co-located COA be assigned to a MN once IPCP has completed? For the non-MIP folks, the question is essentially "Once a PPP peer (i.e. a dial-up server) has dynamically assigned an IP address how can that peer dynamically assign a different IP address to a node?" Chris On Fri, May 30, at 1:36pm, Jim Solomon wrote: Subject: Re: I-D ACTION:draft-ietf-pppext-ipcp-mip-01.txt > > > In message <9705270942.aa01739@ietf.org>, > Internet-Drafts@ietf.org writes: > > > Title : Mobile IPv4 Configuration Option for PPP IPCP > > Author(s) : J. Solomon, S. Glass > > Filename : draft-ietf-pppext-ipcp-mip-01.txt > > Pages : 18 > > Date : 05/23/1997 > > As directed at the Memphis IETF, Steve and I have produced a new draft > of the Mobile-IPv4 Configuration Option which works in conjunction > with the IP-Address option (as opposed to subsuming its "dynamic > address assignment" capability). We would appreciate comments, > particularly on our attempt at clarifying the use of the IP-Address > option in section 2.5 (items 5-7), as well as any other comments you > might have. > > Regards, > Jim S. > > P.S. Folks on the mobile-ip mailing list who wish to comment should > send such comments to . > >-- End of excerpt from Jim Solomon ----------------------------------------------------------------------------- IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com Unsubscribe: unsubscribe mobile-ip (as message body, not subject) Direct all administrative requests to majordomo@smallworks.com   Received: from cnri by ietf.org id aa23967; 15 Jun 97 2:11 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid CAA21441 for ; Sun, 15 Jun 1997 02:10:53 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id BAA16610; Sun, 15 Jun 1997 01:38:22 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 15 Jun 1997 01:34:56 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id BAA16594 for ietf-ppp-outgoing; Sun, 15 Jun 1997 01:34:55 -0400 (EDT) Received: from rnd-gate.rad.co.il (rnd-gate.rad.co.il [207.232.32.14]) by merit.edu (8.8.5/8.8.5) with ESMTP id BAA16590 for ; Sun, 15 Jun 1997 01:34:49 -0400 (EDT) Received: from smtp-gateway.rad.co.il ([176.189.111.1]) by rnd-gate.rad.co.il (8.7.3/8.7.3) with SMTP id IAA26429 for ; Sun, 15 Jun 1997 08:23:44 +0300 (IDT) Received: by smtp-gateway.rad.co.il with Microsoft Mail id <33A38E82@smtp-gateway.rad.co.il>; Sun, 15 Jun 97 08:41:06 EST From: Michael Liwerant To: "'ietf-ppp@merit.edu'" Subject: FW: new subscriber + question Date: Sun, 15 Jun 97 08:34:00 EST Message-ID: <33A38E82@smtp-gateway.rad.co.il> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu Dear Sir My name is Michael Liwerant, I am a senior software engineer who joined RND company recently. I am in charge of all PPP issues in the RND's MRT software package. We are checking the possibility to implement the Stac LZS compression protocol over our PPP link and I will appreciate your help providing the following information: Regarding the LZS protocol packet Check field - Which is most popular mode used for implementation of the packet data integrity check ? is LCB mostly used, or CRC or the protocol uses its Extended Mode ? Thank you for responding - Michael Liwerant.   Received: from cnri by ietf.org id aa08269; 15 Jun 97 14:43 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA21937 for ; Sun, 15 Jun 1997 14:42:35 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA19668; Sun, 15 Jun 1997 14:28:22 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 15 Jun 1997 14:25:14 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA19648 for ietf-ppp-outgoing; Sun, 15 Jun 1997 14:25:13 -0400 (EDT) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA19644 for ; Sun, 15 Jun 1997 14:25:10 -0400 (EDT) Received: from jrmhtp.endicott.ibm.com (slip129-37-221-140.ny.us.ibm.net [129.37.221.140]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id SAA78518 for ; Sun, 15 Jun 1997 18:25:08 GMT Message-Id: <3.0.1.32.19970615134159.007b0dc0@pop01.ny.us.ibm.net> X-Sender: jrmartz@pop01.ny.us.ibm.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 15 Jun 1997 13:41:59 -0400 To: ietf-ppp@merit.edu From: "John R. Martz" Subject: authentication by multiple methods: Why NOT?? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu I apologize if I'm raising a subject that was already covered in previous notes. But I'm STILL confused by the following statement from the last paragraph of page 10 of RFC 1994. ... "It is not anticipated that a particular named user would be authenticated by multiple methods. This would make the user vulnerable to attacks which negotiate the least secure method from among a set (such as PAP rather than CHAP). If the same secret was used, PAP would reveal the secret to be used later with CHAP". What I do not understand is how allowing authentication by either CHAP or PAP is a greater security risk for the secret for a particular user name than authentication by PAP alone? If authentication is allowed by PAP and the secret for a user is compromised, then the secret is compromised, correct? Whether PAP or CHAP is later used to gain access using the compromised user name seems of little consequence to me. Certainly if the intent is always authenticate with CHAP, then authentication must never be allowed to be negotiated down to PAP. But if PAP is allowed, what is the harm in first requesting CHAP and then negotiating it down to PAP? Or, from the other direction, accepting CHAP authentication if requested when you would have allowed PAP? Why would either case pose a greater risk than using only PAP? Can someone tell me what I'm not seeing here? Thanks, -john martz   Received: from cnri by ietf.org id aa09489; 15 Jun 97 16:39 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA22015 for ; Sun, 15 Jun 1997 16:38:50 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA20713; Sun, 15 Jun 1997 16:24:54 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 15 Jun 1997 16:23:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA20686 for ietf-ppp-outgoing; Sun, 15 Jun 1997 16:23:28 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id QAA20682 for ; Sun, 15 Jun 1997 16:23:24 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id NAA19197 for ; Sun, 15 Jun 1997 13:23:23 -0700 Received: from ascend.com by ascend.com with ESMTP id NAA15225 for ; Sun, 15 Jun 1997 13:23:22 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id NAA16457; Sun, 15 Jun 1997 13:23:20 -0700 Date: Sun, 15 Jun 1997 13:23:20 -0700 Message-Id: <199706152023.NAA16457@gump.eng.ascend.com> From: Karl Fox To: Michael Liwerant Cc: "'ietf-ppp@merit.edu'" Subject: FW: new subscriber + question In-Reply-To: <33A38E82@smtp-gateway.rad.co.il> References: <33A38E82@smtp-gateway.rad.co.il> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Michael Liwerant writes: > Regarding the LZS protocol packet Check field - Which is most popular > mode used for implementation of the packet data integrity check ? is LCB > mostly used, or CRC or the protocol uses its Extended Mode ? Support for sequence numbers (check mode 3) is required for all conforming implementations. I don't know what the next most popular mode is. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041   Received: from cnri by ietf.org id aa09542; 15 Jun 97 16:43 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid QAA22024 for ; Sun, 15 Jun 1997 16:42:41 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA20668; Sun, 15 Jun 1997 16:21:49 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 15 Jun 1997 16:20:12 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA20646 for ietf-ppp-outgoing; Sun, 15 Jun 1997 16:20:11 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id QAA20642 for ; Sun, 15 Jun 1997 16:20:07 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id NAA19136 for ; Sun, 15 Jun 1997 13:20:06 -0700 Received: from ascend.com by ascend.com with ESMTP id NAA15148 for ; Sun, 15 Jun 1997 13:20:05 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id NAA16453; Sun, 15 Jun 1997 13:20:03 -0700 Date: Sun, 15 Jun 1997 13:20:03 -0700 Message-Id: <199706152020.NAA16453@gump.eng.ascend.com> From: Karl Fox To: "John R. Martz" Cc: ietf-ppp@merit.edu Subject: authentication by multiple methods: Why NOT?? In-Reply-To: <3.0.1.32.19970615134159.007b0dc0@pop01.ny.us.ibm.net> References: <3.0.1.32.19970615134159.007b0dc0@pop01.ny.us.ibm.net> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu John R. Martz writes: > I apologize if I'm raising a subject that was already covered in previous > notes. But I'm STILL confused by the following statement from the last > paragraph of page 10 of RFC 1994. > > ... "It is not anticipated that a particular named user would be > authenticated by multiple methods. This would make the user vulnerable to > attacks which negotiate the least secure method from among a set (such as > PAP rather than CHAP). If the same secret was used, PAP would reveal the > secret to be used later with CHAP". > > What I do not understand is how allowing authentication by either CHAP or > PAP is a greater security risk for the secret for a particular user name > than authentication by PAP alone? It's not. However, if you have a NAS (Network Access Server) serving several users, some of which use PAP (perhaps because their dialing systems don't support anything better) and some of which use CHAP, the CHAP users shouldn't be able to get in using PAP. The PAP users *always* are vulnerable to anyone who can see their packets, but there's no reason to bring the CHAP users down to the same level. > If authentication is allowed by PAP and the secret for a user is > compromised, then the secret is compromised, correct? Whether PAP or > CHAP is later used to gain access using the compromised user name > seems of little consequence to me. Correct, but if CHAP is the *only* system allowed for a particular user, his dial-in account is safe from eavesdroppers. > Certainly if the intent is always authenticate with CHAP, then > authentication must never be allowed to be negotiated down to PAP. That's the real point of the RFC 1994 sentence. > But if PAP is allowed, what is the harm in first requesting CHAP and > then negotiating it down to PAP? Or, from the other direction, > accepting CHAP authentication if requested when you would have > allowed PAP? Why would either case pose a greater risk than using > only PAP? That's not what 1994 says--it's not talking about first requesting CHAP and then negotiating down to PAP, it's talking about which protocol will be allowed to be used for a particular named user. > Can someone tell me what I'm not seeing here? > > Thanks, -john martz -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041   Received: from cnri by ietf.org id aa15139; 15 Jun 97 22:36 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid WAA22282 for ; Sun, 15 Jun 1997 22:35:26 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id WAA23095; Sun, 15 Jun 1997 22:13:34 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 15 Jun 1997 22:11:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id WAA23076 for ietf-ppp-outgoing; Sun, 15 Jun 1997 22:11:56 -0400 (EDT) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by merit.edu (8.8.5/8.8.5) with SMTP id WAA23071 for ; Sun, 15 Jun 1997 22:11:52 -0400 (EDT) Received: (fox@localhost) by greatdane.cisco.com (8.6.12/8.6.5) id TAA05370; Sun, 15 Jun 1997 19:11:18 -0700 From: Craig Fox Message-Id: <199706160211.TAA05370@greatdane.cisco.com> Subject: Re: IPCP Help Required To: Chris Sullivan Date: Sun, 15 Jun 97 19:11:18 PDT Cc: ietf-ppp@merit.edu In-Reply-To: <199706131759.NAA17656@jester.gandalf.ca>; from "Chris Sullivan" at Jun 13, 97 1:59 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ietf-ppp@merit.edu > > I have been unable to help via private email, so I am throwing this > out to the list. Seems either there is an (invisible?) ACCM problem > as has been discussed, or the peer is lying about being able to > decompress ACFC. > > I enclose my annotated version of the trace, then the whole enchilada: > > There does seem to be a 17h in the IP address. Yeah, but that is not a CTRL-S or CTRL-Q. Those values are 0x13 and 0x11 respectively. I believe that comment about 17 was referring to a decimal 17, ie 0x11, which would be the CTRL-Q. The problem with this trace is that it does not show the ACCM escaping. The packets are being traced above that layer in WR's code. So nothing is known. I would suggest tracing the line from the middle with something like Klos Technologies SerialView or any other packet sniffer. Craig > > REM is the ISP (remote), and WR is the local box. > > REM ff03 c021 01 010018 010405dc 020600000000 050655d809e6 0702 0802 > WR ff03 c021 01 01000e 010405dc 020600000000 > REM ff03 c021 02 01000e 010405dc 020600000000 > WR ff03 c021 01 02000e 010405dc 020600000000 > WR ff03 c021 01 03000e 010405dc 020600000000 > REM ff03 c021 01 030018 010405dc 020600000000 050655d809e6 0702 0802 > WR ff03 c021 03 030008 010405f4 > Here he NAK'ed his peer's MRU upwards. Unlikely to succeed. May cause > interoperability problems (failure to converge). > > REM ff03 c021 02 03000e 010405dc 020600000000 > REM ff03 c021 01 040018 010405dc 020600000000 050655d809e6 0702 0802 > See? It won't change. Good thing local box will live with that. > > WR ff03 c021 02 040018 010405dc 020600000000 050655d809e6 0702 0802 > WR ff03 c021 01 04000e 010405dc 020600000000 > REM ff03 c021 01 050018 010405dc 020600000000 050655d809e6 0702 0802 > WR ff03 c021 02 050018 010405dc 020600000000 050655d809e6 0702 0802 > REM ff03 c021 02 04000e 010405dc 020600000000 > > OK, now LCP is open, the ISP has announced MRU of 05DC, ACCM of 0, magic, ACFC > (he can uncompress it) and PFC (he can uncompress it). > > The local box has announced MRU of 05DC, ACCM of 0. > > WR 8021 01 01000a 030600000000 > REM ff03 8021 01 21000a 0306ccb38817 > WR 8021 02 21000a 0306ccb38817 > WR 8021 01 02000a 030600000000 > REM ff03 8021 01 22000a 0306ccb38817 > WR 8021 02 22000a 0306ccb38817 > WR 8021 01 03000a 030600000000 > > repeats... > > WR ff03 c021 05 050004 term req > REM ff03 8021 05 2b0004 > REM ff03 c021 06 050004 > > > > OK, now the whole trace: > > > The packets which are labelled > "WR" at the start of line are sent out of my router and the packets > which are labelled in as REM are the one which are coming from the remote end i.e ISP. > Don't worry about the second and third columns. Then is your trace. > Hope that helps. > > Thanks, > R.Ashok > > > > >WR :M2: 2 41540000 > >REM:M2: 5 41544f4b 04000000 > > > >REM:M2: 31 ff03c021 01010018 010405dc 02060000 > > 00000506 55d809e6 07020802 c5b97e00 > > > >WR :M2: 22 7eff03c0 21010100 0e010405 dc020600 > > 0000004f 357e0000 > >REM:M2: 22 7eff03c0 21020100 0e010405 dc020600 > > 00000071 b67e0000 > >WR :M2: 22 7eff03c0 21010200 0e010405 dc020600 > > 000000b8 3b7e0000 > >WR :M2: 22 7eff03c0 21010300 0e010405 dc020600 > > 00000015 3e7e0000 > >REM:M2: 32 7eff03c0 21010300 18010405 dc020600 > > 00000005 0655d809 e6070208 0246a27e > > > >WR :M2: 16 7eff03c0 21030300 08010405 f4cf507e > > > >REM:M2: 22 ffff03c0 21020300 0e010405 dc020600 > > 0000002b bd7e0000 > >REM:M2: 32 7eff03c0 21010400 18010405 dc020600 > > 00000005 0655d809 e6070208 020a077e > > > >WR :M2: 32 7eff03c0 21020400 18010405 dc020600 > > 00000005 0655d809 e6070208 02c6ea7e > > > >REM:M2: 10 7eff8021 ccb388ab e37e0000 > >WR :M2: 22 7eff03c0 21010400 0e010405 dc020600 > > 00000056 267e0000 > >REM:M2: 7 7eff8021 209c7e00 > >REM:M2: 32 7eff03c0 21010500 18010405 dc020600 > > 00000005 0655d809 e6070208 02c38e7e > > > >WR :M2: 32 7eff03c0 21020500 18010405 dc020600 > > 00000005 0655d809 e6070208 020f637e > > > >REM:M2: 22 7eff03c0 21020400 0e010405 dc020600 > > 00000068 a57e0000 > >WR :M2: 16 7e802101 01000a03 06000000 006dc67e > > > >REM:M2: 18 7eff0380 21012100 0a0306cc b38817d3 > > 307e0000 > >WR :M2: 16 7e802102 21000a03 06ccb388 17c4aa7e > > > >WR :M2: 16 7e802101 02000a03 06000000 006a107e > > > >REM:M2: 18 7eff0380 21012200 0a0306cc b38817d4 > > e67e0000 > >WR :M2: 16 7e802102 22000a03 06ccb388 17c37c7e > > > >WR :M2: 16 7e802101 03000a03 06000000 00975d7e > > > >REM:M2: 18 7eff0380 21012300 0a0306cc b3881729 > > ab7e0000 > >WR :M2: 16 7e802102 23000a03 06ccb388 173e317e > > > >WR :M2: 16 7e802101 04000a03 06000000 0075b47e > > > >REM:M2: 18 7eff0380 21012400 0a0306cc b38817cb > > 427e0000 > >WR :M2: 16 7e802102 24000a03 06ccb388 17dcd87e > > > >WR :M2: 16 7e802101 05000a03 06000000 0088f97e > > > >REM:M2: 18 7eff0380 21012500 0a0306cc b3881736 > > 0f7e0000 > >WR :M2: 16 7e802102 25000a03 06ccb388 1721957e > > > >WR :M2: 16 7e802101 06000a03 06000000 008f2f7e > > > >REM:M2: 18 7eff0380 21012600 0a0306cc b3881731 > > d97e0000 > >WR :M2: 16 7e802102 26000a03 06ccb388 1726437e > > > >WR :M2: 16 7e802101 07000a03 06000000 0072627e > > > >REM:M2: 18 7eff0380 21012700 0a0306cc b38817cc > > 947e0000 > >WR :M2: 16 7e802102 27000a03 06ccb388 17db0e7e > > > >WR :M2: 16 7e802101 08000a03 06000000 005af47e > > > >REM:M2: 18 7eff0380 21012800 0a0306cc b38817e4 > > 027e0000 > >WR :M2: 16 7e802102 28000a03 06ccb388 17f3987e > > > >WR :M2: 16 7e802101 09000a03 06000000 00a7b97e > > > >REM:M2: 18 7eff0380 21012900 0a0306cc b3881719 > > 4f7e0000 > >WR :M2: 16 7e802102 29000a03 06ccb388 170ed57e > > > >WR :M2: 16 7e802101 0a000a03 06000000 00a06f7e > > > >REM:M2: 18 7eff0380 21012a00 0a0306cc b388171e > > 997e0000 > >WR :M2: 16 7e802102 2a000a03 06ccb388 1709037e > > > >WR :M2: 12 7eff03c0 21050500 045ca47e > >REM:M2: 12 7eff0380 21052b00 04adb57e > >REM:M2: 12 7eff03c0 21060500 0491817e > >WR :M2: 2 41540000 > >REM:M2: 11 ff03c021 05080004 235b7e00 > >REM:M2: 11 ff03c021 05090004 ff017e00 > >WR :M2: 2 41540000 > >REM:M2: 5 41544f4b 50000000 > >WR :M2: 4 41542646 > >REM:M2: 7 41542646 4f4b2000 > >WR :M2: 3 61747a00 > >REM:M2: 4 61747a21 > >REM:M2: 3 4f4b2500 > >WR :M2: 7 41544454 37373700 > >REM:M2: 7 41544454 37373700 > >REM:M2: 14 434f4e4e 45435420 35373630 307e0000 > > > >WR :M2: 22 7eff03c0 21010100 0e010405 dc020600 > > 0000004f 357e0000 > >REM:M2: 31 ff03c021 01010018 010405dc 02060000 > > 00000506 d3db1afb 07020802 01417e00 > > > >WR :M2: 16 7eff03c0 21030100 08010405 f474677e > > > >REM:M2: 22 7eff03c0 21020100 0e010405 dc020600 > > 00000071 b67e0000 > >REM:M2: 32 7eff03c0 21010200 18010405 dc020600 > > 00000005 06d3db1a fb070208 024bd37e > > > >WR :M2: 32 7eff03c0 21020200 18010405 dc020600 > > 00000005 06d3db1a fb070208 02873e7e > > > >WR :M2: 16 7e802101 01000a03 06000000 006dc67e > > > >REM:M2: 18 7eff0380 21011f00 0a0306cc b3881e6a > > 7e7e0000 > >WR :M2: 16 7e802102 1f000a03 06ccb388 1e7de47e > > > >WR :M2: 16 7e802101 02000a03 06000000 006a107e > > > >REM:M2: 18 7eff0380 21012000 0a0306cc b3881eef > > e07e0000 > >WR :M2: 16 7e802102 20000a03 06ccb388 1ef87a7e > > > >WR :M2: 16 7e802101 03000a03 06000000 00975d7e > > > >REM:M2: 18 7eff0380 21012100 0a0306cc b3881e12 > > ad7e0000 > >WR :M2: 16 7e802102 21000a03 06ccb388 1e05377e > > > >WR :M2: 16 7e802101 04000a03 06000000 0075b47e > > > >REM:M2: 18 7eff0380 21012200 0a0306cc b3881e15 > > 7b7e0000 > >WR :M2: 16 7e802102 22000a03 06ccb388 1e02e17e > > > >WR :M2: 16 7e802101 05000a03 06000000 0088f97e > > > >REM:M2: 18 7eff0380 21012300 0a0306cc b3881ee8 > > 367e0000 > >WR :M2: 16 7e802102 23000a03 06ccb388 1effac7e > > > >WR :M2: 16 7e802101 06000a03 06000000 008f2f7e > > > >REM:M2: 18 7eff0380 21012400 0a0306cc b3881e0a > > df7e0000 > >WR :M2: 16 7e802102 24000a03 06ccb388 1e1d457e > > > >WR :M2: 16 7e802101 07000a03 06000000 0072627e > > > > > >TOTAL OF 99 RECORDS > >value = 21 = 0x15 >   Received: from cnri by ietf.org id aa10160; 16 Jun 97 12:08 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid MAA23777 for ; Mon, 16 Jun 1997 12:07:27 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA01536; Mon, 16 Jun 1997 11:37:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 16 Jun 1997 11:29:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA01362 for ietf-ppp-outgoing; Mon, 16 Jun 1997 11:29:08 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id LAA01358 for ; Mon, 16 Jun 1997 11:28:57 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id IAA08246 for ; Mon, 16 Jun 1997 08:28:55 -0700 Received: from ascend.com by ascend.com with ESMTP id IAA17100 for ; Mon, 16 Jun 1997 08:28:50 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id IAA17846; Mon, 16 Jun 1997 08:28:38 -0700 Date: Mon, 16 Jun 1997 08:28:38 -0700 Message-Id: <199706161528.IAA17846@gump.eng.ascend.com> From: Karl Fox To: Karl Fox Cc: Michael Liwerant , "'ietf-ppp@merit.edu'" Subject: FW: new subscriber + question In-Reply-To: <199706152023.NAA16457@gump.eng.ascend.com> References: <33A38E82@smtp-gateway.rad.co.il> <199706152023.NAA16457@gump.eng.ascend.com> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu Karl Fox writes: > Michael Liwerant writes: > > Regarding the LZS protocol packet Check field - Which is most popular > > mode used for implementation of the packet data integrity check ? is LCB > > mostly used, or CRC or the protocol uses its Extended Mode ? > > Support for sequence numbers (check mode 3) is required for all > conforming implementations. I don't know what the next most popular > mode is. Correction--support for sequence numbers is required for all implementations which implement compression histories. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041   Received: from cnri by ietf.org id aa11710; 16 Jun 97 13:47 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA24084 for ; Mon, 16 Jun 1997 13:46:22 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id MAA02848; Mon, 16 Jun 1997 12:27:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 16 Jun 1997 12:27:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id MAA02831 for ietf-ppp-outgoing; Mon, 16 Jun 1997 12:27:26 -0400 (EDT) Received: from mailman.hifn.com (mailman.hifn.com [206.19.120.66]) by merit.edu (8.8.5/8.8.5) with SMTP id MAA02827 for ; Mon, 16 Jun 1997 12:27:21 -0400 (EDT) Received: by mailman.hifn.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC7A38.11B875F0@mailman.hifn.com>; Mon, 16 Jun 1997 09:31:29 -0700 Message-ID: From: Robert Friend To: 'Michael Liwerant' Cc: "'ietf-ppp@merit.edu'" Subject: RE: new subscriber + question Date: Mon, 16 Jun 1997 09:31:22 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Hi Michael, As Karl Fox stated, mode 3 (sequence numbers) is required if you want to maintain history between packets on the link. This statistically provides a higher compression ratio for PPP transmissions. Extended mode is utilized by Windows 95 in their Remote Access Services (RAS - for example, Dial-up Networking client). MS also supports Option 18 (MPPC algorithm) in RAS. NT3.5x and beyond only supports Option 18 (MPPC algorithm) in RAS. Also, since Option 17 requires some kind of reliable transport mode below (again to maintain history between packets on the link), CRC or LCB MAY provide another layer of error detection; however, they will not detect missing or out of order packets. Someone please correct me if I'm wrong, but my experience tells me that most people implement Sequence numbers, and Extended mode for MS support. Also, I heard that MS was planning on implementing sequence numbers in their RAS, but I have not yet heard if that version is available. Michael, I hope this helps. Regards, _____________________________________________________________ Robert C. Friend Hi/fn Applications Engineering 5973 Avenida Encinas, Suite 110 voice: (760) 827-4542 Carlsbad, CA 92008 FAX: (760) 827-4577 email: rfriend@hifn.com >-----Original Message----- >From: Michael Liwerant [SMTP:MichaelL@RND.RNDMAIL.rad.co.il] >Sent: Sunday, June 15, 1997 6:34 AM >To: 'ietf-ppp@merit.edu' >Subject: FW: new subscriber + question > > > > >Dear Sir > >My name is Michael Liwerant, I am a senior software engineer who joined >RND company recently. I am in charge of all PPP issues in the RND's MRT >software package. >We are checking the possibility to implement the Stac LZS compression >protocol over our PPP link and I will appreciate your help providing the >following information: > >Regarding the LZS protocol packet Check field - Which is most popular >mode used for implementation of the packet data integrity check ? is LCB >mostly used, or CRC or the protocol uses its Extended Mode ? > >Thank you for responding - Michael Liwerant.   Received: from cnri by ietf.org id aa15716; 16 Jun 97 17:30 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA24961 for ; Mon, 16 Jun 1997 17:29:58 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA06511; Mon, 16 Jun 1997 16:12:37 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 16 Jun 1997 16:10:50 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA06473 for ietf-ppp-outgoing; Mon, 16 Jun 1997 16:10:49 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm107-02.dialip.mich.net [141.211.5.165]) by merit.edu (8.8.5/8.8.5) with SMTP id QAA06469 for ; Mon, 16 Jun 1997 16:10:44 -0400 (EDT) Date: Mon, 16 Jun 97 02:49:49 GMT From: William Allen Simpson Message-ID: <6049.wsimpson@greendragon.com> To: "John R. Martz" Cc: ietf-ppp@merit.edu Subject: Re: authentication by multiple methods: Why NOT?? Sender: owner-ietf-ppp@merit.edu Although mostly correct, I'm going to differ with Karl a bit on his answers, because I think the distinctions are important. > Date: Sun, 15 Jun 1997 13:20:03 -0700 > From: Karl Fox > John R. Martz writes: > > I apologize if I'm raising a subject that was already covered in previous > > notes. But I'm STILL confused by the following statement from the last > > paragraph of page 10 of RFC 1994. > > You are correct, this kind of discussion could have been answered by scanning the archives. > > ... "It is not anticipated that a particular named user would be > > authenticated by multiple methods. This would make the user vulnerable to > > attacks which negotiate the least secure method from among a set (such as > > PAP rather than CHAP). If the same secret was used, PAP would reveal the > > secret to be used later with CHAP". > > > > What I do not understand is how allowing authentication by either CHAP or > > PAP is a greater security risk for the secret for a particular user name > > than authentication by PAP alone? > > It's not. Wrong question leads to wrong answer. If we thought that PAP security was just as good as CHAP, then your question might have some validity. That is, not a "greater security risk" than PAP alone. We are deprecating PAP, and only CHAP is advancing. There are good reasons for this! Think about it a little. CHAP is more secure than PAP in several ways. For one, PAP discloses the secret (password or passphrase). Note that RFC-1994 doesn't say "greater security risk". It says "vulnerable to attacks". Attacks are defined by threat models. If your threat is packet snooping, wiretapping, or other passive evesdropping somewhere on your network, then allowing the same secret to be used for PAP and CHAP means that someone can sniff the PAP password, and then use it for CHAP. Allowing both PAP and CHAP for the same user can destroy the security of CHAP's protection against sniffing. Therefore, it is "vulnerable", a very bad thing! There are other vulnerabilites. PAP is one time. CHAP is continuously verified. PAP is more vulnerable to man in the middle than CHAP. Etc. Now, the Security Considerations is not intended to be a tutorial on risks. It simply tells you what you SHOULD NOT do, and points to the vulnerabilities. If you want detailed analysis, you are expected to do some research and study. There are entire conferences every year on this subject. > However, if you have a NAS (Network Access Server) serving > several users, some of which use PAP (perhaps because their dialing > systems don't support anything better) and some of which use CHAP, the > CHAP users shouldn't be able to get in using PAP. The PAP users > *always* are vulnerable to anyone who can see their packets, but > there's no reason to bring the CHAP users down to the same level. > Agreed. And then there is the attack discussed a few years back where the user dials in, is asked for CHAP in LCP negotiation, and negotiates PAP in the other direction (to itself). The CHAP challenge comes. The PAP request comes. The same name and secret are used. The user takes the PAP request secret and uses it to successfully generate the CHAP reply. Boing! Never, never, never use the same username for PAP and CHAP! Note that CHAP uses a _PAIR_ of names. The secret for NameA challenging NameB should be different from NameB challenging NameA. Same timing issues described above apply. Never, never, never use the same secret in both directions! > > If authentication is allowed by PAP and the secret for a user is > > compromised, then the secret is compromised, correct? Whether PAP or > > CHAP is later used to gain access using the compromised user name > > seems of little consequence to me. > > Correct, but if CHAP is the *only* system allowed for a particular > user, his dial-in account is safe from eavesdroppers. > Again, his question is biased. He seems to think that PAP and CHAP are equally secure. Thus, in his eyes, protection against evesdropping is "of little consequence". > > Certainly if the intent is always authenticate with CHAP, then > > authentication must never be allowed to be negotiated down to PAP. > > That's the real point of the RFC 1994 sentence. > Actually, authentication can _always_ be negotiated down to PAP. But, if the user doesn't have a PAP name and password, then it is a waste of time, and the user will fail. That's the real point. It's OK if some users are PAP and others are CHAP at the same NAS. It depends on what level of protection the "realm" desires. In the end, we want them all to move to CHAP (or EAP). > > But if PAP is allowed, what is the harm in first requesting CHAP and > > then negotiating it down to PAP? Or, from the other direction, > > accepting CHAP authentication if requested when you would have > > allowed PAP? Why would either case pose a greater risk than using > > only PAP? > > That's not what 1994 says--it's not talking about first requesting > CHAP and then negotiating down to PAP, it's talking about which > protocol will be allowed to be used for a particular named user. > > > Can someone tell me what I'm not seeing here? > > John, you are misusing words. "Risk" for one. What's your threat environment? Do you know and trust all the other users of your ISP? Do you know and trust your ISP equipment vendor? Do you trust the phone company? Do you trust the government? My question is, did you strictly follow the RFC in your implementation? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2   Received: from ietf.org by ietf.org id aa05555; 17 Jun 97 7:46 EDT Received: from ietf.ietf.org by ietf.org id aa04464; 17 Jun 97 7:21 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ietf-ppp@merit.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-sec-00.txt Date: Tue, 17 Jun 1997 07:20:37 -0400 X-Orig-Sender: scoya@ietf.org Message-ID: <9706170721.aa04464@ietf.org> --NextPart A New 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 : Layer Two Tunneling Protocol "L2TP" - Security Extensions for Non-IP networks Author(s) : Pat Calhoun, W. Mark Townsley Filename : draft-ietf-pppext-l2tp-sec-00.txt Pages : 8 Date : 06/16/1997 The L2TP Document defines the base protocol which describes the method of tunneling PPP data. The spec states that the security mechanism used over an IP network is to use the IETF's IPSEC protocols. L2TP was designed in such a way as to be able to run over any underlying layer (i.e. Frame Relay, ATM, etc.). This document specifies extensions to the L2TP protocol in order to provide authentication and integrity of individual packets in a tunneled session over a non-IP network. It does not intend to provide a mechanism for encryption of packets. 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-l2tp-sec-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-sec-00.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-l2tp-sec-00.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: <19970616093318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-sec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-sec-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970616093318.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa13929; 17 Jun 97 15:18 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA28448 for ; Tue, 17 Jun 1997 15:17:47 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA23863; Tue, 17 Jun 1997 14:24:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 17 Jun 1997 14:21:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA23809 for ietf-ppp-outgoing; Tue, 17 Jun 1997 14:21:15 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by merit.edu (8.8.5/8.8.5) with SMTP id OAA23805 for ; Tue, 17 Jun 1997 14:21:11 -0400 (EDT) Received: from spud.ascend.com (fw-ext.ascend.com [198.4.92.5]) by drawbridge.ascend.com (8.6.12/8.6.12) with ESMTP id LAA07832 for ; Tue, 17 Jun 1997 11:21:03 -0700 Received: from ascend.com by ascend.com with ESMTP id LAA01487 for ; Tue, 17 Jun 1997 11:20:57 -0700 Received: from carp.morningstar.com.ascend.com (karl@carp.MorningStar.Com [137.175.81.4]) by gump.eng.ascend.com (8.6.12/8.6.12) with SMTP id LAA24686 for ; Tue, 17 Jun 1997 11:20:55 -0700 Date: Tue, 17 Jun 1997 11:20:55 -0700 Message-Id: <199706171820.LAA24686@gump.eng.ascend.com> From: Karl Fox To: ietf-ppp@merit.edu Subject: Munich PPPEXT schedule Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ietf-ppp@merit.edu The PPPEXT schedule for Munich is as follows: Monday, August 11 at 1930-2200 (opposite calsch, snmpv3, udlr, tcpimp) Tuesday, August 12 at 1415-1515 (opposite nntpext) -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041   Received: from cnri by ietf.org id aa28332; 18 Jun 97 1:49 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid BAA00064 for ; Wed, 18 Jun 1997 01:49:03 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id BAA05246; Wed, 18 Jun 1997 01:31:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 18 Jun 1997 01:29:56 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id BAA05231 for ietf-ppp-outgoing; Wed, 18 Jun 1997 01:29:56 -0400 (EDT) Received: from rnd-gate.rad.co.il (rnd-gate.rad.co.il [207.232.32.14]) by merit.edu (8.8.5/8.8.5) with ESMTP id BAA05227 for ; Wed, 18 Jun 1997 01:29:28 -0400 (EDT) Received: from smtp-gateway.rad.co.il ([176.189.111.1]) by rnd-gate.rad.co.il (8.7.3/8.7.3) with SMTP id IAA29079 for ; Wed, 18 Jun 1997 08:18:22 +0300 (IDT) Received: by smtp-gateway.rad.co.il with Microsoft Mail id <33A781EC@smtp-gateway.rad.co.il>; Wed, 18 Jun 97 08:36:28 EST From: Michael Liwerant To: "'ietf-ppp@merit.edu'" Subject: MLCP (RFC_1990) - need clarification Date: Wed, 18 Jun 97 08:26:00 EST Message-ID: <33A781EC@smtp-gateway.rad.co.il> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu I will appreciate your help by clarifying the meaning of the following paragraph included in the bottom of page 3: "All packets received over links identified as belonging to the multilink arrangement are presented to the same network-layer protocol processing machine, whether they have multilink headers or not" I am confused when reading this as it seems to contridict the following sentence found in chpater 8 of the same RFC: "In some instances it may be desirable for some Network Protocols to be exempted from sequencing requirements, and if the MRU sizes of the link did not cause fragmentation, those protocols could be sent directly over the member links" My specific question is: can LCP/NCP/NLP protocol packets be proccessed according to the ususal PPP specification even if they are received on a link associated with a multilink bundle (and those packets do not contain multilink header) ? Thank you for responding.   Received: from cnri by ietf.org id aa28414; 18 Jun 97 1:55 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid BAA00070 for ; Wed, 18 Jun 1997 01:55:02 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id BAA05286; Wed, 18 Jun 1997 01:35:03 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 18 Jun 1997 01:33:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id BAA05262 for ietf-ppp-outgoing; Wed, 18 Jun 1997 01:33:36 -0400 (EDT) Received: from rnd-gate.rad.co.il (rnd-gate.rad.co.il [207.232.32.14]) by merit.edu (8.8.5/8.8.5) with ESMTP id BAA05258 for ; Wed, 18 Jun 1997 01:33:30 -0400 (EDT) Received: from smtp-gateway.rad.co.il ([176.189.111.1]) by rnd-gate.rad.co.il (8.7.3/8.7.3) with SMTP id IAA29092 for ; Wed, 18 Jun 1997 08:22:25 +0300 (IDT) Received: by smtp-gateway.rad.co.il with Microsoft Mail id <33A782DF@smtp-gateway.rad.co.il>; Wed, 18 Jun 97 08:40:31 EST From: Michael Liwerant To: 'ietf_ppp' Subject: MLCP (RFC_1990) - need clarification Date: Wed, 18 Jun 97 08:32:00 EST Message-ID: <33A782DF@smtp-gateway.rad.co.il> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ppp@merit.edu I will appreciate your help by clarifying the meaning of the following paragraph included in the bottom of page 3: "All packets received over links identified as belonging to the multilink arrangement are presented to the same network-layer protocol processing machine, whether they have multilink headers or not" I am confused when reading this as it seems to contridict the following sentence found in chpater 8 of the same RFC: "In some instances it may be desirable for some Network Protocols to be exempted from sequencing requirements, and if the MRU sizes of the link did not cause fragmentation, those protocols could be sent directly over the member links" My specific question is: can LCP/NCP/NLP protocol packets be proccessed according to the ususal PPP specification even if they are received on a link associated with a multilink bundle (and those packets do not contain multilink header) ? Thank you for responding.   Received: from cnri by ietf.org id aa07644; 18 Jun 97 10:12 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA00970 for ; Wed, 18 Jun 1997 10:11:23 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA10139; Wed, 18 Jun 1997 09:40:28 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 18 Jun 1997 09:36:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA10035 for ietf-ppp-outgoing; Wed, 18 Jun 1997 09:36:15 -0400 (EDT) Received: from ftp.com (ftp.com [128.127.2.122]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA10028 for ; Wed, 18 Jun 1997 09:36:10 -0400 (EDT) Received: from ftp.com by ftp.com ; Wed, 18 Jun 1997 09:35:39 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Wed, 18 Jun 1997 09:35:39 -0400 Received: from bray-2.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id JAA08039; Wed, 18 Jun 1997 09:31:52 -0400 Message-Id: <199706181331.JAA08039@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: MichaelL@rnd.rndmail.rad.co.il, ietf-ppp@merit.edu X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Subject: RE: MLCP (RFC_1990) - need clarification Date: Wed, 18 Jun 1997 09:35:36 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu >>Reply to message from Michael Liwerant (MichaelL@RND.RNDMAIL.rad.co.il) dated 6/18/97 1:51 AM > > > > I will appreciate your help by clarifying the meaning of > the following > paragraph included in the bottom of page 3: > > "All packets received over links identified as belonging > to the multilink > arrangement are presented to the same network-layer > protocol processing > machine, whether they have multilink headers or not" > > I am confused when reading this as it seems to > contridict the following > sentence found in chpater 8 of the same RFC: > > "In some instances it may be desirable for some > Network Protocols to be > exempted from sequencing requirements, and if the > MRU sizes of the link > did not cause fragmentation, those protocols could be > sent directly over > the member links" I don't see a contradiction there. > > My specific question is: can LCP/NCP/NLP protocol > packets be proccessed > according to the ususal PPP specification even if they > are received on a > link associated with a multilink bundle (and those > packets do not contain > multilink header) ? Yes. Even if you have negotiated multilink, you are not obligated to use MLP headers on all of your packets. If you don't need to fragment, and you don't care whether packets sent on different links are kept in sequence, there is no need to use MLP. Some implementations (ours, for example) always send NCP packets without MLP headers. The peer MUST NOT make any distinction between packets sent with MLP and without MLP. _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 E-mail: bray@ftp.com   Received: from cnri by ietf.org id aa18666; 18 Jun 97 17:19 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA02270 for ; Wed, 18 Jun 1997 17:18:16 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id QAA21105; Wed, 18 Jun 1997 16:49:15 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 18 Jun 1997 16:48:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id QAA21080 for ietf-ppp-outgoing; Wed, 18 Jun 1997 16:48:15 -0400 (EDT) Received: from vangogh.CS.Berkeley.EDU (vangogh.CS.Berkeley.EDU [128.32.33.5]) by merit.edu (8.8.5/8.8.5) with ESMTP id QAA21076 for ; Wed, 18 Jun 1997 16:48:11 -0400 (EDT) Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id NAA04530; Wed, 18 Jun 1997 13:47:08 -0700 (PDT) Date: Wed, 18 Jun 1997 13:47:08 -0700 (PDT) From: Keith Sklower Message-Id: <199706182047.NAA04530@vangogh.CS.Berkeley.EDU> To: MichaelL@rnd.rndmail.rad.co.il Subject: RE: MLCP (RFC_1990) - need clarification Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu From MichaelL@RND.RNDMAIL.rad.co.il Tue Jun 17 22:50:35 1997 Dear Mr. Sklower Thank you for clarifying and solving my confusion. I still think that the discussed paragraph on page 3 lacks a stress that the meaning of "the same network-layer protocol processing machine" is the end destination NLP protocol (i.e. - IP, IPX, BCP) and not the MP. Am I wright ? Dear Mr. Liwerant There were many heated discussions on the mailing list whether The multilink protocol should be considered a network level entity or not. The group reached a consensus that it was not a network level entity. Being the chooser of those words, of course I think that they were plainly sufficient, and this is the first time I've received a question concerning it; however, if RFC 1990 needs to be revised in going from draft to full standard and if somebody on the mailing list wishes to propose alternate wording for that paragraph I will consider including it. ---------- From: Keith Sklower Sent: Tuesday, June 17, 1997 1:41 PM To: MichaelL Subject: Re: MLCP (RFC_1990) - need clarification From MichaelL@RND.RNDMAIL.rad.co.il Tue Jun 17 07:28:17 1997 From: Michael Liwerant To: "'sklower@CS.Berkeley.EDU'" Subject: MLCP (RFC_1990) - need clarification Date: Tue, 17 Jun 97 17:26:00 EST Encoding: 24 TEXT X-Mailer: Microsoft Mail V3.0 I will appreciate your help by clarifying the meaning of the following paragraph included in the bottom of page 3: "All packets received over links identified as belonging to the multilink arrangement are presented to the same network-layer protocol processing machine, whether they have multilink headers or not" I am confused when reading this as it seems to contradict the following sentence found in chpater 8 of the same RFC: "In some instances it may be desirable for some Network Protocols to be exempted from sequencing requirements, and if the MRU sizes of the link did not cause fragmentation, those protocols could be sent directly over the member links" This is no contradiction because the multilink processing is not considered a network-layer protocol. In terms of the description there is a strict layering between LCP, link and multilink processing on the one hand, and NCP and network-level data protocols, on the other. My specific question is: can LCP/NCP/NLP protocol packets be proccessed according to the ususal PPP specification even if they are received on a link associated with a multilink bundle and those packets do not contain multilink header ? I believe that the RFC goes on to state, or at least imply that you are forbidden from putting multilink headers in front of an LCP packet. If the receiver gets a packet with a multilink header at the front of it, it holds it up and subjects to reassembly and sequencing delays. If there is no multilink header on it, and if it is not an LCP packet, then the link layer immediately presents it to the appropriate network-level processing engine. If my language is still confusing to you, then you should ask on the ietf-ppp mailing list. (I won't take offense at this, but I gave the document my best effort at being clear, and it could be that there is something about my choice of words which is misleading you, and maybe somebody else's choice of words will help you understand what was intended). Thank you for responding. You're welcome, and I hope this helps.   Received: from cnri by ietf.org id aa19421; 18 Jun 97 18:13 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA02424 for ; Wed, 18 Jun 1997 18:12:47 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id RAA22294; Wed, 18 Jun 1997 17:43:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 18 Jun 1997 17:43:26 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id RAA22278 for ietf-ppp-outgoing; Wed, 18 Jun 1997 17:43:25 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by merit.edu (8.8.5/8.8.5) with ESMTP id RAA22274 for ; Wed, 18 Jun 1997 17:43:19 -0400 (EDT) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.7.6/8.6.10/MOT-3.8) with ESMTP id QAA11863 for ; Wed, 18 Jun 1997 16:43:16 -0500 (CDT) Received: from il02dns1.comm.mot.com (il02dns1.comm.mot.com [145.1.3.2]) by pobox.mot.com (8.7.6/8.6.10/MOT-3.8) with ESMTP id QAA29054 for ; Wed, 18 Jun 1997 16:43:13 -0500 (CDT) Received: from ssd.comm.mot.com ([145.1.92.11]) by il02dns1.comm.mot.com (8.7.5/8.7.3) with SMTP id QAA00232; Wed, 18 Jun 1997 16:43:07 -0500 (CDT) Received: from ssdultra24.ssd by ssd.comm.mot.com (4.1/SMI-4.1) id AA09680; Wed, 18 Jun 97 16:42:57 CDT Origin: ssd Received: by ssdultra24.ssd (SMI-8.6/SMI-SVR4) id QAA04363; Wed, 18 Jun 1997 16:42:54 -0500 Date: Wed, 18 Jun 1997 16:42:54 -0500 From: Chris Stanaway Message-Id: <9706181642.ZM4361@comm.mot.com> In-Reply-To: stanaway@comm.mot.com (Chris Stanaway) "Re: I-D ACTION:draft-ietf-pppext-ipcp-mip-01.txt" (Jun 13, 4:48pm) References: <9705301844.AA07466@becks.comm.mot.com> <9706131648.ZM17978@comm.mot.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-ipcp-mip-01.txt Cc: mobile-ip@smallworks.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu On Fri, Jun 13, at 4:48pm, Chris Stanaway wrote: Subject: Re: I-D ACTION:draft-ietf-pppext-ipcp-mip-01.txt > > I've a question on how this would work with co-located COA's. > > How would a new co-located COA be assigned to a MN once IPCP has completed? > For the non-MIP folks, the question is essentially "Once a PPP peer (i.e. > a dial-up server) has dynamically assigned an IP address how can that > peer dynamically assign a different IP address to a node?" > >-- End of excerpt from Chris Stanaway I think I might be able to answer my own question, but I'm not sure if it's correct. Even so, I think the draft needs to be updated to clarify this. If a MN has detected that is has moved (as described in section 3.2 of the draft), then the MN MUST (SHOULD?) re-negotiate IPCP regardless of whether it is using a co-located COA or a FA COA. Also in section 3.2, the statement was made (twice) that upon detecting a move and receiving an Agent Advertisement, the MN is to register with that FA. I believe this needs to changed to indicate that the MN only needs to register with the FA if it is using the FA COA or the Agent Advertisement indicates that the MN must register with the FA. Last comment. draft-ietf-pppext-ipcp-mip-01.txt states => Nak(IP=0) SHOULD NOT be sent and historically means "send me Request(a.b.c.d) because I insist on knowing your address". Goto 6. and draft-ietf-pppext-ipcp-network-01.txt states If negotiation about the remote IP-address is required, and the peer did not provide the option in its Configure-Request, the option SHOULD be appended to a Configure-Nak. The value of the IP-address given must be acceptable as the remote IP-address, or indicate a request that the peer provide the information. Assuming that to "indicate a request that the peer provide the information" means to send Nak(IP=0), then the two drafts appear to be in conflict. Comments? Chris +-----------------------------------------------------------+ |J. Christopher Stanaway |Motorola, Inc. | |Lead Engineer |Land Mobile Products Sector | |iDEN Strategic Features |iDEN Technology Division | |E-Mail: stanaway@comm.mot.com |1301 E. Algonquin Road | |Office: (847) 576-9517 |Schaumburg, IL 60196 USA | +-----------------------------------------------------------+   Received: from cnri by ietf.org id aa19910; 18 Jun 97 18:40 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA02493 for ; Wed, 18 Jun 1997 18:39:23 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id SAA22775; Wed, 18 Jun 1997 18:13:41 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 18 Jun 1997 18:13:27 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id SAA22760 for ietf-ppp-outgoing; Wed, 18 Jun 1997 18:13:26 -0400 (EDT) Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.8.5/8.8.5) with SMTP id SAA22753 for ; Wed, 18 Jun 1997 18:13:21 -0400 (EDT) Received: from ftp.com by ftp.com ; Wed, 18 Jun 1997 18:12:50 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Wed, 18 Jun 1997 18:12:50 -0400 Received: from bray-2.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id SAA00029; Wed, 18 Jun 1997 18:09:01 -0400 Message-Id: <199706182209.SAA00029@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: sklower@cs.berkeley.edu, MichaelL@rnd.rndmail.rad.co.il Cc: ietf-ppp@merit.edu X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Subject: RE: MLCP (RFC_1990) - need clarification Date: Wed, 18 Jun 1997 18:12:47 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu >>Reply to message from Keith Sklower (sklower@CS.Berkeley.EDU) dated 6/18/97 5:40 PM > > . > . > . > > I believe that the RFC goes on to state, or at least imply > that you > are forbidden from putting multilink headers in front of > an LCP > packet. Actually, only LCP negotiation (Config-Req, Config-Ack, Config-Nak, Config-Rej) and link termination (Terminate-Req and Terminate-Ack) are forbidden within the bundle. Other LCP packets (Echo-Request, Echo-Reply, etc.) are OK. > > . > . > . > _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 E-mail: bray@ftp.com   Received: from cnri by ietf.org id aa21011; 18 Jun 97 19:46 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA02629 for ; Wed, 18 Jun 1997 19:45:50 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id TAA23979; Wed, 18 Jun 1997 19:21:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 18 Jun 1997 19:21:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id TAA23961 for ietf-ppp-outgoing; Wed, 18 Jun 1997 19:21:30 -0400 (EDT) Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.8.5/8.8.5) with SMTP id TAA23954 for ; Wed, 18 Jun 1997 19:21:26 -0400 (EDT) Received: from ftp.com by ftp.com ; Wed, 18 Jun 1997 19:20:40 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Wed, 18 Jun 1997 19:20:40 -0400 Received: from elsinore by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id TAA03436; Wed, 18 Jun 1997 19:16:51 -0400 Message-Id: <199706182316.TAA03436@MAILSERV-2HIGH.FTP.COM> X-Sender: glass@mailserv-2high X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Jun 1997 19:20:18 -0400 To: Chris Stanaway , ietf-ppp@merit.edu From: Steven Glass Subject: Re: I-D ACTION:draft-ietf-pppext-ipcp-mip-01.txt Cc: mobile-ip@smallworks.com, solomon@comm.mot.com Sender: owner-ietf-ppp@merit.edu At 16:42 6/18/97 -0500, Chris Stanaway wrote: >On Fri, Jun 13, at 4:48pm, Chris Stanaway wrote: >Subject: Re: I-D ACTION:draft-ietf-pppext-ipcp-mip-01.txt >> >> I've a question on how this would work with co-located COA's. >> >> How would a new co-located COA be assigned to a MN once IPCP >>has completed? For the non-MIP folks, the question is >>essentially "Once a PPP peer (i.e. a dial-up server) has >>dynamically assigned an IP address how can that peer dynamically >>assign a different IP address to a node?" >> >>-- End of excerpt from Chris Stanaway > >I think I might be able to answer my own question, but I'm not >sure if it's correct. Even so, I think the draft needs to be >updated to clarify this. If a MN has detected that is has moved >(as described in section 3.2 of the draft), then the MN MUST >(SHOULD?) re-negotiate IPCP regardless of whether it is using a >co-located COA or a FA COA. If a MN is using an FA CoA, then it should be able to simply register it's home address with the new FA; renegotiating IPCP is a waste of time. If the ppp peer doesn't like the MN's address it should be the one to commence IPCP renegotiation. A mobile node MUST renegotiate IPCP if it detects it's moved, and it's colocated. Perhaps there's a multiple-bindings-like solution out there - my head hurts too much to think about it now! >Also in section 3.2, the statement was made (twice) that upon >detecting a move and receiving an Agent Advertisement, the MN is >to register with that FA. I believe this needs to changed to >indicate that the MN only needs to register with the FA if it is >using the FA COA or the Agent Advertisement indicates that the MN >must register with the FA. Agreed - after IPCP is renegotiated... >Last comment. draft-ietf-pppext-ipcp-mip-01.txt states > > => Nak(IP=0) SHOULD NOT be sent and historically means "send me > Request(a.b.c.d) because I insist on knowing your address". > Goto 6. > >and draft-ietf-pppext-ipcp-network-01.txt states > > If negotiation about the remote IP-address is required, and the > peer did not provide the option in its Configure-Request, the > option SHOULD be appended to a Configure-Nak. The value of the > IP-address given must be acceptable as the remote IP-address, or > indicate a request that the peer provide the information. > >Assuming that to "indicate a request that the peer provide the >information" means to send Nak(IP=0), then the two drafts appear >to be in conflict. > >Comments? Well, it's not a MUST in our draft ()... Actually, I'm not convinced that Nak(IP=0) is what will be sent. Actually, if Nak(IP=0) is sent, what should the peer send in reply? For example, lets say I send foo(x) in my request, and the PPP server requires IP address negotiation (but foo(x) is alright), according to the draft it should either respond with Nak(IP=0), or Nak(IP=x.y.z.t) where x.y.z.t is a valid IP address on this link. In the case of Nak(IP=x.y.z.t) the peer is nudging me towards using x.y.z.t as my IP address, which I can accept, or try to negtiate another. I guess what I'm getting at is why should the peer send Nak(IP=0) which can only prompt to send Req(IP=0) if I don't know what to request, or Req(IP=x.y.z.t), when it can send Nak(IP=a.b.c.d) which I can accept (saving round trips!), or try Req(IP=x.y.z.t) anyway. It seems better for the peer to cut to the chase, and propose an actual address to potential save a round trip... Perhaps the authors of draft-ietf-pppext-ipcp-network-01.txt have something more intelligent (or specific) to add? Cheers, Steve   Received: from cnri by ietf.org id aa06380; 19 Jun 97 10:04 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid KAA03642 for ; Thu, 19 Jun 1997 10:03:44 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id JAA03103; Thu, 19 Jun 1997 09:34:53 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 19 Jun 1997 09:31:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id JAA03053 for ietf-ppp-outgoing; Thu, 19 Jun 1997 09:31:09 -0400 (EDT) Received: from ftp.com (ftp.com [128.127.2.122]) by merit.edu (8.8.5/8.8.5) with SMTP id JAA03049 for ; Thu, 19 Jun 1997 09:31:05 -0400 (EDT) Received: from ftp.com by ftp.com ; Thu, 19 Jun 1997 09:30:25 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Thu, 19 Jun 1997 09:30:25 -0400 Received: from bray-2.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id JAA09670; Thu, 19 Jun 1997 09:26:37 -0400 Message-Id: <199706191326.JAA09670@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: Steven Glass , stanaway@comm.mot.com, ietf-ppp@merit.edu Cc: mobile-ip@smallworks.com, solomon@comm.mot.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: John Bray Subject: RE: I-D ACTION:draft-ietf-pppext-ipcp-mip-01.txt Date: Thu, 19 Jun 1997 09:30:23 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu >>Reply to message from Steven Glass (glass@ftp.com) dated 6/18/97 8:04 PM > At 16:42 6/18/97 -0500, Chris Stanaway wrote: > >On Fri, Jun 13, at 4:48pm, Chris Stanaway wrote: > >Subject: Re: I-D ACTION:draft-ietf-pppext-ipcp-mip-01.txt > >> > . > . > . > > >Last comment. draft-ietf-pppext-ipcp-mip-01.txt states > > > > => Nak(IP=0) SHOULD NOT be sent and historically > means "send me > > Request(a.b.c.d) because I insist on knowing your > address". > > Goto 6. > > > >and draft-ietf-pppext-ipcp-network-01.txt states > > > > If negotiation about the remote IP-address is required, > and the > > peer did not provide the option in its > Configure-Request, the > > option SHOULD be appended to a Configure-Nak. The > value of the > > IP-address given must be acceptable as the remote > IP-address, or > > indicate a request that the peer provide the > information. > > > >Assuming that to "indicate a request that the peer > provide the > >information" means to send Nak(IP=0), then the two > drafts appear > >to be in conflict. > > > >Comments? > > Well, it's not a MUST in our draft ()... > > Actually, I'm not convinced that Nak(IP=0) is what > will be > sent. Actually, if Nak(IP=0) is sent, what should the > peer send > in reply? For example, lets say I send foo(x) in my > request, and > the PPP server requires IP address negotiation (but > foo(x) is > alright), according to the draft it should either respond > with > Nak(IP=0), or Nak(IP=x.y.z.t) where x.y.z.t is a valid IP > address > on this link. In the case of Nak(IP=x.y.z.t) the peer is > nudging > me towards using x.y.z.t as my IP address, which I can > accept, or > try to negtiate another. I guess what I'm getting at is > why > should the peer send Nak(IP=0) which can only prompt > to send > Req(IP=0) if I don't know what to request, or > Req(IP=x.y.z.t), > when it can send Nak(IP=a.b.c.d) which I can accept > (saving round > trips!), or try Req(IP=x.y.z.t) anyway. It seems better for > the > peer to cut to the chase, and propose an actual address > to > potential save a round trip... > > Perhaps the authors of > draft-ietf-pppext-ipcp-network-01.txt > have something more intelligent (or specific) to add? > > Cheers, > Steve > > >>End of message This has been a rather controversial subject. My opinion (which I believe is consistent with the current consensus) is that Nak(IP=0) is useless and effectively violates RFC1661. What does the remote peer do if the local peer responds by sending Config-Req(IP=0)? According to RFC1661, options included in a Config-Nak MUST specify acceptable values. By that logic, the remote MUST then respond by sending Ack(IP=0)! In any event, if the local peer knew its IP address, it should have specified it in the first place. The fact that it didn't implies that it doesn't know and/or doesn't care. If the remote *does* care, it should assign an address. I think the words "or indicate a request that the peer provide the information" should be stricken from the draft to avoid further confusion. _________________________________________________ John Bray Senior Staff Engineer FTP Software, Inc. 2 High St. North Andover, MA 01845 E-mail: bray@ftp.com   Received: from cnri by ietf.org id aa12530; 19 Jun 97 14:43 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA04548 for ; Thu, 19 Jun 1997 14:42:14 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id OAA08069; Thu, 19 Jun 1997 14:01:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 19 Jun 1997 14:00:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id OAA08018 for ietf-ppp-outgoing; Thu, 19 Jun 1997 14:00:09 -0400 (EDT) Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by merit.edu (8.8.5/8.8.5) with ESMTP id OAA08013 for ; Thu, 19 Jun 1997 14:00:04 -0400 (EDT) Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id KAA13744; Thu, 19 Jun 1997 10:54:56 -0700 (PDT) for Received: from lobster1.corpeast.Baynetworks.com (lobster1.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/06/05-I) with SMTP id KAA16854; Thu, 19 Jun 1997 10:55:50 -0700 (PDT) for Posted-Date: Thu, 19 Jun 1997 10:55:50 -0700 (PDT) Received: from bl-mail2.corpeast.BayNetworks.com (bl-mail2-nf0) by lobster1.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AA07843; Thu, 19 Jun 97 13:55:52 EDT for ietf-ppp@merit.edu Received: from rnayak.xylogics.com ([132.245.105.41]) by bl-mail2.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA20107 for ; Thu, 19 Jun 1997 13:55:46 -0400 Message-Id: <3.0.32.19970619135519.00696a2c@bl-mail2.corpeast.baynetworks.com> X-Sender: rnayak@bl-mail2.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 19 Jun 1997 13:55:20 -0400 To: ietf-ppp@merit.edu From: Ramakrishna Nayak Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu   Received: from cnri by ietf.org id aa07584; 20 Jun 97 11:51 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA06729 for ; Fri, 20 Jun 1997 11:50:37 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id LAA23189; Fri, 20 Jun 1997 11:17:19 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 20 Jun 1997 11:12:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id LAA23103 for ietf-ppp-outgoing; Fri, 20 Jun 1997 11:12:03 -0400 (EDT) Received: from relay2.iemmc.org ([206.85.20.103]) by merit.edu (8.8.5/8.8.5) with ESMTP id LAA23096 for ; Fri, 20 Jun 1997 11:11:57 -0400 (EDT) Received: from img.outgoing.com (img.outgoing.com [209.14.30.51]) by relay2.iemmc.org (8.8.5/8.8.5) with ESMTP id LAA12150 for ; Fri, 20 Jun 1997 11:11:21 -0400 (EDT) X-Advertisement: Visit http://www.iemmc.org for name removal information. Received: (from email@localhost) by img.outgoing.com (8.8.3/8.7.3) id LAA25975 for ietf-ppp@merit.edu; Fri, 20 Jun 1997 11:13:07 -0400 (EDT) Date: Fri, 20 Jun 1997 11:13:07 -0400 (EDT) Message-Id: <199706201513.LAA25975@img.outgoing.com> From: info@did-it.com To: ietf-ppp@merit.edu Subject: Is your site listed? Sender: owner-ietf-ppp@merit.edu Hi, I just surfed in from your Yahoo listing. It's good to see that you are listed there... As a webmaster or webmarketer, you know that getting traffic from the search engines and directories is absolutely crucial to the success of your (or your client's) site. You have probably used Submit-it or another service to submit your sites. Submit-it is a really great service .... but, as you may be aware, the search engines don't always process the submissions, and they also drop many sites that used to be listed out of the directories to keep the size of their database down, so you never can be sure if you have an active listing, till now. So, we have launched a new service called did-it.com at http://www.did-it.com. The did-it.com Detective will check any URL to see if the URL is listed in the search engines and e-mail you a status report FREE OF CHARGE. If you find you're not listed, you can utilize our Did-it submission service. What is unique about this service is that it will monitor the status of your site on all the popular search engines and automatically resubmit you wherever you're not listed. Today, that's the ONLY way you can be sure you get listed and stay listed, automatically. Come take a look... http://www.did-it.com and use our detective service FREE! BTW, If you like our service you can also become a did-it.com Partner. In exchange for putting a small icon next to a link to us, you will become eligible for did-it.com Partner benefits. Check out the partner program at: http://www.did-it.com/ click on the partner icon. Thanks so much. Regards, The did-it.com team.   Received: from ietf.org by ietf.org id aa15551; 23 Jun 97 18:26 EDT Received: from ietf.ietf.org by ietf.org id aa15203; 23 Jun 97 18:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-sec-00.txt Date: Mon, 23 Jun 1997 18:18:14 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9706231818.aa15203@ietf.org> --NextPart A New 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 : Layer Two Tunneling Protocol "L2TP" - Security Extensions for Non-IP networks Author(s) : Pat Calhoun, W. Mark Townsley Filename : draft-ietf-pppext-l2tp-sec-00.txt Pages : 8 Date : 06/16/1997 The L2TP Document defines the base protocol which describes the method of tunneling PPP data. The spec states that the security mechanism used over an IP network is to use the IETF's IPSEC protocols. L2TP was designed in such a way as to be able to run over any underlying layer (i.e. Frame Relay, ATM, etc.). This document specifies extensions to the L2TP protocol in order to provide authentication and integrity of individual packets in a tunneled session over a non-IP network. It does not intend to provide a mechanism for encryption of packets. 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-l2tp-sec-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-sec-00.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-l2tp-sec-00.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: <19970623181644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-sec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-sec-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970623181644.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa00835; 23 Jun 97 20:03 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA12402 for ; Mon, 23 Jun 1997 20:02:12 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id TAA04196; Mon, 23 Jun 1997 19:47:13 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 23 Jun 1997 19:46:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id TAA04168 for ietf-ppp-outgoing; Mon, 23 Jun 1997 19:46:24 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by merit.edu (8.8.5/8.8.5) with ESMTP id TAA04164 for ; Mon, 23 Jun 1997 19:46:21 -0400 (EDT) Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49) id ; Mon, 23 Jun 1997 16:46:21 -0700 Message-ID: <9106B0327B3ACF11ACEF00805FD47A0B02EAA3C1@RED-67-MSG.dns.microsoft.com> From: Vijay Baliga To: ietf-ppp@merit.edu Subject: Status field in BAP Call-Status Option (RFC 2125) Date: Mon, 23 Jun 1997 16:09:16 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ietf-ppp@merit.edu Hi, RFC 2125 (The PPP Bandwidth Allocation Protocol) states on pg 22 that the Status field in the BAP Call-Status Option MAY contain the same number as the Q.931 cause value (i.e., 1 is unassigned number, 17 is user busy, etc.). I would like to know where I can get the complete list of Q.931 cause values. Thanks in advance for any help! Vijay   Received: from ietf.org by ietf.org id aa06052; 26 Jun 97 9:32 EDT Received: from ietf.ietf.org by ietf.org id aa05647; 26 Jun 97 9:10 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ietf-ppp@merit.edu Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-04.txt Date: Thu, 26 Jun 1997 09:10:22 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9706260910.aa05647@ietf.org> --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 : Layer Two Tunneling Protocol "L2TP" Author(s) : K. Hamzeh, T. Kolar, M. Littlewood, G. Pall, J. Taarud, A. Valencia, W. Verthein Filename : draft-ietf-pppext-l2tp-04.txt Pages : 81 Date : 06/25/1997 Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up via PPP [1]. This document describes the Layer Two Tunneling Protocol (L2TP) which permits the tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. 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-l2tp-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-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-l2tp-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: <19970625175814.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970625175814.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa01398; 30 Jun 97 3:52 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid DAA14960 for ; Mon, 30 Jun 1997 03:51:36 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id DAA26963; Mon, 30 Jun 1997 03:25:03 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 30 Jun 1997 03:16:40 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id DAA26900 for ietf-ppp-outgoing; Mon, 30 Jun 1997 03:16:40 -0400 (EDT) Received: from sphere.ad.jp (mail.sphere.ad.jp [210.150.255.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id DAA26896 for ; Mon, 30 Jun 1997 03:16:35 -0400 (EDT) Received: from Ozawa.sphere.ad.jp ([210.136.166.225]) by sphere.ad.jp (8.8.5/3.5Wpl7) with SMTP id QAA05335; Mon, 30 Jun 1997 16:16:32 +0900 (JST) Message-Id: <199706300716.QAA05335@sphere.ad.jp> X-Sender: mitsuko@sphere.ad.jp X-Mailer: Windows Eudora Pro Version 3.0-J (32) Date: Mon, 30 Jun 1997 16:21:22 +0900 To: ietf-ppp@merit.edu From: Mitsuko Ozawa Subject: Qs about RFC1661 Cc: mitsuko@sphere.ad.jp Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Sender: owner-ietf-ppp@merit.edu Dear Sirs, I have across a sentence that I am not sure about how to translate from English to Japanese, and I was hoping that someone out there can help me. These are all from the documents of RFC1661. ＜Q1＞ Page23：4.6. Counters and Timers Implementation Note: The Restart timer SHOULD be based on the speed of the link. The default value is designed for low speed (2,400 to 9,600 bps), high switching latency links (typical telephone lines). Higher speed links, or links with low switching latency, SHOULD have correspondingly faster retransmission times. Instead of a constant value, the Restart timer MAY begin at an initial small value and increase to the configured final value. Each successive value less than the final value SHOULD be at least twice the previous value. The initial value SHOULD be large enough to account for the size of the packets, twice the round trip time for transmission at the link speed, and at least an additional 100 milliseconds to allow the peer to process the packets before responding. Some circuits add - - > another 200 milliseconds of satellite delay. Round trip times for modems operating at 14,400 bps have been measured in the range of 160 to more than 600 milliseconds. In this section, I don't know how to understand the structure of last sentence. "Round trip times for modems operating at 14,400 bps have been measured in the range of 160 to more than 600 milliseconds." "In the range of 160 to more than 600 milliseconds" points what? I want to know the unit of 160 in this case. I guess 60 round trip times, does it make sense? Could you let me know another expression of this sentence? I would be very grateful for help with any of these sentences. Also, any good reference works for this type of stuff would be great. Thank you very much in advance for any help. Sinserely, Mitsuko Ozawa   Received: from cnri by ietf.org id aa10027; 30 Jun 97 11:21 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA15866 for ; Mon, 30 Jun 1997 11:20:36 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA00972; Mon, 30 Jun 1997 10:50:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 30 Jun 1997 10:40:34 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA00802 for ietf-ppp-outgoing; Mon, 30 Jun 1997 10:40:33 -0400 (EDT) Received: from Bill.Simpson.DialUp.Mich.Net (pm035-21.dialip.mich.net [141.211.7.32]) by merit.edu (8.8.5/8.8.5) with SMTP id KAA00788; Mon, 30 Jun 1997 10:40:22 -0400 (EDT) Date: Mon, 30 Jun 97 13:42:42 GMT From: William Allen Simpson Message-ID: <6149.wsimpson@greendragon.com> To: Mitsuko Ozawa Cc: ietf-ppp@merit.edu Subject: Re: Qs about RFC1661 Sender: owner-ietf-ppp@merit.edu Hmmm, he sent me this same message earlier, here's my reply: > least twice the previous value. The initial value SHOULD be > large enough to account for the size of the packets, twice the > round trip time for transmission at the link speed, and at > least an additional 100 milliseconds to allow the peer to > process the packets before responding. Some circuits add > - - > another 200 milliseconds of satellite delay. Round trip times > for modems operating at 14,400 bps have been measured in the > range of 160 to more than 600 milliseconds. > > In this section, I don't know how to understand the structure of last > sentence. > "Round trip times for modems operating at 14,400 bps have been measured in > the range of 160 to more than 600 milliseconds." > "In the range of 160 to more than 600 milliseconds" points what? > I want to know the unit of 160 in this case. I guess 60 round trip times, does > it make sense? The units (as in all the related sentences) are in milliseconds. That's the "range of 160 to more than 600" -> "160 .. 600+". WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2   Received: from cnri by ietf.org id aa10251; 30 Jun 97 11:31 EDT Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA15920 for ; Mon, 30 Jun 1997 11:30:24 -0400 (EDT) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA00981; Mon, 30 Jun 1997 10:50:34 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 30 Jun 1997 10:43:03 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA00850 for ietf-ppp-outgoing; Mon, 30 Jun 1997 10:43:02 -0400 (EDT) Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by merit.edu (8.8.5/8.8.5) with SMTP id KAA00846 for ; Mon, 30 Jun 1997 10:42:56 -0400 (EDT) Received: (fox@localhost) by greatdane.cisco.com (8.6.12/8.6.5) id HAA25236; Mon, 30 Jun 1997 07:41:48 -0700 From: Craig Fox Message-Id: <199706301441.HAA25236@greatdane.cisco.com> Subject: Re: Qs about RFC1661 To: Mitsuko Ozawa Date: Mon, 30 Jun 97 7:41:47 PDT Cc: ietf-ppp@merit.edu, mitsuko@sphere.ad.jp In-Reply-To: <199706300716.QAA05335@sphere.ad.jp>; from "Mitsuko Ozawa" at Jun 30, 97 4:21 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ietf-ppp@merit.edu > > Dear Sirs, > > I have across a sentence that I am not sure about how to translate from English > to Japanese, and I was hoping that someone out there can help me. These are all > from the documents of RFC1661. > ＜Q1＞ > Page23：4.6. Counters and Timers > Implementation Note: > The Restart timer SHOULD be based on the speed of the link. > The default value is designed for low speed (2,400 to 9,600 > bps), high switching latency links (typical telephone lines). > Higher speed links, or links with low switching latency, SHOULD > have correspondingly faster retransmission times. > > Instead of a constant value, the Restart timer MAY begin at an > initial small value and increase to the configured final value. > Each successive value less than the final value SHOULD be at > least twice the previous value. The initial value SHOULD be > large enough to account for the size of the packets, twice the > round trip time for transmission at the link speed, and at > least an additional 100 milliseconds to allow the peer to > process the packets before responding. Some circuits add > - - > another 200 milliseconds of satellite delay. Round trip times > for modems operating at 14,400 bps have been measured in the > range of 160 to more than 600 milliseconds. > > In this section, I don't know how to understand the structure of last > sentence. > "Round trip times for modems operating at 14,400 bps have been measured in > the range of 160 to more than 600 milliseconds." > "In the range of 160 to more than 600 milliseconds" points what? > I want to know the unit of 160 in this case. I guess 60 round trip times, does > it make sense? 160 milliseconds Craig > Could you let me know another expression of this sentence? > > I would be very grateful for help with any of these sentences. > Also, any good reference works for this type of stuff would be great. > Thank you very much in advance for any help. > > Sinserely, > Mitsuko Ozawa > > > >