From owner-ietf-ppp-outgoing@merit.edu Wed Aug 4 15:07:52 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 95E7D44476; Wed, 4 Aug 1999 15:07:43 -0400 (EDT) Received: from star.cirrus.com (star.cirrus.com [141.131.7.10]) by segue.merit.edu (Postfix) with ESMTP id 8179144584 for ; Wed, 4 Aug 1999 15:04:42 -0400 (EDT) Received: from ss563.corp.cirrus.com (ss563.corp.cirrus.com [141.131.8.55]) by star.cirrus.com (8.9.3/8.8.8) with ESMTP id MAA11303 for ; Wed, 4 Aug 1999 12:04:41 -0700 (PDT) Received: from u230-192.corp.cirrus.com (u230-192.corp.cirrus.com [141.131.68.232]) by ss563.corp.cirrus.com with SMTP id MAA01053 (8.7.5/IDA-1.6 for ); Wed, 4 Aug 1999 12:04:39 -0700 (PDT) Received: from ssu036.corp.cirrus.com by u230-192.corp.cirrus.com (SMI-8.6/Corp-2.20) id MAA21122; Wed, 4 Aug 1999 12:04:35 -0700 Received: by ssu036.corp.cirrus.com (SMI-8.6/Corp-2.20) id MAA20997; Wed, 4 Aug 1999 12:04:33 -0700 From: bhaveshp@corp.cirrus.com (Bhavesh Pathak - BasisComm) Message-Id: <199908041904.MAA20997@ssu036.corp.cirrus.com> Subject: using ML-PPP,BAP,BACP in PPP over ATM configuration To: ietf-ppp@merit.edu Date: Wed, 4 Aug 1999 12:04:33 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24alpha3] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Dear everyone, 1. I would like to know whether, following protocol stacking is permitted by the BAP/BACP standard? --------------------------- | ML-PPP along with BAP/BACP| | | ----------------------------- virtual | |virtual ppp_link1 | |ppp_link2 | | ----------------------------- | AAL-5 CPCS | | | ----------------------------- | |ATM layer output. 2. If above configuration is valid, whether people above support configuration in the product or not? bhavesh From owner-ietf-ppp-outgoing@merit.edu Tue Aug 10 07:16:28 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A6C4944469; Tue, 10 Aug 1999 07:16:27 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 023B34446E for ; Tue, 10 Aug 1999 07:16:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05065; Tue, 10 Aug 1999 07:16:23 -0400 (EDT) Message-Id: <199908101116.HAA05065@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-mib-05.txt Date: Tue, 10 Aug 1999 07:16:23 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --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' Management Information Base Author(s) : E. Caves, P. Calhoun, R. Wheeler Filename : draft-ietf-pppext-l2tp-mib-05.txt Pages : 68 Date : 09-Aug-99 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Layer 2 Tunneling Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-mib-05.txt Internet-Drafts are also 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-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-mib-05.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19990809094133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990809094133.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Tue Aug 10 12:12:14 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 93FA844475; Tue, 10 Aug 1999 12:12:14 -0400 (EDT) Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by segue.merit.edu (Postfix) with ESMTP id BA6A644470 for ; Tue, 10 Aug 1999 12:12:12 -0400 (EDT) Received: from gos.ukc.ac.uk ([129.12.21.64]) by mercury.ukc.ac.uk with smtp (Exim 2.12 #1) id 11EEVX-0004dG-00 for ietf-ppp@merit.edu; Tue, 10 Aug 1999 17:12:11 +0100 Received: from localhost by gos.ukc.ac.uk (SMI-8.6/UKC-2.14) id RAA25662; Tue, 10 Aug 1999 17:12:12 +0100 Date: Tue, 10 Aug 1999 17:12:12 +0100 (BST) From: "Ian Moy." To: ppp Subject: CCP negotiations. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi, Does anyone know if a win95 box can negotiate to use MPPE without negotiating to use MPPC? Also could a win95 box be setup to use STAC with MPPE? What about NT, can that use MPPE without MPPC? Any information on how to do this, if possible, would also be appreciated. Thanks in advance, Ian. From owner-ietf-ppp-outgoing@merit.edu Tue Aug 10 12:18:51 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 40FB644475; Tue, 10 Aug 1999 12:18:51 -0400 (EDT) Received: from cody.nlc.com (mail.nlc.com [209.204.132.12]) by segue.merit.edu (Postfix) with ESMTP id 656F644465 for ; Tue, 10 Aug 1999 12:18:49 -0400 (EDT) Received: from nlc_nt2.nlc.com (nlc_nt2 [10.0.0.76]) by cody.nlc.com (8.8.8/8.8.8) with ESMTP id JAA11013 for ; Tue, 10 Aug 1999 09:18:48 -0700 (PDT) Received: by NLC_NT2 with Internet Mail Service (5.5.2448.0) id ; Tue, 10 Aug 1999 09:18:52 -0700 Message-ID: From: "Kendall, Greg (NLC-EX)" To: "'ietf-ppp@merit.edu'" Subject: L2TP rev 16 question Date: Tue, 10 Aug 1999 09:18:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu In the L2TP spec, rev 16, section 4.3, it reads: Next, An MD5 hash is performed on the concatenation of: + the 2 octet Attribute number of the AVP + the shared secret + an arbitrary length random vector And later on says: Call the shared secret S, the Random Vector RV, and the Attribute Value AV. Break the value field into 16-octet chunks p1, p2, etc. ... b1 = MD5(AV + S + RV) c(1) = p1 xor b1 I'm presuming that, in the second part, it should be "the Attribute Number AV", can anybody verify or refute that? From owner-ietf-ppp-outgoing@merit.edu Tue Aug 10 12:31:53 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 228D144476; Tue, 10 Aug 1999 12:31:53 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id 9C60944475 for ; Tue, 10 Aug 1999 12:31:51 -0400 (EDT) Received: from bluegill ([216.28.121.202]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAAF1; Tue, 10 Aug 1999 12:31:51 -0400 Message-Id: <4.2.0.58.19990810122716.04e353c0@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 10 Aug 1999 12:31:45 -0400 To: ietf-ppp@merit.edu From: "Karl Fox" Subject: L2TP MIB - Working Group Last Call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is last call. I will advise the area directors that we want to take Layer Two Tunneling Protocol 'L2TP' Management Information Base (draft-ietf-pppext-l2tp-mib-05.txt) to Proposed Standard on August 25, 1999 unless there is substantive comment raised on the list. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Tue Aug 10 14:29:33 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 573034447D; Tue, 10 Aug 1999 14:29:33 -0400 (EDT) Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by segue.merit.edu (Postfix) with ESMTP id E85B64447A for ; Tue, 10 Aug 1999 14:29:31 -0400 (EDT) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id LAA25054; Tue, 10 Aug 1999 11:28:53 -0700 (PDT) From: Archie Cobbs Message-Id: <199908101828.LAA25054@bubba.whistle.com> Subject: Re: CCP negotiations. In-Reply-To: from "Ian Moy." at "Aug 10, 1999 05:12:12 pm" To: ism1@ukc.ac.uk (Ian Moy.) Date: Tue, 10 Aug 1999 11:28:53 -0700 (PDT) Cc: ietf-ppp@merit.edu (ppp) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Ian Moy. writes: > Does anyone know if a win95 box can negotiate to use MPPE without > negotiating to use MPPC? Yes, it can. > Also could a win95 box be setup to use STAC with MPPE? Not sure.. try it! > What about NT, can that use MPPE without MPPC? Yes NT can too. > Any information on how to do this, if possible, would also be appreciated. You have to have your server NAK the CCP config-request in such a way that it turns off the compression bits. See also ftp://ftp.whistle.com/pub/archie/mpd/mpd-2.0b2.tar.gz for an example of how to do this (sorry, it doesn't contain the actual encryption or compression code of course due to their patent/proprietary nature.. ) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From owner-ietf-ppp-outgoing@merit.edu Thu Aug 12 16:49:51 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B81A344627; Thu, 12 Aug 1999 16:49:23 -0400 (EDT) Received: from ntmail.2wire.com (unknown [209.247.193.10]) by segue.merit.edu (Postfix) with ESMTP id F28F244607 for ; Thu, 12 Aug 1999 16:29:29 -0400 (EDT) Received: by NTMAIL with Internet Mail Service (5.5.2448.0) id ; Thu, 12 Aug 1999 13:30:14 -0700 Message-ID: <215A9DD55241D311887800C04F47D1B3014D38@NTMAIL> From: Randy Turner To: "'ietf-ppp@segue.merit.edu'" Subject: subnet allocation request Date: Thu, 12 Aug 1999 13:30:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Awhile back, someone issued a draft that specified IPCP functionality to allocate a subnet with a fixed number of addresses. Unlike the current DHCP proposal that requests a specific subnet, the previous IPCP proposal I believe had the capability to just request a subnet of a certain size and was agnostic to the subnet that was selected. At some point after submission of this draft, it was decided that this functionality should be better taken up by the DHCP WG, and I believe the draft was left to expire. To date, I don't believe anyone else has made such a request in this group or the DHCP group, but I would like confirmation that this is the correct history regarding this draft before I take the time to draw one up myself. If anyone has any other information on this proposal, please let me know. Thanks in advance! Randy Randy Turner 2Wire, Inc. rturner@2wire.com From owner-ietf-ppp-outgoing@merit.edu Thu Aug 12 18:28:11 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9010C44605; Thu, 12 Aug 1999 18:28:11 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id E845144603 for ; Thu, 12 Aug 1999 18:28:09 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id QAA01750 env-from ; Thu, 12 Aug 1999 16:28:08 -0600 (MDT) Date: Thu, 12 Aug 1999 16:28:08 -0600 (MDT) From: Vernon Schryver Message-Id: <199908122228.QAA01750@calcite.rhyolite.com> To: ietf-ppp@merit.edu, rturner@2wire.com Subject: Re: subnet allocation request Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Randy Turner > To: "'ietf-ppp@segue.merit.edu'" > At some point after submission of this draft, it was decided that this > functionality should be better taken up by the DHCP WG, and I believe the > draft was left to expire. To date, I don't believe anyone else has made such > a request in this group or the DHCP group, but I would like confirmation > that this is the correct history regarding this draft before I take the time > to draw one up myself. > ... I really hope the proposed draft is for DHCP and not PPP. PPP stands for "point-to-point." It makes *NO SENSE* to talk about blocks of IP addresses in the context of a point-to-point link. To points need at most 2 IP addresses. It is *WRONG* to stuff all of the upper layers in the link layer, including routing (e.g. this IP block allocating), naming (e.g. the Microsoft DNS server mistake), and the rest of the kitchen sink. That PPP and IPCP have extension mechanisms no excuse for using them for things that have nothing to do with PPP or the IP link between a pair of peers. It might be ok to jam unrelated stuff into PPP if there were no available (not to mention at least as convenient) alternatives. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Thu Aug 12 23:20:22 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 68FCA44627; Thu, 12 Aug 1999 23:20:19 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id C2C8F44625 for ; Thu, 12 Aug 1999 23:20:17 -0400 (EDT) Received: from bluegill ([209.116.97.146]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA192C; Thu, 12 Aug 1999 23:20:17 -0400 Message-Id: <4.2.0.58.19990812231739.00ce4970@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 12 Aug 1999 23:20:13 -0400 To: Vernon Schryver , ietf-ppp@merit.edu, rturner@2wire.com From: "Karl Fox" Subject: Re: subnet allocation request In-Reply-To: <199908122228.QAA01750@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Randy, Vernon is right--the consensus of this working group has long been that such upper layer features belong in DHCP, which is designed to handle exactly this sort of thing. Karl Fox PPPEXT Working Group Chair At 04:28 PM 8/12/99 -0600, Vernon Schryver wrote: > > From: Randy Turner > > To: "'ietf-ppp@segue.merit.edu'" > > > At some point after submission of this draft, it was decided that this > > functionality should be better taken up by the DHCP WG, and I believe the > > draft was left to expire. To date, I don't believe anyone else has made such > > a request in this group or the DHCP group, but I would like confirmation > > that this is the correct history regarding this draft before I take the time > > to draw one up myself. > > ... > >I really hope the proposed draft is for DHCP and not PPP. > >PPP stands for "point-to-point." It makes *NO SENSE* to talk about blocks >of IP addresses in the context of a point-to-point link. To points need >at most 2 IP addresses. It is *WRONG* to stuff all of the upper layers >in the link layer, including routing (e.g. this IP block allocating), >naming (e.g. the Microsoft DNS server mistake), and the rest of the kitchen >sink. That PPP and IPCP have extension mechanisms no excuse for using >them for things that have nothing to do with PPP or the IP link between >a pair of peers. It might be ok to jam unrelated stuff into PPP if there >were no available (not to mention at least as convenient) alternatives. > > >Vernon Schryver vjs@rhyolite.com Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Fri Aug 13 00:02:38 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E3C7F4463F; Fri, 13 Aug 1999 00:02:37 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by segue.merit.edu (Postfix) with ESMTP id E10B64463C for ; Fri, 13 Aug 1999 00:02:35 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id HAA15256; Fri, 13 Aug 1999 07:02:32 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14259.39127.733665.902455@lohi.eng.telia.fi> Date: Fri, 13 Aug 1999 07:02:31 +0300 (EEST) To: Randy Turner Cc: "'ietf-ppp@segue.merit.edu'" Subject: subnet allocation request In-Reply-To: <215A9DD55241D311887800C04F47D1B3014D38@NTMAIL> References: <215A9DD55241D311887800C04F47D1B3014D38@NTMAIL> X-Mailer: VM 6.71 under Emacs 19.34.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu randy, i wrote the i-d and the idea was like you described, i.e., the ppp client could ask during the ipcp negotiation phase a subnet of a certain (possibly any) size instead of a single ip address. the "consensus" of the wg was that ipcp is not the right means to negotiate the subnet, but that bootp or dhcp inform should be used instead and since there already exists a subnet option both in boopt and dhcp, nothing was left to be standardized. what has happened in practice though is that some (adsl) router vendors actually went and implemented an ipcp subnet option and i'm very happy about it, since it solves my real problem. if some vendors come up with the bootp or dhcp solution, that would be fine with me too, since i don't care how the problem is solved as long as it is done. just for information (if someone plans to sell adsl equipment to me), below is the packet format of the ipcp subnet option that is currently implemented in my network. -- juha ------------------------------------------------------------------ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Mask +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mask (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where Type = 0x90 and Length = 0x06. From owner-ietf-ppp-outgoing@merit.edu Fri Aug 13 00:48:25 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7547F4467E; Fri, 13 Aug 1999 00:48:25 -0400 (EDT) Received: from ntmail.2wire.com (unknown [209.247.193.10]) by segue.merit.edu (Postfix) with ESMTP id CEB864467B for ; Fri, 13 Aug 1999 00:48:23 -0400 (EDT) Received: by NTMAIL with Internet Mail Service (5.5.2448.0) id ; Thu, 12 Aug 1999 21:49:10 -0700 Message-ID: <215A9DD55241D311887800C04F47D1B3014D3D@NTMAIL> From: Randy Turner To: 'Juha Heinanen' Cc: "'ietf-ppp@segue.merit.edu'" Subject: RE: subnet allocation request Date: Thu, 12 Aug 1999 21:49:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thanks for the replies, I will work with whoever is interested to see that an extension like the one I described is advanced through the DHCP WG. The existing subnet option in DHCP would not meet my requirements, since I really don't want to specify up front what subnet I want to use. Instead, I would like the DHCP server to figure out an available subnet and allocate it to me. If anyone is interested and has similar requirements, I would appreciate your comments on how this option should operate. I will subsequently move this discussion to the DHCP WG. Thanks again, Randy > -----Original Message----- > From: Juha Heinanen [SMTP:jh@lohi.eng.telia.fi] > Sent: Thursday, August 12, 1999 9:03 PM > To: Randy Turner > Cc: 'ietf-ppp@segue.merit.edu' > Subject: subnet allocation request > > randy, > > i wrote the i-d and the idea was like you described, i.e., the ppp > client could ask during the ipcp negotiation phase a subnet of a certain > (possibly any) size instead of a single ip address. the "consensus" of > the wg was that ipcp is not the right means to negotiate the subnet, but > that bootp or dhcp inform should be used instead and since there already > exists a subnet option both in boopt and dhcp, nothing was left to be > standardized. > > what has happened in practice though is that some (adsl) router vendors > actually went and implemented an ipcp subnet option and i'm very happy > about it, since it solves my real problem. if some vendors come up with > the bootp or dhcp solution, that would be fine with me too, since i > don't care how the problem is solved as long as it is done. > > just for information (if someone plans to sell adsl equipment to me), > below is the packet format of the ipcp subnet option that is currently > implemented in my network. > > -- juha > ------------------------------------------------------------------ > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Mask > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Mask (cont) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > where Type = 0x90 and Length = 0x06. From owner-ietf-ppp-outgoing@merit.edu Fri Aug 13 00:48:51 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 73EAA44682; Fri, 13 Aug 1999 00:48:51 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id E9DDE4467E for ; Fri, 13 Aug 1999 00:48:49 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id WAA11514 for ietf-ppp@merit.edu env-from ; Thu, 12 Aug 1999 22:48:49 -0600 (MDT) Date: Thu, 12 Aug 1999 22:48:49 -0600 (MDT) From: Vernon Schryver Message-Id: <199908130448.WAA11514@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: subnet allocation request Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Juha Heinanen > ... > just for information (if someone plans to sell adsl equipment to me), > below is the packet format of the ipcp subnet option that is currently > implemented in my network. > ... > where Type = 0x90 and Length = 0x06. Does whoever stole type IPCP 0x90 also allocate random IP addresses? (and I don't mean out of RFC 1918). Do they also run their own DNS root and use whatever names that seem cool? How about IP protocol numbers? Why don't we just disband the IANA? Who needs it? Everyone can just pick random numbers and everything will work just fine. Personally, I wouldn't want my name associated with a thing like that, certainly not such positive words. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Fri Aug 13 01:03:32 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0F72F4440B; Fri, 13 Aug 1999 01:03:32 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by segue.merit.edu (Postfix) with ESMTP id 0A8BB44401 for ; Fri, 13 Aug 1999 01:03:30 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id IAA15377; Fri, 13 Aug 1999 08:03:27 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14259.42783.202615.965102@lohi.eng.telia.fi> Date: Fri, 13 Aug 1999 08:03:27 +0300 (EEST) To: Randy Turner Cc: "'ietf-ppp@segue.merit.edu'" Subject: RE: subnet allocation request In-Reply-To: <215A9DD55241D311887800C04F47D1B3014D3D@NTMAIL> References: <215A9DD55241D311887800C04F47D1B3014D3D@NTMAIL> X-Mailer: VM 6.71 under Emacs 19.34.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Randy Turner writes: > I will work with whoever is interested to see that an extension like the one > I described is advanced through the DHCP WG. The existing subnet option in > DHCP would not meet my requirements, since I really don't want to specify up > front what subnet I want to use. Instead, I would like the DHCP server to > figure out an available subnet and allocate it to me. If anyone is > interested and has similar requirements, I would appreciate your comments on > how this option should operate. in the simple adsl case that i have, the subscriber has subscribed to a subnet of a certain size, so the isp router knows from which subnet pool to allocate the ip address using during ipcp negotiation. once the cpe router has got the ip address, it then used bootp or dhcp inform to figure out, what to configure as its subnet mask. the situation would be different if the subscriber would be allowed to dynamically ask a subnet of a given size. in that case, the ip address and the subnet mask would be need to be negotatiated at the same time and the above solution would not work. -- juha From owner-ietf-ppp-outgoing@merit.edu Fri Aug 13 07:01:58 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6DBFE4440C; Fri, 13 Aug 1999 07:01:58 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 7736A44407 for ; Fri, 13 Aug 1999 07:01:56 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16190; Fri, 13 Aug 1999 07:01:53 -0400 (EDT) Message-Id: <199908131101.HAA16190@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eaptls-06.txt Date: Fri, 13 Aug 1999 07:01:52 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --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 : PPP EAP TLS Authentication Protocol Author(s) : B. Aboba, D. Simon Filename : draft-ietf-pppext-eaptls-06.txt Pages : 25 Date : 12-Aug-99 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which can be used to negotiate authentication methods, as well as an Encryption Control Protocol (ECP), used to negotiate data encryption over PPP links, and a Compression Control Protocol (CCP), used to negotiate compression methods. The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-eaptls-06.txt Internet-Drafts are also 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-eaptls-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eaptls-06.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19990812123900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eaptls-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eaptls-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990812123900.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Fri Aug 13 11:07:12 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A502244429; Fri, 13 Aug 1999 11:07:11 -0400 (EDT) Received: from hawk.prod.itd.earthlink.net (hawk.prod.itd.earthlink.net [207.217.120.22]) by segue.merit.edu (Postfix) with ESMTP id F1C9544426 for ; Fri, 13 Aug 1999 11:07:09 -0400 (EDT) Received: from 2wire.com (dialup-209.245.137.211.SanJose1.Level3.net [209.245.137.211]) by hawk.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id IAA21026; Fri, 13 Aug 1999 08:07:07 -0700 (PDT) Message-ID: <37B43A40.98256FC3@2wire.com> Date: Fri, 13 Aug 1999 08:31:13 -0700 From: Randy Turner Organization: 2Wire, Inc. X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Bray Cc: ietf-ppp@merit.edu Subject: Re: subnet allocation request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu My interpretation of section 2 of the "Subnet Selection Option for DHCP" draft implies that the DHCP server must return a subnet based upon the base address that the "client specifies" in the request. Basically, all I would like to specify in the request is "Please allocate me a /30 subnet. I don't really care the specific prefix that is used". Randy John Bray wrote: > On Thu, 12 Aug 1999, Randy Turner wrote: > > > > > Thanks for the replies, > > > > I will work with whoever is interested to see that an extension like the one > > I described is advanced through the DHCP WG. The existing subnet option in > > DHCP would not meet my requirements, since I really don't want to specify up > > front what subnet I want to use. Instead, I would like the DHCP server to > > figure out an available subnet and allocate it to me. If anyone is > > interested and has similar requirements, I would appreciate your comments on > > how this option should operate. > > I'm sorry, I must have missed something. Since when does a DHCP > client "specify up front" the subnet it wants to use? This option > (along with other configuration paramters) is returned by the server > to the client in the DHCP reply. > > Please explain again why this doesn't meet your needs. > > John > > > > > I will subsequently move this discussion to the DHCP WG. > > > > Thanks again, > > Randy > > > > > > > > > > > -----Original Message----- > > > From: Juha Heinanen [SMTP:jh@lohi.eng.telia.fi] > > > Sent: Thursday, August 12, 1999 9:03 PM > > > To: Randy Turner > > > Cc: 'ietf-ppp@segue.merit.edu' > > > Subject: subnet allocation request > > > > > > randy, > > > > > > i wrote the i-d and the idea was like you described, i.e., the ppp > > > client could ask during the ipcp negotiation phase a subnet of a certain > > > (possibly any) size instead of a single ip address. the "consensus" of > > > the wg was that ipcp is not the right means to negotiate the subnet, but > > > that bootp or dhcp inform should be used instead and since there already > > > exists a subnet option both in boopt and dhcp, nothing was left to be > > > standardized. > > > > > > what has happened in practice though is that some (adsl) router vendors > > > actually went and implemented an ipcp subnet option and i'm very happy > > > about it, since it solves my real problem. if some vendors come up with > > > the bootp or dhcp solution, that would be fine with me too, since i > > > don't care how the problem is solved as long as it is done. > > > > > > just for information (if someone plans to sell adsl equipment to me), > > > below is the packet format of the ipcp subnet option that is currently > > > implemented in my network. > > > > > > -- juha > > > ------------------------------------------------------------------ > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type | Length | Mask > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Mask (cont) | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > where Type = 0x90 and Length = 0x06. > > From owner-ietf-ppp-outgoing@merit.edu Fri Aug 13 11:52:58 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 572554463D; Fri, 13 Aug 1999 11:52:52 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 565B9445C2 for ; Fri, 13 Aug 1999 11:45:39 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id JAA22562 env-from ; Fri, 13 Aug 1999 09:45:36 -0600 (MDT) Date: Fri, 13 Aug 1999 09:45:36 -0600 (MDT) From: Vernon Schryver Message-Id: <199908131545.JAA22562@calcite.rhyolite.com> To: bray@cisco.com, rturner@2wire.com Subject: Re: subnet allocation request Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Randy Turner > To: John Bray > Cc: ietf-ppp@merit.edu > My interpretation of section 2 of the "Subnet Selection Option for DHCP" draft > implies that the DHCP server must return a subnet based upon the base address that > the "client specifies" in the request. Basically, all I would like to specify in > the request is "Please allocate me a /30 subnet. I don't really care the specific > prefix that is used". But don't you need or at least prefer a block that includes the IP address that your system has negotiated by using IPCP? If you get a /30 that is completely unrelated to the IP address of your end of the PPP link, things will at least seem a little more complicated. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Thu Aug 19 07:06:54 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7AA4A444FF; Thu, 19 Aug 1999 07:06:54 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 86A35444F9 for ; Thu, 19 Aug 1999 07:06:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21460; Thu, 19 Aug 1999 07:06:50 -0400 (EDT) Message-Id: <199908191106.HAA21460@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-security-04.txt Date: Thu, 19 Aug 1999 07:06:50 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --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 : Securing L2TP using IPSEC Author(s) : B. Patel, B. Aboba, W. Dixon Filename : draft-ietf-pppext-l2tp-security-04.txt Pages : 14 Date : 18-Aug-99 This document discusses how L2TP may utilize IPSEC to provide for tunnel authentication, privacy protection, integrity check and replay protection. Both the voluntary and compulsory tunneling cases are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-security-04.txt Internet-Drafts are also 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-security-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-security-04.txt". NOTE: The mail server at ietf.org 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@ietf.org" Content-Type: text/plain Content-ID: <19990818113158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-security-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-security-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990818113158.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Mon Aug 23 18:09:56 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0FA8F44419; Mon, 23 Aug 1999 18:09:56 -0400 (EDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by segue.merit.edu (Postfix) with ESMTP id 9B0D444401 for ; Mon, 23 Aug 1999 18:09:54 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.132.204]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA35648 for ; Mon, 23 Aug 1999 18:09:30 -0400 Received: from cable345 (DIP005899END.endicott.ibm.com [9.130.69.192]) by westrelay01.boulder.ibm.com (8.8.8m2/NCO v2.04) with SMTP id QAA69394; Mon, 23 Aug 1999 16:09:52 -0600 Message-ID: <000101beedb4$36c79be0$c0458209@us.ibm.com> From: "John R. Martz" To: Subject: Usage of ML Endpoint Discriminator Option Date: Mon, 23 Aug 1999 18:08:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Folks, I think my brains are not working correctly because I'm not understanding some of section 5.1.3 "Endpoint Discriminator Option" in RFC 1990. Hope by posting my questions to this list some kind soul will help out. First question: What should an implementation do if it receives the Endpoint Discriminator Option but does NOT receive the MRRU option? RFC1990 says that "the implementation MUST NOT assume that multilink operation is being requested on this basis alone". Well why not?? I'm a bit confused at this point as to when/how an implementation knows a link can be part of a multilink bundle and when it knows a link can NOT be part of a bundle. (Probably doesn't matter in typical connect scenarios ... but figure it's best to ask and learn). Second question: What is RFC1990 asking an implementation to do for scenario (1), "no authentication, no discriminator". The text reads: "All new links MUST be joined to one bundle, unless there is manual configuration to the contrary. It is also permissible to have more than one manually configured bundle connecting two given systems". Does this mean there is supposedly a "default bundle" to which all new links that negotiate an MRRU but nothing else to identify the list are implicitly joined? Or does it mean that the link is considered to part of a "bundle" of one and only 1 link? Also, I don't think I understand what is a "manually configured bundle connecting two given systems". (Can anyone provide me with or point me towards an example?) Thanks for you patience in reading this. Hope someone will be able to set me straight. -john martz (jmartz@us.ibm.com) IBM AS/400 TCP/IP PPP (and stuff) From owner-ietf-ppp-outgoing@merit.edu Tue Aug 24 08:32:35 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 687C94445F; Tue, 24 Aug 1999 08:32:35 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id BCF4D44450 for ; Tue, 24 Aug 1999 08:32:33 -0400 (EDT) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id IAA18673 for ietf-ppp@merit.edu; Tue, 24 Aug 1999 08:32:33 -0400 (EDT) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: Usage of ML Endpoint Discriminator Option Date: 24 Aug 1999 08:32:33 -0400 Organization: IronBridge Networks Lines: 70 Message-ID: <86hflpcqam.fsf@ironbridgenetworks.com> References: <000101beedb4$36c79be0$c0458209@us.ibm.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu jmartz@us.ibm.com ("John R. Martz") writes: > First question: What should an implementation do if it receives the > Endpoint Discriminator Option but does NOT receive the MRRU option? Nothing. Some implementations will Configure-Reject it, others will Configure-Ack it. In either case, it doesn't enable MP, and doesn't do anything special to the link. (Personally, I prefer to send LCP Configure-Ack, since it leads to faster convergence. More conservative implementations might Configure-Reject it to avoid triggering MP-related bugs in their peers.) > RFC1990 says that "the implementation MUST NOT assume that multilink > operation is being requested on this basis alone". Right. MRRU enables MP. The ED is just an unauthenticated identifier. In fact, an implementation could view it as logically concatenated with the PAP/CHAP Peer-ID for validation purposes. (Although this would lead to failures in practice if the hardware at one end were replaced.) > Well why not?? I'm a bit confused at this point as to when/how an > implementation knows a link can be part of a multilink bundle and > when it knows a link can NOT be part of a bundle. (Probably doesn't > matter in typical connect scenarios ... but figure it's best to ask > and learn). For simplicity, there needs to be exactly one switch to enable or disable MP on a link. MRRU was chosen as that switch. > Second question: What is RFC1990 asking an implementation to do for > scenario (1), "no authentication, no discriminator". > > The text reads: "All new links MUST be joined to one bundle, unless > there is manual configuration to the contrary. It is also > permissible to have more than one manually configured bundle > connecting two given systems". > > Does this mean there is supposedly a "default bundle" to which all > new links that negotiate an MRRU but nothing else to identify the > list are implicitly joined? Yes. Exactly. > Or does it mean that the link is considered to part of a "bundle" of > one and only 1 link? Also, I don't think I understand what is a > "manually configured bundle connecting two given systems". (Can > anyone provide me with or point me towards an example?) It could be an explicit list provided by an operator specifying that ports, 1, 2, and 7 (say) are all a single bundle, and that ports 3 through 6 are another bundle. You would do this if you had some kind of reliable indication that the links are actually connected to the peers intended. For instance, if it's a set of physical cables between two boxes and the cables are under your control, you might forego authentication, but still want MP. Note that "manually configured" might also involve external information -- such as calling party numbers on an ISDN line -- but that's outside the scope of the specification. (Scenario 1 is rather marginal; it's generally not used in practice except with conformance tests. ;-}) -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 03:19:08 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B92A54441E; Wed, 25 Aug 1999 03:19:07 -0400 (EDT) Received: from mail-gw6.pacbell.net (mail-gw6.pacbell.net [206.13.28.41]) by segue.merit.edu (Postfix) with ESMTP id E180F44417 for ; Wed, 25 Aug 1999 03:18:54 -0400 (EDT) Received: from pacbell.net (adsl-63-193-114-250.dsl.snfc21.pacbell.net [63.193.114.250]) by mail-gw6.pacbell.net (8.9.3/8.9.3) with ESMTP id AAA18414; Wed, 25 Aug 1999 00:18:51 -0700 (PDT) Message-ID: <37C39951.83F7D2E5@pacbell.net> Date: Wed, 25 Aug 1999 00:21:01 -0700 From: Clara McKenzie X-Mailer: Mozilla 4.51 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "John R. Martz" Cc: ietf-ppp@merit.edu Subject: Re: Usage of ML Endpoint Discriminator Option References: <000101beedb4$36c79be0$c0458209@us.ibm.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi John et al, "John R. Martz" wrote: > > First question: What should an implementation do if it receives the Endpoint Discriminator Option > but does NOT receive the MRRU option? I always just Configure-ACK it - it's just a point of information. > > > RFC1990 says that "the implementation MUST NOT assume that multilink operation is being requested on > this basis alone". > > Well why not?? I'm a bit confused at this point as to when/how an implementation knows a link can be > part of a multilink bundle and when it knows a link can NOT be part of a bundle. (Probably doesn't > matter in typical connect scenarios ... but figure it's best to ask and learn). If you have not been given an endpoint discriminator, you can assign one based on the login name. Here's my reading of the bundling rules. RFC1990 5.1.3: >As there is also no requirement for authentication, there are four > sets of scenarios: > (1) No authentication, no discriminator: > All new links MUST be joined to one bundle, unless > there is manual configuration to the contrary. > It is also permissible to have more than one manually > configured bundle connecting two given systems. An example would be (and here's where that manual configuration clause comes in) could be a no-auth connection, but one that is identifiable by Called-Number or Calling-Number, you could assign the Called or Calling Number as the bundle identifier. > (2) Discriminator, no authentication: > Discriminator match -> MUST join matching bundle, > discriminator mismatch -> MUST establish new bundle. no-auth connections are not "typical" but if there is no auth and the endpoints discriminators are identified to you as the same then they can join the bundle. If you have additional information about the calls that suggest to you that they shouldn't join (such as the Called Numbers are different and you are identifying or "authenticating" via Called Numbers), then you can but them in separate bundles. > (3) No discriminator, authentication: > Authenticated match -> MUST join matching bundle, > authenticated mismatch -> MUST establish new bundle. Since authentication is the only identifier here, this makes sense. > (4) Discriminator, authentication: > Discriminator match and authenticated match -> MUST join bundle, > discriminator mismatch -> MUST establish new bundle, > authenticated mismatch -> MUST establish new bundle. No problem here either, if both as present, both must match. > > > Second question: What is RFC1990 asking an implementation to do for scenario (1), "no > authentication, no discriminator". > > The text reads: "All new links MUST be joined to one bundle, unless there is manual configuration to > the contrary. It is also permissible to have more than one manually configured bundle connecting two > given systems". > > Does this mean there is supposedly a "default bundle" to which all new links that negotiate an MRRU > but nothing else to identify the list are implicitly joined? As noted before, you are able to identify the links by whatever means available, not just negotiated values. > Or does it mean that the link is > considered to part of a "bundle" of one and only 1 link? Each link is part of one bundle. > Also, I don't think I understand what is a > "manually configured bundle connecting two given systems". (Can anyone provide me with or point me > towards an example?) If I login as "clara", the system looks up my connection information based on "clara". That is essentially manual configuration. The conneciton information lookup could also have been based on my Calling-Number, the Called-Number, or even based on my negotiated IP Address. All examples of manual configuration. > > > Thanks for you patience in reading this. Hope someone will be able to set me straight. > > -john martz (jmartz@us.ibm.com) > IBM AS/400 TCP/IP PPP (and stuff) Hope I didn't make it worse! Clara McKenzie klara@pacbell.net From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 03:57:08 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 95B2A44453; Wed, 25 Aug 1999 03:57:07 -0400 (EDT) Received: from relay.conware.de (relay.conware.de [153.92.5.3]) by segue.merit.edu (Postfix) with SMTP id 310D34441E for ; Wed, 25 Aug 1999 03:57:05 -0400 (EDT) Received: from gin.conware.de [153.92.64.18] (kummert) by relay.conware.de with esmtp (Exim 1.624 #1) id 11JXzI-0001OT-00; Wed, 25 Aug 1999 10:00:52 +0200 Content-Length: 1923 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) In-Reply-To: <86hflpcqam.fsf@ironbridgenetworks.com> Date: Wed, 25 Aug 1999 09:56:52 +0200 (MEST) Organization: Nentec GmbH From: Holger Kummert To: James Carlson Subject: Re: Usage of ML Endpoint Discriminator Option Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On 24-Aug-99 James Carlson wrote: > jmartz@us.ibm.com ("John R. Martz") writes: [...] >> Well why not?? I'm a bit confused at this point as to when/how an >> implementation knows a link can be part of a multilink bundle and >> when it knows a link can NOT be part of a bundle. (Probably doesn't >> matter in typical connect scenarios ... but figure it's best to ask >> and learn). > > For simplicity, there needs to be exactly one switch to enable or > disable MP on a link. MRRU was chosen as that switch. > In reading rcc1990 that is not so clear to me. Maybe it's intended when you "read between the lines", but what I found was (as was pointed out before): 5.1.3. Endpoint Discriminator Option [...] the implementation MUST NOT assume that multilink operation is being requested on this basis alone. So MRRU and ED together will be accepted to negotiate MP. Another hint is in 11.1. Negotiating Multilink, per se RFC 1717 permitted either the use of the Short Sequence Number Header Format (SSNHF) or the Maximum Reconstructed Receive Unit (MRRU) options by themselves to indicate the intent to negotiate multilink. This specification forbids the use of the SSNHF option by itself; but does permit the specific of both options together. So MRRU and SSN together will also do. So we decided in our PPP-implementation to accept a link to join (or create) a bundle only when MRRU and one of SSN or ED is negotiated. Is that correct? Holger > -- > James Carlson, System Architect > IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 > Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 > "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp -- Holger Kummert Phone: +49 721 9495-135 Nentec Netzwerktechnologie GmbH WWW: http://www.nentec.de/ From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 08:38:32 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EE2B344460; Wed, 25 Aug 1999 08:38:31 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id DE5B94440E for ; Wed, 25 Aug 1999 08:38:29 -0400 (EDT) Received: (from carlson@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id IAA09530; Wed, 25 Aug 1999 08:38:24 -0400 (EDT) Date: Wed, 25 Aug 1999 08:38:24 -0400 (EDT) Message-Id: <199908251238.IAA09530@ironbridgenetworks.com> X-Authentication-Warning: helios.helios: carlson set sender to carlson@ironbridgenetworks.com using -f From: James Carlson To: kummert@nentec.de Cc: ietf-ppp@merit.edu In-reply-to: (message from Holger Kummert on Wed, 25 Aug 1999 09:56:52 +0200 (MEST)) Subject: Re: Usage of ML Endpoint Discriminator Option References: Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > > For simplicity, there needs to be exactly one switch to enable or > > disable MP on a link. MRRU was chosen as that switch. > > > > In reading rcc1990 that is not so clear to me. Maybe it's intended when > you "read between the lines", but what I found was (as was pointed > out before): I agree that the wording makes this less than clear, but my original reply was correct. There is only one switch that turns on MP -- it is the MRRU. You can certainly use the other options *with* the MRRU when using MP. But none of them enable MP. > So MRRU and ED together will be accepted to negotiate MP. > Another hint is in Sure. ED is accepted. So are Protocol Field Compression and Address and Control Field Compression. None of these, though, enable multilink operation. > So MRRU and SSN together will also do. > So we decided in our PPP-implementation to accept a link to join (or > create) a bundle only when MRRU and one of SSN or ED is negotiated. > Is that correct? No. MRRU alone does the job. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 10:20:23 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DF49F44463; Wed, 25 Aug 1999 10:20:22 -0400 (EDT) Received: from relay.conware.de (relay.conware.de [153.92.5.3]) by segue.merit.edu (Postfix) with SMTP id 40CF444461 for ; Wed, 25 Aug 1999 10:20:20 -0400 (EDT) Received: from gin.conware.de [153.92.64.18] (kummert) by relay.conware.de with esmtp (Exim 1.624 #1) id 11Jdxy-0001hm-00; Wed, 25 Aug 1999 16:23:54 +0200 Content-Length: 867 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199908251238.IAA09530@ironbridgenetworks.com> Date: Wed, 25 Aug 1999 16:19:58 +0200 (MEST) Organization: Nentec GmbH From: Holger Kummert To: James Carlson , karl@extant.net Subject: Re: Usage of ML Endpoint Discriminator Option Cc: ietf-ppp@merit.edu Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On 25-Aug-99 James Carlson wrote: >> > For simplicity, there needs to be exactly one switch to enable or >> > disable MP on a link. MRRU was chosen as that switch. >> > >> >> In reading rcc1990 that is not so clear to me. Maybe it's intended when >> you "read between the lines", but what I found was (as was pointed >> out before): > > I agree that the wording makes this less than clear, but my original > reply was correct. There is only one switch that turns on MP -- it is > the MRRU. You can certainly use the other options *with* the MRRU > when using MP. But none of them enable MP. > So I would recommend that we make this more clear when rfc1990 will be revised (for standard, when I remember correctly). Holger -- Holger Kummert Phone: +49 721 9495-135 Nentec Netzwerktechnologie GmbH WWW: http://www.nentec.de/ From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 10:23:20 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9649644463; Wed, 25 Aug 1999 10:23:20 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by segue.merit.edu (Postfix) with ESMTP id 495F444410 for ; Wed, 25 Aug 1999 10:23:19 -0400 (EDT) Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA38888 for ; Wed, 25 Aug 1999 10:22:54 -0400 Received: from jmartz (lig32-224-38-84.us.lig-dial.ibm.com [32.224.38.84]) by southrelay01.raleigh.ibm.com (8.8.8m2/NCO v2.04) with SMTP id KAA30686; Wed, 25 Aug 1999 10:22:38 -0400 Message-ID: <002c01beef05$5b1c2a40$0300a8c0@us.ibm.com> From: "John R. Martz" To: References: <000101beedb4$36c79be0$c0458209@us.ibm.com> <37C39951.83F7D2E5@pacbell.net> Subject: Re: Usage of ML Endpoint Discriminator Option Date: Wed, 25 Aug 1999 10:22:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Folks, Thanks much for your responses. The "default bundle" scenario makes me nervous. I'm not sure it's something my customers would really want chosen for them as the default. I'm considering limiting my implementation to not allow scenario (1) multilink unless a customer explicitly manually configures to allow it. Perhaps something like a "Require remote link identification to enable multlink" checkbox. The default would be to have this "checked" and the customer would have to uncheck it to get scenario (1) behavior. My impression is this is a valid RFC 1990 compliant implementation choice. Anyone disagree? Clara's ideas about using the called or calling phone numbers to limit the scope of a "default bundle" are interesting alternatives too. Thanks, -john martz (jmartz@us.ibm.com) IBM AS/400 TCP/IP PPP (and stuff) From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 10:36:08 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5A56D44464; Wed, 25 Aug 1999 10:36:08 -0400 (EDT) Received: from obiwan.intecom.com (obiwan.intecom.com [198.242.17.70]) by segue.merit.edu (Postfix) with ESMTP id 24F5044463 for ; Wed, 25 Aug 1999 10:36:07 -0400 (EDT) Message-ID: <882866C049DED211AE830008C7394A10338D1A@obiwan.intecom.com> From: "Millen, Bob" To: ietf-ppp@merit.edu Subject: Remove from list Date: Wed, 25 Aug 1999 09:37:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Please remove from list. bmillen@intecom.com From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 11:04:33 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A56B84445F; Wed, 25 Aug 1999 11:04:32 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id C9CF74442E for ; Wed, 25 Aug 1999 11:04:30 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id JAA09626 for ietf-ppp@merit.edu env-from ; Wed, 25 Aug 1999 09:04:30 -0600 (MDT) Date: Wed, 25 Aug 1999 09:04:30 -0600 (MDT) From: Vernon Schryver Message-Id: <199908251504.JAA09626@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Usage of ML Endpoint Discriminator Option Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "John R. Martz" > The "default bundle" scenario makes me nervous. I'm not sure it's something my customers would > really want chosen for them as the default. I'm considering limiting my implementation to not allow > scenario (1) multilink unless a customer explicitly manually configures to allow it. Perhaps > something like a "Require remote link identification to enable multlink" checkbox. The default would > be to have this "checked" and the customer would have to uncheck it to get scenario (1) behavior. What is "scenario (1) behavior"? It makes perfect sense to always have a default MP bundle, even when MP is explicitly not configured (e.g. MRRU never seen or Configure-Rejected) To make that point another way, some common MP implementations do not use MP headers when there is only a single link in the bundle (subject to the cautions in RFC 1990, which were added explicitly for such implementations). Another consideration is that RFC 1990 is not the only PPP multilink protocol. RFC 1990 is the only IETF official protocol, but the far older "load sharing," "round-robin," or "BF&I" tactic is still around. That tactic consists of simply running 2 or more parallel PPP links with the same IP addresses at both ends and doing the obvious with IP packets. The Endpoint Discriminator is a handy way to distinquish those old style bundle from RFC 1990 bundles. > My impression is this is a valid RFC 1990 compliant implementation choice. Anyone disagree? An implementaor can disable most PPP features. > Clara's ideas about using the called or calling phone numbers to limit the scope of a "default > bundle" are interesting alternatives too. I doubt that would be useful in many situations. When you establish a second phone call, don't you usually have a new calling phone number (or CID or ANI)? If so, the called PPP peer cannot always use calling phone numbers to label the MP link. Don't you sometimes have different called phone numbers? If so, you can't always use the called numbers. Note that one of the official types of Endpoint Discriminator is a telephone nuymber. If you can pick a single phone number, then you can also use it with Endpoint Discriminators. When I don't have Endpoint Discriminators, I like to identify the MP bundle by the IP address at the far end. In fact, I like to make the remote IP address the primary identification of the bundle, since you always have a remote IP address, but many not have other info. The trouble with that idea is that with some configurations, you do not discover the remote IP address until inconveniently late. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 11:09:39 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 73C1C44464; Wed, 25 Aug 1999 11:09:39 -0400 (EDT) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by segue.merit.edu (Postfix) with ESMTP id 6978C4445F for ; Wed, 25 Aug 1999 11:09:38 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp1.ntcom.nortel.net; Wed, 25 Aug 1999 11:08:56 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 25 Aug 1999 11:08:57 -0400 Message-ID: From: "John Tintor" To: ietf-ppp@merit.edu Subject: Remove from list Date: Wed, 25 Aug 1999 11:08:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Please remove from list. jtintor@nortelnetworks.com From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 11:12:27 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 65C9E44465; Wed, 25 Aug 1999 11:12:27 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 190DC44405 for ; Wed, 25 Aug 1999 11:12:26 -0400 (EDT) Received: from dbl-pserv.Ireland.Sun.COM ([129.156.220.7]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05493 for ; Wed, 25 Aug 1999 08:12:24 -0700 (PDT) Received: from berkeley (berkeley [129.156.228.76]) by dbl-pserv.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id QAA14550 for ; Wed, 25 Aug 1999 16:12:23 +0100 (BST) Message-Id: <199908251512.QAA14550@dbl-pserv.Ireland.Sun.COM> Date: Wed, 25 Aug 1999 16:12:23 +0100 (BST) From: Brendan Doyle SMI European Software Centre Reply-To: Brendan Doyle SMI European Software Centre Subject: Re: Remove from list To: ietf-ppp@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: whldzDdFD32vJiiPkSkBUg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 i86pc i386 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Please remove from list. brendan.doyle@ireland.sun.com From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 11:28:00 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2EFC744467; Wed, 25 Aug 1999 11:28:00 -0400 (EDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by segue.merit.edu (Postfix) with ESMTP id DFD0844464 for ; Wed, 25 Aug 1999 11:27:58 -0400 (EDT) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.132.204]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA229550 for ; Wed, 25 Aug 1999 11:27:33 -0400 Received: from jmartz (lig32-224-38-84.us.lig-dial.ibm.com [32.224.38.84]) by westrelay01.boulder.ibm.com (8.8.8m2/NCO v2.04) with SMTP id JAA183128 for ; Wed, 25 Aug 1999 09:27:55 -0600 Message-ID: <001d01beef0e$62d8ab60$0300a8c0@us.ibm.com> From: "John R. Martz" To: Subject: ML without ML headers - requirements? suggestions? Date: Wed, 25 Aug 1999 11:21:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Folks, Another aspect of multilink I'm not totally clear on is the usage of the ML headers. Going to post what I think I know to allow someone to set me straight if I've got it wrong. (1) A ML header should not be sent/received if you haven't enabled ML. (If you do allow ML ... do not Cfg-Ack the peer's MRRU option ... should you discard any packets the peer sends with a ML header? Seems so ... ) (2) If ML is enabled, the use of the ML is completely optional. You should use them, but the RFC doesn't require you to do this. (????) Bad things that can happen if you do NOT always use ML headers include: - Packets may arrive out of sequence. (You send A then B, but the peer received B before A). - Peer will not be able to detect lost fragments for any packets sent to it with ML headers - You won't be able to fragment packets (i.e. can't increase bandwidth when sending a "large" PPP packet) OTOH, since IP does it's own fragmentation I'm not sure how much of a loss it is to loose the ability to fragment PPP packets. The loss of packet sequencing might be a problem for PPP protocol negotiation. But then again, because the PPP protocol is request/response based, it's sorta self sequenced, no? Guess I'm not seriously proposing to implement ML without sending ML headers. But I am wondering what part of the picture I'm missing here. And just what policy to follow re accepting/discarding packets with ML headers. Thanks, -john martz (jmartz@us.ibm.com) IBM AS/400 TCP/IP PPP (and stuff) From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 11:47:14 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 080FD4446D; Wed, 25 Aug 1999 11:47:14 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id 684E944471 for ; Wed, 25 Aug 1999 11:47:12 -0400 (EDT) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id LAA24460 for ietf-ppp@merit.edu; Wed, 25 Aug 1999 11:47:11 -0400 (EDT) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: Usage of ML Endpoint Discriminator Option Date: 25 Aug 1999 11:47:11 -0400 Organization: IronBridge Networks Lines: 53 Message-ID: <86emgr3ls0.fsf@ironbridgenetworks.com> References: <002c01beef05$5b1c2a40$0300a8c0@us.ibm.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu jmartz@us.ibm.com ("John R. Martz") writes: > The "default bundle" scenario makes me nervous. I'm not sure it's > something my customers would really want chosen for them as the > default. I'm considering limiting my implementation to not allow > scenario (1) multilink unless a customer explicitly manually > configures to allow it. Perhaps something like a "Require remote > link identification to enable multlink" checkbox. The default would > be to have this "checked" and the customer would have to uncheck it > to get scenario (1) behavior. You're certainly free to add any sort of user controls you like, and I agree with you that the default bundle scenario is odd in some configurations. > My impression is this is a valid RFC 1990 compliant implementation > choice. Anyone disagree? If I were pressed to worry about this, I would make it so that if a peer fails to include an E-D in its LCP Configure-Request AND either it sends LCP Configure-Reject for the authentication option or we're configured not to offer that option, then I would not include MRRU in my LCP Configure-Request and would send Configure-Reject if the peer does include it. There's one corner case you'll have to deal with to do this. If you send LCP Configure-Request with MRRU but no authentication, and the peer Configure-Acks this request, and you then receive LCP Configure-Request with MRRU but without E-D, you must Configure-Reject MRRU and send a new Configure-Request without the MRRU option, since your assumption would then be invalid. (Of course, if you always demand authentication from your peers, and you never accept an unauthenticated connection, then all of this discussion, including the check-box option, is completely moot. The Peer-ID from the authentication protocol is as good as the E-D; and maybe better.) > Clara's ideas about using the called or calling phone numbers to > limit the scope of a "default bundle" are interesting alternatives > too. Those all fall under the "manual configuration" area; and they're all legal if you have the information to do it right. (Note that doing it *right* might be hard, since calling party information isn't always going to be strictly identical for a single caller, depending on what his line configuration looks like. Even on ISDN, the two B channels *might* provide different number appearances. Sigh.) -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 13:45:58 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B7C1144476; Wed, 25 Aug 1999 13:45:57 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id D3A9B44428 for ; Wed, 25 Aug 1999 13:45:55 -0400 (EDT) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id NAA11445 for ietf-ppp@merit.edu; Wed, 25 Aug 1999 13:45:55 -0400 (EDT) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: Usage of ML Endpoint Discriminator Option Date: 25 Aug 1999 13:45:55 -0400 Organization: IronBridge Networks Lines: 51 Message-ID: <86d7wb3ga4.fsf@ironbridgenetworks.com> References: <199908251504.JAA09626@calcite.rhyolite.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu vjs@calcite.rhyolite.com (Vernon Schryver) writes: > What is "scenario (1) behavior"? Scenario 1 from RFC 1990: (1) No authentication, no discriminator: All new links MUST be joined to one bundle, unless there is manual configuration to the contrary. It is also permissible to have more than one manually configured bundle connecting two given systems. > It makes perfect sense to always have a default MP bundle, even when MP Right; though I think you're making a very different point. John Martz's message was questioning the utility (or security, perhaps) of allowing all unauthenticated, no-ED links to join into a single, implementation-wide "default" bundle. You are right that having a default MP bundle for a clearly identified *separate* link (not a default implementation-wide) is probably a good implementation choice, but I don't think that was the issue. > Another consideration is that RFC 1990 is not the only PPP multilink > protocol. RFC 1990 is the only IETF official protocol, but the far older > "load sharing," "round-robin," or "BF&I" tactic is still around. That > tactic consists of simply running 2 or more parallel PPP links with the > same IP addresses at both ends and doing the obvious with IP packets. > The Endpoint Discriminator is a handy way to distinquish those old style > bundle from RFC 1990 bundles. Um, I don't think so. MRRU distinguishes RFC 1990 from BF&I bundles. ED itself might be a nice thing to have around for BF&I ... > When I don't have Endpoint Discriminators, I like to identify the MP > bundle by the IP address at the far end. For configuration management and SNMP interfaces, that probably makes sense. I can't make sense out of that for an MP implementation, though. You don't have the IP address on subsequent links that should join the bundle since you won't be going through IPCP again on those links. The only data you have around when you must make the decision to join a bundle "already in progress" (as they say) or create a new one is from LCP and authentication. Right? -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 14:01:02 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 107A444468; Wed, 25 Aug 1999 14:01:02 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id 45BA44443A for ; Wed, 25 Aug 1999 14:01:00 -0400 (EDT) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id OAA29162 for ietf-ppp@merit.edu; Wed, 25 Aug 1999 14:00:58 -0400 (EDT) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: ML without ML headers - requirements? suggestions? Date: 25 Aug 1999 14:00:58 -0400 Organization: IronBridge Networks Lines: 74 Message-ID: <86btbv3fl1.fsf@ironbridgenetworks.com> References: <001d01beef0e$62d8ab60$0300a8c0@us.ibm.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu jmartz@us.ibm.com ("John R. Martz") writes: > (1) A ML header should not be sent/received if you haven't enabled > ML. (If you do allow ML ... do not Cfg-Ack the peer's MRRU option > ... should you discard any packets the peer sends with a ML header? > Seems so ... ) You should send LCP Protocol-Reject if you receive any packet that has a protocol number you haven't agreed to receive. This applies to MP as well. > (2) If ML is enabled, the use of the ML is completely optional. You > should use them, but the RFC doesn't require you to do this. (????) Right. It's up to you. You MUST be able to receive such data, but whether or not you send it is your choice. (Of course, with all such choices, you need to have a good reason to do something other than what the RFC says to do.) > Bad things that can happen if you do NOT always use ML headers include: > - Packets may arrive out of sequence. (You send A then B, but the > peer received B before A). > - Peer will not be able to detect lost fragments for any packets > sent to it with ML headers > - You won't be able to fragment packets (i.e. can't increase > bandwidth when sending a "large" PPP packet) All true. However, if you send something without the MP header, then it won't be delayed by reassembly's lost-fragment detection algorithm if there are drops at the peer. That's the choice *you* must make. It's not up to the standard to specify this, since it can't be properly specified in all possible cases. (Suppose there's a UDP protocol that doesn't care about packet reordering but *does* care about delay variance caused by reassembly. An system that uses this protocol could allow a socket-level flag to be passed down through the IP layer into the driver to tell it to avoid encapsulating those particular packets with MP headers.) > OTOH, since IP does it's own fragmentation I'm not sure how much of > a loss it is to loose the ability to fragment PPP packets. It means a lot more to other protocols, of course. IP fragmentation has its own problems as well considering that a fair number of people leave PMTU discovery enabled. > The loss > of packet sequencing might be a problem for PPP protocol > negotiation. But then again, because the PPP protocol is > request/response based, it's sorta self sequenced, no? I'm not sure I understand the point there. You certainly do *not* want to send one PPP negotiation packet without MP headers on one link and then another for the same state machine over a different link. That would be a bad idea. It's much better to choose a single link and negotiate over that. > Guess I'm not seriously proposing to implement ML without sending ML > headers. But I am wondering what part of the picture I'm missing > here. And just what policy to follow re accepting/discarding > packets with ML headers. If you're referring to packets received with PPP protocol ID 003D when you haven't specifically negotiated MRRU, you should Protocol-Reject those. Otherwise, you should generally do discard in accordance with section 4.1 of RFC 1990. (Of course, any datagram implementation is free to discard any datagram at any time. But that's another topic ...) -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 14:50:17 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5100B4446F; Wed, 25 Aug 1999 14:50:17 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by segue.merit.edu (Postfix) with ESMTP id CFC5C4446E for ; Wed, 25 Aug 1999 14:50:15 -0400 (EDT) Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA355440 for ; Wed, 25 Aug 1999 14:49:51 -0400 Received: from jmartz (DIP005899END.endicott.ibm.com [9.130.69.192]) by southrelay01.raleigh.ibm.com (8.8.8m2/NCO v2.04) with SMTP id OAA74516 for ; Wed, 25 Aug 1999 14:49:34 -0400 Message-ID: <000d01beef2a$a5ae96e0$c0458209@us.ibm.com> From: "John R. Martz" To: References: <001d01beef0e$62d8ab60$0300a8c0@us.ibm.com> <86btbv3fl1.fsf@ironbridgenetworks.com> Subject: Re: ML without ML headers - requirements? suggestions? Date: Wed, 25 Aug 1999 14:47:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > > The loss > > of packet sequencing might be a problem for PPP protocol > > negotiation. But then again, because the PPP protocol is > > request/response based, it's sorta self sequenced, no? > I'm not sure I understand the point there. James, I'm not so sure I had a point. What I was thinking was, "I don't see how you'd actually get packets out of sequence while doing PPP negotiation because it's a request/response protocol. But OTOH I don't feel I completely understand the PPP state machine, so maybe I'm missing something?" > You certainly do *not* > want to send one PPP negotiation packet without MP headers on one link > and then another for the same state machine over a different link. > That would be a bad idea. It's much better to choose a single link > and negotiate over that. Why is this a bad idea? Not tryiing to argue with you, I just don't see why it's a problem and I'd really like to understand. This isn't something we'd considered doing before. I thought the NCP negotiation could be over the virtual link/bundle and thus could end up going down any of the links that had been bundled together. Whether you send an IPCP packet over link A or link B they both should be processed by the same state machine task on the remote peer, correct? By "sorta self-sequencing" I meant that PPP is request/response. You send Cfg-Req and then wait for a response. You only resend the request if the retry timer pops. And if you do resend, then the resent packet is identical to the sent packet so there's practically speaking they can't be received "out of sequence". No? What is that I am not seeing? Why should you ALWAYS use the MP headers when sending NCP packets over multiple links in a bundle? Thanks, -john martz (jmartz@us.ibm.com) IBM AS/400 TCP/IP PPP (and stuff) From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 15:29:33 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6604D44476; Wed, 25 Aug 1999 15:29:33 -0400 (EDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by segue.merit.edu (Postfix) with ESMTP id F07BA44474 for ; Wed, 25 Aug 1999 15:29:31 -0400 (EDT) Received: from southrelay01.raleigh.ibm.com (southrelay01.raleigh.ibm.com [9.37.3.208]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA252434; Wed, 25 Aug 1999 15:27:48 -0400 Received: from jmartz (DIP005899END.endicott.ibm.com [9.130.69.192]) by southrelay01.raleigh.ibm.com (8.8.8m2/NCO v2.04) with SMTP id PAA80934; Wed, 25 Aug 1999 15:27:21 -0400 Message-ID: <001e01beef2f$ecafd400$c0458209@us.ibm.com> From: "John R. Martz" To: Cc: "Vernon Schryver" References: <199908251504.JAA09626@calcite.rhyolite.com> Subject: Re: Usage of ML Endpoint Discriminator Option Date: Wed, 25 Aug 1999 15:27:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > When I don't have Endpoint Discriminators, I like to identify the MP > bundle by the IP address at the far end. In fact, I like to make > the remote IP address the primary identification of the bundle, since > you always have a remote IP address, but many not have other info. This may be a pointless counter-point, but the peer doesn't have to give you an IP address, correct? One of the things I intiailly screwed up and had to fix in my IPCP negotiation was connecting to a router. Routers typically don't want to give you their IP address because it expects it'll just be forwarding/routing all the IP packets sent to it. Consequently, a dedicated router is likely to send you an IPCP cfg-request with no options. -john martz (jmartz@us.ibm.com) IBM AS/400 TCP/IP PPP (and stuff) From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 16:37:57 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C3E8C444CF; Wed, 25 Aug 1999 16:37:56 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id ABDDB444C8 for ; Wed, 25 Aug 1999 16:37:54 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id OAA15894 for ietf-ppp@merit.edu env-from ; Wed, 25 Aug 1999 14:37:54 -0600 (MDT) Date: Wed, 25 Aug 1999 14:37:54 -0600 (MDT) From: Vernon Schryver Message-Id: <199908252037.OAA15894@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Usage of ML Endpoint Discriminator Option Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > ... > > When I don't have Endpoint Discriminators, I like to identify the MP > > bundle by the IP address at the far end. > > For configuration management and SNMP interfaces, that probably makes > sense. > > I can't make sense out of that for an MP implementation, though. You > don't have the IP address on subsequent links that should join the > bundle since you won't be going through IPCP again on those links. > The only data you have around when you must make the decision to join > a bundle "already in progress" (as they say) or create a new one is > from LCP and authentication. Right? Agreed, but at least in BSD kernels, the identity of the entire bundle will be closely associated with that original IP address. Anything that conflicts with that original IP address, such as recycling through IPCP and getting a different IP address, is problem. Also, if you consciously associate the IP address with the identity of the bundle, it's easy to use BF&I instead of RFC 1990. I can't tell if BF&I still matters. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 16:48:35 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3AE274448C; Wed, 25 Aug 1999 16:48:29 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 15E2744491 for ; Wed, 25 Aug 1999 16:47:54 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id OAA16098 for ietf-ppp@merit.edu env-from ; Wed, 25 Aug 1999 14:47:53 -0600 (MDT) Date: Wed, 25 Aug 1999 14:47:53 -0600 (MDT) From: Vernon Schryver Message-Id: <199908252047.OAA16098@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Usage of ML Endpoint Discriminator Option Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "John R. Martz" > > When I don't have Endpoint Discriminators, I like to identify the MP > > bundle by the IP address at the far end. In fact, I like to make > > the remote IP address the primary identification of the bundle, since > > you always have a remote IP address, but many not have other info. > > This may be a pointless counter-point, but the peer doesn't have > to give you an IP address, correct? In principle, but rarely in practice with good implementations. > One of the things I intiailly screwed up and had to fix in my IPCP > negotiation was connecting to a router. Routers typically don't want to > give you their IP address because it expects it'll just be > forwarding/routing all the IP packets sent to it. Not so. Today the router will also want to talk at least RADIUS, TACUS, SNMP, telnet, BOOTP, DHCP, DNS, syslog, TFTP, and lots of routing protocols and will need and use an IP address of its own. > Consequently, > a dedicated router is likely to send you an IPCP cfg-request with > no options. In principle, that's legal. However, I don't remember ever hearing of a non-junk implementation that does that, particularly for an IP router instead of bridge. It's too useful and too easy to send the router's IP address. Where have you seen empty IPCP Configure-Requests? Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 18:04:17 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C3D0444484; Wed, 25 Aug 1999 18:04:16 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id C64E844482 for ; Wed, 25 Aug 1999 18:04:10 -0400 (EDT) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id SAA08633 for ietf-ppp@merit.edu; Wed, 25 Aug 1999 18:04:10 -0400 (EDT) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: ML without ML headers - requirements? suggestions? Date: 25 Aug 1999 18:04:10 -0400 Organization: IronBridge Networks Lines: 72 Message-ID: <86672334bp.fsf@ironbridgenetworks.com> References: <000d01beef2a$a5ae96e0$c0458209@us.ibm.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu jmartz@us.ibm.com ("John R. Martz") writes: > What I was thinking was, "I don't see how you'd actually get packets > out of sequence while doing PPP negotiation because it's a > request/response protocol. Not really. There are timers running and, during Network phase, there are any number of NCPs running simultaneously. > But OTOH I don't feel I completely > understand the PPP state machine, so maybe I'm missing something?" The state machine isn't designed with that case in mind. I *think* the worst you'll do is end up not converging and drop the link. But I'm not sure and I'd have to think about it for a while. > > You certainly do *not* > > want to send one PPP negotiation packet without MP headers on one link > > and then another for the same state machine over a different link. > > That would be a bad idea. It's much better to choose a single link > > and negotiate over that. > > Why is this a bad idea? Not tryiing to argue with you, I just don't > see why it's a problem and I'd really like to understand. This isn't > something we'd considered doing before. I thought the NCP > negotiation could be over the virtual link/bundle It can, though it's rarely done that way. > and thus could end > up going down any of the links that had been bundled together. No. MP puts everything back into sequential order at the other end if you do it over the bundle. (Unless you try to run without sequencing on individual links, then you're not really running over the bundle itself.) > Whether you send an IPCP packet over link A or link B they both > should be processed by the same state machine task on the remote > peer, correct? By "sorta self-sequencing" I meant that PPP is > request/response. No, it's not. You're both sending Configure-Acks and receiving Configure-Requests at the same time. > You send Cfg-Req and then wait for a response. You > only resend the request if the retry timer pops. And if you do > resend, then the resent packet is identical to the sent packet so > there's practically speaking they can't be received "out of > sequence". No? Not always so. It's perfectly legal to change the ID number when doing a retransmit, and many implementations do that. > What is that I am not seeing? Why should you ALWAYS use the MP > headers when sending NCP packets over multiple links in a bundle? It's obvious that it will slow down things on a phase transition -- for example, getting a PAP Authenticate-Request while you're still waiting for an LCP Configure-Ack will cause you to ditch the PAP message and force the peer to retransmit. Otherwise, no, it's not immediately obvious to me why reordering is considered to be absolutely fatal. (And it is considered that way; this was an important consideration in L2TP.) I'll think about it ... -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Aug 25 18:07:14 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 83E3B44487; Wed, 25 Aug 1999 18:07:14 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id DDD8744485 for ; Wed, 25 Aug 1999 18:07:12 -0400 (EDT) Received: (from news@localhost) by ironbridgenetworks.com (8.9.3/8.9.3) id SAA09443 for ietf-ppp@merit.edu; Wed, 25 Aug 1999 18:07:12 -0400 (EDT) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: Usage of ML Endpoint Discriminator Option Date: 25 Aug 1999 18:07:12 -0400 Organization: IronBridge Networks Lines: 28 Message-ID: <864shn346n.fsf@ironbridgenetworks.com> References: <199908252037.OAA15894@calcite.rhyolite.com> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu vjs@calcite.rhyolite.com (Vernon Schryver) writes: > Agreed, but at least in BSD kernels, the identity of the entire bundle > will be closely associated with that original IP address. Anything that > conflicts with that original IP address, such as recycling through IPCP > and getting a different IP address, is problem. True, but I'm missing something here. When you get a new connection from a peer (one that *you* didn't originate, and therefore have no reason to associate with any particular IP address), how do you a priori know the address at the other end? I think that was the point I was trying to make. You generally have to wait until authentication is done until you put a new link into an existing bundle. > Also, if you consciously associate the IP address with the identity of > the bundle, it's easy to use BF&I instead of RFC 1990. > > I can't tell if BF&I still matters. Very much so! MP is horrid at very high speeds, or if you have to deal with fail-over. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Aug 26 13:33:59 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 66403444A0; Thu, 26 Aug 1999 13:33:26 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by segue.merit.edu (Postfix) with ESMTP id 43642444A2 for ; Thu, 26 Aug 1999 13:31:21 -0400 (EDT) Received: from northrelay01.pok.ibm.com ([9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA88394; Thu, 26 Aug 1999 12:12:38 -0400 Received: from cable345 (DIP005899END.endicott.ibm.com [9.130.69.192]) by northrelay01.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id MAA136400; Thu, 26 Aug 1999 12:12:24 -0400 Message-ID: <001401beefdd$c569aac0$c0458209@us.ibm.com> From: "John R. Martz" To: Cc: "Vernon Schryver" References: <199908252047.OAA16098@calcite.rhyolite.com> Subject: Re: Usage of ML Endpoint Discriminator Option Date: Thu, 26 Aug 1999 12:11:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > Where have you seen empty IPCP Configure-Requests? Vernon, In our case we were using an IBM 2210 router. But I'm sure ... that is I don't really know, but I'd bet a small amount of money on it being true ... that this scenario is also quit possible with other routers still in common use today. Yes, you can configure the 2210 to have a local IP address. And depending on what you're doing this might be the "better" thing to do. My point was just that I don't think I can always assume that the remote peer is going to tell me it's IP address. That's just too big a leap for me. (Customers are notorious for wanting to do things I personally don't think are very reasonable. Not so long ago I was called for a customer who had an old "clunker" 2400 baud IBM modem that AS/400 PPP wasn't working with. He could have simply switched to a Sporster 28.8 (or such) and both eliminated the problem and increased his throughput for what I considered a very negligible cost. But nope. He had an IBM modem and he darn well expected it to work with an IBM system! How could I say no?? :) -john martz (jmartz@us.ibm.com) IBM AS/400 TCP/IP PPP (and stuff) From owner-ietf-ppp-outgoing@merit.edu Thu Aug 26 18:19:26 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C2FEE444AD; Thu, 26 Aug 1999 18:19:25 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id F396A444A0 for ; Thu, 26 Aug 1999 18:19:23 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id QAA14781 for ietf-ppp@merit.edu env-from ; Thu, 26 Aug 1999 16:19:23 -0600 (MDT) Date: Thu, 26 Aug 1999 16:19:23 -0600 (MDT) From: Vernon Schryver Message-Id: <199908262219.QAA14781@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Usage of ML Endpoint Discriminator Option Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "John R. Martz" > In our case we were using an IBM 2210 router. But I'm sure ... > that is I don't really know, but I'd bet a small amount of money > on it being true ... that this scenario is also quit possible with > other routers still in common use today. Again, I've seen packet traces from more than 1 or 2 routers, albeit never as far as I know from an IBM box, but I don't recall a router not having an IP address. > Yes, you can configure the 2210 to have a local IP address. And > depending on what you're doing this might be the "better" thing to > do. If the 2210 does not have an IP address, how do you manage it? A router that cannot be remotely managed had better cost almost nothing in today,s market. > My point was just that I don't think I can always assume that > the remote peer is going to tell me it's IP address. That's just > too big a leap for me. Yes, besides the dogma "be conservative in what you send and generous in what you receive," it is a fact that the peer is not required to negotiate an IP address. > (Customers are notorious for wanting to do things I personally don't > think are very reasonable. Not so long ago I was called for a customer > who had an old "clunker" 2400 baud IBM modem that AS/400 PPP wasn't working > with. He could have simply switched to a Sporster 28.8 (or such) and both > eliminated the problem and increased his throughput for what I considered > a very negligible cost. But nope. He had an IBM modem and he darn well > expected it to work with an IBM system! How could I say no?? :) yes, customers can be picky. Still, if you have any influence on this 2210 IBM product, and you have any reason to hope it does well in the market, it would be wise to exert your influence to make it less unreasonable. A router that does not divulge its IP address is legal, but not reasonable and not competative. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Fri Aug 27 12:02:25 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8F2A8444DA; Fri, 27 Aug 1999 12:02:10 -0400 (EDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by segue.merit.edu (Postfix) with ESMTP id 9E9B1444A8 for ; Fri, 27 Aug 1999 12:00:17 -0400 (EDT) Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA318636 for ; Fri, 27 Aug 1999 11:59:52 -0400 Received: from cable345 (DIP005899END.endicott.ibm.com [9.130.69.192]) by northrelay01.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id MAA201930 for ; Fri, 27 Aug 1999 12:00:14 -0400 Message-ID: <001b01bef0a5$3cab9360$LocalHost@cable345> From: "John R. Martz" To: Subject: Re: Usage of ML Endpoint Discriminator Option Date: Fri, 27 Aug 1999 11:59:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > Still, if you have any influence on this 2210 IBM product, and you have > any reason to hope it does well in the market, it would be wise to exert > your influence to make it less unreasonable. A router that does not > divulge its IP address is legal, but not reasonable and not competative. Vernon, Unfortunately I'm just a "dumb user". I've never configured this router myself so I can't give you a definitive answer. But I assume that it functions this way as a security feature. Just because the router HAS an IP address doesn't mean you WANT it passed out to anyone who dials into it. Alternatively, the router's IP address may be on a network that is intentionally not accessible to (most) folks who dial into the router. Again, as a security feature. The harder it is for someone to talk directly to the router the less likely it is that someone can hack into it. In other words, I don't view this as a competative disadvantage at all. It's a feature. I'd also speculate that even the routers you have worked with could exhibit be configured this way. No? -john martz (jmartz@us.ibm.com) IBM AS/400 TCP/IP PPP (and stuff) From owner-ietf-ppp-outgoing@merit.edu Fri Aug 27 17:17:53 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A3B1844447; Fri, 27 Aug 1999 17:17:52 -0400 (EDT) Received: from fs-sd-exch1.coppermountain.com (fs-sd-exch1.coppermountain.com [209.246.224.234]) by segue.merit.edu (Postfix) with ESMTP id 6527D4443E for ; Fri, 27 Aug 1999 17:17:51 -0400 (EDT) Received: by fs-sd-exch1.coppermountain.com with Internet Mail Service (5.5.2448.0) id ; Fri, 27 Aug 1999 14:13:40 -0700 Message-ID: <47FEF5D2BE22D311AA8600508B10891532BA83@fs-sd-exch1.coppermountain.com> From: Eric Michelsen To: ietf-ppp@merit.edu Subject: RE: Usage of ML Endpoint Discriminator Option Date: Fri, 27 Aug 1999 14:13:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I'm not familiar with BF&I. Can someone give me reference for it? Or tell me what it stands for? ------------------------------------------- Eric L. Michelsen, Copper Mountain Networks > -----Original Message----- > From: James Carlson [mailto:carlson@ironbridgenetworks.com] > Sent: Wednesday, August 25, 1999 15:07 > To: ietf-ppp@merit.edu > Subject: Re: Usage of ML Endpoint Discriminator Option > > > vjs@calcite.rhyolite.com (Vernon Schryver) writes: > > Agreed, but at least in BSD kernels, the identity of the > entire bundle > > will be closely associated with that original IP address. > Anything that > > conflicts with that original IP address, such as recycling > through IPCP > > and getting a different IP address, is problem. > > True, but I'm missing something here. When you get a new connection > from a peer (one that *you* didn't originate, and therefore have no > reason to associate with any particular IP address), how do you a > priori know the address at the other end? > > I think that was the point I was trying to make. You generally have > to wait until authentication is done until you put a new link into an > existing bundle. > > > Also, if you consciously associate the IP address with the > identity of > > the bundle, it's easy to use BF&I instead of RFC 1990. > > > > I can't tell if BF&I still matters. > > Very much so! MP is horrid at very high speeds, or if you have to > deal with fail-over. > > -- > James Carlson, System Architect > > IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 > 781 372 8132 > Lexington MA 02421-7996 / USA 42.423N Fax: +1 > 781 372 8090 > "PPP Design and Debugging" --- > http://people.ne.mediaone.net/carlson/ppp > From owner-ietf-ppp-outgoing@merit.edu Fri Aug 27 17:29:22 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EC6B444447; Fri, 27 Aug 1999 17:29:21 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 68F2244446 for ; Fri, 27 Aug 1999 17:29:20 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.0/calcite) id PAA15662 for ietf-ppp@merit.edu env-from ; Fri, 27 Aug 1999 15:29:19 -0600 (MDT) Date: Fri, 27 Aug 1999 15:29:19 -0600 (MDT) From: Vernon Schryver Message-Id: <199908272129.PAA15662@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: RE: Usage of ML Endpoint Discriminator Option Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Eric Michelsen > I'm not familiar with BF&I. Can someone give me reference for it? Or tell > me what it stands for? It stands for Brute Force & Ignorance, and I apply it to the obvious way to reverse multiplex IP packets over serial links. It is not pejoritive, at least in my mind. I also believe that simpler is usually better. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Mon Aug 30 07:02:24 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D47DE44411; Mon, 30 Aug 1999 07:02:23 -0400 (EDT) Received: from helios.ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by segue.merit.edu (Postfix) with ESMTP id F3A1C44409 for ; Mon, 30 Aug 1999 07:02:21 -0400 (EDT) Received: (from news@localhost) by helios.ironbridgenetworks.com (8.8.8+Sun/8.8.8) id HAA17256 for ietf-ppp@merit.edu; Mon, 30 Aug 1999 07:02:21 -0400 (EDT) To: ietf-ppp@merit.edu From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: Usage of ML Endpoint Discriminator Option Date: 30 Aug 1999 07:02:21 -0400 Organization: IronBridge Networks Lines: 43 Message-ID: <86g1118rb6.fsf@ironbridgenetworks.com> References: <001b01bef0a5$3cab9360$LocalHost@cable345> NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu jmartz@us.ibm.com ("John R. Martz") writes: > But I assume that it functions this way as a security feature. Just > because the router HAS an IP address doesn't mean you WANT it passed > out to anyone who dials into it. Alternatively, the router's IP > address may be on a network that is intentionally not accessible to > (most) folks who dial into the router. Again, as a security > feature. The harder it is for someone to talk directly to the router > the less likely it is that someone can hack into it. Three comments: 1. Obscurity != security. Making it hard to get the IP address is not a security advantage. Someone who does want the address will likely find it through other means. (What source address do you use if you support Path MTU Discovery? What do you tell customers if you *don't* support it?) 2. There's no particular reason to apply the same security mechanisms to the "network" and the "dial-up" sides of the box. Most routers have the ability to apply stricter access control to the dial-up lines. Thus, knowing the "true" IP address of the box is not necessarily as useful on those dial-up lines as it might be on the Ethernet side. 3. The address that you hand out via IPCP need not be the "true" or "unrestricted" IP address of the box. Handing out an IP address that happens to lead to a firewall or other security mechanism is perfectly acceptable. > In other words, I don't view this as a competative disadvantage at > all. It's a feature. I'd also speculate that even the routers you > have worked with could exhibit be configured this way. No? Yes, many can. I side with Vern on this one, though: setting it up that way isn't a feature. It's a bug. -- James Carlson, System Architect IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8090 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Aug 30 12:34:55 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B0A9544410; Mon, 30 Aug 1999 12:34:54 -0400 (EDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by segue.merit.edu (Postfix) with ESMTP id 5A59B44405 for ; Mon, 30 Aug 1999 12:34:53 -0400 (EDT) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA264344; Mon, 30 Aug 1999 12:34:26 -0400 From: jmartz@us.ibm.com Received: from D51MTA10.pok.ibm.com (d51mta10.pok.ibm.com [9.117.200.38]) by northrelay02.pok.ibm.com (8.8.8m2/NCO v2.04) with SMTP id MAA102018; Mon, 30 Aug 1999 12:34:50 -0400 Received: by D51MTA10.pok.ibm.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852567DD.005B1129 ; Mon, 30 Aug 1999 12:34:41 -0400 X-Lotus-FromDomain: IBMUS To: ietf-ppp@merit.edu Cc: James Carlson Message-ID: <852567DD.005B0FFB.00@D51MTA10.pok.ibm.com> Date: Mon, 30 Aug 1999 11:34:25 -0500 Subject: Re: Usage of ML Endpoint Discriminator Option Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > Yes, many can. I side with Vern on this one, though: > setting it up that way isn't a feature. It's a bug. James, Point taken. However "bug" seems too strong a description since "setting it up that way" is still a correct implementation of RFC1332. If you want to call it a bug, shouldn't you negotiate a change to the description of IP address negotiation in RFC1332? I also feel I should clarify one more time "for the record" that the 2210 (and many other routers actively in use) CAN be configured to provide an IP address as part of IPCP negotiation. So when a router does not provides an IP address when you connect, it is doing this because the customer decided to do it this way. Even if RFC1332 required an IP address to be provided (which it does not) an implementation that does not send an IP address as a result of a customer configuration choice is still technically correct, no? Speaking from my end of the link, an implementation cannot break ... cause a link attempt to fail ... because a customer set up my peer with a legal configuration that may not be viewed as appropriate for a wider context. And I don't recall any of the points that have been made as being stronger than reasons why one peer SHOULD tell the other peer what its IP address is. So while it may be a very good idea to do this, it cannot be depended on. I cannot drop the link if a peer does NOT give me its IP address. Correct? Finally, whatever else it did, this discussion has at least made me feel better about AS/400. A while back we made a design decision that AS/400 MUST always have a local IP address to give to its peer in order to use PPP. Nice to know that we appear to have made a "right" decision (... even though we made it for other reasons :) -john martz, 8-852-5539, jmartz@us.ibm.com IBM AS/400 TCP/IP PPP development (and stuff)