From gwz@net-zen.net Wed Feb 3 18:32:38 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906333A6876 for ; Wed, 3 Feb 2010 18:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAXrQ5lmd9FI for ; Wed, 3 Feb 2010 18:32:37 -0800 (PST) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id C58163A68FE for ; Wed, 3 Feb 2010 18:32:37 -0800 (PST) Received: (qmail 14897 invoked from network); 4 Feb 2010 02:33:21 -0000 Received: from unknown (124.120.217.36) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 04 Feb 2010 02:33:20 -0000 From: "Glen Zorn" To: Date: Thu, 4 Feb 2010 09:32:56 +0700 Organization: Network Zen Message-ID: <00b801caa542$5d9daec0$18d90c40$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B9_01CAA57D.09FC86C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqlEeR+6EjYXe3NR3iu3sbltJeW8AAL5hzQ Content-Language: en-us Subject: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 02:32:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B9_01CAA57D.09FC86C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit FYI -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, February 04, 2010 3:45 AM To: i-d-announce@ietf.org Subject: I-D Action:draft-huang-ipv6cp-options-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6CP Options for PPP Host Configuration Author(s) : J. Huang Filename : draft-huang-ipv6cp-options-00.txt Pages : 10 Date : 2010-02-03 The Softwire Hub and Spoke Framework document outlines three steps for the Softwire Initiator (SI) and PPP peer of the Softwire Concentrator (SC) over IPv4 connectivity to be fully configured for IPv6 once the PPP session has been established. For the same function over IPv6 connectivity, however, only one additional step is needed. This is because IPv6CP only defines the Interface-Identifier option. This document defines additional host configuration options for IPv6CP so that the operational model of IPCP is extended to IPv6CP to reduce requirements on the SI and SC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huang-ipv6cp-options-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_00B9_01CAA57D.09FC86C0 Content-Type: Message/External-body; name="draft-huang-ipv6cp-options-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-huang-ipv6cp-options-00.txt" Content-Type: text/plain Content-ID: <2010-02-03124334.I-D@ietf.org> ------=_NextPart_000_00B9_01CAA57D.09FC86C0 Content-Type: text/plain; name="ATT00155.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00155.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ------=_NextPart_000_00B9_01CAA57D.09FC86C0-- From carlsonj@workingcode.com Mon Feb 8 10:42:34 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2127E28B56A for ; Mon, 8 Feb 2010 10:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6OhZyvyVlej for ; Mon, 8 Feb 2010 10:42:33 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 306C73A71DD for ; Mon, 8 Feb 2010 10:42:32 -0800 (PST) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o18IhQfY026089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 13:43:27 -0500 (EST) Message-ID: <4B705B4E.6030405@workingcode.com> Date: Mon, 08 Feb 2010 13:43:26 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Glen Zorn , jhuang1@att.com References: <00b801caa542$5d9daec0$18d90c40$@net> In-Reply-To: <00b801caa542$5d9daec0$18d90c40$@net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-dmv.com-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 18:42:34 -0000 Glen Zorn wrote: > FYI Thanks for forwarding. > Title : IPv6CP Options for PPP Host Configuration > Author(s) : J. Huang > Filename : draft-huang-ipv6cp-options-00.txt We've had the same proposal come up -- and get shot down -- multiple times in the past. Please search the archives. There's plenty of detail available in the archives to describe why these ideas don't actually work well in deployment and are fundamentally unnecessary. In short, PPP is a link layer protocol. It negotiates only what's necessary to make the link itself work and prevent obvious sorts of misconfigurations in the the link. It does not (and should not be expected to) negotiate for arbitrary network and application level parameters that might help your system function. It doesn't make any more sense to do that than to (say) build DNS server negotiation into Ethernet. The commonly accepted mechanisms are: 2.1 through 2.4: prefixes and default gateway addresses are acquired via IPv6 Router Discovery RS/RA messages. These mechanisms already exist and are used on numerous platforms. 2.5 and 2.6: these are already doable with DHCPv6 Information; there's no need to build it into PPP. 2.7 and 2.8: prefix delegation requires mechanisms in other protocols, such as DHCPv6 and Router Discovery. Looking there for common link-layer agnostic answers is likely the best answer. -- James Carlson 42.703N 71.076W From zh1424@att.com Mon Feb 8 11:34:50 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D27A3A6F49 for ; Mon, 8 Feb 2010 11:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYVGEG+U2XtU for ; Mon, 8 Feb 2010 11:34:49 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 368543A6C7E for ; Mon, 8 Feb 2010 11:34:49 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: zh1424@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1265657751!29417193!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 29816 invoked from network); 8 Feb 2010 19:35:51 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-6.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Feb 2010 19:35:51 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o18JZhCw018731; Mon, 8 Feb 2010 14:35:43 -0500 Received: from misout7msgusr7a.ugd.att.com (misout7msgusr7a.ugd.att.com [144.155.43.103]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o18JZdBb018709; Mon, 8 Feb 2010 14:35:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Feb 2010 14:35:45 -0500 Message-ID: <2FFFD6E98F51BE43878BFED80215F83805512CB3@misout7msgusr7a.ugd.att.com> In-Reply-To: <4B705B4E.6030405@workingcode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt Thread-Index: Acqo7qRNtpMd6oYMTP2qXRXOX2I6yQAAe11g References: <00b801caa542$5d9daec0$18d90c40$@net> <4B705B4E.6030405@workingcode.com> From: "HUANG, JERRY (ATTLABS)" To: "James Carlson" , "Glen Zorn" X-Mailman-Approved-At: Mon, 08 Feb 2010 12:12:45 -0800 Cc: pppext@ietf.org Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 19:37:26 -0000 Thanks for the pointer. And you are right that an archive search could have been done... I understand your point of RS/RA and DHCPv6 being already available and can/should be used for these configuration events on IP layer. In fact, these are actually the way Softwire Hub and Spoke [RFC5571] works. They are also the motivations behind this I-D: to avoid having to relying on them over the PPP link. Bringing in other subsystems can bring additional system complexity, as well as overhead such as DAD. While PPP is a link layer protocol, it is also used to negotiate higher layer protocol parameters such as address [RFC1332] and DNS server [RFC1877] information, so I figured that IPv6 address (instead of just the interface ID, RFC5072), gateway information, IPv6 DNS information, even prefix assignment are reasonable parameters to negotiate over PPP. I saw that as a more efficient model over PPP link than RA and DHCPv6 combined. In any case, thanks for the feedback. The point was to see if there is interest in pursuing it further but I suppose that could have been found out another way. Thanks, -- Jerry Huang, AT&T Labs, +1 630 719 4389 -----Original Message----- From: James Carlson [mailto:carlsonj@workingcode.com]=20 Sent: Monday, February 08, 2010 12:43 To: Glen Zorn; HUANG, JERRY (ATTLABS) Cc: pppext@ietf.org Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt Glen Zorn wrote: > FYI Thanks for forwarding. > Title : IPv6CP Options for PPP Host Configuration > Author(s) : J. Huang > Filename : draft-huang-ipv6cp-options-00.txt We've had the same proposal come up -- and get shot down -- multiple times in the past. Please search the archives. There's plenty of detail available in the archives to describe why these ideas don't actually work well in deployment and are fundamentally unnecessary. In short, PPP is a link layer protocol. It negotiates only what's necessary to make the link itself work and prevent obvious sorts of misconfigurations in the the link. It does not (and should not be expected to) negotiate for arbitrary network and application level parameters that might help your system function. It doesn't make any more sense to do that than to (say) build DNS server negotiation into Ethernet. The commonly accepted mechanisms are: 2.1 through 2.4: prefixes and default gateway addresses are acquired via IPv6 Router Discovery RS/RA messages. These mechanisms already exist and are used on numerous platforms. 2.5 and 2.6: these are already doable with DHCPv6 Information; there's no need to build it into PPP. 2.7 and 2.8: prefix delegation requires mechanisms in other protocols, such as DHCPv6 and Router Discovery. Looking there for common link-layer agnostic answers is likely the best answer. --=20 James Carlson 42.703N 71.076W From carlsonj@workingcode.com Mon Feb 8 12:26:48 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5FE28C181 for ; Mon, 8 Feb 2010 12:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgSBX1Ya68vy for ; Mon, 8 Feb 2010 12:26:47 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 456F428C176 for ; Mon, 8 Feb 2010 12:26:47 -0800 (PST) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o18KRkvg012602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 15:27:46 -0500 (EST) Message-ID: <4B7073C2.407@workingcode.com> Date: Mon, 08 Feb 2010 15:27:46 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: "HUANG, JERRY (ATTLABS)" References: <00b801caa542$5d9daec0$18d90c40$@net> <4B705B4E.6030405@workingcode.com> <2FFFD6E98F51BE43878BFED80215F83805512CB3@misout7msgusr7a.ugd.att.com> In-Reply-To: <2FFFD6E98F51BE43878BFED80215F83805512CB3@misout7msgusr7a.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-dmv.com-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 20:26:48 -0000 HUANG, JERRY (ATTLABS) wrote: > Thanks for the pointer. And you are right that an archive search could > have been done... > > I understand your point of RS/RA and DHCPv6 being already available and > can/should be used for these configuration events on IP layer. In fact, > these are actually the way Softwire Hub and Spoke [RFC5571] works. They > are also the motivations behind this I-D: to avoid having to relying on > them over the PPP link. Bringing in other subsystems can bring > additional system complexity, as well as overhead such as DAD. While PPP Agreed on the additional complexity, which is why having a duplicate mechanism to solve this problem -- the existing one in IPv6 Router Discovery plus your proposed one added to IPV6CP in PPP -- is not in my opinion helpful for the future. (We'll have to wait for other wg members to chime in before declaring any sort of wg response, of course.) I understand the desire to optimize your own equipment for the purposes it serves. However, our goal is to make the protocols work right for the Internet in the longer term. Duplication does not help in that regard. > is a link layer protocol, it is also used to negotiate higher layer > protocol parameters such as address [RFC1332] and DNS server [RFC1877] > information, A closer reading will show that the IPv4 addresses are negotiated because of the experience with SLIP. There is (or at least was at the time) no native IP mechanism that allowed the detection of misconfigured IP addresses on point-to-point (ARP-less) links, and silent mistakes were common with SLIP. Thus, although a slight layering violation, address negotiation was added to IPCP in PPP to avoid a known problem. Yes, it does at least partially overlap with DHCP/BOOTP functionality in IPv4, and that is a known issue. Fortunately, if you're using IPCP for IPv4 addresses, there's no conflict to use stateless DHCP INFORM to get other configuration parameters. As for the DNS options, those were implemented and deployed by a vendor, and then later documented for the working group. You'll note that they're "Informational," not standards-track, features. Working group consensus does NOT exist for standardizing the DNS options in IPCP described in RFC 1877. Based on that, I doubt that an argument for a standards-track extension for IPV6CP could be constructed. > so I figured that IPv6 address (instead of just the > interface ID, RFC5072), gateway information, IPv6 DNS information, even > prefix assignment are reasonable parameters to negotiate over PPP. I saw > that as a more efficient model over PPP link than RA and DHCPv6 > combined. It's not more efficient for the other vendors who will be forced to implement and reconcile duplicate configuration mechanisms. The server side looks "easy," but not so much for the client. What should a client do if the PPP extension tells him to use address A, but Neighbor Discovery says address B? Use both? Pick one? Neither? > In any case, thanks for the feedback. The point was to see if there is > interest in pursuing it further but I suppose that could have been found > out another way. I think you'll find it hard to build consensus around extensions like these. Even if you do, what's your plan for supporting non-PPP media? -- James Carlson 42.703N 71.076W From fitz@jfitz.com Mon Feb 8 13:36:14 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A4C3A729B for ; Mon, 8 Feb 2010 13:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.008 X-Spam-Level: **** X-Spam-Status: No, score=4.008 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_PACBELL_D=3.944, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_32=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5eXfa5jUg7U for ; Mon, 8 Feb 2010 13:36:13 -0800 (PST) Received: from jfitz.com (adsl-69-233-182-147.dsl.pltn13.pacbell.net [69.233.182.147]) by core3.amsl.com (Postfix) with SMTP id 16CA23A6A88 for ; Mon, 8 Feb 2010 13:36:13 -0800 (PST) Received: (qmail 91976 invoked from network); 8 Feb 2010 21:37:16 -0000 Received: from office-gw-vpn.jfitz.com (HELO ?192.168.12.77?) (192.168.12.77) by bub-vpn.jfitz.com with SMTP; 8 Feb 2010 21:37:10 -0000 From: John Fitzgibbon To: pppext@ietf.org Date: Mon, 8 Feb 2010 13:37:08 -0800 User-Agent: KMail/1.9.4 References: <00b801caa542$5d9daec0$18d90c40$@net> <2FFFD6E98F51BE43878BFED80215F83805512CB3@misout7msgusr7a.ugd.att.com> <4B7073C2.407@workingcode.com> In-Reply-To: <4B7073C2.407@workingcode.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201002081337.08488.fitz@jfitz.com> Cc: "HUANG, JERRY \(ATTLABS\)" Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 21:36:14 -0000 On Monday 08 February 2010 12:27, James Carlson wrote: > HUANG, JERRY (ATTLABS) wrote: > > Thanks for the pointer. And you are right that an archive search could > > have been done... > > > > I understand your point of RS/RA and DHCPv6 being already available and > > can/should be used for these configuration events on IP layer. In fact, > > these are actually the way Softwire Hub and Spoke [RFC5571] works. They > > are also the motivations behind this I-D: to avoid having to relying on > > them over the PPP link. Bringing in other subsystems can bring > > additional system complexity, as well as overhead such as DAD. While PPP > > Agreed on the additional complexity, which is why having a duplicate > mechanism to solve this problem -- the existing one in IPv6 Router > Discovery plus your proposed one added to IPV6CP in PPP -- is not in my > opinion helpful for the future. (We'll have to wait for other wg > members to chime in before declaring any sort of wg response, of course.) > > I understand the desire to optimize your own equipment for the purposes > it serves. However, our goal is to make the protocols work right for > the Internet in the longer term. Duplication does not help in that regard. I couldn't agree more. Having worked with multiple vendors testing cross-compatibility of their IPv6 implementations, (and in particular the standard configuration mechanisms, RS, NS/NS-DAD, DHCPv6, DHCPv6-PD), I can certainly attest to the complexity, but I agree that the last thing anyone would (should?) want at this point is a new link-specific configuration mechanism -- making PPP substantially different from, say, pure Ethernet would be a real headache. Both of these link types work just fine with the existing protocols. John Fitzgibbon > > > is a link layer protocol, it is also used to negotiate higher layer > > protocol parameters such as address [RFC1332] and DNS server [RFC1877] > > information, > > A closer reading will show that the IPv4 addresses are negotiated > because of the experience with SLIP. There is (or at least was at the > time) no native IP mechanism that allowed the detection of misconfigured > IP addresses on point-to-point (ARP-less) links, and silent mistakes > were common with SLIP. > > Thus, although a slight layering violation, address negotiation was > added to IPCP in PPP to avoid a known problem. > > Yes, it does at least partially overlap with DHCP/BOOTP functionality in > IPv4, and that is a known issue. Fortunately, if you're using IPCP for > IPv4 addresses, there's no conflict to use stateless DHCP INFORM to get > other configuration parameters. > > As for the DNS options, those were implemented and deployed by a vendor, > and then later documented for the working group. You'll note that > they're "Informational," not standards-track, features. Working group > consensus does NOT exist for standardizing the DNS options in IPCP > described in RFC 1877. > > Based on that, I doubt that an argument for a standards-track extension > for IPV6CP could be constructed. > > > so I figured that IPv6 address (instead of just the > > interface ID, RFC5072), gateway information, IPv6 DNS information, even > > prefix assignment are reasonable parameters to negotiate over PPP. I saw > > that as a more efficient model over PPP link than RA and DHCPv6 > > combined. > > It's not more efficient for the other vendors who will be forced to > implement and reconcile duplicate configuration mechanisms. The server > side looks "easy," but not so much for the client. What should a client > do if the PPP extension tells him to use address A, but Neighbor > Discovery says address B? Use both? Pick one? Neither? > > > In any case, thanks for the feedback. The point was to see if there is > > interest in pursuing it further but I suppose that could have been found > > out another way. > > I think you'll find it hard to build consensus around extensions like > these. > > Even if you do, what's your plan for supporting non-PPP media? From zh1424@att.com Mon Feb 8 13:48:48 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36A833A72A4 for ; Mon, 8 Feb 2010 13:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.859 X-Spam-Level: X-Spam-Status: No, score=-105.859 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvfWWYgME+-m for ; Mon, 8 Feb 2010 13:48:47 -0800 (PST) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 1989D3A6CD5 for ; Mon, 8 Feb 2010 13:48:47 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: zh1424@att.com X-Msg-Ref: server-2.tower-129.messagelabs.com!1265665789!29997421!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 27961 invoked from network); 8 Feb 2010 21:49:50 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Feb 2010 21:49:50 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o18Lnf5r018936; Mon, 8 Feb 2010 16:49:42 -0500 Received: from misout7msgusr7a.ugd.att.com (misout7msgusr7a.ugd.att.com [144.155.43.103]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o18Lnc9T018880; Mon, 8 Feb 2010 16:49:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Feb 2010 16:49:42 -0500 Message-ID: <2FFFD6E98F51BE43878BFED80215F83805512E88@misout7msgusr7a.ugd.att.com> In-Reply-To: <4B7073C2.407@workingcode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt Thread-Index: Acqo/TQjlPJL6Vu6Sa2RMv3u8xTiRQAAo64w References: <00b801caa542$5d9daec0$18d90c40$@net> <4B705B4E.6030405@workingcode.com> <2FFFD6E98F51BE43878BFED80215F83805512CB3@misout7msgusr7a.ugd.att.com> <4B7073C2.407@workingcode.com> From: "HUANG, JERRY (ATTLABS)" To: "James Carlson" Cc: pppext@ietf.org Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 21:48:48 -0000 Thanks. Some more responses inline. -- Jerry Huang, AT&T Labs, +1 630 719 4389 > -----Original Message----- > From: James Carlson [mailto:carlsonj@workingcode.com] > Sent: Monday, February 08, 2010 14:28 > To: HUANG, JERRY (ATTLABS) > Cc: Glen Zorn; pppext@ietf.org > Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt >=20 > HUANG, JERRY (ATTLABS) wrote: > > Thanks for the pointer. And you are right that an archive search could > > have been done... > > > > I understand your point of RS/RA and DHCPv6 being already available and > > can/should be used for these configuration events on IP layer. In fact, > > these are actually the way Softwire Hub and Spoke [RFC5571] works. They > > are also the motivations behind this I-D: to avoid having to relying on > > them over the PPP link. Bringing in other subsystems can bring > > additional system complexity, as well as overhead such as DAD. While PPP >=20 > Agreed on the additional complexity, which is why having a duplicate > mechanism to solve this problem -- the existing one in IPv6 Router > Discovery plus your proposed one added to IPV6CP in PPP -- is not in my > opinion helpful for the future. (We'll have to wait for other wg > members to chime in before declaring any sort of wg response, of course.) >=20 > I understand the desire to optimize your own equipment for the purposes > it serves. However, our goal is to make the protocols work right for > the Internet in the longer term. Duplication does not help in that regard. >=20 > > is a link layer protocol, it is also used to negotiate higher layer > > protocol parameters such as address [RFC1332] and DNS server [RFC1877] > > information, >=20 > A closer reading will show that the IPv4 addresses are negotiated > because of the experience with SLIP. There is (or at least was at the > time) no native IP mechanism that allowed the detection of misconfigured > IP addresses on point-to-point (ARP-less) links, and silent mistakes > were common with SLIP. >=20 > Thus, although a slight layering violation, address negotiation was > added to IPCP in PPP to avoid a known problem. >=20 > Yes, it does at least partially overlap with DHCP/BOOTP functionality in > IPv4, and that is a known issue. Fortunately, if you're using IPCP for > IPv4 addresses, there's no conflict to use stateless DHCP INFORM to get > other configuration parameters. >=20 > As for the DNS options, those were implemented and deployed by a vendor, > and then later documented for the working group. You'll note that > they're "Informational," not standards-track, features. Working group > consensus does NOT exist for standardizing the DNS options in IPCP > described in RFC 1877. >=20 > Based on that, I doubt that an argument for a standards-track extension > for IPV6CP could be constructed. Yes. RFC 1877 is Informational. I agree that calling for expanding the standards track scope for IPv6CP does not seem supportable.=20 > > so I figured that IPv6 address (instead of just the > > interface ID, RFC5072), gateway information, IPv6 DNS information, even > > prefix assignment are reasonable parameters to negotiate over PPP. I saw > > that as a more efficient model over PPP link than RA and DHCPv6 > > combined. >=20 > It's not more efficient for the other vendors who will be forced to > implement and reconcile duplicate configuration mechanisms. The server > side looks "easy," but not so much for the client. What should a client > do if the PPP extension tells him to use address A, but Neighbor > Discovery says address B? Use both? Pick one? Neither? Reasonable question. But the intent was to operate one way or the other in any single operational instance. Vendors will have to implement IPv6CP already along with RA/DHCPv6 options. Is the addition of these few options overly burdensome to existing IPv6CP code? I suppose working code will help. The scenarios might be: 1. Client with RFC5072 only + Server with RFC5072 and RA/DHCPv6 --> current documented behavior 2. Client w/ RFC5072 & proposed extension + Server with RFC5072 and RA/DHCPv6 --> falls back to (1) 3. Client with RFC5072 only + Server with RFC5072 & proposed extension and RA/DHCPv6 --> falls back to (1) 4. Client w/ RFC5072 & proposed extension + Server with RFC5072 & proposed extension and RA/DHCPv6 --> new behavior Servers not having RA/DHCPv6 support seem unlikely given the standards track status of 5072 and 5571.=20 Hmmm. While this draft may seem to simplify the end point configuration by doing it within the IPv6CP flow, in practice, does it really simplify things for implementers? Or solve a new problem?=20 > > In any case, thanks for the feedback. The point was to see if there is > > interest in pursuing it further but I suppose that could have been found > > out another way. >=20 > I think you'll find it hard to build consensus around extensions like these. >=20 > Even if you do, what's your plan for supporting non-PPP media? I think I see your point. If I am going to support non-PPP media on the same service box, would I not need to support RA/DHCPv6 or just DHCPv6 on it already, thus negating the need to extend IPv6CP? As the motivation for the draft arises from RFC 5571 within the Softwire Hub and Spoke's Softwire Concentrator and Initiator concept, the PPP sessions ride in L2TP over IPv4 or IPv6. The need to support non-PPP media directly is not apparent on the Concentrator at first blush.=20 Thanks for the discussion. It is very informative. I'll go read the relevant threads in the archives.=20 > -- > James Carlson 42.703N 71.076W From bernard_aboba@hotmail.com Mon Feb 8 13:57:29 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858FA28C193 for ; Mon, 8 Feb 2010 13:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.035 X-Spam-Level: X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPb4TvNqepgF for ; Mon, 8 Feb 2010 13:57:28 -0800 (PST) Received: from blu0-omc3-s24.blu0.hotmail.com (blu0-omc3-s24.blu0.hotmail.com [65.55.116.99]) by core3.amsl.com (Postfix) with ESMTP id C7FC128C166 for ; Mon, 8 Feb 2010 13:57:28 -0800 (PST) Received: from BLU137-DS6 ([65.55.116.74]) by blu0-omc3-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 13:58:32 -0800 X-Originating-IP: [131.107.0.103] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'John Fitzgibbon'" , References: <00b801caa542$5d9daec0$18d90c40$@net> <2FFFD6E98F51BE43878BFED80215F83805512CB3@misout7msgusr7a.ugd.att.com> <4B7073C2.407@workingcode.com> <201002081337.08488.fitz@jfitz.com> In-Reply-To: <201002081337.08488.fitz@jfitz.com> Date: Mon, 8 Feb 2010 13:58:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-index: AQHnuMQ+lgn/ierYOAzzyhdS6g6KxwJqR0LxAdOzfAAB2oitOpFR3c5A X-OriginalArrivalTime: 08 Feb 2010 21:58:32.0590 (UTC) FILETIME=[DAE7BAE0:01CAA909] Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 21:57:29 -0000 +1. John Fitzgibbon said: "I couldn't agree more. Having worked with multiple vendors testing cross-compatibility of their IPv6 implementations, (and in particular the standard configuration mechanisms, RS, NS/NS-DAD, DHCPv6, DHCPv6-PD), I can certainly attest to the complexity, but I agree that the last thing anyone would (should?) want at this point is a new link-specific configuration mechanism -- making PPP substantially different from, say, pure Ethernet would be a real headache. Both of these link types work just fine with the existing protocols." From carlsonj@workingcode.com Tue Feb 9 05:56:04 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C46E3A758C for ; Tue, 9 Feb 2010 05:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55xAsti9wh2d for ; Tue, 9 Feb 2010 05:56:03 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id DEEFB3A7589 for ; Tue, 9 Feb 2010 05:56:02 -0800 (PST) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o19DurYn025565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Feb 2010 08:56:54 -0500 (EST) Message-ID: <4B7169A4.2090006@workingcode.com> Date: Tue, 09 Feb 2010 08:56:52 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: "HUANG, JERRY (ATTLABS)" References: <00b801caa542$5d9daec0$18d90c40$@net> <4B705B4E.6030405@workingcode.com> <2FFFD6E98F51BE43878BFED80215F83805512CB3@misout7msgusr7a.ugd.att.com> <4B7073C2.407@workingcode.com> <2FFFD6E98F51BE43878BFED80215F83805512E88@misout7msgusr7a.ugd.att.com> In-Reply-To: <2FFFD6E98F51BE43878BFED80215F83805512E88@misout7msgusr7a.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-dmv.com-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 13:56:04 -0000 HUANG, JERRY (ATTLABS) wrote: > Reasonable question. But the intent was to operate one way or the other > in any single operational instance. Vendors will have to implement > IPv6CP already along with RA/DHCPv6 options. Is the addition of these > few options overly burdensome to existing IPv6CP code? I suppose working > code will help. The scenarios might be: > 1. Client with RFC5072 only + Server with RFC5072 and RA/DHCPv6 --> > current documented behavior > 2. Client w/ RFC5072 & proposed extension + Server with RFC5072 and > RA/DHCPv6 --> falls back to (1) > 3. Client with RFC5072 only + Server with RFC5072 & proposed extension > and RA/DHCPv6 --> falls back to (1) > 4. Client w/ RFC5072 & proposed extension + Server with RFC5072 & > proposed extension and RA/DHCPv6 --> new behavior > Servers not having RA/DHCPv6 support seem unlikely given the standards > track status of 5072 and 5571. > > Hmmm. While this draft may seem to simplify the end point configuration > by doing it within the IPv6CP flow, in practice, does it really simplify > things for implementers? Or solve a new problem? I believe it creates new problems. As we've seen with RFC 1877 deployment, there are vendors and administrators out there who will offer information only by way of that PPP mechanism, and not by way of the standards-track mechanisms. And there are users who have little choice but to comply. The result is that it forces other clients to implement both mechanisms, and that causes the data-integration problem I mentioned. It's not always clear when you should use one or the other. The scheme you're suggesting is one where successful negotiation of the new IPV6CP options trumps all other sources of information, and the existing standards-based ones are used only if the new feature is unavailable on one or both ends. But is that necessarily right? What if the server only offers these new options as a "convenience" to less-capable clients, and actually offers better service (and more information) via the standards-track mechanisms? Perhaps more importantly, the PPP-based mechanism described is a bit less capable than the other mechanisms. It's generally done once at connection establishment time and provides little in the way of customization mechanisms. What happens if the parameters change while the connection is running? What if particular classes of clients need different answers? What if particular vendors or users need local extensions to carry configuration information that's useful to them? What if two DNS server addresses aren't right, but three are? These are problems already solved in DHCP, but not solved here. >> Even if you do, what's your plan for supporting non-PPP media? > > I think I see your point. If I am going to support non-PPP media on the > same service box, would I not need to support RA/DHCPv6 or just DHCPv6 > on it already, thus negating the need to extend IPv6CP? As the Yes. > motivation for the draft arises from RFC 5571 within the Softwire Hub > and Spoke's Softwire Concentrator and Initiator concept, the PPP > sessions ride in L2TP over IPv4 or IPv6. The need to support non-PPP > media directly is not apparent on the Concentrator at first blush. Implementations and requirements change, but specifications are forever. What if a future deployment of "Hub and Spoke" uses Ethernet or some other link layer tunneled over L2TP? I *think* what you're describing is what's sometimes called a "walled garden:" a specific deployment (or set of deployments) with particular and consistent needs that are a either a subset of or distinct from the more diverse Internet. There's nothing particularly wrong with walled gardens, but there's also little reason to standardize what they do, at least within the IETF. The protocols used there can be ad-hoc (or set by some other standards group) without compromising the Internet itself. -- James Carlson 42.703N 71.076W From zh1424@att.com Tue Feb 9 23:01:05 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD8628C0F4 for ; Tue, 9 Feb 2010 23:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.004 X-Spam-Level: X-Spam-Status: No, score=-106.004 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULmp329a-Fo5 for ; Tue, 9 Feb 2010 23:01:04 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id D97773A68E9 for ; Tue, 9 Feb 2010 23:01:03 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: zh1424@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1265785331!40314579!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 11725 invoked from network); 10 Feb 2010 07:02:12 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Feb 2010 07:02:12 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1A724tm018504; Wed, 10 Feb 2010 02:02:04 -0500 Received: from misout7msgusr7a.ugd.att.com (misout7msgusr7a.ugd.att.com [144.155.43.103]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o1A71w3K018478; Wed, 10 Feb 2010 02:01:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Feb 2010 02:02:07 -0500 Message-ID: <2FFFD6E98F51BE43878BFED80215F838055933F9@misout7msgusr7a.ugd.att.com> In-Reply-To: <4B7169A4.2090006@workingcode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt Thread-Index: Acqpj8j56TmrmocuR3KoQIKBVwIUCQABZL2A References: <00b801caa542$5d9daec0$18d90c40$@net> <4B705B4E.6030405@workingcode.com> <2FFFD6E98F51BE43878BFED80215F83805512CB3@misout7msgusr7a.ugd.att.com> <4B7073C2.407@workingcode.com> <2FFFD6E98F51BE43878BFED80215F83805512E88@misout7msgusr7a.ugd.att.com> <4B7169A4.2090006@workingcode.com> From: "HUANG, JERRY (ATTLABS)" To: "James Carlson" Cc: pppext@ietf.org Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 07:01:05 -0000 > -----Original Message----- > From: James Carlson [mailto:carlsonj@workingcode.com] >=20 > HUANG, JERRY (ATTLABS) wrote: > > Reasonable question. But the intent was to operate one way or the other > > in any single operational instance. Vendors will have to implement > > IPv6CP already along with RA/DHCPv6 options. Is the addition of these > > few options overly burdensome to existing IPv6CP code? I suppose working > > code will help. The scenarios might be: [Scenario outlines deleted.] > > Servers not having RA/DHCPv6 support seem unlikely given the standards > > track status of 5072 and 5571. > > > > Hmmm. While this draft may seem to simplify the end point configuration > > by doing it within the IPv6CP flow, in practice, does it really simplify > > things for implementers? Or solve a new problem? >=20 > I believe it creates new problems. >=20 > As we've seen with RFC 1877 deployment, there are vendors and > administrators out there who will offer information only by way of that > PPP mechanism, and not by way of the standards-track mechanisms. And > there are users who have little choice but to comply. The result is > that it forces other clients to implement both mechanisms, and that > causes the data-integration problem I mentioned. It's not always clear > when you should use one or the other. >=20 > The scheme you're suggesting is one where successful negotiation of the > new IPV6CP options trumps all other sources of information, and the > existing standards-based ones are used only if the new feature is > unavailable on one or both ends. But is that necessarily right? What > if the server only offers these new options as a "convenience" to > less-capable clients, and actually offers better service (and more > information) via the standards-track mechanisms? >=20 > Perhaps more importantly, the PPP-based mechanism described is a bit > less capable than the other mechanisms. It's generally done once at > connection establishment time and provides little in the way of > customization mechanisms. What happens if the parameters change while > the connection is running? What if particular classes of clients need > different answers? What if particular vendors or users need local > extensions to carry configuration information that's useful to them? > What if two DNS server addresses aren't right, but three are? Given the scenario is PPP in L2TP, changes in parameters can be accommodated via L2TP control messages (CDN, etc) and allow the PPP session to be renegotiated, right? Classes of users are accommodated via AAA (RADIUS) so different configuration parameters can be returned. Vendor-Specific-Attributes can probably handle local extensions. > These are problems already solved in DHCP, but not solved here. >=20 > >> Even if you do, what's your plan for supporting non-PPP media? > > > > I think I see your point. If I am going to support non-PPP media on the > > same service box, would I not need to support RA/DHCPv6 or just DHCPv6 > > on it already, thus negating the need to extend IPv6CP? As the >=20 > Yes. >=20 > > motivation for the draft arises from RFC 5571 within the Softwire Hub > > and Spoke's Softwire Concentrator and Initiator concept, the PPP > > sessions ride in L2TP over IPv4 or IPv6. The need to support non-PPP > > media directly is not apparent on the Concentrator at first blush. >=20 > Implementations and requirements change, but specifications are forever. >=20 > What if a future deployment of "Hub and Spoke" uses Ethernet or some > other link layer tunneled over L2TP? >=20 > I *think* what you're describing is what's sometimes called a "walled > garden:" a specific deployment (or set of deployments) with particular > and consistent needs that are a either a subset of or distinct from the > more diverse Internet. There's nothing particularly wrong with walled > gardens, but there's also little reason to standardize what they do, at > least within the IETF. The protocols used there can be ad-hoc (or set > by some other standards group) without compromising the Internet itself. I was thinking more in terms of dial network and (potential) RFC 5571 implementation scenarios and attempted to extend the IPCP model for IPv4 straight-forwardly to IPv6. IMHO, in those cases, IP address assignment by the NAS/LNS model could still make sense without invoking RA and/or DHCPv6 mechanisms. But I concede that in reality the proposal probably doesn't provide the benefits I was hoping to get, mainly because it adds to implementation requirements, instead of reducing them.=20 > -- > James Carlson 42.703N 71.076W Thanks for the discussion, -- Jerry Huang, AT&T Labs, +1 630 719 4389 [Not speaking for my employer in any way, shape or form.] From carlsonj@workingcode.com Wed Feb 10 06:17:55 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFAB93A76EC for ; Wed, 10 Feb 2010 06:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHbblIrs0inP for ; Wed, 10 Feb 2010 06:17:54 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id DEFA33A76E6 for ; Wed, 10 Feb 2010 06:17:53 -0800 (PST) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o1AEIqbw013202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Feb 2010 09:18:52 -0500 (EST) Message-ID: <4B72C04C.20906@workingcode.com> Date: Wed, 10 Feb 2010 09:18:52 -0500 From: James Carlson User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100103 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: "HUANG, JERRY (ATTLABS)" References: <00b801caa542$5d9daec0$18d90c40$@net> <4B705B4E.6030405@workingcode.com> <2FFFD6E98F51BE43878BFED80215F83805512CB3@misout7msgusr7a.ugd.att.com> <4B7073C2.407@workingcode.com> <2FFFD6E98F51BE43878BFED80215F83805512E88@misout7msgusr7a.ugd.att.com> <4B7169A4.2090006@workingcode.com> <2FFFD6E98F51BE43878BFED80215F838055933F9@misout7msgusr7a.ugd.att.com> In-Reply-To: <2FFFD6E98F51BE43878BFED80215F838055933F9@misout7msgusr7a.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-dmv.com-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 14:17:56 -0000 On 02/10/10 02:02, HUANG, JERRY (ATTLABS) wrote: >> From: James Carlson [mailto:carlsonj@workingcode.com] >> Perhaps more importantly, the PPP-based mechanism described is a bit >> less capable than the other mechanisms. It's generally done once at >> connection establishment time and provides little in the way of >> customization mechanisms. What happens if the parameters change while >> the connection is running? What if particular classes of clients need >> different answers? What if particular vendors or users need local >> extensions to carry configuration information that's useful to them? >> What if two DNS server addresses aren't right, but three are? > > Given the scenario is PPP in L2TP, changes in parameters can be > accommodated via L2TP control messages (CDN, etc) and allow the PPP > session to be renegotiated, right? Classes of users are accommodated > via AAA (RADIUS) so different configuration parameters can be returned. > Vendor-Specific-Attributes can probably handle local extensions. RADIUS doesn't have client classes the way DHCP does, but that's perhaps a minor point. A larger point is that the scheme you're describing is actually a bit worse. There's no defined way for RADIUS to tell the client that parameters need to be negotiated. You'd have to invent some way of telling PPP to restart from scratch -- because RADIUS depends on an authentication session -- any time a parameter changed on the RADIUS server. Or you'd have to configure the PPP clients to do a restart periodically just to check whether there are changes. In contrast, DHCP obliges the clients to refresh their parameters periodically, and (with v6) even includes an optional server-to-client refresh mechanism. In addition to that, DHCP doesn't require a new round of authentication, nor does it involve tearing down the IP link just to change a DNS server address. The checks are "hitless." Without RADIUS in the picture, and with the needed parameters somehow present on the PPP "server," you'd still need to have IPCP restart, which (for most implementations) would still cause an unnecessary link bounce. In some peers, though, layer restart is known to trigger bugs that will cause link failure. (Obviously not a specification issue, as the spec is clear on what should happen, but a deployment issue none the less.) On top of that, DHCP is dirt cheap. If all you need are configuration parameters, then you just need DHCPv6 Information. It's a UDP request/response, without much in the way of overhead. The "simplicity" argument in favor of new PPP options unfortunately also runs into the usual counter-argument: computer capacity limitations (even for the tiniest of embedded systems) are fleeting things in comparison to the longevity of protocols. We're still using the same basic TCP/IP that was originally deployed in 1982. Imagine if the computer system limitations back then were encoded into the base protocols. Again, the archive should be consulted here. We've discussed at length the problems in this concept when it's deployed outside of a walled garden. For essentially the same reason that it makes no sense to have an Ethernet NIC caring about DNS addresses, it also makes no sense to have PPP handling them. >> more diverse Internet. There's nothing particularly wrong with walled >> gardens, but there's also little reason to standardize what they do, > at >> least within the IETF. The protocols used there can be ad-hoc (or set >> by some other standards group) without compromising the Internet > itself. > > I was thinking more in terms of dial network and (potential) RFC 5571 > implementation scenarios and attempted to extend the IPCP model for IPv4 > straight-forwardly to IPv6. IMHO, in those cases, IP address assignment > by the NAS/LNS model could still make sense without invoking RA and/or > DHCPv6 mechanisms. But I concede that in reality the proposal probably > doesn't provide the benefits I was hoping to get, mainly because it adds > to implementation requirements, instead of reducing them. Exactly. For a robust and interoperable implementation, you'd actually have to include both mechanisms. It's only inside of the previously mentioned walled gardens (where interoperability is tightly constrained) that this can be safely ignored. That makes it more complex. Or as a wise IETF-er once said, a specification isn't complete when there's nothing left to add, but rather not until there's nothing left to remove. -- James Carlson 42.703N 71.076W From d3e3e3@gmail.com Wed Feb 10 18:22:09 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CD13A6F05 for ; Wed, 10 Feb 2010 18:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHwhilN72mDJ for ; Wed, 10 Feb 2010 18:22:07 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id ECFC33A68C7 for ; Wed, 10 Feb 2010 18:22:06 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 22so224917eye.51 for ; Wed, 10 Feb 2010 18:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=BUgHLIPc+JxnSr59USYBzTqkrh0OGX6J0eowCIupjEs=; b=js8Ne1PPrmQInblg3C+8tDtuY+U+LjiTEAMrQ7WGqk7DhILcQhzgAJRmO4WJN3WcYO 45lcnjuVdNoDVqQyY8/rL100yxvUtmmGAJ9webv8cqX9oIGbVBP+SDuKx9y8JJSejx8i pQVqF/X2+S3Vj6LGd1SnK1Y5n6gg+cVtoRRKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vFQunwQiVh/QRFl3owpTEv1GN2tM/A2jv8CzDHwCQhmZFXJN9Cpz5n5aCtRAmHfGzx murxFuGwbo7cAdRK56i8eobhQU3+QAi9Odo1pZaPp16mFiCV7PUlGMk83LCq1/2f6gph ITlAkK3iS18vskcmdog2m/dZ5CqX1pow/i35s= MIME-Version: 1.0 Received: by 10.216.90.137 with SMTP id e9mr653937wef.141.1265854995961; Wed, 10 Feb 2010 18:23:15 -0800 (PST) In-Reply-To: <4B72C04C.20906@workingcode.com> References: <00b801caa542$5d9daec0$18d90c40$@net> <4B705B4E.6030405@workingcode.com> <2FFFD6E98F51BE43878BFED80215F83805512CB3@misout7msgusr7a.ugd.att.com> <4B7073C2.407@workingcode.com> <2FFFD6E98F51BE43878BFED80215F83805512E88@misout7msgusr7a.ugd.att.com> <4B7169A4.2090006@workingcode.com> <2FFFD6E98F51BE43878BFED80215F838055933F9@misout7msgusr7a.ugd.att.com> <4B72C04C.20906@workingcode.com> Date: Wed, 10 Feb 2010 21:23:15 -0500 Message-ID: <1028365c1002101823n7e6b94d0q8d32765cf2cb1acf@mail.gmail.com> From: Donald Eastlake To: James Carlson Content-Type: multipart/alternative; boundary=0016e6d99cd75f160b047f49d5e2 Cc: pppext@ietf.org, "HUANG, JERRY \(ATTLABS\)" Subject: Re: [Pppext] FW: I-D Action:draft-huang-ipv6cp-options-00.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 02:22:09 -0000 --0016e6d99cd75f160b047f49d5e2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Feb 10, 2010 at 9:18 AM, James Carlson wr= ote: > ... > > Or as a wise IETF-er once said, a specification isn't complete when > there's nothing left to add, but rather not until there's nothing left > to remove. I think the origin was French writer and aviator Antoine de Saint - Exup=E9= ry who, in his popular novella The Little Prince (Le Petit Prince, published i= n 1943) wrote "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Actually "La perfection est atteinte non quand il ne reste rien =E0 ajounter, mais quand il ne reste rien =E0 enlever."). Donald -- > James Carlson 42.703N 71.076W > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext > --0016e6d99cd75f160b047f49d5e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 10, 2010 at 9:18 AM, James Carlson <= span dir=3D"ltr"><carlsonj@workingcode.com> wrote:
...=A0

Or as a wise IETF-er once said, a specification isn't complete when
there's nothing left to add, but rather not until there's nothing l= eft
to remove.

I think the origin was French wr= iter and aviator=A0Antoine de Saint - Exup=E9ry who, in his popular novella= The Little Prince (Le Petit Prince, published in 1943) wrote=A0"Perfe= ction is achieved, not when there is nothing more to add, but when there is= nothing left to take away." (Actually "La perfection est atteint= e non quand il ne reste rien =E0 ajounter, mais
quand il ne reste rien =E0 enlever.").

Donald

--
James Carlson =A0 =A0 =A0 =A0 42.703N 71.076W =A0 =A0 =A0 =A0 &= lt;carlsonj@w= orkingcode.com>
_______________________________________________<= br> Pppext mailing list
Pppext@ietf.org = https://www.ietf.org/mailman/listinfo/pppext

--0016e6d99cd75f160b047f49d5e2-- From asbafail@gmail.com Mon Feb 15 11:38:16 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C05828C0F0 for ; Mon, 15 Feb 2010 11:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.822 X-Spam-Level: ** X-Spam-Status: No, score=2.822 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EMPTY_MESSAGE=1.439, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klo9GMhKVJLn for ; Mon, 15 Feb 2010 11:38:15 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 915E03A7BD0 for ; Mon, 15 Feb 2010 11:38:15 -0800 (PST) Received: by fxm7 with SMTP id 7so6184425fxm.28 for ; Mon, 15 Feb 2010 11:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=apGpbG+lDY31NG7M9E9ph60aPs1GngQHrbYVXTq5Pg8=; b=DuhiSZGl3BDreHGKSisseku0H7sd+noDI/Fx0YvL8LVssMlBEmYHGPuHRHB2bxAcwi zxNIIbjjQlEqSCtFjhdGfKeP2Fw6H/0KdndAvWwWFyc6gVhJ786aGyi78NE7GZgcspFd kzyUW2/0jqAeKuqcAgkjAZhsro6NPRdRAMTos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FiFderc7Qn1lMHpcCft0fL5ELCaxNEcGaG9ckoCubE1hbwpcbjXWGdkv+PX5WjCXOA 9HUxuSFSrbN7OgVVBaeeCcQwDySxfV/jFcGa5J0g0S9DJvIIODfV+4e1sf2fokP6SNDl tL3yRSJK6KbJjdQ+l1SPoRGTV//nYV+o+kZcU= MIME-Version: 1.0 Received: by 10.103.122.14 with SMTP id z14mr4146548mum.10.1266262782699; Mon, 15 Feb 2010 11:39:42 -0800 (PST) Date: Mon, 15 Feb 2010 22:39:42 +0300 Message-ID: <2d2251c01002151139q66da4f64pb3c81f5332a8ba2f@mail.gmail.com> From: Ali Bafail To: pppext@ietf.org Content-Type: multipart/alternative; boundary=0016e65aed4a5ae8fe047fa8c763 Subject: [Pppext] (no subject) X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 19:38:16 -0000 --0016e65aed4a5ae8fe047fa8c763 Content-Type: text/plain; charset=ISO-8859-1 --0016e65aed4a5ae8fe047fa8c763 Content-Type: text/html; charset=ISO-8859-1
--0016e65aed4a5ae8fe047fa8c763-- From wwwrun@rfc-editor.org Mon Feb 22 18:14:51 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E00B28C4E9 for ; Mon, 22 Feb 2010 18:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhjHOgGQbvhM for ; Mon, 22 Feb 2010 18:14:50 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 2257D28C20D for ; Mon, 22 Feb 2010 18:14:50 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 193E6130016; Mon, 22 Feb 2010 18:16:50 -0800 (PST) To: gurdeep@microsoft.com, palter@zev.net, acr@del.com, townsley@cisco.com, vandys@cisco.com, gwz@acm.org, rdroms.ietf@gmail.com, jari.arkko@piuha.net, james.d.carlson@sun.com From: RFC Errata System Message-Id: <20100223021651.193E6130016@rfc-editor.org> Date: Mon, 22 Feb 2010 18:16:50 -0800 (PST) X-Mailman-Approved-At: Tue, 23 Feb 2010 06:06:20 -0800 Cc: pppext@ietf.org, whj@puzhong.org, rfc-editor@rfc-editor.org Subject: [Pppext] [Technical Errata Reported] RFC2661 (2049) X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 02:14:51 -0000 The following errata report has been submitted for RFC2661, "Layer Two Tunneling Protocol "L2TP"". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2661&eid=2049 -------------------------------------- Type: Technical Reported by: Wang Haojian Section: 1.2 Original Text ------------- DSLAM Digital Subscriber Line (DSL) Access Module Corrected Text -------------- DSLAM Digital Subscriber Line (DSL) Access Multiplexer Notes ----- I think 'Multiplexer' is more appropriate Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2661 (draft-ietf-pppext-l2tp-16) -------------------------------------- Title : Layer Two Tunneling Protocol "L2TP" Publication Date : August 1999 Author(s) : W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter Category : PROPOSED STANDARD Source : Point-to-Point Protocol Extensions Area : Internet Stream : IETF Verifying Party : IESG From yprasad@juniper.net Tue Feb 23 02:03:24 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D5028C24C for ; Tue, 23 Feb 2010 02:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.814 X-Spam-Level: X-Spam-Status: No, score=-5.814 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEm7slc5RFyP for ; Tue, 23 Feb 2010 02:03:15 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 09E7428C275 for ; Tue, 23 Feb 2010 02:03:13 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKS4OoWysK/0gkSiJGGHO5gbBO1LhrwRwj@postini.com; Tue, 23 Feb 2010 02:05:16 PST Received: from gaugeboson.jnpr.net (10.209.194.17) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server id 8.1.393.1; Tue, 23 Feb 2010 02:04:36 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB46F.4D36D8EF" Date: Tue, 23 Feb 2010 15:32:26 +0530 Message-ID: <0DB0FFEA6887E349861A3F6B40D71C3A054E3439@gaugeboson.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LCP echo request/reply support over multilink interface (RFC 1990) Thread-Index: Acq0WhNrJLAfAqi6SsmabrIYPvuWVQ== From: Y Prasad To: X-Mailman-Approved-At: Tue, 23 Feb 2010 06:06:20 -0800 Cc: Y Prasad Subject: [Pppext] LCP echo request/reply support over multilink interface (RFC 1990) X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 10:03:24 -0000 ------_=_NextPart_001_01CAB46F.4D36D8EF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20 =20 Can you please help me to understand how LCP echo request/response can be supported on a bundle?=20 =20 Page no.4 of RFC 1990 says below. =20 LCP negotiations are not permitted on the bundle itself. An implementation MUST NOT transmit LCP Configure-Request, -Reject, -Ack, -Nak, Terminate-Request or -Ack packets via the multilink procedure, and an implementation receiving them MUST silently discard them. (By "silently discard" we mean to not generate any PPP packets in response; an implementation is free to generate a log entry registering the reception of the unexpected packet). By contrast, other LCP packets having control functions not associated with changing the defaults for the bundle itself are permitted. An implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo- Request, Echo-Reply and Discard-Request Packets. =20 =20 "Bundle interface is a virtual interface. If there has to be LCP keep alive on it, it has to go through one of the underlying physical links. But LCP keep alive packet format does not seem to specify any interface details. How does the remote identify that the LCP echo received on a physical link belongs to bundle? =20 Regards yp =20 =20 =20 =20 ------_=_NextPart_001_01CAB46F.4D36D8EF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

Can you please help me to = understand how LCP echo request/response can be supported on a bundle? =

 

Page no.4 of RFC 1990 says = below.

 

LCP negotiations are not permitted on the =
bundle itself.  An
   implementation MUST NOT transmit =
LCP Configure-Request, -Reject,
   -Ack, -Nak, Terminate-Request or =
-Ack packets via the multilink
   procedure, and an implementation =
receiving them MUST silently =
discard
   them.  (By "silently =
discard" we mean to not generate any PPP =
packets
   in response; an implementation =
is free to generate a log entry
   registering the reception of the =
unexpected packet).  By =
contrast,
   other LCP packets having control =
functions not associated with
   changing the defaults for the =
bundle itself are permitted.  =
An
   implementation MAY transmit LCP =
Code-Reject, Protocol-Reject, =
Echo-
   Request, Echo-Reply and =
Discard-Request Packets.
 

 

“Bundle interface is a virtual interface. If there has to be LCP keep alive on = it, it has to go through one of the underlying physical links. But LCP keep = alive packet format does not seem to specify any interface details. How does = the remote identify that the LCP echo received on a physical link belongs to = bundle?

 

Regards

yp

 

 

 

 

------_=_NextPart_001_01CAB46F.4D36D8EF-- From carlsonj@workingcode.com Tue Feb 23 06:32:38 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417BE28C125 for ; Tue, 23 Feb 2010 06:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip7w+Ikb4IfG for ; Tue, 23 Feb 2010 06:32:37 -0800 (PST) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 4162828C122 for ; Tue, 23 Feb 2010 06:32:37 -0800 (PST) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.3) with ESMTP id o1NEYYQJ020469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 09:34:36 -0500 (EST) Message-ID: <4B83E77A.8050708@workingcode.com> Date: Tue, 23 Feb 2010 09:34:34 -0500 From: James Carlson User-Agent: Thunderbird 2.0.0.22 (X11/20090605) MIME-Version: 1.0 To: Y Prasad References: <0DB0FFEA6887E349861A3F6B40D71C3A054E3439@gaugeboson.jnpr.net> In-Reply-To: <0DB0FFEA6887E349861A3F6B40D71C3A054E3439@gaugeboson.jnpr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-DCC-dmv.com-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] LCP echo request/reply support over multilink interface (RFC 1990) X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 14:32:38 -0000 Y Prasad wrote: > “Bundle interface is a virtual interface. If there has to be LCP keep > alive on it, it has to go through one of the underlying physical links. > But LCP keep alive packet format does not seem to specify any interface > details. How does the remote identify that the LCP echo received on a > physical link belongs to bundle? If you run those non-negotiation LCP messages on the bundle, they may need to be encapsulated using RFC 1990 fragment headers if you want to segregate bundle and link level traffic. You're not required to do that, though. In general, this is more of an implementation issue than anything else. For example, you need to inspect LCP Protocol-Reject messages to deliver them properly. If the rejected protocol is one of the few per-link protocols, then it should be handled at the link level. If not, then it should be communicated upwards to the bundle head for processing. Some implementations will deliver LCP errors at the link level that are targeting problems detected at the bundle level. You must be prepared to handle that. In the case of LCP Echo Request, if you implement that only at the bundle level, then you can send requests without encapsulation and simply have all of the received LCP Echo Reply messages forwarded up to the bundle head. If you implement only at the link level, then process them there, again without encapsulation. In short, since you know how you send your requests, you can decide how you want to process the replies. (And since implementing at both levels at the same time would likely not serve much of a purpose, it would probably be wise to choose one and stick with it. I'd recommend link-level, as it's links that usually run into trouble, but it's your code ...) Note that packets sent at the bundle level are _not_ required to have MP fragment headers. Using those headers guarantees ordering and reassembly where needed, but it's not a requirement -- either for signaling messages or for user data. The only special action needed to ensure interoperability is that when an implementation receives a bare LCP Echo-Request, it must reply on the same link. -- James Carlson 42.703N 71.076W From gwz@net-zen.net Tue Feb 23 19:04:56 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4723A829F for ; Tue, 23 Feb 2010 19:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyZl50k9uk3l for ; Tue, 23 Feb 2010 19:04:55 -0800 (PST) Received: from smtpauth03.prod.mesa1.secureserver.net (smtpauth03.prod.mesa1.secureserver.net [64.202.165.183]) by core3.amsl.com (Postfix) with SMTP id 933A03A8280 for ; Tue, 23 Feb 2010 19:04:55 -0800 (PST) Received: (qmail 27641 invoked from network); 24 Feb 2010 03:07:00 -0000 Received: from unknown (124.122.101.86) by smtpauth03.prod.mesa1.secureserver.net (64.202.165.183) with ESMTP; 24 Feb 2010 03:06:59 -0000 From: "Glen Zorn" To: "'RFC Errata System'" , , , , , , , , References: <20100223021651.193E6130016@rfc-editor.org> In-Reply-To: <20100223021651.193E6130016@rfc-editor.org> Date: Wed, 24 Feb 2010 10:06:39 +0700 Organization: Network Zen Message-ID: <022d01cab4fe$65ae6020$310b2060$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq0kaqpQJTU4vdJTGqRb3LcyEqXjgAbHKLw Content-Language: en-us X-Mailman-Approved-At: Tue, 23 Feb 2010 19:06:33 -0800 Cc: pppext@ietf.org, whj@puzhong.org Subject: Re: [Pppext] [Technical Errata Reported] RFC2661 (2049) X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 03:04:56 -0000 > The following errata report has been submitted for RFC2661, > "Layer Two Tunneling Protocol "L2TP"". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=2661&eid=2049 > > -------------------------------------- > Type: Technical > Reported by: Wang Haojian > > Section: 1.2 > > Original Text > ------------- > DSLAM > > Digital Subscriber Line (DSL) Access Module > > Corrected Text > -------------- > DSLAM > > Digital Subscriber Line (DSL) Access Multiplexer > > Notes > ----- > I think 'Multiplexer' is more appropriate > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. I think that classifying this as a technical error may be stretching it a bit, but I have no problem w/the change. > > -------------------------------------- > RFC2661 (draft-ietf-pppext-l2tp-16) > -------------------------------------- > Title : Layer Two Tunneling Protocol "L2TP" > Publication Date : August 1999 > Author(s) : W. Townsley, A. Valencia, A. Rubens, G. Pall, G. > Zorn, B. Palter > Category : PROPOSED STANDARD > Source : Point-to-Point Protocol Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www.ietf.org/mailman/listinfo/pppext From jari.arkko@piuha.net Tue Feb 23 21:54:07 2010 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 730553A84EC for ; Tue, 23 Feb 2010 21:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xf89CF8gtQP for ; Tue, 23 Feb 2010 21:54:06 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D87A33A7A63 for ; Tue, 23 Feb 2010 21:54:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D6C1C2D291; Wed, 24 Feb 2010 07:56:09 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcjfZzALlIR1; Wed, 24 Feb 2010 07:56:09 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id B737C2D287; Wed, 24 Feb 2010 07:56:08 +0200 (EET) Message-ID: <4B84BF77.70103@piuha.net> Date: Wed, 24 Feb 2010 07:56:07 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Glen Zorn References: <20100223021651.193E6130016@rfc-editor.org> <022d01cab4fe$65ae6020$310b2060$@net> In-Reply-To: <022d01cab4fe$65ae6020$310b2060$@net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 24 Feb 2010 07:14:26 -0800 Cc: "pppext@ietf.org" , "palter@zev.net" , "whj@puzhong.org" , "james.d.carlson@sun.com" , "vandys@cisco.com" , "gurdeep@microsoft.com" , "rdroms.ietf@gmail.com" , "acr@del.com" , "townsley@cisco.com" , 'RFC Errata System' Subject: Re: [Pppext] [Technical Errata Reported] RFC2661 (2049) X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 05:54:07 -0000 Its editorial. I agree with the errata. Based on our policies below I believe the right classification is Hold for Document Update.

http://www.ietf.org/iesg/statement/errata-processing.html

Jari

Glen Zorn kirjoitti: 
The following errata report has been submitted for RFC2661,
"Layer Two Tunneling Protocol "L2TP"".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=2661&eid=2049

--------------------------------------
Type: Technical
Reported by: Wang Haojian <whj@puzhong.org>

Section: 1.2

Original Text
-------------
DSLAM

Digital Subscriber Line (DSL) Access Module

Corrected Text
--------------
DSLAM

Digital Subscriber Line (DSL) Access Multiplexer

Notes
-----
I think 'Multiplexer' is more appropriate

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.
    

I think that classifying this as a technical error may be stretching it a
bit, but I have no problem w/the change.

  
--------------------------------------
RFC2661 (draft-ietf-pppext-l2tp-16)
--------------------------------------
Title               : Layer Two Tunneling Protocol "L2TP"
Publication Date    : August 1999
Author(s)           : W. Townsley, A. Valencia, A. Rubens, G. Pall, G.
Zorn, B. Palter
Category            : PROPOSED STANDARD
Source              : Point-to-Point Protocol Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www.ietf.org/mailman/listinfo/pppext
    


_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www.ietf.org/mailman/listinfo/pppext