Re: [Pppext] new PPP-related individual submission
James Carlson <carlsonj@workingcode.com> Mon, 13 September 2010 13:18 UTC
Return-Path: <carlsonj@workingcode.com>
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 38F1E3A69B9 for <pppext@core3.amsl.com>; Mon, 13 Sep 2010 06:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.441
X-Spam-Level:
X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, 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 bkAIlD+qBXNA for <pppext@core3.amsl.com>; Mon, 13 Sep 2010 06:18:48 -0700 (PDT)
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 DA9CB3A6826 for <pppext@ietf.org>; Mon, 13 Sep 2010 06:18:47 -0700 (PDT)
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.4) with ESMTP id o8DDJ30e010019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Sep 2010 09:19:03 -0400 (EDT)
Message-ID: <4C8E24C7.2010609@workingcode.com>
Date: Mon, 13 Sep 2010 09:19:03 -0400
From: James Carlson <carlsonj@workingcode.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: mohamed.boucadair@orange-ftgroup.com
References: <4C87A4AC.10404@workingcode.com> <4C87D7D6.3000606@workingcode.com> <13692_1284361742_4C8DCE0E_13692_114058_1_94C682931C08B048B7A8645303FDC9F31C50646461@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <13692_1284361742_4C8DCE0E_13692_114058_1_94C682931C08B048B7A8645303FDC9F31C50646461@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-DCC-x.dcc-servers-Metrics: carlson; whitelist
Cc: "pppext@ietf.org" <pppext@ietf.org>, "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>, VILLEFRANQUE Alain RD-BIZZ <alain.villefranque@orange-ftgroup.com>, GRIMAULT Jean-Luc RD-MAPS <jeanluc.grimault@orange-ftgroup.com>, LEVIS Pierre RD-BIZZ <pierre.levis@orange-ftgroup.com>, "teemu.savolainen@nokia.com" <teemu.savolainen@nokia.com>
Subject: Re: [Pppext] new PPP-related individual submission
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2010 13:18:51 -0000
mohamed.boucadair@orange-ftgroup.com wrote: > FYI, a new updated version is available at: http://www.ietf.org/id/draft-boucadair-pppext-portrange-option-03.txt Thanks for the update. If possible, standard quoting would be appreciated. Otherwise, it'll become hard to attribute text to authors in the thread. > De : James Carlson [mailto:carlsonj@workingcode.com] > Envoyé : mercredi 8 septembre 2010 20:37 > > So, in reference to IPv6 tunnel deployment, is it true that only 6to4 > > addresses can be supported by this mechanism? Are there any IPv6 > > providers doing that? > Med: Architectural issues are out of scope of this document. Please refer to http://tools.ietf.org/html/draft-boucadair-port-range-02 or http://tools.ietf.org/html/draft-ymbk-aplusp-05 for more architectural discussion. BTW, an IPv6-centric solution is defined in http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04. Those references seem to indicate that only certain "structured" IPv6 addresses will work with this scheme, which I think answers my question. I understand that it's out of scope for this particular draft. The reason I asked was to be sure I understood the material. > > As a third architectural issue, what happens when two distinct end > > systems sharing a single IP address but with distinct port ranges > > attempt to talk to each other? How does one of these devices know that > > the IP packet being sent isn't destined locally for an unavailable port? > > What changes are necessary to RFC 791 itself to make external > > transmission of for-self packets possible? > > > Med: This is not an issue. Please refer to tests that we have undertaken to assess this behaviour http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange-02#section-4.3 and the results are listed in http://tools.ietf.org/html/draft-boucadair-behave-bittorrent-portrange-02#section-5. These tests demonstrated that no issue has been encountered when two machines having the same IP address communicate together. I don't believe those reference materials answer my question, because the modifications on CPE-1 and CPE-2 that must have been necessary seem not to be described. To make the question more detailed in the context of this draft: I do not understand how the IP stack in CPE-1 could have a packet with destination address 193.51.145.206 and then decide that this packet belongs to CPE-2 (and thus needs to be forwarded to PRR) without modifications to the IP stack that cause inspection of the transport layer headers. I suspect that one of the underlying assumptions here is that peer-to-peer communication is not necessarily possible. T1 cannot send packets that go straight to T2. > > (For what it's worth, I think that if the draft were disconnected from > > the address assignment mechanism, it would be better for all involved. > > What I think this system really represents is a way to configure remote > > NAT systems at the customer site(s) with non-overlapping port ranges on > > shared IP addresses. That should be a helpful feature regardless of how > > addresses are assigned or what datalink layer protocol is in use. There > > should be a "discover NAT configuration" protocol; perhaps implemented > > using DHCP INFORM or similar protocol.) > > Med: I added this note to the introduction: "IPv4 address exhaustion is only provided as an example of the usage of the PPP IPCP Options defined in this document. In particular, Port Range Options may be used independently of the presence of IP-Address IPCP Option." That's an improvement, but not what I was suggesting. To make it more direct: I am unconvinced that transport-layer port range restrictions are really the sort of issue that should be negotiated down at the datalink (PPP) layer. There ought to be a more common way to do this. > > Getting closer to the draft details, it seems that you've got DHCP hooks > > for this feature. That's good. But why can't those same hooks be used > > over PPP? Either negotiate private addresses or no addresses at all (if > > you wish) and then just do the same port-range allocation you'd do via > > DHCP. Why modify both DHCP and PPP? > > Med: Because some operators have PPP in their networks and not DHCP. I don't understand that answer. PPP and DHCP are in no way mutually exclusive protocols. Should we eventually add all DHCP options into PPP? Why? How hard is it to send a single UDP packet and get one in reply for DHCP INFORM? How hard is it compared to modifying many different PPP implementations around the world? If we could get away with adding an option to just one more general protocol rather than two separate protocols, wouldn't that be a simpler result? > > I don't understand how this option can be considered "MANDATORY," as > > there are many PPP implementations out in the field, and we (the IETF) > > have no power to force any of them to change. Some commentary on this > > might be needed. (Perhaps what the draft means here is that if the BRAS > > device's policy insists on port ranges, and the peer doesn't agree, then > > the link should fail. In that case, I don't think sending back an IPCP > > Configure-Ack for 0.0.0.0 is wise. It'd be much better to do an > > unsolicited IPCP Configure-Nak, or an LCP Protocol-Reject for IPCP, or > > even LCP Terminate-Request instead. Agreeing to 0.0.0.0 is quite > > misleading.) > > Med: The options are not mandatory. The text you are referring to was about an example where the server can only assign shared IP addresses; otherwise 0.0.0.0 is returned. I suggest a rewording to avoid "mandatory." Perhaps "required by the BRAS policy configuration" would be more accurate. In any event, I do not think it's wise to send IPCP Configure-Ack for address 0.0.0.0. If the lack of this option means that the Host system will be unable to use IP with the BRAS, then the behavior should be either shutting down IPCP (using Protocol-Reject or by just giving Configure-Nak until the link times out) or shutting down the entire link with LCP Terminate-Request. Allowing IPCP to go to Opened state with negotiated parameters that are known to be unusable is very much against the intent of PPP negotiation. I don't agree that this is a good solution to the problem. > > Finally, I don't think this works as an individual submission. > > Allocating IPCP code points requires IETF Consensus, which typically > > means working within the PPPEXT working group; see RFC 3818. If you > > want to go ahead without working group review, I suggest looking into > > the Vendor-Specific Option -- see RFC 2153. > > Med: Our plan was to submit this document as individual submission, but if there is an interest of pppext to work on this feature, we can re-consider our plans. Please advise. I don't believe that this work (as it is presently drafted) can or should go forward without approval of the PPPEXT working group due to the requirements of RFC 3818. That document requires consensus to add new options. > This message and any attachments (the "message") are confidential and intended solely for the addressees. Please remove or disclaim this text in any future transmission on this list. It's not appropriate for IETF communications, because these messages are not being kept confidential. -- James Carlson 42.703N 71.076W <carlsonj@workingcode.com>
- [Pppext] new PPP-related individual submission James Carlson
- Re: [Pppext] new PPP-related individual submission James Carlson
- Re: [Pppext] new PPP-related individual submission mohamed.boucadair
- Re: [Pppext] new PPP-related individual submission James Carlson
- Re: [Pppext] new PPP-related individual submission mohamed.boucadair
- Re: [Pppext] new PPP-related individual submission James Carlson
- Re: [Pppext] new PPP-related individual submission Vernon Schryver
- Re: [Pppext] new PPP-related individual submission mohamed.boucadair
- Re: [Pppext] new PPP-related individual submission James Carlson